How to use Claude to build a deterministic loop game
Claude Code built a seeded Godot loop prototype. Actual editor testing caught a built-in type collision; game-feel review and balancing work remained ahead.
kirsantov.com
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
Build this Godot vertical slice from the design files using a fixed simulation tick and a single seeded RNG. Test repeated same-seed battles, then run the actual installed editor to catch built-in type-name collisions. Keep art simple and leave game-feel acceptance to my repeated play sessions.
Reach people exploring AI agents
See placements →Evidence at a glance
Sourced account- Source author
- Kirsantov
- Original account
- Read the source ↗
- Published
- Source link checked
- Reported result
- A working loop prototype included repeatable same-seed battles after a real-editor type-collision fix. Human assessment of repeated-run fun remained a later gate.
- Human involvement
- Kirsantov wrote design constraints, opened the actual Godot editor, tested the prototype and corrected a built-in class-name collision.
A linked account supports attribution. It does not mean we independently reproduced its result.
Report an issue with this case
Open correction emailOpens your email app with the case link included. Nothing is sent automatically.
How the agent did it
- Kirsantov supplied design documents requiring a fixed tick core and seeded randomness.
- Claude implemented the loop, tile effects, battles and reproducibility check.
- The developer ran Godot and fixed a TileData naming collision before accepting the working launch.
Kirsantov used Claude Code to produce a Godot prototype in which a hero walks a loop automatically while the player places tiles. Graveyards spawned enemies, groves generated resources and bonfires buffed the hero, with auto-battles, a HUD and speed controls making the vertical slice playable.
The repository already contained design, roadmap and agent-instruction documents. A fixed tick core and one seeded random generator were explicit requirements, because future balance simulations would need comparable results independent of rendering. The prototype included a repeated same-seed battle check rather than leaving determinism as an architectural intention.
The first real editor run exposed a problem missed by looking at code: a project type called TileData collided with a Godot built-in class. Kirsantov renamed it and repaired the affected random-generator behavior. The separate launch fix came from running the actual engine, not from the code's apparent plausibility.
The result was a functioning prototype with reproducible battle behavior and deliberately simple square graphics. The developer still planned to play several complete runs before deciding whether it was fun enough to advance. Agent-written implementation had reached a technical milestone, while engine compatibility and game feel required human checks.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Developer blog · Kirsantov
Frequently asked questions
Why require seeded randomness?
Future balance simulations needed comparable outcomes independent of rendering.
What did the real editor expose?
A project TileData type collided with a Godot built-in class.
Was game feel already approved?
No. The planned repeated-run fun assessment was still ahead.
More details
About this account
Kirsantov supplied design documents requiring a fixed tick core and seeded randomness. Claude implemented the loop, tile effects, battles and reproducibility check.
Firsthand devlog opened. Runs and reproducibility are reported; the planned five-run fun assessment and future balancing agents were not yet complete. Suggested prompt written by Agents In Use; no original task prompt was published in the verified account.
Credit: Kirsantov — Developer blog
Source published
Added to Agents In Use
Source checked
Tools and topics
Claude Code · Godot · GDScript · Seeded RNG
Deterministic simulation · Runtime collision
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.