Hallo. Vor Kurzem habe ich allein ein Mobile Game namens „Sumbi“ entwickelt. Es ist ein vertikales Roguelike, inspiriert vom Tauchen der Jeju-Haenyeo. Mit einem einzigen Atemzug taucht man ins Meer, sammelt Meeresfrüchte und entscheidet, ob man noch gieriger werden oder jetzt umkehren soll.
Am 2. Juli habe ich mit dem Design begonnen, am 9. Juli den ersten Build bei Google Play hochgeladen und die beim Spielen aufgefallenen Schwächen laufend verbessert, sodass ich am 19. Juli bereits den v1.1-Build in die Produktion hochgeladen habe.
Was mich von Anfang an interessiert hat, war nicht einfach nur: „Wie schnell kann AI Code schreiben?“ Ich wollte testen, wie weit man ein tatsächlich veröffentlichungsreifes Spiel entwickeln kann, wenn man mehreren AI-Modellen unterschiedliche Rollen gibt und sie wie ein einziges Entwicklungsteam arbeiten lässt.
Was für ein Spiel ist es?
„Sumbi“ ist benannt nach dem pfeifenden Atem der Haenyeo, wenn sie nach dem Tauchen wieder an die Wasseroberfläche kommen und ausatmen.
Eine Runde dauert etwa 10 bis 30 Sekunden. Mit einer Hand bewegt man die Haenyeo, taucht tiefer hinab oder sammelt Meeresfrüchte in der Umgebung. Nur wenn man sicher die Oberfläche erreicht, kann man das Gesammelte vollständig mitnehmen, weshalb man ständig abwägt, ob man noch etwas gieriger wird oder jetzt umkehrt. Oben angekommen rechnet man die Beute ab, verbessert Lungenkapazität, Flossen, Netzkorb und Spürsinn und taucht dann erneut hinab.
Ich habe einen Roguelike-Draft eingebaut, bei dem man pro Runde eine von drei Fähigkeiten wählt, ein Meeresfrüchte-Lexikon mit 60 Arten, Ausrüstung und einen Fortschrittsbaum, Beförderungen im Haenyeo-Rang sowie einen bis auf 100 m reichenden Atempfad. Die Steuerung sollte einfach bleiben, aber mit jedem weiteren Tauchgang sollten sich die angestrebten Rekorde und Builds verändern.
Ich habe AI nicht als einen allmächtigen Einzelentwickler eingesetzt
Wenn ein einziges Modell alles von der Planung bis zur Umsetzung und Selbstprüfung übernimmt, behandelt es seine eigenen Annahmen leicht einfach als richtige Antwort. Deshalb habe ich die Rollen so aufgeteilt.
- Fable 5: Spielstruktur und Funktionsspezifikation, Ziele für die Wirtschafts-Balance, Definition der Abnahmekriterien
- Opus 4.8: Umsetzung mit Flutter·Flame, Schreiben von Tests, Debugging
- Fable 5: erneuter Abgleich der ursprünglichen Spezifikation mit dem Implementierungsergebnis, Prüfung auf Auslassungen und Regressionen
- Codex GPT-5.5: unabhängiges Review von Code und Änderungen sowie Hinweise auf Edge Cases
Die Arbeitsreihenfolge war im Großen und Ganzen Design → Implementierung → erneute Prüfung durch den ursprünglichen Planer → unabhängiges Code-Review → automatisierte Tests und praktisches Spielen.
Dabei stellte sich heraus, dass es wichtiger ist, zuerst überprüfbare Abnahmekriterien festzulegen, als besonders elegante Prompts zu schreiben. Statt „Sorg für ein gutes Progressionsgefühl“ habe ich Zahlen definiert, etwa die Zahl der Käufe in den ersten 10 Minuten, die Zeit bis zur ersten Beförderung und ob es in irgendeinem Fortschrittsabschnitt lange Phasen gibt, in denen man gar nichts kaufen kann. Anschließend habe ich das mit einem Wirtschaftssimulator und Tests überprüft.
Derzeit gibt es 627 automatisierte Tests, und alle bestehen. Auch die statische Analyse von Flutter läuft für App-Code, Tests und Tools ohne Fehler durch.
Fälle, in denen AI plausibel falsch lag
Aus dem ersten Entwurf wurde nicht sofort ein unterhaltsames Spiel.
In der frühen Version gab es pro Runde nur 5 bis 9 sammelbare Ziele. Für ein Sammelspiel wirkte das Meer leer. Nach eigenem Anspielen habe ich diese Struktur verworfen. Mit wachsendem Fortschritt wird das Spielfeld nun reichhaltiger, und an geernteten Stellen wachsen wieder neue Meeresfrüchte nach. Mit bestimmten Progressions-Builds kann man in einer Runde bis zu etwa 40 Stück sammeln.
Ähnlich war es beim Fortschrittsbaum. Es gab zwar 290 Knoten, aber das tatsächliche Spielen verlief fast geradlinig. Die AI hatte zwar die Anforderung „290 Knoten“ erfüllt, aber nicht den Spaß an der Auswahl erzeugt. Am Ende habe ich die Struktur in drei spezialisierte Pfade und permanente Knoten neu aufgeteilt.
AI kann schnell viel Code erzeugen, garantiert aber weder Spielspaß noch Prioritäten. Beim eigenen Spielen klar zu sagen „Das macht keinen Spaß“ oder „Es gibt viele Features, aber das nächste Ziel ist nicht erkennbar“ blieb weiterhin Aufgabe des Menschen.
Auch für Bilder und Sound habe ich selbst eine Pipeline gebaut
Wichtige Bild-Assets wie die Haenyeo-Figur, Meeresfrüchte, Ausrüstung und Karten-Icons habe ich mit der GPT Image Generation API erstellt. Ich habe die generierten Sheets nicht unverändert verwendet, sondern sie nach dem Entfernen des Chroma Keys, Frame-Ausrichtung, Vereinheitlichung der Größe und Pixel-Quantisierung durch eine Korrektur-Pipeline geschickt und dann geprüft. Hintergründe, Blasen, Lichtstrahlen und Ähnliches wurden größtenteils per Code gezeichnet.
Beim Sound habe ich statt externer Assets WAV-Dateien direkt in Dart-Code synthetisiert. Das beim Ende eines Tauchgangs hörbare Sumbi-Geräusch habe ich als zentralen Sound festgelegt, in dem der Spielname und das Ende einer Runde zusammenkommen.
Was sich nach der Entwicklung an meinem Denken geändert hat
Oft heißt es: „AI arbeitet gut, wenn man sie gut anweist.“ Dieses Mal habe ich noch stärker gelernt, dass es wichtiger ist, eine Struktur zu haben, die Fehler auffängt.
Ich habe Planer, Umsetzer und Prüfer getrennt und andere Modelle dazu gebracht, Plan und Code aggressiv zu hinterfragen. Die endgültige Bewertung habe ich Zahlen, Tests und echtem Spielen überlassen. Diese Methode war deutlich stabiler, als mit einem einzigen Modell lange Gespräche zu führen und ihm alles zu überlassen.
Auch wenn AI schneller wird, verschwinden die Engpässe der Solo-Entwicklung nicht. Stattdessen hat sich der Engpass vom Codieren zum Entscheiden verlagert. Am meisten Zeit kostete die Frage, was bleiben und was gestrichen werden soll und warum etwas im aktuellen Zustand keinen Spaß macht.
Google Play
https://play.google.com/store/apps/details?id=com.kinderia.sumbi
Es ist immer noch ein allein entwickeltes Spiel, daher gibt es noch vieles, was nicht ausgereift ist. Ich würde gern hören, ob es keinen Spaß macht oder ob das Fortschrittsmenü zu komplex ist. Fragen zur Entwicklungsmethode oder zur Rollenverteilung der einzelnen Modelle könnt ihr ebenfalls gern hinterlassen.
Noch keine Kommentare.