HN

Comments (122)

• sieep
  This is a whole lot of words (that you didnt write) for something that can't even produce a single decent game. Learn to code, learn to write, learn to build and don't end up like this guy.
• Menu

  hmokiguess
  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
• Menu

  samiv
  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?
• EagnaIonat
  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.
• weakfish
  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.
• Menu

  bhu8
  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.
• Menu

  stephc_int13
  Gamedev here.I looked at the video, awful results, better start with a template.
• scumblr
  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.
• soared
  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!
• Menu

  andreagrandi
  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?
• Menu

  c0m47053
  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!
• stevefan1999
  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.
• aed
  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.
• nanobuilds
  Was expecting a higher jump for plumbers. Cashiers were already suffering with the self-checkouts for years.
• avaer
  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/
• Menu

  Underphil
  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.
• Menu

  lemming
  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?
• Menu

  tyleo
  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.
• Menu

  chaosprint
  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?
• canadiantim
  Very impressive! Looks great!
• rybosworld
  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.
• Menu

  guitarlimeo
  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").
• Menu

  eudamoniac
  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.
• Menu

  twelvevaginas
  “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.
• Menu

  slopinthebag
  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.
• Madmallard
  "real games"
• _QrE
  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.
• leontloveless
  [dead]
• takahitoyoneda
  [flagged]
• RomanPushkin
  Upvoting this! And thanks!
• Menu

  vblanco
  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.
• Menu

  mattfrommars
  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?