Kurz nachdem ich meinen letzten Artikel online gestellt habe, hat Juan Linietsky, einer der Gründer der Godot Engine, einen Artikel über die Konkurrenzfähigkeit der Godot Engine im Bereich von AA- und AAA-Spieleentwicklung veröffentlicht.

Der Artikel ist wirklich sehr lesenswert, da er einerseits auf die technischen Möglichkeiten mit Godot 4 (Renderer, Physik, Scripting, GDExtension, …) eingeht und andererseits aufzeigt, was seiner Meinung nach noch fehlt, um Spiele auf AA-/AAA-Niveau mit der Godot Engine zu entwickeln.

Aktueller Stand

Mit der komplett neuen Rendering-Architektur und der Aufteilung in die Backends modern und compatibility ist der Renderer gut für die Zukunft aufgestellt. Mit modern werden aktuelle Schnittstellen wie Vulkan unterstützt und demnach auch aktuelle Hardware, während durch compatibility Abwärtskompatibilität mit OpenGL ES 3.0 und OpenGL 3.3 gewährleistet wird. Man kann Godot also unabhängig von der angestrebten Zielplattform einsetzen, für moderne Hardware nutzt man modern und für ein breiteres Spektrum inkl. älterer Mobilgeräte wählt man compatibility. Moderne Technologien wie bspw. AMD FSR 1.0 oder SDFGI werden bereits jetzt vom modern Backend unterstützt. Die Bestrebung, zukünftig auch AMD FSR 2.0 zu unterstützen, existiert ebenfalls.

Standardmäßig liefert Godot 4, im Gegensatz zu 3.x, nur noch die eigene Physik-Engine mit, die in erster Linie auf Einfachheit und Anpassbarkeit ausgelegt ist. Dafür ist es mit Version 4.0 möglich, andere Physik-Engines (PhysX, Jolt, …) per GDExtension zur Laufzeit einzubinden, ohne dass Godot neu kompiliert werden muss.

Mit GDScript 2.0 wurden die Möglichkeiten der Sprache durch bspw. Lambdas und Ausbau der Enum-Funktionalitäten deutlich erweitert.

Das neue Erweiterungssystem GDExtension ermöglicht es, die Funktionalität auszubauen, ohne dass dafür Godot neu kompiliert werden muss.

Die fehlenden Teile

Als noch fehlende Teile identifiziert Juan die folgenden Funktionalitäten:

Streaming

Um riesige Szenen oder sogar OpenWorlds zu unterstützen, ist die effiziente Nutzung des Speichers vonnöten. “Streaming” bezeichnet eine Technologie, mit der Assets erst bei Bedarf nachgeladen werden und nicht bereits zu Beginn einer Szene. Dabei wird zwischen Texture-, Mesh-, Animation-, und Audio-Streaming unterschieden. Wobei die effiziente Implementierung von Mesh-Streaming wohl die größte Herausforderung darstellt.

Low Level Zugriff aufs Rendering

Beim Rendering gibt es, unabhängig von der Architektur, keine one size fits all-Lösung. Daher sind Entwickler größerer Studios es gewohnt, dass sie Zugriff auf den Renderingprozess haben, um eigene Lösungen für bspw. das Post-Processing oder Rendering-Techniken zu integrieren. Um so etwas, ohne Godot selbst anzupassen, verwirklichen zu können, muss die API für GDExtension noch deutlich erweitert werden.

Verbesserungen am Szenensystem

Server sind die eigentlichen Arbeitspferde bei Godot. Sie werden vom Szenensystem benutzt, um die Arbeit für Physik, Rendering etc. zu verrichten. Mit Godot 4 wurden zwar alle Server deutlich verbessert, sodass sie mittlerweile auch Multithreading unterstützen, aber das Szenensystem ist weiterhin Single-Threaded. Das bedeutet, dass komplexe Szenen, also mit vielen Unterknoten, weiterhin nur auf einem CPU-Kern ausgeführt werden und somit langsamer als eigentlich möglich laufen. Aber es gibt schon einen Vorschlag, wie man dieses Problem lösen kann.

Schwarmsystem

Das Szenensystem von Godot ist auf Flexibilität und leichte Benutzbarkeit mit wenigen hundert Knoten ausgelegt. Aber es kann Situationen geben, wo dies nicht mehr ausreicht. Ein gutes Beispiel für eine solche Situation ist die “Bullet Hell”, wie sie devmar mit Godot 3.4 gezeigt hatte, bei der es darum geht, Tausende simpler Objekte zu verwalten. Um die Umsetzung solcher Systeme deutlich zu vereinfachen, gibt es den Vorschlag für ein Schwarmsystem.

