Alle Beiträge
KI Claude Code Spieleentwicklung MCP Agenten Heilstätten Online Brandenburg Jewels

Spieleentwicklung mit KI: Heilstätten Online und Brandenburg Jewels

Von der Idee über Wirkmittel Studio zu Claude Code: Agenten, GitHub Issues und Hooks in zwei Spieleprojekten eines Solo-Founders.


Gemalte Spielszene aus Heilstätten Online: Heizkraftwerk mit Wasserturm im Herbstwald

Heilstätten Online, Szene Heizkraftwerk. Der Wasserturm ist das Ende des Spiels.

Seit Anfang Oktober hab ich zwei Spiele in Arbeit, und an keinem davon sitze ich allein. Heilstätten Online ist eine isometrische Koop-Sandbox für ein bis zehn Spieler auf dem Tablet, angesiedelt in Beelitz Heilstätten, vom Gefühl her irgendwo bei Ultima Online. Brandenburg Jewels ist ein Match-3 mit Motiven aus der Region, erst für Android, iOS kommt aus demselben Code hinterher. Die Arbeitsteilung ist in beiden Projekten gleich: Ideen und Entscheidungen kommen von mir, Bilder aus Wirkmittel Studio, der Code von Claude Code, und ein paar Agenten passen auf, dass Qualität und Geschichte nicht auseinanderlaufen. Wie das im Alltag aussieht, steht hier.

Die Idee bleibt bei mir

Was ein Spiel sein soll, steht nicht in irgendeinem Prompt, sondern im PRD und in der CLAUDE.md des Repos, dort in einem Abschnitt mit der Überschrift Intent. Da finden sich Sätze wie „Kampf ist Teil des Weges, nie das Ziel“ oder „Kein Kaufdialog öffnet sich von selbst“. Wenn Claude davon abweichen will, muss ich vorher das PRD ändern, anders geht es nicht. Jede Entscheidung, die ich im Lauf der Arbeit treffe, wandert mit Datum und Issue-Nummer in denselben Abschnitt. Die Datei ist inzwischen das, was ich bei einem menschlichen Team im Kopf des Projektleiters erwarten würde, und Claude Code liest sie bei jedem Start.

Alles andere ist Backlog, und der Backlog besteht ausschließlich aus GitHub Issues. Keine TODO-Listen in Dateien, kein Plan mit Statusspalte. Heilstätten Online hat seit dem 4. Oktober über 1500 Issues und Pull Requests gesehen, Brandenburg Jewels seit dem 23. Oktober über 400. Die meisten davon hat Claude selbst angelegt, etwa Folgefragen aus Reviews oder Dinge, die zwar aufgefallen sind, aber nicht ins aktuelle Issue gehören. Fragen, die nur ich beantworten kann, also Geschmack, Geld oder Ortskenntnis, bekommen das Label doc und werden mir gesammelt vorgelegt. An allem, was nicht daran hängt, wird in der Zwischenzeit weitergearbeitet.

Bilder aus dem eigenen MCP

Assets waren für mich als Einzelperson immer der Punkt, an dem Spieleprojekte liegen geblieben sind. Wirkmittel Studio ist mein eigener MCP-Server, technisch eine Supabase Edge Function, die Bilder mit Gemini erzeugt und dauerhaft in einem Bucket ablegt. Claude Code ruft ihn direkt auf, wenn es Steine, Schmuckbilder, Hintergründe oder Symbole braucht.

Stilanker von Brandenburg Jewels: Spielbrett mit Steinen vor einem Fließ im Abendlicht

Brandenburg Jewels, Stilanker. Jeder weitere Prompt des Landes bekommt dieses Bild als Vorlage.

Damit das nicht nach zwanzig verschiedenen Illustratoren aussieht, gibt es in Brandenburg Jewels pro Land einen Stilanker, ein Referenzbild, das ich abgenommen habe und das jeder weitere Prompt als Vorlage mitbekommt. Jedes erzeugte Bild wird mit Prompt, URL und Status in einem Asset-Index im Repo eingetragen, der Status ist abgenommen, gewählt, verworfen oder fehlt. Bevor eine Runde losgeht, sagt mir Claude, wie viele Bilder es werden sollen, und ich gebe eine Zahl frei. Die Regel kam nach dem 25. Oktober, an dem es 42 Bilder an einem Tag waren, Proben und Verworfene mitgezählt. Sound und Musik kommen aus Hedra oder sind CC0 und stehen im selben Index.

Spielstein Bernstein auf magentafarbenem Grund, Rohasset vor dem Freistellen
Jewels, Stein Bernstein. Rohasset auf Magenta, so kommt es aus dem Studio.
Kapitelkarte Beelitz mit Bockwindmühle, Spargelfeld, Stadt und Kiefernwald
Jewels, Kapitelkarte Beelitz. Der Weg führt von der Mühle bis zur Ruine.
Hintergrund Kapitel Spreewald: Fließ im Abendlicht mit Kahn, Brücke und Heuschober
Jewels, Hintergrund Spreewald. Die Mitte bleibt ruhig, dort liegt das Brett.
Porträt der Köchin Hilde aus dem Jahr 1902 mit Haube, Schürze und Kochlöffel
Heilstätten, Hilde 1902. Dialogporträt, eine Figur aus der Erzählbibel.

