Discussion
Search code, repositories, users, issues, pull requests...
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.
tpxl: 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.
vblanco: 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.
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.
pragmatic: I don’t think the web output works with c# currently.Be happy to find out I’m wrong.
andai: 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.
htdt: 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.
andai: 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!
