Personne n'a encore appris à une IA à maîtriser le tempo de réaction d'un jeu de cartes à collectionner. Nous essayons.

Pourquoi c'est difficile, et pourquoi presque personne ne l'a fait

Les jeux de plateau sont des jeux à information parfaite. La position est sur la table, donc elle peut être explorée. Les jeux de cartes brisent cela dès le premier coup : le deck est aléatoire et la main de l'adversaire est cachée, donc « la position actuelle » n'est pas une chose unique.

Le deuxième obstacle est celui qui détermine quels jeux finissent par être résolus : c'est de savoir si l'adversaire peut agir pendant votre tour. Hearthstone est le jeu où la recherche publique est allée le plus loin, et le pool de cartes plus petit n'en est que la raison mineure. La vraie raison, c'est qu'il n'y a quasiment aucun espace pour que l'adversaire agisse pendant votre tour, ce qui fait d'un tour une séquence fermée que l'on peut explorer jusqu'au bout. Même là, la recherche ne tourne pas contre le client publié : elle tourne sur des réimplémentations écrites par la communauté. Il faut que quelqu'un écrive d'abord les règles sous forme de programme pour qu'il y ait un sol, et c'est vrai de tous les jeux de cette liste.

C'est du côté de Magic que la tentative a eu la plus grande ampleur, et le résultat mérite d'être énoncé précisément. En 2016, Google DeepMind a publié Latent Predictor Networks for Code Generation, dont la tâche de référence était exactement celle-ci : lire le texte imprimé d'une carte et produire le code qui l'implémente. Les cibles étaient de vrais moteurs — 11 969 cartes Magic tirées de XMage en Java, et 533 cartes Hearthstone tirées de hearthbreaker en Python. Le meilleur modèle a produit exactement 4,8 % des cartes Magic correctement. Son score BLEU était de 61,4 : le code écrit ressemblait beaucoup au code qu'il aurait fallu écrire. Ces deux chiffres réunis, c'est tout le problème. Plausible et correct sont deux propriétés différentes, et une seule des deux s'exécute.

C'était il y a dix ans, et rien depuis n'a prétendu combler cet écart. Ce qui existe est écrit à la main et maintenu par la communauté : XMage et Forge du côté de Magic, et ygo-agent pour Yu-Gi-Oh, qui ne peut s'entraîner que parce que ygopro-core existe en dessous. Les benchmarks récents sur les deux jeux, MTG-Causal-RL et PTCG-Bench, montrent que les agents LLM peuvent jouer à un niveau non nul, sans qu'aucun des deux ne montre un niveau fiable. Les deux placent un ensemble borné d'archétypes dans un espace d'observation fixe pour comparer des méthodes : un benchmark de recherche, pas un monde où on peut s'auto-entraîner.

Riftbound se situe du côté difficile. Il a une chaîne, il transmet la priorité et le focus, il a un tempo de réaction, la position change entre les actions de l'autre joueur. Des tentatives existent : il y a au moins un simulateur Riftbound ouvert avec des liaisons de recherche arborescente, et il affronte la résolution de chaîne de front plutôt que de l'éviter.

Ce qu'aucun d'entre eux ne possède, c'est une suite de conformité : un moyen de vérifier, clause par clause, que le tempo implémenté est celui que décrivent les règles, et de dire quelles parties ne sont pas implémentées du tout. Sans cela, « illégal » et « non modélisé » sont la même réponse. Pour jouer, ça n'a pas d'importance ; les deux signifient que vous ne pouvez pas le faire. Pour tout ce qui doit apprendre de l'environnement ou le citer comme preuve, c'est la différence entre un résultat et une supposition.

L'obstacle n'a donc jamais été que les modèles ne sont pas assez intelligents. L'obstacle, c'est que quelqu'un doit d'abord transformer les règles en programme. Ce qui a changé depuis 2016, c'est qui s'en charge. Le noyau de règles décrit sur cette page n'a pas été écrit à la main par une personne : il a été écrit par des agents fondés sur des modèles de langage, relu par un humain, et retenu par une suite de conformité rattachée à des numéros de clause. C'est la tâche posée par DeepMind en 2016, mais menée comme de l'ingénierie ordinaire plutôt que comme un benchmark ponctuel — et c'est cette suite qui remplace l'exact-match contre une implémentation de référence. Cela compte particulièrement ici, car Riftbound n'a aucune implémentation faisant autorité à laquelle se comparer.

