Nadie le ha enseñado todavía a una IA a dominar el ritmo de respuesta de un juego de cartas coleccionables. Nosotros lo estamos intentando.

Por qué es difícil, y por qué casi nadie lo ha hecho

Los juegos de mesa son de información perfecta. La posición está sobre la mesa, así que se puede explorar. Los juegos de cartas rompen eso desde el primer movimiento: el mazo es aleatorio y la mano del rival está oculta, así que «la posición actual» no es una sola cosa.

El segundo obstáculo es el que decide qué juegos terminan resolviéndose: si el rival puede actuar durante tu turno. Hearthstone es el juego donde la investigación pública ha llegado más lejos, y el pool de cartas más pequeño es la razón menor. La de verdad es que casi no hay espacio para que el rival actúe durante tu turno, lo que convierte un turno en una secuencia cerrada que puedes explorar hasta el final. Incluso ahí, la investigación no corre contra el cliente publicado, sino sobre reimplementaciones hechas por la comunidad. Alguien tiene que escribir las reglas como programa antes de que haya dónde pisar, y eso vale para todos los juegos de esta lista.

Magic es donde eso se intentó a mayor escala, y el resultado merece contarse con precisión. En 2016 Google DeepMind publicó Latent Predictor Networks for Code Generation, cuya tarea de benchmark era exactamente esta: leer el texto impreso de una carta y emitir el código que la implementa. Los objetivos eran motores reales: 11.969 cartas de Magic tomadas de XMage en Java, y 533 cartas de Hearthstone tomadas de hearthbreaker en Python. El mejor modelo acertó exactamente el 4,8 % de las cartas de Magic. Su puntuación BLEU fue 61,4: el código que escribió se parecía muchísimo al código que debería haber escrito. Esos dos números juntos son el problema entero. Plausible y correcto son propiedades distintas, y solo una de las dos se ejecuta.

De eso hace diez años, y desde entonces nada ha afirmado que la brecha esté cerrada. Lo que existe está escrito a mano y mantenido por la comunidad: XMage y Forge del lado de Magic, y ygo-agent de Yu-Gi-Oh, que solo puede entrenar porque debajo existe ygopro-core. Los benchmarks recientes de ambos juegos, MTG-Causal-RL y PTCG-Bench, muestran que los agentes LLM pueden jugar con un rendimiento distinto de cero, y ninguno de los dos muestra un rendimiento fiable. Ambos meten un conjunto acotado de arquetipos en un espacio de observación fijo para comparar métodos: un benchmark de investigación, no un mundo donde autojugar.

Riftbound está del lado difícil. Tiene cadena, pasa prioridad y foco, tiene ritmo de reacción, la posición cambia entre las acciones del otro jugador. Ya hay intentos: existe al menos un simulador abierto de Riftbound con búsqueda en árbol integrada, y aborda la resolución de cadena de frente en lugar de evitarla.

Lo que ninguno de ellos tiene es una suite de conformidad: una forma de comprobar, cláusula por cláusula, que el ritmo implementado es el que describen las reglas, y de decir qué partes no están implementadas en absoluto. Sin eso, «ilegal» y «no modelado» son la misma respuesta. Para jugar da igual, ambas cosas significan que no puedes hacerlo. Pero para cualquier cosa que vaya a aprender del entorno o citarlo como evidencia, es la diferencia entre un resultado y una suposición.

Así que el obstáculo nunca fue que los modelos no fueran lo bastante listos. El obstáculo es que alguien tiene que traducir primero las reglas a un programa. Lo que ha cambiado desde 2016 es quién lo hace. El núcleo de reglas que describe esta página no lo escribió una persona a mano: lo escribieron agentes de modelo de lenguaje, lo revisó una persona y lo sostiene una suite de conformidad atada a números de cláusula. Esa es la tarea que DeepMind planteó en 2016, corriendo como ingeniería ordinaria en lugar de como un benchmark de una sola vez, y la suite es lo que ocupa el lugar del exact-match contra una implementación de referencia. Aquí importa especialmente, porque Riftbound no tiene ninguna implementación autoritativa con la que contrastar.

