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.
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.
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 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.
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.