htdt

The two-tier loading is exactly that — ~128 common classes always visible as one-liners, full docs loaded on demand. The agent does sometimes pull the wrong class, but since each task runs in a forked context, a bad lookup doesn't cascade beyond that task. Gemini Flash for QA was a capability choice — it's able to catch spatial issues like z-fighting and clipping, which is not obvious since vision models aren't typically trained on broken game screenshots. Turned out to work surprisingly well.

Give it a couple of model upgrades :)

On 3D from primitives — I think that hits a wall fast once you need anything organic. If you don't want a private API, TRELLIS 2 is worth a look — I experimented with it and the quality is surprisingly good.

Thanks! Good point on unit testing — I haven't gone in that direction yet honestly. The current approach is selective: the decomposer identifies genuinely hard elements (custom physics, procedural generation) and those get dedicated testing. Routine stuff like movement or UI doesn't, since the visual QA already catches most breakage there. Haven't hit real problems with code correctness so far, but I could see unit tests becoming more relevant as projects scale up. Worth experimenting with.

The LLM costs are hard to pin down exactly since I run it on a Claude Max subscription, but based on token usage I'd estimate it's in the low single digits — probably around $1–3 for a full game generation run if you were paying API rates.

The asset generation costs are tracked precisely. The current cost table: images are 5–15 cents depending on resolution (7 cents at 1K default, 10 cents at 2K, 15 cents at 4K). 3D models via Tripo3D run 30–60 cents depending on quality tier (a full 3D asset including the reference image is 37 cents at medium). Visual QA (Gemini Flash) is essentially free at this scale.

A typical game needs maybe 10–20 images and a handful of 3D models, so total asset costs usually land under $3. For something like the snowboarding game, you're looking at roughly $5–8 all-in — closer to your $5 bucket than $50. And image gen costs are dropping fast, Grok Imagine is 2 cents per image now, which is on the migration roadmap.

They are for 2D — classic animated sprite sheets with numbered frames. 3D models are static for now. The video model switch should help with smoother 2D animation between frames.

Gemini with some tricks for grid alignment and background removal. Not perfect yet, planning to switch to a video model for animated sprites.

Fair enough on the writing, I do use LLMs heavily, including for writing. That's what made a solo project of this scope possible at all alongside a full-time job. The generated skill files aren't meant to be human-readable, they're machine instructions. On the 'tool vs generator' framing — I think both matter. Assisted tooling is the obvious win, but full autonomy unlocks different use cases entirely. Curious where we'll end up.

Bold of you to assume I'm not making this with passion, I've been yelling at LLMs for a year straight, that's basically the 80s experience with better coffee

That was actually my starting point — generating Three.js output that looked okay-ish but broke the moment you touched anything. Godot gives you a real engine with physics, scene trees, which is why the output is more robust even if it's far from polished.

That's exactly the failure mode this project exists to solve. The core issue is Claude Code has no way to see what it's producing — code compiles fine but assets are floating, paths lead nowhere, layouts are garbage. It even told you as much.

Godogen closes that loop: after writing code, it captures screenshots from the running engine and a vision model evaluates them. That's the difference between "compiles but broken" and "actually playable."

And yes — providing design docs helps a lot. The pipeline generates those automatically (visual reference, architecture, task plan), but you can provide your own and customize the skills to match your vision.

Assets are a big chunk of the pipeline — generates 2D art with Gemini, converts to 3D via Tripo3D, handles sprite sheets and background removal. Animation is the main remaining gap.

Haven't looked into Bevy but will check it out, thanks.

Fair point, these demos are essentially raw single-run output, not cherry-picked or polished. The goal was showing the pipeline works end-to-end, not producing a finished game.

I'm planning to do a proper full game with more iteration and publish it as a playable build, not just a video. That should give a much better sense of actual quality ceiling.

Good point, I haven't tried C# yet and will after this comment.

The original reasoning: GDScript is the default path in Godot, nearly all docs and community examples use it, and the engine integration is tighter (signals, exports, scene tree). C# still has some gaps — no web export, no GDExtension bindings.

But you're right that from the LLM side, C# flips the core problem. Strong training data, static typing for better compiler feedback, interfaces for clean architecture. The context window savings from not loading a custom language spec could be significant.

Main thing I'd want to test is whether headless scene building — the core of the pipeline — works as smoothly in C#. Going to experiment with this.

Thank you! In my case each note is quite long (about 1 page), so total number of them is only about 20, folders are not needed. Also there is a quick search by typing title. But in general it's a great idea, I will look into it.