Post-Mortem de Jogo Indie: Como Fazer a Retrospectiva que Mais Ensina

Você lançou. Depois de meses, talvez anos, o jogo está na Steam, na itch.io, na loja que for. Vendeu bem, vendeu mal, ou vendeu nada. E agora a maioria dos devs faz exatamente a mesma coisa: abre um projeto novo "pra esfriar a cabeça" e nunca mais olha pra trás. É aí que o post-mortem de jogo indie deixa de existir, e com ele some o único momento em que o projeto inteiro está fresco o bastante pra ser entendido de verdade. Um post-mortem é a retrospectiva escrita do que aconteceu entre a ideia e o lançamento, e ele é o passo que mais ensina entre um jogo e o próximo. Esse artigo é como fazer um, com uma estrutura que você pode copiar hoje.

A palavra assusta porque parece autópsia, coisa de defunto. Mas post mortem de jogo não é só pra projeto que morreu. É pra todo projeto que terminou, e principalmente pros que deram errado, porque é onde mora a lição mais cara que você já pagou.

O que é um post-mortem de jogo indie (e o que não é)

Um post-mortem é um documento honesto, escrito por você, sobre como o projeto correu do começo ao fim. Não é um relatório de vendas, não é um diário de desabafo, e não é material de marketing. É análise: o que funcionou, o que não funcionou, o que estava fora do seu controle, e o que você vai fazer diferente da próxima vez.

A tradição vem do desenvolvimento de software e foi popularizada por estúdios que publicavam suas retrospectivas abertamente. A versão indie é mais simples e mais brutal, porque normalmente é só você prestando contas pra você mesmo. Sem chefe pra impressionar, sem RH pra suavizar. Isso é uma vantagem: você pode ser sincero de um jeito que time grande raramente consegue.

A diferença entre post-mortem e "achismo sobre o que deu errado" é que o post-mortem é escrito. Pensamento na cabeça mente, encolhe, racionaliza. No papel não tem pra onde fugir. Quando você escreve "lancei sem nenhuma wishlist acumulada", a frase fica lá te encarando, e na próxima vez vira uma decisão consciente em vez de um erro repetido no automático.

Por que ele ensina mais que o próximo jogo

A intuição diz que você aprende fazendo o próximo projeto. Em parte sim. Mas o próximo projeto é cego pro anterior se você não destrinchou o anterior. Você vai repetir os mesmos erros com problemas novos por cima, e atribuir tudo a "azar" ou "o mercado tá difícil".

O post-mortem força três coisas que o cérebro evita sozinho. Primeiro, separa causa de resultado. "Vendeu pouco" é resultado. A causa pode ter sido escopo, marketing, gênero saturado, página de loja fraca, ou tudo junto. Sem separar, você "corrige" a coisa errada. Segundo, te obriga a olhar dado, não memória. A memória diz que o lançamento foi um caos; o dado diz que metade dos refunds aconteceu nos primeiros minutos de jogo, o que aponta pro tutorial, não pro preço. Terceiro, transforma experiência em regra: algo que você só sentiu vira uma frase que você consegue seguir, como "nunca mais anuncio data antes de ter o jogo content-complete".

E tem o lado frio do negócio: post-mortem é o que separa o hobby de quem está construindo uma carreira. Quem leva a sério não joga o aprendizado fora junto com o projeto encerrado.

A estrutura clássica: certo, errado, fora do controle

O coração de qualquer post-mortem são três perguntas, na ordem. Não pule nenhuma e não misture.

O que deu certo. Comece por aqui, e não por modéstia. Você precisa saber o que repetir tanto quanto o que evitar. Talvez o core loop tenha ficado redondo, talvez você tenha terminado o projeto (o que já te coloca na minoria), talvez sua pipeline de arte tenha sido rápida. Liste com a mesma honestidade que você listaria os erros. Acertos não documentados não viram processo, viram sorte que você torce pra ter de novo.

O que deu errado. Aqui a tentação é listar sintomas. Force-se a ir até a decisão que causou cada um. "O jogo travava no boss final" é sintoma; a causa foi "deixei o conteúdo final sem teste porque o prazo apertou". Pra cada erro, anote a decisão que o gerou e o momento em que ela foi tomada. É lá que você intervém no próximo projeto.

