Modelo de documento de design de jogos de uma página

Você precisa de um modelo de documento de design de jogos que caiba em uma página e só cresça quando o jogo pedir. Comece com sete blocos: pitch, loop central, verbos do jogador, mundo, sistemas, escopo e perguntas abertas. Dá para preencher tudo em uma noite. Corte qualquer coisa que você não consiga testar em um protótipo neste mês. O resto deste post é o próprio modelo, além das partes que a maioria dos guias deixa de fora.

Por que a maioria dos documentos de design morre na segunda semana

Imagine o GDD de 40 páginas. Capa bonita, sumário, um capítulo de lore que ninguém pediu. Na segunda semana, o protótipo já saiu do rumo e o documento virou fóssil.

Esse é o problema de verdade. Não são as seções que faltam, e sim um arquivo que deixa de ser verdade. Um GDD é uma ferramenta de trabalho, mais parecido com um registro de mudanças do que com uma bíblia. Se o documento e o build discordam, o documento perde, e as pessoas param de abrir.

Então a pergunta não é "o que um documento de design deveria conter?". A pergunta é "qual é o menor documento que eu vou de fato manter honesto?"

O modelo de documento de design de jogos em uma página

Copie este esquema. Cada bloco leva de duas a cinco linhas, nunca mais que isso na primeira versão.

1. Pitch. Uma frase que um estranho conseguiria repetir. "Uma cidade portuária cooperativa onde a maré redesenha o mapa toda noite."

2. Loop central. O que o jogador faz, de novo e de novo, em menos de um minuto. Desenhe como um círculo de verbos.

3. Verbos do jogador. Cinco a oito ações. Não funcionalidades. Verbos: escalar, negociar, esconder, bifurcar, consertar.

4. Mundo. Lugar, clima e três regras que são sempre verdade. Clima conta como regra.

5. Sistemas. Os dois ou três mecanismos que tornam os verbos interessantes. Economia, furtividade, criação, o que for que sustente o loop.

6. Escopo. O que será lançado, o que foi cortado e o que é extra. Coloque uma data ao lado de cada item.

7. Perguntas abertas. A lista honesta do que você ainda não sabe. Este bloco é o mais valioso da página.

Repare no que falta: monetização, plano de marketing, capítulo de história do personagem. Eles pertencem a arquivos separados, escritos quando o protótipo provar o loop. A maioria dos modelos publicados começa por eles, e é exatamente por isso que esses documentos nunca ficam prontos.

Se o seu time precisa de um formato mais longo para aprovação, o guia do GitBook sobre como escrever um documento de design de jogos traz a lista clássica de capítulos. A recomendação dele de começar por uma versão de uma página e acrescentar detalhes conforme os protótipos avançam é o instinto certo.

O que a seção de loop central deveria dizer de fato

Corte os adjetivos. Escreva o loop como uma frase com cronômetro.

Vasculhe por 40 segundos -> leve os destroços até o píer -> troque por uma melhoria -> a maré muda, o mapa muda -> repita

Agora leia em voz alta. Se um passo soa morto, você achou a primeira tarefa de protótipo. Se todos os passos parecem bons, mas você não consegue dizer por que o jogador volta, o loop está sem motivo. Coloque isso nas perguntas abertas em vez de enterrar no texto.

Um teste de que eu gosto: a frase do loop precisa caber em uma única linha. Se precisar de um parágrafo, são dois loops, e você está desenhando dois jogos.

Quais seções você pode cortar sem arrependimento?

Seja implacável. Um projeto solo ou de duas pessoas costuma poder eliminar estas no primeiro dia:

• Biografias completas de personagens. Mantenha nome, desejo e falha. Escreva mais quando o personagem aparecer em um build.

• Descrições detalhadas de fases. Descreva as regras da fase, não os cômodos.

• Capítulos de plataforma e monetização. Deixe para depois que o loop funcionar.

• Bíblia de arte. Três imagens de referência e uma paleta. Só isso.

Pule tudo isso se você estiver lançando um jogo de game jam em 72 horas: o pitch, o loop e os verbos são o documento inteiro. Vale manter a lista completa se você tiver uma editora, um caminho de certificação para console ou contratados que não podem tirar dúvidas à meia-noite.

O modelo de GDD em PDF da Unity é uma boa referência de como mecânicas e comportamentos de objetos são registrados quando há uma equipe envolvida. Leia como catálogo, não como checklist.

Onde guardar o documento?

No lugar onde você vai editá-lo todos os dias. Parece óbvio até você ver quantos GDDs vivem em um PDF que ninguém consegue comparar.

Escolha uma ferramenta que ofereça títulos, um banco para tarefas e histórico de versões. Um app de notas com banco de dados funciona bem, porque as perguntas abertas e a lista de escopo podem virar itens rastreados em vez de marcadores que apodrecem.

