Postmortem (III)

Elección del motor gráfico

La elección del motor gráfico se realizó en función de la facilidad para utilizarlo, sin olvidar las características que ofrecía, que en principio para nuestro proyecto debían ser las básicas: mostrar objetos en la pantalla y disponer de algún método para animarlos. En principio se pensó en utilizar el motor gráfico utilizado en el desarrollo de Vórtice. El problema de este motor es que es difícil de utilizar, ya que incorpora pocas explicaciones acerca de cómo utilizarlo en su documentación, limitándose prácticamente a mostrar ejemplos de su uso sin apenas comentarios.

Por otra parte también necesitábamos un motor que soportase formatos de archivos de animaciones conocidos,  puesto que nuestra idea era la de reaprovechar modelos de personajes disponibles en Internet debido a que la realización de estos modelos con sus respectivas animaciones llevaría un tiempo considerable, del que no disponíamos.

Así, de todos los motores estudiados, el que mejor cumplía nuestras expectativas era Ogre3D. Este motor gráfico es muy potente, tanto que se puede utilizar en juegos comerciales (bajo cierta licencia de uso) y además existe multitud de información sobre su utilización, desde manuales hasta tutoriales y ejemplos de código concretos sobre algunas de sus características. Además soporta un formato de archivos de animación de modelos propio, fácilmente obtenibles mediante las utilidades de exportación para los principales programas de modelado 3D (como por ejemplo 3DS MAX).

Para la realización de los modelos animados, era necesario realizar previamente algunos pasos de conversión. Los modelos utilizados en el proyecto son modelos diseñados exclusivamente para Quake2. Estos modelos se encuentran comprimidos en archivos de extensión .md2 que contienen tanto la descripción del modelo como de todas sus animaciones, archivos de texturas y de audio especiales para ese modelo. Lo que nos interesaba a nosotros eran únicamente el modelo del personaje y las animaciones. El primer paso era obtener el contenido de los archivos m2d, ya que estaban comprimidos en el original. Para ello se utilizó un programa de edición de modelos 3D llamado MilkShape 3D. Este programa se utilizó tanto para descomprimir el contenido de los archivos como para definir los modelos finales a utilizar en Ogre 3D, gracias a su exportador de modelos.

La elección del motor gráfico fue la más acertada, puesto que a la hora de implementar el módulo de gestión de gráficos resultó ser ideal al separar completamente la representación visual del juego de la lógica interna del programa.

Para las pantallas del interfaz de usuario se utilizó  la librería CEGUI que se adaptaba perfectamente a Ogre 3D. Esta librería permite crear interfaces de usuario de una manera cómoda y rápida. De esta forma ahorramos tiempo en la creación de estos interfaces gráficos.

El único conflicto entre módulos de gran importancia que tuvimos en el desarrollo del proyecto fue causado por la utilización de Ogre 3D y Zoidcom. Ambas APIs sobrecargan los operadores de creación y destrucción de instancias de clases (new y delete). El problema surge a la hora de compilar el proyecto, ya que el compilador interpreta las sobrecargas como distintas y se pierde al intentar encontrar la adecuada, fallando en la compilación. Para resolver este inconveniente, que por otro lado es uno de los más graves y que más tiempo llevó solucionar, se optó por incluir las cabeceras include de Zoidcom antes de las de Ogre 3D siempre. De esta forma conseguíamos que las sobrecargas de los operadores que prevalecieraneran las de Ogre 3D y el compilador siempre las detectara como esas.

Desarrollo del módulo de red

La principal diferencia en la orientación de este módulo para Battle Arena respecto del desarrollado en Vórtice es que desde el primer momento se ha intentado desarrollar este módulo pensando en la modalidad cliente-servidor del juego. En el caso de Vórtice uno de los problemas de este módulo era que se había desarrollado por separado la parte cliente y servidor, por lo que al realizar las pruebas de integración se produjeron numerosos problemas.

Para el desarrollo de este módulo se ha utilizado el API de red Zoidcom. De entre todas las librerías estudiadas para manejar este apartado, Zoidcom resultó ser la más fácil de incorporar al proyecto. Se trata de un API altamente eficiente y flexible que incorpora incluso mecanismos para la interpolación del movimiento en base a algoritmos de dead reckoning. El inconveniente de esta librería es que distribuye el código dedicado al manejo de la red en diferentes puntos del proyecto, lo que lleva a que este código no esté centralizado en un único punto dentro de todo el código general del proyecto, y por tanto dificultando su mantenimiento o modificación en el caso de querer utilizar otro API de red, por ejemplo.

Aún así, el punto de vista del que parte Zoidcom en el diseño de aplicaciones de red es el más adecuado, ya que todas las actualizaciones del estado de los objetos se realizan inmediatamente mediante la utilización de mecanismos internos del API, haciendo transparente su uso de cara al programador. Así por ejemplo sólo es necesario indicar a Zoidcom qué atributos de una clase se deben replicar para que cada vez que se cambie su valor en el servidor se actualice inmediatamente en el cliente.

Zoidcom permite trabajar en varios niveles de complejidad. Se puede utilizar Zoidcom para establecer conexiones de red entre cliente y servidor  y gestionar manualmente el tráfico de red, o bien se puede dejar a Zoidcom que realice el sólo todas las tareas, como por ejemplo sincronizar objetos entre cliente y servidor. Cada vez que se produce un cambio en una variable monitoreada por Zoidcom, la librería se da cuenta de este cambio y actúa enviando actualizaciones a los clientes o servidor.

Mucho más importante es la característica que ofrece Zoidcom en cuanto al movimiento de los personajes. Como ya se comentó anteriormente, Zoidcom ofrece mecanismos de interpolación y predicción de la posición de los personajes mediante algoritmos de dead reckoning. Antes de pensar en utilizar Zoidcom para realizar esta función, se intentó realizar algunas pruebas manuales con este tipo de eliminación del lag en el juego, pero con resultados poco satisfactorios. Fue entonces cuando pensamos en confiar en Zoidcom para realizar todas estas tareas a bajo nivel con unos resultados válidos.

Por lo demás, la integración del módulo de red no provocó ningún problema, puesto que la programación con este API es sencilla y en general con la documentación del manual ya es suficiente para montar un sistema de gestión de tráfico de red.

Los comentarios están cerrados.