Como Escrever um Game Design Document (GDD) Que Alguém Realmente Lê

O game design document tem uma fama injusta. Todo mundo já ouviu falar do GDD de 200 páginas que ninguém abriu depois da semana 2 do projeto, e a conclusão errada que muita gente tira é "documentar não funciona". O que não funciona é escrever um romance antes de ter um jogo. Um GDD bom é curto, vivo e responde perguntas que o time vai fazer de verdade durante a produção.

Eu já vi os dois extremos: projeto sem documento nenhum, onde cada decisão era rediscutida do zero a cada conversa, e projeto com uma bíblia de design que envelheceu mal em um mês porque ninguém tinha coragem de atualizar. Os projetos que andam ficam no meio: um documento de 10 a 20 páginas que captura a visão, as mecânicas centrais e o escopo, e que muda junto com o jogo.

Esse artigo mostra a estrutura que eu uso, seção por seção, um template pra você copiar e, talvez a parte mais importante, o que deixar de fora.

Pra que serve um GDD (e pra que não serve)

Antes da estrutura, vale alinhar a função do documento. Um GDD serve pra três coisas:

1. Alinhar o time. Quando o artista, o programador e o designer leem o mesmo parágrafo sobre o sistema de combate, eles constroem a mesma coisa. Sem isso, cada um constrói a versão que imaginou.
2. Forçar decisão. Escrever expõe buraco. "O jogador pode pular?" parece detalhe até você ter que escrever a seção de movimentação e perceber que nunca decidiu.
3. Proteger o escopo. O documento é o lugar onde "seria legal ter" vai morar numa seção separada das features que realmente entram. Quando alguém sugere multiplayer na metade da produção, você aponta pro documento.

E pra que ele NÃO serve: o GDD não é pitch pra publisher (isso é um pitch deck, documento diferente, com foco em mercado), não é contrato imutável e não é prova de que o jogo é divertido. Diversão se prova em protótipo, não em texto. Se você está escrevendo página 40 sem ter um protótipo jogável, pare de escrever e vá prototipar.

Estrutura do game design document, seção por seção

Essa é a espinha que funciona pra maioria dos jogos indie e de pequeno porte. A ordem importa: começa do mais geral e desce pro específico.

1. Visão geral (1 página, no máximo)

A primeira página responde, em ordem:

• High concept: o jogo em uma ou duas frases. "Um roguelike de deckbuilding onde as cartas são feitiços que combinam entre si" diz mais que três parágrafos de ambientação.
• Gênero e referências: dois ou três jogos que o time conhece. "Hades encontra Stardew Valley" comunica tom, ritmo e estrutura num golpe só. Use referências como atalho de comunicação, não como promessa de qualidade.
• Plataforma alvo: PC, console, mobile. Isso muda decisões de controle e UI desde o dia 1.
• Público: quem joga isso e em sessões de quanto tempo.

Se alguém ler só essa página, deveria entender o que o jogo é. Esse é o teste.

2. Pilares de design

Três pilares, no máximo quatro. Um pilar é um valor que decide empates. Exemplos reais de pilar: "toda morte é culpa do jogador, nunca do jogo", "nenhuma sessão dura mais de 15 minutos", "o mundo reage a tudo que o jogador faz".

Os pilares são a parte mais usada do documento durante a produção, porque viram critério de corte. Feature nova chegou? Se ela não serve a nenhum pilar, não entra, por mais legal que seja. Se você só puder escrever uma seção do GDD inteiro, escreva essa.

3. Mecânicas centrais (core loop)

Aqui você descreve o que o jogador faz, em camadas:

• Loop de momento a momento: o que acontece a cada poucos segundos. Mirar, atirar, desviar. Plantar, regar, colher.
• Loop de sessão: o que uma partida ou sessão completa contém. Entrar na dungeon, limpar salas, voltar com loot.
• Loop de progressão: o que muda entre sessões. Desbloqueios, upgrades, história avançando.

Descreva cada mecânica com profundidade suficiente pra alguém implementar a primeira versão, mas sem cravar números. "O pulo tem altura variável e coyote time" é design. "O pulo dura 0,42 segundos" é tuning, e tuning se descobre com o jogo rodando, não no documento.

4. Conteúdo e escopo

A lista do que existe no jogo, com quantidades: quantas fases, quantos inimigos, quantas armas, quantos chefes, quantas horas de campanha. Essa seção é a que mais dói escrever, porque é onde a ambição encontra a realidade.

Um truque que uso: escreva duas colunas, MVP e versão completa. O MVP é o menor jogo que ainda entrega os pilares. Se o seu MVP tem 40 fases, ele não é um MVP, e o documento acabou de te avisar disso de graça.

5. Arte, áudio e narrativa (direção, não execução)

