Como Fazer um Cronograma de Jogo Indie Que Você Cumpre

Fazer um cronograma de jogo indie é a tarefa que quase todo desenvolvedor independente faz mal na primeira vez, e a boa notícia é que dá pra fazer bem sem virar gestor de projeto profissional. O problema quase nunca é preguiça ou falta de talento. É que a gente estima o jogo pela parte que imagina fazendo (a mecânica legal, o chefe épico) e esquece o resto, que é a maior parte do trabalho. Este texto mostra como montar um cronograma para fazer um jogo que resista ao contato com a realidade, sem prometer datas que você não vai cumprir.

Vou ser honesto sobre uma coisa desde o começo: nenhum cronograma sobrevive intacto até o lançamento. O objetivo não é adivinhar o futuro com precisão. É ter um plano bom o bastante pra você perceber cedo quando está atrasando, e ter as ferramentas pra decidir o que fazer a respeito antes que seja tarde.

Por que a maioria dos indies estoura o prazo

Antes de montar o cronograma, vale entender por que ele costuma quebrar. São sempre os mesmos culpados.

O primeiro é subestimar cada tarefa. Quando você pensa "faço o sistema de inventário em dois dias", está imaginando o caminho feliz: o código que guarda os itens. Você não está imaginando arrastar item entre slots, empilhar quantidades, salvar o inventário no save, o ícone que não carrega, o bug de item que duplica. A tarefa que parecia de dois dias vira uma semana, e isso se repete em cada feature do jogo.

O segundo é esquecer o trabalho invisível. Todo mundo estima as mecânicas. Quase ninguém estima os menus, as telas de opções, o rebind de controles, o suporte a controle de videogame, a localização, o áudio, as transições, o tutorial, o polimento de feedback (screen shake, partículas, som de clique). Esse trabalho invisível é fácil metade do projeto e some das estimativas iniciais.

O terceiro é ignorar bugs e polimento como fases próprias. Bug não é imprevisto, é certeza. Um jogo passa semanas ou meses só em correção e ajuste depois que "está pronto". Se seu cronograma termina no dia em que a última feature funciona, ele está errado por construção.

O quarto, e o mais silencioso, é o marketing. Página na Steam, trailer, GIFs, wishlist, contato com criadores de conteúdo, demo. Isso é trabalho de produção também, e rouba semanas do calendário. Um jogo pronto que ninguém sabe que existe não vendeu.

Como quebrar o jogo em marcos

A base de um cronograma que funciona não é uma lista de tarefas soltas com datas. É uma sequência de marcos (milestones), cada um com um objetivo claro e um estado do jogo definido. A indústria usa uma escada que serve muito bem pro indie:

• Protótipo: responde uma única pergunta, "isso é divertido?". Arte de rascunho, quadrados coloridos, tudo feio. O protótipo é descartável e existe pra você descobrir cedo se a ideia central segura o jogo. Se o protótipo não é divertido, mais arte não conserta.
• Vertical slice: uma fatia pequena (2 a 5 minutos) do jogo com qualidade final. Arte, som e jogabilidade no nível do produto acabado. É o marco que prova o jogo pra você mesmo, pra publishers e pra imprensa. Diferente do protótipo, o vertical slice não se joga fora.
• Alpha: o jogo está feature complete. Todas as mecânicas e sistemas existem, mesmo que cheios de bugs e sem polimento. Não entra feature nova depois da alpha. A partir daqui, você constrói conteúdo e corrige, não inventa.
• Beta: o jogo está content complete. Todas as fases, inimigos e itens estão no lugar. O foco vira estabilidade, balanceamento e polimento. Beta é a fase dos playtests sérios com gente de fora.
• Gold: acabou. O build final está pronto pra publicar. Na prática, gold vem depois de uma fase de correção de bugs mais chata do que você imagina.

Pensar em marcos, e não em datas soltas, muda o jogo porque cada marco tem um critério de "terminou" que não depende de opinião. Ou o jogo está feature complete ou não está. Isso corta a autoenganação de "acho que estou em 80 por cento" (todo projeto fica em 80 por cento por metade do tempo).

