Custom Battle Phases

Trevan

@LaFayette See the https://forums.triplea-game.org/topic/2348/custom-firing-groups-for-units/ for probably a better version of the targeting definition. It is based on the already existing typeAA and targetsAA.

And for the "Dynamic calculation of squadrons", the problem with that is you need to display a name in the Battle UI when things fire. So, my proposal allows the map maker to actually specify the name of the group. Again, this is similar to the typeAA property but centralizes it so you don't have accidental mistakes where two units with the same typeAA have different targetsAA (the engine will just pick the first one it sees).

LaFayette

How would you handle the hypothetical scenario with two first strike units each with different targets?

Couldn't the name just be derived based on some attributes of the unit?

Trevan

@LaFayette said in Custom Battle Phases:

Another related question is whether we should simplify our implementation of the rules for whether first strike is merely neutralized or negated. If we go with negated, that could be cohesive with any other unit ability that also has a counter ability.

It depends on the map. In WW2V2, I would say that first strike is neutralized if an isDestroyer is present because the first strike still happens but the casualties can still fire back. In non-WW2V2, first strike is negated if an isDetroyer is present because the first strike never happens and the isFirstStrike units fire with the rest of the units.

LaFayette

@Trevan Perhaps there is confusion, I'm not seeking clarification of the rules. I'm proposing that we consider removing that distinction so that an 'anti-ability' always removes the opposing ability. This creates symmetry and cohesiveness with any other anti-ability and creates a concept of an anti-ability with a well understood definition of what it does.

LaFayette

To another extent, what I'm getting at is it seems that any unique combat ability would roll on its own. This perhaps could be as simple as defining the ordering of when combat abilities would roll. We then know which abilities those target by looking at an ability definition XML and which units have that ability by looking at the unit definition.

Trevan

@LaFayette said in Custom Battle Phases:

How would you handle the hypothetical scenario with two first strike units each with different targets?

Couldn't the name just be derived based on some attributes of the unit?

I would handle it similar to how AA units with different targets are handled, but in a centralized manner. Currently, with AA, you do the following:

<attachment name="unitAttachment" attachTo="destroyer" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
<option name="typeAA" value="Depth Charge" />
<option name="targetsAA" value="submarine" />
...
</attachment>
<attachment name="unitAttachment" attachTo="cruiser" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
<option name="typeAA" value="Sea to Air" />
<option name="targetsAA" value="fighter" />
...
</attachment>

But as I mentioned, that has the problem (which I've found maps that do have this problem) of mistypes where the same typeAA has different targetsAA.

So, to fix that problem, it would be in a central location, inside of the battlePhases or battleGroups or firingGroups (the name doesn't really matter). And it could look like:

<firingGroup name="Depth Charge">
  <firingUnits>
    <unit name="destroyer" />
  </firingUnits>
  <targetUnits>
    <unit name="submarine" />
  </targetUnits>
</firingGroup>
<firingGroup name="Sea to Air">
  <firingUnits>
    <unit name="cruiser" />
  </firingUnits>
  <targetUnits>
    <unit name="fighter" />
  </targetUnits>
</firingGroup>

LaFayette

Would you comment on defining targets as part of unit abilities vs in battle phases?

I think the former scales better and would be more cohesive. I also think it would be fundamentally simpler, where the battle phases is largely just defining an ordering. There is more to the battle phases than the target groups, which makes me think keeping it largely to ordering would keep it simpler.

Trevan

@LaFayette said in Custom Battle Phases:

To another extent, what I'm getting at is it seems that any unique combat ability would roll on its own. This perhaps could be as simple as defining the ordering of when combat abilities would roll. We then know which abilities those target by looking at an ability definition XML and which units have that ability by looking at the unit definition.

I don't believe that would actually work with how map makers are using typeAA/targetsAA and the other requests that have been made. Looking at existing maps, I just don't see how that would fit.

Maybe could you give an example of how to implement your hypothetical scenario where two first strike units have different targets or the real scenario of two AA units have different targets?

LaFayette

Sorry for quick responses here @Trevan , I'll come back later today with some more detailed examples comments.

One quick item, food for thought: I think part of the issue is the over-use of 'AA' type. I suspect that is more a hack than anything else to simulate behavior.

If we avoid using that concept so heavily, we could have something like the following example:

<unitAbility name="Depth Charge" casualtiesImmediatelyRemoved="true">
    <targets>....
</unitAbility>


<combatPhases>
       <phase unitAbility="Depth Charge" order="1" />
        <generalPhase order="2" />
</combatPhases>

Trevan

@LaFayette no problem with taking time.

As for your example, that actually looks a lot like what I'm proposing, just with different names. You basically renamed "firingGroup" to "unitAbility". So I don't have much of a problem with that.

I think part of the issue is the over-use of 'AA' type. I suspect that is more a hack than anything else to simulate behavior.

Since it is the only way for units to target specific units, that is what map makers had to use. The custom firing groups/battle phases/etc is meant to try and unify that logic so that it isn't AA specific anymore and so that map makers don't have to hack it.

Trevan

@LaFayette said in Custom Battle Phases:

Perhaps there is confusion, I'm not seeking clarification of the rules. I'm proposing that we consider removing that distinction so that an 'anti-ability' always removes the opposing ability. This creates symmetry and cohesiveness with any other anti-ability and creates a concept of an anti-ability with a well understood definition of what it does.

The engine currently supports three types of "anti-abilities".

Prevent the unit from firing (willNotFireIfPresent which prevents an AA unit from firing)
Allow the casualties to fire back (WW2V2 and isDestroyer which is used to prevent an isFirstStrike from killing a casualty outright but it still allows it to fire during its phase)
Force the unit to fire in the latter phase (non-WW2V2 and isDestroyer which forces an isFirstStrike to fire in a different phase)

So, the idea of unifying the "anti-abilities" is great but it needs to support those three types.

There's also the comment in https://forums.triplea-game.org/post/43790 where @alkexr asked to have an "unlessOffense" and an "unlessDefense". That would mean that a unit might have an "friendly anti-ability" and/or an "enemy anti-ability".

Trevan

@Trevan said in Custom Battle Phases:

So, the idea of unifying the "anti-abilities" is great but it needs to support those three types.

Thinking about this more, I think anti-abilities might work if they also allow changing abilities. Then, if you don't change the ability, it handles type #1 but if you do change the ability, it handles both #2 and #3.

LaFayette

I think it is on the table to consider whether to merge #2 and #3 together. Is the distinction between those two actually so significant that we should continue to code it in? There is an impact to the rule style between confusion, extra clicks, extra logic in code, and extra configuration to select between one or another.

If those two are merged then this calculus would also seem simplified and the battle algorithms for sorting units and selecting firing squadrons and what fires during which phases would all be more unified.

Thinking about this more, I think anti-abilities might work if they also allow changing abilities.

@Trevan would you clarify this a bit, I don't quite fully understand.

Trevan

@LaFayette said in Custom Battle Phases:

Is the distinction between those two actually so significant that we should continue to code it in?

The distinction is significant. In WW2V2, all subs fire at the same time, no matter if their casualties will return fire or not. Say the defense has an isDestroyer. The offense subs fire and the defense has to pick their casualties but those casualties will return fire. Then the defense fires and the offense has to remove their casualties. In this situation, the offense subs still were able to fire.

But in non-WW2V2 situation, the offense subs would fire AFTER the defense subs have fired. So a defense sub could kill an offense sub and prevent it from firing.

So, #2 means that the units will always have a chance to fire while #3 means that the units might not have a chance to fire.

@LaFayette said in Custom Battle Phases:

Thinking about this more, I think anti-abilities might work if they also allow changing abilities.

@Trevan would you clarify this a bit, I don't quite fully understand.

Based off of your basic example, here's WW2V2 example:

<combatPhases>
  <phase name="first strike" order="1">
    <ability name="submarine"/>
    <ability name="submarine with return fire"/>
  </phase>
  <phase name="general" order="2">
    <ability name="general"/>
    <ability name="air vs non submarine"/>
  </phase>
</combatPhases>

<unitAbility name="submarine" returnFire="false">
    <targets>...</targets>
</unitAbility>
<unitAbility name="submarine with return fire" returnFire="true">
    <targets>...</targets>
</unitAbility>
<unitAbility name="general">
    <targets>...</targets>
</unitAbility>
<unitAbility name="air vs non submarine">
  <targets>
    <target>destroyer</target>
  </targets>
</unitAbility>
<unitAbility name="negate first strike">
  <abilityFrom>submarine</abilityFrom>
  <abilityTo>submarine with return fire</abilityTo>
</unitAbility>
<unitAbility name="allow air to hit submarines">
  <abilityFrom>air vs non submarine</abilityFrom>
  <abilityTo>general</abilityTo>
</unitAbility>
<attachment name="unitAttachment" attachTo="destroyer" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
  <unitAbilities>
    <ability>general</ability>
  </unitAbilities>
  <antiAbilities>
    <ability side="enemy">negate first strike</ability>
    <ability side="ally">allow air to hit submarines</ability>
  </antiAbilities>
...
</attachment>
<attachment name="unitAttachment" attachTo="submarine" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
  <unitAbilities>
    <ability>submarine</ability>
  </unitAbilities>
...
</attachment>
<attachment name="unitAttachment" attachTo="fighter" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
  <unitAbilities>
    <ability>air vs non submarine</ability>
  </unitAbilities>
...
</attachment>

The destroyer has two "anti-abilities", one that effects enemy units and one that affects ally units.

The first one, "negate first strike", will change any enemy units that have the "submarine" ability to instead have the "submarine with return fire" ability. Both of those abilities occur in the first phase but one has returnFire=true and one has returnFire=false.

The second one, "allow air to hit submarines", will change any ally units that have the "air vs non submarine" ability to instead have the "general" ability. This allows the fighter to be able to hit the submarine if it has an ally destroyer.

LaFayette

Concern: we are making things more general but are still specific (in which case it's arguably just complex but not actually more generic). EG: rule names that mention "submarines" and that know about specific unit types. This seems to be the same problem where everything knows about AA rather than just being it's own combat phase.

For first strike, it actually seems like that ability name is underspecified and it's an option whether other first strike units get to return fire or not. If we can design the unit abilities in such a way that an 'anti-ability' is a wholesale negation or (an effective) removal of the ability, I think that would make things quite a bit simpler and lend itself to generic abilities and anti-abilities. It would also let us avoid having specific submarine logic and instead we could have XML that is less aware of specific units and instead defines abilities, when those abilities fire in combat, and what those abilities do (EG: the abilities have a set of parameters, what it targets, whether those units get to fire back, etc).

LaFayette

In part what I'm getting at is if we were to have custom battle phases I think it should overall be relatively generic. No phase should be defined in terms of specific units. If we have that, then we have combat logic that knows about specific unit types an their abilities. This couples unit types and abilities, specific games, to the generic battle flow. Instead I think the route is to define an interface, a set of parameters for each unit ability (which would be its own XML block), and then a way to configure the battle phases to configure and order those abilities within combat. The lack of any specific ability (either through having no special ability or all abilities negated), would be the general combat phase.

For example, this structure would support units that could attack multiple times per round with different attack types. Let's say we have something like a "Cleric" unit, could cast 'heal' at the start of a round but still then be able to participate in combat.

Trevan

@LaFayette said in Custom Battle Phases:

Concern: we are making things more general but are still specific (in which case it's arguably just complex but not actually more generic). EG: rule names that mention "submarines" and that know about specific unit types. This seems to be the same problem where everything knows about AA rather than just being it's own combat phase.

Please don't get hung up on how I'm naming things. I'm giving rough examples to explain the idea. Here's the exact same XML using gibberous names but it still does the same thing:

<combatPhases>
    <phase name="first strike" order="1">
      <ability name="cat"/>
      <ability name="dog"/>
    </phase>
    <phase name="general" order="2">
      <ability name="general"/>
      <ability name="fish"/>
    </phase>
  </combatPhases>

>><unitAbility name="cat" returnFire="false">
      <targets>...</targets>
  </unitAbility>
  <unitAbility name="dog" returnFire="true">
      <targets>...</targets>
  </unitAbility>
  <unitAbility name="general">
      <targets>...</targets>
  </unitAbility>
  <unitAbility name="fish">
    <targets>
      <target>destroyer</target>
    </targets>
  </unitAbility>
  <unitAbility name="turtle">
    <abilityFrom>cat</abilityFrom>
    <abilityTo>dog</abilityTo>
  </unitAbility>
  <unitAbility name="horse">
    <abilityFrom>fish</abilityFrom>
    <abilityTo>general</abilityTo>
  </unitAbility>
  <attachment name="unitAttachment" attachTo="destroyer" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
    <unitAbilities>
      <ability>general</ability>
    </unitAbilities>
    <antiAbilities>
      <ability side="enemy">turtle</ability>
      <ability side="ally">horse</ability>
    </antiAbilities>
  ...
  </attachment>
  <attachment name="unitAttachment" attachTo="submarine" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
    <unitAbilities>
      <ability>cat</ability>
    </unitAbilities>
  ...
  </attachment>
  <attachment name="unitAttachment" attachTo="fighter" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
    <unitAbilities>
      <ability>fish</ability>
    </unitAbilities>
  ...
  </attachment>

@LaFayette said in Custom Battle Phases:

If we can design the unit abilities in such a way that an 'anti-ability' is a wholesale negation or (an effective) removal of the ability, I think that would make things quite a bit simpler and lend itself to generic abilities and anti-abilities

The ability for "anti-abilities" to not only negate an ability but to "convert" an ability is I think quite simple and it lends itself to generic abilities and anti-abilities. It also handles all the different permutations that the engine current provides.

@LaFayette said in Custom Battle Phases:

In part what I'm getting at is if we were to have custom battle phases I think it should overall be relatively generic. No phase should be defined in terms of specific units.

My example does do that. None of the abilities or phases are tied to any specific units. The ability "submarine" could be attached to a "fighter" unit without any problem. Then the "fighter" would have a first strike ability but a "destroyer" would still negate the "fighter".

LaFayette

Sorry, I didn't parse the example closely enough.

@Trevan , I think we are getting closer to consensus. I'm thinking two further examples would be useful at this point for more consideration:

An example of the default value that would be inferred if the combat phase XML block is not present. Presumably no map will be required to have such a block (WWII maps). In such cases there would be a default that would be effectively generated and used. What would this effective default block be?
An example of a map where the combat phase definition is particularly useful. This example would potentially be hypothetical and show what could be done to make an existing map less hacky and simpler. I'm thinking something like the WoW map or the map that has depth charges.

Trevan

Here's a rough draft of what the inferred phases and abilities would look like in three possible property configurations:

<!-- WW2V2 = false, Defending Subs Sneak Attack = true -->
<combatPhases>
  <phase name="AA">
    <ability name="AA" />
  </phase>.
  <phase name="bombardment">
    <ability name="bombard" />
  </phase>
  <!--phase name="land paratroopers" /-->
  <!--phase name="evade retreat" /-->
  <phase name="first strike">
    <ability name="first strike" />
  </phase>
  <phase name="general">
    <ability name="general" />
    <ability name="ignore evaders" />
  </phase>
  <!--phase name="retreat" /-->
</combatPhases>
<unitAbilities>
  <unitAbility name="AA" type="combat" returnFire="false" dice="AA">
    <!-- units with isAAforCombatOnly get this automatically -->
    <targets><!-- all air units --></targets>
  </unitAbility>
  <unitAbility name="bombard" type="combat" returnFire="false" dice="bombard">
    <!-- units with canBombard get this automatically -->
    <targets><!-- all units --></targets>
  </unitAbility>
  <unitAbility name="first strike" type="combat" returnFire="false" dice="normal">
    <!-- units with isFirstStrike get this automatically -->
    <targets><!-- all sea units --></targets>
  </unitAbility>
  <unitAbility name="anti-first strike" type="change" faction="enemy">
    <!-- units with isDestroyer get this automatically -->
    <from>first strike</from>
    <to>general</to>
  </unitAbility>
  <unitAbility name="ignore evaders" type="combat" dice="normal">
    <!-- units with isAir get this automatically -->
    <targets><!-- all non canEvade --></targets>
  </unitAbility>
  <unitAbility name="anti-evader" type="change" faction="allied">
    <!-- units with isDestroyer get this automatically -->
    <from>ignore evaders</from>
    <to>general</to>
  </unitAbility>
</unitAbilities>


<!-- WW2V2 = false, Defending Subs Sneak Attack = false -->
<combatPhases>
  <phase name="AA">
    <ability name="AA" />
  </phase>.
  <phase name="bombardment">
    <ability name="bombard" />
  </phase>
  <!--phase name="land paratroopers" /-->
  <!--phase name="evade retreat" /-->
  <phase name="first strike">
    <ability name="first strike" />
  </phase>
  <phase name="general">
    <ability name="general" />
    <ability name="ignore evaders" />
  </phase>
  <!--phase name="retreat" /-->
</combatPhases>
<unitAbilities>
  <unitAbility name="AA" type="combat" returnFire="false" dice="AA">
    <!-- units with isAAforCombatOnly get this automatically -->
    <targets><!-- all air units --></targets>
  </unitAbility>
  <unitAbility name="bombard" type="combat" returnFire="false" dice="bombard">
    <!-- units with canBombard get this automatically -->
    <targets><!-- all units --></targets>
  </unitAbility>
  <unitAbility name="first strike" type="combat" side="offense" returnFire="false" dice="normal">
    <!-- units with isFirstStrike get this automatically -->
    <targets><!-- all sea units --></targets>
  </unitAbility>
  <unitAbility name="anti-first strike" type="change" faction="enemy">
    <!-- units with isDestroyer get this automatically -->
    <from>first strike</from>
    <to>general</to>
  </unitAbility>
  <unitAbility name="ignore evaders" type="combat" dice="normal">
    <!-- units with isAir get this automatically -->
    <targets><!-- all non canEvade --></targets>
  </unitAbility>
  <unitAbility name="anti-evader" type="change" faction="allied">
    <!-- units with isDestroyer get this automatically -->
    <from>ignore evaders</from>
    <to>general</to>
  </unitAbility>
</unitAbilities>

<!-- WW2V2 = true -->
<combatPhases>
  <phase name="AA">
    <ability name="AA" />
  </phase>.
  <phase name="bombardment">
    <ability name="bombard" />
  </phase>
  <!--phase name="land paratroopers" /-->
  <!--phase name="evade retreat" /-->
  <phase name="first strike">
    <ability name="first strike" />
    <ability name="first strike with return fire" />
  </phase>
  <phase name="general">
    <ability name="general" />
    <ability name="ignore evaders" />
  </phase>
  <!--phase name="retreat" /-->
</combatPhases>
<unitAbilities>
  <unitAbility name="AA" type="combat" returnFire="false" dice="AA">
    <!-- units with isAAforCombatOnly get this automatically -->
    <targets><!-- all air units --></targets>
  </unitAbility>
  <unitAbility name="bombard" type="combat" returnFire="false" dice="bombard">
    <!-- units with canBombard get this automatically -->
    <targets><!-- all units --></targets>
  </unitAbility>
  <unitAbility name="first strike" type="combat" side="offense" returnFire="false" dice="normal">
    <!-- units with isFirstStrike get this automatically -->
    <targets><!-- all sea units --></targets>
  </unitAbility>
  <unitAbility name="first strike with return fire" type="combat" side="offense" returnFire="false" dice="normal">
    <!-- no units get this by default -->
    <targets><!-- all sea units --></targets>
  </unitAbility>
  <unitAbility name="anti-first strike" type="change" faction="enemy">
    <!-- units with isDestroyer get this automatically -->
    <from>first strike</from>
    <to>first strike with return fire</to>
  </unitAbility>
  <unitAbility name="ignore evaders" type="combat" dice="normal">
    <!-- units with isAir get this automatically -->
    <targets><!-- all non canEvade --></targets>
  </unitAbility>
  <unitAbility name="anti-evader" type="change" faction="allied">
    <!-- units with isDestroyer get this automatically -->
    <from>ignore evaders</from>
    <to>general</to>
  </unitAbility>
</unitAbilities>

Trevan

Here's some rough examples of how it could help some feature requests:

https://forums.triplea-game.org/topic/2463/bombers-single-round-attack

<unitAbility name="bomber" type="combat" dice="normal" rounds="1">
  <targets>...</targets>
</unitAbility>

<phase name="general">
  ...
  <ability name="bomber" />
</phase>

https://forums.triplea-game.org/topic/2344/cannottarget-cannotbetargetedby-on-attack-defense

<unitAbility name="defending against bombers" type="combat" dice="normal" side="defense">
  <targets><!-- all unit types other than bombers --></targets>
</unitAbility>
<unitAbility name="attacking against bombers" type="combat" dice="normal" side="offense">
  <targets><!-- all unit types --></targets>
</unitAbility>

<phase name="general">
  ...
  <ability name="defending against bombers" />
  <ability name="attacking against bombers" />
</phase>

As for WoW, I think I'd need some help from @Frostion. WoW is heavily using AA and I think there are aspects of it that were hacked around, but I'm not positive.