Godot 4.7 Versionsübersicht: Architektonische Innovationen, Entwickler-Ökosystem und Produktionsstandards

Godot, einer der wichtigsten und innovativsten Vertreter im Ökosystem der Open-Source-Game-Engines, hat mit der am 18. Juni 2026 veröffentlichten stabilen Version (stable release) 4.7 einen kritischen Reifegrad in Bezug auf architektonische Flexibilität, grafische Genauigkeit und Entwickler-Ergonomie erreicht 1. Während sich frühere Versionen auf die Stabilisierung der grundlegenden Systeme der Engine und die Behebung von Kernfehlern konzentrierten, weist die Version 4.7 eine „auf Produktion und Workflow ausgerichtete“ Struktur auf, die direkt auf die Beseitigung von Engpässen abzielt, mit denen professionelle Studios und Indie-Entwickler in ihrer täglichen Arbeit in der Produktionsphase konfrontiert sind 3. Mit dem am 18. August 2026 veröffentlichten Wartungs-Update 4.7.2 wurden zudem PCSS-Schattenkoordinaten, die Leistung von Mäusen mit hoher Abtastrate (polling rate) unter Windows und kleinere Unstimmigkeiten in Multiplayer-Replikationsszenarien behoben, wodurch die Stabilität der Engine in der Produktionsumgebung (production-ready) gefestigt wurde 5.

Anstatt eine von Grund auf neue Physik-Engine oder eine komplett neu geschriebene Render-Pipeline anzubieten, ist Godot 4.7 ein tiefgehendes Verbesserungspaket, das die bestehenden Forward+- und Mobile-Render-Infrastrukturen erweitert, chronische Probleme bei Benutzeroberflächen- (UI-)Animationen löst, mobile Entwicklungsprozesse standardisiert und moderne Hardware-Anforderungen wie High Dynamic Range (HDR) erfüllt 2. Bewertungen durch die Community und Branchenprofis zeigen, dass insbesondere Entwickler, die seit vielen Jahren verschiedene geschlossene Engines (z. B. Unity) nutzen, von den Render-Fähigkeiten und den Möglichkeiten zum schnellen Prototyping von Godot 4.7 beeindruckt sind 2. Dieser Bericht untersucht die von Godot 4.7 gebotenen technischen Innovationen, die Auswirkungen dieser Innovationen auf die Softwarearchitektur, das Feedback der Community und strategische Überlegungen von Projekten bei Übergangsprozessen zu dieser neuen Version in einem äußerst umfassenden analytischen Rahmen.

Innovationen im Bereich der Render-Engine und der 3D-Grafik-Infrastruktur

Die Grafik-Pipeline gehört zu den Bereichen, in denen Godot 4.7 die deutlichsten Fortschritte verzeichnet hat. Das empfindliche Gleichgewicht zwischen Fotorealismus und Leistungsoptimierung in der modernen Spieleentwicklung hängt von der Vielfalt der von der Render-Engine bereitgestellten Werkzeuge und der Kapazität zur Hardwarebeschleunigung ab. Die neue Version bietet analytische Funktionen, die in vielen Schichten, von Lichtberechnungen bis hin zum Materialmanagement, Industriestandards entsprechen.

Flächenlichter (AreaLight3D) und Beleuchtungsphysik

Beleuchtungsmodelle sind die grundlegendsten Elemente, die die visuelle Glaubwürdigkeit von 3D-Render-Engines bestimmen. Vor Godot 4.7 mussten Entwickler Punktlichter clustern oder emissive (emittierende) Materialien verwenden, die durch globale Beleuchtung (Global Illumination) unterstützt wurden, um rechteckige oder großflächige Lichtquellen (z. B. Leuchtreklamen, riesige industrielle Fenster, Fernsehbildschirme, Leuchtstoffröhren oder weiche Studiobeleuchtungen) zu simulieren 1. Diese temporären und indirekten Lösungen verursachten sowohl unnötige Kosten für die GPU in Bezug auf die Leistung als auch Unzulänglichkeiten hinsichtlich der Kantenschärfe (Halbschatten bzw. Penumbra) und der physikalischen Korrektheit der erzeugten Schatten.

Das mit Godot 4.7 zur Knotenbogen-Architektur hinzugefügte AreaLight3D-Node bietet eine analytische Echtzeit-Render-Lösung, die dafür sorgt, dass Licht nicht von einem einzigen unendlich kleinen Punkt, sondern von einer begrenzten zweidimensionalen rechteckigen Oberflächenfläche abgestrahlt wird 1. Diese strukturelle Architektur erzeugt natürliche und sich allmählich weich anfühlende Schattenübergänge in Abhängigkeit von der physischen Größe der Lichtquelle und garantiert gleichzeitig, dass sich die rechteckige Form der Lichtquelle auf glatten und reflektierenden Oberflächen in der Szene (specular reflections) korrekt widerspiegelt 1. Dieser Ansatz, der kein Raytracing erfordert, erhöht die Beleuchtungsqualität von Szenen drastisch, ohne das Leistungsbudget zu überschreiten. Im Hinblick auf architektonische Visualisierung, Indoor-Horrorspiele und cineastisches Atmosphären-Design bietet diese Entwicklung den Szenendesignern einen wesentlich saubereren Workflow und eine überlegene visuelle Qualität.

Unterstützung für High Dynamic Range (HDR) Bildschirmausgabe

Mit den Fortschritten in der Anzeigetechnologie hat Hardware, die die Grenzen des Standard-sRGB-Farbraums sprengt, begonnen, auf dem Endverbrauchermarkt zum Standard zu werden. Godot 4.7 hat die Fähigkeit erhalten, die hochdynamischen Beleuchtungsdaten, die die Engine intern im Gleitkommaformat (floating point) berechnet, über HDR-APIs auf Betriebssystemebene direkt an unterstützte Bildschirme zu übertragen 2. Diese Funktion, die theoretisch Helligkeitswerte von bis zu 10.000 Nits unterstützt, ermöglicht es, Elemente wie Explosionen, Neonlichter, Zaubereffekte oder direktes Sonnenlicht mit einer blendenden Helligkeit, tiefem Schwarz und einem viel größeren Farbraum (color gamut) auf dem Bildschirm darzustellen 3.

