Combat Preferred Targetting

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

Moderator: Oberlus

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

Re: Combat Preferred Targetting

#46 Post by Ophiuchus »

Krikkitone wrote: Wed Oct 17, 2018 9:03 pm Possible Targets would be conceptually simpler than priority targets, and force a degree of "combined arms" (every decent assault fleet will need to be able to attack boats/missiles, ships, and planets)
Yes, I also think that possible_targets is simpler and easier to understand. But i think i (or the AI) would not like not being able to fight with my fleet because my enemy has forces which are not in the possible_targets of my fleet.

I also think that i can't solve all the problems i wanted with possible_targets. priority_targets alone is able to solve all. And the combination of possible_targets and priority_targets is able to solve all well. I am not sure if priority is completely necessary if we have both possible_targets and priority_targets.

The problems from top of my head are: "disarming" of decoys, useful differentiation of bombers/fighters/interceptors, enhance flak usefullness.

With possible_targets only: flak could be restricted to boats (i think this is ok), bombers could be restricted to ships, interceptors could be restricted to bombers (if we add a LaunchedBy condition), fighters could be restricted to boats (not sure that is ok), restricting ship weapons to shoot only dangerous ships (having weapons, troops) would remove decoys completely from the game and prohibit one from shooting down scouts/colonies/outposts (which is probably unacceptable). This would also mean a huge shift in game balance i think.
Krikkitone wrote: Wed Oct 17, 2018 9:03 pmIt would also force a degree of consideration of the enemy
You probably mean that you have to set up "combined arms" accordingly?
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: 13586
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Combat Preferred Targetting

#47 Post by Geoff the Medio »

Ophiuchus wrote: Thu Oct 18, 2018 10:36 amBut i think i (or the AI) would not like not being able to fight with my fleet because my enemy has forces which are not in the possible_targets of my fleet.
While theoretically possible, I think this sort of situation would be relatively rare. Most ships should be able to shoot other ships, and players should design ships so that's the case.
I also think that i can't solve all the problems i wanted with possible_targets. priority_targets alone is able to solve all. And the combination of possible_targets and priority_targets is able to solve all well. I am not sure if priority is completely necessary if we have both possible_targets and priority_targets.
Conditions can be written to sort objects and pick the "top" X from the sorted list. With some limitations, this can be used to implement priority select of targets within a targeting condition. A basic targeting condition for interceptors might match all fighters. A sorted targeting condition for spinal mount weapons might attack the ship with the highest structure. A more complicated targeting condition for mass drivers might target ships if any are present, and if no ships are present, then target fighters. This may not be possible with the current conditions and valuerefs, but suitable support wouldn't be very difficult to implement, and can be added later.
...interceptors could be restricted to bombers (if we add a LaunchedBy condition)
Could you elaborate on this?
This would also mean a huge shift in game balance i think.
Any modification of this sort will substantially affect balance.

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

Re: Combat Preferred Targetting

#48 Post by Ophiuchus »

Geoff the Medio wrote: Thu Oct 18, 2018 2:29 pmConditions can be written to sort objects and pick the "top" X from the sorted list.
So every part gets its own definition? How to combine those? If I get you right you suggested a hardcoded cadence (e.g. basic level weapon/hangar part; next tier battle scanner; next tier species; next tier battle policy) which narrows down the targets list in each tier until either there are no tiers left or no targets. If no targets left, you choose one of the last tier. (And the basic tier being the exception: if no targets, you dont shoot).

Note with that deterministic approach that if fleet narrows down the target list to one out of hundred, all your weapons will fire at that one target and ignore the other 99.
Geoff the Medio wrote: Thu Oct 18, 2018 2:29 pm
...interceptors could be restricted to bombers (if we add a LaunchedBy condition)
Could you elaborate on this?
The current way to specify space boats (or fighters in your lingo) is And [ Not Ship Not Planet ]. There is no way to check what kind of space boat was launched. But it would be really easy to add a LaunchedBy condition which checks the hangar part from which the boat was launched. e.g. LaunchedBy hangar="FT_HANGAR_3" or something like e.g. LaunchedByHangar HasTag="ANTI_SHIP".
Geoff the Medio wrote: Thu Oct 18, 2018 2:29 pm
This would also mean a huge shift in game balance i think.
Any modification of this sort will substantially affect balance.
I disagree. The slight shifting of probabilities with priority_targets only does affect balance, but the deterministic exclusion of possible_targets only can completely tilt it. My gut feeling is also that AI will have more problems with the latter.
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: 13586
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Combat Preferred Targetting

