Poll on how Defender Retreat should work

[iratoric]

I've been programming an optional defensive retreat into TripleA and have a basic version of it working on a separate Git branch. It is currently a game property called "Defenders Can Retreat Combat Round" which accepts an integer. The default of -1 means no retreat, 0 means defenders can retreat before combat, 1 means defenders can retreat after 1 round of combat, etc. Currently it just applies evenly to all units. But it sounds like people would want to have more specific options for mapmaking.

The main question is how customizable per unit should this be? Should there be separate properties for land, sea and air units? Or should this instead be a unit attachment?

[iratoric]

Here is the discussion we've already had on Git as reference: https://github.com/triplea-game/triplea/pull/14649

[beelee]

@iratoric

Nice work.

I think a unitAttachment would be best. One could individualize which units get it then. Idk if that causes other issues though.

I know the guys don't like new Game Properties. That goes back to when Veqryn was still here. Idk enough of how it all interacts to give more of an opinion than that

[RogerCooper]

@beelee said:

I think a unitAttachment would be best. One could individualize which units get it then. Idk if that causes other issues though.

A unitAttachment would cause problems. What happens with a force of mixed units.

Separate game properties for land, sea and air battles makes sense, the same way limited rounds of combat work.

    <!-- Land Battle Rounds means the number of rounds that a normal Battle goes on for (land). Default is -1, and if negative, the battle continues forever until 1 side is eliminated. -->
    <property name="Land Battle Rounds" value="-1" editable="false">
      <number min="-1" max="100"/>
    </property>
    <!-- Sea Battle Rounds means the number of rounds that a normal Battle goes on for (sea). Default is -1, and if negative, the battle continues forever until 1 side is eliminated. -->
    <property name="Sea Battle Rounds" value="-1" editable="false">
      <number min="-1" max="100"/>
    </property>
    <!-- Air Battle Rounds means the number of rounds that an Air Battle goes on for. If negative, the battle continues forever until 1 side is eliminated. Default is 1, meaning the battle ends after the first round of combat. -->
    <property name="Air Battle Rounds" value="1" editable="false">
      <number min="-1" max="100"/>
    </property>

I would expect a property like "Land Battle Retreat".

[LaFayette]

Thanks for the opening the new issue. There's a couple aspects to tease out:

1. how should the defender retreat mechanic work overall, and which options should there be for it?

2. how should it be implemented in terms of the engine and game XML

Lots of questions for a mechanic

Sorry for a bit of a gish-gallop, but there are SO many questions on how the mechanic itself should work, and out of these various answers should be non-options, and others should be configurable.

We should also keep in mind that there ought to be some symmetry with how offensive retreat would work. Any mechanism to disable offensive retreat, should be very similar. In other words, there are a lot of implied rules in game XMLs today, one notably that offensive units can retreat and that defensive units cannot.

With regards to mechanics, there's a lot of considerations. Which territories and how far a unit can retreat are all open questions. Any territory, random territory, territory of the defenders choice, territory of opponents choice, same territory, any allied or unoccupied territory, a territory where the unit moved from previously, allied occupied territory only? Which of these should be configuration options, and which should be non-options?

Once defenders have retreated, do they participate in combats in territories where they retreated? If a unit has blitzed past such a territory, is it eligible for retreat? Could an offensive attacker block all retreat options by say for example sending one fighter into each adjacent territory?

What happens to fighters when a carrier retreats? Does it take the fighters with it?

Then, there's the question of which units can retreat, how far, and when and if the there should be variance in the rules per unit. This implies there are multiple mechanics possible for the same rule and it can vary by unit. So, there is set of rule-sets for a given mechanic, and each unit type can have a different rule-set.

How to Code it Up

As previously mentioned, there's an implied mechanic for offensive retreat, so arguably there should be a pretty consistent way in XML to code either defender or offensive retreat options.

I highlight this as there are many such "implied" rules that are enforced by the game engine and it's not at all clean.

Another issue is when a single property represents multiple other properties - it's almost always a disaster of complexity. The big example there is "isSub", which means "canSubmerge" + "firstStrike" (and more). Meanwhile, there are properties for first-strike, which creates a bit of a complexity hodge-podge of one-off exceptions, rules, long if/else chains and just bugginess.

Potential Future Approach - a game-mechanics block

A feature that I think we should build, is the ability to update any of the game mechanics and unit stats on a per-game basis.

Further, having observed several design flaws, the implied rules and the rules which are a composite of other rules are generally bad.

To fix this and allow for a sane way to customize rules and stats, I was thinking of there being a new "game-mechanics" block. EG:

<game-rules>
    <battle>
          <phase-order>
                 <phase id=attackersFire />
                 <phase id=defendersFire />
                  :
                 :
           </phase-order>
   </battle>
            <game-mechanics>
                       <game-mechanic>
                                <name>FirstStrike</name>
                                <type id=battle />
                                 <startFireRound>0</startFireRound>                                                         
                        </game-mechanic>
                      <game-mechanic>
                                <name>NormalCombat</name>
                                <type id=battle />
                                 <startFireRound>1</startFireRound>
                        </game-mechanic>
                      <game-mechanic>
                                <name>SuicideUnit<name>
                                <type id=battle />
                                 <startFireRound>1</startFireRound>
                                 <lastFireRound>1</lastFireRound>
                    </game-mechanic>
            </game-mechanics>
           <unit-category>
                   <name>Sub</name>
                   <mechanics>
                            <mechanic name=FirstStrike />
                   </mechanics>
              </unit-category>
 </game-rules>

<!-- Then later, on the units -->

<unit>
    <name>Submarine</name>
    <category>Sub</category>
    <!-- maybe an optional block to opt into mechanics -->
</unit>

The above is not meant to be comprehensive, but just illustrative of what the mechanics block would look like.

We could have some short-cut variants as well that are "pre-defined" blocks, eg:

<game-rules rule-set-id=classic />
<game-rules rule-set-id=revised />

Then, every 'game property' would be translated into a set of XML that could be expressed as a game mechanic. So instead of having a big "v1" and "v3" rule set, the individual mechanics would be broken down and each one would be opt-in, opt-out and could be mixed and matched.

The game properties tie into this heavily as those imply a lot of different mechanics. I'm thinking the XML parsing layer would be updated to completely hide the game properties and translate them under-the-hood into the corresponding game mechanic.

At this point, we would no longer have a big list of combat phases and rule definitions in the game engine, but instead it would all be driven by the XML.

Finally, I'm thinking it would be most natural for offensive retreat and defensive retreat would be part of these mechanic definitions. That gives flexibility to have a variety of options, configurable in XML and dynamically at game launch, and attached to units in explicit ways.

[LaFayette]

I'll follow up with the consideration as well as what is pragmatic.

Should we try to build something where different rule changes can be expressed in a very explicit and clean way?

Or, should we go ahead and try to work with the existing structure?

If we go with the existing structure, then we are consigning ourselves to forever support these XML additions and forever have engine logic to support it - FOREVER.

This is why I mentioned in the PR that XML + game mechanic updates are the least trivial of any possible update to the game engine.

Hence, if we can build up the game rules in a way where retreat options can be naturally expressed as part of the game mechanics, without one-off special properties - that seems like a big win. OTOH, that's an undertaking, well worth it, but on the other side one-off options have an extremely high complexity/maintenance cost that we are never able to get rid of.

[RogerCooper]

@LaFayette This is all a good idea. Someone just needs to code it. Many mechanics should be expressed in a generalized way. For retreat, the possibilities are

Attacker, Defender or both
After how many rounds and environment (land,sea,air)
Enemy units that can prevent retreat
Retreat to where (in place, friendly,no enemies)

I think that allowing retreating units to fight would be hard to implement and unrealistic. If a territory retreated to is lost, the retreating units should be eliminated.

[Cernel]

I suggest just having retreating defensive units always retreating to the same zone so not actually moving (similarly to how submerging or the property "Retreating Units Remain In Place" work). This would have 2 main advantages.

1. It eliminates the absurdity that defensive units which retreated can round-wise actually move more than units which were left unmolested. (Moreover, with multiple players, for example, an infantry could defensively retreat 3 times in the same round if attacked across 3 turns in the same round and then also move by 1 space, thus having moved away of 4 spaces from its starting position during the round.) (Otherwise, to eliminate this absurdity, you would need to keep track of units across rounds so to make sure the total retreats are not exceeding the total movement and either are subtracted to the allowed movement on their next movement phase or to make sure that the units which defensively retreated will be unable to move on their next movement phase.)
2. It makes the whole system easier the devise and perfect. Specifically, it would either remove the need to answer or make much easier answering some question posed by @lafayette, namely "Which territories and how far a unit can retreat are all open questions. Any territory, random territory, territory of the defenders choice, territory of opponents choice, same territory, any allied or unoccupied territory, a territory where the unit moved from previously, allied occupied territory only? Which of these should be configuration options, and which should be non-options?", "Once defenders have retreated, do they participate in combats in territories where they retreated?", "If a unit has blitzed past such a territory, is it eligible for retreat?", "Could an offensive attacker block all retreat options by say for example sending one fighter into each adjacent territory?" and "What happens to fighters when a carrier retreats? Does it take the fighters with it?".

On top of the two main advantages, it would feel more in line with the more modern rulesets because this is going to be seen similar to the special withdraw ability of submarines, which has the submarines retreating only to the same territory in which they already are for every game after V1 (Classic) (V1 being by now mostly a legacy ruleset, new custom games being almost all based on V2 (Revised) or following rulesets).

[Cernel]

I'll add that, doing it this way, it is going to be much easier to test it. Once everything appears to be working fine for same-zone defensive retreat, it would be still possible to add the option defensively to retreat to an other zone (either with a specific property or using the existing "Retreating Units Remain In Place" property). Thus, I would suggest limiting defensive retreating to remaining inside the embattled zone for now even in case it would be ultimately wanted eventually to have non-same zone defensive retreat.

[LaFayette]

@iratoric after some more reflection, let's try to nail down the game mechanics first. It does not necessarily have to be all at once. There are probably a couple key configuration options. Specifically, there's a question of how many variations of rules we should support, and what exactly those rules should be.

Another key question, is whether retreat should work how subs are supposed to work, where it is 1 to N that can submerge, perhaps similar for retreat so it would not have to be the whole army.

Once the mechanics are nailed down, we can then decide how many and what best options to use to encode the rules. Waiting for a nicer generalized framework is likely too much to wait for. With rules nailed down, we can then consider what the least painful way would be to encode the settings, and which key configurations options are needed.