Retro Vibes

Retro-Spielprogrammierung mit Large Language Models

Stefan Höltgen

Ein Gespenst geht um in Retrotopia: das Gespenst, das mit seiner künstlicher Intelligenz Computerspiele für historische Systeme programmiert. Und wohlgemerkt: Nicht nur Computerspiele und 8-Bit-Computer werden von diesem heimgesucht, sondern auch moderne Systeme, ihre Anwendungen und ihre Programmiersprachen! „Vibe Coding“ heißt das Verfahren, das es sogar Nicht-Programmierern ermöglichen soll, komplexe und lauffähige Software zu entwickeln, ohne auch nur eine einzige Zeile Code eintippen zu müssen. Jüngst ist ein solches Programm als Experiment für Ataris 8-Bit-Computer erschienen, programmiert in Assembler von Googles „Gemini“ und Arkadiusz Staworzynski (im Folgenden mit seinem Szene-Namen „Nosty“ zitiert).

„First AI Shooter“ hat Nosty das Spiel betitelt und „Gemini“ hatte keine Einwände (obwohl vielleicht unklar war, was Subjekt und Objekt in diesem Titel ist). Es handelt sich um einen recht altbacken wirkenden Vertical-Shooter: Man steuert darin eine kleine weiße Rakete am unteren Bildschirmrand und muss sich Aliens erwehren, die von oben herabgeflogen kommen. Dazu kann man ihnen ausweichen, sie beschießen oder, wenn es allzu gefährlich wird, sie mit einer von drei „Magabombs“ vom Bildschirm fegen. Dies alles findet vor einem ebenfalls vertikal scrollenden Sternenmeer statt. Zunächst erscheinen die Gegner noch einzeln und bewegen sich ausschließlich vertikal über den Bildschirm; bald wird das Spiel jedoch schneller, die Aliens schießen zurück und fliegen einem diagonal um die Ohren. Einen Levelwechsel gibt es nicht; man spielt so lange, bis alle drei Raketen, mit denen man zu Beginn ausgestattet ist, von den Gegnern abgeschossen wurden. Hat man dabei den vorherigen Highscore übertroffen, wird die aktuelle Punktezahl vermerkt.

Den Computer programmieren lehren

Nosty beschreibt auf dem polnischen „Atarionline“-Portal detailliert, was seine Motive für die Entwicklung des Spiels waren und wie er dabei vorgegangen ist. Eine Bedingung für ihn war, dass er selbst keinen Code schreiben, sondern dies allein von einem Large Language Model (LLM) erledigen lassen wollte. Hierfür stehen inzwischen ja mehrere zur Auswahl. Das bekannteste – „ChatGPT“ hat er in den Versionen 3.5, 4.0 und 5.0 zuerst getestet. Hierbei haben sich verschiedene Schwierigkeiten gezeigt, die mit der Unfähigkeit zu tun hatten, den XASM-Assembler syntaxkonform anzuwenden, so dass am Ende übersetzbarer Sourcecode herauskam. Version 5.0 habe sogar eine Internetquelle herbei „halluziniert“, aus der es seine Kenntnisse über die Register der Player-Missle-Grafik gewonnen haben wollte – die aber allesamt nicht korrekt waren.

Mit dem Sprachmodell „Claude“ von Anthropic funktionierte es schon etwas besser, allerdings wurden immer noch so viele Programmierfehler erzeugt, dass die Nachbearbeitung durch Nosty überproportional viel Zeit in Anspruch nahm. Erst mit Googles „Gemini“-KI in der Version „3 Pro“ erzielte er brauchbare Ergebnisse ohne allzu hohen Korrekturaufwand. Ein Programm, das er mit jeder der getesteten Sprachmodelle, zu implementieren versuchte, war die Erzeugung einer Smiley-Grafik auf dem Bildschirm. Hierzu verwendete er folgenden Prompt:

Sie sind ein exzellenter Programmierer mit Spezialisierung auf die Erstellung von Programmen im XASM-Assembler des 6502-Prozessors für den Atari 800XL. Erstellen Sie ein kurzes, vollständiges XASM-Assemblerprogramm, das ein von Ihnen entworfenes lächelndes Gesicht (ein sogenanntes Smiley) etwa in der Mitte des Bildschirms anzeigt. Das Smiley-Gesicht soll eine Auflösung von 8×8 Pixeln haben und rot sein. Beginnen Sie mit der Entwicklung der Programmstruktur und der wesentlichen Komponenten, schreiben Sie dann den Code und analysieren Sie ihn anschließend kritisch auf mögliche Fehler – syntaktische, logische und inhaltliche. Prüfen Sie, ob das Programm korrekt ausgeführt wird und seine beabsichtigte Funktion erfüllt. Hinweis: Wenn Sie sich bei etwas unsicher sind, fragen Sie mich. Ich kann programmieren und helfe gerne.

