Como escrever o prompt único que faz o Claude Opus 5.5 entregar um jogo jogável?

Um jogo inteiro saindo de um prompt só virou teste de fogo pra modelo de IA

E não é coisa de hypezeiro do Twitter: a própria Anthropic conta, no anúncio do Claude Opus 5.5, que um avaliador pediu a vários modelos Claude a construção de um jogo a partir de um único prompt, e o Opus 5.5 pontuou acima de todos os outros pela qualidade dos gráficos e do acabamento

Agora vem a parte que quase ninguém comenta

O mérito não é só do modelo

Quando tu manda "faz um jogo aí", o loop agêntico tem que inventar tudo que tu não disse: gênero, regras, quanto de vida o inimigo tem, quando o jogo acaba, se roda no navegador ou não. E ele VAI inventar, porque não tem alternativa

O prompt único bom é aquele que não deixa lacuna importante pro modelo preencher no chute. Bora montar esse prompt? 😀

O que você precisa antes de escrever o prompt

Primeiro, onde o Opus 5.5 vive hoje: claude.ai e apps do Claude, Claude Code, Claude Cowork, Claude Developer Platform, Amazon Bedrock, Google Cloud e Microsoft Foundry

Se tu for pela API, o identificador é claude-opus-5-5 na Claude API, no Google Cloud, no Microsoft Foundry e na Claude Platform na AWS. No Amazon Bedrock ele aparece como anthropic.claude-opus-5-5

Dois controles importam num pedido grande desse tipo:

• effort: são cinco níveis, com medium como padrão (no Opus 5 o padrão era high). O pensamento adaptativo fica sempre ligado, não dá pra desligar. Effort é o controle principal de profundidade de raciocínio, latência e custo
• task budget: quantos tokens o modelo tem pro loop agêntico INTEIRO, contando pensamento, chamadas de ferramenta, resultados e saída. O mínimo aceito é 20.000 tokens, e valor menor que isso volta com erro 400

E tem o teto físico do que cabe: 1.000.000 de tokens de contexto e 128.000 tokens de saída máxima, os mesmos do Opus 5

Esse número de saída é o que define se o teu "jogo em arquivo único" cabe numa tacada só. Guarda ele na cabeça, porque a maior fonte de frustração em prompt único é pedir um escopo que não cabe no entregável que tu declarou

Como escrever o prompt único, passo a passo

A ordem aqui não é decorativa

A Anthropic afirma que o Opus 5.5 foi ajustado pra colocar a informação crítica logo no começo e seguir mais de perto as instruções de formatação do usuário. Então escreve o teu prompt do mesmo jeito: o que importa primeiro, o enfeite depois

1. Defina o gênero e a fantasia em uma frase

Uma frase, não um parágrafo. O modelo usa isso como âncora pra tudo que vem depois

Crie um jogo arcade 2D top-down onde o jogador pilota uma nave
limpando ondas de asteroides dentro de uma arena fechada

O erro comum deste passo: escrever "um jogo divertido e inovador". Isso não é informação, é adjetivo. O modelo não consegue derivar mecânica de adjetivo

2. Descreva o loop de gameplay

Loop é o que o jogador faz repetidamente, do segundo 5 ao minuto 10. Se tu não descrever, o modelo monta uma cena bonita sem jogo dentro

Loop: o jogador se move com WASD e atira com o mouse.
Asteroides entram pelas bordas em ondas.
Destruir um asteroide grande gera dois médios; médio gera dois pequenos.
A onda seguinte só começa quando a arena fica limpa.

O erro comum deste passo: descrever a TELA em vez da AÇÃO. "Tem uma nave no meio e asteroides em volta" é screenshot, não loop

3. Fixe regras e números em vez de deixar o modelo escolher

Esse passo é o que separa o jogo jogável do jogo impossível ou do jogo entediante. Vida, dano, velocidade, cadência de tiro, spawn: escreve tudo

Números fixos:
- jogador: 3 vidas, hitbox circular de 12px, velocidade 220px/s
- tiro: 1 por 180ms, velocidade 520px/s, some ao sair da tela
- asteroide grande: 3 hits, 60px, velocidade 40 a 90px/s
- onda 1 tem 4 asteroides grandes; cada onda soma +1
- colisão com asteroide: perde 1 vida e 1,5s de invencibilidade piscando

Se a tua regra tiver exceção em cima de exceção ("só perde vida se não estiver no dash, e no chefe o dash não protege"), vale o mesmo cuidado de quando você precisa descrever regra de negócio cheia de exceções: escreve a exceção junto da regra, não num parágrafo perdido lá embaixo

O erro comum deste passo: dizer "balanceamento justo". Justo pra quem? 😛 Número vago vira número aleatório

4. Declare condição de vitória E de derrota

As duas. Sempre

