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.
Malware is very easy to build. Competent threat actors don't need to rely on open source software, and incompetent ones can buy what they use from malware authors who sell their stuff in various forums. Concerns similar to yours about 'upgrading' the capabilities of threat actors were raised when NSA made Ghidra public, yet the NSA considers the move itself to have been good (https://www.nsa.gov/Press-Room/News-Highlights/Article/Artic...).
People will build malware. It is actually both fun and educational. Them sharing it makes the world aware of it, and when people are aware of it, they tend to adjust their security posture for the better if they feel threatened by it. Good cybersecurity research & development raises the bar for the industry and makes the world more secure.
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.