Como Documentar seu Projeto de Jogo (Wiki)

Toda vez que você toma uma decisão no seu jogo, uma informação nasce. "A gente decidiu que inimigo não dropa vida", "o pulo tem coyote time de 6 frames", "o pessoal da arte entrega sprite em PNG com nome no padrão tal". No momento, isso parece óbvio demais pra anotar. Três semanas depois, é fumaça. Aprender a documentar projeto de jogo é, no fundo, parar de perder essas informações no caminho, e uma wiki viva é a ferramenta certa pra isso.

Este post não é sobre o GDD. O GDD tem o lugar dele (falo mais pra frente), mas ele responde "o que é o jogo". A documentação de projeto responde outra coisa: "como a gente trabalha nesse jogo". São duas camadas diferentes, e misturar as duas é o primeiro erro de quem começa a organizar a casa.

O que significa documentar projeto de jogo de verdade

Documentar projeto de jogo não é escrever um manual bonito que ninguém lê. É manter, em um lugar só, as informações que o time (ou o seu eu do futuro) vai precisar e não vai lembrar. A palavra que importa aqui é viva. Documentação morta é aquela que você escreve uma vez, no começo do projeto, cheio de empolgação, e nunca mais toca. Ela envelhece, vira mentira, e aí todo mundo para de confiar e para de ler. A partir daí ela só ocupa espaço.

Uma wiki viva é o contrário: um conjunto pequeno de páginas que mudam junto com o projeto. Quando a decisão muda, a página muda. Quando entra gente nova, a página explica. Quando você volta depois de um tempo, a página lembra por você.

O que vale documentar

Nem tudo merece uma página. O filtro é simples: vale documentar aquilo que custa caro de redescobrir. Se perder a informação te obriga a reabrir o código, reabrir uma discussão antiga ou refazer um teste, ela merece estar escrita. Na prática, isso costuma cair em algumas categorias.

Decisões de design e o porquê delas. Não só "inimigo não dropa vida", mas a razão: "pra forçar o jogador a usar as fontes de cura fixas do mapa". O porquê é o que impede você de reabrir a mesma discussão daqui a dois meses, achando que teve uma ideia nova quando na verdade já tinha descartado ela.

Convenções de código. Como você nomeia variáveis, onde ficam os scripts de cada tipo, qual o padrão de commit, como organiza as cenas. Isso vale até sozinho, porque "o jeito que eu faço as coisas" muda sem você perceber e vira inconsistência.

Estrutura de pastas do projeto. Um mapa curto de onde mora o quê: assets, scripts, cenas, áudio, builds. Parece bobo até o projeto crescer e você passar dez minutos caçando um arquivo que deveria estar óbvio.

Pipeline de arte e áudio. O caminho que um asset percorre do software de criação até dentro do jogo: formato de exportação, resolução, naming, pasta de destino, se passa por algum tratamento. Esse é o tipo de informação que, sem doc, mora só na cabeça de uma pessoa e trava o projeto quando ela some.

Acordos do time. Quem decide o quê, como vocês resolvem discordância de design, qual o horário de sincronia, o que cada um assumiu. Acordo que não está escrito vira "mas eu achei que você ia fazer".

How-to de build. O passo a passo pra gerar a build jogável: quais configurações, que plataforma, o que checar antes de exportar, onde publicar. Você vai fazer isso poucas vezes e esquecer entre uma e outra, garantido.

O backlog e o estado atual também vivem perto da doc, embora normalmente num quadro próprio. A wiki guarda o que é estável; o quadro guarda o que está em movimento.

O que NÃO vale documentar

Aqui mora o erro mais comum de quem leva documentação a sério: documentar demais. A pessoa descobre o valor de escrever as coisas e sai registrando tudo, com páginas e páginas que nunca mais são atualizadas. O resultado é pior que não ter nada, porque uma wiki grande e desatualizada ensina o time a desconfiar de toda a wiki.

Não documente o que o código já diz melhor. Se o nome da função e a estrutura do script explicam o que ele faz, uma página descrevendo linha por linha só vai ficar desatualizada no primeiro refactor. Documente a decisão por trás do código, não o código.

Não documente o que muda toda semana. Número que você ainda está ajustando (dano, velocidade, preço de item) não deveria morar em página de texto, porque você vai mudar no jogo e esquecer de mudar na doc. Esse tipo de dado vive melhor no próprio projeto ou numa planilha de balanceamento que é a fonte única.

Não documente pra parecer organizado. Se você está escrevendo uma página porque "projeto sério tem que ter isso" e não porque alguém vai ler, pare. Página que ninguém consulta é trabalho que concorre com fazer o jogo.

A régua é honesta: cada página tem um custo de manutenção. Se você não vai manter, não crie.

Ferramentas gratuitas pra montar a wiki

A ferramenta importa menos do que a disciplina, mas a escolha certa reduz a fricção, e fricção é o que mata wiki. Algumas opções gratuitas que funcionam bem em projeto de jogo pequeno:

Notion. Flexível, bom pra misturar texto, tabelas, checklists e até um quadro simples de tarefas no mesmo lugar. Ótimo pra quem gosta de tudo centralizado e trabalha online. O risco é virar bagunça se você não impuser uma estrutura de páginas.

Obsidian. Trabalha com arquivos de texto locais e links entre notas. É a escolha de quem quer a doc versionada junto com o projeto, offline, e gosta de conectar ideias. Curva um pouco maior, mas muito durável.

Wiki do repositório. GitHub e GitLab têm wiki embutida no repositório. A grande vantagem é que a doc fica ao lado do código, no mesmo lugar onde você já trabalha todo dia. Pra time que já vive no Git, é a menor fricção possível.

Google Docs. O mais simples de todos, e por isso mesmo subestimado. Pra solo ou dupla que só quer anotar decisões e acordos sem cerimônia, resolve. Fácil de compartilhar, fácil de abrir, difícil de abandonar porque já está aberto o tempo todo.

Não gaste uma semana escolhendo. A melhor ferramenta é a que você abre sem pensar. Comece simples e migre só quando sentir uma dor real, não antes.

Solo e time usam a doc de formas diferentes

Vale separar os dois casos, porque o motivo de documentar muda.

Trabalhando sozinho, a wiki é memória externa. O inimigo não é outra pessoa que não entende o combinado, é você mesmo daqui a seis semanas, depois de um tempo longe do projeto. Sem doc, voltar significa reaprender o próprio jogo: por que aquela pasta existe, o que você já tinha decidido sobre tal mecânica, como gerar a build. Com doc, você relê três páginas e volta ao trabalho no mesmo dia. Pra solo, documente menos, mas documente o que dói esquecer: decisões, convenções, build.

Em time pequeno, a doc é alinhamento. O custo de não documentar não é só esquecimento, é retrabalho e atrito: duas pessoas fazendo a mesma coisa de jeitos diferentes, asset chegando fora do padrão, decisão que uma lembra e outra não. A wiki vira o lugar onde o combinado existe por escrito, acima da memória de cada um. Em time, as páginas de convenção e acordo valem ainda mais que as de design.

Como manter a wiki viva

Essa é a parte difícil. Montar a doc é fácil; manter é o que separa wiki útil de cemitério de páginas. Alguns hábitos que funcionam.

Ligue a doc à rotina, não trate como tarefa à parte. Documentação separada do trabalho sempre fica pra depois, e depois nunca chega. Em vez disso, atualize a página no mesmo momento da decisão. Decidiu algo numa discussão? Antes de fechar, alguém registra em duas linhas. A doc acontece dentro do fluxo, não num bloco heroico de "arrumar a wiki" que você nunca faz.

Escreva curto. Página longa assusta na hora de atualizar, então ninguém atualiza. Duas, três linhas por decisão já carregam o essencial. Doc enxuta sobrevive; doc extensa apodrece.

Revise no fechamento de milestone. Quando um ciclo termina, passe os olhos no essencial: ainda é verdade? Mudou alguma convenção? Essa é a hora natural de podar páginas mortas e corrigir o que virou mentira.

Deixe a wiki visível. Se a doc mora num lugar que você só abre de propósito, ela morre. Deixe o link onde você já olha todo dia, perto do quadro de tarefas, no canal do time, no README do repositório.

Aceite apagar. Página que não serve mais deve sair. Wiki viva encolhe tanto quanto cresce. Deletar o que virou lixo é o que mantém o resto confiável.

Onde isso se encaixa no resto da produção

A documentação não vive sozinha. Ela faz par com duas outras peças da gestão do projeto. O game design document (GDD) é a página (ou conjunto de páginas) que descreve a visão do jogo, e ele mora dentro da wiki como uma seção, não como documento isolado numa gaveta. Já a doc em si é parte de como gerenciar projeto de jogo de ponta a ponta: escopo, milestones e conhecimento registrado andam juntos.

E tem uma divisão de trabalho que vale fixar: a wiki guarda o que é estável, o quadro guarda o que está em movimento. Decisão fechada, convenção, acordo, how-to vão pra doc. Tarefa em andamento, bug a corrigir, feature a fazer ficam no fluxo de trabalho, que é melhor tratado quando você aprende a organizar tarefas com kanban. Quando algo que estava no quadro vira regra do projeto, ele graduou: sai do quadro e entra na wiki.

No fim, documentar projeto de jogo é um investimento pequeno que paga caro num momento específico, aquele em que você (ou alguém do time) precisa de uma informação que já existiu e sumiu. Você não vai sentir falta da wiki nos dias bons. Vai sentir no dia em que voltar ao projeto e ela for a diferença entre retomar o trabalho e ter que redescobrir tudo do zero. Monte pequena, mantenha viva, e deixe ela crescer só na medida em que você consegue sustentar.