HeapPlay

Qual deve ser o tamanho do seu primeiro jogo?

Pequeno o bastante para terminar: uma ação, uma tela, um jeito de ganhar ou perder e alguns minutos de jogo. Veja como cortar uma ideia maior até esse tamanho.

Pequeno o bastante para você conseguir terminar: uma única coisa que o jogador faz, uma tela, um jeito de ganhar ou perder, e um jogo inteiro que leva alguns minutos para jogar. Se você consegue construir isso em um fim de semana, ou em duas semanas de noites, é o tamanho certo. Um assistente de programação com IA leva você mais cedo a uma versão jogável, mas não muda a resposta, e este artigo explica por quê. Para cortar uma ideia maior, escreva o jogo em uma frase, mantenha só o que essa frase precisa e passe todo o resto para uma lista chamada "depois".

Como é um jogo pequeno?

Use quatro limites.

  • Uma ação. O jogador se move, ou pula, ou combina peças, ou mira. Uma delas.
  • Uma tela, ou uma fase que se repete e fica mais difícil.
  • Um jeito de ganhar ou perder. Uma pontuação a bater, um cronômetro ou vidas que acabam.
  • Alguns minutos entre apertar "começar" e ver o resultado.

Duas referências públicas mostram que um jogo dentro desses limites é um jogo de verdade.

A primeira é uma game jam. Na categoria Compo da Ludum Dare, uma pessoa faz um jogo do zero em 48 horas; a categoria Jam dá 72 horas e permite equipes. As regras descrevem a participação ideal como um jogo jogado no navegador, em alguns minutos, sozinho. Era o que a página de regras dizia em 9 de outubro de 2026.

A segunda é um tutorial. O 2D breakout game da MDN tinha onze lições no mesmo dia: um canvas, uma bola em movimento, paredes, uma raquete, fim de jogo, um campo de tijolos, uma pontuação e uma vitória, vidas extras, e depois animações, botões e um pouco de acaso. Essa lista mostra bem o que "completo" quer dizer nesse tamanho.

Um jogo pequeno e completo temPor enquanto, dá para ficar sem
Uma ação que o jogador repeteUm segundo modo de jogo
Uma tela ou uma fase que se repeteUm mapa do mundo, um editor de fases
Um jeito de perder, e uma pontuação ou um objetivoUma história, cenas de corte
Um começo e um recomeçoContas, jogos salvos, jogo online
Controles mostrados na telaUma loja, melhorias, configurações

Por que o tamanho pequeno ainda importa quando uma IA escreve o código?

Porque escrever o código nunca foi o trabalho todo. Um assistente encurta a escrita. Três coisas continuam com você.

Você ainda precisa jogar cada mudança. Alguém tem que abrir o jogo depois de cada mudança, experimentar e decidir se ficou melhor do que antes. Esse alguém é você.

Os recursos se multiplicam. Um recurso novo tem que funcionar com todos os que já existem. Três recursos formam três pares que podem entrar em conflito. Seis formam quinze. Doze formam sessenta e seis. A verificação cresce muito mais rápido do que a lista de recursos.

Três pontos ligados por 3 linhas, seis pontos ligados por 15 linhas, doze pontos ligados por 66 linhas
Cada ponto é um recurso. Cada linha é um par de recursos que precisa funcionar em conjunto.

Um pedido mexe em mais do que diz. "Adicione uma loja" parece uma tarefa só. Ela muda a pontuação, a tela de pausa, os controles e o que é salvo, e cada uma dessas coisas precisa ser conferida depois, seja quem for que escreveu o código.

Um jogo pequeno é um jogo que cabe na sua cabeça. Você consegue descrever uma mudança com exatidão, ler o que voltou e perceber o que ela quebrou.

Quanto cada recurso a mais custa depois?

Custa de novo toda vez que você acrescenta uma plataforma ou um idioma. Vimos isso com KittenGalaxy, o jogo de tiro hospedado no HeapPlay.

Quando adicionamos controles por toque, o trabalho foi contado por tela, não por jogo: o menu, a entrada do nome, o voo, a loja, o desafio de matemática e as telas de fim de jogo e de finais precisaram cada um dos seus próprios controles. Quando o jogo passou a ter dez idiomas, cada tela foi conferida em cada um deles, como registra a página do jogo.

