Ein eigenes Pokémon generieren: Ein Forschungsprototyp im Spiel

Überblick

Ich habe einen Forschungsprototyp entwickelt, der aus sechs während des Spiels ausgewählten Wörtern eine neue Pokémon-Art erzeugt. Wenige Minuten später erscheint sie im hohen Gras, wo die spielende Person ihr begegnen, sie fangen und ihr einen Spitznamen geben kann. Der Prototyp generiert Aussehen, Namen, Typ, Basiswerte, Attacken und die Daten, die für die Einbindung ins Spiel benötigt werden.

Der Prototyp verbindet Gespräche im Spiel, Wortauswahl, Generierung im Hintergrund, Begegnung mit wilden Pokémon, Fang und Namensvergabe, ohne das Spiel anzuhalten. Jede erzeugte Art wird in einer Form registriert, die die bestehenden Spielsysteme verwenden können.

Mein Schwerpunkt lag auf dem Rahmen für die Generierung, nicht auf dem Modell selbst: Ich definierte Anforderungen, die Spielbalance und visuelle Einheitlichkeit bewahren, und ließ die KI innerhalb dieser Grenzen nach Lösungen suchen. Außerdem spielte ich den Prototyp selbst, um vorläufig einzuschätzen, ob ein einzigartiger Charakter allein ausreicht, um eine Bindung entstehen zu lassen.

Fragestellung: Entsteht durch Einzigartigkeit eine Bindung?

In Spielen können Menschen Charaktere auswählen, entwickeln und benennen, bis sie sich ganz wie ihre eigenen anfühlen. Ausgangspunkt ist jedoch weiterhin eine Auswahl, die von den Entwickelnden vorbereitet wurde. Würde eine stärkere Bindung entstehen, wenn generative KI es erlaubte, einen Charakter von Beginn an mitzugestalten?

Ein generiertes Bild allein reicht nicht aus, um diese Frage zu untersuchen. Der Charakter muss in der Spielwelt erscheinen, eine Begegnung und einen Fang ermöglichen und danach weiter spielbar bleiben. Ich erstellte zwei Wege mit unterschiedlicher Beteiligung: Das Gespräch mit dem alten Mann löst eine Generierung ohne Eingabe aus; beim Gespräch mit der alten Frau kann die spielende Person sechs Wörter wählen. Welche Figur zuerst angesprochen wird, bestimmt die Generierungsart für diesen Spieldurchlauf.

Der Prototyp erlaubt keine abschließende Aussage über Bindung. Sein Zweck ist, generierte Inhalte in den normalen Spielablauf einzubinden und Bedingungen für spätere Vergleiche zu bestimmen.

Spielablauf

Die folgende Sequenz zeigt den Weg mit eigener Wortauswahl. Im Blütenburgwald spricht die spielende Person eine alte Frau an und wählt sechs Wörter aus dem bestehenden Easy-Chat-Wortschatz des Spiels. Während sie weiterspielt, läuft die Generierung im Hintergrund. Ein Ruf signalisiert, dass die neue Art bereit ist. Das Betreten des hohen Grases löst eine Begegnung aus, und das Pokémon lässt sich mit der gewohnten Bedienung fangen. Jede Generierung liefert einen Namen, einen Typ, Basiswerte, Attacken, Kampf-Sprites für Vorder- und Rückansicht sowie ein Team-Symbol. Das Demovideo zeigt den vollständigen Ablauf.

Gestaltungsaufgabe: Generierte Charaktere spielbar halten

Einen neuen Charakter zu erzeugen und ihn in einem Spiel funktionsfähig zu machen sind unterschiedliche Herausforderungen. Zu hohe Werte können die Schwierigkeitsbalance stören; nicht zusammenpassende Typen und Attacken können das Training erschweren. Ein zu komplexer Entwurf kann bei der Reduktion auf ein Sprite von 64 × 64 Pixeln unkenntlich werden.

Wäre jedes Detail festgelegt, ginge der Sinn verloren, jedes Mal ein anderes Ergebnis zu generieren. Ich musste unterscheiden, welche Elemente für den Spielablauf unerlässlich sind und welche variieren dürfen.

Deshalb konzentrierte ich mich darauf, den Möglichkeitsraum für Pokémon zu gestalten, statt einen einzelnen Charakter zu entwerfen. Menschen bestimmen Ziele, Constraints, unzulässige Inhalte und Prüfverfahren; die KI entwickelt innerhalb dieses Rahmens Vorschläge. Dieser funktionsfähige Prototyp setzt meinen Ansatz des constraintbasierten Designs in die Praxis um.