Antes de montar os marcos, vale ter o escopo escrito em algum lugar. Um documento de design enxuto, o GDD, é o que te diz o que precisa existir pro jogo ficar "completo", e é a referência que você usa depois pra decidir o que corta.

Como estimar tarefas com folga

Dentro de cada marco, você quebra o trabalho em tarefas. A regra que mais ajuda é: se uma tarefa passa de dois dias na estimativa, ela ainda está grande demais. Quebre mais. "Fazer o chefe" não é tarefa, é um projeto. "Fazer a máquina de estados do chefe", "animar o ataque giratório", "programar a fase 2 de fúria" são tarefas.

Com as tarefas pequenas, estime cada uma no seu melhor palpite honesto. E aí vem a parte que ninguém gosta de aceitar: multiplique o total por 1,5 a 2. Não é pessimismo, é estatística. Suas estimativas são sistematicamente otimistas porque você estima o caminho feliz. O multiplicador cobre o retrabalho, os bugs e as tarefas que você esqueceu de listar. Depois de alguns meses, você mede seu erro real (compara o estimado com o gasto) e calibra o multiplicador pra você mesmo.

Um detalhe prático: estime em dias de trabalho ideais, não em dias de calendário. Você não programa oito horas líquidas por dia. Tem e-mail, tem a build que não compila, tem o dia ruim. Uma boa conversão é assumir que um dia de calendário rende meio dia ideal de trabalho focado. Se você é indie de meio período, com um emprego durante o dia, essa conta fica ainda mais dura, e é melhor encarar isso no papel do que descobrir na marra.

Buffer para imprevistos

Além da folga por tarefa, reserve um buffer no nível do cronograma inteiro: 20 a 30 por cento do prazo total, sem tarefa nenhuma alocada. Esse tempo não é "folga pra descansar", é a reserva que absorve o imprevisto que você não tem como listar hoje: o bug que trava tudo por uma semana, a placa de vídeo que morre, a feature que você refez do zero porque a primeira versão não era divertida.

Projeto sem buffer é projeto que atrasa no primeiro tropeço, porque não tem para onde o tempo ir. Um erro comum é preencher o buffer com "mais uma featurezinha" assim que sobra folga. Não faça isso. O buffer só existe enquanto está vazio. No dia em que você aloca tarefa nele, ele deixou de ser buffer.

Como lidar com scope creep no cronograma

Scope creep é o inimigo número um do prazo, e ele não chega como uma decisão grande. Chega como dez ideias pequenas. "Seria legal ter um pet que segue o jogador." "E se cada fase tivesse um segredo escondido?" "Podia ter um modo difícil." Cada ideia, sozinha, parece barata. Somadas, empurram o lançamento por meses.

O controle não é dizer não pra toda ideia nova (algumas são ótimas e melhoram o jogo). O controle é ter um lugar pra ideia esperar e uma regra de troca. O lugar é uma lista de "talvez depois", separada do cronograma ativo. A regra é: nada entra no escopo atual sem algo de valor equivalente sair. Se o pet entra, o modo difícil sai, ou o segundo bioma vira DLC futura. Isso força a ideia a competir pelo tempo, em vez de só se somar a ele.

O momento mais importante pra segurar o escopo é a transição pra alpha. Depois que o jogo está feature complete, a porta pra feature nova fecha. Toda ideia daí pra frente vai pra lista de "próximo jogo" ou "atualização pós-lançamento". Sem essa trava, você nunca chega na beta, porque sempre tem mais uma coisa legal pra adicionar.

Ferramentas simples: planilha e Kanban

Você não precisa de software de gestão caro. Duas ferramentas resolvem quase tudo.

A planilha é pro planejamento macro. Uma aba com os marcos, as datas-alvo e o buffer. Outra aba com as tarefas, cada uma com estimativa, tempo real gasto e status. A coluna que compara estimado com real é ouro: depois de um mês, ela te mostra seu erro médio e calibra suas próximas estimativas. Google Sheets ou Excel bastam.

