Niemand hat einer KI beigebracht, das Reaktions-Timing eines Sammelkartenspiels zu beherrschen. Wir versuchen es.

Warum das schwer ist, und warum es fast niemand gemacht hat

Brettspiele sind Spiele mit vollständiger Information. Die Stellung liegt offen auf dem Tisch und lässt sich durchsuchen. Kartenspiele brechen das schon beim ersten Zug: Das Deck ist zufällig gemischt, die Hand des Gegners ist verdeckt, also ist die aktuelle Stellung nicht eindeutig.

Die zweite Hürde entscheidet, welche Spiele überhaupt lösbar werden: ob der Gegner in deinem Zug handeln kann. Hearthstone ist dort, wo öffentliche Forschung am weitesten gekommen ist, nicht nur wegen des kleineren Kartenpools, sondern weil der Gegner meist nicht eingreifen kann und die ausgelieferte Implementierung selbst die einzig korrekte Regel-Engine ist, sodass niemand die Regeln neu interpretieren muss, um eine Umgebung zu bauen.

Bei Magic gibt es so etwas nicht. Die nächstliegenden Referenzen sind community-gebaut: Forge für MTG, eine seit langem gepflegte inoffizielle Regel-Engine, und ygo-agent für Yu-Gi-Oh, das nur trainieren kann, weil darunter ygopro-core existiert. Aktuelle Benchmarks zu beiden Spielen, MTG-Causal-RL und PTCG-Bench, zeigen, dass LLM-Agenten nicht bei null spielen, aber keiner der beiden zeigt Zuverlässigkeit. Beide stecken eine begrenzte Menge an Archetypen in einen festen Beobachtungsraum, um Methoden zu vergleichen: ein Forschungs-Benchmark, keine Welt zum Selbstspiel.

Riftbound gehört zur schwierigen Seite. Es hat eine Kette, gibt Priorität und Fokus weiter, hat Reaktions-Timing, die Stellung ändert sich zwischen den Zügen des Gegners. Versuche gibt es: mindestens ein offener Riftbound-Simulator mit Baumsuche-Anbindung geht die Kettenauflösung direkt an, statt ihr auszuweichen.

Was keinem von ihnen zueigen ist, ist eine Konformitätsprüfung: eine Möglichkeit, Klausel für Klausel zu prüfen, ob das implementierte Timing dem Timing der Regeln entspricht, und zu sagen, welche Teile überhaupt nicht implementiert sind. Ohne das sind „illegal“ und „nicht modelliert“ dieselbe Antwort. Zum Spielen macht das keinen Unterschied, beides bedeutet, man kann es nicht. Für alles, was aus der Umgebung lernen oder sie als Beleg zitieren soll, ist es der Unterschied zwischen einem Ergebnis und einer Vermutung.

Die Hürde war also nie, dass die Modelle nicht klug genug sind. Die Hürde ist, dass jemand die Regeln erst in ein Programm übersetzen muss.

Die Wette: begrenzter Umfang, und die Erlaubnis, „weiss ich nicht“ zu sagen

Man muss nicht jede Karte modellieren. In der Praxis stützt sich ein Format nur auf einen Bruchteil des Gedruckten, und die ehrliche technische Uebersetzung davon ist ein begrenzter Umfang: die Mechaniken umsetzen, die tatsächlich vorkommen, und den Rest als nicht modelliert kennzeichnen.

Die Arbeitsteilung ist also festgelegt: Das Programm besitzt die mechanische Ebene, und das Modell schlussfolgert innerhalb dessen, was davon übrig bleibt. Nicht die Regeln in einen Prompt übersetzt, damit ein Modell sie lesen kann, sondern die Regeln tatsächlich ausgeführt, sodass es einen Raum gibt, aus dem es sich nicht herausreden kann.

Genau der aktuelle Stand

Das obige Ziel ist in voller Größe formuliert. Dieser Teil ist exakt formuliert, und beides ist nicht dasselbe. Jede Zeile hier wird von einer Konformitätsprüfung im Repository geprüft; ändert sich die Prüfung, ist diese Seite falsch.

• Fertig Timing- und Berechtigungskern. Vier Zugzustände, Aktions- und Reaktions-Timing, Priorität und Fokus, ausstehende und abgeschlossene Ketten-Einträge. 21 ausführbare Testfälle, jeder mit der offiziellen Klausel, die er kodiert.
• Fertig Typisierte Effekt-Zwischendarstellung. 12 Operationen plus Reihenfolge, Ziele, verknüpfte Effekte, tödliche Bereinigung und Trigger-Auslösung. Keine Kartennamen-Bedingungen im Interpreter: Eine Karte setzt sich aus typisierten Operationen zusammen oder ist nicht modelliert, und im zweiten Fall sagt das System das auch so.
• Fertig Gemeinsame Ergebnishülle. Fünf Ausgänge: unterstützt, illegal, nicht unterstützt, Entscheidung erforderlich, ungültige Eingabe, jeweils mit den Abdeckungsgrenzen, unter denen sie entstanden. Zwei der drei nutzenden Systeme sind bereits angebunden.
• Teilweise Karten-Verhaltenspakete. Der Vertrag für die Klauselabdeckung pro Karte existiert und ist validiert. Noch ist kein Produktionspaket eingebunden, für ein reales Deck lautet die ehrliche Antwort also weiterhin „nicht verfügbar“, und das Tooling sagt das auch, statt es zu beschönigen.
• Offen Aufzählung legaler Aktionen. Blockiert durch die Konformitätsabdeckung, nicht durch das Sammeln von Spielaufzeichnungen. Das ist das Teil, das allem Nachgelagerten Suche oder Lernen ermöglichen würde.
• Offen Replay-Rekonstruktion und Nachbesprechung. Vollständig spezifiziert und bewusst noch nicht angebunden, bis die Aktivierungsbedingungen erfüllt sind.

Warum wir überhaupt einen Kern gebaut haben

Das Projekt begann als hergeleitete Wissensbasis: Jeder Eintrag wurde aus Kartentext und Spielmechanik geschrieben, statt aus fremden Guides zusammengefasst, was Einträge billig in der Neuerstellung, aber für sich genommen unbewiesen macht. Deshalb wurden alle 46 gegen etablierte Spielweise geprüft. Drei brauchten keine Aenderung.

Der wertvollste Fund hatte gar nichts mit einer Legend zu tun. Eine Ersatzroutine für die Bannliste tauschte eine Karte, die jedem Spieler bedingungslos eine Rune gibt, gegen eine Karte, die nur an denjenigen auszahlt, der den Punkt hält: gleiche Domäne, gleiche Währung, vollkommen legal, und der Tausch hätte in einem Deck, das das frühe Spielfeld absichtlich aufgibt, den Gegner finanziert. Gefunden hat es ein Spieler ausserhalb des Projekts, bevor eine interne Prüfung es tat.

Diese Prüfung ist der Grund, warum der Kern existiert. Herleitung aus Kartentext hält stand. Sobald die Frage wird, was ein Deck tatsächlich versucht, oder was gerade mechanisch legal ist, hält sie nicht mehr, und diese mechanische Hälfte lässt sich nicht herleiten, nur ausführen.

Die Linie, auf die wir zielen

Go-KI war ihre Förderung wert, weil sie jeden Menschen schlägt. Ein Sammelkartenspiel hat nicht diese Form, und ein übermenschlicher Spieler wäre kaum etwas wert, selbst wenn ihn jemand baute. Die Linie hier ist bewusst anders und auf ihre eigene Art schwerer:

Spielen zu lernen erweist sich als die leichtere Hälfte. Die schwierige Hälfte ist Deckbau, das Lesen eines Formats und zu wissen, was man tauscht, wenn eine Karte gebannt wird, genau dort, wo unsere eigene Ersatzroutine versagte, bei einem Deck, bei dem sie jeden legalen Grund zur Zuversicht hatte. Dieses Versagen ist die Form des Problems, keine Peinlichkeit, die man vertuschen muss.

Ob daraus je eine vollständige Regel-Engine oder ein Lernsystem wird, wissen wir nicht. Was sich in der Zwischenzeit ansammelt, strukturierter Zustand, ausführbare Konformitätsfälle, eine Beleg-Spur, ist das Fundament, das beides brauchen würde.

Was es nicht ist

Eine Regel-Engine, ein KI-Agent und ein trainiertes Spielermodell sind drei verschiedene Dinge. Dieses Projekt begann als das zweite und hat seither einen begrenzten Teil des ersten geschrieben. Es ist nicht das dritte und gibt auch nicht vor, es zu sein: Es gibt keine vollständige Zustandsmaschine, keine komplette Karteneffekt-Engine, keine Selbstspieldaten und keine trainierte Strategie.

Es spielt auch nicht selbst. Alles davon bleibt in der Vorbereitungsphase: Aufbauen, Verstehen, Ueben, Nachbesprechen. Eine massgebliche Regel-Engine, einschliesslich eines offiziellen digitalen Clients, sollte es je einen geben, würde dieses Projekt nützlicher machen statt überflüssig: Diese Engine dient dem Spielen, dieses Projekt dient der Vorbereitung.

Riots Digital Tools Policy ist offen für Deck-Manager und Bildungstools, und ausdrücklich dagegen, automatisierte Regelausführung oder Gameplay-Simulatoren vorab freizugeben. Diese Grenze hat das Design geformt, bevor der Ehrgeiz es tat: Jeder Spielvorschlag wartet auf die Bestätigung eines Menschen. Es ist für Forschung und Bildung gebaut, und die Nutzung während eines Turniers verstößt gegen das Regelwerk.