[HN Gopher] Show HN: Claude Code skills that build complete Godo...
___________________________________________________________________
Show HN: Claude Code skills that build complete Godot games
I've been working on this for about a year through four major
rewrites. Godogen is a pipeline that takes a text prompt, designs
the architecture, generates 2D/3D assets, writes the GDScript, and
tests it visually. The output is a complete, playable Godot 4
project. Getting LLMs to reliably generate functional games
required solving three specific engineering bottlenecks: 1. The
Training Data Scarcity: LLMs barely know GDScript. It has ~850
classes and a Python-like syntax that will happily let a model
hallucinate Python idioms that fail to compile. To fix this, I
built a custom reference system: a hand-written language spec, full
API docs converted from Godot's XML source, and a quirks database
for engine behaviors you can't learn from docs alone. Because 850
classes blow up the context window, the agent lazy-loads only the
specific APIs it needs at runtime. 2. The Build-Time vs. Runtime
State: Scenes are generated by headless scripts that build the node
graph in memory and serialize it to .tscn files. This avoids the
fragility of hand-editing Godot's serialization format. But it
means certain engine features (like `@onready` or signal
connections) aren't available at build time--they only exist when
the game actually runs. Teaching the model which APIs are available
at which phase -- and that every node needs its owner set correctly
or it silently vanishes on save -- took careful prompting but paid
off. 3. The Evaluation Loop: A coding agent is inherently biased
toward its own output. To stop it from cheating, a separate Gemini
Flash agent acts as visual QA. It sees only the rendered
screenshots from the running engine--no code--and compares them
against a generated reference image. It catches the visual bugs
text analysis misses: z-fighting, floating objects, physics
explosions, and grid-like placements that should be organic.
Architecturally, it runs as two Claude Code skills: an orchestrator
that plans the pipeline, and a task executor that implements each
piece in a `context: fork` window so mistakes and state don't
accumulate. Everything is open source:
https://github.com/htdt/godogen Demo video (real games, not
cherry-picked screenshots): https://youtu.be/eUz19GROIpY Blog post
with the full story (all the wrong turns) coming soon. Happy to
answer questions.
Author : htdt
Score : 114 points
Date : 2026-03-16 16:07 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| RomanPushkin wrote:
| Upvoting this! And thanks!
| bhu8 wrote:
| Great work but why not use C# instead of GDScript?
|
| LLMs are really good at C# (and tscn files for some reason), so
| that solves the "LLMs suck at GDScript" problem. Also, C# can be
| cheaper in terms of token usage (even accounting for not having
| to load the additional APIs): one agent writes the interfaces,
| another one fills in the details.
|
| Saying this because I had really enjoyed vibecoding a Godot game
| in C# - and it was REALLY painful to vibecode with GDScript.
| htdt wrote:
| 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.
| andai wrote:
| 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!
| saint_yossarian wrote:
| GDScript has static type hints now, it's still a bit basic
| but continually getting better.
| pragmatic wrote:
| I don't think the web output works with c# currently.
|
| Be happy to find out I'm wrong.
| andai wrote:
| I think it worked in the previous version.
|
| The way unity solves this is with some kind of proprietary
| compiler. They translate the C# into C++, and then compile
| that into webassembly.
|
| Whereas others (incl. Godot) need to ship the .NET runtime in
| the browser. (A VM in a VM.)
|
| It makes me sad that Unity doesn't open source that. That
| would be amazing.
| empiricus wrote:
| c# to webasm - should be 2 weeks of llm work :)
| lemming wrote:
| This actually produces more impressive results than I expected.
| My understanding was that models are quite poor at spatial
| reasoning/understanding, so I'm surprised it can generate such
| good assets. Do you use different models for the 3d generation?
| tyleo wrote:
| What is the development loop like with this? There's a lot of
| folks successfully building games with agents already on the AI
| gamedev Discord server. So I'm wondering if there were some
| shorter paths to your goal. You might want to exchange notes with
| folks there.
| chaosprint wrote:
| Interesting. But if you claim "prompt in Godot game out", how do
| you deal with assets? I think assets pipeline is one of the most
| challenging parts in game dev. Is there anything similar but for
| Bevy?
| htdt wrote:
| 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.
| tayo42 wrote:
| What handles making sprite sheets?
| htdt wrote:
| Gemini with some tricks for grid alignment and background
| removal. Not perfect yet, planning to switch to a video
| model for animated sprites.
| tayo42 wrote:
| Are they not animated?
| htdt wrote:
| 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.
| vblanco wrote:
| There is not much need for this. I already use claude code with
| godot to build serious projects, and you only need to point the
| bot at godot + sourcecode folder, and use C#, then it works like
| a charm.
|
| Nice set of prompts and skills tho, im grabbing them for personal
| use.
| tpxl wrote:
| Can you expand on how you do this? I've gotten into gamedev a
| couple of times, but never got around to completing anything.
| Something like this might just do the trick.
| vblanco wrote:
| First of all, you dont do one prompt to do the entire game,
| but "decent" style vibecoding where you do things little by
| little controlling the bot.
|
| Godot whole engine is text based. This means you can just let
| claude rip through the assets and files just fine. It
| basically just works.
|
| The thing that is critical is to make some documentation
| about the axis systems and core classes (the one on OP
| project is pretty good, ive grabbed it) and then you set your
| claude.md to point at the godot source code so that the bot
| can doublecheck things.
|
| Ive been playing with multiple engines, and godot is by far
| the best one to use with the AI. Unreal engine is too heavy
| on binary files that coding tools cant parse, and Unity is
| closed source which leaves the bot with no reliable
| documentation or way to check what the game apis are doing.
| Godot is small enough that the bot can understand it and
| works fine for games that arent too complicated.
|
| Im using it to build a spiritual remake of daggerfall as a
| procedural open world rpg, right now its at 60.000 lines of
| code, quite advanced. I got it running on a steamdeck at 60
| fps even with 4 kilometers of draw distance with thousands of
| trees and procedural terrain thanks to doing tons of custom
| shaders and a few engine edits.
| mattfrommars wrote:
| incredible. And this was all using $20 plan from Claude or
| do you pay extra for Claude bandwidth?
| vblanco wrote:
| I use the 100 plan, the 20 dollar plan is more of a
| trial, you run out of that in no time. With the 100 model
| i use it both for work (graphics rendering) and this
| which i do part time. Ive captured a few screenshots here
| <https://imgur.com/a/RJIcKqM> .
| hmokiguess wrote:
| I saw the demo video, in all honesty, they felt really lifeless
| to me. The snowboard one was the one that most caught my
| attention but then the mechanics, and movements of the character,
| made it seem like it's really bad physics. Do you have a
| published game I could try rather than these demos? I'm curious
| htdt wrote:
| 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.
| bgirard wrote:
| 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.
| lexicality wrote:
| 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.
| andreagrandi wrote:
| Context: I've been using agents (both Claude Code and Codex) for
| my daily work and for personal projects, but always in domains
| where I had some knowledge and I'm currently happy with them.
|
| I tried using Claude Code to build an RPG game with Godot and
| GDScript, using free to use assets: a total failure :/
|
| The game was supposed to be many implementation steps long but I
| asked Claude to first produce a one area demo, so I could test
| the assets and choose the one I liked. First it produced some
| garbage using the assets randomly. Then it tried to copy from an
| existing demo but it had not idea where a door or a path were and
| at a certain point it even admitted it with something like: "I
| can't design an usable and nice area: I either make it functional
| and ugly or I copy and adapt the existing demo but I will have no
| clue about what is what"
|
| I've never even attempted to develop games before so I'm sure I
| don't even know the basic concepts, but this use case definitely
| didn't work for me.
|
| Maybe it could generate the code of the game if I provided the
| full design?
| htdt wrote:
| 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.
| dr_kiszonka wrote:
| 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.
| guitarlimeo wrote:
| Nice work, must have been a pain to get Godot's formats working
| with Claude. As another commenter suggested the demo videos don't
| do any justice to this project - yeah it's the magic that you can
| generate playable (wouldn't say complete myself) games with a
| single prompt, but the quality of those is exactly why people are
| so put off by AI slop. If this was a better harness that acted
| more like a tool I think it would be seen as more useful.
|
| Btw: Have you looked at Tripo3D models' topology? Is it still so
| bad that if you want to make small edits you have to retopologize
| the whole thing first?
|
| FWIW as a disclaimer I'm making my own game not using AI since I
| value learning the skills myself, but I am interested to see how
| fast AI tools adopt to gamedev. For now they've been more of a
| false shortcut in anything else than prototyping and semantic
| search ("I need to achieve this visual effect, what algorithms
| should I look up").
| twelvevaginas wrote:
| "Real games" the most incomplete bullshit you ever saw passed off
| as a game.
|
| The starting points of Three.js examples are more of a game than
| anything here.
|
| Stop saying AI is building games when it can't even build a
| standard web page to match a mockup.
| htdt wrote:
| 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.
| mattfrommars wrote:
| This is incredible piece of work. I was looking into .claude
| folder and skim reading it. One thing stood out to me how large
| it is.
|
| If I'm not mistake how Claude Code or AI agent work, they need
| everything in 'context' and few tricks to reduce the context
| size. Sure, but given the number of files you have, how much of
| the context is consumed by all those claude files vs actual user
| input?
| parasti wrote:
| This is entirely based on the "agent skills" system. LLM agent
| only sees the one-line skill description in its context and
| "lazy loads" the rest of the skill file on demand.
| jwelten wrote:
| The lazy loading approach is smart. We've been publishing
| agent skills too and the context budget is a real constraint;
| six skills with reference docs would blow past 30k tokens if
| loaded eagerly.
|
| Filtering at load time based on what the agent actually needs
| makes a huge difference. Curious if the orchestrator/executor
| split causes issues with state handoff between the two
| context forks.
| rybosworld wrote:
| I think this is a cool tech demo. But the commonality I see in
| all of these "let the agent run free" harnesses is that the
| output is never something I would want to use/watch/play.
|
| I think minimizing the amount of human effort in the loop is the
| wrong optimization, and it's the reason we end up with "slop".
|
| It's the dream of a lot of people to have a magic box that makes
| you things you can sell, or enjoy for personal leisure. But LLMs
| are not the magic box. And there may not ever be a magic box. The
| sooner we can accept that the magic box isn't in the room with
| us, then the sooner we can start getting real utility out of
| LLMs.
|
| TLDR: Human taste is more important than building things for the
| sake of building them.
| avaer wrote:
| How does this stack up against something like Tesana [1], which
| is also Godot based? Would it be accurate to say that it's like
| "Tesana but local"?
|
| [1] https://tesana.ai/
| samiv wrote:
| A minute of silence to mourn the lost art of making games with
| passion.
|
| Let there be games! And games there shall be, millions of
| generated games.
|
| Can I go back to the 80's please?
| krapp wrote:
| >A minute of silence to mourn the lost art of making games with
| passion.
|
| There are still... dozens of us left!
| htdt wrote:
| 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
| krapp wrote:
| The problem is your passion is for the LLM workflow and not
| the games, and the end result is going to be a powerful way
| to generate mediocre games.
| hardaker wrote:
| This. I've been making a game in Godot with zero AI help.
| Because I enjoy it. I enjoy solving with weird coding problems
| you run into. I enjoy leaning as I fixed things. I do it out of
| love for the process, knowing competition right now from things
| like this means a flooded market. But I'm ok with that and must
| be because the other option is to quit.
| tayo42 wrote:
| A prompt like "make it more fun" will never work. What's the
| line for an authentic enough game?
| colechristensen wrote:
| Why does what other people do affect you?
|
| If you want to handcraft something, do it. How popular it is
| among other people isn't relevant.
| spwa4 wrote:
| Because you use steam and the play store and ... to get
| games, and there will be so overwhelmingly much slop you
| can't find anything.
|
| I've switched to emulators, a bluetooth controller and zero
| android games (and zero ios games on my work phone). But yeah
| it was/is horribly enshittified already. And what people
| predicted did happen.
|
| The fact that the app store allows updates means existing
| games get systematically worse. Even the games I used to
| enjoy, and bought 5 years ago, like collossatron now have ads
| after every play.
| skeeter2020 wrote:
| This comment screams someone who wasn't around during the
| rise and fall of Atari 2600 games or Commodore 64 games. More
| was certainly not better back then either.
| WillPostForFood wrote:
| There are literally 1000x more games being released today*
| than during the best days of the Atari/C64, and it is
| great. More has been better.
|
| *Atari 1980 (20 games) vs Steam 2025 (20,008 games)
| i_cannot_hack wrote:
| It becomes a problem for everone when spaces meant for
| meaningful work become overrun with an awful stream of
| endless mediocre slop that someone quickly generated without
| giving it a second thought. The problem here is not that it
| is fast and easy. The cardinal sin is that it is fast, easy
| AND bad.
| sbarre wrote:
| Huge gatekeeping energy right here.
| hoppp wrote:
| No more code, only markdown files...
| beernet wrote:
| Coding is not dead. No one stops you guys and nobody intends
| to.
|
| I like the knittling analogy that was made by the OpenClaw
| inventor recently. Programming will continue to exist as a
| hobby, not as a profession.
| runarberg wrote:
| knitting machines don't generate the design from a prompt,
| and neither does industrial knitwear production facilities.
| In fact, knitting machines have quite a lot of manual input
| that goes into the final product, including careful
| programming.
| pipes wrote:
| I heard him say that too. And he's probably right. But it's
| more like every knitter now has access to an automated loom.
|
| Oddly I feel AI is getting me off the endless learn new tech
| churn. I was looking at a few odd ball programming books on
| my shelf, graphics programming from scratch and retro game
| dev (c64 edition and nes editions) and thinking I might now
| have time to work through these instead of learning
| technology x.
|
| https://www.retrogamedev.com/
|
| https://gabrielgambetta.com/computer-graphics-from-scratch/
|
| And I'll be manually coding as I want to learn!
| ytoawwhra92 wrote:
| Personally, most of the time I spend prototyping is taken up by
| wrestling with tools, engines, and assets. Then I discover that
| my game design just isn't very fun. I've been experimenting
| with using LLMs to speed up building prototypes because I want
| to spend a higher percentage of my time adjusting game design
| and feel rather than solving problems that are irrelevant if
| the game's not fun to play.
| galleywest200 wrote:
| If you took the time to throughly learn an engine, would you
| spend so much time wrestling with it afterwards?
| petcat wrote:
| I don't do web dev, so anytime I thought about making a web
| app, I always shudder at the thought of having to spend most
| of my time learning about tool chains and ecosystems and
| build tools and all of the stuff that goes into _making code
| build_ , before even making code do what I want.
|
| And then I realized that I can just tell an llm to scaffold a
| project and give me a justfile with three or four commands
| that I run to do the things that I need to do so that I can
| write some code and see it working.
|
| The JavaScript ecosystem especially is much more enjoyable
| when you don't have to internalize every possible build tool
| and ecosystem pattern in order to just see something work.
|
| To be honest, I've actually even just given up on all of it.
| I just write plain HTML files in a folder with JavaScript
| files and CSS files and bootstrap and jQuery and maybe some
| HTMX.
| SchemaLoad wrote:
| Curation is probably going to be king over the next years. A
| game simply existing is no guarantee that any effort has been
| put in or that even the developer played it.
|
| You'll need to find a publisher, journalists, etc to market
| your game. You'll ask your friends what they are playing
| instead of scrolling the store page. Trusted platforms will
| promote games that are actually worth looking at. This problem
| already exists on modern platforms like Steam but AI is
| supercharging it.
| captainbland wrote:
| We've all seen shovelware, now introducing excavatorware. A
| single shovelware studio is now empowered to deliver on the
| order of kilogames per month.
| slopinthebag wrote:
| Everything about this feels like AI slop, including the post
| which is very clearly AI written. I'm sorry but if you aren't
| even willing to put any effort into writing a post showcasing
| what you have worked on what is the point of anybody taking a
| serious look? And the tools are clearly AI generated as well, I
| can even tell where you used Gemini in some places because you
| left in it's distinctive comments. Not to mention the showcase
| games are meme-tier.
|
| I feel like this could be a real positive thing if you had spent
| some effort writing about how and why this is useful, and
| targeted this more for learning + artist assistance versus just
| generating a complete game. Gamers universally do not want more
| AI slop, but tools that artists and programmers could use to
| automate busywork or learn the engine would have been much
| better.
| stephc_int13 wrote:
| Gamedev here.
|
| I looked at the video, awful results, better start with a
| template.
| empressplay wrote:
| Yeah exactly, build a library of a hundred or so stock game
| templates and just let the model configure / modify them as
| needed. Would cover most use cases.
| Closi wrote:
| I wouldn't feel that smug considering these are single prompt
| generations on a pretty small project.
|
| As Two Minute Paper's always says, it's not just about what
| this looks like at the moment, it's about what this might look
| like another three breakthroughs down the line.
|
| While you can't guarantee further breakthroughs, at the rate of
| advancement and pace of improvement, you would have to be brave
| to bet on no further breakthroughs.
| c0m47053 wrote:
| Very interesting. Have to admit, I assumed Godot was just out of
| the realm of agentic dev. I decided to actually build a game a
| few months ago, and went with Raylib (with C#), and it worked out
| pretty well (https://github.com/alexwlsnr/neo-arena)
|
| I had assumed with the complex mix of scripts and the scene graph
| in Godot wouldn't be a good fit (personally trying and failing to
| make games in it by hand in the past may have been a factor)
|
| Perhaps I'll give this approach a go if inspiration strikes!
| fxwin wrote:
| fyi that link is dead, maybe the repo is set to private?
___________________________________________________________________
(page generated 2026-03-16 23:00 UTC)