L'autre moitié, c'est que la cible n'a plus besoin d'être vingt mille cartes. Riftbound hérite de la structure de Magic — la chaîne, la priorité, les fenêtres de réaction — donc la mécanique difficile est entièrement là, pour une fraction de la taille imprimée. Assez petit pour être terminé ; assez structuré pour que le terminer veuille dire quelque chose.

Le pari : un périmètre borné, avec le droit de dire qu'on ne sait pas

Il n'est pas nécessaire de modéliser chaque carte. En pratique, un format ne repose que sur une fraction de ce qui est imprimé, et la traduction honnête de cela en ingénierie est un périmètre borné : implémenter les mécaniques réellement atteintes, et marquer le reste comme non modélisé.

La répartition du travail est donc fixe : le programme possède la couche mécanique et le modèle raisonne à l'intérieur de ce qu'elle laisse. Pas des règles traduites en prompt pour qu'un modèle les lise, mais des règles exécutées, de sorte qu'il existe un espace dont il ne peut pas discuter la sortie.

L'état exact aujourd'hui

L'objectif ci-dessus est énoncé à sa pleine mesure. Cette partie est énoncée avec exactitude, et les deux ne sont pas la même chose. Chaque ligne ici est vérifiée par une suite de conformité dans le dépôt ; si la suite change, cette page a tort.

• En service Noyau de temporisation et de permissions. Quatre états de tour, temporisation d'action et de réaction, priorité et focus, éléments de chaîne en attente et finalisés. 21 cas exécutables, chacun portant la clause officielle qu'il encode.
• En service Représentation intermédiaire typée des effets. 12 opérations plus séquencement, cibles, effets liés, nettoyage létal et émission de déclencheurs. Aucune condition sur le nom de carte dans l'interpréteur : une carte se compose d'opérations typées ou n'est pas modélisée, et le deuxième cas le dit clairement.
• En service Enveloppe de résultat partagée. Cinq issues : supporté, illégal, non supporté, décision requise, entrée invalide, portées avec les limites de couverture sous lesquelles elles ont été produites. Deux des trois systèmes consommateurs y sont déjà connectés.
• Partiel Paquets de comportement de carte. Le contrat de couverture des clauses par carte existe et est validé. Aucun paquet de production n'est encore inclus, donc pour un deck réel, la réponse honnête reste « indisponible », et l'outil le dit plutôt que d'arrondir vers le haut.
• Ouvert Énumération des actions légales. Bloqué par la couverture de conformité, pas par la collecte d'enregistrements de parties. C'est la pièce qui permettrait à tout ce qui est en aval de rechercher ou d'apprendre.
• Ouvert Une partie qui se termine. Combat, nettoyage, résolution de l'affrontement, contrôle du champ de bataille et — ce que tout le reste attend — résolution de conquête, décompte et détermination du vainqueur. Sans signal de victoire, il n'y a rien à quoi comparer : cette seule ligne bloque toute question ultérieure sur la performance réelle d'un deck.
• Ouvert Reconstruction de replay et analyse post-partie. Entièrement spécifié et délibérément non raccordé tant que ses conditions d'activation ne sont pas remplies.

Pourquoi nous avons fini par construire un noyau

Le projet a commencé comme une base de connaissances dérivée : chaque entrée écrite à partir du texte des cartes et de la mécanique du jeu plutôt que résumée depuis le guide de quelqu'un d'autre, ce qui rend les entrées peu coûteuses à régénérer et, en elles-mêmes, non prouvées. Les 46 ont donc été vérifiées face au jeu établi. Trois n'ont nécessité aucun changement.

La découverte la plus utile n'avait rien à voir avec une Légende. Une routine de substitution de liste de cartes bannies a échangé une carte qui donne une rune à chaque joueur sans condition contre une carte qui ne paie que celui qui tient le point : même domaine, même monnaie, entièrement légale, et cela aurait financé l'adversaire dans un deck qui cède délibérément le terrain en début de partie. Un joueur extérieur au projet l'a trouvé avant qu'une vérification interne ne le fasse.

