💬 NLP

GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?

Este artigo apresenta o GameCraft-Bench, um benchmark de 140 tarefas baseadas em Godot projetado para avaliar a capacidade de agentes de codificação de gerar jogos completos e jogáveis de ponta a ponta, revelando que os modelos de fronteira atuais lutam significativamente para alcançar a completude de artefatos e a coerência interativa, apesar de implementarem mecânicas reconhecíveis.

Autores originais: Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan

Publicado 2026-06-17

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan Liu, Xin Lai, Chenxin Li, Yiduo Guo, Zhexin Zhang, Xinyuan Wang, Tianyi Bai, Ziniu Li, Benyou Wang

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você contrata um robô chef e dá a ele uma receita para um jantar complexo de vários pratos. Você não quer apenas que o robô escreva a receita em um pedaço de papel; você quer que ele realmente cozinhe a refeição, monte o prato e a sirva para que você possa dar uma mordida e saborear.

Isso é essencialmente o que este artigo, GameCraft-Bench, aborda. É um teste para ver se os agentes de codificação de IA conseguem realmente "cozinhar" um videogame jogável do zero, em vez de apenas escrever o código para um.

Aqui está uma análise das principais ideias do artigo usando analogias simples:

1. O Problema: "A Receita vs. A Refeição"

No passado, quando testávamos a IA em codificação, verificávamos principalmente se o código parecia correto no papel (como verificar se os ingredientes da receita estavam listados corretamente). Mas para videogames, olhar o código não é suficiente. Um jogo precisa rodar, os gráficos precisam aparecer e o jogador precisa ser capaz de mover um personagem e ver o que acontece.

Os autores argumentam que, para testar verdadeiramente a habilidade de uma IA em fazer um jogo, precisamos de três coisas:

A Cozinha Real (Aterramento no Motor/Engine Grounding): A IA deve trabalhar em um motor de jogo real (eles usaram o Godot, uma ferramenta gratuita popular), não em uma versão falsa ou simplificada. É como pedir ao chef para usar um fogão de verdade, não um de brinquedo.
A Refeição Completa (Completude de Artefatos/Artifact Completeness): A IA não pode te dar apenas um ingrediente (como um script para um personagem pulando). Ela deve entregar o jogo inteiro, totalmente empacotado e pronto para ser lançado. Sem partes faltando.
O Teste de Sabor (Verificação Interativa/Interactive Verification): Você não pode apenas olhar para o prato acabado; você tem que comê-lo. O jogo deve ser jogado. O sucesso da IA é julgado por rodar o jogo, pressionar botões e ver se o mundo reage corretamente.

2. O Teste: GameCraft-Bench

Os pesquisadores construíram uma grande cozinha de testes chamada GameCraft-Bench.

O Menu: Eles criaram 140 desafios diferentes em 15 tipos de jogos (como jogos de plataforma, jogos de corrida, jogos de estratégia e jogos de terror).
O Processo:
1. Eles dão à IA uma descrição em linguagem natural (ex: "Faça um jogo de plataforma 2D onde você coleta moedas e evita inimigos").
2. A IA constrói o jogo no motor Godot.
3. A IA também deve gravar um "traço de demonstração" (demo trace) — um roteiro de vídeo mostrando exatamente como jogar o jogo para provar que funciona.
4. Um sistema de computador "joga" o jogo usando esse roteiro, grava o vídeo e, em seguida, um juiz de IA inteligente assiste ao vídeo para dar uma nota.

3. Os Resultados: "Bom em Escrever, Ruim em Cozinhar"

Os resultados foram surpreendentes e um pouco humildes para a comunidade de IA. Mesmo os modelos de IA mais inteligentes e avançados (como Opus-4.7 e GPT-5.5) tiveram dificuldades.

A Pontuação: A melhor IA obteve apenas cerca de 41% no teste. A maioria pontuou abaixo de 40%.
O que fizeram bem: As IAs foram decentes em construir o "loop central" (core loop). Se você pedisse um jogo onde um personagem pula, o personagem geralmente conseguia pular. Elas conseguiam construir as partes do motor.
Onde falharam: Elas tiveram dificuldade em juntar tudo em uma experiência completa.
- Conteúdo Ausente: Muitas vezes criavam um jogo que era curto demais ou que não tinha níveis para progredir.
- Visuais Quebrados: Os gráficos podiam até estar lá, mas não faziam sentido (ex: o jogador não consegue ver o inimigo, ou a interface/UI está quebrada).
- A Lacuna da "Demonstração": Muitas IAs construíram um jogo, mas esqueceram de gravar o "traço de demonstração" necessário para provar que funcionava. É como o chef cozinhar a refeição, mas esquecer de montar o prato para o juiz.

