How to set up Claude Code for game development: make the game legible to the agent

If you want to know how to set up Claude Code for game development, one recent source makes a useful argument: most of the work is on the game, not the agent. In his talk write-up "Your Game Is A Harness", developer Kyle Kukshtel argues for one seeded random source, save/load from day one, a single object type, serializable commands, and image diffs the agent can read. This guide turns his argument into an ordered checklist. It also marks where his claims stop and where the evidence is thin.

What "harness" means here, and what this guide does not cover

Kukshtel's post is the blog version of a 45-minute talk he gave at Indie Rodeo in Calgary, dated 9/12/26 in the post. He says the text is fully human-written from his slides and is not a transcription.

He defines a harness as a set pattern of actions an agent takes in response to some defined input. He names Claude Code as a harness most readers already use, and says harnesses can be extended to fit specific work.

His central claim is that existing harnesses do not talk to your game. To the model, the game is a black box, and mostly only the code is visible. So the job, in his framing, is to make more of the game addressable by an LLM.

Be clear about scope. This is a guide to changing your game's architecture and tooling. The article does not cover CLAUDE.md files, hooks, permissions, MCP servers or slash commands, so this guide does not either. For the configuration side, see our notes on Claude Code's /doctor prompt audit and CLAUDE.md, the godot-ai MCP server setup, and the Awesome Gamedev Agent Skills pack.

Why do agents struggle with games?

Kukshtel reports that LLMs worked well for him on web stacks. He cites mood.site, a moodboarding project he built early on with ChatGPT in roughly 20 hours. Game work, he says, kept falling over.

His explanation is that games hold a lot of content that is not code, and that content is opaque to an LLM. He also guesses that far less open-source game code exists for models to learn from, and he labels that guess as his own bias and speculation.

He links the wave of one-shot Three.js games to an "everything is code" approach: boxy primitives stand in for assets, so the model can reason about all of it. He adds that much of that output lacks an authorial voice.

He frames the fix as a context problem. In a session, every earlier message is resent with each new one, so bad context early on keeps shaping later work. He points to Drew Breunig's How Long Contexts Fail, which names four failure modes: context poisoning, distraction, confusion and clash. Breunig argues that managing context is key to agents that work.

Step 1: Create one seeded source of randomness

This is the cheapest step, and the author says it gets very hard to retrofit late in a project.

1. At game start, create a single seeded random generator.
2. Route every non-deterministic call (spawns, loot, AI choices, procedural layout) through it.
3. Store the seed so any run can be repeated.

Kukshtel's reasoning: if your code calls a random function in 30 places, the 30th call returns the same value every time. An agent iterating on a fix can then reach the same state from scratch repeatedly, without fighting failures to reproduce the state.

Step 2: Make screenshots useful with layer toggles and image diffs

Kukshtel notes that most engines have a built-in screenshot API. He recommends adding toggles for UI layers, gameplay layers and so on, so the agent can look at one layer at a time. If you are fixing a UI style, for example, hide the gameplay underneath.

He then warns against the obvious next step. Handing a model raw before/after screenshots, even a vision-capable one, can leave it unsure what changed and whether it moved closer to the goal. He calls this noise a form of context rot: everything in the frame you did not ask about is processed alongside your request.

His fix is to diff the images and crop them to the area that matters. He recommends odiff, a free command-line image-diffing tool. According to Kukshtel, odiff can output a diff image and a similarity value, such as "85% similar". The agent can read that number each turn as a stable measure of progress.

The odiff GitHub page describes the project as a fast, SIMD-first image comparison library with a Node.js API. Its documented options include a colour-difference threshold from 0 to 1 and an antialiasing option that leaves antialiased pixels out of the diff. Both matter for game frames, where minor rendering noise could otherwise count as change.

A practical setup, following the author's description:

1. Capture a target image (a mockup or a reference frame) at a known seeded state.
2. After each agent change, reload that state, hide unrelated layers and take a screenshot.
3. Crop both images to the region under work.
4. Run odiff and give the agent the similarity figure and diff image, not the two raw frames.

The caveat: Kukshtel gives no measurements of how much diffing improves results. Treat this as his reported practice, not a benchmarked method.

Step 3: Build save/load on day one, around one object type

Kukshtel's test for deterministic state is simple: how easily can you save and load an exact state? He argues that save/load is often put off to the end, and that this is a serious mistake. Build it at the start and develop alongside it.

His approach to making that easy is what he calls Thing-driven development. Instead of a class hierarchy, everything in the game is one struct with a type enum, some stat values and an isAlive flag. His example: a tree and a dog are both compositions of mesh, collider and so on. Movement is not a "dog" property, so in code terms they are the same kind of thing.

A minimal sketch of the shape he describes (illustrative, not his code):

enum ThingType { Tree, Dog, Player, Pickup }

struct Thing {
    public ThingType Type;
    public bool IsAlive;
    public float Health;
    public float Speed;
    // mesh, collider and other components as plain fields or indices
}

The benefits he reports:

• One source of truth. With 100 classes, an agent has to understand all of them and their relationships, which fills context. With one type, it does not have to choose between extending a class, changing a type or adding a new one.
• One serialization path. Saving and loading go through a single shape, which avoids polymorphic deserialization problems.

He points to the Wookash podcast episodes with the creators of Dreams for a similar system, and says the memory cost is smaller than people expect.

The trade-off. This is a heavy architectural choice made partly for agent legibility. It suits a new, code-first project and looks hard to retrofit. Engine workflows built around scenes, nodes or prefabs, such as those in Godot, Unity or Unreal, may not map onto a single fat struct neatly. The source does not address that tension, so weigh it before rewriting an existing project.

Step 4: Route changes through serializable commands

Kukshtel recommends the command pattern, citing the book Game Programming Patterns. Every change to game state becomes a serializable command object, and a single handler processes them all.

What that buys you, according to the author:

1. Replayable bugs. A bug can be reproduced from the start state plus the command log, by a human or by an agent.
2. No-recompile iteration. Commands can be written in a text editor, or by the AI, and played into a running game without recompiling.
3. A tighter agent loop. He argues that removing compile time from each iteration shortens the loop the agent runs.

Combined with Step 1's seed and Step 3's save format, this gives the agent a reliable way to reach a state, change it and check the result.

How does the full loop work, and what is still unverified?

Put together, the loop Kukshtel describes looks like this:

1. Load a known seeded save state.
2. Apply a command log (or a new command the agent wrote).
3. Toggle off unrelated layers and take a screenshot.
4. Crop and diff against the target with odiff.
5. Read the similarity score; make the smallest change that improves it.
6. Repeat from step 1.

He stresses minimal changes that can be verified quickly, on a stable, "boring" baseline, so new work does not pile up technical debt.

What the source does not give you:

• No engine-specific walkthrough for Unity, Unreal or Godot.
• No token, cost or time figures.
• No failure rates or before/after comparisons.
• Nothing on Claude Code configuration itself.

The article continues into a data management section and beyond, which this guide does not cover. Check the live post for the rest.

Verdict, based on the sources: this checklist suits solo developers starting a new, code-heavy project who can shape the architecture from the first commit. Steps 1, 2 and 4 look adaptable to most projects. Step 3 is the costly one. For games dominated by scenes, art and editor-authored content, the source offers few direct answers. For other angles on agent-built games, see the Claude-built 3D Terraria rebuild and more in coding agents.