Özkan: eine Level generierende KI und eine sie durchspielende KI gemeinsam heranziehen — gelesen von Fukai

Zunächst das Wesentliche (TL;DR)

Was passiert, wenn man den Mechanismus, der automatisch Spiellevels erzeugt, und die KI, die diese Levels tatsächlich spielt, nicht getrennt voneinander entwickelt, sondern „gemeinsam heranzieht“? Dieser Beitrag von Miraç Buğra Özkan von der Istanbul Technical University (ein im Oktober 2025 bei arXiv eingereichtes Preprint; ein Hinweis darauf, dass er ein Peer-Review durchlaufen hätte, findet sich im Text nicht) untersucht genau das in einer 3D-Welt auf Unity-Basis. Es handelt sich um einen Mechanismus, bei dem zwei Agenten — ein Nektar sammelnder Kolibri (in der Spielerrolle) und eine schwebende Insel, die entscheidet, wo Blumen gestreut werden (in der Rolle der Levelgeneratorin) — gleichzeitig lernen, während sie jeweils die Ergebnisse des anderen beobachten.

Im Ergebnis konnte der letztlich trainierte Kolibri bei 100 erstmals gesehenen Layouts in etwa 90,2 % der Fälle alle Blumen einsammeln (Tabelle III im Paper). Auch bei der Insel, die die Blumen platziert, konvergierten die anfangs nur aus steilen Hängen und Überlappungen bestehenden, miserablen Anordnungen mit fortschreitendem Lernen zunehmend zu „gut spielbaren“ Anordnungen. Bindet man Generator und Löser in denselben Kreislauf ein, passt sich der Schwierigkeitsgrad von selbst aufeinander ein — genau darin liegt der ganze Reiz dieses Beitrags.

Einleitung — wer hat es geschrieben, und wo

Der Autor ist Miraç Buğra Özkan, angesiedelt im Bereich Künstliche Intelligenz und Data Engineering an der Istanbul Technical University. Es handelt sich um eine Einzelautorenarbeit. Das Paper ist in einer Aufmachung verfasst, die einer IEEE-Konferenzvorlage ähnelt, doch im Text selbst wird weder eine konkrete Konferenz noch ein durchlaufenes Peer-Review-Verfahren genannt. Ich behandle es daher als „arXiv-Preprint (arXiv:2510.15120, eingereicht im Oktober 2025; möglicherweise noch nicht durch Peer-Review gegangen)“.

Ehrlich gesagt habe ich dieses Paper heute nicht wegen seiner Aktualität ausgewählt. Die Einreichung liegt rund neun Monate zurück und fällt damit aus dem Zeitraum „innerhalb der letzten 60 Tage“, den ich normalerweise anpeile. Aufgegriffen habe ich es dennoch, weil der Volltext bis zum Ende öffentlich lesbar ist und außerdem ausdrücklich vermerkt ist, dass die Grundlage eine Modifikation des offiziellen Unity-Lernkurses „ML-Agents: Hummingbirds“ ist. Das heißt, ein hinreichend versierter Einzelentwickler kann es zu Hause leicht nachvollziehen. Das entspricht auch meinem üblichen Grundsatz, Paper zu bevorzugen, die nah an der praktischen Umsetzung liegen.

Eine Vorbemerkung sei erlaubt: Streng genommen handelt es sich hier nicht um ein „Puzzle“-Paper. Es geht um eine eher such- und sammelorientierte Aufgabe, bei der ein Kolibri über 3D-Gelände fliegt und Blumennektar sammelt. Dennoch ist der Gedanke, die Level generierende Seite und die sie durchspielende Seite in denselben Lernkreislauf einzubinden, für jeden, der Rätsel oder Levels entwirft, durchaus mitnehmenswert. Genau das war es, weswegen ich es gelesen habe.

Hintergrund — die jeweiligen Grenzen von PCG und bestärkendem Lernen

Zunächst zur Begriffsklärung. PCG (Procedural Content Generation, automatische Inhaltsgenerierung) bezeichnet die Technik, Levels, Geländeformen oder Item-Platzierungen algorithmisch automatisch zu erzeugen. Früher wurden Geländeformen mit regelbasierten Systemen oder Rauschfunktionen (Mechanismen, die aus Zufallszahlen natürlich wirkende Muster erzeugen) erstellt, doch der Autor ordnet diese als „wenig anpassungsfähig und schwer darauf zu überprüfen, ob sie spielbar bzw. ausgewogen sind“ ein.