Da die Unterstützung der HDR-Ausgabe eine extrem low-level Integration mit Gerätetreibern und Fensterverwaltungen des Betriebssystems (window manager) erfordert, sind die Plattform- und Render-Engine-Abhängigkeiten spezifisch. Die Konfigurationsmatrix bezüglich der Integration dieser Funktion ist in der folgenden Tabelle aufgeführt:

Betriebssystem / PlattformHDR-UnterstützungsstatusErforderliche Render-EngineArchitektur- und IntegrationshinweiseWindowsVollständig unterstütztForward+ oder MobileDie Windows HD Color-Einstellungen auf Betriebssystemebene müssen aktiviert sein und ein kompatibler Monitor verwendet werden.macOSVollständig unterstütztForward+ oder MobileDirekt in Apples native HDR-Verwaltungs-APIs und die Metal-Schnittstelle integriert.iOS & visionOSVollständig unterstütztForward+ oder MobileKompatibel mit den hohen Helligkeitsfähigkeiten und XDR-Bildschirmstrukturen mobiler Apple-Geräte.Linux (Wayland)Vollständig unterstütztForward+ oder MobileFunktioniert nur unter modernen Wayland-Compositorn. Erfordert ein umfassendes Fensterverwaltungsprotokoll.Linux (X11)Nicht unterstütztNicht anwendbarDeaktiviert aufgrund von Farbtiefenbeschränkungen in der alten X11-Architektur. Entwickler sollten zu Wayland wechseln.AndroidNicht unterstütztNicht anwendbarDerzeit aufgrund der breiten Android-Hardware-Fragmentierung (fragmentation) nicht verfügbar.Web (HTML5)Nicht unterstütztNicht anwendbarDie Einschränkungen der Browser-Grafik-APIs von WebGL und WebGPU haben die HDR-Ausgabe noch nicht standardisiert.

Wie aus der Tabelle hervorgeht, sollte die Verwendung von HDR eher als eine optionale visuelle Anreicherungsschicht betrachtet werden, die auf unterstützten Plattformen aktiviert wird, anstatt eine ganzheitliche Anforderung (requirement) zu sein 4. Entwickler sollten HDR nicht als Grundlage für das gesamte Artdirection-Konzept nutzen, sondern vielmehr als eine Aufbereitung, um Projekte, die auf dem Standard Dynamic Range (SDR) bereits gut aussehen, weiter zu bereichern 4.

Vulkan Hardware Raytracing-Infrastruktur

Einer der größten technologischen Wendepunkte in der Gaming-Industrie, die Hardware-Raytracing-Technologie, wurde mit Godot 4.7 als Low-Level-Infrastruktur (plumbing) in die Vulkan-Architektur der Engine integriert 2. Diese Version enthält keine direkten Endbenutzer-Funktionen wie „Raytracing-Reflektionen“ (Ray-traced reflections) oder „Path Tracing“, die Spieler oder Entwickler mit einem einzigen Klick aktivieren können 10. Stattdessen wurden der Engine die grundlegenden Voraussetzungen für das Raytracing – wie das Erstellen von Beschleunigungsstrukturen (acceleration structures) und direkte Ray-Dispatch-Fähigkeiten (Strahlenaussendung) innerhalb der Vulkan-Render-Pipeline – verliehen 2.

Dieser strategische ingenieurtechnische Schritt bietet eine standardisierte Grundlage für große Studios, um ihre eigenen maßgeschneiderten Raytracing-Lösungen (z. B. spezielle Beleuchtungs-Shader oder Spiegelsysteme) zu programmieren. In den vergangenen Jahren waren Teams, die Hardware-Raytracing nutzen wollten, von speziellen Godot-RTX-Forks abhängig, die von NVIDIA oder unabhängigen Entwicklern gewartet wurden 2. Diese mit 4.7 kommende Kernintegration ist ein sicherer Beweis dafür, dass integrierte Raytracing-Funktionen in zukünftigen Versionen wie Godot 4.8 und 4.9 direkt im Hauptstrang (mainline) laufen werden 2.

DrawableTexture2D und Laufzeit-Texturverarbeitung

Der in Spielmechaniken häufig benötigte Vorgang des „Zeichnens auf Texturen zur Laufzeit“ (runtime texture drawing) wurde in früheren Versionen durch indirekte und kostspielige Operationen ausgeführt, wie etwa das Erstellen eines separaten Viewports, um die Szene in diesen Viewport zu rendern, oder das Senden von Low-Level-GPU-Befehlen über komplexe RenderingDevice-APIs. Godot 4.7 abstrahiert diese Schwierigkeiten und stellt die Klasse DrawableTexture2D vor, eine äußerst zugängliche und performante API 2.

DrawableTexture2D ermöglicht Entwicklern das direkte Schreiben von Pixeldaten oder Pinselstrichen auf eine Textur (texture) über Standard-Blit-Aufrufe 2. Diese Funktion stellt sicher, dass selbst Entwickler ohne tiefe Kenntnisse der Rendering-APIs komplexe Effekte einfach erstellen können. Beispielsweise können aufgedeckte Kriegsnebelmasken (fog of war) in Strategiespielen, dynamische Reifenspuren in Rennspielen, Mechaniken, bei denen Charaktere Farbe auf Oberflächen werfen (paint tools), Werkzeuge, mit denen Spieler frei zeichnen können, Spiele mit Kratz-/Enthüllungsmasken (reveal mask) oder Rüstungstexturen, die bei Beschädigung deformiert werden (scratch effects), mit dieser API entwickelt werden, ohne das Hauptsystem zusätzlich zu belasten 1.

Pixel Art und 3D-Optik: Nearest-Neighbor Skalierung

Traditionelle 3D-Render-Engines verwenden standardmäßig eine bilineare (bilinear) Filterung, wenn sie niedrig aufgelöste Texturen, Verkleidungen oder Bildschirmausgaben auf den Bildschirm projizieren. Obwohl dieser Glättungsalgorithmus bei fotorealistischen Grafiken hervorragende Ergebnisse liefert, führt er insbesondere bei Spielen im Retro-Stil der 90er Jahre (PS1-Ästhetik) oder bei 3D-Pixel-Art-Spielen mit niedriger Auflösung zu unerwünschten Unschärfen (blurring) 2. Viele Entwickler innerhalb der Community mussten allein zur Beseitigung dieser Unstimmigkeiten spezielle Shader schreiben. Godot 4.7 integriert die Nearest-Neighbor-Skalierungsoption für 3D-Ansichtsfenster (Viewports) als Standard-Engine-Funktion und bietet ein hervorragendes Werkzeug zur ästhetischen Kontrolle, das die Schärfe und die abgehackten Linien von Pixeln selbst bei reduzierter Auflösung beibehält 1. Diese Funktion bildet eine unverzichtbare Infrastruktur für Indie-Produktionen, die moderne 3D-Funktionen mit einem nostalgischen Pixel-Art-Ansatz verbinden.

