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

Se puede apreciar, pues, que la planeación de un juego depende en gran parte de quien este elaborando el juego, pero a pesar de esto, existen características comunes como la documentación, la definición de características del juego, la estructura de la interfaz de entrada y salida y las relaciones existentes entre los componentes que harán parte del juego.

La metodología usada para la creación del juego motivo de esta investigación fue una adaptación propia del Proceso de Desarrollo Unificado, teniendo en cuenta que para la fase de análisis se definió el guión del juego el cual sirvió posteriormente para las etapas de diseño e implementación.

En conclusión, si se desea desarrollar un juego, antes de empezar a escribir toneladas de código, hay que sentarse a pensar en cómo se desea ver el juego, pero a partir de lo que se defina inicialmente, la historia y el propósito del juego. Con esto claro, se puede escribir las características del juego, lo que debe tener (requerimientos), las interacciones entre los componentes, la interfaz de entrada y salida y en fin todo aquello que se debería considerar al crear un sistema de información convencional.

IMPLEMENTACIÓN DE JUEGOS DE ESTRATEGIA

Después de tener el diseño, ya se puede empezar a codificar, pero no sin antes tener unos conocimientos básicos que son útiles en el momento de elaborar un juego de estrategia en tiempo real y que incluso se utilizan en la mayoría de los juegos. Estos conceptos incluyen el conocimiento de programación basada en losas (tiles), algoritmos de búsqueda de caminos (path finding) y análisis y diseño orientado a agentes, además de algunos prerrequisitos matemáticos que se detallan en el Anexo G.

En este apartado se dará una introducción a estos temas y se buscará establecer unas bases que puedan ser utilizadas posteriormente para la creación de un motor 3D y en general para la utilización en la construcción de juegos en tres dimensiones.

MANEJO DE LOSAS

Cuando se piensa en losas, hay que hacerlo como si se estuviera viendo un tablero de ajedrez, pero no de 8 x 8, sino de n x n, donde cada casilla del tablero constituye una losa. De tal forma, se puede afirmar que la losa es un bloque de construcción que unido a otros tiene sentido, pero, solo no.

La utilización de losas es muy popular en la programación de juegos, y se utilizan en la construcción del mapa del juego y/o de terrenos. Muchos tipos de juegos como los RPG (Role Playing Games) usan losas para crear todo el mapa del juego y además para programar la lógica del mismo. En cuanto a la creación del mapa, es claro, que cada losa constituye un pedazo que unido a los demás dan la sensación de conjunto del terreno, un caso típico es Super Mario Bros. (Figura 2), que tiene un conjunto de losas para la creación de los mundos.

Figura 2. Losas usadas en Super Mario Bros.

En cuanto a la lógica del juego, se puede implementar gracias a que se puede establecer qué hay en cada losa en un determinado momento, de este modo se puede controlar la acción del juego.

Ahora bien, además de utilizarse como mapa, ¿por qué hay que usar losas? La respuesta contempla dos temas: memoria y reutilización. La utilización de losas ayuda a conservar la memoria, pues no es lo mismo usar 100 losas de 64 x 64 píxeles, a usar un bitmap de 100 x 100 de 64 x 64 píxeles, ya que en el primer caso sólo son necesarios aproximadamente 2MB, mientras que en el otro cerca de 163 MB de memoria.

La reutilización es un factor clave, pues el uso de losas permite que se puedan reutilizar en diferentes partes del mapa, con lo cual el diseñador gráfico sólo tendría que crear pedazos pequeños y no un gran mapa, que tuviera mayor complejidad.

Pero no solo la reutilización y conservar memoria son importantes, también es de destacar que se puede establecer si una losa está ocupada por una unidad y qué unidad es la que está ahí, además de que a las losas se les puede especificar propiedades, las cuales pueden ser utilizadas para definir características de una losa o de un conjunto de ellas. Estas propiedades incluyen:

• Obstrucción: que dice si se puede caminar o no por la losa,

• Elevación: determina si una losa es una "montaña" o no, o en su defecto, puede tener un valor que me indica que tan elevada está, y

• Brillo: que es útil para los efectos de guerra y también como propiedad para ocultar losas.

Como se ve, entonces, usar losas, es una de esas técnicas de programación que ayuda no sólo a preservar memoria, sino que facilita la construcción de mapas para la creación de terrenos y para la manipulación de la lógica del juego.

BÚSQUEDA DE CAMINOS

Teniendo definidas las losas, se debe pensar en cómo se va a hacer para desplazar a una unidad desde un punto A hasta un punto B del mapa, y más aún, gracias a las propiedades de las losas, hay que establecer si hay obstáculos que puedan alterar dicho desplazamiento. A este problema se le conoce como la búsqueda de camino. En la Figura 3 se muestran dos ejemplos de búsqueda de caminos, uno sin obstáculo y otro con un obstáculo.

El problema de encontrar caminos, no sería tan complicado si no hubiera obstáculos que sortear para ir desde un punto hasta otro, pues un algoritmo fácil sería:

Si la unidad está a la izquierda del objetivo, muévase a la derecha.

Si la unidad está a la derecha del objetivo, muévase a la izquierda.

Si la unidad está encima del objetivo, muévase hacia abajo.

Si la unidad está debajo del objetivo, muévase hacia arriba.

Pero los problemas surgen cuando hay obstáculos, pues hay que bordearlos. Una forma inicial de solucionar este inconveniente sería generando un movimiento aleatorio, pero se corre con la posibilidad de que se bloquee o se demore mucho para poder llegar al objetivo. El pseudo código sería:

Mientras no esté en el objetivo

Si está a la izquierda del objetivo, muévase a la derecha.

Si está a la derecha del objetivo, muévase a la izquierda.

Si está encima del objetivo, muévase hacia abajo.

Si está debajo del objetivo, muévase hacia arriba.

Si está bloqueado, muévase aleatoriamente.

Fin mientras

Una forma de solucionar este problema es mediante la implementación del método de la A estrella (A*) [14]. Este método es un buen algoritmo de búsqueda de camino, puesto que bordea obstáculos y mejor aún encuentra la mejor ruta basado en un terreno cambiante.

Los fundamentos del algoritmo A* consisten en definir una lista de nodos cerrados y otra de nodos abiertos, donde cada nodo corresponde a una losa del mapa y el nodo actual se denomina nodo padre.

Lo primero que se debe hacer es definir unos costos, los cuales servirán para el cálculo de la mejor ruta. Estos costos son:

• Costo base de un nodo: Es el costo del nodo en términos de movimiento, es decir, el costo según las características de la losa. Así por ejemplo a una losa que posee césped, se le puede dar un costo de 1, a una con rocas 2, a otra con arena 3 y así sucesivamente.

• Costo del nodo de inicio: Indica cuanto cuesta para el nodo regresar al punto de inicio. Para calcular esto, se toma el costo del nodo padre y se le suma el costo base de la losa actual.

• Costo desde el nodo objetivo: Es calculado sumando el número horizontal y vertical de nodos que hay del nodo actual hasta el nodo objetivo.

• Costo total: Es la suma de los tres costos anteriores.

El método de búsqueda de caminos A*, trabaja de la siguiente forma:

• Se coloca el nodo de inicio en la lista de nodos cerrados.

• Se adicionan los nodos adyacentes al nodo de inicio, en la lista de los nodos abiertos.

• Se busca el nodo adyacente con el menor costo total y se adiciona a la lista de nodos cerrados.

• Se remueve el nodo con el costo total más bajo de la lista de nodos abiertos.

• Si no se ha conseguido llegar al objetivo en la lista de nodos abiertos, se continúa buscando, abriendo nodos alrededor del que se adicionó a la lista de nodos cerrados y luego colocando en esta lista al nodo con el menor costo total de la lista de nodos abiertos. El proceso sigue hasta que se encuentre el objetivo.

• Cuando se llegue al objetivo, hay que volver hacia atrás. Esto se hace utilizando los nodos padres, de tal manera que nuevamente se retorne al nodo inicial y se pueda hacer el recorrido desde el inicio hasta el final.

MODELADO DEL COMPORTAMIENTO DE LOS PERSONAJES

Existen muchas técnicas que utilizan los juegos modernos para el modelado del comportamiento de los personajes [17], pero es de destacar la utilización de las máquinas de estados finitos, los agentes y el scripting, no con esto desmeritando la importancia que tienen otras como las redes neuronales, la lógica difusa, entre otros. Sin embargo, las tres primeras son de especial atención, dado su gran utilización en el mundo de los juegos debido a su fácil codificación y a los resultados que ofrece en corto tiempo.

Para la construcción de Independencia se hizo uso de una metodología para el análisis y diseño orientado a agentes llamada GAIA, la cual permitió modelar el comportamiento de los personajes dentro del juego, haciendo uso además en la fase de implementación, de las técnicas de Maquinas de Estados Finitos y scripting. Por esto, a continuación se hace una breve introducción a las máquinas de estado finitas, los agentes y el scripting, teniendo en cuenta un ejemplo práctico de su utilización en el mundo de los juegos de computador.

• MÁQUINAS DE ESTADOS FINITOS

Las máquinas de estado finitos (MEF) son quizá, la técnica más ampliamente usada en los juegos de computador por sobre cualquier otra técnica. Su fortaleza radica principalmente en que son fáciles de programar y generalmente suficientes para resolver casi cualquier problema. Una MEF divide el comportamiento de los objetos en estados lógicos, de manera que cada estado identificará un tipo de comportamiento que el objeto exhibe en un momento determinado.

Otra ventaja del uso de las MEF es que facilitan el proceso de depuración y de comprensión de las mismas, además se ajustan casi a cualquier sistema que exhiba un número limitado de estados de operación y puede que no brinden la mejor solución, pero habitualmente funcionan y son mucho más simples de desarrollar que otras técnicas; e incluso pueden trabajar en conjunto con otras técnicas de IA, como por ejemplo pueden ser usadas como el módulo corazón de los agentes.

Algunos inconvenientes de las MEF es que si no se estructuran adecuadamente, presentan muy poca escalabilidad (mantenimiento muy difícil) e incrementan su tamaño con cada ciclo de desarrollo.

Son usadas en la mayoría de juegos de computador comerciales tales como: Age of Empires, Enemy Nations, Half Life, Doom y Quake. Quake, por ejemplo usa una MEF con 9 estados diferentes (parado, caminando, corriendo, eludiendo, atacando, esquivando, mirando al enemigo, desocupado y buscando) para representar el comportamiento de cada personaje. Específicamente en Independencia se utilizaron para representar la actitud que asumen los personajes en un momento determinado.

• AGENTES

Un agente es un sistema de computador que es capaz de realizar acciones independientes en beneficio de su propietario o usuario, es decir, son autónomos. En tal sentido, se puede afirmar que un agente es capaz de actuar independientemente, exhibiendo control sobre su estado interno, para cual hace uso de su percepción interna del ambiente en el que se desenvuelve.

Los juegos brindan ambientes realistas perfectos para los agentes, en los cuales solo una parte de la información puede estar disponible para el agente y donde las decisiones deben ser tomadas bajo restricciones de tiempo y presión. Generalmente, los agentes en juegos son conjuntos de MEF que trabajan cada uno en un problema particular y se comunican con los demás.

Cuando se considera la inclusión de agentes en juegos, es importante considerar si el agente va a ser puramente reactivo, dirigido por objetivos o una combinación de los dos. Los agentes puramente reactivos están asociados con ambientes altamente cambiantes, mientras que los agentes dirigidos por metas están asociados con ambientes estáticos, en los que es conveniente planear y considerar movimientos previos antes de emprender alguna acción.

Un buen ejemplo de la utilización de agentes en juegos es "Empire Earth", en el cual la IA se compone de varios componentes llamados administradores. Cada administrador es responsable por un área específica dentro del juego. En dicho juego hay administradores para la civilización, las construcciones, las unidades, los recursos, la investigación y el combate. El administrador de la civilización es el administrador de más alto nivel y es responsable por el desarrollo de la economía del jugador computador y la coordinación entre los otros administradores. Los otros administradores tienen deberes de más bajo nivel y envían peticiones y reportes a los demás.

• SCRIPTING

La técnica de scripting consiste básicamente en la creación y/o utilización de un lenguaje de programación usado para simplificar alguna tarea compleja para un programa particular. Un lenguaje de scripting es considerado un lenguaje de cuarta generación y su alcance puede variar desde un simple archivo de configuración hasta un complejo lenguaje interpretado en tiempo de ejecución, pero en todos los casos pretende controlar el comportamiento del sistema desde afuera.

Los juegos que hacen uso de scripting, tales como Quake o Unreal, permiten que el código del juego sea programado en un lenguaje de alto nivel, semejante al inglés, logrando así ocultar muchos aspectos complicados del juego y permitiendo a los usuarios no programadores modificar el comportamiento del juego de una manera más natural.

El scripting es ampliamente usado en los juegos de rol para la construcción de árboles de conversación y en general para el manejo de eventos de IA, por ejemplo para la creación de tutoriales de juego.

• GAIA: UNA METODOLOGÍA PARA EL ANÁLISIS Y DISEÑO ORIENTADO A AGENTES

GAIA [18], es una metodología para realizar los procesos de análisis y diseño orientados a agentes. La orientación a agentes surge como un nuevo paradigma de la ingeniería del software para la abstracción de sistemas a un nivel más alto, lo cual brinda la posibilidad de hacer una mejor comprensión del sistema en estudio mediante el uso de agentes como herramienta de entendimiento de las sociedades. La filosofía de GAIA se basa en el concepto del sistema visto como una organización en la cual existe una serie de roles y a su vez, cada rol posee un conjunto de interacciones con otros roles. Un rol es asumido por un individuo en un determinado momento.

Esta metodología hace uso de una serie de modelos de análisis y diseño. La relación entre estos, se muestra en la Figura 4.

ANÁLISIS

La etapa de análisis en GAIA busca el entendimiento del sistema y su estructura como una organización. Una organización puede ser vista como un conjunto de roles que mantienen ciertos tipos de interacción con otros roles en el sistema. Un rol es definido en GAIA por cuatro atributos: las responsabilidades, los permisos, las actividades y los protocolos. Las responsabilidades, a su vez, pueden fraccionarse en 2 categorías: las propiedades de vida y las propiedades de seguridad. Todos estos conceptos del sistema pueden verse en la Figura 5.

Las responsabilidades determinan la funcionalidad y son talvez los atributos claves asociados con un rol. Las propiedades de vida intuitivamente declaran que "algo bueno ocurre". Por el contrario, las propiedades de seguridad son invariantes e intuitivamente afirman que "nada malo pasa". Los permisos identifican los recursos que el rol tiene disponibles para realizar sus responsabilidades. Por lo general, estos tienden a ser recursos de información y con cada recurso habrá asociados unos derechos coligados, como por ejemplo: leer, cambiar o generar el recurso. Las actividades representan acciones privadas u operaciones que el agente puede completar sin la necesidad de interactuar con otros agentes en el sistema. Por último, los protocolos definen las formas en que un agente asumiendo dicho rol podría interactuar con otros agentes.

Durante la etapa del análisis en GAIA se generan dos tipos de modelos a saber: el modelo de roles y el modelo de interacción.

• EL MODELO DE ROLES

El objetivo principal del modelo de roles es el de identificar los distintos tipos de rol que se encuentran en el sistema. Un rol puede ser visto como la representación de un tipo de función específica dentro de la organización, por ejemplo, el gerente de una compañía. Con cada rol hay asociados unos permisos y unas responsabilidades. Los permisos identifican los recursos a los cuales el rol puede acceder y los límites impuestos sobre estos recursos. Los permisos pueden ser del tipo:

reads recurso // Permite leer el recurso

changes recurso // Permite leer y modificar el recurso

generates recurso // El rol es el productor del recurso

La funcionalidad de un rol está determinada por sus responsabilidades, y estas pueden verse como responsabilidades de vida y responsabilidades de seguridad. Las responsabilidades de vida son llamadas así tienden a decir que "algo se hará" y por tanto que el agente desempeñando el rol está aún vivo. La forma general de una expresión de vida es:

NOMBRE_ROL = expresión

La expresión de vida está compuesta por actividades y/o protocolos y operadores, donde las actividades son acciones que el agente puede realizar por si mismo, mientras que los protocolos involucran la interacción con otros agentes. Los operadores se muestran en la Tabla 2.

Por otro lado, las responsabilidades de seguridad se relacionan usualmente con la ausencia de alguna condición no deseable y se expresan por medio de una serie de predicados, por ejemplo:

recurso > límite

Con estos conceptos claros, se puede especificar un esquema de rol para cada tipo de rol en la organización y conformar así el modelo de roles. Un esquema de rol presenta una descripción del rol, sus protocolos y actividades, sus permisos y las responsabilidades de vida y seguridad. Una plantilla del esquema de rol es proporcionada en la Tabla 3.

• EL MODELO DE INTERACCIÓN

Este modelo se conforma de una serie de definiciones de protocolo, una para cada tipo distinto de interacción entre los roles. Cada definición de protocolo consiste de un propósito de la interacción, los roles iniciador y receptor de la misma, las entradas y salidas y el procesamiento ejecutado. El propósito de la interacción es una descripción textual breve del objetivo de la interacción. Las entradas al protocolo son toda la información usada por el rol iniciador, mientras que las salidas son la información suministrada por/a el receptor del protocolo durante el curso de la interacción y el procesamiento es una corta descripción textual del proceso que realiza el rol iniciador. Una plantilla de la definición de protocolo es proporcionada en la Tabla 4.

• DISEÑO

El proceso de diseño en GAIA involucra la transformación de los modelos de análisis a un nivel de abstracción suficientemente bajo para que sea posible implementar los agentes haciendo uso de las técnicas de diseño tradicionales, tales como las que hacen uso de la orientación a objetos. Así pues, el propósito de la metodología GAIA no es el de definir como un agente va a realizar sus responsabilidades, sino el de cómo van a cooperar para cumplir con los objetivos a nivel de la organización.

En la etapa de diseño, GAIA hace uso de 3 tipos de modelos: el modelo de agentes, el modelo de servicios y el modelo de conocidos.

• EL MODELO DE AGENTES

La intención de este modelo es la de definir los diferentes tipos de agente que se podrán encontrar en el sistema y el número de instancias que se tendrán de cada uno en tiempo de ejecución. Un tipo de agente, no es más que un conjunto de roles. Se puede afirmar entonces, que un tipo de agente puede asumir uno o más roles, aunque lo contrario no es cierto.

El modelo de roles es construido mediante un árbol de tipos de agentes, en el cual los nodos hoja corresponden a los roles y los restantes a los tipos de agentes. Para cada tipo de agente se debe definir un cuantificador de instancia, el cual precisa el número de instancias que se tendrán en el sistema en tiempo de ejecución. En la Figura 6 se brinda un ejemplo de un modelo de agentes y en la Tabla 5 se dan lo posibles cuantificadores de instancia para un modelo de agentes.

• EL MODELO DE SERVICIOS

Este modelo expone los servicios que cada tipo de agente va a implementar, entendiendo por servicio, cierta funcionalidad del agente. Cada servicio es derivado de las actividades y protocolos, así como de sus propiedades de vida y seguridad encontradas en la etapa de análisis.

El modelo de servicios se compone de las propiedades de cada uno de los servicios, como son: las entradas, las salidas, las precondiciones y las poscondiciones. Las entradas y salidas proceden en forma directa del modelo de protocolos. Las precondiciones y las poscondiciones constituyen limitantes en los servicios y son derivadas de las propiedades de un rol.

• EL MODELO DE CONOCIDOS

La finalidad del modelo de conocidos es la de precisar los enlaces de comunicación que existen entre tipos de agentes e identificar posibles problemas de embotellamiento surgidos por el uso de estos canales de comunicación. El modelo es un grafo dirigido, en donde cada nodo corresponde a un tipo de agente y las aristas se relacionan con los caminos de comunicación. Así pues, un grafo A -> B, muestra que hay un camino de A a B, pero no necesariamente de B a A.

CAPÍTULO II:

Desarrollo del proyecto

Previo al desarrollo del proyecto, se llevó a cabo una fase exploratoria, en la cual se buscaba principalmente tener un conocimiento y dominio suficiente de la tecnología proporcionada por DirectX con el fin de que después en el juego, se pudiera realizar un diseño consistente y apropiado, teniendo en cuenta lo que podía ofrecer la tecnología elegida. Para un mejor conocimiento de la tecnología de DirectX, referirse al Anexo F.

Durante el desarrollo de este proyecto de investigación se adoptó como metodología de trabajo una adaptación del proceso unificado de desarrollo (UP), el cual está compuesto por una serie de fases (Inicio, elaboración, construcción y transición) con unas etapas bien definidas que son: Análisis, Diseño, Implementación, Pruebas y Entrega. Este proceso, se trabajó de manera iterativa e incremental. Sin embargo, la etapa de análisis no se realizó de forma tradicional, debido a que en esta se buscó, en primer lugar, contextualizar y enmarcar el juego dentro de los aspectos históricos relevantes que sirvieron como soporte para el desarrollo del mismo, y en segundo lugar, modelar el comportamiento de los personajes que intervendrían en él. Los resultados de esta fueron el guión del juego y los modelos de análisis de la metodología GAIA[4]

Ya en la etapa de diseño, y basándose en los resultados arrojados por el guión y en los objetivos propuestos al inicio de este proyecto, se hizo pertinente modelar los artefactos necesarios para la construcción de los productos que se tendrían al finalizar esta investigación. Para tal fin, se decidió hacer uso de la potencialidad del UML (Lenguaje unificado de modelado), cuyo propósito es el de apoyar a los diseñadores y desarrolladores en su trabajo de modelado y posterior paso a implementación. Cabe anotar aquí, que el UML no pretende ser camisa de fuerza para el proceso y cada desarrollador usa los artefactos que considera necesarios y/o apropiados para la buena marcha de su proyecto. En este caso, se considero pertinente el uso de diagramas de casos de uso y diagramas de clases principalmente, además de un diagrama de estados y un diagrama de secuencia.

En la primera parte de la etapa de diseño se trabajó en la construcción de los artefactos que servirían de base para la creación de aplicaciones con capacidad para manipular objetos 3D y 2D, flujos de audio y video y entrada desde el teclado y el ratón, todo esto haciendo uso de la API de DirectX. Dichos artefactos conformaron lo que se denomina un Motor 3D, que está caracterizado por ser Orientado a Objetos e implementar las funcionalidades más comunes para soportar las capacidades arriba mencionadas, así como otras utilidades frecuentemente usadas por este tipo de aplicaciones.

A medida que los artefactos para el Motor 3D crecían y se hacían cada vez más completos, surgían nuevos inconvenientes que era imperativo solucionar. El primero de ellos fue la dificultad de sincronización y pruebas del trabajo interdisciplinario que se realizó con el personal de diseño. Más concretamente, esta dificultad se daba gracias a que para la creación de los modelos 3D de los personajes y la ambientación para el terreno, el diseñador usaba 3D Studio MAX y luego exportaba los modelos al formato nativo de DirectX (.x) mediante un plug-in (Panda DirectX) y al momento de probar dichos modelos en el contexto del proyecto, el formato, en muchas ocasiones, era incorrecto, la escala no era la adecuada, las animaciones se veían distorsionadas o simplemente el modelo no se podía visualizar. Todas estas dificultades generaban retrasos que había que eliminar del proyecto y para lograrlo se pensó en la construcción de una aplicación que permitiera visualizar los modelos en formato .x que el diseñador generaba. De esta forma, la persona encargada del modelado de los personajes podía hacer pruebas una vez realizaba la exportación del modelo y se aseguraba que éste estaba correcto. A esta aplicación se le llamo un Visor 3D y su funcionalidad general es la de permitir visualizar los modelos 3D estáticos y animados en el formato nativo del DirectX (.x) haciendo uso de las clases que fueron generadas para el Motor 3D.

Ya en el momento de trabajar con terrenos, se presentó una nueva complicación. Esta se daba básicamente por la necesidad de agilizar el proceso de edición de las texturas usadas, la ambientación y las alturas de un terreno. Para subsanar este inconveniente se consideró apropiado desarrollar una aplicación específica que diera soporte a estas operaciones y que pudiera ser usada tanto por los desarrolladores del juego, como por el personal del área de diseño. A este aplicativo se le denomino un Editor de Terrenos, y su propósito es el de agilizar el proceso de creación y edición de terrenos, incluyendo la aplicación de texturas y la modificación de ambientación y alturas.

Superados los anteriores inconvenientes y encontrándose en la etapa de implementación, surge la necesidad de hacer pruebas de rendimiento al algoritmo usado para la búsqueda de caminos, ya que el algoritmo genérico A* funciona bien, pero puede demorarse demasiado en arrojar un resultado, y dado que el juego está clasificado como un juego en tiempo real, este comportamiento no es deseable. Por tal motivo, se empezó a trabajar también en una aplicación que permitiera a los desarrolladores, realizar pruebas con un modelo caminando sobre diferentes terrenos con variados obstáculos y tamaños y haciendo uso del algoritmo de búsqueda de caminos creado para el juego. Esta aplicación fue llamada el Buscador de Caminos.

Una vez el Motor 3D era consistente y estable (en cuanto a que proporcionaba la funcionalidad deseada y poseía una arquitectura escalable) se empezó el diseño e implementación del juego, para lo cual en primera instancia se hizo uso de la metodología GAIA [18] para el diseño orientado a agentes y posteriormente se complementó mediante la utilización de UML para el completo modelado del sistema. Acto tras del cual se pasó a la implementación.

Cabe comentar, que entre las etapas de diseño e implementación se realizaron varias iteraciones dado que en primera instancia se procedía a diseñar los artefactos que posteriormente se implementaban y de los cuales surgía un prototipo que poco a poco se iba mejorando hasta obtener el resultado deseado. De esta manera se creó el Motor 3D que a su vez sirvió como base no sólo de diseño sino de implementación para la construcción de las otras aplicaciones.

Para mostrar más en detalle el proceso de desarrollo a continuación se profundizará en la fase de exploración y en las etapas de análisis, diseño e implementación.

FASE DE EXPLORACIÓN

En esta fase se inició un proceso de autoaprendizaje de los conceptos fundamentales referentes al soporte gráfico proporcionado por DirectX. Aquí se empezó a conocer la arquitectura de Direct3D, el manejo de luces y materiales, transformaciones de mundo, de vista y de proyección y manipulación de modelos tridimensionales. Adicionalmente, también se empezó a averiguar la forma en la que se podía trabajar la musicalización.

Para poder verificar el cumplimiento del objetivo de esta fase, es decir, lograr la apropiación del conocimiento referente a DirectX y a la construcción de juegos con esta tecnología, se propuso la creación de un juego sencillo denominado Defensor 3D, cuya historia es la de una nave espacial que debe proteger a la tierra de invasores y peligrosos asteroides. Esta aplicación tenía como requerimientos iniciales la utilización de modelos tridimensionales, música de fondo y efectos de sonido.