Derrota: vidas chegam a zero, mostra tela de Game Over com pontuação final
Vitória: completar a onda 10, mostra tela de vitória com tempo total

O erro comum deste passo: declarar só a derrota. Aí sai aquele jogo infinito que nunca termina e nem parece ter terminado, e tu fica achando que bugou

5. Trave a stack e o entregável

Aqui tu decide se o resultado abre com dois cliques ou se vira uma tarde de setup

Entregável: um único arquivo index.html, autocontido.
Canvas 2D puro, sem framework, sem bundler, sem npm install.
ZERO assets externos: nada de .png, .mp3 ou fonte de CDN.
Todo visual e som gerado em runtime por código.
O arquivo deve abrir com duplo clique no navegador e funcionar offline.

O erro comum deste passo: não proibir asset externo. O modelo referencia sprites/nave.png, o arquivo não existe, e tu abre no navegador e vê uma tela preta com erro no console

6. Liste controles e feedback de tela

HUD, menu inicial, pausa, restart. Sem isso o jogo roda mas tu não sabe o que está acontecendo

UI: menu inicial com botão Jogar e lista de controles.
HUD no topo: vidas, pontuação, número da onda.
Tecla P pausa, tecla R reinicia a partir da tela de Game Over.

O erro comum deste passo: esquecer o restart. Aí pra testar de novo tu tem que recarregar a página toda vez, e testar jogo assim cansa rápido

7. Peça o critério de aceite

Essa frase vale por meio prompt

Critério de aceite: o arquivo deve abrir no navegador e ser jogável
do início ao fim sem nenhum erro no console.
Antes de finalizar, revise o código procurando referências a arquivos
que não existem e variáveis usadas antes de declarar.

O erro comum deste passo: assumir que "funcionando" é óbvio. Critério de aceite explícito dá ao modelo um alvo verificável, e não uma impressão

8. Ajuste effort e task budget ao tamanho do pedido

Um arcade de arquivo único é uma coisa

Um FPS 3D com inimigos, níveis e menu é outra bem diferente, e o padrão medium de effort pode ficar curto pro segundo caso

O erro comum deste passo: apertar o task budget achando que economiza. O modelo enxerga a contagem regressiva e usa isso pra priorizar e encerrar de forma organizada, ou seja: teto apertado não deixa o pedido mais barato, deixa o jogo mais pobre

Se tu quer entender melhor como estruturar pedido grande sem desperdiçar o modelo, dá uma olhada em prompts longos no Claude Opus

Três prompts de exemplo (e por que cada um funciona)

Montei três em complexidade crescente. Repara em quais blocos do checklist aparecem em cada um

Arcade 2D em canvas (o mais seguro pra começar)

Crie um jogo arcade 2D top-down de sobrevivência em arena, entregue
como um ÚNICO arquivo index.html autocontido, canvas 2D puro,
sem framework e com ZERO assets externos (tudo desenhado por código).

Loop: o jogador se move com WASD, mira com o mouse e atira com clique.
Inimigos surgem nas bordas e perseguem o jogador em linha reta.

Números: jogador com 3 vidas e velocidade 220px/s; tiro a cada 180ms;
inimigo comum com 2 hits e velocidade 70px/s; 6 inimigos na onda 1,
+2 por onda.

Derrota: vidas em zero, tela de Game Over com pontuação.
Vitória: sobreviver até o fim da onda 8.

UI: menu inicial, HUD com vidas/pontos/onda, P pausa, R reinicia.

Critério de aceite: abrir com duplo clique no navegador e ser jogável
do início ao fim sem erro no console.

Por que funciona: entregável travado, loop explícito, números fixos e as duas condições de fim. É o formato com menos chance de sair quebrado

Roguelike de turno (regra pesa mais que gráfico)

Crie um roguelike de turno em grid, arquivo único index.html, canvas 2D,
sem assets externos, mapa desenhado com retângulos e caracteres.

Loop: cada tecla de direção gasta 1 turno; todos os inimigos agem
depois do jogador. Andar sobre item coleta o item. Descer escada gera
um novo andar.

Mapa: grid 40x24 gerado proceduralmente com salas e corredores,
sempre com caminho garantido entre entrada e escada.

Números: jogador com 20 HP, dano 3; rato 5 HP dano 1; esqueleto 9 HP
dano 3; poção cura 8 HP. Cada andar soma +1 de HP nos inimigos.

Derrota: HP em zero, tela de morte com andar alcançado.
Vitória: chegar ao andar 8 e derrotar o chefe (30 HP, dano 5).

UI: HP, andar, inventário e log de combate com as 5 últimas ações.

Critério de aceite: jogável do teclado do início ao fim, sem turno
travado e sem erro no console.

Por que funciona: aqui o peso está nas REGRAS, não no visual. Geração procedural sem a exigência de "caminho garantido" é convite pra nascer um mapa onde a escada fica isolada, e tu só descobre isso no meio da run

