Comment by htdt
12 hours ago
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!
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.
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
1 reply →