Independencia: juego de estrategia en 3D basado en hechos importantes de la campaña libertadora de Colombia (página 3)

Posteriormente, el jugador también puede configurar las opciones dentro del juego, tal y como son el sonido y la música, así como las propias del juego. Dentro de la configuración del sonido y la música se estableció que el jugador pudiera al menos determinar el volumen tanto de la música como de los efectos de sonido empleados en el juego y mediante las opciones propias del juego se buscó que el jugador pudiera establecer el nivel de dificultad, pudiendo elegir entre fácil, medio o difícil.

Figura 19. Diagrama de casos de uso general de Independencia.

La otra acción que puede realizar el usuario es jugar en modo campaña la misión implementada para el juego, para lo cual el jugador en primer lugar puede visualizar la historia y los objetivos de la misión y luego pasar a ejecutarla. Todas las acciones que puede emprender el jugador en esta parte de la aplicación, se resumen en el diagrama de casos de uso mostrado en la Figura 20. En él se afirma que el jugador puede seleccionar una unidad, lo cual implica desplazar el puntero del ratón hasta que se encuentre sobre la unidad y luego hacer clic. Una vez seleccionada la unidad, el jugador puede moverla, esto se logra haciendo clic derecho sobre la parte del terreno a la cual desea mover la unidad. El jugador puede también, ordenar a la unidad seleccionada que ataque, para lo cual debe hacer clic derecho sobre la unidad enemiga que desea atacar. Adicionalmente, Si la unidad seleccionada es el prócer, el usuario puede ordenarle que emita el grito comunero, esto se hace dando clic sobre el botón para lanzar el poder especial del prócer. Este botón estará activo siempre y cuando el prócer pueda emitir el grito comunero, ya que cada vez que lo haga deberá esperar unos segundos hasta que pueda volverlo a hacer.

Figura 20. Diagrama de casos de uso para la etapa de Juego de Independencia.

Una vez que el sistema valida que el jugador ha cumplido con los objetivos de la misión, se dice que ésta se completó, por lo cual se le presenta al usuario una pantalla en la cual puede visualizar los resultados de la misión. Estos resultados también son mostrados al jugador cuando éste decide abandonar el juego sin que haya terminado.

En la etapa del juego, el jugador también puede interactuar con el mini mapa y desplazarse por el terreno, tal como lo hace en el editor de terrenos, además cuando lo desee, puede visualizar la misión para luego continuar jugando.

Modelados los casos de uso, tanto de la aplicación en general, como el juego en sí, se procedió a crear los diagramas de clases necesarios para definir la estructura de la aplicación. Estos se dividen en dos: en el primero de ellos (Figura 21) se muestran a modo general, las clases de cada uno de las diferentes pantallas de la aplicación y en el segundo (Figura 22), se detallan las clases involucradas en la campaña del juego. En ambos diagramas se reutilizaron clases que ya se habían diseñado en aplicaciones anteriores, tal y como es el caso de la clase CDlgPreferencias creada en el visor de modelos y CBuscaCamino diseñada en el buscador de caminos.

Figura 21. Diagrama de clases de aplicación de Independencia.

El diagrama de clases mostrado en la Figura 21 es fruto de la experiencia y el conocimiento adquiridos en las aplicaciones anteriores donde se determinó que la funcionalidad ofrecida al usuario por una pantalla de la aplicación debería estar encapsulada en una clase que a su vez controlara la lógica necesaria para brindar el servicio. En este caso, mediante la clase CPantallazo se obtiene la funcionalidad necesaria para recibir mensajes desde la aplicación (CAppIndependencia) y pasarlos a cada uno de objetos que se hayan definido en una clase descendiente. Estas clases que heredan de CPantallazo, a su vez sirven como escuchadores de eventos de los objetos que contienen y se encargan del control de la lógica.

Cabe anotar que CAppIndependencia hace uso de una máquina de estados finitos para definir las diferentes etapas de la aplicación, donde cada uno de los estados de la máquina se representa por un valor definido dentro de la enumeración EN_ETAPA_JUEGO. En cada etapa se identifica la pantalla que se debe mostrar al jugador y los cambios entre estados se realizan por medio de un mensaje enviado desde la clase que muestra la pantalla actual hacia la aplicación.

Cuando la aplicación inicia se muestra la primera etapa que es la presentación (CPresentacion), seguida por un menú de inicio (CInicio) desde donde se puede configurar las opciones del juego (CConfiguracion) o iniciar el juego en modo campaña, para lo cual se muestra la misión (CMision) y se procede luego al desarrollo del juego como tal (CJuego). Una vez terminado el juego se muestra el resumen del mismo (CResumen).

Respecto al diseño de la etapa de juego, se debe apreciar que se utilizó el modelado hecho con GAIA para definir las clases mediante las cuales se crearían los agentes que modelan el comportamiento de los personajes. Estas clases, posteriormente se integrarían con el resto del diseño del juego y se verían reflejadas en la clase CUnidad y sus respectivas especializaciones, las cuales deberían implementar los servicios definidos para el tipo de agente AgenteUnidad.

Por tratarse de un agente, la clase CUnidad debía tener capacidad de procesamiento autónomo, por lo cual se le definió el método Ejecutar( ), mediante el cual la aplicación le puede ceder el control al agente para que éste realice sus procesos.

En el diagrama de la Figura 22 se muestran las clases de la etapa de juego de Independencia, incluyendo la clase CUnidad y sus descendientes. La campaña del juego se diseñó mediante la clase CJuego, que contiene información del terreno, la cámara, el mini mapa, la lista de unidades comuneras y españolas, la música y los sonidos, y la ayuda.

Figura 22. Diagrama de clases de juego de Independencia

IMPLEMENTACIÓN

Al enfrentar la etapa de implementación la primera tarea que se realizó fue la de definir claramente un documento de estándares de programación y documentación del código fuente generado para el proyecto (Ver ANEXO A), esto con el fin de tener las reglas claras para el nombrado de clases y variables, la documentación y el control de cambios entre las modificaciones hechas por parte de los desarrolladores. Gracias al seguimiento de lo estipulado en dicho documento y al uso de Visual Source Safe para comparar los archivos de código, se facilitó la tarea de unificar el trabajo realizado individualmente.

