What do folks think of the name SimulGear?

One relatively simple solution (yeah, I'm sure it's been considered before, but I'm starting from scratch) to the BoA problem might be to have all players take a complete mock turn on the board ..where best case scenarios happen. As they make their moves, they can set thresholds for how many armies advance and how many stay.   Play unfolds where the computer picks a random order of players and then goes in rotation making one move per player per turn until all possible orders are exhausted.  This solution precludes an attack with 3 here, then attack with 3 there type of padding procedure, so it's SimpleSimulGear, or SG-1.  This would be a VERY accessible format for players because the order procedure feels similar to regular play.  On the other hand, I'm sure the downside for the hardcore BaO players is that it feels like regular Risk.

The other thought I have concerns the use of the traditional Risk style use of dice.  What if an entirely different paradigm could be used?  Here’s one that comes to mind.  Battle proceeds one skirmish at a time, with each player rolling one die only. In the case of a tie, those two dice are rolled again, ..and again, etc.  The engine doesn’t mind.

Consider the implications.  It doesn’t really matter who's attacking and who's defending, which could have some significance for some BaO solutions – otherwise, let dice modifiers determine parity.  Example: A attacks B with 10,  B defends with 5..

 6, 1        A:10  B:4

1, 1        Roll again

1, 3        A:9  B:4

6, 6        Roll again

4, 2,       A:9  B:3

Etc..

If you wanted extra bloody battles you could set ties to annihilate both armies (this could be a border mod) – until it gets down to 1v1 where, tiebreaker extra rolls kick in.

Hmm.. This this wouldn't be a bad option for regular games where designers know they want a quick and easy 50/50 dice solution for certain border situations.  Just put a GearDice button in the designer section.

So I read this thread, and the old one as well. And I decided to try my hand at creating an intuitive system that addresses many of the concerns raised by the commentators. Thus, without further ado, I present...

Kjeld’s Engine of Simultaneous Play (KESP)

First, forget everything you thought you knew about a simultaneous system of play. Let’s start with a blank slate.

Now imagine a game board with some territories that are connected in some way, each owned by a player with some number of units. Let’s call this state A. Notice that A is the state of the board at the beginning of turn n, and also the state of the board at the end of turn n-1. Thus A is the state of the board between turns, and thus also the state of the board upon which players base their orders for turn n. At this point, note that A is a static state, with all units firmly in placeat a territory, and no units are in transition (more on that later).

Now, suppose that each turn, a player gives orders to his units that describe how many units should move from a territory he controls to a bordering territory. Further, he gives instructions that describe how those units should act if they happen to encounter enemy troops in transition or as defenders. For example, he could dictate that his troops should attack unto death or victory; his troops should attack until they reach a certain threshold at which point they attempt to retreat; or they retreat if they encounter any opposition. Those instructions would constitute each player’s turn.

After orders are given and each player ends turn, those orders need to be resolved. I’ve outlined the steps for the resolution process here.

1. The first thing to happen is that all troops ordered to move leave their starting territory and change their status to in transition. Let us label this second state, B, in which units are now on the move.
2. The game engine then looks at all cases where opposing units will encounter each other while both are in transition (i.e. two different players have ordered their units to move opposite directions along the same border). These in-transition encounters are resolved first, according to the simultaneous battle engine described below.
3. Once all of the “in transition” encounters are resolved, the board transitions to State C, in which units are still on the move but in which there are no longer surviving troops moving opposite directions along the same path. In other words, in C, only the surviving troops are still moving toward their original objective (note: in the case of one or both armies retreating their remaining units, those units are considered to be located back in their starting location in State C, and thus no longer in transition, but in place).
4. The game engine then looks at all territories to which units are moving, and breaks those territories into three categories:
   1. Occupation: One player has troops moving into a vacant territory owned by another player, with no other opposing troops moving in.
   2. Fortify: One player has troops moving to his own territory, with no opposing units moving in.
   3. Contest: One player is moving units to a territory occupied by units of another player, or two players are moving units to the same occupied territory. Note that if a player is moving a stack of units to a contested territory that he controls (i.e. he’s trying to fortify while someone else is attacking), his units are considered to be added to the stack of in place defenders for the purpose of battle resolution.
5. First, fortifies are resolved, resulting in the addition of the moving units to the stack already in place (those units change status from “in transition” to “in place”). Second, occupations are resolved, resulting in the transfer of ownership and the transition of any units moving into that territory from “in transition” to “in place”. Third, any contests are resolved by the simultaneous battle engine, and victorious armies take control of the territory, and any surviving armies attempt to retreat to their designated territory.
6. Once all the contests are resolved, the board transitions to State D, where the only units in transition are those attempting to retreat. Retreats are resolved this way: if the units are attempting to retreat to a friendly territory, they are added to the existing in place stack and their status is changed from “in transition” to “in place”. If the units are attempting to retreat to a territory that is enemy owned, all the retreating units are lost.
7. The turn concludes with State E, in which all units are once again “in place”. This board state will be the state A for the next turn, n+1.

The Simultaneous Battle Engine

My battle engine is actually pretty simple. It relies on three basic concepts: (1) rounds of attack; (2) attack priorities; and (3) end conditions.

I’ll start with end conditions. These end conditions are derived from the orders given to each stack of moving units by the player, and describe to what extent the stack should engage with any enemy troops it encounters. Basically, I envision these orders as consisting of a threshold number of units that when reached triggers the stack to attempt to retreat from the battle. That threshold number can be any integer from 0 (attack until all are killed) up to the size of the stack (never engage, and retreat if any resistance is encountered). An end condition is met when either (a) the stack reaches its threshold or (b) there are no opposing units left to battle (i.e. they’re all dead or in retreat).

The battle proceeds through rounds of attack, continuing until end conditions have been met for every stack in the battle. Note that if a round of attack results in all contesting stacks reaching their retreat threshold, there is no victor and all stacks attempt to retreat – this could result in an un-owned territory at the end of the turn. In each round of attack, the battle engine generates a random integer from 1-100 for each unit, and that unit "scores a kill” if the number is greater than X (defined by the board designer, and subject to border mods). The battle engine then tallies up the total kills scored by each stack, which are then divided amongst each opposing stack according to the killing stack’s attack priorities (see below). After the killed units are removed, the engine checks to see if an end condition has been met for each stack (i.e. have they reached their retreat thresholds). Any stacks that are below their retreat threshold are removed from the battle, and another round of attack commences with the remaining stacks. The battle ends after the first round of attack in which all contesting stacks have met an end condition.

Explanation of attack priorities. Attack priorities only matter in battles in which more than two players are contesting a territory. Basically, players set attack priorities for each moving stack of units to describe how to divvy up any kills that stack scores during a round of attack. The default will be to divide evenly amongst all enemies, but players will have the option to rank their opponents, such that kills are first doled out to player A, then to player B, etc.

-------------------------------------------------------------------------------------------------------------------------

So that's pretty much it in a nutshell. It's straightforward and it avoids questions of turn order completely, but still allows for a tremendous amount of tactical and strategic control. What do you think?

My offering is a potential solution for any engine that requires adjudication of intertwined simultaneous attack scenarios.

It uses the GearDice I described in a previous post.

The overarching premise is that you are only rolling one die at a time so you can only lose 1 army no matter how many people you lose to.  I believe the concept can be scaled to any number of players executing any single attack order simultaneously using any combination of dice modifiers. It is difficult for me to explain, so I have posted a number of scenarios that demonstrate how it works, as well as to put it to the test. The focus of these scenarios is where two players don't attack each other simultaneously as I believe these situations are more easily resolved.

* Descriptions with an asterisk represent an alternate method of adjudication that places an order priority on the highest die roll, which in turn prevents other battles from happening. Using this alternate method, a re-roll between two or three players does not change their relative position in the overall hierarchy of all die rolls; rather it only resolves the tie between those rolls.

Die Rolls (Player A, Player B, Player C) >> Units remaining in those respective territories: (#, #, #)
Dice modifiers are suspended for re-rolls.

Scenario 1: Aw/10 >> Bw/3 >> Cw2 >> A  (w/# means how many units there are on the territory to start.)

6, 5, 5 >> 10, 2, ?       B and C re-roll. C can still lose an army but B can’t (or* A’s higher roll prevents B from Attacking C. )

6, 6, 5 >> 10, 3, 1       C loses 1 to B and A and B tie (or* A and B re-roll because the highest die has not been established )

6, 5, 4 >> 10, 2, 1      C loses 1 to B; B loses 1 to A (or* A's higher roll prevents B from attacking C: (10, 3, 2))

6, 5, 6 >> 10, 2, 2        B cannot lose 2 armies rolling 1 die.

5, 6, 5 >> 9, 3, 1         Both A and C lose to B (or* A and C roll to see who loses to B first. If A loses, All orders are carried out because C is not prevented from attacking A.  If C loses,  Both A and C lose and army, but if

Scenario 2: Aw/10 >> Bw/2 >> Cw1  (C can’t attack)

6, 5, 5 >> 10, ?, ?        B loses to A, and B and C Re-roll (or* A's higher roll stops B from attacking C (10, 1, 1))

6, 6, 5 >> 10, 1, 1B    A and B tie, C loses to B who transfers 1 (or* A and B re-roll because the highest die has not been established yet.)

6, 5, 4 >> 9, 1A, 1B      A takes B’s (home) army and transfers one, B takes C and transfers attacking army. (or* B loses to A and is prevented from attacking C)

6, 5, 6 >> 4, 1, 1          B cannot lose 2 armies in one roll.

5, 6, 5 >> 9, 1, 1B       both A and B lose 1 army (or* A and C roll to see who loses to B)

Scenario 3: Aw/10 >> Cw/1 AND  Bw/2 >> Cw/1  (C can’t attack)

6, 5, 1 >> 9, 2, 1A       Both A and B won but A rolled higher!

6, 6, 1 >>                   A and B Re-roll to see who takes C 

6, 5, 5, >>                  B and C Reroll to see who A occupies.

Scenario 4: Aw/10 >> Cw/1 AND  Bw/2 >> Cw/1  (C can’t attack) AND Dw/2 >> Bw/2

(4, 5, 1, 6) >> (10, 1D, 1B, 1D)   C lost to both A and B but B rolled higher and thus gets to occupy C.  D did however take B’s remaining (home army).

(or* B loses to D, who rolled the highest, and this prevents B from attacking C, so C loses to A instead. (9, 1, 1A 1)).

Scenario 5: A >> B AND  B >> A   AND C >> A

4, 4, 6 >>                A loses to C, and A and B re-roll to see if B loses anything. (or* C's high roll prevents A from Attacking B, but because B is also Attacking A, Band A must re-roll to see if B loses anything.)  In other words, no difference.

 I could see where you would want probably use 20+ sided dice to cut down on re-rolls.

M57, your proposal seems less clear to me than the simultaneous battle engine I described in #62. I don't see that it resolves any types of conflicts that my engine doesn't, and I'm inclined to say WarGear should go with the simplest method of battle adjudication.

Kjeld wrote: M57, your proposal seems less clear to me than the simultaneous battle engine I described in #62. I don't see that it resolves any types of conflicts that my engine doesn't, and I'm inclined to say WarGear should go with the simplest method of battle adjudication.

Mine admittedly seems complex, but in fact if you think of it in terms of everyone throwing a single 100 sided die, and then resolving the whole scenario in order of the highest die thrown, that generally describes the algorithm.

K - Your's is unclear to me.. Can you provide an example or two that describes the process in more detail?

I think the jury's out on whether the simplest method is the best.  Moreover, mine may actually end up being simpler than yours and might get what you wish for.  It only requires an order with thresholds for how many armies stay (when to stop attacking) and how many advance.  It requires no attack priorities, just a order list (I'm not sure if these are the same thing).

It makes a lot more sense if you have a graphic in front of you, but I'll try my best (since I'm no good at embedding graphics in the forum posts).

Let's take a few examples to illustrate.

1. There are two territories, 1 and 2 owned by A and B respectively, that are connected by a default border. Each has 10 units at the start of the turn (state A, when orders are made).
   1. Say that A decides to order 5 units to move toward B, and sets the retreat threshold to 0 (attack until they're all dead). B orders 7 to move toward A, but sets the retreat threshold at 2 (attack until there are 2 or less left, then attempt a retreat).
   2. Now the turn commences, and the board moves to state B*. At this point, 5 units remain on terr 1, and 3 units on terr 2. A has 5 units moving 1->2, and B has 7 units moving 2->1. You can see that A's units are going to run smack into B's. Since State B is where all in-transition conflicts are resolved, this situation triggers a battle.
   3. For the sake of this battle, assume that units have a 50% chance of scoring a kill. So on the first round of attacks, 2 of A's 5 units score a kill, and only 2 of B's units kill. Now A has 3 and B has 5. Check end conditions: both are still alive, and neither has reached the retreat threshold. Now let's look at three possible outcomes for the next round of attack:
      1. A kills 1 and B kills 3. A's troop is extinguished and B still has 4 left, which continue on to territory 1 to eventually launch an attack against A's 5 defenders there, which will be resolved in the same manner once all other in-transition conflicts are resolved and the board moves to state C.
      2. A kills 3 and B kills 1. A has 2 left, and B has 2 left. Check end conditions- A’s has not reached the threshold of 0, but B’s stack has reached its threshold and so retreats back to territory 2, which will have 5 units in place to defend against A’s 2 remaining attackers (again, this will be resolved in the next stage, at state C).
      3. A kills 3 and B kills 3. A has none left, and B has 2 left. Even though A’s stack is extinguished, B’s stack still retreats back to territory 2 (which will have 5 units), and no attacks are left to be resolved in the next stage.
   4. Let’s assume that the first scenario in #3 occurred, such that the in-transition battle stage concludes with B’s stack of 4 units now moving unopposed toward A’s 5 defending units in place at territory 1 (this describes State C). Territory 2 has no impending fortifies, conquers, or conflicts, so it is done for this turn. Territory 1, however, has the impending conflict of 4 attackers against 5 defenders, so this triggers a battle. So, we follow the same drill of attack rounds and testing against the end conditions. Here’re two examples of how it might go:
      1. First attack round, A gets 2 kills, and B gets 3 kills. A now has 2 units left, and B has 2, which triggers a retreat back to territory 2. Since B still controls territory 2, those units are added to the stack of 3 there, and the turn ends with A in control of terr 1 with 2 units, and B in control of terr 2 with 5 units.
      2. First attack round, A gets 1 kill, and B gets 4 kills. A now has 1 unit left, and B has 3 units left. No end conditions met, so a second attack round commences. A gets 1 kill, and B gets 2 kills. Now A has been completely extinguished, and so an end condition has met. While B only has 2 units left, its retreat does not trigger because there are no units possibly left for that stack to battle this turn, so B occupies terr 1 with 2 units. The turn ends with B in control of both territories 1 and 2, with 2 and 3 units respectively. (Alternatively, this situation could trigger a retreat for B, and terr 1 could be left unoccupied at the end of the turn – could be a designer setting which case occurs).
2. To model a more complex battle scenario, let’s go back to #4 above, but let’s also suppose that, in addition to B’s units moving against territory 1, player C has also sent 3 units from territory 3. Now State C looks a little different, with two separate players attacking A’s 5 defenders with a stack of 3 and a stack of 4. Here’s some examples of how it might play out:
   1. Suppose that player C set his attack priorities to distribute evenly against any opponents and set the retreat threshold to 0, and that player B set his attacks to count first against A, and then against C. As defender, A distributes evenly amongst all attackers. On the first attack round, A gets 4 kills, B gets 2 kills, and C gets 2 kills**. A kills 2 of B’s and 2 of C’s, B kills 2 of A’s, and C kills 1 of A’s and 1 of B’s. At the end of the round, A has 2, B has 1, and C has 1. B has reached his retreat threshold of 2, and his remaining units retreats toward terr. 2. However, A and C are both still in the fight, so the battle would continue to additional attack rounds until one or both stacks are killed.
   2. Suppose that player C set his attack priorities to count first against A and then against B, and that player B set his attacks to count first against A, and then against C. As defender, A distributes evenly amongst all attackers. On the first attack round, A gets 2 kills, B gets 3 kills, and C gets 2 kills**. A kills 1 of B’s and 1 of C’s, B kills 3 of A’s, and C kills 2 of A’s. At the end of the round, A is eliminated, B has 3, and C has 2. B and C have not reached their retreat thresholds, and are now left to fight additional rounds of attack to see who gets to conquer territory 1.

*The "states" I refer to are for illustrative purposes, and happen behind the scenes. Players only ever see the static State A that starts and ends every turn, which is what they're looking at when they're giving orders each turn.

**There are a couple of different ways to handle the allocation of kills. Either each player could be assigned a seat number, and kills could be apportioned all in one big pot, so that overkill (i.e. extra kills that essentially would be wasted) are possible, or apportioned up to the death of the target stack, at which point they spill over to any other eligible stacks in the priority order assigned. Or each player could take turns doling out their kills according to their attack priorities, with the target stack being defined each time based on which stacks are still in existence.

M57 wrote:

Kjeld wrote: M57, your proposal seems less clear to me than the simultaneous battle engine I described in #62. I don't see that it resolves any types of conflicts that my engine doesn't, and I'm inclined to say WarGear should go with the simplest method of battle adjudication.

I think the jury's out on whether the simplest method is the best.

Good point. One might also argue that the method that gives the most fine-grained tactical control to the players is the best.

K - How are attack and defense dice resolved? In your above example 5 meets 7 on the battlefield at the beginning of state B. How is that resolved? Are you using the standard Risk dice rules? If so, who is attacking and who is defending?

The more I think about it, the more I am with Gimli: more than anything else, I want Bomb Factory, I love Bomb Factory, I am suffering from Bomb Factory withdrawal. Nothing against the new ideas - they are great, but I want Bomb Factory.

M57 wrote: K - How are attack and defense dice resolved? In your above example 5 meets 7 on the battlefield at the beginning of state B. How is that resolved? Are you using the standard Risk dice rules? If so, who is attacking and who is defending?

There are no dice. Quote: "In each round of attack, the battle engine generates a random integer from 1-100 for each [and every] unit [in each stack], and that unit "scores a kill” if the number is greater than X (defined by the board designer, and subject to border mods). The battle engine then tallies up the total kills scored by each stack, which are then divided amongst each opposing stack according to the killing stack’s attack priorities".

EDIT: I wanted to clarify why it's important to not use dice. If you have attack dice and defense dice, then that means that one stack has to be an "attacker" and one a "defender", which implies some sort of turn order -- which gets us into the whole can of worms opened up earlier in this thread. This is supposed to be simultaneous play, so each player is attacking and defending at the same time, hence why I think that resolving battles with dice is a poor process for simultaneous play.

There are no dice. Quote: "In each round of attack, the battle engine generates a random integer from 1-100 for each [and every] unit [in each stack], and that unit "scores a kill” if the number is greater than X (defined by the board designer, and subject to border mods). The battle engine then tallies up the total kills scored by each stack, which are then divided amongst each opposing stack according to the killing stack’s attack priorities".

 ..so let's say we're in Stage B and the stacks in transition have 50 and 10 units respectively with orders to kill or be killed with a 50% kill rate in effect. What prevents an average resolution to this battle from being 25 killed to 5 killed?

EDIT: I wanted to clarify why it's important to not use dice. If you have attack dice and defense dice, then that means that one stack has to be an "attacker" and one a "defender", which implies some sort of turn order -- which gets us into the whole can of worms opened up earlier in this thread. This is supposed to be simultaneous play, so each player is attacking and defending at the same time, hence why I think that resolving battles with dice is a poor process for simultaneous play.

 ..unless you consider my little proposal, ..or variation thereof.  It could fit in here, but I want to understand what you've got going here.

M57 wrote:

There are no dice. Quote: "In each round of attack, the battle engine generates a random integer from 1-100 for each [and every] unit [in each stack], and that unit "scores a kill” if the number is greater than X (defined by the board designer, and subject to border mods). The battle engine then tallies up the total kills scored by each stack, which are then divided amongst each opposing stack according to the killing stack’s attack priorities".

 ..so let's say we're in Stage B and the stacks in transition have 50 and 10 units respectively with orders to kill or be killed with a 50% kill rate in effect. What prevents an average resolution to this battle from being 25 killed to 5 killed?

That could be a result of the first round of attack in the resolution of that battle. If that were the case, at the end of that round, player A (who started with 50) would have 45, and player B (who started with 10) would have 0, so the battle would be resolved and A's remaining 45 would continue on their way unopposed to any potential confrontations in Stage C.

Note: The 50% chance of scoring a kill applies to each unit in each round of attack, not the battle overall. Thus any given unit could theoretically kill an unlimited number of opponents, should the battle last long enough.

..and the number of units engaged in the round is determined by size of the short stack?

No, every unit engaged in the battle -- all units from all stacks -- are engaged in each round. The stacks don't have to match up evenly -- you would expect a massive stack to maul a weaker stack pretty quickly.

My head hurts, but I swear I will reread that until I understand it.

asm is right, I do get cranky sometimes. I never mean anything personal by it, so Risky I apologize if I went overboard and pissed you off.

One thing is abundantly clear after having two large discussions on this topic. Despite me being the most vocally opposed to ToS BaO system, it is obvious that implementing that exact system before any others is the best possible thing for WG. Reasons:

Popular support from the standpoint of familiarity.

Popular support from the standpoint of the number of maps that are already created and ready to be ported that are optimized for this system.

The ability to use the BaO system on every map already created without having to change anything in the designer (default BaO dice odds can be assigned and changed only if desired).

I think that last point may be the most important. When and if another system is ultimately created I think a requirement would have to be that it be usable on all existing maps without additional designer input or we'll end up with feature fracture.

I'm not reading all that. Just copy the old BAO and work on something different later. At least then I can copy over my dueling maps.

IRoll11s wrote:

The ability to use the BaO system on every map already created without having to change anything in the designer (default BaO dice odds can be assigned and changed only if desired).

I think that last point may be the most important. When and if another system is ultimately created I think a requirement would have to be that it be usable on all existing maps without additional designer input or we'll end up with feature fracture.

11's,

I don't know if I agree with this. Can someone who is familiar with the mechanics of my Appomattox board confirm that it would work reasonably with ToS BaO?  I doubt it.

The only thing about Kjeld's system that would have to happen to make it work on just about any board design I can think of would be a Risk-Dice to Percent-Dice conversion. And from the looks of your above parenthetical remark, Tos BaO needs the same attention.  The difference is that a Risk-Dice to % Dice Conversion algorithm could be made to automatically convert dice mods.  Though the two are not equal, a value could be found that creates similar results over a range of circumstances.  Right off the bat.. I'd put 6s v 6s in the 50% kill rate category.

In fact, if you really wanted to get fancy, you could assign an automatic sliding scale to Percent-Dice that mimics the advantage of having more armies in your stack.

I wasn't really thinking about the WG boards developed with the new settings. I suppose a setting like the Fog Override setting so that board designers could specify whether they wanted to allow their boards to be played BaO would suffice.

Cramchakle wrote: I'm not reading all that. Just copy the old BAO and work on something different later. At least then I can copy over my dueling maps.

I came here to get away from ToS and a BaO system that made no sense to me. If you want to play on the ToS system, play your maps on ToS ..or read "all that" and then explain how KESP or any other system that is proposed is not any better than what's being suggested.  I see no good reason to jump into a system that clearly has its controversial aspects, such as it requires sophisticated but non-intuitive ordering-mechanics to play effectively.

Don't get me wrong.  If ToS's model looks to be the better one, I'll make the first contribution to the "Bring over ToS BaO" campaign fund and make the check out to Cramchakle.  I just want see WG get it right the first time.