Fluchtpunkt

Keine Technologie hat die Softwareentwicklung in so kurzer Zeit so stark verändert wie generative künstliche Intelligenz mit Sprachmodellen (LLM). Die Entwicklung von Computerprogrammen war teure und zeitaufwendige Hand- bzw. Kopfarbeit. Generative KI hat Softwareentwicklung billiger gemacht. Viel billiger! Jetzt sind für Einzelentwickler Projekte möglich, die vor einem Jahr noch undenkbar waren.

Nach dem Sprung von Maschinencode zu Assembler und von Assembler zu Hochsprachen erfolgt nun der Übergang zur Programmierung in natürlicher Sprache. Das war immer die originäre Vision für menschliche Interaktionen mit Computern. Vor zwei Jahren war das noch Science-Fiction. Jetzt sinkt dadurch die Einstiegshürde dramatisch. Softwareentwicklung wird endlich wieder einfach! Man kann sich auf das eigentliche Problem konzentrieren, ohne sich durch 500 Zeilen Initialisierungscode eines unbekannten Grafik-Subsystems kämpfen zu müssen, um eine einfache Linie auf dem Bildschirm zu zeichnen.

Am besten fasst es meiner Meinung nach dieses Zitat zusammen:

"Maybe there is an enormous amount of code-shaped value waiting to exist, and AI happens to make that value cheap enough to create."
— Hank Green, 2026

Mein Code-Shaped Value heißt „Fluchtpunkt“. Es ist ein Retro-Rennspiel mit Pseudo-3D-Grafik, dessen Umsetzung für mich als Einzelentwickler bislang so unrealistisch war, dass ich vor drei Monaten noch nicht wusste, dass ich es überhaupt wollte. Dies ist die Geschichte eines Speedruns in Spieleentwicklung und meiner Suche nach der Antwort auf die Frage: Endet ein KI-generiertes Computerspiel zwangsläufig in Slop?

Die Inspiration: Lotus Turbo Challenge II

Frühe Rennspiele hatten ein Problem: Die Hardware war viel zu schwach, um echte 3D-Grafik darzustellen. So musste man sich etwas einfallen lassen. Die Lösung war Pseudo-3D. Die Straße wurde aus vielen horizontalen Bildzeilen zusammengesetzt, die gegeneinander verschoben wurden, um Kurven zu simulieren. Dafür gab es spezielle Grafikchips. Im Amiga waren das ein Blitterchip für die horizontale Verschiebung der Straßensegmente und ein Copperchip für deren Einfärbung.

Lotus Turbo Challenge 2 auf dem Amiga: Tagesstrecke mit Verkehr. © 1991 Magnetic Fields / Gremlin.

Strecke mit Schneefall. © 1991 Magnetic Fields / Gremlin.

Lotus Turbo Challenge 2 ist ein Vertreter dieser Klasse von Computerspielen. Es war eines der populärsten Rennspiele für den Amiga-Heimcomputer und taucht in praktisch allen Listen der besten Amigaspiele auf. Ich verwende es hier als Referenz und werde einige Mechaniken wie Tunnel und Wassergräben auch in „Fluchtpunkt“ übernehmen. Ich möchte ein modernes Pseudo-3D-Rennspiel entwickeln, das so gut wie möglich wird. Dafür investiere ich vor allem Zeit, aber auch ein wenig Geld und nutze alle KI-Tools, die mir zur Verfügung stehen.

Das Entwicklerteam

Entwickelt wurde Fluchtpunkt mit Claude Code, dem Kommandozeilentool von Anthropic. Das ist ein Agent, der direkt im Terminal läuft. Er kann Dateien lesen und schreiben, Kommandos ausführen, Unit-Tests starten und mit dem Versionskontrollsystem Git arbeiten. Das Team bestand aus mehreren Instanzen dieses Werkzeugs, die alle in einer tmux-Sitzung liefen (bzw. psmux auf Windows).

Die Teamstruktur: Ich beauftrage den Claude-Projektmanager und Codex. Der Projektmanager koordiniert mehrere KI-Agenten mit unterschiedlichen Zuständigkeiten. Nebenbei generiert Codex Sprites und Spielegrafiken.