Ansatz: Bedingungen für die Generierung festlegen

Das System fordert ein großes Sprachmodell (LLM) auf, vorgegebene Felder wie Name, Typ, Basiswerte, Attacken, Körperform und Farbe auszufüllen, statt frei formulierten Text zu schreiben. Eine Validierungsinstanz prüft jede Antwort, bevor sie übernommen wird. Verstößt eine Antwort gegen eine Regel, meldet das System den konkreten Verstoß zurück und fordert so lange eine erneute Generierung an, bis die Anforderungen erfüllt sind.

1. Menschen setzen die Grenzen. Anforderungen an Spielbalance, erkennbare Sprites und zulässige Inhalte werden zu expliziten, überprüfbaren Regeln.
2. Die KI entwickelt Vorschläge. Das Modell schlägt anhand der gewählten Wörter Werte für die erlaubten Felder vor.
3. Das System prüft die Ausgabe anhand der Regeln. Zahlenbereiche, Attackenkombinationen und unzulässige Inhalte werden automatisch kontrolliert.
4. Die Rückmeldung bezieht sich nur auf Regelverstöße. Ein regelwidriger Vorschlag wird mit einer Begründung zurückgegeben und erneut generiert.

Constraints zum Erhalt der Spielbarkeit. Die Summe der Basiswerte legte ich auf 280–360 fest, mit Ober- und Untergrenzen für jeden einzelnen Wert. Die Attacken wurden aus dem Quellcode des Spiels entnommen und auf solche begrenzt, die zum Typ der Art passen oder dem Typ Normal angehören. Sofort-K.-o.-Attacken, selbstzerstörerische Attacken, Attacken mit festem Schaden und übermäßig starke Attacken wurden ausgeschlossen. Die Validierung prüfte außerdem die Anzahl offensiver Attacken und ob typgleiche Attacken vorhanden waren. Fangrate, Wachstumsrate und weitere Faktoren wurden festgelegt, um die generierten Unterschiede in einem für Vergleiche geeigneten Bereich zu halten.

Constraints für visuelle Erkennbarkeit. Die Körperformen stammen aus einer Auswahl mit Silhouetten, die auch bei kleinen Sprites erkennbar bleiben. Auch der Wortschatz für Farben und Merkmale ist eingeschränkt. Menschenähnliche Merkmale, Blut, Waffen und Text sind ausgeschlossen. Die Bildgenerierungsanweisungen enthalten stets Vorgaben wie „nur ein Wesen“, „den ganzen Körper zeigen“ und „keine zusätzlichen Gliedmaßen“.

In einem dokumentierten Durchlauf schlug das Modell zunächst eine Basiswertsumme von 380 vor. Die Validierung erkannte den Verstoß und verlangte eine erneute Generierung, die schließlich eine Spezifikation mit einer Summe von 320 ergab. Der Beitrag lag in einem Prozess, der Ausgaben außerhalb der definierten Constraints zurückweist, statt auf einen zufällig gelungenen Vorschlag zu vertrauen.

Das Erlebnis im Spiel halten

Die spielende Person nutzt ausschließlich Gespräche im Spiel, Wortauswahl und Begegnungen im Gras; eine separate Generierungsansicht gibt es nicht. Rechenintensive Arbeit läuft in einem Python-Prozess auf dem PC, der über Dateien Daten mit dem Spiel austauscht. Lua-Skripte im mGBA-Emulator verbinden beide Seiten. So bleibt die vertraute Spielbedienung erhalten, während die KI-Verarbeitung außerhalb des Spiels stattfindet.

1. Spezifikation generieren. Ein lokales Sprachmodell übersetzt die sechs Wörter in Artendaten, die vor ihrer Verwendung geprüft werden.
2. Grafiken generieren. Ein Bildmodell erzeugt eine Referenzillustration und anschließend visuell einheitliche Sprites für Vorder- und Rückansicht sowie ein Team-Symbol.
3. In Spieldaten umwandeln. Die Bilder werden auf 15 Farben reduziert und anschließend in Sprites und Paletten umgewandelt und komprimiert, die mit dem Game Boy Advance (GBA) kompatibel sind.
4. In das laufende Spiel integrieren. Die Daten werden in einen reservierten Bereich geschrieben, sodass die neue Art ohne Neustart ins Spiel gelangt.

Dieselben Daten werden auch auf dem Datenträger gespeichert, damit die generierte Art beim erneuten Laden des Spiels erhalten bleibt. Die Generierung findet nur einmal statt und lässt sich nicht rückgängig machen. Flieht die spielende Person oder verliert sie die Begegnung, bleibt das Pokémon in der Welt. Besiegt sie es, erscheint es nie wieder. Diese Unumkehrbarkeit macht „nur eines in diesem Spieldurchlauf“ zu einem Teil des Erlebnisses.

Was der Prototyp bestätigt hat

Ich habe diesen Prototyp allein entwickelt, um die technische Machbarkeit zu prüfen. Er ist weder ein fertiges Spiel noch eine Nutzerstudie. Im Folgenden unterscheide ich, was ich überprüft und implementiert habe und was noch ungetestet ist.

• Durchgängig überprüft. In mGBA bestätigte ich die vollständige Abfolge vom Gespräch im Spiel und der Eingabe von sechs Wörtern über die Generierung im Hintergrund und die Einbindung ins laufende Spiel bis zur Begegnung, zum Fang und zur Vergabe eines Spitznamens.
• Für künftige Vergleiche implementiert. Ich ergänzte zwei Einstiege: passive Generierung ohne Eingabe und Generierung mit eigener Wortauswahl. Gespräche, Begegnungen und Fänge können für Vergleiche protokolliert werden.
• Mit bestehenden Systemen verbunden, aber nicht über längeres Spielen geprüft. Levelaufstieg nach dem Fang, Erlernen von Attacken, Kämpfe, Lagerung in Boxen und weitere Nutzung nach dem Speichern sind in die bestehenden Spielsysteme eingebunden. Ich habe sie nicht in langen Spielsitzungen getestet.
• Künftige Arbeit. Die Generierung von Entwicklungsformen während des Spiels ist noch nicht implementiert. Vergleichende Studien zur Bindung mit mehreren Teilnehmenden wurden noch nicht durchgeführt.

Meine Erfahrung beim Spielen: Einzigartigkeit allein erzeugte bei mir keine Bindung

Beim eigenen Spielen des Prototyps entstand bei mir keine starke Bindung an das generierte Pokémon. Das ist mein persönlicher Eindruck als Entwickler und kein Ergebnis, das sich auf andere Spielende verallgemeinern lässt. Er gab jedoch Hinweise darauf, was in einem künftigen Vergleich variiert werden könnte.

Zwei Faktoren erschienen mir untersuchenswert.

• Qualität des Ergebnisses. Wenn Aussehen und Charakterkonzept nicht ansprechend genug sind, reicht es möglicherweise nicht aus, „das einzige in diesem Spieldurchlauf“ zu sein, um eine Bindung aufrechtzuerhalten.
• Tiefe der Beteiligung. Durch die Auswahl von sechs Wörtern wirkte das Ergebnis auf mich eher wie etwas, das mir geliefert wurde, als wie etwas, das ich selbst geschaffen hatte. Ich vermute, dass Beteiligung von der Qualität des kreativen Prozesses abhängt: Entscheidungen überdenken, Alternativen vergleichen, Details überarbeiten und Verantwortung für das Ergebnis übernehmen, statt lediglich mehr Eingaben zu machen.

Dagegen empfinde ich eine Bindung an Hanagitsune, einen Charakter, den ich außerhalb der automatisierten Spielpipeline durch wiederholte Gespräche mit mehreren generativen KI-Werkzeugen und manuelle Überarbeitung geschaffen habe. Ich verglich Entwürfe, korrigierte Details und arbeitete weiter, bis ich zufrieden war. Meiner Einschätzung nach trugen sowohl die Qualität des Ergebnisses als auch meine Beteiligung am iterativen Prozess zu dieser Bindung bei.

Dieser Prototyp beantwortet nicht, ob generierte Inhalte eine Bindung erzeugen. Er übersetzt die breite Fragestellung in zwei gezielt veränderbare Faktoren: Ergebnisqualität und Beteiligungstiefe. Eine künftige Studie würde während der Gestaltung Möglichkeiten zum Auswählen, Vergleichen und Überarbeiten ergänzen, die Ergebnisse auf ein einheitliches Qualitätsniveau bringen und die Erfahrungen mehrerer Teilnehmender vergleichen.

Implementierung

Die Generierungspipeline, das Constraint- und Validierungsverfahren, die Umwandlung in GBA-Daten und die spielseitigen Änderungen sind im GitHub-Repository veröffentlicht.