Gemini konnte dieses Prompt nicht sofort in ein funktionierendes Programm umsetzen. Also ergänzte Nosty das Prompt durch folgende Aufforderung zur Selbstreflexion: „Sehen Sie sich den beigefügten Screenshot an. Das Programm zeigt nichts an. Bitte analysieren Sie den Code noch einmal sorgfältig und finden und beheben Sie alle Fehler.“ Dies führte dazu, dass Gemini nach zwei weiteren Minuten tatsächlich Code erzeugte, der einen roten Smiley auf dem Bildschirm ausgab. Die Methode, dem Sprachmodell seine Fehlgriffe vor Augen zu führen, wandte Nosty in der Folge häufiger und mit wachsendem Erfolg an.

Lehrend lernen wir

Ich gebe selbst Programmierkurse in 6502-Assembler an Universitäten – in Studiengängen, die zumeist nur wenig mit Informatik zu tun haben. Mein Ziel ist es, den Studentinnen und Studenten hierdurch die Funktionsweise von Computern (auf der Hardwareebene) näher zu bringen. Beim Lesen der Darstellungen Nostys im Umgang mit „Gemini“ hatte ich die eine oder andere Reminiszenz an meine eigene Programmierlehre. Auch Nosty verfolgt hier eine eher konstruktivistische Didaktik, die man „moderierte Trial & Error-Programmierung“ nennen könnte und bei der erste (erfolgreiche) Programme in den folgenden Lernschritten immer weiter ausgebaut werden – bis hin zu einem fertigen Spiel.

Und so sollte auch „Gemini“ nun als nächstes eine Joystick-Steuerung für den Smiley implementieren, damit dieser über den Bildschirm bewegt werden konnte. Erstaunlicherweise kam hier nicht nur sofort lauffähiger Code zum Vorschein, sondern „Gemini“ hatte auch gleich noch die „Randbedingungen“ bedacht – also, was passieren sollte, wenn die Player-Missile-Grafik über einen der vier Bildschirmränder hinaus gesteuert würde. Solche „unaufgeforderten Innovationen“ erlebte Nosty im weiteren Programmierprojekt noch häufiger. So entwickelte „Gemini“ etwa ohne Aufforderung die animierte Starfield-Grafik und zeigte sich bei der Aufforderung einen Titelbildschirm zu generieren sogar bewandt darin, die Display-List so zu programmieren, dass mehrere verschiedene Schrift- und Grafik-Elemente angezeigt wurden.

Beim Wechsel von technisch-syntaktischen Fingerübungen zu ästhetischen Umsetzungen tat sich die Sprach-KI allerdings etwas schwerer. So überzeugte die Raketen-Grafik auf dem Startbildschirm zunächst nicht: „Es stellte sich heraus, dass Gemini nicht zeichnen kann“, witzelt Nosty in seiner Dokumentation über die Ergebnisse. Die Rakete, die in ihrem vertikalen Flug dargestellt werden sollte, sah verzerrt aus und auch die horizontale Variante wirkte eher wie ein Zäpfchen als wie ein Flugkörper. Hier zeigt sich in diesem Projekt zum ersten mal, dass ein LLM eben ein Sprach-Modell und nichts anderes (etwa eine Bild-Generierungs-KI) ist. Das verwechseln ja leider viele Nutzerinnen und Nutzer solcher LLM-Chatbox und wundern sich über deren Ausgaben.

Entwicklungshilfe

Der „First AI Shooter“ wurde, wie sich jetzt schon angedeutet hat, nicht „in einem Rutsch“ entwickelt und auch das kontinuierliche Zutun Nostys kann bei der Entwicklung sicherlich nicht vernachlässigt werden. Seine Prompts, Fehleranmerkungen und Nachfragen wirken geradezu wie die rhetorische „Hebammenkunst“, mit der Sokrates seine Gesprächspartner nach und nach dazu gebracht hat, korrekte Gedanken und Ideen zu entwickeln. Abgesehen von kleineren Fehlern und Problemen ergaben sich für Nosty aber vor allem Schwierigkeiten mit der wachsenden Komplexität der Software. So realisierte „Gemini“ zum Beispiel nicht, dass Programmmodule von der Main Loop aus nicht in beliebiger Entfernung durch Branch-Befehle aufrufbar sind (weil mit diesen nur 128 Adressen rückwärts und 127 Adressen vorwärts gesprungen werden darf). Also brachte Nosty „Gemini“ einen Trick bei, mit dem dieses Problem umgangen werden kann:

Anstelle von:

bne DalekaEtykieta ; (Fehler)

verwenden:
beq Omin_Jmp
jmp DalekaEtykieta

Omin_Jmp

