Anatomia de um motor de jogos com IA: o que realmente existe por trás do prompt

Por Mariana Muntean, CEO da Cinevva

O comentário mais comum que ouvimos de quem não conhece a Cinevva é que ela não passa de uma camada sobre IA. A pessoa entra na página inicial, vê uma única caixa de texto com a frase "Descreva seu jogo" e acha que já entendeu o produto. Ela entendeu a porta de entrada. O produto é tudo o que você não vê quando digita essa frase e, desde esta semana, também um mundo aberto no qual seus jogadores entram para encontrar seu jogo.

Por trás dessa caixa, há um motor de jogos completo, um orquestrador com 26 ferramentas tipadas, uma frota de modelos generativos, uma busca agregada de ativos em onze provedores, um iframe com o jogo ao vivo que o agente pode ler e modificar e uma vitrine na qual o mesmo agente publica seu jogo finalizado como um reel de gameplay que pode ser navegado com gestos. Nada disso é exótico. É tudo infraestrutura. O trabalho interessante foi decidir o que conectar a quê.

Este post percorre a máquina de cima a baixo. É a explicação que damos a investidores técnicos e a desenvolvedores que pensam em contribuir. Todos querem a mesma resposta.

1. O prompt é a superfície, não o sistema

A primeira decisão de design foi esconder tudo até que o usuário tivesse algo em jogo. A página inicial tem uma única função: receber uma frase e transformá-la em um projeto. Dividimos a experiência em um lado público (o prompt, as demonstrações, o feed da vitrine) e um lado para criadores (a IDE, as ferramentas de ativos, o fluxo de publicação), para que quem só quer jogar não precise olhar para a cabine de comando.

É por isso que o texto de exemplo alterna entre frases como "Crie um jogo da cobrinha com gráficos neon" e "Jogo de tiro contra zumbis com visão de cima". Não são tutoriais. São uma autorização. O usuário percebe que uma "ideia maluca de fliperama" é uma entrada válida.

No momento em que você envia o prompt, três coisas acontecem. O sistema cria um novo projeto de jogo com um ID estável. Ele inicializa uma árvore de arquivos vazia (index.html, game.js, style.css, assets/, GDD.md). E encaminha sua frase ao orquestrador com uma janela de contexto do projeto que aponta para esses arquivos vazios. Daqui em diante, você está conversando com um agente que tem mãos.

2. Por trás do campo, uma IDE completa no navegador

O espaço de trabalho do criador é uma IDE de três painéis que roda inteiramente no navegador. Árvore de arquivos à esquerda, editor de código no centro, iframe com o jogo ao vivo à direita e um campo de chat ao longo da parte inferior. Escolhemos esse layout de propósito. Quem já escreve código o reconhece de imediato. Quem não escreve pode ignorar o painel central e interagir apenas pelo chat.

A árvore de arquivos não é uma metáfora. Cada projeto realmente é um pequeno site estático composto por HTML, JS, CSS, imagens geradas, modelos GLB e arquivos de áudio, servido diretamente pelo R2 por meio de um Cloudflare Worker. Não há etapa de build. E o motivo é importante. Isso significa que o agente pode ler e modificar os arquivos que você realmente publicaria, e que o mesmo artefato roda no iframe, em um celular encapsulado pelo Capacitor, na Steam encapsulado pelo Tauri e dentro do Discord como uma Embedded Activity. Um sistema de arquivos, seis destinos de distribuição.

Todo jogo que geramos precisa expor duas funções em window. getGameState() retorna um objeto simples que descreve o jogo em execução (posição do jogador, pontuação, vidas, inimigos, temporizadores). setGameState(patch) aplica uma atualização parcial ao jogo ao vivo. Essa pequena API é o contrato que permite ao agente inspecionar e modificar um jogo em execução sem recarregá-lo. Voltaremos ao motivo disso na seção 6.

3. O orquestrador, onde o motor realmente funciona

O que as pessoas não percebem quando chamam isso de "uma camada sobre IA" é que a IA não escreve código tanto quanto rege uma pequena orquestra. O orquestrador é um loop de chamadas de ferramentas executado sobre um modelo de fronteira, com um prompt de sistema de cerca de mil linhas e uma superfície tipada de 26 funções. As definições das ferramentas são o motor. O modelo é o maestro.

As 26 ferramentas se dividem em cinco famílias. As ferramentas de sistema de arquivos (list_game_files, read_files, search_game_file, edit_files, write_files, delete_files, rename_files) permitem que o agente trate seu jogo como qualquer outra base de código. As ferramentas de projeto (create_new_game, list_games, open_game, ask_user, game_ready) cuidam do ciclo de vida do projeto e da devolução do controle ao humano. As ferramentas generativas (generate_image, generate_skybox, generate_music, generate_sfx, rig_model, apply_animation, list_animations, list_skybox_styles) acionam modelos especializados que abordaremos a seguir. As ferramentas de conhecimento (search_fonts, list_library_docs, search_library_docs, list_generations) fornecem ao agente fontes confiáveis, indexadas e verdadeiras, em vez de APIs inventadas. E as ferramentas de runtime (read_console_logs, execute_js) permitem que o agente veja e interaja com o jogo ao vivo.

Um primeiro turno típico funciona mais ou menos assim. O usuário digita "Crie um jogo de tiro espacial neon". O modelo emite uma chamada a write_files com um GDD.md que descreve o design e depois chama write_files novamente com index.html, game.js e style.css. Ele chama generate_music com prompt="jogo de tiro espacial synthwave, 120 BPM, linha de baixo pulsante", iniciando uma tarefa no ElevenLabs Music e retornando uma URL de MP3 dentro do R2. Ele chama generate_skybox com um estilo do modelo 3 da Blockade Labs para criar o campo estelar. Chama game_ready(title, message) para atualizar o iframe com a nova build e, por fim, read_console_logs para confirmar que o jogo iniciou sem erros. Se encontrar um stack trace, volta a edit_files e corrige o problema antes mesmo que o usuário o reporte.

A propriedade interessante desse design é que o prompt de sistema e os esquemas das ferramentas são as únicas partes específicas do produto. Troque o modelo e tudo continuará funcionando. Migramos entre três modelos de fronteira no último ano sem alterar a interface, porque ela é nossa.

4. O lado dos ativos: distribuição entre modelos

O agente não gera imagens, músicas, sons ou modelos 3D. Ele chama especialistas. O lado de ativos da Cinevva distribui o trabalho entre os melhores modelos de cada categoria, conectados de modo que a saída de um seja uma entrada válida para o seguinte.

Para imagens e sprites, generate_image chama o Flux Pro 1.1 com largura e altura sempre múltiplas de 32 e um formato de saída que muda para PNG quando o prompt pede transparência. Para músicas completas, o agente chama o ElevenLabs Music com um prompt estilístico e uma duração em segundos. Para efeitos isolados, o ElevenLabs SFX produz um clipe a partir de um texto como "disparo de arma laser, blaster de ficção científica" em cinco a quinze segundos. Para ambientes em 360 graus, generate_skybox chama a Blockade Labs com um de aproximadamente noventa estilos, usando por padrão o modelo 3 Digital Painting. Para personagens 3D, rig_model envia um GLB à Tripo para receber esqueleto e rig como criatura bípede, quadrúpede, hexápode, octópode, serpentina ou aquática; depois, apply_animation reproduz qualquer uma das quinze predefinições (parado, andar, correr, pular, escalar, mergulhar, golpear, atirar, sofrer dano, cair, virar, além das marchas para não bípedes).

Cada uma dessas operações é uma tarefa, não uma chamada síncrona. Elas levam de segundos a minutos. O orquestrador as inicia, retorna imediatamente com um jobId, e um canal separado envia o resultado de volta à conversa quando o ativo está pronto. Isso muda completamente a experiência. O agente pode continuar construindo a lógica do jogo enquanto o rig de um modelo 3D é finalizado em segundo plano. O usuário nunca precisa esperar por um único caminho crítico.

Todos os artefatos vão para o mesmo lugar. O R2, por trás de cdn.cinevva.com, acessível por URLs simples. Isso significa que a próxima chamada write_files do agente pode simplesmente incorporar <audio src="https://cdn.cinevva.com/audio/abc.mp3">, e o jogo funciona. Sem SDK, sem empacotador de ativos, sem manifesto.

5. Busca de ativos em onze provedores

A geração é ótima quando você precisa de algo específico. A busca é mais rápida quando aquilo já existe. A Biblioteca de Ativos é uma busca federada em onze provedores gratuitos e licenciados, apresentada em um único feed ordenado por relevância.

O registro de provedores fica no worker e executa cada consulta em paralelo na PolyHaven, Sketchfab, Freesound, Kenney, AmbientCG, Quaternius, OpenGameArt, coleção 3D do Smithsonian, TurboSquid, Synty e Jamendo. Cada provedor implementa uma interface comum (search, getMetadata, isBrowsable, getSupportedTypes), portanto adicionar um novo exige apenas um arquivo TypeScript. A camada de agregação cuida da paginação baseada em cursor entre provedores que paginam de formas diferentes, elimina licenças duplicadas, normaliza os tipos de ativos em uma taxonomia comum (modelo, textura, áudio, HDRI, sprite) e marca cada ativo com sua licença, para que o agente nunca escolha algo que não possa redistribuir.

Quando o ChatGPT recomendou essa ferramenta no trimestre passado como um dos melhores buscadores gratuitos de ativos para desenvolvedores de jogos, fomos ler a recomendação. Ela estava certa sobre o que importa. A questão não é termos uma barra de busca sobre uma única biblioteca. A questão é que um desenvolvedor independente procurando por "textura de parede de pedra" recebe resultados da PolyHaven e da AmbientCG lado a lado com a versão estilizada da Kenney e uma opção de fotogrametria do Smithsonian, com uma única consulta e metadados de licença consistentes. O agente pode acessar o mesmo endpoint e escolher ativos da mesma forma que uma pessoa.

Essa é a parte do motor que costuma receber menos destaque do que merece. A maioria das demonstrações de IA para jogos gera tudo do zero e acaba com uma aparência uniforme, brilhante e ligeiramente estranha. Os jogos interessantes na Cinevva combinam ativos gerados com fotogrametria CC0 real do Smithsonian e uma árvore low-poly feita à mão pela Quaternius. O orquestrador pode fazer tudo isso em um único turno.

6. O agente joga o jogo

Essa é a parte que mais surpreende os engenheiros quando a demonstramos. O agente não se limita a escrever código em arquivos. Ele executa o jogo em um iframe isolado, lê o console, faz capturas de tela em camadas separadas para a interface e a cena 3D e executa JavaScript dentro do runtime ao vivo para inspecionar ou alterar o estado. read_console_logs retorna as últimas cinquenta linhas de console.log, console.warn, console.error e exceções não capturadas do iframe. Após cada chamada de game_ready, o prompt do sistema exige que o agente chame read_console_logs e corrija todos os erros antes de devolver o projeto ao usuário. Essa única regra elimina a maioria das falhas do tipo "a IA disse que estava pronto, mas a tela está preta" que outras ferramentas apresentam.

execute_js é a ferramenta mais poderosa. Ela executa JavaScript arbitrário dentro do escopo global do jogo. Como todo jogo precisa implementar getGameState e setGameState, o agente pode executar JSON.stringify(getGameState()) para ler todo o estado do jogo em execução e, depois, setGameState({player: {x: 500, y: 100}}) para teletransportar o jogador, setGameState({lives: 99}) para conceder invencibilidade ou setGameState({level: 3}) para avançar de fase. Ele também pode investigar níveis mais baixos, usando algo como scene.children.map(c => c.type) para inspecionar o grafo de cena do Three.js ou document.querySelectorAll('canvas').length para confirmar que o renderizador foi montado.

É fácil entender por que isso importa. Quando um usuário diz "o jogador fica preso na parede na segunda fase", o agente não precisa adivinhar. Ele abre a segunda fase, executa getGameState(), examina os dados de colisão, testa uma correção com execute_js e só então grava a correção no disco. Ele depura como você depura. Tratamos o iframe como um par, não como um alvo.

