Custom Battle Phases

LaFayette

Given some recent progress on this front, we need to be sure about two things:

Be very clear about the value of this and why we should do it
Be clear which maps would benefit, how many places would we actually use this?
Carefully design how we will express this in XML

For example, re (3), we should consider whether it makes sense to define the battle phase a unit fires in as part of the unit type. That would avoid the problem where a unit type is omitted from any battle phase.

djabwana

I actually like this idea when I thought about it in light of a build tool like Maven or Gradle. One could define rather arbitrary named phases and then "bind" units or behaviors to those phases. I think this is what @Trevan is getting at but I would propose the phases themselves have no special meanings or naming conventions. However, just like Maven, TripleA would have a series of "built in"/stock phases that units could bind to for standard behavior.

Phase attributes:

Dice sides
Max rounds
Casualties fire back or not

Unit attributes:

Which phases they participate in as attacker, defender, or target (able to be killed but not return fire)

For example, instead of saying a sub is sneak attack, you bind it to "phase 1", which is a no-fire-back phase with a max round of 1.

This would also allow interesting things like:

AA guns fire 1
Strategic bomb phase 1 with max dice sides 6 and max round of 1
AA guns fire 2
Strategic bomb phase 2 with max dice sides 8 and max round of 1
AA guns fire 3
Strategic bomb phase 3 with max dice sides 10 and max round of 1

(basically, being able to continue bombing with less likelihood of damage and more chances of AA to fire)

Trevan

@LaFayette said in Custom Battle Phases:

Be clear which maps would benefit, how many places would we actually use this?

I, personally, think that all maps would benefit. Right now, to figure out which units fire when and how they fire is complicated. The information is spread out across lots of different properties and some aren't that obvious. Take for instance your request to group all of the dice when subs don't have first strike. Several of the responders were talking about isDestroyer implications and WW2V2 implications. But if, instead, the maps just specified how and when the units fire, then there isn't confusion about the affect of isDestroyer, WW2V2, isInfrastructure, AA, etc.

For example, here's how the WW2V2 could possible look:

<battlePhase name="First Strike">
  <returnFire side="both">
    <exists type="destroyer" />
  </returnFire>
  <firingSquadron name="submarine" side="both">
    <units type="submarine" />
    <targets type="transport:submarine:destroyer:carrier:battleship" />
  </firingSquadron>
</battlePhase>
<battlePhase name="General">
  <firingSquadron name="air" side="both">
    <units type="fighter:bomber" />
    <targets type="infantry:artillery:armour:fighter:bomber:transport:destroyer:carrier:battleship" />
    <targets type="submarine" exists="destroyer"/>
  </firingSquadron>
  <firingSquadron name="land" side="both">
    <units type="infantry:artillery:armour" />
    <targets type="infantry:artillery:armour:fighter:bomber" />
  </firingSquadron>
  <firingSquadron name="sea" side="both">
    <units type="destroyer:carrier:battleship" />
    <targets type="fighter:bomber:transport:submarine:destroyer:carrier:battleship" />
  </firingSquadron>
</battlePhase>

That is really easy to see that submarines always fire together at the beginning and that destroyers only affect the return fire.

But for a non WW2V2, the xml could look like:

<battlePhase name="First Strike" returnFire="false">
  <firingSquadron name="submarine sneak attack" notexists="destroyer" side="both">
    <units type="submarine" />
    <targets type="transport:submarine:destroyer:cruiser:carrier:battleship" />
  </firingSquadron>
</battlePhase>
<battlePhase name="General">
  <firingSquadron name="submarine" exists="destroyer" side="both">
    <units type="submarine" />
    <targets type="transport:submarine:destroyer:cruiser:carrier:battleship" />
  </firingSquadron>
  <firingSquadron name="air" side="both">
    <units type="fighter:tactical_bomber:bomber" />
    <targets type="infantry:artillery:mech_infantry:armour:fighter:tactical_bomber:bomber:transport:destroyer:cruiser:carrier:battleship" />
    <targets type="submarine" exists="destroyer"/>
  </firingSquadron>
  <firingSquadron name="land" side="both">
    <units type="infantry:artillery:mech_infantry:armour" />
    <targets type="infantry:artillery:mech_infantry:armour:fighter:tactical_bomber:bomber" />
  </firingSquadron>
  <firingSquadron name="sea" side="both">
    <units type="destroyer:cruiser:carrier:battleship" />
    <targets type="fighter:tactical_bomber:bomber:transport:submarine:destroyer:cruiser:carrier:battleship" />
  </firingSquadron>
</battlePhase>

And now you can see that the destroyer is affecting when the submarines fire. And you could then change your request to ask that all of the units in the same BattlePhase fire roll together if they have the same targets.

LaFayette

An initial reaction is I wonder if this is too verbose? Are we going to have the same 30 lines per XML? We do still need to support all existing XMLs (we do not control all maps, we cannot break existing maps). So while we make existing maps more explicit, we are not necessarily changing anything. What's the benefit?

I've personally have been wanting to consolidate rules to a module so that it could be turned on and off per game. Would this structure lend itself easily to that?

For example, a map could in short say "WWv2" rules which then brings in 30 additional options that have default options. In turn, when a game starts we expose each of these default values for per-game configuration in the UI. I would also like to see unit stats and it's a natural add-on to extend that to unit abilities as well.

Does that change the calculus here at all? Do I understand right that the primary benefit is to make the rules more explicit and easier to determine by looking at the XML?

Trevan

@LaFayette said in Custom Battle Phases:

An initial reaction is I wonder if this is too verbose?

That XML was a rough draft. I'm sure it can be tightened up quite a bit.

Are we going to have the same 30 lines per XML?

No, because maps generally have lots of different units. So, the map will need its own specific XML. Though, I guess with variables and such, it could be simplified and maybe will become similar across different maps.

We do still need to support all existing XMLs (we do not control all maps, we cannot break existing maps). So while we make existing maps more explicit, we are not necessarily changing anything. What's the benefit?

There have been requests to be able to make more custom battle groups/phases/etc. I've linked to a few in this thread as well as the custom firing groups thread. So map makers are wanting it. Also, they are currently using the AA/Targeted Attack to replicate some of this logic (see Warcraft and the extensive AA logic there). So, map makers will be able to benefit from it.

For me, personally, it clears up confusion on the differences between map versions (v1, v2, v3, v4, v5, etc). Instead of trying to track down which properties do what or adding a new property to support an obscure rule, this xml will make it easier to see how they work and to handle the obscure cases (such as v2 where subs always fire together).

@LaFayette said in Custom Battle Phases:

I've personally have been wanting to consolidate rules to a module so that it could be turned on and off per game. Would this structure lend itself easily to that?
For example, a map could in short say "WWv2" rules which then brings in 30 additional options that have default options. In turn, when a game starts we expose each of these default values for per-game configuration in the UI. I would also like to see unit stats and it's a natural add-on to extend that to unit abilities as well.
Does that change the calculus here at all?

Maybe? I don't know?

Schulz

What about combat AA units?

Trevan

@Schulz said in Custom Battle Phases:

What about combat AA units?

What about them? They would be specified in the phase in the AA phase.

LaFayette

A few thoughts & feedback regarding this block:

<firingSquadron name="submarine sneak attack" notexists="destroyer" side="both">
    <units type="submarine" />
    <targets type="transport:submarine:destroyer:cruiser:carrier:battleship" />
  </firingSquadron>

Units bind into their combat phase via their abilities and not type

I think a unit should 'bind into' a combat phase and not the other way around. It is the unit ability that defines when it rolls, not the unit type persay.

Unit 'anti' abilities to define counter-abilities

In that same manner, instead of 'isDestroyer', perhaps we should call that 'antiFirstStrike'. It negates or neutralizes the first strike ability from another unit.

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.

Unit targeting by unit type

For targets I'd rather we avoid delimited lists. It's easier to parse and less error prone to use canonical XML, eg:

<targets>
   <target>transport</target>
    :
    :
</targets>

At this level of specification I also think we probably should favor defining a unit attribute that is targetted rather than specific units. For non-WW2 maps we should consider this further and whether it is better to specify specific units in addition to units by type. To this extent I'm thinking to have something like:

<targets type=naval />

Dynamic calculation of squadrons

Though, similar to other points, I think it should be the unit that defines what it can target. Let's say for example there were multiple first strike units. Perhaps an air-to-air first strike unit. The combat phase should probably define which types of units roll during that phase, then it is up to the game engine to compute the intersections of which units can target others and break them up accordingly. For example, the engine is processing a first strike phase, it see that we have subs and air-to-air that have mutually exclusive targets. It would then dynamically create two groups to roll against their respective targets.

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.