Pedir à IA para fazer um jogo já não é novidade hoje em dia.

Mas e se ela não entregar uma pequena página com um botão para clicar e personagens que se movem, e sim trabalhar continuamente por oito horas, criando cenários, modelos, texturas e sons?

Felix Rieseberg, da Anthropic, compartilhou um experimento assim. Ele queria ver em que um jogo poderia se transformar com o Claude Fable 5.2, sem adicionar feedback humano. Segundo seus registros públicos, esta execução levou cerca de oito horas, custou aproximadamente 550 dólares pelos preços da API, acumulou cerca de 445M Tokens de entrada e 2,7M Tokens de saída, além de fazer amplo uso de cache. Compartilhamento original

Esses números não são nossos testes reais, nem uma cotação padrão para “fazer um jogo”. No entanto, em comparação com a frase “o modelo ficou mais forte de novo”, eles ao menos nos permitem ver uma questão concreta: quando os modelos conseguem escrever código continuamente, para onde os limites da criação irão se deslocar?

Este artigo não roda rankings e analisa principalmente três casos públicos. As imagens vêm de projetos ou telas de demonstração exibidos publicamente pelos autores; as descrições envolvendo tempo, custo e processo de geração seguem as explicações das fontes, sem apresentar experimentos individuais como conclusões universais.

O que foi feito em oito horas é uma pequena fase, não uma grande obra completa

O jogo exibido por Felix se chama Saltline, um projeto de tiro em primeira pessoa que pode ser experimentado no navegador. Acesso ao projeto

Tela de demonstração do jogo Saltline exibida publicamente por Felix Rieseberg

Tela de demonstração de Saltline, extraída da capa do vídeo na postagem original de Felix Rieseberg, com apenas uma imagem estática citada. Fonte: postagem original do autor。

O prompt dele não era longo: ele queria um jogo de tiro em primeira pessoa, com visuais o mais refinados possível, mas com escopo pequeno, podendo ser apenas uma fase muito pequena. Prompt público

Esse “pequeno” é muito importante.

Concentrar recursos de produção em um pequeno trecho da experiência e fazer um jogo comercial rico em conteúdo, capaz de ser jogado continuamente por dezenas de horas, são dificuldades de naturezas diferentes. A menção a visuais de nível AAA no prompt também é apenas um objetivo, não uma conclusão de qualidade obtida após avaliação.

O que realmente vale observar é a forma de geração dos recursos. Felix acrescentou posteriormente que as texturas e os modelos são todos funções, sem arquivos de imagem nem arquivos de modelos tridimensionais, e que o código-fonte está no HTML, podendo ser consultado por qualquer pessoa. Explicação complementar

Segundo o autor, isso não consiste em primeiro chamar um modelo de imagens para gerar uma imagem e depois fazê-la se mover, mas em construir por meio de programas os elementos da cena.

Esse caminho é muito atraente para criadores: se quiserem alterar uma luz, ajustar as proporções de um objeto ou trocar um material, podem tentar modificar parâmetros e lógica, sem precisar gerar novamente toda a imagem. Para conteúdos que exigem interação, o código também pode responder diretamente pela câmera, pelas colisões e pelas entradas.

Mas ser modificável não significa ser fácil de manter. Aqui, não auditamos o código-fonte do jogo, nem concluímos testes de compatibilidade em múltiplos dispositivos. Uma demonstração que parece boa ainda está a certa distância de um produto estável.

Além disso, “concluído com um único prompt” também é facilmente mal interpretado. Isso significa que o autor não continuou dando instruções durante esta execução, não que o modelo tenha sido chamado apenas uma vez, muito menos que tenha entregado o resultado em poucos segundos. As oito horas e aquela conta são ambas parte deste caso.

Centenas de mundos tridimensionais são mais interessantes do que um cenário bonito

O experimento de Ethan Mollick levou essa questão em outra direção.

Ele deu ao Fable uma descrição, esperando criar uma viagem que avançasse automaticamente por diferentes mundos tridimensionais conectados por portais. Segundo seu registro em Fable 5.2 and Jagged AGI, após vinte horas, o site tinha 204 mundos; a quantidade registrada posteriormente no artigo já ultrapassava 450. Artigo do autor

Aqui, não fixamos a quantidade em determinado momento como um “resultado final”. Este é um projeto em atualização contínua, e a quantidade vai mudar; o que realmente interessa é a forma de criação por trás dele.