O que foi sorte ou estava fora do controle. Categoria que quase todo mundo esquece, e que protege você de duas mentiras. A primeira é se gabar de um sucesso que foi um streamer grande pegando seu jogo por acaso. A segunda é se crucificar por um fracasso que foi um lançamento concorrente gigante na mesma semana, ou uma mudança de algoritmo da loja. Separar o que você controla do que você não controla é o que mantém o post-mortem útil em vez de virar sessão de autoflagelo ou de autoengano.

A regra que amarra as três: para cada item, pergunte "isso depende de uma decisão minha?". Se sim, vai pra certo ou errado. Se não, vai pra fora do controle. Decisão é onde você aprende; o resto é contexto.

As métricas que você precisa revisar

Sentimento é ponto de partida, não conclusão. Antes de escrever as lições, puxe os números. Você não precisa de um dashboard sofisticado, precisa olhar o que a loja já te dá de graça e cruzar com o que você lembra.

• Wishlists ao longo do tempo. Onde subiram, onde estagnaram. Cada pico costuma ter uma causa (um trailer, um post que viralizou, uma feira). Identificar a causa te diz o que funcionou de marketing.
• Conversão de wishlist em venda. Quantos que adicionaram realmente compraram, e em quanto tempo. Conversão baixa fala da página ou do preço; alta fala de uma comunidade que confiava em você.
• Taxa e janela de reembolso. Quanto e, principalmente, quando. Refund cedo aponta pra primeiros minutos (tutorial, performance, expectativa furada pela página). Refund tardio aponta pra falta de conteúdo ou bug lá pra frente.
• Origem do tráfego e das vendas. De onde veio quem comprou: orgânico da loja, redes sociais, imprensa, criadores de conteúdo. Isso te diz onde investir esforço da próxima vez.
• Retenção e tempo de jogo. Se a plataforma mostra, veja onde a maioria parou de jogar. O ponto de abandono em massa é o seu defeito de design mais caro.
• Receita líquida real. Depois do corte da loja, impostos, regionais e devoluções. O número que sobra é o que define se isso foi sustentável, e ele costuma assustar quem só olhou o bruto.

Não invente métrica que você não mediu. Se você não instrumentou nada e só tem os números da loja, registre isso como um erro de processo ("não tive dados de comportamento dentro do jogo") e resolva instalar telemetria simples no próximo. A ausência de dado também é um achado.

Escopo, marketing e prazo: as três frentes de decisão

Quase todo erro de projeto indie cabe em uma destas três frentes. Revise cada uma separadamente.

Escopo. A causa número um de projeto que atrasa, estoura ou nunca lança. Pergunte sem rodeio: o jogo era do tamanho certo pra você, no tempo que você tinha? Quantas features você cortou no fim com dor, e quantas deveria ter cortado seis meses antes? Esse é o lugar de ser honesto sobre ambição mal calibrada. Se você ainda está numa fase de planejar projetos, vale entender de antemão como definir escopo de jogo indie sem se afogar, porque é mais barato evitar o erro do que diagnosticar ele depois.

Marketing. Quando você começou a divulgar? A maioria começa tarde demais, no mês do lançamento, quando wishlist não tem mais tempo de acumular. Sua página de loja estava pronta cedo? Você tinha trailer, GIFs, comunidade? Marketing de jogo não é o que você faz na semana do lançamento; é o que você devia ter feito durante todo o desenvolvimento. Anote a data em que você começou de verdade e compare com a data em que devia ter começado.

Prazo. Bateu a data planejada? Por quanto errou? E mais importante: a estimativa estava errada desde o início ou o escopo cresceu no caminho? Erro de estimativa é uma lição; escopo crescendo é outra completamente diferente. Distinga as duas, porque a correção de cada uma é distinta.

Uma frente que devs esquecem no post-mortem: o que vem depois do lançamento. Você tinha plano pra o jogo viver, ou tratou o launch como linha de chegada? Mesmo um indie pequeno se beneficia de pensar em atualizações, eventos e o ciclo de liveops e o que acontece depois que o jogo entra no ar. Se você não planejou nada disso, é um item legítimo do "o que faria diferente".

De achado a lição acionável

