Shortly after I posted my last article, Juan Linietsky, one of the founders of Godot Engine, published an article about the competitiveness of Godot Engine in AA and AAA game development.

The article is really worth reading, because on the one hand he goes into the technical possibilities with Godot 4 (renderer, physics, scripting, GDExtension, …) and on the other hand he points out what he thinks is still missing to develop AA/AAA level games with the Godot Engine.

Current state

With the completely new rendering architecture and the division into the backends modern and compatibility, the renderer is well positioned for the future. Modern supports current interfaces like Vulkan and therefore also current hardware, while compatibility ensures backwards compatibility with OpenGL ES 3.0 and OpenGL 3.3. So you can use Godot regardless of the target platform, for modern hardware you use modern and for a broader spectrum including older mobile devices you choose compatibility. Modern technologies such as AMD FSR 1.0 or SDFGI are already supported by the modern backend. There is also an effort to support AMD FSR 2.0 in the future.

By default, Godot 4, in contrast to 3.x, only provides its own physics engine, which is primarily designed for simplicity and customizability. Instead, with version 4.0 it is possible to integrate other physics engines (PhysX, Jolt, …) via GDExtension at runtime without having to recompile Godot.

With GDScript 2.0, the language have been significantly expanded by, for example, lambdas and expansion of the enum functionalities.

The new extension system GDExtension allows to extend functionality without having to recompile Godot.

The missing parts

Juan identifies the following features as still missing:

Streaming

To support huge scenes or even OpenWorlds, efficient use of memory is needed. “Streaming” refers to a technology that allows assets to be reloaded only when needed, rather than at the beginning of a scene. A distinction is made between texture, mesh, animation and audio streaming. The efficient implementation of mesh streaming is probably the greatest challenge.

Low level rendering access

When it comes to rendering, regardless of the architecture, there is no one size fits all solution. Therefore, developers of larger studios are used to having access to the rendering process in order to integrate their own solutions for e.g. post-processing or rendering techniques. To be able to realize something like this without adapting Godot itself, the API for GDExtension still needs to be extended significantly.

Improvements to the scene system

Servers are the real workhorses in Godot. They are used by the scene system to perform the work for physics, rendering, etc. With Godot 4, all servers have been significantly improved to support multithreading, but the scene system is still single-threaded. This means that complex scenes, i.e. with many sub-nodes, are still only executed on one CPU core and thus run slower than actually possible. But there is already a proposal how to solve this problem.

Swarm system

The scene system of Godot is designed for flexibility and ease of use with a few hundred nodes. But there can be situations where this is no longer sufficient. A good example of such a situation is the “Bullet Hell” as devmar had shown with Godot 3.4, where the goal is to manage thousands of simple objects. To simplify the implementation of such systems significantly, there is the proposal for a swarm system.

VCS-Support for large teams

Godot uses text-based file formats for project files, scenes etc. This generally provides a high level of compatibility with version control systems (VCS), as it allows changes to be validated by humans (with a little practice) and potential merge conflicts to be handled well. However, the integration of VCS into the Godot development environment could be improved significantly, e.g. to make changes more recognizable and to apply asset changes in real time if possible.

Commercial asset store

Even if AAA studios actually create all assets themselves or have them created exclusively for them, purchasing from asset stores is quite common in the AA area, as long as the quality is right. The current asset library contains only open source assets. By establishing an own foundation, the way is now clear to introduce a store that offers assets for money, similar to the Unity Asset Store or the Unreal Engine Marketplace. I think it is realistic that such a store will create high-quality assets for easy use in Godot.

Genre-specific templates

Everyone who has ever “played around” with the Unreal Engine has made acquaintance with the ready-made project templates. They are a good start not only for fast prototyping. Similar templates exist in the Godot asset library, but the level of configurability and scope is somewhat different.

Visual scripting

Godot 3 had visual scripting, which was discontinued with Godot 4. As far as I know, the scope was much smaller compared to Unreal Engine Blueprints. Especially in combination with configurable templates visual scripting could open new possibilities for configuration.

Specialized artist UIs

When editing shaders, effects or animations, the Godot engine offers comparable features as e.g. the Unreal Engine, but the way to get there is completely different. While the Unreal Engine provides special UIs for editing such “special tasks”, which then provide everything for the respective task, it looks unfortunately (still) different with Godot. Juan shows this in his article with the example of editing a particle system, which requires the understanding of the following subsystems in Godot:

• GPUParticles node
• GPUParticlesMaterial resource or even an optional dedicated shader
• Mesh resource for each pass of the particle
• Mesh material resource for each surface of the mesh or even an optional dedicated shader

This makes it unnecessarily complicated for highly specialized artists (VFX/effects artists, technical artists, …) to work, as is common and necessary in the AAA area. Therefore, similar specialized UIs as in the Unreal Engine are also needed for this to be used efficiently with such a high level of specialization. Such interfaces could also be delivered via plug-ins or by third parties, the general functionality is already available in Godot.

Conclusion

With Godot 4, the Godot Engine is already quite well prepared. Version 4.0 will still have some open issues, which should then gradually improve with the upcoming 4.x versions. As described, a part of the missing technical functionalities is relatively straightforward to implement and requires time in the first place. Other things, such as specialized UIs for artists, require appropriate feedback from those for whom they are intended. All in all, I interpret Godot 4 as a very good starting point for larger studios to build an in-house engine on. Certainly, it would be nice to see some of that in-house development return to the original project.

For a closer look, I can recommend the original article.