The Turn Model — Orders and the Cascade

Status: Design proposal v1 · Subsystem: turn structure and activation · Supersedes: the (A)/(B) fork left open in §4 of the design direction.

This document resolves the open question in §4, specifies the turn and activation model that follows from that resolution, and works a full turn through step by step with real numbers. Every value here is invented for a stated reason and is calibration, not scripture.

1. The problem, stated honestly

Multiplayer games of this shape have one structural defect that dwarfs all others: the wall clock scales with the number of players. Six players, four minutes of thinking each, and a turn takes twenty-four minutes, of which you spend twenty watching. Over a two-hundred-turn game that is not a minor annoyance. It is the reason these games are played asynchronously by email or not at all.

There is a second defect that only appears later and is just as fatal: the decision count scales with the empire. By turn 150 a player may own 150 units. If the turn model demands one human decision per unit per turn, the game dies of its own success — the better you play, the more unbearable your turns become. §6 of the direction names this ("late-game micromanagement"), but it is not a UI problem. It is a turn-model problem, because the turn model is what decides how often a human must be consulted.

Any proposal that fixes the first defect and ignores the second is worthless at turn 150. I will therefore judge every option against both.

§4 proposes a single global activation queue ordered by unit creation sequence, and flags an ambiguity in how that queue governs play. That ambiguity is the first thing to settle, because it is not a detail — the two readings are different games.

2. Resolving the fork

2.1 What each reading actually costs

Let me put numbers on it. Assume midgame: each player commands 30 units, and a player who plans their whole turn in one uninterrupted sitting takes 8 seconds per unit, so 4 minutes per player-turn.

Under (A) strict global order the player never gets an uninterrupted sitting. They are handed one unit at a time, in an order they do not control, with other players' units — and other players' actions, which change the board — interleaved between their own. Every activation is a cold start: where is this unit, what was I doing with it, what has changed since I last looked at this corner of the map. I estimate that inflates per-unit time by at least 50%, to 12 seconds. That estimate is the weakest number in this document and I flag it as such, but the direction of the effect is not in doubt.

Three things fall out of that table, and they decide the question.

First: (A) does not reduce your idle fraction at all. It cannot. The turn's length is the sum of every decision made in it, and (A) changes nothing about how many decisions there are or who makes them. It re-slices the same idle time into thinner pieces. §4 already half-admits this ("waiting is reduced rather than solved"); the table says it is not reduced either, only redistributed.

Second: the redistribution is not obviously an improvement, and at eight players it is a regression. At N=8 the expected run of consecutive foreign units between two of yours is seven units — about 84 seconds of enforced watching, repeated thirty times. That is long enough to be boring and short enough that you cannot leave the desk, get a coffee, or look at another window. It is the worst possible interval. And it is longer than the 60-second cascade the concurrent model asks you to watch once per turn.

Third: (A) makes turns longer. 48 minutes instead of 32 at eight players. Push it to turn 150 and 150 units each: 8 × 150 × 12 s = four hours per turn. There is no version of this game where that is playable.

There is a fourth cost that does not show up in a table and that I think is the real objection. Empire-shaped games are about operations: "these six units execute a pincer on the ford while the artillery displaces forward." Under (A) you cannot execute an operation, because you do not choose the order your own units act in — creation sequence does — and enemy actions land between your units' moves. You are reduced to making thirty locally-sensible moves. For an audience that came from Shadow Empire and Old World, taking away the ability to sequence your own forces is not a novel constraint. It is the removal of the thing they came for.

2.2 Can (B) be made deterministic?

Yes — but only by abandoning what makes it (B).

Read literally, (B) says players advance through their units in real time and actions take effect as they are submitted. That is recordable: stamp each order with an arrival index, log it, replay the log, get the same game. So it is replayable. It is not reproducible — re-running the same decisions yields a different game, because arrival order is a function of network latency and human reaction speed. And it is contestable: a player on 20 ms wins races against a player on 180 ms, systematically, in a game about contesting tiles. For a patient strategy game marketed to people who think for four minutes a turn, losing a ford to ping is disqualifying.

