Como Definir o Escopo de um Jogo Indie Sem Se Afogar

A maioria dos jogos indie não morre por falta de talento, dinheiro ou engine. Morre porque o escopo do jogo indie foi definido no entusiasmo do primeiro dia: mundo aberto, crafting, multiplayer, vinte fases, história ramificada. Três meses depois o projeto tem dez sistemas pela metade, zero diversão comprovada, e o desenvolvedor abre um projeto novo "só pra descansar a cabeça". Você conhece o resto.

Escopo não é uma lista do que o jogo vai ter. É uma decisão sobre o que ele NÃO vai ter. Esse artigo é o processo que eu uso e ensino pra chegar nessa decisão: encontrar o core loop, montar um MVP jogável, cortar features com critério e estimar com honestidade.

Por que o escopo de jogo indie sai do controle

O escopo explode por três motivos que se alimentam.

Você projeta o jogo que joga, não o jogo que consegue fazer. Suas referências são Hollow Knight, Stardew Valley, Hades. Todos parecem "jogos pequenos de indie", e nenhum deles é. Stardew Valley levou anos de trabalho integral de um desenvolvedor obsessivo. Hades é um estúdio inteiro experiente. Quando sua régua de "jogo pequeno" está errada, todo escopo que você definir nasce errado.

Feature no papel é grátis. Escrever "sistema de crafting" no documento de design custa cinco segundos. Implementar custa semanas: UI, balanceamento, persistência, tutorial, bugs de interação com todos os outros sistemas. O documento de design aceita tudo; o calendário não.

Cada sistema multiplica os outros. O custo não soma, multiplica. Inventário sozinho é tranquilo. Inventário + multiplayer significa sincronizar inventário pela rede. Inventário + save system significa serializar tudo. Adicionar o sexto sistema custa muito mais caro que adicionar o segundo, porque ele precisa conversar com os outros cinco.

A consequência prática: a pergunta certa não é "o que deixaria meu jogo mais legal?". É "qual é a menor versão disso que já é um jogo?".

Comece pelo core loop, não pela lista de features

Core loop é o ciclo de ações que o jogador repete o tempo todo. Em Vampire Survivors: mover, sobreviver, escolher upgrade, ficar mais forte, repetir. Em um jogo de plataforma: pular, errar, tentar de novo. Se esse ciclo de 30 segundos não é divertido, nenhuma feature em volta salva o jogo. Se ele é divertido, o jogo já funciona quase pelado.

Então a primeira meta de qualquer projeto não é "fazer o jogo". É responder uma pergunta: o core loop é divertido? E você responde isso com um protótipo feio. Cubos cinzas, sem menu, sem som, sem arte. Uma ou duas semanas de trabalho, não meses.

Dois resultados possíveis, os dois bons:

• É divertido. Agora você tem fundação pra construir em cima, e cada feature nova pode ser testada contra ela: "isso melhora o loop ou só enfeita?"
• Não é divertido. Você acabou de economizar um ano. Ajuste o loop ou mate a ideia. Matar uma ideia na semana dois é vitória, não fracasso.

O erro clássico é pular essa etapa porque "eu sei que vai ser divertido". Ninguém sabe. Diversão não se deduz, se testa no controle.

MVP de jogo: a menor versão que alguém joga até o fim

MVP (produto mínimo viável) em jogo tem uma definição prática: a menor versão que um estranho consegue jogar do início ao fim e sentir o que o jogo é. Não é demo, não é protótipo. É o jogo inteiro, em miniatura.

Pra chegar nele, pegue sua lista de features e separe em três caixas:

Núcleo: sem isso não existe jogo. O core loop, uma condição de vitória ou derrota, e o mínimo de conteúdo pra sustentar uma sessão. Num plataforma: movimento, perigo, algumas fases, um fim.

Suporte: deixa o núcleo melhor, mas o jogo existe sem. Mais fases, mais inimigos, trilha sonora original, achievements, opções de acessibilidade. Entram depois que o núcleo está de pé, em ordem de impacto.

Sonho: o jogo dos seus sonhos, não o jogo atual. Multiplayer, mundo aberto, modo foto, New Game+, dublagem. Anote num arquivo chamado versao-2.md e feche o arquivo. Não é "nunca", é "não agora". Esse arquivo é o que permite cortar sem dor: a ideia não morreu, mudou de fila.

A regra de bolso pra caixa do núcleo: se você remover o item e o jogo continuar sendo jogável e reconhecível, ele não era núcleo. Aplique sem piedade. A primeira versão dessa caixa quase sempre ainda está grande demais; passe o filtro duas vezes.