Dentro de la construcción de Defensor 3D, se presentaron algunos problemas de orden técnico que a la larga sirvieron para solidificar el conocimiento deseado y cuya solución permitió que Independencia pudiera nutrirse de toda esa experiencia. Se cuenta dentro de estos problemas, la conversión de coordenadas de dos (2) a tres (3) dimensiones, la selección con el ratón de modelos tridimensionales, la utilización de sonidos y el manejo de colisiones. Además la realización de Defensor 3D permitió vislumbrar un panorama que facilitó la estructuración del motor 3D, diseñado e implementado posteriormente.

Para poder realizar la conversión de coordenadas de dos (2) a tres (3) dimensiones, fue necesario considerar la manera en como se podía calcular el ancho y el alto de la ventana y a partir de estos, realizar los cálculos necesarios para obtener un rayo que permitiera determinar el origen y la dirección hacia la cual se tendría que expandir la transformación del punto. Adicionalmente, este problema requirió de la utilización de la transformada de vista, con el fin de hacer coincidir la ubicación espacial del objeto con la posición desde la que se observaba la escena.

La solución del problema anterior aportó al momento de poder determinar si el puntero del ratón estaba o no sobre un modelo tridimensional, porque se tuvo en cuenta la intersección entre el rayo calculado a partir de la posición del ratón y una esfera contenedora del objeto, calculada teniendo en cuenta el centro y el radio del modelo.

La esfera contenedora del modelo, no sólo sirvió para el propósito anterior, sino que fue utilizada para la detección de colisiones entre modelos, realizando los cálculos con base en el solapamiento de los centros y radios de los objetos.

El otro problema afrontado, fue el de la música, el cual se abordó desde la tecnología proporcionada por DirectMusic, que ofrece soporte para la carga y reproducción de sonidos desde archivos o recursos MIDI, WAV, o en formato de ejecución nativo de DirectMusic. Sin embargo, analizando los posibles alcances que pudiera llegar a tener el proyecto, se debió considerar la inclusión de un objeto que soportara y permitiera la reproducción de otros formatos, no sólo de audio, sino también de video. En la Figura 7 se muestra la pantalla de configuración de Defensor 3D, desde donde se puede seleccionar además de la nave para el juego, las opciones para determinar si usa o no música de fondo y efectos de sonidos controlados por la API de DirectMusic.

Figura 7. Pantalla de configuración de Defensor 3D.

La solución a los anteriores inconvenientes y el estudio adecuado de la tecnología ofrecida por DirectX, permitió que el diseño del motor 3D que posteriormente se abordó fuera más consistente y ofreciera la funcionalidad necesaria para crear juegos. Así por ejemplo, el requerimiento del soporte para diferentes formatos de audio y video, que tuvo como desenlace la tecnología ofrecida por DirectShow, dio origen a una sola clase que en el motor se encarga de brindar esos servicios.

Una vez terminado el juego Defensor 3D, se llegó a la conclusión que los conocimientos apropiados hasta el momento eran los suficientemente maduros como para continuar con el proyecto y además se tuvo la satisfacción y motivación que impulsaron las siguientes etapas en la construcción de Independencia.

ANÁLISIS

Por ser Independencia un juego de estrategia en tiempo real, el análisis que se hace en este tipo de proyecto difiere al que se podría hacer en un sistema de información tradicional, puesto que no es posible modelar la realidad del juego sin tocar aspectos de diseño, en tal sentido no se puede concebir la idea del jugador ejerciendo la acción de jugar el juego sin verlo frente a un sistema computarizado. Para hacer más claridad al respecto, téngase en cuenta el caso del análisis de un juego de ajedrez. En este tipo de juego si se puede realizar un modelado del sistema, porque es fácil visualizar al jugador ejerciendo su rol en el mundo real.

Sin embargo, era necesario crear un hilo conductor para el juego, de tal manera que definiera los hechos que se iban a tratar, en dónde se iban a realizar y que personajes iban a intervenir. Esto se logró con la creación de un guión que contenía la historia del juego, el lugar y el tiempo de la misma y los personajes que iban a intervenir.

Una vez hecho lo anterior, y antes de empezar el diseño, se inició el modelado del comportamiento de los personajes definidos previamente en el guión y para lo cual se uso la metodología GAIA.

EL GUIÓN DEL JUEGO

La tarea de escribir un guión para un juego, no es una labor para ingenieros y debería ser producto de un trabajo interdisciplinario con personas que tengan experiencia en la elaboración de libretos y sepan narrar claramente una historia apropiada para el juego. Este fue un gran inconveniente en la elaboración del presente proyecto, porque no se pudo contar con una persona idónea que proveyera este vital insumo para el juego.

Como el proyecto estaba andando y no se podía detener se optó por investigar dentro de los manuales de juego de títulos conocidos, como Warcraft y Age of mythology, la forma en la cual estructuraban la historia. Esto permitió obtener características comunes que fueron incluidas dentro del guión de Independencia, tal como la narración de la historia y la definición de los personajes y sus características. A continuación se muestra ese resultado, que es la base para el juego y que se enmarca dentro del contexto histórico que se presenta en el Anexo D.

• HISTORIA DEL JUEGO

El 16 de abril de 1781, un mes después del rompimiento del edicto, se reunió en el Socorro (Santander) un grupo de hombres provenientes de regiones circundantes, con el fin de protestar por el reciente incremento en los impuestos. Ese día, se nombra una junta a la cual se le denominó Común, siendo designado como general el señor Juan Francisco Berbeo. Se empieza, entonces, una marcha con destino hacia la Capital.

Las autoridades coloniales deciden enviar un grupo de hombres bien armados, al mando del señor Joaquín de la Barrera, para que detenga la marcha. Mientras tanto, los 'comuneros' siguen la ruta Socorro, Oiba, Velez hasta llegar a Puente Real, lugar donde se desencadena una confrontación entre los dos bandos.

La lucha era desigual, porque los comuneros tan solo estaban armados de hondas y machetes, mientras que los españoles eran superados en número, pero poseían rifles y espadas de combate. Sólo la exaltación de los ánimos mediante el continuo aliciente de su líder, llevó a los comuneros a ganar la batalla.

• ESPACIO GEOGRÁFICO

El espacio geográfico en el que ocurrieron los hechos abarca el espacio recorrido por el ejército de los comuneros luego del rompimiento del edicto y hasta la victoria en Puente Real, es decir, el espacio comprendido entre El Socorro y Puente Real, pasando por Oiba y Vélez.

• PERSONAJES

Una vez que se tiene definida la historia del juego, es necesario identificar en ésta, los personajes principales y secundarios con el fin de determinar cuales de ellos tienen real trascendencia dentro de la historia y porqué. Los personajes principales, generalmente juegan el rol de líderes, héroes o caudillos dentro de la historia, y su intervención en la misma es de vital importancia para el desarrollo de los hechos. Los personajes secundarios son los que intervienen en la historia de una forma un poco menos importante y no siempre son recordados o identificados con nombre propio en ella, por ejemplo, los soldados de un ejercito en una batalla.

En la historia del presente guión se identificaron dos personajes principales y cuatro personajes secundarios que intervienen de forma activa en la misma y que se presentan a continuación.

• PRINCIPALES

• Sin quererlo ser, Juan Francisco Berbeo, se convierte en el caudillo que guía a los comuneros en su travesía hacia la capital, pero no sin antes mencionar su lealtad a la Corona Española e insinuar que su participación era obligada. Este personaje por ser el líder del ejército de los comuneros es llamado Prócer, esta armado con una espada y tiene la habilidad especial de emitir un grito de batalla denominado "El grito comunero", el cual incentiva, a los combatientes comuneros que lo escuchan, a atacar con más ahínco a su enemigo.

• En el ejercito de los españoles el personaje principal es Joaquín de la Barrera, quién es el dirigente de su ejército. Está armado con una gran espada, tiene un ataque fuerte y buena protección de armadura.

• SECUNDARIOS

• Honda: Este integrante del ejército de los comuneros tiene como arma una honda. Tiene un ataque fuerte pero es lento entre cada ataque y está muy desprotegido de armadura.

• Machete: Este combatiente comunero esta equipado simplemente con un machete. Tiene un ataque débil, pero es rápido entre cada ataque y tiene protección de armadura media baja.

• Rifle: Este integrante del ejército español tiene como arma un rifle. Tiene un ataque fuerte pero es lento entre cada ataque y tiene armadura media.

• Espada: Este combatiente español esta armado con una espada. Tiene un ataque débil, pero es rápido entre cada ataque y tiene protección de armadura media.

• CAMPAÑA

Una vez que el usuario decida jugar la campaña del juego, debe afrontar una misión que debe ser completada, en un tiempo determinado por el nivel de dificultad, para poder obtener la victoria. Esta misión esta compuesta por unos objetivos principales o de obligatorio cumplimiento y unos objetivos secundarios u opcionales.

• MISIÓN

Llevar al prócer desde El Socorro hasta Puente Real y ganar la batalla contra los españoles.

• OBJETIVOS

OBJETIVOS PRINCIPALES

• El prócer debe sobrevivir.

• Armar un ejército compuesto por al menos 10 comuneros.

• Ir desde Socorro hasta Puente Real y ganar la confrontación.

OBJETIVOS SECUNDARIOS

• Desarrollar la habilidad del grito comunero.