Cet audit est la raison pour laquelle le noyau existe. La dérivation à partir du texte des cartes tient la route. Dès que la question devient ce qu'un deck essaie réellement de faire, ou ce qui est mécaniquement légal à cet instant, elle ne tient plus, et cette moitié mécanique ne peut pas être dérivée, seulement exécutée.

La ligne que nous visons

L'IA de Go valait son financement parce qu'elle bat tout être humain. Un jeu de cartes à collectionner n'a pas cette forme, et un joueur surhumain n'aurait pas grande valeur même si quelqu'un en construisait un. La ligne visée ici est délibérément différente, et à sa façon plus difficile :

Apprendre à jouer s'avère être la moitié facile. La moitié difficile, c'est construire, lire un format, et savoir quoi échanger quand une carte est bannie, exactement là où notre propre routine de substitution a échoué, sur un deck pour lequel elle avait toutes les raisons légales d'être confiante. Cet échec est la forme même du problème, pas une gêne à dissimuler.

Que cela devienne un jour un moteur de règles complet ou un système d'apprentissage, nous l'ignorons. Ce qui s'accumule entretemps, un état structuré, des cas de conformité exécutables, une piste de preuves, est le socle dont l'un ou l'autre aurait besoin.

D'où cela vient, et où va ce que cela produit

Ce n'est pas un projet d'IA parti en quête d'un usage. Cela a commencé par un problème de contenu sur Riftbound Chronicle, un site Riftbound en chinois traditionnel : écrire un guide de deck, c'est affirmer comment ce deck se joue réellement, et il n'existait aucun moyen de vérifier une telle affirmation. En parallèle, les joueurs demandaient quelque chose capable d'expliquer une interaction de règles et de montrer sur quoi reposait la réponse. Deck Coach et Rule Consult sont ces deux questions, dans cet ordre.

Le site reste le premier utilisateur en production, et c'est ce qui empêche tout ceci d'être une démo. Les guides de deck y font générer leur analyse de jeu depuis cette base de connaissances, chacun portant un badge explicite d'analyse par IA et un lien vers la méthodologie. Les problèmes rencontrés en écrivant les guides repartent dans la skill, et l'audit ci-dessus est ce qui s'est passé la première fois que cette boucle a été prise au sérieux.

Ce qui est refusé, et ce qui n'est simplement pas encore construit

Un moteur de règles, un agent IA et un modèle de joueur entraîné sont trois choses différentes. Ce projet a commencé comme le deuxième et a depuis écrit une partie bornée du premier. Il n'y a ni politique entraînée, ni corpus d'auto-jeu, ni machine à états complète, ni moteur d'effets de cartes complet.

C'est un ordre, pas un refus. Une politique apprise se situe en aval d'un environnement correct : entraînez-la contre des règles que personne n'a vérifiées et elle apprendra les bugs de cet environnement — avec assurance et de façon invisible, car elle gagne bel et bien la partie qu'on lui a donnée. Une suite de conformité n'est pas un obstacle placé devant l'apprentissage. C'est ce qui donnerait un sens à un résultat appris.

Ce qui est réellement refusé est bien plus étroit, et le reste. Il ne joue pas à votre place. Tout ici relève de la phase de préparation : construire, comprendre, s'entraîner, revoir. Dans le mode Joueur 2, un humain détient l'information cachée, la légalité, la résolution et chaque mise à jour d'état, et aucun résultat du moteur ne déplace quoi que ce soit de tout cela. Il ne publie ni taux de victoire, ni taux de jeu, ni classement de tiers, ni tableau de matchups. Un moteur de règles faisant autorité — y compris un client numérique officiel, s'il en sort un un jour — rendrait ceci plus utile plutôt que redondant : ce moteur-là sert le jeu, celui-ci sert la préparation.

La Digital Tools Policy de Riot est ouverte aux gestionnaires de decks et aux outils éducatifs, et précise explicitement qu'elle n'approuve pas au préalable l'exécution automatisée des règles ni les simulateurs de jeu. Cette limite a façonné la conception avant l'ambition : chaque suggestion de coup attend qu'un humain la confirme. Il est conçu pour un usage de recherche et éducatif, et l'utiliser pendant un tournoi enfreint le règlement.