Custom Battle Phases

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.

LaFayette

This is a good examle. I notice that the bomber defense and attack are part of the 'general' phase. Are there multiple phases specified, or the elements within a phase different phases? If that is just one phase as it just appears, what would multiple phases look like?

Another question, does 'dice=normal' control the number of dice sides, where normal means use the default defined for the game?

Trevan

@LaFayette said in Custom Battle Phases:

This is a good examle. I notice that the bomber defense and attack are part of the 'general' phase. Are there multiple phases specified, or the elements within a phase different phases?

I only showed what would need to be changed to the general phase. There would be the AA, bombardment, first strike phase as well but they wouldn't need a change.

If that is just one phase as it just appears, what would multiple phases look like?

I think my previous example shows this.

Another question, does 'dice=normal' control the number of dice sides, where normal means use the default defined for the game?

There are three types of dice that are definable on a unit: AA dice (attackAA, offensiveAttackAA, and related), bombardment dice (bombard or attack), and normal/other/general/somename dice (attack and defense). So there needs a way to indicate which of the type of dice will be used by a unitAbility. My examples used dice.

Trevan

I just noticed that there is a property unitAbilitiesGained that is a part of the techAbilityAttachment. This currently allows units to gain the canBombard and canBlitz abilities. And since this is tech, it means that players can have different settings per unit.

I was envisioning that the unitAbilities that each unitType would be the same for all players. But because of unitAbilitiesGained, the units that would participate in the bombard phase can be different for each player.

My question is, should the mapping of unitAbilities <-> unitType be dependent on the player?