En esta sección se hará énfasis principalmente en los problemas de implementación que se presentaron en las diferentes aplicaciones que se desarrollaron y las soluciones que se dieron, antes que hacer un resumen de clases y mostrar su codificación. De esta manera, se abordarán en primera instancia los problemas que surgieron en la creación del Motor 3D, para luego continuar con los presentados en el visor de modelos, el editor de terrenos, la aplicación para búsqueda de caminos y finalizar con los que se dieron en la creación de Independencia.

CREACIÓN DEL MOTOR 3D

En el diseño del Motor 3D, había un requerimiento que especificaba que este debía ser independiente del juego, lo cual suponía una librería aparte que soportara la funcionalidad necesaria para la creación de juegos. La solución a este requerimiento fue la creación del Motor 3D como una librería de enlace dinámico (DLL), que permitiera exportar los objetos que se definieran y mantuviera ocultos los que no se requerían.

Pero debido a que las DLL no soportan herencia para exportar, es decir, si se define una clase base que sea exportable, las descendientes no heredarán esta cualidad. Este inconveniente llevó a pensar en replantear la jerarquía de clases o a una solución menos drástica. Afortunadamente, la solución estuvo al alcance y lo que se hizo fue definirle específicamente el atributo de exportable a cada clase que lo necesitara, sin modificar la jerarquía ya definida.

Posteriormente surgió la necesidad de encapsular el funcionamiento de la aplicación con el fin de dejar las tareas de registro de la clase de Windows, creación e inicialización de la ventana de la aplicación y posterior liberación de estos recursos en una o varias clases del motor. Todas estas actividades se dejaron como responsabilidad de la clase CAplicacion, de la cual heredó la clase CAplicacionD3D. Esta última se encarga de crear e inicializar el dispositivo Direct3D a través de un objeto del tipo CDirect3D para que posteriormente todos los objetos de la aplicación puedan usarlo en las tareas de dibujado.

Un nuevo inconveniente se presentaría al intentar controlar los mensajes provenientes del sistema operativo, determinar qué objeto de los que conforman la aplicación disparó el evento y luego manejarlo adecuadamente. Se pensó entonces, en el uso de un patrón que es usado en algunos lenguajes de programación tales como Java y que consiste en asignar un escuchador para el control de los eventos de cada uno de los objetos. Para lograr implementar este patrón se crearon las interfaces CEscuchadorEventos, CEscuchadorVentana e IObjetivo. El escuchador de eventos sería implementado por las clases que iban a controlar los eventos de ratón y teclado de algunos objetos, la interfaz para escucha de una ventana se usaría para poder controlar los eventos generados los objetos que heredan de CVentana (tal como la ventana principal de la aplicación), y la interfaz IObjetivo serviría para poder implementar objetivos que responden a eventos de ratón y teclado.

Aunque las clases con las que se implementó el patrón escuchador responden bien ante el propósito deseado, su forma de uso en una aplicación puede resultar un poco confusa y difícil de entender para los desarrolladores que por primera vez entren en contacto con el Motor 3D, por lo cual se recomienda revisar la forma en la que se realiza el control de los mensajes de eventos en las aplicaciones creadas durante el desarrollo de este proyecto. De igual manera se recomienda revisar el ANEXO B, en el cual se muestra un ejemplo de cómo utilizar el Motor 3D.

Teniendo ya las bases para la creación de aplicaciones con soporte para Direct3D, se inició la tarea de implementar los objetos con características tridimensionales y en este proceso se tuvo que encontrar, en primer lugar, la forma en la cual se podía realizar la carga, manipulación y dibujado de mallas con animación incluida. Esto se convirtió en una dificultad que generó un retraso en el proyecto, puesto que es de vital importancia para un juego en 3D poder mostrar modelos con diferentes animaciones en el espacio tridimensional.

Luego de investigar la forma en la que se podía realizar la carga y dibujado de los modelos animados se llegó a la implementación de la técnica de mallas con piel (SkinMesh), la cual consiste en cargar el modelo como una jerarquía, donde existe una parte del modelo que es la "raíz" y a esta se le adjuntan las demás partes. Cada parte se toma como un hueso, al cual se le "pegan" los vértices que representan la piel. Además, las animaciones se dan como transformaciones de mundo que en cada parte del modelo dependen de la parte que está arriba en la jerarquía. Así por ejemplo cuando se construye el modelo de una persona, la posición de un brazo, una pierna o la cabeza, dependerá de la posición del tronco en el momento de la animación.

Una vez que se logra cargar y pintar adecuadamente un modelo con información de animación, incluyendo animaciones diversas (por ejemplo caminar, atacar, morir), surgió la necesidad de verificar si el puntero del ratón se encontraba sobre la imagen del modelo animado proyectada en la pantalla. Para dar solución a este problema existen dos técnicas: la primera de ellas consiste en calcular una esfera que pueda contener al modelo a partir de su centro y radio, y luego verificar matemáticamente si el rayo generado por la posición del ratón en la pantalla se intersecta con la esfera, y la segunda técnica usa el mismo rayo para determinar si intersecta alguno de los triángulos que componen la malla del modelo.

De estas dos técnicas, se optó por el uso de la esfera contenedora, ya que los cálculos que se realizan para determinar si el rayo la intersecta son relativamente sencillos y no consumen recursos abundantes en cuanto a procesamiento, mientras que la otra técnica, debe verificar triángulo por triángulo si el rayo intersecta a alguno de ellos, lo cual consume una cantidad considerable de tiempo en procesamiento. Pero es preciso anotar, que aunque la técnica de la esfera funciona, no siempre es la mejor ya que brinda un margen de error considerable debido a que dentro de la esfera que contiene al modelo queda un espacio "libre" que el modelo no ocupa. Esto produce por ejemplo, que cuando haya varios modelos juntos, no responda al evento clic el modelo deseado. Se recomienda entonces hacer una revisión de los requerimientos en cuanto a tiempo de procesamiento y precisión de los cálculos cuando se desee implementar una de estas técnicas, e incluso contemplar la posibilidad de implementar un hibrido de ambas.

