Game design document: Criando um GDD

Hoje vamos falar sobre uma das partes mais importantes (se não a mais importante) na criação de um jogo digital. Vamos falar da documentação, o famoso GDD.

GDD significa Game Design Document e é uma parte vital do planejamento e desenvolvimento de qualquer jogo. Como não existe um padrão da indústria, existem muitas maneiras de criar um e isso torna a criação do seu primeiro GDD um processo difícil, cheio de possibilidades e incertezas. As necessidades do seu documento provavelmente também mudarão entre projetos, plataformas e clientes. Eu tenho o meu próprio modelo de GDD,  vou disponibilizar ele no final do post, mas talvez no futuro possa fazer um vídeo e outro post sobre ele na integra, explicando cada seção criada. Mas em linhas gerais, hoje quero falar sobre como iniciar o seu GDD. Com isso dito, aqui estão alguns passos que servem como um guia ou coringa, e que podem ajudar você a escrever um GDD também. 

Comunicando ideias de forma atrativa

O livro de Scott Rogers, Level Up! O Guia para um ótimo design de videogame afirma que “… mesmo que escrever um GDD leve muito tempo e esforço, ninguém da sua equipe deseja lê-lo” (Rogers 85). Então, como os designers lidam com isso? Rogers sugere o uso de diagramas, storyboards ou desenhos para comunicar ideias e despertar interesse, que são ótimas opções.

Também recomendo o uso de subseções em todo o seu GDD que são personalizadas para funções individuais. Imagine, por exemplo, que você esteja criando uma nova IA inimiga. Como projetista, você deve comunicar à sua equipe como esse inimigo se comporta, onde ele gera um nível, o que soa quando ele ataca e assim por diante. Isso é tudo relacionado à programação. Você também precisa descrever que tipo de vibração ela transmite através de sua linguagem corporal e esquema de cores, detalhar qualquer efeito de partícula e considerar quais ações ela executa que precisam ser animadas. Isso é coisa para o artista. Os artistas não precisam ler todo o jargão técnico e os programadores não precisam se preocupar com a forma como um ativo será desenhado. Minha solução é escrever as duas seções separadamente usando os prefixos “Para o programador:” e “Para o artista”.

Brainstorming

Leve em consideração uma seção para o brainstorming para marcar pensamentos e discussão nas reuniões da equipe. Todos os membros da equipe são ativamente incentivados a revisar e adicionar ideias (e a todas as outras seções do GDD). Isso ajuda os designers a rastrear quaisquer problemas que ocorram à medida que o documento cresce e manter os dados claros e consistentes. Além disso, fornece ao designer um local para revisar comentários sobre o design do jogo antes das reuniões do grupo e procurar preventivamente soluções. Este é um lugar para lançar toda e qualquer ideia que a equipe pense. Sempre haverá maneiras de melhorar seu jogo e é importante tirar esses pensamentos da cabeça e colocar no papel, mesmo que nem sempre haja tempo ou nem sempre haja recursos para implementá-los. Prefiro manter isso como seu próprio documento e depois transferir as ideias assim que a equipe concordar com elas, mas esta seção também pode encontrar um lar dentro do GDD.  

Relatório de erro

Um GDD reúne informações importantes necessárias a todos os membros de uma equipe de desenvolvimento em um único local. Ter dezenas de documentos espalhados por várias pastas, mesmo quando feitas com cuidado, pode se tornar difícil de rastrear. Ao mesmo tempo, sobrecarregar o GDD com cotão e enchimento significa que os colegas de equipe gastam um tempo valioso de desenvolvimento percorrendo blocos de texto de design desnecessário. Há um equilíbrio delicado a ser atingido. Dito isso, pode fazer sentido rastrear seus bugs em outro lugar, mas dependendo da demanda do estúdio, é legal localizá-los no GDD.

Enquanto os programadores serão os que corrigem os erros, eles não serão os únicos a encontrar os erros. Designers ou artistas podem encontrar maneiras de resolver bugs que exigem menos tempo e esforço do que uma correção definitiva. Colocar o Relatório de Bug no GDD aumentará a chance de seus colegas de equipe verem as alterações observadas lá enquanto procuram instruções para fazer seu próximo recurso ou recurso.

Visão geral do jogo

A seção de visão geral do jogo é um local para fornecer uma visão geral de alto nível do jogo, essencialmente uma extensão do campo original. Sobre o que é o jogo? Qual é a narrativa? Qual é o principal mecânico? Deve ser descritivo e direto. Os colegas de equipe sempre podem retornar a esta seção para garantir que a visão original do jogo esteja sendo respeitada (que também é o objetivo do documento como um todo).

Jogabilidade

Como a maior seção do GDD, este é o lugar para descrever como o jogo será jogado, se sentirá e se envolverá. Qual é o loop principal do jogo? Quais são as condições de ganhar / perder? Quais são as principais mecânicas? Descreva seu sistema de saúde, inimigos, obstáculos e os sistemas que os governam em detalhes. Inicie cada seção com uma breve descrição do mecânico ou do recurso, focada no designer, e entre em informações específicas sobre arte e programador.

Ajustando as variáveis

Estes são os aspectos do jogo que podem ser ajustados para mudar a experiência. Estes são obrigatórios para qualquer documento de design. Eles podem ser sua própria seção ou incorporados à seção de jogabilidade.

Referências e Inspiração

Ter um conhecimento geral sobre videogames e outros assuntos, é importante para comunicar ideias aos seus colegas de equipe. Ajuda a ter um ponto de referência comum para qualquer conceito em discussão, especialmente porque a terminologia na comunidade de desenvolvimento de jogos ainda não está totalmente de acordo ou padronizada. Algumas pessoas chamam isso de juice, algumas dizem o game feel, outras ainda usam o termo feedback. De qualquer forma, se todos do seu time entenderam o ponto. A referência não apenas a outros jogos ajuda a criar uma terminologia comum (ou a superá-la), mas os colegas de equipe podem apontá-los para fazer referência ao estilo, música, humor ou escopo da arte. Todas essas coisas se tornam mais concretas quando há um ponto de referência comum.

O log de alterações

Esta seção do GDD, na parte inferior, é usada para rastrear alterações no próprio documento, incluindo adições, subtrações e alterações. Isso ajuda os designers a se lembrarem de quais questões já foram levantadas, consideradas e tratadas. Sem esse log, é fácil esquecer se determinados recursos foram testados ou se determinadas soluções foram implementadas. Pode não parecer que você esqueceria uma solução que já tentou, mas após meses ou mesmo anos de desenvolvimento, torna-se cada vez mais provável. Isso também pode servir como uma maneira confiável de restaurar iterações mais antigas do seu jogo, se necessário.

Conclusão

Essas ainda são apenas algumas das seções que você pode inserir no seu GDD, pois muitas delas dependerão de você, sua equipe, seu projeto e seus investidores. Sempre há mais inspiração, se você precisar, veja vídeos, leia livros e artigos. Abaixo um modelo básico usado por nós da evertalegames.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *