KI-native Game-Engines werden ausgeliefert, und sie sehen kein bisschen aus wie Unity
Von Oleg Sidorkin, CTO von Cinevva
Im März sind drei Game-Engines aufgetaucht, die architektonisch anders sind als alles aus der Linie Unity, Unreal und Godot. Sie haben keine visuellen Editoren. Sie sind nicht darauf optimiert, dass sich ein Mensch durch Menüs klickt. Sie sind von Grund auf dafür gebaut, dass KI-Agenten den Spielzustand lesen, schreiben und steuern.
Das ist nicht "Unity mit einem KI-Tab". Das ist eine andere Gattung von Engine.
KI verändert 3D-Entwicklungs-Workflows bereits. Die Engine-Ebene ist als Nächstes dran.
Die drei Engines
nAIVE Engine ist quelloffen, in Rust geschrieben und rendert mit WebGPU. Hot-Reload im Subsekundenbereich: Shader unter 200 ms, Szenen unter 100 ms, Skripte unter 50 ms. Szenen, Pipelines und Materialien werden in YAML definiert, LLMs können sie also lesen und erzeugen, ohne Binärformate zu parsen. Die Engine bietet eine MCP-Befehlsschnittstelle, über die KI-Agenten Engine-Funktionen per JSON-RPC steuern. Sie bringt Gaussian Splatting als vollwertige Funktion und Headless-Rendering für automatisierte Tests mit. Die gesamte Architektur nimmt an, dass dein Hauptnutzer ein KI-Agent sein könnte und kein Mensch mit einer Maus.
Arcane Engine ist eine Code-first-2D-Engine. Rust-Kern, TypeScript-Skripting. Gar kein visueller Editor. Ihre Philosophie: "Code ist die Szene." Der Spielzustand ist eine abfragbare Datenbank statt eines Szenenbaums. Ein eingebautes Protokoll für die Interaktion mit KI-Agenten gehört dazu. Lizenziert unter Apache 2.0.
Mirror Engine ist in der Alpha und Multiplayer-first mit einem Entity Component System. Der interessante Teil: Sie enthält KI-Text-zu-3D-Generierung, die in etwa 60 Sekunden Gaussian Splats aus Text-Prompts erzeugt. TypeScript-Skripting, browserbasierter Client "Mirror Lite".
Diese drei Engines teilen weder Codebasis noch Team, aber sie teilen eine Designthese: Die primäre Schnittstelle zu einer Game-Engine sollte strukturierter Text sein, keine GUI.
Warum diese Architektur zählt
Klassische Game-Engines sind darauf gewachsen, einen Menschen am Schreibtisch zu bedienen. Du hast ein Viewport. Ein Hierarchie-Panel. Einen Inspector. Eine Timeline. Alles ist auf Klicken, Ziehen und visuelles Platzieren ausgelegt. Dieser Workflow ist mächtig. Er ist auch für einen KI-Agenten unbenutzbar.
Wenn dein primärer "Nutzer" ein LLM ist, brauchst du andere Grundbausteine. YAML statt binärer Szenenformate. Abfragbarer Zustand statt verschachtelter Szenenbäume. Protokollbasierte Befehle statt Mausklicks. Headless-Betrieb statt Fenster-Rendering.
Das ist dieselbe Verschiebung, die in der Infrastruktur passierte, als DevOps von GUI-Kontrollpanels zu Infrastructure-as-Code wechselte. Dasselbe passiert jetzt bei Game-Engines, nur zwanzig Jahre später.
nAIVEs MCP-Schnittstelle ist das klarste Beispiel. MCP (Model Context Protocol) wird zum Standard dafür, wie KI-Agenten mit Werkzeugen sprechen. Wenn eine Engine MCP von Haus aus spricht, kann jeder KI-Agent, der das Protokoll unterstützt, Szenen manipulieren, Parameter anpassen, Tests laufen lassen und Gameplay iterieren, ohne dass ein Mensch dazwischensitzt. Das ist kein Feature, das man an eine klassische Engine schraubt. Das ist ein grundlegend anderes Verhältnis zwischen Engine und Nutzer.
Gaussian Splatting in der Spieleentwicklung. Sowohl nAIVE als auch Mirror behandeln es als vollwertigen Rendering-Baustein.
Das größere Bild
Diese drei Engines sind nicht das einzige Signal. Meshys Black Box hat KI-generierte Spielmechaniken zur Laufzeit gezeigt. OpenAI hat auf der GDC ein taktisches RPG präsentiert, gebaut mit Phaser. Die Werkzeugschicht zwischen "KI erzeugt etwas" und "dieses Etwas läuft als spielbares Spiel" wird jeden Monat dünner.
Bei Cinevva bauen wir diese Brücke von der anderen Seite. Unsere Engine kümmert sich um Rendering, Physik und Echtzeitinteraktion, während KI die Asset-Generierung übernimmt. Der Ansatz unterscheidet sich von nAIVE oder Arcane, aber die zugrunde liegende Wette ist dieselbe: Die Game-Engine der Zukunft muss KI als Erstsprache sprechen und sie nicht als Plugin ergänzen.
Die klassischen Engine-Hersteller wissen das auch. Unity hat auf der GDC KI-Werkzeuge zum Spielebauen gezeigt. Roblox hat KI-gestützte 4D-Modellerstellung gestartet. Aber es macht einen echten Unterschied, ob man KI-Funktionen zu einer für Menschen entworfenen Engine hinzufügt oder eine Engine entwirft, in der KI die primäre Schnittstelle ist.
Was meiner Meinung nach als Nächstes passiert
Die meisten dieser Engines werden nicht überleben. Das ist bei einer neuen Kategorie normal. Aber die Entwurfsmuster bleiben. Szenendefinitionen in YAML, MCP-Protokolle zur Agentensteuerung, abfragbarer Spielzustand, Headless-Betrieb. Diese Ideen werden binnen zwei Jahren in die etablierten Engines einsickern.
Die Engine, die diese Ära gewinnt, existiert wahrscheinlich noch nicht. Aber die architektonische DNA wird gerade geschrieben, in diesen drei Projekten und einer Handvoll weiterer. Die Frage ist nicht, ob Game-Engines KI-nativ werden. Die Frage ist, ob die Verwandlung von innen aus den Platzhirschen kommt oder von Neueinsteigern, die vom ersten Tag an für Agenten entworfen haben.
Verwandt:
- Jetzt will jeder die KI-Game-Engine sein — das Plattformrennen, das die Bühne bereitet hat
- Führende quelloffene Gen-AI-Modelle — die Modelle, die diese Engines einbinden
- Web-Game-Engines im Vergleich — wo die neuen Engines ins Ökosystem passen
- Open Source hat ein KI-Verschmutzungsproblem — die Kostenseite KI-generierter Beiträge