Step22

From a trailer clip to a Big Battle - plan, build and proof in one day

24 October 2026 · 5 min read

vibe-codingbig-battleplanningclaudetokens

Both fleets in a bay seen from high above, with a green shore and a naval yard on either side.

The trailer set pieces were recorded from the real simulation: at the start of the big ground battle there are 618 units on the field, and up to 668 alive at the peak. Watching them on 24 October, the owner had a simple thought. If the game can run that, why can you not play it? This step is how that idea became a plan, a build and a set of proof files in a single day. It is also a fair example of how the work gets split between a person and Claude, with all the caveats.

No release date is promised here, and the mode is not in the menu yet. Read it as a process story.

Earlier that day: an idea, written down

The idea went into the decisions file in the owner's words: spawn giant armies for you and you just fight, skipping economy and tech. The CEO role filed it as a queue row. That is all that happens at this stage. A plan is not code.

The plan

A lead-engineer role (a strong model, told to investigate before writing) read the code and wrote Docs/BATTLE_MODE_PLAN.md, with a one-page summary on top for the owner. Before proposing anything it looked at what existed and recorded it with file and line references: how a skirmish starts, where spawning happens, how lockstep sends orders (one order per unit, about 17 bytes each, so a 500-unit attack order is about 8.5 KB, too much for online), and that target scans were linear over every actor.

The honest performance picture went in the summary, before any feature list:

Measured: 150 to 200 units alive at 60 fps, and 300 alive at 59.2 fps with a worst frame of 39.5 ms.
Not measured: 600 to 1,000 units live. The trailer was recorded offline.

So the plan has gates, 300, then 600, then 1,000 total units, and says outright that the biggest tier ships only if the third gate passes.

The phases and the cost classes

The plan has about 12 build and 9 test phases. Every phase names an owner, the deliverable, the acceptance test and a cost class: S under 150k tokens, M 150k to 500k, L 500k to 1.5M, XL over 1.5M. Hard engine and AI phases go to the strongest model; setup screens and map work to a mid-sized one; scripted test sweeps to the smallest.

Phase	Job	Model class	Cost
B1	settings, presets, spawn planner, win rule	strongest	L
B2	the battle AI	strongest	L
B3	performance to 600 (a spatial grid)	strongest	L
B4	navy, coast, bases, walls	strongest	L
U1	setup screen	mid-sized	M
T1	test pass	smallest or mid-sized	S to M

There were eleven open decisions, each with a recommendation, for the owner to answer.

The owner approves, and changes one thing

The owner approved the plan with every recommendation except one: the first playable should be the full version, not a cut-down minimum. No milestone check-ins, to save tokens, but the performance gates and the determinism tests still decide each commit. The decision is recorded as "GO FOR GOLD". That is the human part: scope, risk and money.

20:25: four phases in one commit (the plan itself was committed at 17:26)

The commit for phases B1 to B4 changed 30 files with 4,031 added lines:

a settings struct, 14 presets and a shareable battle code;
a pure, deterministic spawn planner that places armies in lines, corners or a ring, and fleets in open water;
a battle AI (form, advance, engage, regroup, hunt);
a spatial grid that makes target scans cheaper, and a group-order command;
a navy, coast, naval yards and curved broken walls.

The proof is in files next to it. 71 of 71 tests passed. The ordinary skirmish fingerprint is identical to the baseline of 22 October, so old modes were not touched. The new battles ran at different speeds, and with the grid on and off, and produced the same fingerprints; the grid gives the same result with it switched on and off, in battles and in a 600-second skirmish.

A mockup of the Big Battle setup screen with sides, army sizes, a battle code and a map preview — A mockup, not a screen from the game: the setup screen as designed. The code behind it is not built yet.

What is not done

The build state lists it plainly, and so do we:

No setup screen yet. Today the mode starts from a flag, for example -BigBattle=ground_war. The picture above is a design mockup.
Coast Assault ends in a draw. The last ships stand off out of reach of the land army. That is AI tuning, handed to the opponent role.
The "80 per cent engaged at 30 seconds" target is missed (28 to 67 per cent): the back lines are still marching.
No live measure at 300 or 600 units in this mode yet.
The test phases by the small model come after this commit, and the owner has not played it.

A trailer take of a fleet battle, 720p loop. The mode's navy battles are built to look like this. Not a live play capture.

What the day shows

Claude did a great deal in a few hours: it read the code, wrote the plan, then wrote and tested most of 4,000 lines. It could do that because the plan had acceptance tests written before the code, the determinism check was already there, and every phase fitted a context. It did not decide to build the mode, choose the scope, or play the result.

Try it yourself

Before you ask an agent to build a feature, ask it for a plan with an acceptance test and a cost class for each phase, plus a list of what it has not measured. Approve the plan, not the code. Then check the proof files, not the summary.

Next: How to vibe code a real game with Claude - the ten rules that worked (25 October 2026)

Start at Step 1 All 27 steps