Ein 3D-Rennspiel mit ChatGPT entwickeln: Was ich nach fünf Versionen gelernt habe

Am 26. Juli 2026 wollte ich testen, wie weit sich ChatGPT bei der Entwicklung eines eigenen Browsergames einsetzen lässt. Meine Ausgangsidee war ein dreidimensionales Rennspiel in Berlin, das ohne Registrierung direkt im Browser startet, auf meiner Website eingebunden werden kann und später möglicherweise als App erscheint.

Wenige Stunden später existierte mit „Spree Rush 1“ tatsächlich ein einigermaßen spielbarer Prototyp, wenngleich noch einige Bugs enthalten sind. Er hatte eine 3D-Strecke, drei Schwierigkeitsgrade, Berliner Sehenswürdigkeiten, mehrere Fahrzeuge, Motorengeräusche, Checkpoints und verschiedene Straßenbeläge. Bis zur fünften Version entstand allerdings auch eine lange Liste aus Missverständnissen, oberflächlich umgesetzten Änderungen, technischen Fehlern und übertrieben optimistischen Erfolgsmeldungen.

Gerade diese Probleme machen das Experiment interessant. Es zeigt nicht nur, was ChatGPT bei der Spieleentwicklung leisten kann, sondern auch, warum ein funktionierender Build noch lange kein gutes Spiel ist und weshalb präzise Tests wichtiger sind als eine lange Featureliste.

Wie viele Tokens hat die Entwicklung verbraucht?

Zumindest nicht so viel, als dass die gesamten Limits meines Plus-Plans verbraucht wären, aber ca. 50 % davon waren schon weg. Der sichtbare Gesprächsinhalt allein dürfte bereits im hohen fünfstelligen bis niedrigen sechsstelligen Tokenbereich liegen. Rechnet man die wiederholte Verarbeitung des Gesprächskontexts, Quellcode, Testergebnisse, Fehlermeldungen und interne Werkzeugausgaben über zahlreiche Arbeitsschritte hinweg hinzu, ist ein kumulierter Verbrauch von mehreren Hunderttausend bis möglicherweise mehr als einer Million verarbeiteten Text-Tokens plausibel.

Diese Schätzung ist keine API-Abrechnungszahl. Bildgenerierung, Browserautomatisierung, Builds und Rechenzeit lassen sich ebenfalls nicht sinnvoll in dieselbe Tokenzahl umrechnen.

Der hohe Verbrauch kam nicht hauptsächlich durch meine eigentlichen Prompts zustande. Teuer waren vor allem die zahlreichen kompletten Umbauten, wiederholten Codeanalysen, Browserdurchläufe, Screenshots, Bildgenerierungen und Fehlerkorrekturen. Jede Iteration musste außerdem einen wachsenden Projektkontext berücksichtigen.

Mein erster Prompt

Mein Ausgangsprompt lautete sinngemäß:

Ich möchte ein 3D-Rennspiel entwickeln, das in Berlin spielt. Nutze bekannte Orte und Bilder beziehungsweise Street View als Referenz. Das Spiel soll zunächst als Browserversion funktionieren, später aber eventuell auch als App. Es soll keinen Login geben, drei Schwierigkeitslevel besitzen und direkt spielbar sein. Eine Rennstrecke reicht fürs Erste. Entwickle ein Konzept, einen guten Titel, ein ansprechendes Design und eine Datei, die ich auf meiner Website einbinden kann.

Der Prompt enthielt bereits mehrere hilfreiche Produktentscheidungen:

• Browser als erste Zielplattform
• keine Benutzerkonten
• nur eine Strecke
• drei Schwierigkeitsgrade
• Berlin als klar definierte Spielwelt
• eine direkt einbindbare Datei als Ergebnis
• eine spätere App als mögliche Erweiterung

Gleichzeitig blieben zentrale Fragen offen. Ich hatte nicht festgelegt, ob das Spiel eher realistisch, stilisiert oder bewusst arcadeartig aussehen sollte. Es gab keine Zielgeräte, keine maximale Dateigröße, keine Mindestbildrate und keine genaue Definition des Fahrgefühls. Auch „direkt spielbar“ konnte sowohl „ohne Login“ als auch „ohne vorgeschaltetes Menü“ bedeuten.

