Ohne LLM dauert die Entwicklung eines Spiels 3 Monate, mit LLM 3 Tage
(marianogappa.github.io)- Ein Softwareingenieur mit 15 Jahren Erfahrung teilt seine Erfahrung, ein Kartenspiel aus der Kindheit in Go zu entwickeln
- Ohne LLM (Large Language Model) dauerte die Entwicklung von „Truco“ 3 Monate, da er alle Probleme wie UI-Design und serverlose Bereitstellung manuell lösen musste
- Bei „Escoba“ verkürzte der Einsatz eines LLM die Umsetzungsgeschwindigkeit und Umstellung des Backend-Codes erheblich; der Großteil funktionierte schon nach einem einzigen Prompt
- Im zweiten Teil des Artikels gibt es zusammen mit einem Tic-Tac-Toe-Beispiel eine Schritt-für-Schritt-Anleitung, mit der dank Go-Backend, WASM-Konvertierung und React-Anbindung jeder ein Spiel bauen kann
- Allerdings müssen React-Frontend und WASM-basierte Verwaltung des Spielzustands weiterhin direkt selbst implementiert und debuggt werden
Einführung
- Ein Softwareingenieur mit 15 Jahren Erfahrung stellt fest, dass er noch nie selbst ein Spiel gebaut und veröffentlicht hat
- Er beschließt, eines der Kartenspiele aus seiner Kindheit in Argentinien, das er mit Freunden gespielt hat, in Go zu entwickeln
Truco: 3 Monate ohne LLM
- Ab dem 18. Juni 2024 beginnt er mit der Entwicklung des Kartenspiels Truco mit einem Go-Backend. Das Frontend schreibt er mit nur minimalen React-Kenntnissen
- Die UI-Implementierung war die größte Herausforderung. Um keinen Server betreiben zu müssen, transpiliert er den Code mit TinyGo zu WASM (WebAssembly) und stellt die statischen Dateien auf GitHub Pages bereit
- Da es damals kein LLM gab, musste er alle Details selbst herausfinden und durch viel Trial-and-Error lösen; insgesamt dauerte die Fertigstellung etwa 3 Monate
- Das Ziel war allein, das Spiel fertigzustellen, ohne Werbung oder Monetarisierung. Auch ein Jahr nach dem Release wird es noch regelmäßig gespielt
- Truco spielen: https://marianogappa.github.io/truco-argentino
- Backend (Golang): https://github.com/marianogappa/truco
- Frontend (React): https://github.com/marianogappa/truco-argentino
Escoba: 3 Tage mit LLM
- Ein Jahr später besucht er Argentinien, um seine Familie zu sehen, und bringt seinem Neffen Escoba bei, das zweitbeliebteste Kartenspiel
- Diesmal nutzt er ein LLM (Claude), kopiert das Backend von Truco, erklärt die Regeln von Escoba im Prompt und bittet um Refactoring des Codes
- Schon mit dem ersten Prompt war die Implementierung fast perfekt; nur kleinere Bugs und zusätzliche Funktionen mussten noch manuell ergänzt werden
- Das Frontend musste dennoch über mehrere Tage hinweg direkt selbst implementiert und debuggt werden. Grenzen des LLM, React-Skills und die ungewöhnliche Umgebung mit in WASM verwaltetem Spielzustand waren dabei allesamt Herausforderungen
- Escoba spielen: https://marianogappa.github.io/escoba-de-15
- Backend (Golang): https://github.com/marianogappa/escoba
- Frontend (React): https://github.com/marianogappa/escoba-de-15
Schritt für Schritt: So baut man sein eigenes Spiel
- Damit andere selbst Spielentwicklung ausprobieren können, stellt er eine minimale Praxisanleitung mit Beispielcode vor
- Es gibt ein Beispiel-Repository für Tic-Tac-Toe, das man forken und als Ausgangspunkt nutzen kann
Backend-Entwicklung
- Ein rundenbasiertes Backend lässt sich funktional klar entwerfen
- Eine serverlose Struktur beizubehalten und eine Architektur zu vermeiden, in der Menschen gegeneinander spielen, ist eine realistische Wahl, wenn kein produktiver Server vorhanden ist
Frontend-Entwicklung
- Das Frontend muss folgende Aufgaben übernehmen
- Anforderung zur Erstellung eines neuen
GameStatean das Backend senden - Zustand in der UI anzeigen
- Eine Oberfläche zur Auswahl gültiger Aktionen bereitstellen
- Beim Anwenden einer Aktion einen Befehl an das Backend senden
- Wenn der Bot am Zug ist, eine Anfrage an das Backend schicken
- Anforderung zur Erstellung eines neuen
Umstellung des Backends auf WASM
- Um Go-Code zu WASM zu bauen, wird
GOARCH=wasm GOOS=js go buildverwendet - Da die Binärgröße problematisch sein kann, wird TinyGo genutzt, um die Größe zu reduzieren
- Um Funktionen zu exportieren, die mit dem Frontend verbunden werden sollen, wird in Go ein separater Entry-Point (z. B.
main_wasm.go) geschrieben und beim Build verzweigt behandelt - In der Main-Funktion muss mit
select {}blockiert werden, damit das Programm nicht sofort beendet wird
Datenanbindung zwischen Backend und Frontend
- Freie Go-Structs wie
GameStatekönnen in WASM nicht direkt serialisiert/deserialisiert werden - Daher müssen alle Daten im JSON-Format ausgetauscht werden
- Unter Bezug auf die TinyGo-Dokumentation werden Ein- und Ausgabe vollständig per JSON-Serialisierung übertragen
Frontend-Backend-Schnittstelle
- Im Frontend werden Backend-Funktionen direkt aufgerufen
GameStatewird ausschließlich innerhalb von WASM verwaltet; das Frontend kann ihn nicht mutieren, das Backend ist stets die Single Source of Truth- Nach einer WASM-Neukompilierung muss die Datei ersetzt werden; ein Beispiel zur Automatisierung per Makefile wird gezeigt
WASM-Laufzeitumgebung
- Für die Ausführung muss
wasm_exec.jsim Head eingebunden werden; über dieses Skript wird anschließend die Instanz erzeugt und gestartet
Fazit
- Das Bauen von Spielen war eine spannende Erfahrung, und die Kombination aus Go, WASM und React ist ein Ansatz, den jeder ausprobieren kann
- Mit Hilfe von LLMs stieg die Produktivität deutlich, aber Frontend-Kompetenz und Debugging-Erfahrung bleiben weiterhin wichtig
- Da jeder mit dieser Struktur selbst die Entwicklung eines Spiels ausprobieren kann, lohnt sich ein Versuch
4 Kommentare
Wenn ein in React generierter Code
document.getElementByIdverwendet, welches LLM wurde dann wohl eingesetzt....Wirkt fast wie ein reißerischer Clickbait-Titel..
„Wenn man es von Grund auf neu baut, dauert es 3 Monate; wenn man etwas Ähnliches noch einmal baut, 3 Tage“
Der ursprüngliche Autor scheint wohl jemand zu sein, der normalerweise nicht weiß, was er eigentlich macht.
Hacker-News-Kommentare
Was mir an diesem Beitrag gefällt, ist, dass er auf etwas hinweist, das viele Entwickler übersehen. Beim Entwickeln von Spielen war das eigentliche Programmieren nur selten der Engpass. Auch Solo-Entwickler können Mechaniken schnell bauen, selbst ohne AI. Die wirklich schwierigen Teile sind die darüberliegenden, unsichtbaren Ebenen: etwa das Balancing der Gameplay-Loop, das Abstimmen des Schwierigkeitsgrads, die Erstellung stimmiger Assets oder das Polishing, das Nutzer länger als fünf Minuten bei der Stange hält. Darin liegt auch der Grund, warum Steam seit dem Aufkommen von LLMs nicht mit herausragenden Spielen überflutet wurde. Die Technologie hat eine Hürde gesenkt, aber die größeren Hürden sind geblieben. Genauso war es schon mit dem Aufstieg von Unity in den 2010ern. Die Engine hat die Spieleentwicklung demokratisiert, aber statt einer Explosion guter Spiele gab es vor allem mehr Versuche. LLMs bewirken bei Code und Bildmodelle bei Art denselben Effekt, aber keines dieser Tools kann dir sagen, welches Spiel wirklich Spaß macht. Die interessante Frage für mich ist, was passiert, wenn AI nicht nur implementiert, sondern auch Playtesting übernimmt. Wenn sie also Tausende Loops durchläuft und sagen kann, welche Mechaniken simulierte Spieler wirklich fesseln, dann würde sich ihre Rolle von einem Produktivitäts-Hack zu einem Design-Partner erweitern. So weit sind wir noch nicht, aber dieser Beitrag fühlt sich wie ein früher Datenpunkt in genau diese Richtung an
Zu der Meinung, dass spannend wäre, welche Zukunft auf uns zukommt, wenn AI nicht nur implementiert, sondern auch Playtesting übernimmt und in Tausenden Loops herausfindet, was Spieler stärker fesselt: Da stellt sich für mich die Frage, wie AI überhaupt Spieler simulieren soll und warum sie zuverlässig beurteilen könnte, worin echte Menschen aufgehen
Beim Beispiel des Unity-Aufstiegs in den 2010ern möchte ich widersprechen, dass es gar nicht so viele wirklich gute Spiele gegeben habe. Verglichen mit der XBLA-Zeit wäre das heutige Volumen an Spielen ohne Tools wie Unity, Godot, Gamemaker, Renpy und RPG Maker schlicht unmöglich gewesen. Es gab also nicht nur qualitativ, sondern ganz eindeutig auch quantitativ einen sprunghaften Anstieg
Für mich ist der Lackmustest für generative AI, ob sie ein komplettes Spritesheet für ein 2D-Pixel-Art-Actionspiel erzeugen kann. Mein Ziel war zum Beispiel schon, allein die Bewegung eines Panzers oder der Hauptfigur perfekt hinzubekommen, aber bis heute habe ich dafür noch keinen Erfolgsfall gesehen
Ich denke, der Kern dieses Insights ist der Hinweis: „AI kann dir nicht sagen, ob dein Spiel tatsächlich Spaß macht.“ AI kann Spiele nicht auf demselben Niveau erfahren wie Menschen, und auch keine anderen Erfahrungen auf menschliche Weise machen. Sie kann anhand menschlicher Bewertungsdaten ähnlicher Spiele höchstens gewisse Vorhersagen treffen. Mit anderen Worten: AI kann dein Spiel nicht genießen. Genau dieses Wesen der Sache wird künftig die Rolle von Menschen im AI-Zeitalter definieren. AI kann Dokumente oder Code auf Basis vergangener Daten bis zu einem gewissen Grad menschenähnlich erzeugen, aber es gibt bedeutsame Integration und Erfahrung, die nur echte Menschen leisten können. Es gibt einen Punkt, an dem menschlicher Wert unersetzbar bleibt; nur müssen wir womöglich anders darauf schauen, worin dieser Wert besteht
Dieses Muster gilt nicht nur für Spieleentwicklung, sondern auch für andere Bereiche. Wie viele erwarten, steckt in agentenbasiertem Coding enormes Potenzial, aber bislang werden nur bestimmte Tasks überwältigend schnell gelöst, etwa schnelle Web-App-Demos oder das Verbinden kleiner Libraries; auf echte große Software ist das noch kaum übertragbar. Sowohl die Art, wie die Modelle trainiert wurden, als auch unser Know-how in der Nutzung sind noch unzureichend. Das ist nicht überraschend. Selbst git wurde in den ersten fünf Jahren eigentlich nur von Elite-Unternehmen sauber eingeführt, und bis zur breiten Nutzung vergingen noch einmal fünf Jahre. Heute sind wir damit sehr vertraut, aber ich halte LLMs sogar für schwieriger sinnvoll einzusetzen als git. Ich frage mich, ob wir nicht schneller vorangekommen wären, wenn nicht bei jedem Produkt, OSS-Projekt oder Blogpost gleich übertrieben würde mit „Jetzt ist alles vorbei, alles wurde revolutioniert“. Wir befinden uns immer noch in Trial-and-Error und Experimenten, und das braucht Zeit. Man sollte nicht zu schnell urteilen. Wenn wirklich schon alles gelöst wäre, müssten wir eigentlich längst von deutlich besserer Software überrollt worden sein, aber aktuell halten wir gerade so die Balance. Dafür ist das nach nur ein bis zwei Jahren neuer Technologie trotzdem ziemlich beeindruckend
Dass das LLM einen Vorsprung von drei Monaten hatte, lag daran, dass es auf Code, auf einem früheren Spiel als Vorlage und vor allem auf all den Erfahrungen und Fehlern aufbaute, die beim händischen Coden gesammelt worden waren
Anfangs dachte ich, das sei nur ein reißerischer Titel, aber die Stelle „Ich habe das Truco-Backend kopiert, Claude die Escoba-Regeln ausführlich erklärt und dann den Code refaktorieren lassen“ fand ich tatsächlich überraschend. Ich frage mich, wie lange ein Mensch für dieses Refactoring gebraucht hätte. Vielleicht länger als drei Tage, vielleicht aber auch nicht
Ein weiterer wichtiger Punkt ist, dass dieses Spiel das erste Spiel des Teilnehmers war. Beim ersten Versuch hat man es mit unzähligen Unbekannten zu tun, aber wenn man mit den Erkenntnissen und dem Know-how aus einem ersten Durchlauf noch einmal von vorn beginnt, kann man es auch ohne LLM wahrscheinlich in deutlich weniger als drei Monaten schaffen
Ich habe selbst erlebt, dass sich bei derselben Art von Projekt, wenn man es zum zweiten oder dritten Mal wiederholt, etwas, das anfangs Monate gedauert hat, beim nächsten Mal auf etwa ein Drittel reduziert
<i>hust</i> Ich habe so etwas auch schon in unter 24 Stunden entwickelt, Beispiele gibt es auf nordicgamejam.com. Ich will damit sagen, dass damals, als es weder LLMs noch GenAI noch Unity gab, Microsoft XNA und C# das Beste waren, was man hatte. Die Art war größtenteils mit Paint hingekritzelte Handarbeit. Trotzdem entstanden jedes Jahr genug unterhaltsame Spiele, und manche wurden auch einem breiteren Publikum bekannt, etwa Baba is You oder Braid. Der Engpass war nicht das Coden; ich bin vielmehr überzeugt, dass die Kommunikation zwischen den Teammitgliedern der echte bottleneck ist
Wenn ich diesen Kommentarstrang so sehe, wirken viele Beiträge, als kämen sie von Leuten ohne Erfahrung in der Spieleentwicklung. In Wahrheit eignen sich Projekte, bei denen LLMs eingesetzt werden, oft genau deshalb, weil sie im Trainingsmaterial bereits reichlich vorhanden sind. Solche Projekte kommen etwa auch in Programmier-Einführungskursen vor, und in südeuropäischen Ländern gibt es tatsächlich sehr viele Kartenspiele, die dem aus diesem Blog ähneln. Ich habe im ersten Studienjahr selbst ohne jede Erfahrung Moon Patrol von Grund auf in Python nachgebaut; das hat zwei bis drei Monate gedauert, mit drei durchcodeten Nächten pro Woche. Ein Kartenspiel zu bauen ist sogar noch einfacher. LLMs sind sicher in mancher Hinsicht nützlich, aber für Benchmarks zur Coding-Produktivität oder Nützlichkeit von LLMs taugen solche simplen Beispiele nicht
Ich habe mit LLMs über mehrere Tage immer wieder nebenbei an so etwas gearbeitet: stacky. Effektiv waren es vielleicht zwei Tage echte Arbeit. Erst habe ich es komplett from scratch gebaut, später eher brownfield-artig weitergeschrieben, ohne wirklich die Absicht, es ernsthaft fertigzustellen. Aber je mehr Details und Features ich hinzugefügt habe, desto mehr Ideen kamen nach (Super Rotation, DAS usw.). Es ist immer noch unvollständig, vielleicht erst bei 10 bis 20 Prozent des gesamten Spiels. Eine WebGL-Version läuft auch. Aber wenn ich versuchen würde, das ultimative Tetris zu bauen, würde ich wahrscheinlich verklagt werden, und die Lizenzgebühren könnte ich mir sowieso nicht leisten, also habe ich aufgehört. Unterm Strich habe ich Selbstvertrauen und Erfahrung gewonnen. Neulich habe ich nach einem HN-Link über parametrische Funktionen in ein bis zwei Stunden auch noch den Playground graphy gebaut. Auch da verliert man sich ständig in Details. Wenn man klar weiß, was man will, macht diese Art von Arbeit mit einem LLM ziemlich viel Spaß
Ich entwickle schon seit einer ganzen Weile hobbymäßig Spiele auf einem gewissen Niveau und habe auch mehrere fertiggestellt. Trotzdem habe ich beim Lesen dieses ganzen Kommentarstrangs den Eindruck, dass viele nicht besonders viel echte Erfahrung in der Spieleentwicklung haben. Der Aussage, dass das Programmieren in der Spieleentwicklung einfach sei, kann ich nicht zustimmen. Neue Ideen oder Genre-Variationen bei Mechaniken auszudenken, ist eher der leichtere Teil; die eigentliche Implementierung im Code ist deutlich schwieriger. Es ist zum Beispiel leicht, sich ein Multiplayer-Vampire-Survivor mit BattleMech-Customization vorzustellen, aber das allein mit einem LLM umzusetzen ist nahezu unmöglich. In diesem Fall geht es um ein vollständig bekanntes Kartenspiel-Regelwerk, also ist das ungefähr so simpel wie Snake. Das ist keine Kritik am Autor des Beitrags; ich möchte nur darauf hinweisen, dass viele Leute Entwicklung beurteilen, ohne selbst wirkliche Erfahrung in der Spieleentwicklung zu haben
Ich stimme der Behauptung nicht zu, dass das Coden der schwierige Teil der Spieleentwicklung sei. Natürlich kann es schwierig sein, aber die eigentliche Herausforderung ist, auf neue und unterhaltsame Ideen zu kommen. Wenn man eine gute Idee hat, kann man sie in kleine Teile zerlegen, iterieren und am Ende schon umsetzen. Die wahre Hürde ist der Moment vor dem leeren Blatt, wenn man entscheiden muss, was man überhaupt machen will. Geh spazieren, probier alles Mögliche aus — das ist ein Problem, das sich in der Kunst seit Jahrtausenden wiederholt. Dagegen ist Coden letztlich Ingenieursarbeit. Ich lerne gerade selbst Spieleentwicklung und parallel auch Mathematik; Vektormathematik oder Quaternionen zu lernen war für mich viel einfacher, als zu entscheiden, „welches Spiel will ich eigentlich machen?“
Grundsätzlich stimme ich zu, aber für mich war es immer deutlich schwieriger, auf neue Ideen zu kommen oder kreativ zu experimentieren. So gut wie jede Spielmechanik kann ich irgendwie coden, aber der Schreib-/Kreativteil ist wirklich hart. Wer das leicht findet, ist wirklich gesegnet. Für jeden ist das nicht etwas Natürliches
Wenn man ein vollständig clientseitiges Spiel bauen will, frage ich mich, warum man dann überhaupt von einem „Backend“ spricht und warum man nur für das Backend eine andere Technologie einsetzt statt für die ganze App
Ich habe das Gefühl, dass es in der Softwarebranche kaum noch Bereiche gibt, in denen sich Ideen schnell und leicht umsetzen lassen. Die Konkurrenz ist inzwischen so hart, dass man selbst in kleinsten Märkten direkt mit globalem VC und globaler AI konkurriert. Früher konnte man wenigstens noch Nischen finden, die große Unternehmen ignorierten. Heute konkurriert man, ob mit großem VC oder in einer Nische, in jedem Fall weltweit, sodass am Ende nur noch kleine Märkte mit extrem komplexer Technologie bleiben oder Bereiche mit geringer Profitabilität, hoher Ausfallwahrscheinlichkeit und kurzem Lebenszyklus — und die meisten Spiele fallen genau in diese Kategorie. Im ersten Fall braucht man Marketing auf dem Niveau persönlicher Verkaufsgespräche. Nach meiner Erfahrung in der Games-Branche besteht der große Hit oft nur daraus, eine Million Views zu bekommen und sechs Monate später komplett tot zu sein. Weil wiederkehrende Einnahmen fast nicht existieren, ist schon der Einstieg extrem demotivierend. Ein Spiel wie Minecraft zu machen, ist fast wie ein Lottogewinn. Allerdings ist die Spielebranche im Vergleich zu anderen Softwarebereichen immerhin noch relativ meritokratisch. Qualität und Spielspaß hängen tatsächlich mit der Akzeptanz zusammen. Andere Branchen sind ein Labyrinth aus Regulierung, durch Netzwerkeffekte erzeugten Monopolen oder staatlicher Kontrolle. Manchmal wünschte ich, der Staat würde schon früh sagen: „Dieser Bereich ist bereits von dieser Firma besetzt, also gründet dort kein Startup und macht lieber etwas anderes“, damit man nicht ein Jahr verschwendet
Ich frage mich, wann endlich verstanden wird, dass Greenfield-Projekte, also komplett neue Projekte, der denkbar schlechteste Fall sind, um Agent-Coding-Fähigkeiten zu benchmarken
Ich mag LLMs, weil sie mir erlauben, Code näher an der Art zu behandeln, wie ich Programme im Kopf abstrahiere. Wenn ich Code lese, verstehe ich ihn fast wie einen AST: Funktionen und Aufrufe werden zu abstrakten Knoten aus Eingaben und Ergebnissen. Mit LLMs wird es extrem einfach, das rückwärts wieder in Code umzusetzen. Ich muss nicht mehr mühsam nach Codebeispielen suchen, die zu einer Idee passen, oder mich erinnern, wie etwas ging; ich kann dem LLM einfach sagen, es soll Boilerplate wie eine WiFi-Initialisierung schreiben. Am Ende kann ich Programme fast wie aus Lego-Steinen zusammensetzen. Auch vor LLMs war das möglich, aber mit viel mehr Aufwand. Dadurch entwickle ich heute mühelos über verschiedene Sprachen hinweg. Ich lerne zwar weniger über interne Sprachstrukturen oder Syntax, aber genau das ist der Punkt. Sprache und Syntax sind Nebendetails, die mit dem logischen Fluss eines Programms wenig zu tun haben. So wie sich alles von Maschinensprache über Assembler und C hin zu immer höherwertigen Sprachen entwickelt hat, nähern wir uns jetzt immer mehr nicht dem Coden, sondern dem eigentlichen „Programmieren“. Wie die Endform aussieht, weiß niemand, aber ganz sicher wird immer mehr Zeit in „Programmieren“ fließen und immer weniger in das eigentliche „Schreiben“