Godot as an Embeddable Game Engine

Re:Godot as an Embeddable Game Engine by TheCleric on Sunday April 14, 2024 @02:09PM (#40033065)

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.

[ Parent | on HN ]

Re:Godot as an Embeddable Game Engine by dartos on Monday April 15, 2024 @07:43AM (#40039214)

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

[ Parent | on HN ]

Re:Godot as an Embeddable Game Engine by TheCleric on Tuesday April 16, 2024 @11:11AM (#40052998)

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).

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.

[ Parent | on HN ]

Re:Godot as an Embeddable Game Engine by dartos on Tuesday April 16, 2024 @12:24PM (#40053973)

For sure. No heated debates here!

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.

[ Parent | on HN ]