#49 Post by Geoff the Medio »

Ophiuchus wrote: Thu Oct 18, 2018 7:56 pmSo every part gets its own definition? How to combine those?
They aren't combined. Each weapon part has a condition that determines its targets independently of all other parts.
If I get you right you suggested a hardcoded cadence (e.g. basic level weapon/hangar part; next tier battle scanner; next tier species; next tier battle policy) which narrows down the targets list in each tier until either there are no tiers left or no targets. If no targets left, you choose one of the last tier. (And the basic tier being the exception: if no targets, you dont shoot).
Multiple tiers can be considered later. For now, just add conditions to parts to pick targets.
Note with that deterministic approach that if fleet narrows down the target list to one out of hundred, all your weapons will fire at that one target and ignore the other 99.
The fleet does nothing. Individual weapon parts shoot.
The current way to specify space boats (or fighters in your lingo) is And [ Not Ship Not Planet ].
The Type condition should be extended to handle OBJ_FIGHTER just like OBJ_SHIP or OBJ_PLANET.
There is no way to check what kind of space boat was launched.
Fighter objects track their damage, species, and the id of the ship they were launched from. Adding tests based on those properties would be simpler... and probably just the damage test is enough to classify the "kind of space boat"?

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

Re: Combat Preferred Targetting

#50 Post by Ophiuchus »

Geoff the Medio wrote: Thu Oct 18, 2018 9:12 pm
Ophiuchus wrote: Thu Oct 18, 2018 7:56 pmSo every part gets its own definition? How to combine those?
They aren't combined
So no battle scanners? No species, policy... conditions? Else, if you have multiple sources those are in some way implicitly or explicitly combined.
Geoff the Medio wrote: Thu Oct 18, 2018 9:12 pm
Ophiuchus wrote: Thu Oct 18, 2018 7:56 pmNote with that deterministic approach that if fleet narrows down the target list to one out of hundred, all your weapons will fire at that one target and ignore the other 99.
The fleet does nothing. Individual weapon parts shoot.
You seem to miss the essence of what i wrote, so I rephrase: All the individual weapons in the ships in that system will shoot at that one target and ignore the other 99 because they have the same deterministic possible_targets condition.
Geoff the Medio wrote: Thu Oct 18, 2018 9:12 pm
Ophiuchus wrote: Thu Oct 18, 2018 7:56 pmThere is no way to check what kind of space boat was launched.
Fighter objects track their damage, species, and the id of the ship they were launched from. Adding tests based on those properties would be simpler... and probably just the damage test is enough to classify the "kind of space boat"?
If you have a super-fancy condition which knows of tech level of your enemies and possibly other effects which affect the damage of a space boat. If your intend is not to query for the ship it was launched from, one could add the tags from launcher and hangar parts to the launched boat and query something there. But is a dictionary lookup so evil? LaunchedBy would be much cleaner and flexible IMHO.
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: 13586
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Combat Preferred Targetting

#51 Post by Geoff the Medio »

Ophiuchus wrote: Fri Oct 19, 2018 4:49 pmSo no battle scanners? No species, policy... conditions? Else, if you have multiple sources those are in some way implicitly or explicitly combined.
Not for the first iteration. Probably later.
Ophiuchus wrote:All the individual weapons in the ships in that system will shoot at that one target and ignore the other 99 because they have the same deterministic possible_targets condition.
An implementation detail is whether to enforce number of targets in the condition or after the condition narrows down the options. The NumberOf condition can return a specified number of objects (eg. 1 or 3) randomly selected from the matches of a subcondition. Atlernatively, the battle code could take the list of matches and draw however many objects are needed for the number of shots the weapon has (allowing or not allowing replacement of drawn objects). The latter would be more efficient if there are multiple copies of the same part that will have the same set of candidate objects for a given attack round, as the condition would still only need to be evaluated once regardless of how many parts will use the results.
Ophiuchus wrote:If you have a super-fancy condition which knows of tech level of your enemies and possibly other effects which affect the damage of a space boat.
That shouldn't be needed; Fighter objects have a damage property. I'd just add a Condition or ValueRef to test that value for fighters, which can be used in targeting conditions. One can also set up a ValueRef to get the the name of the design of the ship that launched a fighter, since fighters track ship they launched from. This would involve adding a suitable ValueRef to access the Fighter object's stored launching-ship-ID.
Last edited by Geoff the Medio on Sun Oct 21, 2018 10:18 am, edited 1 time in total.
Reason: Fixed mis-attributed quotes

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