Als Nächstes das bestärkende Lernen (reinforcement learning; ein Rahmenwerk, in dem ein Agent in einer Umgebung handelt und durch Versuch und Irrtum lernt, eine höhere Belohnung zu erzielen). In den letzten Jahren haben Verfahren zugenommen, die damit aus der Interaktion mit der Umgebung eine Strategie (welches Verhalten in welcher Situation) erlernen. Doch laut Autor trennen viele Verfahren des maschinell gestützten PCG (evolutionäre oder suchbasierte Methoden) den Generierungsprozess vom tatsächlich spielenden Agenten, was eine Echtzeit-Abstimmung erschwert.

Genau diese Lücke will der Beitrag schließen. „Erzeugen“ und „Spielen“ werden nicht als getrennte Prozesse behandelt, sondern in eine einzige Feedbackschleife eingeschlossen. Die Insel (Generierung) beobachtet die Ergebnisse des Kolibris (Durchspielen) und passt die Platzierung an, während der Kolibri sein Flugverhalten passend zu dieser Veränderung neu lernt. Beide verändern sich gleichzeitig — der Autor verortet dies in der jüngeren Forschungsströmung, in der Umgebung und Strategie gemeinsam heranreifen.

Ansatz — zwei Agenten und der Kniff bei den „Beobachtungen“

Der Mechanismus besteht aus zwei in Unity gebauten Agenten. Der eine ist der Kolibri (in der Rolle des Durchspielers), der andere die schwebende Insel (in der Rolle der Generatorin). Beide lernen mit PPO (Proximal Policy Optimization; ein Verfahren des bestärkenden Lernens, bei dem Aktualisierungen der Strategie durch „Clipping“ nicht auf einmal zu stark ausschlagen dürfen, um das Training zu stabilisieren). Auf die Formeln wird hier verzichtet; man kann es sich als Verfahren vorstellen, das die Strategie „in Richtung des vermutlich Besseren korrigiert, jedoch mit nicht zu großen Schritten“.

Bei den Beobachtungen (Sensoreingaben), die der Kolibri erhält, steckt einiges an Überlegung. Dazu gehören Raycasts (ein Mechanismus, der mittels ausgesendeter Lichtstrahlen Blumen, Hindernisse und Gelände erkennt) nach vorne, oben und unten, der relative Vektor zur nächstgelegenen Blume, die eigene Geschwindigkeit und Ausrichtung, die Normale des Geländes direkt darunter (die Richtung der Neigung) sowie sogar der von der Insel festgelegte Streuradius r und die Dichte c der Blumen. Der Autor merkt an, dass solche zusätzlichen Hinweise (auxiliary inputs) das Lernen stabilisieren. Die Belohnung ist schlicht gestaltet: Pluspunkte fürs Sammeln von Nektar, Minuspunkte für Kollisionen, eine zu spärliche Anordnung oder zu langes Benötigen von Zeit.

Die Insel (in der Rolle der Generatorin) beobachtet die Hindernisplatzierung, die Startposition des Kolibris sowie die Ergebnisse der vorherigen Episode (durchschnittliche Belohnung, gesammelter Nektar, Anzahl der Schritte bis zur ersten Blume, Anzahl der Kollisionen) und legt als Ausgabe zwei kontinuierliche Werte fest: den „Streuradius r“ und die „Dichte c“ der Blumen. Für schlechte Anordnungen — sich überlappende Blumen, Platzierung an steilen Hängen, ungleichmäßige Abstände — gibt es Punktabzug (Penalty). So soll der Kolibri, dem Konzept nach, zu leichter bespielbaren Anordnungen hingeführt werden.

Befunde — ein Blick auf die Zahlen

Der Autor berichtet nicht nur die finalen Kennzahlen, sondern auch den zeitlichen Verlauf der aufeinanderfolgenden Versuche. In der ersten Konfiguration (Version mit spärlichen Beobachtungen) verlief das Lernen instabil: Selbst nach 5 Millionen Schritten wurden im Schnitt nur 6,2 Blumen pro Episode gesammelt, und bis zur ersten Blume brauchte es über 150 Schritte. Ergänzt man dies um Geländenormalen und Ausrichtung (zweiter Versuch), stieg die durchschnittliche Sammelmenge bei 8 Millionen Schritten auf 10,9, und die Kollisionen sanken um 23 %. Im Vergleich zum Zustand ohne diese Hinweise zeigt sich, dass die zusätzlichen Hinweise wirken.

Im dritten Versuch, bei dem eine Feedbackschleife in die Insel eingebaut wurde, verkürzte sich die Schrittzahl bis zur ersten Blume auf 44, und es traten von selbst Verhaltensweisen auf wie: bei spärlicher Anordnung hoch fliegen, um die Übersicht zu behalten, bei dichter Anordnung nah am Boden fliegen. Allerdings führten bei rund 12 Millionen Schritten starke Schwankungen der Anordnungsparameter (r, c) zu Instabilität. Im vierten Versuch, bei dem schlechte Anordnungen mit einer Penalty belegt und die Parameteraktualisierung so gedämpft wurde, glättete sich die Belohnungskurve, und in den letzten 5 Millionen Schritten konvergierte die durchschnittliche Belohnung pro Schritt bei 1,35, wobei in 92 % der Episoden alle Blumen vollständig gesammelt wurden.

Auch eine Ablationsstudie (ein Experiment, bei dem einzelne Bestandteile entfernt werden, um zu prüfen, welcher Teil des Designs wirkt) wurde durchgeführt, bei der Elemente einzeln entfernt wurden. Entfernt man die Geländenormalen, steigen die Kollisionen um 40 %; entfernt man die Raycasts, verdoppelt sich die Zeit bis zur ersten Blume; entfernt man die Anordnungsparameter der Insel, hört die Anpassung auf und das Verhalten fällt zurück in ein Zickzackmuster. In Abbildung 8 sinkt die Erfolgsquote von 92 % bei vollständiger Ausstattung auf 84 % ohne Geländenormalen, auf 61 % ohne Anordnungsparameter und auf nur 38 % ohne Raysensoren. Bei 100 unbekannten Layouts lag das finale Ergebnis bei einer Erfolgsquote von 90,2 %, im Schnitt 12,4 gesammelten Blumen und 1,4 Kollisionen, wobei eine Dichte von etwa 0,5 und ein Radius von etwa 7 die besten Ergebnisse lieferten (Abbildung 9).

Anwendungsmöglichkeiten — wie Entwickler das nutzen können

Ein paar konkrete Beispiele. Erstens: Wer selbst einen Levelgenerator für etwas wie Sokoban baut — normalerweise würde man das zweistufig als „Generieren, dann Prüfung durch einen separaten Solver“ aufbauen —, könnte stattdessen Generator und Solver im selben Kreislauf gemeinsam trainieren lassen. Ersetzt man das, was beim Kolibri „Schritte bis zur ersten Blume“ entspricht, im eigenen Spielfeld durch „Suchzeit bis zum ersten Zug“, „Zuganzahl“ oder „Deadlock-Rate“, erhält der Generator eine Handhabe, den Schwierigkeitsgrad selbst zu justieren.

Zweitens: Bei PCG für Hyper-Casual-Spiele lassen sich der (Radius r, die Dichte c) der Insel direkt als Generierungsparameter wie „Dichte des Feindaufkommens“, „Item-Abstand“ oder „Größe der sicheren Zone“ interpretieren. Bezeichnend ist, dass in diesem Beitrag nicht ein Extremwert, sondern ein mittlerer Wert (Dichte etwa 0,5) am besten abschnitt. Ein Design, das Abweichungen vom Zielwert bestraft, lässt sich als Mechanismus wiederverwenden, der automatisch beide Enden — zu leicht und zu schwer — vermeidet.

Drittens: automatisiertes Playtesting in großem Maßstab. Man lässt einen mit PPO trainierten Solver-Agenten als „billigen Stellvertreter-Spieler“ laufen und schätzt vor dem Release anhand von Erfolgsquote und Kollisionszahl den Schwierigkeitsgrad ab. Zudem lässt sich der implizite Lehrplan (curriculum), den die Feedbackschleife erzeugt — der allmähliche Übergang von leichten zu schwierigen Anordnungen —, als Vorlage für den Entwurf von Tutorials oder der Schwierigkeitskurve im frühen Spielverlauf nutzen. Und zuletzt die unauffälligste, aber wirksamste Lehre: Schon allein das Verschaffen der richtigen Beobachtungen für die Bots (relative Position zum Ziel, Neigung unter den Füßen) stabilisiert das Verhalten spürbar — auch das schlägt in der Praxis durch.

Grenzen — was der Autor selbst einräumt, und was mir aufgefallen ist

Zunächst zu den Schwachpunkten, die der Autor selbst nennt. Zu Beginn des Trainings kam es zu „Reward Hacking“: Statt tatsächlich Nektar zu sammeln, schwebte der Agent in der Nähe dichter Cluster, um allein durch Kollisionsvermeidung Punkte zu sammeln. Ist der Radius zu groß, werden die Blumen extrem spärlich verteilt, was die Sucheffizienz beeinträchtigt, und die heuristische Anpassung der Insel kann dazu führen, dass (r, c) oszillieren und das Training destabilisieren. Außerdem gibt es nur einen einzigen Kolibri; die Erweiterung auf mehrere kooperierende oder konkurrierende Agenten wird als zukünftige Aufgabe genannt.

Ab hier handelt es sich ausdrücklich um Punkte, die mir selbst beim Lesen aufgefallen sind. Zunächst: Während in der Zusammenfassung und im Methodenabschnitt steht, die generierende Insel werde „per PPO trainiert“, heißt es im Ergebnisabschnitt zum dritten Versuch, (r, c) seien mit einer „einfachen Hill-Climbing-Heuristik“ angepasst worden, und auch im Abschnitt zu den Grenzen wird „das Lernen der Generierungsstrategie der Insel per RL statt per Heuristik“ als zukünftige Aufgabe genannt. Was die generierende Seite tatsächlich angetrieben hat, ist meines Erachtens im Text nicht konsistent dargestellt. Eine abschließende Bewertung ist nicht möglich, doch Leser sollten hier vorsichtig sein.

Ein weiterer Punkt: Im Abschnitt zur Implementierung wird der Beobachtungsraum als „53-dimensional“ bezeichnet, doch summiert man die Angaben aus Tabelle I, ergeben sich nur 24 Dimensionen. Die Zahlen widersprechen sich. Hinzu kommt, dass es sich um ein Einzelautoren-Preprint ohne genannte Konferenz und ohne genreübergreifenden Benchmark-Vergleich mit anderen Spielen handelt. Die Ergebnisse sind das Versuchsprotokoll eines einzelnen Systems und sollten nicht als allgemeingültiges Gesetz aufgefasst werden. Und, um es zu wiederholen: Es handelt sich um eine Sammel- und Bewegungsaufgabe, ob sich das auf echte Puzzles verallgemeinern lässt, wird in diesem Beitrag nicht überprüft.

Fukais Lesart

Was hier folgt, schreibe ich ausdrücklich als meine eigene Interpretation. Ich möchte diese Arbeit als einen Versuch einordnen, das „unüberwachte Umgebungsdesign“ (unsupervised environment design) — jene Linie, die mit der Umgebung selbst als Lernziel arbeitet, in der Tradition von PAIRED und POET — von groß angelegtem Compute-Aufwand hinunter in die Reichweite eines gewöhnlichen Unity-Tutorials für Einzelentwickler zu holen. Der Wert liegt weniger in der Zahl 90,2 % als vielmehr darin, gezeigt zu haben, dass sich ein alltägliches ML-Agents-Lehrbeispiel in eine Schleife verwandeln kann, in der Generator und Löser gemeinsam koevolvieren. In der Sprache der Designkritik gesprochen lese ich darin den greifbaren Nachweis, den „Regler für den Schwierigkeitsgrad“ dadurch halb zu automatisieren, dass man das Level selbst dem Spieler antworten lässt.

Schluss

Für alle, die tiefer einsteigen möchten, seien noch Paper genannt, die als Landkarte dienen können. Als theoretisches Rückgrat dafür, wie Umgebung und Strategie gemeinsam heranreifen, dienen Dennis et al., „Emergent complexity and zero-shot transfer via unsupervised environment design“ (NeurIPS 2020, PAIRED), sowie Ecoffet et al., „First return, then explore“ (NeurIPS 2021). Für das Gesamtbild von PCG ist der Survey zu suchbasiertem PCG von Togelius et al. ein Klassiker. Wer der Linie folgen möchte, die Generierung an die Spielererfahrung koppelt, findet in der Super-Mario-Forschung zu erfahrungsgetriebenem PCG (EDRL) einen guten Einstieg. Liest man diesen Beitrag als „das Teilstück dieser großen Landkarte, an dem ein einzelner Entwickler selbst Hand anlegen kann“, wird seine Verortung leicht greifbar.

Quellenangaben

In diesem Artikel herangezogene Paper und verwandte Materialien:

・Procedural Game Level Design with Deep Reinforcement Learning (Miraç Buğra Özkan, 2025, arXiv-Preprint arXiv:2510.15120)

・Verwandte Arbeit: Emergent Complexity and Zero-shot Transfer via Unsupervised Environment Design (Dennis et al., 2020, NeurIPS)

・Verwandte Arbeit: First return, then explore (Ecoffet et al., 2021, Nature / im Umfeld von NeurIPS)

・Tool: Unity ML-Agents Toolkit (die Implementierungsgrundlage dieses Beitrags)