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.
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.
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
>Acting like most people made good and enjoyable games when it was handcoded is just not right.
Every good and enjoyable game made was handcoded, with art, music, dialogue and design created with intent. I have yet to see a game created with an LLM that's even worth playing, despite countless LLM enthusiasts declaring the death of art , design and programming.
A tool that takes a simple prompt and generates a game from it isn't capable of any of that, and the necessary passion is nonexistent. It's an interesting technical demo but it's useless for gamedev unless your only goal is churning out programmatic slop, which is exactly what it will be used for.
> Every good and enjoyable game made was handcoded, with art, music, dialogue and design created with intent.
I am not sure about you, but I do not know a single developer who isn't using LLMs with a passion, even if its only just cursor and auto-complete.
So, quite the opposite. Instead, literally all games are being made with AI now. I expect the same thing applies to the other professions that you brought up, if not now then soon.
>But I do not know a single developer who isn't using LLMs with a passion, even if its only just cursor and auto-complete
A passion for using LLMs, not for making games. If they had a passion for making games they would recognize how limiting LLMs actually are to the creative process. They wouldn't be making Show HN's for what amount to barely coherent tech demos. But it's very clear from having seen many such projects that the actual game doesn't matter to them.
> Instead, literally all games are being made with AI now.
That's a statement of faith. It's something you want to be true, and believe must be true. And it may prove more accurate as time goes on but it certainly isn't true now.
Patently the idea that it is a passion for using LLMs is crank, what does that even mean? People don't have passion for screwdrivers. I've developed for 20 years now. I wrote my first line of code when I was 10. My passion is for realizing my ideas in general. I liked making the fire ball move. Code was a convenient means to do that, there are increasingly more convenient means now.
The latest stack overflow survey puts AI dev usage at 84% of their respondents, increasingly your position is the faith based one.
Nothing you've written here disproves my point. If you drop the barrier to entry, which this does, of course you see more crap. It won't change the fact someone with taste and skill will make a good game with this tech. People with those qualities will make a good game with whatever tools are available. They're just tools.
I think game designers who work with a developer would be surprised to learn their skill in game design doesn't factor into the end product even though they don't code the game.
What is the 80s experience? Are you Jobs yelling at Wozniak or something? It's like people with this view are (or will be) the object lesson of a parable or something.
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.
It would be a hit, if you packaged that loop as an MCP. Opus can make really pretty 3d models even using three.js primitives but they tend to have serious issues (like facial features inside the head). Being able to have it automatically generate a set of screenshots and Gemini scrutinize them and provide structured feedback would be a time saver. Curiously, I could not get Gemini 3.1 Pro to ever generate anything even remotely passable.
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.
I think the byline "builds complete Godot games" is rubbing people up the wrong way, when really the sell here is that it helps you build Godot games with Claude Code
And it's exactly what I was trying to do manually :D
I accept the limit and say that probably doing a video game is not for me, but it's nice that a solution exists.
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.
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.
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.
Were those three games the best results you got? Only the bike one appeared to have an actual ... game to it.
The "Racing game" appeared to be a car following a set path with a freecam and there didn't seem to be any gameplay mechanics in the snowboarding one, just a physics entity wildly crashing down a hill with no consequences or score.
Can you speak to the total api costs to create one such game? Not looking for exact numbers but I'm curious if to create, say, that snowboarding game, it cost closer to $5, $50, or $500 in usage.
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.
I'd love to see the results of that. I think calling a single prompt iteration lifeless misses the point. It's like looking at a game that has had a few hours of development and saying it's bad. Games need iterations. Seeing your results as the first iteration is impressive. I can see follow-up prompts and custom tweaking get really good results!
Last summer I built a factorio-like automation game with older models and over time the game really started to take life.
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.
Don't all of these advantages also apply to humans? :)
This always puzzled me about Godot. I like Python as much as the next guy (afaik GDScript is a quite similar language), but for anything with a lot of moving parts, wouldn't you prefer to use static typing? And even simple games have a lot of moving parts!
Godot exists to be a playground for game dev aspirants, not as an engine for shipping serious games. The Community (tm) likes gdscript because it's "easier" to "get started". They are completely unconcerned with it being harder to finish.
I am not convinced that that matters. Great games have been made with Godot (Cruelty Squad) and GameMaker (Sexy Hiking), or with no engine at all (Minecraft, Cave Story).
Great games have been made with probably any tool you can think of. That doesn't mean the tool is good, or that you should choose to start making a serious game with it.
I do not agree with your unsupported claim. For example, I would bet no good games have been programmed in Haskell. As far as I am aware, no great games have been made with the Unity or Unreal engines.
Yeah people groan about GDScript but the performance code in the engine is written in c++. Since they added static typing, GDScript is perfectly adequate as a scripting language
