Le cauchemar classique consiste à saisir nom, coût, stats, texte et comportement spécial pour des centaines de cartes.
Mais si les données sont déjà structurées et qu’un moteur de bataille réutilisable existe, le problème change totalement. On importe la base, on réutilise les règles communes et on ne code que les mécaniques réellement nouvelles.
Dans ce cas, Beyond Decks possédait déjà données, decks, seeds, replays, Battle Sim, IA et benchmarks.
Il ne fallait pas refaire le jeu. Il fallait ajouter des instruments de recherche et un meilleur cerveau à un sandbox existant.
1. Sans animations, une partie devient ridiculement courte
Le client réel consomme du temps en pioche, glisser-déposer, voix, évolution, attaques, dégâts et réflexion humaine.
Le simulateur fait essentiellement :
état A
→ actions légales
→ choix
→ mise à jour
→ état B
jusqu’à la défaite.
Ce qui coûte cher n’est pas l’animation, mais la profondeur de futur demandée à l’IA.
2. Le simulateur de base est sérieux, pas un gadget
Il possède deterministic seed, replay inspection, target selection, tactical look-ahead, full-turn planning, lethal solver, mécaniques de classe, benchmarks, audit de couverture et runtime checks.
L’auteur précise aussi que l’IA n’est pas un oracle parfait de tournoi, mais une IA intermédiaire.
C’est idéal : règles, cartes, seeds, replay et machine de combat sont déjà là. Il faut surtout améliorer la couche de décision proche de l’humain.
3. 12 480 parties ont donné Royal vers 79,8 %—un gros échantillon amplifie aussi les biais
La couverture des règles était bonne, mais Royal atteignait environ79,8% et Witch25,6%.
Ce n’est pas une preuve absolue de force.
Si Royal fonctionne avec « poser, prendre le board, taper face » alors qu’un deck complexe gaspille combo, évolution et main, la policy favorise les plans simples.
Un gros échantillon peut mesurer une mauvaise policy avec une précision magnifique.
4. Le savoir humain est devenu une habitude de pensée, pas une table de réponses
Mulligan, cartes à garder, évolution, espace de main/board, changement attaque-défense, power turns adverses, plans alternatifs, lethal à2–3 tours et erreurs fréquentes ont été structurés.
On les injecte en scores :
hold_value +20
future_combo_value +30
opponent_counter_cost +25
usage trop tôt -40
Le guide oriente la recherche sans l’emprisonner.
5. L’exécution actuelle représente 4 032 vraies parties—2 016 sont les conditions A/B
56 groupes × 2 directions × 18 seeds = 2 016 conditions
La policy de référence et human-prior jouent chacune une partie. Total moteur : 4 032.
2 016 est le nombre de questions identiques données à deux IA.
6. Avant le gros lot, on s’arrête et on valide
On corrige d’abord la régression du finisher joué trop tôt, puis on fait des smoke tests avec DB et decks réels.
On contrôle couverture, unsupported, rule gaps, hash DB, IDs dupliqués, références manquantes et version du corpus.
Le principe : valider l’expérience avant d’acheter de la taille d’échantillon.
7. human-prior v1 n’est pas encore vraiment adaptative
Le même Ramp Dragon doit changer de but :
normal → ramp
mort au prochain tour → défense
adversaire à sec → attaque
finisher sans setup → conserver
setup prêt → utiliser
Il faut recalculer ce qui compte maintenant à chaque tour.
8. Adaptive AI bascule ATTACK / SURVIVE / SETUP / RESOURCE / LETHAL
Vie, board, main, PP, évolution, pression, dégâts prévus et combo readiness donnent un score aux modes.
À6PV face à14 dégâts, SURVIVE doit battre RESOURCE.
S’adapter, c’est comparer jouer maintenant à attendre.
9. Regarder 2–3 tours, mais élaguer grâce au savoir humain
50 actions légales
→ priors humains : 20
→ évaluation rapide : 10
→ recherche 2–3 tours sur les 10 meilleures
+8 maintenant mais mort ensuite doit perdre contre +3 maintenant avec survie et riposte.
10. Lire la main cachée serait tricher—modéliser « il peut l’avoir »
Leader, archétype, cartes utilisées, deck restant, taille de main et actions passées créent plusieurs mondes possibles.
AoE présent 30%
absent 70%
On évalue la même action dans ces mondes.
On obtient : « il peut l’avoir, je respecte un peu, mais je ne peux pas tout respecter ».
11. L’ordre compte—ne changez pas l’IA au milieu des 4 032 parties
geler v1
→ finir 4 032
→ analyser les erreurs
→ Adaptive v2
→ quick A/B
→ refaire ~2 016 conditions
→ full ~12k
→ optimiser 40 cartes
→ diagnostic
v2 doit répondre aux erreurs réellement observées.
12. Le but n’est pas un CPU qui récite le guide, mais un CPU qui peut le contredire
Combinez savoir humain, arbre de jeu, futur, probabilité de main cachée et mode dynamique.
Alors : « ramp normalement, mais défends si tu meurs », « conserve normalement, mais dépense tout si lethal », « développe normalement, mais garde des ressources si l’AoE est probable ».
Le guide conseille. La position décide.
13. Cette méthode dépasse un seul jeu—construisez un laboratoire de victoire
Pour Pokémon, réutilisez un simulateur et optimisez équipe, sélection, switch et moves. Pour les card games, deck, mulligan, ressources et matchups.
Reconstruire le jeu et rechercher comment gagner sont deux métiers différents.
Si un bon simulateur existe, utilisez-le.
Ne reconstruisez pas le stade. Construisez le laboratoire qui apprend à y gagner.
Et si Royal revient à80% :
« Ce bot est encore premier de la classe en “poser une unité et taper face” ? »