O quadro Kanban é pro dia a dia. Colunas "A fazer", "Fazendo" e "Feito", com cada tarefa num cartão. Trello, Notion, um quadro do GitHub Projects, ou até post-its numa parede. A regra sagrada do Kanban é limitar quantas tarefas ficam em "Fazendo" ao mesmo tempo (idealmente uma ou duas). Isso te obriga a terminar antes de começar, que é o oposto do instinto de pular pra parte mais divertida e deixar dez coisas pela metade.

Não invente uma máquina de processo elaborada. Pra um projeto solo ou de dupla, planilha mais Kanban é suficiente, e o tempo que você gastaria configurando uma ferramenta complexa é tempo que não está fazendo o jogo.

Como saber quando cortar escopo em vez de furar o prazo

Chega o dia em que a conta não fecha: as tarefas restantes não cabem no prazo que sobrou. Aqui está a decisão que separa quem lança de quem não lança. Você tem três alavancas, e só três: mais tempo, mais gente, ou menos escopo.

Mais tempo é caro e muitas vezes impossível (tem uma data de feira, um dinheiro que acaba, uma vida que precisa de renda). Mais gente quase nunca ajuda no fim do projeto, porque treinar alguém novo custa tempo que você não tem, e software não fica pronto mais rápido só porque tem mais gente mexendo. Sobra a alavanca que a maioria evita: cortar escopo.

Cortar escopo não é fracasso, é a ferramenta normal de quem entrega. A pergunta certa quando algo atrasa não é "como recupero esse tempo?", é "o que sai do jogo pra data se manter?". Corte pelo que agrega menos valor por hora de trabalho: aquele terceiro bioma que consome três semanas e que o jogador vê por dez minutos, o modo secundário que ninguém pediu, o sistema complexo que você ama mas que não é o coração do jogo. Um jogo menor e polido que existe vale infinitamente mais que um jogo ambicioso que nunca sai. É o mesmo princípio de saber quando um curso ou uma estrutura de aprendizado vale o investimento: você paga pelo caminho mais curto até o resultado, não pela versão mais completa possível.

Um exemplo de cronograma de jogo pequeno

Pra deixar concreto, imagine um jogo de plataforma pequeno, feito por uma pessoa em meio período, com escopo enxuto: um personagem, três biomas, um chefe por bioma, umas 15 fases. Um cronograma honesto poderia ser assim:

• Mês 1: Protótipo. Movimentação, pulo, uma fase de teste feia. Pergunta a responder: pular e correr aqui é gostoso? Se não for, mexa nisso antes de qualquer outra coisa.
• Meses 2 e 3: Vertical slice. Uma fase completa com arte final, som, inimigos e um mini-chefe. É o build que você mostra pros amigos e usa pra decidir se continua.
• Meses 4 a 7: Alpha. Todos os sistemas no lugar: os três tipos de inimigo, os três chefes, o save, o menu, o HUD. Feio em partes, com bugs, mas tudo existe. Escopo congela aqui.
• Meses 8 a 10: Beta. As 15 fases construídas, balanceamento, playtests com gente de fora, polimento de feedback. Página na Steam no ar, trailer e GIFs pra wishlist.
• Mês 11: Gold e correção final. Caça a bugs, ajustes finais, build de lançamento.
• Buffer embutido: os 11 meses já incluem cerca de 30 por cento de folga. Na prática, sem folga, o mesmo escopo caberia em uns 8 meses no papel, e é exatamente por isso que projetos "de 8 meses" viram projetos de mais de um ano.

Repare que só os dois primeiros meses são a parte "divertida" de inventar. O resto é construção, correção e divulgação, e é onde os prazos morrem quando não estão no plano.

Um cronograma de jogo indie não é uma promessa gravada em pedra, é um instrumento de navegação. Ele te diz onde você está, aponta quando está saindo da rota e te dá as alavancas pra corrigir o curso: cortar, trocar, adiar. Se você aprende a montar marcos claros, estimar com folga honesta e tratar corte de escopo como parte normal do ofício, deixa de ser o indie que "está quase lançando" há dois anos e vira o que realmente coloca o jogo na rua. Se quiser encurtar essa curva de aprendizado com método em vez de tentativa e erro, vale considerar um curso de criação de jogos para iniciantes que já te entrega o caminho estruturado.