Resumo Técnico: Síntese de Cenas de Jogos Unity Executáveis via LLM Condicionada por Conhecimento em Passagem Única

Declaração do Problema

As demonstrações atuais de Grandes Modelos de Linguagem (LLMs) gerando scripts C# para Unity dependem fortemente de loops de reparo iterativos, onde os modelos regeneram o código até que ele compile. Este fluxo de trabalho confunde o conhecimento paramétrico intrínseco do modelo com o poder corretivo do loop de reparo ou da intervenção humana. Além disso, as avaliações existentes frequentemente utilizam rótulos de gênero instáveis ou linguagem natural livre, que carecem da reprodutibilidade necessária para a pesquisa cumulativa.

Este artigo aborda a seguinte questão: Qual é o teto de capacidade intrínseca da geração de artefatos de jogo executáveis por LLM em passagem única, quando não é permitido feedback humano ou reparo iterativo? O estudo isola o conhecimento armazenado do modelo da expertise de domínio do profissional, tratando o compilador como um portão estrito e objetivo. Se um script não compila na primeira passagem, é uma falha atribuível exclusivamente ao modelo.

Metodologia

Design Experimental

O estudo avalia a geração de Conceitos Jogáveis de Objetivo (GPCs - Goal Playable Concepts) — contrapartes jogáveis de 26 padrões específicos de design de gameplay definidos por Björk e Holopainen. Esses padrões servem como um vocabulário teoricamente fundamentado e reprodutível para o design de jogos, substituindo rótulos de gênero instáveis.

• Escala: 10.400 registros de geração.
• Modelos: Quatro modelos de pesos abertos de diferentes famílias (7B-Qwen2.5, 16B-DeepSeek, 22B-Codestral, 30B-Qwen3).
• Modos de Geração:
  • Estilo Editor (Editor-style): Scripts que constroem cenas no momento da edição usando APIs de UnityEditor.
  • Construtor de Tempo de Execução (Runtime-builder): Scripts que constroem cenas programaticamente no momento do play usando MonoBehaviour (testado apenas no modelo 30B).
• Níveis de Condicionamento: Quatro níveis de condicionamento de Representação Intermediária (IR):
  • Sem Esquema (No Schema): Geração direta a partir da descrição do padrão.
  • Com Esquema (Free/Min/Full): Geração de um IR em JSON primeiro, seguido pela geração de código C#. O rigor do esquema varia desde nomes de campos de nível superior até definições completas de campos e restrições.
• Procedimento: Cada registro é uma única passagem de geração. O script C# gerado é compilado dentro de um projeto Unity pré-construído. Nenhum erro de compilador é enviado de volta ao modelo.

Construção da Taxonomia de Falhas

Os autores categorizam os 99 códigos distintos de erros de compilador C# observados em 90.673 ocorrências de erros em duas classes mutuamente exclusivas:

1. Erros de Fundamentação (Grounding Errors) (18 códigos): Falhas específicas de domínio que exigem conhecimento do motor Unity para serem resolvidas. Envolvem tipos, namespaces e APIs da Unity inventados ou usados incorretamente (ex: CS0246: tipo ou namespace não encontrado; CS1061: não há tal membro).
2. Erros de Higiene (Hygiene Errors) (81 códigos): Defeitos estruturais independentes de domínio, diagnosticáveis sem conhecimento de Unity. Incluem erros sintáticos como pontos e vírgulas ausentes, chaves não correspondentes e variáveis não declaradas (ex: CS1003, CS1002).

Resultados Principais

1. Falha de Compilação Universal

Nenhum script C# gerado compilou em uma cena executável em nenhum dos 10.400 registros. Esta falha uniforme elimina o viés de sobrevivência, permitindo um censo exaustivo dos modos de falha.

2. Composição de Erros e Comportamento do Modelo

• Distribuição de Fundamentação vs. Higiene: A divisão entre erros de Fundamentação e Higiene varia significamente conforme o padrão de objetivo e a configuração do modelo.
  • Padrões de Alta Fundamentação: Conceitos vinculados às APIs de percepção e física da Unity (ex: Stealth, Rescue, Exploration, Survive) falham predominantemente com erros de Fundamentação. O modelo inventa componentes de engine não existentes (ex: GuardAI, Pathfinding) para satisfazer a semântica do design.
  • Padrões de Alta Higiene: Conceitos redutíveis à manipulação de estado geral (ex: Capture, Collection) falham predominantemente com erros de Higiene. Os scripts gerados colapsam estruturalmente (erros de sintaxe) antes de atingirem a camada onde o conhecimento da Unity é testado.