Gestartet wird das Agententeam über ein Skript, wobei Projektmanager und Agenten ihre Rollen über Textdateien erklärt bekommen. Darin wird beschrieben, wo ihre Arbeitsverzeichnisse sind und welche Regeln für die Arbeit im Projekt gelten (Coding-Style, Architekturregeln wie SOLID, KISS).

Nur der Projektmanager nimmt Aufträge von mir entgegen, schneidet daraus Arbeitspakete zu und verteilt diese an die bis zu acht Entwicklerinstanzen. Diese werden vom Projektmanager automatisch in tmux-Panels gestartet und nach Beendigung ihrer Aufgabe auch wieder geschlossen. Jeder der Agenten arbeitet in einem eigenen Git-Worktree auf seinem eigenen Branch. Nach Fertigstellung eines Paketes prüft der Projektmanager die Ergebnisse der Agenten und führt diese im Hauptzweig zusammen. Zusätzlich lief noch eine freie Instanz von OpenAI Codex als Helfer für Sonderaufgaben wie Bildgenerierung.

Ein Auftrag kommt rein, sechs Agenten arbeiten los: Der Projektmanager versteht die Aufgabe, schneidet die Arbeit zu und verteilt die Pakete. Die Entwickler bearbeiten sie parallel.

Es ist die Übertragung der Funktionsweise eines Softwareteams auf agentische, nichtmenschliche Arbeitskräfte. Meine Rolle beschränkte sich auf die des Produkteigentümers, also die Festlegung der Entwicklungsrichtung, die Identifizierung von Aufgaben und die Abnahme der Änderungen. Ich beschreibe dem Projektmanager die nächste Aufgabe und der bereitet sie für sein Team auf und erstellt daraus eine Taskliste. Die wird dann von den rund um die Uhr arbeitenden Agenten abgearbeitet.

Zwei Agenten, die gleichzeitig an derselben Datei arbeiten, würden Merge-Konflikte verursachen, die mühselig aufgelöst werden müssten. Um das zu vermeiden, achtet der Projektmanager auch darauf, dass die Arbeitspakete überschneidungsfrei sind.

Die erste Version

Der erste Prompt verlangte nach der Erstellung eines Retro-Rennspiels mit Pseudo-3D-Grafik im Stil von „Lotus Turbo Challenge 2“ für einen JavaScript-basierten Softwarestack, da es ursprünglich in eine einzige HTML-Datei passen sollte. Das Ergebnis lag nach ein wenig Hin und Her ungefähr 30 Minuten später vor und war grafisch und spielerisch wenig beeindruckend. Die Sprites waren prozedural generiert, die Soundeffekte rudimentär und die Spielphysik fragwürdig.

Eine erste spielbare Version.

Jetzt stellte sich die Frage: Kann man es gut machen? Was käme dabei heraus, wenn man alle möglichen KI-Helfer auf das Problem wirft? Doch zunächst stand eine andere Richtungsentscheidung an: Der Stack wurde von mir auf TypeScript umgestellt, weil ich JavaScript als untypisierte Programmiersprache von meiner Sozialisierung als C++- und C#-Programmierer her für einen schrecklichen Fehler halte und zu diesem Zeitpunkt noch davon ausging, irgendwann in den Code schauen zu müssen. Die zweite Entscheidung war es, auf einen Canvas-basierten Renderer zu setzen. Eine Festlegung, die ich später zugunsten von WebGL in Kombination mit three.js revidiert habe.

Reverse Engineering des Originals

Eine durch Claude Code rekonstruierte originale Trackmap von Lotus Turbo Challenge II.

Das Problem mit der mangelhaften Fahrphysik habe ich die KI lösen lassen, indem ich ihr den Auftrag gab, „Lotus Turbo Challenge 2“ auf Basis des WHDLoad-Pakets von Version 1.11 der Original-Amiga-Version zu reverse-engineeren. Es ging darum herauszufinden, wie die Vorlage das Problem löste. Ich wollte alles wissen:

• Wie sind die Game-Assets organisiert?
• Wie sehen die Level aus und wie sind sie aufgebaut?
• Wie funktioniert die Motor- und Schaltungssimulation?
• Wie funktioniert das Wettersystem?

