Como Gerenciar um Projeto de Jogo Sem Ele Virar um Monstro

Se você quer saber como gerenciar um projeto de jogo, a primeira verdade desconfortável é essa: o maior inimigo do dev indie não é a parte técnica, é o escopo. Você provavelmente não vai abandonar seu jogo porque travou num bug de física ou porque não entendeu shaders. Vai abandonar porque o projeto cresceu tanto que terminar virou impossível, a motivação acabou, e começar do zero outra ideia parecia mais fácil do que encarar o monstro que o atual virou.

Eu já vi (e já fui) o dev com dez projetos na pasta e zero jogos publicados. Não é falta de talento. É falta de gestão de escopo. Este artigo é sobre como fechar o escopo, manter ele fechado, e de fato terminar um jogo, mesmo que pequeno.

Por que escopo grande mata projeto

O escopo não te mata de uma vez. Ele te mata aos poucos, com decisões que parecem inofensivas no momento.

Você começa com "um plataformer simples". Aí pensa "seria legal ter um sistema de upgrades". Depois "e se tivesse chefões com fases?". Logo vem "preciso de um mapa-múndi pra conectar os níveis", "um sistema de save robusto", "umas cutscenes pra dar contexto". Cada item parece pequeno. Nenhum deles, sozinho, parece um problema. Mas a soma transforma um jogo de três meses num projeto de três anos.

Isso tem nome: scope creep. É o crescimento silencioso do escopo, feature por feature, sem que ninguém tenha decidido conscientemente fazer um jogo maior. E ele é traiçoeiro porque cada adição vem disfarçada de boa ideia. O problema nunca é a feature isolada. É que você nunca disse não a nenhuma.

O custo real do escopo grande não é só o tempo de desenvolvimento. É a motivação. Projeto que não mostra progresso visível desanima. Quando você trabalha três meses e o jogo ainda parece 5% pronto porque a meta era gigante, seu cérebro conclui (com razão) que isso nunca vai acabar. E aí entra a tentação mais perigosa do dev iniciante: começar um projeto novo, limpo, cheio de promessa. O ciclo recomeça. Dez pastas, zero jogos.

Defina o escopo mínimo: o core do jogo

A pergunta que destrava tudo é: qual é a única coisa que faz esse jogo ser esse jogo?

Em todo jogo existe um core, um loop central de mecânica que é a alma da experiência. Num roguelike de tiro, é o ato de atirar, desviar e ficar mais forte. Num puzzle, é a sacada de resolver o quebra-cabeça. Num jogo de fazenda, é plantar, colher e ver crescer. Esse loop é inegociável. Todo o resto é decoração que orbita ele.

Pra definir o escopo mínimo, faça este exercício honesto. Liste tudo que você imagina no jogo. Depois, pra cada item, pergunte: o core funciona e é divertido sem isso? Se a resposta for sim, o item não faz parte do escopo mínimo. Ele vai pra uma lista separada que eu chamo de "talvez depois". Não jogue fora, só tire da frente.

O escopo mínimo é o menor conjunto de coisas que ainda forma um jogo completo e jogável. Se você cortar mais um pedaço, deixa de ser um jogo e vira uma demo quebrada. Esse é o alvo. Não é o jogo dos seus sonhos. É a versão que você consegue terminar, e que ainda assim é boa naquilo que se propõe a fazer.

Um sinal de que você acertou o escopo mínimo: dá pra descrever o jogo inteiro numa frase, e essa frase não tem "e também" nem "além disso". "Um jogo onde você empilha caixas com física ruim pra alcançar a saída." Pronto. Se a sua frase tem cinco vírgulas e três conjunções, o escopo ainda está grande.

Vale escrever isso num documento de design enxuto pra não esquecer. Não precisa de cem páginas. Se quiser um ponto de partida, montei um guia sobre como escrever um GDD que serve de bússola sem virar um romance que ninguém lê.

Milestones e vertical slice: como medir progresso de verdade

Escopo definido, o próximo problema é não se perder no caminho. É aqui que entram os milestones.

Milestone é um ponto de chegada concreto, com uma definição clara de "pronto". Não é "trabalhar no combate". É "o combate contra o inimigo básico está funcional, com dano, morte e feedback visual". O primeiro é uma tarefa vaga que pode durar pra sempre. O segundo é uma porta que fecha. Você sabe exatamente quando passou por ela.

Quebre o projeto em milestones pequenos, de uma a duas semanas cada. Cada milestone deve produzir algo que você pode rodar, jogar e mostrar pra alguém. Isso resolve o problema da motivação: você tem vitórias frequentes em vez de uma linha de chegada distante e abstrata.

O milestone mais importante de todos é o vertical slice. Em vez de fazer o jogo inteiro num nível de qualidade "rascunho" e só depois polir tudo (horizontal), você faz uma fatia pequena no nível de qualidade final. Uma fase, um inimigo, uma arma, mas com arte de verdade, som de verdade, interface de verdade, polimento de verdade. Do jeito que estaria na versão que você venderia.

O vertical slice responde a pergunta mais cara do projeto: esse jogo é bom e é possível? Se a fatia completa é divertida, você tem prova de que vale a pena produzir o resto. Se ela é morna mesmo polida, melhor descobrir agora, com uma fase feita, do que com vinte. É a mesma lógica do protótipo, mas um passo adiante. Aliás, antes mesmo do vertical slice, o protótipo cinza valida se a mecânica é divertida. Se você ainda não validou isso, comece por um protótipo rápido e descartável antes de investir em produção.

