Spiel mit KI entwickeln: von Phaser bis Godot

Am einfachsten entwickelst du ein Spiel mit KI, indem du einen Coding-Agenten ein kleines Browserspiel mit HTML-Canvas oder Phaser schreiben lässt, jede Änderung sofort im Browser spielst und das „Spielgefühl“ selbst abstimmst, denn genau das kann der Agent nicht beurteilen. Für größere 2D- oder 3D-Projekte ist Godot ein guter nächster Schritt. Wenn du fertig bist, kannst du das Spiel auf itch.io stellen und in wenigen Minuten teilen.

Dieser Beitrag führt ein erstes Spiel vom leeren Ordner bis zur veröffentlichten Seite: welches Tool ich wähle und warum, den ersten Prompt an den Agenten, die Game Loop, Grafik und Sound (einschließlich Lizenzen), das Abstimmen des Spielgefühls, Playtests und itch.io.

Warum Spiele so gut zu Vibe Coding passen

Spiele gehören zu den unterhaltsamsten und lehrreichsten Dingen, die du mit Vibe Coding bauen kannst. Ergebnisse sind sofort sichtbar: Ändere eine Zahl, und die Figur springt höher. Ein kleines Spiel besteht nur aus wenigen Dateien, sodass der Agent alles im Kontext behalten kann.

Es gibt allerdings eine Falle. „Es läuft“ und „es macht Spaß“ liegen weit auseinander. Der Agent kann prüfen, ob der Code funktioniert; er kann nicht prüfen, ob das Spiel Spaß macht. Dieser Teil gehört dir.

Welches Tool: Canvas, Phaser, Godot oder Unity

Für ein erstes Spiel empfehle ich Phaser. Reines Canvas geht auch, aber Kollision, Sprite-Animation und Eingabeverarbeitung von Grund auf schreiben zu lassen kostet Zeit; Phaser bringt sie mit. Dazu ist alles eine Textdatei, die im Browser läuft, es gibt also keinen Editor, den der Agent nicht sehen kann.

Wechsle zu Godot, wenn das Spiel wächst: viele Szenen, aufwendiges Leveldesign, 3D oder ein Desktop-Build. Godots Szenendateien (.tscn) und Ressourcen (.tres) sind lesbarer Text, der Agent kann sie also bearbeiten. Trotzdem baue ich Szenen selbst im Editor zusammen und überlasse dem Agenten das GDScript; ein kleiner Fehler in einer von Hand bearbeiteten Szenendatei kann dazu führen, dass der Editor sie nicht mehr öffnet.

Unity ist mächtig, aber die sperrigste Option, um sie mit einem Agenten zu steuern. Der Agent schreibt C#-Skripte problemlos; Szenen, Prefabs und Inspector-Einstellungen liegen im Editor. Wenn du Unity schon kennst, nimm es; für ein erstes Spiel ist es nicht meine Wahl.

Schritt 1: Einrichtung

Das brauchst du:

• Node.js und einen Paketmanager
• Einen Coding-Agenten: Claude Code, Codex, Gemini CLI, opencode oder Ähnliches
• Git, damit du immer zu „gestern ging es noch“ zurückkehren kannst

Starte ein Projekt mit Vite und füge Phaser hinzu:

npm create vite@latest cactus-run -- --template vanilla-ts
cd cactus-run
npm install
npm install phaser
git init && git add -A && git commit -m "initial scaffold"
npm run dev

npm run dev gibt eine lokale Adresse aus; öffne sie, um das Spiel zu sehen, und die Seite lädt neu, sobald der Agent Dateien bearbeitet.

Schritt 2: Der erste Prompt

Der erste Prompt ist bei Spielen sehr wichtig, denn „mach ein Spiel“ liefert dir das Spiel, das sich der Agent vorstellt. Halte den Umfang klein und konkret:

This is a Vite + TypeScript project with Phaser installed. We're
building a simple endless runner.

Game:
- The player runs left to right and jumps with space or a tap.
- Cacti come in from the right; touching one ends the game.
- Score increases over time and shows in the top right.
- On game over, show "Press space to restart".

Rules:
- Use coloured rectangles instead of art for now.
- Put every tunable number (gravity, jump velocity, game speed,
  cactus spacing) in a single object in src/config.ts.
- Use Arcade physics.
- The game is 800x400 and scales to fit the screen.
- npx tsc --noEmit must pass.
- When done, explain the file structure and the values in config.ts.

Die wertvollste Regel hier ist config.ts. Das Spielgefühl stimmst du ab, indem du mit den Zahlen in dieser Datei spielst; liegen sie verstreut im Code, bedeutet jede Anpassung einen Umweg über den Agenten.

Auch die Regel „Rechtecke statt Grafik“ ist wichtig. Bring zuerst das Gameplay in Ordnung, dann mach es hübsch. Ein schöner Prototyp, der keinen Spaß macht, ist das schlechteste Ergebnis.

Schritt 3: Die Game Loop verstehen

Im Herzen jedes Spiels steckt eine Schleife: Eingabe lesen, Welt aktualisieren, Bild zeichnen, wiederholen, dutzende Male pro Sekunde. Phaser führt sie für dich aus und ruft in jedem Frame update(time, delta) deiner Szene auf. Bei reinem Canvas schreibst du sie selbst:

let last = performance.now()

function loop(now) {
  const dt = (now - last) / 1000 // seconds since the last frame
  last = now
  update(dt)
  draw()
  requestAnimationFrame(loop)
}

requestAnimationFrame(loop)

Das eine Konzept, das du kennen solltest, ist dt: Bewege Dinge anhand der vergangenen Zeit, nicht pro Frame. Agenten schreiben manchmal x += 5, und dann läuft das Spiel auf einem Bildschirm mit hoher Bildwiederholrate schneller. Siehst du im Bewegungscode kein dt, frag den Agenten danach.

Schritt 4: Spielen, iterieren, committen

Der Ablauf:

1. Spiele eine Minute lang.
2. Beschreibe konkret, was du gespürt hast: „Der Sprung hängt zu lange in der Luft; den Kakteen auszuweichen ist zu leicht.“
3. Lass den Agenten es ändern und spiele dann erneut.
4. Committe jede Version, die sich gut anfühlt.

Füge Fehler aus der Browser-Konsole (F12) wortgetreu beim Agenten ein. Bei visuellen Problemen schick einen Screenshot.

Eine Warnung: Lass die Spiellogik nicht in einer einzigen großen Anfrage wachsen. „Füge Power-ups, einen Bosskampf und ein Levelsystem hinzu“ verheddert alle drei miteinander. Eine Mechanik nach der anderen.

Schritt 5: Spielgefühl

Was ein Spiel gut anfühlen lässt, sind meist nicht große Features, sondern kleine Details. Agenten bauen sie nicht von allein ein, setzen sie aber gut um, wenn du darum bittest:

• Coyote Time: Erlaube kurz nach dem Laufen über eine Kante noch einen Sprung.
• Jump Buffering: Merke dir einen Sprung, der kurz vor der Landung gedrückt wurde.
• Variable Sprunghöhe: Kappe die Aufwärtsgeschwindigkeit, wenn die Taste losgelassen wird.
• Screen Shake und Hit Stop: Bei einem Treffer für ein paar Frames einfrieren.
• Tweens: Der Punktestand, der aufploppt, ein Gegner, der beim Verschwinden wackelt.
• Sound: Ein kurzer Sprungsound verändert das Gefühl mehr als alles, was auf dem Bildschirm passiert.

So ein Prompt sieht bei mir aus:

Improve the jump feel:
- Add 100 ms of coyote time and a 100 ms jump buffer.
- If space is released early, halve the upward velocity.
- On collision, add an 80 ms hit stop and a light screen shake.
Put all durations in config.ts. Don't change any other behaviour.

Spiele dann selbst mit den Zahlen in config.ts. Diesen Teil kannst du nicht an eine KI abgeben; Unterschiede von ein paar Millisekunden spürst du nur beim Spielen.

Schritt 6: Grafik, Sound und Lizenzen

Wenn das Gameplay stimmt, tausche die Rechtecke gegen echte Grafik. Nur bei der Lizenzierung musst du aufpassen.

Fertige Packs:

• Viele Packs von Quellen wie Kenney sind CC0 und lassen sich sogar ohne Namensnennung nutzen.
• Auf OpenGameArt hat jede Datei ihre eigene Lizenz (CC0, CC‑BY, CC‑BY‑SA, GPL …). CC‑BY verlangt eine Namensnennung; CC‑BY‑SA kann verlangen, dass du abgeleitete Werke unter derselben Lizenz teilst. Lies die Lizenz jeder Datei.
• Bezahlte und kostenlose Asset-Packs auf itch.io haben jeweils eigene Lizenzen; prüfe, ob kommerzielle Nutzung erlaubt ist.

Führe eine CREDITS.md oder einen Credits-Bildschirm im Spiel, der Quelle und Lizenz jedes Assets nennt.

KI-generierte Grafik ist schnell und verlockend, aber mit einigen Vorbehalten:

• Der urheberrechtliche Status KI-generierter Inhalte ist je nach Land verschieden, und einige Fragen sind noch ungeklärt.
• Jedes Bildtool hat eigene Nutzungsbedingungen; prüfe die kommerzielle Nutzung.
• Manche Spiele-Stores verlangen einen Hinweis auf KI-generierte Inhalte.
• Auch technisch ist es fummelig: Stilkonsistenz, Sprite-Sheet-Layout und passende Animationsframes brauchen oft manuelle Nacharbeit.

Mein Vorgehen: offen lizenzierte Packs für den Prototyp; für die Veröffentlichung Grafik, die ich selbst gemacht habe oder deren Lizenz ich sicher kenne.

Es gibt Asset-Arbeit, die der Agent gut erledigt: ein Sprite Sheet in Phaser laden, Animationen definieren, Sounddateien verdrahten. Gib ihm Dateinamen und Framegröße, statt ihn raten zu lassen.

Schritt 7: Playtesting

Wer das Spiel gebaut hat, ist sein schlechtester Tester; er weiß ja schon, was zu tun ist. Dasselbe gilt für den Agenten. So gehst du vor:

• Gib das Spiel jemandem und erkläre nichts. Beobachte still, wo er hängen bleibt.
• Mach Notizen: wo er gestorben ist, wo er sich gelangweilt hat, was er missverstanden hat.
• Verwandle diese Notizen in Aufgaben für den Agenten: „Spieler laufen immer in den ersten Kaktus; in den ersten 5 Sekunden keine Kakteen.“

Kleine Teile der Spiellogik (Punktewertung, Kollisionsregeln) lassen sich mit Unit-Tests prüfen; lass den Agenten sie schreiben. Das Gefühl kannst du nur durch Spielen testen.

Schritt 8: Veröffentlichen auf itch.io

Ein Browserspiel auf itch.io zu stellen dauert ein paar Minuten:

npm run build
cd dist && zip -r ../cactus-run.zip . && cd ..

Lege dann auf itch.io ein neues Projekt an, setze die Art auf HTML, lade das Zip hoch und markiere es als im Browser spielbar. Stelle die Viewport-Größe (zum Beispiel 800×400) und den Vollbild-Button ein. Das Zip braucht index.html im Stammverzeichnis; mit Vite brauchst du eventuell base: './' in vite.config.ts für relative Pfade, was der Agent für dich prüfen kann.

In Godot installierst du das Web-Export-Template, exportierst nach HTML5 und lädst genauso hoch. Wenn du oft aktualisierst, automatisiert das Kommandozeilen-Tool butler von itch.io die Uploads.

Was Agenten bei Spielen häufig falsch machen

