lunes, 26 de septiembre de 2011

Más aprendizaje: Programación

Es mi punto débil, lo admito, y muchas veces he leído que para ser un buen diseñador hay que manejarse al menos de forma básica, siendo capaz de programar scripts y cosas así. Además, un grafista o un diseñador de juegos que conozca los límites que pone la programación a un proyecto, sabrá abstenerse de pedir cosas imposibles a su equipo.

Como lo que me falla es ordenarme un poco a la hora de escribir código y dominar bien la Programación Orientada Objetos, he empezado por un lenguaje como ActionScript 3, con el que se pueden desarrollar pequeños juegos gracias a Flash.


Mi aprendizaje de momento se desarrolla gracias al libro que ya comenté hace un tiempo ActionScript 3.0 Game Programming University, pero por momentos veo como debería extenderse a formarme un poco recurriendo a la educación tradicional, con profesores y eso, ya que el ser autodidacta a veces ralentiza el aprendizaje, y además no da un título (que por otra parte, tampoco es que sirva de mucho).


Programar, o más bien “programar” videojuegos cada vez es más sencillo gracias a herramientas o Motores para el desarrollo de juegos, tanto en 2D como en 3D. En muchos casos se nos promete que no tendremos que teclear ni una sola línea de código. Sin embargo, si queremos que los límites no nos los pongan dichas herramientas, tarde o temprano tendremos que aprender y escribir mucho para lograr llevar esa idea tan espectacular o simpática que teníamos, a la pantalla de nuestro juego.

Por que hasta un modelador 3D puede añadir utilidades a… por ejemplo, 3D Studio Max, si es capaz de programar en MaxScript y un desarrollador puede añadir más y mejores acciones, eventos o lo que sea a… tal vez Unity. Quizás haya que atreverse con las mates, la física y la lógica.

jueves, 22 de septiembre de 2011

Documentando nuestro juego V: Documento de Diseño de Juego (Parte final)

En la parte anterior me quedé explicando las cámaras y ya quedaban solo unos últimos puntos a tratar del documento que explicará como va a ser nuestro juego. A estas alturas con todo lo escrito seguro que tenéis muchas más cosas claras y algún concept art o boceto explicativo con el que empezar a rellenar el texto.

16. IA: es decir, Inteligencia Artificial, o explicar los comportamientos que tienen los personajes que no maneja el jugador como, los enemigos o personajes neutrales. (Como luchan, como se mueven, si se protegen, si nos localizan, si son capaces de moverse por todo el escenario o solo una zona…).

17. Cinemáticas (Con sus Storyboards a poder ser): Se puede incorporar un guión que cuente las cinemáticas y explique su funcionamiento (donde van, si funcionan con el motor del juego o son videos, etc.) Si se puede, sería bueno incluir Storyboards.

18. Controles: Si sabemos en que plataformas va a aparecer nuestro proyecto ya podemos pensar en como se va a controlar con el mando/teclas de la misma, pero lo ideal, tal vez sería pensar en algo genérico y decidir que acciones tendremos y como se harán (pulsando un botón, acciones sensibles al contexto, apuntar y hacer click con el ratón, etc.)

19. Audio y música: Describiremos como va a ser la ambientación de nuestro juego. La banda sonora es muy importante y debemos procurar que cuadre con la época, ambiente y lugar donde se desarrolla la acción.

20. Diseño de sonido: ¿Va a haber diálogos grabados? ¿Qué sonidos necesitamos? ¿Cuántas canciones pueden hacer falta?

21. Diseño de programación: Si lo sabéis podéis comentar el motor que se va a usar. Sistemas de colision, fisica, iluminación, renderizado, IA, recuento de poligonos, distancia de vision, operaciones del motor, streaming de video…

22. Walkthrought: Se trata de explicar paso por paso como se pasa el juego. Si no os hacéis una idea clara pensad en las guías que se compran (o compraban) en los kioscos donde se nos explicaba como acabar con tal título con todos sus secretos.

23. Finales: Aquí vamos a contar el final o los finales tan sorprendentes que nos hemos currado y que dejarán al jugador con la boca abierta.

