El documento de diseño de proyecto es un instrumento que cumple dos funciones: comunicación y registro. Sirve para comunicar a todos los profesionales involucrados (stakeholders) la intención del producto que se quiere desarrollar, de tal forma que todos tengan una idea clara de él, y así evitar sorpresas o mal entendidos. Por ejemplo, en un eventual ambiente empresarial, ayudaría a los productores a escoger cuáles proyectos financiar y cuáles no. A los miembros del equipo les ayuda a tener en mente un mismo propósito a lograr. Cuando un nuevo miembro se une al equipo, la lectura de este documento le debe dejar una idea clara de qué se trata el proyecto.

La función de registro es una amenidad para los desarrolladores. Cuando los miembros del equipo realizan una tarea, por ejemplo, la corrección de una pulga, se sumergen en una profundidad de detalles. Al salir de ella se sienten desubicados, "¿Y ahora qué sigue?". El documento de diseño se convierte en un mapa de rutas (roadmap) que provee respuesta a este tipo de preguntas. También es una ayuda para la memoria, evitando olvidar ideas ingeniosas. De esta forma, el documento de diseño debe verse como un producto para el equipo y no como una imposición para complacer al profesor o a un jefe.

El propósito del documento de diseño del proyecto es comunicar sobre lo que consiste el futuro videojuego o simulación, tanto a los miembros del equipo como a personas ajenas (que nunca han oído algo sobre el proyecto). Entre más claro, mejor. No hay un formato estándar. Use el que mejor resultados le genere. Trate de que la lectura sea amena, ilustrada. Puede utilizar humor e imágenes sencillas, hechas a mano o en un programa de ilustración. Recuerde que lo importante es dejar la idea del proyecto clara. Una estrategia para lograrlo es contarle a dos o tres personas ajenas su proyecto hasta que lo hayan comprendido y grabar la conversación. Sus explicaciones y los materiales que utilizó servirán para que una nueva persona pueda entender el proyecto. Trate de plasmarlos en el documento de diseño. Esta guía de tareas les puede ayudar:

1. Fórmense en equipos de 3 miembros.
2. Identifiquen el equipo de desarrollo. Provéanse un nombre. Puede ser ingenioso o jocoso.
3. Discutan sobre el producto que quieren desarollar. Hagan una lluvia de ideas. Anoten algunas ideas clave. Hagan dibujos sencillos en un papel.
4. Escojan un nombre para su proyecto. Discútanlo con cuidado hasta estar a gusto.
5. Creen un repositorio de control de versiones para trabajar los archivos del proyecto en forma colaborativa. Si la modalidad de proyecto de software libre es viable, pueden crear su repositorio en GitHub, de lo contrario en Bitbucket.
6. Revisen la documentación del proveedor del servicio de control de versiones para crear equipos. Identifiquen el equipo con el nombre que escogieron en el paso 2.
7. Inviten al equipo en el control de versiones, al asistente y al profesor. De esta forma, el asistente y el profesor podrán revisar el control de cambios y ofrecer aportes de utilidad al trabajo del equipo.
8. Den a conocer la existencia del equipo y del repositorio de control de versiones a los demás compañeros en la Plataforma educativa.
9. Registren y extiendan las ideas generadas en el punto 3 en un documento de diseño en formato Markdown en su repositorio de control de versiones. Sugerencia: por convención puede dar el nombre gdd.md a su documento si se trata de un videojuego (game design document). Trabajen el contenido de este documento en forma colaborativa.
10. Utilizando el documento e imágenes, trate de comunicar su idea a personas ajenas al proyecto. Puede ser en su hogar o a otros estudiantes de la carrera ajenos al curso. Explique hasta que ellos tengan clara la idea y puedan brindarle sugerencias. Grabe las conversaciones. Utilícelas para mejorar el documento de diseño.
11. Asegúrese de que su idea de proyecto sea visionaria. Haga ver que su idea puede crecer mucho, y provea algunos ejemplos de cómo. Luego delimite lo que va a implementar durante el curso de 16 semanas.