E o teste final do MVP é externo: coloque na mão de alguém que não é seu amigo próximo e veja se a pessoa termina. Onde ela larga o jogo, ali mora seu problema real, que quase nunca é a feature que você queria adicionar.

Como cortar features sem matar o jogo

Cortar é a habilidade, definir escopo é só a primeira aplicação dela, porque o escopo vai tentar crescer de novo toda semana. Critérios que funcionam:

Corte sistemas, não polimento. O instinto é manter todos os sistemas e fazer todos "mais ou menos". É o pior corte possível: jogo raso em tudo. Faça o contrário. Cinco fases excelentes vendem mais que vinte medianas. Um sistema de combate profundo vale mais que combate + crafting + pesca + romance, todos rasos. Celeste é basicamente um botão de pulo e um dash polidos até o limite, e é um dos plataformas mais respeitados da década.

Pergunte o custo total, não o custo de implementar. Toda feature tem custo escondido: UI, tutorial, balanceamento, testes, e interação com cada sistema existente. Quando alguém (inclusive você) propõe uma feature, a pergunta é "quanto custa com tudo incluído e o que a gente NÃO vai fazer pra pagar isso?". Se a resposta não cabe, a feature vai pro versao-2.md.

Desconfie da feature que resolve tédio. Boa parte do feature creep nasce quando o desenvolvimento fica chato (balancear, corrigir bug, fazer a fase 7) e começar um sistema novo parece mais divertido. Sistema novo nessa hora não é design, é fuga. Reconhecer o padrão já resolve metade.

Estabeleça uma data de congelamento. A partir de certo ponto da produção, nenhuma feature nova entra, só conteúdo e correção. Sem congelamento, o jogo fica eternamente "quase pronto". Com congelamento, ele lança.

Estimando com honestidade

Estimativa de iniciante falha sempre pro mesmo lado: otimismo. Duas práticas corrigem boa parte.

Faça uma vertical slice antes de estimar o todo. Construa um pedaço pequeno do jogo com qualidade final: uma fase com arte, som, UI e polimento de verdade. O tempo que isso levar é sua régua real. Se uma fase finalizada levou três semanas, doze fases não levam doze semanas de conteúdo, levam isso mais integração, menus, balanceamento global, testes e a parte que sempre dá errado. Multiplique a primeira estimativa por dois e você ainda vai estar apertado; é desconfortável e é o que a prática mostra projeto após projeto.

Conte as horas reais, não as horas do calendário. "Seis meses de projeto" fazendo 10 horas por semana são cerca de 260 horas, o equivalente a um mês e meio de trabalho integral. Planeje pelo número de horas que você realmente tem, não pela data no calendário.

Qual o escopo realista pro primeiro jogo

Se é seu primeiro projeto completo, a resposta honesta: menor do que você está pensando agora, mesmo depois de ler este artigo.

Um primeiro jogo saudável tem um mecânica central, sessões curtas, arte que você consegue produzir (ou comprar barato) e semanas de produção, não anos. Algo na linha de um arcade com placar, um puzzle com algumas dezenas de níveis, um plataforma curto. Game jams são o melhor campo de treino justamente por isso: o prazo de 48 horas ou de uma semana força o músculo de cortar, que é o músculo que você vai usar a carreira inteira.

E terminar pequeno ensina o que nenhum projeto abandonado ensina: a reta final. Menu, save, build, página da loja, os 10% finais que tomam um esforço enorme e que você só aprende fazendo. Quem lançou um jogo minúsculo sabe mais sobre desenvolvimento do que quem tem três mundos abertos inacabados no HD. Inclusive sobre o lado comercial: publicar na Steam custa USD 100 de taxa do Steam Direct por jogo, e passar por esse processo uma vez já te coloca na frente.

Fechando

Escopo é uma aposta sobre o que você consegue terminar, e quem nunca terminou nada tende a apostar errado pra cima. O processo que corrige isso: prove o core loop com um protótipo feio, defina o MVP separando núcleo de sonho, corte sistemas em vez de polimento, estime pela vertical slice e congele features antes da reta final.

O jogo grande dos seus sonhos continua de pé. Ele só não é o primeiro da fila. Cada projeto pequeno terminado te deixa mais perto de conseguir fazê-lo de verdade, com o repertório de quem já lançou. Termine um jogo pequeno. Depois outro um pouco maior. É assim que se chega no grande.