Re: Combat Preferred Targetting

#52 Post by Ophiuchus »

Geoff the Medio wrote: Fri Oct 19, 2018 5:12 pm
Ophiuchus wrote: Fri Oct 19, 2018 4:49 pmSo no battle scanners? No species, policy... conditions? Else, if you have multiple sources those are in some way implicitly or explicitly combined.
Not for the first iteration. Probably later.
I honestly don't have the resources necessary for that kind of development style. The discussion was already past the first iteration some weeks ago. Is the intention to have something more complex or is it off the table? This really matters for the design and "later".

Maybe I speak from bad experience, but for imperial stockpile i did a 80/20 solution in about one and a half weeks. It took more than a year to get a solution into the project. I can't remember any development effort less efficienct in my whole life. I went with it to learn the freeorion way, but i certainly wont commit again to it.

So what can I offer? You seem to have a very clear understanding where you want this to go, i think you can just rip the parts you need out of the PR and do an implementation accordingly. Else i could offer basic support for possible_targets allongside priority_targeting to get somebody else started. But I certainly wont do the polishing with new conditions and tweaking all the content to fit the scheme like you suggested.
Geoff the Medio wrote: Thu Oct 18, 2018 9:12 pmAn implementation detail is whether to enforce number of targets in the condition or after the condition narrows down the options...
I really don't understand why you say that and the connection to what i wrote. If you have a possilbe_targets condition like armed ships, all the enemy troops, scouts, ... will be unharmed.
Geoff the Medio wrote: Thu Oct 18, 2018 9:12 pm
Ophiuchus wrote: Fri Oct 19, 2018 4:49 pmIf you have a super-fancy condition which knows of tech level of your enemies and possibly other effects which affect the damage of a space boat.
That shouldn't be needed; Fighter objects have a damage property.
Which is different depending on the hangar type, the owners empire tech, if the ship was resupplied since tech change and species weapon skill. Probably something else what i forgot. Does not look too simple to me.
Geoff the Medio wrote: Thu Oct 18, 2018 9:12 pmI'd just add a Condition or ValueRef to test that value for fighters, which can be used in targeting conditions. One can also set up a ValueRef to get the the name of the design of the ship that launched a fighter, since fighters track ship they launched from. This would involve adding a suitable ValueRef to access the Fighter object's stored launching-ship-ID.
Yes, i called that condition "LaunchedBy". I am really not sure you read what i wrote...
*puzzled*
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: 13586
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Combat Preferred Targetting

#53 Post by Geoff the Medio »

Ophiuchus wrote: Sat Oct 20, 2018 11:41 pm
Geoff the Medio wrote: Fri Oct 19, 2018 5:12 pmNot for the first iteration. Probably later.
I honestly don't have the resources necessary for that kind of development style. The discussion was already past the first iteration some weeks ago. Is the intention to have something more complex or is it off the table? This really matters for the design and "later".
For this case (targetting), it's not necessary to implement a complicated multi-tier system immediately. Just adding conditions to select targeting for parts will be functional in of itself, should solve some / much of the problems motivating these changes, and should be relatively quick. It can also be implemented in a way that effectively changes nothing to start with... in that the targeting conditions added to parts can replicate the hard-coded part-type-based restrictions that currently exist. It will thus allow small incremental scripted content changes to be tried out and tested to see what works and doesn't. After that's implemented and understood with testing, whether how to extend the system further can be better determined than now. We / you shouldn't spend a lot of effort and time implementing a much more complicated system than is necessary to make that first step. By keeping the scope of the initial changes smaller, it can get accepted and put into master much quicker, at which point other can start experimenting with it.

