Poll on how Defender Retreat should work

[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.

[iratoric]

@Cernel Actually you make a really good point about units that retreated being able to move further than units that didn't retreat. You shouldn't be able to use retreating as a "cheat" to get more movement. I added code that marks the units as having moved if they retreated to another territory, and the movement doesn't get reset until after that player's turn is done.

E.g. if an infantry retreated to another territory, they used up their only movement point, if a tank retreated one space, then they only have one movement point left

[iratoric]

@Cernel So for now, should I just comment out the code that allows you to select any territory other than the current one to retreat to?

[Cernel]

@iratoric said:

@Cernel Actually you make a really good point about units that retreated being able to move further than units that didn't retreat. You shouldn't be able to use retreating as a "cheat" to get more movement. I added code that marks the units as having moved if they retreated to another territory, and the movement doesn't get reset until after that player's turn is done.

E.g. if an infantry retreated to another territory, they used up their only movement point, if a tank retreated one space, then they only have one movement point left

Wow. I was just assuming that was something too difficult to implement. Didn't actually expect you to do it. Did you actually do it so that it works across rounds? For example, let's say it's Classic except there is retreat, British attack in Western Europe and a German armour retreats from Western Europe to Southern Europe, then Americans attack in Southern Europe and the same German armour retreats from Southern Europe to Germany. At this point, a new round starts, and Russians attack Germany: will the armour be unable to retreat? Assuming it survives (or the Russians do not attack), will it also be unable to move during both phases of the Germans turn on this round?

Regarding visualisation, unfortunately TripleA already has the problem that showing how much a unit has left to move does simply not exist at all until you try to move the unit, but, for now, that actually impacts only aircraft within the same turn, so it's not too much of a big deal. However, that would become quite a big deal if an armour retreats during a British attack and then it is down only to 1 movement left through the Japanese, Americans and Russians turn until the Germans turn on the following round too. All or some of these players may need to know that the Germans will be able to move that armour of only 1 space during their turn so to calculate properly without having to go back in history to see what retreated where or keeping all in memory. This is something which cannot be seriously left without a good display for everyone playing (or watching) the game at any moment until that condition is reset.

---

Personally, even if a retreat-to-an-other zone is made and works very well both itself and in displaying, I think I'd just prefer retreating on the same zone, possibly with the additional limitation that the unit must be moved out of the zone on the Combat Move phase of its next turn (possibly out and back into to attack on the same turn if it can move at least of 2 spaces) or be lost. The other less important but still fairly important dynamic would be that such a defensive retreat to an other zone would imply that I can now defend in that other zone against an other attack before my next turn, whereas I would not have been able to do so if not attacked unless I'm able to scramble (not requiring any bases for scrambling) to it, which would require that every unit able to retreat is also able to scramble and that (akin to what we just said for the movement) its scramble ability is lowered by how much it retreated until the unit is not able to retreat any more once it has retreated as many time as its maximum scramble distance.

[Cernel]

@iratoric said:

@Cernel So for now, should I just comment out the code that allows you to select any territory other than the current one to retreat to?

Well, up to you. I seem to understand that it is either that or you need to answer all @LaFayette's questions and on top of that writing down an exhaustive set of rules covering this matter (since this is not based on a game for which you can just say "go read this page of the rulebook"). From what I understand, it would be much easier for you (or anyone) "to nail down the game mechanics first" in case the feature has only retreating to the same zone. However, if you feel confident that you can support both cases right away, I guess go for it. In that case, I would still suggest that it is retreating to the same zone if the property "Retreating Units Remain In Place" is true, otherwise it is retreating to an other zone (and I understand you have already it done this way).

I'm not a developer, so I don't know, but I'd rather see this feature being successfully added to TripleA for retreat-to-same-zone only than getting lost in development hell or resulting problematic.

[RogerCooper]

@Cernel Let's not overthink this. Yes, in theory a unit could retreat more than once in a turn by being attacked by different players but in practice this is unlikely.

It is similar to the situation where attackers coming from different directions retreat together, creating a potential jump-move. Already legal and supported but it is rare.

[beelee]

@iratoric >

@Cernel said:

... I'd rather see this feature being successfully added to TripleA for retreat-to-same-zone only ...

As Cernel mentions above, this seems a good starting point. If I understand correctly, it's basically the same as Subs submerge, which is what you initially started out with.

The process would be

Attacker attacks

Defender either stays and fights or retreats. If retreating, they undergo 1 rd of combat that they cannot fire back at.

Defender remains in same TTy, the way the submerged Sub does. Control of the TTy goes to the Attacker.

Next turn for the Player owning the retreated Units, they can attack in the TTy they are already in or move out of that TTy to avoid combat. Similar to newly built Naval Units where Enemy Units are present.

Or they could move out of the TTy avoiding combat but move into a TTy and conduct combat also.

If an Ally of the Player they retreated from attacks before their turn, they can retreat again or stay and fight. They would only fight the attacking units whose turn it is, not the previous units that forced the retreat.

Being able to retreat at any round of combat. I think "AirBattle" has some code similar to that.

I don't see any issue if it plays out like that. Deciding on whether to make a Game Property, probably the easiest or to implement it into the xml in another way, would also need to be decided.

Future enhancements could be done at a later date and if needed, the initial Game Property could even be removed when the future code replaces the need for it.

It seems that you basically have the above done or could easily, for you write it up that way ?

At least this way, people could start using it soon. Otherwise, as Cernel mentioned in his post, probablly won't see it anytime soon.

Well, just some thoughts