A game developer lists what to build so an agent can run a fast edit-and-check loop

Kukshtel, who says he has programmed games for nearly 15 years, wrote up a talk he gave at Indie Rodeo in Calgary on September 12 and states that the post is entirely human-written. His argument is that agents fail on games because much of a game is not code, so the fix is to make the game addressable. He lists concrete steps: one seeded source of randomness so any state can be reproduced; saving and loading from the start of the project; a single object type for everything in the game; serializable commands that an agent or a text file can replay against a running build; static data kept outside the code so values change without recompiling; and a simulation core in its own library that takes commands and returns state.

Two of his points are specific enough to try. He argues that handing a model before and after screenshots adds noise, and suggests the free odiff tool, which produces a diff image and a similarity figure ("85% similar") the agent can track from turn to turn. For performance he prefers samply, because it can dump profiles as text an agent can read. His line on the goal is "The tighter you can make the agentic loops, the better!"

He reports no measurements. The claims that screenshot pairs confuse models and that a full loop can run "in seconds" are his own assertions. His postscript says he is shipping a small project that used none of this, and that the approach is aimed at larger games.

Why it matters: For anyone building agent loops around software that is not mostly text, the post gives a short checklist of what to expose: reproducible state, a numeric progress signal, replayable commands and text-readable profiles. Treat it as one experienced developer's practice, not tested guidance.