GDD: quando, onde e como
Game Design Document, ou GDD para os íntimos, ainda não é um consenso entre todos os desenvolvedores, acadêmicos e alunos de jogos. Algumas equipes usam de um jeitos, outras de outro, outras não usam, e muitos acabam ficando perdidos entre as várias padronizações conflitantes.
Sem nenhum consenso ou pretensão de defini-los, vamos falar de GDD.
Para perceber a misticidade que ainda ronda o GDD não é só a quantidade de posts que saem toda a semana afirmando trazerem o “formato de GDD definitivo”, mas também a quantidade de pessoas perguntando qual a importância do GDD em um jogo e qual o formato usar. Ou qual o formato eu uso. Ou pedindo para ler um GDD meu. Então, abram bem os olhos para ler isso que vem a seguir bem certinho.
Acontece, meus queridos, GDD definitivo não existe.
Absorveu? Espero que sim. É impossível traçar uma regra geral sobre o quão importante ou irrelevante é um GDD para todos os jogos e videogames a serem feitos. A resposta se torna exponencialmente mais complexa quando se prolonga em definir um formato ideal. GDD depende de um milhão de variáveis, desde o tipo e extensão do jogo ao o que funciona melhor para equipe.
#comofas GDD?
Qual a função do GDD? A única e grande função dele é servir de guia de desenvolvimento do jogo para que todo mundo esteja na mesma página durante o desenvolvimento. Imagine um jogo como uma estante da Tok & Stok, o GDD é o manual que vem junto para te ensinar a montar.
O GDD não é um livro sobre estantes, não é um compilado das melhores estantes do mundo, não é um trato acadêmico da utilidade de estantes nem um livro narrativo sobre a vida de uma estante. Ele é o manual de montagem e só.
Como o manual de montagem, toda informação contida nele tem que ter uma aplicação direta e prática no jogo. Rever jogos do mesmo gênero que o jogo a ser feito só é relevante se essa revisão impacta diretamente nas decisões do jogo. Contar a backstory do personagem secundário só pertence ao GDD se em algum momento do jogo ela é revelada ou relevante, e ainda assim ela deve estar presente da exata forma que vai apareceu no jogo (há excessões, trataremos caso a caso).
Isso não significa que esses conteúdos adicionais não devam existir ou ser organizados em algum documento, se eles são importantes para o jogo e para a equipe eles podem e devem ser feitos. O ponto é que mesmo existindo, o lugar deles não é no GDD.
Por quê não documentar?
Cada minuto que você gasta documentando é um minuto que perde desenvolvendo. Parece simplista, mas é a pura verdade.
Documentar precocemente idéias que ainda estão sendo discutidas ou documentar em extensão assuntos simples também cria a tendência de solidificar um conceito ou feature antes da maturidade. Se alguém já escreveu 3 páginas sobre o sistema de level, por exemplo, todas as outras pessoas vão pensar duas vezes antes de propor um sistema novo, mesmo que melhor, já que a mudança envolveria jogar todo aquele trabalho no lixo. Faz parte da natureza humana, por mais que tentamos manter a mente aberta a mudanças, ninguém gosta de ver trabalho sendo jogado fora. Também faz parte da natureza humana ir aprimorando suas idéias com o tempo, aperfeiçoando a forma como as coisas são feitas o que em geral leva a um jogo melhor. Documentar cedo de mais, coisas de mais, barra ou atrapalha esse desenvolvimento natural.
Então pra quê sim?
Não documentar, por outro lado, tem consequências ainda piores, como informações importantes serem perdidas, esquecidas ou mal interpretadas, a mudança de escopo de projeto sem os próprios desenvolvedores perceberem ou ainda discussões desnecessárias aparecerem. O tempo passa, é normal resultados de discussões do começo do projeto não estarem mais tão frescas na cabeça e algumas informações já encontram-se misturadas com outras.
Logo, existe aí um difícil equilíbrio entre a quantidade de documentação necessária para cada projeto que não consuma mais tempo que o necessário e também permita que os membros da equipe trabalhem da melhor forma possível (mesmo que seja uma equipe de uma pessoa).
Já que não dá para definir, podemos ao menos explicar algumas dessas variáveis para ajudar você a entender qual é o seu caso.
Quando não
Toda vez que o manual de montagem não se faz necessário. Ou seja, se o desenvolvimento é muito simples e/ou curto, ou quando todo o desenvolvimento é evidente para todos na equipe. Mas quando é isso?
Em geral, quando a equipe e o jogo são pequenos o suficiente para não haver problemas de comunicação e de entendimento. Por exemplo, se você está trabalhando sozinho ou com poucas pessoas em um jogo que é um clone ou um experimento isolado de uma única mecânica, documentar o que deve ser feito parece e é redundante. Se o seu objetivo é fazer mais um clone de Flappy Bird só para testar seus conhecimentos em uma nova engine, para que se dar ao trabalho de documentar?
A duração do projeto também é essencial nessa escolha. Se é um projeto de um ou dois dias que será realizado sem interrupções, talvez documentar realmente não seja uma necessidade.
Mas se o projeto envolver modificações ou outras atividades ficarão no meio do desenvolvimento, cuidado para não superestimar sua memória! Realmente não vale a pena documentar ao menos o funcionamento geral e principais features?
Quando mínimo
Muitas vezes, mesmo quando o projeto é simples, alguma documentação se faz necessária. Uma estante simples talvez não precise de manual, mas uma estante que tem tábuas reguláveis ou que se encaixa de uma forma não convencional com certeza precisa de algo.
Por exemplo, em uma jam (ou seja, 48h a 72h de desenvolvimento) que você esteja em uma equipe. Mesmo sendo um jogo simples, alguma documentação é importante para:
- Todo mundo ter certeza que estão pensando no mesmo jogo: muitas vezes, mesmo que todo mundo parece entender exatamente a mesma coisa e concorde quando converse, cada um bolou na cabeça uma imagem muito diferente do que foi descrito com as mesmas palavras. Colocar no papel ou esquematizar em um quadro ajuda todo mundo ter a mesma imagem do trabalho a ser realizado.
- Não deixar dúvidas sobre o escopo de cada parte do jogo: Quando a gente fala "jogo multiplayer" parece que fica claro a quantidade de trabalho que vai estar envolvido. Mas não, essa terminologia geral esconde muitas particularidades que mudam completamente a quantidade de trabalho envolvida, como por exemplo se assíncrono ou simultâneo, se é local ou online, qual o tamanho das equipes, co-op ou competitivo, o tipo de jogo, engine, servidor, etc. Esse mesmo conceito "multiplayer" pode significar a diferença entre habilitar as teclas setas e AWSD ao mesmo tempo para dois jogadores dividirem o mesmo teclado (algo relativamente simples na maior parte das engines) e ter 20 programadores back-end fazendo um banco de dados por seis meses. E a quantidade de trabalho de cada parte do jogo não está clara, como dividir igualmente entre todo mundo da equipe e estimar a entrega corretamente? Isso é essencial em jams, por exemplo.
- Não esquecer particularidades e detalhes: "Ah mas com certeza eu vou lembrar disso depois", disse todo mundo ao ter uma idéia ou discutir e resolver um problema no começo de uma jam. Acontece que o cansaço, a correria e o tempo fazem nossa memória falhar ou distorcer algumas informações. Se elas estiverem documentadas em algum lugar fica muito mais fácil e seguro para todos, e evita discussões redundantes sobre coisas que já haviam sido acordadas.
- Acompanhar o andamento do desenvolvimento, saber o que falta e se vai dar tempo: isso é mais relacionado com a produção do que com o GD, mas depois que já sabemos qual é o jogo e quanto trabalho mais ou menos ele involve fica bem mais fácil acompanhar o que está feito, o que falta e se vai dar tempo. Se o jogo tem três features, já estamos na metade da jam e estamos debuggando a primeira, sem nem ter começado a segunda e terceira, chegou a hora de rever o escopo e cortar coisas. Como você percebeu isso ainda com bastante tempo de sobra, dá tempo para readaptar o jogo todo para essa mudança e ainda fazer uma experiência completa.
OK, então vamos precisar de alguma documentação. O que eu faço? Abro o processador de texto e escrevo tudo que me vem a mente sobre o jogo?
Não necessariamente.
De novo, isso depende muito da sua equipe e do jogo. 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.
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 pota-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.
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.
Quando médio
A abordagem da "uma página" não costuma funcionar tão bem em projetos um pouco maiores. Imagine uma estante retrátil, que vira uma mesa com bancos. O manual vai precisar de uma seção para cada uma das duas diferentes fases de montagem, uma seção para o uso cotidiano e manipulação da estante e talvez até uma seção para limpeza.
Em casos de equipes com mais de duas pessoas em projetos que vão durar mais de uma semana, é importante ter algo que contenha mais informações. E para ter mais informações, você vai precisar de um pouco mais de estrutura, como a divisão por seções.
Não, isso ainda não quer dizer que toda e qualquer parte relacionada ao jogo deve ser escrita, mas sim que todas as partes relevantes precisam estar documentadas e organizadas por tema de forma que seja fácil para qualquer pessoa encontrar mesmo que nunca tenha mexido no GDD antes.
Gameplay, Backstory, Sistemas, Audio, UI Flow são algumas das possíveis seções que o documento irá se estruturar ao redor. Ou não. Cada jogo é único e, enquanto o jogo em si não está pronto para provar isso, as categorias do seu documento devem ser a maior expressão da sua unicidade. Pense o que é mais importante para seu jogo e comece listando essas áreas. Essas áreas vão ser seus capítulos, cada capítulo pode ter sub capítulos.
Por exemplo, um documento de Super Mario Bros. possivelmente teria um capítulo sobre 1) Movimentação, 2) Inimigos, 3) Elementos do level, 4) Levels, 5)Limitações de gameplay e 6)Feedback sonoro e visual. No primeiro capítulo, seria descrito a movimentação do Mario, no que ela era semelhante a outros jogos plataforma da sua época e no que ela era diferente. No segundo, cada um dos inimigos seria descrito e como eles funcionavam. No terceiro, o funcionamento das estruturas do mundo como os buracos, os tubos, as plataformas que podem ser atravessadas ou não, destruídas ou não e a bandeira de fim de fase. O capítulo de levels daria uma intro de quantos mundos e quantos levels por mundo existem, mencionando as mudanças estéticas e de level design em cada um deles. O quinto capítulo falaria do sistema de vidas, de pontos e de tempo, ou seja, tudo que limita o jogador e adiciona dificuldade ao jogo que é externo ao level design. Por fim, o capítulo de feedback explicaria a musica e efeito visual de pegar uma estrela, os efeitos de morte, o som de pegar uma moeda, a aceleração da musica quando o tempo está acabando etc.
Esse documento inteiro poderia ter menos de dez páginas. Lembre-se, nesse caso não me importa a backstory ou os sonhos e motivações dos Goombas. Não me importa se ele é uma aberração genética criada no laboratório do Kamek e que se sente inseguro tendo em vista a quantidade de irmão idênticos ele tem. Me importa que ele se move da direita para a esquerda até colidir com algo e mudar de direção, que o jogador perde uma vida se Mario colidir lateralmente com ele e que ele morre se Mario pular em cima dele.
Quando bíblia
A bíblia, ao meu ver, é sempre sua última opção. Se você está em uma equipe de mais de cinco pessoas em um projeto que vai durar mais de um ano, realmente é difícil fugir de documentar cada aspecto do jogo.
A documentação aqui pode ser detalhada e completa, abordado cada aspecto de cada parte do jogo. Um cuidado importante é não documentar com profundidade até se ter testado e amadurecido cada aspecto do jogo para evitar consolidações desnecessárias.
O cuidado do teste enquanto há implementações somado com a extensão da própria documentação e da equipe envolvida com o desenvolvimento fazem desse tipo de documento um Leviatã gigante que está o tempo todo sendo construído, editado e modificado. Isso abre espaço para que outros membros da equipe visitem esse conteúdo enquanto ele ainda é Work in Progress e não percebendo isso assumam que a versão inacabada é o conteúdo final. Então sempre que estiver trabalhando em um projeto com GDD gigante, faça questão de deixar bem claro qual conteúdo ainda esta sendo trabalhado e qual já é definitivo e crie números para as versões do GDD. É importante que todos na equipe entendam isso e é sua obrigação ter certeza que todos dominem essas regras.
Tratamos aqui majoritariamente de jogos com foco em gameplay, mas se seu jogo tem foco em conteúdo, tem bastante narração e o desenvolvimento dos personagens é relevante ao gameplay em si do jogo, talvez esse seja seu caso. Backstory dos personagens não pertence ao GDD se não for relevante ao gameplay, mas se seu gameplay é baseado no storytelling a história deve estar no GDD sim. Mas não livremente como se fosse um livro feito em uma aula de escrita criativa. A informação narrativa do GDD deve estar organizada e hierarquizada em categorias para facilitar o acesso da equipe.
Mas pense bem antes de escolher ou acabar caindo nesse tipo de documentação. Lembre-se que cada hora gasta documentando é uma hora perdida desenvolvendo. É comum jovens que ainda estão pegando o jeito da coisa tentarem ser sucintos e acabarem com uma bíblia. É mais comum ainda esse jogo documentado nunca ser feito e esses jovens partirem para a documentação-bíblia de outro jogo. Cuidado para não perder o escopo do projeto, da equipe e do tempo que você tem. Mas isso também é outro artigo.
Sobre extensão e formato
Não existe exatamente um tipo de limitação de mídia e formado baseado em extensão e profundidade de GDD e uma recomendação geral é faça o que funciona para sua equipe. Mas essa recomendação é tão geral que pode fazer todo sentido ou nenhum, dependendo da sua experiência e da sua equipe. Então vamos falar mais específico.
Independentemente do tamanho do GDD, uma regra geral que funcionou em todas as equipes que eu já estive é: todos entendem mecânicas muito melhor com um gif ou uma esquematização visual do que com qualquer número de parágrafos que você jogue neles. Ver o funcionamento do que ler sobre ele é a diferença entre ver um animal, mesmo que só em um foto, e ler sobre ele.
Se você trabalha sozinho, um documento local, uma apresentação em ppt ou até um caderno ou folha de A3 podem ser uma documentação suficiente. Uma abordagem comum em jams é anotar coisas importantes em post-its e ir agrupando eles tematicamente, para ficar mais fácil entender a relação entre os elementos e tirar partes com mais facilidade.
Mas se você tem mais de uma pessoa na equipe, precisa pensar como todos os membros vão estar atualizados sobre a evolução e mudanças no documento. É por isso que o Google docs é tão popular entre desenvolvedores. Todos os membros da equipe, não importa o tamanho dela, tem acesso ao mesmo material e podem fazer alterações simultaneamente.
No GDD tipo bíblia é ainda mais importante a estrutura do texto e a forma do que em qualquer outro tipo. A quantidade de texto e material envolvido quase impossibilitam que você use um documento linear, tipo Word. Suas alternativas ficam entre montar uma wiki com uma página para cada assunto ou usar alguma ferramenta colaborativa digital (como Google Docs) e carregar nos links entre seções.
Então
Existem incontáveis formas de se fazer um GDD e nenhuma é certa e ou errada; tudo depende do escopo projeto e como a equipe se sente mais confortável. O GDD é uma ferramenta para ajudar no desenvolvimento do projeto e guiar sua equipe para a melhor versão de jogo possível. Se ele não estiver fazendo isso, está na hora de repensar essa relação.
