Devlog #2: a prototype in one evening, a Godot 4.7 facepalm, and why the bottleneck isn't code

Last time I made a solemn announcement: next post, a playable prototype built over a single weekend. I want to close that loop right away — the prototype exists, it runs, and you can actually click things in it. Now the uncomfortable part: I didn't build it over a weekend. I built it in one evening.

I know how that sounds right after a post where I swore to be honest about timelines and stop bragging about "over a weekend." But this isn't the kind of bragging you're thinking of — stick around, there's a facepalm coming up that balances the scales.

What actually happened

Seven commits, all on July 13, 2026, between 14:45 and 20:17. That's roughly five and a half hours of active work, squeezed into a single calendar day instead of the planned weekend. The result: 1,329 lines of code in a Godot project.

I didn't write it. Or rather, I didn't type it — I wrote one big prompt, and Claude Code produced the code. My job that evening was architect and tester, not author of lines. More on that below, because that's where the real insight of the evening is buried.

What the demo actually does (in human terms)

If you're not a programmer and don't want to dig into ticks and seeds, here's what you'd see if you opened the prototype:

• - A hero (a blue square) walks the loop on his own — you can't move him directly, that's a feature, not a bug
• - When he reaches a skeleton, an auto-battle kicks off: an exchange of hits, a win or a death
• - You can place three tile types on the map: a graveyard (spawns skeletons), a grove (generates a resource essence), and a bonfire (buffs the hero when he's next to it)
• - A HUD up top shows hero HP, loop count, resources, and XP
• - There's pause and speed-up x1/x2/x3 — you can watch slowly or skip through the boring parts

Visually it's colored squares. No art — deliberately, so the evening went into logic instead of a sprite sheet.

For the engineers: why this isn't a flex, it's a foundation

Here's the part that matters if you write code for a living. Before Claude Code wrote a single line, the repo already had four markdown files: CLAUDE.md, design.md, roadmap.md, and agents.md. Not documentation for its own sake — it's the context the agent reads before every task. The design doc pins down what tiles and runes are supposed to do; the roadmap says we're at the "vertical slice, not a full game" stage right now; agents.md describes the other agents that will show up in this project later — a balance simulator, an auto-playtester — and the code needs to already be shaped to accept them. The markdown base works like a spec that never goes stale, because the agent checks it every single time instead of holding an outdated version in its head.

That's what drives a concrete architectural decision, nailed down in design.md: a deterministic tick core (a fixed 10 ticks per second) plus a single seeded random generator for the entire run. This isn't premature optimization — it's literally the thing that makes agents.md make sense at all. If combat math depends on rendering or on "real" time, a future balance-simulator agent can't run a thousand headless auto-battles and get comparable numbers. So even the prototype ships with a test: a hundred battles with the same seed produce bit-for-bit identical results. A green test here isn't a checkbox for the report — it's proof the foundation under the future balancing agent hasn't shifted.

Honest part: what went wrong

And now the facepalm that's the actual reason to read this post instead of scrolling straight to the metrics at the bottom.

Everything was written against Godot 4.3+, as advertised from day one. My machine runs Godot 4.7. When I finally opened the project in the real editor (not just eyeballed the code — yes, I did that first, an old habit from the web, where you can mostly trust the logs), it turned out one of my data types was named TileData — which, it turns out, is the name of a built-in engine class. There was no compile error right away, just a silent name collision that only surfaced at runtime. I had to rename TileData to TileDef across the project and fix the seeded RNG along the way, which had been misbehaving because of the same collision.

The separate commit, fix: working launch on Godot 4.7, is exactly the work that was impossible to do by staring at code. It could only be done by actually running the game.

The insight of the evening

Here's the thing. Writing 1,329 lines of working GDScript took the model, essentially, a fraction of that evening. The bottleneck turned out not to be code generation — it was the decisions only a human with a running Godot window can make: open the editor, hit F5, notice something's off, figure out why. The engineer-plus-agent pairing doesn't bottleneck on how fast lines get written — it bottlenecks on how fast and how well you verify them. How quickly I, as the human staring at the actual screen, notice the gap between "the code looks correct" and "the code actually works."

That's exactly what I wrote about in the first post regarding the future balancing agent: the agent proposes, the pipeline verifies, the human approves. Turns out "the pipeline verifies" isn't an abstraction reserved for stage 2 — it was literally what I spent the whole evening doing with my own hands.

What's next

Per roadmap.md, the gate for stage 1 is playing 5 runs myself and honestly asking whether this is actually fun, or just technically functional. I haven't hit five yet — I'll get there this week — and if it's boring by run five, I iterate here instead of pushing forward on the plan.

If the gate passes, stage 2 is next: elements (a 4×4 matrix — fire, water, earth, air) and runes — the League of Legends-style rune-page system that's supposed to turn run prep into its own little game. Expect a report on whether balance breaks immediately, exactly as promised in post one.

Subscribe

If you want to watch this keep breaking and getting fixed, subscribe to the devlog. Next post is either about elements and runes, or about discovering a second name collision with the engine, because life isn't fair.

#agenticGameDev

---

Metrics (honest, straight from git log)

• - Commits: 7
• - Calendar days: 1 (July 13, 2026)
• - Active time: ~5.5 hours (first commit 14:45, last commit 20:17)
• - Codebase size: 1,329 lines (all tracked project code)
• - Reproducibility test: green, 100/100 battles identical with the same seed