# Modelo de documento de game design: uma página que cresce URL: https://koroverse.app/pt/journal/modelo-de-documento-de-game-design Type: blog Locale: pt Published: 2026-10-16 Updated: 2026-10-16 --- > Um modelo de documento de game design que começa em uma página e cresce quando os playtests comprovam cada mecânica, com pilares, lore e escolha de ferramenta para designers indie e de RPG. Um modelo de documento de game design deve caber em uma página no começo e crescer só quando o jogo justificar isso. Comece com cinco blocos: pitch, pilares de design, loop central, lista de sistemas e perguntas em aberto. Todo o resto, do lore às notas de nível, entra quando um playtest provar que a mecânica é real. Abaixo está o modelo que usamos em projetos de RPG de mesa e de jogos indie, e os pontos em que cada seção costuma apodrecer. ## Por que a maioria dos documentos de game design morre na terceira semana? O erro mais comum é a ambição. Alguém abre um arquivo em branco, cola um roteiro de vinte seções tirado de um fórum e passa o fim de semana preenchendo caixas para mecânicas que ninguém testou. Na terceira semana, o jogo mudou e o documento não. Ninguém abre mais, e ninguém admite. O guia de GDD da Game Dev Beginner aponta o problema sem rodeios: documentos grandes e excessivamente detalhados exigem muito trabalho no início, quase sempre ficam desatualizados e viram uma camisa de força quando o design ainda está mudando. A solução dele é fazer por etapas. Escreva primeiro um documento de uma página, depois um de dez páginas quando o jogo tomar forma, e a versão completa só quando o conteúdo estiver sendo produzido. Essa etapa importa mais para quem cria RPG de mesa do que para equipes de videogame. Um designer de RPG costuma ser ao mesmo tempo o redator, o responsável pelos sistemas e o playtester. Não há engenheiro esperando uma especificação. O documento tem um único trabalho: impedir que você se contradiga entre a sessão quatro e a sessão quarenta. Dispense o modelo de 40 páginas se você trabalha sozinho, porque você não vai conseguir mantê-lo. Até a [definição padrão de game design document](https://en.wikipedia.org/wiki/Game_design_document) trata o GDD como um documento vivo, o que significa que ninguém espera que ele esteja pronto no primeiro dia. ## O que realmente entra em um modelo de documento de game design que as pessoas abrem? Cinco blocos cobrem o primeiro mês de quase qualquer projeto. Mantenha cada um curto o bastante para ler a página inteira em dois minutos. - **Pitch.** Duas frases. Quem joga, o que faz e o que torna o jogo diferente do mais parecido que a pessoa já possui. - **Pilares de design.** Três ou quatro afirmações contra as quais cada decisão posterior será testada. "Todo combate custa algo permanente" é um pilar. "Divertido e envolvente" não é. - **Loop central.** O que o jogador repete. Em uma masmorra, pode ser explorar, escolher, arriscar e gastar. Em uma campanha política, pode ser intriga, pressão, consequência e desgaste. - **Lista de sistemas.** Só nomes, com uma linha cada. Não especifique números ainda. - **Perguntas em aberto.** A seção mais útil da página, e a que os modelos costumam deixar de fora. Escreva o que você ainda não sabe e data a anotação. Acrescente um registro de mudanças no final, nem que seja uma linha por semana. Quando um playtest matar uma ideia, anote a morte e o motivo. Caso contrário, seu eu do futuro vai tentar a mesma ideia de novo. ![Quadro de cortiça com nove fichas em branco presas em grade, uma mão ajustando uma delas](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/koroverse/2026-10/eb3440-inline1.webp) ## Como escrever pilares de design que possam perder uma discussão? Um pilar se justifica vetando algo. Se você não consegue citar uma funcionalidade que o pilar rejeitaria, ele é só enfeite. Teste cada pilar com uma lista de cortes. Pegue as três funcionalidades de que você mais gosta e pergunte a qual pilar cada uma serve. Uma funcionalidade que não serve a nenhum pilar vai para a prateleira do "talvez depois", e essa prateleira pode ser longa. É a hora mais difícil de todo o processo, e ela vale mais do que qualquer seção de modelo. Veja um exemplo trabalhado, de um cenário de campanha com uma peste no centro. Pilar um: a escassez é visível, então cada recurso de cura é rastreado na mesa. Pilar dois: as facções querem curas diferentes, então nenhum tratamento resolve tudo. Pilar três: o mapa encolhe, então viajar fica mais caro conforme a história avança. Agora chega a proposta de uma magia de ressurreição. O pilar um a rejeita. A decisão leva dez segundos em vez de um debate de quarenta minutos. Vale saber: pilares não são slogan de marketing. São internos, diretos e podem soar meio ásperos. Tudo bem. ## Onde o lore deve ficar em um GDD, e onde ele atrapalha? O lore é a seção que mais cresce e a que menos é lida. A maioria dos documentos ou o enterra em um título "História" no fim, ou deixa que ele engula o arquivo inteiro. Nenhuma das duas coisas funciona. Separe o material pelo que ele faz. O lore que muda a jogabilidade, como a rixa de uma facção que destrava uma missão ou uma maldição que molda uma classe, fica dentro dos sistemas que afeta. O lore que só cria atmosfera vai para uma página separada de Codex, que ninguém precisa abrir para tomar uma decisão de design. O teste é simples: se apagar o parágrafo não mudaria mecânica, rolagem nem escolha do jogador, ele pertence ao Codex. Essa divisão também protege o cânone. Quando um fato vive em dois lugares, os dois se afastam. Escolha uma casa para cada fato e linke para ela a partir de todos os outros lugares. Cânone é uma promessa, e cada inconsistência a quebra. ![Notebook fechado ao lado de um caderno em branco, lápis, dados e livros sobre a mesa do mestre de jogo](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/koroverse/2026-10/74d10f-inline2.webp) Designers de jogos com narrativa forte costumam acrescentar uma página curta de linha do tempo e uma lista de quem sabe o quê. As duas são baratas. As duas economizam sessões inteiras de retrabalho quando uma revelação tardia precisa cair do jeito certo. ## Qual ferramenta deve guardar seu modelo: Notion, Obsidian ou um documento simples? A ferramenta importa menos do que o fato de o documento ficar no lugar onde você já trabalha. Um documento numa aba que você nunca abre é um documento morto. O Notion é a escolha padrão de equipes pequenas, porque as páginas se linkam entre si, bancos de dados guardam itens e facções, e os colaboradores não precisam de configuração. Existem modelos prontos, incluindo [um modelo de GDD para o Notion](https://www.notion.com/templates/game-design-document-gdd), com seções para controles, loop de jogo, desenho de fases e regras. O porém é o aprisionamento à ferramenta e a tentação de criar bancos de dados para coisas que não precisam deles. O Obsidian serve ao designer solo que quer arquivos Markdown simples no próprio computador. Os backlinks trabalham de verdade aqui: linke uma facção a todas as cenas em que ela aparece e você ganha uma checagem de consistência de graça. Ele sobrevive ao fim de um fornecedor, o que importa se o projeto durar anos. O GitBook funciona quando o documento precisa ser público ou semipúblico, por exemplo para um grupo de playtest ou a página de apoiadores de um financiamento coletivo. Um Google Docs simples serve para uma game jam. Evite qualquer coisa com um modelo de permissões pesado, a não ser que uma editora peça. Seja qual for a escolha, defina uma regra: o documento é atualizado ao fim de cada playtest, antes de todo mundo ir para casa. Dez minutos, sem exceção. ## O que acrescentar quando o protótipo sobrevive aos playtests? Depois de três ou quatro sessões com jogadores reais, a página de uma folha ganha a próxima camada. Acrescente seções nesta ordem, e só quando a dor aparecer. **Detalhe dos sistemas.** Números, tabelas de consulta, casos-limite. Escreva isso à medida que trava um sistema, não antes. Em RPG de mesa é aqui que entram a economia de ações, as faixas de dano e os custos de recursos, junto com o texto das regras como ficou escrito. Em videogame, adicione as tabelas de dados que os engenheiros vão ler. **Listas de conteúdo.** Itens, inimigos, facções, locais. Use uma lista com uma linha por entrada e, em cada linha, o pilar que ela serve. Entradas que não servem a nenhum pilar são candidatas a corte. **Interface e fluxo.** Layout da ficha de personagem no RPG de mesa, fluxo de telas no digital. Esboce à mão antes de descrever em texto. **Notas de produção.** Marcos, escopo, riscos, o que entra na primeira versão e o que fica de fora. Se você planeja vender o resultado na DriveThruRPG ou na Itch.io, é também aqui que começam o texto da página e as premissas de preço. Uma seção de pitch ou de marketing é um documento separado, para um leitor separado. Editoras e apoiadores querem contexto de mercado e diferenciais. Seus playtesters querem regras. Misturar os dois gera um arquivo que não serve a nenhum deles. ![Mapa de região desenhado à mão, com miniaturas pintadas marcando os territórios das facções](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/koroverse/2026-10/4279d7-inline3.webp) ## A IA pode ajudar a escrever um documento de game design, e onde ela deixa a desejar? Ela ajuda com rascunhos das partes chatas e falha nas partes que importam. Peça a um modelo para expandir uma lista de sistemas em uma tabela de casos-limite e você terá uma primeira versão razoável em um minuto. Peça que escolha seus pilares e você receberá pilares que soam como os de qualquer outro jogo. Ela gera rápido. As decisões ainda precisam de uma passada humana. O uso prático é a checagem de consistência. Alimente a ferramenta com as páginas de lore e com a lista de sistemas, depois pergunte em quais páginas duas afirmações se contradizem. Ferramentas feitas em torno de uma bíblia de história longa, como o Novelcrafter, são pensadas para esse tipo de cruzamento de referências. Trate a saída como uma lista de suspeitos, não como veredito, e confira cada alerta contra as suas próprias páginas. Uma regra firme: o modelo nunca escreve a seção de perguntas em aberto. Essa página é a sua lista honesta do que você não sabe, e entregá-la a outro derrota o propósito. ## O que pular e o que manter? Pule o modelo completo até que uma mecânica tenha sobrevivido a pelo menos três sessões reais. Pule o ensaio sobre "público-alvo" se você não consegue nomear cinco pessoas de verdade que jogariam. Pule seções detalhadas de monetização para um jogo que ainda não encontrou seu loop. Pule qualquer seção que você não consiga imaginar lendo em voz alta para um colaborador. Mantenha os pilares, as perguntas em aberto e o registro de mudanças. Esses três fazem a maior parte do trabalho. Um documento só com eles, atualizado toda semana, vence um arquivo de 30 páginas bem acabado que ninguém abre desde março. O modelo é uma promessa para o seu eu futuro sobre o que você decidiu e por quê. Mantenha-o curto o bastante para conseguir cumprir a promessa. ## FAQ ### Qual deve ser o tamanho de um modelo de documento de game design no início? Uma página, com pitch, pilares de design, loop central, lista de sistemas e perguntas em aberto. O documento só cresce para cerca de dez páginas depois que o jogo toma forma, e a versão completa entra quando o conteúdo começa a ser produzido. ### Quantos pilares de design um GDD deve ter? Entre três e quatro. Cada pilar precisa conseguir rejeitar pelo menos uma funcionalidade concreta, senão ele não ajuda na hora de decidir. ### Onde colocar o lore em um documento de game design? O lore que altera uma regra, uma rolagem ou uma escolha do jogador fica dentro do sistema afetado. O restante vai para uma página separada de Codex, que não precisa ser consultada para tomar decisões de design. ### Notion, Obsidian ou Google Docs: qual escolher? A melhor ferramenta é a que você já usa todo dia. O Notion serve a equipes pequenas, o Obsidian serve a quem trabalha sozinho com arquivos Markdown e o Google Docs basta para uma game jam. ### Com que frequência o documento deve ser atualizado? Ao fim de cada playtest, antes de encerrar o dia. Leva cerca de dez minutos e evita que as decisões de uma sessão se percam na seguinte. ### A IA pode escrever a seção de perguntas em aberto? Não. Essa seção é a lista honesta do que você ainda não sabe. Use a IA para checar contradições entre páginas e expandir rascunhos, e revise cada alerta antes de aceitá-lo. ### O que deixar de fora de um GDD em um projeto solo? Ensaios sobre público-alvo sem pessoas reais, monetização antes de o loop estar definido e qualquer seção que você não leria em voz alta para um colaborador.