jueves, 1 de septiembre de 2011

Documentando nuestro juego II: Documento de diseño de Juego (Primera parte)

Este documento es muy importante y al igual que ocurría con el Product Sheet, cada diseñador tendrá su propia versión del mismo y las partes que lo componen.

Esta vez hemos comenzado el desarrollo del juego y ya empezamos a tener algo de material (poco, quizá algunos bocetos) y podemos ordenar nuestras ideas para que estén totalmente claras de cara a nuestro equipo de desarrollo. Debemos conseguir que nuestra imagen del proyecto se convierta en una visión en común para que todos trabajemos hacia el mismo objetivo.

El Documento de diseño de juego tendrá varias versiones según cambien algunas cosas que inicialmente iban a ser de una forma en el desarrollo, pero al ser probadas y ver que no resultan, acaben siendo de otra.

Como esto es largo de explicar y me saldría un post enorme lo dividiré en varias partes, así que de momento pongo lo que suelo usar yo y lo iré explicando en post sucesivos.

Portada

Titulo y versión

Autor del documento

Descripción del proyecto
- Genero
- Plataformas
- Target
- Storyline
- Sinopsis
- Objetivo del juego
- Resumen del concepto
- Elementos y características de la jugabilidad
- ¿Qué tiene de bueno?
- Apariencia y ambientación (Con referencias)


Modos de juego

Opciones de juego

Mecánicas de juego

Entornos

Ítems

Personajes (Animaciones necesarias).

Personajes no jugables (Animaciones necesarias)

Vehículos

Guión de juego

Interfaz o GUI

Cámaras

IA

Cinemáticas (Storyboards)

Controles

Audio y Música

Diseño de Sonido

Diseño de programación

Walkthrough

Finales y elementos divertidos

Problemas del proyecto

Apéndice


Solo me queda decir que la parte de problemas del proyecto no la he visto en ningún libro que hable sobre esto, pero me gusta ponerla a nivel interno (para mi mismo). No voy a enseñarle a nadie las debilidades de mi idea, pero si pienso en las primeras versiones del documento de diseño en ellas, puedo modificar el gameplay, la historia o lo que sea necesario, para corregir esos fallos que he visto, en las versiones sucesivas. Por ejemplo: Si estoy haciendo un juego para redes sociales (En las que he leído que el publico mayoritario a la hora de jugar es de género femenino) y mi juego esta orientado sobretodo al publico masculino, pondré ese defectillo en esta parte del documento para en el futuro, cuando se me ocurra como, solucionarlo si es posible cambiando algo, o escribirlo como “un riesgo que he decidido asumir a la hora de tener éxito”.

Próximamente más.


3 comentarios:

  1. Algunos desarrolladores hicieron públicos los informes de "problemas del proyecto". Aquí puedes encontrar algunos:

    http://www.vidaextra.com/industria/postmortems-la-mejor-herramienta-para-el-desarrollo-de-videojuegos

    ResponderEliminar
  2. Es un buen documento para tener en cuenta, y para corregir errores en futuras creaciones.

    Has escrito un artículo breve, pero muy completo, Javi. Enhorabuena :).

    ResponderEliminar
  3. Gracias! Suelo leer muchos postmortems de juegos, así que estoy al tanto del tema y... lo de que el articulo sea breve es por que aun me queda explicarlo, pero lo haré en varias partes o los post serán muyyyyyyyyyyyyyyyy largos :P

    Saludos!

    ResponderEliminar