[Postmortem] Paul Hero: EPN! – Game Design Document

 Otro mes con postmortem de Paul Hero: End Polio Now! aprovechando que aún lo tengo fresco en mi cabeza. Lamentablemente no vi mucho interés de que haga algo más «visual» (en video) sobre algunos aspectos pero sí en escrito…por lo que me gastaré en esto que me resulta más cómodo (toda la flojera de hacer las dos cosas). Esta vez el tema a tratar es como encaré algo que considero esencial actualmente, sobre todo si hay más de 2 personas en el proyecto: Game Design Document (GGD).

 Hasta la actualidad he realizado tres GDD completos, siendo el último uno del proyecto que estoy actualmente programando (Momo Space, que está en pañales), además que también estoy asesorando sobre otro proyecto de Crios Devs llamado Grammar Zombie. No es para sacar «chapa», sino para que se entienda de «que nivel hablo»…no he hecho cursos ni nada, más allá de conversar con otros desarrolladores, ver videos o artículos del tema y haber leído el genial libro «The Art Of Game Design«. No me considero un «erudito del diseño de mecánicas de juego», por lo que lo que expondré seguramente tiene errores de conceptos o que a futuro tal vez cambie de opinión.

 Mi intención no es explicar «que es un Game Design Document», sino dejar una lista de 5 cosas que he aprendido y aconsejo cuando se hace un GDD, no están en un orden de importancia pero me gusta enumerar cosas y se ve todo mas prolijo (puede ser un TOC que tengo).


1) No hacerlo en un primer momento

Tampoco es irse al carajo con el GDD

 Algunos recomiendan que antes de tocar la computadora o papel y tijera (en el caso de un juego de mesa) es que se establezca todas las reglas en un documento de diseño del juego y recién ahí empezar a incluir las cosas ¡NO LO HAGAN! La razón principal es porque seguramente en papel y su mente una idea parece genial, pero al momento de aplicarla no lo es…por lo que habrán perdido semanas (si es que no meses) haciendo un GDD cuyo contenido, la mitad, deberán eliminar.

 Lo que recomiendo es que definan que elemento es el principal de su juego (que no sea historia, hablo de mecánicas y jugabilidad) y luego hagan una Game Jam de «X» tiempo finito o que participen en una (Internet o presencial) y hagan un prototipo, a partir de ahí podrán definir algunas reglas basados en algo jugable. Recuerden: que tengan una linda receta, no quiere decir que la comida al menos sea digerible.

2) No hacerlo a último momento

Se que suena raro con respecto a lo que dije arriba, pero eso sería «otro extremo» y todos los extremos son malos. Yo cometí este error con Paul Hero, un proyecto que nos demoró un año y al cuarto mes recién había hecho el GDD debido a que todo se había hecho un desorden bárbaro de explicar y entender. Si hubiera hecho el documento al instante de tener algo jugable, no necesariamente completo, me hubiera salvado mucho tiempo de explicar una y otra vez que es lo que necesitaba del músico, de la diseñadora gráfica, del level designer y de mi mismo (si, yo hablo solo muchas veces…asusta de vez en cuando).

Actualmente el juego tiene 6 sectores, pero la idea original era tener 7. Si hubiéramos hecho un GDD más al principio, habríamos notado que se hacía extenso. Gastamos tiempo e hicimos recursos sonoros y gráficos de más.

 Otra razón de porque no hacerlo a último momento es que ya hay cosa definidas pero «no sabes donde» y al cambiar un aspecto no sabrás como afectan al resto. Es mejor «más tarde que nunca», ya que permitió limitar algunas cosas del juego y que no se extendiera mucho más, pero no es lo recomendable. Estoy seguro que Paul Hero hubiera sido más pequeño como producto final, pero nos hubiera llevado la mitad de tiempo realizarlo.


3) Ser directos

 El GDD no es un libro narrativo ni debes contar todos los aspectos del juego, sirve para definir reglas y que tu equipo (o tus distintas personalidades, como es mi caso también) estén en la misma página. Todos deben saber de qué trata, cuál es su mecánica principal y poder definirlo en una oración…si necesitas más de un minuto para explicar tu juego, estas haciendo algo mal.

También es bueno saber, por más que le pese a tu orgullo, que casi nadie va a leerlo completamente a menos que lo hagas extremadamente útil y resumido. Al programador le interesa como se manejaran las interacciones y las reglas de juego, al diseñador gráfico como va a estar la interfaz del usuario, que referencias tener en cuenta y que se desea transmitir, etcétera. Ya demasiado deben hacer para el juego como para leer 20 hojas que cuenten por qué decidiste X tema frente a otro.

Si tu juego tiene mucha historia y demás, hay que hacerlo en un documento aparte y referenciarlo en el GDD, lo mismo si necesitas explicar detalle del arte gráfico y sonoro.

4) No buscar la receta

Este aspecto es algo que muchos caen y que yo lo hice con el primer GDD que hice (para el juego Code-Man): empecé a comentar y escribir cosas que mi juego no tenía mucho que explicar (como el uso de la cámara, historia, diseño gráfico, etcétera) y al final atrasé el juego 2 meses solo por eso.

Sé que uno siente esa desesperación de no saber por donde empezar, como aquel aspirante a pintor que tiene un lienzo en blanco y nunca ha usado un pincel. Lo mejor es leer algunos GDD parecidos al tamaño del proyecto que están y luego ir buscando una estructura propia. Encarar un juego arcade de naves es muy diferente a un RPG, o uno dirigido a niños con otro a adolescentes. Anoten lo que crean importante por arriba y luego lo ordenen poco a poco, solo vale la pena explicar lo que tu equipo (o vos mismo) necesitan definir.

5) El GDD está vivo

Algo muy importante sobre la definición de lo que es un Game Design Document es que está vivo (no, no va a robar sus almas), lo que quiere decir es que constantemente se va a modificar. Si esperan que el documento les quede perfecto y luego nunca más lo van a tocar, están equivocados…y si lo hacen, será lo mismo que nunca haberlo hecho.

Muy pronto mi cerebro hará esto.

Como dije más arriba, todo puede parecer genial en la cabeza de uno pero al implementarlo es otra historia. Hay cosas que van a eliminar y cambiar durante el desarrollo del juego, no crean que «se les quedará en su cabeza y fácilmente se acordarán», nuestro cerebro es el peor disco duro que existe (el mio principalmente, por poco mis ojos muestran la pantalla azul de la muerte).

Sé que da flojera pero es algo que se va iterando hasta que no necesitan mas explicaciones sobre un aspecto del juego, obviamente hay cosas que al final no estarán en el producto final aunque sí en el GDD (o viceversa), pero serán detalle a último momento.

Conclusión

Hay muchos que odian los GDD y es verdad que en proyectos chicos (realmente chicos, no los «que creen que son chicos» y luego tardan meses en terminar) no hace falta o cuando uno está aprendiendo, pero cuando se integra gente al equipo y hay varios aspectos que necesitan recordar se hace muy útil. Personalmente no me gusta ser estructural y documentar todo antes de hacer algo como muchos desarrolladores de Norteamérica, sino más parecido (no igual) como los orientales que experimentan aspectos que quieren incluir en un juego y a la par van documentando lo que consideran importante. Espero que esto le sirva a alguien, por ahora…Saludos y Game Over.