Documentos de diseño

Aunque en la etapa de preproducción se realizan muchos documentos de diseño, voy a hablar de los tres que son más relevantes en esta fase y que sirven para describir la evolución de la idea del juego, por llamarlo de alguna manera.

Si alguien tiene dudas sobre el proceso de creación de un videojuego, les remito a Game Over, el primer programa satírico sobre videojuegos, programa de radio y podcast en el que fanatiko tiene una sección llamada «Destripando la industria» donde habló sobre Las fases de desarrollo de un videojuego.

Su artículo es especialmente interesante porque la mejor visión posible es la de alguien que trabaja ya en la industria, porque aunque yo intentara hablar sobre ello, no sería más que un enfoque teórico, porque aún no he participado en ningún desarrollo.

Comenzando con el meollo, los tres documentos a tratar son el

1. Game Design Overview o One-sheet
2. Ten-Pager
3. Game Design Document o GDD

Todos tienen una serie de características comunes y es bueno tenerlas en cuenta a la hora de redactarlos:

• Concreción. Sobre todo en las versiones «técnicas» de los mismos, es decir, los que van orientados a tu grupo de trabajo.
• Precisión. Los documentos serán la información base con la que la gente trabajará y creará los contenidos. Cuanto más exacto mejor porque evitarás interpretaciones erróneas y eso ahorrará tiempo.
• Ameno. Mucha gente va a leer el documento, y si es un ladrillo, será pesado para los que lo tienen que consultar. Intenta organizarlo lo mejor posible y utiliza las herramientas disponibles, como índices, enlaces y listas.
• Bien escrito. Al igual que por la razón que el punto anterior, mucha gente terminará consultando tus documentos, y los fallos gramaticales o tipográficos pueden dar una sensación de dejadez o de falta de interés a la hora de redactar los documentos, así que revísalos.

One-Sheet

Como su nombre indica, es un documento que idealmente debe de ocupar una cara y tener la capacidad de ser atractivo, porque va a ser la carta de presentación de tu idea. ¡Y vas a tener solo una cara para expresar lo maravilloso que va a ser! Siempre va a ser insuficiente y hay una serie de datos que es más que recomendable que aparezcan, reduciendo aún más tu espacio. Tampoco es obligatorio hablar sobre los datos que comentaré a continuación, pero es una plantilla bastante buena.

• Título del juego
• Plataformas en las que estará disponible
• Edad objetivo
• Calificación por edades (PEGI y ESRB)
• Resumen de la historia
• Jugabilidad
• Unique Selling Points o USP. Es decir, qué hace especial a tu juego
• Competencia

Otra cosa importante sobre este documento es que, por lo general, no va a estar dirigido a una persona que juega habitualmente. Este documento, con el que pretender vender tu idea, estará leído por gente que tiene que invertir o por jefazos, así que intentar hacerlo lo más ameno posible será buena idea.

Ten-Pager

El Ten-Pager es la evolución del One-Sheet, si la cosa funciona como es debido, la idea debe de desarrollarse, en este caso, hasta que ocupe unas diez páginas, pero al igual que el documento anterior, si es posible que sea más escueto, es incluso beneficioso.

Como detalle y para posibles contingencias, no está de más que este documento tenga forma de presentación de diapositivas, porque si la idea gustó, probablemente la siguiente fase sea enseñar, en forma de pequeña presentación, por qué tu juego es el mejor en este momento prematuro y deben de invertir su dinero a lo loco en tí.

Pero un Ten-Pager más técnico para que tu grupo pueda comenzar a trabajar tampoco está de más, por lo que mi recomendación es hacer dos documentos (por suerte no son extensos) siendo uno más centrado a la venta de tu producto y otro más centrado a las características del juego.

Los apartados recomendados para este documento, y con una longitud de aproximadamente una página por cada uno son:

• Página del título
• Resumen del juego
• Personajes
• Jugabilidad
• Mundo
• Experiencia de juego
• Mecánicas
• Enemigos
• Cutscenes
• Material extra

Una regla que se aplica en este documento y en el siguiente es la regla de los tres ejemplos, porque los ejemplos son un gran aliado. Permiten explicar situaciones con todo lujo de detalles y la resolución de las mismas, permitiéndonos aclarar posibles puntos oscuros. Siguiendo con la regla de los ejemplos:

• El primer ejemplo da una idea al lector sobre la situación, pero puede que no quede claro.
• El segundo ejemplo nos permite comparar con el primer ejemplo.
• El tercero anula el efecto binario, y complementa los ejemplos anteriores.

¿Quiere esto decir que cada vez que hay que poner un ejemplo, debemos de invertir el espacio y la capacidad de atención del lector con tres? Evidentemente no, hay que saber cuándo utilizar esta técnica.

Game Design Document

Este ladrillo de innumerables páginas será vuestra peor pesadilla por varias razones, pero para desarrollos grandes, mi opinión es que hace falta, ya que en él TODO debe de estar especificado, explicado y detallado para que cualquier desarrollador, en un momento dado, si tiene que consultarlo para saber cómo realizar algo, lo encuentre y no tenga que molestar a las personas que han dedicado su tiempo a la creación de este documento.

Por desgracia todos conocemos a la gente y lo vaga que es, y en más de una ocasión pasarán de buscar en el documento y preguntarán directamente. Esto es inevitable a menos que dispongas de un elemento disuasorio en una posición privilegiada y visible (como por ejemplo, un trofeo de caza con la cabeza del último desarrollador que preguntó demasiado), pero se puede mitigar siendo un documento ordenado, fácil de entender y ameno (cosa imposible para este documento).

Otro de los grandes problemas que traerá este documento, es que el proceso de desarrollo de un juego es un proceso vivo, y a lo largo del tiempo, ciertas cosas ya especificadas serán modificadas por alguna razón, y todos esos cambios deben de figurar en este documento, así que mantenerlo al día debería ser imperativo.

Nota: Si os habéis dado cuenta, estos documentos están enfocados a la entrega a un publisher y un desarrollo para un grupo grande. Esto no quiere decir que no os pueda servir para un desarrollo individual o para grupos pequeños. Mi experiencia es que estos documentos habrían sido de gran ayuda en el caso de haberlos realizado correctamente y habernos ceñido a ellos.

Aprovecho para agradecer a Victor Cerezo por la clase sobre Documentación, sin la que éste artículo no habría sido posible.