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.
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.
