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, no solo porque el pool de cartas es más pequeño, sino porque el rival casi nunca puede interrumpirte, y porque la implementación publicada es en sí misma el único motor de reglas correcto, así que un investigador nunca tiene que reinterpretar las reglas para conseguir un entorno.

Del lado de Magic no existe nada parecido. Las referencias más cercanas están construidas por la comunidad: Forge de MTG, un motor de reglas no oficial mantenido desde hace mucho tiempo, 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.

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 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.

Qué no es esto

Un motor de reglas, un agente de IA y un modelo de jugador entrenado son tres cosas distintas. Este proyecto empezó como la segunda y desde entonces ha escrito una parte acotada de la primera. No es la tercera, y no finge serlo: no hay máquina de estados completa, ni motor completo de efectos de cartas, ni datos de autojuego, ni política entrenada.

Tampoco juega. Todo esto se queda en la fase de preparación: construir, entender, practicar, revisar. Un motor de reglas con autoridad, incluido un cliente digital oficial si alguna vez llega a existir, haría este proyecto más útil en vez de redundante: ese motor sirve para jugar, este sirve para prepararse.

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.