Postmorten (III)

Primeras pruebas en red

La programación de todos los módulos anteriores tuvo una duración aproximada de cinco meses. En mayo de 2004 ya se contaba con todos los módulos listos e incorporados al cliente y al servidor. Era entonces el momento de comenzar con las primeras pruebas. A medida que se realizaron las pruebas se fueron descubriendo pequeños bugs que se solucionaron en poco tiempo. La solución a dichos bugs no planteó excesivas dificultades, si bien algunos fueron bastante difíciles de encontrar y reparar.

En ese momento aún no estaba construido el soporte gráfico del cliente, por lo que para la realización de estas pruebas empleamos una sencilla representación basada en modo texto para el cliente.

La elección del motor gráfico

La misión fundamental del cliente de Vórtice es la de representar sonora y visualmente la acción del juego en cada momento, de cara al jugador. Por tanto el motor gráfico se convierte en una parte esencial del cliente. La necesidad de incorporar dicho motor viene dada por razones de eficiencia y comodidad, ya que su uso evita al programador tener que trabajar a bajo nivel con el hardware. La elección de un motor gráfico para Vórtice fue uno de los problemas que más dificultades planteó durante el desarrollo.

En primer lugar se probó con el Avatar Graphics Engine 1.0, un motor en fase experimental desarrollado en el ámbito del Gamelab. Este presentaba un manejo sencillo y gran facilidad para la representación de elementos 2D, pero pronto se comprobó que mostraba limitaciones en el apartado tridimensional que obligaron a buscar otra alternativa.

Posteriormente se trabajó con Truevision3D 6.2, un motor más potente y testeado que presentaba multitud de funciones y efectos gráficos. Esta parecía que sería la elección definitiva; tanto es así, que se trabajó con él durante gran parte del desarrollo. Sin embargo en aquel momento se trataba de un motor más orientado a su uso en Visual Basic, por lo que presentaba ciertas incompatibilidades con C++. Esto, unido a otros problemas para soportar los modelos 3D de que disponíamos (MD2 y X) hizo que finalmente tuviéramos que prescindir de él.

Aún probaríamos con dos motores más: en primer lugar el Ogre Engine 0.13.1. Se trata de un motor gráfico orientado a objetos bastante popular en el mundo 3D. También es bastante potente y dispone de gran cantidad de funciones, así como la documentación más completa de todos los motores que analizamos. Fue su dificultad de manejo la que nos llevó a no utilizarla como opción definitiva.

Finalmente, se optó por trabajar con el Irrlicht 3D Engine v0.6 Stable. Además de tratarse de un motor gratuito (como los anteriores) y de código abierto, nos convenció su fácil manejo, la perfecta integración con Visual C++ y su soporte para múltiples formatos 3D, características todas ellas que no encontramos en ninguno de los anteriores.

El Vortex Graphics Engine

Toda esta búsqueda de un motor gráfico que se adaptara a nuestras necesidades constituía un lastre que retrasaba el desarrollo de las otras partes del cliente. Para evitar en buena medida este retraso, se optó por crear lo que llamamos el Vortex Graphic Engine (VGE), que no es otra cosa que una capa de abstracción de software que concentra todas las llamadas que el cliente realiza al motor gráfico.

Esta capa maneja sus propios tipos y estructuras de datos, que comparte con el resto de la aplicación. Así, todas las llamadas a las funciones del motor gráfico se eliminaban de los restantes módulos y se sustituían por llamadas al VGE, que es el único módulo que interactuaría con las funciones pertinentes propias del motor. De este modo logramos hacer a los restantes módulos de la aplicación independientes de un motor gráfico concreto.

Motor gráfico antes de usar el VGE

Motor gráfico antes de usar el VGE

Motor gráfico después de usar el VGE

Motor gráfico después de usar el VGE

