Poll on how Defender Retreat should work

[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

[Cernel]

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

I did understand that @iratoric does not want this rule, but I'm not sure. Nevertheless, I would much suggest having a property to define whether or not retreating units must be subjected to a round of fire (with no fire-back) before they can retreat.

I also suggest retreating happening before everything (beside air battles), meaning that retreat also happens before any AA can fire.

Personally, instead of having a retreat round, I guess we should better have 3 settings for game-makers:

1. Retreat is possible before each combat round (and also before AA fire), meaning that you can defensively retreat without even engaging in battle.

2. Retreat is possible in the middle of each combat round, between offensive and defensive attacks, meaning that, if you defensively retreat, you will be subjected to offensive fire without being able to fire back (but both the AA fire as well as any first strike will fire both ways). However, you have to decide to retreat before the combat round. (In this case, a unit with first strike would be able to fire before retreating as that happens before offensive fire.)

3. Retreat is possible at the very end of each combat round, immediately after the offender is possibly offered the option to retreat (and refuses to do so or cannot retreat). In this case, you decide this at the moment.

I understand that point 2 is how it works in North Africa. Can anyone confirm this? @panther? (I've never read the rules.)

@iratoric Can you please clarify which one of the 3 points above you primarily want (or letting us know exactly otherwise)?

Personally, I don't like the point 2, and I think it is messy. It is up to @iratoric if he/she wants to support such North Africa rules as part of its proposed feature or not. I'm not advising it, but I do believe that (like @beelee) persons will expect defensive retreat to work at least possibly like in North Africa (not doing so having the likelihood of being seen like a problem no matter if this feature was never done for supporting such rule-set).

If not supporting point 2, I strongly suggest trying to make as clear as possible that this is the case, to avoid misunderstandings (persons assuming this is the North Africa's retreat rule).

I think the best way of doing this is generally giving game-makers the ability to customise the battle round more or less in the same way they can currently customise the phase order within the round. In doing so, if supporting North Africa, it would be needed to have 2 defensive retreat combat phases, one in which you decide whether defensively to retreat or not and the other one in which the retreat happens (if still possible). (Obviously, the former must always be before the latter.) (This would be somewhat similar to having two phases for tech development and tech activation of what you developed.)

[beelee]

Thinking on this some more and to add what I previously posted,

Defender retreats.

Next turn, Defender attacks and retreats after 1 rd. They can only retreat from a TTy where they started, assuming no units from other TTys attacked, they would have to retreat/remain where they started.

Original Attacker still has units in the TTy.

Their next turn they can either attack with some or all of their units, including units from other TTys, as per current rules.

Remain in place, no combat takes place and they retain control of the TTy. Can be reinforced in NCM, even if all units at turn start have moved out.

Can move some or all of units out of the TTy and either attack or NCM. They would still retain control of the TTy even with no units present.

The retreated units would have to attack the empty TTy on their turn to take control of it. Blitzing allowed.

I may have misunderstood what @iratoric was originally proposing. I thought it was basically to work like submerging Subs.

At any rate, Good Luck with whatever you decide

[iratoric]

Thanks everyone for your opinions. I have thought about this a lot, and it is probably best if we start with implementing one set of rules and branch out from there. Otherwise there are simply too many possible combinations to do all at once. Since the North Africa game is the “official” ruleset and an already existing game that needs this rule, I think that whatever I implement should support that first. I will code it in such a way that it still leaves room for more variations later. Thoughts?

[Cernel]

@iratoric said:

Thanks everyone for your opinions. I have thought about this a lot, and it is probably best if we start with implementing one set of rules and branch out from there. Otherwise there are simply too many possible combinations to do all at once. Since the North Africa game is the “official” ruleset and an already existing game that needs this rule, I think that whatever I implement should support that first. I will code it in such a way that it still leaves room for more variations later. Thoughts?

I instead think that the baseline should be some version of what you/we can devise as the simplest retreat system, have that done and tested, then adding properties and/or options for each element adding complexity.

For example, in the basic system you retreat to the same zone. Next step, with property, is retreating to an other zone. Next step, with property, is limiting retreat only to zones not under attack by land units. And so on.

[LaFayette]

@iratoric which North Africa game? AFAIK some of the variations are mutually exclusive. I think the first task it is to identify which variations should be plausibly supported. Once done, I would like a full spec identified. Following, we can then look at the plan for how that would be encoded into XML. Doing so iteratively and not all-at-once is perfectly fine. Though, I think we should know beforehand which retreat variations we are likely to want (and also in which maps).