• Escala e Identidade do Modelo: O aumento do tamanho do modelo (de 7B para 30B) não resulta em uma cena executável. Em vez disso, altera a composição da falha. Modelos maiores (como o 30B-Qwen3-Ed) alcançam o compilador com mais frequência e falham na camada de Fundamentação (falta de conhecimento de API), enquanto modelos menores frequentemente falham no portão de formato (rejeição pelo sanitizador) ou na camada de Higiene (sintaxe).
• Efeitos do Condicionamento de IR: O condicionamento de esquema mais rigoroso não resolve as falhas, mas as reloca.
  • Para modelos menores (7B, 16B), esquemas rigorosos aumentam as taxas de rejeição pelo sanitizador (até 89%), impedindo que o código chegue ao compilador.
  • Para modelos maiores (22B, 30B-Ed), esquemas mais rigorosos melhoram a conformidade de formato, permitindo que mais registros cheguem ao compilador. No entanto, isso desloca o perfil de erro para erros de Fundamentação, pois o modelo é forçado a produzir código sintaticamente válido que ainda carece de referências corretas da engine.
• Modo de Geração: Alternar do modo Estilo Editor para o modo Construtor de Tempo de Execução (testado no 30B) redistribui os erros, mas não elimina as falhas de Fundamentação. Em alguns casos (ex: Collection), o modo de Tempo de Execução introduziu picos severos de Higiene sem melhorar o sucesso de compilação.

3. Perfis de Erro por Padrão

O estudo estabelece uma ordenação empírica dos 26 padrões de objetivo com base no conhecimento da engine que sua instanciação exige.

• Stealth (participação de Fundamentação ~0.98 em algumas configurações) falha principalmente porque o modelo inventa tipos específicos da engine para visão e detecção que não existem.
• Capture (participação de Fundamentação ~0.0 em algumas configurações) falha principalmente devido a erros de sintaxe estrutural, pois a lógica pode ser expressa em C# puro sem APIs específicas da engine.

Significância e Alegações

O artigo alega fornecer o primeiro censo sistemático dos modos de falha de LLMs na geração de código acoplado a engines na granularidade de erros de compilador individuais. Suas principais contribuições são:

1. Uma Taxonomia de Fundamentação/Higiene: Uma distinção formal entre erros de domínio específico (conhecimento da engine) e independentes de domínio (estruturais), derivados de 90.673 diagnósticos de compilador observados.
2. Uma Lente de Complexidade de Design Baseada em Erros: O estudo demonstra que a complexidade semântica de um conceito de gameplay pode ser empiricamente ordenada pelo tipo de erro que ela provoca. Padrões que exigem APIs específicas da engine (percepção, física) expõem a falta de conhecimento paramétrico da engine pelo modelo, enquanto padrões que dependem de lógica geral expõem fraquezas de geração estrutural.
3. O Teto da Passagem Única: As descobertas estabelecem que, dentro do nível de pesos abertos de 7B–30B, o gargalo para a geração de passagem única é o conhecimento específico da engine ausente, não a escala do modelo, o modo de geração ou o condicionamento estrutural.
4. Diagnóstico Prático para Designers: Os perfis de erro oferecem um guia concreto para designers e desenvolvedores de jogos. Eles indicam quais conceitos de gameplay (ex: Stealth) estão atualmente além do alcance da geração de passagem única sem auxílio e que requerem suporte de conhecimento externo da engine (ex: geração aumentada por recuperação - RAG ou fine-tuning), versus quais conceitos (ex: Capture) podem ser passíveis de pós-processamento sintático ou decodificação guiada por gramática.

Os autores concluem que, embora os loops de reparo iterativos sejam produtivos na prática, eles mascaram as limitações intrínsecas dos LLMs atuais. A avaliação de passagem única revela que, sem a injeção de conhecimento externo da engine, os modelos atuais não conseguem sintetizar cenas Unity executáveis, independentemente da complexidade do padrão de design ou do tamanho do modelo.