Shader, Effekte und Materialverbesserungen

Auch Post-Processing-Effekte (Nachbearbeitung) und Partikelsysteme, die die visuelle Sprache des Spiels definieren, wurden detaillierten Optimierungen unterzogen. Die größte Neuerung für Entwickler, die an codebasierten Text-Shadern (text shaders) arbeiten, sind Inline-Shader-Vorschauen im Editor. Wenn nun eine mathematische Änderung im Shader-Code vorgenommen wird (z. B. eine Änderung der Frequenz einer Wellenfunktion), können die Änderungen in Echtzeit direkt im Hintergrund des Code-Editors in der Vorschau angezeigt werden, ohne dass die Engine neu kompiliert oder in einen anderen Arbeitsbereich gewechselt werden muss 2. Dies ist eine Entwicklung, die die Iterationsgeschwindigkeit enorm steigert.

Auf der Seite der physikalisch basierten Render-Materialien (PBR) wurden die Klarlack-Render-Algorithmen (clearcoat), die zur Simulation von Oberflächen wie Autolack oder nassem Boden verwendet werden, verbessert; die Lichtbrechung auf diesen transparenten Schichten wurde genauer gestaltet 1. Render-Durchläufe (render passes) verfügen nun über eigene separate Umgebungseinheitspuffer (environment uniform buffers), was Flexibilität in komplexen Post-Processing-Ketten bietet 1. In 3D-Partikelsystemen wurden Entwicklern erweiterte Steuerelemente über Skalierung (scale) und Rotation (rotation) von Partikeln zur Verfügung gestellt, und mathematische Korrekturen der Winkelgeschwindigkeiten (angular velocity) von Partikeln wurden angewendet, um Simulationen organischer erscheinen zu lassen 1.

Benutzeroberflächen- (UI) Engineering und Animations

systeme

In der Spieleentwicklung ist das Design von Benutzeroberflächen ein Bereich, der im Vergleich zur Kernmechanik-Programmierung oft viel mehr Zeit in Anspruch nimmt, stark iterativ und äußerst fragil ist 9 . Damit sich UI-Elemente an wechselnde Auflösungen auf dem Spielbildschirm anpassen können, bietet Godot von Anfang an ein robustes, knotenbasiertes (node-based) Layout-System. Die Version 4.7 löst jedoch ein tiefgreifendes strukturelles Problem bei der Interaktion von UI-Elementen mit Animationen und stellt damit eines der fähigsten UI-Toolkits der Branche vor 9 .

Control-Knoten-Offset-Transformationen (Offset Transforms)

Das UI-Layout-System von Godot basiert auf hierarchischen Container-Knoten. Control-Knoten (Schaltflächen, Panels, Bildlaufleisten usw.), die in einen HBoxContainer (horizontaler Container) oder VBoxContainer (vertikaler Container) platziert sind, werden streng von den automatischen Sortier- und Platzierungsalgorithmen des Containers verwaltet 1 . In früheren Versionen, wenn ein Designer die Skalierung (scale), den Rotationswinkel (rotation) oder die Position (position) einer Schaltfläche mit einer Tween-Animation vergrößerte, um bei einem Mausübertragen (hover state) visuelles Feedback zu erzeugen, wurde diese Änderung vom übergeordneten Container als „Layout-Verzerrung“ interpretiert. Der Container versuchte sofort, eine Neuberechnung durchzuführen und die UI-Elemente gemäß seiner eigenen algorithmischen Logik neu zu positionieren, was dazu führte, dass Schaltflächen unerwartet zurücksprangen (snap back), Menüs flackerten und Entwickler gezwungen waren, quasi gegen das Containersystem zu kämpfen (fighting layout) 1 .

Die kritischste Lösung, die Godot 4.7 für das UI-Engineering bringt, ist das System der Control-Offset-Transformationen (offset transforms), das visuelle Transformationen vom logischen Box-Modell (box model) trennt. Die neu hinzugefügten offset_transform_* Eigenschaften (Position, Rotation, Skalierung) bestimmen, wie das UI-Element visuell gerendert wird, während seine logischen Koordinaten und sein eingenommener Bereich im Originalzustand verbleiben 1 . Das bedeutet, wenn eine Schaltfläche mithilfe von Offset-Transformationen visuell um 20 % vergrößert oder auf dem Bildschirm verschoben wird, erkennt der übergeordnete Container diese Änderung nicht als Layout-Aktualisierung und behält seine Platzierungsberechnungen bei 4 . Diese Isolierung gibt UI-Programmierern und technischen Künstlern die vollständige Freiheit, flüssige, dynamische und flexible Benutzeroberflächen-Animationen zu entwerfen, ohne die Containerstruktur oder die Verankerungslogik (anchoring) zu beschädigen 4 . Community-Feedback bestätigt, dass diese Funktion Hunderte Zeilen von Workaround-Code in Menüdesigns überflüssig gemacht hat und ein „Lebensretter“ ist 9 .

Rich-Text-Labels (RichTextLabel) und konische Farbverläufe

Die Fähigkeiten von Benutzeroberflächen zur Datenanzeige wurden verbessert, um den Anforderungen moderner Spiele an die dynamische Schriftgrößenanpassung gerecht zu werden. Bilder, die mit dem [img]-Tag in ein RichTextLabel eingebettet sind (zum Beispiel ein Xbox-Controller-„A“-Button oder ein spezielles Emoji-Symbol, das im Text angezeigt wird), können nun in Abhängigkeit von der Inline-Textgröße positioniert werden 1 . Entwickler können relative, CSS-ähnliche Definitionen wie [img height=1em] verwenden, um sicherzustellen, dass das Bild beim Ändern der Spielauflösung, von Sprachübersetzungen oder Barrierefreiheitseinstellungen automatisch proportional mit dem Textfont skaliert wird 3 .

Darüber hinaus wurde der Bereich für 2D-Effekte und UI-Design um die Klasse GradientTexture2D erweitert, die den Modus FILL_CONIC (konische Füllung) erhalten hat. Im Gegensatz zu standardmäßigen linearen oder radialen Farbverläufen verteilt diese konische Farbverlaufsfunktion die Farben ähnlich wie CSS-Stile durch eine Drehung (sweep) um den Mittelpunkt. Diese mathematische Ergänzung bildet eine äußerst praktische Grundlage beim Schreiben von 2D-Shadern, um kreisförmige Fortschrittsbalken, Munitionsanzeigen, Radarscanning-Effekte oder Illusionen von vorgetäuschter 3D-Zylinderschattierung (fake 3D shading) zu erzeugen 3 .

Editor-Ökosystem und Verbesserungen des Entwickler-Workflows

Game-Engines sind nicht nur Compiler-Engines, die ausführende Dateien erzeugen; sie sind auch Produktivitäts- und Entwicklungssoftware (IDE), in der Designer, Künstler und Programmierer Tausende von kognitiven Stunden verbringen. In diesem Zusammenhang beeinflusst die Flüssigkeit der Editorschnittstelle selbst direkt die Entwicklungszeit. Godot 4.7 enthält zahlreiche Qualitätsupdates (Quality of Life - QoL), die das Editor-Erlebnis optimieren, die Anzahl der Klicks reduzieren und die kognitive Belastung (cognitive load) bei großen Projekten verringern.

Die Geburt des Asset Store (Ehemalige Asset Library)

Die Asset Library (Asset-Bibliothek), die Godot-Entwicklern viele Jahre lang den Download von von der Community erstellten Tools ermöglichte, wurde durch das Konzept des Asset Store (Asset-Shop) ersetzt, der von Grund auf mit modernen API-Standards neu geschrieben wurde 2 . Dies ist keine rein kosmetische Namensänderung, sondern eine infrastrukturelle Architekturüberarbeitung. Im alten System fror der Haupt-Editor-Thread (main thread) ein, während massive Asset-Pakete vom Server heruntergeladen oder Suchanfragen verarbeitet wurden, was zu Hängern führte. Die neue Store-API nutzt Hintergrund-Threads (background threading) aktiv aus 1 . Dadurch bleibt die Editor-Benutzeroberfläche beim Herunterladen von Inhalten vollständig responsiv (responsive) 3 . Darüber hinaus wurden das Zoomen von Vorschaubildern zur genaueren Betrachtung von Assets, die Anzeige aktueller Community-Bewertungen (ratings) und ein wesentlich übersichtlicherer Kategoriebaum (Schaufenster) integriert 3 .

### Inspektor-Verbesserungen (Inspector) und Reduzierung von Animationsspuren

Einer der zeitaufwendigsten Punkte für Entwickler bei großen 3D-Projekten ist die Übertragung komplexer Datenstrukturen zwischen Knoten (nodes). Dank eines neuen Dashboard-Tools, das dem Inspector-Panel in Godot 4.7 hinzugefügt wurde, ist es nun möglich, anstelle des manuellen Kopierens und Übertragens von Variablen (wie X-, Y-, Z-Rotationen oder Materialfarbcodes) zwischen ähnlichen Knoten eine ganze Eigenschaftsgruppe (property section) gebündelt zu kopieren und mit einem einzigen Klick in denselben Bereich eines anderen Knotens einzufügen 1 . Diese Mechanik reduziert die manuelle Fehlerquote auf Null, insbesondere beim Massenimport von Materialparametern oder hierarchischen Physikkonfigurationen, und spart enorm viel Zeit 2 .

Das Panel für AnimationPlayer und Animationsspuren (Animation Tracks), das zur Verwaltung von Animationen komplexer Szenen verwendet wird, wurde ebenfalls ergonomisch überarbeitet. Um zu verhindern, dass der Bildschirm bei der Animation eines komplexen Charakter-Skeletts (skeleton) mit 40 bis 50 verschiedenen Spuren überflutet wird und um Scroll-Chaos zu vermeiden, wurde die Funktion „Nicht verwendete Knotenspuren einklappen“ (track collapsing) eingeführt 1 . Schlüsselbilder (keyframes) auf eingeklappten Spuren werden in einer einzigen Zeile als „aggregierte Darstellung“ (aggregate representation) präsentiert; auf diese Weise behalten Animateure weiterhin eine visuelle Orientierung über das allgemeine Animations-Timing, ohne die spezifischen Details innerhalb der eingeklappten Spuren sehen zu müssen 3 .

3D-Szenenausrichtung (Snapping) und Lineal-Verbesserungen

Die Werkzeuge zur Szenenmanipulation wurden für 3D-Künstler und Level-Designer, die sich mit Leveldesign und Weltenbau (world building) beschäftigen, stark erweitert. Vor Godot 4.7 basierte das Zusammenfügen von Assets und das Platzieren auf Böden meist auf Augenmaß oder der Eingabe numerischer Werte. Die neue Version bietet drei wesentliche Toolsets, die Industriestandards entsprechen:

Scheitelpunkt-Ausrichtung (Vertex Snapping): Wenn die zugewiesene Tastenkombination im Editor gedrückt gehalten wird (standardmäßig 'B'), kann der Entwickler direkt einen bestimmten Scheitelpunkt eines 3D-Meshes (Mesh) auswählen und ihn mit millimetergenauer Präzision an den Scheitelpunkten anderer Objekte einrasten lassen (snap) 1 . Dies verhindert das Entstehen von Lücken beim Erstellen modularer Dungeon-Designs oder Bausteine.
Path3D- und Kollisionsausrichtung (Collider Snapping): Path3D-Knotenpunkte, die zum Zeichnen von Bahnen in Szenen verwendet werden, können jetzt nicht nur an der Kameraebene des Viewports (camera plane) ausgerichtet werden, sondern auch direkt an den Oberflächen physischer Kollider (colliders) in der Szene 1 . Diese Funktion bietet eine lebenswichtige Erleichterung beim Zeichnen von KI-Patrouillenpfaden (patrol paths) oder Rennstreckenverläufen, die sich über bergige oder geneigte Gelände bewegen 3 .
Erweitertes Lineal (Ruler): Das mit der Umschalttaste (Shift) verwendete 3D-Messwerkzeug zeigt jetzt nicht mehr nur den absoluten Abstand zwischen zwei Punkten an (z. B. 15 Meter), sondern auch die relativen Längenvektoren entlang jeder einzelnen Koordinatenachse im dreidimensionalen Raum (z. B. 10m auf der X-Achse, 5m auf Y, 10m auf Z) separat an 1 . Dieses geometrische Feedback ist in der ersten Designphase, dem sogenannten Blockout, von entscheidender Bedeutung. Darüber hinaus wurden die 3D-Kamerasteuerungen mit dem eingebetteten Spielfenster (embedded game view) im Motor vereinheitlicht (unified), sodass der Entwickler seine Tastenkombinationen oder sein Navigationslayout auf beiden Seiten gleich halten kann 3 . Um das Auffinden gewünschter Objekte in langen Listen zu erleichtern, wurde den PopupMenu-Fenstern eine Suchleiste hinzugefügt; und in den Bildschirmen zum Erstellen neuer Knoten (Node) oder Ressourcen (Resource) (Create Dialog) wurden Filtermechanismen wie „Nur Benutzerdefinierte anzeigen“ (Show Custom) integriert 1 . Wenn ein Entwickler, der im Code-Editor arbeitet, auf den Dateinamen oben im Skriptfenster doppelklickt, wird automatisch hervorgehoben (highlighted), wo sich die Datei im Dateisystem auf der linken Seite befindet, wodurch das Verlieren in großen Datenbäumen verhindert wird 3 . Im Remote Scene Inspector (Remote-Szenen-Inspektor) werden Enum-Werte nun nicht mehr nur als bedeutungslose ganze Zahlen (0, 1, 2) angezeigt, sondern mit ihren repräsentierten String-Namen (string names) im Code 3 .

Mobile Entwicklung, Virtual Reality (XR) und Leistungsoptimierungen

Während der Anteil von Mobilgeräten und Virtual-Reality-Headsets (Plattformen) in der Spieleindustrie kontinuierlich wächst, macht Godot 4.7 spezielle Software-Hooks, die auf die Hardware-Einschränkungen dieser Geräte zugeschnitten sind, zu Standard-Kernfunktionen.

Eingebaute VirtualJoystick-Integration

Teams, die Action- oder Rollenspiele für mobile Plattformen entwickeln, waren lange Zeit auf Drittanbieter-Plugins oder von Grund auf neu geschriebene, schwer zu wartende Eingabecodes für virtuelle Touch-Steuerelemente auf dem Bildschirm angewiesen. Community-Plugins bergen bei jedem Engine-Update das Risiko von Inkompatibilitäten4. Godot 4.7 löst diese Fragmentierung grundlegend, indem es einen VirtualJoystick-Knoten bereitstellt, der direkt in den Engine-Kern integriert ist1.

Diese Integration unterstützt drei verschiedene Interaktionsmodelle, die perfekt zu klassischen Steuerungsschemata im mobilen Spieldesign passen:

Joystick-ModusMechanismus und BenutzerverhaltenIdeales AnwendungsszenarioFest (Fixed)Die Position des Joystick auf dem Bildschirm ist fixiert. Der Spieler muss seinen Daumen in diesen spezifischen Bereich des Bildschirms ziehen. In seiner Mitte befindet sich eine klassische „Tote-Zone“-Einstellung (dead zone).Retro-Arcade-Ports, konsolenartige feste Controller1.Dynamisch (Dynamic)Sobald der Spieler einen bestimmten Bereich des Bildschirms berührt, erscheint der Joystick an diesem Punkt. Wenn der Finger abgehoben wird, verschwindet er sofort und setzt seine Position zurück.Shooter, die schnelle Reaktionen erfordern1.Folgend (Following)Beginnt mit derselben Logik wie der dynamische Modus, aber wenn der Daumen des Spieler die Bewegungsgrenzen überschreitet, verschiebt sich auch die Mittelachse des Joysticks und folgt dem Finger, sodass der Spieler ständig in Kontakt bleibt.RPGs oder Endless Runner, bei denen sich der Charakter ununterbrochen bewegt1.

Darüber hinaus wurde das Auslesen von Beschleunigungsmesser- und Gyroskopdaten von Gamepads über die API ermöglicht, wodurch die Integration von Neigungs- und Bewegungssteuerungen (Motion-Controls), die von Mobil- oder Konsolen-Gamepads geboten werden, stabilisiert wurde3.

GABE (Godot Android Build Environment) und On-Device-Entwicklung

Godots Vision, nicht nur Spiele für Android zu entwickeln, sondern als philosophische Haltung „die Spieleentwicklung direkt auf Android-basierten Tablets und Mobilgeräten“ (Godot Editor for Android) zu betreiben, hat in Version 4.7 einen großen Sprung gemacht. Dank einer speziellen Companion-App namens GABE (Godot Android Build Environment) verfügt der Godot-Editor, der auf Android-Geräten (zum Beispiel einem Samsung Galaxy Tab) läuft, direkt im Gerät über die Gradle-Exportunterstützung, die zum Erstellen von APKs oder AABs erforderlich ist3. Dies bedeutet, dass Entwickler den auf dem Gerät geschriebenen Code direkt auf dem Gerät kompilieren und vollständige Softwarepakete (APKs) erstellen können, ohne einen Computer zu benötigen4.

Auch die ergonomischen Einschränkungen des auf Android laufenden Editors wurden überwunden. Das eingebettete Spielfenster zur Laufzeit (embedded game window) ist nun nicht mehr starr, sondern in der Größe veränderbar und verschiebbar; dadurch können verschiedene Bildschirmseitenverhältnisse (Aspect Ratios) wie Querformat, Hochformat oder Tablet-Format auf einem einzigen Gerät getestet werden1. Der Skript-Schreibbildschirm wurde so gestaltet, dass er auf die Quer- und Hochformatsensoren des Geräts reagiert und gedreht werden kann (Landscape Coding), wodurch die Ergonomie beim Anschließen einer Tastatur verbessert wird4. Darüber hinaus hat die Bild-in-Bild-Funktion (Picture-in-Picture) Testprozesse viel modularer gemacht, sodass das Spiel selbst im Hintergrund überwacht werden kann1. Die Exportoptionen wurden erweitert, und die Startbildschirme (Splash Screens) von Android-Projekten können nun angepasst werden1.

An dieser Stelle muss jedoch auf Leistungswarnungen aus der Entwickler-Community hingewiesen werden. Obwohl Godots 3D-Engine über fortgeschrittene Funktionen verfügt, kann es insbesondere auf Mobilgeräten bei der Verwendung der Kompatibilitäts-Engine (GLES3/OpenGL) auf Geräten mit GPUs der Mittelklasse wie der Mali G68 zu Render-Einschränkungen kommen. Branchenanalysen (z. B. Reddit-Testberichte) zeigen, dass in einer einfachen Szene mit sehr wenigen Hintergrundobjekten und nur 3.000 Polygonen die Bildraten auf bis zu 38 FPS sinken können, es sei denn, die Auflösungsskalierung wird verringert16. Daher müssen Entwickler bei der Entwicklung von 3D-Produkten für die Android-Plattform maximale Aufmerksamkeit auf die Ansichtsfenster-Auflösungsskalierung (Viewport Resolution Scale), die Materialeinfachheit und die Vielfalt der Testgeräte legen16.

Erweiterte Realität (XR): Kompositionsschichten und Foveated Rendering

Die OpenXR-Architektur, die zum Branchenstandard auf dem Markt für Virtual Reality (VR) und Augmented Reality (AR) geworden ist, wurde mit Godot 4.7 produktionsorientierter gestaltet2. Während für die Plattformen Steam Frame und Android XR eine produktionsreife Unterstützung (Production-Ready) bereitgestellt wird, wurden die OpenXR-Aktionszuordnungen (Action Maps) auf die vier grundlegendsten Profile reduziert, um die Komplexität bei der Controller-Integration zu verringern1.

Bei der VR-Entwicklung ist die Lesbarkeit der Benutzeroberfläche (UI) das kritischste ergonomische Problem. Das Platzieren von Head-Up-Displays (HUDs) oder Texten in der Szene wie normale 3D-Geometrie (Eye-Buffer Rendering) führt aufgrund der Fokusdistanz und Pixeldichte der Linsen zu flackernden, verschwommenen und unleserlichen Texten. Das OpenXR-Kompositionsschicht-System (Composition Layer) bewegt Benutzeroberflächen aus dem normalen Spielwelt-Buffer heraus und rendert sie direkt auf die Projektionsschicht des Visiers (auf den Projektor)3.

Godot 4.7 hat die Kontrolle über diese Kompositionsschichten vertieft. Entwickler können nun:

Kompositionsschichten direkt mit dem XRCamera3D-Knoten in der Szene verknüpfen (Lock) und fixieren, um ultra-scharfe (crisp) HUD-Bildschirme zu entwerfen, die unabhängig davon, wie schnell der Spieler den Kopf dreht, ohne auch nur eine Millisekunde Verzögerung im Sichtfeld fixiert bleiben3.
Kompositionsschicht-Objekte mit der Weltgeometrie (World Geometry) abgleichen (Pairing), um Textschichten an bestimmten Koordinaten im Raum verankert (World-Locked) zu lassen3.

Im Kontext der Grafikleistung sind VR-Headsets (wie z. B. Meta Quest) Geräte mit enormen Auflösungen, und die Einsparung jeder einzelnen Millisekunde ist für den Komfort (Comfort) von vitaler Bedeutung4. In die Mobile-Render-Engine von Godot 4.7 wurde die Vulkan-Technologie für „unterabgetastete Bilder“ (Subsampled Images) integriert1. Diese Technologie reduziert die GPU-Speicherbandbreite (Memory Bandwidth) drastisch, indem sie die Pixel, die während Prozessen des Foveated Renderings (bei denen der Fokuspunkt des Auges scharf und das periphere Sichtfeld mit niedriger Auflösung gerendert wird) verarbeitet werden, mit geringerer Dichte speichert3. Dadurch wird ein großer Gewinn bei der Leistung und dem Akkuverbrauch

von Mobilgeräten erzielt 1 . Es wird empfohlen, für XR-Projekte standardmäßig die Mobile-Render-Engine zu verwenden 1 .

Physik-Philosophie und erweiterter 2D-Toolset

Physiksysteme und Kollisionsalgorithmen bilden das verhaltensbezogene Herzstück von Game-Engines. Mit Version 4.6 hatte Godot das hochperformante Jolt-Physics-Plugin als standardmäßige 3D-Physik-Engine in das Core-Ökosystem integriert. Entgegen einigen Gerüchten in der Branche hat Version 4.7 Jolt Physics weder ersetzt noch entfernt; die Jolt-Engine behält ihre Produktionsstabilität als Standard-Physik-Engine für neue 3D-Projekt und die Architektur von 4.7 bei 1 . Die eigentliche Physik-Revolution bringt Version 4.7 jedoch durch die Überwindung einer tiefgreifenden Einschränkung in den 2D-Kollisionsarchitekturen.

Freiheit der Einweg-Kollisionsrichtung (One-way Collision)

In 2D-Plattformspielen (wie z. B. Mario oder Hollow Knight, wo Wolken- oder Hängebrückenplattformen von unten durchsprungen und nach dem Passieren von oben betreten werden können) sind Einwegkollisionen eine häufig verwendete Mechanik. Vor Godot 4.7 ging die Physik-Engine starr und unveränderlich davon aus, dass der Vektor für die Einwegkollision in Richtung des lokalen „Oben“ (Up) des jeweiligen CollisionShape2D-Knotens zeigte ((0, -1)-Vektor) 3 . Wenn Spieldesigner die Kollisionsrichtung ändern wollten (z. B. eine Wand, die ein Charakter von rechts passieren, aber von links treffen kann), mussten sie zu schmerzhaften (painful) Tricks greifen, wie etwa das Drehen der physischen Struktur oder Rotation des Colliders völlig unabhängig von den visuellen Grafikknoten und dem Synchronisieren dieser beiden Strukturen 3 .