• Sie sehen das Spiel nicht. Der Agent schreibt Code, weiß aber nicht, was auf dem Bildschirm ist. Screenshots oder eine Beschreibung dessen, was du siehst, sind unverzichtbar.
• Magic Numbers. Werte verstreuen sich im Code. Wiederhole die config.ts-Regel bei jeder neuen Mechanik.
• Frameabhängige Bewegung. Ohne dt läuft das Spiel auf verschiedenen Bildschirmen unterschiedlich schnell.
• Veraltete APIs. Phaser und Godot haben ihre APIs zwischen Hauptversionen geändert, und der Agent schreibt womöglich Code für die alte. Nenne ihm die Version: „Wir sind auf Godot 4, schreib keine Godot-3-Syntax.“
• Alles in einer Datei. Wächst das Spiel, bitte ihn, Szenen, Entitäten und Einstellungen auf getrennte Dateien aufzuteilen.
• Performance wird ignoriert. Bei hunderten Projektilen oder Gegnern wird das Spiel langsam. Bitte um Object Pooling.

Sicherheit

Ein Spiel wirkt harmlos, aber dieselben Regeln gelten:

• Wenn du eine Bestenliste oder ein Multiplayer-Backend hinzufügst, halte Schlüssel in .env und trage .env in .gitignore ein.
• Alles in einem Browserspiel kann der Spieler lesen; geheime Schlüssel gehören nie in Client-Code.
• Füge keine API-Keys in den Chat ein; sag dem Agenten, welche Umgebungsvariable er lesen soll.
• Lies die Befehle, die der Agent ausführt, bevor du sie freigibst, besonders Paketinstallationen und Löschbefehle.
• Vertraue keinen Punktzahlen, die der Client schickt; eine Online-Bestenliste zu fälschen ist leicht.

Mit AgentVera arbeiten

All das funktioniert mit einem Terminal und einem Browser. Bei Spielprojekten lasse ich gern mehrere Agenten nebeneinander laufen und sehe das Ergebnis im selben Fenster, deshalb nutze ich AgentVera:

• Getrennte Experimente in getrennten Worktrees. Ein Agent arbeitet in einem Git-Worktree am Sprunggefühl, während ein anderer in einem zweiten einen neuen Gegnertyp ergänzt; verwirf das Experiment, das dir nicht gefällt. Das Git-Panel zeigt die Branches.
• Der Agent-Browser. Mit dem Agent-Browser kann der Agent das Spiel über Playwright öffnen und Screenshots machen, während du den Tab live verfolgst. Das löst „der Agent sieht das Spiel nicht“ teilweise; das Gefühl löst es nicht.
• Terminal und Editor. npm run dev bleibt in einem Pane offen, und config.ts bearbeitest du selbst im Editor.
• Review und Tokens. Das Code-Review prüft jeden Turn, bevor du mergst, und der Token-Verbrauch ist pro Pane sichtbar.

AgentVera ist keine Game-Engine; sie ersetzt weder den Godot-Editor noch itch.io.

Kurze Checkliste

• Das erste Spiel ist klein: eine Mechanik, ein Bildschirm
• Einstellbare Zahlen liegen in config.ts
• Bewegung nutzt dt
• Erst Gameplay mit Rechtecken, dann Grafik
• Quelle und Lizenz jedes Assets sind notiert
• Mindestens eine Person hat es ohne Erklärung gespielt
• Das itch.io-Zip hat index.html im Stammverzeichnis

Zum Schluss

Ein Spiel mit KI zu entwickeln gehört zu den schönsten Einsatzzwecken von Vibe Coding. Fang klein an mit Phaser im Browser, halte die Zahlen in einer Datei, bring das Gameplay mit Rechtecken in Ordnung, stimm das Gefühl mit eigenen Händen ab und achte auf die Lizenzen. Der Agent schreibt den Code; du sorgst dafür, dass es Spaß macht. Wie du Experimente mit mehreren Agenten fährst, steht unter parallele Coding-Agenten; bei der Wahl eines Tools helfen die besten KI-Coding-CLI-Tools.