Have been using Godot via the excellent Gdext Rust wrapper. It's all smooth sailing except for one issue: if a Rust signal initiated trigger calls into Godot and that in turn (via callbacks/signals whatever) calls back into Rust, it crashes because of Rust ownership rules.
Of course there are workarounds to circumvent this but they are a bit clunky.
Have been following Miguel de Icaza's work on Swift Godot and am really tempted to switch. Swift feels like an ideal language for game dev: type safe to allow frequent refactoring, a simple but effective (enough) memory management mechanism, good performance...
And de Icaza spearheading this makes it more compelling still. The guy takes on rather tricky engineering problems and sees it to completion.
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.
Ownership rules can be arbitrarily violated by unsafe code which may cause a crash, or undefined behaviour but it does not prevent rust code from running.
Many “violates single ownership rules” (eg. Concurrent mutable references) actually dont break rust, because the undefined behaviour on many platforms happen to be “eh, does whatever c does, which is actually fine”.
It would be more correct to say that they must upheld to guarantee rust code functions correctly.
However, segfaults come from memory corruption, which comes from unsafe code; probably use after drop. It doesnt usually come from violating single ownership rules, and usually it’s from “object was dropped because it was owned and you forgot to keep it alive across a callback boundary” just like c++ code with unique_ptr
…but eh, whatever. The point is it crashes, which means the binding isn’t done correctly, whatever you call it. Lay blame where blame is due; the rust wrapper isn’t safe.
A program that fails under some circumstances is a buggy program. The fact that it doesn't crash under some circumstances is no redeeming quality at all.
I don't know what you are trying to argue here. This thread is already too deep. Ownership rules are not optional. Sorry?
I've explained and I've linked references, your last two comments say "not correct". If you don't want to argue don't, if you do please present arguments.
You are not "pointing out" anything, you are stating against evidence.
Brings back memories of doing the same with Ogre to support embedding Ogre scenes in android UI elements for the Amazon Fire Phone. Sadly not open-sourced at the time, so lost to corporate bullshit.
Of course there are workarounds to circumvent this but they are a bit clunky.
Have been following Miguel de Icaza's work on Swift Godot and am really tempted to switch. Swift feels like an ideal language for game dev: type safe to allow frequent refactoring, a simple but effective (enough) memory management mechanism, good performance...
And de Icaza spearheading this makes it more compelling still. The guy takes on rather tricky engineering problems and sees it to completion.