I’m developing Fracterebus in C# using the Godot engine. This is a supported approach according to the folks at Godot that support it, but based on the videos you can find on YouTube, it is definitely not a common approach. In my mind, it comes with a bunch of advantages and disadvantages.
Advantages
- I like C# better than GDScript. This one is very important to me.
- When not interacting directly with Godot Engine, C# code operates a great deal faster than GDScript (about 45x faster in my tests). It is my understanding that it is close in speed when closely tied to things Godot does.
- C# has a massive library of features built in that eliminates the need to recode data structures you expect to just be there in GDScript, but aren’t.
Disadvantages
- C# editing integration in Godot is very poor. You don’t get basic creature comforts like intellisense or syntax highlighting when coding in C# right in Godot. As a rule, if you’re coding in C# you are expected to use an external editor like VSCode to get these features.
- Dragging nodes from the scene tree into the code editor doesn’t set up references automatically like it does when using GDScript.
- Things like tweening operate differently and can access fewer properties on things you want to tween than you get with GDScript.
Which brings me to the point… Where is the line? If I’m coding on C#, and things like state machines exist in Godot, where does my use of them make sense? In other words, if I use the built in Godot state machines, I get a bunch of cool features essentially for free and I honestly don’t know if I get those same things in C#, or importantly if I do, how to use them. Most of the online tutorials I’ve watches while learning Godot use GDScript, and even those often make their own state machine code instead of using the Godot state machine editor. So where is the line? When do I try to lean on Godot for something and when do I just make it myself so I have explicit control over how it works in my code?