Markdown puro no repositório é a outra boa resposta. Ele fica ao lado do código, gera diffs limpos e ninguém esquece de atualizá-lo durante um pull request. O custo é que colegas não técnicos não vão mexer nele.

De qualquer forma, deixe a página de uma folha no topo e linke para arquivos mais profundos. A página é o mapa. Os arquivos são o território.

O motor muda o que você escreve?

Um pouco, sim. O motor decide quais verbos são baratos e quais são caros, então as seções de sistemas e escopo devem dizer isso com clareza.

Se você estiver em uma engine 3D completa, com um pipeline grande de assets, o escopo precisa de uma linha para cada categoria de asset, porque é no conteúdo que os cronogramas morrem.

Se você quer uma engine de código aberto, sem contas de royalties para acompanhar, a seção de escopo fica mais simples: sem linha de licenciamento, mas com uma nota real sobre quais recursos você vai construir por conta própria.

E se o jogo for 2D, com mecânicas apertadas, a seção de loop carrega quase tudo. Documentos pequenos e legíveis combinam com jogos pequenos e legíveis.

O ponto não é escolher um vencedor. O ponto é que "Engine e ferramentas" não é uma linha descartável. Ela deveria listar o que o motor facilita, o que dificulta e o que você se recusa a construir.

Como escrever um GDD para um mundo que se gera sozinho?

Esta é a lacuna de quase todos os modelos. Eles presumem que você posiciona cada árvore à mão.

Quando um mundo nasce de um prompt, o documento muda de forma. Você já não especifica salas. Especifica restrições: o que precisa ser verdade em todo mundo que o motor consegue produzir e o que pode variar.

Acrescente dois blocos ao esquema de uma página:

• Restrições do mundo. As regras que não podem quebrar. "Todo assentamento tem água a no máximo dois minutos de caminhada." "Nenhuma missão secundária termina em beco sem saída."

• Sementes de prompt. Os prompts exatos que você usou, guardados como parte do documento.

Veja como uma semente fica na prática:

uma vila portuária com neblina na maré baixa, um farol, escadas estreitas, pontes de corda entre os telhados, ninguém à vista ainda

Salve o prompt, salve o que voltou e anote o que você bifurcaria. O prompt é, ao mesmo tempo, sua especificação e seu registro de mudanças. Bifurque, mude uma coisa, veja o que acontece e só então escreva a diferença no documento. Esse hábito transforma um mundo gerado em algo que você consegue raciocinar, e dá aos colegas algo concreto para criticar, em vez de um clima vago.

Um alerta: a qualidade da geração varia muito entre ferramentas, e alguns recursos ainda estão em beta na indústria. Anote a versão e a data ao lado de cada semente, para saber se um resultado é repetível ou apenas uma jogada de sorte.

Um jeito rápido de testar o loop antes de escrever mais

Este é o fluxo de uma noite que eu usaria numa ideia nova.

1. Escreva a página de uma folha em 30 minutos. Não edite.

2. Transforme o pitch e as três regras do mundo em um prompt e gere uma primeira versão do espaço.

3. Percorra o loop central nesse espaço, à mão ou num protótipo rápido.

4. Marque cada passo que pareceu morto. Eles vão para as perguntas abertas.

5. Corte um verbo. Sempre corte um.

O corte é a parte que as pessoas pulam. Um documento de design que só cresce é uma lista de desejos. Remover um verbo obriga os restantes a carregar mais peso e normalmente revela qual sistema estava fazendo o trabalho real.

Como manter o documento vivo depois da segunda semana?

Três hábitos, nenhum heroico.

Data cada pergunta aberta. Se uma pergunta tem mais de três semanas e segue aberta, responda ou admita que está evitando.

Atualize o documento na mesma sessão do build. Não depois. Depois é como o fóssil se forma. Uma edição de duas linhas no fim de uma sessão custa um minuto.

Mantenha uma lista de ideias descartadas no fim. Ela evita rediscutir a mesma mecânica todo mês, e é estranhamente motivador ver quanto você entregou por ter dito não.

Quando alguém novo entra no projeto, entregue primeiro a versão de uma página e observe onde a pessoa fica confusa. Cada dúvida é uma linha que faltou no documento.

O que usaríamos de fato?

Se você está sozinho ou em dupla, o esquema de sete blocos mais uma lista de sementes de prompt basta para o primeiro mês. Se tem equipe, mantenha a página de uma folha como porta de entrada e acrescente arquivos separados para sistemas e conteúdo conforme o protótipo justificar. Se tem uma editora, entregue a versão longa, mas continue confiando na sua página de uma folha.

Abra uma página em branco hoje à noite e escreva o pitch. Uma frase. Depois o loop, com um cronômetro. Se você não conseguir terminar isso em meia hora, a ideia ainda é um sonho, e isso também é útil saber antes de gastar um mês nela.