Documentando um projeto
Há um mês atrás na Campus Party, levantou-se uma pergunta que é provavelmente uma das questões mais relevantes quando vamos tratar de Game Design. A pergunta foi algo assim: “estou começando um projeto independente com um amigo e não sei como começar a documentar o projeto. Você tem algum template para me passar?”
Apesar de parecer uma questão simples, tem muita coisa que podemos tirar de informação da resposta para ela. O principal, e algo que eu sempre digo, é que o GDD (Game Design Document) como uma “bíblia” do jogo, está em extinção, ainda existem empresas que usam, mas são poucas, e podemos considerá-las até atrasadas, já que uma “bíblia” é provavelmente a maior perda de tempo que um game designer pode ter durante um projeto. Um jogo no planejamento nunca vai ser o mesmo jogo no desenvolvimento e ao final do projeto as chances da sua “bíblia” não refletirem mais nada do que é aquele jogo, são muito grandes.
Mas então como documentar? Essa é a grande questão. Isso tudo vai depender de empresa para empresa, estúdio para estúdio, mas minha sugestão é: documente tudo aquilo que você acha que poderá esquecer. A grande sacada da documentação é que ela é uma ferramenta para facilitar o desenvolvimento e não um problema para que ele aconteça. Não detalhe completamente todas as mecânicas, faça com que o seu documento seja direto e objetivo, sendo útil nos momentos em que surgir uma dúvida ao mesmo tempo em que dá a chance de novas soluções para problemas surgirem no momento do desenvolvimento, sem limitar ninguém.
A grande sacada está em saber onde parar de escrever sobre algo ou não, e aí não tem muita regra. O importante é treinar e tentar perceber até onde uma informação documentada pode ser útil no futuro ou vai ser simplesmente um limitador, ou até algo que não vai acontecer.
Concluindo esse pensamento, o GDD tem como principal função guiar o projeto, ser um facilitador e uma fonte de inspiração para o desenvolvedor no momento em que ele está com a mão da massa. O game designer precisa entender que essa documentação será ferramenta importante para que o jogo saia na qualidade esperada e, portanto, menosprezar essa documentação também é uma falha gravíssima, assim como perder todo o seu tempo escrevendo informações que serão modificadas ou tão detalhadas que nem serão consultadas.
cateogories: Game Design
Erik VInicius
February 17, 2011 at 12:39
Olá…
Eu creio ter sido o questionador da campus party e agradeço
ao post, pois estamos para criar o documento de design semana
que vem.
Vlw pela dica!! ^^
LimaJunior
February 17, 2011 at 12:52
Legal!
er… onde está a parte do post com o link para o donwload do template ? (bla bla bla Whiskas sache bla bla bla Whiskas sache , rsrsrs)
Rubens Brilhante
February 17, 2011 at 13:42
Não pode escrever muito, mas também não pode escrever pouco.
Não tem regras. Cada caso é um caso.
Tem que saber o que vai ser importante e o que não vai ser.
Escrever um GDD não é pra qualquer um.
Mas escrever um GDD bíblia é mesmo algo tão ultrapassado?
Achava que as empresas meio que exigiam um documento bem detalhado.
Principalmente para o projeto ser aprovado e verificar se o resultado está condizente com o planejado.
E como vão prever os custos do projeto?
Como faz esse controle sem um documento bem detalhado?
Isso não faz parte do papel do GDD?
Leonardo Garcia Fischer
February 17, 2011 at 13:53
Essa regra devia ser seguida não só no desenvolvimento de jogos, mas no desenvolvimento de muitos softwares de pequeno e médio tamanho. Já vi cada documento descrevendo detalhes inúteis que desanimava documentar as coisas importantes.
Henrique Vilela
February 17, 2011 at 14:12
Gostaria de compartilhar com o pessoal um GDD de exemplo, criado pelo Luiz Alessandro que é professor do curso de pós-graduação em Arquitetura e Desenvolvimento de Jogos Digitais.
Ele descreve um jogo fictício chamado Anti-Invaders e pode ser usado como base para a griação de outros GDDs.
http://abrindoojogo.com.br/wp-content/uploads/2010/06/gdd_anti_invaders.pdf
Nada a ver com o post, mas não tive como não notar na foto:
Saudoso Grim Fandango!
Artemis
February 17, 2011 at 17:09
@Rubens Brilhante
Você levantou uma questão bem interessante. Existem sim GDDs que são usados para vender projeto esses sim são usados para medir prazos e valores, mas mesmo eles nem sempre precisam ter um detalhe muito a fundo. Não vai fazer tanta diferença você saber que o jogo terá 3 mundos com 3 fases cada ou dizer o que cada mundo detalhadamente tem (salvo exceções muito grandes).
No final, muda muito mesmo de empresa pra empresa, e estúdio para estúdio. Essa dica pode acabar indo mais para desenvolvedores indies ou empresas pequenas que se utilizam de outros formatos para vender seus jogos. Mesmo assim é algo que o game designer tem que manter sempre em mente, escrever mais ou menos pode significar o sucesso ou não do jogo.
Felipe Menezes
February 17, 2011 at 19:09
Meu projeto recente eu tinha uma idéia original mas sem a mecanica, que deu surgiu depois e então foi ai que comecei de fato a produzir o game. Durante a produção algumas adaptações e o mais interessante inovações. Muita coisa mudou por causa da mecanica do jogo.
Mas algumas idéias de animações e etc ficaram de fora na versão beta, por questão de prazo.
Então percebi que o ideal é fazer um roteiro por alto com a mecânica do jogo, mas não encher muito porque talvez muita coisa pode ser cortada ou adaptada.
Dêem uma olhada no game : http://migre.me/3TMjq
Fernando Secco
February 24, 2011 at 03:08
Discussao legal essa.
Queria so comentar que quanto mais detalhado e preciso for o documento menos flexivel ele se torna. Pouca documentação também é ruim pois pode deixar muitos furos no design. Acho que a
melhor prática é ter um overview da features com os detalhes mais significativos do gameplay. Se for muito detalhado pode acontecer de algo passar despercebido e ser dificil de mudar mais tarde e, na maioria dos casos, ser impossivel refatorar (devido as deadlines). Temos sempre que lembrar que o gamedesign é uma das partes do jogo. Informacoes como cores, som, efeitos não fazem sentido nesse documento, mesmo quando o documento é uma e
proposta. O foco desse documento deveria ser o que o game design espera do jogo do ponto de vista do design pois o designer não define o jogo ele ajuda a compor o jogo.
Rafael
February 24, 2011 at 10:13
GDD grande e detalhado serve mais pra QA do que pra desenvolvimento. Como o Secco falou, GDD detalhado tira a flexibildiade, o que no nosso ramo eh passagem pro fracasso. O GDD deve ser tao detalhado quanto o TIME precisar pra trabalhar e no formato que seja mais conveniente pra todos. Alguns usam wiki, outros usam post-its colados num quadro, outros usam paginas e paginas com listas em bullet-points.
Nenhum documento substitui a presenca e imput direto e frequente dos game designers JUNTO com os programadores, artistas, sound designers, etc… Um game designer que escreve um documento enorme e joga na mao do time nao pode ser considerado o designer do jogo.
Resumindo pra finalizar. O GDD deve servir pra AJUDAR o time e tornar o projeto mais agil e coeso. Pra isso nao existe formula magica, cada estudio aprimora seu jeito de trabalhar de acordo com o time que tem. Qualquer coisa fora disso vai contra o proposito do documento.
Valeu ai =)
Gilliard Lopes
March 8, 2011 at 02:34
void JabaNaCaraDura(bool semVergonha = true)
{
A discussão aqui estava tão boa que decidimos fazer um episódio do PodQuest inteiro sobre o assunto: http://www.doublejump.com.br/archives/2243. Convido a todos para ouvirem e continuarmos essa discussão!
}