1. Decide primero qué estás construyendo: ¿un juego o un laboratorio para estudiar cómo ganar?
Para investigar mazos y decisiones no hace falta comenzar con arte, animaciones, voces e interfaz.
El núcleo es:
estado actual
→ generar acciones legales
→ elegir
→ aplicar reglas
→ nuevo estado
El producto es un laboratorio numérico.
Si ya existe un motor fiable, reutilízalo. Si no, construye primero las reglas mínimas correctas.
2. Define entradas y salidas antes de programar
Entradas: card DB, mazos, first/second, seed, policy, environment y partidas.
Salidas: ganador, turnos, matchup WR, first/second gap, worst matchup, brick, key-card drop, errores y cambios útiles.
El simulador empieza por la pregunta.
3. Card DB — datos no son comportamiento
Guarda ID, nombre, clase, coste, tipo, stats, rareza, set, texto, evolución, relacionadas y tags.
JSON o SQLite sirven.
“Fanfare: 4 damage” no implementa target, reducción, triggers ni orden.
La DB guarda manuales; el rules engine los ejecuta.
4. Representa el juego como estado
Guarda turn, active player, HP, PP, hand, deck, board, graveyard, Evolution, Super-Evolution, Crests, amulets, counters y temporary effects.
Importa el significado de reglas, no la posición visual.
5. Rules engine = estado A → acción → estado B
Jugar, atacar, evolucionar, Act, target, end turn, draw, PP refresh y win check son transiciones.
El engine debe ser correcto incluso con un bot tonto.
6. Efectos: reglas genéricas + excepciones
Crea damage, heal, draw, buff, summon, destroy, banish, Ward, Storm.
Casos especiales usan overrides.
Cuenta unsupported, partial y runtime gaps.
7. Legal action generation
Incluye playable cards, targets, attacks, Evolution, Act, end turn y cuando corresponda hold, draw-first o board-slot clearing.
Pregunta primero:
¿La jugada correcta existía en el candidate set?
8. Seed, replay y hash
Fija seed y guarda engine commit, DB hash, deck hash, policy hash, environment hash, schedule hash, seed hash.
Mismas condiciones deben reproducir la misma partida.
9. Primera IA: reference policy simple
Lethal → terminar; muerte cercana → defender; jugar curva; board favorable → face; board desfavorable → trade.
Es baseline, no campeona.
10. Human knowledge como prior
Usa mulligan, hold, EP/SEP, setup, swing turn, hand cap, board slot, future lethal.
No hagas reglas absolutas.
Usa scores como hold_value, future_combo, survival, premature_spend.
La guía es mapa, no gabarito.
11. Tree search, beam, node budget
10 candidatos por capa producen 10, 100, 1.000, 10.000.
Usa depth, beam width, node budget, pruning.
No elimines demasiado pronto líneas de setup.
Separa immediate, future, survival, setup, lethal y resource value.
12. Hidden hand: belief, POMDP, Monte Carlo
No des la hidden hand real a la policy.
Construye mundos plausibles, por ejemplo AoE 30%, Ward 20%, nada 50%.
Eso es belief.
El problema se parece a POMDP; samplea manos y simula futuros varias veces.
13. Grandes simulaciones como paired A/B
Mismo deck, rival, first/second y seed; cambia solo policy.
Quick → development → unseen holdout.
El objetivo es reducir ruido con comparación justa.
14. Mide más que win rate
Average, meta-weighted, worst matchup, bottom average, variance, first/second gap, brick, key-card drop, turns, confidence intervals.
CVaR mira la zona mala.
Bootstrap y McNemar ayudan en paired A/B.
15. Deck optimization comprime candidatos
No puedes brute-force todas las combinaciones de 40 cartas.
Parte de decks reales y prueba swaps 1–3 cartas, role replacement y techs.
Double Oracle añade counters, PSRO usa deck + policy, No-Regret reduce regret, Robust Optimization protege el floor.
16. Registra por qué pierde la IA
Action trace: candidates, scores, choice, objective, reservation, early combo spend, missed lethal, hand burn, board lock.
Ablation quita componentes.
Counterfactual prueba A y B desde el mismo public state.
17. Nueva expansión = environment snapshot nuevo
Guarda formato, legal sets y hashes.
Haz diff de DB y recalcula solo decks/matchups afectados.
Si solo cambia meta weight, reutiliza resultados.
18. Arquitectura pequeña y CLI-first
Separa upstream, deck, policy, simulation, diagnosis, statistics, config, data, reports, docs, tests.
CLI: status, doctor, db check, validate, simulate, experiment, optimize, diagnose, context.
GitHub es memoria externa.
19. Roadmap zero-to-one
1 card DB
2 una partida mínima correcta
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
No construyas una máquina que se equivoque 10.000 veces por minuto.
20. Conclusión
DB = memoria. Rules Engine = física. Policy = cerebro. Search = anticipación. Statistics = boletín. Action Trace = cámara. Git = cuaderno. AI Agents = investigadores.
La persona pregunta:
“¿Puedo confiar de verdad en ese número?”
Empezó con Storm a la cara.
Terminó como laboratorio de IA.
Último turno: quitar Ward, evolucionar,
Storm a la cara.