Mit dem Update 4.7 wurde der CollisionShape2D-Klasse eine neue Variable namens `one_way_collision_direction` (Einweg-Kollisionsrichtung) hinzugefügt 3 . Dank dieser Funktion kann der Richtungsvektor von Einweg-Interaktionen frei im 3D-Lokalraum über 360 Grad zugewiesen werden, ohne dass jemals die allgemeine Geometrie der Kollisionsform (Kasten- oder Kapselstruktur) verzerrt wird 3 . Dies macht das Codieren von starken Windströmungen, charakterverschiebenden Förderbändern, angewinkelten Schwerkraftzonen oder Gleitmechaniken von Plattformen weit eleganter und mathematisch korrekter, da unnötige Rotationsberechnungen entfallen.

Dynamische CSG-Glättung (Autosmooth)

Constructive Solid Geometry (CSG) ist ein Werkzeug, mit dem Spieldesigner ohne externe 3D-Modellierungsprogramme wie Blender oder Maya direkt in der Engine durch die Verwendung sich überschneidender einfacher geometrischer Formen (Würfel, Kugel, Zylinder) mithilfe von (Additions-, Subtraktions- und Schnittmengenoperationen) sofortige 3D-Level-Prototypen erstellen können 3 . Die erstellten CSG-Böden wirkten jedoch immer scharf, polygonarm und rau.

Die neue Autosmooth-Funktion (Automatische Glättung), die den CSG-Root-Knoten in Godot 4.7 hinzugefügt wurde, glättet diese scharfen polygonalen Strukturen prozedural auf Hardware-Ebene 3 . Der Parameter für den Glättungswinkel (Smoothing Angle) ist standardmäßig auf 50 Grad eingestellt; während Oberflächenübergänge unterhalb dieses Schwellenwerts automatisch als glatte Oberflächen (Smooth Faces) verarbeitet werden, behalten steilere Überschneidungen mit größerem Winkel ihre Kantenlinien (Sharp Faces) bei 3 . Je höher der Wert erhöht wird, desto aggressiver wird das Glättungsprofil angewendet; diese Funktion ermöglicht es nicht nur Teams, die Prototyping betreiben, sondern auch Studios, die Low-Poly-Produktionen erstellen, ihre CSG-Strukturen direkt in Endproduktqualität (Final Asset) in ihre Spiele zu übernehmen 3 .

API-Änderungen, Scripting und

Migrationsstrategien Jedes größere .x-Versionsupdate (Minor Release) ändert einige API-Signaturen (Application Programming Interface), um die Engine-Leistung im Hintergrund zu verbessern, während neue Funktionen hinzugefügt werden, und enthält Code-Ebene Breaking Changes 3 . Auch wenn die Grundphilosophie von Godot 4.7 darin besteht, die Abwärtskompatibilität zu wahren, gibt es eine strenge Migrationshierarchie, die Entwickler beim Aktualisieren ihrer bestehenden Projekte (4.6 oder älter) berücksichtigen müssen.

Die wichtigste Methodik während des Migrationsprozesses besteht darin, das aktuelle Verzeichnis eines Projekts, an dem aktiv gearbeitet wird, keinesfalls direkt mit der neuen Version 4.7 der Engine zu öffnen, sondern stattdessen einen neuen Testbranch (Branch) im Versionskontrollsystem (VCS - z. B. Git) des Projekts zu erstellen oder eine vollständige Kopie des gesamten Ordners anzufertigen 1 . Wenn der Editor das Projekt zum ersten Mal im Format 4.7 öffnet, schreibt er alle Textur-, Text- und Modell-Importprozesse (Import Pipeline) von Grund auf neu; da dieser Vorgang nicht rückgängig gemacht werden kann, verhindert die Isolierung kritische Datenverluste und Schäden an der Abwärtskompatibilität 13 .

Innovationen beim Programmieren und Skripten

Godots eigene dynamische Skriptsprache GDScript wurde in Version 4.7 im Bereich der Flusssteuerung und Systemintegration gestärkt:

Implementierung von Java-Schnittstellen (Interfaces): Zuvor mussten C++- oder Java-Zwischenplugins geschrieben werden, um auf die spezielle Hardware von Android-Geräten (Kamera-API, spezielle Sensoren oder Zahlungssysteme) zuzugreifen. Mit 4.7 hat GDScript die Fähigkeit erhalten, Java-Schnittstellen direkt in der Engine zu integrieren, wodurch der Bedarf an externen Plugins stark reduziert wurde 1 .
Tween-Pause (tween_await): Das für die Erstellung codebasierter Animationen verwendete Tween-System kann nun seine Laufzeit anhalten (Pause), indem es eine `tween_await()`-Funktion aufruft, bis ein Signal von einem anderen Objekt im System ausgelöst wird. Diese Funktion ist eine enorme Erleichterung für die Erstellung asynchroner (Asynchronous) Animationsketten 1 .

Für C# (.NET)-Benutzer bleibt das strukturelle System erhalten. Godot 4.7 bietet weiterhin zwei separate ausführbare Binärdistributionen (Binary) an: „Standard“ (unterstützt C++ über GDScript und GDExtension) und „.NET“ (unterstützt C# und erfordert das .NET SDK) 1 . Wenn ein früheres C#-basiertes Projekt mit der neuen Standard-Engine geöffnet wird, werden die Skripte nicht kompiliert und es kommt zu Fehlern; daher ist das Herunterladen der korrekten Version unerlässlich 1 .

Tabelle der wichtigsten Breaking Changes

Die folgende Tabelle fasst die wesentlichen Änderungen zusammen, die beim Übergang von Godot 4.6 zu Godot 4.7 bestehende Codestrukturen, Datentypen und API-Aufrufe betreffen und daher ein Refactoring (Code-Bereinigung) erfordern:

