Nasir u. a.: die „Regeln selbst" eines Spiels evolvieren lassen — Fukai liest MORTAR

Zusammenfassung in einem Absatz

Können die „Mechaniken" eines Spiels — also die grundlegenden Regeln, die Spieleraktionen und ihre Konsequenzen bestimmen — automatisch entworfen werden? Diese Forschungsarbeit geht der Frage direkt nach. Die meisten Arbeiten zur automatischen Generierung konzentrieren sich auf Level- oder Terraingenerierung; Versuche, die Mechaniken selbst zu erzeugen und zu bewerten, sind selten. MORTAR, das System der Autoren, behandelt jede Mechanik als Python-Codefragment und lässt ein großes Sprachmodell (LLM — eine KI, die auf riesigen Textmengen trainiert wurde und Fortsetzungen oder Antworten generieren kann) diese schrittweise umschreiben, während gute Ergebnisse gesammelt und verbreitet werden.

Der Schlüssel liegt in der Überzeugung: „Der Wert einer Mechanik lässt sich nicht isoliert beurteilen — er erschließt sich erst beim tatsächlichen Spielen." MORTAR baut jede neue Mechanik in ein vollständiges Spiel ein, lässt es von 5 KI-Spielern unterschiedlicher Stärke spielen und misst die Qualität daran, ob „der stärkere Spieler tatsächlich gewinnt". Ein Forschungsprototyp, der mit GPT-4o-mini läuft und laut Autoren pro Lauf etwa 30–50 Dollar kostet. Der vorliegende Artikel schlüsselt „Was", „Wie" und „Was wurde herausgefunden" der Reihe nach auf, damit das Wesentliche ohne Öffnen der Publikation erfassbar ist.

Einleitung

Der heute vorgestellte Artikel trägt den Titel „MORTAR: Evolving Mechanics for Automatic Game Design". Die Autoren sind Muhammad U. Nasir, Yuchen Li, Steven James und Julian Togelius von der University of the Witwatersrand (Südafrika) und der New York University. Julian Togelius ist ein Forscher, der das Gebiet der prozeduralen Inhaltsgenerierung (PCG) und der Spiele-KI seit Jahren prägt — sein Name taucht auf jeder Landkarte dieses Feldes auf. Der vorliegende Text ist ein im Januar 2026 auf arXiv veröffentlichtes Preprint (arXiv:2601.00105; da eine bestandene Peer-Review zum Zeitpunkt der Abfassung nicht bestätigt werden konnte, wird es hier als Preprint behandelt).

Der Grund, warum ich diesen Artikel heute ausgewählt habe: Er steht für den Moment, in dem die Diskussion über automatische Generierung von „Levels" zu „den Regeln selbst" vorgedrungen ist — und das hat meines Erachtens viel zu bieten für alle, die Spiele machen. Levelgenerierung verfügt über eine reichhaltige Vorläuferliteratur; doch sobald es darum geht, Mechaniken — etwa „Schlüssel aufheben öffnet eine Tür" oder „Gegner berühren stößt zurück" — von Grund auf maschinell zu erzeugen, steigt der Bewertungsaufwand sprunghaft. Die Autoren stellen sich dieser Herausforderung. Der Artikel erwähnt zudem, dass die generierten Spiele auf einer von den Autoren veröffentlichten Webseite tatsächlich gespielt werden können.

Hintergrund

PCG (Procedural Content Generation — prozedurale Inhaltsgenerierung) ist ein seit Langem erforschtes Gebiet mit vielfältigen Anwendungen: Laufzeitgenerierung in Roguelikes, Unterstützung der kreativen Ideenfindung von Designern, Automatisierung repetitiver Aufgaben. Die Aufmerksamkeit richtete sich jedoch größtenteils auf die „Struktur" von Gelände und Levels, deren Qualität sich anhand von „Lösbarkeit" und „Neuartigkeit" vergleichsweise leicht messen lässt.

Die automatische Generierung von Mechaniken — den Interaktionsregeln eines Spiels — hat dagegen verhältnismäßig wenig Beachtung gefunden. Was die Autoren betonen: Der Wert einer Mechanik tritt erst in der „Dynamik des Spiels, das sie erzeugt" zutage. Eine äußerlich neuartige und komplexe Mechanik kann langweilig sein, wenn sie kein Spielgeschehen erzeugt, das Leistungsunterschiede sichtbar macht. Deshalb ist nicht nur die Generierung, sondern vor allem die Konzeption der „Bewertung" die eigentlich schwierige Aufgabe — das ist der Ausgangspunkt.

Die Bedeutung dieser Frage liegt darin, dass Mechaniken das Skelett der Spielerfahrung bestimmen. Sie beeinflussen nicht nur, was man tun kann, sondern auch, welche Strategien und emergenten Verhaltensweisen möglich werden. Lässt sich dies automatisieren, könnte daraus ein Werkzeug entstehen, das die Kreativität von Designern erweitert — die Autoren positionieren es jedoch ausdrücklich nicht als Mittel zur vollständigen Spielerstellung, sondern als Unterstützung, nicht als Ersatz von Designern.

Ansatz

MORTAR basiert auf einem Qualitäts-Diversitäts-Algorithmus (Quality-Diversity — ein Suchrahmen, der nicht eine einzige beste Lösung sucht, sondern gleichmäßig gute Lösungen mit unterschiedlichen Eigenschaften sammelt), konkret der Methode MAP-Elites. Jede Mechanik wird als Python-Funktion dargestellt und entlang zweier „Regalachsen" eingeordnet: dem Mechanikentyp (9 Kategorien: Bewegung, Interaktion, Kampf, Fortschritt, Umgebung, Denkrätsel, Ressourcenmanagement, Erkundung, Zeitmanipulation) und der Code-Komplexität (geschätzt durch Analyse der Programmstruktur anhand von Funktionsaufrufen und Zuweisungen). In jedes Feld des aus diesen Achsen gebildeten Rasters wird eine hochwertige Mechanik eingetragen.

Neue Mechaniken werden erzeugt, indem das LLM bestehende umschreibt. „Mutation" (Hinzufügen von Funktionen zu einer bestehenden Mechanik), „Diversifikationsmutation" (drei werden gezeigt, eine stilistisch abweichende soll erzeugt werden), „Kreuzung" (zwei werden gemischt), „Kompatibilitätsmutation" (eine zum bestehenden Spiel passende soll erzeugt werden) — all diese Operationen der evolutionären Berechnung (Methode, die Lösungen durch Wiederholung von Mutation und Selektion verbessert, nach dem Vorbild biologischer Evolution) werden vom LLM als tatsächliche Code-Editierung ausgeführt. Der erzeugte Code wird zunächst auf Syntax- und Laufzeitfehler geprüft, dann in einer einfachen Testumgebung von einer MCTS-KI (Monte-Carlo-Baumsuche — Suchtechnik, die durch massenhaftes Ausprobieren zukünftiger Züge gute Züge auswählt) erkundet, um zu prüfen, ob er funktioniert und nicht trivial ist.

Die zentrale „Bewertung" verläuft so: Mit einer Mechanik als Wurzel wird durch Baumsuche ein vollständiges Spiel zusammengestellt, indem weitere Mechaniken hinzugefügt werden. Dieses Spiel wird von 5 KIs unterschiedlicher Stärke gespielt — 3 MCTS mit jeweils 100.000, 10.000 und 1.000 Simulationen, einem Zufallsagenten und einem passiven Agenten — und mithilfe der Rangkorrelation (Kennzahl für die Übereinstimmung zweier Rangreihen) quantifiziert, wie stark „erwartete Stärkereihenfolge" und „tatsächliche Gewinnraten-Reihenfolge" übereinstimmen. Je stabiler diese Ordnung aufrechterhalten wird, desto „tiefer" und „fähigkeitsbewertend" gilt das Spiel. Die genaue Formel sei hier ausgelassen; der Kern ist, „Entsprechen die Ergebnisse der Kompetenz?" als Ersatzindikator für Qualität zu verwenden.

Zusätzlich führen die Autoren den Indikator CITS (Constrained Importance Through Search) ein. Er schätzt, wie stark jede Mechanik zur Qualität des fertigen Spiels beiträgt — inspiriert vom „Shapley-Wert" der kooperativen Spieltheorie (Konzept zur fairen Verteilung aller Beiträge). Diese Berechnung würde normalerweise in eine kombinatorische Explosion münden; MORTAR macht sie handhabbar, indem die Annäherung nur innerhalb des während der Generierung aufgebauten Suchbaums erfolgt. So lässt sich im Nachhinein zeigen, welche Regel das Interesse erzeugte.

Ergebnisse

Die Autoren verglichen den Baumsuche-basierten Aufbau — das Herzstück der Bewertung — mit anderen Auswahlmethoden (zufällig, per LLM, gierig nach bester Leistung). Laut Tabelle 1 des Artikels erzielt MORTAR die besten Werte beim Diversitätsindikator (QD-Score 31,18), beim maximalen (Max CITS 0,59) und mittleren (Mean CITS 0,20) Mechanikenbeitrag sowie bei der Anzahl besetzter Felder (155). Lediglich beim „Anteil spielbar gewordener Spiele" liegt die gierige Methode knapp vorn (18,24 gegenüber 16,97 für MORTAR); die Autoren sehen darin eine Tendenz, nach der Mechaniken mit besserer Leistung häufiger spielbare Spiele ergeben.