El trabajo que se había realizado hasta el momento con los modelos animados era muy bueno, pero aún era necesario tener en cuenta un aspecto que es de gran impacto en el rendimiento y uso de la memoria de un juego y es que, generalmente, se necesita cargar varios modelos del mismo tipo con el fin de mostrarlos dentro de la misma escena pero en una posición diferente y con animaciones heterogéneas. Para lograr reducir la cantidad de memoria ocupada por los diversos modelos de un mismo tipo, se separó la parte lógica del modelo, como su posición, escala y rotación, de la parte que contiene la información de los vértices del modelo y la animación. De este modo, si en un juego se deben mostrar varios personajes con el mismo modelo (por ejemplo, los ciudadanos en EmpireEarth) basta simplemente con crear un objeto del tipo CAnimado en el cual se carga la información de la malla y la animación, y crear tantos objetos CModelo como personajes se necesiten y a cada uno asignarle el animado anterior. Cada objeto CModelo crea un objeto para el control de la animación mediante el uso de la interfaz ID3DXAnimationController del DirectX.

Habiendo finalizado la implementación de las clases para los modelos, se presentó un nuevo reto y consistía en implementar una clase para el terreno. En principio se intentó manejar una malla completa para representar todo el objeto terreno, pero esto se dificultó dado que en un juego de estrategia normalmente el terreno debe ocultarse en las partes en las que no se ha explorado y con una malla esto resulta demasiado complicado de realizar. Además, el objeto para el terreno debe permitir posteriormente "navegar" por el mismo o desplazarse por su superficie, para lo que se debe conocer la información exacta de la altura de un punto en la malla y esto implicaría hacer un recorrido por todos (o la mayoría) de sus vértices. Estas razones motivaron el uso de un terreno compuesto por losas, lo cual permitiría: ocultar las losas que el jugador no ha explorado, aplicar un factor de niebla a las losas que las unidades del jugador no pueden visualizar, obtener la altura exacta de un punto dentro del terreno con el fin de facilitar el desplazamiento sobre su superficie, y posteriormente usar las losas como unidades lógicas para el algoritmo de búsqueda de caminos asumiendo el terreno como una cuadrícula en la cual cada losa puede representar un espacio libre o un obstáculo.

Otro aspecto de gran importancia durante el proceso de implementación del terreno y las losas fue el uso de los conceptos matemáticos de 3D para generar los vectores normales adecuados para cada vértice de las losas de tal forma que al pintar el terreno no se notaran las divisiones o bordes entre losas consecutivas. Adicionalmente, se trabajo con los rayos con el fin de determinar la losa sobre la que se encuentra el puntero del ratón en un determinado momento, lo cual es fundamental para el editor de terrenos y para Independencia.

En la siguiente fase de implementación del Motor 3D se abordaría la construcción de los objetos que se presentan en dos dimensiones y que son usados en la mayoría de juegos, para lo cual se decidió construir los más comunes y que resultan más útiles para crear interfaces de usuario, tales como botones, etiquetas, cajas de texto, cajas de chequeo e imágenes. Estos objetos se construyen como objetos en 3D, pero se muestran en el espacio 2D de la pantalla, por lo que son denominados controles e implementados heredando de la clase CControl. La implementación de esta clase estuvo ligada al inconveniente de hacer que estos objetos siempre se muestren en la pantalla de acuerdo con su posición en 2D y para superarlo se trabajó en el método para pintar el control. En este método se tomó la inversa de la transformada de vista y se fijó como la transformada de mundo, lo que en otras palabras implica que cada vez que se pinta un control se toma éste y se lleva hasta en frente de la posición desde la cual se observa la escena. De este modo los controles siempre se pintan en la misma posición de la pantalla, no importando que la posición u orientación de la vista cambien.

Con los objetos antes mencionados se abarcaban los más importantes y necesarios para la creación de juegos en cuanto a la parte gráfica usando Direct3D, pero es preciso señalar que los juegos recientes hacen uso de las características multimedia que los equipos de esta era poseen y que ayudan en la tarea de atraer y divertir al jugador. Buscando que las aplicaciones creadas haciendo uso del Motor 3D puedan fácilmente implementar este tipo de características, se creó la clase CMedio, la cual se responsabiliza de la carga y reproducción de flujos de audio y video. Para la construcción de esta clase se tomó la experiencia vivida en la creación de Defensor 3D, en la cual se buscó que el juego presentara música de fondo y sonidos de ambiente. En Defensor 3D se usó DirectMusic, pero se pudo apreciar que esta API solo permite la reproducción de archivos de sonido en los formatos WAV, MIDI y los nativos de DirectX. Por esta razón se exploró en la API DirectShow y se encontró que haciendo uso de ella se puede realizar la carga de flujos de audio y video en diversos formatos tales como MP3, WAV, MIDI, MPEG, AVI, DIVX y otros. La clase CMedio hace uso entonces, de esta API para lograr encapsular dicha funcionalidad dispersa en las interfaces que expone DirectShow.

Adicionalmente a las clases que controlan la aplicación, los eventos, la parte gráfica en dos y tres dimensiones y los flujos de audio y video, era necesario incluir en el Motor un conjunto de clases que resultaran útiles para la creación de juegos. Una de ellas es la clase CExcepcion, la cual se construyó con el propósito de que el desarrollador pueda realizar el manejo de las excepciones producidas por el motor. Estas excepciones, regularmente se originan cuando el motor detecta que algún tipo de inicialización que intentaba realizar no fue exitosa.

Otra situación que se presenta muy frecuentemente en los juegos, es el uso de listas para mantener el estado de objetos de algún tipo. Una lista es una colección enlazada de nodos, la cual, dependiendo de la implementación, puede generar retrasos en un juego debido a que se puede necesitar recorrerla muchas veces. Para ayudar con esta situación y dependiendo de las necesidades específicas del juego, el motor brinda dos tipos de estructuras para el manejo de listas: la clase CLista representa una lista lineal enlazada y la clase CTablaClaves es una implementación a modo de árbol binario de una lista que en cada nodo asocia una clave de búsqueda con la referencia al objeto que contiene.

La solución a todos los problemas mencionados en está sección arrojó como resultado el Motor 3D orientado a objetos (para mayor detalle de las clases ver Anexo C), con el que luego se implementaría el visor de modelos, el editor de terrenos, el buscador de caminos y el juego Independencia.

VISOR 3D

Después de obtenido un primer prototipo del Motor 3D y que brindaba la funcionalidad necesaria ya expuesta se procedió a la creación del visor de modelos, que usa la librería de clases, proporcionada por dicho motor, para implementar el diseño definido para el visor.

Se identificó para entonces, que era necesario poder configurar el adaptador de video y de esta manera ofrecer una mayor versatilidad para las aplicaciones que se desarrollaran de ahí en adelante. Para la implementación de esta utilidad se empleó un cuadro de diálogo de Windows que se definió mediante un archivo de recursos y se programó en la clase CDlgPreferencias, garantizando con esto que podía ser reutilizada en las demás aplicaciones.

Un punto a resaltar de la implementación de la clase anterior fue que se empezó a utilizar archivos de configuración, donde se guardaban y podían recuperar las opciones elegidas, con lo cual se empezó a entender las bases de la técnica de scripting, muy utilizada en la implementación de juegos.

Al continuar con la codificación del visor se descubrieron algunas falencias que se presentaban en la clase CAnimado, dentro de las que se contaba el no poder fijar una animación a voluntad ni poder detenerla, por lo que se debió realizar una extensa consulta que proveyera las respectivas soluciones, consistiendo éstas en la utilización de las interfaces ID3DXAnimationSet e ID3DXAnimationController, que ofrecen los servicios para fijar una animación y determinar cuando ha finalizado un periodo de ejecución.

Adicionalmente y gracias al conocimiento adquirido en cuanto al manejo de animaciones se logró profundizar en cuanto a la forma en como están definidos los archivos .x, es decir, se conoció la sintaxis de las plantillas empleadas para la creación de dichos archivos. Esto permitió que se pudiera saber donde encontrar la información referente a las animaciones lo cual fue de mucha utilidad porque después se necesito integrar de forma manual los diferentes archivos de animación de los modelos, ya que el diseñador gráfico (debido a los problemas de exportación del plug – in) solo podía entregar una animación por archivo.

Al finalizar el desarrollo de esta aplicación, se logró el objetivo deseado: el diseñador podía contar con una herramienta que le facilitaba probar los modelos que generaba y los desarrolladores tenían la certeza de contar con modelos que iban a funcionar perfectamente en Independencia. Una imagen de la ventana de la aplicación se muestra en la Figura 23.

Figura 23. Imagen del Visor de modelos.

EDITOR DE TERRENO

Al iniciar la implementación del diseño del editor de terrenos se tuvo un gran tropiezo: sólo los objetos definidos a partir de la clase CObjetivo podían procesar los eventos de ratón y teclado de modo que la aplicación debía conocerlos a todos, y por tanto debía realizar muchas tareas que podía delegar. Esta dificultad llevó a la creación de la interfaz IObjetivo que define los métodos que deben implementar las clases que quieran responder a eventos de ratón y teclado y que no sean necesariamente objetos de la clase CObjetivo. Es así, como a partir de la interfaz se implementaron las clases que controlarían la lógica del menú, de los botones y del mini mapa.

Superada esta situación era momento de abordar la implementación del mini mapa que suponía una instantánea del terreno pero en miniatura y cuyo principal inconveniente radicó en poder modificar la imagen que se iba a mostrar para que reflejara lo que en realidad se observa en el terreno. Fue necesario hacer uso de una superficie (algo así como un lienzo de dibujo) en memoria del sistema para poder modificarla y luego actualizar una textura (una imagen) en memoria del dispositivo que finalmente se dibuja en la pantalla.

Se habían terminado los objetos de la interfaz de usuario del editor de terreno y se había implementado la funcionalidad deseada, obteniéndose un producto robusto que adaptó algunas características de los editores de juegos comerciales como Age of Empires y Rise of Nations. Era hora de empezar a generar terrenos. Pero se presentó un problema porque no se poseían cuadros de diálogo que permitieran pedir un texto al usuario para abrir o guardar los archivos de terreno al igual que cuadros de diálogo que mostraran mensajes.

Se inició la labor de diseñar e implementar cuadros de diálogo para las tareas mencionadas y se consideró su conveniencia dentro de la jerarquía de objetos del Motor 3D, siendo necesaria su inclusión y finalizando con esto la codificación del editor de terrenos. En la Figura 24 se muestra una imagen de la creación de un terreno, donde se detalla un cuadro de dialogo implementado para la selección de opciones para el nuevo terreno.

Figura 24. Imagen del Editor de Terrenos.

BUSCADOR DE CAMINOS

Con el fin de permitir que los personajes del juego pudieran desplazarse por el terreno, se inició la construcción de una aplicación que implementara un algoritmo de búsqueda de camino y permitiera probar los escenarios más comunes que se pudieran presentar. El algoritmo elegido fue el A estrella (A*) y a pesar que existe muy buena documentación acerca de su funcionamiento, cada desarrollador debe adecuarlo a sus necesidades.

Se emprendió el proceso de adaptación del algoritmo a los requerimientos de Independencia y se obtuvo una primera versión que al ser probada arrojó unos tiempos de respuesta demasiado grandes en determinadas situaciones, como por ejemplo cuando se intentaba ir desde una zona libre hasta otra que estuviera encerrada por obstáculos, tal como se muestra en la Figura 25. En estos casos el número de nodos visitados por el algoritmo crecía demasiado dado que una vez llegaba al lado de la frontera que encerraba el destino, empezaba a expandirse hacia los lados, pudiendo visitar toda el área por fuera de la región limitada. Después de hacer el análisis respectivo, se optó por limitar el número de nodos cerrados que el algoritmo podía crear ya que estos nodos determinan cuanto se expande la búsqueda.

Figura 25. Ejemplo de un escenario de prueba para búsqueda de caminos

Fue de gran ayuda también para mejorar el rendimiento del algoritmo, el hecho de haber creado listas que permitieran ordenar los nodos, puesto que la lista que se definió inicialmente (CLista) no soportaba esta funcionalidad. Esta mejora implementada ayudo a que no se tuviera que recorrer toda la lista de nodos abiertos cada vez que deseaba encontrar el de menor costo.

Ya obtenido el algoritmo de búsqueda deseado y estando nuevamente en una fase de pruebas en diferentes escenarios, se notó que los personajes del juego podían pasar por en medio de los modelos de ambientación cuando estos ocupaban más de una losa. La solución a este problema suponía el replanteamiento del diseño del terreno manejado con losas modificándolo de tal manera que hubiera sido necesario cambiar toda la lógica trabajada hasta el momento. Esto no era conveniente en este momento para los intereses del proyecto y había que buscar otra solución menos drástica. Se pensó entonces en el uso de modelos de ambientación planos que estuvieran ubicados por debajo de los modelos más grandes.

Esta última solución no sólo fue creativa, sino que sirvió para añadir otra característica especial al juego como la de permitir que los personajes dieran la sensación de poder caminar por los andenes e incluso se podría pensar en la posibilidad de que ingresaran a las edificaciones.

INDEPENDENCIA

En el momento de abordar la codificación de Independencia, se contaba con un cúmulo de experiencias y conocimiento fruto de los anteriores desarrollos, de tal modo que se sabía como manipular modelos con animaciones, trabajar con terrenos, usar el algoritmo para búsqueda de caminos, e incluso la manera de implementar las diferentes pantallas del juego. Solo hacia falta unir todos los componentes y dar forma a Independencia.

De acuerdo al diseño definido, se debía empezar la creación del tipo de agente AgenteUnidad para que llevara a cabo las labores propias de los personajes dentro del juego, que incluían vigilar, caminar, atacar, recibir ataque, emitir y escuchar el grito comunero y morir. Estas acciones fueron mapeadas a métodos, los cuales eran llamados desde el procedimiento de ejecución del agente de acuerdo con la actividad que se encontraba realizando la unidad en ese momento.

El implementar el método para caminar y atacar supuso una mejora en cómo la unidad debía moverse, porque hasta ese momento no se había considerado que si se elegía ir a una losa que ya estuviera ocupada, la unidad debía desplazarse hasta el punto más cercano posible. Fue necesario entonces, realizar un cambio al algoritmo de búsqueda de caminos de tal forma que si la losa de destino se encuentra ocupada se prueba con las losas adyacentes pero siempre teniendo en cuenta en buscar por el lado más cercano posible.

Pero para que el jugador pueda ordenar a sus unidades que realicen una actividad como caminar o atacar, es necesario antes seleccionarlas y esto debe reflejarse visualmente. Para lograr esto se tomó como referencia la forma como lo realizan juegos de similar clasificación y es mediante el dibujado de una barra sobre la unidad. Se exploraron diferentes alternativas de solución como son:

• Dibujar una línea recta sobre el modelo en el espacio 3D. Esta solución presentó el inconveniente de que la línea se mostraba en perspectiva y por lo tanto se deformaba.

• Dibujar la misma línea pero en el plano más cercano de la cámara, lo cual no gustó porque visualmente no era atractivo.

• Hacer uso de una malla para pintar un cilindro encima del modelo. Esta fue la opción seleccionada debido a que es visualmente muy llamativa y por ser un objeto 3D no presenta el problema de la perspectiva, es decir no se deforma.

Con esto se obtenía la funcionalidad y la apariencia gráfica de las unidades, sin embargo, se detectó que gráficamente el juego en general era muy plano, en el sentido de que a pesar de ser tridimensional, el terreno y la ambientación se veían un poco bidimensionales. Se realizó entonces una revisión de juegos de estrategia en la que se vio que juegos como Age of Empires y Rise of Nations usan una vista isométrica, es decir rotan el terreno o la cámara en un ángulo determinado, que por lo general es de 45º. Cabe resaltar que Age of Empires a pesar de ser un juego en 2D, gracias a este cambio de perspectiva adquiere el aspecto de ser un juego en 3D. Esto motivó a que en Independencia se trabajara con una vista isométrica para lo cual se realizó una rotación de 45º a la cámara logrando con esto mejorar su apariencia.

Junto con la rotación de la cámara era necesario rotar también el mini mapa pues se debía mantener la concordancia con el terreno. Aunque el trabajo de rotar la cámara resultó sencillo, no ocurrió igual con el mini mapa, dado que éste se implementó con objetos de tipo control (CImagen), los cuales no permitían mostrarse con algún tipo de rotación. Este inconveniente fue resuelto modificando la clase CControl del Motor 3D, para lo cual se hizo uso de los conceptos matemáticos de rotación de ejes [25]. De igual manera se requirió de los mismos conceptos de rotación de ejes para poder hacer selección múltiple de unidades utilizando el ratón mediante el método de mover el puntero mientras se tiene presionado el botón izquierdo.

Hasta ese momento ya se habían implementado muchos de los requerimientos del juego, pero faltaban varios detalles que complementan y enriquecen la interfaz de usuario y la funcionalidad de Independencia, tales como animación del grito comunero, zoom sobre el terreno, despliegue de botones de funciones para cada unidad y la musicalización y efectos de sonido. En cada uno de ellos se precisó de un trabajo específico y aunque los requerimientos eran pequeños, no por eso debían ser menospreciados, pues proporcionan el realce audiovisual necesario para lograr la motivación del jugador.

Un ejemplo de cómo se fue mejorando la apariencia del juego fue la animación del grito comunero, que es el poder especial que puede usar el prócer y por tanto debería destacarse gráficamente (como se muestra en la Figura 26). Por sugerencia del diseñador gráfico se optó por el uso de una secuencia de imágenes para crear una animación, razón por la cual se incluyó dentro del motor la clase CSecuencia, que cumplía con el fin propuesto.

Figura 26. Animación del grito comunero en Independencia.

Finalmente se pudo obtener el juego deseado, Independencia contaba con las características de un juego de estrategia en modo campaña, pero además:

• Permite hacer acercamientos de primer plano que facilitan la visualización de las acciones.

• Hace uso de técnicas de animación avanzadas como los modelos 3D texturizados y/o animados y las secuencias de texturas con canal alfa.

• Utiliza transparencias para las edificaciones y diferentes factores de niebla en las áreas del terreno.

• Emplea música de fondo para la partida y efectos de sonido para las acciones en el juego.

CAPÍTULO III:

Conclusiones, recomendaciones y trabajo futuro