There is also the invalidation problem §4 flags. If unit 7's action is submitted and then unit 4's action arrives and would have made it illegal, you have three choices: re-prompt player 1 (which re-serialises the queue, destroying the concurrency you bought), silently cancel unit 7's action (a wasted unit-turn caused by another player's typing speed), or roll back and re-resolve (which is a distributed-systems problem with no bounded solution when the actors are humans). None of the three is acceptable.

But there is a fourth reading of (B) that §4 does not quite say, and it is the right one:

Players submit concurrently. The engine resolves in a fixed order that has nothing to do with arrival time.

Under that reading determinism is not merely preserved, it is trivial. There is no race, because there is no race condition — the resolution order is decided before anyone submits anything, and submitting earlier buys you nothing. The invalidation problem does not arise, because at resolution time nothing is pending: unit 4 fully resolves, then unit 7 is evaluated against the world unit 4 left behind.

2.3 The recommendation

Take (B)'s concurrency and (A)'s ordering. They are not competing answers to the same question; they are answers to two different questions that §4 conflated.

• When may a player think and issue orders? Answer: always, concurrently with everyone else. This is (B)'s contribution and it is where the entire wall-clock win comes from.
• In what order do actions take effect? Answer: one strict total order over all units, decided by the engine. This is (A)'s contribution — "the ordering is the conflict resolver", exactly as §4 says — and it is where determinism and the absence of paradox come from.

§4's core invention, a single global sequence-ordered activation queue, is excellent and I am keeping it. What I am rejecting is its use as an interaction schedule. It is a resolution schedule. Applied there it costs nothing, blocks nobody, and does everything §4 wanted from it.

One honest concession: at two players with small forces, (A) is a genuinely good game. Alternating activation is a beloved model in board wargames for good reason, and I would not sneer at shipping it as a small-skirmish variant. But it cannot be the default, because the default has to survive eight players and turn 150, and (A) does not.

3. The model: Orders and the Cascade

Two phases per turn.

Orders — concurrent, all players at once, bounded by a clock. Every player revises orders for as many of their units as they wish, in whatever order suits them, seeing the world as it stood at the end of the last Cascade. Nobody is ever blocked by anybody. This phase is the game's thinking time.

The Cascade — no input. The engine walks every unit in initiative order and resolves each one's order against the world as it is at that instant. The Cascade takes milliseconds to compute and is presented to players as an animated, fog-filtered sequence lasting perhaps thirty to sixty seconds.

Then production, upkeep, and end-of-turn bookkeeping, and the next Orders phase opens.

That is the whole skeleton. Everything below is detail on how the Cascade is ordered and what an order actually is.

3.1 The activation order is initiative, with creation sequence as the tiebreak

§4 proposes ordering the queue by raw creation sequence, permanently. I think that is wrong, for two reasons that are failure modes rather than matters of taste.

Fossilised first-mover advantage. A player who built earlier has permanently lower sequence numbers on everything, forever. Whatever advantage "acts first" confers, they hold it for two hundred turns and cannot lose it. Nothing in the game can take it away, and no decision the player makes can earn it. That is the worst kind of advantage: invisible, compounding, and unearnable.

Degenerate blocks. Creation sequence interleaves players only by accident. If Meridian built heavily on turns 1–10 and Karsk on turns 11–20, the queue reads all of Meridian, then all of Karsk — which is strict sequential turns, with Meridian permanently first, arrived at by a rule that promised the opposite.

So: the order is recomputed every turn from an integer Initiative score, and the creation sequence number survives as the tiebreak. That preserves §4's guarantee exactly — sequence numbers are unique, so the sort is a total order, so no two units ever contest a tile simultaneously — while making the order something players can steer.

Initiative is a pure function of committed state, computed once at the start of the Cascade and frozen for the duration. Nothing that happens during a Cascade re-sorts it. That keeps replay exact and keeps the order explicable to a player: it is a list they can see before the Cascade runs.

Base initiative by class. These are the shape of the number, not a roster — the unit designer owns the roster:

Modifiers:

The calibration statement, which is the number that actually matters: class spans 36 points (24–60); posture spans 20 (+8 to −12); condition can subtract another 18. A unit's state and its owner's choices can move it further than its class does. A veteran field gun in March (24+8+6 = 38) outranks a broken, out-of-supply line battalion (40−8−10 = 22) by a wide margin. That is the intended feel: what a unit is sets the expectation; what has happened to it and what you told it to do can overturn the expectation.

The score has no floor and needs none — it is a sort key. Ties break on ascending unit sequence number, which is unique, which makes the order total.

Seniority, and its counterweight. §4 asks whether seniority-by-age unfairly punishes rebuilding. Under raw creation order, yes, permanently and unrecoverably. Under this model the age term is inverted and bounded: instead of veterans accumulating an unbounded bonus, new units carry a temporary penalty that expires in four turns. Same arithmetic, completely different consequence, and a much better story — the unit is forming up, it has not learned its officers' names yet, and in four turns it is a line unit like any other. A player who loses an army and rebuilds is behind for four turns on the units they rebuilt, not forever. The real seniority mechanic — the one that should persist — is veterancy, which is earned by fighting, not by existing. That is a reward for having played well, which is the only kind of accumulating advantage a game should hand out.

There is a second, subtler counterweight built into the model, and it is my favourite thing in it. High initiative means you act first, which means you act on less information: at your activation, few units have moved this turn. Low initiative means you act last, on a board where everything else has already committed. Seniority buys you the first strike; youth buys you knowing where everyone went. Neither is strictly better. Players will learn to keep young or low-initiative units back as a reserve precisely because they resolve with full information, and that is an emergent role for exactly the units a naive seniority rule would have punished.

3.2 Orders are intents, evaluated at activation

This is the second load-bearing decision, and it is what makes concurrent planning survive contact with a changing board.

An order is not a recorded script of steps. It is a small policy, stored on the unit, evaluated when the Cascade reaches it, against the world as it then is. A unit's order persists across turns until it completes or the player changes it.

Two consequences, both large.

Invalidation stops being a category of error. §4 asks what happens when a later unit's action invalidates an earlier unit's pending action. Under sequenced resolution nothing is ever pending, so the question dissolves into a smaller and much more tractable one: what happens when an order is unachievable at the moment it is evaluated? Four cases, and each has an obvious answer:

If a policy can produce nothing at all, the unit falls back to its stance, which every unit always has and which defaults to Hold. There is no error state and no wasted-because-of-a-technicality unit-turn. Note the distinction from the "fail loudly" engineering rule: an order that is illegal when issued is rejected loudly at submission. An order that is legal when issued and unachievable at activation is not a bug, it is the game.

Order persistence is what makes turn 150 survivable. The Orders phase is about changing orders, not issuing them. A player with 150 units touches the twenty that need new instructions and leaves the rest to continue what they were doing. That is the difference between a four-minute turn and a four-hour one, and it is a turn-model property, not a UI convenience. It also makes the deadline humane: if you time out, your army does something coherent rather than freezing in place.

Move is not attack. A bare Move-To halts on contact with an enemy; it never initiates a fight. Attacking requires an Attack order. This costs a little friction and prevents an enormous amount of accidental suicide, and it means a Move-To order that goes stale degrades safely rather than catastrophically.

Conditionals. Orders carry optional conditions evaluated at activation: "Move to the ford; if it is held by two or more enemies, entrench where you are." This is where the reactivity that sequenced resolution seems to take away comes back — declaratively, in advance, without requiring a human to be present, which means async play gets it too. I regard the richness of this conditional vocabulary as the single biggest open risk in the design and I return to it in §7.

3.3 Posture, and reactions

Full activation (a unit spends its whole allowance when reached, then yields — see §5) has one real cost: a fast unit completes a six-tile run before a slow unit has moved at all, so it cannot be intercepted mid-move. Fix it with reactions rather than by stepping the whole world.

When a unit's movement takes it adjacent to an enemy that has reaction capacity available, that enemy may interrupt: the mover halts, and the reaction resolves. Reaction capacity comes from posture — Hold and Entrench have one reaction each; March and Advance have none. Among several eligible reactors, the one with the higher initiative reacts, ties on ascending sequence number, which keeps it deterministic.

Reaction capacity is set by the stance the unit committed to at the start of the turn and is live for the entire Cascade, before and after that unit's own activation. This matters enormously: it is what lets a low-initiative defender meaningfully affect a high-initiative attacker who acted long before them. Without it, low initiative would be purely a penalty.

The tactical shape this produces is good and it is exactly what §6 asks for ("terrain, posture, combined arms, and positioning should matter, without becoming fiddly"): if you want to intercept, somebody has to be standing still. A player who puts every unit on March gets the whole first half of the activation order and a line that cannot catch anything.

What the turn model owns here is when an interrupt happens and who gets it. The resolution — what overwatch fire actually does — belongs to the combat design.

3.4 Birth, death, and other mid-Cascade changes

Destroyed mid-Cascade. The slot is skipped. Nothing is compacted or re-sorted. This is why freezing the order at the start of the Cascade matters: a mutating sort during iteration is exactly the kind of thing an AI-written codebase gets subtly wrong.

Created mid-Cascade. It does not happen. Production resolves after the Cascade completes, at end of turn. The new unit draws the next global sequence number, appears on the map, and enters the next turn's order like anything else — near the bottom of it, because Forming Up is −8. A unit built this turn acts next turn. Uniform, predictable, plannable, and it gives production timing real weight ("that garrison arrives one turn too late" is a sentence a player should be able to say).

I considered letting new units enter the current Cascade at the very tail with a severely restricted action set, and rejected it: extra rules, extra edge cases, and the only thing it buys is shaving a turn off production latency, which is better handled by tuning production time.

Multiple cities completing in the same end-of-turn step resolve in ascending city sequence number, from the same global counter units draw from. One monotonic counter for every entity in the game, consumed in a defined order. That single sentence is most of the determinism argument for creation.

Embarked units. A unit inside a transport is not in the activation order at all. It is acted on as part of its transport's activation, and a unit that lands is spent for that turn — it may still react if its stance allows, but it does not get its own activation. This prevents an amphibious force getting a free move on the beach. I would expect the transport design to want a specific assault-landing type that relaxes this, and that is the right place for the exception to live.

3.5 Stalls, deadlines, and disconnects

This is where the model most obviously beats both readings of §4, because under (A) and (B) a stalled player is the queue. Here, nobody is ever blocked by anybody during Orders. The only shared resource is the turn boundary.

• Every turn has an Orders deadline, configured per game: 90 seconds (blitz), 8–15 minutes (live), 24–72 hours (correspondence), or unbounded-until-unanimous-commit (hotseat and solo).
• A player who has not committed when the deadline passes does not stall the turn. Their units execute their standing orders and stances — which, because orders persist, is usually a coherent continuation of what they were already doing rather than a freeze.
• Each player holds a reserve bank (default 30 minutes per game in live play, chess-clock style) drawn down automatically when they overrun a deadline. It absorbs the two or three genuinely hard turns without letting one player hold eight people hostage.
• Disconnect: standing orders continue. After three consecutive missed turns the remaining players are offered a vote to substitute an AI (auto-substituted in ranked play). The absent player reclaims their position on reconnect.
• Async: identical rules, deadline measured in days, no live presence required at any point. This is the mode the model is best suited to, and it needs no special-casing at all.

A quantitative point worth making: under strict sequential turns, a player who overruns by five minutes costs each of the other seven players five minutes. Under concurrent Orders, a player who overruns costs the others only their excess over the second-slowest player, which is usually near zero. Slowness stops being externalised.

Hotseat degrades gracefully rather than breaking: at one machine, Orders phases are necessarily taken in sequence, but the Cascade is byte-identical. The rules do not change; only the input schedule does.

3.6 Fog: what you see, and when

