Was Web-Entwickler von Game-Engine-Architektur lernen können

Wenn du mit React, Vue oder Angular arbeitest, nutzt du Patterns, die aus der Spieleentwicklung stammen. Nicht inspiriert davon. Direkt übernommen. Der Component Tree, den du jeden Tag baust, wurde in den 1980ern als Scene Graph erfunden, lange bevor JavaScript überhaupt existierte.

Hier sind vier Architektur-Patterns aus Game Engines, die dein Web-Development besser machen.

1. Der Scene Graph: Reacts Urgroßvater

Der Scene Graph ist eine hierarchische Baumstruktur, in der jeder Knoten Transformationen und Eigenschaften an seine Kinder vererbt. PHIGS (Programmer's Hierarchical Interactive Graphics System) wurde 1984 entwickelt und 1988 als ANSI-Standard verabschiedet. Es war die erste kommerzielle Scene-Graph-Spezifikation.

Das Prinzip: Du baust eine Szene nicht als flache Liste, sondern als Baum. Ein Raumschiff-Node enthält einen Triebwerk-Node, der enthält einen Partikel-Node. Wenn sich das Raumschiff bewegt, bewegen sich Triebwerk und Partikel automatisch mit. Kaskadierung von Eigenschaften durch die Hierarchie.

Kommt dir das bekannt vor? Reacts Component Tree funktioniert identisch. Context propagiert durch den Baum nach unten. CSS-Variablen kaskadieren. State fließt von Eltern zu Kindern. Das ist kein Zufall. Jordan Walke, der Erfinder von React, hat sich explizit von Szenegraphen und funktionaler Programmierung inspirieren lassen.

Godot macht das noch konsequenter als React. In Godots Scene Tree ist alles ein Node: UI-Elemente, Spiellogik, Physik, Audio. Kein useEffect, kein Lifecycle-Hook. Du hast _ready() (Mount), _process() (Render-Loop) und _exit_tree() (Unmount). Drei Funktionen statt 15 Hooks.

class_name Raumschiff extends CharacterBody2D

func _ready():
    # Wie componentDidMount / useEffect([], ...)
    $Triebwerk.starten()

func _process(delta):
    # Wie requestAnimationFrame, 60x pro Sekunde
    position += geschwindigkeit * delta

2. Composition over Inheritance: Die Spielebranche wusste es zuerst

Das Entity Component System (ECS) hat Composition over Inheritance nicht erfunden, aber es hat bewiesen, dass es skaliert. Thief: The Dark Project nutzte 1998 ein ECS, und der gleiche Ansatz lief später in System Shock 2.

Die Idee: Eine Spielfigur ist keine Klasse in einer Vererbungshierarchie. Sie ist eine leere Entity mit angehängten Components. Braucht sie Physik? PhysicsComponent anhängen. Braucht sie Gesundheit? HealthComponent anhängen. Braucht sie beides nicht mehr? Components entfernen.

React hat dieses Pattern 2018 mit Hooks übernommen. Statt Klassen-Vererbung (class MyComponent extends React.Component) nutzt du Composition mit useState, useEffect und Custom Hooks. Die Game-Engine-Welt hatte das gleiche Problem 20 Jahre früher gelöst.

Unity hat die Performance-Vorteile gemessen: Ihr Data-Oriented Technology Stack (DOTS) mit ECS erreicht 5x bis 50x bessere CPU-Performance als die klassische OOP-Architektur, je nach Parallelisierungsgrad. In der Megacity-Demo von 2018 renderte Unity damit eine Stadt mit 4,5 Millionen Mesh-Renderern.

Für Web-Entwickler heißt das: Wenn du merkst, dass deine Klassen-Hierarchie zu tief wird, denk wie ein Game-Engine-Architekt. Zerlege Verhalten in kleine, kombinierbare Einheiten. In React sind das Hooks. In Godot sind das Nodes. Das Prinzip ist dasselbe.

3. Signals: Observer Pattern ohne den Boilerplate

Godot hat Signals als erstklassiges Sprachfeature. Du deklarierst ein Signal, und andere Nodes verbinden sich damit. Keine Event-Bus-Bibliothek, kein Redux, kein Pub/Sub-Framework.

signal leben_verloren(neues_leben: int)

func schaden_nehmen(menge: int):
    leben -= menge
    leben_verloren.emit(leben)

func _ready():
    spieler.leben_verloren.connect(_bei_leben_verloren)

func _bei_leben_verloren(neues_leben: int):
    label.text = str(neues_leben)

Das ist das Observer Pattern in seiner reinsten Form, ohne Middleware-Layer. Die Web-Welt hat Jahre gebraucht, um an einen ähnlichen Punkt zu kommen. Solid.js Signals, Angular Signals (seit v16), Vue 3 Reactivity: Alle lösen das gleiche Problem, das Game Engines seit den 2000ern gelöst haben.

Der entscheidende Unterschied: In Game Engines sind Signals architektonisch. Sie definieren, wie Systeme kommunizieren. Im Web werden sie oft nur als State-Management-Optimierung behandelt. Game-Engine-Entwickler denken von Anfang an in entkoppelten Systemen, die über Signals kommunizieren. Web-Entwickler sollten das auch tun.

4. Object Pooling: Warum Game Engines Garbage Collection hassen

In einem Shooter entstehen pro Sekunde Dutzende Projektile. Jedes Mal new Bullet() und dann den Garbage Collector aufräumen lassen? Unspielbar. Stattdessen nutzen Game Engines Object Pools: Eine fixe Menge an Objekten wird beim Start erstellt. "Verbrauchte" Objekte werden nicht zerstört, sondern zurückgesetzt und wiederverwendet.

Web-Entwickler kennen das Prinzip als Connection Pooling bei Datenbanken. Aber es geht weiter: React 18s Concurrent Rendering recycelt Fiber-Nodes intern. Workers in Node.js Thread-Pools werden wiederverwendet. Das Pattern ist überall, nur redet im Web kaum jemand darüber.

Wenn du eine Anwendung baust, die viele kurzlebige Objekte erzeugt (Chat-Nachrichten, Tabellen-Zeilen, Animationen), frag dich: Könnte ich die recyceln statt neu zu erstellen? Die Spielebranche beantwortet diese Frage seit 30 Jahren mit Ja.

Die Zahlen hinter Game-Engine-Architektur

Die deutsche Spielebranche hat 2023 mit knapp 1.200 Unternehmen und fast 13.000 Beschäftigten über 3,9 Milliarden Euro Umsatz erwirtschaftet (Quelle: game.de Jahresreport 2025). Das sind keine Hobby-Projekte. Das sind Produktionssysteme, die unter extremen Performance-Anforderungen laufen.

Godot, die Open-Source-Engine mit über 108.000 GitHub Stars, hat beim GMTK Game Jam 2025 einen Marktanteil von 39% erreicht, mehr als dreimal so viel wie noch 2021 (13%). Tools wie Ziva helfen Godot-Entwicklern dabei, effizienter zu arbeiten, aber die Architektur der Engine selbst ist der eigentliche Lernstoff.

Fazit: Lerne von den Leuten, die 60 FPS halten müssen

Web-Entwickler optimieren für Time-to-Interactive. Game-Engine-Entwickler optimieren für 16,67 Millisekunden pro Frame, bei 60 FPS. Diese Einschränkung hat Architektur-Patterns hervorgebracht, die robuster und performanter sind als das, was die meiste Web-Architektur bietet.

Das heißt nicht, dass du deine Next.js-App wie eine Game Engine bauen sollst. Es heißt: Wenn du vor einem Architektur-Problem stehst, schau dir an, wie Godot, Unity oder Unreal es lösen. Die Chancen stehen gut, dass sie das Problem vor 10 oder 20 Jahren schon gelöst haben.

Drei konkrete Schritte:

1. Lies Game Programming Patterns von Robert Nystrom. Es ist kostenlos online und erklärt jedes Pattern mit konkretem Code.
2. Bau ein kleines Godot-Projekt. Nicht um Spiele zu entwickeln, sondern um die Architektur zu erleben. Der Scene Tree verändert, wie du über Component-Hierarchien denkst.
3. Hinterfrage deine Abstraktionen. Wenn du drei NPM-Pakete brauchst, um ein Problem zu lösen, das eine Game Engine in 10 Zeilen löst, stimmt etwas mit der Abstraktion nicht.

Die beste Architektur entsteht nicht in Frameworks. Sie entsteht dort, wo Performance keine Option, sondern eine harte Grenze ist.