An AI agent built a Godot game. Then it checked its work.

An agent built a game, wrote bots to play it, and adjusted the game from their results. It passed every target in the first prompt.

That wasn't the end of the experiment. The results exposed questions those targets hadn't asked: could every seed be won? Was judging a bargain actually better than accepting every offer? Could the player even see the ending?

A second prompt sent the agent back. Nobody edited the game by hand between the two turns.

You can play the result in your browser, or inspect the prompts, source, results and checks. This is one recorded example, not a benchmark or a promise that another run will succeed.

This is the first article in Building with persistent AI agents. I'm the author of Spore, the open-source runtime used for this experiment.

The task: keep a doomed city above water

Kêr-Is draws on the Breton legend of Ys: a city below sea level, protected by dikes and a bronze sea gate. The gate brings trade. It can also let the sea in.

The player has to survive twelve tides. Workers quarry stone, grow grain and repair the dike. Gold hires workers. Opening the gate makes money, but the forecast can be wrong. A stranger offers resources in exchange for damage that only appears later.

On a loss, the city sinks and its bells keep ringing under the water.

The prompt specified that structure, the numerical acceptance targets and the execution environment. It was not just “make a game.” It required art and sound generated in code, without downloaded assets, and game rules separated from rendering so automated playtests could run headlessly.

The agent wrote the code, generated the visuals and sound, chose the balancing numbers, recorded video and exported the game for the web.

Why bots were part of the prompt

A screenshot can show that a game exists. It cannot establish that repairing the dike matters, or that one trivial strategy doesn't dominate.

So the prompt required several kinds of player:

• Idle: does nothing.
• Greedy: keeps the gate open and accepts every bargain.
• Fixed: keeps the same worker allocation and gate policy throughout. All 110 combinations were tried.
• Steward: reacts to information a player can see.
• Seer: has knowledge of future events.

The tests covered 200 seeds. Targets included idle losing early, greedy rarely winning, fixed strategies doing poorly, and steward winning within a specified range. Removing repairs or keeping the gate permanently closed had to make steward substantially worse.

These were explicit tests of the intended design, not a model's impression that the game felt balanced.

The agent could run the tests, inspect results, change the implementation and run them again. The published attempt log records problems such as trade being unnecessary and flooded districts making defence easier rather than harder.

Passing the targets wasn't enough

The first turn met all seven original targets. But reviewing the data revealed three important gaps.

A weak oracle doesn't prove an impossible game

None of the tested policies won 24 of the 200 seeds. Seer won 87% overall.

That did not establish that the remaining seeds were impossible. It could mean the bot wasn't clever enough.

In the second turn, the agent wrote a search over the full future. It found winning plans for every one of the 200 seeds and replayed them through the game's rules.

The important distinction is that it improved the search, not simply the win rate by making the game easier. The published comparison reports unchanged balance parameters and identical outcomes for all fixed strategies across the two turns.

There is still a caveat: a full-future search is no longer the original “plays like steward, but knows the future” bot. It establishes that winning paths exist in these seeds, not that a human could discover them. In the final results, 58 seeds were won by seer alone.

The stranger rewarded the wrong behavior

After the first turn, always accepting bargains won 55% of seeds. Steward's selective rule won only 44.5%.

The original targets required bargains to help some runs and ruin others. That could be true even while accepting every offer was the better strategy.

The second prompt added a stronger requirement: selective play should beat both always accepting and never accepting.

The agent gave the stranger a visible voice—warm, wavering or hollow—that hints at the damage behind the gift. Steward could use that information. Its win rate rose to 60%, against 55% for always accepting.

That meets the new target, but it also exposes another design compromise: the signal is quite revealing. In the later unseen-seed test, heavy damage followed a hollow voice almost every time. Wavering offers retained more uncertainty.

A passing test isn't the same as an interesting game-design decision.

The ending existed, but the player couldn't see it

The result dialog covered the drowned city, and the final scene was too dark.

The second turn hid planning panels during the sinking, kept the city lit, and delayed the result until the bells had rung for eight seconds.

The numerical balance tests hadn't asked whether the ending was visible. That needed a different kind of review.

We also made a mistake in the prompt

Our draft of the first prompt included a 95% seer target. The actual prompt sent to the agent did not.

We wrote the second prompt from the draft and accused the first report of missing that requirement. The agent's target audit correctly identified it as a new target. Its final report nevertheless accepted the blame.

That is worth preserving in the write-up. The seven original targets passed; the second turn introduced three additional targets. Calling the first turn a failure would misrepresent the instructions it received.

Checking the checker

The agent wrote both the game and its bots. Agreement between them is useful, but not independent validation.

The published repository separates the agent's artifacts from the checks we added afterward:

• The agent delivered the game source, bot data, attempt log and media.
• We added Python verification scripts to recompute results from the artifacts and compare the turns.
• We also added a test over 2,000 unseen seeds, because steward's rule had been tuned on the same 200 seeds used for scoring.

On those unseen seeds, the published output reports:

The advantage held on that additional sample. This still isn't a human playtest, a proof of enjoyable gameplay, or a general evaluation of the model.

The README explains how to recompute the artifact checks with Python, replay policies in Godot and inspect the unseen-seed output.

Where Spore fits

Spore didn't supply game logic or a Godot-specific plugin. Godot ran from the command line inside the agent's sandbox; this example required no external application bridge.

The runtime provided the workspace and execution environment in which the agent could keep programs and results, run tools, inspect files and continue into a second turn.

The distinction matters: the model brought the reasoning and code generation. Spore provided the machinery around the work. This example doesn't isolate how much each contributed, and it doesn't establish superiority over another runtime.

The recorded run used Spore 1.57.0, Godot 4.7.2 and gpt-6.1-sol through a ChatGPT plan. The published timings are roughly half an hour for the first turn and three quarters of an hour for the second. There is no metered API cost for those plan-based turns; that is not a claim that execution or model access was free.

What I'd take from this experiment

The most useful result isn't “an agent can generate a game.” It's the workflow:

1. Make the intended behavior mechanically testable where possible.
2. Let the agent write and reuse programs to measure it.
3. Inspect what the acceptance targets leave out.
4. Separate generated evidence from additional verification.
5. Keep the remaining limitations visible.

The game is playable, not a finished commercial production. A new run may make different choices or fail. The prompts and evidence are public so you can examine more than the final video.

Play Kêr-Is · Inspect the experiment · Spore source

Next in this series: using a persistent coding agent in a Git project—running a task, reopening the workspace and inspecting what changed.