• Buscar el centro de construcción de armas para convertir a los campesinos en guerreros.

ANÁLISIS GAIA

Cuando se habla de un juego en modo campaña contra el sistema, se debe tener en cuenta que el jugador "sistema" debe adoptar un comportamiento que dé la apariencia de inteligencia. En tal sentido, son muy variadas las técnicas con las que se puede implementar este tipo de conducta, tal como se vio en el ítem MODELADO DEL COMPORTAMIENTO DE LOS PERSONAJES en el CAPÍTULO II: MARCO TEÓRICO.

En este proyecto en particular la apariencia de inteligencia del juego estaba determinada por el comportamiento de los personajes dentro del mismo, por tal motivo, era necesario hacer uso de alguna técnica para soportar este hecho, así como también, de una metodología que permitiera trabajar en el modelado del mismo. Se pensó entonces en el uso de una metodología para realizar el proceso de análisis tal como GAIA [18]. Dicha metodología brindaba dos fortalezas: la primera de ellas es que es orientada a agentes, lo cual nos permitiría posteriormente hacer uso de los mismos como eje central de la lógica del juego, y la segunda es que no impone un núcleo para la implementación, sino que por el contrario, permanece desligada de esta etapa y brinda la posibilidad al desarrollador de escoger la estructura de implementación deseada.

La posibilidad de utilizar una metodología para el análisis y modelado orientado a agentes en Independencia, no sólo permitió el modelado del comportamiento de los personajes, sino que explora una técnica de vanguardia en el mundo de los juegos que está siendo adoptada por grandes casas de desarrollo de juegos como Sierra y su título Empire Earth.

Dado que en este proyecto el uso de GAIA es únicamente para propósitos de modelado del comportamiento de los personajes, se hace una descripción del mismo, antes de pasar al modelo de roles y posteriormente al de interacción.

• COMPORTAMIENTO DE LOS PERSONAJES

Todos los personajes que intervienen en la historia del juego y que fueron descritos en el guión representan integrantes dentro de un ejército u otro. Cada uno de ellos es denominado una Unidad, y en el caso especial de Juan Francisco Berbeo es denominado Prócer. El comportamiento que puede ser asumido por éstos actores es resumido en un diagrama de casos de uso que se muestra en la Figura 8, en el cual se observa que el actor Unidad puede vigilar, caminar, atacar a un enemigo, recibir un ataque, escuchar el grito comunero y morir, mientras que el actor Prócer puede asumir todo el comportamiento de una Unidad y adicionalmente puede lanzar el grito comunero.

Figura 8. Casos de uso para el comportamiento de los personajes

Cuando una unidad está en estado de vigilancia, constantemente verifica si hay enemigos en el área dentro de su rango de visión y de ser así, decide atacar a la unidad enemiga visualizada. Si la unidad decide atacar, se mueve hasta que el objetivo se encuentre dentro del rango de ataque y cuando suceda lo anterior, la unidad hace que su enemigo reciba el ataque. Cuando una unidad recibe un ataque, disminuye sus puntos de vida de acuerdo al poder de ataque de la unidad que realiza el ataque, combinado con la protección o armadura de la unidad atacada. Si luego de recibir un ataque, los puntos de vida de la unidad son menores o iguales a cero (0), la unidad muere. Luego de realizar un ataque, la unidad debe esperar un tiempo dado para poder realizar el siguiente ataque, dicho tiempo está determinado por la velocidad de ataque de la unidad.

Adicionalmente, una unidad puede caminar desde su posición actual a una nueva posición deseada en el terreno, para lo cual la unidad calcula la ruta que debe seguir hasta su destino e inicia el recorrido.

El tipo especial de unidad denominada un Prócer, tiene la habilidad de lanzar un grito de batalla que incentive a los combatientes comuneros para que ataquen con más ahínco. En el momento en que el prócer decide lanzar el grito, determina si ha pasado un tiempo suficiente desde la última vez que lo hizo para poder volver a lanzarlo. De ser así, las unidades de su ejército que están al 'alcance del grito' pueden escucharlo e incrementan su poder de ataque durante un lapso de tiempo determinado por la duración del grito.

• EL MODELO DE ROLES

Siguiendo la metodología de análisis GAIA se empezó por identificar los roles que iban a ser considerados dentro del juego. Esto con el fin de determinar que papeles eran relevantes y aportaban dentro de la configuración de la organización del juego. Como tal, se identificó únicamente el rol Unidad, el cual se detalla en la Tabla 6 mediante su esquema de rol.

Del esquema anterior se puede resaltar lo siguiente:

• Terreno es un recurso que representa la información geográfica del terreno donde se encuentra la unidad. El terreno esta dividido en Losas y cada losa tiene información específica de esa parte del terreno, como por ejemplo, la altura, si la losa es visible para el jugador o no y el factor de niebla que tiene la losa. La unidad (si es una unidad del jugador) en su desplazamiento por el terreno necesita cambiar el estado de visibilidad y el factor de niebla de las losas que se encuentran dentro de su rango de visión.

• Mapa es un recurso que representa la información acerca de los obstáculos en el terreno. Esta información es utilizada por las unidades cuando desean desplazarse de un lugar a otro dentro del terreno; por tal motivo esta información se encuentra en cambio constante.

• EsProcer: La unidad puede únicamente leer la información de este recurso, el cual le indica si puede, cada cierto intervalo de tiempo y a petición del usuario, incentivar a las unidades amigas que se encuentren cercanas a ella emitiendo el grito comunero. El tipo de unidad con esta capacidad es llamada un Prócer.

• EL MODELO DE INTERACCIÓN

Luego de haber hecho la identificación del rol Unidad, fue necesario definir las interacciones que podrían tener, un agente desempeñando este rol, con otros agentes en el sistema. Para lograr esto se definieron unos protocolos que podían ser usados por el rol Unidad. A continuación se muestran las definiciones de dichos protocolos.

• EL PROTOCOLO ATACAR

En protocolo Atacar se puede visualizar desde las perspectivas de la unidad que ataca y de la unidad que recibe el ataque. Desde el punto de vista de la unidad que ataca, esté protocolo es utilizado cuando la unidad visualiza a una unidad enemiga dentro del espacio abarcado por su rango de visión. Por otro lado, la unidad que recibe el ataque hace uso de este protocolo cuando una unidad enemiga ha completado un ataque en contra de ella; el resultado de esto es la disminución de los puntos de vida de la unidad receptora en una cantidad que depende del valor del ataque, llegando posiblemente a pasar al estado de muerte si sus puntos de vida llegan a ser menores o iguales a cero. Lo anterior se representa en la Tabla 7.

• EL PROTOCOLO GRITOCOMUNERO

En protocolo GritoComunero es básicamente una habilidad especial que puede tener una unidad y consiste en hacer que las unidades amigas cercanas a ella incrementen su nivel de ataque durante un tiempo determinado. Este tipo de unidad es llamada un prócer y el protocolo se describe en la Tabla 8.

DISEÑO

En esta etapa se tuvieron en cuenta dos fases: una inicial en la cual se crearon las bases para dar soporte a la parte gráfica y de musicalización del juego y otra en la cual se desarrollaron los artefactos para las aplicaciones que utilizaban los productos resultantes de la primera. A continuación se hablará en primera instancia del diseño del motor 3D para después pasar a lo relacionado con el diseño del visor de modelos, el editor de terrenos, el buscador de caminos y el juego.

MOTOR 3D

Una vez concebido el guión, se inició la tarea de construcción de la librería de clases base o el Motor 3D, el cual sirvió posteriormente para la creación del juego y quedó como un producto tangible independiente del juego y que sirve para el desarrollo de aplicaciones que necesitan hacer uso de características tales como objetos en 3D, música, sonidos, videos y control de los dispositivos de entrada (el teclado y el ratón). Para llevar a cabo esta labor, se inició en primer lugar, un trabajo de apropiación tecnológica en cuanto a la funcionalidad, interfaces y servicios expuestos por las API"s de DirectX Graphics y DirectShow, las cuales se encargan de la manipulación de objetos en 3D y flujos de medios (audio y video) respectivamente, esto se logró mediante el desarrollo del juego Defensor 3D. Luego se prosiguió con el diseñó de la jerarquía de clases que conformaría el motor y posteriormente a la construcción de cada una de estas.

• ESTRUCTURA JERÁRQUICA

Cuando se empezó el diseño del motor 3D, se buscó que permitiera la manipulación de gráficos en tres y dos dimensiones, además de audio y video. Este requerimiento inicial, planteó una necesidad no explorada hasta el momento: derivar todas las clases a partir de un tronco en común o por el contrario usar muchas derivaciones provenientes de diferentes partes, es decir utilizar una jerarquía en árbol o por el contrario en bosque. Al respecto Timothy Budd [19] comenta que la ventaja del enfoque de árbol es "que la funcionalidad proporcionada en la raíz del árbol es heredada por todos los objetos. En un lenguaje así, toda clase definida por el usuario debe ser una subclase de alguna clase ya existente que por lo general es la clase Objeto."

El otro enfoque sostiene que "las clases que no están lógicamente relacionadas deben ser por completo distintas. El resultado es que el usuario se enfrenta a un bosque compuesto por diversos árboles de herencia. Una ventaja de este enfoque es que la aplicación no está obligada a cargar con una gran biblioteca de clases, de las cuales podrían usarse sólo unas pocas. La desventaja es que no puede garantizarse que todos los objetos posean una funcionalidad definible por el programador."

Debido a que muchos de los objetos que se diseñaron para el motor, tenían mucho en común, se optó por una jerarquía en árbol (ver Figura 9), puesto que se consideró necesario que todo el motor fuese exportable, es decir, que se pudiera transportar y usar fácilmente. Además los objetos gráficos requerían del uso de recursos compartidos y generales a todos estos, tal como el dispositivo de video y un identificador global.

El dispositivo de video fue utilizado para el proceso de dibujado (Rendering), mientras que el identificador se empleó para ayudar al control de los eventos generados por los mensajes enviados desde la aplicación hacia los diferentes objetos. Estos mensajes son capturados por clases que implementan los servicios expuestos en las interfaces, haciendo uso del Patrón Escuchador.

Sin embargo, aunque la jerarquía utilizada fue la de árbol, no fue posible que todas las clases heredaran de la raíz en común ya que no mostraban características similares, y es por eso que algunas clases no se desprenden de la clase base (ver Figura 9).

Figura 9. Estructura jerárquica del motor 3D.

• DIAGRAMA DE CLASES

Para entender el diagrama de clases del motor 3D que se muestra en la Figura 9, es necesario dividirlo de acuerdo a la función de sus clases, examinando en primera instancia la clase base de la jerarquía, seguido por las clases para la creación de aplicaciones, las clases para el manejo de eventos, las de manipulación de objetos 3D, controles, medios y finalmente detallar las correspondientes a utilidades.

• CLASE BASE

Con el fin de que todas las clases gráficas pudieran tener acceso al dispositivo de video para su correspondiente dibujado y tuvieran un identificador único dentro de la aplicación que ayudara con el manejo de eventos y mensajes, se creó la clase CObjeto, la cual es la base de la jerarquía del motor 3D.

• CLASES PARA LA CREACION DE APLICACIONES

Durante la creación de una aplicación que hace uso de las características de Direct3D, es necesario realizar una serie de pasos encaminados a registrar la clase de Windows, definir un procedimiento para el procesamiento de mensajes de Windows, crear la ventana e inicializar un dispositivo Direct3D. En el motor 3D, todas estas operaciones son efectuadas por medio de un conjunto de clases dedicadas a tal labor, las cuales se describen a continuación:

• CAplicacion: El propósito de esta clase es el de manejar la instancia de la aplicación, para lo cual se encarga de registrar la clase de Windows y finalizarla cuando termina, así como también de recibir los mensajes de Windows y enviarlos a la ventana principal.

• CVentana: Esta clase permite la creación de ventanas de Windows, tales como formularios, botones, etiquetas, etc., además define un procedimiento para el procesamiento de los mensajes, los cuales son manejados por el escuchador de la ventana.

• CVentanaPrincipal: Esta clase hereda de CVentana y representa la ventana principal para la aplicación de Windows.

• CDirect3D: La función de esta clase es la de interactuar con la interfaz IDirect3D con el fin de inicializarla, verificar las capacidades de(l) dispositivo(s) de video, obtener los modos de pantalla y las tasas de refresco soportadas por el mismo y finalmente crear el dispositivo Direct3D obteniendo un puntero a la interfaz IDirect3DDevice9.

• CAplicacionD3D: El objetivo de esta clase es el de facilitar la creación de aplicaciones con soporte para Direct3D, para lo cual hereda de las clases CAplicacion y CEscuchadorVentana y crea un objeto de la clase CDirect3D con el fin de inicializar el dispositivo. Adicionalmente, ofrece funcionalidades típicamente requeridas por este tipo de aplicaciones tales como llevar el tiempo transcurrido entre actualizaciones de la misma, calcular los ticks por segundo y permitir la inicialización de un material o una luz.

• CLASES PARA EL MANEJO DE EVENTOS

La comunicación entre el sistema operativo Windows y sus aplicaciones se hace por medio de mensajes de diferentes tipos que son enviados a un procedimiento especial que debe definir la aplicación en el momento de registrar la clase Windows.

Para realizar el control de los mensajes de eventos que Windows pasa a la aplicación y más precisamente de los eventos generados por los objetos gráficos de la misma, se diseñó un conjunto de clases que permitiera realizar dicha tarea dentro del motor 3D. A continuación se describen las clases involucradas en dicho proceso y en la sección DIAGRAMAS DE SECUENCIA se presenta con más detalle el control de los mensajes de eventos dentro del motor 3D.

• CEscuchadorEventos: Interfaz que define un conjunto de métodos específicos para el control de los eventos relacionados con el ratón (mover, presionar un botón, liberar un botón, dar clic, girar la rueda) y el teclado (presionar o liberar una tecla).

• CEscuchadorVentana: En esta interfaz se definen los métodos para el control de los eventos propios de la ventana de la aplicación, como son crearse, activarse, desactivarse, cerrarse o ejecutar un comando.

• IObjetivo: Esta interfaz define los métodos por los cuales un objeto es informado del acontecimiento de un evento de ratón o teclado.

• CObjetivo: Clase base para los objetos que responden a eventos de ratón y teclado.

• SECCIÓN DE OBJETOS 3D

El motor 3D fue concebido principalmente para facilitar la creación de aplicaciones con soporte para Direct3D, razón por la cual fue necesario diseñar una colección de clases que permitieran la creación y manipulación de objetos tridimensionales, tal como modelos animados y estáticos, rayos, secuencias de imágenes, terrenos y losas. En seguida se muestra una descripción de la funcionalidad de cada una de estas clases:

• CEstatico: Esta clase permite cargar y pintar una malla (mesh) estática (sin animación).

• CAnimado: El objetivo de esta clase es permitir cargar, manipular y pintar una malla con animación incluida.

• CAlojarJerarquia: Esta clase permite alojar toda la jerarquía con la que se construye un modelo animado y su importancia radica en las operaciones que debe realizar para crear o liberar un frame o un contenedor en el momento de animar el modelo.

• CModelo: Esta clase representa un modelo animado o estático en el espacio tridimensional y hereda de la clase CObjetivo, por lo cual los objetos de este tipo puede responder a eventos de ratón y teclado.

• CRayo: Esta clase se encarga de crear un 'rayo', para que pueda ser utilizado en el momento en que se desee calcular si se hace clic sobre un objeto 3D.

• CSecuencia: Esta clase permite la creación de un objeto que hace uso de una secuencia de texturas para crear la sensación de estar visualizando una textura animada en el espacio 3D.

• CTerreno: La función de esta clase es la de facilitar la construcción de un terreno en 3D que hace uso de losas. Un ejemplo de aplicación de este tipo de objeto es los juegos de estrategia.

• CLosa: Esta clase representa una losa dentro del terreno 3D y guarda información relacionada con la altura y posición del vértice.

• SECCIÓN DE CONTROLES

Generalmente, una aplicación que usa objetos 3D, necesita también hacer uso de objetos en dos dimensiones para la construcción de interfaces de usuario. Estos objetos pueden ser botones, imágenes, etiquetas, diálogos y otros.

En el motor 3D, se diseñaron varias clases con las cuales, un desarrollador puede construir una interfaz de usuario enriquecida con controles en dos dimensiones. Estas clases se presentan a continuación.

• CControl: Clase base que permite la creación de objetos que se muestran en dos dimensiones haciendo uso de Direct3D. Cada control posee tres estados: libre (el control se encuentra libre), abajo (el control esta presionado), arriba (el control no está presionado, pero el ratón está sobre él) y click (se hizo click sobre el control).

• CImagen: Esta clase es un control que permite la visualización de imágenes.

• CEtiqueta: Esta clase permite mostrar un texto en la pantalla.

• CBoton: Este control permite la creación y manipulación de botones.

• CBotonImagen: Esta clase es un botón que permite mostrar una imagen diferente en cada uno de los tres estados gráficos del control: libre, abajo o click, arriba.

• CCajaTexto: Mediante esta clase se puede crear una caja que permite el ingreso de texto por parte del usuario.

• COpcion: La función de esta clase es la de permitir la construcción de un objeto que tiene un cuadro de chequeo y un texto.

• CFormulario: Esta clase es un contenedor de controles y su principal función es la de facilitar el paso de mensajes a los objetos que contiene.

• CCuadroMensaje: Mediante esta clase se puede mostrar un dialogo que contiene un mensaje y un botón Aceptar.

• CEntradaTexto: Este es un dialogo para solicitar al usuario la entrada de un texto.

• CCuadroAceptarCancelar: Este dialogo permite mostrar un mensaje al usuario con las opciones Aceptar y Cancelar.

• SECCIÓN DE MEDIOS

Cuando se construye una aplicación que hace uso de características tales como el 3D, puede resultar útil tener la posibilidad de incluir audio o video a la misma. Por tal motivo, dentro del motor 3D se incluye una clase que se encarga de crear y controlar lo referente a flujos multimedia, tanto de audio, como de video.