La otra mitad es que el objetivo ya no tiene que ser veinte mil cartas. Riftbound hereda la estructura de Magic —la cadena, la prioridad, el tiempo de reacción—, así que la mecánica difícil está entera, con una fracción del tamaño impreso. Lo bastante pequeño para terminarlo; lo bastante estructurado para que terminarlo signifique algo.

La apuesta: alcance acotado, con permiso para decir que no lo sabe

No hace falta modelar cada carta. En la práctica, un formato se apoya en una fracción de lo que existe impreso, y la traducción honesta de eso a ingeniería es un alcance acotado: implementar las mecánicas que realmente se alcanzan, y marcar el resto como no modelado.

Así que el reparto de trabajo es fijo: el programa posee la capa mecánica y el modelo razona dentro de lo que esa capa deja. No las reglas traducidas a un prompt para que un modelo las lea, sino las reglas ejecutadas, de modo que hay un espacio del que no puede escaparse argumentando.

Dónde está exactamente hoy

El objetivo anterior está expresado a tamaño completo. Esta parte está expresada con exactitud, y las dos cosas no son lo mismo. Cada línea aquí se comprueba con una suite de conformidad en el repositorio; si la suite cambia, esta página está equivocada.

• En marcha Núcleo de temporización y permisos. Cuatro estados de turno, temporización de acción y reacción, prioridad y foco, elementos de cadena pendientes y finalizados. 21 casos ejecutables, cada uno con la cláusula oficial que codifica.
• En marcha Representación intermedia tipada de efectos. 12 operaciones más secuenciación, objetivos, efectos vinculados, limpieza letal y emisión de disparadores. Sin condicionales por nombre de carta en el intérprete: una carta se compone de operaciones tipadas o no está modelada, y en ese caso el sistema lo dice.
• En marcha Envoltorio de resultado compartido. Cinco resultados: soportado, ilegal, no soportado, decisión requerida, entrada inválida, cada uno con los límites de cobertura bajo los que se produjo. Dos de los tres sistemas que lo consumen ya están conectados.
• Parcial Paquetes de comportamiento de carta. El contrato de cobertura de cláusulas por carta existe y está validado. Todavía no hay ningún paquete de producción incluido, así que para un mazo real la respuesta honesta sigue siendo «no disponible», y la herramienta lo dice en vez de redondear hacia arriba.
• Abierto Enumeración de acciones legales. Bloqueado por la cobertura de conformidad, no por recopilar registros de partidas. Es la pieza que permitiría que cualquier cosa aguas abajo buscara o aprendiera.
• Abierto Una partida que termina. Combate, limpieza, resolución del enfrentamiento, control del campo de batalla y — lo que todo lo demás está esperando — resolución de conquista, puntuación y determinación de la victoria. Sin una señal de victoria no hay nada contra lo que evaluar, así que esta única línea bloquea toda pregunta posterior sobre cómo rinde un mazo de verdad.
• Abierto Reconstrucción de repeticiones y revisión post-partida. Especificado por completo y deliberadamente sin conectar hasta que se cumplan sus condiciones de activación.

Por qué acabamos construyendo un núcleo

El proyecto empezó como una base de conocimiento derivada: cada entrada escrita a partir del texto de las cartas y la mecánica del juego en lugar de resumida de la guía de otra persona, lo que hace que las entradas sean baratas de regenerar y, por sí solas, no demostradas. Así que las 46 se comprobaron contra el juego establecido. Tres no necesitaron ningún cambio.

El hallazgo más útil no tuvo nada que ver con una Leyenda. Una rutina de sustitución de lista de prohibidas cambió una carta que da una runa a cada jugador sin condiciones por otra que solo paga a quien controla el punto: mismo dominio, mismo coste, totalmente legal, y habría financiado al rival en un mazo que cede el tablero temprano a propósito para ganar tempo. Un jugador ajeno al proyecto lo encontró antes de que lo hiciera ninguna revisión interna.

