Ainda ninguém ensinou uma IA a dominar o timing de resposta de um card game. Estamos tentando.

Por que isso é difícil, e por que quase ninguém fez isso

Jogos de tabuleiro são de informação perfeita. A posição está sobre a mesa, então dá para buscar nela. Card games quebram isso já no primeiro movimento: o deck é aleatório e a mão do adversário está escondida, então a posição atual não é uma coisa só.

A segunda barreira é a que decide quais jogos acabam sendo resolvidos: se o adversário consegue agir durante o seu turno. Hearthstone é onde a pesquisa pública foi mais longe, e o pool de cartas menor é a razão menor. A de verdade é que quase não existe espaço para o adversário agir durante o seu turno, o que faz de um turno uma sequência fechada que dá para explorar até o fim. Mesmo lá, a pesquisa não roda contra o cliente lançado, e sim sobre reimplementações feitas pela comunidade. Alguém precisa escrever as regras como programa antes de existir chão para pisar, e isso vale para todos os jogos desta lista.

Foi do lado de Magic que isso se tentou na maior escala, e o resultado merece ser dito com precisão. Em 2016 o Google DeepMind publicou Latent Predictor Networks for Code Generation, cuja tarefa de benchmark era exatamente esta: ler o texto impresso de uma carta e emitir o código que a implementa. Os alvos eram motores reais — 11.969 cartas de Magic tiradas do XMage em Java, e 533 cartas de Hearthstone tiradas do hearthbreaker em Python. O melhor modelo acertou exatamente 4,8% das cartas de Magic. O BLEU dele foi 61,4: o código que ele escreveu se parecia muito com o código que deveria ter escrito. Esses dois números juntos são o problema inteiro. Plausível e correto são propriedades diferentes, e só uma delas roda.

Isso foi há dez anos, e nada desde então afirmou que essa distância foi fechada. O que existe é escrito à mão e mantido pela comunidade: XMage e Forge do lado de Magic, e o ygo-agent de Yu-Gi-Oh, que só consegue treinar porque por baixo existe o ygopro-core. Benchmarks recentes dos dois jogos, MTG-Causal-RL e PTCG-Bench, mostram que agentes LLM conseguem jogar com desempenho diferente de zero, e nenhum dos dois mostra um desempenho confiável. Os dois colocam um conjunto limitado de arquétipos em um espaço de observação fixo para comparar métodos: um benchmark de pesquisa, não um mundo em que dá para se autojogar.

Riftbound está do lado difícil. Tem corrente, passa prioridade e foco, tem timing de reação, a posição muda entre as ações do outro jogador. Já existem tentativas: há pelo menos um simulador aberto de Riftbound com busca em árvore integrada, e ele encara a resolução de corrente de frente em vez de evitar.

O que nenhum deles tem é uma suíte de conformidade: uma forma de checar, cláusula por cláusula, se o timing implementado é o timing que as regras descrevem, e de dizer quais partes não estão implementadas de jeito nenhum. Sem isso, ilegal e não modelado são a mesma resposta. Para jogar, tanto faz, os dois significam que você não pode fazer aquilo. Mas para qualquer coisa que vá aprender com o ambiente ou citá-lo como evidência, é a diferença entre um resultado e um chute.

Então a barreira nunca foi os modelos não serem inteligentes o suficiente. A barreira é que alguém precisa primeiro transformar as regras em programa. O que mudou desde 2016 é quem faz isso. O núcleo de regras descrito nesta página não foi escrito à mão por uma pessoa: foi escrito por agentes de modelo de linguagem, revisado por um humano e sustentado por uma suíte de conformidade amarrada a números de cláusula. Essa é a tarefa que a DeepMind propôs em 2016, rodando como engenharia comum em vez de um benchmark de uma vez só — e a suíte é o que ocupa o lugar do exact-match contra uma implementação de referência. Aqui isso importa especialmente, porque Riftbound não tem nenhuma implementação autoritativa para conferir.

A outra metade é que o alvo não precisa mais ser vinte mil cartas. Riftbound herda a estrutura de Magic — a corrente, a prioridade, o tempo de reação — então a mecânica difícil está inteira, com uma fração do tamanho impresso. Pequeno o bastante para terminar; estruturado o bastante para que terminar signifique alguma coisa.

A aposta: escopo limitado, com permissão para dizer que não sabe

Não é preciso modelar cada carta. Na prática, um formato usa só uma fração do que foi impresso, e a tradução honesta disso para engenharia é um escopo limitado: implementar as mecânicas que realmente aparecem, e marcar o resto como não modelado.

Então a divisão de trabalho é fixa: o programa é dono da camada mecânica e o modelo raciocina dentro do que sobra dela. Não são as regras traduzidas para um prompt para o modelo ler, e sim as regras executadas de verdade, criando um espaço do qual ele não consegue se safar argumentando.

O estado exato hoje

O objetivo acima está descrito em tamanho real. Esta parte está descrita com exatidão, e as duas coisas não são a mesma. Cada linha aqui é checada por uma suíte de conformidade no repositório; se a suíte mudar, esta página está errada.

• Em funcionamento Núcleo de timing e permissão. Quatro estados de turno, timing de ação e reação, prioridade e foco, itens de corrente pendentes e finalizados. 21 casos executáveis, cada um carregando a cláusula oficial que ele codifica.
• Em funcionamento IR tipada de efeitos. 12 operações mais sequenciamento, alvos, efeitos vinculados, limpeza letal e emissão de gatilhos. Sem condicionais por nome de carta no interpretador: uma carta se compõe de operações tipadas ou não está modelada, e nesse segundo caso o sistema diz isso claramente.
• Em funcionamento Envelope de resultado compartilhado. Cinco resultados: suportado, ilegal, não suportado, decisão necessária, entrada inválida, cada um carregando os limites de cobertura sob os quais foi produzido. Dois dos três sistemas que consomem isso já estão conectados.
• Parcial Pacotes de comportamento de carta. O contrato de cobertura de cláusulas por carta existe e foi validado. Ainda não há nenhum pacote de produção incluído, então para um deck real a resposta honesta continua sendo indisponível, e a ferramenta diz isso em vez de arredondar para cima.
• Em aberto Enumeração de ações legais. Travado pela cobertura de conformidade, não pela coleta de registros de partidas. Essa é a peça que deixaria qualquer coisa a jusante buscar ou aprender.
• Aberto Uma partida que termina. Combate, limpeza, resolução do confronto, controle do campo de batalha e — o item que todo o resto está esperando — resolução de conquista, pontuação e determinação de vitória. Sem um sinal de vitória não há nada contra o que avaliar, então essa única linha trava toda pergunta seguinte sobre como um deck realmente se sai.
• Em aberto Reconstrução de replay e revisão pós-partida. Totalmente especificado e deliberadamente não conectado até que suas condições de ativação sejam cumpridas.

Por que resolvemos construir um núcleo, afinal

O projeto começou como uma base de conhecimento derivada: cada entrada escrita a partir do texto das cartas e da mecânica do jogo em vez de resumida de guias de outras pessoas, o que torna as entradas baratas de regenerar e, por si só, não comprovadas. Então todas as 46 foram checadas contra o jogo estabelecido. Três não precisaram de nenhuma mudança.

A descoberta mais útil não teve nada a ver com uma Lenda. Uma rotina de substituição da lista de banidas trocou uma carta que dá uma runa para cada jogador sem condição por uma que só paga para quem controla o ponto: mesmo domínio, mesmo custo, totalmente legal, e isso teria financiado o adversário em um deck que abre mão do tabuleiro cedo de propósito para ganhar tempo. Quem encontrou isso foi um jogador de fora do projeto, antes de qualquer checagem interna.

