A IA consegue construir um quebra-cabeça inteiro? ScriptDoctor e seu ciclo de gerar-testar-reparar

Introdução

Prazer — esta é a resenha de artigo de Fukai. Eu leio artigos acadêmicos sobre quebra-cabeças e game design, traduzindo o jargão em palavras do dia a dia, e percorro cada um em cinco partes: problema, método, achados, onde se pode usar e limitações. Para a primeira edição, escolhi um estudo que pede a uma IA que construa um quebra-cabeça inteiro.

O artigo é o ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search, publicado no arXiv em 6 de junho de 2025. É coescrito por sete pesquisadores — liderados por Sam Earle, da New York University, com colegas da University of Malta, da University of the Witwatersrand e da Microsoft — e foi submetido como artigo curto à IEEE Conference on Games (CoG). Um dos autores, Julian Togelius, está entre as figuras mais conhecidas da pesquisa em geração procedural de conteúdo.

Por que este artigo primeiro? Porque o tema é PuzzleScript. Lançada por Stephen Lavelle (increpare) em 2013, essa minúscula linguagem específica de domínio descreve um jogo inteiro ao estilo Sokoban — regras, sprites e níveis — em algumas dezenas de linhas de texto, e desenvolvedores indie do mundo todo, Hempuli, de Baba Is You, entre eles, a usaram para prototipagem. Um mundo familiar aos leitores deste site é, aqui, o laboratório.

O problema — como verificar que 'uma IA fez um jogo'?

Role os feeds sociais certos e você encontrará um sem-fim de posts do tipo 'mandei uma IA fazer um jogo'. Os autores partem de uma pergunta simples sobre esse espetáculo: é um bom jogo? É mais do que uma leve releitura de algo nos dados de treinamento? E há alguma maneira de verificar que não seja um humano sentar para jogar cada um?

Para jogos comuns escritos em JavaScript ou Python, não existe essencialmente maneira de uma máquina jogar e avaliar a qualidade automaticamente. Enquanto a avaliação depender de humanos, os experimentos não escalam, e não podemos estudar sistematicamente como formular prompts para jogos melhores. Antes de perguntar se a IA consegue fazer jogos, falta-nos uma régua para saber se ela fez. É esse o problema que este artigo enfrenta.

Então os autores escolheram o PuzzleScript como um pequeno mundo experimental — assim como os biólogos estudam a E. coli ou as moscas-das-frutas como 'organismos modelo'. Três razões. Primeiro, um jogo inteiro cabe num texto curto, o que combina com a saída de um modelo de linguagem. Segundo, o motor é leve, com entrada e saída padronizadas, então as máquinas podem jogar milhares de partidas. Terceiro, o corpo de jogos PuzzleScript publicados é pequeno o bastante para se conhecer aproximadamente por inteiro — um ambiente raro em que 'isto é de fato novo?' poderá um dia ser perguntado a sério.

O método — um ciclo de geração, inspeção e reparo

O ScriptDoctor é, em uma frase, um ciclo de gerar-inspecionar-reparar. Um LLM (GPT-4o, o1 e o3-mini nos experimentos) escreve um programa PuzzleScript completo — definições de objetos, regras, condições de vitória, níveis. Seu prompt é recheado com a documentação do PuzzleScript, exemplos extraídos de uma base de dados de 610 jogos feitos por humanos e ideias de design produzidas por um agente separado de 'brainstorming'.

A inspeção acontece em duas etapas. Primeiro, a compilação: o código gerado passa pelo motor do PuzzleScript, e quaisquer erros ou avisos são devolvidos direto ao LLM. Um analisador construído a partir de uma gramática livre de contexto do PuzzleScript (escrito com a biblioteca Python Lark) sinaliza também os erros de sintaxe.

Se o código compila, vem a etapa dois: a máquina de fato joga. A busca em largura (BFS) — uma busca metódica, quase exaustiva, que verifica primeiro os lances rasos — explora cada nível em até um milhão de estados únicos e reporta três números: se é solúvel, qual o comprimento da solução e quantos estados foram examinados para encontrá-la. Esses números são realimentados ao LLM via servidor.

O LLM recebe dez chances. Uma tentativa tem sucesso no momento em que todo nível admite uma solução com mais de dez lances; do contrário, mostra-se ao modelo o código anterior e os resultados da inspeção e pede-se que ele reescreva. A filosofia de design: pegar o ciclo construir-jogar-corrigir do designer humano e rodá-lo, tanto quanto possível, só em máquinas.

Achados — exemplos ajudam, modelos de raciocínio vencem, e 'quebrado mas interessante'

O resultado mais claro primeiro. Sem exemplos feitos por humanos (zero-shot), apenas 30% dos jogos do GPT-4o compilaram, e 0% tinha um nível que o agente de busca conseguisse resolver. Coloque exemplos no prompt (few-shot), e a compilação salta para 70–80%, com mais da metade dos jogos ganhando níveis solúveis. O PuzzleScript não é uma linguagem importante como o Python, então exemplos trabalhados importam de forma decisiva — os autores observam que isso não os surpreendeu.

A comparação entre modelos é igualmente interessante. Sob as mesmas condições few-shot, de 10 mil tokens, dez jogos cada: o GPT-4o compilou 67% das vezes, o modelo de raciocínio o1 87%, o o3-mini 93%. Em 'todos os níveis solúveis', os 20% do o3-mini foram o melhor. Modelos que pensam antes de escrever são melhores em montar regras e níveis coerentes. Enquanto isso, enfiar mais exemplos no prompt atingiu retornos decrescentes em torno de 30.000 tokens.

