GoDot Engine: Complaints from experienced programmers

This is a READ-ONLY snapshot of the Godot Community Forums when TwistedTwigleg was the owner, which is hosted for archival reasons only. The current Godot Community Forums can be found here.

Some links may point to external websites, including the current Godot Community Forums. These websites are not associated with TwistedTwigleg.

GoDot Engine: Complaints from experienced programmers

GoldenDuckFloats

After talking with people who attempted to make something more complex than a 'Flappy Bird' style game, I cataloged their most common complaints with the engine. If any of the main dev's are reading this, you should take these points into consideration and decide on the direction you wish to take.

The overuse of linked lists as a 'Data-structure'. This means the engine misses out on a lot of possible optimizations.
The inability to load assets from a 'stream'. Only files, so a 'game archive-system' is impossible for this engine.
The OpenGL renderer does not use 'culling' or 'batching'. The result is the engine draws everything on individual draw calls. This MASSIVELY reduces the frame rate (FPS).
Instructions are 'mono-instances' running inside a program, so a C# de-bugger or any other preference tools cannot be attached. . There seems to be a large disparity between the praise that the GoDot engine is given and people's actual experience with it. I'm not here to argue with you, merely to bring to light the issues that prevent GoDot from becoming a world standard. From what I've been hearing, these problems are so bad that people have suggested that GoDot or a large part of it should just be re-written.

With that said, I think its important to also mention its strengths. From what I understand, the engine itself is free. The costs of developing it are paid for by the online market that sells code and other assets.

SIsilicon28

The OpenGL renderer does not use 'culling' or 'batching'. The result is the engine draws everything on individual draw calls. This MASSIVELY reduces the frame rate (FPS).

OpenGL does use culling. More specifically it does view frustum culling. What it doesn't do is occlusion culling. That along with batching is planned to be implemented in Godot 4.0 and most likely in Vulkan only.

ReimGrab

Instructions are 'mono-instances' running inside a program, so a C# de-bugger or any other preference tools cannot be attached. The last time I attached a VS Code debugger it worked as expected.

cybereality

I think that Godot does still need some work, but 4.0 is coming along and will fix many things. I also hope to contribute myself once I am more familiar with the code (I got as far as compiling from source and spot checking a few files but nothing in-depth).

Honestly, I think Godot is good enough to make an indie game as-is today. Granted, performance can be better in some cases but it's not horrible. Out-of-box the graphics aren't quite as good as Unity or Unreal, but if you write your own shaders it can look very good.

For me the productivity gains on Godot are pretty massive. I've only been using for about 6 months, but I can easily create a new project and start messing around without tutorials or maybe just looking at the docs. I've used Unity and Unreal and tons of other engines, and I've never been this comfortable, even after considerably more time.

But feedback is good, I do agree that performance can use some work so thanks.

Azedaxen

@GoldenDuckFloats said: There seems to be a large disparity between the praise that the GoDot engine is given and people's actual experience with it. I'm not here to argue with you, merely to bring to light the issues that prevent GoDot from becoming a world standard.

Aside from maybe the lack of Occlusion Culling and other rendering optimizations, I don't think these issues listed are going to prevent Godot from becoming competitive with other engines. And as mentioned already, the missing rendering optimizations are going to added in Godot 4. You said these were experienced programmers, so perhaps that's not representative of the core Godot userbase? I don't want to assume that the average game developer isn't an "experienced" programmer, (I'm not sure how you're qualifying that) but these issues certainly aren't an obstacle for me using the engine, and I would imagine this is the case for several others.

The thing that you have to keep in mind is that Godot is a relatively young game engine. A lot of issues with the engine will be ironed out over time.

Calinou

The overuse of linked lists as a 'Data-structure'. This means the engine misses out on a lot of possible optimizations.

There was an issue about this. I encourage you to read the whole discussion to see why those design decisions were made. In general, Godot aims for ease of use rather than absolute performance.

The OpenGL renderer does not use 'culling' or 'batching'. The result is the engine draws everything on individual draw calls. This MASSIVELY reduces the frame rate (FPS).

2D batching was implemented in 3.2.2. It's enabled automtaically if you use the GLES2 renderer. It may be added to the GLES3 renderer in 3.2.3.

In 3D, you can use MultiMeshInstance to merge 3D meshes together into a single draw call. If you need to do lots of processing on thousands of instances, you can also interact directly with Godot's servers.

The inability to load assets from a 'stream'. Only files, so a 'game archive-system' is impossible for this engine.

What do you mean? PCK is precisely a "game archive" format as it's basically a virtual file system. As for texture streaming, this is coming to Godot 4.0.

There seems to be a large disparity between the praise that the GoDot engine is given and people's actual experience with it. I'm not here to argue with you, merely to bring to light the issues that prevent GoDot from becoming a world standard. From what I've been hearing, these problems are so bad that people have suggested that GoDot or a large part of it should just be re-written.

Godot is a do-ocracy. If you want your voice to be heard, you need to contribute :)

We've had "experienced programmers" tell us what to do for years now, but I would really appreciate if they could make more meaningful contributions. Even contributing documentation or demos goes a long way.

With that said, I think its important to also mention its strengths. From what I understand, the engine itself is free. The costs of developing it are paid for by the online market that sells code and other assets.

There's no official marketplace, actually. The engine development is funded by Patreon (which I'm not part of) and various sponsors.