Um post-mortem que termina em "preciso fazer marketing mais cedo" falhou. Isso é um sentimento, não uma instrução. A última etapa, e a única que realmente muda o próximo projeto, é converter cada achado numa regra que o seu eu do futuro consegue executar sem pensar.

Pegue cada item de "o que deu errado" e reescreva como uma frase imperativa, específica e verificável. "Marketing começou tarde" vira "abrir página da Steam e começar a juntar wishlist antes de ter qualquer arte final pronta". "O tutorial espantava jogador" vira "fazer playtest com cinco estranhos antes do lançamento e medir onde largam". Repare que a segunda já aponta pra um processo concreto: testar com gente de fora e iterar em cima do que você vê, que é o ciclo de playtesting, feedback e iteração que separa palpite de evidência.

A boa lição acionável passa em três testes. É específica (diz o que fazer, não o que sentir). É verificável (dá pra conferir se cumpriu). E é sua (vem do seu projeto, não de um conselho genérico). Junte essas frases num arquivo fixo que você relê no dia que abrir o próximo projeto. Esse arquivo é o verdadeiro produto do post-mortem; o resto é raciocínio pra chegar nele.

Por que o projeto que "fracassou" é o mais importante de analisar

Existe uma tentação cruel: quando o jogo vai mal, você quer enterrar o assunto. Dói reabrir. Mas o projeto que vendeu pouco é onde está concentrado o maior aprendizado por real investido. O sucesso esconde os erros porque o resultado bom perdoa tudo; quem vendeu muito raramente sabe ao certo por quê. O fracasso, ao contrário, deixa os erros expostos. É um relatório gratuito sobre o que não fazer.

Tem também o efeito psicológico, que não é pequeno. Um fracasso sem post-mortem vira uma nuvem vaga de "não sou bom o suficiente" que te paralisa por meses. Um fracasso destrinchado vira uma lista de decisões concretas que você tomaria diferente. A lista não dói; ela te devolve o controle. Você sai do "fracassei" e entra no "sei o que errei e tenho um plano". Essa é a diferença entre quem desiste depois de um projeto ruim e quem lança o próximo mais forte.

Checklist de post-mortem pra você copiar

Cole isso num documento, responda cada bloco com honestidade e você tem um post-mortem completo. Reserve algumas horas, não tente fazer em quinze minutos.

1. Dados do projeto. Nome, gênero, plataforma, tempo total de desenvolvimento (planejado x real), tamanho do time, orçamento gasto (mesmo que só o seu tempo).

2. O que deu certo. Liste de 3 a 5 acertos, cada um ligado à decisão que o causou.

3. O que deu errado. Liste de 3 a 5 erros, cada um ligado à decisão e ao momento em que ela foi tomada.

4. Fora do controle. O que foi sorte, contexto de mercado ou acaso, pra cima e pra baixo.

5. Métricas. Wishlists, conversão, reembolsos (taxa e janela), origem das vendas, retenção, receita líquida real.

6. Escopo. O tamanho estava certo? O que cortou tarde demais?

7. Marketing. Quando começou de verdade x quando devia ter começado. A página estava pronta cedo?

8. Prazo. Bateu a data? Erro de estimativa ou escopo crescente?

9. Pós-lançamento. Tinha plano de vida pro jogo depois do launch? Cumpriu?

10. Lições acionáveis. Reescreva os erros como regras imperativas, específicas e verificáveis pro próximo projeto. Este é o bloco que você vai reler.

Não precisa publicar nada disso. Um post-mortem privado e honesto vale mais que um público e diplomático. Mas se você se sentir confortável, publicar ajuda outros devs e ainda te força a um nível de clareza que o documento privado às vezes deixa passar.

O encerramento que abre o próximo projeto

Terminar um jogo já é raro. Terminar e entender por que ele saiu como saiu é mais raro ainda, e é o que transforma cada projeto numa subida em vez de um recomeço do zero. O post-mortem é barato: custa algumas horas e a coragem de olhar pro que você preferia esquecer. O retorno é você não pagar a mesma lição duas vezes.

Faça o seu enquanto o projeto ainda está quente. Daqui a três meses os detalhes somem, as racionalizações tomam conta, e o documento vira ficção. Abra um arquivo hoje, copie o checklist de cima, e comece pelo bloco que mais incomoda. É exatamente ali que está a lição que você mais precisa.