Die Einzelbeispiele sind aufschlussreich. AllyCraft, ein generiertes Spiel, weist eine hohe Rangkorrelation von 0,8 auf und verfügt über eine mehrstrangige Strategie mit Verbündeten und der Kontrolle mehrerer Einheiten — die Tiefe bleibt erhalten. TreasureHunt bleibt bei 0,4; die Autoren erklären dies damit, dass „der Spielwert sinkt, sobald man den optimalen Weg einmal gefunden hat". Je höher die Rangkorrelation, desto mehr koexistieren wirksame Strategien, und desto weniger wird das Spiel langweilig — ein klarer Kontrast.

Auch eine Bewertung durch Menschen wurde durchgeführt. 10 Teilnehmer spielten 6 Spiele in 3 Paaren und verglichen sie anhand der Kriterien „spaßig, neu, angenehm, verständlich, frustrierend". Gesamtnote und Rangkorrelation wiesen überwiegend in dieselbe Richtung, doch das 3. Paar zeigte eine umgekehrte Tendenz; die Autoren erkennen selbst die Schwierigkeit an, den automatischen Indikator und menschliche Präferenzen in Einklang zu bringen. Im 2. Paar war die Zahl der „gleichgültig"-Stimmen hoch (7 Stimmen); die Autoren interpretieren dies als Anzeichen „zu großer Komplexität, die das Erkennen eines Sinns erschwert", und schlussfolgern, dass Mini-Spiele angemessene, nicht maximale Komplexität benötigen.

Einsatzmöglichkeiten

Wie können Spiel- und Puzzle-Entwickler diese Forschung nutzen? Einige konkrete Beispiele. Erstens: „Ideenfindung" für Mechaniken. Stecke ich bei einem kleinen Puzzle-Projekt fest, könnte ich die bestehenden Regeln als Ausgangspunkt an ein MORTAR-artiges System übergeben und per Kompatibilitätsmutation massenhaft „Kandidaten für neue, zum System passende Regeln" erzeugen lassen — nicht als fertige Produkte, sondern als Material, aus dem ein Mensch auswählt.

Zweitens: automatische Prüfung, ob „Kompetenz belohnt wird". Die Bewertungsmethode dieses Artikels — KIs unterschiedlicher Stärke spielen lassen und prüfen, ob die Reihenfolge stabil bleibt — lässt sich unabhängig von der Mechanikerzeugung weiterverwenden. Wer ein Sokoban-like entwickelt, kann mehrere Solver mit unterschiedlichem Nachgeben-Niveau vorbereiten und als einfache „Tiefenmessung" laufen lassen: Level, bei denen die Reihenfolge zusammenbricht, sind vermutlich durch Zufall oder Brute-Force lösbar.

Drittens: Herausarbeiten, „welche Regel wirkt". Die CITS-Idee — das Interesse am fertigen Spiel auf Beiträge einzelner Regeln zu verteilen — ist beim Feintuning von Spielen nützlich, in denen mehrere Mechanismen ineinandergreifen. Wer in einem Hyper-Casual-Spiel mehrere Gimmicks mischt, kann in Anlehnung an eine Ablation (Experiment, bei dem Designkomponenten einzeln entfernt werden, um zu ermitteln, welche wirken) Gimmicks nacheinander entfernen und Indikatorveränderungen beobachten, um gering beitragende Gimmicks zu streichen.

Viertens bietet das Forschungsfeld für Forscher des Reinforcement Learning (Bestärkendes Lernen — Rahmen, in dem Agenten durch Versuch und Irrtum Handlungen mit hoher Belohnung erlernen) einen vielfältigen Spielkorpus, in dem Kompetenzunterschiede messbar sind — als Testfeld für die Generalisierung der Agenten (Fähigkeit, mit unbekannten Situationen umzugehen), wie die Autoren prognostizieren. Nicht nur für Entwickler, sondern auch für KI-Trainer nützlich — diese Dualität ist das Besondere an dieser Forschung.

Grenzen

Die Grenzen werden offen benannt. Was die Autoren selbst als Erstes nennen, ist die visuelle Armut. Das Rendering ist auf ein Minimum reduziert, ohne Animation und mit nur wenigen Sprites (Charaktergrafiken). Auch die Teilnehmer der Nutzerbewertung wiesen wiederholt auf die visuelle Dürftigkeit hin, wie der Artikel festhält. Ferner ist das verwendete LLM das vergleichsweise kleine GPT-4o-mini — ein leistungsfähigeres Modell könnte ausgefeiltere Mechaniken und Code produzieren. Zudem schränkt das 2D-Vogelperspektive-Setting den Erkundungsraum ein, und die Wahl der Rasterinitialisierung sowie die Anzahl der Baumsuche-Iterationen stellen einen Kompromiss zwischen Qualität und Rechenaufwand dar. Am wichtigsten: Es gibt noch keinen Mechanismus, der es dem Designer erlaubt, die Suche zu lenken.

Was Fukai hier anmerkt, ist die Verzerrung des Bewertungsindikators selbst. Die Idee, „gewinnt die stärkste KI wirklich?" als Ersatzindikator zu verwenden, ist klar — aber sie begünstigt auch Spiele mit Wettbewerbscharakter, in denen Leistungsunterschiede sichtbar werden. Spiele, die auf narrativer Erfahrung oder Atmosphäre beruhen, oder Erlebnisse des Typs „es ist egal, wer spielt, das Ende ist dasselbe", könnten bei diesem Indikator niedrig abschneiden. Die Divergenz zwischen automatischem Indikator und menschlicher Präferenz im 3. Paar der Nutzerbewertung könnte eben diese Grenze markieren.

Ein weiterer Punkt, der mich beschäftigt, ist der kleine Maßstab: 10 Personen, 6 Spiele — die Autoren selbst schreiben „small". Auch wenn über 5 Läufe gemittelt wurde, bedarf die Verallgemeinerung der Schlussfolgerungen weiterer Überprüfung. Zudem handelt es sich um ein arXiv-Preprint, und zum Zeitpunkt der Abfassung konnten keine Spuren einer breiten Diskussion gefunden werden — es ist angemessen, es als neuen, noch nicht eingehend bewerteten Vorschlag aufzunehmen.

Fukais Lektüre

Das Folgende ist meine Interpretation — das sei vorab klargestellt. Ich möchte diese Forschung im Kontext der Bewegung verorten, in der sich das Schwergewicht der automatischen Generierung von „sichtbaren Ergebnissen (Levels, Terrain)" zu „unsichtbaren Strukturen (Regelbeziehungen)" verschiebt. Im Vokabular der Designkritik kommt das, was MORTAR unternimmt, dem nahe, „Interesse operationalisierbar zu machen, indem man es als Grad definiert, in dem Kompetenz sich in Ergebnissen niederschlägt". Dieses vage Interesse zunächst in „Bleibt die Kompetenzreihenfolge erhalten?" zu übersetzen und dann diesen Beitrag auf Regelebene aufzugliedern — diese zweistufige Übersetzung ist, so lese ich es, der Kern der Publikation. Der Maßstab ist nicht perfekt, aber Mechaniken „sagbar" zu machen, hat seinen Wert.

Zum Weiterlesen

Für alle, die tiefer einsteigen möchten, skizziere ich einige Wege, die als Orientierungskarte dienen können. Aus dem Umfeld von Togelius stammt ScriptDoctor (Earle u. a., 2025), das PuzzleScript-Puzzles per LLM und Baumsuche generiert — auf dieser Seite bereits vorgestellt. GAVEL (Todd u. a., 2024), das Brettspiele per Qualitäts-Diversität evolviert, und Pixie (Cook, 2025), das Mechaniken auf Code-Ebene evolviert, machen nebeneinandergestellt sichtbar, wie unterschiedlich die Konzepte von „Was wird generiert" und „Wie wird bewertet" ausfallen können. Alle zusammen zu lesen sollte die Umrisse des Feldes des automatischen Spieldesigns erkennbar machen.

Persönlich erhoffe ich mir als nächsten Schritt, was die Autoren selbst unter Grenzen nennen: eine Version, in der der Designer die Suche lenken kann. Ein Ideenfindungswerkzeug wird erst dann zum Praxispartner, wenn es „nach unseren Absichten generieren" kann. Eine Tasse kräftigen Kaffees in der Hand und die generierten Spiele selbst ausprobieren — das ist vielleicht der beste Weg, diesen Artikel zu lesen.

Literatur

Im vorliegenden Artikel herangezogene Publikationen und Ressourcen:

・MORTAR: Evolving Mechanics for Automatic Game Design (Nasir, Li, James, Togelius, 2026, arXiv-Preprint)

・Verwandte Forschung: ScriptDoctor: Automatic Generation of PuzzleScript Games via LLMs and Tree Search (Earle u. a., 2025)

・Verwandte Forschung: GAVEL: Generating Games via Evolution and Language Models (Todd u. a., 2024)

・Verwandte Forschung: Pixie: Code-level Mechanic Generation for Game Designers (Cook, 2025, AIIDE)