Essa auditoria é o motivo de o núcleo existir. A derivação a partir do texto das cartas se sustenta. No momento em que a pergunta vira o que um deck está realmente tentando fazer, ou o que é legal mecanicamente agora, ela para de se sustentar, e essa metade mecânica não dá para derivar, só executar.

A linha que estamos mirando

A IA de Go valia o investimento porque vence qualquer humano. Um card game não tem esse formato, e um jogador sobre-humano não valeria muita coisa mesmo que alguém construísse um. A linha aqui é deliberadamente diferente, e à sua maneira mais difícil:

Aprender a jogar acaba sendo a metade fácil. A metade difícil é montar o deck, ler o formato, e saber o que trocar quando uma carta é banida, exatamente onde a nossa própria rotina de substituição falhou, num deck que tinha todo motivo legal para estar confiante. Essa falha é a cara do problema, não um vexame para esconder.

Se isso um dia vai virar um motor de regras completo ou um sistema de aprendizado, não sabemos. O que está se acumulando nesse meio tempo, estado estruturado, casos de conformidade executáveis, um rastro de evidências, é a base que qualquer um dos dois precisaria.

De onde veio, e para onde vai o que ele produz

Isso não começou como um projeto de IA procurando um uso. Começou como um problema de conteúdo no Riftbound Chronicle, um site de Riftbound em chinês tradicional: escrever um guia de deck significa afirmar como aquele deck realmente joga, e não havia como checar uma afirmação dessas. Em paralelo, os jogadores pediam algo capaz de explicar uma interação de regras e mostrar em que a resposta se apoiava. Deck Coach e Rule Consult são essas duas perguntas, nessa ordem.

O site continua sendo o primeiro usuário em produção, e é isso que impede que tudo isso seja uma demo. Lá os guias de deck têm sua análise de jogo gerada a partir desta base de conhecimento, cada um com um selo explícito de análise por IA e um link para a metodologia. Problemas encontrados ao escrever guias voltam para a skill, e a auditoria acima é o que aconteceu na primeira vez em que esse ciclo foi levado a sério.

O que é recusado, e o que apenas ainda não foi construído

Um motor de regras, um agente de IA e um modelo de jogador treinado são três coisas diferentes. Isto começou como o segundo e desde então escreveu um pedaço delimitado do primeiro. Não há política treinada, nem corpus de autojogo, nem máquina de estados completa, nem motor completo de efeitos de carta.

Isso é uma ordem, não uma recusa. Uma política aprendida fica a jusante de um ambiente correto: treine uma contra regras que ninguém verificou e ela aprende os bugs daquele ambiente — com confiança e de forma invisível, porque ela realmente está ganhando o jogo que lhe foi entregue. Uma suíte de conformidade não é um obstáculo colocado à frente do aprendizado. É o que faria um resultado aprendido significar alguma coisa.

O que de fato é recusado é bem mais estreito, e continua recusado. Ele não joga por você. Tudo aqui está na fase de preparação: construir, entender, praticar, revisar. No modo Jogador 2 uma pessoa detém a informação oculta, a legalidade, a resolução e cada atualização de estado, e nenhum resultado do motor move nada disso. Ele não publica taxas de vitória, taxas de uso, rankings de tier ou tabelas de confronto. Um motor de regras autoritativo — inclusive um cliente digital oficial, se algum dia sair — tornaria isto mais útil em vez de redundante: aquele motor serve ao jogo, este serve à preparação.

A Digital Tools Policy da Riot é aberta a gerenciadores de deck e ferramentas educacionais, e deixa explícito que não pré-aprova execução automatizada de regras nem simuladores de gameplay. Esse limite moldou o design antes da ambição: toda sugestão de jogada espera a confirmação de uma pessoa. Foi feito para uso de pesquisa e educacional, e usar durante um evento vai contra as regras do torneio.