The stockpile case was a bit different, in that there needed to be a lot of interacting complicated systems working together to get it right. But the stockpile is the same in that knowing how it will work as a system before it was implemented and tested wasn't possible.

Since in this case things can be done more incrementally, I strongly prefer to do so, and just start with the minimal functional change, which is, I think, adding a targeting condition to parts to extend and replace the part-type based restrictions that currently exist. Prioritizing targets with randomness might be interesting, but I don't think it's necessary or a good idea. If it is done, I don't think it should be done the way you propose, and should instead be done using the existing conditions mechanism, with some supporting extensions to that.

It's also not necessary to add any new conditions to start with, to support things like fighters that have a particular damage value, or better support for sorting / prioritizing targets instead of just filtering them. The current system just has fighter vs. not, and all that is needed to support that is to extend the types recognized by the ObjectType condition, which currently doesn't support matching Fighter objects. This is a relatively simple change, which I can just do in master if you prefer not to. And if without that change, a workaround could be scripted using something like "Not [Or [Planet Ship]]", which would be equivalent to "Fighter" in the context of objects involved in combat. Edit: "Fighter" should work now in master /Edit
Geoff the Medio wrote: Thu Oct 18, 2018 9:12 pmAn implementation detail is whether to enforce number of targets in the condition or after the condition narrows down the options...
I really don't understand why you say that and the connection to what i wrote. If you have a possilbe_targets condition like armed ships, all the enemy troops, scouts, ... will be unharmed.
I was discussing how to go from a large set of possible targets (that match a targeting condition like "Fighter" or "Ship") to a single or small set of targets that will actually be fired upon by a weapon. This was in response to:
Ophiuchus wrote: Fri Oct 19, 2018 4:49 pmAll the individual weapons in the ships in that system will shoot at that one target and ignore the other 99 because they have the same deterministic possible_targets condition.
Regarding what happens to objects that don't match a targeting condition, like unarmed ship or planets if the targeting condition excludes them, I don't think that needs to be addressed in the first pull request. I have suggested solutions though; the most flexible would be having a sorting based targeting condition, which will pick armed ship first, and then target unarmed if no armed ships are present. Doing this would probably require implementing some non-trivial condition support though, so I'd put that off for now. Alternatively, use conditions that limit the target of a weapon to armed ships sparingly. Most weapons in the initial iterations should target all ships. A few specialized one could target only armed ships. This would be a temporary solution, though.
Geoff the Medio wrote: Thu Oct 18, 2018 9:12 pmFighter objects have a damage property.
Which is different depending on the hangar type, the owners empire tech, if the ship was resupplied since tech change and species weapon skill. Probably something else what i forgot. Does not look too simple to me.
Fighter objects are created during combat and assigned a damage value at that time based on the meters of the ship they launch from. After that, it doesn't matter what effects or factors lead to a fighter object having a particular damage value, and it isn't necessary to know what hangar type a fighter launched from to test its damage value. A fighter's damage value can be tested and matched by a condition (that needs to be implemented, but not necessarily in the first pull request, or by you).
Geoff the Medio wrote: Thu Oct 18, 2018 9:12 pmI'd just add a Condition or ValueRef to test that value for fighters, which can be used in targeting conditions. One can also set up a ValueRef to get the the name of the design of the ship that launched a fighter, since fighters track ship they launched from. This would involve adding a suitable ValueRef to access the Fighter object's stored launching-ship-ID.
Yes, i called that condition "LaunchedBy". I am really not sure you read what i wrote...
*puzzled*
LaunchedBy would let one get access to the statistics of the ship that launched the fighter. But as above, this information is unnecessary to just check what the fighter's damage value is because the Fighter object itself contains the damage value which is set when the Fighter object is created when the fighter is launched. Edit: I've added support for the .Attack property on fighter objects in FOCS, which returns their stored damage value. /Edit

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

Re: Combat Preferred Targetting

