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ê.

Escopo é um assunto grande o bastante pra ter guia próprio. Este post é o panorama de gestão do projeto inteiro; se o seu problema específico é o escopo inchando, dois textos descem mais fundo do que cabe aqui: como controlar o escopo e vencer o scope creep, focado em identificar e frear o crescimento, e como definir o escopo de um jogo indie do zero, focado em achar o core loop e montar o MVP antes de produzir.

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. Se ajuda a enxergar o caminho inteiro, vale montar um roadmap com milestones do protótipo ao lançamento e usar ele como mapa do projeto.

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.

Exemplo: a quebra em milestones de um jogo pequeno

"Quebre em milestones" soa fácil até você encarar a tela em branco. Veja como fica para um projeto concreto e pequeno: um arcade de nave com placar, feito por um dev solo nas horas vagas. Cada milestone tem uma definição de pronto que fecha como uma porta:

Repare em três coisas. Primeiro, o jogo é jogável e perdível já no milestone 2, antes de qualquer arte: se a nave não for divertida de pilotar aí, nenhuma arte conserta, e você descobriu isso em duas semanas. Segundo, o milestone 3 é o vertical slice, e o tempo que ele levar de verdade recalibra o milestone 4; se a slice levou três semanas em vez de duas, o conteúdo também vai estourar, e melhor saber agora. Terceiro, a reta final tem peso próprio de milestone, porque menu, save, build e loja são os famosos 10% que custam 40% do esforço e que a maioria subestima.

Cada milestone desses vira uma coluna ou um conjunto de cartões num quadro, e a forma prática de tocar isso no dia a dia está em como organizar as tarefas com um Kanban: a cada semana você só olha o cartão da vez, não o monstro inteiro. Pra escolher onde montar esse quadro sem pagar nada, o comparativo de ferramentas para gerenciar o projeto de jogo ajuda a não perder tempo testando dez apps. O ponto não é a ferramenta, é ter um "pronto" claro em cada etapa, pra o projeto avançar por portas que fecham em vez de tarefas que nunca terminam.

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? Multiplayer é o exemplo campeão disso, e por isso vale decidir cedo se vale a pena fazer um jogo multiplayer antes de deixá-lo dobrar o seu escopo. 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. Técnicas mais finas de estimativa, com buffer e dados do seu próprio histórico, estão no guia de como estimar tempo de tarefas no desenvolvimento de jogos. 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. Escopo estourado é só um dos perigos previsíveis do projeto, e dá pra antecipar quase todos com uma gestão de riscos do jogo feita ainda no começo.

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.

A revisão semanal: o hábito que segura o projeto

Plano bom morre sem manutenção. Definir escopo e milestones no começo não basta: o projeto só fica sob controle se você revisa o rumo em intervalo curto e fixo. O hábito mais barato e mais eficaz que conheço é uma revisão semanal de quinze minutos, sempre no mesmo dia, com três perguntas.

O que fechou essa semana? Olhe o milestone da vez e marque o que de fato ficou pronto, com a definição de pronto que você escreveu, não "quase pronto". Se nada fechou duas semanas seguidas, é sinal de que a tarefa está grande demais e precisa ser quebrada, ou de que o escopo voltou a crescer sem você notar.

O que entrou na lista que não deveria? Toda semana aparecem ideias novas. A revisão é o filtro: cada item novo vai pro core, pra lista "talvez depois" ou pro lixo. Decidir isso uma vez por semana, com calma, evita que a ideia da terça-feira vire um sistema inteiro na quinta.

A estimativa ainda bate? Compare o tempo que o milestone atual está levando com o que você planejou. Se estourou, não finja que vai recuperar: recalibre os milestones seguintes com o ritmo real, que é o único dado honesto de velocidade que você tem. É a mesma lógica de estimar o tempo das tarefas, só que aplicada em loop, com o seu próprio histórico alimentando a próxima estimativa.

Esse ritual cabe em qualquer quadro: no fim da revisão você reorganiza os cartões do Kanban pra refletir a decisão, e pronto. Quinze minutos por semana custam quase nada e são o que diferencia um plano que vira jogo de um plano que vira enfeite de pasta. Projeto sem revisão regular não falha de uma vez: ele deriva, devagar, até você não reconhecer mais o escopo que tinha combinado consigo mesmo.

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.