A peça de exibição do artigo é o 'Unconventional PushPull', gerado pelo o1. Sobre o familiar empurrar-e-puxar, ele acrescenta uma reviravolta — quando o caminho do jogador está bloqueado, uma caixa desliza um quadrado a mais — além de um interruptor e um portão. A solução mais curta tem 34 lances, e até a metódica BFS teve de examinar 1.006 estados para encontrá-la. O veredito dos autores: capcioso, mas sensato para um jogador humano.

Nem tudo é boa notícia, porém, e os autores são francos: os jogos gerados mais complexos tendiam a ser complexos 'apesar de, ou até em decorrência de' mecânicas quebradas. Num jogo gerado em que um mago pode se teletransportar através de paredes ou destruí-las, interações presumivelmente não intencionais acabaram produzindo as soluções mais interessantes. E os sprites gerados eram abstratos — às vezes literalmente invisíveis — a ponto de as figuras do artigo trocarem por arte de jogos feitos por humanos. Escrever regras é uma coisa; alinhar aparência e intenção ainda está longe.

Onde se pode usar — o que levar para desenvolvedores e jogadores

Para desenvolvedores indie, o aprendizado mais transponível não é a IA em si, mas o hábito de design da verificação automatizada por solucionador. Alimente seus níveis num algoritmo de busca e olhe o comprimento da solução e o esforço de busca — uma checagem de qualidade que você pode copiar hoje, sem LLM nenhum. Um nível com solução de três lances, ou um que nem a força bruta consegue quebrar, aparece nos dados antes que um testador o veja.

Se você quiser mesmo usá-lo à moda ScriptDoctor, pense nele como uma fábrica de rascunhos. O ciclo de autorreparo de dez rodadas é uma automação grosseira do construir-jogar-corrigir. No primeiro dia de uma game jam, peça que ele proponha dez reviravoltas de regra, jogue nove fora, lapide uma. O que o Unconventional PushPull sugere é que essa uma pode ser surpreendentemente decente.

Para os jogadores, o artigo se lê como uma régua para a distância entre solúvel e divertido. As contagens de nós da BFS medem a dificuldade para um computador, o que não é a mesma coisa que o prazer humano do insight. Dito ao contrário: o que quer que os grandes quebra-cabeças feitos por humanos tenham — intenção comunicada, despiste engendrado, o clique de uma solução que faz sentido — se destaca em contorno justamente porque os instrumentos deste artigo não conseguem vê-lo.

No contexto da pesquisa, os autores propõem usar a saída do pipeline — jogos garantidamente compiláveis e solúveis — como um conjunto de dados para afinar modelos menores. Um gerador com um verificador embutido também serve de fábrica de material didático.

Limitações — o que este artigo não mede

As formalidades primeiro. Este é um artigo curto de cinco páginas, e na época de sua publicação no arXiv estava no estágio de 'submetido à CoG'. Cada condição experimental cobre apenas de 10 a 20 jogos gerados, então as tabelas são melhor lidas como tendências do que como comparações rigorosas.

Em seguida, a limitação que mais importa. O estudo mede se os jogos compilam, se são solúveis e se as soluções são longas — não se são divertidos. Não há avaliação por jogadores humanos, e os próprios autores observam que muitos jogos amados feitos por humanos têm soluções curtas e ainda assim permanecem interessantes. O comprimento da solução e o esforço de busca são apenas proxies grosseiros para a diversão.

As fraquezas técnicas também são expostas com clareza. Os LLMs têm dificuldade com o raciocínio espacial que o design de níveis exige e, deixados por conta própria, tendem a produzir níveis com soluções curtas demais. Pedidos a acrescentar desafio, muitas vezes apenas esticam o nível por algumas fileiras ou espalham alguns obstáculos. O sistema tampouco consegue diagnosticar por conta própria que uma mecânica está quebrada em relação à intenção; como trabalho futuro, os autores sugerem mostrar imagens de gameplay a um modelo de visão-linguagem para detectar tais falhas.

Por fim, a pergunta de abertura — isto é só uma releitura dos dados de treinamento? — também não é, na verdade, respondida aqui. Medir a semelhança em relação aos 610 jogos existentes fica como trabalho futuro, e o real proveito de ter escolhido o PuzzleScript, um mundo cujo corpus publicado inteiro é aproximadamente conhecível, só virá quando essa checagem for construída.

Referências

・ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search (Sam Earle, Ahmed Khalifa, Muhammad Umair Nasir, Zehua Jiang, Graham Todd, Andrzej Banburski-Fahey, Julian Togelius; arXiv:2506.06524, publicado em 6 de junho de 2025; CC BY 4.0)

・PuzzleScript (a linguagem de script para quebra-cabeças de Stephen Lavelle, lançada em 2013; código-fonte no GitHub)

・PuzzleScript games database (fonte dos 610 jogos feitos por humanos que o artigo usa como exemplos few-shot)

・Trabalho relacionado: GAVEL: Generating Games via Evolution and Language Models (Todd et al., 2024 — um sistema anterior que combina busca evolutiva e LLMs no framework Ludii)

Para encerrar

A conversa sobre IA fazendo jogos tende a oscilar entre o hype e o pavor. O que eu gosto neste artigo é que ele para aquém de ambos e constrói antes o aparelho de medição. O que o aparelho consegue ver, até agora, é apenas 'compila, e a força bruta consegue resolver' — a maior parte do que de fato desfrutamos num quebra-cabeça não registra. Mas o contorno do que não se pode medir só ficou claro porque alguém tentou medir.

É isso para a primeira edição da resenha de artigo de Fukai. Da próxima vez, outro estudo sobre o design da brincadeira, lido pelas mesmas cinco lentes.