Ohne LLM dauert die Entwicklung eines Spiels 3 Monate, mit LLM 3 Tage

• 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: https://github.com/marianogappa/tictactoe-backend
  • Frontend: https://github.com/marianogappa/tictactoe-frontend
  • Demo: https://marianogappa.github.io/tictactoe-frontend/

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 GameState an 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

Umstellung des Backends auf WASM

• Um Go-Code zu WASM zu bauen, wird GOARCH=wasm GOOS=js go build verwendet
• 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 GameState kö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
• GameState wird 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.js im 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