El formato y estructura del documento de diseño será el que mejor considere el equipo. A modo de sugerencia debe tener al menos la siguiente información.

1. Título del juego o simulación. De ser posible que sea una imagen con tipografías llamativas.
2. Ilustración. Al menos una imagen de un escenario típico/representativo del videojuego o simulación en ejecución.
3. Descripción. Uno o dos párrafos que resumen de qué se trata el juego o simulación.
4. Ficha técnica:
   1. Plataformas destino: Windows, Mac OS X, Web, iOS, Android.
   2. Audiencia: niños, adultos mayores, profesionales, amantes del fútbol, estudiantes de química, etc. De ser posible indique el rango de edades si lo conocen.
   3. Productos similares y en qué se diferencia su juego o simulación.

Para un videojuego:

5. Historia/trama (story). Un relato que saboriza al videojuego.
6. Flujo del juego (game flow o game play). Explique cómo el jugador avanza y crece por el juego a medida que la dificultad incrementa. Indique qué gana: experiencia (habilidades), dinero, puntos, coleccionables, recompensas, elementos ocultos, etc. ¿Cómo el gameplay está entrelazado con la trama?: ¿hay rompecabezas que deben resolverse para anvanzar o hay que derrotar bosses?. ¿Cuál es la condición de victoria del jugador? ¿recolectar 100 estrellas? ¿derrotar al villano?...
7. Caracteres. A quién (una persona) o qué (un carro) controla el jugador. Cuáles son sus características (sexo, edad, alimentación, intereses...). Cuál es su apariencia (de ser posible dibujarlo). Cuál es su historia y cómo llegó a esta situación (el juego). Qué tipo de personalidad tiene (en el juego debe hacer movimientos y acciones acordes). Sólo incluya detalles relevantes al juego. Qué tipo de movimientos/ataques/instrumentos tiene o puede utilizar. Corre, vuela, nada?. Cambia el jugador de personajes durante el juego?
8. Controles. Para cada plataforma pretendida, dibuje sus controles (el teclado en PC, el ratón/touchpad en PC, la pantalla en iOS/Android, etc.). Indique los botones, teclas, gestos, o combinaciones de ellos, que tienen acción y cuáles son.
9. Gameplay. Aplique los principios de los géneros al que se apega su videojuego. Está el juego divido en niveles? Liste todos los escenarios. Se pueden hacer proezas como conducir a alta velocidad mientras deja caer obstáculos en la vía. Aplique sus características distintivas al juego. Haga diagramas o dibujos para explicar. Indique si usa hardware especial o hace un uso distinto, por ejemplo, la pantalla está divida en cámaras y el jugador puede agregarlas o desaparecerlas.

Para una simulación:

5. Antecedentes/justificación. Una descripción de porqué es importante la simulación.
6. Modelo. El modelo matemático, físico, biológico, etc. que está detrás de la simulación.
7. Agentes. Los objetos, personas, seres vivos que serán simuladas. Qué características de ellos se representan. Las relaciones. La cantidad aproximada para que la siulación tenga sentido.
8. Controles. Las variables que el usuario puede controlar. Sus unidades. Los controles que se utilizarán para solicitarlas.
9. Salida. Las gráficas o visualizaciones que la aplicación produce mientras la simulación está en curso. Los controles para detenerla, pausarla. Cómo obtener detalles de un agente...
10. Resultados. La información resumida que generá la simulación. ¿Gráficas, texto, tablas, una combinación de las anteriores? ¿Las generará en pantalla, en archivos?.

Usted recibirá retroalimentación por su participación en el equipo. El equipo recibirá retroalimentación por su documento de propuesta de proyecto. Tanto el profesor como sus miembros del equipo anotarán sus percepciones en la siguiente rúbrica: