Ich habe ein Tower-Defense-Spiel mit KI programmiert und den gesamten Prozess dokumentiert
(github.com/maciej-trebacz)- Obwohl ich seit 20 Jahren Softwareentwickler bin, habe ich für meine erste Spieleentwicklung einen KI-Coding-Agenten genutzt und damit das auf Phaser.js basierende Tower-Defense-Spiel "Tower of Time" fertiggestellt
- Ziel war es, die tatsächliche Einsetzbarkeit von KI in der Spieleentwicklung zu erproben; der Code sowie alle KI-Prompts und Arbeitsschritte wurden auf GitHub dokumentiert
- Mehr als 95 % des Codes wurden von KI geschrieben; dabei kamen verschiedene KI-Tools wie Augment Code, Cursor und Claude Sonnet 4 in Kombination zum Einsatz
- Das Spiel bietet mit einer Zeit-zurückspulen-Funktion (Rewind) strategische Tiefe sowie eigenständigen Spielspaß durch verschiedene Türme, ein Energiemanagement-System und pro Welle auftretende Gegner
- Durch Live-Streaming, die Nutzung von Art- und Sound-Assets sowie die im Entwicklungsprozess gewonnenen Erkenntnisse und Praxistipps ist es sowohl für Spiele- als auch KI-Einsteiger ein nützliches Lernmaterial
Überblick über Tower of Time
- Dieses Projekt wurde mit dem Ziel durchgeführt, zu testen, ob mit KI-Coding-Tools echte Spieleentwicklung möglich ist
- Nach dem ersten Einarbeiten in Phaser.js, eine JavaScript-Game-Engine, wurde am Beginner's Jam Summer 2025 teilgenommen und Tower of Time in 25 bis 30 Stunden fertiggestellt
- Der gesamte Entwicklungsprozess, alle Prompts, der Code, die Dokumentation und der Play-Link wurden auf GitHub festgehalten
Spielvorstellung
- Tower of Time ist ein Tower-Defense-Spiel mit Zeitreise-Thema, in dem Spieler anrollende Gegnerwellen abwehren und in kritischen Situationen die Zeit zurückspulen können, um ihre Strategie neu zu planen
- Es kombiniert mehrere Arten von Türmen (Standard, Sniper, Slowdown, Splash usw.) mit einem Energiesystem (wird für Turmbau und das Zurückspulen der Zeit verwendet)
- Hauptmerkmale
- Zeit zurückspulen: In ungünstigen Momenten kann man zu einem früheren Zustand zurückkehren und die Verteidigungsstrategie neu ausrichten
- Vielfältige Türme: Durch die Platzierung von Türmen mit unterschiedlichen Eigenschaften lassen sich verschiedene Verteidigungsstrategien entwickeln
- Energiemanagement: Ein Ressourcenfaktor, bei dem gut überlegt werden muss, wofür die Energie eingesetzt wird
- Steuerung
- Tastatur/Gamepad unterstützt (Bewegung: Pfeiltasten/Stick, Aktion: Leertaste/Gamepad-Taste, Zurückspulen: Backspace/Trigger)
KI-Coding-Experiment und Entwicklungsprozess
- Rund 95 % des gesamten Codes wurden mit KI (Claude Sonnet 4, OpenAI, Augment Code, Cursor usw.) erstellt
- Alle wichtigen Prompts, Iterationen und das Endergebnis wurden im Repository in PROMPTS.md dokumentiert
- Vorteile der automatischen KI-Codegenerierung: schnelles Prototyping, Automatisierung wiederkehrender Codearbeiten, einfache Dokumentation
- Grenzen und Vorsichtsmaßnahmen: KI neigt dazu, zu viel Code zu erzeugen; bei bestimmten Implementierungsproblemen sind eine Neugestaltung der Prompts oder Rollbacks nötig; die Nutzung von Debugging-Logs wird empfohlen
Erkenntnisse aus der Entwicklung
- Auch allein mit KI-Coding ist es durchaus möglich, ein unterhaltsames Spiel fertigzustellen
- Prompt-Qualität, klarer Kontext und Debugging-Strategien sind äußerst wichtig
- Es muss laufend geprüft werden, dass die Codebasis nicht unnötig anwächst
Tech-Stack
- Engine: Phaser 3 (v3.90.0) + Phaser Editor v4
- Sprache: TypeScript
- Build-Tool: Vite
- Art-Assets: itch.io, teilweise selbst nachbearbeitet
- Sound: freesound.org
Im Browser spielen: Tower of Time
3 Kommentare
Ich denke, das wird eine gute Referenz sein.
Ich bin auch fleißig dabei, mithilfe von KI ein Webspiel zu entwickeln.
Hacker-News-Kommentare
Es macht großen Spaß, die für die Entwicklung verwendeten Prompts einzeln durchzulesen
Beiträge über „erfolgreiche Beispiele für Vibe Coding“ vermitteln oft die Illusion, dass ein Spiel quasi wie von selbst entsteht, wenn man nur viele Agenten, komplexe Code-Orchestrierung und von LLMs erzeugte Regeln hat – mit einer einzigen Prompt-Zeile wie „Erstelle ein Tower-Defense-Spiel mit Zeitrückspulung, ohne Mängel und ohne Bugs“.
Die im tatsächlichen Projekt verwendeten Prompts entsprechen jedoch genau der Arbeitsweise, die bei AI Coding am besten funktioniert.
Es ist effektiv, eine klare und sorgfältig ausgearbeitete Idee in Hunderte kleiner Probleme zu zerlegen und für die wirklich wichtigen Teile konkrete architektonische Leitlinien vorzugeben.
In meiner Rolle, in der ich zugleich Tech Lead und Product Owner bin, ist das übrigens auch beim Arbeiten mit Menschen der Standardweg.
70 % meiner Arbeit bestehen darin, eine abstrakte Vorgabe von Führungskräften wie „ein Time-Travel-Tower-Game, ohne Bugs“ in eine Reihe von Prompts zu übersetzen, die eine starke Architekturvision im Kontext tragen, sodass das Team mit hoher Abstraktion arbeiten kann, ohne sich gegenseitig zu überschneiden.
Ich habe versucht, ein einfaches HTML-Spiel zum Brettspiel Just One zu bauen, aber selbst nachdem ich vier verschiedene LLMs immer wieder mit Prompts gefüttert habe, konnte keines den Bug beheben, bei dem sich das Eingabefeld bewegt.
Alle reden davon, ganze Spiele auf einmal zu implementieren, und ich schaffe es nicht einmal, die Bewegung eines Textfelds zu fixen – das finde ich erstaunlich.
Nach dem Prompt „keine Sicherheitslücken, keine Bugs“ braucht es unbedingt auch „keine Halluzinationen“.
Das ist eine Grundvoraussetzung für AI-Einsteiger.
Mein Ansatz, der beim AI Coding gut funktioniert, ist, zuerst Grundfunktionen oder das Gameplay-Grundgerüst per AI als „One Shot“ zu erzeugen und dann iterativ mehrfach darauf aufzubauen.
Wenn das One-Shot-Ergebnis nicht sofort überzeugend ist, bessere ich es direkt mit einem anderen Prompt nach und versuche es erneut, bis eine brauchbare Grundlage steht.
Dem stimme ich voll zu.
Tatsächlich basiert auch mein letzter Beitrag auf genau diesem Konzept.
Wenn man AI vor dem Codieren zuerst die Spezifikation schreiben lässt, sinkt die Hürde für Menschen, überhaupt eine Spezifikation zu verfassen, und die Wahrscheinlichkeit steigt deutlich, dass sie tatsächlich entsteht.
Nach mehr als 20 Jahren in der Softwarebranche habe ich den Eindruck, dass viele unserer Kolleginnen und Kollegen AI Coding eher skeptisch sehen.
Vor Kurzem habe ich eine größere App mit etwa 34.000 Zeilen größtenteils mit AI entwickelt, und dabei stieg die Effizienz exponentiell mit der Qualität meiner Anweisungen, der Struktur der Interaktion und der Sorgfalt für die Ergebnisse – inklusive Kurskorrekturen.
Es fühlte sich an wie: „Am Ende ist es wie jedes andere Tool!“
Gleichzeitig hat dieses Tool im Vergleich zu allen „10x-Tools“, die ich bisher erlebt habe, tatsächlich eine zehnfach größere Hebelwirkung.
Was die meisten Skeptiker übersehen, ist, dass man diese Tools nicht als etwas völlig Äußerliches behandeln darf.
Wer Ziele unklar beschreibt und dann einfach delegiert, wird Schiffbruch erleiden.
Vielleicht wird AI eines Tages unsere Gedanken direkt lesen können, aber heute ist das noch nicht so.
Im Moment liegt die eigentliche Stärke darin, Gedanken klar zu strukturieren, Neues zu lernen und lästige Teile schnell zu erledigen.
Für maximale Hebelwirkung muss man dieses Tool gut in den eigenen Denkprozess integrieren.
Ich programmiere zwar schon lange, hatte mit Spielen aber seit Hunt the Wumpus in der Highschool nichts mehr zu tun und habe vor Kurzem mit Hilfe von AI angefangen, neue Spiele zu bauen.
AI übernimmt dabei im Wesentlichen drei Rollen.
(1) Lernwerkzeug – das ist die wichtigste Rolle, weil AI meine Absicht auch dann gut versteht, wenn ich die Fachbegriffe nicht kenne, mir einen Einstiegspunkt gibt und mich sogar auf Dinge hinweist, die ich noch gar nicht wusste.
(2) Erledigung wiederholender oder langweiliger Aufgaben – Code-Kommentare, Konfigurationsdateien usw. könnte ich zwar selbst schreiben, aber AI übernimmt solche Dinge zuverlässig, die mich sonst nur ausbremsen würden.
(3) Suche – ähnlich wie bei (1) erkennt AI, was ich eigentlich will, und übernimmt dann Filtern oder Empfehlungen.
Man kann AI auch das „Denken“ überlassen, aber das muss man nicht.
Sie ist nicht klüger als ein Mensch, sondern eher wie eine FPU, die nur schneller ist und mehr weiß.
Nach HN-Maßstäben gehöre ich eher zu den Skeptikern, in der Praxis treibe ich die Einführung von AI in meiner Firma aber weiter voran und schreibe diesen Kommentar gerade, während ich Claude parallel etwas erledigen lasse.
Der Grund für meine Skepsis ist die Lücke zwischen der Art, wie aktuelle AI-Lösungen verkauft werden, und dem, was sie tatsächlich leisten.
Alle AI-Lösungen, besonders Agenten, liefern ohne Anleitung durch erfahrene Personen nur nutzlose Ergebnisse.
Es gibt in Wahrheit kaum etwas „Autonomes“ daran.
Sogar die Person, die den Begriff „Vibe Coding“ geprägt hat, sagt, dass die Branche die Reihenfolge falsch herum angeht.
Diese Tools sind fantastisch, aber den entscheidenden Punkt wegzulassen, dass man sie streng steuern muss, ist praktisch eine Lüge.
In den letzten Monaten bin ich gedanklich zu einem sehr ähnlichen Schluss gekommen.
Früher habe ich kritische Kommentare zu AI hinterlassen, aber die neuesten Tools sind eindeutig viel besser geworden.
Dinge, die früher Wochen dauerten, lassen sich jetzt in wenigen Stunden erledigen.
Man muss die Prompts allerdings gut durchdenken, fein aufgliedern und sauber mit der IDE verzahnen.
Am revolutionärsten ist das beim Arbeiten mit völlig neuen Bibliotheken oder Frameworks.
Früher habe ich die Nutzung recherchiert und Beispielcode zurechtgebogen, während AI heute viel intuitivere und vielfältigere Wege zeigt, was mich oft überrascht.
Wer noch skeptisch ist, sollte es inzwischen ruhig noch einmal ausprobieren.
Ein Beispiel für 10x-Hebelwirkung ist Sprache.
Früher hieß es, Lisp und Ähnliches würden einem erlauben, schneller mehr zu schaffen; heute kann man tatsächlich weniger Code selbst schreiben und trotzdem Ergebnisse in schnellen, performanten Sprachen erzeugen lassen.
Die Falle dabei ist allerdings, dass man die Teile des erzeugten Codes, die sich nicht leicht verifizieren lassen, gründlich prüfen muss.
So wie hoch ausdrucksstarke Sprachen schon früher dazu geführt haben, dass Menschen ohne Vorabplanung chaotische Codebasen produziert haben, dürfte sich das mit AI-Tools wiederholen.
Meine eigentliche Zeitersparnis liegt jedoch weniger im Schreiben völlig neuen Codes als vielmehr beim Integrieren oder Verbessern von altem und neuem Code.
Beim Debugging ist das ein enormer Sprung.
Statt wie früher nur
print-Ausgaben einzubauen, kann ich einfach Code kopieren und einfügen und AI fragen: „Warum kommt nicht dieses, sondern jenes Ergebnis heraus?“, und bekomme schnell Ursachen und Alternativen.Gerade bei Arbeiten wie SQL, IaC oder Build-Skripten, wo sich nicht so leicht ein Debugger anhängen lässt, ist das ein gewaltiger Vorteil.
Noch etwas: Die Lernkurve und die Obergrenze der Schwierigkeit sind viel höher, als man denkt.
Die Resultate unterscheiden sich stark, je nachdem ob man Claude Opus in einem komplexen Automatisierungs-Framework nutzt oder GPT-4o im Browser nur per Copy-and-Paste.
Ich fand es großartig, dass der Entwicklungsprozess transparent offengelegt und sogar die Prompts geteilt wurden, deshalb habe ich auf GitHub einen Star vergeben.
Sowohl der Code als auch das Ergebnis wirken auf mich wunderschön.
Es ist klar, dass hier nicht nur AI im Spiel war, sondern auch viel eigene Beteiligung.
Ich hatte lange nicht mehr programmiert und habe auf Empfehlung von Freunden versucht, mit AI einfache kleine Programme zu bauen.
Herausgekommen sind bisher so etwas wie Bubble Wrap zum Platzenbringen und ein Lautlosmacher, also ein Button, der den Ton stummschaltet.
Bubble Popper
Silencer
Mich würde interessieren, ob Pull Requests willkommen sind.
Gerade Indie-Games wirken auf mich wie ein hervorragender Anwendungsfall für Coding-AI.
Das geringe Risiko und der spielerische Charakter passen perfekt.
Der erste Commit enthält bereits eine große Menge Code, aber
PROMPTS.mdfehlt dort noch.Zum Beispiel existiert
EnergySystem.tsschon im ersten Commit, während es inPROMPTS.mdspäter so aussieht, als hätte AI es von Anfang an erstellt.Ich würde gern wissen, ob du diesen Teil in der Repository-Historie etwas genauer erklären kannst.
Link zum ersten Commit
Die Prompts habe ich ebenfalls nicht direkt mitgeschrieben, sondern erst nach Fertigstellung des Spiels aus dem Verlauf des verwendeten Chat-Tools zusammengesucht und in die Datei
PROMPTS.mdkopiert.Wenn du den Entstehungsprozess des Projekts sehen möchtest, ist es am besten, die Prompt-Datei von Anfang bis Ende zu lesen.
Zum Beispiel wurde die Datei
EnergySystem.tsvon AI komplett neu erzeugt, nachdem Dinge wie Gegnerpfadfindung, Spawning und Turm-Schießen bereits implementiert waren und ich den Prompt gegeben hatte: „Ich möchte ein Energie-Subsystem implementieren“.Von einem Tool namens Augment Code habe ich zum ersten Mal gehört.
Mich würde interessieren, was es macht, warum du es gewählt hast, wie es sich von Konkurrenztools unterscheidet, wie die praktische Nutzung war und ob du es empfehlen würdest.
Mich würde auch interessieren, ob für beide bezahlt wurde.
Dass du die Prompts dokumentiert hast, ist beeindruckend und motivierend.
Meiner Erfahrung nach kann man mit „Vibe Coding“ entweder sehr schnell vorankommen oder völlig feststecken.
Wenn man prägnante und klare Anweisungen geben kann, Code schnell überprüft und ein Gespür für Architektur hat, kann das die Entwicklungsgeschwindigkeit wirklich erhöhen.
Ich habe selbst einmal ein Tower-Defense-Spiel gebaut und hatte zuletzt darüber nachgedacht, AI auch für die Erzeugung neuer Wellen oder fürs Balancing-Tuning einzusetzen.
Damit AI ein Spiel wirklich „spüren“ kann, bräuchte man vielleicht ein Protokoll, das den auf dem Bildschirm sichtbaren Spielzustand in Tokens umwandelt und kodiert.
Also Terrain, Positionen von Spielobjekten und weitere Eigenschaften, die der Spieler sehen kann.
Alles in einen Autoencoder zu werfen, wäre wohl keine gute Idee, aber eine Tokenisierung als Listen einzelner Spielelemente könnte Potenzial haben.
Wenn die Game Engine Bildschirmbilder liefert und die Tokens direkt für AI entfaltet, könnte AI den tatsächlichen Spielverlauf viel tiefer verstehen.
Ich weiß nicht, wie groß der Trainingsdatensatz sein müsste, um solche Tokens sinnvoll zu nutzen, aber vielleicht ließe sich das mit dem heutigen Embedding-Raum schon in wenigen Tokens ausdrücken.
Mit einem Trainingssatz aus Spiel-Logs und Bewertungen des Spielspaßes durch Nutzerinnen und Nutzer könnten dabei viele interessante Daten entstehen.
Man könnte sogar Cluster von Spielerpräferenzen finden und Spiele für verschiedene Typen erzeugen.
Danke, dass du diesen Workflow geteilt hast.
Ich überlege ebenfalls, wie sich Nachverfolgbarkeit und Transparenz in LLM-Workflows einführen lassen.
Wenn man Prompts teilt und historisiert, hat das den großen Vorteil, dass man das eigentliche Problem, das Entwicklerinnen und Entwickler anfangs lösen wollten, und auch dessen Veränderung sowie neu entstandene Themen auf einen Blick sehen kann.
Cooles Projekt.
Beitrag zur verantwortungsvollen Nutzung von LLMs
Ich bin seit über 20 Jahren in der Tech-Branche und experimentiere in letzter Zeit viel damit, mit Gemini-cli ein Integrationstest-Tool für Enterprise-Apps zu gamifizieren.
In Kombination mit einem MCP-Server habe ich festgestellt, dass die besten Ergebnisse entstehen, wenn man Probleme in einzelne Schritte zerlegt und die Prompts klarer formuliert.
AI kann Fehler machen oder in Schleifen geraten, besonders etwa beim App-Routing; in solchen Fällen ist es hilfreich, aktiv mit einer Haltung des „Pair Programming“ heranzugehen.
Noch etwas ist mir aufgefallen: Prinzipien wie das Vermeiden von doppeltem Code lassen sich viel leichter als früher einhalten.
Sonst passiert leicht, dass AI nur einen Teil ändert und zusammenhängende Dateien übersieht.
Das gilt nicht nur für Programmlogik, sondern genauso für UX und App-Verhalten.
Mit AI lassen sich Aufgaben, die früher Wochen gedauert hätten, heute oft in wenigen Stunden mit Freude abschließen.
Dass man Gemini eine eigene Persönlichkeit geben und die Datei
GEMINI.mdunverändert auf verschiedene Geräte mitnehmen und weiter anpassen kann, ist ein sehr großer Vorteil.