Mosaico de mundos tridimensionais de Portals exibido no artigo de Ethan Mollick

Mosaico de mundos do projeto Portals, imagem extraída do texto original de Ethan Mollick. Fonte: Fable 5.2 and Jagged AGI。

No site Portals, é possível ver um vale costurado em jeans, sendo aberto por um zíper, e também entrar na perspectiva de uma mosca-das-frutas que tem uma geladeira como céu e terra. Há ainda um mundo em que os dois lados de um cânion não são rochas, mas gaveteiros empilhados bem alto. Projeto do vale · Projeto da geladeira · Cânion de gavetas

Mollick escreveu que esses mundos são todos desenhados em tempo real por código, sem usar modelos tridimensionais pré-fabricados ou arquivos de imagem. Seu prompt exigia a colaboração entre agentes de arte, programação e avaliação; posteriormente, ele também propôs requisitos como uma lista de locais, um modo para reduzir a sensação de enjoo e uma galeria de imagens.

Portanto, não se pode dizer que o site final foi feito “depois de algumas palavras, sem nenhuma participação humana”. O início foi muito breve, mas as escolhas de direção e os ajustes de funcionalidades posteriores ainda foram feitos por pessoas.

Para quem quer criar animações interativas ou conteúdos educacionais, acredito que este projeto tem mais valor de referência do que uma única imagem de efeito. Ele sugere que podemos fazer o modelo dividir uma ideia em regras de cenário, relações espaciais, movimentos e parâmetros ajustáveis, em vez de apenas escrever uma descrição em uma janela de conversa. Por exemplo, ao falar sobre movimento planetário, é possível transformar órbitas, períodos e velocidades em variáveis controláveis; ao falar sobre geometria, é possível permitir que o público arraste vértices e observe as mudanças. Aqui estão direções de aplicação que propomos com base nos casos, não uma declaração de testes reais de que o Fable já concluiu esses projetos didáticos específicos.

A parte mais fascinante talvez também seja a parte que mais facilmente sai de controle

A história do Portals não parou em “cada vez mais mundos”.

Mollick descobriu que a qualidade de algumas cenas era inconsistente e que diferentes equipes também repetidamente pensavam em ideias semelhantes. Ele pediu ao modelo que pausasse a expansão e primeiro refinasse o conteúdo existente.

O que aconteceu em seguida foi muito interessante: os agentes começaram a estabelecer processos de avaliação. As novas versões precisavam passar pela comparação de vários avaliadores em capturas de tela fixas, e as equipes então tendiam a otimizar para essas capturas; depois que o agente responsável pela coordenação percebeu isso, acrescentou mais regras.

Segundo os registros de Mollick, o documento de regras posteriormente cresceu para 204 seções, cerca de 87.500 palavras. Um projeto criativo foi gradualmente desacelerado por seu próprio processo de aprovação. Registro do processo

Isso não é apenas um episódio engraçado.

Frequentemente consideramos “verificar seus próprios resultados” como uma vantagem, mas verificar também exige um objetivo. Se, cada vez que um problema é encontrado, uma regra é adicionada, mas exigências obsoletas não são removidas, o sistema pode se tornar cada vez mais rigoroso, mas cada vez menos eficiente.

Da mesma forma, ter avaliações não significa ter estética. Capturas de tela aprovadas, código que executa e todos os itens de verificação aprovados também não significam necessariamente que um mundo vale a pena permanecer por mais alguns minutos.

Uma observação importante de Mollick sobre esses experimentos é: os modelos conseguem concluir muitos trabalhos complexos, mas não necessariamente descobrem por iniciativa própria que uma obra é longa demais, repetitiva demais ou pouco interessante. No fim, ainda é preciso que pessoas tragam o projeto de volta de uma direção errada.

Para a criação, essa limitação merece mais atenção do que um pequeno erro ocasional. Porque ela muitas vezes se esconde no resultado de “cada etapa ter sido feita com muito cuidado”.

O curta no Blender ilustra outra coisa: o modelo pode ser um coordenador entre ferramentas

O experimento compartilhado por Riley Brown, por sua vez, inseriu código em um fluxo de produção tridimensional mais tradicional.

Segundo sua publicação original, o Fable escreveu código e construiu no Blender um quarto, uma mesa, um notebook, iluminação e personagens; a interface exibida na tela do computador também era uma página web que ele escreveu. Em seguida, o modelo organizou 13 tomadas, além de ações de teclado, movimentos dos personagens e mudanças de iluminação do entardecer para a noite e depois para o amanhecer. Publicação original do autor

Cena de animação do Blender apresentada publicamente por Riley Brown

Cena de animação do Blender, extraída da capa do vídeo na publicação original de Riley Brown, com apenas uma imagem estática citada. Fonte: Publicação original do autor.

Riley também escreveu que a renderização usou 10 GPUs no RunPod, concluindo a renderização em 4K em cerca de 52 minutos, e que a música e os efeitos sonoros usaram ElevenLabs.

Portanto, isso não significa que “o próprio Fable seja um modelo de geração de vídeo”. Mais precisamente, ele avançou a construção de cenas, a animação, a renderização e a produção de som por meio de código e ferramentas externas.

A publicação original também apresentou o valor de custo de 5,75 dólares, mas não incluiu uma fatura detalhada completa. Este texto não o interpreta como um custo geral de produção final que inclua chamadas de modelo, música, efeitos sonoros e toda a infraestrutura, nem promete com base nisso que os leitores poderão reproduzi-lo com o mesmo orçamento.

Para quem realmente quer produzir conteúdo, essa distinção é muito útil.

Se a tarefa for obter rapidamente um trecho visual, usar diretamente um modelo de geração de vídeo pode ser mais prático. Se você precisa ajustar repetidamente as tomadas, modificar um objeto específico, manter relações espaciais ou fazer a animação acompanhar mudanças nos dados, vale a pena tentar um fluxo tridimensional orientado por scripts.

As duas abordagens não precisam substituir uma à outra. O ponto-chave é saber quais conteúdos precisam ser controláveis e editáveis, e quais partes podem ser deixadas para modelos generativos explorarem.

Se realmente quiser experimentar por conta própria, primeiro troque “faça algo incrível” por uma pequena tarefa que possa ser validada

Depois de ver esses casos, é fácil querer dar diretamente ao modelo uma frase: faça para mim um jogo completo, ou produza um filme de animação.

Eu recomendaria primeiro reduzir o escopo.

Para o jogo, faça apenas uma sala, uma rota ou um mecanismo claro; para a animação, faça primeiro uma tomada; para o conteúdo didático, explique primeiro um único ponto de conhecimento. Primeiro verifique se o modelo consegue concluir, no ambiente que você fornece, uma vez o ciclo de “gerar, executar, observar, modificar”, e só então decida se vale expandir o projeto.

Também não é necessário escrever prompts de forma muito misteriosa. Abaixo está uma descrição de tarefa que pode ser adaptada, pertencente às nossas recomendações práticas, e não ao prompt original dos autores mencionados:

Crie uma cena interativa que possa ser executada no navegador, exibindo apenas uma ideia central, sem expandi-la para um jogo completo. Antes de começar, explique primeiro a solução técnica, as dependências necessárias e as etapas previstas de execução. Expresse, tanto quanto possível, a geometria, as cores e os movimentos da cena por meio de código, e concentre os ajustes comuns como parâmetros. Primeiro entregue uma versão mínima executável e, depois, corrija-a com base nos resultados reais da execução. Diferencie o conteúdo que você já testou daquele que ainda não foi verificado; não use “deve funcionar” como substituto de registros de teste. Sem minha confirmação, não compre recursos de nuvem, não implante na internet pública e não acesse arquivos fora do diretório do projeto. Ao atingir o limite de orçamento ou tempo acordado, pause, preserve o resultado atual e explique os problemas restantes.

O mais importante aqui não é a formulação, mas os limites da entrega.

Conseguir executar exige um método claro de inicialização e dependências. Conseguir modificar exige saber onde estão os parâmetros e a lógica central. Conseguir validar exige registros de teste, problemas conhecidos e as partes que não foram concluídas.

Tarefas longas também devem manter versões intermediárias. Se a última modificação quebrar a cena, pelo menos será possível retornar à versão utilizável anterior, em vez de restar apenas um registro de conversa dizendo “corrigindo”. Os sistemas multiagente também podem começar com um pequeno número de papéis claros, em vez de colocar dezenas de agentes para trabalhar ao mesmo tempo logo de início. O que o responsável pela produção, o responsável pela verificação da execução real e o responsável por avaliar a experiência visual entregam, respectivamente, é melhor deixar claro. Depois que a revisão encontra problemas, também é preciso que alguém decida quais valem a pena corrigir e quais devem parar por aí.

A barreira para criar está mudando, o discernimento não perdeu valor

