Saludos lupinos.
Seré breve: ando mal de tiempo, muy mal con el trabajo y contento con mi familia.
Pero no os escribo para contaros mi vida, sino para compartir con vosotros otra traducción. En esta ocasión es la traducción de una entrada del blog de Radical Poesis Games, referente a los documentos de diseño. Como siempre, mi traducción es libre como la vida misma, pero he intentado mantener el contenido intacto. La verdad es que no estoy totalmente de acuerdo con todo lo narrado, no al menos en la forma en que dice algunas cosas, ya que creo que pueden dar pie a confusión. Sin embargo si que lo estoy con la mayoría del contenido. Como ya comentamos hace algún tiempo, en lo referente a documentos de diseño, cada maestrillo tiene su librillo.
Espero que os sea útil, o al menos tan interesante como me lo ha resultado a mi.
Muchas personas no diseñan sus juegos por escrito. Lo mantienen todo en su cabeza o simplemente hacen el juego a medida que avanzan. Eso no tiene porque estar mal, pero algunos juegos son demasiado grandes para eso, y otros toman tanto tiempo que olvidas parte de lo que tenías pensado. Si tienes un equipo de desarrollo, un documento de diseño ayuda a todo el mundo como una fuente de referencia. Es por esto que pensé en explicar como escribir un documento de diseño.
Algunas personas piensan que escribir las cosas es restrictivo, pero no comparto esa opinión, creo que me hace más creativo el tener todas las ideas escritas delante de mí, en lugar de tratar de hacer las cosas conforme las voy necesitando. Tampoco consiste en diseñar el juego una vez y hacer el juego sin editar el documento de diseño, este documento normalmente cambia conforme avanza el desarrollo del juego.
MEDIA
El formato realmente no importa, pero yo encontré muy útil una Wiki, porque puede ser editada muy facilmente y porque puede ser compartida online con otros miembros del equipo.
Las dos mejores que he encontrado han sido MediaWiki (el que usa Wikipedia) y DocuWiki. DocuWiki tiene la ventaja de que no requiere una base de datos MySQL y funciona completamente a través de archivos de texto, con lo que puede ser utilizada en servidores gratuitos sin soporte para bases de datos. También existen Wikis que pueden ser instaladas en disco duro, pero las encuentro menos útiles porque normalmente trabajo online con otras personas.
FORMATO
Yo recomendaría utilizar el documento de diseño principalmente para “listas” – el tipo de lista varía según el tipo de juego, pero a menudo incluye una lista de enemigos, una lista de personajes jugables, una lista de áreas o niveles, una lista de temas musicales que necesitará el juego y así consecutivamente. Normalmente un documento de diseño es aproxímadamente un 80% listas y un 20% descripciones del juego en general.
Cada ítem en una lista; por ejemplo una lista de enemigos, no puede simplemente enumerar sus nombres y punto. También debe describirlos en cierto grado: como se mueve, estratégias que el jugador puede utilizar en su contra, lugares donde aparece, etc. Normalmente uno o dos párrafos son suficientes.
También es importante pensar en la idea general del juego, que está tratando de conseguir e incluir unas cuantas secciones al respecto.
LONGITUD
La longitud del documento de diseño varía según la complejidad del juego; he escrito documentos de apenas unas páginas, y otros de cientos de ellas. Intenta incluir suficiente información sobre algo de forma que cuando tengas que codificarlo o dibujarlo, puedas tener una buena idea de como hacerlo, pero no tan detallado como para incluir información innecesaria.
También es una buena idea hacer el juego y el documento de diseño más o menos al mismo tiempo. No pierdas unos cuantos meses haciendo el documento y después otros cuantos haciendo el juego, porque esto te volverá loco. Es mejor empezar con el prototipo del juego al principio, trabajar en él cada día e ir añadiendo información al documento de diseño durante el proceso de creación. Encuentro que es fácil caer en la trampa de solo diseñar y no trabajar en el juego, trata de evitarlo.
EJEMPLOS
Este es el documento de diseño del juego en el que estoy trabajando en este momento; está aún incompleto y contiene algunos spoilers por lo que si tienes intención de leerlo y probar el juego, puedes omitir las secciones de personajes e historia. De todas formas, el juego irá cambiando en el futuro, así que no tomes el documento como una representación exacta de como será el producto final.
Sin embargo, leyendo este documento puedes hacerte una buena idea del formato que yo utilizo y el aspecto que tiene un documento de diseño.
Aquí tienes otros dos buenos ejemplos de documentos de diseño:
– Documento de diseño de Planescape Torment’s
– Documento de diseño de Metal Gear Solid 2’sEstoy seguro de que hay muchos mas, pero estos dos son los mas interesantes que he leído.
UTILIDAD
El uso principal del documento de diseño es como manual para crear las diferentes partes de tu juego. Por ejemplo, cuando trabajas en un nuevo enemigo, tú puedes ir al documento y ver que quieres que haga el enemigo, aunque hubieras escrito eso hace 20 meses, y tener una idea exacta de como proceder, en lugar de comenzar sin un punto de partida. Esto no tiene porqué ser algo restrictivo, no te sientas como si tuvieras que traducir literalmente lo que dice el documento, este suele funcionar más bien como lo haría un esquema para una novela.
Tampoco lo utilices como un sustituto de una lista de “cosas por hacer”: seguramente necesites crear una por separado para todas las tareas que quieras hacer para terminar el juego, bugs que corregir, etc.
Otra gran utilidad de un documento de diseño es el poder compartirlo con otros miembros del equipo, tomar sus opiniones y cambiar partes de él tras discutir sobre el juego, tambiés sirve para mantener una visión compartida de como debe verse el juego. Es mucho más difícil si no hay nada escrito, porque los otros miembros del grupo pueden tener una idea totalmente distinta de como será al no tener ninguna referencia escrita.
A menudo el documento será más ambicioso que el resultado final si realmente quieres terminar el juego. Es fácil listar 100 enemigos y todas las ideas que tienes para cada uno, pero es mucho más difícil codificar su comportamiento o crear sus sprites, por lo que generalmente algunas partes del documento de diseño no se plasmen en el juego. Es cierto en los documentos de MGS2 y Torment documents above, y lo más seguro es que suceda en la mayoría de los documentos de diseño, así que no tengas miedo de “sobre diseñar” con la intención de solo incluir lo mejor del diseño en tu juego. Por ejemplo, no tengas miedo de escribir las descripciones de esos 100 enemigos y después solo quedarte con las 40 o 20 mejores ideas para el juego. No sientas que un juego solo esta completo si contiene todo lo que dice el documento de diseño, puede estar completo si solo incluye la mitad de lo que dice.
About The Author
Hola, buenas, soy Dani. Mi hermano y yo ta tenemos blog, a ver si te pasas por ahí.
El documento de diseño es muy útil, y necesario sobre todo si el proyecto es en equipo. En él se va dejando claro todos los apartados del juego y se detectan muchos errores e incongruencias.
Lo de que sea público aún no lo entiendo, sobre todo para según qué juegos. No me imagino un juego de suspense con un documento de diseño público.
Personalmente uso un documento de texto donde describo el género y estilo, la sinopsis, la mecánica de juego y los sucesos clave. También lo utilizo para desarrollar los personajes y su trasfondo, e ir cuadrando edades.
Dices por ahí que no estás de acuerdo con algunas cosas, ¿cuáles son?
Un saludo.
Guay, voy a ir echandole un vistazo a vuestro blog. 🙂
Yo el documento lo hago un poco mas en vuestro plan. Hace algun tiempo dedique tres entradas al tema, pero para mi hay cosas como la mecanica que deben de estar definidas desde el mismo documento de diseño, pero que no se mencionan aqui. De todas formas, en el caso de este articulo, hay cosas en las que, mas que no estar de acuerdo, con lo que no concilio es con la forma en que lo explica, ya que da pie a confusion. Veras, en el mismo articulo menciona como no recomienda tener hecho antes el documento, invitando al lector a ir haciendolo conforme el juego va siendo creado. Es una verdad a medias. El documento es cierto que evoluciona y se modifica a lo largo del desarrollo, pero no concebirse sobre la marcha.
Hay detalles, como el transcurso de la historia, su flujo o la distribucion de las escenas, que si no los tienes definidos claramente desde el principio (aunque despues lo modifiques) repercuten directamente en el devenir del proyecto. Hay cosas que no se pueden ir creando sobre la marcha porque implican una refactorizacion o una duplicacion del trabajo enorme. Lo que tiene una repercusion aun mas importante cuando se trata de trabajar en grupo, ya que minas la moral de la gente, pierdes tiempo y desperdicias parte del trabajo.
Tambien es preciso tener una idea general lo suficientemente definida en el documento como para ser capaz de estimar un tiempo aproximado de desarrollo y el personal necesario para llevarlo a cabo (aunque lo tengas que multiplicar por dos, teniendo en cuenta los futuros imprevistos).
En este caso habla de un supuesto de 100 enemigos diseñados. OK, deacuerdo, usemos solo los 20 mejores. Pero tambien tengo que ver cuantos tiles necesito, cuantos niveles he de diseñar, cuantos temas musicales necesitare… en resumen, cuantos ambientes he de recrear y con que personal y tiempo es posible hacer algo asi. Un documento de diseño es, como bien dice, un esquema, pero bajo mi punto de vista, tambien es una herramienta para estimar la magnitud exacta de un proyecto. Cuando imaginamos, tenemos la tendencia de llenar las lagunas de nuestro proyecto de “cosas bonitas” al igual que hace nuestra mente para dar coherencia a los sueños. Eso sin embargo, no sirve para un juego. Hay que saber donde estan realmente esos huecos y planear, aunque sea de forma somera, que es preciso meter dentro para que todo el proyecto en su conjunto tenga la coherencia necesaria.
Sea como fuere, me consta que el redactor escribe bastante mas del documento de diseño antes de empezar a programar de lo que se podria llegar a pensar con una primera lectura. Tambien entiendo su aviso con respecto al “over design” frente al trabajo real (el prototipo es necesario para ver si funciona el diseño), pero mi aviso a este respecto seria no tomarse este aviso como un “voy haciendo el documento conforme programo el juego” porque si bien se puede (y debe) ir modificando sobre la marcha, si que es preciso gastar un tiempo en hacer un primer documento de diseño, aunque sea bastante “light” antes de comenzar a trabajar. No hay porque gastar un año, porque como bien dices, te puedes perder el norte, pero tampoco pasa nada por dedicarle un mes, porque todo lo que planifiques al principio, no hara mas que acelerar el desarrollo y dar coherencia al producto final. Sobre todo si tu juego es comercial porque para calcular si te puedes permitir pagar a tus colaboradores, necesitas tener una estimacion previa basada en un documento de diseño. Lo mismo para el tiempo de desarrollo e incluso el estilo y ambientacion de tu juego. En este caso ni tan siquiera se habla de un estudio previo de mercado, que lo creamos o no es fundamental. Los documentos de diseño tienen tambien una parte conceptual de la que no se habla en este articulo, en la que se explican no solo detalles como la mecanica, sino cosas como porque ese genero o las fortalezas de tu proyecto conforme a lo que ya esta en el mercado. Ojo de nuevo, que este hombre si que sabe hacer un buen plan de marketing. Lo se porque le vengo siguiendo la pista. Otra cosa es que no hable del tema en este articulo o bien para no extenderlo demasiado o porque siga otra metodologia diferente. No se, quizas el deja esa parte en su mente, o crea un documento puramente conceptual… ni idea.
Resumiendo, que me parece un articulo genial, del que yo saco algunos datos bastante buenos, pero del que matizaria algunos detalles, sobre todo si el que lo lee no ha redactado nunca un documento de diseño.
Perdon por la redaccion y el triple post. Acabo de descubrir que existe un limite en la longitud de los comentarios XD
Jaja, joder, me he leído todo tu comentario.
No sé hasta qué punto hay que ser tan estricto y darle tanta importancia al documento de diseño, si a desarrollo de juegos amateur (y modestos) nos referimos. Está claro que es útil cuando se trabaja en equipos grandes y si tienes la esperanza de comercializar el juego en un futuro, ya que puedes estimar todo eso que has dicho, entre otras cosas, el tiempo de desarrollo y costes.
De todas formas, ajustar tus proyectos al tiempo e ideas que el mercado exige no es más que limitar tu creatividad. Eso sería aceptable para las compañías modestas que pretenden vivir de esto, no les queda otra, pero no lo recomiendo a la gente que está empezando o que tiene todo esto por un hobby.
Es un tema complejo, y cada cual que haga lo que vea oportuno. Mi opinión es que por delante de todo esto del documento de diseño y el estudio de mercado, está la creatividad y la calidad.
Un saludo.
Claro, todo esta en en como te lo tomes. Si te da igual el tiempo que vas a tardar en desarrollarlo tampoco es tan importante. Sin embargo, aunque lo hagas a nivel amateur, no esta de mas tener en cuenta que tambien te sirve para calibrar la magnitud de lo que quieres hacer y ver si realmente eres capaz de terminarlo o estas dispuesto a dedicar tanto tiempo.
Por eso viene bien “perder” un tiempo en hacer un documento de diseño que contemple el proyecto en su conjunto, aunque sea un poco a modo de esbozo.
Al menos eso es lo que he ido observando yo. Tambien puedo estar equivocado, al fin y al cabo tampoco es una ciencia exacta.