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
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.
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.
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.
This has always been the case. Just because someone made an album or a game or a movie it doesn't guarantee that it's worth your time even if there was effort. Low effort music can be good too, namely by musicians that are really talented. A really talented game designer may be able to make a very engaging game with little effort beyond the initial design.
If you want to test this, find yourself a record store and pick up a few LPs less than a few bucks from bands you've never heard. You might get something really great or it might be terrible.
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.
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.
If I was working on this full time the investment of learning an engine thoroughly would be worth it, I imagine. Game dev is a hobby for me, though, and what motivates me is making fun games. If I stumble across a game idea that's really fun and worth releasing to a wider audience there's nothing stopping me from building a better version of the game by hand at that point.
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.
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.
Not equally true at all. Far from it. If you have ever seen people use knitting machine you would know the amount of skill required to operate one is far beyond creating a prompt. Same is true of looms, etc.
In fact this whole analogy makes no sense, a knitting machine is far closer to a compiler in this analogy then it is to a language model. Many would argue that automatic looms were the first compilers of the industrial age, and I would agree with that argument.
Not for long, presumably. Apparently the majority of marketable skills will come from a handful of capex heavy, trillion dollar corporations and you will like it.
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.
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.
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.
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.
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.
I have been automating unity headlessly via C# editor scripts written by GPT5.4. The competence level is amazing. It can effectively do everything the GUI can do and it gets the script right on the first try ~80% of the time. I've never seen it fail given enough retries w/ feedback from stdio.
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!
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.
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.
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!
This will do poorly with the HN crowd because they can write or understand code. This is an incredible tool for TikTok/nontechnical people who don’t know anything about ai, and want to see their random idea turned into a game. Really cool!
There's understandably a lot of negativity in here, myself included. But isn't this at least good to create a "jumping off" point for building a game? The demos might be shit but using them to create a basis for an idea seems like it could remove a lot of the headaches of prototyping and early-stage burnout.
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?
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.
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?
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.
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?
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.
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.
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").
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.
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.
Anecdotal, but I have used Claude to help me write sections of games that I'm (sometimes) working on in Godot fairly recently (Opus 4.5 iirc). It's been very helpful, and it's been very easy to guide it to do this. It came up with approaches of calculating targeting and movement that I would not have thought of myself.
That being said, Claude does not structure the project in the way someone familiar with the engine would, and just like any 'real' software, if you don't guide it, the output quickly degenerates. For example, stuff that would normally, intuitively be a child item in a scene, Claude instead prefers to initialize in code for some reason. It does not seem to care about group labels, which is an extremely easy way to identify different (types of) objects that should be treated in the same way in certain cases.
The games in the video look like GameJam projects? I'm not good at Godot, and I could probably hack most of them together in a week or so. I imagine an actual game developer could put some of them together in days.
In order to have LLMs build something good with any framework, not just a game engine, you have to steer and curate the output, otherwise non-trivial projects become intractable past a certain point, and you have a mountain of bugs to sort through.
> The Training Data Scarcity: LLMs barely know GDScript.
I've not found this to be an issue. Claude does just fine when you explain what you want. I've never had it hallucinate stuff, and I've barely seen it look at docs. Granted, I've only had it write 1-2k lines of GDScript, but I've never felt like it was spouting complete nonsense.
> 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.
This is the point where I feel like this is nonsense (more than what the LLM-written prose would imply). Maybe this is my inexperience talking, but I feel there is no way that this would be better in any way over any alternative. Especially if you just lazy-load stuff at runtime. Godot already has good docs. They should certainly cover much more than whatever you need to make the games you demonstrated. What is the point of making a duplicate version of the docs, when you have the docs right there? If you really think that Claude can't handle GDScript, you can just use C#?
> 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.
Again, maybe that's my inexperience with Godot, but I have no idea what you're talking about here? When you run, you do get a different node tree (and 'state' I guess?) but where does "hand-editing Godot's serialization format" come into this? Why would you ever need to concern yourself with what Godot does to transform your code after you've written it?
> It catches the visual bugs text analysis misses: z-fighting, floating objects, physics explosions, and grid-like placements that should be organic.
Funnily enough, those are all stuff that text analysis should be better at finding. I personally use logs & actually playing the game.
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.
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.
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.
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> .
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?
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.
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.
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
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.
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.
These demos are far, far better than what I expect from one-shot-prompting. It's interesting how our expectations shifted though.
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?
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.
This has always been the case. Just because someone made an album or a game or a movie it doesn't guarantee that it's worth your time even if there was effort. Low effort music can be good too, namely by musicians that are really talented. A really talented game designer may be able to make a very engaging game with little effort beyond the initial design.
If you want to test this, find yourself a record store and pick up a few LPs less than a few bucks from bands you've never heard. You might get something really great or it might be terrible.
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.
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.
If you took the time to throughly learn an engine, would you spend so much time wrestling with it afterwards?
If I was working on this full time the investment of learning an engine thoroughly would be worth it, I imagine. Game dev is a hobby for me, though, and what motivates me is making fun games. If I stumble across a game idea that's really fun and worth releasing to a wider audience there's nothing stopping me from building a better version of the game by hand at that point.
We've all seen shovelware, now introducing excavatorware. A single shovelware studio is now empowered to deliver on the order of kilogames per month.
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.
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!
> Programming will continue to exist as a hobby, not as a profession.
How is that a good thing? Sounds insanely dystopian to me. Especially considering all the other jobs that will be affected too.
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.
> In fact, knitting machines have quite a lot of manual input that goes into the final product, including careful programming.
Equally true for today's AI coding agents
Not equally true at all. Far from it. If you have ever seen people use knitting machine you would know the amount of skill required to operate one is far beyond creating a prompt. Same is true of looms, etc.
In fact this whole analogy makes no sense, a knitting machine is far closer to a compiler in this analogy then it is to a language model. Many would argue that automatic looms were the first compilers of the industrial age, and I would agree with that argument.
Not for long, presumably. Apparently the majority of marketable skills will come from a handful of capex heavy, trillion dollar corporations and you will like it.
>A minute of silence to mourn the lost art of making games with passion.
There are still... dozens of us left!
No more code, only markdown files...
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
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.
The majority of all code written is highly mediocre. Acting like most people made good and enjoyable games when it was handcoded is just not right.
The same people who were going to make something good will still make something good, the code imo has very little to do with it.
Passion is necessary but insufficient by itself to make good things
>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.
A prompt like "make it more fun" will never work. What's the line for an authentic enough game?
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.
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.
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)
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.
Huge gatekeeping energy right here.
Do you think people complaining about online marketplaces being overrun with unscrupulous drop-shippers are "gatekeeping e-commerce" as well?
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.
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.
I have been automating unity headlessly via C# editor scripts written by GPT5.4. The competence level is amazing. It can effectively do everything the GUI can do and it gets the script right on the first try ~80% of the time. I've never seen it fail given enough retries w/ feedback from stdio.
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!
GDScript has static type hints now, it's still a bit basic but continually getting better.
I don’t think the web output works with c# currently.
Be happy to find out I’m wrong.
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.
c# to webasm - should be 2 weeks of llm work :)
Gamedev here.
I looked at the video, awful results, better start with a template.
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.
I will happily re-evaluate when on the next breakthrough, but for now, for an aspiring gamedev, this is likely a waste of time.
Models can be used more efficiently, at the moment, but you have to understand what you are doing, and not trying to one-shot anything.
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.
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!
fyi that link is dead, maybe the repo is set to private?
This will do poorly with the HN crowd because they can write or understand code. This is an incredible tool for TikTok/nontechnical people who don’t know anything about ai, and want to see their random idea turned into a game. Really cool!
There's understandably a lot of negativity in here, myself included. But isn't this at least good to create a "jumping off" point for building a game? The demos might be shit but using them to create a basis for an idea seems like it could remove a lot of the headaches of prototyping and early-stage burnout.
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?
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.
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/
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?
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.
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?
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.
What handles making sprite sheets?
Gemini with some tricks for grid alignment and background removal. Not perfect yet, planning to switch to a video model for animated sprites.
Are they not animated?
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.
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.
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").
“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.
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.
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.
Anecdotal, but I have used Claude to help me write sections of games that I'm (sometimes) working on in Godot fairly recently (Opus 4.5 iirc). It's been very helpful, and it's been very easy to guide it to do this. It came up with approaches of calculating targeting and movement that I would not have thought of myself.
That being said, Claude does not structure the project in the way someone familiar with the engine would, and just like any 'real' software, if you don't guide it, the output quickly degenerates. For example, stuff that would normally, intuitively be a child item in a scene, Claude instead prefers to initialize in code for some reason. It does not seem to care about group labels, which is an extremely easy way to identify different (types of) objects that should be treated in the same way in certain cases.
The games in the video look like GameJam projects? I'm not good at Godot, and I could probably hack most of them together in a week or so. I imagine an actual game developer could put some of them together in days.
In order to have LLMs build something good with any framework, not just a game engine, you have to steer and curate the output, otherwise non-trivial projects become intractable past a certain point, and you have a mountain of bugs to sort through.
> The Training Data Scarcity: LLMs barely know GDScript.
I've not found this to be an issue. Claude does just fine when you explain what you want. I've never had it hallucinate stuff, and I've barely seen it look at docs. Granted, I've only had it write 1-2k lines of GDScript, but I've never felt like it was spouting complete nonsense.
> 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.
This is the point where I feel like this is nonsense (more than what the LLM-written prose would imply). Maybe this is my inexperience talking, but I feel there is no way that this would be better in any way over any alternative. Especially if you just lazy-load stuff at runtime. Godot already has good docs. They should certainly cover much more than whatever you need to make the games you demonstrated. What is the point of making a duplicate version of the docs, when you have the docs right there? If you really think that Claude can't handle GDScript, you can just use C#?
> 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.
Again, maybe that's my inexperience with Godot, but I have no idea what you're talking about here? When you run, you do get a different node tree (and 'state' I guess?) but where does "hand-editing Godot's serialization format" come into this? Why would you ever need to concern yourself with what Godot does to transform your code after you've written it?
> It catches the visual bugs text analysis misses: z-fighting, floating objects, physics explosions, and grid-like placements that should be organic.
Funnily enough, those are all stuff that text analysis should be better at finding. I personally use logs & actually playing the game.
Upvoting this! And thanks!
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.
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.
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.
incredible. And this was all using $20 plan from Claude or do you pay extra for Claude bandwidth?
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> .
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?
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.
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.