Na apresentação oficial de lançamento, a Anthropic posiciona o Fable 5.2 para trabalhos técnicos difíceis e abertos, ao mesmo tempo em que recomenda começar a maioria das tarefas cotidianas de programação e conhecimento com o Opus 5.5 e então escolher o modelo conforme a complexidade.Apresentação oficial de lançamento

Ao recolocar esse posicionamento nos três casos, será mais fácil entender o significado deles.

Saltline demonstra a possibilidade de produção procedural de longa duração; Portals demonstra a capacidade de construir mundos criativos em lote, e também expõe a repetição e o inchaço do processo; já o curta do Blender demonstra como o código pode conectar diferentes ferramentas de produção.

Tudo isso merece ser observado com seriedade, mas não é necessário se apressar para resumir isso como “os criadores não são mais necessários”.

O modelo pode nos ajudar a montar cenários, escrever lógica, organizar tomadas e até organizar verificações por conta própria. Mas o que a obra afinal quer expressar, por que determinada imagem deve permanecer, quando metade do conteúdo deve ser removida e quando já está bom o suficiente ainda exigem que pessoas tomem decisões.

Talvez o que seja mais digno de expectativa não seja que todos possam criar uma grande obra com uma única frase, mas que algumas pequenas ideias que antes só podiam ficar na mente agora tenham a oportunidade de se tornar obras que podem ser abertas, experimentadas e continuadas a ser modificadas.


Fontes e descrição das imagens

As três imagens ilustrativas do texto citam, respectivamente, imagens públicas de apresentação ou capas de demonstrações estáticas dos projetos mencionados acima, e os direitos autorais pertencem aos respectivos titulares dos direitos; isso não representa a obtenção de autorização para republicação; antes da publicação pública, devem ser confirmados a licença de uso das imagens, a disponibilidade dos links externos e os requisitos de atribuição. A capa do artigo mantém o pôster em inglês do Fable 5.2 já preparado para esta criação. Este texto é um rascunho de análise de casos, não uma avaliação independente de desempenho, nem constitui garantia de uso comercial dos projetos ou disponibilidade dos modelos.


Quer experimentar mais algumas ideias? Reserve um limite mais amplo para criar

Ao criar cenas interativas, modificar a lógica de jogos e depurar animações repetidamente, o que realmente consome Tokens muitas vezes não é apenas a primeira geração, mas as sucessivas rodadas posteriores de modificação e validação. Se você também está se preparando para transformar essas ideias em seus próprios pequenos projetos, pode conferir o Ace Data Cloud Coding Plan.

O Coding Plan pode se conectar a ferramentas de programação comuns, como Claude Code e Codex, permitindo que você continue escrevendo código, executando testes e ajustando obras em um ambiente familiar. A promoção por tempo limitado atual adiciona Credits sem alterar o preço dos planos, para que os planos da mesma categoria tenham mais limite disponível para chamadas de Token.

Plano Limite básico Bônus por tempo limitado Total da promoção
Coding Plus 400 Credits 100 Credits 500 Credits
Coding Standard 1,200 Credits 400 Credits 1,600 Credits
Coding Pro 3,000 Credits 1,000 Credits 4,000 Credits
Coding Max 8,000 Credits 2,000 Credits 10,000 Credits

As informações acima baseiam-se na descrição atual dos planos oficiais; a promoção está prevista para durar até 30 de novembro de 2026, 23:59:59 (horário de Pequim), e os preços específicos, a elegibilidade de participação e o limite creditado estão sujeitos à página de compra. O escopo de acesso aos modelos de Coding é o mesmo nos quatro planos, e a principal diferença são os Credits incluídos.

Os Credits aqui são limite de chamadas, não uma quantidade fixa de Tokens; a quantidade de Tokens que realmente pode ser usada depende do modelo, da proporção entre entrada e saída e da situação de cache. Os planos são gerenciados em ciclos de 30 dias; a renovação antes do vencimento permite transferir o limite restante e estender por mais 30 dias, enquanto o limite não utilizado no vencimento expira; não há renovação automática, nem dedução automática do saldo geral. A disponibilidade do Fable 5.2 e a compatibilidade com clientes devem seguir o catálogo atual de modelos e as permissões das credenciais.

Não é preciso desafiar um grande projeto de oito horas logo no início. Primeiro, escolha uma pequena cena que você realmente queira criar, faça-a funcionar e então use o limite mais amplo para aprimorá-la aos poucos.

Links relacionados: