← Caderno de laboratório

Antes de criar um jogo de plataforma: o que estudei e o que mantive

9 min de leitura

O que estudei antes de criar o Skyline Run — seis tipos de jogo de plataforma, o pulo, a câmera, a primeira fase —, o que escolhi quando o jogo já existia e o que os agentes de IA que o construíram erraram.

A primeira fase do meu jogo de plataforma tinha um buraco que devia ensinar o dash. Quando medi, um pulo comum conseguia atravessá-lo.

Isso veio depois. Antes de criar o Skyline Run, eu não sabia do que um jogo de plataforma é feito. Então estudei: que tipos existem, como um pulo deve ser sentido, o que a câmera deve ao jogador e como uma primeira fase ensina. Este post é essa pesquisa, mais o que escolhi quando o jogo já existia, como uma equipe de agentes de IA o construiu e onde a pesquisa chegou ao limite.

O personagem branco do Skyline Run atravessa um buraco de seis blocos entre telhados com um rastro ciano de dash aéreo, enquanto valores medidos do pulo e da fase emolduram a cena.
O Skyline Run hoje: um buraco de seis blocos que finalmente exige o dash.

Só quer jogar? Jogue o Skyline Run. Não precisa ler isto antes.

A versão curta

Esta é a ordem que eu daria a quem vai começar um jogo de plataforma pequeno. Ela parte das três perguntas do meu post sobre o jogo da velha.

  1. Escolha um tipo de jogo de plataforma e escreva o objetivo em uma frase.
  2. Descreva o pulo que você quer (altura, distância, tolerância) antes de escolher números.
  3. Garanta que a câmera mostre onde você vai cair antes de pular.
  4. Ensine uma ideia por vez e depois conecte início, lição, falha, nova tentativa e final.
  5. Meça, veja alguém jogar e corrija o que atrapalha antes de adicionar mais coisas.

Escolha um tipo de jogo de plataforma primeiro

Pular pode servir a jogos muito diferentes. Usei seis formas para enxergar o leque. Elas se sobrepõem, e os exemplos são só pontos de referência.

  • Precisão: movimento e timing repetíveis, como em Celeste.
  • Quebra-cabeça: resolver um problema espacial ou sistêmico, como em Braid.
  • Cinematográfico: animação, encenação e sequências roteirizadas, como em Inside.
  • Metroidvania: exploração reaberta por novas habilidades, como em Hollow Knight.
  • Híbrido roguelite: partidas repetidas com condições que mudam, como em Dead Cells.
  • Corrida: movimento para a frente e antecipação, como em Canabalt.

A ideia é contenção: um primeiro projeto escolhe um e deixa o resto.

No Skyline Run: precisão. O jogo inteiro em uma frase: chegue à saída no telhado de um distrito neon correndo, pulando e usando o dash; um perigo ou uma queda manda você de volta ao último checkpoint.

Essa escolha traz quatro perguntas que se alimentam o tempo todo: como o movimento responde, o que a câmera mostra, como uma fase ensina e o que acontece depois de uma falha.

Movimento, câmera, ensino pela fase e falha ou nova tentativa se conectam em um ciclo em que cada decisão pode provocar outra revisão.
Quatro perguntas, respondidas juntas e revisitadas.

Descreva o pulo antes de escolher números

O livro Game Feel, de Steve Swink, trata de como uma ação é sentida e de quão claramente o jogo responde a um comando. A palestra de Kyle Pittman na GDC, "Building A Better Jump", tornou isso prático para mim: comece pela altura, distância e tempo que você quer, não por um valor de gravidade. Ele também mostra altura de pulo variável e uma queda mais rápida depois do pico.

O texto "Celeste & Forgiveness", de Maddy Thorson, me deu três truques pequenos para comandos que chegam um instante cedo ou tarde demais:

  • Coyote time: você ainda consegue pular por um instante depois de sair correndo de uma borda.
  • Buffer de pulo: um pulo apertado pouco antes de pousar é executado no quadro do pouso.
  • Suspensão no pico: em Celeste, segurar o pulo reduz a gravidade pela metade no alto, dando tempo para alinhar o pouso.
Um arco de pulo mostra altura e distância junto de janelas curtas de comando perto de uma borda, do pouso e do topo do pulo.
Descreva o arco e suas janelas de tolerância primeiro; os números vêm depois.

No Skyline Run: um pulo completo sobe 56 px, três blocos e meio, e atinge o pico no tick 14 de um jogo a 60 Hz. Um toque de um tick dá um pulinho de 16,56 px, cerca de um bloco. O coyote time e o buffer de pulo permitem 5 ticks cada, cerca de 83 ms. A gravidade cai pela metade perto do topo enquanto você segura o pulo, e a gravidade na queda é 25% mais forte que na subida.

Mostre o pouso antes do pulo

Você não consegue se comprometer com um pulo se não vê onde ele termina. O trabalho da câmera é mostrar a próxima decisão, não só seguir o personagem.

A análise de câmeras em jogos de rolagem lateral de Itay Keren descreve uma janela de câmera: o jogador se move livremente dentro dela antes de a tela rolar. Em Rastan, a janela vertical tem a altura de um pulo. Fez suaviza uma câmera travada na vertical, enquanto Super Mario World pode ficar parado durante um pulo e se ajustar no pouso.

Uma janela de câmera limitada dá ao jogador espaço para se mover antes da rolagem e mantém a próxima área de pouso visível.
Um bom primeiro quadro mostra o destino sem se mover à toa.

No Skyline Run: a câmera olha 24 px à frente na direção em que você está virado. A janela para cima tem 72 px, mais que um pulo completo de 56 px, e a janela para baixo tem 40 px, com suavização nos dois eixos.

Ensine uma ideia por vez

O texto de Timothy J. Seppala no Engadget sobre Super Mario 3D World descreve uma lição em quatro passos. Ela vem de um jogo 3D, mas o formato funciona para uma primeira fase 2D:

  1. Apresente uma ideia onde errar custa pouco.
  2. Desenvolva a ideia com uma nova posição, ritmo ou consequência.
  3. Mude a ideia para que a primeira solução precise de ajuste.
  4. Conclua com um uso claro e siga em frente.
Quatro espaços conectados apresentam uma ação com segurança, desenvolvem, acrescentam uma mudança e depois concluem ou encerram a lição.
Uma ideia, quatro tempos.

No Skyline Run: foi aqui que a pesquisa se sustentou e meus números não. O buraco de ensino do distrito um tinha 5 blocos de largura e devia dizer "aqui você precisa do dash". Medido no motor do jogo, um pulo comum conseguia atravessá-lo. A correção foi um buraco de 6 blocos sobre um piso rebaixado: só o pulo deixa você cair no fosso, de onde dá para voltar e tentar de novo, e só pulo mais dash aéreo alcança o telhado do outro lado. No buraco seguinte, duas plataformas generosas tinham formado uma escada que permitia pular o dash; elas viraram uma única plataforma de recuperação que não pode virar atalho. A história completa está em Quando a medição corrigiu o salto.

O buraco de ensino, renderizado quadro a quadro pelo próprio motor do jogo. Primeiro, a partida vencedora gravada com o dash removido: o pulo não alcança e cai no fosso. Depois, a partida real: pulo, dash, travessia.
Um diagrama medido compara o buraco de ensino acidental de cinco blocos com o buraco corrigido de seis blocos e destaca o limite de um tick que tornava a passagem antiga pouco confiável.
A lição estava certa. A largura do buraco, não.

Torne a falha barata

Um jogo de plataforma é, em grande parte, falhar e tentar de novo, então o momento depois de um erro faz parte do design. Decida quando o controle para, onde o jogador volta e o que uma nova tentativa mantém.

No Skyline Run: uma queda ou um perigo trava os comandos por 18 ticks, 0,3 s, e depois você renasce no último checkpoint. Uma nova tentativa mantém seu tempo, suas mortes e seu checkpoint.

Como agentes de IA construíram o jogo, e o que erraram

Eu não escrevi o código do Skyline Run à mão. Em 19 de agosto, apontei o Claude Fable 5 para minhas anotações de pesquisa e pedi um plano de implementação detalhado. Ele escreveu um: constantes do motor, quatro salas e uma sala de ensino com "one 5-tile gap (jump-uncrossable)", ou seja, um buraco de 5 blocos que o pulo não atravessa.

Um agente Claude Opus 5 então conduziu a construção como orquestrador. Ele distribuiu o trabalho em ondas: agentes GPT-5.6 escreveram o motor, a fase e a página em paralelo, e agentes separados de QA e revisão checaram o que eles produziram. O plano resumia assim: implementadores, QA e avaliadores ficam separados, e o QA dá o veredito. A primeira versão jogável ficou pronta naquela mesma noite, em cerca de duas horas.

O erro é o mesmo em torno do qual este post gira. O orquestrador reajustou os números do plano e entregou aos agentes uma tabela intitulada "Measured ability envelope — authoritative for level authoring and tests" (envelope de habilidades medido, oficial para criar fases e testes). A linha do pulo dizia que um pulo atravessa 4 blocos e que "5 is impossible" (5 é impossível). Nada tinha sido medido no motor real ainda. Um agente transformou essa afirmação em teste, e o agente de QA o executou. O teste falhou: um pulo conseguia atravessar o buraco de 5 blocos.

O próprio diagnóstico do orquestrador foi que o buraco estava no fio da navalha: um pulo com coyote time no quadro exato conseguia atravessá-lo. O jogador continua no chão enquanto a borda esquerda da sua caixa de 12 px de largura ainda está sobre o telhado, então o ponto real de impulso ficava 12 px depois do que ele tinha modelado. Na mesma noite, ele declarou a fase "not completable" (impossível de concluir) quando o errado era a sua própria tabela de alcance, e um agente de revisão descobriu que segurar Shift enquanto apertava uma tecla de letra podia deixar você sem conseguir pular pelo resto da partida.

O que levei disso: um agente chamar um número de "medido" é uma afirmação, não uma medição. Quem pegou o erro foi outro agente, rodando a afirmação contra o motor real. Por isso a fase agora tem um teste fixo: uma partida vencedora gravada, de 1.304 ticks, que precisa concluir o distrito um sem nenhuma morte, sempre.

O que ficou de fora

A primeira versão era um distrito em quatro salas: correr, pular, um dash aéreo, cinco checkpoints, controles por teclado e por toque na tela, e arte provisória em blocos cinza. Um replay gravado conclui a fase em 21,7 segundos, sem mortes. Em 30 de agosto, a campanha já tinha dez distritos.

Todo o resto esperou: outras habilidades de movimento, inimigos, combate, itens, som, arte final, suporte a controle, salvamento, editor de fases e níveis de dificuldade. Nada disso está escondido depois da tela final.

Onde a pesquisa chegou ao limite

Ler me deu as perguntas certas. Não podia me dar números verdadeiros para o meu jogo; só medir o motor rodando fez isso. E ainda não vi ninguém jogar sem orientação, então ainda não sei se uma pessoa entende a lição do dash.

O que veio depois: eu medi o pulo, depois transformei o jogo em campo de treino e perguntei se uma rede neural conseguiria aprender a correr pelos telhados. Ela decorou um único distrito.

Você pode ajudar: jogue o distrito um e me conte onde caiu primeiro e se percebeu a lição do dash. Uma DM ou um comentário no @ai.maker.lab no Instagram chega até mim.

IA e automação ajudaram na pesquisa, nas ilustrações, na tradução e na revisão deste artigo, e agentes de IA construíram o jogo que ele descreve. Sou dono do AI Maker Lab e do Skyline Run e respondo pela redação final e pela checagem das fontes.

Fontes

Continue lendo