Postmortem (II)

SDK’s, frameworks y herramientas

En esta parte del postmortem centraremos la atención en las bibliotecas, frameworks, SDK’s y herramientas usadas durante el desarrollo del juego. La mayoría de estas bibliotecas y herramientas son open source.

Desde un primer momento se tuvo en mente que Enter The Death iba a ser un juego para ordenadores de escritorio (PC), al menos inicialmente. No se tuvo en consideración el uso de SDK’s para desarrollo en consolas o dispositivos móviles.

Así mismo también cabe señalar que el juego iba a estar orientado a un uso no comercial, por lo que prima la flexibilidad y libertad a la hora de desarrollar y diseñar el juego, frente a las limitaciones de otros SDKs y frameworks que están enfocados hacia un tipo de juego concreto, acciones concretas, etc. Esto lleva consigo un mayor tiempo de desarrollo ya que implica construir cada una de las partes de las que consta el juego, pero a cambio se dispone de mayor flexibilidad a la hora de diseñar.

Microsoft Visual Studio

Visual Studio 2008

Microsoft Visual Studio es el IDE (Integrated Development Environment) en el que se desarrolla el juego. De entre todos los lenguages proporcionados por Visual Studio (VB .NET, C#, C++, J#, etc. ) los que mejor encajan con el desarrollo de un juego, principalmente por su rendimiento, son C# y C++. La elección de C++ sobre C# como lenguage de programación para Enter The Death se debe a que el motor gráfico usado (Ogre 3D) está implementado de forma nativa en C++, aunque existen wrappers para C# y otros lenguages. También, la gran mayoría de bibliotecas está implementada en C++, dejando claro qué lenguage se debía utilizar.

La versión de Visual Studio con la que se trabaja es la versión 2008.

Visual Leak Detector

Uno de los «inconvenientes» de C++ es que la gestión de memoria se debe realizar manualmente. A diferencia de otros lenguajes como C#, VB .NET o Java, que cuentan con un recolector de basura, en C++ es necesario definir explícitamente el ciclo de vida de los objetos. Por ello se hace necesario el uso de alguna utilidad que permita detectar memory leaks (literalmente, fugas de memoria) y evitar que el programa llegué a hacer un uso excesivo de memoria.

En nuestro caso, la herramienta seleccionada es Visual Leak Detector (VLD). Su instalación e integración con Visual Studio es muy sencilla y ofrece un informe detallado de la memoria no libera al finalizar la ejecución de un programa. Es una herramienta imprescincible en cualquier desarrollo con C++.

Mercurial y HgSccPackage

Mercurial

Puesto que el desarrollo de un juego se trata de un proyecto complejo y de larga duración, se planteó el uso de un sistema de control de versiones como repositorio de código fuente. Se estudiaron principalmente dos sistemas: Git y Mercurial. Ambos tienen características muy similares, pero la elección fue finalmente para Mercurial, principalmente porque se iba a usar un framework de desarrollo que ya se encontraba en Mercurial (este framework es CEGUI, como se verá más adelante) y además contaba con plugins para Visual Studio.

BitBucket

Una vez clara la idea de que se iba a usar un sistema de control de versiones basado en Mercurial, se comezó un estudio sobre las alternativas disponibles. Las preferencias del sistema eran que fuese gratuito y que permitiera gestionar proyectos privados (no open source) ya que inicialmente no se tenía pensado liberar el código fuente del proyecto. De entre todos los sistemas analizados, el que mejores condiciones ofrecía era Bitbucket. Este servicio permite gestionar proyectos privados (y públicos) de forma ilimitada para un equipo reducido de desarrolladores.

Con la decisión tomada acerca del sistema de control de versiones y decidido el servicio que se iba a usar, se barajó la posibilidad de usar un cliente que facilitase la sincronización con el respositorio de código fuente. Para ello se escogió el plugin HgSccPackage que se integra perfectamente con Visual Studio.

Ogre 3D

Ogre 3D

Ogre 3D es un SDK open source para el desarrollo de aplicaciones 3D. A diferencia de otros SDK’s (como por ejemplo Unity3D, Torque3D, Unreal Engine o CryEngine) no es un motor de juegos, si no que se trata únicamente de un motor de renderizado que se puede integrar con cualquier otro componente. Esta flexibilidad, junto con su facilidad de uso, es la que determinó su uso para el desarrollo del juego.

Otra de las ventajas de usar este SDK frente a otros, es que ya contaba con la experiencia en otro proyecto: Battle Arena.

OIS

Inicialmente, Ogre 3D incluía un sistema rudimentario para tratar la entrada por parte del usuario (teclado y ratón principalmente). A medida que pasaba el tiempo se contempló la posibilidad de tratar este módulo como un proyecto independiente, que a fin de cuentas no tenía que ver con la función principal del SDK, que era renderizar gráficos. Así surgió el proyecto OIS (Object Oriented Input System).

OIS se integra perfectamente con Ogre 3D, ya que es de donde surgió. Como las funciones de control del personaje en Enter The Death iban a ser con el teclado y ratón, OIS cubre perfectamente esta función. Aún así, también soporta el uso de gamepads y joysticks.

CEGUI

CEGUI

Un punto en el que no destaca Ogre 3D es en el apartado de la interfaz de usuario o GUI. A pesar de contar con elementos para dar soporte a esta función como son textos, overlays y widgets sencillos, esto no cubre las necesidades de un GUI para un juego.

Para ello se utilizó CEGUI (Crazy Eddie’s GUI). Este proyecto también tuvo su origen como una extensión de Ogre 3D que permitía mostrar interfaces de usuario de forma sencilla. Sin embargo, a día de hoy, se integra de forma genérica con otros motores gráficos: OpenGL, Direct3D e Irrlich.

CELayoutEditor2

Se trata del editor de ventanas GUI de CEGUI que permite diseñar de forma muy intuitiva el contenido de las mismas y ofrece una paleta muy completa de widgets y temas que se pueden usar directamente.

CELayoutEditor2 es la evolución de la versión clásica de CElayoutEditor. Su autor decidió rehacer el código para generar una aplicación más estable y usable. Debido a que es muy dependiente de la versión de Ogre 3D que se utilice, es necesario compilar los fuentes contra la versión de Ogre 3D que se vaya a utilizar. El código fuente está escrito en Python y es accesible desde un repositorio basado en Mercurial.

CImg

CImg Library

CImg es una biblioteca de funciones escrita en C++ para procesar y gestionar imágenes de diferentes formatos.

La necesidad de utilizar un API para gestionar imágenes surgió cuando se diseñaron los mapas de alturas de los niveles. Estos mapas se basan en imágenes BMP en escala de grises que indican la altura del suelo de cada punto del mapa. Por ello es necesario acceder a cada píxel individual de la imagen para convertirlo en una altura. Es en el acceso a esos píxeles cuando entra en juego esta biblioteca.

Audiere

Audiere

Audiere es un API escrito en C++ para reproducir y controlar sonidos en el juego. A pesar de no actualizarse desde hace mucho tiempo (desde 2006), sigue siendo un API muy potente para trabajar con sonidos.

También cabe señalar que se ha utilizado en Battle Arena con muy buenos resultados, por lo que se decidió incorporar al juego como API de sonido.

Xerces

Apache Xerces

Xerces es un procesador que analiza, valida y manipula datos en formato XML. Se trata de un proyecto open source de The Apache Software Foundation. Existen implementaciones en diferentes lenguages, aunque en nuestro caso nos centraremos en Xerces C++ XML Parser.

La información de los mapas de Enter The Death está guardada en archivos XML, que contiene todo lo necesario para generar los niveles del juego. Para procesar esta información se hace indispensable el uso de una biblioteca que permita cargar un documento XML en memoria y ofrezca mecanismos para interpretarla.

El método elegido para procesar documentos XML es SAX en lugar de DOM. Como los archivos se cargarán una única vez, SAX permite obtener un mayor rendimiento que DOM al lanzar eventos cada vez que procesa un nodo del documento XML. DOM en su lugar carga todo el documento en memoria y permite acceder a cualquier nodo. Los archivos de mapa se descartan una vez leídos, por lo que carece de sentido tenerlos almacenados en memoria.

Autodesk 3ds Max

3ds Max

Todos los modelos del juego, desde los modelos de personajes hasta el modelado de los niveles han sido creados con 3ds Max 9.

OgreMax Scene Exporter

OgreMax es un plugin para 3ds Max que permite exportar las mallas de los modelos hechos en 3ds Max al formato nativo de Ogre 3D (formato MESH). Ofrece también un exportador para Maya y un visor de modelos.

Con OgreMax se puede exportar directamente la información de los materiales y animaciones del modelo realizado en 3ds Max a un formato conocido por Ogre 3D. Con esto se evita la creación de una herramienta de conversión de modelos, reduciendo el tiempo de desarrollo.

Cannonfodder’s 3DS Max Importer/Exporter

Este plugin se engloba en una serie de herramientas desarrolladas por Cannonfodder para trabajar con los recursos de Half-Life 2.

En Enter The Death se utilizan los modelos de personajes en formato MDL como base, que es el utilizado por el motor de Half-Life. Para ello es necesario decompilar estos archivos e importarlos en 3ds Max. Es aquí donde entra en juego este plugin, que permite importar directamente el modelo en 3ds Max, incluyendo sus animaciones y materiales, y trabajar con él.

NSIS

NSIS

NSIS (Nullsoft Scriptable Install System) es un sistema open source para crear instaladores de Windows. Enter The Death utiliza este sistema para generar el instalador del juego.

Este sistema se basa en la creación de un script que contiene todas las acciones a realizar durante el asistente de instalación. Como la creación de este script es una labor compleja, se utiliza una herramienta llamada HM NIS Edit, que facilita enormemente esta labor e incluye algunas automatizaciones.

Los comentarios están cerrados.