O GDD (ou Game Design Document) é um documento contendo todas as informações relevantes do design de um jogo: temática, mecânicas, plataformas, inimigos, levels, entre outros.

Quando ainda estamos dando os primeiros passos no mundo de criação de jogos, é normal ficarmos perdidos na hora de tirar ideias da cabeça e colocar no papel. Para organizar nossas ideias e ter clareza sobre o jogo que será criado, o que precisamos é criar um bom GDD (não se preocupe, vou te explicar o que “bom GDD” significa nesse contexto durante o artigo).

O Game Design Document será seu guia (ou o guia da sua equipe) na hora de criar o jogo. Ele vai funcionar como um “Manual de Montagem” do seu jogo, contendo as principais informações sobre a proposta, funcionalidades e mecânicas do seu game.

Existem diversos fóruns, artigos e cursos tentando estabelecer um formato “definitivo” de GDD. Esqueça isso. Criar um GDD é um pouco de ciência e um pouco de arte. Existem vários formatos e diretrizes importantes (que veremos neste artigo), mas a verdade é que você precisará adaptar o seu GDD às necessidades do seu jogo e da sua equipe.

Continue então lendo esse artigo onde vamos aprofundar nos seguintes tópicos:

• Quando vale a pena criar um GDD? (e quando é perda de tempo?)
• Definindo o formato: Dos GDDs de página única às “Bíblias” de jogos AAA
• Escrevendo com foco: 14 perguntas para criar o seu GDD
• Como disponibilizar o Game Design Document para sua equipe e garantir que nenhuma ideia será perdida
• Dicas importantes de 3 profissionais experientes da indústria de games

Quando vale a pena criar um GDD? (e quando é perda de tempo?)

Há quem diga “nunca crie um GDD, é uma perda de tempo”.

As pessoas que dizem isso geralmente argumentam que o GDD atrapalha mais que ajuda, pois existem demasiadas informações, detalhes e a equipe acaba nunca seguindo as orientações lá contidas.

Isso realmente pode acontecer, mas apenas quando o formato de GDD adotado pela equipe é inadequado. Ou seja, quando documenta-se no GDD muito mais que o necessário para a implementação eficiente do projeto.

Um ótimo exemplo são as famosas game jams de 24 a 48 horas, onde cada minuto é extremamente valioso. Em casos assim, o tempo que você gastaria criando um GDD elaborado pode ser muito melhor aproveitado trabalhando no desenvolvimento do jogo em si.

Quando o jogo é simples e possui mecânicas conhecidas, ou mesmo quando estamos criando um jogo apenas pra treinar nossas habilidades, é bem provável que escrever um GDD seja desnecessário.

Em casos assim, escrever um GDD pode ser até perda de tempo.

Mas, como você deve imaginar, existem várias situações onde escrever um GDD não apenas irá te economizar tempo, mas também pode garantir que seu jogo será de fato concluído e publicado (veremos isso em detalhes logo a seguir).

Por que então criar um GDD?

Eu pessoalmente acredito que um GDD escrito de acordo com as necessidades do projeto e da equipe é uma ferramenta extremamente útil.

Ele fará com que todos os envolvidos no desenvolvimento do jogo tenham clareza sobre qual é o objetivo do projeto e o que precisa ser feito até ele ser concluído.

Assim, um dos seus principais objetivos ao escrever o GDD é a comunicação de como será o design do jogo. É no GDD que o game designer irá reunir as informações sobre o conceito, as mecânicas e os detalhes do jogo.

Se você estiver desenvolvendo sozinho, o GDD vai servir como uma forma de deixar o projeto documentado para você não se perder ao longo do processo.

E no caso de desenvolvimento em equipe, o GDD terá um papel ainda mais importante: garantir que todos os envolvidos no projeto consigam trabalhar em sintonia e com clareza sobre o que precisa ser feito.

A partir do GDD, todos os membros da equipe (desde os programadores até os artistas gráficos e músicos) podem ter certeza do que estão fazendo e de como será o jogo, para assim conseguirem criar os assets certos para o jogo.

Em resumo, um GDD bem escrito servirá como um “guia” durante todo o desenvolvimento.

Definindo o tamanho: Dos GDDs de página única às “Bíblias” de jogos AAA

Não existe um formato único de GDD, algo que funcione para todos os casos.

Mas existem sim alguns formatos mais populares, como os GDDs de página única, os GDDs de 10 páginas e o GDDs mais longos, popularmente conhecidos como “GDD tipo Bíblia”.

Eu vou te explicar em detalhes cada um desses formatos, mas primeiro precisamos aprender a analisar as necessidades de cada projeto.

Existem alguns princípios básicos que vão te ajudar a decidir se você precisa de um GDD mais curto ou mais longo. E é isso que eu vou te mostrar a seguir.

Analisando suas necessidades: como decidir qual formato de GDD adotar?

Antes de decidir qual formato de GDD adotar, você precisa analisar as necessidades do seu projeto. Na minha opinião, esses são os 3 principais pontos que você deve avaliar: Tempo de Desenvolvimento, Tamanho da Equipe e Complexidade do Projeto.

Vamos ver cada um deles em detalhes.

1) Tempo de desenvolvimento

No geral, quanto menor o tempo de desenvolvimento, menos você precisa documentar.

Vamos pensar em extremos: em uma game jam de 24h, se você estiver trabalhando individualmente ou mesmo em uma equipe, gastar muito tempo documentando cada detalhe do jogo pode acabar te atrapalhando em conseguir concluir seu desenvolvimento.

Acredito ser importante ter algum tipo de documentação para todos entenderem o que precisa ser feito e como é o projeto, mas nada extenso. Nesses casos, até mesmo um conjunto de post-its podem resolver o problema.

Por outro lado, vamos pensar num projeto que está planejado para durar 1 ano. Seja desenvolvendo sozinho ou com uma pequena equipe, é loucura pensar em ficar 1 ano sem documentação nenhuma.

A chance de você se perder no meio do desenvolvimento ou aumentar o escopo sem se dar conta é enorme. E também não é uma boa ideia contar unicamente com a sua memória para se lembrar de todos os detalhes.

2) Tamanho da equipe

Quanto menor é a equipe, teoricamente mais fácil é a comunicação entre seus membros.

Logo, se for apenas você ou uma equipe pequena, é possível não ser necessário um documento com muitos detalhes. Afinal, vocês provavelmente vão se comunicar com bastante frequência e todos terão acesso direto ao game designer.

Por outro lado, com uma equipe grande as coisas já mudam. A comunicação começa a não ser tão fácil, pois existem várias pessoas trabalhando no mesmo projeto.

Nesse caso o GDD se faz necessário para garantir que todos tenham todos os detalhes relevantes do projeto, aumentando assim as chances da equipe trabalhar em sintonia em busca do mesmo objetivo final.

3) Complexidade do projeto

Nesse ponto, vamos fazer uma distinção importante: nem sempre o tempo de desenvolvimento de um projeto é diretamente proporcional à sua complexidade.

Num exemplo de jogo puzzle, o projeto pode ser extremamente simples, mas o tempo de desenvolvimento ser longo porque existe apenas uma pessoa na equipe e o objetivo é criar 5.000 fases.

Nesse caso do projeto ser simples, mas o tempo de desenvolvimento longo, é provável que a documentação não precise ser tão extensa.

Por outro lado, a complexidade aumenta se você tem um jogo com diversos personagens, multiplayer, vários níveis de dificuldade e diferentes chefões. Nesse caso, por menor que seja a equipe ou o tempo de desenvolvimento, você provavelmente precisará de uma documentação mais extensa.

Cabe a você avaliar qual é a necessidade do seu projeto. Mas perceba que se for criar um jogo como Pacman, não precisará de muitas páginas, pois é um jogo simples e de poucos elementos.

No entanto, se pretende criar um jogo com uma história complexa, vários personagens e mecânicas elaboradas, seu GDD com certeza precisará ser maior.

Os 3 formatos mais populares de GDD (e quando adotar cada um)

Existem diversas recomendações sobre quais informações um bom GDD deve ter. Uma referência nessa questão é o livro Level UP, onde o autor Scott Rogers compartilha algumas diretrizes para criar esse documento.

No livro, Rogers sugere algumas etapas para completar antes de criar um GDD mais completo. Duas etapas que ele recomenda são a criação de um documento de 1 página e em seguida a de um documento de 10 páginas.

No entanto, esses documentos podem ser uma ótima ferramenta “por si só”, ou seja, não é preciso “evoluí-los” para outro documento mais complexo se isso não estiver de acordo com a necessidade do projeto.  

Vamos ver as características gerais de cada um:

GDD de página única

Esse é um documento curto, de apenas 1 página, cujo objetivo é dar uma visão geral do jogo e suas principais características.

Seus tópicos são curtos e objetivos e pode ser ótimo para projetos pequenos ou de baixa complexidade. Eu acredito que todo desenvolvedor de jogos deveria ter familiaridade pelo menos com esse tipo de GDD. 

Inclusive, já fiz um vídeo analisando o GDD de 1 página de um jogo que foi publicado na Steam e no Nintendo Switch! Confira o vídeo na íntegra logo abaixo:

GDD de 10 páginas

Esse é um documento de aproximadamente 10 páginas (como o próprio nome diz) que vai delinear os principais pontos do projeto com um pouco mais de detalhes e profundidade.

Como é um documento maior, aqui você tem mais espaço para incluir elementos visuais (como diagramas do gameplay) para facilitar o entendimento e tornar a leitura mais dinâmica.

Se o tempo estimado para desenvolver seu jogo é de alguns meses, esse provavelmente é o formato adequado. Ele não é tão raso quando o GDD de página única, mas também não é um documento complexo e extenso (como o formato “Bíblia” que veremos a seguir).

GDD no formato “Bíblia”

Ainda há um outro tipo de GDD, que é conhecido popularmente como “bíblia”. Esse já é um documento bem maior, que pode ter de 80, 100 ou muito mais páginas, com detalhes bem específicos sobre cada parte do jogo.

No geral, jogos menores como os indie não necessitam de um GDD tão longo. Na verdade, até mesmo entre as grandes empresas de games esse é um tipo de GDD que está caindo em desuso.

Por ser um documento muito grande, ele acaba não sendo lido ou consultado pela equipe. Além disso, é difícil realizar atualizações no documento por conta de sua estrutura e complexidade.

Algumas décadas atrás, esse era o GDD padrão para grandes jogos. Aquele criado “to rule them all“.

Mais pra frente no texto, você verá uma solução que grandes empresas encontraram para isso.

Escrevendo com foco: 14 perguntas para criar o seu GDD

Apesar de não existir um formato padrão, a maioria dos GDDs contém alguns itens em comum. A seguir, eu vou te explicar cada um desses itens para que você possa avaliar se deve incluí-los no GDD dos seus jogos.

Você vai notar que nem todos os tópicos são aplicáveis a todos os tipos de jogo. Mas com o que você aprendeu até aqui, eu acredito que você conseguirá tomar boas decisões sobre o que entra no seu GDD e o que ficará de fora no início.

Mais uma vez, tenha em mente que o objetivo principal do GDD é a comunicação. Não existe uma forma “certa” de criá-lo e você pode (e deve!) utilizar o melhor recurso que conseguir para comunicar suas ideias.

Aqui vão as perguntas:

• Qual é o título do seu jogo? Escreva aqui o nome dele (mesmo que provisório) e também pode adicionar o nome e logo da equipe se houver.
• O seu jogo será desenvolvido para qual/quais plataformas?
• Qual será a classificação etária do jogo? E quem é o público alvo? (exemplo: mulheres de 30-50 anos)
• Qual é o modelo de monetização? Defina como será o modelo de monetização (se houver), se vai ser com micro transações, se o jogo será pago ou completamente gratuito.
• Quais são os produtos competidores/semelhantes? Fale dos jogos que já foram publicados e se assemelham com o seu em diversos pontos. Isso ajuda a equipe de desenvolvimento ter uma noção do todo, entender como as ideias escritas no GDD vão ser aplicadas.  
• Qual é a história? Em um GDD curto você só vai ter espaço para um resumo da história. Num GDD mais longo você terá espaço para mais detalhes. Conte o início, meio e desfecho da história.
• Qual é a Proposta Única de Vendas? Fale sobre as características únicas que fazem o seu jogo se diferenciar de todos os outros e se destacar dentre eles. Mesmo usando outros jogos como referência, pense em como o seu jogo se diferencia deles.
• Como é o fluxo do jogo? Fale o contexto que o jogador se encontrará no jogo. Alguns pontos interessantes para incluir são: (1) quem é o personagem que ele está jogando, (2) o ângulo da câmera (primeira pessoa, terceira pessoa?), (3) o gênero do jogo, (4) os desafios que o jogador vai encontrar e como superá-los, (5) como o jogador evolui no jogo de acordo com o aumento do desafio e (6) qual é a grande vitória do jogador ao terminar o jogo.
• Como é o personagem principal? Descreva com mais detalhes o personagem principal como seu sexo e idade. Aqui é interessante ter uma concept art mostrando a aparência dele. Além disso, fale sobre as suas principais habilidades, sobre o traço predominante de sua personalidade e sobre seu comportamento em ambientes críticos (como pouca vida por exemplo ou subindo uma escada). Também é interessante destacar os comandos de controle, como quais botões ele se movimenta, como realiza ações. Imagens e GIFs podem ajudar a esclarecer melhor alguns pontos.
• Como é a o gameplay? Em algum momento você já terá definido o gênero do jogo, mas é interessante descrever como é que os jogadores vão interagir com o jogo. Fale sobre as experiências do jogador, se o jogo terá vários capítulos ou se o jogo é feito em níveis e rodadas. Além disso, fale sobre mecânica do gameplay e quais serão os elementos colecionáveis (moedas ao longo do caminho), os power-ups (como vida extra) e os danos (espinhos, guilhotinas). Se houver minigames, descreva-os também.
• Como será o mundo do Jogo? Descreva os ambientes mencionados na sua história, como por exemplo como eles são e como eles interferem na história. Fale sobre a mudança de paisagens ao longo do jogo, as músicas em cada uma e como o jogador se movimenta através delas.
• Como é a interface? Escreva sobre a interface de navegação durante o jogo, como será cada tela de interface e se possuem música. Imagens e GIFs também ajudam a ilustrar esses itens.
• Quais e como são os inimigos e chefes? Defina aqui as características dos inimigos (como onde são encontrados, tamanho, como agem e como batem). Assim como para os chefes, aqui descreve-se suas características, quando aparecem, o que fazer para derrotá-los e o que acontece quando são derrotados.
• Qual é o fator replay? Descreva o que motivará o jogador a continuar a jogar depois de finalizar o jogo, ou terminar uma fase ou luta. Esses elementos podem ser elencados a fim de ter uma ideia do que possa ser melhorado futuramente para aumentar ainda mais a motivação do jogador em continuar a jogar.