Cortar features sem dó: kill your darlings

Aqui está a parte que dói. Gerenciar escopo não é só planejar bem no começo. É cortar coisas durante o projeto, inclusive coisas que você ama.

"Kill your darlings" é uma expressão de escritores que se aplica perfeitamente a jogos. Os seus darlings são aquelas features que você acha geniais, que te empolgaram, que talvez tenham sido o motivo de você começar o jogo. E justamente por isso são as mais perigosas: você as defende mesmo quando elas estouram o cronograma, complicam o código e atrasam tudo o que importa.

O critério de corte é frio: a feature serve o core ou serve o seu ego? Aquele sistema de clima dinâmico com chuva que afeta a física é incrível. Ele torna seu jogo de puzzle melhor, ou só te deu vontade de programar chuva? Seja honesto. Se a resposta for "é legal mas não é necessário", vai pra lista "talvez depois". Pós-lançamento existe. Update existe. Mas só se houver um lançamento primeiro.

Uma forma prática de cortar sem sentir que está jogando trabalho fora: trate a lista "talvez depois" como conteúdo de versão 1.1. Você não cancelou a ideia, só adiou. Isso tira o peso emocional do corte. A maioria dos jogos terminados é cheia de features que o autor sonhou e nunca implementou, e ninguém sente falta, porque o jogo que existe é melhor que o jogo perfeito que nunca saiu.

Cronograma realista: multiplique sua estimativa

Devs são otimistas crônicos com prazo. Você estima que uma feature leva dois dias, e ela leva uma semana, porque você esqueceu de contar os bugs, o playtesting, o "ah, isso quebrou outra coisa", e a vida real que acontece fora do código.

Uma regra que funciona na prática: pegue sua estimativa honesta e multiplique. Se você acha que o jogo leva três meses, planeje pra seis. Não é pessimismo, é estatística da sua própria experiência. Quase ninguém termina um jogo no prazo que estimou no começo, e quem termina geralmente cortou escopo no caminho.

Se você trabalha no jogo nas horas vagas, sê ainda mais conservador. Duas horas por noite, com cansaço do trabalho principal, rendem bem menos que duas horas de foco fresco. Conte isso no plano. Um cronograma realista evita o pior dos cenários: a frustração de estar "atrasado" o tempo todo em relação a um prazo que nunca foi viável.

O "jogo terminável": prefira pequeno e pronto

Existe um conceito que muda a cabeça de quem está preso no ciclo de não terminar nada: o jogo terminável.

Um jogo terminável é um projeto pequeno o suficiente pra você de fato chegar ao fim, lançar, e aprender com o ciclo completo de desenvolvimento. Não é o seu RPG dos sonhos. É um jogo de uma mecânica, com começo, meio e fim, que cabe na sua realidade de tempo e habilidade hoje.

Terminar um jogo pequeno ensina mais que abandonar dez grandes. Você passa pelas fases que ninguém fala: o tédio dos 80% finais, o polimento, o bug que só aparece no build final, a publicação, o marketing. Essas etapas são onde a maioria desiste, e são exatamente as que você precisa praticar. O seu décimo jogo pode ser o RPG ambicioso. Mas chegue lá tendo terminado nove jogos pequenos, não tendo abandonado nove grandes.

Pense em escopo como músculo. Cada jogo terminado aumenta o tamanho do que você consegue terminar da próxima vez. Quem nunca terminou nada não tem base pra estimar nem pra encarar o tédio do fim. Pequeno e pronto vence grande e abandonado, sempre.

Sinais de que o escopo explodiu

Como saber, no meio do projeto, que o escopo saiu do controle? Alguns sinais claros:

• Você não consegue mais descrever o jogo numa frase sem usar "e também".
• A data de lançamento que você imaginava ficou pra "ano que vem" sem que você tenha decidido isso de propósito.
• Faz semanas que você trabalha e o jogo não parece mais perto de pronto.
• Você está fazendo sistemas (inventário, menu complexo, save robusto) antes do core estar divertido.
• A lista de tarefas só cresce. Cada item que você risca gera dois novos.
• Você começou a fantasiar sobre um projeto novo e mais simples. Esse é o sinal mais honesto de todos.

Se você reconheceu três ou mais desses, pare. Não acelere, não trabalhe mais horas. Sente e corte escopo. Volte pra pergunta do core: qual é a menor versão disso que ainda é um jogo? Reduza pra ela. É mais doloroso admitir que o escopo explodiu do que continuar empurrando, mas continuar empurrando é como a maioria dos projetos morre, exaustos, a poucos passos de lugar nenhum.

Se você está começando agora e quer evitar as armadilhas mais comuns antes mesmo de cair nelas, vale dar uma olhada nos erros mais frequentes de quem começa a desenvolver jogos. Escopo grande está no topo da lista, e não é coincidência.

O resumo honesto

Gerenciar um projeto de jogo é, no fundo, gerenciar a sua própria ambição. A técnica você aprende com tempo e tutoriais. A disciplina de fechar o escopo, cortar o que ama e terminar algo pequeno é o que separa quem tem jogos publicados de quem tem pastas cheias de protótipos abandonados.

Defina o core. Corte o resto pra uma lista de "depois". Trabalhe em milestones que você consegue mostrar. Faça um vertical slice pra provar que o jogo é bom antes de produzir tudo. Multiplique seu prazo. E escolha um jogo terminável, não o jogo dos seus sonhos, não ainda. Termine um. Depois outro. O monstro só nasce quando você deixa o escopo crescer sem olhar. Olhe sempre.