El último capítulo de este documento tiene por finalidad presentar las conclusiones a las que se llegó una vez terminado este trabajo de investigación, así como también plantear una serie de recomendaciones encaminadas a ayudar los futuros trabajos que se realicen a partir de los resultados de este proyecto o que estén relacionados con el área del desarrollo de video juegos. Finalmente, se presentan las actividades futuras a llevar a cabo por parte de los investigadores y que buscan dar continuidad a la labor iniciada con la presente investigación.

CONCLUSIONES

Cuando se optó por llevar a cabo un proyecto que tendría que ver con la implementación de un juego de estrategia en 3D, fueron muchos los escépticos que pensaron que era una labor muy complicada e incluso difícil de lograr, debido en gran parte a que proyectos de este tipo no son frecuentes en nuestro medio y por tanto no se cuenta con la experiencia suficiente para desarrollos así.

Se logró pues implementar, no sólo un juego de estrategia en 3D y varios productos más, sino que se ganó experiencia y conocimiento en la creación de esta clase de proyectos en los cuales hasta ahora no se había incursionado, por lo menos, en el ámbito regional. En este sentido es de destacar que, a pesar de haber empezado casi desde cero, se logro un dominio deseable no sólo de la tecnología utilizada, sino del proceso de desarrollo en sí, en el cual se empezó por una fase exploratoria, para después ir construyendo poco a poco el producto final mediante acercamientos a la solución de problemas que tenían que ver con el juego.

Fue de gran ayuda para iniciar este proceso de construcción del conocimiento el estudio y apropiación de la tecnología ofrecida por Microsoft DirectX, pero además fue un gran aliciente la creación de Defensor 3D, porque no solamente brindó los primeros conceptos en cuanto a la creación de juegos usando Direct3D, sino que sirvió como motivación para el equipo de desarrollo, pues por ser un proyecto pequeño, los resultados se obtuvieron en un corto plazo y la aplicación de lo estudiado empezó a rendir los frutos deseados.

Sirvió esta primera aproximación, también, para empezar a dar forma al Motor 3D, ya que se inició con la determinación de las clases que serían necesarias para llevar a cabo los desarrollos subsiguientes. Pero fue mediante la definición de la jerarquía de objetos y su posterior implementación que se logró cumplir con uno de los objetivos propuestos: crear y usar un Motor 3D para el dibujado, musicalización y manejo de dispositivos de entrada y salida.

No obstante, aunque el motor tenía un propósito claro que era ayudar en la construcción del juego, su utilidad se extendió más allá, hasta el punto de servir como soporte para otras aplicaciones como el visor de modelos, el editor de terrenos y el buscador de caminos.

Se emprendió pues un proceso segmentado, en cuanto que se abordó el proyecto dividiéndolo en proyectos más pequeños, pero con objetivos claros, porque el objetivo central seguía siendo el mismo: crear Independencia. En este sentido es de destacar que cada aplicación 'intermedia' tuvo un propósito definido, siendo el del visor de modelos poder servir de puente de comunicación entre el diseñador gráfico y el equipo de desarrollo, el del editor de terrenos facilitar la creación y edición de terrenos para ser usados en Independencia y el del buscador de caminos facilitar la realización de pruebas y permitir la optimización del algoritmo A estrella.

Hoy por hoy es claro que el trabajo realizado con el diseñador gráfico se aprovechó y simplificó más gracias a la creación del visor de modelos, pero el valor de esta aplicación se extendió aún más, debido a que además se implementó una utilidad para la configuración del adaptador de video, con lo cual se permitió que el motor se pudiera instalar en diferentes máquinas y determinar si era capaz de ejecutarse en cada una de ellas o no.

Respeto al editor de terrenos es de destacar que, al igual que el visor de modelos, sirvió para trabajar en conjunto con el diseñador gráfico, con el fin de definir el tamaño de los modelos de ambientación, las imágenes de las losas y el terreno en general, demostrando con esto que cuando se realiza trabajo interdisciplinario es necesario definir canales adecuados de comunicación, siendo en este caso unas aplicaciones que facilitaran la labor de empalme de información necesaria tanto para el diseño gráfico, como para la implementación del juego. Es de resaltar que la experiencia adquirida mediante este trabajo interdisciplinario fortaleció el proceso de desarrollo, pues gracias a ello se aprendió a trabajar con otras personas que tienen un dominio en un área de aplicación diferente y resultó interesante poder llegar a un punto de entendimiento tal entre las partes de manera que si una de ellas hacía una propuesta en su "propio lenguaje", la otra captaba la esencia del mensaje.

Referente al buscador de caminos es de destacar que su creación fue vital para el mejoramiento del algoritmo A estrella, porque aunque la teoría acerca de la utilización de dicho algoritmo es muy difundida, la implementación es difícil de conseguir, por lo que las mejoras hay que encontrarlas sobre la marcha y esto se logra probando diversos escenarios posibles. Se logró de esta manera conseguir un algoritmo eficiente y robusto que posteriormente fue utilizado por las unidades modeladas en Independencia para realizar los desplazamientos dentro del terreno.

Ya entrando en detalle en cuanto a la creación de Independencia en sí, se debe resaltar que la metodología utilizada sirvió en pro de la solución buscada. Se nota en primera instancia, que siguiendo los consejos de gente con experiencia en el diseño de juegos, el punto de partida de un juego debe ser el guión, pues este servirá como eje conductor del mismo y será el que al final determine si se cumplieron las metas respecto a lo que se esperaba en un principio. Después se debe seguir un proceso de desarrollo al igual que se haría para cualquier otro proyecto de software, pero se resalta en Independencia la utilización de otras metodologías como GAIA, que facilitaron su creación.

En relación a este último aporte se debe considerar que GAIA ayudó a definir los agentes que se utilizarían dentro del juego sin necesidad de entrar en detalles de implementación y que los productos obtenidos gracias a esta metodología se pudieron diseñar muy fácilmente usando UML. Existió, entonces, una complementariedad entre ambos permitiendo con esto que el trabajo para la definición e implementación del comportamiento de las unidades del juego estuviera a la altura y vanguardia de grandes títulos de juegos en esta misma categoría.