As perguntas acima foram pensadas para um GDD um pouco mais detalhado (um de 10 páginas, por exemplo), então provavelmente você não conseguirá incluir todos esses itens em um GDD de página única. Se você quiser ver exemplos desse tipo específico de GDD, eu preparei um template e exemplos pra você baixar no final desse artigo.

Além da parte escrita do GDD, alguns tópicos podem ser mais facilmente entendidos se tiverem uma ilustração, um desenho ou mesmo gif (por exemplos os tópicos Mecânica, Gameplay, Personagem e Interface).

Um ótimo exemplo disso são as imagens de interface criadas para o jogo Heroes of Andromeda durante a 4ª Maratona da Academia de Produção de Jogos:

Como disponibilizar o Game Design Document para sua equipe e garantir que nenhuma ideia será perdida

Se a equipe está desenvolvendo sempre junta de forma presencial, é possível criar o GDD em mídias físicas como cadernos, post-is e cartolinas.

Mas se será um documento maior e/ou a equipe trabalha de diferentes lugares, é interessante ter a documentação online para que todos tenham acesso de forma rápida e fácil.

Algumas formas de compartilhamento online do GDD podem ser:

• Documento no Google Drive: para utilizar o Google Drive é preciso que os membros da equipe possuam um email do Google para acessarem o documento do GDD e outros arquivos e pastas do projeto. É uma boa opção, pois é um serviço gratuito e no documento em texto ficam salvas todas as alterações e versões do documento.
• Dropbox: no plano individual gratuito, cada membro pode utilizar seu email para acessar o GDD e outros arquivos e pastas do projeto. No documento em texto ficam salvas todas as alterações e versões.
• GitHub: para utilizar o Github é preciso que os membros da equipe possuam uma conta no site também para ter melhor experiência. Nele você pode criar o arquivo privado ou público e compartilhá-lo com a equipe, que também pode alterá-lo.

Enfim, a forma de compartilhamento vai depender do que melhor se enquadra em seu projeto, lembrando sempre que a equipe (se for o caso) deve ter acesso sempre e poder acompanhar as mudanças que houver no documento.

Dicas importantes de 3 profissionais experientes da indústria de games

Abaixo eu separei algumas dicas importantes de 3 desenvolvedores profissionais, para você entender como eles utilizam GDDs em seus próprios projetos.

Nicholas Souza, senior game designer na Ubisoft Montreal

No trecho dessa entrevista, Nicholas Souza conta como o Game Design Document é visto em grandes empresas de jogos, como a Ubisoft.

Ele começa falando que em grandes empresas internacionais não existe mais o GDD (pelo menos não no formato de documento único):

“Se você for na Ubisoft ou numa grande empresa, o GDD não existe mais. GDD era uma coisa que se fazia até o início dos anos 2000 em que você cria um documento que tem toda a informação de design do jogo.

O principal da comunicação do design é como explicar o que você quer fazer. Partindo desse pressuposto, o documento que você vai criar para passar a informação do design, a equipe tem que entender. Quando a equipe tiver algum problema, ela tem que pegar aquilo e ler. O GDD por natureza é um documento que o designer vai fazer, vai gastar um tempão pra fazer e ninguém vai ler. Você vai ter 150 páginas e nunca vai atualizar depois.”

