Como Escrever um GDD🔗

Definição curta: O Game Design Document (GDD) é o documento central que descreve todos os aspectos de design de um jogo — conceito, mecânicas, personagens, levels, UI — servindo como referência autoritativa para toda a equipe durante o desenvolvimento.

Antes de começar

Ter lido O que é Game Design
Um projeto ou ideia de jogo em que aplicar o que está aqui — o material não funciona no vazio

O que você vai aprender

Explicar Quando escrever GDD com suas palavras
Explicar Estrutura recomendada com suas palavras
Explicar Seções essenciais com suas palavras
Aplicar o conteúdo desta página a um jogo que você conhece

O que é🔗

O GDD é o documento vivo do projeto de jogo. Diferente de um pitch (proposta curta para vender a ideia), o GDD é detalhado o suficiente para guiar a produção.

Não existe um formato universal de GDD — cada estúdio e projeto tem seu próprio template. O importante é que seja claro, acionável e acessível para toda a equipe.

flowchart LR
    subgraph GDD["Game Design Document"]
        C["Concept\n(Conceito)"]
        M["Mechanics\n(Mecânicas)"]
        N["Narrative\n(Narrativa)"]
        U["UI/UX\n(Interface)"]
        T["Technical\n(Técnico)"]
    end

    C --> M --> N --> U --> T --> C

Índice de sub-tópicos🔗

Quando escrever GDD🔗

Pré-produção (sempre!)🔗

O GDD deve existir antes de começar a implementar. Sem ele:

Desenvolvedores não sabem o que implementar
Designer muda de ideia constantemente
Equipe perde tempo em features que serão cortadas

Durante produção🔗

O GDD evolves — atualize conforme aprende:

Novo insight de playtest
Escopo precisa mudar
Sistemas mudam

Evite🔗

Escrever GDD de 200 páginas antes de jugar qualquer protótipo
Tratar GDD como contrato inmutable
Deixar GDD apodrecer sem updates

Estrutura recomendada🔗

Estrutura minimalista (para indie/small team)🔗

1. Concept & Vision
2. Core Loop
3. Mecânicas principais (3-5)
4. Progressão básica
5. Monetização (se aplicável)
6. Inspirations/references

Estrutura completa (para equipe maior)🔗

1. Executive Summary
2. Concept & Vision
3. Core Loop
4. Mecânicas detalhadas
5. Sistema de progressão
6. Narrativa (se houver)
7. Personagens
8. Level design
9. UI/UX
10. Technical requirements
11. Audio/music
12. Monetização
13. Marketing

Seções essenciais🔗

1. Concept & Vision🔗

Perguntas a responder:

O que é este jogo?
Que experiência queremos criar?
Em uma frase, por que alguém jogaria?

Exemplo:

“Um roguelike deckbuilder onde cada carta é um artefato mágico com personalidade própria. A experiência é de ‘companhia estranha mas querida’ — como um grupo de amigos excêntricos em uma jornada.”

2. Core Loop🔗

Descreva o minuto a minuto do jogo:

Core Loop: Explorar → Lutar → Coletar → Melhorar → Explorar

Para cada fase do loop:

O jogador faz o quê?
Quanto tempo leva?
Qual é o reward?

3. Mecânicas principais🔗

Para cada mecânica:

O que é: descrição clara
Por que existe: que problema resolve / que estética apoia
Como funciona: regras específicas (números!)
Como se relaciona com outras mecânicas

4. Progressão🔗

Como o jogador melhora?
Quais são os gates (locks de progressão)?
Qual é o longo prazo ( endgame)?

Exemplo de conceito🔗

## Concept: "Dungeon of Borks"

**Elevator pitch**: "Harry Potter meets roguelike meets Tamagotchi"

**Genre**: Roguelike de ação com elementos de creature-collection

**Core fantasy**: Você é um bruxo iniciante que treina criaturas mágicas
("Borks") para explorar masmorras. Cada Bork tem personalidade distinta
que afeta seu comportamento em combate.

**Target audience**: Jogadores de 12-35 que curtem:
- Roguelikes (Hades, Slay the Spire)
- Creature collection (Pokémon, Temtem)
- Fantasy/acción

**Platform**: PC (Steam), depois Switch

**Competitors**: Hades, Temtem, Monster Sanctuary

**Unique hook**: Borks têm "personalidade" que afeta comportamento —
um Bork brave pode se recusar a atacar eticamente em certas situações.

Anti-patterns🔗

❌ GDD como specrigid🔗

Problema: GDD muito detalhado mata criatividade durante production.

Solução: Marque explicitamente “decisões finais” vs “sugestões”.

❌ GDD como wishful thinking🔗

Problema: Descrever o jogo perfeito sem considerar constraints de time/orçamento.

Solução: Inclua seção “Scope constraints” e “Technical realities”.

❌ GDD de uma pessoa🔗

Problema: Designer writes GDD alone, team doesn’t buy in.

Solução: Review GDD com equipe antes de lockar seções.

❌ GDD sem imagens🔗

Problema: Walls of text are boring, people don’t read.

Solução: Use diagrams, mockups, concept art, flowcharts.

Mantendo o GDD vivo🔗

Processo de update🔗

Design decision é tomada
GDD updated dentro de 24h
Change logged com data e razão
Team notified via canal apropriado

Versionamento🔗

gdd_v1.0_concept.md
gdd_v1.1_core_loop.md
gdd_v2.0_full_draft.md
gdd_v2.1_milestone_alpha.md

Ownership🔗

Game Designer é o owner do GDD
Outros podem propor changes via PR ou issue
Designer tem a palavra final em disputes

Veja também🔗

Design Doc Template — template prático
Paper Prototyping — testando ideias antes de escrever
Postmortem Writing — documentando após o projeto

Você aprendeu

Quando escrever GDD
Estrutura recomendada
Seções essenciais
Exemplo de conceito
Anti-patterns

Perguntas para reflexão

O que Quando escrever GDD resolve, e o que se perde sem isso?
O que Estrutura recomendada resolve, e o que se perde sem isso?
O que Seções essenciais resolve, e o que se perde sem isso?
Que parte desta página você conseguiria explicar a alguém que nunca fez um jogo?

Referências🔗

Adams, Ernest (2006). Fundamentals of Game Design. Prentice Hall. ISBN 978-0-13-210475-3.
Fullerton, Tracy (2004). Game Design Workshop. CRC Press. ISBN 978-0-240-80974-8.
Schell, Jesse (2014). The Art of Game Design: A Book of Lenses (2ª ed.). CRC Press. ISBN 978-1-4665-9864-5. Materiais suplementares