Pero no sólo se destacó la implementación de dicho comportamiento en Independencia, sino que el juego como tal aportó muchas características que no estaban definidas desde el principio y que fortalecieron la apariencia visual y auditiva del mismo. Dentro de estas características se cuenta con poder hacer zoom sobre las unidades, animaciones, uso de transparencia y niebla y musicalización, siendo el soporte para todo esto la tecnología de DirectX.

DirectX ofrece un gran y completo conjunto de librerías que permiten la creación de proyectos multimedia de diversa índole, pero además brinda la posibilidad de que cada desarrollador utilice las características que necesita de la API. De las diversas API"s que conforman a DirectX, se destaca la versatilidad de DirectShow, que tan solo a partir de una clase (CMedio) dio soporte para audio y video de una manera transparente para el desarrollador. Las otras API"s como DirectGraphics, DirectPlay, DirectInput, DirectMusic, DirectSound, DirectSetup y DirectX Media Objects, se destacan por su funcionalidad y cobertura de las necesidades para la creación de juegos de excelente calidad.

Al crear Independencia se aprovecharon las ventajas tecnológicas de DirectX, pero también se benefició de la historia patria, buscando con esto rescatar la tradición y darle a esta tecnología la posibilidad de servir como instrumento motivador para el redescubrimiento y reconocimiento de esa historia olvidada en los libros de educación media.

Realizado todo el plan de creación de Independencia, se puede afirmar que es posible llevar a cabo en nuestro medio un proyecto relacionado con la creación de juegos, no obstante aún no existan todos los espacios que favorezcan el desarrollo de proyectos de este tipo. Es así como a la luz de los hechos se puede ver fácilmente que la apropiación de la tecnología no es una gran limitante, ni tampoco la escasez de recursos o el tiempo empleado y que lo que hace falta realmente es un poco de apoyo para poder sacar a flote estas ideas salidas de lo convencional. Se han dado, entonces, los primeros pasos en el programa de Ingeniería de Sistemas de la Universidad del Cauca, para que se considere ofrecer nuevos espacios para la creación de proyectos fuera de lo convencional, en cuanto que no se debe brindar únicamente la posibilidad de incursionar en proyectos que se puedan denominar tradicionales (como Sistemas de información para gestión de datos o aplicaciones para la Web), sino que se requiere un esfuerzo para proponer nuevas alternativas que permitan que los egresados puedan desempeñarse en un mercado que hoy por hoy está falto y ávido de ingenieros motivados y con ganas de emprender proyectos diferentes.

Recomendaciones

A los investigadores y personas interesadas en dar continuidad al trabajo iniciado con este proyecto se les recomienda en primer lugar, realizar una optimización de los algoritmos de rendering de los diversos objetos del Motor 3D para luego continuar con la implementación de características que aún no están presentes en el juego como jugar en modo aleatorio y modo multi jugador. Además sería muy enriquecedor el iniciar el desarrollo de otro tipo de juegos diferentes a los de estrategia, tal como los juegos de habilidad y acción.

Por todo el trabajo que involucró la construcción de Independencia y por todos los conocimientos que se tuvieron que aplicar, se puede afirmar que en el proceso de desarrollo de un juego se deben complementar muchos de los conceptos tratados en las diferentes asignaturas del programa de Ingeniería de Sistemas de la Universidad del Cauca. Por tal motivo se recomienda integrar las actividades realizadas en asignaturas complementarias, como es el caso de la electiva de desarrollo de software orientado a agentes y las asignaturas en las que se tratan tópicos relacionados con matemáticas en 3D, ingeniería de software, teoría de la computación y otros.

Sería acertado, también que en un futuro los estudiantes del programa de ingeniería de sistemas puedan tener la posibilidad de contar con un pensum más flexible en el que se brinden más opciones en cuanto a las diferentes áreas en la que se pueden desenvolver y aplicar sus conocimientos, habilidades y fortalezas, una vez que terminen sus estudios de pregrado.

De igual manera se recomienda que para proyectos de este tipo se pueda contar, no solo con el apoyo de diseñadores gráficos, sino con muchas más personas en diversas áreas, como por ejemplo literatos e historiadores que den forma a la historia y en general al guión del juego y matemáticos que ayuden en la tarea de reforzar los conceptos necesarios para un mejor trabajo con objetos en tres dimensiones.

Así mismo se recomienda la creación de una electiva al interior del programa de Ingeniería de Sistemas de la Universidad del Cauca en la que se ofrezca la posibilidad de conocer y desarrollar proyectos en el área de creación de juegos y que además se realice un trabajo interdisciplinario con docentes y estudiantes del programa de Diseño Gráfico, de manera que se puedan complementar las actividades propias del diseño de juegos.

TRABAJO FUTURO

La labor de la creación del juego no debe quedar sólo con lo hecho hasta ahora en Independencia, sino que se debe complementar el juego de manera tal que se brinde mayor funcionalidad y más características que no se pudieron llevar a cabo en este proyecto debido a limitantes de tiempo y recursos. Para lograr este objetivo, será necesario buscar instituciones que apoyen la investigación y el trabajo innovador en nuestro medio, tal y como puede ser el caso de COLCIENCIAS.

Con esto se podría avanzar mucho más en cuanto al proceso de desarrollo de juegos y se podría explorar temas que no fueron incluidos dentro de Independencia, tal y como es el caso del framework de efectos o la utilización de shaders en Direct3D. Se lograría una investigación y aprehensión de conocimientos que redundaría en beneficios personales y en mejora del producto con posibilidades reales de comercialización.

Bibliografía

• [1] Revista ENTER. Edición Nº 57: Información tomada de http://www.theesa.com/pressroom.html. Mayo 2003.

• [2] PENQUÉ, EDGAR. Implementación de un sistema de visión artificial para la clasificación y el control de calidad de frutas. Trabajo de grado para optar al título de Ingeniero Físico Universidad del Cauca, 2003.

• [3] GARRETA, LUIS. Presentación Electiva de Procesamiento Digital de Imágenes. Universidad del Cauca, Departamento de Sistemas. 2003.

• [4] HAWKINS, KEVIN. Game Dictionary. http://www.gamedev.net/dict/

• [5] SAWYER BENJAMIN. The Getting Started Guide to Game Development FAQ: What Types of Games Do Well?. http://www.gamedev.net/reference/articles/article261.asp. 1995

