Como diseñadores de juego, buena parte de nuestro tiempo lo vamos a emplear utilizando el programa Word para crear documentos de diseño. Estos documentos serán las guías y los puntos de referencia para que el resto del equipo pueda llevar a cabo su trabajo. Expondremos algunos consejos y técnicas para que escribir buenos documentos de diseño.
OBJETIVOS DE LOS BUENOS DOCUMENTOS DE DISEÑO
Los buenos documentos de diseño han de:
▪ Capturar el consenso del diseño.
▪ Conducir la visión del documento entre departamentos.
▪ Ayudar al plan de producción.
▪ Generar foco.
▪ Dar visibilidad hacia dependencias futuras y conflictos en el diseño.
PROBLEMATICA EN TORNO A LOS DOCUMENTOS DE DISEÑO
Algunos de los principales problemas con los que nos encontramos a la hora de escribir documentos de diseño son los siguientes:
▪ Se tiende a “sobre-diseñar”, cuando es mucho más importante que la documentación sea corta y precisa.
▪ Diseñar documentación de juego suele enfrentarse con la complejidad y con la interconexión de varios sistemas de juego.
▪ A menudo, los documentos de diseño no permiten interacción.
▪ Los documentos no son actualizados a medida que el proyecto avanza.
Conoce a tu target Conoce a tu target: ¿a quién va dirigido el documento que estás escribiendo? Puede ser que lo escribas para:
▪ El Equipo de Diseño: para llegar a consensos de diseño.
▪ El Equipo de Programación o Arte: para construir el juego.
▪ Productores: de cara a establecer un plan de desarrollo y obtener financiación.
▪ QA: para implementar el testeo.
▪ Marketing: para construir argumentarios de venta y promociones.
▪ Socios externos.
Si tienes duda, haz que el documento sea útil para un programador, normalmente son el target más importante y quienes más información necesitan para poder implementar el juego. Consejos para escribir buenos Documentos de Diseño Veremos a continuación algunos consejos para escribir buenos documentos de diseño.
▪ Haz que los documentos sean cortos. Es la primera de las reglas de oro para hacer buenos documentos de diseño. El tamaño no equivale a calidad, hay que buscar precisión sobre lo que se plasma en él.
También tenemos que considerar que, en la mayoría de ocasiones, será mejor tener muchos documentos cortos, asociados cada uno a una parte del juego, que uno muy grande.
Los documentos cortos:
− Son fáciles de leer.
− Son fáciles de escribir.
− Son fáciles de gestionar y de mantener actualizados.
−Tienen menos probabilidades de ser contradictorios.
Para ello, elimina:
− Lo que no aporte valor.
− Los espacios vacíos.
− Lo que sea "Cortar y Pegar".
− El texto innecesario de sistemas obvios.
▪ Usa un formato y terminología clara.
−Usa un lenguaje sencillo.
− Evita el uso de términos extraños.
− Evita el uso de términos específicos de la compañía.
−Considera la posibilidad de incorporar un glosario, como otro documento aparte si fuese necesario.
−Usa el listado de bullets.
−Usa cajas informativas como ejemplos.
− No uses un lenguaje débil (podría, tal vez, sería, puede, ...).
− No uses un lenguaje ambiguo.
▪ Evita la redundancia.
▪ No dupliques contenido explicando lo mismo varias veces, en su lugar haz que un documento apunte o enlace a otro documento, pero no repitas nunca.
−Acostúmbrate a escribir los documentos de diseño en inglés ya que, en todas las compañías grandes, ese es el idioma en el que se escribe toda la documentación.
−Puede que te interese también escribirlo en inglés porque alguien de tu equipo es angloparlante o porque tu estudio de desarrollo busque financiación para el proyecto y necesites enviar la documentación a algún publisher.
▪ Prioriza el diseño.
−Otorga prioridades a las diferentes funcionalidades que diseñes y vayas a documentar. Después, divídelas en fases.
−Asegúrate que el documento separa claramente las fases de las funcionalidades:
• Fase 1. Funcionalidades del prototipo. Necesarias para validar o testear el juego.
• Fase 2. Funcionalidades Core. Funcionalidades y herramientas que sostienen la creación de contenidos.
• Fase 3. Indispensable en Producto Final. Incluye funcionalidades que dependen en prioridad de otras funcionalidades.
• Fase 4: Wishlist. Posible Expansión. Incluye funcionalidades que dependen en prioridad de otras funcionalidades.
▪ No digas a otros cómo tienen que hacer su trabajo. Diseña un juego y transmite tu diseño, pero no quieras decir cómo otros tienen que programar el juego.
▪ Crea un índice al inicio con hipervínculos. No hagas que la gente tenga que buscar la información que quiere leyendo todo el documento.
▪ Refleja tus razonamientos en un apéndice aparte. Documentar tus razonamientos es especialmente útil para proyectos largos, donde el equipo literalmente se olvida de porqué habían tomado una decisión y no otra. Documentar los razonamientos hace que se reduzca el número de veces que las cuestiones controvertidas vuelvan a surgir.
▪ Y, el más importante de todos: actualiza la documentación cada vez que se apruebe cualquier cambio en el diseño o desarrollo de juego.
▪ Haz que la documentación esté siempre al día y actualizada e informa a todo el equipo de los cambios que se hayan realizado para que todo el mundo esté al corriente.