Diese technische Evaluation untersucht die Fähigkeit moderner Frontier-KI-Modelle (Stand Oktober 2026), auf Basis eines kompakten Spezifikationsdokuments (game_engine_doc.md) autonom eine voll funktionsfähige 3D-Game-Engine in C++ inklusive Editor, Renderer, Skriptanbindung und Standalone-Export zu entwickeln. Im direkten Vergleich traten OpenAI GPT-6 Astra Ultra und Anthropic Claude Opus 5.5 an.
Beide Systeme generierten funktionale Architekturen basierend auf dem vorgegebenen Tech-Stack (C++, CMake, NVRHI/Vulkan, GLFW, GLM, miniaudio, Lua, glTF, PBR, SSAO, 3D-Physik). Die Ausführungstiefe divergierte jedoch drastisch:
GPT-6 Astra Ultra beendete die Aufgabe nach 1 Stunde und 26 Minuten (6 Git-Commits, 7,7 % des wöchentlichen Token-Kontingents). Das Ergebnis (Forge) lieferte eine funktionale Basisinfrastruktur mit Bullet-Physics, ImGuizmo, ungestylter ImGui-Oberfläche, JSON-Szenenformat und Export-Pipeline, wies jedoch visuelle Shader-Bugs (Fresnel-Artefakte, unvollständige Mipmap-Filterung) sowie limitierte Editor-Interaktionen auf.
Claude Opus 5.5 operierte über ca. 36 Stunden kontinuierlich bis zum Erreichen des wöchentlichen Kontingentlimits (~50 USD anteilige Rechenkosten, 299 Git-Commits, Erschöpfung der GitHub-CI-Minuten). Das resultierende System (Basalt) lieferte eine hochgradig optimierte ImGui-Oberfläche mit Thumbnail-Asset-Browser, Viewport-Picking, benanntem Undo/Redo-System, Selektions-Outlines, Post-Processing-Pipeline (FXAA, Tonemapping), deterministischer Physik-Matrix, Partikeleffekten sowie zwei vollwertigen, spielbaren Demos (Tetris und Marble Run), validiert durch automatisierte Headless-Smoke-Tests (120 Frames).
Wichtigste Punkte & Zeitstempel
00:00 Autonome Game-Engine-Entwicklung: Evaluation der Leistungsfähigkeit moderner LLMs (Stand: Ende 2026) zur Erstellung komplexer C++-Softwarearchitekturen ohne menschliche Code-Intervention.
02:16 Versuchsaufbau & Modell-Konfiguration: Direkter Benchmark zwischen Claude Opus 5.5 (Anthropic) und GPT-6 Astra Ultra (OpenAI) im uneingeschränkten Autonomie-Modus ("Yolo-Mode") auf 200-Dollar-Monatsplänen.
07:18 Technische Spezifikationsanforderungen: Vorgabe eines konsistenten Stacks: C++, CMake, NVRHI als Rendering Hardware Interface (primär Vulkan / MoltenVK für macOS), GLFW, GLM, miniaudio für Audio, Lua für Scripting, 3D-glTF-Mesh-Import, PBR-Materialien, IBL (Poly Haven HDRIs), Soft Shadows, SSAO, HDR-Tonemapping und 3D-Physik.
14:18 Spezifikationsdokument & Entwicklungsrichtlinien: Übergabe von game_engine_doc.md mit strikten Direktiven für autonome Namensgebung, Unit-Tests, automatische Git-Commits, CI-Workflows und Style-Konformität zum Hazel-Engine-Repository.
23:14 Initialisierung & Task-Zuweisung: Start beider Agenten auf getrennten Verzeichnissen und Repositories; Benennung der Engines als Forge (GPT-6 Astra) und Basalt (Claude Opus 5.5).
27:47 Quantitativer Leistungs- und Ressourcenvergleich: GPT-6 Astra stoppte nach 1:26:12 Stunden mit 6 Commits und 7,7 % Wochenlimit-Verbrauch. Claude Opus 5.5 iterierte ca. 36 Stunden autonom, erzeugte 299 Commits, richtete automatisierte CI-Pipelines ein (welche das freie GitHub-Runner-Kontingent aufbrauchten) und stoppte erst bei Erreichen des wöchentlichen LLM-Limits.
31:15 Analyse der Engine "Forge" (GPT-6 Astra): Erfolgreiche Kompilierung einer ausführbaren Datei mit integriertem Editor, Bullet-Physics-Integration, ImGuizmo-Transform-Tools und miniaudio. Einschränkungen: Standard-ImGui-Layout ohne Styling, fehlendes Viewport-Picking (nur Selektion via Hierarchie-Baum), fehlerhafte Mip-Filterung bei Umgebungsreflexionen, Randabdunklung durch Fresnel-Bugs und JSON-basiertes Szenenformat.
39:18 Validierung des Standalone-Runtimes von "Forge": Funktionsfähiger Export-Mechanismus (ForgeRuntime.exe), der die Szene außerhalb des Editors fehlerfrei ausführt.
42:33 Analyse der Engine "Basalt" (Claude Opus 5.5): Bereitstellung einer vollständig angepassten ImGui-UI mit Thumbnail-Vorschau im Asset-Browser, nativem 3D-Viewport-Picking, QWER-Transformations-Gizmos, Snapping-Funktion, hierarchischer Kamera-Steuerung (Fokus via F, Orbit via Alt+LMB) und präzisen Selektions-Outlines.
46:30 Undo/Redo-System & Shader-Qualität: Transaktionsbasiertes Undo/Redo (Strg+Z / Strg+Y) mit benanntem Aktionsverlauf im Edit-Menü. Deutlich sauberere Schattengenerierung, Post-Processing-Volumen mit FXAA, multiplen Tonemappern und SSAO.
51:29 Live-Inspektion & Lua-Hot-Reloading: Skript-Eigenschaften in trigger_zone.lua (z. B. Soundpfade, Emissive-Glow-Parameter) werden im Inspector dynamisch generiert und bei Dateiänderung sofort ohne Neustart im laufenden System aktualisiert.
53:40 Erweiterte Subsysteme in "Basalt": Integrierte Physik-Ebenen-Konfiguration mit Kollisionsmatrix, deterministischer Simulation via Seed-Vorgabe, konfigurierbares Partikelsystem (Spark Fountain) sowie UI-Rendering-Komponenten.
55:05 Autonom generierte Demoprojekte: Das System lieferte zwei vollständige Beispielanwendungen: Ein physikbasiertes Tetris (inklusive Partikeleffekten, Screen-Shake und Hold-Mechanik) sowie eine interaktive 3D-Murmelbahn (Marble Run).
01:01:24 Export-Pipeline mit Headless-Smoke-Testing: Integrierter Export-Check, der das kompilierte Projekt vor der Distribution 120 Frames lang im Headless-Modus auf Exit-Codes testet; fehlerfreie Ausführung der exportierten MarbleRun.exe.
Glossar
CMake: Ein plattformübergreifendes Open-Source-Werkzeug zur Steuerung des Software-Kompilierungsprozesses und der automatischen Generierung nativer Build-Dateien (z. B. Makefiles oder Visual-Studio-Projektdateien).
ECS (Entity Component System): Ein Architekturmuster in der Spieleentwicklung, das Daten und Logik strikt trennt. Entitäten sind reine Identifikatoren (IDs), Komponenten reine Datencontainer und Systeme enthalten die ausführende Spiellogik.
Fresnel-Effekt: Ein physikalisches Phänomen der Optik, das beschreibt, dass die Reflexionsstärke einer Oberfläche vom Betrachtungswinkel abhängt (flache Winkel reflektieren stärker als senkrechte). Shader-Bugs führen hierbei oft zu fehlerhaften schwarzen Säumen an Objekträndern.
FXAA (Fast Approximate Anti-Aliasing): Ein ressourcenschonendes Post-Processing-Kantenglättungsverfahren, das im fertigen Pixelbild Kanten anhand von Helligkeitskontrasten erkennt und weichzeichnet.
Gizmo: Ein interaktives 3D-Steuerelement im Editor-Viewport (meist mit Achsen für X, Y, Z), mit dem Entwickler Objekte im Raum verschieben (Translate), rotieren (Rotate) oder skalieren (Scale) können.
GLFW: Eine leichtgewichtige C-Bibliothek zur Erstellung von Anwendungsfenstern, OpenGL/Vulkan-Kontexten sowie zur Verarbeitung von Tastatur-, Maus- und Gamepad-Eingaben.
GLM (OpenGL Mathematics): Eine Header-only-Mathematikbibliothek für C++, die auf Vektor- und Matrizenoperationen (3D-Transformationen) gemäß den Spezifikationen der GLSL-Shadersprache ausgelegt ist.
glTF / GLB (GL Transmission Format): Ein standardisiertes, kompaktes Dateiformat zur effizienten Übertragung und schnellen Ladezeit von 3D-Szenen, Modellen, Texturen und Animationen.
Headless-Ausführung: Das Starten und Ausführen eines Programms (oder einer Spiel-Engine) ohne grafische Benutzeroberfläche und ohne Rendering auf einem Monitor, häufig eingesetzt für automatisierte Tests auf Servern.
HDRI (High Dynamic Range Image): Ein Bildformat mit hohem Dynamikumfang, das reale Lichtinformationen speichert und in Engines als Umgebungshintergrund für fotorealistisches Licht verwendet wird.
IBL (Image-Based Lighting): Eine Rendering-Technik, bei der ein 360-Grad-Panoramabild (meist ein HDRI) als Lichtquelle genutzt wird, um realistische Umgebungsbeleuchtung und Reflexionen auf 3D-Objekten zu berechnen.
ImGui (Dear ImGui) / ImGuizmo: Eine weit verbreitete, extrem performante Immediate-Mode-GUI-Bibliothek für C++, die für Entwickler-Tools und Debug-Oberflächen genutzt wird; ImGuizmo erweitert sie um 3D-Manipulations-Gizmos.
Mipmaps / Mip-Filtering: Vorberechnete, herunterskalierte Versionen einer Textur. Das Mip-Filtering sorgt dafür, dass je nach Distanz zur Kamera die passende Texturstufe verwendet wird, um Flimmern (Aliasing) zu verhindern und Rechenleistung zu sparen.
MoltenVK: Eine Software-Kompatibilitätsschicht, die Vulkan-API-Aufrufe zur Laufzeit auf Apples proprietäre Metal-Grafikschnittstelle übersetzt, um Vulkan-Code auf macOS und iOS auszuführen.
NVRHI (NVIDIA Rendering Hardware Interface): Eine Abstraktionsschicht für Grafik-APIs (wie DirectX 11/12 oder Vulkan), die Low-Level-Grafikprogrammierung vereinfacht, indem sie Aufgaben wie Speicherbarrieren, Ressourcentransitionen und Synchronisation vereinheitlicht.
PBR (Physically Based Rendering): Ein Rendering-Ansatz, der physikalische Gesetzmäßigkeiten des Lichts (wie Energieerhaltung, Mikrooberflächen-Rauheit und Metallizität) exakt simuliert, um Materialien unter beliebigen Lichtbedingungen realistisch darzustellen.
RHI (Rendering Hardware Interface): Eine architektonische Schnittstelle in einer Game-Engine, die die systemspezifischen Grafik-APIs (z. B. Vulkan, DirectX, Metal) kapselt, damit der Kern-Renderer plattformunabhängig bleibt.
Smoke Test (Rauchtest): Ein minimaler, schneller Testdurchlauf in der Softwareentwicklung, der lediglich prüft, ob die Basisfunktionen einer Anwendung ohne sofortigen Absturz (Crash) lauffähig sind.
SSAO (Screen Space Ambient Occlusion): Ein Rendering-Verfahren im Post-Processing, das anhand des Tiefenpuffers (Depth Buffer) berechnet, wie stark Ecken, Spalten und aufeinandertreffende Flächen durch diffuses Umgebungslicht abgedunkelt werden müssen.
Tonemapping: Die Umwandlung von Renderings mit hohem Dynamikumfang (HDR) in den Standardfarbraum (LDR), damit die Helligkeitsabstufungen auf herkömmlichen Bildschirmen ohne Detailverlust in hellen oder dunklen Bereichen angezeigt werden können.
Vulkan: Eine moderne, plattformübergreifende Low-Level-Grafik- und Compute-Schnittstelle (API) mit direktem Hardware-Zugriff und minimalem Treiber-Overhead.