Jesús Bosch

XNA, programación gráfica y desarrollo de videojuegos por un Microsoft Student Partner

[XNA] La importancia de una buena arquitectura en nuestros videojuegos

Cómo muchos ya sabéis, hará poco más de un mes terminé la primera parte del desarrollo de Robot Strike Bowling. Programar un juego es una tarea enormemente compleja, mucho más de lo que parece a simple vista. Si no se utiliza una buena arquitectura, la tarea puede convertirse en un tremendo dolor de cabeza, o en un abandono del proyecto. Así pues, ahí van algunas recomendaciones.

Si eres programador profesional, provablemente tienes experiencia en el desarrollo de aplicaciones ASP.NET, Winforms, Silverlight… básicamente aplicaciones de gestión. Olvida lo aprendido (vale, no todo, tampoco nos pasemos). En un videojuego no valen cosas como registrar eventos (es muy lento), operaciones de acceso a datos síncronas (un juego se ejecuta a 60fps en windows/xbox y a 30 fps en Windows Phone 7), y no se puede parar la ejecución/interacción del juego durante más de un segundo.

La aplicación genera gráficos, animaciones y efectos en tiempo real, y en este sentido es esencial un buen conocimiento de programación orientada a objetos: y sí, quizá álguien se ofenda, pero en las aplicaciones de gestión se hacen muchas guarradas, y realmente he visto muy pocas aplicaciones de gestión (sinó ninguna) orientada totalmente a objetos –y puedo decirlo de primera mano, he trabajado en la empresa de IT más grande de España y la tercera de europa (no diremos nombres…)-. En definitiva, que en un juego el código bien hecho es lo más sagrado.

 

En Robot Strike Bowling intenté seguir estas premisas. Era mi primer juego completo y sí, como tal cometí muchos errores. Se podría decir que algo he aprendido de ello: Es imprescindible realizar un diseño detallado de la arquitectura de la aplicación, paralelamente a pruebas realizadas directamente sobre Visual Studio (los diagramas UML son muy bonitos y quedan muy vacilones –soy arquitecto de software! dicen algunos con el pecho rebosante de orgullo…-, pero tendemos a dibujar cosas que luego en un juego pueden no funcionar como esperamos). Así que hay que tragarse el orgullo de ingeniero y usar el visual studio…

Personalmente no trabajo directamente con el diagrama de clases de visual studio. Primero me hago un Visio, y luego voy pasando algunos trozos a Visual Studio, y voy probando… detecto que he hecho fallos en el diseño, los arreglo en VStudio, lo arreglo en el Visio… y hago unas cuantas iteraciones en este sentido. No se si es la mejor forma pero a mi me está funcionando.

GameLibraries En este diseño hay que plantear muy bien que es lo que queremos hacer. Muy especialmente: la gestión de estados, forma de renderizar los gráficos, sprites, animaciones, modelos 3D… Yo recomiendo poner todo lo que sea genérico en una librería de clases. En concreto en XNA les llamamos “Game Libraries”, como se muestra en la foto.

 

Usar una Game Librarie nos permitirá separar los objetos genéricos del juego de los objetos concretos. Por ejemplo la clase “Sprite” podría estar en la Game Library y la clase “NaveMala”, que hereda de Sprite, estaría en el proyecto de XNA Game. Esta decisión puede variar… dependiendo del proyecto podríamos decidir poner “NaveMala” en la GameLibrary, o incluso en una segunda GameLibrary (seguramente esta sería la mejor opción).

Usar esta opción se traduce en que tenemos un juego separado en capas. Que nos permitirá hacer cosas como esta:

 

En este caso estamos hablando de un generador de animaciones, pero podría ser perfectamente un editor de niveles. Estas herramientas, que integran XNA con Winforms, tienen una importancia crucial en el ciclo de vida del desarrollo de un juego. Nos permite tener una lógica separada del contenido.

En este ejemplo concreto, que corresponde al próximo juego que estoy preparando, cuyo codename es “Ultimatum to Earth”, he creado un editor de animaciones que puede utilizar cualquier usuario, no necesariamente un programador –lo cual se traduciría, en una reducción de costes y aumento de la productividad-. Esta animación se serializa como XML, posteriormente este XML puede ser deserializado por la GameLibrary y utilizado en nuestro juego, evitando lo que de otra forma sería un montón de código en nuestro juego! Provablemente hacer este tipo de animaciones directamente desde código sería mucho más lento (codificar, ejecutar el juego, probar, volver a empezar, lo cual vendría a ser prueba-error!). En cambio con una aplicación que lo genere, y que permita tener una vista previa en un entorno real de XNA visualmente, hace que el proceso sea más fácil para el usuario, y seguramente se terinará traduciendo en mejores animaciones (dudo que muchos programadores sean buenos animadores).

Todo esto sería imposible (o una monumental e inviable chapuza) sin un proyecto GameLibrary.

Una última ventaja del GameLibrary, es que puede terminar convirtiéndose en un Framework própio para el desarrollo de videojuegos, por lo que hacer una saga de “Ultimatum to Earth” sería mucho menos costoso.

Posted: 6/11/2010 11:03 por Jesús Bosch | con 6 comment(s)
Archivado en: ,
Comparte este post:

Comentarios

Miemblogs ha opinado:

Cómo muchos ya sabéis, hará poco más de un mes terminé la primera

# November 8, 2010 7:03 PM

Tyler ha opinado:

Eiiii!!! si es que no paras!!! el código está visible para el resto de mortales??

Saludos!!

# November 8, 2010 7:55 PM

Jesus Bosch ha opinado:

Hola Tiler;

Bueno es verte por aqui :) Perdon por las faltas que estoi con un teclado estrajero...

El caso es que este codigo no puedo hacerlo publico... el juego se vendera en el marketplace i por tanto ahora mismo no puedo abrirlo.

Saludos!

# November 9, 2010 12:38 AM

Eduard Tomàs i Avellana ha opinado:

"Ultimatum to Earth"... Espero que el juego sea mejor que la peli, porque sino... :P

Aunque viniendo de tí, no lo dudo!! ;-)

Un saludo!

# November 9, 2010 8:25 AM

adrigm ha opinado:

Totalmente de acuerdo en separar el juego en lo que llamas capas. Yo vengo del mundo de Python y Pygame y tenía ya un mini motor hecho en pygame con clases genéricas para cargar sprites, hacer animaciones, etc. Y a la hora de programar un juego ya no tenía que llamar a Pygame (la biblioteca gráfica) sino que todo lo automatizaba la llamada al pequeño engine que hacía las cosas genéricas, por ejemplo, un personaje heredaba de la clase sprite del engine.

Ahora estoy empezando con XNA y aún estoy en lo básico, a ver si puedes escribir más acerca de la GameLibrary y tus ideas de desarrollo, suena muy interesante.

# November 10, 2010 2:36 AM

Rafael Muñoz ha opinado:

Hola Jesus, me ha parecido muy interesante este artículo, ultimamente muchas cosas, y cuanto mas hago mas tiempo le dedico al esquema general y menos a picar código, jeje. Esta bien saber que no es una enfermedad mía.

Me ha sorprendido cuando decías que suscribirse a eventos es lento. En principio un evento es una lista de delegados así que si no hay una miriada de delegados suscritos ¿no tiene por que ser lento no?

En el caso de que lo sea, que solución usas tú. Actualemnte estoy trabajando en un juego para WP7, y uso los eventos, no creo que se vayan a comer el movil, simplemente esta bien saber otras formas.

Gracias por tu tiempo,

Saludos!

# December 5, 2010 7:24 PM