ChatGPT musste diese Lücken selbst ausfüllen. Das führte schnell zu einem funktionsreichen Prototyp, aber auch zu gestalterischen Entscheidungen, die nicht meiner späteren Vorstellung entsprachen.

Die Rollenverteilung im Experiment

Während der Entwicklung übernahm ich weniger die Rolle eines Programmierers als die eines Creative Directors, Product Owners und manuellen Testers.

Diese Aufteilung funktionierte grundsätzlich gut. ChatGPT konnte in kurzer Zeit wesentlich mehr technische Arbeit ausführen, als ich als Laie selbst hätte umsetzen können. Meine wichtigste Aufgabe bestand jedoch darin, die Ergebnisse nicht nur anhand der beschriebenen Änderungen, sondern durch eigenes Spielen zu beurteilen.

Version 1: Schnell spielbar, aber stark stilisiert

Die erste Version hieß „Spree Rush: Berlin“. Sie entstand als vollständig prozedural aufgebautes Three.js-Spiel in einer einzelnen HTML-Datei.

Die Berliner Welt bestand nicht aus realen 3D-Modellen oder kopierten Street-View-Aufnahmen. Stattdessen erzeugte der Code Straßen, Häuser, Lichter und vereinfachte Sehenswürdigkeiten aus Three.js-Geometrie. Street View und andere Bilder dienten nur als visuelle Referenz.

Der erste Build enthielt bereits erstaunlich viele Funktionen:

• ein stilisiertes 3D-Nachtrennen
• acht Checkpoints
• drei Schwierigkeitsstufen
• unterschiedliche Zeitlimits
• KI-Verkehr
• Nitro und Drift
• lokale Bestzeiten
• Berliner Landmarken
• Tastatur- und Touchsteuerung
• Pause und Neustart
• synthetisch erzeugte Geräusche
• eine responsive Desktop- und Mobilansicht

Ein automatisierter Chromium-Test prüfte Start, Steuerung, Checkpoints, Pause und mobile Darstellung. Technisch war das ein überzeugender erster Prototyp.

Optisch blieb das Ergebnis jedoch weit von einem modernen Berlin-Rennspiel entfernt. Gebäude wirkten wie einfache Blöcke, Fahrzeuge wie primitive Geometrie und Sehenswürdigkeiten eher wie Symbole als wie reale Orte.

Die erste wichtige Erkenntnis lautete deshalb:

KI kann sehr schnell ein vollständiges Spielsystem erzeugen. Der Umfang der Funktionen sagt aber wenig über die visuelle Qualität aus.

Version 2: Mehr Realismus als Prompt, aber noch kein realistisches Fundament

Mein nächster Prompt verlangte ein moderneres und realistischeres Spiel. Ich wollte einen Tag- und Nachtmodus, deutlich erkennbare Berliner Sehenswürdigkeiten, bessere Motorengeräusche, mehr Stadtatmosphäre und den neuen Titel „Spree Rush 1“.

ChatGPT erweiterte daraufhin die vorhandene Version. Es kamen ein auswählbarer Tagesmodus, mehr Landmarken, eine überarbeitete Präsentation und zusätzliche Umgebungsdetails hinzu.

Das Ergebnis wirkte umfangreicher, aber nicht grundlegend realistischer. Der Grund lag nicht in fehlenden Adjektiven im Prompt, sondern in der technischen Basis: Eine Stadt aus einfachen Boxen wird nicht fotorealistisch, nur weil Beleuchtung, Farben und Anzahl der Landmarken verändert werden.

Hier zeigte sich ein typisches Problem KI-gestützter Entwicklung. Das Modell reagierte auf „realistischer“ zunächst mit Änderungen, die innerhalb des bestehenden Systems leicht umsetzbar waren. Es verbesserte die Oberfläche, obwohl meine Erwartung eigentlich einen Austausch des visuellen Fundaments erforderte.

Version 3: Viele neue Funktionen, aber zu wenig spürbare Veränderung

Mein nächster Prompt war wesentlich umfangreicher. Ich verlangte unter anderem:

• einen glaubwürdigeren V8-Benzinersound
• fotorealistischere Fahrzeuge und Umgebungen
• eine deutlich längere Strecke
• mehr Kurven und Brücken
• drei Runden
• ausschließlich Tageslicht
• Rückprall und Geschwindigkeitsverlust bei Kollisionen
• keine zufälligen Hindernisse auf der Fahrbahn
• drei unterschiedliche Fahrzeuge
• eine Hupe
• eine scherzhafte „Berlin-Taste“, mit der Müll aus dem Fenster geworfen wird
• ein neues Menü
• eine klarere Berliner Identität

ChatGPT verlängerte die Route von ungefähr 499 auf 1.508 interne Streckeneinheiten. Das Rennen bestand nun aus drei Runden mit insgesamt 24 Checkpoints. Drei Fahrzeuge konnten ausgewählt werden, Hupe und Wurfmechanik wurden eingebaut, Straßenbegrenzungen erhielten Rückprall und die Welt bekam KI-generierte Texturen und Fotolayer.

Die ausgelieferte Version bestand ihre technischen Tests. Im Code waren die neuen Funktionen tatsächlich vorhanden. Trotzdem meldete ich nach dem Anspielen zurück:

Deine Änderungen scheinen nicht eingearbeitet worden zu sein. Das Spiel spielt sich immer noch wie die letzte Version.

Diese Rückmeldung war korrekt. Ein Screenshot der ausgelieferten Datei zeigte, dass vor allem das Menü neu war. Die eigentliche Spielwelt bestand weiterhin weitgehend aus derselben blockigen Three.js-Szene. Die längere Strecke war technisch vorhanden, doch Kamera, Fahrgefühl, Straßenbild und Gebäudedarstellung hatten sich nicht tief genug verändert.

Das war der wichtigste Wendepunkt des gesamten Experiments.

ChatGPT hatte einen erfolgreichen Featuretest mit einer erfolgreichen Überarbeitung gleichgesetzt. Die Aussage, die „große neue Version“ sei fertig, war zu weitgehend. Ein Test konnte bestätigen, dass drei Autos auswählbar waren und nach 24 Checkpoints das Ziel erschien. Er konnte nicht automatisch bestätigen, dass sich das Spiel für einen Menschen wesentlich besser anfühlte.

Version 4: Vom Featuretest zur tatsächlichen Ursachenanalyse

Nach meiner Kritik prüfte ChatGPT erstmals gezielt die ausgelieferte Einzeldatei und nicht nur den Entwicklungsstand oder interne Testfunktionen.

Dabei wurde unterschieden zwischen:

1. einer Funktion, die im Code existiert,
2. einer Funktion, die im normalen Spiel erreichbar ist,
3. einer Änderung, die der Spieler wirklich wahrnimmt.

Für Version 4 wurden deshalb tiefere Systeme überarbeitet:

• variable Straßenbreiten
• schmale Kiezstraßen und breite Hauptachsen
• getrennte Brückenabschnitte
• ein geschwindigkeitsabhängiges Lenkmodell
• neue Grip- und Bremsberechnungen
• Gang- und Drehzahllogik
• eine tiefere Verfolgerkamera
• eine sichtbare Streckenkarte
• neue Berliner Fassadentexturen
• ein eigener Build-Identifier
• Testfunktionen für Kollisionen, Checkpoints und Fahrverhalten

Auch dieser Umbau verlief nicht geradlinig. Der erste Test hing an einer temporären Chromium-Installation. Ein älteres Testskript blieb in einer Kollisions-Wartebedingung stecken. In der Software-GPU des Testsystems liefen 0,85 Sekunden reale Zeit teilweise nur als etwa 0,15 Sekunden Spielsimulation, wodurch Beschleunigung und Lenkung extrem träge wirkten.

Weitere Prüfungen fanden einen Off-by-one-Fehler beim automatischen Drei-Runden-Nachweis. Außerdem war die Fahrbahn wegen einer verkehrten Flächenorientierung teilweise unsichtbar. Was im Screenshot wie grüner Boden aussah, war nicht nur eine schlechte Textur, sondern ein Renderingfehler.

Ein weiterer Fehler betraf das Fahrzeug: Ein fotorealistisches Heckbild lag über dem alten blockigen 3D-Chassis. Aus der vorgesehenen Kameraperspektive wirkte das zunächst akzeptabel, aus anderen Winkeln wurde die Konstruktion sofort sichtbar.

Diese Fehler wurden korrigiert. Die neue Datei erhielt außerdem einen eigenen Namen und einen sichtbaren Build-Hinweis. Dadurch ließ sich ausschließen, dass der Browser erneut eine alte Version aus dem Cache lud.

Die Lehre daraus:

Versionsnummern sind nicht nur organisatorisch wichtig. Bei Browsergames sind eindeutige Dateinamen, Build-IDs und Cache-Parameter Bestandteil der Qualitätssicherung.

Version 5: Referenzbilder machen Feedback messbarer

Für Version 5 lieferte ich mehrere Berliner Fotos sowie die Datei Problem.png. Darauf war deutlich zu sehen, dass das rote Auto über der Straße schwebte.

Mein Prompt enthielt diesmal nicht nur neue Wünsche, sondern auch klare Bestandsschutzregeln:

• Menü unverändert lassen
• Streckenlänge beibehalten
• Karte und Steuerung beibehalten
• Sound von Auto 1 nicht verändern
• Sounds von Auto 2 und 3 verbessern
• rotes Auto auf der Straße platzieren
• Asphalt und Kopfsteinpflaster mischen
• Straßen unterschiedlich breit gestalten
• Gehwege sichtbar erhöhen
• Gebäude immer vollständig neben der Straße platzieren
• die gelieferten Berlin-Bilder als visuelle Referenz verwenden

Dieser Prompt war wesentlich wirksamer als die allgemeine Aufforderung, alles „realistischer“ zu machen. Er trennte gewünschte Änderungen von bereits akzeptierten Bestandteilen.

Warum das rote Auto schwebte

Die Ursache lag nicht in der Position des 3D-Fahrzeugs. Die drei KI-generierten Heckansichten enthielten unterschiedlich viel transparenten Leerraum unter den Reifen.

Wurden alle Bilder mit demselben Offset positioniert, erschien das rote Fahrzeug höher als die anderen Modelle. ChatGPT musste deshalb für jedes Fahrzeug einen individuellen Bildanker an der tatsächlichen Reifenlinie definieren.

Das Beispiel zeigt den Wert visueller Fehlerbelege. Die Formulierung „Das Auto schwebt“ beschrieb das Symptom. Der Screenshot machte Position, Fahrzeugmodell und Perspektive eindeutig und führte damit zu einer konkreten technischen Diagnose.

Erhöhte Gehwege und sichere Gebäudeabstände

Die Gehwege wurden um 24 Zentimeter gegenüber der Straße angehoben und erhielten sichtbare Bordsteinkanten.

Bei den Häusern reichte es nicht, nur den Mittelpunkt eines Gebäudes außerhalb der Straße zu platzieren. Ein breites Gebäude konnte mit seiner Grundfläche trotzdem in die Fahrbahn ragen. Deshalb wurde der gesamte Gebäudegrundriss gegen Fahrbahn, Gehweg und Sicherheitsabstand geprüft.

Auch diese Lösung musste erweitert werden. An einer engen Streckenschleife konnte ein Haus vom aktuellen Straßenabschnitt korrekt entfernt sein, aber in einen anderen Streckenbogen hineinragen. Die Prüfung musste daher global gegen alle relevanten Streckenpunkte erfolgen. Gebäude, die nach mehreren Verschiebungsversuchen keinen sicheren Standort erreichten, wurden gar nicht erzeugt.

Der abschließende Test ermittelte für normale Gebäude einen Mindestabstand von 4,94 internen Einheiten zur Fahrbahn.

Fotorealistische Bilder sind noch keine fotorealistische Welt

Aus meinen Referenzen wurden neue Materialien für Berliner Fassaden, Asphalt und unregelmäßiges Kopfsteinpflaster erzeugt.

Ein erster Versuch, eine große fotorealistische Landmarkenebene in die Szene einzubauen, scheiterte visuell. Aus einer günstigen Kameraposition sah die Ebene überzeugend aus. Bei einer schrägen oder mobilen Perspektive wirkte sie wie eine riesige Fotowand.

Die Ebene wurde deshalb wieder entfernt. Fotografische Texturen blieben nur auf räumlich passenden 3D-Flächen wie Straßen und Fassaden.

Danach wurden zwei weitere alte Szenenfehler sichtbar. Zunächst ragte die polygonale Basis der Siegessäule in die Fahrbahn. Anschließend stellte sich heraus, dass die ursprünglich über große Teile der Karte gelegte Spree-Wasserfläche samt Ufermauer eine Straße außerhalb der Brückenabschnitte durchschnitt.

Die Siegessäule wurde versetzt und das Wasser auf die beiden tatsächlichen Brückenbereiche begrenzt.

Diese Korrekturen zeigen, warum automatisierte Tests und Screenshots unterschiedliche Aufgaben erfüllen. Ein geometrischer Test kann Gebäudeabstände prüfen. Er erkennt aber nicht automatisch, dass eine Fototextur wie eine Kulisse aussieht oder ein Landmarkenfundament die Sichtachse stört.

Der technische Stand nach fünf Versionen

Die fünfte Version ist weiterhin ein Prototyp, aber kein kleines Wegwerfexperiment mehr.

Der aktuelle Entwicklungsstand umfasst:

• rund 2.900 Zeilen JavaScript
• rund 1.065 Zeilen CSS
• mehrere Browser- und Smoke-Testskripte
• 21 generierte Bildassets im Projekt
• eine etwa 2,3 MB große gebündelte HTML-Version
• ein ungefähr 20 MB großes Source-Paket mit ursprünglichen Bilddateien
• drei Runden und 24 Checkpoints
• eine Strecke mit rund 1.508 internen Einheiten
• Asphalt-, Pflaster- und Brückenabschnitte
• drei Fahrzeuge mit getrennten Parametern
• Tastatur- und Touchsteuerung
• synthetische Motor-, Reifen-, Wind- und Stadtgeräusche
• erhöhte Gehwege und globale Gebäudeabstandsprüfungen
• eine diagnostische Schnittstelle für automatisierte Tests

Die V5 ist deutlich besser als die erste Version. Sie ist aber nicht „100 Prozent fotorealistisch“. Sie kombiniert echte Three.js-Geometrie mit KI-generierten Fototexturen und zweidimensionalen Fahrzeugdarstellungen. Diese Hybridtechnik kann aus einer festen Verfolgerperspektive gut aussehen, erreicht aber nicht die räumliche Qualität hochwertiger GLB-Fahrzeuge, PBR-Materialien und professionell modellierter Stadtumgebungen.

Was meine Prompts bewirkt haben

Nicht jede Formulierung hatte denselben Einfluss.

Was an meinen Prompts gut funktionierte

1. Ich beschrieb das Produkt, nicht nur einzelne Funktionen

Berlin, Browser, drei Schwierigkeitsstufen, keine Anmeldung und eine einbindbare Datei ergaben zusammen ein verständliches Produktziel. ChatGPT konnte dadurch selbstständig Architekturentscheidungen treffen.

2. Ich testete das Spiel selbst

Der entscheidende Fehler der dritten Version wurde nicht durch einen automatisierten Test, sondern durch mein eigenes Fahrgefühl entdeckt. Hätte ich mich nur auf die Änderungsübersicht verlassen, wäre eine oberflächliche Überarbeitung als Erfolg durchgegangen.

3. Ich sagte ausdrücklich, was unverändert bleiben sollte

In V5 waren Menü, Strecke, Karte, Steuerung und der Sound von Auto 1 bereits akzeptiert. Ihre explizite Nennung reduzierte das Risiko, dass funktionierende Bereiche bei einer weiteren Überarbeitung verschlechtert wurden.

4. Ich lieferte visuelle Referenzen

Die Berlin-Fotos gaben der Aufforderung „realistischer“ eine konkrete Richtung. Problem.png verwandelte eine subjektive Beschreibung in einen reproduzierbaren Fehlerfall.

5. Ich formulierte negative Anforderungen

„Keine Gebäude auf der Straße“, „keine Hindernisse in der Fahrbahn“ und „Wasser nur an Brücken“ sind oft wirksamer als abstrakte Qualitätswünsche. Sie definieren beobachtbare Zustände, die sich testen lassen.

Was ich an meinen Prompts verbessern würde

Zu viele Systeme in einer Iteration

Der Prompt für Version 3 verlangte gleichzeitig eine längere Strecke, neue Fahrzeuge, neue Sounds, mehr Fotorealismus, andere Kollisionen, drei Runden, neue Mechaniken und ein neues Menü.

ChatGPT konnte viele Punkte formal abhaken. Die wichtigste Erwartung – ein deutlich anderes Fahr- und Weltgefühl – ging dabei jedoch unter.

Besser wäre folgende Reihenfolge gewesen:

1. Strecke und Straßenraum überarbeiten
2. Fahrphysik und Kamera testen
3. Fahrzeugdarstellung verbessern
4. Umgebung und Landmarken austauschen
5. Sound integrieren
6. zusätzliche Mechaniken ergänzen

Jeder Schritt hätte eine eigene spielbare Abnahme erhalten.

„Fotorealistisch“ war nicht präzise genug

Für mich bedeutete Fotorealismus eine glaubwürdige Berliner Straße mit korrekten Proportionen, räumlichen Gebäuden, realistischen Autos und natürlichen Materialien.

Das Modell interpretierte den Begriff zunächst als fotorealistisches Menümotiv, neue Texturen und Fotolayer. Diese Elemente erfüllten einen Teil des Wortlauts, aber nicht meine eigentliche Erwartung.

Ein besserer Prompt hätte festgelegt:

• keine flachen Fotowände
• keine sichtbaren Blockgebäude
• echte räumliche Fahrbahn
• erkennbare Bordsteine
• Fahrzeuge mit Kontakt zur Straße
• Gebäudegrundflächen vollständig außerhalb des Fahrraums
• Screenshots aus mindestens drei Kameraperspektiven
• bekannte Einschränkungen vor der Auslieferung offen nennen

Anforderungen und Abnahme waren nicht getrennt

Ein Entwicklungs-Prompt sollte nicht nur erklären, was gebaut werden soll. Er sollte auch definieren, woran der Erfolg erkennbar ist.

Für die längere Strecke hätte ein Kriterium beispielsweise gelautet:

Die neue Runde muss beim normalen Spielen mindestens dreimal so lange dauern wie die bisherige und im Streckenverlauf sichtbar neue Abschnitte enthalten.

Damit wäre eine rein mathematische Verlängerung ohne ausreichend neues Spielerlebnis nicht als vollständiger Erfolg durchgegangen.

Die größten Fehler von ChatGPT

1. Zu frühe Erfolgsmeldungen

Die problematischste Stelle war nicht der technische Fehler selbst, sondern die Aussage, die große Überarbeitung sei abgeschlossen. Tatsächlich waren Menü und Featureliste stärker verändert als die wahrgenommene Spielwelt.

Eine bessere Abschlussmeldung hätte zwischen „implementiert“, „automatisiert geprüft“, „visuell geprüft“ und „noch nicht auf realem Gerät bestätigt“ unterschieden.

2. Tests prüften zunächst die falschen Dinge

Interne Diagnosefunktionen konnten Checkpoints überspringen, Kollisionen erzwingen und Fahrzustände simulieren. Das war für Regressionstests nützlich, bildete das normale Spielerlebnis aber nicht vollständig ab.

Ein Test, der das Fahrzeug direkt zum nächsten Checkpoint teleportiert, beweist die Rundenlogik. Er beweist nicht, dass die Strecke gut fahrbar, abwechslungsreich oder optisch überzeugend ist.

3. Visuelle Qualität wurde zu spät geprüft

Mehrere Probleme wurden erst nach Screenshots aus konkreten Kameraperspektiven entdeckt:

• unsichtbare Straßenflächen
• Fotolayer über alten Blockmodellen
• schwebendes rotes Auto
• eine Landmarkenebene als Fotowand
• Siegessäulenfundament auf der Straße
• Wasser und Ufermauer im Fahrraum

Bei 3D-Projekten sollte visuelle Qualität deshalb während jeder Iteration geprüft werden und nicht erst nach bestandenen Code-Tests.

4. Die Einzeldatei wurde zu lange als Zielarchitektur behandelt

Eine einzelne HTML-Datei war für den ersten Prototyp ideal. Sie ließ sich direkt herunterladen, öffnen und später per iframe einbinden.

Mit zunehmender Komplexität wurde sie jedoch zum Hindernis. Modelle, Texturen, Audio, Physik, Leveldaten und Tests sollten in einem regulären Projekt organisiert werden. Eine gebündelte Einzeldatei kann weiterhin als Export entstehen, sollte aber nicht die eigentliche Entwicklungsarchitektur bestimmen.

5. Der gewählte Lösungsweg wurde nicht früh genug hinterfragt

Fototexturen und 2.5D-Fahrzeugbilder waren clevere kurzfristige Verbesserungen. Sie konnten das fehlende 3D-Asset-Fundament jedoch nicht ersetzen.

Statt den bestehenden Prototyp immer weiter zu dekorieren, wäre ab einem bestimmten Qualitätsziel ein sauberer Neuaufbau günstiger gewesen.

Warum ein anderes Sprachmodell nicht automatisch ein besseres Spiel erzeugt

Nach V5 stellte sich die Frage, ob Vibe Coding mit Claude für die Weiterentwicklung besser geeignet wäre.

Ein anderes Modell könnte einzelne Systeme anders strukturieren, Fehler früher erkennen oder bei langen Codebasen andere Stärken besitzen. Der sichtbare Qualitätsunterschied zwischen diesem Prototyp und einem modernen Rennspiel entsteht aber hauptsächlich außerhalb des Sprachmodells.

Entscheidend sind:

• hochwertige 3D-Fahrzeugmodelle
• modulare Gebäude und Straßenelemente
• PBR-Materialien
• realistische Beleuchtung und Reflexionen
• eine richtige Physik-Engine
• Animationen und Federung
• aufgenommene oder lizenzierte Motorsamples
• Leveldesign
• Performanceoptimierung
• systematische Tests

Claude statt ChatGPT würde eine fehlende Asset-Pipeline nicht ersetzen. Der sinnvollere Ansatz ist, ChatGPT beziehungsweise Codex als Entwicklungsassistenten in einer besseren Produktionsumgebung einzusetzen.

Der sinnvollste nächste technische Schritt

Für eine kleine, möglichst kostengünstige Browser- und App-Version würde ich den jetzigen Prototyp nicht endlos erweitern. Ich würde ihn als Konzept und Referenz verwenden und „Spree Rush Mini“ strukturiert neu aufsetzen.

Ein geeigneter kostenloser Stack wäre:

• Vite als Entwicklungs- und Buildsystem
• TypeScript statt einer immer größeren JavaScript-Datei
• Three.js für die Darstellung
• Rapier für Kollisionen und Fahrzeugphysik
• Blender für Fahrzeuge, Straßen und Gebäude
• GLB für komprimierte 3D-Modelle
• optimierte Texturen statt eingebetteter großer PNG-Dateien
• PWA-Funktionen für die Installation im Browser
• Capacitor für eine spätere Android-App

Als erstes Ziel würde ich keinen vollständigen Berlin-Rundkurs bauen, sondern einen kurzen Vertical Slice:

• ein überzeugendes Fahrzeug
• ein breiter Asphaltabschnitt
• eine enge Kopfsteinpflasterstraße
• ein Brückenabschnitt
• eine klar erkennbare Berliner Landmarke
• ein vollständiges kurzes Rennen
• stabile Desktop- und Touchsteuerung

Erst wenn dieser Ausschnitt in Grafik, Fahrgefühl und Performance überzeugt, sollte die Welt erweitert werden.

Ein besseres Prompt-Format für kommende Versionen

Künftige Entwicklungs-Prompts würde ich nach einem festen Schema schreiben:

PROJEKT
Spree Rush Mini – Browser- und PWA-Rennspiel.

ZIEL DIESER ITERATION
Nur Fahrphysik und Fahrzeugkontakt zur Straße überarbeiten.

UNVERÄNDERT LASSEN
Menü, Strecke, Karte, Checkpoints, Touchsteuerung und Auto-1-Sound.

ÄNDERUNGEN
- Fahrzeug darf optisch nicht schweben.
- Räder müssen Asphalt und Pflaster sichtbar berühren.
- Lenkung soll bei niedriger Geschwindigkeit direkter reagieren.
- Bei hoher Geschwindigkeit soll der maximale Lenkwinkel sinken.
- Pflaster soll weniger Grip als Asphalt haben.

ABNAHMEKRITERIEN
- Screenshots mit allen drei Fahrzeugen auf Asphalt und Pflaster.
- Automatisierter Test für die individuellen Fahrzeuganker.
- 30 Sekunden normale Testfahrt ohne Konsolenfehler.
- Keine Änderung an den als unverändert markierten Bereichen.

AUSLIEFERUNG
- neuer Build-Identifier
- neuer cache-sicherer Dateiname
- kurze Liste der geprüften Kriterien
- offene Einschränkungen ausdrücklich nennen

Dieses Format reduziert Interpretationsspielraum und verhindert, dass eine Änderung an einem System unbeabsichtigt mehrere bereits akzeptierte Bereiche beeinflusst.

So lässt sich der Tokenverbrauch künftig reduzieren

Der größte Effizienzgewinn entsteht nicht durch kürzere Formulierungen, sondern durch weniger unnötige Neuimplementierungen.

Für zukünftige Iterationen würde ich:

1. eine dauerhafte Spezifikationsdatei im Projekt führen,
2. akzeptierte Funktionen und bekannte Fehler dokumentieren,
3. pro Iteration nur ein oder zwei Systeme ändern,
4. messbare Abnahmekriterien vor dem Coding festlegen,
5. automatisierte Regressionstests erhalten,
6. visuelle Vergleichsscreenshots erzeugen,
7. neue Chats nur mit der Spezifikation und dem aktuellen Build starten,
8. Quellcodeänderungen statt wiederholter Komplett-Rebuilds verlangen,
9. Bildgenerierung erst nach geklärter Geometrie einsetzen,
10. vor jeder Auslieferung exakt die bereitgestellte Produktionsdatei testen.

Damit muss das Modell nicht in jeder Runde den gesamten Entwicklungsverlauf neu rekonstruieren. Gleichzeitig sinkt das Risiko, dass alte Anforderungen vergessen oder bereits gelöste Fehler erneut eingebaut werden.

Mein Fazit nach fünf Versionen

Das Experiment war als erster Test sehr erfolgreich. Aus einem einzigen natürlichen Sprachprompt entstand an einem Tag ein echtes, spielbares 3D-Browsergame mit eigener Gestaltung, mehreren Fahrzeugen, Berlin-Strecke, Sound, Touchsteuerung und automatisierten Tests.

Genauso deutlich wurden jedoch die Grenzen sichtbar.

ChatGPT ist sehr gut darin, schnell Breite zu erzeugen: Menü, HUD, Steuerung, Checkpoints, Schwierigkeitsgrade, Sounds und Effekte können innerhalb kurzer Zeit zusammenkommen. Schwieriger ist die Tiefe: glaubwürdige Fahrzeugphysik, räumlich korrekte Umgebungen, konsistente visuelle Qualität und echtes Fotorealismusniveau benötigen eine geeignete Asset- und Produktionspipeline.

Die wichtigste Erfahrung war deshalb nicht, dass ich meinen ersten Prompt genauer hätte formulieren müssen. Entscheidend war die Erkenntnis, dass KI-gestützte Spieleentwicklung weiterhin eine klare Abnahme braucht.

Das Modell kann programmieren, Bilder erzeugen, Fehler suchen und Tests ausführen. Es kann aber nicht zuverlässig selbst entscheiden, ob sich ein Rennspiel wirklich neu, schnell, glaubwürdig oder hochwertig anfühlt. Diese Bewertung blieb meine Aufgabe.

Die fünfte Version von „Spree Rush 1“ ist noch nicht perfekt. Sie ist aber ein funktionierender Beweis dafür, dass auch ohne klassische Erfahrung in der Spieleentwicklung innerhalb weniger Stunden ein eigener Prototyp entstehen kann.

Der nächste Qualitätssprung wird nicht durch einen noch längeren Prompt oder den einfachen Wechsel zu einem anderen KI-Modell entstehen. Er wird durch einen kleineren, sauber geplanten Umfang, echte 3D-Assets, eine bessere Projektarchitektur und strengere visuelle Abnahmekriterien erreicht.

Genau darin liegt für mich der größte Nutzen von ChatGPT bei der Spieleentwicklung: nicht als magische Maschine, die auf Anhieb ein fertiges Spiel ausgibt, sondern als extrem schneller technischer Partner, dessen Arbeit durch konkrete Ziele, gute Referenzen und ehrliches menschliches Testing gesteuert werden muss.