4. Descobertas Principais (O "Porquê")

O artigo investigou por que as IAs falharam:

Ver é Acreditar: As IAs que tiveram o melhor desempenho foram aquelas que olhavam para a tela do jogo enquanto o construíam. Elas tratavam a saída visual como uma ferramenta de depuração (debugging). Se o personagem parecia estranho, elas corrigiam o código. As IAs que apenas escreviam código sem olhar para a tela cometiam mais erros.
Ocupado não é Melhor: Um modelo de IA (MiMo) escreveu muito código e executou muitos comandos, mas não obteve uma pontuação maior. Foi como um chef picando vegetais furiosamente, mas nunca realmente cozinhando o prato. Fazer mais trabalho não garante um resultado melhor se você perder a etapa final.
Habilidades Diferentes: Fazer a mecânica de "pulo" funcionar (Mecânica) é diferente de fazer o jogo parecer bonito (Arte) ou ter níveis suficientes (Conteúdo). Uma IA pode ser boa em uma coisa, mas ruim em outras. Elas não estão todas interligadas.

5. A Conclusão

O artigo conclui que, embora a IA esteja ficando muito boa em escrever código, a criação de jogos de ponta a ponta ainda é um desafio massivo.

As IAs atuais podem construir "fragmentos" de jogos ou protótipos simples, mas ainda não conseguem, de forma confiável, pegar uma ideia criativa de um humano e transformá-la em um pacote de jogo polido, jogável e completo por conta própria. A lacuna entre "escrever um código que parece correto" e "entregar um sistema que funciona" ainda é muito ampla.

Em resumo: A IA consegue escrever a receita, mas ainda está aprendendo a cozinhar a refeição completa e serví-la ao cliente.

Resumo Técnico: GameCraft-Bench

Definição do Problema

O artigo aborda o desafio da geração de jogos de ponta a ponta (end-to-end game generation), definida como o processo onde um agente autônomo transforma uma especificação de jogo em linguagem natural ( $s$ ) em um sistema interativo jogável ( $G$ ) dentro de um ambiente específico de desenvolvimento e execução ( $E$ ). Diferente das tarefas de codificação tradicionais, onde o sucesso é medido pela correção do código ou testes unitários, a geração de jogos exige a produção de um artefato coerente e lançável que responda aos comandos do jogador em tempo real.

Os autores argumentam que os métodos de avaliação existentes falham em capturar toda a complexidade desta tarefa. Os benchmarks atuais frequentemente focam em:

Jogos baseados na web que carecem da complexidade de ambientes de motores de jogo reais.
Edições localizadas de projetos existentes em vez de construção completa.
Inspeção estática de código ou ativos (assets), o que falha em verificar o comportamento real da jogabilidade.

Para abordar isso, o artigo formaliza a geração de jogos de ponta a ponta como um mapeamento $(s, E) \mapsto G$ e identifica três desideratas críticas para um benchmark válido:

Aterramento no Motor (Engine Grounding): O desenvolvimento deve ocorrer dentro de um motor de jogo real com sua documentação nativa, ativos e restrições de tempo de execução.
Completude do Artefato: O agente deve entregar um projeto de jogo completo e lançável (incluindo metadados, cenas, scripts e ativos), não apenas códigos parciais ou protótipos.
Verificação Interativa: A avaliação deve ser baseada em interações observadas de jogabilidade (ações do jogador e respostas do sistema) em vez de análise estática de código.

Metodologia: GameCraft-Bench

Os autores instanciam essas desideratas no GameCraft-Bench, um benchmark projetado para avaliar agentes de codificação no motor Godot 4.

1. Suíte de Tarefas

Escala: 140 tarefas em 15 famílias de jogos distintas (ex: Plataforma, Estratégia, Roguelike, Visual Novel, Tycoon).
Estrutura da Tarefa: Cada tarefa $\tau = (s, E, \rho)$ $τ = (s, E, ρ)$ consiste em:
- $s$ : Uma especificação em linguagem natural descrevendo a fantasia do jogador, o core loop e as mecânicas.
- $E$ : Um ambiente baseado em Godot fornecendo um espaço de trabalho, ferramentas e ativos compartilhados.
- $\rho$ : Uma rubrica de avaliação oculta usada pelo verificador.

2. Pipeline de Avaliação

O benchmark emprega um pipeline de cinco estágios (Figura 5):

