Ein 3D-Spiel an einem Tag: BOINGWARD mit KI-Agenten

BOINGWARD ist ein 3D-Handyspiel, in dem ein rostiger Roboter auf einem Pogostab, der nie aufhört zu springen, einen Turm aus schwebenden Plattformen hinaufklettert. Es gibt keine Sprungtaste: Der Pogostab springt bei jeder Landung von selbst ab, und Sie wählen mit dem linken Daumen, wo er landet, und mit dem rechten, wohin Sie schauen.

Dieser Beitrag erzählt vom ersten Tag des Spiels. Der erste Commit kam am 4. Oktober 2026 um 8:47 Uhr, der 148. um 18:06 Uhr. Dazwischen entstanden ein Build auf dem iPhone, ein handgestalteter Parcours, mehr als vierzig Plattformtypen, Medaillen, Erfolge, ein etwa einen Kilometer hoher Klettermodus und ein Online-Rennserver, der noch nicht eingeschaltet ist. Den Code habe nicht ich geschrieben. Ich habe mehrere Claude-Code-Sitzungen gleichzeitig gesteuert, die Entscheidungen getroffen und auf dem Telefon getestet. Das Spiel ist weiter in Entwicklung und in keinem Store; was fertig ist und was nicht, steht weiter unten.

Kalecik hatte ich bereits auf dieselbe Weise entwickelt. Neu war diesmal: Die Aufgabe war größer, und in der ersten Stunde haben wir die Engine gewechselt.

Der Ausgangspunkt: ein Designpaket

Es gab keinen Code, nur ein Designpaket: Produktvision, Pogo-Physik, mobile Steuerung, Mehrspieler, Leveldesign, Art Direction, Ökonomie, UI-Ablauf, Performance-Budgets und Roadmap, jeweils als eigenes Dokument. Am nützlichsten war die Liste der unverhandelbaren Punkte:

• Pogo-Springen ist die Hauptbewegung. Es gibt keine klassische Sprungtaste.
• Über Rennen entscheidet das Können; Kosmetik ändert nie die Physik.
• In Ranglistenrennen prallen Spieler nicht physisch aufeinander.
• Belohnte Werbung ist freiwillig; keine Werbung nach jedem Sturz.
• Kein Paket, Dienst oder kostenpflichtiges SDK wird stillschweigend hinzugefügt; die Entscheidung wird zuerst dokumentiert.

Im Paket gab es auch einen „So nicht“-Ordner: frühere Konzeptbilder, die verworfen wurden, weil sie zu sehr nach Fall Guys aussahen. Den Agenten nicht nur das Ziel, sondern auch das Nicht-Ziel zu zeigen, hat die Diskussion über die Optik stark abgekürzt. Der Name wurde genauso sorgfältig gewählt: Als sich Namen wie Pogo Panic, HopBound und Hopspire als vergeben herausstellten, blieb BOINGWARD. Im Dokument steht klar: Dass ein Name in der Suche nicht auftaucht, ist keine Markenfreigabe; das wird vor dem Start eigens geprüft.

Warum Godot statt Unity?

Das Paket war für Unity 6 und C# geschrieben. Noch am selben Morgen, vor dem ersten Commit, sind wir zu Godot gewechselt. Die Begründung steht in der Regeldatei des Projekts: Ein Unity-Projekt lässt sich nur in einem Editor gleichzeitig öffnen, Batch-Builds sind langsam, und binäre Szenendateien samt .meta-Dateien erzeugen Merge-Konflikte zwischen parallel arbeitenden Agenten.

In Godot sind Szenen, Code und Ressourcen reiner Text. Agenten können ohne Editor über die Kommandozeile importieren und Tests ausführen: godot --headless --path game -s tests/run_tests.gd. Erst das machte mehrere Sitzungen in einem Projekt möglich. Die Wahl fiel auf Godot 4.7.2, statisch typisiertes GDScript, den Mobile-Renderer und die Physik-Engine Jolt.

Parallele Sitzungen: Jeder hat seinen Ordner

Der erste Plan sah drei Sitzungen vor, jede mit festgeschriebenen Ordnern:

• Lead: Pogo-Physik, Integration, Tests, Export-Einstellungen.
• B: Touch-Eingabe, Kamera, Oberfläche, Haptik, Einstellungen.
• C: Parcours, visueller Stil, Sound.

Jede Sitzung arbeitete in einem eigenen Git-Worktree auf einem eigenen Branch und fasste nur ihre eigenen Ordner an. Gemeinsame Dateien wie project.godot oder die Pogo-Tuning-Ressource durfte nur der Lead ändern; die anderen schrieben ihre Wünsche in ihre Berichte. Verbunden wurden die Teile über kleine Verträge. Der Eingabeknoten bietet zum Beispiel nur zwei Dinge an: get_move() für die Stick-Richtung und consume_look_delta() für das Ziehen der Kamera. Der Pogostab sendet die Signale bounced, state_changed und respawned. Das Kamera-Team musste das Innenleben des Pogostabs nie kennen, das Pogo-Team nie den Touchscreen.

Im Laufe des Tages kamen weitere Sitzungen dazu: Performance, Netzwerk für den Mehrspielermodus, Plattform-Kit, Abschnitts-Replay, Erfolge, Levelliste und Maskottchen-Animation entstanden jeweils auf eigenen Branches und wurden in den Hauptzweig gemergt.

Ein Haken trat auf: Wenn mehrere Sitzungen gleichzeitig die volle Testsuite auf demselben Mac starteten, lief die CPU voll und zeitkritische Netzwerktests schlugen zufällig fehl. Die Lösung war einfach: Das Testskript holt sich eine maschinenweite Sperre, es läuft immer nur ein voller Testlauf, die anderen warten.

Wie der Tag verlief

Die Uhrzeiten stammen aus dem Commit-Log; Arbeit auf einem Branch kann vor ihrem Merge datiert sein.

Uhrzeit	Was geschah
8:47	Godot-Basis-Commit: Pogo-Physik, Tests, Laborszene
9:11	iOS-Export; Debug-Build auf einem iPhone 15 Pro Max installiert
9:38	Parcours, Pogo, Kamera, Oberfläche und Ton in einer Szene vereint
10:01	Erstes Plattform-Kit (9 Teile)
10:29	Mehrspieler-Kern: versioniertes Protokoll, autoritativer Rennserver, Bots
11:23	Eigener Startbildschirm
13:40	Checkpoints zählen nur, wenn man auf ihrem Pad landet
14:17	Abschnitts-Replay: alle Versuche eines Abschnitts laufen gleichzeitig ab
14:27	Erfolge und Statistikdienst
15:38	Zweites Plattform-Kit: 24 weitere Typen
16:48	Lufttricks: Zustandsautomat, Belohnung, Bruchlandung
16:58	Levelliste und Medaillenzeiten
17:34	Hauptmenü
17:39	Klettermodus: ein einziger, handgebauter Turm von etwa 1 km
18:06	Letzter Commit des Tages

Tests sind der einzige Beweis

Der wichtigste Satz in der Regeldatei ist für mich dieser: „Behaupte nie, dass etwas funktioniert, wenn es nicht ausgeführt wurde. Wenn es nur auf dem Telefon überprüfbar ist, sag genau das.“ Agenten schreiben sehr schnell Code; ob schnell geschriebener Code wirklich funktioniert, zeigen nur Tests.

Am Ende des Tages enthielt das Repository 33 Testdateien und 15 einzelne Testsuiten: Physik, Oberfläche, beide Plattform-Kits, Parcours, Netzwerk, Replay, Erfolge, Klettermodus, Level, Menü, Performance und Maskottchen-Animation. Insgesamt etwa 26.800 Zeilen GDScript. Darüber liegt noch eine Prüfung: Derselbe Physiktest läuft mit 30, 60 und 144 Bildern pro Sekunde, und die Ergebnisse müssen exakt übereinstimmen. Wie das funktioniert, erkläre ich im Beitrag zur Pogo-Physik.

Am nützlichsten waren die Parcours-Bots. Ein Bot versucht jeden Sprung einzeln mit der echten Pogo-Physik; wenn selbst ein Bot eine Plattform nicht erreicht, ist der Parcours falsch. Das steht ausführlich im Beitrag zum Leveldesign.

Was das Telefon verraten hat

Das Telefon zeigte, was der Rechner nicht zeigte. Auf einem iPhone 15 Pro Max hielt das Spiel 60 Bilder pro Sekunde, aber die Bildzeiten waren ungleichmäßig: 23,4 Millisekunden im 95. Perzentil. Ursache war die 120-Hz-Bildwiederholung des Displays im Zusammenspiel mit der 60-fps-Grenze; die Bilder kamen in einem Mix aus 8, 17 und 25 Millisekunden. Mit abgeschalteter hoher Bildwiederholrate sank derselbe Messwert auf 17,3 Millisekunden. Ein 120-fps-Modus kam später mit Physik-Interpolation als Option in den Einstellungen zurück. Bei Kalecik hatten wir gesehen, wie 120 Hz das Telefon aufheizen; diese Geschichte hat einen eigenen Beitrag.

Mein Anteil

Den Code haben die Agenten geschrieben, die Richtung habe ich vorgegeben. Die Fall-Guys-ähnlichen Entwürfe habe ich verworfen. Die Lufttricks gehen auf einen Satz von mir zurück: „Wenn er einen coolen Move hinlegt, soll er höher springen.“ Der Agent hat daraus ein riskantes, freiwilliges Belohnungssystem gemacht; die Einzelheiten stehen im Beitrag zum Trick-Design. Jeden Zwischenstand habe ich auf dem Telefon ausprobiert, und der Mehrspielerserver wurde in einem echten Netz mit acht Bots über den Hotspot meines Telefons getestet. Den Fehler, den dieser Test fand, beschreibe ich im Mehrspieler-Beitrag.

Was fertig ist und was nicht

An einem Tag ist viel entstanden, aber nicht alles ist fertig. Die ehrliche Liste:

• Spielbar: der Spire-Parcours, der Klettermodus, Medaillen, Erfolge, Abschnitts-Replay, Einstellungen.
• Im Code, für Spieler verborgen: Online-Rennen. Server und Tests sind fertig; der Menüknopf ist ausgeblendet.
• Halb fertig: Physik und Animation der Lufttricks sind drin, aber die TRICK-Taste auf dem Bildschirm ist noch nicht an die Eingabe angebunden.
• Nicht gemessen: Performance auf irgendeinem Android-Gerät und der Wärmeverlauf über fünf Minuten auf dem iPhone.
• Store: Das Spiel ist weder im App Store noch bei Google Play, und die Menüs gibt es vorerst nur auf Englisch und Türkisch.

Den aktuellen Stand halte ich auf der BOINGWARD-Seite fest.

Die weiteren Beiträge der Serie

1. Pogo-Physik in Godot: Eine Figur, die von selbst springt
2. Leveldesign mit Messwerten, geprüft von einem Bot
3. Risiko und Belohnung: Lufttricks für ein Pogo-Spiel
4. Schummelschutz im Mobilfunknetz: serverautoritative Rennen in Godot

Häufig gestellte Fragen

Kann man ein Spiel wirklich an einem Tag entwickeln?

Einen spielbaren Prototyp, ja; ein storefertiges Spiel, nein. Am ersten Tag von BOINGWARD entstanden das Kern-Gameplay, zwei Modi und viele Tests. Store-Grafiken, Gerätetests, Sprachunterstützung und das Einschalten des Online-Modus laufen noch.

Unity oder Godot für Spiele mit KI-Agenten?

Wer mehrere Agenten parallel in einem Projekt arbeiten lassen will, hat es mit Godots Textdateien und Tests ohne Editor deutlich leichter. Unitys Ein-Editor-Sperre und binäre Merges erschweren diesen Aufbau. Mit nur einer Sitzung ist der Unterschied kleiner.

Machen sich parallele Claude-Code-Sitzungen nicht gegenseitig die Arbeit kaputt?

Ohne Regeln schon. Hier haben drei Dinge funktioniert: eigener Worktree und eigene Ordner pro Sitzung, gemeinsame Dateien ändert nur der Lead, und die Sitzungen sind über kleine, schriftliche Verträge verbunden. Eine Sperre, die nur einen vollen Testlauf gleichzeitig erlaubt, hat außerdem die zufälligen Testfehler beendet.