7. Documentação das bibliotecas, a entediante fonte da verdade

Indexamos a documentação oficial das bibliotecas que os jogos realmente usam (Three.js, Tone.js, Cannon e uma lista cada vez maior) em um repositório JSON estruturado e pesquisável. O agente recorre a search_library_docs("threejs", "Mesh") antes de buscar na web aberta. É mais rápido, tem controle de versão e nunca alucina um método que foi renomeado duas versões menores atrás.

Isso não é glamouroso. É a diferença entre uma IA que produz código funcional e uma IA que produz código com aparência convincente, mas que trava na linha quarenta. Grande parte da qualidade visível dos jogos criados com a Cinevva vem dessa única decisão.

8. De jogável a encontrável: reels e a vitrine

Um jogo que ninguém joga é um hobby particular. O problema não resolvido mais difícil do desenvolvimento independente já não é criar jogos. É a distribuição. Por isso, o mecanismo não para em "jogável". Ele para em "diante dos jogadores".

Todo projeto na Cinevva tem uma URL de compartilhamento estável, como play.cinevva.com/{game-id}, que abre a versão mais recente do jogo em um iframe de página inteira com uma pequena sobreposição para curtidas e compartilhamentos. Quando o agente chama game_ready, ele não apenas atualiza a prévia no ambiente de desenvolvimento. Ele também oferece a publicação de um reel de gameplay de 15 segundos na vitrine da Cinevva. O reel é uma gravação real do jogo sendo jogado, capturada diretamente do iframe (fornecemos um pequeno script de gravação que o agente injeta no ambiente de execução do jogo), então o que o espectador vê ao rolar a tela é gameplay de verdade, não uma edição de marketing.

Isso muda o ciclo de trabalho de quem desenvolve. O ciclo antigo era programar, compilar, empacotar, enviar, escrever uma página na Steam, enfrentar um algoritmo e observar um contador de listas de desejos. O novo ciclo é digitar uma frase, ver o agente criar, apertar publicar e assistir ao seu jogo aparecer no mesmo feed vertical junto de todos os outros. A descoberta acontece no mesmo produto em que a criação acontece, na mesma URL e com o mesmo login.

Para quem acompanha a comunidade de desenvolvimento, esta é a parte que vale examinar. A distribuição sempre foi a vantagem competitiva que os mecanismos de jogos não ofereciam. A Unity fornece um editor; você publica o jogo na Steam. A Unreal fornece um editor; você publica na Epic Store. A Cinevva fornece as duas metades. O mecanismo e a vitrine se comunicam por meio do mesmo orquestrador que criou o jogo.

9. Mais jogados: o ciclo virtuoso da descoberta

O feed de reels é uma metade do ciclo virtuoso. O ranking Mais jogados é a outra. Ele classifica os jogos por popularidade, recência e desempenho histórico, com peso baseado na taxa de conclusão (o jogador terminou uma sessão?) em vez de cliques brutos. É mais difícil manipular conclusões do que instalações. Um jogo que prende a atenção por sessenta segundos supera um jogo que é aberto e fechado.

Cada sinal retroalimenta o próximo turno do orquestrador. Quando o agente diz "vamos adicionar um power-up", ele não está se baseando em uma biblioteca fixa de padrões. Ele usa um modelo que observou quais mecânicas realmente retêm jogadores na Cinevva neste mês. O ciclo virtuoso não é apenas um ranking no fim da página. É o sinal de treinamento de todo o mecanismo.

Para investidores, essa é a nossa vantagem competitiva baseada em dados. Não temos apenas jogos gerados. Temos jogos gerados com métricas reais de engajamento em nível de sessão, vinculadas aos prompts que os produziram, às escolhas de recursos feitas pelo agente e aos jogadores que gostaram deles. Cada ciclo aprimora o seguinte.

10. O mecanismo se torna um jogo

Esta é a parte que venho insinuando nas redes sociais há meses. Tudo o que aparece nas seções 1 a 9 descreve um sistema que cria jogos. O mais difícil de descrever, até você ver, é o que acontece quando o próprio sistema se torna um lugar.

