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, und der kleinere Kartenpool ist dabei der geringere Grund. Der eigentliche ist, dass der Gegner während deines Zuges kaum Raum zum Handeln hat, wodurch ein Zug zu einer geschlossenen Folge wird, die man bis zum Ende durchsuchen kann. Selbst dort läuft die Forschung nicht gegen den ausgelieferten Client, sondern auf Reimplementierungen aus der Community. Jemand muss die Regeln erst als Programm aufschreiben, damit es überhaupt einen Boden gibt — und das gilt für jedes Spiel auf dieser Liste.

Bei Magic wurde genau das im größten Maßstab versucht, und das Ergebnis verdient es, genau genannt zu werden. 2016 veröffentlichte Google DeepMind Latent Predictor Networks for Code Generation, dessen Benchmark-Aufgabe genau dies war: den gedruckten Text einer Karte lesen und den Code ausgeben, der sie implementiert. Die Ziele waren echte Engines — 11.969 Magic-Karten aus XMage in Java und 533 Hearthstone-Karten aus hearthbreaker in Python. Das beste Modell traf 4,8 % der Magic-Karten exakt. Sein BLEU-Wert lag bei 61,4: Der geschriebene Code sah dem Code, der hätte entstehen sollen, sehr ähnlich. Diese beiden Zahlen zusammen sind das ganze Problem. Plausibel und korrekt sind verschiedene Eigenschaften, und nur eine davon läuft.

Das ist zehn Jahre her, und seither hat nichts behauptet, die Lücke sei geschlossen. Was existiert, ist handgeschrieben und von der Community gepflegt: XMage und Forge auf der Magic-Seite, 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. Was sich seit 2016 geändert hat, ist, wer das tut. Der auf dieser Seite beschriebene Regelkern wurde nicht von Hand geschrieben: Er wurde von Sprachmodell-Agenten geschrieben, von einem Menschen geprüft und von einer an Klauselnummern gebundenen Conformance-Suite aufgefangen. Das ist DeepMinds Aufgabe von 2016, nur läuft sie als gewöhnliche Ingenieursarbeit statt als einmaliger Benchmark — und die Suite tritt an die Stelle des Exact-Match gegen eine Referenzimplementierung. Das zählt hier besonders, weil es für Riftbound keine maßgebliche Implementierung zum Abgleichen gibt.

Die andere Hälfte: Das Ziel müssen nicht mehr zwanzigtausend Karten sein. Riftbound erbt die Struktur von Magic — die Kette, Priorität, Reaktionszeitfenster —, die schwierige Mechanik ist also vollständig da, bei einem Bruchteil des gedruckten Umfangs. Klein genug, um es fertigzustellen; strukturiert genug, dass Fertigstellen etwas bedeutet.

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 Eine Partie, die zu Ende geht. Kampf, Cleanup, Showdown-Auflösung, Kontrolle des Schlachtfelds und — das, worauf alles andere wartet — Eroberungsauflösung, Punktewertung und Siegbestimmung. Ohne Siegsignal gibt es nichts, wogegen man auswerten könnte; diese eine Zeile blockiert daher jede nachgelagerte Frage danach, wie gut ein Deck wirklich läuft.
• 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.

Woher es kommt und wohin das Ergebnis geht

Das hier begann nicht als KI-Projekt auf der Suche nach einem Zweck. Es begann als Inhaltsproblem auf Riftbound Chronicle, einer Riftbound-Seite auf traditionellem Chinesisch: Einen Deck-Guide zu schreiben heißt zu behaupten, wie ein Deck tatsächlich läuft — und es gab keine Möglichkeit, eine solche Behauptung zu prüfen. Parallel dazu fragten Spieler nach etwas, das eine Regelinteraktion erklären und zeigen kann, worauf die Antwort beruht. Deck Coach und Rule Consult sind genau diese zwei Fragen, in dieser Reihenfolge.

Die Seite ist bis heute der erste produktive Nutzer, und genau das hält dies davon ab, eine Demo zu sein. Die Deck-Guides dort lassen ihre Spielanalyse aus dieser Wissensbasis erzeugen, jeweils mit ausdrücklichem KI-Analyse-Hinweis und einem Link zur Methodik. Probleme, die beim Schreiben von Guides auftauchen, fließen zurück in die Skill — und das Audit oben ist das, was passierte, als diese Schleife zum ersten Mal ernst genommen wurde.

Was abgelehnt wird — und was bloß noch nicht gebaut ist

Eine Regel-Engine, ein KI-Agent und ein trainiertes Spielermodell sind drei verschiedene Dinge. Dies begann als das zweite und hat inzwischen ein begrenztes Stück des ersten geschrieben. Es gibt keine trainierte Policy, kein Selbstspiel-Korpus, keine vollständige Zustandsmaschine und keine vollständige Karteneffekt-Engine.

Das ist eine Reihenfolge, keine Ablehnung. Eine gelernte Policy liegt hinter einer korrekten Umgebung: Trainiert man sie gegen Regeln, die niemand geprüft hat, lernt sie die Fehler dieser Umgebung — selbstbewusst und unsichtbar, denn sie gewinnt das Spiel, das man ihr gegeben hat, ja tatsächlich. Eine Conformance-Suite ist kein Hindernis, das man vor das Lernen stellt. Sie ist das, was ein gelerntes Ergebnis überhaupt bedeutsam machen würde.

Was tatsächlich abgelehnt wird, ist deutlich enger — und bleibt abgelehnt. Es spielt nicht für dich. Alles hier sitzt in der Vorbereitungsphase: bauen, verstehen, üben, nachbesprechen. Im Spieler-2-Modus besitzt ein Mensch die verdeckten Informationen, die Legalität, die Auflösung und jedes Zustandsupdate, und kein Engine-Ergebnis verschiebt davon irgendetwas. Es veröffentlicht keine Siegraten, Nutzungsraten, Tier-Rankings oder Matchup-Tabellen. Eine maßgebliche Regel-Engine — auch ein offizieller digitaler Client, falls je einer erscheint — würde dies nützlicher machen statt überflüssig: Jene Engine dient dem Spielen, diese 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.