Das handgefertigte 3A-Spiel Opus 5 ist zu einem riesigen Hit geworden, aber Karpathy hat ihm einen Dämpfer versetzt.

Ein einziger Prompt verbrauchte 690 Millionen Token und kostete 423 US-Dollar.

Am Ende erhielt Vyom Wave Racer, ein Ruderboot-Rennspiel mit integrierter Physik-Engine.

Dieses Spiel ist auf Basis von Three.js aufgebaut, verfügt über einen Cel-Shading-Renderstil, die Rennstrecke ist ein prozedural generierter unendlich großer Ozean, und jede einzelne Welle in der Szene wird in Echtzeit per Code berechnet – ohne Abhängigkeit von externen Asset-Paketen.

Der Code wurde bereits auf GitHub hochgeladen, jeder kann das Spiel direkt im Browser spielen.

Erlebnis-Link👉: https://wave-racer.vercel.app/

»Ein Spiel auf einmal generieren«

Claude Opus 5 wurde am 24. Juli veröffentlicht, in den darauffolgenden Tagen tauchten in den sozialen Medien eine Reihe auffälliger Browser-Spielprototypen auf.

Der AI-Investor Matt Shumer veröffentlichte ein Ego-Shooter-Spiel, das vollständig von Opus 5 erstellt wurde: Alle Elemente auf dem Bildschirm – Code, Texturen, Physik, Gegnerverhalten – wurden vollständig selbst generiert, ohne Verwendung externer Assets.

Prompt:I want you to build a first-person shooter at the level of the most recent Call of Duty games. It should be utterly perfect, visually beautiful, with every single thing done at AAA quality—from textures to physics to anything you could think of.

Fan out sub-agents and have sub-agents tackle each one individually so that the game is utterly perfect. You should /loop on each item and have a separate sub-agent check it visually to ensure it looks triple A. That separate sub-agent should be a really harsh critic, and if it doesn't look triple A, it should keep going.

Don't stop until each sub-agent is utterly wowed with the quality when compared with the actual Call of Duty game. It should literally compare them side by side blind and say which one looks better. Do this in ThreeJS. /loop until it's utterly perfect. Fan out sub-agents and ultracode.

Wie oben beschrieben, hat Shumer nie einen Renderer festgelegt, das System des Spiels aufgelistet oder definiert, welche Elemente die »AAA-Qualität« umfassen soll.

Er nennt diese Methode »Gauntlet Loop« (Herausforderungs-Schleife): Man gibt dem Agenten einen realen, überprüfbaren Standard statt vager Anweisungen, lässt ihn die Aufgabe in kleine Teile zerlegen, und reicht jeden Teil der Aufgabe an einen Prüfer weiter – der Prüfer kann niemals den Denkprozess des Erstellers bei der Auswahl der Optionen einsehen.

Anschließend hat @mikeluan123 Shumers Prompt-Framework in ein universelles Weltraum-Echtzeitstrategiespiel im Stil von *Homeworld* umgewandelt: Es verbrauchte 68.600 Eingabe-Token und 4,6 Millionen Ausgabe-Token und kostete 632,65 US-Dollar.

Es gibt aber auch kostengünstigere Ansätze. Andrej Karpathy nutzte ein Budget, das weniger als ein Bruchteil davon betrug, um die KI eine ganze Welt von Mittelerde rendern zu lassen.

Er gab Opus 5 den Originaltext des ersten Absatzes von *Der Herr der Ringe*, gewährte ein Budget von 1 Million Token (ca. 10 US-Dollar) und bat das Modell, diese Geschichte zu rendern.

Zwei Stunden später waren 5500 Zeilen Code geschrieben, eine prozedural generierte Welt von Mittelerde lief im Browser. Er lud sie auf karpathy.ai/lotr-movie hoch und schrieb nebenbei: »Ich freue mich darauf, dass das GTA-Hobbits-Dorf vor GTA VI erscheint.«

In der traditionellen 3D-Entwicklung bauen Entwickler Szenen aus Asset-Bibliotheken zusammen, Texturen sind Bilddateien, die Physik hängt von der Engine ab – es ist ein bisschen wie beim Zusammenbauen von Lego.

Diese mit Opus 5 erstellten Werke ähneln dagegen eher dem Prozess, bei dem Kunststoffpartikel zu Bausteinen werden: Geometrien sind prozedural erzeugt, Texturen werden über Shader dargestellt, Physik und Steuerung sind vollständig in derselben HTML-Datei geschrieben und laufen sofort nach dem Öffnen.

Eine Umfrage der Game Developers Conference 2026 zeigt, dass 52 % der Spieleentwickler eine negative Einstellung zu generativen Tools haben, 53 % sind der Meinung, dass solche Tools das Fehlerrisiko von Projekten erhöhen. Die Mängel sind ebenfalls offensichtlich: Kunstrichtung, narrative Tiefe und jener unbeschreibliche »Feinschliff«, den Spieler sofort wahrnehmen können, sind nach wie vor deutliche Schwachstellen.

Der Entwickler Leon Lin hat einen interessanten Vergleich angestellt. Er schrieb direkt ein detailliertes Designdokument mit bis zu 20 Kapiteln, in dem er von der Ragdoll-Physiksimulation bis zu kaskadierenden Schattenzuordnung alles genau beschrieb, und gab es dann Opus 5 zur Generierung von »Dust Corridor« – das ebenfalls im Browser läuft, gut aussieht und in einigen Dimensionen stabiler ist als die Version mit kurzem Prompt.

Aber dieses Dokument hat Leon selbst geschrieben. Er konnte es schreiben, weil er weiß, was AAA-Qualität bedeutet. Das Modell liefert in seinem Rahmen hervorragende Ergebnisse, weil der Rahmen selbst aus jahrelanger menschlicher Erfahrung und Anhäufung von Wissen stammt.

Generierung ist nur der Ausgangspunkt – das Urteilsvermögen entscheidet über alles

Die Kosten für die Generierung nähern sich schnell der Null an, dies ist eine der wichtigsten Veränderungen, die gerade stattfindet.

Aus langfristiger Sicht bringt dies eine extrem aufregende Sache mit sich: Spieler können als Neben-NPC in die Geschichte von *Der Herr der Ringe* eintreten oder eine der Rollen übernehmen – eine Art »on-demand generiertes GTA X«.

Das ist die wahre Zukunft der Spiele: Es handelt sich möglicherweise nicht mehr um Konserven mit festem Inhalt, sondern es kann basierend auf Ihren Vorlieben, Ihrem Tempo und Ihren Interessen in Echtzeit eine ganz eigene Welterfahrung für Sie generieren. Jeder Spieler hat seine eigene Welt von Mittelerde, sein eigenes Hobbits-Dorf und seine ganz eigene Geschichte.

Aber »Generierung« ist nur der Ausgangspunkt, die Arbeit danach ist das eigentliche Problem.

https://the-decoder.com/claude-opus-5-pushes-prompt-to-game-ai-from-rough-color-blocks-to-full-3d-prototypes-with-physics-and-music/

Karpathy hat in seinem *Der Herr der Ringe*-Experiment ein grundlegendes technisches Hindernis aufgedeckt. Während Opus 5 den Rendercode generierte, musste es sehr langsam und mühsam zu verschiedenen Zeitpunkten Screenshots aufnehmen, und anhand dieser statischen Screenshots den Zustand des dynamischen Laufzeitumfelds ableiten – trotzdem kam es mehrfach zu Fehlern und entstand einiges Durcheinander.

Seine Schlussfolgerung lautet: »Der Bereich Spiele und Welten deckt eine Schwäche großer Sprachmodelle auf: Sie können ihre eigene Arbeit nur schwer prüfen, da sie keine effiziente, native Wahrnehmung von Videos haben und das darin enthaltene Spiel nicht wirklich erleben können.«

Das Modell kann Code schreiben, der dafür sorgt, dass ein Rennboot schön über die Wasseroberfläche driftet, aber es kann dieses Spiel nicht selbst spielen und merkt nicht, dass der Spieler nach drei aufeinanderfolgenden S-Kurven bereits die Geduld verliert. Es leitet seine Erkenntnisse aus Screenshots und statischer Code-Analyse ab – die Genauigkeit und Reichweite dieser Ableitungen ist weit von einer echten Spielbewertung entfernt.

Daraus ergibt sich eine Folgerung: Wenn die Generierung fast kostenlos wird, ist das Urteilsvermögen, das die Qualität des Ergebnisses beurteilen kann, die wirklich knappe Ressource.

Urteile wie »Die Physik fühlt sich hier nicht richtig an«, »Das Tempo dieses Levels bricht in der fünften Minute zusammen« oder »Diese Aufgabenbeschreibung ist zu vage, der Spieler wird direkt aufgeben« können nicht automatisch aus der Menge des Codes entstehen und erscheinen auch nicht automatisch, wenn das Token-Budget größer wird.

Personen, die die Ergebnisse des Modells prüfen und kritisieren können, haben derzeit einen höheren Wert.

Was fehlt noch, damit das Modell lernt, seine eigene Arbeit zu prüfen?

Was muss sich ändern, damit große Sprachmodelle in diesem Bereich wirklich besser werden?

Heutige Modelle können einzelne Screenshots analysieren und verstehen, was in einem Bild passiert – aber »den Lauf eines Spiels kontinuierlich über die Zeit wahrzunehmen« ist etwas völlig anderes.

Um ein Spiel wirklich zu »sehen«, muss das Modell die Zustandsänderungen zwischen den Frames verfolgen, Muster wie »Der Spieler ist hier dreimal gestorben« erkennen, die nur über mehrere Frames hinweg entdeckt werden können, und spüren, dass »das Bedienungstempo des Spielers in diesem Abschnitt durcheinander gerät – irgendetwas stimmt hier nicht«.

Auf Forschungsebene lassen sich einige praktische technische Richtungen erkennen. Im Bereich des automatisierten Spieltests wird bereits erforscht, wie LLM-Agenten den Spielzustand durch multimodale Wahrnehmung erfassen, nach der Ausführung von Aktionen selbst reflektieren, Ruckler und Abstürze erkennen, dann die Strategie anpassen und die Kette »Screenshot → Analyse → Aktion« zu einem nahezu Echtzeit-Feedback-Zyklus zusammenfassen.

Solche Methoden warten nicht darauf, dass die native Fähigkeit des Modells, »Videos anzusehen«, reift, sondern schließen die Wahrnehmungslücke zunächst durch die Architektur – das ist derzeit der praktischste technische Ansatz.

Das Modell weiß, wie man WebGL-Code schreibt, der Normal-Maps korrekt rendert, da solcher Code im Internet in großer Menge vorhanden ist und gelernt werden kann.

Aber Urteile wie »An welcher Ecke dieses Korridors erzeugt der Spieler ein Gefühl von Bedrängnis«, »Wie stark darf der Rückstoß einer Waffe sein, damit sich der Spieler nicht außer Kontrolle fühlt« oder »Welches Belohnungstempo sorgt dafür, dass der Spieler nach einem Level direkt das nächste spielen möchte« wurden nicht »als Code geschrieben« und im Internet gespeichert, damit das Modell sie lernen kann.

Damit das Modell diese Fähigkeit auf Wahrnehmungsebene wirklich erlangt, reicht der Code-Korpus allein wahrscheinlich nicht aus. Es braucht möglicherweise eine große Menge an Interaktionsdaten, die durch das tatsächliche Spielen von Spielen durch das Modell erzeugt werden, um in echten Spielprozessen Beurteilungsgrundlagen für Spielgefühl, Feedback, Tempo und Frustration aufzubauen.

Das erinnert in gewisser Weise an die Logik von AlphaGo: Es lernte Schachspielen durch eine riesige Menge an selbst durchgeführten Partien, um das Spielgefühl zu sammeln. Die Spielwelt ist aber viel komplexer als ein Schachbrett und hat viel breitere Wahrnehmungsschnittstellen – dieser Weg ist also sehr viel länger.

Eine wirklich personalisierte Spielerfahrung bedeutet nicht nur, eine Rennstrecke mit unendlichem Ozean zu generieren, sondern auch zu wissen, welches Tempo dieser Spieler bevorzugt, welche Art von Herausforderungen diesem Spieler Freude bereitet und welche ästhetischen Vorlieben er hat.

Wave Racer und die von Karpathy erstellte Welt von Mittelerde im Browser sind sehr interessant – aber zumindest im Sommer 2026 ist das Szenario »Ein einziger Prompt erzeugt ein Spiel auf dem Niveau von *Call of Duty*« noch nicht eingetreten.

Wann wird das Modell in der Lage sein, das von ihm selbst erstellte Spiel wirklich zu spielen, zu merken, dass »das Tempo des siebten Levels in der zweiten Minute zusammenbricht« und daraus Er