Esa auditoría es la razón por la que existe el núcleo. La derivación a partir del texto de las cartas se sostiene. En cuanto la pregunta pasa a ser qué intenta hacer realmente un mazo, o qué es legal mecánicamente en este momento, deja de sostenerse, y esa mitad mecánica no se puede derivar, solo ejecutar.

La línea a la que apuntamos

La IA de Go valía su inversión porque gana a cualquier humano. Un juego de cartas coleccionables no tiene esa forma, y un jugador sobrehumano no valdría gran cosa aunque alguien lo construyera. La línea que se busca aquí es deliberadamente distinta, y a su manera más difícil:

Aprender a jugar resulta ser la mitad fácil. La mitad difícil es construir, leer un formato y saber qué cambiar cuando se prohíbe una carta, justo donde falló nuestra propia rutina de sustitución, en un mazo que tenía todas las razones legales para tener confianza. Ese fallo es la forma del problema, no una vergüenza que haya que disimular.

No sabemos si esto llegará a convertirse algún día en un motor de reglas completo o en un sistema de aprendizaje. Lo que se está acumulando mientras tanto, estado estructurado, casos de conformidad ejecutables, un rastro de evidencia, es la base que cualquiera de los dos necesitaría.

De dónde viene, y adónde va lo que produce

Esto no empezó como un proyecto de IA buscando un uso. Empezó como un problema de contenido en Riftbound Chronicle, un sitio de Riftbound en chino tradicional: escribir una guía de mazo significa afirmar cómo se juega ese mazo de verdad, y no había forma de comprobar semejante afirmación. Por otro lado, los jugadores pedían algo capaz de explicar una interacción de reglas y mostrar en qué se apoyaba la respuesta. Deck Coach y Rule Consult son esas dos preguntas, en ese orden.

El sitio sigue siendo el primer usuario en producción, que es lo que impide que esto sea una demo. Allí las guías de mazo generan su análisis de juego desde esta base de conocimiento, cada una con una insignia explícita de análisis por IA y un enlace a la metodología. Los problemas que aparecen al escribir guías vuelven a la skill, y la auditoría de arriba es lo que pasó la primera vez que ese bucle se tomó en serio.

Qué se rechaza y qué simplemente no está construido todavía

Un motor de reglas, un agente de IA y un modelo de jugador entrenado son tres cosas distintas. Esto empezó como lo segundo y desde entonces ha escrito una parte acotada de lo primero. No hay política entrenada, ni corpus de autojuego, ni máquina de estados completa, ni motor completo de efectos de carta.

Eso es un orden, no un rechazo. Una política aprendida está aguas abajo de un entorno correcto: entrénala contra reglas que nadie ha verificado y aprenderá los fallos de ese entorno, con confianza y de forma invisible, porque realmente está ganando la partida que le entregaron. Una suite de conformidad no es un obstáculo puesto delante del aprendizaje. Es lo que haría que un resultado aprendido significara algo.

Lo que sí se rechaza es más estrecho, y se sigue rechazando. No juega por ti. Todo aquí está en la fase de preparación: construir, entender, practicar, repasar. En el modo Jugador 2 una persona posee la información oculta, la legalidad, la resolución y cada actualización de estado, y ningún resultado del motor mueve nada de eso. No publica porcentajes de victoria, tasas de uso, rankings de tier ni tablas de emparejamiento. Un motor de reglas autoritativo —incluido un cliente digital oficial, si algún día llega— haría esto más útil en lugar de redundante: ese motor sirve al juego, este sirve a la preparación.

La Digital Tools Policy de Riot está abierta a gestores de mazos y herramientas educativas, y dice explícitamente que no aprueba de antemano la ejecución automatizada de reglas ni los simuladores de juego. Ese límite dio forma al diseño antes que la ambición: cada sugerencia de jugada espera la confirmación de una persona. Está hecho para uso de investigación y educativo, y usarlo durante un torneo va contra el reglamento.