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, não só porque o pool de cartas é menor, mas porque o adversário quase nunca consegue te interromper, e porque a implementação lançada é ela mesma o único motor de regras correto, então quem pesquisa nunca precisa reinterpretar as regras para ter um ambiente.

Do lado de Magic não existe nada assim. As referências mais próximas são feitas pela comunidade: o Forge de MTG, um motor de regras não oficial mantido há muito tempo, 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.

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

O que isso não é

Um motor de regras, um agente de IA e um modelo de jogador treinado são três coisas diferentes. Este projeto começou como o segundo e desde então escreveu uma parte limitada do primeiro. Não é o terceiro, e não finge ser: não há máquina de estados completa, nem motor completo de efeitos de carta, nem dados de auto-jogo, nem política treinada.

Também não joga sozinho. Tudo isso fica na fase de preparação: construir, entender, praticar, revisar. Um motor de regras com autoridade, incluindo um cliente digital oficial caso um dia exista, tornaria este projeto mais útil em vez de redundante: aquele motor serve para jogar, este serve para preparar.

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.