TripleA Logo TripleA Forum
    • TripleA Website
    • Categories
    • Recent
    • Popular
    • Users
    • Groups
    • Tags
    • Register
    • Login

    Poll on how Defender Retreat should work

    Scheduled Pinned Locked Moved Development
    23 Posts 5 Posters 761 Views 5 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C Offline
      Cernel Moderators Lobby Moderators @iratoric
      last edited by

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

      RogerCooperR 1 Reply Last reply Reply Quote 1
      • RogerCooperR Offline
        RogerCooper @Cernel
        last edited by

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

        1 Reply Last reply Reply Quote 1
        • B Online
          beelee
          last edited by

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

          Screenshot from 2026-06-27 15-14-22.png

          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 🙂

          C 1 Reply Last reply Reply Quote 1
          • C Offline
            Cernel Moderators Lobby Moderators @beelee
            last edited by

            @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.)

            1 Reply Last reply Reply Quote 0
            • B Online
              beelee
              last edited by

              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 🙂

              1 Reply Last reply Reply Quote 0
              • I Online
                iratoric @iratoric
                last edited by

                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?

                C LaFayetteL 2 Replies Last reply Reply Quote 3
                • C Offline
                  Cernel Moderators Lobby Moderators @iratoric
                  last edited by 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.

                  1 Reply Last reply Reply Quote 0
                  • LaFayetteL Online
                    LaFayette Admin @iratoric
                    last edited by

                    @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).

                    I 2 Replies Last reply Reply Quote 0
                    • I Online
                      iratoric @LaFayette
                      last edited by

                      @LaFayette This game: https://forums.triplea-game.org/topic/4074/north-africa-triplea-module

                      Here is the rulebook I've been looking at, Pg. 20
                      https://renegadegamestudios.com/content/File Storage for site/Rulebooks/Axis Allies/A&A_NorthAfrica_Rulebook_v8_WEB_090324.pdf?srsltid=AfmBOopVwvgEyZeJnjYp_ruRU2jn9aTpuvxW6KJfxVfl6WqGoXWC8mog

                      1 Reply Last reply Reply Quote 1
                      • I Online
                        iratoric @LaFayette
                        last edited by iratoric

                        This is my interpretation of the rules & what I coded:

                        At the very start of the round, if any unit has the attachment canDefensiveRetreat = true, the defender gets a prompt if they want to retreat, and to which territory. They may only retreat to friendly/neutral territories, not an enemy territory, and they can't retreat to a territory with enemy units in it, unless only enemy air is present, which is non-blocking.

                        If the defender chooses not to retreat, then the battle proceeds as normal. If the defender chooses a territory to retreat to, then that territory is saved and stored for later. The attackers fire at all of the defending units. Any units that are doing a defensive retreat do not fire back. Casualties are removed, and then any retreating units retreat to the destination we stored earlier. Any defender units not capable of retreating remain and must fight to the end/get captured/get removed, whatever happens normally

                        EDIT: I was originally going to have a property that applies to all land units, but it turns out that in A&A North Africa not all land units can defensive retreat (the truck and the supply token can't) so it pretty much needs to be a unit attachment. This offers some variation as the mapmaker can select what units they want to be able to do a defender retreat

                        1 Reply Last reply Reply Quote 1

                        Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                        Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                        With your input, this post could be even better đź’—

                        Register Login
                        • 1
                        • 2
                        • 2 / 2
                        • First post
                          Last post
                        Powered by NodeBB Forums