It’s worth noting that they ported SS2 from unity to Godot, so it’s likely they were trying to keep as much of their existing code as they could, but tbh they’d probably use c# from the beginning regardless
Not OP, and have only ever made hobby games in GDScript, but here are a few I'd be concerned with:
- GDScript objects are very heavy, as the base class of objects are a bit heavy (by their own admission). So having a lot of them can lead to memory/performance issues.
- GDScript is best when you’re using the optional typings, but there are certain operations that make this a pain (e.g., Arrays can be typed such as Array[int], but most functions will return an untyped array, as well complex types such as Array[Array[int]] and Dictionary[String, int] are not supported. Generics are also unsupported.)
- Coming from a Python background, GDScript is just close enough to Python to feel familiar, but just different enough that half the things you’d expect to work don’t. It can be a bit taxing keeping them straight in your head if you try to use both frequently in different contexts.
- The editor itself is missing a lot of IDE creature comforts such as code formatting.
These are just a few off the top of my head. None is enough to make me abandon Godot or GDScript, but would wear on me in a larger project.
What makes gdscript object “heavier” than the c++ classes that implement them? IIRC the docs just mention that creating gdscript objects is an expensive operation, but that’s just as true with C# objects because both have memory allocations.
Modern gdscript best practices call for typing, but tbh I think making a game without types is possible and fine (Lua and JavaScript are used to make successful games for example)
Totally true about python. If you’re used to python, gdscript is like writing code in a funhouse mirror.
You don’t need to use godot’s editor. Godot has a built in LSP, so the vscode extension works well. I think they even added a scene graph view.
I mean use whatever you want to make a game, but personally, I find the Godot specific language features really sell gdscript. (Signal connection syntax, $ and %)
I usually wire up signals is gdscript and write actual work (algorithms and math) in dependency-free gdextensions
Here is the reference for the base Object class in Godot, so every time you instantiate an object (even if you have defined a simple class without a lot of complexity), all of this gets instantiated and allocated. This is MUCH heavier than a C# base object (which wouldn't necessarily have to be based on a Godot class).
Rollercoaster tycoon 1 and 2 were written in assembly. Great games can be made from anything.
Normally when I make Godot games, all of my classes are nodes anyway.
I really lean into the “everything is a node” idea.
Now if I’m writing some algorithm (A* or marching cubes or whatever) I wouldn’t start with gdscript, so I guess I never really made gdscript objects just off the base Object class before.
Yeah, you can totally use both gdscript / C#, as well as C/C++/Rust for targeting performance sensitive objects, like doing heavy simulations, since gdscript / C# will still be often simpler for glue code and light-weight signal handling. I think people misunderstand that this is less Rust bindings for the engine and more so like producing plugins/mods for the engine to import.
For why Rust vs. C++, Rust is often able to handle embedded invariants through the type system, while in C++ you'd need to juggle them in your head, which scales a bit poorly through time or number of people working on the project. That said one thing that doesn't match well is the Godot is very inheritance based, which is a bit of an impedance mismatch for using Rust, but I've found gdext to translate these things into composition well enough.
As someone who likes lower level languages (like rust) I find gdscript to cover all my needs (since 2017)