Custom Battle Phases

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.

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.