[XNA] Cómo desarrollar un Indie Game – Parte II

Continuando con el caso real de el desarrollo de un Indie Game, y habiendo hablado ya de la creación del equipo de desarrollo y la planificación, me centraré hoy en cómo hicimos el diseño y las pruebas de concepto, viendo ejemplos de código y las librerías utilizadas para el desarrollo del juego para Windows Phone 7, Robot Strike Bowling.

 Robot Strike Bowling: Pruebas de concepto

De forma paralela al diseño, e incluso un poco antes de comenzar este, es bueno realizar alguna prueba de concepto, esto es, programar una pequeña prueba de que lo que queremos hacer es viable. Esto no tiene que ser una versión detallada del juego que queremos hacer, sinó pequeños bloques aislados que creemos que podrán resultar complicados de hacer (pues sí, nos guste o no hay que comenzar por lo más difícil). En el caso de Robot Strike Bowling, hicimos algunas pruebas con el engine de física utilizado (Bepu Physics). Esta fué nuestra prueba de concepto:

[View:http://www.youtube.com/watch?v=nbO_pV23_NE:550:0] 

Es importante realizar alguna prueba de concepto ya que los programadores acostumbramos a alucinar un poco en cuanto a nuestras aspiraciones en cuanto nos ponemos a programar un videojuego, así que este tipo de pruebas nos puede ayudar a tocar de pies en el suelo, y evitar hacer un montón de trabajo que sería inútil si resulta que el juego es inviable. Puede ser inviable normalmente porque no se disponga de la experiencia necesaria para desarrollar el tipo de juego que se quiere hacer.

Robot Strike Bowling: Diseño

Casi todos sabemos, o deberíamos saber, que es importante saber qué queremos hacer antes de ponernos a picar código… y en el mundo de los videojuegos hay otro factor a tener en cuenta: si lo que queremos hacer es factible, o lo que es lo mismo, si somos capaces de hacerlo. Es muy importante darle a esta fase la importancia que merece, y es mucha. En el caso de Robot Strike, le dimos importancia, pero seguramente no la suficiente. Dedicar más tiempo al diseño nos habría ahorrado varios futuros problemas. Pero es lo que pasa en cualquier proyecto donde vamos justos de tiempo y no hay recursos: se recortan el diseño y las pruebas!

En fin, que nuestro diseño fué a muy alto nivel. Seguramente este diseño es aceptable como diseño conceptual, pero no como diseño técnico. Este diseño conceptual definirá en mayor detalle qué es lo que queremos hacer, sin entrar mucho en cómo lo vamos a hacer. En este caso generé un documento con un índice muy parecido a este:

• Game Mechanics
  • Characters, describe los personajes del juegos, que pueden ser usados por humanos o por la AI
  • Game Play Elements, posibles objetos que el jugador puede ir recogiendo durante el juego, como armas y mejoras
  • Game Physics, define qué tipo de físicas utiliza el juego
  • Artificial Intelligence, define por encima qué tipo de AI tendrá el juego
  • Multiplayer, explica si hay modo multijugador y cómo funciona este
• User Intrerface
  • Flowchart, flujos de navegación, muy útiles
  • Requisitos funcionales, que describen qué es lo que hace el gameplay en sí mismo
  • GUI Objects define los objetos que te puedes encontrar por la interfaz
• Art and Video, Idealmente contendrá una lista de todo el arte y vídeo que habrá en el juego, o al menos un esbozo inicial…
  • 2D Art & Animation
  • GUI
  • Terrains
  • Game Play elements
  • Special Effects
  • 3D Art & animation
  • Cinematics
  • Video
• Sound & Music, se definirán los objetivos de la música, el estilo que se desea transmitir. Se pueden detallar formatos de archivos, tamaño máximo, etc.
  • FX, es una lista de todos los FX que se van a identificar
    • GUI
    • FX
    • Characters
    • Game Play elements
    • Enironment, terrains
    • Motion
  • Music
    • Event Jingles, éxito, fracaso, muerte, victoria, etc
    • Shell screen, para créditos títulos y final de juego
    • Level Themes, música específica para cada nivel
    • Situations, música específica para situaciones como acción o peligro
• Level Requirements
  • Level diagram, viene a ser un diagrama que define cómo se accede de un nivel a otro. En algunos juegos será lineal, pero en otros no.
  • Asset Reservation Schedule, tabla que indica en qué momento del juego ciertas partes del juego deben ser rebeladas al jugador
  • Level design seeds, son borradores del diseño de los niveles, y pueden estar sujetos a cambios posteriores

Nota: Este índice está generado a partir de varios documentos, principalmente de GameDev.net, adaptado a Robot Bowling Strike, que a mi entender nos han sido tremendamente útiles, eso no quiere decir que tenga que ser útil a cualquier proyecto de videojuegos exactamente con este índice y contenidos, pero estoy seguro que sí que será positivo invertir tiempo en hacer un diseño.

Este sería el diagrama de flujo de nuestro juego. Contiene elementos, como la entidad «Juego» que puede (y debe) ser desglosada en mayor detalle en otro diagrama.

Y así queda el tema por el momento… próximamente… espero centrarme ya un poco en la parte más técnica!