Dicha clase se denomina CMedio y sirve para la manipulación de contenido multimedia, tal como videos y música en formatos avi, mpeg, wav, mp3, etc. Para lograr esto, la clase hace uso de la API DirectShow, la cual se describe con más detalle en el Anexo F.

• SECCIÓN DE UTILIDADES

Esta sección comprende todas las clases que brindan utilidades complementarias a la funcionalidad de las clases antes mencionadas, y que igualmente son importantes dentro de la construcción de aplicaciones Direct3D. A continuación se detallan las clases.

• CExcepcion: Clase genérica para el manejo de excepciones.

• CFuente: Esta clase permite definir un tipo de fuente para utilizar posteriormente en etiquetas y demás objetos 2D.

• CTexto: Esta clase sirve para manipular cadenas de texto.

• CCamara: Permite la creación de un objeto que guarda información de una cámara en el espacio 3D.

• CLista: Mediante esta clase se puede manejar una lista enlazada de punteros a la información de otras clases.

• CNodo: Define un nodo dentro de una lista enlazada dinámica.

• CTablaClaves: Esta clase permite construir una tabla de claves, asociando un objeto de cualquier tipo con una clave de búsqueda.

• CNodoClaves: Esta clase guarda la información de un registro dentro de la tabla de claves.

• DIAGRAMAS DE SECUENCIA

Durante la etapa de diseño del motor, no se estimó necesaria la realización de diagramas de secuencia para todas las clases. Sin embargo, fue conveniente crear un diagrama de secuencia para poder tener una mejor visualización de cómo se lleva a cabo el proceso de control de los mensajes de eventos generados dentro del motor 3D.

En el motor 3D, los mensajes son recibidos por el procedimiento de ventana de la clase CAplicación y desde allí enviados a la ventana principal, la cual determina el tipo del mensaje e informa a su escuchador de ventana. El escuchador de ventana, generalmente debe informar a los controles apropiados del evento. Cuando un control es informado de un evento, éste realiza algunas comprobaciones, como por ejemplo si el ratón se encuentra sobre el objeto (cuando el evento es de ratón). De ser así informa a su respectivo escuchador para que este controle apropiadamente el evento generado. Todo lo anterior puede visualizarse en el diagrama mostrado en la Figura 10 en el cual se supone que el evento generado es un botón del ratón que se presionó.

Figura 10. Diagrama de secuencia del manejo de mensajes.

VISOR DE MODELOS

Después de determinar que el Motor 3D cumplía con la funcionalidad necesaria para la creación del juego surgieron dos inconvenientes:

• 1. Era necesario tener un punto en común con el diseñador gráfico, de tal manera que los personajes que modelara, pudieran ser cargados y mostrados adecuadamente por el motor, ya que cuando se realizaron los primeros modelos se encontraron problemas como intercambio de ejes, animaciones mal hechas y problemas en el manejo de luces. Estos problemas se originaron principalmente porque para poder exportar los modelos desde 3D Studio Max (que fue la herramienta utilizada por el diseñador gráfico) al formato de DirectX, era necesaria la utilización de un plug – in (Panda DirectX) que en principio fue difícil de configurar adecuadamente.

• 2. Hacía falta un módulo que permitiera probar el adaptador de video, puesto que no en todos los equipos era posible iniciar Direct3D, que es la base para el motor.

La solución planteada fue la de crear una aplicación en la cual se pudiera probar los modelos desarrollados por el diseñador gráfico y que además permitiera configurar el adaptador de video.

Esta aplicación por supuesto, daría las bases para entender aún más los conceptos relacionados con matrices de transformación, luces, control de animaciones y por supuesto configuración del adaptador de video. En la Figura 11 se muestra el diagrama de casos de uso para el visor de modelos, donde se establece la funcionalidad básica de la aplicación.

En primera instancia se puede apreciar que el usuario puede cargar un modelo 3D, esto es, buscar un archivo en formato de DirectX (*.x), leerlo y mostrarlo (pintarlo). Después de esto se puede manipular el modelo 3D, en cuando a realizarle transformaciones (como mover, rotar o escalar), iluminarlo o no, cambiar la forma de presentación (en malla, sólido o con una esfera contenedora), o controlar las animaciones si ese era el caso. Adicionalmente, permitía configurar el adaptador de video para que trabajara en distintos modos de pantalla.

Figura 11. Diagrama de casos de uso para el visor de modelos

Para la implementación del visor de modelos se tuvo en cuenta que el motor 3D ya soportaba y proporcionaba la funcionalidad necesaria para su creación (del visor), por lo que se utilizaron las clases que se detallan en el diagrama mostrado en la Figura 12.

Como se aprecia el modelo es bastante simple y solamente consideró tres clases externas al motor, pero que de alguna manera se relacionaban con este mediante la especificación de clases que soportaban toda la funcionalidad requerida.

El diagrama de clases muestra como se creó una clase llamada CVisor3D que heredaba de CAplicacionD3D y que contenía una clase de tipo CModelo y otra de tipo CAnimado. Aquí se encuentra la funcionalidad principal del visor, es decir, la clase CVisor3D permitiría crear la aplicación, mientras que CModelo y CAnimado, estarían encargadas de facilitar la manipulación de los modelos tridimensionales hechos por el diseñador gráfico. Además se diseñó otra clase que se encargará de mostrar un cuadro de diálogo para definir las opciones de creación del adaptador de video. Esta clase se encargaría de cargar las opciones desde un archivo de configuración, facilitaría la configuración y también guardaría los cambios realizados.

Pensando en el futuro, se decidió que la clase CDlgPreferencias, quedara por fuera del visor, porque sería necesaria para la configuración del adaptador de video de otras aplicaciones como el mismo juego.

Figura 12. Diagrama de clases del visor de modelos

EDITOR DE TERRENOS

Cuando se comenzó a trabajar con el motor, se descubrió que el proceso de edición de un terreno es un trabajo que resultaría engorroso y difícil de realizar si no se cuenta con una herramienta que lo facilite, puesto que es necesario determinar la altura de cada vértice de las losas, la textura que usa cada una de ellas y la ubicación de los modelos de ambientación. Además, esta dificultad es directamente proporcional al tamaño del terreno debido a que con un terreno más grande se debe usar un número mayor de losas.

Se plantea entonces, la creación del editor de terrenos como una aplicación que ayuda a agilizar el proceso de ubicar texturas y ambientación y editar las alturas de un terreno. Para lograr esto, en la etapa de diseño se delimitó la funcionalidad esperada de la aplicación mediante un diagrama de casos de uso, el cual se muestra en la Figura 13. De dicho diagrama cabe resaltar que el actor de todos los casos de uso es llamado Usuario, el cual puede ser el desarrollador del juego u otro integrante del proyecto de desarrollo, por ejemplo las personas encargadas de la labor de modelado de los personajes y la ambientación. En este sentido, es de resaltar, que el editor de terrenos fue de gran utilidad para el diseñador gráfico, porque le permitió escalar adecuadamente los modelos de los personajes y de la ambientación de acuerdo al tamaño del terreno y además le ayudo a visualizar el aspecto más acertado para las texturas que utilizarían las losas del terreno.

Figura 13. Diagrama de casos de uso del editor de terreno.

La aplicación permite, en primer lugar, que el usuario cargue un terreno ya existente o guarde el terreno que se encuentra editando, desde o hacia un archivo, respectivamente. Además, el usuario tiene la posibilidad de crear un nuevo terreno pudiendo escoger el tamaño deseado (pequeño, mediano, grande o enorme) y también si desea usar un archivo con información para las alturas del terreno o simplemente desea que éste comience plano.

Ya en el campo de la edición del terreno, el usuario tiene la posibilidad de aplicar la textura que desee a una losa seleccionada, ubicar un elemento o modelo de ambientación y también cambiar la altura de los vértices de la misma con el fin de generar formaciones montañosas o variaciones en la altura del terreno.

Además, el usuario puede interactuar con el mini mapa dando clic sobre él, de tal forma que la cámara de la aplicación se ubique en la parte del terreno que se selecciona. Otra forma en la que el usuario puede cambiar la parte del terreno que se encuentra visualizando es a través del uso del teclado, de modo tal que la cámara se desplace en una dirección deseada (adelante, atrás, hacia la izquierda o hacia la derecha).

Finalmente, si el usuario lo desea, puede hacer que la aplicación muestre el terreno y los objetos de ambientación en modo de malla, o que la ambientación se pinte de modo transparente. El modo malla hace que se visualicen simplemente el conjunto de líneas que unen los vértices del modelo tridimensional, mientras que el modo transparente hace que los objetos de ambientación se pinten de tal forma que permitan ver los objetos que hay detrás.

Con el fin de implementar la funcionalidad del editor de terreno descrita anteriormente, se diseñó un conjunto de clases que hacen uso de los artefactos generados para el motor 3D, las cuales se muestran en el diagrama de clases de la Figura 14.

Figura 14. Diagrama de clases del editor de terreno.

En dicho diagrama se puede destacar que las clases que se encuentran en color amarillo, son clases derivadas del motor 3D y la clase de color violeta (CMiniMapa) es necesaria para el juego Independencia, mientras que las clases de color azul claro son específicas al editor de terreno. De estas últimas, la clase CEditorTerreno es la clase responsable de la aplicación ya que hereda de CAplicacionD3D y por tanto es el escuchador de eventos de los objetos gráficos de la misma. Esta clase es la responsable de crear el mini mapa, la cámara y el terreno que el usuario edita. Hace uso también, de un objeto CEntradaTexto para pedir el nombre del archivo de terreno, cuando el usuario desea cargar o guardar un terreno, de un objeto CCuadroMensaje para mostrar mensajes de información al usuario, y de un objeto CCuadroAceptarCancelar para preguntar al usuario si desea sobrescribir un archivo de terreno cuando este ya existe. Finalmente, esta clase crea los objetos de tipo CMenuEditor, CBotonesEditor y CNuevoTerreno.

La clase CMenuEditor es la encargada de mostrar un menú al usuario con las opciones para crear un nuevo terreno, cargar uno ya existente, guardar el actual en un archivo o salir de la aplicación. Las opciones para seleccionar una textura o un modelo de ambientación o editar la altura de una losa, son presentadas al usuario a través de la clase CBotonesEditor. Finalmente, cuando el usuario decide crear un nuevo terreno, se le muestra un diálogo en el que puede seleccionar el tamaño e ingresar el nombre de un archivo con información para las alturas del terreno, si así lo desea. La clase responsable de mostrar este dialogo es la clase CNuevoTerreno.

BUSCADOR DE CAMINOS

A medida que iba creciendo el proyecto e iba tomando forma, apareció un nuevo reto: lograr que los personajes que iban a intervenir dentro del juego pudieran desplazarse dentro del terreno definido para éste. La solución a este dilema fue el estudio y adopción del algoritmo A estrella para la búsqueda de caminos, puesto que combina lo mejor de otros algoritmos como es: una búsqueda rápida y cálculo de la mejor ruta. Se procedió entonces a diseñar una aplicación que permitiera hacer pruebas para la búsqueda de caminos y evaluar el rendimiento de la implementación que se haría.

Una vez realizada la primera fase de implementación y hechas las pruebas de rendimiento, se determinó que el algoritmo presentaba algunas falencias que debían corregirse, por lo que en otra iteración dentro del proceso de desarrollo, se buscaron soluciones para estos problemas. Específicamente se encontró que el algoritmo en determinadas situaciones llegaba a visitar un número muy elevado de nodos, razón por la cual, su tiempo de respuesta se incrementaba considerablemente (haciendo muy lento el juego). La solución para esto fue limitar el número de nodos visitados de acuerdo con el tamaño del terreno.

En este proceso de prueba, aprendizaje, experiencia y mejora, fue de vital importancia la aplicación para la búsqueda de caminos, ya que permitió encontrar un algoritmo más óptimo, que posteriormente se utilizó dentro del juego. La funcionalidad de esta aplicación se muestra en el diagrama de casos de uso detallado más adelante y posteriormente se exhibe el diagrama de clases en el que se presentan las diferentes relaciones entre las clases utilizadas para la creación de la misma.

Para la aplicación de búsqueda de caminos, se consideró que debía permitir cargar distintos terrenos con el fin probar diferentes escenarios a los cuales se podría enfrentar el algoritmo. Una vez cargado el terreno, el desarrollador debería tener la posibilidad de desplazarse por el terreno usando el teclado para la navegación o interactuando con un mini mapa. Finalmente, era necesario que la aplicación permitiera al desarrollador ordenarle al modelo moverse hasta una determinada posición, utilizando por supuesto, el algoritmo A estrella. En este último paso el sistema debería mostrar las estadísticas relacionadas con la búsqueda del camino, tales como el número de nodos abiertos y cerrados usados por el algoritmo, el número de nodos de la ruta y el tiempo empleado para realizar el cálculo. Toda esta funcionalidad se expone en el diagrama de casos de uso mostrado en la Figura 15.

Figura 15. Diagrama de casos de uso del buscador de caminos

La construcción de la aplicación para la búsqueda de caminos, continuó con la creación de un diagrama de clases que permitiría establecer las clases usadas para la misma y las relaciones entre ellas. Este diagrama se muestra en la Figura 16, en la cual se observa que la clase CAplBuscadorCamino es la clase que hereda de CAplicacionD3D y por tanto es la encargada del control de la aplicación. Además, la clase crea el terreno, la cámara, el mini mapa, el modelo y su animado, un dialogo CEntradaTexto para leer el nombre del archivo de terreno que se desee cargar, un dialogo CCuadroMensaje para mostrar un mensaje cuando no se puede cargar el archivo y una etiqueta para mostrar las estadísticas de los cálculos de camino.

Figura 16. Diagrama de clases del buscador de caminos

Cuando el usuario ordena a la aplicación que mueva el modelo desde un punto a otro dentro del terreno, la clase CAplBuscadorCamino hace uso de un objeto del tipo CBuscaCamino, el cual es el encargado de realizar el cálculo de la ruta entre los puntos. Para realizar esa labor, la clase hace uso de dos listas del tipo CListaCamino con el fin de mantener los nodos cerrados y los nodos abiertos por el algoritmo durante el proceso. Cada nodo dentro de estas listas es almacenado por un objeto del tipo CNodoListaCamino y la información relacionada con el nodo de la ruta, como su posición en el terreno, su antecesor y su costo, son guardadas en un objeto del tipo CNodoCamino, el cual sirve, posteriormente, para generar una lista del tipo CLista con los nodos de la ruta encontrada. Esta última lista es almacenada por la aplicación para que posteriormente el modelo pueda seguirla.

INDEPENDENCIA

Llegada la hora de abordar el diseño de Independencia, se tenía la experiencia y el conocimiento fruto del esfuerzo realizado en los anteriores desarrollos, por lo que se nutrió de lo explorado en Defensor 3D, y los diseños realizados para el visor de modelos, el editor de terrenos y el buscador de caminos.

La experiencia del desarrollo de Defensor 3D fortaleció el diseño del Motor 3D, puesto que no solo se obtuvieron las bases que permitieron la definición jerárquica del motor, sino que se obtuvo la suficiente madurez y experiencia para definir las clases apropiadas para las diferentes tareas que debía soportar, como manejo de gráficas en dos y tres dimensiones, carga y reproducción de flujos de medios, control de aplicaciones y mensajes de eventos.

En cuanto a los diseños previos, se puede resaltar que del visor de modelos se consideró lo concerniente al manejo de modelos que separaban la animación de la lógica del mismo (tal como la posición, rotación, escala, animación actual, tiempo de animación, etc.), del editor de terreno se rescató lo referente al manejo del terreno, el movimiento de la cámara, y el encapsulamiento de la funcionalidad (considerando una clase que se encargara de funciones comunes, por ejemplo una clase para el manejo del menú que controlaba los eventos para los objetos que hacían parte de éste). Del buscador de caminos se utilizó todo el bagaje y la experiencia adquiridos tratando de robustecer el algoritmo A estrella.

Aunque se contaba con diseños que se podían reutilizar en parte, hacia falta abordar un problema que ya se había considerado en el análisis, como era el del comportamiento de las unidades. En esa etapa se había propuesto la utilización de la metodología de GAIA para la definición de agentes que modelaran el comportamiento de los personajes en el juego y en este diseño se identificaron los distintos tipos de agentes que intervendrían en el sistema y los servicios que deberían implementar. Posteriormente, el diseño de GAIA se modeló de tal forma que se pudiera integrar al diseño realizado con UML y de esta manera facilitar la tarea de implementación.

• DISEÑO GAIA

El proceso de diseño en la metodología GAIA involucra la generación de 3 modelos: El Modelo de Agentes, El Modelo de Servicios y El Modelo de Conocidos.

• EL MODELO DE AGENTES

El modelo de agentes en la Figura 17 indica que el sistema únicamente contendrá el tipo de agente AgenteUnidad, el cual asumirá el rol Unidad. Además, en el modelo se puede ver que habrá una o más instancias de este tipo de agente en el sistema en tiempo de ejecución.

• EL MODELO DE SERVICIOS

La Tabla 9 muestra el modelo de servicios implementados por el tipo de agente AgenteUnidad.

• EL MODELO DE CONOCIDOS

El modelo de la Figura 18 muestra que existe un enlace de comunicación entre el tipo de agente AgenteUnidad y otro(s) agente(s) del mismo tipo.

• DISEÑO UML

Luego de haber trabajado en la definición de los tipos de agentes que implementarían el comportamiento de los personajes en el juego mediante la metodología GAIA, fue necesario abordar la funcionalidad que expondría la aplicación hacia el usuario final o jugador. Se definieron, entonces, casos de uso de diseño y diagramas de clases de manera que se lograra modelar los requerimientos básicos que debe contener todo juego, así como los propios de Independencia y que se expresaron mediante la definición del guión.

El primer diagrama de casos de uso que se muestra en la Figura 19 detalla la funcionalidad en general del juego. Ahí se puede apreciar como el jugador puede en primera instancia, configurar el adaptador de video, esto es, determinar cuál resolución de pantalla y formato de dibujado es el apropiado para la tarjeta de video que posee. Este caso de uso inicia cuando el sistema determina que no hay una configuración para el adaptador de video y en ese momento se muestra un cuadro de diálogo que permite realizar la configuración.