Inicio del desarrollo de Battle Arena
Una vez que la idea del juego estuvo clara, se comenzó a diseñar como sería la estructura interna del juego. Para ello se diseñó un diagrama de módulos a alto nivel que permitiese ver los distintos componentes que formarían la estructura interna del juego y como se relacionarían entre ellos. Este diseño de módulos se remodeló muchas veces hasta dar con una estructura de módulos adecuada. Los módulos que componen el proyecto debían mantenerse independientes entre sí lo máximo posible. Además siempre se trabajaba con la idea de integrar en el proyecto diferentes tecnologías y librerías externas, lo que implicaba que el diagrama de módulos se adaptara a estas características.
Durante la fase de diseño de módulos del juego se decidieron también otros aspectos de desarrollo del juego. Decidimos que el juego se programaría en C++, empleando la plataforma Visual Studio .NET. Estas elecciones fueron las más correctas, puesto que C++ es un lenguaje que genera ejecutables rápidos y todas las librerías utilizadas estaban disponibles en este lenguaje y en especial precompiladas para Visual Studio .NET. La elección de un lenguaje como Java quedó desechada por ser muy lento, aunque hubiese sido más fácil programar en este lenguaje. La otra alternativa estudiada era C#, pero también fue descartada debido a la incompatibilidad de las librerías externas con este lenguaje.
¿Elección o implementación de un módulo de Red?
Este es uno de los puntos más críticos del proyecto y en el que primero se empezó a trabajar. Debíamos encontrar una librería de red que fuese lo más eficiente posible y a la vez sencilla de trabajar con ella. En caso de no encontrarla, sería necesario desarrollar una API de red propia basándose en otra API como DirectPlay, Sockets, RPC, etc.
En Vórtice habíamos implementado un módulo de red específico para el juego, partiendo de cero y basado en DirectPlay. El principal problema que presenta DirectPlay es la casi total ausencia de documentación que existe sobre el tema. Apenas existen tutoriales y los pocos que hay o bien están obsoletos (versiones anteriores de DirectX a la actual, la 9.0c) o bien están diseñados para utilizar otro tipo de lenguaje de programación diferente al C++ (por ejemplo Visual Basic). De esta forma, sólo se podía recurrir a la documentación proporcionada por Microsoft en el SDK de DirectX, que en su mayor parte se limita a la descripción de las funciones que proporciona la API. También se utilizaron los tutoriales que venían en el SDK, pero generalmente eran bastante difíciles de entender.
Por suerte para el desarrollo de Battle Arena habían disponibles varias librerías de red donde escoger, eliminando de esta forma la necesidad de implementar el API específico para el juego. Se estudiaron varias alternativas: OpenTNL (Torque Network Library), GNE (Game Network Engine), ReplicaNet, RakNet, HawkNL (Hawk Network Library), GNET y ZoidCom (Zoidcom Automated Network System). El problema que presentan muchas de estas librerías es su complejidad a la hora de utilizarlas. Se estudió su documentación y características que ofrecían y de entre todas se eligió Zoidcom por ser la más sencilla de utilizar y que tenía las características que se necesitaban en el proyecto (especialmente implementación de algoritmos de dead reckoning).
Zoidcom es un muy buen API de red. Incluye una documentación donde se explica paso a paso como integrar las clases de la librería en un proyecto para dar soporte a la red y cómo utilizarlas. Solamente hubo un problema en el desarrollo con este módulo, que se solucionó utilizando una versión actualizada de la librería. Dicho problema consistía en que a la hora de replicar objetos, cuando el objeto era eliminado del servidor (el servidor gobierna la creación y destrucción de objetos), los clientes seguían actualizando el estado de sus objetos replicados, que al no estar presentes en el servidor provocaban un error de ejecución en la librería. Este problema debía de ser un bug en la librería, puesto que en la siguiente versión liberada por su autor, estaba solucionado. Quizá para entender mejor este problema sería necesario entender como hace Zoidcom la replicación de los objetos en el cliente a partir de los objetos presentes en el servidor. Para ello se recomienda leer el manual de Zoidcom donde se explica muy bien esta característica de la librería.
Representación de los niveles y mapas del juego
Los siguientes módulos que se desarrollaron fueron los relacionados con la gestión de la información de la partida y el gestor de información del mapa. Estos dos módulos son muy parecidos tanto en el cliente como en el servidor, por lo que tratamos de ahorrar código y tiempo programando simultáneamente para ambas partes.
Básicamente los niveles de Battle Arena son escenarios 2D formados por muros. Cada mapa del juego está dividido en celdas, donde se colocarán los diferentes elementos que componen los mapas. Estos elementos pueden ser desde los personajes de los jugadores hasta portales de entrada al nivel. Sin embargo, el que una celda esté ocupada por un elemento del mapa no quiere decir estrictamente que sólo pueda contener un único elemento. Así por ejemplo en el caso de los personajes se permite que dos jugadores ocupen la misma celda del mapa siempre y cuando no colisionen ente sí.
Para almacenar esta información en disco se optó por utilizar archivos de texto que contuvieran la estructura del nivel. Más en concreto se utilizaron archivos de texto para almacenar documentos XML con la descripción de la estructura del nivel. XML está muy extendido y por tanto existen librerías que permiten analizar esta clase de documentos. Esto evitó la necesidad de construir un analizador propio para los archivos de mapa, lo que llevaría a crear un procesador de lenguaje y una gramática, con lo que se retrasaría el desarrollo del proyecto. Para analizar estos archivos XML se utilizó el API Xerces-C++ que es una versión adaptada a C++ del conocido Xerces del lenguaje Java. Implementa para el análisis de documentos XML las especificaciones SAX y DOM, de las que escogimos la primera por ser la más fácil de utilizar en el proyecto.
Por un lado ya teníamos resuelto el problema de almacenar la información del nivel, pero queda el mayor problema que es ¿cómo generar esos archivos de texto en formato XML? La idea que surge en un primer momento es la creación de un editor de niveles para el juego. Sin embargo el desarrollo de este tipo de programa, que en principio sería independiente del proyecto, llevaría también mucho tiempo, además de constituir prácticamente un proyecto por sí mismo Es por ello que esta idea se descartó. Así que por lo tanto nos decidimos a utilizar herramientas existentes para poder crear los niveles de una forma automática (aunque más adelante ya se verá como es necesario modificar a mano estos archivos).
Para empezar deberíamos escoger un entorno de trabajo que nos permitiese manejar entornos 3D y cuya finalidad sería la de crear los mapas para los niveles. Además este entorno debería de proporcionarnos un modo de exportar las escenas creadas a archivos cuyo contenido pueda ser analizado fácilmente. Una herramienta ampliamente utilizada y con la que el autor del proyecto estaba familiarizada es 3D Studio MAX. Este era un entorno óptimo, ya que permitía trabajar en 3D y además permitía exportar las escenas a archivos de texto ASE. El formato de estos archivos puede ser consultado en Internet y además existen muchos programas de modelado que lo soportan.
Con 3DS MAX podemos generar dos partes de los archivos de mapas. Por un lado está la parte que delimita las zonas por donde se pueden mover los personajes y los lugares donde se colocan los elementos del mapa, y por otro lado está lo que llamamos entorno del mapa. Este entorno del mapa será el que se utilice para representar el mapa en sí en la pantalla, mientras que la otra parte es la encargada de indicar las posiciones de los elementos del mapa (portales, objetos, etc.) y de marcar los límites del mapa (muros).
Ahora el problema que surge es la necesidad de adaptar los archivos ASE generados con 3DS MAX a documentos XML. Para ello utilizamos un programa de utilidad, desarrollado por nosotros, que extrajera la información necesaria de los archivos ASE y generara archivos XML. Este programa tiene como función la de realizar la conversión de una escena en elementos del mapa que pueden ser escritos en XML. Esto cubre las necesidades para la primera parte de los contenidos de los mapas. La otra parte consiste en la creación del entorno del mapa, básicamente el suelo por el que se mueven los personajes. Para ello es necesario crear una escena nueva en 3DS MAX y guardarla en un formato que admita el motor gráfico usado en el proyecto Ogre3D. Luego habría que modificar manualmente el mapa XML para incluir este entorno.