3.3 - Game Design Document - GDD

Com certeza, o documento mais controverso do processo de Game Design. E nem é culpa dele! O problema acontece porque se tem uma visão deturpada do que é e de como se inicia a construção de um GDD. Tradicionalmente, designers iniciantes sabem que precisam construir um GDD para fazer um bom jogo e querem pegar um modelo pronto, no qual só precise inserir as informações do seu jogo e tocar a vida.

Só que não existe modelo, lembra? Os designers novos são como Jon Snow: não sabem nada (ainda).

Primeiro, é necessário entender porque precisamos de um GDD. Existe um ditado na administração que diz mais ou menos assim: você só controla o que consegue medir. Ora, se não existisse nenhum tipo de documentação, como a equipe de design poderia ficar a par de tudo que está ocorrendo na construção do jogo? Com certeza seria algo digno de entrar na lista dos trabalhos de Hércules! A ideia do GDD é prover uma ferramenta que possibilite aos designers uma visão ampla do que está acontecendo e sendo produzido, de modo a garantir que essa visão seja respeitada.

No GDD, todas as informações vistas nos documentos anteriores estarão presentes, de forma bem detalhada. Além disso, toda a motivação para criação do jogo, detalhes sobre o mundo virtual e seus personagens, inimigos, objetos e mecânicas devem estar descritos de forma completa, com exemplos visuais desde a fase conceitual até os modelos finais do jogo. Se existirem vários modos diferentes de jogabilidade (um jogador, multijogador), uma descrição completa para cada um desses modos deve ser efetuada. A ideia é que o GDD descreva o jogo por completo!

Uma prática comum é colocar uma seção contendo o histórico de revisões do design, explicando as principais mudanças entre as várias versões que foram produzidas ao longo do desenvolvimento do jogo. O objetivo é que a equipe de design possa aprender com o processo, mas às vezes é difícil perceber as nuances das mudanças enquanto elas estão ocorrendo. Com o registro dos fatos no GDD, a equipe pode estudar e compreender porque determinadas direções foram seguidas, porque elemento X não deu certo no jogo, porque elemento Y precisou ser balanceado, e por aí vai!

O GDD normalmente é um documento grande, eu diria mais que isso, enorme! Possui, em média, duzentas páginas.

Só para vocês terem uma ideia, um modelo fornecido por Chris Taylor, o qual pode ser visto neste link: http://www.runawaystudios.com/articles/chris_taylor_gdd.php), possui 22 páginas. Ele é maior do que muitos documentos conceituais e não existe nenhuma informação preenchida! Esse GDD, por sinal, é um bom ponto de partida, pois contém seções genéricas suficientes para descrever múltiplos jogos. Mas não deve também ser seguido ao pé da letra, por isso fique à vontade para modificá-lo de acordo com a sua necessidade. Se o seu jogo for voltado a desafios em forma de puzzle, por que não uma seção contendo a descrição de todos os puzzles, a ideia por trás dele e os passos da solução? Foi o que o pessoal do jogo Grim Fandango fez!

O GDD é um relatório técnico, e isso implica em uma série de cuidados a se tomar no momento de sua construção. A linguagem deve ser objetiva e clara para evitar ambiguidades e frases com dupla interpretação. Sempre que necessário, deve-se utilizar referências a fontes externas e construir apêndices com sumários e listas de todos os recursos do jogo, como uma lista de itens, armas, monstros, equipamentos, etc.

Claro que a ideia de se construir um GDD como um documento físico não é mais adequada, devido à quantidade de informação presente a consulta a um documento tradicional seria trabalhosa, e quanto mais específica for a informação, mais difícil seria de encontrá-la. Por isso recomenda-se o uso de ferramentas que facilitam a estruturação do documento, principalmente com relação à sua navegação. Atualmente, utiliza-se bastante a ideia de documentação web, principalmente com o uso de ferramentas como o Wiki. Você com certeza já usou a Wikipedia para estudar para uma prova, não foi? Não se preocupe, fica só entre a gente!

O uso dessas ferramentas ganhou força na produção de GDDs por três motivos: facilidade de acesso, facilidade de navegação e capacidade de manutenção.

Como o documento está disponível através da rede (seja uma rede interna da empresa ou na internet), basta ter acesso ao sistema para visualizá-lo, tornando a sua distribuição muito mais fácil do que o envio de documentos físicos ou digitais. Outra vantagem refere-se à possibilidade de criar um dicionário de termos específicos e páginas de informações sobre eles. Logo cada mecânica, nível e recurso do jogo terão páginas de informação próprias, que poderão ser acessadas diretamente por links ou por uma busca direta na ferramenta. Esse formato de navegação web torna a busca por informações específicas no documento muito mais simples e permite que vários formatos de mídia suportados de forma padrão pela plataforma web sejam utilizados para informar sobre os itens do jogo (imagens, vídeos, minijogos web, etc.).

A vantagem na capacidade de manutenção do documento é um ponto crucial para o GDD: ao se realizar uma alteração no documento online, ela fica imediatamente disponível para os outros membros da equipe. Não é necessário nenhum procedimento de reenvio de arquivos corrigidos nem reimpressão de documentos. Essa solução, além de prática, se torna bastante econômica!

Veja alguns exemplos de como é fácil organizar informações de um jogo através de wikis:

Ambos os exemplos apresentados foram construídos a partir do projeto Wikia, que permite a construção de wikis de forma online, sem a necessidade de instalação de um servidor local. O link desse site é: http://www.wikia.com/Wikia. Existem também outras soluções de ferramentas wikis para serem usadas de forma interna, como o MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) e o DokuWiki (https://www.dokuwiki.org/dokuwiki# ).

Além da documentação do GDD, pode ser necessário o uso de outras ferramentas para estabelecer a comunicação entre a equipe e a administração do fluxo de tarefas. Isso pode ser feito a partir de um escopo macro (projeto como um todo) ou interno em cada equipe. Não vamos entrar em detalhes acerca dessas ferramentas, então deixarei aqui algumas informações como recomendação de estudo: o Trello é um sistema que permite a criação de notas ou tickets, de forma que pode ser usada para a criação de tarefas a membros de uma equipe. A gestão do ciclo de vida das tarefas é feita de forma manual, então se o seu projeto for maior, recomenda-se o uso de uma ferramenta mais robusta para gestão de projetos, como o Redmine.

Confiram alguns modelos de GDD!

E ficamos por aqui com a nossa documentação! Espero que agora vocês já tenham um pouco mais claro em suas mentes a importância de se escrever esses documentos, mesmo que por vezes essa seja uma tarefa cansativa. Mas são os sacrifícios necessários para se fazer um jogo de qualidade, afinal, ninguém disse que fazer um jogo seria fácil!