24. Problemas del proyecto: Esta parte, como ya dije me, gusta ponerla para ir desarrollando el documento y solucionando posibles fallos que vea en el funcionamiento del gameplay, historia, etc. No se trata de corregir Bugs de programación, si no de arreglar problemas en la idea que no se vieron al principio.

25. Anexos: Para todo lo que tengamos que añadir en forma de documento externo, bibliografías, arte desechado… no se, lo que os venga bien incluir.

Bueno y esto es todo. Como ya dije algunas cosas no se incluyen siempre y cada diseñador tiene su documento particular.
Como ejemplo de otro diseñador pongo un enlace a un documento que usa el diseñador de juegos como Dungeon Siege y Fallout Tactics, entre otros, Chris Taylor (que por supuesto esta en inglés). Se puede descargar en formato Zip haciendo click aquí.

También podéis descargar aquí el documento de diseño del juego Larry 7, escrito por Al Lowe, de Sierra On-line. (Si, este tampoco se parece al mio)

martes, 20 de septiembre de 2011

Webs interesantes: Unseen64.net

Juegos cancelados, arte que se desechó en algún proyecto, versiones Alpha o Beta o incluso zonas secretas que son inaccesibles en las versiones finales de algunos títulos. En esta Web tenéis videos e imágenes de todo esto y para todas las plataformas.

Se puede aprender bastante viendo animaciones, texturas, o concept art, de juegos que, aunque no salieron a la venta, tenían la suficiente calidad para hacerlo, pero a lo mejor se quedaron sin dinero o no encontraron distribuidora.

Es increíble ver la cantidad de juegos que se quedan a medias y el dinero y tiempo invertido en ellos, así que una pagina como esta es muy útil para que los desarrolladores no sientan que este trabajo se tira directamente a la basura (Al menos el público puede verlo). Por otro lado también es curioso ver casos de juegos que estaban proyectados para una consola, pero por un cambio de generación, se paralizan y se vuelve a hacer desde cero para una consola más moderna.

Para mantenerse económicamente, en Unseen64 aceptan donaciones y venden camisetas y, para mantener sus archivos actualizados, piden a desarrolladores que muestren sus trabajos que no pudieron publicarse. Así que ya sabéis que hacer si algún día estáis en esta situación. (Aunque esperemos que no y que todos vuestros proyectos sean excelentes y los publiquen sin problemas).

sábado, 17 de septiembre de 2011

Dibujo de personajes: Muñecos de palo y volumen

Cuando era mucho más pequeño y quería dibujar, pude comprobar en algunos libros como explicaban que primero hay que planear lo que vamos a hacer, haciendo muñequitos con líneas y luego, buscando el volumen con formas sencillas como cilindros, esferas, etc.

El caso es que luego veía en la televisión como algún artista famoso hacia un dibujo rápido para la reportera que lo entrevistaba, y no hacía nada de eso, así que me frustraba y pensaba que era simplemente algo para novatos. (Y yo no quería ser un novato…)

Con el paso del tiempo he visto que, aunque es verdad que mucha gente es capaz de dibujar cosas alucinantes así a lo loco y sin planear nada, es algo que resulta muy útil y es muy recomendable aunque no se sea novato y, de hecho, todos los profesionales comienzan planeando sus dibujos desde líneas y formas más simples a trazos mas complejos.

Estuvimos practicando esta idea hace unos meses en el curso de “Experto en Videojuegos” que hice, y me entretuve bastante creando poses dinámicas y tratando de evitar ese dibujo tan típico de cuerpo y cabeza que miran al frente.



Una forma en la que tratamos de mejorar, fue calcando sobre un “muñeco” de volumen ya hecho, escaneado de un libro, y era sorprendente como sobre el planteamiento de otro artista se conseguían buenos dibujos muy fácilmente.


Cada persona acaba desarrollando su forma de construirse este armazón sobre el que crear su arte definitivo (con más o menos detalle, usando más o menos formas…) Pero si practicamos el dibujo, también deberíamos practicar esto, por que mejoraremos más rápido y tendremos menos problemas con las proporciones y las poses.

jueves, 15 de septiembre de 2011