Um weitere Fehler, die durch den inzwischen auf mehr als 2500 Zeilen angewachsenen Code entstanden, zu vermeiden, und, weil die Übersetzung jedes neuen Codes in Maschinensprache nun immer länger dauerte, wechselte Nosty seine Vorgehensweise: „Gemini“ sollte nun ihm beschreiben, was an welcher Stelle des Programms geändert werden müsse. Mit dieser teilweisen Umkehrung der Aufgaben ging auch einher, dass Nosty mehr und mehr Einblicke in die „Gedankengänge“ der KI bekam: „(…) dieser ‚innere Dialog‘ von ihm (ist) beeindruckend. Nach einer Zeit der Reflexion erhielt ich eine kurze Antwort gefolgt von der Generierung des Codes.“

Sprich zu dir selbst …

Dass Sprachmodelle Programmiersprachen „sprechen“ können, verwundert kaum. Immerhin haben diese – im Gegensatz zu natürlichen Sprachen – eine einfache syntaktische Struktur und keinerlei doppeldeutige semantische Elemente. Dies macht sie zu idealen Kommunikationsmitteln für Computer – und genau deshalb werden sie ja auch von Computern verstanden und ausgeführt. Large Language Models haben nun aber gar keine „Vorlieben“, was die Spracharten, die sie verstehen sollen, angeht. Sie behandeln alle Sprachen – ganz gleich ob natürlich oder formal – auf dieselbe Weise: Aus den Metainformationen (Prompts u.a.) schließen sie, mit welchen Wahrscheinlichkeiten bestimmte Begriffe in einem Text neben anderen Begriffen stehen – und darüber hinaus auch, wie die weiteren begrifflichen Kontexte beschaffen sein sollten.

Das setzt voraus, dass sie ausreichend Trainingsmaterial zum Einüben der jeweiligen Sprache bekommen habe – das gilt ebenso für Shakespeare-Englisch wie für 6502-Assembler. Das, was die Modelle dann an Text generieren, ist nichts „Neues“ in dem Sinne, wie man von einem Schriftsteller erwarten würde, dass er produktiv neue Texte entwickelt. Es ist immer schon eine Assemblage aus den Bestandteilen gelernter Texte. Nun könnte man mit einigem Recht behaupten, dass dies bei einem Menschen ja auch nicht anders wäre, weil auch er ja nur Begriffe nutzen kann, die er schon kennt, und aus ihnen dann Themen und Konzepte entwickelt, die quasi nur eine Neuzusammenstellung dieses schon Vorhanden Sprachwissens sind. Im Gegensatz zum LLM ist bei ihm allerdings unklar, wie viele und welche Aspekte in diesen Prozess von Außen einfließen: biografische Erlebnisse, Gefühle, Werte und vielleicht sogar die Wahl des Mittagessens vom Vortag. Bei LLMs sind alle Einflüsse stets textueller Natur und folgt die Wortwahl stets statistischen Regeln.

Es ist auf amüsante Weise markant, dass „Gemini“ (und Nosty) hier ein Computerspiel-Genre aufrufen, dass zu den ältesten überhaupt zählt. Schon das erste Programmcode-basierte Spiel „Spacewar!“ war ein Weltraum-Shooter, der sukzessive um weitere ästhetische Elemente (etwa einen Sternenhintergrund) ergänzt wurde. „First AI Shooter“ setzt also an, die Computerspiele-Geschichte „hands-on“ nachzuvollziehen. Der Unterschied ist nun jedoch, dass es ein rein datenbasiertes Geschichtsverständnis (basierend auf dem digitalisierten Textarchiv) ist, dass hier nachvollzogen wird.

Früher war alles besser bzw. genauso schlecht

„Wenn ich flüchtig in den Code schaue (ich hatte noch keine Zeit für eine gründliche Analyse)“, schreibt Nosty über den Spiel-Entwicklungsprozess, entdecke er noch vieles Optimierungswürdiges. In diesem Nichthinschauen sehen viele eine neue Gefahr, die mit dem Vibe-Coding aufzieht: dass Computer sich nun selbst programmieren können und niemand mehr den Code versteht (oder nachvollziehen will) – sei es aus Zeitgründen oder, weil man einfach gar nicht selbst programmieren kann. Man muss nicht gleich das Schlimmste befürchten (etwa, dass Computer uns auf diese Weise in ein „Cybernet“-Terminator-Zeitalter führen) – aber mit einigem Recht ließe sich hier vielleicht eine neue Software-Krise befürchten.

Anfang der 1960er Jahre wurde wegen solch einer Krise eine NATO-Konferenz einberufen: Programmierprojekte – insbesondere für militärische Anwendungen – waren über jedes Maß menschlicher Nachvollziehbarkeit hinausgewachsen. Es gab weder Sprach-Standards und noch verbindliche Regeln fürs Programmieren, so dass Programmcode auch von Menschen gelesen werden konnte. Die Befürchtung wuchs damals, dass irgendwann entscheidende Systeme nicht mehr funktionierten, sei es, weil Fehler übersehen wurden oder weil sie inkompatibel zu Neuerungen wurden, und damit ausfielen oder Katastrophen verursachten.

Zwar hat sich „Gemini“ an die damals aufgestellten Regeln für strukturiertes Programmieren gehalten (soweit dies mit 8-Bit-Assembler möglich ist). Mit dem Vibe-Coding stehen uns aber insgesamt sicherlich ähnliche Probleme ins Haus wie in den 60ern, wenn wir die Prozesse nicht nachvollziehbar gestalten – so, wie Nosty es hier vorführt. Der Code von „First AI Shooter“ ist 2582 Zeilen lang. Es existieren nur wenige Kommentare (zumeist als Ãœberschriften für Routinen) und einiges scheint umständlicher programmiert, als es sein müsste. Dafür ging es schnell, wie Nosty betont: „Nach zwei Stunden Arbeit hatte ich einen funktionierenden Prototyp des Spiels. Wir haben die nächsten vier Stunden mit den Änderungen, Abstimmungen und Details verbracht.“ In 6 Stunden also ein spielbares Spiel …

Für moderne Computer spielt Speicher keine so bedeutende Rolle mehr, wie für den Atari-Rechner mit maximal 64 KB adressierbarem RAM. „First AI Shooter“ ist vergleichsweise kurz – aber eben nicht so kurz, wie er von einem erfahrenen Programmierer entwickelt worden wäre. Und zu den Speicher- und Zeit-Kosten (zwei in der praktischen Informatik wichtige Maße) kommen hier noch weitere Kosten hinzu: „Gemini“ hat am Ende 447.784 Token für die Entwicklung verarbeitet. Das sind umgerechnet weniger als 1 US-Dollar (89,6 Cent), die hier an Rechenkosten entstanden sind. Nicht eingerechnet sind die zahlreichen Verarbeitungsschritte, die vorangegangen sind. Und ebenso unberücksichtigt bleiben die Umweltkosten, die LLMs verursachen. Für den „First AI Shooter“ sind diese sicherlich in keinem signifikanten Maß entstanden – aber man kann sich vorstellen, wie schnell solche Werte eskalieren, wenn man an große Software-Projekte mit mehreren Millionen Zeilen Hochsprachen-Sourcecode denkt.

Wer spielt mit wem?

Die Fingerübung „First AI Shooter“ ist in vielerlei Hinsicht lehrreich und interessant. Sie zeigt, wie Large Language Models mit maschinennahen Programmiersprachen von 8-Bit-Systemen umgehen, wie sie Programmcode syntaktisch und semantisch gestalten und wie problematisch ihr ästhetisches Verständnis von Pixelgrafik ist. Das dabei herausgekommene Spiel dürfte wohl kaum jemanden jenseits dieser Aspekte zum Spielen verleiten – zu viele ähnliche Vertical Shooter sind schon über Atari-Monitore gescrollt. Die Simplizität dieser Spiele besitzt jedoch auch noch einen Aspekt, der berücksichtigt werden kann.

Vor einigen Jahren haben Wissenschaftler damit begonnen ihre Machine- und Deep-Learning-Netzwerke dazu zu trainieren auch Computerspiele spielen zu können. Einige interessante Arbeiten zur optimalen Lösung von Spielen wie „Pac-Man“, „Break-Out“ und sogar „Montezuma’s Revenge“ sind hierzu erschienen – aber auch zu moderne(re)n Spielen wie „Zelda“, „Doom“ oder „Minecraft“. Teilweise haben die KIs in diesen Spielen nach einigen Trainingsstunden sogar begonnen Glitches zu finden und auszunutzen, um Level schneller abzuschließen oder höhere Punktzahlen zu erringen. So oder so waren sie am Ende zumeist unschlagbar – verglichen mit menschlichen Spielern.

Nun wäre es natürlich interessant, ein Spiel wie „First AI Shooter“ – quasi als „Generative Adversarial Network“-Spielstategie – durch eine andere KI spielen zu lassen und dessen Ergebnisse dem Large Language Model zu reflektieren, damit der Code automatisch weiterentwickelt und -optimiert werden kann. Die Ergebnisse würden dann immer anspruchsvoller und vom Trainingsnetzwerk immer schwerer zu lösen. Auf diese Weise entstünden vielleicht irgendwann Computerspiele, die nur noch von Computern selbst gespielt werden können – wie es im Prinzip ja schon beim Computerschach der Fall ist. Wir bräuchten dann gar nicht mehr zu spielen und könnten endlich mal wieder raus an die frische Luft gehen.

(Dieser Text ist zuerst erschienen im ABBUC-Magazin #165, 02/2026)