Das Ergebnis waren dutzende Dokumente, in denen die Funktionen der Vorlage im Detail beschrieben und ihre Assets komplett dekodiert und aufgeschlüsselt wurden. Das war extrem hilfreich, um den weiteren Plan zu erstellen, aber in „Fluchtpunkt“ konnte ich weder die Originalassets verwenden, noch konnte ich Spielmechaniken direkt kopieren. Mein Ziel war keine Kopie des Originals, sondern eine Hommage auf moderner Hardware.

Was ich zu der Zeit noch nicht wusste, ist, dass ich wenig später die KI auch eine komplette Portierung des Originalspiels auf C++ mit SDL 2.x durchführen lassen würde. Lotus Turbo Challenge 2 läuft jetzt bei mir auch auf Windows und Linux. Aus rechtlichen Gründen kann ich diese Portierung allerdings nicht veröffentlichen, denn sie benötigt ein Abbild der Original-Amiga-Diskette, um zu laufen.

Werkzeuge und Dienste

Spiele, deren Entwickler sich dazu bekennen, KI-generierte Assets einzusetzen, haben aktuell auf Steam einen schweren Stand. Die Plattform hat für deren Kennzeichnung ein Label „Made with AI“ eingeführt. Die Verwendung dieses Labels führt zu sofortigen Boykottaufrufen. Diese treffen dann die Entwickler, die ehrlich bei der Kennzeichnung waren.

Die Bedenken der Gegner von KI-generierten Inhalten beziehen sich darauf, dass Firmen wie OpenAI und Anthropic ihre Modelle mit Daten trainieren, die sie von Digitalkünstlern ohne deren Wissen gestohlen haben, um damit Produkte zu generieren, die mit ihnen um Aufträge konkurrieren. Das ist nicht falsch, aber auch inkonsequent, denn der Stein des Anstoßes sind immer nur die Game-Assets. Programmerzeugung mittels agentischer KI scheint in den Augen der Community kein boykottrelevantes Vergehen zu sein.

Da das ein Projekt ist, von dem ich keinen finanziellen Gewinn erhoffe, kann ich hier offen über alle verwendeten Werkzeuge und die Herkunft der Assets schreiben.

Verwendete Dienste und deren Kosten

Generative KI wurde für die Erstellung des Quellcodes, die Erstellung aller Billboard-Sprites, für Hintergrundbilder und für alle Musikstücke und Soundeffekte eingesetzt. Im Einzelnen wurden folgende Dienste verwendet:

Dienst	Verwendung	Kosten
Claude Code (Max 20×)	Programmierung und Agententeam	200 US$ / Monat
OpenAI Codex (Pro 5×)	Spezialaufgaben, Reverse Engineering, Code-Analyse	100 US$ / Monat
OpenAI GPT Image	Game-Assets und visuelle Varianten	im OpenAI-Abo enthalten
Suno	Musik und Soundtrack	10 US$ / Monat
ElevenLabs	Soundeffekte	22 US$ / Monat

Grafik- und Soundassets

Fahrzeugmodelle

Die Fahrzeugmodelle sind der einzige Teil der Spiele-Assets, der nicht KI-generiert ist. Sie wurden zugekauft. Ich habe Tests mit generierten Modellen durchgeführt und solche auch mit Meshy.ai aus Fotos erstellt. Diesen Ansatz habe ich aus folgenden Gründen verworfen:

• Die aus Fotos erzeugten Modelle hatten keine dreh- und lenkbaren Räder und deren Meshes waren in für mich wichtigen Details unsymmetrisch.
• Aus rechtlichen Gründen dürfen in den Modellen keine erkennbaren Markenzeichen auftauchen.
• Die Modelle sollten sich auch von real existierenden Fahrzeugen unterscheiden, da diese unter Design- bzw. Markenschutz stehen könnten (z. B. Porsche 911).

Besser hat die Modellgenerierung durch KI mit Blender funktioniert. Das erzeugte Fahrzeug hatte zwar dreh- und lenkbare Räder, benutzte aber auch sehr viele Polygone und hatte einige visuelle Defekte:

3D-Modell laden (1,5 MB) Drehen mit Maus oder Finger, Zoom mit Mausrad

Letztendlich war es die beste Lösung, 3D-Fahrzeugmodelle zu kaufen. Entscheidend war, dass diese gut aussehen, kostengünstig sind und über keine erkennbaren Markenzeichen verfügen.

Dienst	Verwendung	Kosten
mena-assets.com	ARCADE: Retro Super Cars	96,00 €
mena-assets.com	ARCADE: Ultimate Vehicles Pack	22,40 €
Sketchfab, Fab.com	Einige 3D-Fahrzeugmodelle	kostenfreie Modelle

Fahrzeugsprites

Das Spiel verwendet nur für die Darstellung des Spielerfahrzeugs ein echtes 3D-Modell. Das ist das wichtigste Modell und ich wollte die Freiheit haben, es aus allen möglichen Blickwinkeln darzustellen. Das wird im Spiel verwendet, wenn das Fahrzeug auf einer Eisfläche ins Schlingern gerät und sich um 360° dreht.

Alle anderen Fahrzeuge sind vorgerenderte Sprites von 3D-Modellen in verschiedenen vordefinierten Ansichten. Die Fahrzeuge darin sind grau, weil die Farbe erst zur Laufzeit zugeteilt wird. Die Bögen mit den verschiedenen Fahrzeugsprites wurden mittels KI automatisiert aus den gekauften 3D-Modellen erstellt.

Die Spritebögen mit den vorberechneten Fahrzeugansichten in neutraler Wagenfarbe enthalten Ansichten von ±15° horizontal in zwei Sätzen mit jeweils 0° und 2° vertikalem Winkel.

Billboard-Sprites

Dieses KI-generierte Billboard-Sprite für den Straßenrand zeigt ein fiktives Filmplakat.

Billboard-Sprites sind zweidimensionale Grafiken, die in 3D- oder Pseudo-3D-Spielen verwendet werden, um Objekte darzustellen, ohne diese als echte 3D-Modelle abzubilden. Das ist schneller und weniger speicherintensiv. Die Darstellung kann wegen fehlender oder falscher Perspektive aber oft auch surreal wirken.

In „Lotus Turbo Challenge 2“ gab es nur eine Handvoll solcher Sprites. Die damals verwendeten Disketten als Speichermedium hatten eine Kapazität von nur 880 KB und auch der Computer selbst war mit 512 bis 1024 KB Hauptspeicher nach heutigen Verhältnissen sehr bescheiden ausgestattet.

Derartige Restriktionen existieren heute nicht mehr. Daher wurden für Fluchtpunkt über 750 verschiedene Billboard-Sprites erstellt. Hierfür wurde OpenAIs Image Generation Feature verwendet. Die Zahl ist so hoch, weil die meisten davon in vier verschiedenen Versionen vorliegen, eine für jede Jahreszeit. Das ermöglicht auch die Darstellung jedes Szenenbildes in verschiedenen Wettersituationen.

Winter mit leichtem Schneefall.

Ein sonniger Frühlingstag.

Ein sonniger Sommertag.

Herbsttag mit fallendem Laub.

Eine solche Menge an Bildassets ist nur praktikabel, wenn die Varianten automatisiert erzeugt werden können. Das Beauftragen eines Grafikers für ein Projekt mit diesem Umfang wäre teuer und würde sich nicht lohnen.

Sounddesign

Musik und Sounds sind komplett KI-generiert. Für jedes Level gibt es ein eigenes Musikstück, insgesamt sechs. Diese wurden mit Suno erzeugt. Wenn man dort nach Musik im Stile von Amiga MOD-Files fragt, dann erhält man ziemlich guten elektronischen Sound. Musik auf dem Amiga hatte einen unverkennbaren speziellen Klang. Der kam vom Musikteil eines seiner Custom-Chips (Paula). Dieser konnte gleichzeitig auf vier Stimmen 8-Bit-Samples mit bis zu 56 kHz ausgeben. Zu seiner Zeit war das konkurrenzlos.

Die Soundeffekte für Wetter und Fahrzeug, also Donner, Regengeräusche und Reifenquietschen, wurden mit ElevenLabs erzeugt.

Einige der In-Game-Sounds wie Motor, Kollisionen und Fahrzeuggeräusche nach Sprüngen kommen nicht aus Dateien, sondern werden in Echtzeit mit der Web Audio API synthetisiert. Die Grundlage lieferte auch hier das Reverse Engineering. Die Agenten analysierten die Soundeffekte und maßen Frequenzen und Hüllkurven nach. So liegt der Motor-Grundton bei 85 Hz und folgt der Drehzahl zwischen 48 und 191 Hz. Auch Gangwechsel sind als Drehzahlabfall hörbar.

Making it Pop

Die 1980er und 1990er Jahre waren die Blütezeit der Pseudo-3D-Rennspiele. Die besten Versionen gab es in Form von Arcade-Automaten. Das waren leistungsfähige Computerspielautomaten. Ihre Versionen liefen flüssiger und sahen besser aus als die Versionen für Heimcomputer. Wer spielen wollte, musste bezahlen. Viele der Titel führten besondere Spielmechaniken ein. In „Outrun“ gab es Straßengabelungen und das Spielerfahrzeug überschlug sich, wenn man auf Hindernisse stieß. In „Jaguar XJ 220“ konnte man Leitkegel und Pylonen umfahren. In „Powerdrift“ gab es dreidimensionale Strecken und das Bild wurde bei Kurvenfahrten leicht rotiert.

Was macht man, wenn Computerspieleentwicklung nur noch aus der Formulierung von Wünschen besteht? Man kopiert die interessantesten Spielmechaniken und denkt sich ein paar neue aus. Hier also eine Liste der von anderen Spielen inspirierten Mechaniken und wo sie herkommen:

Spielmechanik	Gesehen in	Beispiel	In Fluchtpunkt
Eis- und Ölflecken auf der Straße	„Lotus Turbo Challenge 2“ (1991)
Querverkehr über die Straße	„Lotus Turbo Challenge 2“ (1991)
Tunnel	„Lotus Turbo Challenge 2“ (1991)
Überspringbare Wassergräben	„Lotus Turbo Challenge 2“ (1991)
Verschiedene Wetterstimmungen	„Lotus Turbo Challenge 2“ (1991)
Auto dreht sich um 360°	„Outrun“ (Amiga, 1988)
Straßengabelungen	„Outrun“ (Amiga, 1988)
Brücken	„OutRunners“ (1993)
Umfahrbare Objekte	„Jaguar XJ 220“ (1992)
Bildschirm neigt sich in Kurven	„Powerdrift“ (1988)

Wenn Softwareentwicklung dank agentischer KI nur noch aus dem Formulieren von Wünschen besteht, dann werden auch Dinge wie Shaderprogrammierung, dynamisches Licht an Billboard-Sprites und Steilkurven möglich.

Animierte Sprites

Geschwindigkeitsabhängige Bewegungsunschärfe

Steilkurven

Fahrzeuggischt, Lichtkegel und nasse Straße

Gegen die eigene Bestzeit als Geisterfahrzeug fahren

Licht und Schatten durch Billboard-Sprites

Während man früher an der Implementierung der Animation getüftelt hätte, kann man sich jetzt endlich Gedanken über DIN-konforme Beschilderung der Bahnübergänge in einem Arcade-Rennspiel machen.

Fazit

Ohne agentische KI würde das Spiel nicht existieren. Wenn man es von Hand programmieren wollte, wären vermutlich zwei Programmierer ein Jahr lang damit beschäftigt. Die Kosten für die Programmierleistung und die Asset-Generierung wären enorm. Aber es existiert und ist besser als alles, was ich auf klassische Weise hätte erschaffen können.

Allerdings habe ich auch nichts Neues über Programmierung gelernt: nicht, wie man WebGL-Shader programmiert, nicht, wie die Transformationen der Spielwelt in Pseudo-3D genau funktionieren, nicht, wie die Datenbank strukturiert ist, in der die Spielläufe gespeichert werden. Nebenbei habe ich auch das Original Lotus Turbo Challenge 2 komplett auf Linux portiert. Ich weiß immer noch nichts von MC68000-Assembler, außer dass man früher so programmiert hat und frage mich, ob die nächste Generation der Softwareentwickler generell so auf Quellcode schauen wird: „Das ist etwas, das man früher so gemacht hat.“

Ist es überhaupt mein Spiel? Ist es Claudes? Ich weiß es nicht. Ich weiß, dass es Spaß macht und die Entwicklung war interessant. Das Einzige, was ich gelernt habe, ist, wie man mit einem Team von KI-Agenten Software entwickelt.

Kostenbilanz

Die Programmierung begann am 8. August 2026 mit dem ersten Commit im Repository. Bis heute sind das zwei volle Monate Claude-Abo. Musik und Soundeffekte wurden jeweils in einem einzigen Abo-Monat erzeugt.