Descarga de Proyectos: Hazme caso

Un proyecto del año 2008, si no recuerdo mal, y creado en tan solo 48 horas (gráficos, sonido, música y código) para el concurso “Crap Games”, que consistía básicamente en hacer el juego más cutre y malo posible.

Me alejé un poco del espíritu del concurso y, mas que cutre, quise ser simplón y graciosete, así que hice una música con mis tocadiscos que acompañara a una “historia” de un tipo muy pasota con una novia mandona y que no paraba de hablar, pero eso si, para respetar las normas del concurso, el juego incluía algunos “bugs” hechos a propósito, como que el personaje no responda al salto cuando estas en las escaleras o que cuando te matan o acabas el juego, tengas que salir y volver a ejecutarlo para volver a jugar, además de una pantalla de título lleno de letras que no vienen a cuento.

En fin, una autentica chorrada que seguro que divierte menos al que lo jugase, que a mi cuando lo hice, y que fue desarrollado en el ya difunto Fenix.

Lo pongo para descargar por… por… pues… no se, por hacer relleno en el Blog y, por si por accidente lo pierdo de mi ordenador, tener de donde bajarlo, que a mi me hace gracia jugarlo de vez en cuando. :P

Para descargar el juego para Windows comprimido en un rar, click aquí.

Nota importante: Aunque ponga “basado en hechos reales”, el juego Hazme Caso si Quieres Follar Esta Noche que Estoy Malita y soy tu Novia Maldito Capullo que me Tienes Hartita, que es su título completo, exagera mucho la historia en la que se basa y no es que hable exactamente de mi ni, por supuesto mi pareja actual, que es una chica muy inteligente, muy guapa, muy buena persona, me trata genial, no me esta mandando cosas todo el día y, doy gracias por esto, no tiene un perro devorador de hombres.

No seáis malpensados/as.


martes, 13 de septiembre de 2011

Documentando nuestro juego IV: Documento de diseño de Juego (Tercera parte)

Seguimos explicando los puntos que componen este documento tan importante dentro del mundo de los videojuegos, entrando ya en la parte donde más vamos a escribir, para aclarar como funcionará nuestro proyecto cuando vaya tomando forma.

5. Modos de juego: Debemos explicar los modos que tendrá nuestro juego, ya sea modo historia para un jugador, cooperativo, multijugador… ¿Será online? ¿Cuántas personas juegan en cada modo? ¿Cuál es el objetivo a cumplir? ¿Pantalla completa o pantalla partida? Hay que dejar todo claro al equipo de desarrollo.

6. Opciones de juego: ¿Qué va a ser configurable? Niveles de dificultad, desactivar o cambiar el volumen de la música, formatos de pantalla, controles configurables, sonido… Hay que hablar de todo lo que pueda cambiarse en nuestro juego y de que forma.

7. Mecánicas de juego: Entremos más en detalle haciendo una lista de las mecánicas de juego, incluso con pequeños bocetos o ilustraciones que nos ayuden a entenderlas si es necesario. En cierto modo estaremos diciendo como se juega. Por ejemplo: Una mecánica de juego es hablar, otra caminar por un escenario, otra puede ser activar una palanca que abre una puerta, otra combatir con enemigos, otra podría ser comprar ítems, etc.

Lo mejor es enumerarlas y describirlas contando con se juegan. Por ejemplo: En los combates fijaremos el blanco y podemos atacar a distancia con magia o usando la espada si estamos cerca, esquivar los golpes del enemigo o pararlos cubriéndonos con nuestro escudo.

A veces es útil comentar si estas mecánicas se sirven del escenario o influyen en él. Si escalamos solo en zonas con una determinada textura o forma, si al usar una magia que provoca una explosión puede destruir alguna parte del entorno…

8. Entornos: ¿De que escenarios se compone el juego? Vamos a describirlos e incluso a mostrar alguna referencia si podemos. ¿En que zonas se dividen? ¿Los escenarios tienen subescenarios? Hay que describir lo que contienen. Por ejemplo: Si es una ciudad, ¿Cuántas calles tiene? ¿Se juega de día? ¿Hay personas caminando por ella?

