Escenarios virtuales - Desarrollo de modelos JA Ghoul 2, MD3 y escenarios en 3D

XOFT CORP

Escenarios virtuales

Desarrollo de modelos JA Ghoul 2, MD3 y escenarios en 3D

Este documento contiene información del motor de juego id Tech 3, GtkRadiant, y desarrollo temprano por parte de XOFT CORP para mantener en vigencia La Guerra de las Galaxias Batallas de película II (SW Movie Battles II)

Luis Daniel González Dávila

26/01/2024

Revisión 1.4

id Tech 3

Id Tech 3 es un motor de juego desarrollado por id Software para Quake III Arena y se ha utilizado en muchos juegos que usan el motor de Quake III Arena y la marca de motor Quake III: Team Arena. Durante su tiempo, compitió con el motor Unreal , ambos motores fueron ampliamente disponibles.

Mientras id Tech 3 se basa en id Tech 2, una gran parte del código fue reescrito. El sucesor id Tech 4 se deriva de id Tech 3.

En QuakeCon 2005, John Carmack anunció que el código fuente de Quake III Arena se distribuiría bajo la Licencia Pública General de GNU (versión 2), y fue lanzado el 19 de agosto de 2005. El código puede ser descargado desde el sitio FTP de id.

Características del motor

Gráficos

A diferencia de la mayoría de los otros motores de juego liberados en el momento, incluyendo su principal competidor, Unreal Tournament, id Tech 3 requiere un acelerador de gráficos compatible OpenGL para ejecutar. El motor no incluye un renderizador software.

íd Tech 3 introdujo superficies curvadas basados en spline, además de volúmenes planares, que son responsables de muchas de las superficies presentes en el juego. [1]

Shaders

La tecnología gráfica del juego se basa fuertemente en torno a un shader del sistema donde se encuentra la aparición de muchas superficies definidas en archivos de texto denominados secuencias de comando para sombreado (shader scripts). Los shaders se describen y se representan como varias capas, cada capa contiene una textura, un “modo de mezcla” (blend mode), que determina cómo superponerla sobre la capa anterior y modos de orientación de textura tales como el mapeo de ambiente, desplazamiento y rotación. Estas características se pueden ver fácilmente en el juego con muchas superficies brillantes y activas en cada mapa e incluso en modelos de los personajes. El sistema de sombreado va más allá de la apariencia visual, definiendo los contenidos de volúmenes (por ejemplo, un volumen de agua se define mediante la aplicación de un shader de agua a sus superficies), la emisión de luz y sonido que se reproduzca cuando un volumen es pisoteado. [2] Con el fin de ayudar con el cálculo de estos shaders, id Tech 3 implementa una determinada función rápida de raíz cuadrada inversa, que atrajo a una gran cantidad de atención en la comunidad de desarrollo de juegos para su uso inteligente de las operaciones con enteros. [ 3] [4]

Vídeo

En videojuegos usan un formato de vídeo propietario llamado “RoQ”, que fue creado originalmente por Graeme Devine, diseñador de Quake 3, para el juego The 11th Hour. Internamente RoQ usa cuantificación vectorial para codificar vídeo y DPCM para codificar audio. Mientras que el formato es propietario se le aplicó exitosamente ingeniería inversa en 2001, [ 5] y el propio decodificador RoQ está presente en la liberación de código fuente del Quake 3. RoQ ha visto poco uso fuera de los juegos basados en motores id Tech 3 o id Tech 4, pero está con el apoyo de varios reproductores de video (tales como MPlayer) y un puñado de codificadores de otros fabricantes existe.

Modelos

id Tech 3 carga modelos 3D en el formato MD3. El formato utiliza movimientos de vértice (a veces llamado animación por vértice) en lugar de animación del esqueleto con el fin de almacenar animación. Las funciones de animación en el formato MD3 son superiores a los del MD2 formato id Tech 2 porque un animador es capaz de tener un número variable de fotogramas clave por segundo en lugar del estándar MD2 de 10 fotogramas clave por segundo. Esto permite animaciones más complejas que son menos “inestables” que los modelos que se encuentran en Quake II.

Otro formato es el Ghoul 2 (GLM) para los modelos de jugador y NPC. Estos modelos se dividen en tres partes diferentes que están ancladas entre sí. Típicamente, esto se utiliza para separar la cabeza, torso y las piernas de modo que cada parte puede animar independientemente por la buena mezcla de animación (es decir, una animación en ejecución en las piernas, y la animación de disparo en el torso). Cada parte del modelo tiene su propio conjunto de texturas.

Los modelos de los personajes se iluminan y ensombrecen con sombreado Gouraud mientras que los niveles (almacenados en el formato BSP) se iluminan ya sea con lightmaps o sombreado Gouraud dependiendo de la preferencia del usuario. El motor es capaz de llevar las luces de colores de la rejilla de luz y aplicarlas a los modelos, lo que resulta en una calidad de iluminación que fue, para su época, muy avanzada.

En la versión con licencia GPL del código fuente, la mayoría del código tratado con los archivos de animación del esqueleto MD4 está perdido. Se supone que id simplemente nunca terminó el formato, [6] aunque casi todos los titulares de licencias derivaron sus propios sistemas de animación esquelética, que estaba presente. Ritual Entertainment hizo esto para su uso en el juego, Heavy Metal: FAKK2, el SDK que constituyó la base del soporte MD4 completado por alguien que usó el seudónimo Gongo. [7]

Existe otro tema relacionado con el tratamiento de modelos de un formato distinto al Autodesk 3D Studio. Esto es cuando primero se tiene el modelo en un formato como el OBJ. Para evitar problemas con la exportación a formato Ghoul 2 de un modelo que ya tiene mapeo UV, el modelo debe exportarse a formato de 3D Studio. A continuación importarlo en un programa como Blender, el cual es primer paso para iniciar el “rigging”. Una vez importado, los objetos que superen los límites del motor gráfico deben de dividirse en otros objetos que tengan tengan menos vértices. Después de esto, ya comienza a definirse las propiedades de cada objeto y realizar animación en el modelo, que veremos en el caso de estudio proyecto turbo láser DBY-827. Finalmente se exporta normalmente al formato Ghoul2 como si se tratara de un modelo realizado en Autodesk 3D Studio.

Sombras dinámicas

El motor es capaz de tres tipos diferentes de sombras. Una sólo coloca un círculo con bordes descoloridos a los pies de los personajes, comúnmente conocida como la técnica “gota de sombra”. Las otras dos formas proyectan una sombra precisa poligonal a través del piso. La diferencia entre éstos dos formas es una de dependencia de sombras opacas, negras sólidas, mientras que los intentos de otra forma (con éxito) para proyectar el volumen de profundidad de paso en un negro casi transparente. Ninguna de éstas técnicas recortan los volúmenes de sombras, haciendo que las sombras se extiendan hacia abajo a través de las paredes y la geometría.

Proyecto turbo láser DBY-827

En este proyecto se creó un modelo JA Ghoul 2 para que funcione en el motor id Tech 3, el cual se llama DBY-827, y se creó mediante el software Blender. Para ello se comenzó con un archivo .blend, el cual es un código binario inicial del modelo (Nota: los script se tratan en el proyecto Game Downfall of A Droid). Este modelo posteriormente debe exportarse y los resultantes (otros formatos de archivo) incluirse en un comprimido en formato pk3, el cual además puede incluir scripts y otras cosas necesarias para crear un add-on1 completo. De aquí en adelante se tratará cómo se ha ido desarrollando este add-on.

Requisitos previos

Antes de instalar las herramientas de software para realizar el proyecto, es recomendable actualizar la tarjeta de video para que soporte OpenGL. Luego debe instalar el juego con el que se va a trabajar, antes que las herramientas de desarrollo. El juego que se requiere en este caso es Star Wars Movie Battles II [47], un mod de Star Wars Jedi Knight: Jedi Academy [45]. Abreviado por los jugadores simplemente como “MBII”, cuyo motor está basado en id Tech 3, tratado en las secciones anteriores. Una distribución de éste juego está disponible en muchos sitios web. Por motivos académicos, se puede acudir al sitio oficial, aunque para proyectos lucrativos, sería conveniente tener una aprobación del equipo de desarrollo.

Después sigue la instalación de las herramientas de software gratuitas que se utilizan para crear nuevos proyectos para éste videojuego: Blender 2.64ª, Blender Jedi Academy Plugin Suite v.0.2.1 ó v.3.0.0 (versión actual), GtKRadiant 1.5 y el kit de desarrollo público para Jedi Academy (el cuál se tratará en el proyecto Game Jedi Crash). No se abordará cómo instalar Blender, ya que todo es por defecto.

Blender Jedi Academy Plugin Suite v.0.2.1 y v.3.0.0

Es una suite desarrollada por “mrwonko” Schinmeyer, un estudiante de Ciencias Computacionales. Esta suite contiene manual y varios archivos en lenguaje phyton que facilitan la importación y exportación de varios formatos que reconoce Jedi Academy:

 Exportador ASE (geometría estática)

 Importador ASE (geometría estática)

 Exportador GLA (animaciones)

 Importador GLA (animaciones)

 Exportador GLM (modelos de jugador animados)

 Importador GLM (modelos de jugador animados)

1 En este caso de estudio, un add-on es una adición a un juego existente de rol (RPG), juego de mesa o videojuego

 Exportador MD3 (geometría animada estática / por vértice)

 ROFF Exportador (animación cuerpo rígido)

 ROFF Importador (animación cuerpo rígido)

Además de poder utilizar esta suite para un modelo existente de un jugador, es posible crear nuevos modelos humanoides y también modelos que simulan objetos mecánicos. En este documento se enfoca en cómo hacer un objeto mecánico animado.

Instalación

En este documento se trata un ejemplo de cómo instalar en Windows de 32 y 64 bits una vez ya descargado del sitio e instalado Blender. Para instalaciones en otras plataformas, consulte si hay lanzamientos disponibles. Si ya instaló el videojuego y mod visto en la sección Software requerido, a continuación realice éstos pasos:

1° Inicie Blender. Seleccione el menú File y la opción User Preferences

2° En el cuadro de diálogo User Preferences, haga clic en la ficha Addons.

3° Haga clic en el botón Install Addon… busque el archivo BlenderJAPluginSuite0.2.1.zip o la versión más reciente (ej. jediacademy plugins 3.0 for Blender.zip)

4° Una vez instalado, no olvide activar el complemento. Se encuentra ubicado en la categoría Import-Export llamada “Import-Export: Jedi Academy Import / Export Tools".

5° Haga clic en Save User Settings por lo que todavía estará activa esta suite la próxima vez que empiece con Blender.

Proyecto inicial: uso de Blender para crear un esqueleto y su animación

En este apartado no se tratará de cómo hacer un modelo desde cero, sino más bien modificar y procesar un modelo estático (con o sin textura). Después de haber instalado primero el Blender y luego la suite de plugins (Blender Jedi Academy Plugin Suite v.0.2.1 ó v.3.0.0). Se procede a importar un modelo estático, en este caso el modelo correspondiente al turbo láser DBY-827, que está en formato 3DS.

Para poder hacer una animación se necesitan otras entidades (huesos) los cuales pueden estar conectados o no según el modelo que se vaya a animar. Un esqueleto es una forma de organizar la jerarquía de las partes que se van a mover del modelo durante la secuencia de animación. Antes de hacer el esqueleto, el modelo debe tener las siguientes características, las cuales se deben de efectuar con Blender:

1° El modelo debe de dividirse en varios mesh donde cada uno no debe superar más de 1000 vértices, de lo contrario, no servirá en el motor de id Software. Para esto, en Blender se trabaja en modo edición, y una vez seleccionadas las caras/vértices debe acceder a la opción Mesh > Vertices > Separate > Selection.

2° Crear la estructura de datos scene_root, y dentro de esta, otras dos con estos nombres: model_root_0 y skeleton_root. La primera rama se va a utilizar para referir a las partes del modelo que se separaron y la segunda es para el esqueleto ya comentado. A continuación, una muestra de cómo se ve el contenido de las estructuras de datos turbo láser DBY-827:

En la estructura model_root_0 cada uno de los mesh ( ) deben tener modificadores, similar al siguiente ilustración:

En este caso, al mesh DBY-827_SO se le agregó un modificador llamado Armature con el nombre skin. El nombre del objeto del esqueleto a seleccionar es skeleton_root (como no se ha creado, se deja vacío el cuadro de texto hasta el final del paso 3), y debe estar sólo enlazado a Vertex Groups. Es importante no hacer nunca clic en los tres botones (Apply, Apply as Shape Key y Copy) ya que al hacer esto desaparece el modificador y la exportación no será correcta.

También en cada mesh se requiere establecer la siguiente información para los vértices. Para hacer esto, ya debería haberse separado el modelo en varios mesh, y a continuación trabajar en modo edición, y en la vista 3D seleccionar el mesh correspondiente. Después en las propiedades, debe ubicarse en la sección vértices, como en la siguiente imagen:

Una vez seleccionado, hacer clic en el botón agregar (+) del marco Vertex Groups y poner un nombre al grupo de vértices (ej. model_root_, para el cimiento o base del modelo) Si el mesh fuera parte del cuerpo principal, el nombre sería body_bone. Luego hacer clic en el botón Select para seleccionar los vértices que están seleccionados en la vista 3D.

A continuación hacer clic en el botón Assign para que estos vértices se asignen al grupo de vértices.

Como el modelo no sólo consiste de vértices conectados, también se requiere crear los “UV seams”. Para esto, hacer clic en el botón agregar (+) del marco UV Maps para crear los UV seams de este grupo de vértices. Por último, hay que ubicarse en la categoría de Propiedades del objeto y llenar la información como la siguiente ilustración:

En el grupo de Propiedades Relations, sólo hay que elegir el objeto padre (ej. model_root_0, etc.) del cual depende este mesh.

Después hay que agregar las Propiedades Ghoul2, haciendo clic en el botón Add G2 Properties del grupo Ghoul2 Properties

La propiedad g2_prop_name debe ingresar un nombre más simple, que va a tener este objeto al ser exportado, que en este caso como se trata de un mesh base del modelo, sería “base”.

La propiedad g2_prop_shader sirve para indicar el nombre físico del archivo de textura el cual contiene la textura de este mesh. Si el mesh fuera un mesh que sirve para el origen de algún láser, el contenido de su cuadro de texto sería [nomaterial]

La propiedad g2_prop_tag se utiliza por ejemplo en un mesh que sirve para el origen de algún láser. En este caso hay que activar la casilla de verificación de esta propiedad.

Como puede ver en la ilustración aparecen los campos name y shader, y también se tiene que llenar estos campos.

3° Después crear en modo Object la estructura skeleton_root (Add > Armature > Single Bone) y agregar cada hueso que va a relacionarse con el grupo de vértices, y moverlo para asignarlo jerárquicamente, simplemente moviéndolo hacia dentro de su hueso “padre”. El nombre de cada uno de los huesos debe corresponder con el nombre del grupo de vértices que se creó en el paso anterior. Otra información requerida en el esqueleto es la siguiente:

En esta sección se ha indicado el objeto padre del objeto skeleton_root, es cual debe ser siempre scene_root. Las propiedades Ghoul 2 se agregan automáticamente haciendo clic en el botón Add del grupo

Custom Properties. Si desea cambiar la escala del esqueleto, se ingresa el porcentaje en el cuadro de texto g2_prop_scale, y luego hacer clic en el botón edit para ingresar otras propiedades (Min y Max) para ingresar el porcentaje mínimo y máximo de la escala), los cuales serían 0.000 y 1.000.

4° Se procede a crear la animación del modelo. Para esto ya debería haber tenido idea de qué mesh son los que van a tener movimiento y cuántos frames se ocupan. El primer frame debe ser el número 0. Debe trabajar en modo Pose y ubicarse inicialmente en el primer frame. En el panel Outliner elija todos los huesos (mantenga pulsada la tecla Shift y luego clic en cada uno). Elija Pose > Animation > Bake Action… para crear los canales de la animación. En el cuadro de diálogo que aparece solamente modifique el frame inicial y el final. Luego sólo mover desde el modo Pose los huesos que controlan los mesh desde la vista 3D.

5° Cambie al panel DopeSheet ( ) para crear los keyframes de la animación. En este caso sólo se necesita crear dos keyframes ya que la secuencia en cada frame va cambiando automáticamente (realizado en el paso anterior). Generalmente el primer frame representa el primer movimiento que hace el(los) mesh(s) del modelo, y en el último se representa(n) el(los) mesh(s) del modelo a su estado idle. Posicionarse al inicio de cada frame “clave” y seleccionar Key>Insert Keyframes I y seleccionar LocRotScale.

6° A continuación hay que agregar los marcadores necesarios (pulsando tecla M) y ponerles el nombre adecuado (Ctrl+M para renombrarlos). Cambie a la ventana propiedades y cambie el nombre del Action ( ) que pertenece a la estructura Animation por el nombre skeleton_rootAction.

7° Una vez que se ha revisado que la animación funciona, es momento de crear una plantilla UV de cada mesh para que sirva de base para crear posteriormente su textura en otro programa. Seleccione el mesh y cambie al Modo Edición. En la ventana de edición de Propiedades, cambie a la ventana de edición UV/Image Editor. Visualice el panel de Propiedades (menú View > Properties). Haga clic en el menú Image y elija New Image. En el cuadro de diálogo ingrese el mismo nombre que tiene el mesh, y las dimensiones (es recomendable 1024 y 1024). Deshabilite la casilla de verificación Alpha, ya que no se utiliza en modelos JA Ghoul 2. El tipo generado es Blank. En la imagen cuadrada con fondo negro pueden aparecer las superficies del modelo fuera de lugar y puede ser necesario redimensionar las superficies que aparecen en la ventana de edición UV/Image Editor, utilizando el comando scale (tecla S) y/o mover las superficies que estén encima de otras (importante si la textura no va a ser la misma en todas las superficies), usando tecla C para seleccionarlas y la tecla G para mover la selección.

8° Una vez que queden ubicadas todas las superficies seleccionadas en la ventana de UV/Image Editor, es momento de exportar la plantilla. Haga clic en el menú UVs Export y seleccione UV Layout. Elija la misma ubicación donde están los archivos gly y gla. El nombre que se debería ingresar sería el mismo que tiene el mesh, con la extensión png. Para que se elija esta plantilla como textura, haga clic en la lista desplegable Source y seleccione Single Image. En el cuadro de texto que se muestra debajo de esta lista desplegable haga clic en el botón Open a File Browser y en el cuadro de diálogo elija el archivo png que acaba de generarse en la exportación. Las superficies

ahora deben de aparecer de color blanco. Para concluir este proceso, todavía falta ingresar la propiedad de shader Ghoul 2. Regrese a la ventana de edición de Propiedades y haga clic en el botón Object. Vaya hasta el final del panel Object para llegar a la categoría Ghoul 2 Properties. En el cuadro de texto shader escriba el nombre del archivo png generado en este paso, incluyendo la ubicación (ej. models/map_objects/DBY-827/[nombre_de_archivo].png)

9° El proceso de exportación de un modelo con animación a skeleton/animation (GLA) es el siguiente:

1° En la ventana 3D View, cambiar al Modo Object, y seleccionar la opción de Export (JA Ghoul 2 skeleton/animation (.gla)) del menú File

2° En el cuadro de diálogo de exportación a GLA, ingresar sólo los siguientes campos al exportar a GLA:

gla name (ej. models/map_objects/DBY-827/DBY-827)

3° Seleccionar la opción Export (JA Ghoul 2 model (.glm)) del menú File

4° En el cuadro de diálogo de exportación a GLM, ingresar sólo los siguientes campos al exportar a GLM:

.gla name (ej. models/map_objects/DBY-827/DBY-827)

5° Seleccionar la opción de Export (JA Ghoul 2 model animation markers (.cfg)) del menú File

6° En el cuadro de diálogo de exportación a CFG, ingresar el nombre animation.cfg (la propiedad Offset sólo se usa cuando estamos agregando la secuencia de animación en un archivo animation.cfg que tiene ya otras secuencias.

7° Una vez que se hayan creado los tres archivos, puede usar el programa ModView que viene en el kit de desarrollo público para Jedi Academy para comprobar si el modelo Ghoul 2 se va a poder utilizar en el motor de id Tech 3.

Notas:

En Blender los huesos no deben ser escalados (a menos de que vaya a modificar también la escala de los mesh2), lo cual significa que el valor en la propiedad g2_prop_scale del esqueleto debe ser el que se crea por defecto.

Si en Blender requiere modificar el origen (coordenada central XYZ) del modelo importado 3 , revisar que los mesh del modelo tengan el mismo origen, ya que además no podrá modificar correctamente la escala de todo el modelo en modo edición si algunos mesh tienen orígenes distintos.

2 Para efectos de exportación del modelo a formato ghoul 2 desde Blender, si se desea hacer modificación de escala, sólo tiene efecto en modo edición, a pesar de que Blender lo permite en modo objeto y el punto de vista debe establecerlo en superior antes de escalar, para evitar deformación del mesh o de todo el modelo seleccionado.

3 Para efectos de colocación de una entidad de tipo NPC desde GTKRadiant no hay tanta relevancia de cambio de origen del modelo desde Blender, pero si se utiliza la interfaz de consola del juego, el modelo puede aparecer de forma parcial adentro del terreno. Por esta razón, el origen de un NPC de vehículo está al centro de su altura, y el origen de un NPC de cuadrúpedo está más abajo de dicho centro.

Al abrir el archivo glm en ModView, para evitar "Error Model has x surfaces, but only x of them connected up through the heirarchy, the rest will never be recursed into". Esto se resuelve haciendo que cada mesh del modelo deba tener su propio nombre, y sólo un mesh debe estar al objeto model_root_0 (y los demás mesh deben estar asociados a dicho mesh)

Es importante evitar usar otros comandos en la ventana de edición UV/Image Editor o modificar un primitiva de mesh, y ahí mismo evitar mover sólo algunos vértices de alguna área, ya que al exportar el modelo a glm puede mostrar este error: "Blender could not load surface x (LOD 0) from Blender: UV seam found! split meshes at UV seams"

Proyecto alterno: uso de Blender para crear suelo o modelos sin animación

En este apartado no se tratará de cómo hacer un modelo desde cero (excepto un suelo), sino más bien modificar y procesar un modelo estático (con o sin textura). Después de haber instalado primero el Blender y luego la suite de plugins (Blender Jedi Academy Plugin Suite v.0.2.1 ó v.3.0.0). Se procede a importar un modelo estático, o crear el modelo correspondiente al suelo, que está en formato Blender (el proceso de este tema también aplica a los modelos de objetos sin animación, excepto la explicación de cómo obtener el height map para el suelo)

Para hacer un suelo rápidamente en Blender, lo ideal es proceder a partir de una textura de un terreno existente para hacer un height map. Al terminar de crear el height map con la herramienta de tercero4, se procede con la creación de un mesh plano. Aquí no es necesario comenzar a separar los vértices del mesh para evitar el excedente de 1000 vértices, ya que al principio el mesh sólo tiene cuatro vértices. Para comenzar a modificar el mesh en Blender, primero se carga el heightmap como si fuera una textura5. Después se selecciona el mesh, trabajando en modo objeto, y se utiliza la herramienta Object Modifiers. Se agrega primero el modificador Subdivision Surface. Después se agrega el modificador Displace. En la siguiente ilustración se muestra un ejemplo de propiedades que hay que establecer. Por ejemplo, hacer clic en el botón Simple del modificador, Subdivision Surface, establecer la propiedad Texture en el modificador Displace, es lo principal para que se use el heightmap. Luego se comienza a hacer pruebas cambiando las propiedades de Vista (View:1 por defecto) del modificador Subdivision Surface y la propiedad Fuerza (Strenght:1 por defecto) del modificador Displace. Como el shading de la superficie está en modo “Flat”, la superficie no se ve realista. Para que se vea más realista, hacer clic en Smooth del panel Object Tools. Una vez que termine de configurar el mesh, hacer clic en el botón Apply del modificador Subdivision Surface y luego en el botón Apply del modificador Displace

4 Este es un ejemplo de height map: https://tangrams.github.io/heightmapper/#12.417/36.9918/-110.0903

5 Este es un tutorial para crear una topografía HR: https://www.youtube.com/watch?v=hr75WeIA_nw

También en cada mesh se requiere establecer la siguiente información para aplicar la textura que se verá en el motor del juego. Para hacer esto, puede separar primero el modelo en varios mesh para evitar el excedente de 1000 vértices por mesh (o si el modelo tiene texturas diferentes, separar sus partes al final del proceso), y a continuación trabajar en modo edición, y en la vista 3D seleccionar el mesh correspondiente. En este modo deberá triangular también las caras del mesh, tal como hizo en el tema anterior. Como el modelo no sólo consiste de vértices conectados, también se requiere crear los “UV seams”. Para esto, hacer clic en el botón agregar (+) del marco UV Maps para crear los UV seams de este grupo de vértices. Por último, hay que ubicarse en la categoría de Propiedades del objeto y llenar la información como la ilustración de más adelante.

Para agregar la propiedad en Custom Properties, debe hacer clic en el botón Add. Aparece una propiedad llamada prop la cual deberá modificar su nombre y su valor. Para hacerlo debe hacer clic en el botón edit y mostrará un cuadro de diálogo. En Property Name, escriba el nuevo nombre de propiedad md3shader, y en Property Value el nombre del shader incluyendo su ruta. La propiedad md3shader sirve para indicar la propiedad de textura y su valor es la ruta y nombre físico del archivo de textura el cual es una imagen deseada del mesh. Una vez que termine de establecer las dos propiedades, hacer clic en Ok.

Por defecto, la textura se coloca correctamente y no hay necesidad de utilizar la herramienta UV/Image Editor (sin embargo, en un modelo de objeto que no es el suelo, tendrá que utilizarla para ubicar con precisión la textura, como se especificó en el tema anterior) por lo que ahora sólo queda exportar el mesh o los meshes del suelo. Para hacer esto, realice lo siguiente:

1° En la ventana 3D View, cambiar al Modo Object, y seleccionar la opción de Export (JA MD3 (.md3)) del menú File

2° En el cuadro de diálogo de exportación a MD3, puede ingresar los siguientes campos al exportar a MD3:

Scale, solo si desea cambiar la escala de los objetos seleccionados

3° Ingresar ubicación, el nombre del archivo y hacer clic en el botón Export MD3.

4° Una vez que se haya creado, puede usar el programa MD3View que viene en el kit de desarrollo público para Jedi Academy para comprobar si el modelo se va a poder utilizar en el motor de id Tech 3.

GTKRadiant

Características

GtkRadiant es un software diseñador de niveles desarrollado por id Software y Loki Software, utilizado para crear mapas de una cierta variedad de videojuegos.

GtkRadiant nació como Q3Radiant, la herramienta de diseño de niveles de Quake III Arena, sólo disponible para plataforma Windows. La evolución a GtkRadiant tuvo dos consecuencias: está basado en GTK+, por lo que también existen versiones para Linux y Mac OS, y es independiente del motor de juego, con funcionalidad para otros videojuegos.

Es una aplicación semi-libre. El código fuente está disponible en el repositorio Subversion de id Software y las colaboraciones al código están cubiertas bajo licencias de código abierto. El núcleo original de Q3Radiant, sin embargo, es propietario, bajo licencia de id Software, y su uso comercial en videojuegos sin el permiso de la misma no está permitido. No obstante, debido a la liberación de Quake III Arena bajo licencia GPL, también podría verse afectado este software.

La versión 1.5 incluye el compilador Q3Map2, el cual es un compilador BSP para juegos basado en el motor de Quake III Arena. Compila archivos map (los cuales son editables en el GtkRadiant) hacia archivos bsp, los cuales son comprensibles para el juego y no se pueden editar. Un sitio de distribución de GTKRadiant lo puede encontrar en [48].

Instalación

En este documento se trata un ejemplo de cómo instalar en Windows de 32 y 64 bits. Para instalaciones en otras plataformas, consulte [49]. Cuando haya terminado de descargar el archivo, el programa de instalación que debe ejecutar es GtkRadiant-1.5.0.msi. Si ya instaló el videojuego y mod visto en la sección Software requerido, a continuación realice éstos pasos:

1. En la pantalla de bienvenida haga clic en botón Next:

2. Lea el acuerdo de licencia, y luego haga clic en botón I accept the terms in the Licence Agreement (si no lo estaba) y a continuación en el botón Next:

3. En el cuadro Choose Setup Type seleccione la opción Custom (importante para elegir el juego que hemos instalado):

4. En el cuadro Custom Setup expanda el árbol de GtkRadiant y luego deshabilite el elemento Game support y expanda su árbol como se ve en la figura siguiente (no haga clic en Next

aún):

5. A continuación desplace la barra vertical hasta mostrar el elemento Jedi Academy Support, y habilítelo como se ve en la figura siguiente:

6. Deje la ubicación que aparece por defecto (Location), y haga clic en Next.

7. En el cuadro Ready to install haga clic en el botón Install:

8. Una vez finalizada la instalación aparece la siguiente figura:

Inicialización

Una vez instalado el software con el que se va a trabajar, busque el grupo de programas GtkRadiant 1.5 y ejecute el icono GTKRadiant. Aparecerá el siguiente cuadro de diálogo:

Haga clic en el botón OK. Si está utilizando un sistema operativo Windows de 64 bits, aparecerá este mensaje de error:

En este caso no está encontrando el motor del juego que se ha instalado (carpeta GameData), ya que por defecto GTKRadiant siempre busca en Program Files. Traslade el cursor como se ve en el cuadro de diálogo de la imagen anterior y edite la ruta para que quede así: C:/Program Files (x86)/Star Wars Movie Battles II/GameData/

Haga clic en OK. Si ingresa correctamente la ruta, ya no se le volverá a pedir. A partir de este momento ya se puede trabajar con GTKRadiant. Aparece entonces la ventana principal de la aplicación, y luego comienza la inicialización de OpenGL, y texturas que pertenecen al juego, como se observa en el panel inferior:

Proyecto Hello World - Jedi Crash y Downfall of

A Droid

Proyecto inicial: mapa e inclusión de entidades estáticas y animadas

En lo referente a la interfaz gráfica, en la versión 1.5 de GTKRadiant no hay documentación en español sobre su uso (en inglés se obtiene en el sistema de ayuda). Tiene similitud con su antecesora, que fue la versión 1.4., de la cual si hay tutoriales en español. Para tener una visión de conjunto, elementos básicos de un mapa, texturas, etc. en GTKRadiant 1.4, consulte [50]. Veamos el proyecto Game Jedi Crash de un escenario el cual, “un servidor”, es el que ha desarrollado después de hacer un estudio de mercado:

Lo que estamos viendo en la sección derecha superior (vista 3D) es un pasillo dentro de una nave en fase preliminar para un escenario del mapa, y el final está limitado por una serie de pasillos que conducirían a un hangar. En la barra de título nos indica que está guardado en una carpeta llamada maps, la cual se tiene que generar manualmente dentro de una carpeta creada al instalarse el juego llamada “base”.

Cuando se va a guardar el archivo, se guarda con la extensión .map, que es el formato que reconoce GTKRadiant. En el panel de texturas se puede observar que hay una que está seleccionada. Esto es para indicar cuál es la que se ha aplicado a una cara del poliedro seleccionado en la vista 3D. Como se puede ver en el panel de la parte media inferior, las texturas están organizadas en carpetas, permitiendo recordar además las que se van a necesitar. En este mapa se utilizaron texturas de 512x512 y 1024x1024 en las caras visibles de los poliedros. Otra textura utilizada se llama “Caulk” y sirve para “sellar” caras que no se verán por no ser parte de la escena, y además optimiza el framerate en el juego.

El escenario de éste pasillo no solamente está compuesto de poliedros, sino también de superficies NURB (patches) las cuales se crearon para hacer pipes. Este tipo de formas es más difícil de hacer y se requiere de muchas horas de práctica para dominar su creación. En lo referente a la detección de colisiones con este escenario, GTKRadiant guarda los datos de entrada en el mapa, y luego los procesa Q3Map2 (se tratará más adelante), el cual una de sus tareas es generar la información de descomposición espacial, colocada en un formato de archivo que es el que reconoce el videojuego.

Inclusión de modelos (entidades misc_model, misc_model_static y func_static)

Para realizar modelos, se requiere el uso de otra aplicación y exportarlo al formato que soporta GTKRadiant. En este caso no se abordará el tema de cómo hacerlos, pero sí cómo hacer uso de éstos. GTKRadiant soporta varios formatos, de los cuales ya se mencionó el md3, y los demás son ase (Autodesk 3DSMAX ASCII), obj (Wavefront ASCII), 3ds (Autodesk 3DStudio) y picoterrain (PicoTerrain).

Para conocer cuáles son los que provee el videojuego, se requiere extraerlos de uno de los assets. Para ello se utiliza IZArc que reconoce el formato de archivo PK3 (es como si fuera un archivo zip,

pero contiene por lo general carpetas en la raíz), que es el formato que utiliza el motor del juego. Los modelos estáticos se extraen de assets1.pk3. Al abrirlo aparecen varias carpetas, y la que contiene los modelos se llama models. Se extrae una copia de la carpeta models y se coloca dentro de la carpeta base. A continuación se trata un ejemplo de inclusión de un modelo estático en el escenario.

Hay tres formas de colocar un modelo, pero dos de éstas formas no son adecuadas para modelos que utilizan el efecto glow. La primera se hace de la siguiente manera: primero se hace clic con el botón secundario en la vista 2D en el punto donde se desea colocar, y seleccionará primero el menú misc y luego seleccionar misc_model, cómo en la siguiente ilustración:

En éste caso se va a colocar un modelo que utiliza efecto glow. Aparece el siguiente cuadro de diálogo, mostrando la carpeta de la que se hizo copia:

En éste ejemplo se va a colocar un purificador de aire (airpurifier.md3) y basta con entrar a la carpeta donde está guardado y seleccionarlo, tal como se ve en la siguiente figura:

Después de hacer clic en Open, aparece el modelo en la vista 2D (se está visualizado la vista perpendicular) y en la vista 3D:

Una vez haciendo esto, se puede acceder a las propiedades clave, y para ello se mantiene presionada la tecla Shift y luego se hace clic en alguna de las dos vistas sobre el modelo. Luego se presiona la tecla N para mostrar el cuadro de diálogo Entities:

Las propiedades clave establecidas que se observan por defecto en el tercer cuadro de texto son: classname, con el valor misc_model, la propiedad model, con la ruta relativa models/map_objects/imperial/airpurifier.md3, y la propiedad origin -3176 88 -56, que indica la posición en los ejes de coordenadas XYZ. Hasta aquí termina la primera forma de colocar un modelo estático, sin embargo como es un objeto que utiliza efecto glow, en el videojuego aparecerá sin su textura y sólo se verá la parte que utiliza glow. Ahora se tratará la segunda forma, la cual su procedimiento es similar al caso anterior: primero se hace clic con el botón secundario en la vista

2D en el punto donde se desea colocar, seleccionar primero el menú misc y luego seleccionar misc_model_static, cómo en la siguiente ilustración:

A continuación se muestra un poliedro rojo con una flecha de orientación del modelo, como se ve en la siguiente imagen:

Ésta es una forma correcta de utilizar éste tipo de modelo, sin embargo no se visualizará su aspecto real en tiempo de diseño, y no delimita por sí solo la colisión (se tiene que hacer una caja OBB para cubrirlo). Además sólo podrá verse en tiempo de ejecución (en el videojuego). También se pueden consultar las propiedades de la misma forma como se hizo en el caso anterior. En el cuadro de diálogo las propiedades establecidas por defecto son: classname, con el valor misc_model_static, la propiedad model, con la ruta relativa models/map_objects/imperial/airpurifier.md3, y la propiedad

origin -3192 -72 -48. Explicar otras propiedades clave que se pueden establecer tampoco se abordará en éste documento, pero en el mismo cuadro Entities se puede consultar la descripción de otras propiedades que se pueden establecer (mostrada en el segundo cuadro de texto).

La tercera y la que utiliza menos objetos, se realiza de esta manera: primero seleccionamos la textura que sirve para delimitar la colisión con el purificador de aire. En este caso sería como una caja OBB. Para esto, doble clic en la carpeta system del panel de texturas, y luego buscar y seleccionar la textura physics_clip. Enseguida hay que trazar el poliedro OBB desde la vista 2D. Alternando las vistas 2D, tendrá que modificar las dimensiones del poliedro hasta que se vea como en la siguiente ilustración:

Las dimensiones deberán ser aproximadamente como las del purificador del primer caso, pudiendo tomar como guía, trasladar el poliedro hasta dicho purificador y ajustando las dimensiones, y luego volver a trasladar el poliedro en donde se había colocado originalmente. Después, hay que convertirlo a entidad func_static: seleccionar el poliedro y hacer clic con el botón secundario en la vista 2D, seleccionar primero el menú func y luego seleccionar func_static, cómo en la siguiente ilustración:

Luego se puede ver las propiedades clave por defecto, como se ha hecho antes. En el cuadro de diálogo Entities la propiedad establecida por defecto es classname, con el valor func_static. Las propiedades que hay que establecer manualmente son: la propiedad model2, con la ruta relativa models/map_objects/imperial/airpurifier.md3, y la propiedad origin -2912 0 -56, el cual el valor solamente lo podemos conocer si trasladamos la primera entidad que se colocó (misc_model) dentro del poliedro, tomar nota del origen, y quitarlo de ahí (en este caso se devolverá en su origen original y tener las tres entidades colocadas).

Esta es la otra forma correcta de utilizar éste tipo de modelo en un poliedro que delimita la colisión, y la única desventaja es que el modelo sólo podrá verse en tiempo de ejecución.

Inclusión de modelos animados (entidades NPC_spawner)

El mod Movie Battles trae consigo varios modelos para hacer NPCs, y para el jugador, que están en el mismo formato que en la implementación original del juego. Los modelos están en formato Ghoul2, extensión .glm (malla) y las texturas vienen separadas del archivo. En otro proyecto, Game Dowfall of A Droid, se van a incluir modelos del mod Movie Battles II (por ejemplo R2-D2 y Anakin Skywalker), y un modelo externo que no viene en el mod, es necesario descargarlo del sitio web filefront, en este caso, la padawan Ahsoka [51]. El otro que se requiere descargar es el sable de luz que utiliza, ya que tampoco está incluido con el modelo de Ahsoka [52]. Una vez que se han descargado, hay que descomprimir el zip y colocar sus pk3 en la carpeta base. Al abrir el pk3 del modelo con IZArc, hay que entrar a la carpeta models, luego entramos a players y luego aparece el nombre de la carpeta del modelo, cuyo nombre es incorrecto (aparece Ashoka, en vez de Ahsoka). Como no está bien escrito, renombramos la carpeta por Ahsoka, y salimos del pk3.

Una vez que se ha realizado lo que se pide en el párrafo anterior, se procede con el ejemplo de la inclusión y configuración de Ahsoka. En el proyecto Game Downfall of A Droid se incluirán más NPC en el mapa por ser de Movie Battles II (R2-D2mb, y dos IG-88), pero en este tema se tratará como incluirlos. Para ello, volveremos a trabajar con GTKRadiant 1.5. En el proyecto Game Downfall of A Droid también realizaremos una programación de script para asignarles atributos de NPC a Ahsoka y R2-D2, y puedan ser controlados por un jugador (ej. Anakin Skywalker) en el mod Movie Battles. El control será implementando los estados predeterminados (como el estado idle) y activación para que sigan al jugador.

Una vez que abrimos el mapa que vimos anteriormente, procedemos a colocar las entidades NPC_spawner, aunque en la versión final del proyecto no mantendrán esa ubicación, ya que éste ejercicio es sólo para ilustrar el proceso. En el pasillo, cerca de la puerta colocaremos a Ahsoka: primero se hace clic con el botón secundario en la vista 2D en el punto donde se desea colocar, seleccionar el menú contextual NPC y luego seleccionar NPC_spawner, cómo en la siguiente ilustración:

Lo que sigue a continuación es configurar este poliedro rojo que aparece. Mantenemos pulsada la tecla Shift y hacemos clic con el botón izquierdo sobre el poliedro. Luego presionamos la tecla N para visualizar el cuadro de diálogo Entities. Estableceremos varias propiedades clave, como las que se están visualizando en el tercer cuadro de texto de la siguiente ilustración:

En los cuadros de texto Key y Value establecemos varias propiedades clave, además de las que aparecen por defecto (aparecen ya establecidas las propiedades clave classname y origin): Key Value

Seguimos el mismo proceso anterior para incluir a R2-D2 en el escenario en otra ubicación. Los valores que se deben agregar a éste modelo son los siguientes:

Finalmente seguimos el mismo proceso de Ahsoka pero ahora para incluir a dos IG88 en el escenario en diferentes ubicaciones. Los valores que se deben agregar a estos dos enemigos son los siguientes:

Key Value

NPC_type (Enter)

teamowner (Enter)

ig88 (Enter)

2 (Enter)

Hasta aquí aún no se han codificado los script que se requieren para implementar todos los NPC y control sobre Ahsoka y R2-D2. Como se dijo anteriormente, si desea consultar el significado que tienen estos valores en las propiedades clave, se acude a la descripción de propiedades, mostrada en el mismo cuadro de diálogo Entities.

Proyecto inicial: inclusión de entidades de iluminación y posición del jugador

Ahora es el momento de incluir la iluminación, que es colocar las entidades de iluminación, que servirán para crear los lightmaps en la fase de compilación. En este caso la iluminación ambiental no se va a utilizar, ya que vamos a aplicar radiosidad de luces (entidades de iluminación). Nuevamente en el mapa, colocaremos las entidades en el mismo pasillo visto antes. Para hacer esto, se hace clic con el botón secundario en la vista 2D en el punto donde se desea colocar, y luego seleccionar light, cómo en la siguiente ilustración:

Aparecerá un diamante en el escenario, que corresponde a una entidad de iluminación y el cuadro de diálogo Light intensity. Si pulsamos ESC le asigna el valor por defecto, el cual es 300. El valor que se le puso es 160. Se puede acceder también a sus propiedades clave, y para ello se mantiene presionada la tecla Shift y luego se hace clic en alguna de las dos vistas sobre el modelo. Luego se presiona la tecla N para mostrar el cuadro de diálogo Entities:

La propiedad clave que hemos establecido es light. Las propiedades clave establecidas que se observan por defecto en el tercer cuadro de texto son: classname, con el valor light, y la propiedad origin -3176 88 -56, que indica la posición en los ejes de coordenadas XYZ. Hay propiedades que, aun sin aparecer en el tercer cuadro de texto, son establecidas por defecto. Hay otras propiedades que se pueden establecer y se describen en el segundo cuadro de texto de éste cuadro de diálogo. Un resultado de colocar éstas entidades sería como éste:

Cabe aclarar que si no establecemos la propiedad clave color, el color de la luz es blanco. Si se ingresa el color, éste debe estar especificado en RGB. También aclarando, se han colocado entidades light en el otro cuarto (donde aparecen los purificadores de aire). En la fase de compilación (más adelante) se aplicaría el antialiasing inteligente de los bordes de la sombra en los lightmaps.

Inclusión de posición del jugador (entidad info_player_siegeteam1)

En lo que respecta al desarrollo en GTKRadiant, casi está listo lo mínimo que debería incluirse para probar el mapa en el MBII. Para colocar la entidad de posición del jugador, realizamos lo siguiente: primero se hace clic con el botón secundario en la vista 2D en el punto donde se desea colocar, seleccionar el menú contextual info y luego seleccionar info_player_siegeteam1, cómo en la siguiente ilustración:

Aparecerá un poliedro rojo muy parecido al del NPC_spawner, con la misma orientación. Si queremos que el jugador vea hacia el origen de la entidad NPC_spawner, sólo tenemos que establecer una propiedad clave. Nuevamente se mantiene presionada la tecla Shift y luego se hace clic en alguna de las dos vistas sobre el modelo. Luego se presiona la tecla N para mostrar el cuadro de diálogo Entities:

En el cuadro de texto Key ingresamos la propiedad clave angle, y el valor (cuadro de texto Value) sería 180. Este valor es en grados, y también aparece en el cuadro de texto Yaw Angle, en el cual también podría haberse ingresado sin teclear tanto.

Proyecto Scene

Continuamos con el mismo proyecto del que hemos tratado en el proyecto anterior. Para cargar el mapa y navegar en el mismo, todavía nos falta realizar cuatro fases: fase bsp (partición de escenarios), fase de visibilidad entre celdas, fase de iluminación, y fase de configuración del juego. Para hacer las tres primeras fases, se utiliza el programa Q3Map2, el cual lo veremos a continuación.

Q3Map2

Características

Q3Map2 es un compilador BSP para juegos basados en el motor de Quake III Arena. Compila archivos de mapas (.map), que son editables con un editor, hacia archivos .bsp, que sean comprensibles para el juego y no se puede editar. Actualmente soporta las siguientes plataformas:

• Nexuiz

• Open Arena

• Quake 3 Arena / Team Arena

• Return to Castle Wolfenstien

• Soldier of Fortune II

• Star Trek Elite Force

• Star Wars Movie Battles II

• Tenebrae (Proyecto de Modificación de motor Quake1)

• Tremulus

• Urban Terror

• War§ow

• Wolfenstein: Enemy Territory

• World of Padman

Nota: El apoyo futuro para Call of Duty es una posibilidad.

Q3Map2 fue diseñado para reemplazar el Q3Map.exe que viene con Tempest QERadiant, GtkRadiant y GMAX. Sin embargo, hay mejoras significativas que requieren un poco de testeo para utilizarlas, tales como iluminación y la producción más rápida de superficie mejorada.

Datos curiosos:

 Q3Map2 comenzó como una corrección de errores para Q3Map, el compilador original de mapa Quake 3.

 El ciclista, participante de SIDA LifeCycle, maravilla de codificación de superhéroe, ydnar es el hombre detrás de Q3Map2.

Proyecto: compilación del mapa

En el proyecto inicial terminamos de incluir lo mínimo que puede tener un mapa. Q3Map2 se puede utilizar en la línea de comandos (símbolo del sistema) o en GTKRadiant. En este proyecto se utilizó en la línea de comandos ejecutando un procesamiento por lote, utilizando algunos switches para realizar la fase bsp, fase de visibilidad y la de iluminación. Para ver detalles sobre el uso de los diferentes switches, consulte [53].

En la fase bsp, se debe utilizar Q3Map2 para: creación de superficies meta de las caras de los poliedros, ingresar los shaders, cargar el mapa en memoria, determinar los datos de descomposición espacial, generar los datos para hacer portal culling (archivo .prt), efectuar corrección de Tjunctions, fusionar triángulos, eliminar superficies malformadas, generar un archivo de superficies (.srf) y el archivo incial .bsp, el cual se modificará en las siguientes fases. Para que Q3Map2 haga esta fase en el mapa que se ha tratado en las secciones anteriores, hay que ingresar la siguiente línea de comando (incluido en el archivo doad.bat – abreviatura de Downfall Of A Droid):

"C:/Program Files/GtkRadiant 1.5.0/q3map2.exe" -v -game ja -fs_basepath "C:/Program Files/Star Wars Movie Battles II/GameData/" -meta " C:/Program Files/Star Wars Movie Battles II/GameData/base/maps/mb2_doad.map"

En esta línea, el switch ja es el video juego original (Jedi Academy), y mb2_doad.map es el nombre del mapa creado en GTKRadiant. Cabe aclarar que no son tres líneas separadas en tres renglones. Debe ser una sola línea (un renglón). Cuando se ejecuta, se muestra todo lo que va haciendo Q3Map2, y al finalizar nos devuelve el control del símbolo del sistema.

En la fase de visibilidad se crean conjuntos de visibilidad basados en el archivo de portal que se creó anteriormente (.prt). Si queremos evitar la eliminación de éste archivo cuando termine ésta fase, debemos agregar el switch saveprt en la siguiente línea de comandos (incluido en el archivo doad.bat) para ésta fase:

"C:/Program Files/GtkRadiant 1.5.0/q3map2.exe" -game ja -fs_basepath "C:/Program Files/Star Wars Movie Battles II/GameData/" -vis -saveprt "C:/Program Files/Star Wars Movie Battles II /GameData/base/maps/mb2_doad.map"

Cuando se ejecuta, también Q3Map2 muestra lo que va haciendo, y al finalizar ésta fase de visibilidad nos devuelve el control del símbolo del sistema.

Por último se lleva a cabo la fase de iluminación, utilizando varios switches. En esta fase se debe utilizar el switch light para efectuar la fase, si no, se iluminará todo por igual como si se aplicara luz ambiental. El switch samples habilita antialiasing inteligente de los bordes de la sombra en lightmaps. Un valor de 2 a la vez se ve bien y compila rápidamente, mientras que un valor de 3 se ve muy bien, sino que recoge un poco más despacio. El switch fast permite luces envueltas en las

luces de área (sombreado), e incluye radiosidad. Da lugar en una compilación más veloz, pero oscurece considerablemente todas las fuentes de luz envueltas–esto puede compensarse fácilmente levantando sus valores surfacelight. La línea de comando, incluida también en doad.bat, quedaría de la siguiente forma:

"C:/Program Files/GtkRadiant 1.5.0/q3map2.exe" -v -game Ja -fs_basepath " C:/Program Files/Star Wars Movie Battles II/GameData/" -light -samples 2 -fast " C:/Program Files/Star Wars Movie Battles II/GameData/base/maps/mb2_doad.map"

El archivo que se crearía al terminar las tres fases es el que reconoce el juego y se le puede considerar un archivo binario, ya que no es texto plano. En este caso se llama mb2_doad.bsp, y este posteriormente debe colocarse en una carpeta dentro de un pk3 (ver tema Empaquetado e instalación del add-on)

Proyecto Game “Downfall Of A Droid”

Continuamos con el mismo proyecto del que hemos tratado en los proyectos Hello World y Scene. Después de haber navegado y observado si todos los elementos están como deben visualizarse, ya se puede hacer algo con éstos. Aquí es donde iniciamos con la cuarta y última fase del proyecto. En este documento sólo se va a explicar cómo hacer la programación de script para asignarles atributos de NPC a Ahsoka y R2-D2, y puedan ser controlados por un jugador (ej. Anakin Skywalker) en el mod Movie Battles. El control será implementando los estados predeterminados (como el estado idle) y activación para que sigan al jugador. También se aprovechará para tratar la programación del enemigo (IG-88). Antes de ver esto, se presenta la descripción e instalación del kit de desarrollo público para Jedi Academy, y la descripción del mod Movie Battles.

Kit de desarrollo público para Jedi Academy (Jedi Academy SDK)

Raven Software liberó el SDK y herramientas públicas para Star Wars Jedi Knight: Jedi Academy, ampliando el apoyo de modificación para su juego de acción 3D de ciencia ficción. La distribución incluye un editor/visor de sombreado, visualizador de modelos, editor y compilador de secuencia de comandos en formato Icarus, código fuente público, y documentación. Un sitio de distribución de este kit lo puede encontrar en [54].

Instalación

Cuando haya terminado de descargar el archivo, el programa de instalación que debe ejecutar es Jedi_Academy_SDK_MP.exe. Se ejecuta WinZip Self-Extractor. La ruta de instalación a utilizar sería la siguiente: C:\Program Files\JEDI_Academy_SDK. Una vez que se ha descomprimido todo lo necesario, ya puede uno realizar la programación de NPC y relacionarlos al mapa mb2_doad.bsp para el mod Movie Battles. Veremos antes de que se trata este mod.

Movie Battles II

Descripción

Movie Battles II o MBII es un equipo basado en el mod multijugador Last Man Standing del juego shooter Star Wars Jedi Knight: Jedi Academy inspirado en el popular shooter en primera persona Counter-Strike. [55] El propósito principal del mod es permitir a los jugadores experimentar escenas setpiece de batalla directamente de las seis películas de Star Wars, sumergiéndolos directamente en las partes de las dos trilogías Star Wars. [56] Esto significa que la mayoría de los aspectos originales del juego han cambiado y sólo unas pocos características originales de juego permanecen. El juego enfrenta a un equipo de Imperio Galáctico / Fuerzas Separatistas en contra de las fuerzas Alianza Rebelde / República Galáctica, cualquiera de los cuales intenta completar un objetivo, o para eliminar todos los miembros del equipo enemigo.

Jugabilidad

Ambos equipos suelen tener objetivos que pueden ser completados para ganar la ronda. El jugador también tiene un número de puntos que se puede gastar en mejoras para su personaje. [ 57] Todos los jugadores que mueren antes del final del round se convierten en espectadores. Pueden seguir ciertos jugadores que aún están vivos o de libre vagancia en la cámara del espectador, de forma similar a otros shooters en primera persona, como Battlefield 2. [58]

El combate de sable láser en Movie Battles se cambió del sistema original sustancialmente. Los movimientos de bloqueo y defensivos son favorecidos por el juego "swing-spam" del juego sin modificar. Hay metros de fondo de fuerzas de ambos bloques y la resistencia que agotan como el jugador intercepta los ataques entrantes de bláster y de sable láser. [59] Al igual que en CounterStrike, Movie Battles utiliza un sistema objetivo, donde un equipo defiende y el otro ataca a uno o más objetivos. Tipo de medida objetiva suelen ser variantes en temas comunes, [ 57], como "paneles deslizantes", o vigilancia NPC. Mediante el uso de este sistema, es significativamente diferente de la mayoría de juegos Star Wars, donde el objetivo es a menudo simplemente para matar a cada uno en el otro equipo.

MBII tiene varios tipos de juego. Las versiones más recientes también incluyen el modo de duelo. Ciertos mapas han sido creados para permitir un duelo que librar, una batalla entre dos bandos que representan una escena de una película o un juego. A menudo, estas luchas son uno contra uno, pero a veces el número de jugadores es diferente en cada lado. [60]

Los jugadores en MBII eligen una clase de luchador, similar a juegos como Battlefield 2 con roles definidos. El lado Rebelde o República (dependiente del mapa) tienen acceso a una serie de clases específicas, entre ellas soldados clones con rifles repetidores bláster y Wookiees con bowcasters, así como Jedi. El lado Imperial o Separatista (dependiente del mapa) tienen acceso a una serie de clases específicas, así: droidekas , super droides de batalla, mandalorianos armados de jet pack y lanzallamas, así como Sith. Ambos equipos tienen acceso a las dos clases genéricas (soldados y comandantes).

Proyecto: programación de los NPC (asignar atributos y control)

Después de instalar el kit de desarrollo público, hay que abrir un archivo llamado NPC_read_me.txt (C:\Program Files\JEDI_Academy_SDK\Tools\docs) De ahí se tomó la referencia necesaria para hacer la programación de NPC con los modelos de Ahsoka, IG-88 y R2-D2. Ese archivo explica cada uno de los campos y cuáles son los valores que tiene por defecto por cada NPC a crear. Sólo es necesario poner en un archivo en formato .npc los campos que van a tener otro valor. Por ejemplo, al NPC de Ahsoka (ahsoka.npc) se le ha realizado la siguiente programación de script, tomando como referencia dicho NPC_read_me.txt:

ahsoka

120

scale 70

playerTeam TEAM_ENEMY

enemyTeam TEAM_PLAYER class CLASS_ARMED_VIP

sex female snd Ahsoka

sndcombat Ahsoka

sndjedi Ahsoka

yawSpeed 60

walkSpeed 45

runSpeed 180

health 600

dismemberProbHead 0 dismemberProbArms 0

dismemberProbLegs 0 dismemberProbHands 0 dismemberProbWaist 0 }

En este script, aparece primero el nombre del npc, el cual debe corresponder con el valor que se puso en la propiedad clave NPC_type de la entidad NPC_spawer Ahsoka (consulte el tema Inclusión de modelos animados del proyecto Hello World). Luego entre llaves, siguen los campos que son los de la primera columna, y sus valores son de tipo numérico (o identificadores como se nombran en lenguaje C) son los de la segunda columna. Durante el mod del juego, para que un modelo de jugador haga que un NPC entre en estado idle o en estado “seguir al jugador”, se debe poner el identificador CLASS_ARMED_VIP a continuación del campo class (vea el script de arriba). Este nuevo identificador de clase solamente es reconocido por el mod Movie Battles, no por el juego original Jedi Academy. El juego original no soporta esa nueva clase. Se preguntará de

dónde se obtuvo esta información. Como ya se dijo antes, un pk3 se puede abrir, y en este caso se usó el mismo programa IZArc. Se investigaba abriendo los archivos npc ubicados dentro la carpeta npc ubicada a su vez dentro de otra llamada Ext_data, por cada pk3 del Movie Battles, se descubrió que sólo había tres configuraciones de NPC diferentes. El NPC que permite alternar de estado idle al del seguir al jugador es Zam Wesell (el script está dentro del ext_data del mb2_Coruscant_chase.pk3). Volviendo a la programación, el script de IG88 (IG88.npc) quedó así:

IG88

0

dismemberProbWaist 0 }

El script de IG88 es un ejemplo tradicional de script, y se debe a que el valor que tiene el campo class es soportado tanto para JK3 como para el mod. La programación de R2-D2 para Movie Battles es también un caso muy especial de NPC (r2d2mb.npc) y es similar al de Zam Wesell, ya que también puede ordenarse a que se detenga o siga al jugador:

r2d2mb

Hasta aquí se describe algo de programación de script. La descripción de los demás script se incluye en el código fuente de los mismos, los cuales quedan dentro del comprimido mb2_doad.pk3 para que se pueda agregar al mod y jugar. Tales script son: script del tipo de juego Siege (mb2_doad.siege); scripts de clases de jugadores (TCW_Anakin.mbch y TCW_IG-86.mbch); scripts de configuración de equipos (Doad_centinels.mbtc y Doad_jedi.mbtc); y scripts para aplicar los shader en determinadas texturas.

Hay otros script que se pueden hacer, pero se requiere el uso de otro lenguaje (icarus) utilizando el kit de desarrollo de software para Jedi Academy, para efectuar por ejemplo, la traslación de los poliedros, narraciones de los NPC (sólo para single player), etc. Los tutoriales que se consultaron para saber cómo codificar los script que vienen en el pk3 realizado, se pueden encontrar en [ 61] [62]

Proyecto: empaquetado e instalación del add-on

Una vez que ha terminado realizar la compilación (las tres fases) ejecutando doad.bat y la configuración del juego (cuarta fase), estamos listos para empaquetar todo lo realizado en formato PK3 mediante el programa IZArc. Lo que se tiene que hacer es haber hecho una copia de cualquier mapa (por ejemplo mb2_coruscant_chase) y renombrar la copia (para nuestro mapa, sería mb2_doad.pk3). Una vez hecho esto, iniciar IZARC y abrir mb2_doad, y a continuación incluir las carpetas necesarias para que funcione este add-on. La organización de las carpetas es la siguiente (con lo mínimo que debe tener):

En la carpeta character debe contener TCW_Anakin.mbch y TCW_IG86.mbch.

En la carpeta teamconfig debe contener Doad_centinelas.mbtch y Doad_jedi.mbtc.

En la carpeta npcs debe contener ahsoka.npc, IG-88.npc y r2d2mb.npc

En la carpeta logos se colocan los logos de los equipos, y en este caso sólo si no está originalmente en el juego (en este caso es mb_Zann.tga)

En la carpeta doad (dentro de carpeta siegeicons) deben estar los archivos que se usan en el radar: droid.tga y ext2.tga.

En la carpeta doad (dentro de carpeta mplevels) deben estar los archivos que se usan para describir la “misión”: impobjetive1.jpg, impobjetive2.jpg, map.jpg, rebobjetive1.jpg y rebobjetive2.jpg.

En la carpeta maps debe contener mb2_doad.bsp y mb2_doad.siege.

En la carpeta music debe contener doad.mp3.

En la carpeta scripts debe contener mb2_doad.arena. En la carpeta doad (dentro de carpeta scripts) debe contener r2d2_use.IBI. Finalmente hay que incluir las texturas que no vienen originalmente en el juego, que es en este caso iftstbgrate.png y debe colocarse en la carpeta republic. Finalmente para que ya quede instalado, debe mover el comprimido pk3 a la carpeta MBII.

Proyecto: carga del mapa en modo consola y navegación en escenarios

Una vez que ha terminado de empaquetar e instalar el add-on (archivo pk3) en el lugar correcto, estamos listos para cargar el mapa desde el juego. En esta sección se trata de ver cómo ha quedado el escenario y la situación de las entidades, iluminación, y texturas, para lo cual realice lo siguiente:

1. En Windows, localice el grupo de programa Star Wars Movie Battles II 0.1.7,

2. Inicie el acceso directo Star Wars® Movie Battles.

Nota: si aparece un cuadro de diálogo preguntando si desea actualizar el juego, elija QUIT y vuelva a arrancar el juego.

3. Cuando se encuentre en el menú principal del juego hay que crear un servidor primero así: PLAY > CREATE > ADVANCED > Dedicated Server: LAN > DONE y finalmente elegir BEGIN. Cuando aparezca el siguiente cuadro, escriba map mb2_doad en el cuadro de texto blanco como se ilustra:

De esta forma ya se carga previamente el mapa. Una vez creado el servidor y cargado el mapa en la consola del servidor, hay que iniciar otra instancia del juego en la misma PC (realizando sólo los pasos anteriores 1 y 2). Cuando se encuentre en el menú principal del juego, hay que utilizar el modo consola para iniciar rápido la sesión con el servidor:

4. Para desplegar la consola, presione Shift+| (barra horizontal). En este caso es para un teclado latinoamericano. Se mostrará una imagen similar a la siguiente:

5. Para iniciar sesión con el servidor que hicimos, hay que escribir connect localhost:29070 (Enter) en la consola, como en esta ilustración:

6. Luego de cargar el mapa, elegimos como nuestro modelo de jugador “Anakin”: clic en el icono Jedi > clic en el icono de Anakin > clic en OKAY.

7. El jugador aparece en primera persona en la posición donde se colocó la entidad info_player_siegeteam1, en el pasillo. Ahí veremos también cerca a Ahsoka, la cual sólo reacciona si es atacada. También podemos notar la aplicación de la iluminación por medio de las entidades light. Para que aparezca el jugador en tercera persona, presione la tecla P:

8. Para poder ver las demás entidades, se necesita pasar al otro cuarto que está pasando la “puerta” donde está ubicada Ahsoka. Como no se ha programado la funcionalidad de la puerta, se dejaron abiertas para que el jugador pueda pasar al otro cuarto.

9. Utilice la tecla de dirección (UP) y dirija al jugador hacia la puerta y atraviésela. Al llegar presione la tecla 1 para utilizar el sable de luz, y luego mantenga presionada la tecla ALT para defender al jugador mientras avance con la tecla UP.

10. Verá un pasillo oscuro y hasta al final se ve iluminación. Avance hasta llegar casi al final del cuarto, esquive al enemigo con las teclas A (izquierda) o D (derecha) y colóquese detrás del primer purificador de aire y gire 180° presionando la tecla LEFT o RIGHT. Si trata de atravesarlo como se ve en la siguiente ilustración, no lo conseguirá, ya que la caja OBB está ahí para que exista colisión con el purificador de aire. Esto significa que ha utilizado la mejor técnica de colocación de un modelo que usa efecto glow.

11. Gire con las teclas de dirección LEFT o RIGHT (hasta ver los otros purificadores de aire). Veremos que el purificador de la derecha no se renderiza como debiera (este problema no tiene nada que ver con las entidades de luz que se colocaron). Si queremos ver qué pasa con el purificador de la izquierda, el jugador estará atravesando el modelo:

12. Aquí la alternativa sería que si queremos que haya colisión con éste modelo, sería envolverlo con una caja OBB (textura physics_clip) como se hizo en el purificador de aire del centro, o emplear varios poliedros con la textura physics_clip y modificar los vértices para ajustarlos a las dimensiones precisas del modelo, en GTKRadiant.

13. Para salir del juego, abra la consola como se hizo en el paso 4, y teclee QUIT (Enter) en la consola.

14. Cierre la ventana del servidor.

Consideraciones:

Los poliedros no deberían superponerse (puede haberse copiado incluso un poliedro y colocado su copia en la misma posición del original), ya que algunas veces ocurren problemas de visualización, y no se rende-rizan todas las caras que tienen textura. Cuando no sea necesario mostrar algunas caras del poliedro, es mejor utilizar la textura caulk, de lo contrario puede ocurrir el problema de visualización mencionado. Muchas veces puede seguirse presentando este problema cada vez que se agregan más poliedros. Si no funciona todas las demás soluciones, no queda más que utilizar (siempre como último recurso) la función Make detail. Si este último recurso no funcionara, todavía hay otra alternativa, el cual consiste en “tapar” la zona afectada mediante otro poliedro con la textura hint. El problema es que esta textura bloquea la iluminación en el área afectada. En la compilación final con sun/sky lights, pueden aparecer problemas de visualización y las texturas pueden no aparecer. Esto se debe a que existen dos shaderlist.txt en algún pk3 de terceros, o hay dos archivos .shader idénticos cada uno en su pk3. Para resolver esto siempre hay que dejar en la carpeta base SOLO lo que se tiene que compilar (deben estar antes ya guardadas las texturas y archivos shader dentro de nuestro pk3)

Bibliografía

1. Jaquays, P., & Hook, B. (s.f.). "Quake III Arena Shader Manual". Obtenido de http://www.qeradiant.com/manual/Q3AShader_Manual/ch05/pg5_1.htm

2. Jaquays, P., & Hook, B. (s.f.). "Quake III Arena Shader Manual". Ontenido de http://www.qeradiant.com/manual/Q3AShader_Manual/ch01/pg1_1.htm

3. Eberly, D. (2002). "función rápida de raíz cuadrada inversa". Obtenido de http://www.geometrictools.com/Documentation/FastInverseSqrt.pdf

4. Sommefeldt, R. (29 de noviembre de 2006). "El origen de la función InvSqrt rápida de Quake3". Obtenido de http://www.beyond3d.com/content/articles/8/

5. Ferguson, T. (2001). "Id Software. Formato de archivo Vídeo RoQ". Obtenido de http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt

6. ioquake3 md4-readme.txt. (s.f.). Obtenido de http://svn.icculus.org/quake3/trunk/md4-readme.txt?view=markup

7. Gongo. (s.f.). "md4 - especificación de archivo v4". Obtenido de http://gongo.quakedev.com/md4.html

8. "El sonido en el hilo principal". (s.f.). Obtenido de http://software.intel.com/en-us/articles/open-source-game-development/

9. "Libro de Hook: El Modelo de Redes Quake3". (s.f.). Obtenido de http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

10. "ioquake3 - página de ayuda". (s.f.). Obtenido de http://ioquake3.org/?page=help

11. "Guía Completa: Configurar y Personalizar ioquake3 en Linux". (s.f.). Obtenido de http://www.linuxtoday.com/news_story.php3?ltsn=2009-08-08-007-35-OS-GM

12. "Quake 3 portado para el iPod Touch con controles de inclinación". (s.f.). Obtenido de http://www.betanews.com/article/Quake-3-ported-to-iPod-Touch-with-tilt-controls/ 1208202321

13. "ioquake3 for OS X - Inside Mac Games" (s.f.). Obtenido de http://www.insidemacgames.com/news/story.php?ArticleID=14009

14. "ioquake3 for Mac OS X available for download - Macsimum News" (s.f.). Obtenido de http://www.macsimumnews.com/index.php/archive/ioquake3_for_mac_os_x_available_for_download

15. "IOQuake3 OSX : Clone de Quake III (gratuito) - MaxiApple.com" (s.f.). Obtenido de http://www.maxiapple.com/2009/05/ioquake3-osx-clone-de-quake-iii-gratuit.html

16. "IOQuake3 1.34 - Jogue Quake 3 no Mac OS X - Maclivre.net". (s.f.). Obtenido de 2010, de http://www.maclivre.net/2009/03/18/ioquake3-134-jogue-quake-3-no-mac-os-x/

17. "Open Arena about page" (s.f.). Obtenido de http://openarena.ws/about.html

18. "XP Games". (s.f.). Obtenido de http://home.comcast.net/~SupportCD/XPGames.html

19. "Tremulous about page". (s.f.). Obtenido de http://tremulous.net/about/

20. "Quake, Meet GPL; GPL, Meet Quake - Linux Journal". (s.f.). Obtenido de http://www.linuxjournal.com/article/9867

21. "Entretien avec l'équipe de Smokin'Guns - JeuxLinux" (s.f.). Obtenido de http://www.jeuxlinux.fr/a269-Entretien_avec_lequipe_de_SmokinGuns.html

22. "Urban Terror manual". (s.f.). Obtenido de http://www.urbanterror.net/new_urt_manual/#Do_I_need_Quake_III_Arena_to_play.3F

23. "Two free games based on the Quake 3 engine tip up - The Inquirer" (s.f.). Obtenido de http://www.theinquirer.net/inquirer/news/1040566/two-free-games-quake-engine-tip

24. "A Look At Free Quake3 Engine Based Games - Slashdot" (s.f.). Obtenido de http://games.slashdot.org/article.pl?sid=07/04/06/1638232

25. "Fedora 12 Update: quake3-1.36-5.fc12 - fedora-package-announce" (s.f.). Obtenido de http://www.mail-archive.com/fedora-package-announce@redhat.com/msg32752.html

26. "ioquake3-1.36-1mdv2010.0 RPM for i586 - RPM Find" (s.f.). Obtenido de http://rpmfind.net//linux/RPM/mandriva/2010.0/i586/media/contrib/release/ioquake3-1.361mdv2010.0.i586.html

27. "Package: openarena-data (0.8.1-2) - Debian". (s.f.). Obtenido de http://packages.debian.org/sid/openarena-data

28. "ioquake3 1.36 build 3 - FreshPorts". (s.f.). Obtenido de http://www.freshports.org/games/ioquake3/

29. "igames/ioquake3 - The NetBSD Packages Collection" (s.f.). Obtenido de http://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/games/ioquake3/README.html

30. "Q3osc research paper". (s.f.). Obtenido de https://ccrma.stanford.edu/~rob/papers/hamilton-ICMC2008-q3osc.pdf

31. "Q3osc wiki". (s.f.). Obtenido de https://ccrma.stanford.edu/wiki/Q3osc

32. "A Survey of Collaborative Virtual Environment Technologies". (s.f.). Obtenido de http://www.cse.nd.edu/Reports/2008/TR-2008-11.pdf

33. "L3DGEWorld 2.1 Input & Output Specifications". (s.f.). Obtenido de http://caia.swin.edu.au/reports/070808A/CAIA-TR-070808A.pdf

34. "L3DGEWorld 2.3". (s.f.). Obtenido de http://caia.swin.edu.au/urp/l3dge/tools/l3dgeworld/index.html

35. "VMM-Independent Graphics Acceleration". (s.f.). Obtenido de http://www.vmware.com/files/pdf/vee.pdf

36. "VMM article in ACM ISBN 978-1-59593-630-1 Pages: 33 - 43" (s.f.). Obtenido de http://portal.acm.org/citation.cfm?id=1254816

37. "Real-time Ray Tracing of Dynamic Scenes" (s.f.). Obtenido de http://llvm.org/pubs/2008-06-Reiter-Thesis.html

38. "Run-Time Code Generation for Materials" (s.f.). Obtenido de http://llvm.org/pubs/2008-08-RTCodegen.html

39. LLVM Users, Open Source Projects" (s.f.). Obtenido de http://llvm.org/Users.html

40. "ioquake3 Miscellany - LinuxGames". (s.f.). Obtenido de http://www.linuxgames.com/archives/10379

41. (s.f.). Obtenido de ftp://ftp.idsoftware.com/idstuff/source/

42. Larabel, M. (3 de junio de 2010). "id Software Open-Sources ET, RTCW" Obtenido de http://www.phoronix.com/scan.php?page=news_item&px=ODUwNA

43. Valich, T. (s.f.). "Two free games based on the Quake 3 engine tip up" Obtenido de http://www.theinquirer.net/inquirer/news/1040566/two-free-games-quake-engine-tip

44. Bougard, G. (., & Bougard, G. (29 de enero de 2009). "Smokin'Guns ioQuake3 backport". Obtenido de http://forum.smokin-guns.org/viewtopic.php?t=1518

45.

Star Wars: Jedi Knight: Jedi Academy - Wookiepedia, the Star Wars Wiki (s.f.). Recuperado el 19 de enero de 2013, de http://starwars.wikia.com/wiki/Star_Wars:_Jedi_Knight:_Jedi_Academy

46. LucasArts | Star Wars Jedi Knight: Jedi Academy (s.f.). Recuperado el 18 de enero de 2013, de http://www.lucasarts.com/support/update/jediacademy.html

47. Recent News - MovieBattles II - A Total Conversion for Jedi Academy (s.f.). Recuperado el 18 de enero de 2013, de http://www.moviebattles.com/news#newstitle1

48.

"GTKRadiant 1.5.0 download". (s.f.). Recuperado el 18 de enero de 2013, de http://www.desura.com/company/ioquake/downloads/gtkradiant-150

49.

gtkradiant_install [Neverwiki]. (s.f.). Recuperado el 18 de enero de 2013, de http://wiki.nevercorner.net/doku.php?id=gtkradiant_install

50.

J&B. (s.f.). GTK Radiant Tutoriales en Español. Recuperado el 21 de enero de 2013, de http://gtkradiant.260mb.com/

51.

Hirman's Ahsoka Tano 2.0. (s.f.). Obtenido de http://jediknight3.filefront.com/file/Ahsoka_Tano;112139

52.

Ahsoja Tano's lightsaber hilt v.2.0 (s.f.). Obtenido de http://jediknight3.filefront.com/file/Ahsoka_Tanos_lightsaber_hilt;101125

53.

Q3Map2 - Wikibooks, open books for a open world (s.f.). Recuperado el 21 de enero de 2013, de http://en.wikibooks.org/wiki/Q3Map2

54.

Star Wars Jedi Knight: Jedi Academy SDK (s.f.). Obtenido de Fileplanet: http://www.fileplanet.com/133690/download/Star-Wars-Jedi-Knight:-Jedi-Academy-SDK

55.

"This is what Siege mode should have been..." (s.f.). Obtenido de The Jedi Academy: http://www.thejediacademy.net/articles_detail_page.php?f_id=9

56.

Movie Battles II. (s.f.). Obtenido de http://www.moddb.com/mods/4969/movie-battles-ii

57.

The Forms Of Combat. (s.f.). Obtenido de sitio web Movie Battles: http://www.moviebattles.com/features_formsofcombat

58.

Last Man Standing Features. (s.f.). Obtenido de sitio web Movie Battles: http://www.moviebattles.com/features_lastmanstanding

59.

Art of the Saber. (s.f.). Obtenido de sitio web Movie Battles: http://www.moviebattles.com/features_artofthesaber

60.

New Duel Mode. (s.f.). Obtenido de foro Movie Battles: http://www.moviebattles.com/forums/showthread.php?t=13871

61.

Introduction to Movie Battles 2/Siege Mapping (s.f.). Obtenido de Linsey's Maps-Tutorials: http://lindseysmaps.orgfree.com/tutorials_siege_intro.php

62.

How To Make Your Own Map (s.f.). Obtenido de ClanAOD: http://www.clanaod.net/forums/showthread.php?t=26201&page=1