Esta decisión nos permitió ahorrar bastante tiempo, ya que al cambiar un motor por otro, ya no era necesario modificar todos los módulos que interactuaban con él, sino únicamente el VGE. Además, al concentrar todo el tratamiento gráfico en un solo módulo, resultó más sencillo desarrollar toda la gestión de la representación visual, en especial para el sistema de cámaras y el Heads-Up-Display (HUD), que informa al jugador durante el juego del estado de su personaje en todo momento.

La integración de los modelos 3D

Personaje AlligatorDurante la primera parte del proyecto contamos con la colaboración de nuestro compañero Eduardo Fernández Quiñones (a quien agredecemos la ayuda que nos prestó) en calidad de modelador 3D y animador, para construir los personajes y objetos del juego. En principio comenzó trabajando con 3DStudio Max en base a los bocetos que nos suministraron desde la Escuela de Arte, para más tarde desarrollar algunos modelos originales.

Sin embargo, un fallo técnico en la máquina que servía de repositorio para los modelos ocasionó la pérdida de la práctica totalidad del trabajo realizado. Esto ocurrió en Junio de 2004. Ante este contratiempo, y dado que en ese momento ya era necesario contar con los modelos definitivos, nos vimos obligados a modelar por nuestra cuenta los objetos del juego, empleando 3DS Max y MilkShape 3D. Para los modelos de los personajes, recurrimos a modelos gratuitos que obtuvimos en Internet. Decidimos emplear un modelo de tipo X (Dwarf) tanto para uno de los protagonistas como para los enemigos, aplicándoles diferentes skins para diferenciarlos. También incorporamos el modelo del hada, un modelo de tipo MD2 originariamente ideado para Quake II.

Dado que la incertidumbre sobre qué modelos se acabarían utilizando se mantuvo hasta las últimas fases del desarrollo, se incorporó en el cliente un módulo nuevo: el módulo Models. Este módulo consiste en una especie de base de conocimiento que contiene información sobre los modelos 3D que maneja la aplicación (su tipo, sus dimensiones, su orientación, las animaciones disponibles, etc). Su misión consiste en suministrar al VGE estos datos para que éste sepa cómo representar dichos modelos durante el juego.

De esta forma evitábamos depender de unos modelos concretos, pudiendo trabajar con modelos de diferentes tipos y características. Además, la inclusión de este módulo hace que sea muy sencillo capacitar al cliente para emplear modelos 3D externos, lo que permitiría a un jugador utilizar sus propios modelos para su personaje. Este es un apartado que finalmente no se pudo completar por falta de tiempo, si bien es susceptible de ser realizado en una hipotética futura versión.

Últimas pruebas y puesta a punto

A finales de Agosto de 2004 ya contábamos con una versión plenamente funcional y con todos los módulos integrados tanto en el servidor como en el cliente. Las siguientes semanas las dedicamos fundamentalmente a realizar pruebas de rendimiento tanto en partidas a través de LAN como por Internet.

Si bien en el juego en red local -una vez corregidos varios fallos menores- se obtuvieron buenos resultados, las pruebas realizadas a través de Internet resultaron algo decepcionantes, ya que el retardo de la red provocaba en ocasiones saltos que afectaban directamente a la jugabilidad del juego. Para corregir este problema, probamos a variar la frecuencia de actualización del servidor a los clientes, consiguiendo importantes mejoras. En el momento de la presentación de Vórtice, en Septiembre, aún no habíamos conseguido corregir totalmente este problema, pero no parece ser nada que no se pueda solucionar afinando correctamente los mencionados intervalos de actualización.

Captura Pantalla Vórtice 1   Captura Pantalla Vórtice 2Captura Pantalla Vórtice 3   Captura Pantalla Vórtice 4

Llegados a este punto, solo resta mencionar que el producto final nos resultó bastante satisfactorio, especialmente teniendo en cuenta las dificultades y los retrasos ya comentados, y que en líneas generales cumplimos con el objetivo que nos habíamos marcado desde el inicio: lograr la integración de distintas tecnologías para obtener un prototipo de un videojuego original y jugable.

Los comentarios están cerrados.