• [6] GÓMEZ CLAROS, RODRIGO. Tres historias para la creación y la animación como profesión. Video Conferencia dictada en el marco de Imagen Invisible 2002 en la Cámara de Comercio de Cali, sede principal. 2002. http://www.imageninvisible.com/espa%F1ol/3d.html

• [7] TOONKA Films. K-TOON 2D Animation Toolkit. http://ktoon.toonka.com/.

• [8] ALAMO, JUAN PABLO y SÁNCHEZ, JAIME. La tribu. Software presentado en TISE 99. Departamento de Ciencias de la Computación, Universidad de Chile; 1999.

• [9] HOWLAND, GEOFF. Game Design: The Essence of Computer Games. http://www.gamedev.net

• [10] BELDING, TONY. Elements Of VideoGame Style. http://www.gamedev.net

• [11] HNO. JUSTO RAMÓN. Historia de Colombia, significado de la obra Colonial, Independencia y Republica. Bogota: Librería Stella, 1965.

• [12] LUNA, FRANK D. Introduction to 3D game programming with DirectX 9.0. Wordware Publishing Inc.: 2003

• [13] CRAWFORD, CHRIS. The art of computer game design. http://www.vancouver.wsu.edu/fac/peabody/game-book/Coverpage.html. 1982

• [14] BARRON, TODD. Strategy game programming with DirectX 9.0. Wordware Publishing Inc.: 2003

• [15] LARAMEE, FRANCOIS DOMINIC. The game design process. http://www.gamedev.net/reference/list.asp?categoryid=23#32. 1999

• [16] COOK, DANIEL. Evolutionary Design: A practical process for creating great game designs. http://www.lostgarden.com. 2002

• [17] SWEETSER, PENELOPE. Current AI in Games: A review. School of ITEE, University of Queensland. AUSTRALIA http://www.itee.uq.edu.au/~penny/Game%20AI%20Review.pdf

• [18] WOOLDRIDGE, MICHAEL, JENNINGS, NICHOLAS and KINNY, DAVID. The Gaia Methodology for Agent-Oriented Analysis and Design. Kluwer Academic Publishers, Boston.

• [19] BUDD, TIMOTHY. Introducción a la programación orientada a objetos. Addison Wesley Iberoamericana: Wilmington, Delaware (USA), 1994.

• [20] GRANADOS, RAFAEL. Historia de Colombia, la Independencia y la República. Bogotá: Bibliográfica Colombiana Ltda., 1964.

• [21] MORRIS, DAVE y ROLLING ANDREW. Game architecture and design: Chapter 8, the future of game design. 1999.

• [22] PATEL, AMIT J. Amit's Game Programming Site. http://www-cs-students.stanford.edu/~amitp/gameprog.html. 2003.

• [23] SNOOK, GREGORY. Real-Time 3D Terrain Engines Using C++ and DirectX 9 (Game Development Series).

• [24] TAYLOR, GREG. Tile-Based Games FAQ version 1.2. x2ftp.oulu.fi: pub/msdos/programming/docs. 1995

• [25] PURCELL, EDWIN y VARBERG, DALE. Cálculo con geometría analítica. Prentice Hall. México. 1993.

PUBLICACIONES DE AUTORES Y DIRECTOR (a Diciembre de 2016):

Revistas JCR (ISI)

Notas: [1] En diseño en 3D este proceso se conoce comúnmente como el render de los objetos (incluyendo mapa, personajes, construcciones, etc.) que hacen parte de lo que se desea mostrar.

[2] En programación de video juegos, se conoce al mundo del juego, como el conjunto formado por el escenario de juego, el terreno, las construcciones, los personajes, la forma de interacción, la música y todo lo que hace parte, en sí, del juego como tal.

[3] Para mayor detalle acerca del algoritmo A estrella (A*), referirse a BÚSQUEDA DE CAMINOS en el CAPÍTULO II: MARCO TEÓRICO

[4] Referirse a GAIA: UNA METODOLOGÍA PARA EL ANÁLISIS Y DISEÑO ORIENTADO A AGENTES en el CAPÍTULO I: MARCO TEÓRICO.

Popayán 27 de Abril de 2005

Dedico este trabajo a mis padres: Eyvar Rivera y Evelia López, por brindarme su confianza y por haberme dado la mayor riqueza que un padre puede dar a sus hijos: su amor. A mi hermana Miryam Rivera, por escucharme y ofrecerme siempre su apoyo y cariño incondicionales. A mi segunda familia: Patricia Martínez, Rodrigo Rodríguez y Felipe Rodríguez, por comprenderme, tolerarme y apoyarme incluso en los momentos más difíciles. A todas las personas que han estado conmigo regalándome su afecto.

William Rivera.

Con todo mi amor a mi esposa Mónica y mi hijo Santiago, motivo de mi inspiración y constante apoyo.

Norman Muñoz

Agradecimientos

Por el apoyo que recibimos en el desarrollo del presente trabajo de investigación, queremos expresar nuestros agradecimientos a las siguientes personas:

CARLOS ALBERTO COBOS LOZADA, Magíster en Informática. Por sus valiosos consejos y sus aportes siempre oportunos.

ERICK ORTIZ, Estudiante de diseño gráfico. Por su labor en el realce visual del juego.

DIRECTOR: MSC. CARLOS ALBERTO COBOS LOZADA

UNIVERSIDAD DEL CAUCA

FACULTAD DE INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES

DEPARTAMENTO DE SISTEMAS

LÍNEA DE INTERÉS EN DESARROLLO DE JUEGOS

POPAYÁN, ABRIL DE 2005

INDEPENDENCIA: JUEGO DE ESTRATEGIA EN 3D BASADO EN HECHOS IMPORTANTES DE LA CAMPAÑA LIBERTADORA DE COLOMBIA

DIRECTOR: MSC. CARLOS ALBERTO COBOS LOZADA

UNIVERSIDAD DEL CAUCA

FACULTAD DE INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES

DEPARTAMENTO DE SISTEMAS

LÍNEA DE INTERÉS EN DESARROLLO DE JUEGOS

POPAYÁN, ABRIL DE 2005

Autor:

Norman Hernando Muñoz Fandiño.

William Alexander Rivera López.