FPS em Three.js (o mais ambicioso)

Crie um FPS em primeira pessoa com Three.js, entregue como um único
arquivo HTML. Zero assets externos: geometria, texturas e sons gerados
em runtime por código.

Loop: WASD move, mouse olha (pointer lock), clique atira, R recarrega.
Inimigos surgem em pontos fixos da arena e avançam até o jogador.

Números: jogador com 100 de vida; arma com 12 balas no pente e dano 25;
inimigo com 50 de vida, dano 10 por golpe e velocidade 3 u/s;
3 ondas com 5, 8 e 12 inimigos.

Derrota: vida em zero, tela de Game Over com R para reiniciar.
Vitória: limpar a onda 3, tela de vitória com tempo e precisão.

UI: crosshair, barra de vida, munição, contador de onda e menu inicial
que pede clique para ativar o pointer lock.

Critério de aceite: abrir no navegador, entrar em pointer lock no
primeiro clique e ser jogável até a vitória sem erro no console.

Sobre alcance real desse tipo de pedido, tem dois registros públicos que valem como referência

Matt Shumer publicou um FPS em Three.js apelidado de Claude of Duty gerado a partir de um único prompt, afirmando que tudo no demo é código próprio e que nenhum asset externo foi usado

E o usuário winch publicou um jogo WebGL em arquivo único, também de um prompt, com zero assets e tudo gerado em tempo de execução

Detalhe importante pra não vender ilusão: os dois registros são do Claude Opus 5, não do 5.5. Eu não tenho registro de que foram refeitos no modelo novo, então trata isso como referência de alcance do formato, não como benchmark do 5.5

O que aprendi pedindo projetos inteiros em um prompt só

Eu já fiz esse exercício de prompt único algumas vezes, e no vídeo eu mostro dois casos que ensinam bastante sobre jogo também

O primeiro: escrevi um prompt pedindo um aplicativo interativo completo, em um único arquivo, que rodasse sozinho, simulando o trânsito de uma cidade. Malha de ruas vista de cima, grade com cruzamentos, semáforos e carros se movendo

Mandei tudo em uma única interação, sem ida e volta

E veio funcionando, em menos de 10 minutos

O segundo foi mais detalhado: um sistema web, um "command center" pra criador de conteúdo, com a stack escolhida por mim, CRUD de ideias de vídeo, kanban, dashboard com três gráficos, busca e filtro por tag, autenticação por e-mail e senha, dados de exemplo já cadastrados e tema escuro por padrão

Nesse eu pedi explicitamente que o modelo escrevesse um plano antes de executar

E aí veio o ponto que me incomodou: ele não perguntou se devia seguir o plano, simplesmente executou direto, sem pedir confirmação. Achei estranho

Deu certo mesmo assim: em cerca de 15 minutos o sistema estava de pé, com tela de login e conta demo funcionando e o drag and drop do kanban funcionando também. Pareceu funcional, embora eu não tenha testado todas as funcionalidades do projeto

O que dá pra levar disso pro teu prompt de jogo:

• detalhe de regra compensa mais que detalhe de visual: o prompt do command center era muito mais específico que o do simulador, e é justamente nas regras (auth, kanban, filtro) que o resultado apareceu inteiro
• o modelo preenche lacuna sozinho e nem sempre pergunta: se tu escreveu "escreva um plano antes", conta com a possibilidade de ele já sair executando esse plano. Então o plano tem que estar certo desde o prompt
• tempo de execução de projeto único não é instantâneo nem é uma tarde: os dois casos aí ficaram na casa de dezenas de minutos, e isso é a ordem de grandeza que eu esperaria também de um jogo de arquivo único

Os dois resultados me deixaram satisfeito, mas segue valendo o óbvio: preciso testar mais pra conclusão definitiva

No vídeo tu vê os dois prompts na íntegra, o simulador de trânsito rodando e o command center com login e kanban funcionando na tela

Como ajustar effort e task budget para um pedido de jogo

Bloco curto e operacional, porque aqui tem comando de verdade

1. No Claude Code, /model troca o modelo e SALVA como padrão pras novas sessões. Se tu quer trocar só pra sessão atual, aperta a tecla s no seletor do /model
2. Ainda no Claude Code, /effort define o nível. Chamado sem argumentos, ele abre um slider interativo navegável pelas setas
3. Se o nível escolhido não for suportado pelo modelo ativo, o Claude Code cai pro maior nível suportado abaixo dele. Ou seja: não quebra, mas também não avisa em alto e bom som, então confere o que ficou valendo
4. Na API, o teto do loop inteiro vem do task budget

task_budget.total  // tokens para o loop agêntico inteiro:
                   // pensamento + chamadas de ferramenta + resultados + saída
                   // mínimo aceito: 20000 (abaixo disso retorna erro 400)

A divisão entre os dois é simples e vale decorar:

effort é profundidade por passo. Task budget é o teto do loop inteiro

Um controla o quanto ele pensa em cada etapa, o outro controla quanto trabalho ele pode fazer no total. São complementares, não substitutos. E como o modelo enxerga a contagem regressiva do budget, ele usa isso pra priorizar e encerrar de forma organizada em vez de simplesmente parar no meio

Quando o jogo sai quebrado: sintomas e o que corrigir no prompt

Quase todo defeito de jogo gerado em prompt único é rastreável a uma linha que tu não escreveu 😀

Sintoma: o jogo nunca acaba

Causa: faltou condição de vitória. Tu declarou só a derrota (ou nem isso), então o loop roda pra sempre e o "jogo" vira screensaver

Como prevenir: escreve as duas condições, com a tela que aparece em cada uma e o que acontece depois (restart, pontuação, tempo)

Sintoma: tela preta e erro de arquivo não encontrado no console

Causa: o código referencia imagem, som ou fonte que nunca existiu. Faltou travar "zero assets externos"

Como prevenir: proíbe explicitamente e dá a saída alternativa: tudo desenhado por código, som via API do navegador gerado em runtime, fonte do sistema. Proibir sem oferecer alternativa é meio caminho pro modelo improvisar de novo

Sintoma: o jogo veio pela metade ou com funcionalidades faltando

Causa: escopo maior que o entregável declarado, ou teto do loop curto demais pro tamanho do pedido. Lembra que a saída máxima é de 128.000 tokens: um FPS com cinco níveis e editor de fases não cabe num arquivo único gerado de uma vez

Como prevenir: corta o escopo ou sobe o entregável. Se o pedido é grande de verdade, aumenta o task budget e o effort antes de reclamar do resultado

Sintoma: a resposta tem comportamento diferente do que tu esperava do 5.5

Causa: classificadores de segurança podem redirecionar requisições feitas ao claude-opus-5-5 pra modelos anteriores. Pedido de cibersegurança tende a ir pro Claude Opus 4.8, e trabalho de biologia cai pro Claude Opus 5, a menos que a conta esteja verificada nos programas Life Sciences ou Cyber Verification da Anthropic

Isso pega jogo sim: tema de hacking, vírus, pandemia, arma biológica. Tu acha que está falando com o 5.5 e não está

Como prevenir: se o teu tema encosta nessas áreas e tu precisa do 5.5 mesmo, ou reescreve a fantasia do jogo, ou resolve a verificação de conta. Tome cuidado, porque o roteamento é silencioso

Vale a pena rodar isso no Opus 5.5?

Pra quem gera projeto grande de uma vez, os números do lançamento ajudam bastante

A leitura de cache a US$ 0,20 por milhão é o número que mais importa aqui, porque ela responde pela maior parte do custo em trabalho agêntico e de código. É exatamente o teu caso quando o modelo fica relendo o arquivo do jogo pra corrigir

A Anthropic também afirma que o Opus 5.5 entrega desempenho no nível do Claude Fable 5.1 na maior parte do trabalho e custa 40% menos pra rodar que o Opus 5, porque conclui as mesmas tarefas usando menos tokens

Na página viva do modelo no Artificial Analysis, ele marca 54 pontos no Intelligence Index na configuração Adaptive Reasoning, High Effort, Default Fallback. A mediana dos modelos comparáveis é 25

E tem o ajuste de estilo, que casa demais com esse exercício: informação crítica logo no começo, menos jargão corporativo e mais aderência às instruções de formatação do usuário. Prompt com entregável declarado ("um único arquivo index.html, zero assets") depende justamente disso pra sair do jeito que tu pediu

No quesito comportamento, a Anthropic diz que o Opus 5.5 obteve os melhores resultados de qualquer modelo já testado por ela na auditoria comportamental automatizada, a suíte de alinhamento com milhares de cenários simulados

Conclusão

O checklist é o produto aqui, não o jogo 🙂

Gênero em uma frase, loop de gameplay, regras e números fixos, vitória E derrota, stack e entregável travados, controles e HUD, critério de aceite, effort e task budget no tamanho do pedido. Isso serve pro teu próximo prompt de jogo e serve, com outras palavras, pro teu próximo prompt de sistema também

Conselho de quem já pediu coisa grande demais de uma vez: começa por um arcade de arquivo único, vê o que o modelo preenche sozinho e o que ele erra por falta de instrução tua, e SÓ depois parte pro FPS em Three.js

O Opus 5.5 é o primeiro lançamento da leva 5.5, e a Anthropic já anunciou Claude Sonnet 5.5 e Claude Haiku 5.5 como próximos, ainda sem data divulgada

Ou seja, tem mais coisa vindo por aí…

Faça o teste e me conta o que saiu, até o próximo post!