VCS-Support für große Teams

Godot nutzt textbasierte Dateiformate für Projektdateien, Szenen etc. Dadurch ist generell eine hohe Kompatibilität zu Versionskontrollsystemen (VCS) gegeben, da dadurch Änderungen (mit etwas Übung) durch den Menschen validierbar sind und mögliche Merge-Konflikte gut behandelt werden können. Die Integration von VCS in die Godot-Entwicklungsumgebung könnte aber noch deutlich verbessert werden, um bspw. Änderungen besser erkennbar zu machen und Asset-Änderungen möglichst in Echtzeit anzuwenden.

Kommerzieller Asset-Store

Auch wenn AAA-Studios eigentlich alle Assets selbst erstellen bzw. exklusiv für sich erstellen lassen, ist im AA-Bereich der Einkauf in Assets-Stores durchaus gängig, sofern die Qualität stimmt. Die aktuelle Asset-Library enthält ausschließlich OpenSource-Assets. Durch die Gründung einer eigenen Stiftung ist mittlerweile der Weg frei, einen Store einzuführen, welcher Assets für Geld anbietet, ähnlich wie der Unity Asset Store oder der Unreal Engine Marketplace. Ich halte es für realistisch, dass durch einen solchen Store qualitativ hochwertige Assets für die einfache Nutzung in Godot entstehen werden.

Genre-spezifische Templates

Jeder, der schon mal mit der Unreal Engine “herumgespielt” hat, hat Bekanntschaft mit den vorgefertigen Projekttemplates gemacht. Sie stellen einen guten Einstieg nicht nur für schnelles Prototyping dar. Ähnliche Templates existieren zwar teilweise in der Asset-Library, aber das Niveau, was Konfigurierbarkeit und Umfang angeht, ist dann doch etwas anderes.

Visual Scripting

Godot 3 hatte Visual Scripting, was mit Godot 4 wieder abgeschafft wurde. Der Umfang war meines Wissens deutlich geringer als das, was Unreal Engine Blueprints ermöglichen. Aber gerade in Kombination mit konfigurierbaren Templates könnte Visual Scripting neue Möglichkeiten zur Konfiguration eröffnen.

Spezielle Oberflächen für Artists

Beim Editieren von Shadern, Effekten oder Animationen bietet die Godot Engine zwar vergleichbare Möglichkeiten wie z.B. die Unreal Engine, aber der Weg dahin ist komplett unterschiedlich. Während die Unreal Engine spezielle Oberflächen für das jeweilige Editieren solcher “Spezialaufgaben” zur Verfügung stellt, die dann alles für die jeweilige Aufgabe bereitstellen, sieht es bei Godot leider (noch) anders aus. Juan zeigt dies in seinem Artikel am Beispiel des Editierens eines Partikelsystems, welches das Verständnis folgender Godot-Subsysteme benötigt:

• GPUParticle-Knoten
• GPUParticlesMaterial-Ressource bzw. optional ein dedizierter Shader
• Mesh-Ressource für jeden Durchlauf
• Mesh-Material-Ressource für jede Fläche des Meshs bzw. optional ein dedizierter Shader

Dies macht das Arbeiten für hochspezialisierte Artists (VFX-/Effekt-Artists, Technical-Artists, …), wie es im AAA-Bereich üblich und notwendig ist, unnötig kompliziert. Daher werden dafür auch ähnlich spezialisierte Oberflächen wie in der Unreal Engine benötigt, um effizient bei so hoher Spezialisierung genutzt zu werden. Solche Oberflächen könnten auch per Plug-In nachgeliefert bzw. von dritten geliefert werden, die generelle Funktionalität ist ja bereits in Godot vorhanden.

Fazit

Mit Godot 4 ist die Godot Engine schon ganz gut gewappnet. Version 4.0 wird planmäßig noch einiges an offenen Baustellen haben, was sich dann mit den kommenden 4.x Versionen nach und nach verbessern soll. Wie beschrieben, ist ein Teil der fehlenden technischen Funktionalitäten relativ unkompliziert zu implementieren und erfordert in erster Linie Zeit. Andere Dinge wie bspw. spezialisierte Oberflächen für Artists benötigen passendes Feedback von denen, für die sie gedacht sind. Alles in Allem interpretiere ich es so, dass Godot 4 einen sehr guten Startpunkt darstellt, um als größeres Studio eine Inhouse-Engine darauf aufzubauen. Sicherlich wäre es schön, wenn ein Teil einer solchen Inhouse-Weiterentwicklung wieder in das ursprüngliche Projekt zurückfließen würde.

Für einen genaueren Blick kann ich den Originalartikel empfehlen.