9. Items: Explicar si pueden usarlos también los enemigos, en que escenarios aparecen (o si salen en todo el juego), como se usan, para que sirven, si hay un límite en el número que podamos recoger de un determinado tipo, donde los almacenamos (en caso de que se almacenen), etc.

Items pueden ser, por ejemplo, botiquines, llaves, comida, armadura y… existen discusiones entre diseñadores sobre si considerar las armas como items o lo es solo su munición. (Si no las consideráis items o simplemente queréis tenerlas aparte necesitáis un apartado de armas en el documento de diseño).

10. Personajes: Hagamos una lista de los personajes principales que podemos controlar y, si vamos sabiendo las animaciones que se necesitan hacer para ellos, podemos hacer una lista de las mismas para que los animadores trabajen en ellas.

11. Personajes no jugables: Enemigos (comunes y de final de fase), aliados, personajes neutrales que caminan por una ciudad, con los que podamos interactuar o no, si hay animales, etc. ¿Qué animaciones necesita cada uno y que va a hacer en el juego?

12. Vehículos: ¿Hay vehículos? ¿En que parte del juego sale cada uno? ¿Cómo se consiguen? ¿Cómo se controlan? ¿Sufren daños? ¿Sufrimos daños nosotros estando dentro de ellos? Aclara todo lo que necesites que se sepa sobre el uso de vehículos en tu proyecto.

13. Guión de juego: Esto se suele hacer aparte y se añade en el documento como anexo, así que en este punto puede aparecer un “ver anexo 1” o algo así. El caso es que el guión lo suele escribir un guionista y puede ocupar muchas páginas. Además, tenemos varios tipos: El guión técnico, el guión literario y el que contiene los diálogos.

Para resumir, en el guión literario se cuenta la historia como si escribiéramos un libro.

En los diálogos, aparece lo que dicen los personajes, teniendo en cuenta que en videojuegos, la interactividad y elección de acciones por parte del jugador suele convertir este tipo de texto en un “árbol de diálogos” que se ramifica muchas veces. Si un personaje nos pregunta algo y le respondemos A, el personaje reaccionará o responderá de una forma; pero si le respondemos B lo hará de otra forma completamente distinta y así. En fin, mucho trabajo y mucho lío.

Un guión técnico contiene… pues eso, la parte más técnica: Debemos indicar las secuencias, planos (si podemos añadiremos Storyboards), que música habrá, indicar los sonidos, como empieza un nivel, como se termina, etc.

14. Interfaz o GUI (también se le llama HUD): Hagamos una descripción de marcadores, barras de energía, inventario, etc. Añadiendo imágenes y bocetos para describir perfectamente como funciona, donde se sitúa y si es permanente o se oculta en algunos momentos del juego.

15. Cámaras: ¿Cómo funcionan? ¿Hay cámaras fijas? ¿Las podemos cambiar? ¿O es, por ejemplo, una cámara fija en 3ª persona? ¿Cómo afectan las cámaras a la jugabilidad si lo hacen? (Por ejemplo: En un simulador de vuelo, al disparar un misil contra un objetivo en tierra, la cámara puede pasar a un plano subjetivo del misil volando hacia el blanco hasta estrellarse contra él, y luego volver a la cabina del avión).

Y esto es todo por hoy. Espero que en el próximo post sobre este tema pueda terminar de explicar lo que queda.

Wow, esta siendo más largo de lo que pensaba.


sábado, 10 de septiembre de 2011

Gráficos en 2D para juegos: Pixel Art y Vectores

Actualmente existen una gran variedad de formas de crear arte para videojuegos. La única norma que hay que cumplir realmente es convertir en digital lo que hagamos para que pueda verse en la pantalla. Da igual si escaneamos un dibujo a lápiz, creamos un modelo 3D, sacamos una foto a un muñeco de plastilina, o lo que se nos ocurra. El caso es que al final del proceso lo que tendremos son dos tipos de gráficos: Vectoriales o formados por píxeles.

