Step13

One mission at a time - the mission maker and the bots that test it

16 October 2026 · 4 min read

campaignclaudeagentstesting

Brick towers with smoke and a fireball rising behind them.

By the middle of October the campaign had seventeen missions: fourteen on land, air and sea, and three naval ones. Each one plays from start to finish on Easy and has a scripted proof. This step is about the pipeline that got them there, which is the thing we are most pleased with, and the bots that make it trustworthy.

Five roles, then one

Missions 2 to 4 were built by five roles in turn: the writer wrote the script, the mapper made the map, the modeller made the missing pieces, the engine added what the director could not express, and QA tested. It worked and it was slow, because each handoff costs a conversation.

On 29 September we wrote a single new role, the mission maker, and handed it the whole job for one mission at a time:

The map and the placement layer. Reuse an existing map where the story allows, otherwise generate one. Every name the script uses is a named place on the map.
The mission file. A small generator script writes the mission as data: every beat on its trigger, the objectives, the hints, the radio lines, the lose rules, the checkpoints and the unlocks.
Voice lines. If the recordings exist, import them. If not, the lines play as subtitles only, and the report asks for the recording.
Pieces. Reuse the approved meshes. If one is missing, use a labelled placeholder and file a handoff to the modeller. Never build models.
Code, only when the director cannot express a beat. One small hook, deterministic, one compile for the whole batch.
The proof, on Easy.

The most important instruction is the one in the first line: copy the patterns that already work. Missions 2 to 4 are the examples. The mission maker is a mid-sized model at medium effort, and it is good at this because the work is mostly imitation with care.

The proof

A mission is not playable until a script says so. The harness issues the same commands a player would, and is forbidden from cheating: no free credits, no kills, no damage. For each mission we require:

a win route that completes every objective,
a lose route that fails properly,
a checkpoint that loads and then still wins,
a beats board, a contact sheet with a screenshot at every story beat of the rendered win run,
and the whole test suite and the lockstep check still green afterwards.

A grid of screenshots from a scripted run of a snowy mission, one frame at each story beat — A beats board: one frame at every story beat of a scripted Easy win. We look at this before we look at the mission.

On 29 September all 43 campaign routes were passing on Easy. By the end of the month all thirteen missions of the first story version played start to finish.

The newcomer bar

"Easy" has a particular meaning here. A player who has never touched the game, and only follows the on-screen hints, must be able to win. Our QA role plays that person against each build. When the ninth mission failed that test, the answer was not to make the enemies weaker. It was to change what the mission asks: a hold-the-hill finish instead of a hunt across the map. The problem was pacing, not toughness.

What broke

Flaky trigger lines. Two missions needed a control run to show that their failures were flaky trigger lines and not the engine change we were testing. A test that cries wolf is worse than none.
Test order. A checkpoint run must never follow a lose run, or it loads a state that no longer exists. The harness now runs win, checkpoint, lose in that order.
A machine that is busy. Several regression runs were refused because another job already had the engine open. The result was a re-run, never a skipped one.
A mission too many. One planned finale was merged into another and archived. The count became 17, and an old plan still said 18.

Honest accounting

Our campaign is proved on Easy only. Medium and Hard are copies of Easy until a final balance pass. Everything that needs a human, such as whether a mission is fun, is still the owner's job, and the owner plays every build.

What we would do differently

Write the mission maker first. We built missions 2 to 4 with five roles in turn before we made the role that does the whole job.
Make the board a requirement from the first mission. It is the fastest way to review.
Keep the machine's time budget in the plan. Tests are the slow part, not writing.

Try it yourself

When you find a job you have done three times by hand, write the role that does it, point it at the three examples, and require a proof it must produce every time.

Next: Cutscenes - Unreal puppets, then Grok Imagine, then DaVinci (18 October 2026)

Start at Step 1 All 27 steps