Betroffene Klasse / SystemFunktionGeänderte Methode / Art der Änderung und detaillierte BeschreibungArchitektur-Kompatibilitätsstatus (GDScript / C#)Object (Kern - Core)is_class() Der Typ des class-Parameters wurde vom allgemeinen String-Typ auf den StringName-Typ umgestellt, der auf C++-Ebene wesentlich schneller ist und einen statischen Speicher verwendet18. Dies erhöht die Leistung bei Objektabfragen.GDScript: Kompatibel.
C#: Binär- und quellkompatibel.ZIPPacker (Kern)start_file() Der API wurden aus Sicherheitsgründen zwei neue Parameter hinzugefügt: permissions (Dateiberechtigungen) und modified_time (Änderungszeitpunkt) für den Zeitstempel18.GDScript: Kompatibel.
C#: Binär- und quellkompatibel.OptimizedTranslationgenerate() Der Rückgabewert der Sprachlokalisierungsfunktion (Localization) wurde vom Typ void auf den booleschen (bool) Typ geändert, um den Erfolgsstatus berichten zu können18.GDScript: Kompatibel.
C#: Binär inkompatibel, quellkompatibel.GPU/CPUParticles2D und 3Drequest_particles_process() Zur Feinabstimmung der Partikelsimulationen im Sinne einer erhöhten physikalischen Genauigkeit wurde der Parameter process_time_residual hinzugefügt18.Kompatibel für alle Sprachen.Control (Oberfläche - GUI)accessibility_live Barrierefreiheitsfunktionen (Accessibility) wie Bildschirmleseprogramme wurden vom grafischen Bildschirmserver (DisplayServer) entkoppelt und in den eigenen Typ AccessibilityServer.AccessibilityLiveMode verschoben18.GDScript: Kompatibel.
C#: Völlig inkompatibel (manuelles Refactoring erforderlich).RichTextLabel (Oberfläche)Constant (Konstante) Enum Die Variable ImageUpdateMask.UPDATE_WIDTH_IN_PERCENT, die als Parameter zur Breitenbestimmung dient, wurde in ImageUpdateMask.UPDATE_WIDTH_UNIT umbenannt, was besser zur logischen Struktur passt18.GDScript: Inkompatibel.
C#: Binär inkompatibel, quellinkompatibel.RichTextLabel (Oberfläche)add_image() / update_image() Um Skalierungsflexibilität zu bieten und relative Dezimalskalen wie 1em zu unterstützen, wurden die Parameter width und height von Ganzzahlen (int) auf Gleitkommazahlen (float) geändert18.Kompatibel für alle Sprachen.

Verifizierungs- und Testverfahren nach dem Update

Nachdem das Projekt in der 4.7-Umgebung erfolgreich über das Versionskontrollsystem geöffnet wurde, müssen spezifische Module auch bei erfolgreicher Kompilierung Laufzeit-Regressionstests unterzogen werden:

UI-Hierarchie: Da die neu eingeführten offset_transform-Dynamiken die Berechnungsalgorithmen für einige tief verwurzelte verschachtelte Eltern-Kind-Knotenplatzierungen (Parent-Child), Scrollansichten (Scroll Views) oder Popup-Menüs beeinflussen können, müssen Hauptmenü, Inventar- und HUD-Bildschirme von Anfang bis Ende getestet werden 1 .
materialausdruck und Render-Pipeline: Durch den Übergang vom Standard Dynamic Range (SDR) zu HDR-unterstützten Render-Pipelines in der Umgebung und aufgrund des Clearcoat-Algorithmus können Farbverschiebungen (Color Shifting), Lichtlecks oder Schattenunterschiede im Aussehen der PBR-Materialien beobachtet werden; alle Beleuchtungsstrukturen müssen überprüft werden 1 .
Android-Einstellungen und XR-Profile: In den Export-Voreinstellungen (Export Presets) müssen die Android-Startbildschirme (Splash), OBB-Datenpaketierungsänderungen und die auf vier grundlegende Profile reduzierten OpenXR-Aktionszuordnungen (Action Maps) von Grund auf überprüft werden 1 .
C++ GDExtension-Plugins: Bibliotheken (GDExtensions), die im Projekt verwendet und an den C++-Quellcode der Engine gebunden (Bind) sind, können zum Absturz der Engine führen, wenn sie nicht zur Unterstützung der neuen API-Signatur von Godot 4.7 aktualisiert wurden. Vor dem Upgrade sollten unnötige Plugins deaktiviert und unter den Projekteinstellungen bestätigt werden, dass jedes Plugin erfolgreich geladen wurde 1 .

Fazit

Die Version Godot 4.7 ist ein ausgereiftes Engineering-Update, das sich von der Marketingphilosophie der bloßen „Hinzufügung medienwirksamer Funktionen“ zu einer Spiel-Engine gelöst hat und chronische Schmerzpunkte in professionellen Spielproduktionszyklen systematisch ins Visier nimmt 4 . Wie Analysen aus der Industrie und von unabhängigen Community-Zentren wie Reddit deutlich zeigen, wurde eine Stabilität und Produktionspraxis erreicht, die den Erwartungen von Entwicklern gerecht wird, die von etablierten Engines wie Unity wechseln 8 .

AreaLight3D und die HDR-Bilderintegration beweisen die Kompetenz der Engine bei architektonischen Visualisierungen und hochwertigen, fotorealistischen 3D-Projekten, während die Integration der Hardware-Raytracing-Infrastruktur in den Kern die strategische Vorbereitung der Engine auf die visuellen Standards der Zukunft symbolisiert 2 . Andererseits haben die Offset-Transformationen in den Control-Knoten das Problem der „Layout-Zerstörung“, einen der größten Alpträume von UI-Entwicklern, beseitigt; VirtualJoystick- und GABE-Integrationen haben zudem die Abhängigkeit von Dritten (Plugins) für den Mobilmarkt beendet 1 . Mit den Vulkan-subsampled-image-Systemen, die foveated rendering unterstützen, wurden zudem die Leistungsgrenzen auf XR-Hardware maximiert 1 .

Die Godot Engine, geprägt durch eine Open-Source-Philosophie und die Mühen hunderter Mitwirkender (Contributors), präsentiert mit der Version 4.7 die stabilste, entwicklerfreundlichste und modernste Variante der 4.x-Generation, die die Leistungskapazität der Hardware am stärksten ausschöpft

Eine isolierte Migrationsstrategie für bestehende Projekte, bei der die detaillierten API-Änderungen, Kompatibilitätsgrenzen und Testverfahren berücksichtigt werden, wird die Produktionsgeschwindigkeit (Iteration Time) der Entwicklerstudios, die Produktwartungskosten und die grafische Qualität des Spiels aus Sicht der Endbenutzer zweifellos auf ein höheres Niveau heben.

*Hinweis: Die Bilder wurden von Google Gemini erstellt.

Godot 4.7 Neuerungen Untersuchung