1. Zuerst entscheiden: Spiel oder Forschungslabor?
Für Deck- und Zugforschung braucht man nicht zuerst Art, Animationen, Stimmen und UI.
Der Kern:
aktueller State
→ legale Actions erzeugen
→ wählen
→ Regeln anwenden
→ neuer State
Das Produkt ist ein numerisches Labor.
Existiert eine zuverlässige Engine, wiederverwenden. Sonst minimale korrekte Regeln bauen.
2. Inputs und Outputs vor dem Code
Inputs: Card DB, Decks, first/second, seed, policy, environment, Spiele.
Outputs: winner, turns, matchup WR, first/second gap, worst matchup, brick, key-card drop, errors, deck changes.
Ein Simulator beginnt mit der Frage.
3. Card DB — Daten sind nicht Verhalten
ID, Name, Klasse, Kosten, Typ, Stats, Rarity, Set, Text, Evolution, Related Cards, Tags speichern.
JSON oder SQLite reichen.
„Fanfare: 4 Schaden“ implementiert noch keine Targets, Reduktion, Trigger, Reihenfolge.
DB sammelt Handbücher; Rules Engine führt sie aus.
4. Spiel als State modellieren
Turn, active player, HP, PP, hand, deck, board, graveyard, Evolution, Super-Evolution, Crests, amulets, counters, temporary effects speichern.
Regelbedeutung ist wichtiger als Darstellung.
5. Rules Engine = State A → Action → State B
Play, Attack, Evolution, Act, Target, End Turn, Draw, PP Refresh, Win Check sind Transitions.
Die Engine muss korrekt sein, auch wenn ein dummer Bot legal handelt.
6. Generische Effekte + Ausnahmen
Damage, heal, draw, buff, summon, destroy, banish, Ward, Storm als wiederverwendbare Funktionen.
Sonderfälle per Override.
Unsupported, partial, runtime gaps zählen.
7. Legal Action Generation
Playable Cards, Targets, Attacks, Evolution, Act, End Turn sowie bei Bedarf Hold, Draw-first, Board-Slot-Clearing.
Frage zuerst:
War die richtige Action im Candidate Set?
8. Seed, Replay, Hash
Seed fixieren und engine commit, DB hash, deck hash, policy hash, environment hash, schedule hash, seed hash speichern.
Gleiche Bedingungen sollen dieselbe Partie reproduzieren.
9. Erste KI einfach halten
Reference Policy: lethal → finish; bald tot → defend; curve; board gut → face; board schlecht → trade.
Sie ist die Baseline.
10. Human Knowledge als Prior
Mulligan, hold, EP/SEP, setup, swing turn, hand cap, board slot, future lethal nutzen.
Keine absoluten Gesetze.
Scores wie hold_value, future_combo, survival, premature_spend.
Guide ist eine Karte.
11. Tree Search, Beam, Node Budget
10 Kandidaten pro Layer ergeben 10, 100, 1.000, 10.000.
Depth, beam width, node budget, pruning benutzen.
Wichtige Setup-Linien nicht zu früh löschen.
Immediate, future, survival, setup, lethal, resource value trennen.
12. Hidden Hand: Belief, POMDP, Monte Carlo
Die echte hidden hand darf die Policy nicht sehen.
Plausible Welten: AoE 30 %, Ward 20 %, nichts 50 %.
Das ist Belief.
Problem ähnlich POMDP; plausible Hände samplen und mehrfach rollout.
13. Large Simulation = Paired A/B
Gleiche Decks, Gegner, first/second, seed; nur policy ändert sich.
Quick → development → unseen holdout.
Ziel: Rauschen bei fairem Vergleich reduzieren.
14. Mehr als Winrate messen
Average, meta-weighted, worst matchup, bottom average, variance, first/second gap, brick, key-card drop, turns, confidence interval.
CVaR betrachtet schlechte Ergebnisse.
Bootstrap und McNemar helfen paired A/B.
15. Deck Optimization komprimiert den Suchraum
Alle 40-Karten-Kombinationen sind unmöglich.
Mit echten Decks starten, Swaps, Role Replacement, Techs testen.
Double Oracle fügt Counter hinzu, PSRO nutzt deck + policy, No-Regret reduziert Regret, Robust Optimization schützt Floor.
16. Speichern, warum die KI verliert
Action Trace: Candidates, Scores, Choice, Objective, Reservation, Early Combo Spend, Missed Lethal, Hand Burn, Board Lock.
Ablation schaltet Komponenten aus.
Counterfactual testet A und B aus demselben Public State.
17. Neues Set = Environment Snapshot
Format, Legal Sets und Hashes speichern.
DB diffen und nur betroffene Decks/Matchups neu berechnen.
Nur Meta Weight geändert? Resultate wiederverwenden.
18. Kleine Architektur, CLI-first
Upstream, Deck, Policy, Simulation, Diagnosis, Statistics, Config, Data, Reports, Docs, Tests trennen.
CLI: status, doctor, db check, validate, simulate, experiment, optimize, diagnose, context.
GitHub ist externes Gedächtnis.
19. Zero-to-One-Roadmap
1 Card DB
2 eine minimale korrekte Partie
3 Legal Actions/Targets
4 Seed/Replay/Hash
5 Simple Policy + 100 Games
6 Coverage
7 Real Decks + Matrix
8 Human Prior
9 Search + Belief
10 Paired A/B + Holdout
11 Deck Optimization
12 Diagnosis + Expansion Diff
Keine Maschine bauen, die 10.000-mal pro Minute falsch liegt.
20. Fazit
DB = Gedächtnis. Rules Engine = Physik. Policy = Gehirn. Search = Vorausdenken. Statistics = Zeugnis. Action Trace = Kamera. Git = Forschungsnotizbuch. AI Agents = Forscher.
Der Mensch fragt:
„Kann ich dieser Zahl wirklich vertrauen?“
Anfang: Storm ins Gesicht.
Ende: Kartenspiel-KI-Labor.
Ward entfernen, evolven,
Storm ins Gesicht.