No GDD, essas seções definem direção: paleta, tom, estilo, referências visuais e sonoras. "Pixel art 32x32 com paleta limitada, inspirado em Celeste" é suficiente. Concept arts, roteiros completos e listas de assets vivem em documentos próprios, linkados a partir daqui. O GDD aponta, não armazena.

Pra narrativa, o mesmo: premissa, personagens principais e arco geral em uma página. O roteiro de cada cena fica fora.

6. Interface e controles

Mapa de controles por plataforma e os fluxos de tela principais (menu, HUD, pausa, game over). Um diagrama de fluxo de telas feito em dez minutos evita semanas de retrabalho de UI. Não precisa ser bonito, precisa existir.

7. O cemitério de ideias

Essa seção é a minha favorita e quase ninguém usa: uma lista explícita de tudo que foi considerado e cortado, com uma linha explicando por quê. "Multiplayer: cortado, dobraria o tempo de produção." Serve pra duas coisas: a discussão não renasce a cada mês, e quando alguém novo entra no time, ele entende as decisões sem precisar perguntar.

Template pra copiar

Cole isso num documento novo e preencha. Se uma seção não se aplica ao seu jogo, delete a seção em vez de enchê-la de texto genérico.

# [Nome do Jogo] - GDD

## 1. Visão geral
- High concept (1-2 frases):
- Gênero:
- Referências (2-3 jogos):
- Plataforma:
- Público e duração de sessão:

## 2. Pilares de design
1.
2.
3.

## 3. Mecânicas centrais
### Loop momento a momento
### Loop de sessão
### Loop de progressão
### Mecânicas de suporte

## 4. Conteúdo e escopo
| Conteúdo | MVP | Versão completa |
|---|---|---|
| Fases | | |
| Inimigos | | |
| Chefes | | |

## 5. Direção de arte e áudio
- Estilo visual e referências:
- Direção de áudio:
- Premissa narrativa:

## 6. Interface e controles
- Mapa de controles:
- Fluxo de telas:

## 7. Cemitério de ideias
- [Ideia]: cortada porque [motivo]

Markdown num repositório Git, Notion, Google Docs: a ferramenta importa menos que duas propriedades. Todo mundo do time consegue editar, e dá pra ver o histórico de mudanças. Se o documento mora num lugar onde editar dá trabalho, ele morre.

O que NÃO colocar no GDD

Essa lista vale tanto quanto a estrutura, porque é o excesso que mata o documento.

Números de balanceamento. Dano da espada, HP do chefe, preço da poção. Isso muda toda semana e pertence a uma planilha ou aos dados do próprio jogo. No GDD fica a intenção: "o chefe da área 2 deve exigir domínio do parry".

Lore enciclopédico. A história de 3.000 anos do reino é ótima num documento de worldbuilding separado. No GDD entra só o que afeta o que o jogador vê e faz.

Detalhes de implementação. Arquitetura de código, escolha de engine pattern, estrutura de cenas. Isso é documento técnico, escrito pelo time de programação, com outro ciclo de vida.

Pesquisa de mercado e projeção de vendas. Pitch deck. Documento com leitor diferente e objetivo diferente.

Tudo que você ainda não decidiu. Resista à tentação de escrever três alternativas pra cada sistema "pra decidir depois". O documento existe pra registrar decisões. Indecisão registrada vira ruído que todo leitor precisa filtrar.

A regra geral: se a informação muda mais rápido do que você atualizaria o documento, ela não pertence ao documento.

Mantendo o documento vivo

Um GDD desatualizado é pior que nenhum, porque mente com confiança. Três hábitos resolvem:

1. Atualize quando a decisão muda, não depois. Mudou o sistema de save numa reunião? A última pauta da reunião é alguém editar o parágrafo. Leva dois minutos.
2. Marque o que é protótipo pendente. Mecânica que ainda não foi validada em protótipo ganha uma tag visível. Texto não é prova de diversão.
3. Releia os pilares uma vez por mês. Se o jogo que está no build já não bate com os pilares do documento, ou o build desviou ou os pilares envelheceram. Os dois casos pedem conversa, e é melhor ter essa conversa cedo.

Fechando

Um game design document bom é menor do que você imagina e mais usado do que você espera. Uma página de visão, três pilares que decidem empates, o core loop em camadas, escopo com números honestos e um cemitério de ideias. Isso cabe em 10 a 20 páginas e responde 90% das perguntas que o time faz durante a produção.

Comece pequeno: escreva hoje só a visão geral e os pilares do seu projeto atual. Se travar nos pilares, ótimo, você acabou de descobrir que ainda não sabe qual é o coração do seu jogo. E descobrir isso numa página de texto custa muito menos que descobrir seis meses dentro da produção.