Ele também comenta uma solução que encontraram pra isso:

“O que eles fazem por padrão nas empresas internacionais é criar apresentações que expliquem as diferentes mecânicas e diferentes partes do jogo. Lá a gente faz apresentações no Powerpoint. (…) E depois cria uma apresentação para cada feature do jogo explicando o design dela. É uma forma concisa e que a equipe vai entender. O programador vai conseguir ver o slide e voltar nele quando tiver uma dúvida. Ao invés de ter um documento de 150 páginas, ter apresentações de diferentes features também ajuda você a ver os escopos do projeto.”

E depois ainda completa dizendo o porquê acredita que essa é uma ótima solução:

“Como são documentos individuais, cada um explica uma mecânica, é muito mais fácil atualizar. E é muito mais fácil explicar uma mecânica com imagens, com um pouco de texto e imagens. Isso é o suficiente, as vezes até mesmo usar Excel para mostrar um algoritmo. Os grandes jogos são feitos assim. O GDD é uma coisa mais antiga. Sim, você pode usar o GDD, não tem problema, mas por apresentações é mais simples. (…) Se você fizer um documento com 50 mil linhas, não é gerível. Hoje em dia você fala das features do jogo e então você tem os documentos das features. É como se você tivesse um grande repositório e ali tem tudo compartimentalizado.”

Thais Weiller, game designer na JoyMasher

Nesse artigo escrito pela Thais Weiller, um dos principais pontos que ela discute é como criar o GDD tanto em relação a tamanho e formato de acordo com o seu projeto:

“Para algumas pessoas, um desenho esboçando o funcionamento de uma mecânica é a melhor forma de entender o que deve ser feito. Caso esse seja o caso e realmente o tempo de desenvolvimento seja curto, um apanhado de desenhos e notas esquematizando o jogo todo seja o suficiente. Algo como um quadro negro com com o esquema da primeira fase, a explicação dos inimigos e traps que devem ser implementadas e algumas notas da back story.”

E continua:

“Se tudo couber nesse quadro negro ou A3 e os membros da equipe não estão tendo problemas entendo o que está lá, essa é toda a documentação que você precisa. Mas se o espaço não está contendo todas as informações necessárias ou os membros estão tendo problemas para lembrar ou entender o que está representado, você precisa de algo mais estruturado.”

Além disso, ela também compartilha um caso que aconteceu na Joymasher:

“Danilo Dias, do Oniken e Odallus, usou um A3 para anotar praticamente tudo o que o Oniken devia ter e ser. Esse A3 também era o mouse pad e porta-xícaras, o que rendeu várias manchas de café ao “documento”. Para um jogo simples e com uma pequena equipe como Oniken, esse documento foi mais que suficiente.”

André Alves, fundador da Little Leds

Nesse episódio do PDJ Show, o André Alves falou um pouco da importância de ter um GDD bem documentado.

“Estruturar sua ideia de projeto que vai demorar semanas ou meses é o que separa você de desistir no meio do caminho ou de um profissional que vai chegar no final com o produto pronto.”

Ele também comenta sobre a importância de estruturar bem o GDD:

“A ideia pode ser ótima, mas você precisa estruturar de forma prática, que dê pra trabalhar. Você precisa estruturar de forma que outra pessoa pegue aquele documento e também fazer aquilo. Se você morrer amanhã, outro designer ou outra equipe vai poder pegar o GDD e vai poder trabalhar no jogo e fazer aquilo acontecer”.

Além disso, ele comenta a importância de criar o GDD mesmo num projeto que desenvolveria sozinho:

“O GDD do jogo A Vítima de Ouro eu fiz pra mim porque ia desenvolver sozinho, mas ajuda principalmente naquele momento que você está desmotivado. No dia que você acorda desmotivado, você procura no documento aquelas tarefas mais simples pra você, mas que vão te ajudar a avançar. Levei mais ou menos 2 semanas criando o GDD e depois fui pra parte prática.”  

E se você quer criar jogos simples e com potencial de lucro, você precisa conhecer jogos semelhantes que tiveram boas vendas na Steam. Para isso, eu criei um ebook com uma seleção de 16 jogos simples e interessantes que você poderia ter feito em poucas semanas.

Além dos jogos, também incluí a quantidade de cópias vendidas de cada um desses jogos (dados reais vazados da Steam). Faça o download do ebook gratuitamente no botão abaixo: