More attributes for weapons

For what's not in 'Top Priority Game Design'. Post your ideas, visions, suggestions for the game, rules, modifications, etc.

Moderator: Oberlus

Post Reply
Message
Author
User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

More attributes for weapons

#1 Post by Oberlus »

From the discussion about missiles, missiles should be able to be shot down before they hit, and the change in the backend to allow this is not quite complex: involves separating the shots done on each bout into two phases, with a call to CullTheDead() in between, and making the missiles attack on the second phase (rest on first one). That way, if they get damage from flaks, interceptors, etc. on a given bout, they are removed before attacking anyone. If at any time in the future one wants to make another weapon shoot on that second phase, s/he will have to work with the backend, because there is no way to specify such behaviour in FOCS files.

When I was working on diversified weapons for a multi-theme tech tree, more than once I thought it could be nice to have ignoring-shield cannon variants, or even non-ignoring-shield fighters, but it wasn't possible to set that in FOCS because the backend has that attribute coupled to the part class: cannons (class = ShortRange) can't ignore shields, and fighters (class = Fighter) always ignore shields. I'd like those too characteristics specified in separate attributes.

There is also the matter of the combat ranges, that is a possibly incoming feature. Shall we want to implement that with current attributes of ship parts, class should be overloaded as with IgnoreShields.

So I'd like to add new attributes to ship parts

Already present:

* Class (for weapons: cannon/fighter/missile):
- Cannon: direct damage (beam/ballistic).
- Fighter: autonomous vessel, does not attack the bout it's launched, can be shot down.
- Missile: suicidal autonomous vessel, does not attack the bout it's launched, can be shot down, dies on first hit.

* Damage, fire rate / launch bay capacity, and ammunition / hangar capacity are represented with attributes that depending on the part being internal (hangar, ammo storage) or external (weapon, launch bay) mean one thing or the other. That's a bit confusing but it's fine if it saves some memory and CPU time. (These attributes, IIRC strength, capacity and secondaryStat, or something like that, are also reused for non weapon parts.)

* Targets.

I propose to add three new attributes:

* Range (Close/Short/Long):
- Long: shoots from first bout on.
- Short: shoots from second bout on.
- Close: shoots from third bout on.

* First Strike (yes/no):
- Yes: Shoots on first phase of each bout.
- No: Shoots on second phase of each bout (will not shoot if killed on first phase). Primarily for anti-ship missiles, maybe also for bombers and anti-fighter/missile missiles.

* Ignores shields (yes/no).



Current weapons are:
  • MD..DR: Cannon, LongRange, FirstStrike, TargetsEverything (or TargetsPlanetsShips), FireRate 1, Ammunition infinite.
  • Gamma Burst Slingshot (incoming): Cannon, ShortRange, TargetsEverything, FireRate 3.
  • Bomber: Fighter, LongRange, FirstStrike, IgnoreShields, TargetsShips, FireRate 2, Ammunition 2.
  • Fighters: Fighter, LongRange, FirstStrike, IgnoreShields, TargetsShipsFighters, FireRate 2, Ammunition 3.
  • Interceptors: Fighter, LongRange, FirstStrike, IgnoreShields, TargetsFighters, FireRate 4, Ammunition 4.
We could also have:
  • Torpedoes: Missile, LongRange, TargetsShipsPlanets.
  • Missiles: Missile, LongRange, FirstStrike, TargetsMissilesFighters.
  • Cannons with different ranges (shorter range, greater damage) and fire rates (higher rates, smaller damage). This mostly for themed tech tree.
  • Cannons with ammunition (need an internal part)?: can't be shot down, but can run out of ammo when out of supply.

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: More attributes for weapons

#2 Post by Ophiuchus »

Gamma Burst Slingshots role is to remove chaff (small structure ships) in the beginning of the combat i.e. it needs to be long range.
You could make it 2-shot or 1-shot though.

I do not like the two phases in a bout approach too much. It could make the code more convoluted and makes another pass over all shots necessary. There are maybe other alternatives. E.g. you make it self-destructing and untargetable for the bout it hits (could do it in the pass before hitting - no splitting of bout, also no extra pass; also one could put there a countdown/target bout for how many bouts it flies). But lets see what your implementation looks like. Else i think it is OK game play for missiles - there is one bout duration in which it can be taken down before it does damage.

I am also ok with the ignore shield (should be trivial (?)).

Mainly i do not understand what you mean with "attributes". Are you talking about specific implementation or general idea?
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: More attributes for weapons

#3 Post by Oberlus »

Ophiuchus wrote: Thu Feb 13, 2020 9:49 pm Mainly i do not understand what you mean with "attributes". Are you talking about specific implementation or general idea?
I mean the... Let me explain with an example, because I lack the vocabulary.

Code: Select all

Part
    name = "SR_ICE_BEAM"
    ...
    class = ShortRange
    damage = 9
    mountablesSlotTypes = External
    ...
    ignoresShield = Yes   // Defaults to no
    firstStrike = Yes     // Defaults to yes
    range = CloseRange    // Defaults to ShortRange or LongRange
    ...
I'd like to be able to write something like that in FOCS files.

I do not like the two phases in a bout approach too much.
Hmmm, I understand. I try to rethink the idea, and if I don't see a way to make the code readily understandable and as efficient as currently, I'll stick to your idea of flyinng without shooting during one bout.
I really don't like that one-turn-flying idea because it clashes (in my mind) witht he "fighters shoot from within the shields" fluff. "Oh, really? and how did they get there that fast? My superfast missiles are still on the fly!".

Hmmm... What if all missiles and fighters fly one turn without shooting while vaing valid targets?

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: More attributes for weapons

#4 Post by Geoff the Medio »

You seemingly want to add a lot of complexity to combat and weapons, all at once. I'm very reluctant to do that, much preferring separate single impactful changes slowly over time. Consider what your top priority is to add, and whether it will made it harder to understand how existing stuff works by removing some of the consistent rules about how things work that are currently in place.

For missiles, if combat rounds are made available to targetting conditions, presumably that's all you need... Missiles can be made to not attack on round 2, and everything else can be made to not to attack missiles on round 3.

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: More attributes for weapons

#5 Post by Oberlus »

Geoff the Medio wrote: Fri Feb 14, 2020 12:25 am You seemingly want to add a lot of complexity to combat and weapons, all at once.
In the end yes. But for know I'm looking at having a versatile backend (constrained by efficiency) that allows users to mod in the extra complexity they could want.
In other words, I'm not aiming at introducing such weapons in the tech tree now, just allowing that possibility, and only if it does not slow down combat resolution noticeably.
I'm very reluctant to do that, much preferring separate single impactful changes slowly over time.
A sensible attitude.
Consider what your top priority is to add, and whether it will made it harder to understand how existing stuff works by removing some of the consistent rules about how things work that are currently in place.
Roger.
I guess "self-destruct on hit" will be my top priority. Easy to implement: deal damage to the missile in the MissileAttack*() functions.
For missiles, if combat rounds are made available to targetting conditions, presumably that's all you need... Missiles can be made to not attack on round 2, and everything else can be made to not to attack missiles on round 3.
I'm struggling with the idea of missiles being so slow, but I'll try and change my mind if I find no better solution.
However, the "on round 2", "on round 3" thingy is problematic if we allow for variable number of turns:
- Missiles won't make sense with only 2 bouts per round: no attack.
- Having more ammunition than what you could launch on first round would work inconsistently: missiles launched on round 2 will attack unmolested on round 3?
So I'd like it to be "missiles fly one bout, attack on the next one". Can that be done with FOCS currently? I guess not, since you can't know when was launched a missile.

This has simple solution with the division of the bout into two phases, but I won't do that unless I find a way to avoid iterating throught the whole set of combatants twice.
Maybe, during the loop for the phirst phase (currently the main phase after planets have shot down), I can add the objects that should shoot on second phase to a temporal set and only process that temporal set during second phase? I don't think that would make code noticeably complex, but dunno about performance.

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: More attributes for weapons

#6 Post by Ophiuchus »

Oberlus wrote: Thu Feb 13, 2020 10:09 pm I really don't like that one-turn-flying idea because it clashes (in my mind) witht he "fighters shoot from within the shields" fluff. "Oh, really? and how did they get there that fast? My superfast missiles are still on the fly!".
Thats because of the precursor power the intelligent beings tapped into when the starlane network opened up. It makes it possible to sidestep shield. Does not affect dumb missiles. Precursor power FTW :lol:

If we had a graphical combat report I think the why wouldnt be so important. Seeing is believing.
Oberlus wrote: Thu Feb 13, 2020 10:09 pm Hmmm... What if all missiles and fighters fly one turn without shooting while vaing valid targets?
I would be open to do that, add an extra bout (lets call it bout zero even if it is really bout one then) for that.
Fighters could launch in bout zero, no weapon reaches that far. Then Fighters are not allowed to shoot in bout one (they have only ShortRange weapons) while missiles launch. Then in bout two interceptors can take down missiles as they do now.
So same combat result just more fluff in the report. Then probably someone asks why the fighters launch in bout zero if they can start shooting in bout two.

I think we need to up the number of minimum bouts to three anyway so it wont matter if missiles do not work for two bouts. We also need to do this if we make the combat ranges (long,short,close) happen if we do not want the complexity of doing everything different for two bouts (and we do not want the complexity).

Your implementation idea of "self-destruct on hit" is very good I think has minimal dependencies and probably the fastest result.

The "dont shoot at missiles" in bout 3 (which could be formulated as "if bout is greater two then do not target targets which have a EXPLODES_IN_BOUT_3 tag") would have to be added to all combatTarget conditions. How selfdestruction should be implemented best is unclear. From processing standpoint, the missiles probably really be removed after bout 3 (e.g. marking the death of a shooter in bout three; or one extra pass...) but simply ignoring also works. This is actually OT i guess.. (belongs in the missile thread?)

"missiles fly one bout, attack on the next one" - Cant be done without changing backend. But I like the shoot-all-missiles-you-can at once more anyway (i.e. the same as only-launch in bout one). There are more subtle nuances but that is again talking design.

What I would like more than a ignoresShield attribute would be a damageEffects attribute which would override the defaults (i.e. everything but fighters takes shield meter into consideration). damageEffects would take a bunch of FOCS effect or (restricted) effectGroups. Then you could script there whatever you deem necessary (having part type, shooter source and target available) with shield piercing being the most easiest (i.e. remove part damage meter from target structure for ships). More complicated content could scale the damage depending on the target type or on the bout (e.g. doing the more damage you closer you get with maximum damage in shortrange). The downside would be similar to what is happening with targeting: damage estimation is probably off (which affects AI, stats and UI) and maybe also ship damage presentation UI. This could be right if damage gets simulated against the right kind of target. So first fix this for combatTargets and afterwards maybe add damageEffect. This probably also should go into a specialised thread.

For this thread I think geoff answer means: No, not all at once.

As you said your priority are missiles I suggest going back to the missile design thread.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: More attributes for weapons

#7 Post by Geoff the Medio »

An option is to add tracking of the combat round in which a fighter or missile was launched. Targeting one would require them to have been launched in the previous round, but not 2+ rounds prior. If the combat goes to 4+ rounds, that should still work fine... unless missiles can survive longer than to 2 rounds after they launch in some cases, such as when there are no targets left for them on the round 2 after they launched. Perhaps they should self destruct 2 rounds after launch regardless of availability of valid targets at that time?

User avatar
labgnome
Juggernaut
Posts: 833
Joined: Mon Mar 02, 2015 5:57 pm

Re: More attributes for weapons

#8 Post by labgnome »

Oberlus wrote: Fri Feb 14, 2020 9:25 am
Geoff the Medio wrote: Fri Feb 14, 2020 12:25 am You seemingly want to add a lot of complexity to combat and weapons, all at once.
In the end yes. But for know I'm looking at having a versatile backend (constrained by efficiency) that allows users to mod in the extra complexity they could want.
In other words, I'm not aiming at introducing such weapons in the tech tree now, just allowing that possibility, and only if it does not slow down combat resolution noticeably.
I'm personally all for this. In my opinion: the more mod-able Free Orion is the better it can be made to be. Plus for me my favorite parts of my favorite games are the mods. So even if it never makes into the game proper doesn't mean it's a waste of resources.
I'm very reluctant to do that, much preferring separate single impactful changes slowly over time.
A sensible attitude.
I mean I can see that too, but I also think that this could be a good place to create a road-map of what we want to see in the future. Maybe one thing at a time, but also map out what we want to do next. There are a lot of good ideas here. We are still less than half-way to version 1.
When I was working on diversified weapons for a multi-theme tech tree, more than once I thought it could be nice to have ignoring-shield cannon variants, or even non-ignoring-shield fighters, but it wasn't possible to set that in FOCS because the backend has that attribute coupled to the part class: cannons (class = ShortRange) can't ignore shields, and fighters (class = Fighter) always ignore shields. I'd like those too characteristics specified in separate attributes.
I'd like to see this too. Maybe also both shield-ignoring and non-shield-ignoring missile weapons as well would be interesting.



Current weapons are:
  • MD..DR: Cannon, LongRange, FirstStrike, TargetsEverything (or TargetsPlanetsShips), FireRate 1, Ammunition infinite.
  • Gamma Burst Slingshot (incoming): Cannon, ShortRange, TargetsEverything, FireRate 3.
  • Bomber: Fighter, LongRange, FirstStrike, IgnoreShields, TargetsShips, FireRate 2, Ammunition 2.
  • Fighters: Fighter, LongRange, FirstStrike, IgnoreShields, TargetsShipsFighters, FireRate 2, Ammunition 3.
  • Interceptors: Fighter, LongRange, FirstStrike, IgnoreShields, TargetsFighters, FireRate 4, Ammunition 4.
You forgot
  • Flack: Cannon, ShortRange, TargetsFighters (or TargetsMissilesFighters), FireRate 3, Amunition infinite?
  • Spinal Antimatter Cannon: Cannon, Long Range, TargetsPlanetsShips, FireRate1, Ammunition Infinite?
Also, I thought that all fighters had a FireRate of 2 set by the launcher? Or am I confused.
We could also have:
  • Torpedoes: Missile, LongRange, TargetsShipsPlanets.
  • Missiles: Missile, LongRange, FirstStrike, TargetsMissilesFighters.
  • Cannons with different ranges (shorter range, greater damage) and fire rates (higher rates, smaller damage). This mostly for themed tech tree.
  • Cannons with ammunition (need an internal part)?: can't be shot down, but can run out of ammo when out of supply.
You could also have:
  • (Plasma) Bombs: Missile, LongRange, IgnoreShields, TargetsShips (or TargetsShipsFighters).
I must say I really like the idea of cannons with ammo it intrigues me greatly. Maybe a good fit for the Mech theme.
All of my contributions should be considered released under creative commons attribution share-alike license, CC-BY-SA 3.0 for use in, by and with the Free Orion project.

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: More attributes for weapons

#9 Post by Oberlus »

Ophiuchus wrote: Thu Feb 13, 2020 9:49 pmI am also ok with the ignore shield (should be trivial (?)).
To implement the ignore shield FOCS parameter/attribute/whatever (something you can set in FOCS for weapons), we would part declarations in FOCS of "class = ShortRange" or "class = FighterHangar" to accept an "ignoreshield = 1/0" parameter/attribute/whatever.

C++ changes to make that happen:
I have to look into it yet, but it involves adding a new private variable to class FO_COMMON_API PartType. Something like m_ignores_shield. But that's seems ugly when PartType is used for every kind of parts and no other kind apart from offensive combat effects will "ignore shields" (maybe something about invasion...).

That let me to the think of putting some consistency into the two variable names in class PartType used in combat (and other kind of parts):

Code: Select all

m_capacity;       // damage per shot for cannons, capacity (fire rate) for hangars, strength for other parts like shields, armour and troop pods.
m_secondary_stat; // damage per shot for fighters, fire rate for cannons, no idea if used in other parts.
I'd suggest changing them to:

Code: Select all

m_strength;       // damage per shot for weapons, strength for shields and armor, in general the value of the main effect of the part.
m_rate;           // cannon shots per bout, hangar capacity, launch (bay) rate (fire rate of fighters), in general frequency of any particular effect.
And adding some more:

Code: Select all

m_flag:           // ignores_shields for weapons. Effects that could ignore or not certain values, or have a modality/direction, or can be boosted or countered by a certain trait like telepathy...
m_malus_strength; // damage taken when shoot for suicidal/melee weapons.
m_range;          // Range of weapons (bout at which they start shooting/launching), radius/hops for map effects.
m_delay:          // flying time without shooting/targetting for fighter/missile/pod weapons. Delay in turns after activation for map effects?
Some might not be necessary at all. I would add them (make PRs) one by one, after testing any other change in the code related to them (including getting into the Parser, which I haven't look at yet), and only make those PRs if the effects that would support have a good reception after a discussion (i.e. if the invidicual new variable is accepted for it's usefulness). The idea of bringing so many suggestions together is just to think in advance for good names of the variables.
Regarding the change of names for the first two, I know it might be annoying for others, so the same about consensus goes here.

Post Reply