During Orders, nothing is happening. No opponent action is "in progress", because no action is in progress for anyone. You see the world as of the end of the last Cascade, fog-filtered, and it is stable while you think — no half-glimpsed movement, no partial information, no incentive to stall hoping to see something. This is a real improvement over sequential turns, where the information you act on depends on where you sit in the turn order.

What you do see is presence: who has committed, who is still working, how long remains. That is non-authoritative ephemeral data — exactly the category the stack decision reserves for Colyseus schema sync, and nothing else needs to travel.

During the Cascade, fog is evaluated per activation, not per turn. This matters more than it sounds. If an enemy column crosses your scout's field of view and then leaves it, you must see the transit — otherwise the replay is a lie and the drama of watching a turn unfold is hollow. Getting this right is what makes the Cascade worth watching: a column emerges from the treeline, crosses your line of sight, and is gone.

There is a leak to close. If the client received a per-activation stream in real time, a player could infer that something happened from a gap even when they saw nothing, and correlate gaps with initiative bands to deduce enemy composition. So the server emits, per player, a compacted stream of observable events only — no gaps, no timing that maps back to activation indices — and the client animates it at its own pace. The player learns what they could see and nothing about what they could not.

3.7 Determinism and the log

The log per turn is: the turn number, the set of (unitId, order) changes each player committed, and a commit marker recording whether each player committed or timed out. The Cascade itself is not logged — it is recomputed. That is deliberate: logging the derived result would let a divergence hide inside the log instead of tripping on it.

One cheap, high-value tripwire: canonically hash the frozen activation order at the top of every Cascade and compare across peers. It is a few hundred bytes, it catches the single most likely class of desync (an initiative modifier applied in a different order, or a sort that is not stable), and it catches it before any state has diverged, which makes the bug findable.

The specific determinism hazards this model introduces, all mechanically checkable:

1. Anything that recomputes initiative mid-Cascade. Forbidden.
2. Reaction eligibility that depends on collection iteration order rather than an explicit sort.
3. Order-policy evaluation that reads wall-clock time or unsorted map data.
4. Production resolving in any order other than ascending city sequence number.

3.8 The actual pipeline (stage two)

The model earns the word "pipelined" from this refinement, which I would build after the base model is stable rather than with it.

Once a unit has activated in Cascade T, everything relevant about it for turn T+1 is already known. So the Orders phase for T+1 can open, per unit, the moment that unit activates — planning for the next turn overlaps the execution of the current one. In live play with a long Cascade this is real time recovered, and it makes the Cascade something you participate in rather than watch.

The safety rule is that the formal Orders phase for T+1 still opens when the Cascade ends and everything stays revisable; rolling planning is early access, never a commitment you are locked into before you have seen the rest of the turn.

4. Worked example: turn 41 at Kelsey Crossing

Three players — Meridian, Karsk, Ostry. A river runs north–south at x=15, crossable only at Kelsey Ford (15,9). Meridian's city Vell sits at (12,8), west of the river. Karsk is pushing west along the road at y=9. Ostry is coming up from the southeast. Eight-way movement, Chebyshev distance, stacking limit 3.

4.1 The board at the start of turn 41

Karsk's 0488 lost a skirmish last turn and is Disrupted. Meridian's 0402 is veterancy grade 2; 0104 is grade 1. Nobody is out of supply.

4.2 Computing the activation order

Frozen order, descending, ties on ascending sequence:

0231 (O) → 0601 (M) → 0402 (M) → 0644 (O) → 0117 (K) → 0488 (K) → 0104 (M) → 0670 (M) → 0455 (K)

Owner pattern O M M O K K M M K. Three players thoroughly interleaved, from one integer sort.

Compare the raw creation order §4 proposes — 0104 (M) → 0117 (K) → 0231 (O) → 0402 (M) → 0455 (K) → 0488 (K) → 0601 (M) → 0644 (O) → 0670 (M). It interleaves the players roughly as well, which is fair to note. But look at what it orders: the entrenched garrison acts first, doing nothing; the field gun acts before both cavalry units and gets to open a battle it should be closing; the disrupted battalion acts at full priority as though nothing had happened to it; and nothing any player did this turn changed the order in any way. Creation-order gets the interleaving right by accident and everything else wrong on purpose.

4.3 The Cascade, step by step

1 · 0231, Ostry Light Horse (init 68). Screening ride toward (15,11). Step one, (19,12)→(18,11), fine. Step two, (18,11)→(17,10) — which is adjacent to Karsk's 0117 at (18,9), and 0117 is in Hold with its reaction unspent. Interrupt. Overwatch fires; the horse takes damage and halts at (17,10) with two movement points forfeited. Ostry's screen is blown on the first activation of the turn.

Note what just happened: the lowest-but-two initiative unit on the board stopped the highest. That is the counterweight to initiative working exactly as designed — but only because Karsk chose Hold, paid −6 for it, and gave up 0117's movement to buy the reaction.

2 · 0601, Meridian Light Horse (init 68). March, four points. (11,9)→(12,9)→(13,9)→(14,9)→(15,9). Its condition — if enemy-held, halt at (14,9) — is evaluated on arrival: the ford is empty, because nothing else has moved yet this turn. Meridian takes Kelsey Ford. This is what high initiative buys, and it is bought with risk: 0601 is in March, so it has no reaction and a defensive penalty, and it is now sitting alone on the far side of a river with a Karsk column approaching.

3 · 0402, Meridian Line Infantry (init 44). Two points, (13,9)→(14,9)→(15,9). Its condition — entrench in place if the ford is not friendly-held — evaluates false, because 0601 holds it. So it completes the move and stacks. The ford now holds two Meridian units. Meridian's plan worked because it was written as a plan and not as a hope.

4 · 0644, Ostry Line Infantry (init 38). Ordered to assault the ford. When Ostry wrote that order the ford was empty and the assault was a formality. It is now held by two units, one of them a veteran, across a river. The order says assault, so it assaults, and it is destroyed.

This is the model's sharpest lesson and I want it visible rather than smoothed away. Ostry made two mistakes. The order carried no condition, so it could not notice the world had changed. And Ostry knew better by the time it mattered — 0231's ride in step 1 revealed the Karsk column, which should have told Ostry the ford would be contested — but 0231 activated in the same Cascade, so that knowledge arrived too late to act on. Had Ostry written "assault the ford; if held by two or more, halt at (16,10) and entrench", 0644 would be alive and dug in on the approach. The conditional vocabulary is not a convenience feature. It is the skill ceiling.

5 · 0117, Karsk Infantry (init 34). Hold. No movement, and its reaction is already spent on the horse. A no-op activation — but it shaped the turn thirty seconds ago.

6 · 0488, Karsk Line Infantry (init 32). Two points, (18,9)→(17,9)→(16,9). Nobody can react: the Meridian units at the ford are in March and Advance, neither of which has reaction capacity. It arrives adjacent to the ford unopposed. Karsk is in contact.

7 · 0104, Meridian Infantry (init 30). Entrenched garrison. No-op.

8 · 0670, Meridian Line Infantry (init 28). Holding the Vell approach at (13,8), reaction armed, nothing in range. No-op — but this is the reserve, it is young, it will be first to act after seeing where Karsk went, and next turn its Forming Up penalty drops from −6 to −4. Exactly the unit the naive seniority rule would have written off.

9 · 0455, Karsk Field Gun (init 24). One point, ordered to (17,10) to set up a bombardment. But (17,10) is occupied — by Ostry's damaged light horse, stopped there in step 1 by Karsk's own overwatch. Move-To halts on contact rather than attacking, so the gun stays at (18,10). Karsk's bombardment plan is spoiled by a third party's crippled scout, put there by Karsk's own shot. Nobody designed that. It fell out of the ordering.

End of turn. Vell completes a line infantry: sequence 0681, placed in Vell, Forming Up −8, first activation in turn 42 near the bottom of the order. 0231 carries damage and 0488 clears its Disrupted flag at end of next turn.

4.4 The swap paradox, for completeness

The canonical failure of simultaneous resolution: A at X orders a move to Y; B at Y orders a move to X; they pass through each other, or occupy each other's tiles, or the engine deadlocks. Under the Cascade this cannot occur. Whichever of A and B has higher initiative activates first and finds the other still standing in the destination tile, so the move halts on contact. There is no case to special-case, no tie to break, and no rule to write. §4 called the ordering the conflict resolver, and that is precisely what it is.

5. The other fork: one step per pass, or full activation

§4's model leaves open whether the queue is walked once per turn (a unit does everything and yields) or repeatedly (every unit takes one step per pass). This changes the feel of the game more than almost anything else in this document.

One step per pass is physically honest. Units move alongside each other in time; a six-point cavalry cannot cross your entire front before your one-point infantry has stirred; interception is natural rather than bolted on; speed becomes defensive as well as offensive, because you can withdraw as an enemy approaches. Those are real virtues and I do not want to dismiss them.

But it fails on four counts.

It dilutes initiative into nothing. Under stepping, a one-point unit acts once and a six-point unit acts six times. "Who goes first" collapses into "who has more movement points" — a statistic the game already has. The initiative system, and with it §4's entire seniority idea, becomes a rounding error on movement allowance. That alone would decide it.

It makes the turn unreadable. With a maximum of six movement points and 1,200 units, a turn is 7,200 activation evaluations. The engine does not care — that is milliseconds. The player cares: 7,200 events to present, no coherent narrative in any of them, and no way to say "the cavalry rode from the ford to the ridge and took the outpost" because that sentence never happened as a unit of anything. Under full activation it is one event with a beginning and an end.

It multiplies the log and the replay by the maximum movement allowance, and makes the replay's cost a function of a balance number, which is a bad coupling.

It makes combat structurally awkward. Do you fight mid-move? On which step? Does a unit that has spent four of six points fight at reduced strength? Every answer creates rules, and the rules interact with the unit roster.

Recommendation: full activation. One activation per unit per turn; the unit spends its allowance, fights, and yields. Recover the one thing that genuinely mattered from stepping — interception — through the reaction system in §3.3, which costs one rule and one posture column rather than a sixfold multiplication of the entire simulation.

Be honest about what remains lost: a fast unit in March, with no enemy holding a reaction anywhere along its route, can still run clean through a gap in your line. I think that is correct. That is what cavalry does, and stopping it is what screens and picket lines are for. The model gives you a way to build a screen (units in Hold, which pay initiative for the privilege) and makes the cost of not building one legible.

6. Why this beats the classic approach

Against strict sequential turns: turn wall clock drops from N × d to max(d) — 32 minutes to 4 at eight players — and idle time drops from 87.5% to approximately zero, because you are working whenever anyone is. Information asymmetry from turn position disappears: nobody acts on a board seven other players have already rearranged.

Against (A) strict global order: turns are 12× shorter at eight players (4 minutes against 48), and the gap grows without bound as unit counts rise — at turn 150 it is 4 minutes against roughly four hours. Players can sequence their own forces and execute operations. Nobody has to sit attentive for half an hour to make thirty eight-second decisions.

Against (B) as literally read: identical concurrency, but resolution order is independent of network latency and typing speed, so no race is winnable by having a better connection, and the "later unit invalidates an earlier pending action" problem never arises because nothing is ever pending.

Against plain simultaneous / WEGO resolution: no paradoxes, at all, ever — not swap-through, not double-occupancy, not mutual destruction ambiguity — because resolution is a strict total order rather than a simultaneous evaluation. And unlike WEGO, orders are not blind: a late-initiative unit's order is evaluated against a board where the whole first half of the turn has already happened, so conditionals give real intra-turn reactivity without a human being present. That last property is what makes correspondence play a first-class mode rather than a degraded one.

On §6 of the direction's named weaknesses: order persistence attacks late-game micromanagement at the root by making continuation the default and change the exception. Posture and reaction give combat the tactical texture that repeated coin-flips lack, without adding a resolution step. And initiative is a visible system — you can see the order before the Cascade runs, you can see why each unit sits where it sits, and you can change it — which is the opposite of the opaque invisible tax the direction objects to.

7. Tradeoffs, and what this costs

You commit before you see. This is the real price. In a sequential game you watch the enemy move and then respond. Here you write your intent, and the turn happens. Some players hate this, and the ones who hate it hate it a lot. My argument is that conditionals convert the discomfort into skill — the good player is the one who anticipated the branch — but that argument only holds if the conditional vocabulary is genuinely expressive, and building it is real work.

The conditional vocabulary is a whole subsystem. It needs a UI that is legible at a glance, a grammar simple enough that a new player uses it in their first hour and rich enough that an expert still finds it insufficient in their hundredth. If we ship a thin version, the model degenerates into blind WEGO and Ostry's 0644 dies every single turn. This is the design's biggest risk by a wide margin.

Initiative is a new number players must learn. Nine modifiers is a lot for turn one. It needs progressive disclosure — the tutorial game should probably expose posture and nothing else — and that is a real cost against §3's "escalating complexity" goal, which it can serve well if we get it right and undermine badly if we do not.

The slowest player still sets the pace. Concurrency removes the sum, not the maximum. Deadlines and reserve clocks bound it, but a game with one very deliberate player is still a slow game, and a deadline that forces a hasty commit is a worse experience than waiting was.

Per-activation fog is expensive. Recomputing visibility per player per activation is far more work than once per turn. On a 2,000×2,000 map with 1,200 units it needs incremental visibility rather than recomputation, and that is genuine engineering. Cutting it is tempting and would hollow out the Cascade.

Two phases is more machinery than one. More states, more transitions, more ways for a client to desync from a server about which phase it is. Against that: the phases are cleanly separated, one is pure computation, and the pure one is trivially testable in isolation — which for an AI-authored codebase is worth the extra state.

Hotseat loses the whole benefit. At one machine, Orders phases must be sequential. The rules are unchanged, but a hotseat game is exactly as slow as it always was.

8. What could go wrong, and how playtesting would show it

The single fastest diagnostic in playtesting is the stance-fallback rate. It is cheap to measure, it responds immediately to changes in the conditional vocabulary, and it is a direct proxy for "is the player's intent surviving contact with the turn." If that number is healthy, the model is working. If it is not, nothing else matters.

9. Open questions I could not settle

1. How large should the conditional vocabulary be? I have argued it is the design's biggest risk and I cannot resolve it from a desk. I suspect the answer is six to eight condition types, but the right method is to build three and watch what players try and fail to express.
2. Should enemy initiative be visible? For a unit you can see, showing the exact number leaks veterancy, supply state, and posture. Showing nothing makes planning against it guesswork. I lean toward a coarse three-band display — quick / steady / slow — but the fog design owns this.
3. Should reactions be a per-unit capacity or a shared pool? Per-unit (one per Hold/Entrench unit per turn) is what I have specified because it is simple. A per-player alert pool would make screening a resource-allocation decision, which is richer and might be better. Needs the combat design's view.
4. Should the Cascade ever pause for a live decision? "Your transport is under attack — commit the escort?" is tempting and dramatic. I lean firmly no, because it breaks parity between live and async play and reintroduces the blocking the model exists to remove — but I hold that position less strongly than the others here.
5. Does Forming Up apply to captured units and captured city garrisons? Thematically it should. Mechanically it makes capturing slightly worse, and capture incentives are somebody else's balance problem.
6. Multi-turn orders through fog. Order persistence implies a unit can hold a six-turn march order. What happens when the route passes through unexplored territory, or through terrain that turns out to be impassable? Some rule is needed for how much a unit "knows" about its own route.
7. Is (A) worth shipping as a small-skirmish variant? It is a good two-player game. But a second turn model means every other subsystem must be correct under both, which roughly doubles the rules test matrix. I would defer it well past 1.0 and would want a strong reason to ever pick it up.
8. The 50% context-switch inflation in §2.1 is a guess. It is the least defensible number in this document. It does not change the conclusion — (A) fails on turn length and operational coherence even at zero inflation — but it should be measured rather than assumed if anyone wants to revisit the fork.