Oito agentes do VibeGame montam um jogo 2D a partir de um prompt e superam concorrentes no GameCraft-Bench

Equipes do PRLab, da Universidade de Nanquim, e do S-Lab, da Universidade Tecnológica de Nanyang, publicaram o VibeGame, um framework que cria um projeto de jogo 2D completo a partir de uma descrição em texto e de imagens de referência opcionais. O projeto inclui código, cenas, animação, física e configuração. Por dentro, trabalha uma equipe de oito agentes especializados, e o projeto em si fica em arquivos de texto que o agente pode ler e editar sem um editor gráfico. Em um subconjunto do GameCraft-Bench, no modo em que o próprio sistema desenha a parte gráfica, o VibeGame superou outros arcabouços de agentes rodando sobre o mesmo modelo base, incluindo o GPT-6.1-Sol.

Por que jogos são mais difíceis que código comum

Os autores partem da ideia de que o jogo é um dos tipos de software mais exigentes. Ele precisa sustentar um mundo interativo em tempo real, manter um estilo visual coeso e respeitar regras equilibradas. Muitos erros só aparecem durante a partida: a entrada do jogador, a física, a animação e a lógica de interação se combinam de um jeito que faz um projeto formalmente correto quebrar em pleno funcionamento.

Na avaliação dos autores, as abordagens existentes resolvem o problema só em parte. Modelos de mundo como o Genie geram experiências interativas a partir de vídeo, mas não entregam código-fonte editável. LLMs integradas a motores comerciais, como o DreamGarden para Unreal, esbarram no estado do projeto, espalhado por interfaces gráficas e arquivos binários. Já muitos sistemas de agentes só testam o jogo no final ou se limitam a confirmar que ele compila e executa.

Um motor que os agentes conseguem ler

A base é o Phaser, framework web em que projetos inteiros se expressam em texto. Para que os agentes não criem bagunça, os autores acrescentaram estrutura. O jogo é um conjunto de cenas, com configuração em arquivos JSON com verificação de tipos. Cada cena é uma hierarquia de nós, e cada nó reúne aparência, geometria de colisão, scripts de comportamento e configurações. Nós compartilhados ficam em arquivos separados. O esquema detecta referências quebradas, como a de um asset inexistente, antes mesmo da execução.

A segunda característica é o controle quadro a quadro. O agente pode pausar o jogo, avançá-lo por um número definido de quadros, ler ou alterar a posição e a velocidade dos nós, enviar um comando semântico como "apertar pulo" e tirar um screenshot. Assim, a verificação acontece no ritmo do agente, e não em tempo real: quadro a quadro, por scripts ou bots. A terceira é que o código-fonte completo e não minificado do motor é colocado na pasta do projeto, para que o agente consulte as APIs exatas, e não uma documentação desatualizada.

Uma equipe que discute consigo mesma

Os papéis são distribuídos assim: orquestrador, designer, artista, arquiteto, programador, auditor, jogador e revisor. O designer transforma um pedido como "luta de chefe no estilo Hollow Knight" em um documento de design com mecânicas, progressão e sistemas numéricos. O artista usa modelos de geração de imagens, incluindo o GPT-Image-2, para criar concept art e assets, remover fundos e normalizar tamanhos. Depois que o usuário confirma, o documento e o conceito passam a ser a referência comum.

O código passa por uma cadeia formada por arquiteto, programador, auditor e jogador. O auditor faz a checagem estática do resultado com ferramentas de consistência do motor. O jogador executa o jogo pela interface de runtime e usa um modelo de visão para avaliar se a imagem corresponde à ideia original. Uma subtarefa só é considerada pronta depois das duas verificações. No fim, um revisor independente avalia o projeto pelo comportamento do jogo, pela completude visual e pela coerência, além da sensação de controle. Se algo não passa, ele devolve o projeto com os motivos, e o orquestrador os converte em tarefas de correção.

Autoevolução sem treinamento

Depois que um projeto é aprovado, o sistema extrai dele experiência reutilizável de três tipos: esqueletos, módulos e contratos de interação. O esqueleto é um modelo de projeto executável para um gênero: sem assets, mas com a arquitetura do código, valores configurados e o fluxo de cenas. Novos projetos adaptam e revalidam esse material, em vez de copiá-lo às cegas. O que não foi verificado e é específico de um projeto permanece isolado. Os pesos do modelo não mudam nesse processo.

Os estudos de ablação mostram que remover o motor nativo para IA ou os revisores adversariais reduz de forma significativa a pontuação geral. A experiência extraída por um modelo mais forte ajuda a melhorar o resultado de um modelo mais fraco.

O que levar em conta

A avaliação usa um subconjunto do GameCraft-Bench e quatro eixos: mecânicas básicas, profundidade de conteúdo, parte visual funcional e apresentação artística. O resultado é uma pontuação ponderada, que consta no apêndice do artigo. O texto disponível não traz valores concretos, então não é possível verificar o tamanho da vantagem sobre os concorrentes.

A comparação com outros arcabouços foi feita pelos próprios autores. O framework se limita a 2D e depende do Phaser. Para desenvolvedores, a conclusão é prática: a representação textual do projeto, o controle do runtime quadro a quadro e um papel independente de revisor são técnicas que podem ser levadas a outros pipelines de agentes.

O código e as demos estão publicados no site do projeto e em um repositório no GitHub.