# Modelo de documento de design de jogos de uma página URL: https://auxworld.app/pt/journal/modelo-documento-design-jogos Type: blog Locale: pt Published: 2026-10-27 Updated: 2026-10-29 --- > Um modelo de documento de design de jogos de uma página, com sete blocos, dicas de corte e o que muda quando o mundo é gerado por prompt. 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?" ![Esboço em quadro branco de um loop central desenhado como quatro caixas ligadas por setas](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/7165e4-core.webp) ## 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. - **Pitch.** Uma frase que um estranho conseguiria repetir. "Uma cidade portuária cooperativa onde a maré redesenha o mapa toda noite." - **Loop central.** O que o jogador faz, de novo e de novo, em menos de um minuto. Desenhe como um círculo de verbos. - **Verbos do jogador.** Cinco a oito ações. Não funcionalidades. Verbos: escalar, negociar, esconder, bifurcar, consertar. - **Mundo.** Lugar, clima e três regras que são sempre verdade. Clima conta como regra. - **Sistemas.** Os dois ou três mecanismos que tornam os verbos interessantes. Economia, furtividade, criação, o que for que sustente o loop. - **Escopo.** O que será lançado, o que foi cortado e o que é extra. Coloque uma data ao lado de cada item. - **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](https://www.gitbook.com/blog/how-to-write-a-game-design-document) 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](https://connect-prd-cdn.unity.com/20201215/83f3733d-3146-42de-8a69-f461d6662eb1/Game-Design-Document-Template.pdf) é 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. ![Laptop mostrando uma vila neblinada gerada ao lado de um caderno de esboços de design](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/21d264-world.webp) ## 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. - Escreva a página de uma folha em 30 minutos. Não edite. - Transforme o pitch e as três regras do mundo em um prompt e gere uma primeira versão do espaço. - Percorra o loop central nesse espaço, à mão ou num protótipo rápido. - Marque cada passo que pareceu morto. Eles vão para as perguntas abertas. - 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. ![Quadro de cortiça com fichas ligadas por barbante vermelho, uma ficha sendo fixada](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/0dac63-cards.webp) ## 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. ## FAQ ### O que um modelo de documento de design de jogos precisa ter? Sete blocos: pitch, loop central, verbos do jogador, mundo, sistemas, escopo e perguntas abertas. Tudo cabe em uma página e deve ser preenchido em uma noite. ### Quanto tempo deve ter um GDD? Uma página para começar. Acrescente detalhes apenas quando um protótipo justificar cada um. ### Preciso incluir monetização no documento? Não no começo. Monetização, marketing e história dos personagens pertencem a arquivos separados, escritos depois que o loop central funcionar. ### Markdown ou app de notas para o GDD? Markdown no repositório funciona bem para equipes técnicas, porque gera diffs e fica ao lado do código. Apps de notas com banco de dados ajudam quando há colegas não técnicos. ### Como documentar um jogo com mundos gerados por prompt? Registre as restrições do mundo, as regras que nunca podem quebrar, e as sementes de prompt usadas, com a versão da ferramenta e a data. ### Com que frequência atualizar o documento? Na mesma sessão em que você muda o build. Atrasar a atualização é o que transforma o documento em fóssil.