Godot as an Embeddable Game Engine
tirania.org
tirania.org
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.
As someone who likes lower level languages (like rust) I find gdscript to cover all my needs (since 2017)
Plus most work in gdscript is just calling c++ anyway.
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
It's a fine scripting language for hobby games or glue code. I would never do serious software development with it.
Writing a whole game in gdscript (and godot) seems totally fine.
Imo it’s a better language than Lua, and 100s of games are written in Lua.
Balatro, undertale, hotline Miami (anything in game maker)
- 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.
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
https://docs.godotengine.org/en/stable/classes/class_object....
Keep in mind I don't say any of this because I dislike GDScript. It's just not the best tool for all jobs in my opinion.
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.
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.
I just don’t know if I want to pull in that complexity, yknow?
I’m waiting for bevy’s editor before I go too far into rust land for my games.
Ownership rules exist only at compile time and are not the reason it crashes at runtime.
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.
As per your comparison to C, you are mistaken, this would do whatever C does when it has incorrect `restrict` qualifiers.
See how the book phrases it for yourself: https://doc.rust-lang.org/book/ch15-05-interior-mutability.h... The way RefCell works is not described as a similar but different set of rules or invariants, but as enforcing the same rules.
Please do not ignore the compiler's assumptions in your own programs...
> needs to be upheld both at compile time and run time for Rust code to function.
That is not correct, in general, even if in some cases, it causes a crash via panic or segfault.
I don't know what you are trying to argue here. This thread is already too deep. Ownership rules are not optional. Sorry?
> needs to be upheld both at compile time and run time for Rust code to function.
That is not correct, in general, even if in some cases, it causes a crash via panic or segfault.
/shrug
If you want to argue a different point with someone, do it with someone else.
I’m simply pointing out that you are categorically wrong in your statement.
You are not "pointing out" anything, you are stating against evidence.
Something like a flash authoring and deployment used to be.