Criar jogos é um trabalho árduo, mesmo com tudo o que já lançamos. Se você nunca criou um jogo, de repente passa a ser responsável pelo enredo, pelos personagens, pelo mundo, pelas mecânicas, por quem faz o quê e quando, pelo comportamento da iluminação, pelas camadas de efeitos especiais, pela música, pelos efeitos sonoros e pelos movimentos de câmera. É muita coisa. E, além de tudo isso, você quer que o resultado pareça realmente seu, não um modelo pronto cuspido pela ferramenta de outra pessoa. O prompt e o orquestrador fazem a maior parte do trabalho mecânico por você. O que eles não conseguem fazer sozinhos é dar à sua criação final um palco onde possa se apresentar com outras pessoas assistindo.

Então construímos o palco. Durante a maior parte deste ano, Oleg e a equipe do mecanismo vêm publicando o trabalho em uma série de 14 partes sobre como colocar um mundo aberto no navegador. Terreno esculpido que você pode modificar em tempo real. Biomas que se pintam como rocha ou grama de acordo com a inclinação e a altitude. 80.000 folhas de grama que se curvam com o vento sobre um terreno gerado por computação. Um personagem que caminha, corre, pula e plana sobre terreno volumétrico e baseado em mapas de altura no mesmo movimento. Nada disso era uma demonstração técnica feita por si só. Era a base para isto.

Hoje, o mundo aberto está disponível em uma versão inicial. Você escolhe um avatar e entra. Seus jogos publicados aparecem como espaços visitáveis ao seu redor, assim como os reels da vitrine e o ranking Mais jogados os exibem agora, mas você chega a pé em vez de deslizar pela tela. Você pode entrar no jogo de uma pessoa desconhecida a partir do mundo sem sair dele. Pode ficar ao lado da pessoa que criou aquilo que acabou de jogar e dizer o que adicionaria em seguida. Pode esculpir um pedaço de terreno com alguém que acabou de conhecer e transformá-lo na semente de um novo projeto. A descoberta deixa de ser um feed. Ela se torna um passeio.

Nosso mecanismo sempre foi um mecanismo de jogos no sentido técnico. Hoje, ele também se torna um jogo no sentido literal. Aquilo que cria seu jogo agora é um jogo em si, e o mesmo orquestrador da seção 3, os mesmos fluxos de recursos da seção 4, o mesmo contrato getGameState da seção 6, os mesmos reels da seção 8 e o mesmo ranking da seção 9 se combinam no único lugar pelo qual seus jogadores circulam. A fronteira entre criar e jogar sempre foi artificial. Agora ela desapareceu.

O que achamos que fizemos certo

A primeira coisa que fizemos certo foi tratar o prompt como um recurso de interface, não como um produto. O produto é o orquestrador, o conjunto de ferramentas, os fluxos de recursos e a vitrine. O prompt é a maneira mais simples possível de colocar um usuário dentro do sistema.

A segunda foi insistir em um sistema de arquivos plano e nativo do navegador, sem etapa de compilação. É por isso que um jogo da Cinevva pode ser distribuído para dispositivos móveis, computadores, Steam e Discord a partir de uma única fonte da verdade. É por isso que o agente consegue ler o que escreveu.

A terceira foi o contrato segundo o qual todo jogo gerado implementa getGameState e setGameState. Essa única linha no prompt do sistema é o que faz o agente parecer um colaborador em vez de um gerador de código. O agente consegue jogar, e um sistema que consegue jogar consegue depurar.

A quarta foi conectar a vitrine ao mesmo ciclo do mecanismo. Não venceremos apenas pela qualidade bruta do modelo. Não há vantagem defensável em estar dois meses à frente de um gerador com pesos abertos. Vencemos quando o mesmo agente que cria seu jogo também o publica, mede seu desempenho e aprende com a maneira como pessoas desconhecidas o jogaram.

Se quiser ver toda a máquina em movimento, o prompt da página inicial continua sendo a porta de entrada. Digite uma frase. Veja o que acontece nos bastidores. Depois, volte aqui e conte qual parte do mecanismo devemos abordar em seguida.