I think the software engineer types in this thread misunderstand what makes game developers tick. A lot of people here do game dev as a way to explore new ways to code. My sister is an indie dev and to her, code is an unavoidable means to an end (creating a game). So many games are absolutely spaghetti on the inside because the creator is deeply uninterested in the art of code. So to that end, LLMs are actually an awesome thing to enable creators to experiment more freely.
FWIW, I’m a platform engineer who is actively mourning the loss of reliability and care given to production code. I just think games aren’t an area where this is nearly as much of an issue.
> I just think games aren’t an area where this is nearly as much of an issue.
That's news to me as a game dev. I only get a few milliseconds every frame in which all my calculations need to run. If my program is built on spaghetti code, performance suffers and it becomes very noticeable very quickly.
This doesn't just generate the code though. It generates the "art" and everything else as well. Ideas are beyond cheap. It's the personal creativity that makes games good or bad.
And saying the code doesn't matter is just ignorant. In plenty of great games the art doesn't matter. In plenty of others the code doesn't matter. Or the dialogue. But the reverse is just as true. In a game with tight, fluid player controls, the code to make that happen takes just as much creativity and skill and human touch as any other form of art. A driving sim made by someone deeply uninterested in the code they write will never feel good to play.
It is just so disingenuous to say that people who focus more on the code side of game development aren't creators. If I can make a demo with a black rectangle jumping around on some red rectangles and hand it to someone and have them say it feels like they're jumping around as a cat, with no art or animations, I'd say that took creativity and a human touch that ai is nowhere near being able to emulate.
I do think AI can emulate it - one of the earliest headlines I remember is an AI piece winning a digital art competition. The piece was great and the influence of the (human) artist was obvious.
If something is beautiful, I can't be assed to care what kind of paint was used to create it. If you trust human beings to continue to appreciate art as we have done since the beginning, there's not going to be any intractable issues.
>If you trust human beings to continue to appreciate art as we have done since the beginning, there's not going to be any intractable issues
When did the discussion become about trusting the audience? I think the discussion has always surrounded whether it's worthwhile to treat art as a problem that needs solving.
Well, if you think it's not a problem to solve then you should go tell all the paintbrush manufacturers that their services will no longer be needed. Ditto for publishers, patrons of the arts, etc., etc.
If art is worth doing it's worth doing with good tools.
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.
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.
I think the point of this is to help people into creating full, "life-full" games. A person can use this as the boilerplate base game, so that they can focus on the narrative, designs, and adding specific and quirky mechanics that make the game feel like a full game.
It helps to not have to sink most of your initial motivation energy on setting up the most basic mechanics like player movement physics from scratch and demo level templates.
For what it is, it's amazing. The only issue I would have is the manager goons who would want a commercial game then shove something like this down dev team's throats to "be faster". I can imagine getting the professional polish all through prompts would be a trying experience (especially after not knowing what the code does because it's all generated.)
Its impressive in the gimmick sense, but its not impressive in the "i want to use this tool" sense.
I use cluade code to help work in godot, but I dont try to use claude as a one shot tool anymore. I haven't gotten good results out of it and I haven't seen any good results out of it elsewhere.
I use claude the same way for all programming I do (game, web, minecraft mods). I say I want to accomplish a certain task, claude puts together a plan and explanation, I question any assumptions or things I dont understand, maybe do some research into parts that are new to me, and then either ask claude to implement the feature or I ask claude for a high-level concept and I implement it myself.
i expect the point of the skill isnt that the end games are good, but such that claude can work on any part of the godot engine to help you make a game.
i do think LLMs need a physics skill though. very consistently they are bad at writing physics related code. at least without a lot of prompting and feedback
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.
yes! you wrestle with it because the starting boilerplate is thpically a do-once operation. if you stay working on one project for a few years, you will no longer know how to start the next project, and with modern software, starting a new project in two years from now will be nothing like starting one now
I had the same issue where startup cost was a pain to get little prototypes going. I reduce the cost by making re-usable components. Even if I don't intend to reuse something I still make it a component-esque manner.
It helps that I mostly want to make certain types of games but I think everyone does. I have drop in CameraController, First Person rig, 2D inventory system, dialogue system etc. All flexible enough to get wired into the one off game manager or whatever it needs to plug into.
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.
I agree, in the current ecosystem games are abundant but it's still not easy to find the diamonds in the rough.
Trust signals are going to be quite influential going forward, and that will get exploited too. I think we're going to see the return of high effort, high trust games journalism. Not necessarily as the commercial victor, but as a community we will rally around people and outlets we trust.
The problem is finding the needle in the haystack. When you can cheaply develop AI slop by the millions, good luck finding that one game where a human put blood, sweat and tears to realize their vision/dream. Even if you somehow have access to at-scale distribution, economics will ultimately always triumph everything else and more slop will be pushed because it makes economic sense.
It will take at least a full decade for people to realize the slop isn't helping, has made us all collectively mediocre and will seek out people with real specializations. By then I sure hope those who are specializing haven't lost the motivation to do great things and moved on to other fields.
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.
It will show in your game, and I think that will also continue to translate into a better chance at success even in such a swamped market. Maybe even because it's such a swamped market, players will value the games made with passion.
I agree, taste, story and art direction will continue to cohere into successful games. Studios making high volume shallow games never had these, and they probably don't want them just because AI showed up. They are filling a specific demand in the industry.
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.
you make a good point. I lost interest around "MCP" in all this; now we're up to people not understanding map reduce and manually garbage collecting for the AI.
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.
I was never talking about a knitting machine in the first place. Rather, I was referring to the old lady sitting on her sofa, knitting a sock she could also buy for a dollar, but decides to do it herself for the love of the game and nostalgia: a hobby.
The "art" of programming is going exactly that route, maybe with a little fewer ladies and more men.
I didn’t hear the exact analogy so I made some assumption. But I fail to see any insightful analogy which could make such predictions, unless the analogy is operating on top of some flawed assumptions about industrial knitware production.
An old lady could equally sit in front of her desktop PC write some HTML, and upload a blog page with her amazing knitting projects, or she could get pintrest. This was true before LLMs, and it is still true today.
Another potential flaw is the assumption that professional knitwear design does not exist. It does. Plenty of people work in industrial scale knitwear products. We have people designing new products, making patterns and recipes, we have manual labor in the production, operating machines or even knitting by hand. Case in point, travel anywhere and go to a local market popular with tourists, and you will see plenty of mass produced knitted products, most of them took great skill to design and produce. Nothing compatible to prompting an LLM to do this for you.
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.
The OpenClaw inventor? Ok, sure. I think this is sort of cute. The idea that it is just great that all knowledge work would just be a "hobby" when that logically a world in which there would be no leisure would be quite amusing if it is wasn't so depressing.
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.
What is "passion".. for example.. I vibe coded an art display this weekend for myself for a monitor I have on my wall. I am VERY PROUD of it.. it is in GODOT coincedentally. I think it turned out well. Did I spend weeks on it? Did I even learn GODOT?.. No.. but I did spend my weekend late nights figuring out what I wanted and working with an AI to make it.
In some ways the kind of complaining I see is like complaining about a chef's meal because the chef didn't mine the ore to make his knife.
Look in the specific case of this post... none of the games are "good".. however.. one-shoting games WITH ASSETS.. seems pretty impressive to me.
Isn't this just so disingenuous? No disrespect to you, I just see this kind of sophomoric take so much in response to the very normal reaction of the OP. A year ago, it was in vogue to call the OP "ableist" or something. I think the idea that the OP's concern was like the expectation that a chef would "mine the ore" is a bit ridiculous. A better example would be someone having a painting on the wall feeling ownership in it when they asked their artist friend to paint them a picture; at least that is more reasonable. Also, passion means to struggle, since you asked, which I think follow more the idea of learning the craft. This kind of reductionism would deny that craftsmanship exists, as if sculpting David is the same as buy the finished product on the open market. I think we all know this isn't true but there is some kind of forcefield on the Internet that means we have to pretend it is.
Really well said, I hate that every time I say I value craftmanship, skill and effort in art people flock to this reductionism "well did the painter make his own dyes? Did the developer make his own processor to run the game in?"
cassettes are a bit before my time. I am personally unaware of any "shovelware" being distributed via cassette; i have heard that radio stations would broadcast programs you could record and play back (i remember Acorn in this particular story, i think.)
And floppies, sure, the 3.5" ones had some shovelware, included in trade magazines and whatnot. Maybe someone has a directory listing of a floppy from this era showing what it was like, i'd be interested; i know about AOL disks, too.
But CD-ROM. never before could humans distribute 200 games / software packages so easily. my first computer with a cd-rom had a hard disk 350MB larger than a CD-ROM. 2 shovelware CD-ROMs was more than my PC could handle!
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.
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.
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.
I understood it just fine. You object to creations and creativity that do not pass your subjective quality bar and/or aren't produced in a way that is satisfactory to the people already behind the gate.
It's the literal definition of gatekeeping.
The problem you describe (quantity over so-called quality) is a discovery and curation problem.
Yet you blame the tools of creation and lament the lack of restriction or controls on production instead.
Yes these tools make it easier to produce, and yes that means that you have more low-quality work out there. I'm not pretending like that doesn't introduce new challenges.
But the answer isn't to gate-keep the tools or the process of creation or to stop or shame people from being creative with these new tools by universally calling their work "slop" or "bad".
So you completely agree with the factual description of the problem I supplied when asked to describe the problem, your only real complaint is that I used the phrase "more awful slop" instead of your preferred euphemism "more low-quality work". Having a frank discussion about the problems caused by new technology is not gatekeeping, and I don't think we should sugarcoat it out of fear of hurting people's feelings.
> 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.
So..
"a problem for everyone" <- the fallacy of assuming your personal feelings and opinions are universal and apply to all of us (they're not and they don't).
"spaces meant for meaningful work" <- tells me that you don't seem to believe anything made with these new tools can be meaningful, implying they don't belong etc..
And again the hubris of believing that your personal opinion reflects the ideal state or voice of a broad and diverse community (a fucking textbook definition of gatekeeping btw)
And lastly, do you truly believe that AI tooling is the dividing line?
That all non-AI games made today are meaningful?
There's tons of quick and dirty stuff out there like asset flips and weekend projects that people throw up on Steam or Itch for sale, and there have been for years and years.
If your fear is that bad games are going to get out into the world you haven't been paying attention for the last (checks watch) 50+ years...
> "a problem for everyone" <- the fallacy of assuming your personal feelings and opinions are universal and apply to all of us (they're not and they don't).
The phrase "a problem for everyone" doesn't mean everyone agrees, it just means the described situation would affect everyone broadly...
And even you literally admitted you agree it will introduce problems just in the previous post: "I'm not pretending like that doesn't introduce new challenges", it's a little too late to try walk that back now.
> "spaces meant for meaningful work" <- tells me that you don't seem to believe anything made with these new tools can be meaningful, implying they don't belong etc..
No, just that the non-meaningful work they create risks overwhelming any meaningful work created with or without the tools, which is a real problem AI is already creating in online communities today. Knitting patterns on Etsy is a prime example. It is an accurate description of a problem that already exists today, and trying to avoid discussing it helps no-one.
Again, even you admit the problem is real and don't really have any real complaints except that you keep complaining about my phrasing. It seems you would have been happy if I'd just used the more polite terms you introduce instead, like "new challenges" instead of "problems", "low-quality work" instead of "awful slop", and "not low-quality" instead of "meaningful"? Which is fine, but not really an interesting discussion.
To avoid admitting you are simply annoyed with my phrasing you instead try to pin extreme opinions on me that are nothing close to anything I have ever said, like "you believe your personal opinion reflects the ideal voice of the community", "you believe your personal feelings and opinions are universal", "you believe nothing made with these new tools can be meaningful" and that I think "all non-AI games made today are meaningful", which is just silly.
Since you agree that you see the same problem I see, and just want to discuss other opinions you invent for me that I don't actually share, I don't think we will reach any conclusion here and I probably won't engage further. Thank you for your time anyway.
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.
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
As someone that's been working on a game with Claude Code in a more human-in-the-loop, iterative fashion, I have to say that OP's claim that "LLMs barely know GDScript" does not match my current experience at all even though it seems to have matched yours. Maybe it was true a while ago in both cases; how long ago was your "vibecode" attempt? I've gotten completely fine GDScript and even decent perfectly functional if placeholder-quality TSCN files from Opus 4.5, 4.6, and Sonnet 4.6 with very little issue and no special tricks; just a CLAUDE.md file, the project itself, and going through plan mode before each change. I did start from a playable project with a fair amount of hand-written scaffolding already in place, and I have no idea if that would make a difference. Every once in a while there will be some confusion that I get something appropriate for Godot 3 instead of Godot 4, but never Python despite the similarities of the language.
I agree, Claude does a great job of synthesizing Godot docs, and even of writing unit and integration tests with GUT. I have not tried any e2e testing but I’m not convinced that you couldn’t get a good result there, too, depending on the kind of game.
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.
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 agree with you, but I think it skips over the fundamental point of the demo - that this is possible at all. The door is unlocked. I expect where commercial interests will take this over the next year or two, even without further "model breakthroughs" will be enough to change how many devs engage in game development.
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.
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.
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.
I think this is pretty cool, all things considered. I think it’s unrealistic to expect anything that’s been one-shot to have much polish or charm.
Something I’m surprised about is the lack of unit testing. Agents are remarkably good at creating tests and GUT testing is pretty well developed; having some good unit tests would really assist in the subsequent steps where you polish controls, add features, etc. Without these, I think things will get off the rails pretty quickly.
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.
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!
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.
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.
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!
for what it's worth I have been building a game with godot and using gemini flash and pro to help. it has no trouble editing gd script and scenes. so far it hasn't failed in anything i asked it to do
Very cool. Thanks for sharing! This introduced me to Godot, gave me an excuse to use Claude code and a few hours later had it all installed and created my first game/simulation.
Experimenting each night with a new game idea, genre, style, etc. Really fun. Thanks again!
As a Godot user, GDScript's unique syntax often trips up standard LLMs, so your custom language reference is a game changer. Integrating Claude Code directly into the game dev pipeline like this shows where the future of 'Agentic Workflow' is heading.
The lazy-loading approach for the API reference is clever. Did you consider embedding a smaller, distilled subset of the most-used classes permanently in context, and only lazy-loading the long tail? Curious whether the overhead of deciding what to load ever causes cascading errors where the wrong API gets pulled in.
Also interested in the visual QA separation - using a model that sees only screenshots and never the code is a genuinely good idea for avoiding confirmation bias. Did you try using Claude for that role too, or was Gemini Flash specifically chosen for cost reasons?
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.
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?
A bit misleading marketing there (like always) - all the good looking game videos are actually just AI generated videos (obvious tells: HUD elements wouldn't have scrambled text if they were actual games, rendering of barrels has the worst LOD popout I've ever seen or it's AI), but the actual games are really bad.
The 2D sprites in the bike riding scene are a bit of a mess. Honestly consistent 2D animation is difficult.
You've basically got two approaches right now - use a openpose style controlnet representing a walk cycle in conjunction with img2img OR you can try using a walk LoRA with WAN to generate video and then clip out 4-8 frames that represent a good loop from the video.
Thanks for not cherry picking the output. The demos look great for a single prompt output. I can see myself playtesting a mechanic that I just thought of but would probably take longer to implement in my own WIP game etc.
I think this has great value just now, can't wait for it to get better. Keep at it.
I can't decide if this is impressive or not. At first I think it is, but also the best demos you could find were not good games, and likely not even good bases for further iteration. It seems pretty likely that this tool would increase the speed of shipping a salable game by zero minutes. So it's kind of impressive but at the same time not.
If you put in the effort to polish the scenes, mechanics, and overall feel, then with a great idea and a few iterations, you could potentially build a sellable game. I honestly do not know what it takes to sell a game, but if you have a strong idea and want to put it online, a tool like this can take you surprisingly far and let you focus on the bigger-picture parts of the game.
I think it's quite impressive without even trying it. I think more and more tools like this will pop up soon.
Well no, what I mean is I've used Godot a lot and I think it's likely that the effort to polish this output is more than the effort to start from scratch. Godot as a codebase is very easy to become horrendous spaghetti. Even though this is some form of a start, I kind of doubt it would decrease time to ship by any amount, maybe even increase time to ship, for the same reasons that greenfielding is faster and easier than incrementally refactoring a legacy clusterfuck written by juniors.
You may be right, I don't have any experience with Godot but as a noob game dev it feels to me that if I have a good clear idea (perhaps a simple one), a Claude skills pipeline would help move things faster, get to something roughly working relatively easily. From there to a polished game there's considerable effort, I'm sure. Since I've had a pretty good experience with LLMs and making Lua games my inclination is to think this would propel me quite well with Godot as well. What do I know...
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.
This thing is spot on for me as I'm evaluating trying to build games in Godot using Claude Code, but in C# (I have hacks to make it run on NativeAOT), but the result is...mixed. I see only GDScript option is available and that's kinda sad.
This is a really good idea. Image all the game devs that hate writing actual code but sits on some seriously good ideas. This will help so many to get the initial MVP thats needed to see if a game idea is viable.
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.
Woah! This is very timely. My 9-year-old has been playing around with Claude Code and creating games, mostly with Phaser. He's dabbling with some 3D games and I was just looking at Godot as an option yesterday.
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.
this is great, specially the evaluation loop. the worst part of using AI to make games is testing things work as intended after every modification specially if its a complex game.
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.
Maybe OP could try an angle where at various points, the process presents the user with 2-6 options, and they choose their favourite. With a bit of intentional chaos in there, the user and tool could potentially discover interesting game concepts and eventually build them as prototypes.
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.
Hey bro, been working with the Godot MCP for about a year now myself. This is really cool! The two loops I think you should add / address: 3D assets / rigging. This is the hardest thing to do in the current Claude Code to Godot MCP loop right now. Claude can reliably make 3D assets using the in game creator, but ideally you have a system that works with external models (or better yet, generates them ala something like spline or similar system in Blender) and then can rig them up in game. 2. Expanding the evaluation loop from just screenshots to actually playing the game. I just started building a game in Claude Code Desktop, and the Claude agent there can actually PLAY the game. That's a huge unlock. I've been thinking about how to get this same functionality in the Godot MCP server but if your system can do it that would be awesome too.
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").
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.
Personal attacks, which you crossed into here, are not allowed on HN. Please don't post like this, no matter how you feel about someone else or their work.
This guy is as blatant as it gets, and you can't/refuse to enforce it. Obvious AI writing with all the tells. Your site is going to crap buddy go select which rules you feel like moderating somewhere else and ban me. Never going on here again, enjoy your AI slop.
Perhaps the only way it can go to crap even faster is when people react to this pressure by attacking others. That has never been ok on HN and never will be, so please don't. You can make your substantive points without any of that!
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.
Note that while Godot's formats support being text based (.tscn and .tres) you get a massive speed boost in saving and loading once you convert to using .scn and .res for everything that is over 1MB in size. If you add a high-res model and make it unique because you need to change the textures or something, that already makes your scene as big as the model.
So be aware that supporting text only will become slow once the scenes are big enough.
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> .
The actual screenshots only show like 10k lines of code from the procedural generation system and custom render tech. Its a fully playable RPG game, the lines are split on quest systems, stat stuff, inventory, ui, dungeon generation, enemies, etc.
The world is being generated at startup for a 50-50 kilometer play area through multiple steps of generation that includes city placement, roads, and various biomes.
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 think the software engineer types in this thread misunderstand what makes game developers tick. A lot of people here do game dev as a way to explore new ways to code. My sister is an indie dev and to her, code is an unavoidable means to an end (creating a game). So many games are absolutely spaghetti on the inside because the creator is deeply uninterested in the art of code. So to that end, LLMs are actually an awesome thing to enable creators to experiment more freely.
FWIW, I’m a platform engineer who is actively mourning the loss of reliability and care given to production code. I just think games aren’t an area where this is nearly as much of an issue.
> I just think games aren’t an area where this is nearly as much of an issue.
That's news to me as a game dev. I only get a few milliseconds every frame in which all my calculations need to run. If my program is built on spaghetti code, performance suffers and it becomes very noticeable very quickly.
This doesn't just generate the code though. It generates the "art" and everything else as well. Ideas are beyond cheap. It's the personal creativity that makes games good or bad.
And saying the code doesn't matter is just ignorant. In plenty of great games the art doesn't matter. In plenty of others the code doesn't matter. Or the dialogue. But the reverse is just as true. In a game with tight, fluid player controls, the code to make that happen takes just as much creativity and skill and human touch as any other form of art. A driving sim made by someone deeply uninterested in the code they write will never feel good to play.
It is just so disingenuous to say that people who focus more on the code side of game development aren't creators. If I can make a demo with a black rectangle jumping around on some red rectangles and hand it to someone and have them say it feels like they're jumping around as a cat, with no art or animations, I'd say that took creativity and a human touch that ai is nowhere near being able to emulate.
So if AI can't emulate it, what's the issue?
I do think AI can emulate it - one of the earliest headlines I remember is an AI piece winning a digital art competition. The piece was great and the influence of the (human) artist was obvious.
If something is beautiful, I can't be assed to care what kind of paint was used to create it. If you trust human beings to continue to appreciate art as we have done since the beginning, there's not going to be any intractable issues.
>If you trust human beings to continue to appreciate art as we have done since the beginning, there's not going to be any intractable issues
When did the discussion become about trusting the audience? I think the discussion has always surrounded whether it's worthwhile to treat art as a problem that needs solving.
Well, if you think it's not a problem to solve then you should go tell all the paintbrush manufacturers that their services will no longer be needed. Ditto for publishers, patrons of the arts, etc., etc.
If art is worth doing it's worth doing with good tools.
> If art is worth doing it's worth doing with good tools.
Yeah, that's why we should keep LLMs out of it.
There are many great games absolutely full of attrocious code.
I'd wager that there are no great games without some amount of atrocious code.
Yes, in fact there is a ridiculous amount of people in software that want to gatekeep how others do things.
In the context of making a personal project it will never ever matter whether you know how to code or not as long as you enjoyed the process.
It probably stems from a place of fear and pride.
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.
The year is 2050 and those are all AAA games.
they're already all available on the Nintendo E-Shop
Just enable DLSS 5.
the comment you are replying to says the results were not cherry picked nor iterated over
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.
I think the point of this is to help people into creating full, "life-full" games. A person can use this as the boilerplate base game, so that they can focus on the narrative, designs, and adding specific and quirky mechanics that make the game feel like a full game.
It helps to not have to sink most of your initial motivation energy on setting up the most basic mechanics like player movement physics from scratch and demo level templates.
For what it is, it's amazing. The only issue I would have is the manager goons who would want a commercial game then shove something like this down dev team's throats to "be faster". I can imagine getting the professional polish all through prompts would be a trying experience (especially after not knowing what the code does because it's all generated.)
These demos are far, far better than what I expect from one-shot-prompting. It's interesting how our expectations shifted though.
Its impressive in the gimmick sense, but its not impressive in the "i want to use this tool" sense.
I use cluade code to help work in godot, but I dont try to use claude as a one shot tool anymore. I haven't gotten good results out of it and I haven't seen any good results out of it elsewhere.
What's your workflow like for Godot?
I use claude the same way for all programming I do (game, web, minecraft mods). I say I want to accomplish a certain task, claude puts together a plan and explanation, I question any assumptions or things I dont understand, maybe do some research into parts that are new to me, and then either ask claude to implement the feature or I ask claude for a high-level concept and I implement it myself.
> ... but then the mechanics, and movements of the character, made it seem like it's really bad physics
And when you realize that apps that are vibe-coded are to apps what the games here are to actual games, things get really worrying.
Oh well, back to my Claude Code CLI anyway but I know it's generating a huge amount of crappy code.
You gave the guy prompting the bot the respect of reviewing his 'work' and he just gave you more LLM output, lol.
i expect the point of the skill isnt that the end games are good, but such that claude can work on any part of the godot engine to help you make a game.
i do think LLMs need a physics skill though. very consistently they are bad at writing physics related code. at least without a lot of prompting and feedback
Given how likely they are to hallucinate, it might be more realistic to have ais write code for Bollywood physics first.
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?
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.
yes! you wrestle with it because the starting boilerplate is thpically a do-once operation. if you stay working on one project for a few years, you will no longer know how to start the next project, and with modern software, starting a new project in two years from now will be nothing like starting one now
I had the same issue where startup cost was a pain to get little prototypes going. I reduce the cost by making re-usable components. Even if I don't intend to reuse something I still make it a component-esque manner.
It helps that I mostly want to make certain types of games but I think everyone does. I have drop in CameraController, First Person rig, 2D inventory system, dialogue system etc. All flexible enough to get wired into the one off game manager or whatever it needs to plug into.
Don't listen to these people. Work on your "vision".. figure out what gameplay is "fun".. let the LLMs smooth out the resistance.
Things will change rapidly in the nest 12-36 months and people with vision will outlast "craftsman" 100 to 1.
Because that's how all engines and libraries work? Even ones you write yourself still catch you out now and then.
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.
I agree, in the current ecosystem games are abundant but it's still not easy to find the diamonds in the rough.
Trust signals are going to be quite influential going forward, and that will get exploited too. I think we're going to see the return of high effort, high trust games journalism. Not necessarily as the commercial victor, but as a community we will rally around people and outlets we trust.
The problem is finding the needle in the haystack. When you can cheaply develop AI slop by the millions, good luck finding that one game where a human put blood, sweat and tears to realize their vision/dream. Even if you somehow have access to at-scale distribution, economics will ultimately always triumph everything else and more slop will be pushed because it makes economic sense.
It will take at least a full decade for people to realize the slop isn't helping, has made us all collectively mediocre and will seek out people with real specializations. By then I sure hope those who are specializing haven't lost the motivation to do great things and moved on to other fields.
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.
It will show in your game, and I think that will also continue to translate into a better chance at success even in such a swamped market. Maybe even because it's such a swamped market, players will value the games made with passion.
We've all seen shovelware, now introducing excavatorware. A single shovelware studio is now empowered to deliver on the order of kilogames per month.
>A minute of silence to mourn the lost art of making games with passion.
There are still... dozens of us left!
AI tools are great but ultimately it's about taste and intent (and fun for games) that will hopefully lead to quality floating to the top.
im not so sure?
instead we will see something like flash or game maker, with new art styles driven by what agents make easy, and what children think is fun.
games have immediate feedback loops about quality. either theyre fun or theyre not.
I agree, taste, story and art direction will continue to cohere into successful games. Studios making high volume shallow games never had these, and they probably don't want them just because AI showed up. They are filling a specific demand in the industry.
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!
> off the endless learn new tech churn.
you make a good point. I lost interest around "MCP" in all this; now we're up to people not understanding map reduce and manually garbage collecting for the AI.
I have the Minix book, somewhere...
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.
I was never talking about a knitting machine in the first place. Rather, I was referring to the old lady sitting on her sofa, knitting a sock she could also buy for a dollar, but decides to do it herself for the love of the game and nostalgia: a hobby.
The "art" of programming is going exactly that route, maybe with a little fewer ladies and more men.
I didn’t hear the exact analogy so I made some assumption. But I fail to see any insightful analogy which could make such predictions, unless the analogy is operating on top of some flawed assumptions about industrial knitware production.
An old lady could equally sit in front of her desktop PC write some HTML, and upload a blog page with her amazing knitting projects, or she could get pintrest. This was true before LLMs, and it is still true today.
Another potential flaw is the assumption that professional knitwear design does not exist. It does. Plenty of people work in industrial scale knitwear products. We have people designing new products, making patterns and recipes, we have manual labor in the production, operating machines or even knitting by hand. Case in point, travel anywhere and go to a local market popular with tourists, and you will see plenty of mass produced knitted products, most of them took great skill to design and produce. Nothing compatible to prompting an LLM to do this for you.
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.
The OpenClaw inventor? Ok, sure. I think this is sort of cute. The idea that it is just great that all knowledge work would just be a "hobby" when that logically a world in which there would be no leisure would be quite amusing if it is wasn't so depressing.
> 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.
It sucks to fear for your job because programmers decided to automate your job away, doesn't it?
https://www.newsweek.com/joe-biden-new-hampshire-campaign-co...
yeah, it does suck, all the way to nvidia's bank account
those are extremists. for them it must be left or right. two cannot coexist.
meanwhile in reality many jobs still exist that could be automated..Why? because people dont let others automate their joy of life away.
its how it always goes.
people will be programming professionally, and such programs will be used by businesses.
Maybe can generate roblox games, one gets picked up like the next skibidi, boom rake in the money
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.
> 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.
If it makes the game in its entirety then it isn't a tool and those qualities don't factor in to the end product.
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.
What is "passion".. for example.. I vibe coded an art display this weekend for myself for a monitor I have on my wall. I am VERY PROUD of it.. it is in GODOT coincedentally. I think it turned out well. Did I spend weeks on it? Did I even learn GODOT?.. No.. but I did spend my weekend late nights figuring out what I wanted and working with an AI to make it.
In some ways the kind of complaining I see is like complaining about a chef's meal because the chef didn't mine the ore to make his knife.
Look in the specific case of this post... none of the games are "good".. however.. one-shoting games WITH ASSETS.. seems pretty impressive to me.
Isn't this just so disingenuous? No disrespect to you, I just see this kind of sophomoric take so much in response to the very normal reaction of the OP. A year ago, it was in vogue to call the OP "ableist" or something. I think the idea that the OP's concern was like the expectation that a chef would "mine the ore" is a bit ridiculous. A better example would be someone having a painting on the wall feeling ownership in it when they asked their artist friend to paint them a picture; at least that is more reasonable. Also, passion means to struggle, since you asked, which I think follow more the idea of learning the craft. This kind of reductionism would deny that craftsmanship exists, as if sculpting David is the same as buy the finished product on the open market. I think we all know this isn't true but there is some kind of forcefield on the Internet that means we have to pretend it is.
By that note, no game producer or designer can have passion.
Really well said, I hate that every time I say I value craftmanship, skill and effort in art people flock to this reductionism "well did the painter make his own dyes? Did the developer make his own processor to run the game in?"
There's levels to it, it's not black and white.
No more code, only markdown files...
A prompt like "make it more fun" will never work. What's the line for an authentic enough game?
as soon as CD-ROM was a thing, shovelware boomed.
I think it was around already with diskettes or even cassettes. When medium gets easy enough to produce the lowest quality stuff gets produced...
cassettes are a bit before my time. I am personally unaware of any "shovelware" being distributed via cassette; i have heard that radio stations would broadcast programs you could record and play back (i remember Acorn in this particular story, i think.)
And floppies, sure, the 3.5" ones had some shovelware, included in trade magazines and whatnot. Maybe someone has a directory listing of a floppy from this era showing what it was like, i'd be interested; i know about AOL disks, too.
But CD-ROM. never before could humans distribute 200 games / software packages so easily. my first computer with a cd-rom had a hard disk 350MB larger than a CD-ROM. 2 shovelware CD-ROMs was more than my PC could handle!
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)
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.
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?
No I do not because that's not a reasonable comparison?
Then you haven't understood the complaint.
I understood it just fine. You object to creations and creativity that do not pass your subjective quality bar and/or aren't produced in a way that is satisfactory to the people already behind the gate.
It's the literal definition of gatekeeping.
The problem you describe (quantity over so-called quality) is a discovery and curation problem.
Yet you blame the tools of creation and lament the lack of restriction or controls on production instead.
Yes these tools make it easier to produce, and yes that means that you have more low-quality work out there. I'm not pretending like that doesn't introduce new challenges.
But the answer isn't to gate-keep the tools or the process of creation or to stop or shame people from being creative with these new tools by universally calling their work "slop" or "bad".
So you completely agree with the factual description of the problem I supplied when asked to describe the problem, your only real complaint is that I used the phrase "more awful slop" instead of your preferred euphemism "more low-quality work". Having a frank discussion about the problems caused by new technology is not gatekeeping, and I don't think we should sugarcoat it out of fear of hurting people's feelings.
You initially said:
> 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.
So..
"a problem for everyone" <- the fallacy of assuming your personal feelings and opinions are universal and apply to all of us (they're not and they don't).
"spaces meant for meaningful work" <- tells me that you don't seem to believe anything made with these new tools can be meaningful, implying they don't belong etc..
And again the hubris of believing that your personal opinion reflects the ideal state or voice of a broad and diverse community (a fucking textbook definition of gatekeeping btw)
And lastly, do you truly believe that AI tooling is the dividing line?
That all non-AI games made today are meaningful?
There's tons of quick and dirty stuff out there like asset flips and weekend projects that people throw up on Steam or Itch for sale, and there have been for years and years.
If your fear is that bad games are going to get out into the world you haven't been paying attention for the last (checks watch) 50+ years...
> "a problem for everyone" <- the fallacy of assuming your personal feelings and opinions are universal and apply to all of us (they're not and they don't).
The phrase "a problem for everyone" doesn't mean everyone agrees, it just means the described situation would affect everyone broadly...
And even you literally admitted you agree it will introduce problems just in the previous post: "I'm not pretending like that doesn't introduce new challenges", it's a little too late to try walk that back now.
> "spaces meant for meaningful work" <- tells me that you don't seem to believe anything made with these new tools can be meaningful, implying they don't belong etc..
No, just that the non-meaningful work they create risks overwhelming any meaningful work created with or without the tools, which is a real problem AI is already creating in online communities today. Knitting patterns on Etsy is a prime example. It is an accurate description of a problem that already exists today, and trying to avoid discussing it helps no-one.
Again, even you admit the problem is real and don't really have any real complaints except that you keep complaining about my phrasing. It seems you would have been happy if I'd just used the more polite terms you introduce instead, like "new challenges" instead of "problems", "low-quality work" instead of "awful slop", and "not low-quality" instead of "meaningful"? Which is fine, but not really an interesting discussion.
To avoid admitting you are simply annoyed with my phrasing you instead try to pin extreme opinions on me that are nothing close to anything I have ever said, like "you believe your personal opinion reflects the ideal voice of the community", "you believe your personal feelings and opinions are universal", "you believe nothing made with these new tools can be meaningful" and that I think "all non-AI games made today are meaningful", which is just silly.
Since you agree that you see the same problem I see, and just want to discuss other opinions you invent for me that I don't actually share, I don't think we will reach any conclusion here and I probably won't engage further. Thank you for your time anyway.
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.
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.
Slay the Spire 2 was shipped using godot. I've found it's easier to develop on than Unity. This is an outdated understanding imo
I love Slay the Spire 2, it is a very good game, but it most honestly doesn't look or feel technically impressive.
Not all serious games need to be technically impressive.
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.
Oh, I thought we were having a genuine discussion. My bad.
I was substantiating my claims and you were not.
GDScript has static type hints now, it's still a bit basic but continually getting better.
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
For the longest time the answer to this was that, features would randomly not be supported for C#.
But it's gotten much better.
As someone that's been working on a game with Claude Code in a more human-in-the-loop, iterative fashion, I have to say that OP's claim that "LLMs barely know GDScript" does not match my current experience at all even though it seems to have matched yours. Maybe it was true a while ago in both cases; how long ago was your "vibecode" attempt? I've gotten completely fine GDScript and even decent perfectly functional if placeholder-quality TSCN files from Opus 4.5, 4.6, and Sonnet 4.6 with very little issue and no special tricks; just a CLAUDE.md file, the project itself, and going through plan mode before each change. I did start from a playable project with a fair amount of hand-written scaffolding already in place, and I have no idea if that would make a difference. Every once in a while there will be some confusion that I get something appropriate for Godot 3 instead of Godot 4, but never Python despite the similarities of the language.
I agree, Claude does a great job of synthesizing Godot docs, and even of writing unit and integration tests with GUT. I have not tried any e2e testing but I’m not convinced that you couldn’t get a good result there, too, depending on the kind of game.
Ah thanks, I see. This was 8-9 months ago.
I was starting from scratch and mainly relying on Opus/Sonnet 4.
I also kept running into the Godot 3 vs 4 issue before adding specific guidance about this into CLAUDE.md
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 :)
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.
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 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.
I agree with you, but I think it skips over the fundamental point of the demo - that this is possible at all. The door is unlocked. I expect where commercial interests will take this over the next year or two, even without further "model breakthroughs" will be enough to change how many devs engage in game development.
Well done htdt.
And a few more breakthroughs after that it might look like sticks and stones ... who knows!
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.
What about for prototyping as you hunt for a style or concept and just want to see what resonates? I could see this being useful for that.
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.
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.
I think this is pretty cool, all things considered. I think it’s unrealistic to expect anything that’s been one-shot to have much polish or charm.
Something I’m surprised about is the lack of unit testing. Agents are remarkably good at creating tests and GUT testing is pretty well developed; having some good unit tests would really assist in the subsequent steps where you polish controls, add features, etc. Without these, I think things will get off the rails pretty quickly.
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.
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!
I agree, it will be a boon to other content creators on YouTube: "The #1 Way to Make $181,020 A Month With Games -- Join My Skool"
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.
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.
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!
for what it's worth I have been building a game with godot and using gemini flash and pro to help. it has no trouble editing gd script and scenes. so far it hasn't failed in anything i asked it to do
fyi that link is dead, maybe the repo is set to private?
Very cool. Thanks for sharing! This introduced me to Godot, gave me an excuse to use Claude code and a few hours later had it all installed and created my first game/simulation.
Experimenting each night with a new game idea, genre, style, etc. Really fun. Thanks again!
As a Godot user, GDScript's unique syntax often trips up standard LLMs, so your custom language reference is a game changer. Integrating Claude Code directly into the game dev pipeline like this shows where the future of 'Agentic Workflow' is heading.
Claude codes fine in GoDot. You have to explicitly give it the version you are working on.
Claude’s the only one I’ve got working with GoDot.
The lazy-loading approach for the API reference is clever. Did you consider embedding a smaller, distilled subset of the most-used classes permanently in context, and only lazy-loading the long tail? Curious whether the overhead of deciding what to load ever causes cascading errors where the wrong API gets pulled in. Also interested in the visual QA separation - using a model that sees only screenshots and never the code is a genuinely good idea for avoiding confirmation bias. Did you try using Claude for that role too, or was Gemini Flash specifically chosen for cost reasons?
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.
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?
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/
A bit misleading marketing there (like always) - all the good looking game videos are actually just AI generated videos (obvious tells: HUD elements wouldn't have scrambled text if they were actual games, rendering of barrels has the worst LOD popout I've ever seen or it's AI), but the actual games are really bad.
That site looks like this generations Flash player.
The 2D sprites in the bike riding scene are a bit of a mess. Honestly consistent 2D animation is difficult.
You've basically got two approaches right now - use a openpose style controlnet representing a walk cycle in conjunction with img2img OR you can try using a walk LoRA with WAN to generate video and then clip out 4-8 frames that represent a good loop from the video.
https://imgpb.com/ELJfWpi
Here's Google's: https://www.youtube.com/playablesbuilder/
Thanks for not cherry picking the output. The demos look great for a single prompt output. I can see myself playtesting a mechanic that I just thought of but would probably take longer to implement in my own WIP game etc.
I think this has great value just now, can't wait for it to get better. Keep at it.
I can't decide if this is impressive or not. At first I think it is, but also the best demos you could find were not good games, and likely not even good bases for further iteration. It seems pretty likely that this tool would increase the speed of shipping a salable game by zero minutes. So it's kind of impressive but at the same time not.
If you put in the effort to polish the scenes, mechanics, and overall feel, then with a great idea and a few iterations, you could potentially build a sellable game. I honestly do not know what it takes to sell a game, but if you have a strong idea and want to put it online, a tool like this can take you surprisingly far and let you focus on the bigger-picture parts of the game.
I think it's quite impressive without even trying it. I think more and more tools like this will pop up soon.
Well no, what I mean is I've used Godot a lot and I think it's likely that the effort to polish this output is more than the effort to start from scratch. Godot as a codebase is very easy to become horrendous spaghetti. Even though this is some form of a start, I kind of doubt it would decrease time to ship by any amount, maybe even increase time to ship, for the same reasons that greenfielding is faster and easier than incrementally refactoring a legacy clusterfuck written by juniors.
You may be right, I don't have any experience with Godot but as a noob game dev it feels to me that if I have a good clear idea (perhaps a simple one), a Claude skills pipeline would help move things faster, get to something roughly working relatively easily. From there to a polished game there's considerable effort, I'm sure. Since I've had a pretty good experience with LLMs and making Lua games my inclination is to think this would propel me quite well with Godot as well. What do I know...
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.
This thing is spot on for me as I'm evaluating trying to build games in Godot using Claude Code, but in C# (I have hacks to make it run on NativeAOT), but the result is...mixed. I see only GDScript option is available and that's kinda sad.
This is a really good idea. Image all the game devs that hate writing actual code but sits on some seriously good ideas. This will help so many to get the initial MVP thats needed to see if a game idea is viable.
Good work! Interesting to follow.
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.
Woah! This is very timely. My 9-year-old has been playing around with Claude Code and creating games, mostly with Phaser. He's dabbling with some 3D games and I was just looking at Godot as an option yesterday.
He and I will give this a spin this weekend.
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.
Feels like we have great tooling for code, but prompts are still mostly trial-and-error. Curious how people are validating them today.
this is great, specially the evaluation loop. the worst part of using AI to make games is testing things work as intended after every modification specially if its a complex game.
whats the art creation pipeline?
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.
Maybe OP could try an angle where at various points, the process presents the user with 2-6 options, and they choose their favourite. With a bit of intentional chaos in there, the user and tool could potentially discover interesting game concepts and eventually build them as prototypes.
Was expecting a higher jump for plumbers. Cashiers were already suffering with the self-checkouts for years.
“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.
Awesome stuff, what does it use to generate the assets?
Hey bro, been working with the Godot MCP for about a year now myself. This is really cool! The two loops I think you should add / address: 3D assets / rigging. This is the hardest thing to do in the current Claude Code to Godot MCP loop right now. Claude can reliably make 3D assets using the in game creator, but ideally you have a system that works with external models (or better yet, generates them ala something like spline or similar system in Blender) and then can rig them up in game. 2. Expanding the evaluation loop from just screenshots to actually playing the game. I just started building a game in Claude Code Desktop, and the Claude agent there can actually PLAY the game. That's a huge unlock. I've been thinking about how to get this same functionality in the Godot MCP server but if your system can do it that would be awesome too.
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").
Amazing! We have played with it to create an animation based on "The Three Little Pigs". Video available here [1].
[1] https://drive.google.com/file/d/1ozZmWcSwieZQG0muYjbj7Xjhhlz...
Very impressive! Looks great!
But can it build Doom?
Give it a couple of model upgrades :)
With games we just need some really good slop filters on the storefronts. I mean this has been the case already for some time even before AI
"real games"
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.
[flagged]
Personal attacks, which you crossed into here, are not allowed on HN. Please don't post like this, no matter how you feel about someone else or their work.
https://news.ycombinator.com/newsguidelines.html
Didn't you guys just make rules about using AI to comment and post?
> Don't post generated comments or AI-edited comments. HN is for conversation between humans.
Maybe you need to read your own rules: https://news.ycombinator.com/newsguidelines.html
This guy is as blatant as it gets, and you can't/refuse to enforce it. Obvious AI writing with all the tells. Your site is going to crap buddy go select which rules you feel like moderating somewhere else and ban me. Never going on here again, enjoy your AI slop.
Perhaps the only way it can go to crap even faster is when people react to this pressure by attacking others. That has never been ok on HN and never will be, so please don't. You can make your substantive points without any of that!
I say do what makes you happy and don't worry about people like ^this^ guy.
I mean the title of the post claims it can create full games, it can't. Its not even close?
Full game here means it compiles and runs, not that it beats the charts.
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.
Note that while Godot's formats support being text based (.tscn and .tres) you get a massive speed boost in saving and loading once you convert to using .scn and .res for everything that is over 1MB in size. If you add a high-res model and make it unique because you need to change the textures or something, that already makes your scene as big as the model.
So be aware that supporting text only will become slow once the scenes are big enough.
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> .
The 60,000 lines of code that just works bro!:
The screenshot:
The actual screenshots only show like 10k lines of code from the procedural generation system and custom render tech. Its a fully playable RPG game, the lines are split on quest systems, stat stuff, inventory, ui, dungeon generation, enemies, etc.
The world is being generated at startup for a 50-50 kilometer play area through multiple steps of generation that includes city placement, roads, and various biomes.
Has 3 months of dev time right now
that's reasonable I think if he isn't using any kind of game framework.
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.