Antiguamente los gráficos en videojuegos se hacían todos mediante píxeles, y me refiero a punto a punto, tratando de dar forma a personajes que apenas podían usar un píxel para un ojo o un par de ellos para la boca. Esto se conoce como Píxel Art y se sigue usando actualmente para dar un toque retro o, también en algunos casos (aunque cada vez menos) por exigencias en los tamaños de pantalla de ciertos dispositivos o en las resoluciones de las mismas.

Crear este tipo de imágenes es relativamente sencillo, pero llegar a un buen nivel como Píxel Artist requiere mucha práctica y experiencia.




Normalmente se parte de un boceto, aunque puede pintarse directamente si se tiene una idea clara y habilidad para esto. Después, “calcamos” punto a punto y corrigiendo sobre la marcha cualquier deformidad o problemas en las proporciones que nos encontremos. Podemos añadir color, sombras, luces y hasta textura si le echamos imaginación y, como consejo principal, os recomiendo que trabajéis con algún software que os permita tener la misma imagen abierta dos veces, una ampliada tanto como sea necesario para trabajar cómodamente y otra a su tamaño original.


Los vectores se usan mucho en casi todos los juegos e incluso series de animación de hoy en día, aunque también es verdad que en muchas ocasiones se hace todo el trabajo artístico con vectores pero los gráficos finales son imágenes de píxeles. (Es fácil convertir vectores a píxeles).

Los gráficos vectoriales se crean más o menos del mismo modo. Primero tenemos un boceto a lápiz o hecho en nuestro ordenador y sobre él creamos el definitivo, solo que esta vez lo haremos línea a línea, mediante lo que se conoce como nodos, que son unos puntos que permiten dar curvatura a estas líneas que los unen. Luego llega el color (Que suele ser plano), las luces, sombras, etc.


El nivel de detalle de los gráficos vectoriales no puede ser muy grande, aunque si los combinamos con los otros podemos añadir ese detalle que nos haría falta para dar más matices de color o texturas.


Para aprender más sobre esto esta Internet o libros específicos sobre el tema. Por ejemplo para vectores conviene dominar software como Illustrator, Flash o Corel y, para el manejo de Píxeles están Photoshop, Gimp, Paint Shop Pro, etc. Así que ya tenéis por donde empezar.

martes, 6 de septiembre de 2011

Documentando nuestro juego III: Documento de diseño de juego (Segunda parte)

Después del primer post donde mostré las partes que debería contener un documento de diseño, vengo a cumplir lo prometido de explicar algunas de ellas.

Antes de empezar conviene decir que este tipo de documento puede ser muy extenso, pero dependerá del tamaño de nuestro proyecto. Un minijuego que apenas tiene historia, personajes, etc. no necesita que documentemos ciertos aspectos del mismo. Como ejemplo, puedo poner el juego Pixfrogger, que en solo unas pocas páginas (creo que eran 7) quedó bien explicado para que todos los miembros del equipo supiésemos hacia donde trabajar en el desarrollo.



Vamos con las explicaciones.

1. Portada:
Hazte una portada que sea decente con lo que tienes. Si no hay aún ilustraciones del juego puedes pasar de ello y ya lo añadirás en próximas versiones, pero cuanta más bonita más ilusión hace. :P

2. Título y versión: Los puedes poner en la misma portada o en una página interior del documento. Si el título es provisional especifícalo y, respecto a la versión ponla sabiendo que el juego avanza, cambia y, va a haber algunas más. (Casi siempre es bueno guiarse por las versiones de nuestro juego, Alphas, Betas, etc. y un numerito)

3. Autor del documento: En la misma página que el título y la versión, a no ser que necesitemos mucho espacio por que ha trabajado mucha gente en redactarlo. Se pueden especificar guionistas si se incluye un guión, ilustradores, etc. Además, por supuesto, el propio diseñador que escribe el documento aparece aquí.

4. Descripción del proyecto: Aquí me gusta meter una serie de subtítulos como ya especifiqué en el post anterior, pero quien prefiera puede dejar simplemente dichos subtítulos sueltos y rellenarlos como un punto más dentro del documento. El caso es que tiene que haber una descripción que nos de una primera idea de lo que es nuestro proyecto. Así, dentro de la descripción del proyecto podemos tener:

a. Género: ¿Es un shooter? ¿Plataformas? ¿Un juego de simulación? ¿Un genero nuevo no inventado?

b. Plataformas: ¿Para que plataformas pensamos hacerlo? ¿IPhone, 3DS, Xbox 360…?

c. Target: ¿Cuál es nuestro público objetivo? Podemos poner todo lo que nos sea útil para clasificarlo: Sexo, edad, nivel de experiencia en videojuegos (Casual o Hardcore), etc.

d. Storyline: Un resumen de la historia en una o dos líneas.

e. Objetivo del juego: ¿Cual o cuales son los objetivos de nuestro juego? ¿Salvar una princesa o un príncipe? ¿Salvar la tierra de una invasión alienígena? ¿Obtener más puntos que otros jugadores en Internet? ¿Coleccionar más ítems que nadie?

f. Sinopsis: Es como una especie de resumen de la historia de nuestro juego, pero sin revelar el final. Digamos que sería algo así como explicarle a alguien que nos pregunta, de que va una película y que sienta ganas de verla, pero sin contarle nada que pueda estropearle disfrutar de ella. (Sin spoilers, para que nos entendamos).

g. Resumen del concepto: Explicar brevemente la idea de cómo se juega. Por ejemplo en el caso del clásico Frogger podría ser: “Controlamos una rana que debe cruzar una carretera para llegar a su charca evitando ser atropellada.”

h. Elementos y características de la jugabilildad: Podemos especificar, a modo resumen, por qué ya lo explicaremos al detalle más adelante, como se juega. Si la jugabilidad se basa más en los conflictos, si se basa más en la resolución de puzzles, si hay secretos a descubrir, si saltamos, si escalamos, etc. Además ¿que elementos nos ayudan en está jugabilidad? Armas para enfrentarnos a los malos, magia que nos ayude a resolver los puzzles…

i. ¿Qué tiene de bueno? O más bien ¿qué podría tener de bueno? (por que el juego aún no está hecho). Aquí podemos presumir de innovaciones, de lo currado de nuestra historia, la espectacularidad de los gráficos que usaremos, etc.

j. Apariencia y ambientación: ¿Cómo se va a ver nuestro juego? Y, en este caso, además de una buena descripción, podemos poner referencias de películas, comics, otros juegos, etc. Para dejar claro a que se puede parecer nuestra idea en su aspecto.

Como veis, en muchos casos encontramos que alguna parte del documento no nos resulta útil o sentimos que nos estamos repitiendo, así que si lo consideramos podemos no incluirla, por que todo depende de nuestro proyecto y, unas veces se explica con más y otras con menos, dependiendo de la forma y el tamaño de nuestro juego.

Y hasta aquí llego por ahora. Ya explicaré algunos puntos más.

domingo, 4 de septiembre de 2011

Realistic Game Characters

Un libro imprescindible si os gustaría dedicaros crear personajes 3D, escrito por Ryan Kingslien (y claro, está en inglés). Viene con DVD y trata tanto Zbrush como Maya. Seguro que alguna vez habéis pensado ¿Cómo se modela el pelo en Zbrush y luego lo llevas a Low poly? ¿Cómo hago la ropa? ¿Las armas? ¿Cómo coloco mi personaje en una pose chula y lo pongo presentable para mi portfolio? Pues el libro explica todo eso y más, y es que de hecho, nos guía en la creación de la chica de la portada paso a paso con todo lo que ello conlleva. (Modelado, esculpido, mapeado, texturizado…) Así que se trata de una obra muy completa sobre modelado de personajes Next Gen para videojuegos (ya sabéis, con normal map y esas cosas) para la que, eso si, se necesita una cierta base, tanto con Zbrush como con Maya (o cualquier otro software de modelado 3D similar). No es para usuarios novatos. Otra cosa interesante del libro son sus lecciones de anatomía, necesarias para este tipo de arte “videojueguil”. Pues nada, a practicar. Ya se sabe que con 3DS y Wii U, todas las consolas del mercado van a usar este tipo de técnicas y hay que estar preparados.

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.