Nenhum dos dois trabalhos foi um erro. Mas o tamanho de ambos foi definido pelo número de telas que o jogo já tinha. Um jogo com uma tela paga esse preço uma vez.

Como cortar uma ideia até esse tamanho?

  1. Escreva o jogo em uma frase: o que o jogador faz e como termina. Por exemplo: "Você move uma nave para a esquerda e para a direita e atira nos invasores até suas vidas acabarem."
  2. Liste todo o resto que você imaginou. Chefes, uma loja, dois jogadores, uma história. Escreva tudo, para que nada se perca.
  3. Mantenha só o que a frase precisa. Se a frase continua verdadeira sem um recurso, o recurso vai para a lista "depois". Ele fica adiado, não apagado.
  4. Corte conteúdo antes de cortar a ideia. Um tipo de inimigo, não cinco. Uma onda que acelera, não vinte fases.
  5. Defina o prazo antes de começar. Um fim de semana, ou duas semanas de noites. Quando você se atrasar, tire algo do jogo e mantenha a data.

Veja esse exemplo depois do corte.

Na ideiaPrimeira versãoDepois
Uma nave que se move e atiraSimNada
Cinco tipos de invasorUmMais quatro
Vinte fasesUma onda que aceleraFases
Chefes, uma loja, melhoriasNãoSim
Dois jogadoresNãoSim
Um ranking mundialA melhor pontuação guardada no navegadorSim

Como manter esse tamanho trabalhando com um assistente?

  • Coloque a frase e a lista "depois" em um arquivo do projeto, e aponte o assistente para ele no começo de cada sessão.
  • Peça um item por vez, e jogue o jogo antes de pedir o próximo.
  • Salve uma versão que funciona antes de cada pedido, como um commit no controle de versão, para que uma mudança ruim possa ser desfeita.
  • Quando uma mudança trouxer mais do que você pediu, tire o que sobra. Recursos que ninguém pediu também são escopo.

Como saber que está terminado?

Decida antes de começar e escreva. Um primeiro jogo está terminado quando:

  • um desconhecido consegue iniciá-lo a partir de um link sem uma palavra sua;
  • os controles aparecem na tela;
  • dá para perder, e começar de novo sem recarregar a página;
  • você o jogou do começo ao fim em cada dispositivo que diz ser compatível, e diz quais dispositivos não testou.

Depois, coloque o jogo onde as pessoas possam jogar. Um jogo tão pequeno ainda é um jogo: as regras de envio do HeapPlay pedem um jogo real e jogável com um link oficial, e não definem tamanho mínimo. Você pode enviá-lo sem conta, e um editor analisa cada envio antes de ele aparecer.

O que acontece com a lista "depois"?

Ela vira o seu plano, em uma ordem que você não precisa mais adivinhar. Quando as pessoas jogarem a versão pequena, o que elas disserem vai indicar qual item pegar primeiro. Adicione esse, publique como uma nova versão e ouça de novo.

Perguntas frequentes

Quanto tempo um primeiro jogo deve levar? Não existe uma resposta medida. Escolha um limite que você consiga cumprir e ajuste o jogo a ele. A Ludum Dare dá aos participantes 48 ou 72 horas.

Um clone de um clássico é suficiente? Como prática, sim: você já sabe como é o "terminado". Antes de mostrar a outras pessoas, mude uma coisa para que ele seja seu.

Meu primeiro jogo deve ser o jogo dos meus sonhos? Faça primeiro a menor parte jogável dele, e deixe o resto na lista "depois".

Posso começar maior porque um assistente de IA escreve o código? Você vai chegar mais cedo a uma versão jogável. Jogar, conferir e decidir continuam sendo com você, e crescem a cada recurso.

Vale a pena publicar um jogo de três minutos? Sim, se estiver completo. Os jogadores podem dar nota e avaliar, e os desenvolvedores verificados podem registrar cada nova versão e o que mudou.

scope first-game prototypes

Está fazendo um jogo? Envie-o ao HeapPlay e veja o que os desenvolvedores recebem.