#54 Post by Geoff the Medio »

So what can I offer? You seem to have a very clear understanding where you want this to go, i think you can just rip the parts you need out of the PR and do an implementation accordingly. Else i could offer basic support for possible_targets allongside priority_targeting to get somebody else started. But I certainly wont do the polishing with new conditions and tweaking all the content to fit the scheme like you suggested.
I would ask you to implement a "combat_targets" (or similarly named) condition for ship parts, and use it to pick targets for weapons in combat:
-There should be a condition member added to PartType to hold the targeting condition, and an optional extra field in the parser that will set it.
-During combat, when a ship is picking a target for a weapon, this condition should be evaluated on the set of all objects in the combat, and the set of those objects that match the condition should be considered valid targets for the weapon.
--If a part has no targeting condition specified, it can target everything in the battle, or perhaps default to "EnemyOf empire = Source.Owner" or equivalent.
-Up to "shots" of those objects should be chosen, and the weapon will fire on those objects.
--The "shots" should be selected separately for each copy of the weapon part in the ship's design.
--Alternatively, the shots stat could be referenced in the condition, and shots independent objects could be picked (thereby avoiding the same object being targeted more than once per round).

You said you don't want to modify conditions or script things, but we'll also need to:
-Extend the ObjectType condition to allow matching fighter objects in combat. Edit: already done in master /Edit
-Add suitable targeting conditions, probably with macros, to all weapon part scripts, to replicate the existing weapon type-based restrictions, like fighters not attacking planets, and to add some suitable new ones, like Flak only targeting fighters.

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

Re: Combat Preferred Targetting

#55 Post by Ophiuchus »

Geoff the Medio wrote: Sun Oct 21, 2018 11:09 amYou said you don't want to modify conditions or script things, but we'll also need to..
Yes, i am in a wrapping up phase and want to pass the baton on. As offered i can do a very basic implementation because i am probably fastet for that part. But that implementation in itself will not give any feature and may be broken until somebody fills the holes.

Did you voluteer for finishing it up? Or who is?
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: 13586
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Combat Preferred Targetting

#56 Post by Geoff the Medio »

I'll deal with any necessary Condition adjustments (and already have done much of ut I think. Once the parsing is in olace, setting up default conditions to replicate the existing behaviour sgouldn't take long so I can do that as well. You doing the parsing actually selecting targets would be very helpful, though, and at least partly similar to what you've already done.

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

Re: Combat Preferred Targetting

#57 Post by Ophiuchus »

Lookyou PR-2307 for possibleTargets implementation.
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!

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

Re: Combat Preferred Targetting

#58 Post by Ophiuchus »

Just to wrap this thread up; a version combat targetting was merged into master (PR-2330).

Notes about the combat system for players
  • combatTargets conditions are evaluated once at the beginning of each combat round (aka combat bout)
  • Flak parts target enemy fighters
  • interceptors target enemy fighters
  • default is that ship weapons target planets with defense higher zero, enemy ships and enemy fighters
  • default is that fighters target enemy ships and enemy fighters
  • planets target visible enemy ships (no way to override this currently)
FOCS scripting notes:
  • Source is the ship for short range weapons ship parts
  • Source is the fighter for hangar ship parts; one can query the launching ship id using the LaunchedFrom ValueRef
  • one can filter fighter objects using the Fighter condition
  • one can query damage of fighters, total damage of ships, total damage of fleets using the Attack ValueRef
  • Possible targets (aka scope) are all universe objects which are in the combat (e.g. planets,ships,fighters, including your own)
  • there is no combination logic in the backend; you have to script it in each single part (better use FOCS macros)
  • Note it is possible to implement tiered targeting, changing the target set from one bout to the other
  • fighters get removed at the end of combat bouts when hit; note that currently you have to exclude Ships with no Structure manually
  • reusable macros are in default/scripting/ship_parts/targeting.macros
  • the implemented conditions contain a lot of detail; objects are filtered to be visible to the source owner; "enemy" means enemy or unowned objects, or if the source is unowned, "enemy" means objects which belong to an empire ; "ships" mean ships with structure higher zero
Not sure you can filter fleets.
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!

Post Reply