Agenten mit festen Rollen

Die Hauptsitzung von Claude Code plant, verteilt und prüft, gebaut wird in Subagenten, deren Rollen im Repo definiert sind: Planer, Entwickler, Reviewer, Tester, bei Heilstätten Online dazu ein Optimierer, in beiden Projekten ein Autor. Der Reviewer bekommt nie Code zu sehen, den er selbst geschrieben hat. Geht es um Sicherheit, Login, Zahlung oder Datenbank, läuft er mit einem stärkeren Modell, für den Rest reicht ein kleineres.

Mit dem Autor hatte ich nicht gerechnet. Bei Heilstätten Online pflegt er die Erzählbibel, in der Figuren, Orte und Texte stehen und der Handlungsstrang als nummerierte Liste. Wenn sich an Aufgaben, Bedingungen oder Reihenfolge etwas ändert, prüft er zuerst dagegen: ob der Schritt zu seinem Zeitpunkt überhaupt erfüllbar ist, ob der Spieler dort die Information hat, die er braucht, und ob ein Text etwas erwähnt, das an dieser Stelle noch gar keinen Sinn ergibt. Ein PR, der Dialoge oder Aufgaben anfasst, braucht deshalb seine Bestätigung zusätzlich zum Reviewer. Was am Ende im Spiel steht, entscheide weiterhin ich, er liefert Vorschläge.

Kuppelsaal der Kochküche im Jahr 1902 mit Köchinnen an Kupferkesseln

Heilstätten Online, Kochküche 1902. Die erste Epoche, die der Autor gegen die Erzählbibel prüft.

Das Sicherheitsnetz hängt woanders

In beiden Repos steht die Anweisung, möglichst ohne Rückfrage zu arbeiten, also planen, bauen, testen und reviewen, bis es fertig ist. Angehalten wird nur bei einer kurzen Liste: Abweichung vom Intent, neue Abhängigkeit mit Kosten, Deploy oder Release, Signaturschlüssel, und wenn etwas gelöscht werden soll, das noch nicht in main ist. Den Rest entscheidet Claude selbst und schreibt hinterher ans Issue, was es getan hat.

Das geht nur, weil nicht die Rückfrage absichert, sondern die Werkzeuge drumherum. Hooks lassen keinen Agenten mit roten Tests aufhören. Ein Hook lehnt --no-verify ab, ein zweiter unterbindet das Schreiben in Repo-Dateien über die Shell. Die Spiellogik liegt in einem Paket ohne DOM, ohne Math.random und ohne Uhr, und die CI verlangt dort 90 Prozent Zeilenabdeckung. Bei Heilstätten Online laufen die CI-Jobs auf zwei Docker-Containern auf meinem eigenen PC. Sogar ein Stilcheck gehört dazu, der Gedankenstriche und Emojis in Doku und Commits anmeckert.

Wo es hakt

Im Kleinen sind die Agenten verlässlich. Paketgrenzen werden eingehalten, Tests geschrieben, Reste aufgeräumt. Schwieriger wird es, sobald eine Entscheidung quer durch Spielverlauf, Karte und Erzählung läuft, da fehlt ihnen der Überblick, und genau dafür gibt es den Autor und mich. Auch die Zahl der Issues sagt etwas: Ein guter Teil davon sind Fragen, die man im Team über den Tisch in zwei Sätzen geklärt hätte.

Handgemalte Übersichtskarte der Heilstätten mit Bahnlinie, Gebäuden und Wegen

Heilstätten Online, gemalte Übersichtskarte. Entscheidungen, die hier etwas verschieben, brauchen den Überblick.

Im Store ist noch keins der beiden Spiele. Heilstätten Online spielen Freunde und Familie bereits testweise, und was dabei am meisten ankommt, ist das Multiplayer-Gefühl, wenn mehrere Leute gleichzeitig auf derselben Karte unterwegs sind. Begrenzt wird das gerade von der Infrastruktur, mit Absicht, weil ich noch nicht skalieren will. Brandenburg Jewels steht vor dem Test, den Google vor der Freigabe für die Produktion verlangt. Dort nutze ich zum ersten Mal Google Play Dienste, Erfolge und Bestenlisten, und einen Shop im Spiel. Deploy und Release passieren erst, wenn ich das Wort sage. Nach jedem Meilenstein bekomme ich ein Playtest-Paket mit Build, Neuerungen und einer Liste, was ich ausprobieren soll. Dann sitze ich mit dem Tablet auf dem Sofa und spiele. Den Teil behalte ich.


Zurück zur Übersicht