Empacotamento da Tarefa: O agente recebe a especificação e o ambiente.
Geração pelo Agente: O agente produz um projeto Godot completo ( $G$ ) e um conjunto de traços de interação reproduzíveis ( $\Pi$ ) contendo eventos de teclado/mouse temporizados.
Portão de Build (Build Gate): O verificador tenta lançar o projeto. Se o build falhar ou os traços forem impossíveis de analisar, a pontuação é zero.
Reprodução (Replay): O verificador reproduz os traços em uma instância headless do Godot, gravando vídeos de jogabilidade e amostrando quadros (2 FPS).
Pontuação: Um juiz multimodal pontua a evidência de jogabilidade contra a rubrica oculta em quatro categorias:
- Mecânicas Principais (M): Regras, transições de estado e objetivos.
- Profundidade de Conteúdo (D): Progressão, variedade e escopo de tempo de execução.
- Visuais Funcionais (V): Legibilidade, feedback e estabilidade de UI.
- Arte e Apresentação (A): Coerência estética e sensação de "autoria".
- Fórmula da Pontuação Final: $Score = BUILD \times (w_M M + w_D D + w_V V + w_A A)$ , com pesos priorizando Profundidade de Conteúdo e Apresentação.

3. Seleção do Motor

O Godot foi selecionado por sua natureza de código aberto, configuração leve, fluxo de trabalho 2D nativo e capacidades de execução via linha de comando/headless, que são essenciais para uma avaliação automatizada reprodutível.

Resultados Principais

Os autores avaliaram sete configurações de agentes de codificação de fronteira (incluindo Claude Code, Codex, Kimi Code e Code Buddy) no benchmark completo.

Desempenho Geral: A geração de jogos de ponta a ponta permanece altamente não resolvida. O agente mais forte (Claude Code com Opus-4.7) alcançou uma pontuação geral de 41,46%. A maioria dos outros agentes pontuou abaixo de 40%, com alguns (ex: DeepSeek-V4-Pro) atingindo apenas 2,15%.
Divisão por Categoria:
- Mecânicas: Os agentes tiveram um desempenho relativamente melhor aqui (ex: Opus-4.7 marcou 55,34%), criando loops de interação local reconhecíveis.
- Conteúdo e Apresentação: As pontuações caíram significativamente para Profundidade de Conteúdo e Arte/Apresentação, indicando que os agentes têm dificuldade em montar mecânicas em sistemas completos, polidos e coerentes.
Execução vs. Jogabilidade: Embora muitos agentes tenham alcançado altas "Taxas de Sucesso de Build" (lançando o jogo), eles frequentemente falharam em fornecer traços de reprodução válidos ou falharam em realizar a jogabilidade pretendida nos traços, levando a pontuações baixas.

Achados Diagnósticos

Feedback Visual é Crítico: Agentes que utilizaram inspeções de tela renderizadas (ex: Kimi-K2.6) mostraram melhores capacidades de depuração, corrigindo problemas como UI desalinhada ou layouts de nível quebrados que seriam invisíveis apenas no código fonte.
Uso de Ferramentas $\neq$ Qualidade: Altos volumes de chamadas de ferramentas (particularmente comandos de shell) não correlacionaram com pontuações mais altas. O sucesso dependeu de fechar o ciclo entre o build, o fornecimento de traços de demonstração e a garantia de jogabilidade.
Fatoração Parcial: O desempenho em mecânica, conteúdo e visuais teve apenas uma correlação moderada. Um agente pode produzir um jogo mecanicamente funcional que carece de profundidade de conteúdo ou polimento visual.

Significância e Alegações

O artigo afirma que o GameCraft-Bench estabelece um novo padrão para avaliar agentes de software criativos ao mudar o foco da correção do código para a correção do sistema interativo.

Contrato do Benchmark: Ele define um contrato de benchmark exigindo que os agentes operem em um motor real, entreguem artefatos completos e sejam julgados via interação.
Limitações Atuais: Os resultados demonstram que os agentes de fronteira atuais são capazes de gerar "fragmentos" de software de jogo, mas ainda não conseguem transformar de forma confiável especificações em linguagem natural em experiências de jogo completas, coerentes e visualmente consistentes.
Paradigma de Avaliação: O trabalho argumenta que avaliar sistemas criativos executáveis requer uma avaliação fundamentada na interação (jogabilidade) que vai além da inspeção estática de código, sucesso de build ou plausibilidade visual isolada.

Os autores enfatizam que, embora o benchmark seja atualmente limitado a jogos 2D em Godot e avaliação visual (excluindo áudio), ele fornece um framework rigoroso para diagnosticar as lacunas específicas nas capacidades dos agentes atuais de construir sistemas interativos complexos.