Engines de jogos nativas de IA estão sendo lançadas e não se parecem em nada com a Unity
Por Oleg Sidorkin, CTO da Cinevva
Três engines de jogos surgiram em março com arquiteturas diferentes de tudo o que existe na linhagem Unity/Unreal/Godot. Elas não têm editores visuais. Não são otimizadas para humanos navegando por menus. Foram desenvolvidas desde o início para que agentes de IA leiam, escrevam e controlem o estado do jogo.
Isto não é a “Unity com uma aba de IA”. É uma espécie diferente de engine.
A IA já está mudando os fluxos de trabalho de desenvolvimento de jogos 3D. A próxima camada é a das engines.
As três engines
A nAIVE Engine é de código aberto, escrita em Rust e usa WebGPU para renderização. Hot reload em menos de um segundo: shaders em menos de 200 ms, cenas em menos de 100 ms e scripts em menos de 50 ms. Cenas, pipelines e materiais são definidos em YAML, o que permite aos LLMs lê-los e gerá-los sem precisar analisar formatos binários. Ela disponibiliza uma interface de comandos MCP que permite aos agentes de IA controlar funções da engine por meio de JSON-RPC. Inclui suporte de primeira classe a Gaussian splatting e renderização headless para testes automatizados. Toda a arquitetura parte do princípio de que o usuário principal pode ser um agente de IA, não uma pessoa com um mouse.
A Arcane Engine é uma engine 2D centrada em código. Núcleo em Rust e scripts em TypeScript. Não tem editor visual. Sua filosofia: “o código é a cena”. O estado do jogo é um banco de dados consultável, em vez de uma árvore de cenas. Ela inclui um protocolo integrado para interação com agentes de IA. Licenciada sob a Apache 2.0.
A Mirror Engine está em alfa e prioriza o multiplayer, com um sistema de entidade-componente. O ponto interessante: ela inclui geração de texto para 3D por IA, produzindo Gaussian splats a partir de prompts de texto em cerca de 60 segundos. Scripts em TypeScript e cliente “Mirror Lite” para navegador.
Essas três engines não compartilham uma base de código nem uma equipe, mas partem da mesma tese de design: a interface principal de uma engine de jogos deve ser texto estruturado, não uma GUI.
Por que essa arquitetura importa
As engines de jogos tradicionais evoluíram para atender a uma pessoa sentada diante de uma mesa. Você tem uma viewport. Um painel de hierarquia. Um inspetor. Uma linha do tempo. Tudo foi projetado em torno de clicar, arrastar e posicionar objetos visualmente. Esse fluxo de trabalho é poderoso. Também é impossível de ser usado por um agente de IA.
Quando seu principal “usuário” é um LLM, você precisa de primitivas diferentes. YAML em vez de formatos binários de cena. Estado consultável em vez de árvores de cena aninhadas. Comandos baseados em protocolos em vez de cliques do mouse. Operação headless em vez de renderização em janela.
É a mesma mudança que ocorreu na infraestrutura quando o DevOps passou de painéis de controle com GUI para infraestrutura como código. A mesma coisa está acontecendo nas engines de jogos, apenas vinte anos depois.
A interface MCP da nAIVE é o exemplo mais claro. O MCP (Model Context Protocol) está se tornando a forma padrão de comunicação entre agentes de IA e ferramentas. Quando uma engine oferece suporte nativo a MCP, qualquer agente de IA compatível com o protocolo pode manipular cenas, ajustar parâmetros, executar testes e iterar sobre a jogabilidade sem intervenção humana. Isso não é um recurso acoplado a uma engine tradicional. É uma relação fundamentalmente diferente entre a engine e seu usuário.
Gaussian splatting no desenvolvimento de jogos. Tanto a nAIVE quanto a Mirror o tratam como uma primitiva de renderização de primeira classe.
O panorama mais amplo
Essas três engines não são o único sinal. O Black Box da Meshy demonstrou mecânicas de jogo geradas por IA em tempo de execução. A OpenAI apresentou na GDC um RPG tático desenvolvido com Phaser. A camada de ferramentas entre “a IA gera algo” e “esse algo é executado como um jogo jogável” fica mais fina a cada mês.
Na Cinevva, temos construído essa ponte a partir da direção oposta. Nossa engine cuida da renderização, da física e da interação em tempo real, enquanto a IA cuida da geração de assets. A abordagem é diferente da nAIVE ou da Arcane, mas a aposta subjacente é a mesma: a engine de jogos do futuro precisa falar IA como sua primeira língua, não apenas adicioná-la como plugin.
Os fabricantes de engines tradicionais também sabem disso. A Unity apresentou uma prévia de ferramentas de criação de jogos com IA na GDC. A Roblox lançou a criação de modelos 4D com IA. Mas há uma diferença significativa entre adicionar recursos de IA a uma engine projetada para humanos e projetar uma engine na qual a IA é a interface principal.
O que acredito que acontecerá em seguida
A maioria dessas engines não sobreviverá. Isso é normal em uma nova categoria. Mas os padrões de design sobreviverão. Definições de cena baseadas em YAML, protocolos MCP para controle por agentes, estado do jogo consultável e operação headless. Essas ideias serão incorporadas às engines convencionais nos próximos dois anos.
A engine que vencerá esta era provavelmente ainda não existe. Mas seu DNA arquitetônico está sendo escrito agora, nesses três projetos e em alguns outros. A questão não é se as engines de jogos se tornarão nativas de IA. É se a transformação virá de dentro das empresas estabelecidas ou de novas concorrentes que projetaram suas engines para agentes desde o primeiro dia.
Relacionado:
- Agora todos querem ser a engine de jogos com IA — a corrida entre plataformas que preparou o terreno
- Modelos de IA generativa de código aberto de ponta — os modelos que essas engines estão integrando
- Comparação entre engines de jogos para web — onde as novas engines se encaixam no ecossistema mais amplo
- O código aberto tem um problema de poluição por IA — o custo das contribuições geradas por IA