Tesis Sistemas Educativos Basados en Videojuegos

UNIVERSIDAD COMPLUTENSE DE MADRID
FACULTAD DE INFORMTICA Departamento de Ingeniera del Software e Inteligencia Artificial
ARQUITECTURA Y METODOLOGA PARA EL DESARROLLO DE SISTEMAS EDUCATIVOS BASADOS EN VIDEOJUEGOS
MEMORIA PARA OPTAR AL GRADO DE DOCTOR PRESENTADA POR
Marco Antonio Gmez Martn
Bajo la direccin del doctor Pedro Antonio Gonzlez Calero
Madrid, 2007
ISBN: 978-84-692-0154-1
Arquitectura y metodologa para el desarrollo de sistemas educativos basados en videojuegos
TESIS DOCTORAL
Marco Antonio Gmez Martn Departamento de Ingeniera del Software e Inteligencia Articial Facultad de Informtica Universidad Complutense de Madrid Octubre 2007
Arquitectura y metodologa para el desarrollo de sistemas educativos basados en videojuegos
Memoria que presenta para optar al ttulo de Doctor en Informtica

Marco Antonio Gmez Martn
Pedro Antonio Gonzlez Calero
Dirigida por el Doctor
Departamento de Ingeniera del Software e Inteligencia Articial Facultad de Informtica Universidad Complutense de Madrid Octubre 2007
A mis padres
En todo hombre hay escondido un nio que quiere jugar

Friedrich W. Nietzsche (1844-1900)
Agradecimientos
A todos los que la presente vieren y entendieren.
Inicio de las Leyes Orgnicas. Juan Carlos I
Tengo que reconocer que cuando, all por mi primer ao en la Facultad, conoc al que a la postre se convertira en mi director de Tesis, no me gust nada. La primera impresin que me caus fue bastante mala, como le descubr un da mucho tiempo despus. La casualidad hizo que al ao siguiente volviera a formar parte del grupo de profesores que trataban de llenarnos la cabeza de bits, puertas lgicas, lenguajes de programacin y formalismos. Y entonces mi concepto sobre l dio un vuelco. Pedro no era, ni mucho menos, una persona desagradable. Al terminar la carrera inici, convencido por la inigualable Carmen Fernndez, los estudio de Doctorado en el extinto Departamento de Sistemas Informticos y Programacin. Despus del primer ao, cuando en Septiembre tena que decidirme sobre en qu campo concreto investigar, tena las ideas bastante poco claras; no saba quin podra ser mi tutor en el trabajo del segundo ao ni qu tema elegir. Y entonces, cuidando un examen en el aula magna de fsicas, mirando hacia los alumnos junto a Pedro, profesor de aquella asignatura, ste me mir y me dijo he estado pensando este verano en vosotros. Se refera a mi hermano y a m. Mientras los alumnos trataban de sacar adelante el examen, me propuso una serie de temas de investigacin que no pude (pudimos) rechazar. Por eso, y por todo lo que vino despus, por haber credo en m cuando yo no lo haca, por el apoyo durante todo este tiempo, mi primer agradecimiento es para l. Dentro del departamento hay otro montn de personas que me han ayudado, apoyado o contado conmigo durante este tiempo, y a los que tambin tengo mucho que agradecer. A la primera ya la he nombrado, Carmen Fernndez, que cuando an estaba en quinto y nos cruzbamos por los pasillos nos preguntaba por nuestras ideas para el futuro y tuvo la amabilidad de reservar una maana para explicarnos las posibilidades que ofreca la Universidad. Beln Daz, con su empeo en ver fciles las cosas difciles, tambin ha potenciado aspectos de este trabajo que yo crea muros insalvables. Guillermo Jimnez, vido lector de artculos, siempre poda relacionar mis ideas
ix
Agradecimientos
con las de algn otro investigador. Luis Hernndez, magnco organizador, siempre interesado por mis avances y dispuesto a ayudar en todo. Y Juan Pavn y Jorge Gmez que me acogieron en su grupo de investigacin durante un ao. En general, gracias a todos los miembros del grupo de investigacin de Aplicaciones de Inteligencia Articial en el que he desarrollado el trabajo, y a los miembros del Departamento de Ingeniera del Software e Inteligencia Articial; de las conversaciones con vosotros durante la comida es difcil no aprender algo. Finalmente, tampoco puedo olvidar a los becarios y estudiantes que han contribuido en la implementacin de JV M, como Pablo Palmier que me demostr que los becarios responsables existen. Pero sin duda la persona ms importante ha sido Pedro Pablo. Me resulta muy difcil encontrar palabras de agradecimiento para l por varios motivos. El primero es que ha sido desde siempre un pilar indispensable para m; el segundo es la imposibilidad de agradecerle el haber aguantado mis ideas ms estrambticas y haber sido crtico y revisor de todas las esquinas de esta tesis; y el ltimo es que, si encontrara las palabras de agradecimiento y las expresara en alto, me dira que ya las conoca. Tambin tengo que agradecer a aquellos que durante este tiempo me han apoyado y han soportado mis ausencias. Y eso va y casi nunca ha salido ganando. Gracias. Gracias al resto de mi familia. A mi hermano Jess Javier,
especialmente
por Laura,
que ha competido por mi tiempo con esta criatura que tienes entre tus manos,
Joti ;
a mis
abuelos, por la ropa de punto, las paellas y los paseos por el retiro; y por supuesto a mis tos. A Benjamn por inculcarme la curiosidad por el conocimiento por el mero hecho de saber, por las leyes de Kepler y por el mtodo para calcular eclipses que nunca lleg. A Julio, por explicar entre sudores a ese nio de seis aos que una vez fui qu era el parlamento. A Alfredo, que nos traa a casa la ilusin en piezas de un nuevo ordenador, y lo montaba con dos moscones alrededor deseosos de absorber todo lo que vean. A Marisa que, con Benja, me ayudaron a renar el ejemplo de animales que aparece en el captulo 4 mientras se extraaba de que les preguntara interesado si todos los animales que vuelan y tienen plumas son pjaros. Y a Quique, por las entretenidas conversaciones sobre los ltimos recovecos de C++, sobre libreras de enlace dinmico, y sobre cualquier otra cosa que se precie. Y para terminar dejo para el ltimo lugar a los primeros: a mis padres. Aqu la tenis. Esta tesis es vuestra.
Resumen
Desocupado lector, sin juramento me podrs creer que quisiera que este libro [...] fuera el ms hermoso, el ms gallardo y ms discreto que pudiera imaginarse.
Miguel de Cervantes, Don Quijote de la Mancha

Este trabajo de Tesis Doctoral presenta una arquitectura y metodologa de desarrollo de sistemas educativos basados en videojuegos. El objetivo principal es: 1. Minimizar la dependencia entre el conocimiento especco del dominio que se ensea y el resto del sistema. De esta forma, el conocimiento del dominio puede aprovecharse para implementar otros videojuegos educativos que enseen lo mismo pero de distinta forma. Tambin permite utilizar las partes no especcas del dominio en varios juegos educativos. En denitiva, permite la
reutilizacin,
de forma que se reduzcan
los costes de creacin de este tipo de aplicaciones. 2. Permitir que en desarrollos posteriores sean fcilmente sustituibles algunos mdulos. Principalmente se persigue poder tecnolgico. 3. Permitir que los distintos profesionales que entran en juego durante el periodo de desarrollo puedan trabajar sin solaparse unos con otros, minimizando las dependencias entre ellos. La metodologa propuesta aboga por una clara divisin entre los contenidos pedaggicos y los contenidos ldicos que los rodean. Para poderla hacer efectiva, la arquitectura software subyacente divide la aplicacin en mdulos con unas responsabilidades claras y no solapadas. Como prueba del correcto funcionamiento de la metodologa y arquitectura aqu propuesta, el trabajo incluye la descripcin detallada del desarrollo de JV M, un sistema educativo para ensear la compilacin de un lenguaje de alto nivel orientado a objetos como es Java.
intercambiar
fcil-
mente aquellos mdulos susceptibles de quedar obsoletos con el avance
xi
ndice
Agradecimientos Resumen 1. Introduccin
1.1. 1.2. 1.3. Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estructura de captulos . . . . . . . . . . . . . . . . . . . . . . Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . .
ix xi
1
1 2 4
2. Arquitecturas de videojuegos
2.1. 2.2. 2.3. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . Denicin de arquitectura . . . . . . . . . . . . . . . . . . . . Arquitecturas software en juegos 2.3.1. 2.4. 2.5. . . . . . . . . . . . . . . . .
7
7 9 10 12 14 17 21 21 23 24 27 31 32 33 35 45 46
Razones para el uso de COTS . . . . . . . . . . . . . .
Arquitecturas dirigidas por datos . . . . . . . . . . . . . . . . Bucle principal 2.5.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bucles multihebra
2.6.
Entidades del juego . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1. 2.6.2. 2.6.3. Organizacin y actualizacin de entidades Construccin de las entidades del juego . . . . . . .
. . . . . . . .
Arquitectura basada en componentes . . . . . . . . . .
2.7.
Lenguajes de script . . . . . . . . . . . . . . . . . . . . . . . . 2.7.1. 2.7.2. 2.7.3. Ventajas y desventajas de los lenguajes de script . . .
Ejemplos de lenguajes de script . . . . . . . . . . . . . Casos de uso . . . . . . . . . . . . . . . . . . . . . . .
Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . .
3. Aplicaciones educativas
3.1. 3.2. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . Descripcin de los entornos de aprendizaje . . . . . . . . . . . 3.2.1. Mdulo experto . . . . . . . . . . . . . . . . . . . . . .
49
49 50 52
xiii
xiv
ndice
3.2.2. 3.2.3. 3.2.4. 3.2.5. 3.3.
Modelo del estudiante
. . . . . . . . . . . . . . . . . .
53 54 55 56 60 60 61 62 63 64 66 70 70 72 74 77 77
Mdulo pedaggico . . . . . . . . . . . . . . . . . . . . Mdulo de comunicacin . . . . . . . . . . . . . . . . . Agentes pedaggicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arquitecturas de ITSs 3.3.1. 3.3.2. 3.3.3.
Arquitectura clsica de ITSs . . . . . . . . . . . . . . . Arquitectura Modelo de conocimientoVista . . . . . . Arquitectura basada en agentes . . . . . . . . . . . . . . . . . . . . .
3.4.
Arquitectura de entornos virtuales con agentes 3.4.1. 3.4.2.
Interfaz entre el agente y el entorno . . . . . . . . . . . Ejemplos de agentes en entornos virtuales . . . . . . .
3.5.
Agentes pedaggicos 3.5.1. 3.5.2. 3.5.3.
. . . . . . . . . . . . . . . . . . . . . . .
Interfaz entre el agente pedaggico y el entorno . . . . Arquitectura de ITSs con agentes pedaggicos . . . . . Ejemplo de agentes pedaggicos: Steve . . . . . . . . .
Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Metodologa de creacin de contenidos

4.1. 4.2. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proceso de creacin de un videojuego educativo . . . . . . . . 4.2.1. 4.2.2. 4.2.3. 4.2.4. 4.2.5. 4.3. Concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
79 80 85 86 87 87 89 89 90 91 93 95 95 96 97 99 99
Preproduccin Produccin
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control de calidad
Mantenimiento y explotacin
Creacin de contenidos . . . . . . . . . . . . . . . . . . . . . . 4.3.1. 4.3.2. 4.3.3. Contenidos en aplicaciones educativas . . . . . . . . .
Contenidos en videojuegos . . . . . . . . . . . . . . . . Contenidos en videojuegos educativos . . . . . . . . .
4.4.
Metodologa de creacin de contenidos . . . . . . . . . . . . . 4.4.1. 4.4.2. 4.4.3. Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . Puesta en prctica . . . . . . . . . . . . . . . . . . . .
Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.
Herramientas necesarias para el desarrollo 4.5.1. 4.5.2. 4.5.3. 4.5.4. 4.5.5.
Compiladores, IDEs y herramientas de construccin
Sistemas de control de versiones . . . . . . . . . . . . . 101 Sistemas de gestin del conocimiento . . . . . . . . . . 102 Sistemas de seguimiento de errores Sistemas de integracin continua . . . . . . . . . . . 102
. . . . . . . . . . . . 103
4.6.
Otras herramientas de soporte . . . . . . . . . . . . . . . . . . 105
ndice
xv
4.6.1. 4.6.2. 4.6.3.
Anlisis Formal de Conceptos . . . . . . . . . . . . . . 106 Renamiento de ejercicios . . . . . . . . . . . . . . . . 110 Nivelado del juego . . . . . . . . . . . . . . . . . . . . 116
Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5. Arquitectura de sistemas educativos basados en juegos

5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8.
125
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Objetivos de la arquitectura . . . . . . . . . . . . . . . . . . . 126 Visin general . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Subsistema de tutora . . . . . . . . . . . . . . . . . . . . . . 128
Vista lgica del mundo . . . . . . . . . . . . . . . . . . . . . . 131 Entidades del juego . . . . . . . . . . . . . . . . . . . . . . . . 133 Comunicacin entre vista lgica y entidades . . . . . . . . . . 137 Motor de la aplicacin 5.8.1. 5.8.2. 5.8.3. . . . . . . . . . . . . . . . . . . . . . . 140 . . . . . . . . . . . . . . . . . . 142
Dependencia de datos
Gestin de mapas . . . . . . . . . . . . . . . . . . . . . 143 Implementacin . . . . . . . . . . . . . . . . . . . . . . 145
5.9.
Control de la ejecucin . . . . . . . . . . . . . . . . . . . . . . 145 . . . . . . . . . . . . . . . . . . . . . . . . 146 . . . . . . . . . . . 148
5.10. Agente pedaggico
5.11. Relacin entre entorno virtual y ejercicios
5.12. Evaluacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
6. Sistema educativo para la enseanza de la JVM

6.1. 6.2. 6.2.1. 6.2.2. 6.2.3. 6.3. Descripcin de JV M 1 Descripcin de JV M 2
153
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Descripcin general . . . . . . . . . . . . . . . . . . . . . . . . 154
. . . . . . . . . . . . . . . . . 155 . . . . . . . . . . . . . . . . . 159
Aspectos de la JVM no cubiertos . . . . . . . . . . . . 161 . . . . . . . . . . . . . . . . . . . . . . 163
Motor de la aplicacin 6.3.1. 6.3.2. 6.3.3. 6.3.4. 6.3.5. 6.3.6.
Motor grco . . . . . . . . . . . . . . . . . . . . . . . 164 Gestin de entrada . . . . . . . . . . . . . . . . . . . . 168 Cargador de mapas . . . . . . . . . . . . . . . . . . . . 169 Motor de sonido . . . . . . . . . . . . . . . . . . . . . 171
Motor de colisiones . . . . . . . . . . . . . . . . . . . . 171 Control de ejecucin . . . . . . . . . . . . . . . . . . . 172
6.4.
Gestin de entidades . . . . . . . . . . . . . . . . . . . . . . . 178 6.4.1. 6.4.2. Funciones principales . . . . . . . . . . . . . . . . . . . 178 Mdulos OIM . . . . . . . . . . . . . . . . . . . . . . . 180
xvi
ndice
6.4.3. 6.4.4. 6.4.5. 6.4.6. 6.4.7. 6.5.
Conguracin de entidades segn el ejercicio . . . . . . 183 Objetos OIM . . . . . . . . . . . . . . . . . . . . . . . 185
Implementacin mediante componentes . . . . . . . . . 188 Ejemplos de componentes . . . . . . . . . . . . . . . . 190
Ejemplos de entidades de juego . . . . . . . . . . . . . 193 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Vista lgica 6.5.1. 6.5.2.
Ejecucin de instrucciones de la JVM en JV M 1 . . . 201 Ejecucin de instrucciones de la JVM en JV M 2 . . . 201 . . . . . . . . . . . . . . . . . . . . . . 202 . . . . . . . . . . . . . . . . . . . . . . . 202
2 2
6.6.
Subsistema de tutora 6.6.1. 6.6.2. 6.6.3. Inicializacin Ejercicios
. . . . . . . . . . . . . . . . . . . . . . . . . 203
Ejecucin durante la partida . . . . . . . . . . . . . . . 204 . . . . . . . . . . . . . . . . . . . . 205 . . . . . . . 206
6.7.
Generacin de contenidos 6.7.1. 6.7.2.
Generacin del conocimiento del dominio
Generacin del entorno de aprendizaje . . . . . . . . . 206
Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
7. Conclusiones y trabajo futuro

7.1. 7.2. Conclusiones Trabajo futuro
211
. . . . . . . . . . . . . . . . . . . . . . . . . . . 211 . . . . . . . . . . . . . . . . . . . . . . . . . . 214
A. Mquina virtual de Java

A.2. Estructura de la mquina virtual A.2.1. Tipos de datos
217
. . . . . . . . . . . . . . . . 218 . . . . . . . . . . . . . . . . . . . . . . 218
A.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
A.2.2. reas de datos en tiempo de ejecucin . . . . . . . . . 219 A.2.3. Conjunto de instrucciones . . . . . . . . . . . . . . . . 220
B. Gestor de scripts en Java desde C++

B.2.1. Soporte para hebras B.3. ScriptManager
225
B.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 B.2. JNI: Java Native Interface . . . . . . . . . . . . . . . . . . . . 225 . . . . . . . . . . . . . . . . . . . 227
. . . . . . . . . . . . . . . . . . . . . . . . . . 227 . . . . . . . . . . . . . . . . . . . . . . . . 228 . . . . . . . . . . . . . . . . . . . . . . . 228
B.3.1. ScriptClass B.3.2. ScriptObject B.4. Cadenas en Java
. . . . . . . . . . . . . . . . . . . . . . . . . 229
B.5. Invocacin de mtodos . . . . . . . . . . . . . . . . . . . . . . 229 B.6. Uso de Java en JV M
. . . . . . . . . . . . . . . . . . . . . . 231
C. Cdigo representativo de JV2 M

C.1. Motor de la aplicacin
233
. . . . . . . . . . . . . . . . . . . . . . 233
ndice
xvii
C.1.1. C.1.2. C.1.3. C.1.4. C.1.5.
Maps::CMapFile . . . . . . . Maps::CMapEntity . . . . . . Maps::CMapModel . . . . . . . Maps::CMapLoaderObserver . Maps::CMapLoader . . . . . .
. . . . . . . . . . . . . . 233 . . . . . . . . . . . . . . 235 . . . . . . . . . . . . . . 239 . . . . . . . . . . . . . . 241 . . . . . . . . . . . . . . 242
C.2. Gestor de scripts en Java C.2.1. C.2.2. C.2.3. C.2.4.
. . . . . . . . . . . . . . . . . . . . 245 . . . . . . . . . . . . 245 . . . . . . . . . . . . 252 . . . . . . . . . . . . 256 . . . . . . . . . . . . 259
JVMIntfz::JVM . . . . . . . . . . ScriptSystem::CScriptManager ScriptSystem::CScriptClass . ScriptSystem::CScriptObject . JJVM::COperandStack
C.3. Mquina virtual de Java . . . . . . . . . . . . . . . . . . . . . 262 C.3.1. . . . . . . . . . . . . . . . . . . 262
Bibliografa Lista de acrnimos
271 296
ndice de guras
2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. Ejemplo de juego con datos acoplados en el cdigo Esquema de bucle principal bsico . . . . . . 15 17 20 22 25 26 31 35 37 40 43 44 45 57 60 63 66 67 68 73 75 76 90 93 96 . . . . . . . . . . . . . . . . . . . .
Bucle principal con fotograma variable y tiempo jo
Jerarqua parcial de los tipos de entidad de Half-Life 1 . . . . Ejemplo sencillo de factora de creacin de entidades . . . . .
Cdigo C++ de factora extensible . . . . . . . . . . . . . . . Estructura de objetos utilizando componentes . . . . . . . . . Captura del juego Don Quijote . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cdigo posible para el juego Don Quijote
2.10. Pseudo-cdigo de un comportamiento en busca de cobertura . 2.11. Denicin de un objetivo compuesto en Far Cry . . . . . . . . 2.12. Implementacin de un comportamiento en Far Cry . . . . . .
2.13. Ejemplos del uso de un motor de reglas en un juego . . . . . . 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. 4.1. 4.2. 4.3. 4.4. Captura del sistema Steve en funcionamiento Arquitectura clsica de un ITS Estructura de un agente simple Arquitectura de SimHuman . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Estructura interna de un avatar en SimHuman
Estructura de mVital . . . . . . . . . . . . . . . . . . . . . . . Arquitectura tpica de un agente pedaggico . . . . . . . . . . Arquitectura del sistema Steve completo . . . . . . . . . . . . Estructura interna del agente pedaggico Steve . . . . . . . .
Esquema de contenidos en aplicaciones educativas . . . . . . . Esquema de contenidos en juegos . . . . . . . . . . . . . . . . Esquema de contenidos en juegos educativos . . . . . . . . . . Coste de generacin de contenidos de forma manual y procedimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98 99
4.5. 4.6.
Esquema de creacin de mapas
. . . . . . . . . . . . . . . . .
2 Captura de CruiseControl en el proyecto JV M 2 . . . . . . . 105
xix
xx
ndice de figuras
4.7. 4.8. 4.9.
Retculo generado a partir del contexto formal de animales . . 109 Captura de ConExp . . . . . . . . . . . . . . . . . . . . . . . 110
Vista parcial de la ontologa de elementos de compilacin de Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.10. Base de ejercicios inicial antes del renamiento con FCA . . . 112 4.11. Retculo de la base de ejercicios inicial . . . . . . . . . . . . . 114
4.12. Ejercicios aadidos mediante renamiento con FCA . . . . . . 115 4.13. Captura de U61 . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.1. Arquitectura general de un sistema educativo basado en videojuegos 5.2. 5.3. 5.4. 5.5. 5.6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Vista detallada del subsistema de tutora . . . . . . . . . . . . 129 Esquema detallado del mdulo de vista lgica . . . . . . . . . 131 Ejemplos de entidades basadas en componentes Vista detallada del motor de la aplicacin . . . . . . . . 136
. . . . . . . . . . . 140
Esquema de implementacin del mdulo de percepcin de un agente pedaggico . . . . . . . . . . . . . . . . . . . . . . . . 147 155
6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8.
Capturas de JV M 2 relacionadas con la seleccin de usuario
2 2 2 2
Capturas de JV M 1 relacionadas con la pila de frames . . . . 156 Capturas de JV M 1 . . . . . . . . . . . . . . . . . . . . . . . 158 Capturas de JV M 2 . . . . . . . . . . . . . . . . . . . . . . . 160
2 Ayuda en JV M 2 . . . . . . . . . . . . . . . . . . . . . . . . 161 2 Captura de JV M 1 preliminar . . . . . . . . . . . . . . . . . 164

Modelo de Half-Life cargado con Nebula 1 . . . . . . . . . . . 165 Creacin de un modelo para Nebula 2 . . . . . . . . . . . . . 166
2 6.9. Clases pblicas del motor grco de JV M . . . . . . . . . . . 167 2 6.10. Clases relacionadas con la entrada de JV M . . . . . . . . . . 169
6.11. Diseo de clases del cargador de mapas . . . . . . . . . . . . . 170 6.12. Diseo de clases de la aplicacin . . . . . . . . . . . . . . . . 172
6.13. Diagrama de secuencia del bucle principal de JV M . . . . . . 175 6.14. Diagrama de clases que gestionan la hora de la aplicacin en JV M
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.15. Diseo de clases del temporizador de la aplicacin en JV M
. 178
2 6.16. Diagrama de clases del gestor de manadas de JV M . . . . . . 181 2 6.17. Manadas en funcionamiento en JV M 2 . . . . . . . . . . . . 182
6.18. Edicin de manadas en Worldcraft 6.19. Cdigo parcial de un mapa . . . . . . . . . . . . . . . 183 . . . . . . . . . . . . . . . . . . . 184 . . 185
6.20. Diagrama de secuencia de la inicializacin de una manada
6.21. Relacin entre mapas y objetos OIM . . . . . . . . . . . . . . 186 6.22. Diseo de clases involucradas en la implementacin mediante componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
ndice de figuras
2
xxi
6.23. Jerarqua de clases de componentes y mensajes en JV M 2 . . 192 6.24. Componentes utilizados en las variables locales 6.25. Componentes utilizados en la IA de las manadas . . . . . . . . 194 . . . . . . . 196
6.26. Componentes utilizados en los individuos de las manadas . . . 198 6.27. Diseo de clases de la implementacin de la JVM en JV M 6.28. Ejemplos de invocaciones de la vista lgica al subsistema de tutora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 6.29. Capturas de dos herramientas de generacin de conocimiento del dominio en JV M . . . . . . . . . . . . . . . . . . . . . . . 206 6.30. Generacin de mapas en JV M
. 200
. . . . . . . . . . . . . . . . . 208
ndice de Tablas
4.1. 4.2. 4.3. 4.4. 4.5. 5.1. 5.2. 6.1. 6.2. Ejemplo de contexto formal sobre animales . . . . . . . . . . 107 . . . . . . . . . 113 . . . . . . . . . 116 Contexto formal de la base de ejecicios inicial Contexto formal de la base de ejercicios nal
Reglas de dependencia del contexto formal de animales . . . . 120 Contexto formal parcial de las partidas de tetris . . . . . . . . 122 Acciones primitivas entre el entorno virtual y la vista lgica Distintas instanciaciones de la arquitectura . 139
. . . . . . . . . . 151
Resumen de las metforas de JV M 1 y JV M 2 . . . . . . . . 162 Clases de la JVM que permiten observadores . . . . . . . . . 201 . . . . . . . 221
A.1. Prejos utilizados en las instrucciones de la JVM B.1. Codicacin de tipos de Java en cadenas.
. . . . . . . . . . . 231
xxiii
Captulo 1
Introduccin
Psose don Quijote delante de dicho carro, y haciendo en su fantasa uno de los ms desvariados discursos que jams haba hecho, dijo en alta voz:
Alonso Fernndez de Avellaneda, El Ingenioso Hidalgo Don Quijote de la Mancha
1.1. Motivacin
Varias dcadas de investigacin en aprendizaje por ordenador han demostrado que los expertos del dominio deben involucrarse en el proceso de creacin de los contenidos de las aplicaciones educativas para que el resultado sea satisfactorio. El resultado ha sido un desmesurado esfuerzo en la construccin de diversas herramientas de autora, que permiten directamente a esos expertos la construccin de estas aplicaciones. Durante aos una inmensa coleccin de programas educativos han visto la luz, gracias a estas herramientas que permiten generar contenidos en formatos determinados que luego son presentados por graciadamente, en la mayora de los casos la
visores genricos. Desinteraccin con el usuario es
muy limitada, haciendo que la motivacin inicial por el aprendizaje se diluya en la constante visin de contenidos poco interactivos. Para mejorar la motivacin, los ltimos aos han sido testigos del surgimiento de un nuevo tipo de aprendizaje por computadora utilizando videojuegos, en lo que se ha venido a llamar aprendizaje basado en juegos (game-based
learning ) o juegos serios (serious games ) (Gmez Martn, G-
mez Martn y Gonzlez Calero, 2004a). Resulta fcil defender el argumento de que utilizar videojuegos para ensear es efectivo. Al n y al cabo, los juegos se han utilizado desde siempre para ensear, e incluso los cachorros de muchas especies lo utilizan como mtodo de entrenamiento en un entorno seguro. 1
Captulo 1.
Introduccin
Sin embargo, en el momento de desarrollar una de estas aplicaciones educativas, nos enfrentamos a muchas ms dicultades de las que tenamos con las aplicaciones educativas tradicionales. Desde el punto de vista del
contenido,
en los juegos tradicionales ste
toma dos formas distintas: multimedia y jugabilidad. Los modelos tridimensionales de los escenarios, objetos y personajes, las texturas bidimensionales que los
colorean, las animaciones, msicas y efectos sonoros denen el conte-
nido multimedia, mientras que la jugabilidad viene determinada por lo que el usuario hace dentro del juego. Los diseadores encargados de la jugabilidad construyen descripciones detalladas de las acciones que el jugador puede hacer y cmo el juego debe reaccionar. Cuando aadimos la capacidad educativa a uno de estos juegos, debemos sumar a estos dos tipos de contenidos el del dominio que se pretende ensear. En este caso, el experto del dominio debe
tambin
proporcionar descripciones
detalladas de lo que el estudiante debe hacer y cmo debe reaccionar el sistema, tarea que se solapa por completo con la del diseador del juego. Por si eso fuera poco, el tamao y calidad de los videojuegos no deja de incrementar, hasta el punto de que para poder satisfacer las expectativas de los vidos jugadores, hoy por hoy se puede llegan a necesitar varios cientos de personas trabajando durante al menos dos aos. Debido a todo esto, parece claro que la construccin de videojuegos educativos es mucho ms complicada que la creacin de aplicaciones educativas tradicionales, lo que provoca que el presupuesto necesario diera en varios rdenes de magnitud. La consecuencia directa de estas dicultades es que hoy por hoy no existen demasiados estudios empricos que demuestren que efectivamente su uso es ms efectivo que las aplicaciones educativas tradicionales. Para aliviar el problema, este trabajo de Tesis Doctoral presenta una arquitectura y metodologa de desarrollo de sistemas educativos basados en videojuegos. La arquitectura dirigida por datos permite la construccin de videojuegos educativos permitiendo la creacin por separado de los contenidos de instruccin y los de jugabilidad. Gracias a esta divisin, el solapamiento en las tareas de ambos expertos se reduce al mnimo. La metodologa tambin propone una serie de herramientas para comprobar que los contenidos generados por ambos expertos se adecan al producto nal perseguido. El trabajo ejemplica adems esa arquitectura con un sistema de enseanza llamado JV M, para ensear la compilacin de un lenguaje de alto nivel orientado a objetos como es Java.
1.2. Estructura de captulos

A continuacin aparece la secuencia de captulos, as como una breve descripcin de su contenido:
1.2. Estructura de captulos
Captulo 2: Arquitecturas de videojuegos. Este captulo introduce las

partes ms importantes en las que se estructura una aplicacin de entretenimiento. En particular, describiremos la importancia de una arquitectura basada en datos, justicaremos la necesidad de la utilizacin de cdigo de terceros y detallaremos cmo gestionar la ejecucin de todas las tareas que debe realizar la aplicacin. El captulo pasa despus a explicar algunas formas de manejar las entidades que forman parte del entorno virtual, y los lenguajes de scripts como un mtodo de sacar parte de su control a cheros de datos.
Captulo 3: Aplicaciones educativas. Este captulo hace un anlisis de

las arquitecturas de los programas educativos que centran nuestro foco de atencin. Para eso, comienza por analizar la construccin de sistemas de enseanza inteligentes. Despus se analiza cmo se integran agentes en entornos virtuales para despus aplicar esa integracin a los agentes pedaggicos.
Captulo 4: Una metodologa para la creacin de contenidos dirigidos por datos. Presenta la metodologa de desarrollo de las aplicaciones educativas basadas en videojuegos. Para eso, primero se hace una descripcin de alto nivel de las fases que deben seguirse durante su creacin y las herramientas de soporte necesarias. Tambin describimos nuestra propuesta de metodologa para la creacin de los contenidos que presenta la aplicacin. Por ltimo, el captulo describe dos tcnicas de uso del anlisis formal de conceptos para el anlisis de los contenidos creados.
Captulo 5: Arquitectura para el desarrollo de sistemas educativos basados en videojuegos. Se presenta la propuesta de arquitectura
de aplicaciones educativas basadas en videojuegos. Describe primero los objetivos, para pasar a mostrar la visin general de la misma. Posteriormente analiza cada uno de los mdulos en detalle. El captulo termina con una evaluacin.
Captulo 6: Sistema educativo para la enseanza de la mquina virtual de Java. Este captulo describe las dos versiones de JV2 M, el
sistema educativo que permite aprender la mquina virtual de Java y cmo el cdigo Java es compilado para ella. El sistema ha sido creado utilizando la metodologa y arquitectura descritas en los dos captulos anteriores, por lo que ste se centra en cmo se han llevado a cabo las directrices descritas en ellos.
Captulo 7: Conclusiones y trabajo futuro.
Captulo 1.
Introduccin
1.3. Contribuciones
Todos los captulos de esta tesis, a excepcin de ste de Introduccin y del ltimo de Conclusiones, terminan con una seccin titulada Notas bibliogrcas. En esas secciones se ponen en contexto todos aquellos artculos escritos por el autor y por el director de este trabajo que han sido publicados en distintas revistas, congresos y
workshops ; en concreto, se relaciona su
contenido con el del captulo en cuestin. Aunque aconsejamos la lectura de estas secciones, por describir el contenido de los artculos propios y ajenos, a continuacin aparece una lista de algunas de las publicaciones a las que ha dado lugar este trabajo de Tesis Doctoral. Para una lista exhaustiva, remitimos al lector a las secciones anteriormente mencionadas y a las citas bibliogrcas que aparecen a partir de la pgina 271.
Uso de juegos para educacin: en Gmez Martn, Gmez Martn y Gonzlez Calero (2004a), Gmez Martn, Gmez Martn y Gonzlez Calero (2004b) y Gonzlez Calero, Gmez Martn y Gmez Martn (2006) describimos el uso de juegos para la educacin. Metodologa y arquitectura: una descripcin preliminar de la metodologa y arquitectura presentadas en esta memoria fue expuesta en Gmez Martn, Gmez Martn y Gonzlez Calero (2003). La arquitectura nal es presentada en Gmez Martn, Gmez Martn y Gonzlez Calero (2007a) y Gmez Martn, Gmez Martn y Gonzlez Calero (2007b) con distintos grados de detalle. Arquitectura en otros contextos: la arquitectura descrita tambin se ha utilizado para la implementacin de VirPlay, como se explica brevemente en Jimnez Daz, Gmez Albarrn, Gmez Martn y Gonzlez Calero (2005c). Tambin hemos descrito en Peinado Gil, Gmez Martn y Gmez Martn (2005) una variacin de la misma para el desarrollo de aplicaciones con una fuerte componente narrativa. Anlisis de los contenidos: gracias a la separacin entre los dos tipos de contenido, pedaggico y ldico, la metodologa permite aplicar tcnicas de anlisis a ambos por separado. Daz Agudo, Gmez Martn, Gmez Martn y Gonzlez Calero (2005) describe una tcnica para analizar el contenido pedaggico; por su parte, Gmez Martn, Gmez Martn, Gonzlez Calero y Daz Agudo (2006b) hace lo propio con los datos relativos al juego. Descripcin de JV M: la aplicacin educativa para ensear la estructura interna de la mquina virtual de Java ha sido descrito en Gmez
1.3. Contribuciones
Martn, Gmez Martn y Gonzlez Calero (2006a) y Gmez Martn, Gmez Martn, Gonzlez Calero y Palmier Campos (2007d). Desarrollo de la aplicacin: en Gmez Martn, Gmez Martn y Jimnez Daz (2007c) se describen las herramientas necesarias para el desarrollo de aplicaciones educativas basadas en videojuegos. Por su parte, Gmez Martn y Gmez Martn (2006) describe, entre otras cosas, las caractersticas y diferencias entre los dos motores grcos utilizados en JV M, Nebula 1 y Nebula 2.
Captulo 2
Arquitecturas de videojuegos
Si los arquitectos hiciesen edicios de la misma forma en que los programadores escriben programas, el primer pjaro carpintero que pasase por aqu destruira la civilizacin
Gerald Weinberg
Este captulo introduce las partes ms importantes en las que se estructura una aplicacin de entretenimiento. En particular, describiremos la importancia de una arquitectura basada en datos, justicaremos la necesidad de la utilizacin de cdigo de terceros y detallaremos cmo gestionar la ejecucin de todas las tareas que debe realizar la aplicacin. El captulo pasa despus a explicar algunas formas de manejar las entidades que forman parte del entorno virtual, y los lenguajes de scripts como un mtodo de sacar parte de su control a cheros de datos.
2.1. Introduccin
La construccin de programas educativos basados en juegos no es una tarea fcil. Como punto de partida, es necesaria la toma de decisiones de diseo iniciales que darn lugar a la arquitectura general del sistema. Si dejamos de lado las metodologas giles expuestas por la Agile Alliance (2001), esa arquitectura creada al principio del proceso de desarrollo, establecer una serie de restricciones en el momento de la implementacin. Est claro que el arquitecto software basa sus decisiones, entre otras cosas, en su propia experiencia (parafraseando a Astrachan et al. (1998), los buenos diseos se consiguen con la experiencia; la experiencia se consigue con los malos diseos). En el caso particular que nos incumbe, es decir, en el desarrollo de programas educativos basados en juegos, es valiosa la experiencia en el desarrollo de arquitecturas para videojuegos, as como de programas educativos. 7
Captulo 2.
En este captulo nos centraremos en el anlisis de las arquitecturas de programas de entretenimiento, que servirn de base a la arquitectura de un sistema que junte este rea con las aplicaciones educativas. De esta forma, se podr comprobar qu tcnicas comnmente utilizadas en videojuegos pueden ser extrapolables a nuestro rea. En el captulo siguiente haremos lo mismo pero en el rea de los programas educativos. No existe mucha literatura relativa a la descripcin de las arquitecturas utilizadas en estas aplicaciones, a pesar de ser un campo en el que cada ao se crean miles de aplicaciones; como dato, en el 2006, el nmero de expositores en la feria del videojuego por excelencia, la E3 (The
Entertainment Expo ),
2006).
Electronic
super los 500 (The Electronic Entertainment Expo,
La causa es que slo desde hace unos aos los desarrollos de videojuegos se hacen planicando por adelantado una arquitectura software. En 1999, Rollings y Morris comentaban que era muy habitual que los estudios de juegos saltaran desde el diseo del juego a su implementacin directamente, sin pasar por un periodo previo de maduracin de la arquitectura software que lo iba a sustentar. Con ese mtodo de trabajo, el xito o fracaso del desarrollo dependa casi por completo de la habilidad y nivel de experiencia de los desarrolladores. Hoy en da la situacin ha mejorado signicativamente. Es difcil crear un juego AAA
1 en menos de dos aos. Con estos largos desarrollos en los que
se ven involucradas decenas o cientos de personas, la ingeniera del software resulta completamente necesaria. Afortunadamente, tanto los estudios como los propios desarrolladores ya se han dado cuenta de esto, como demuestra, por ejemplo, la existencia de listas de discusin dedicadas en exclusiva al tema (ver por ejemplo Sweng-Gamedev, creada en 2002). An as, en muchos casos la arquitectura planeada queda restringida a un nico ttulo, y el estudio vuelve a disear una gran parte de ella para el siguiente desarrollo. Por ejemplo, el creador de la saga Doom y Quake, John Carmack, asegur en una entrevista que gran parte del cdigo de Quake 3 no se aprovech para Doom 3, pese a pertenecer ambos al mismo gnero y tener jugabilidad similar (Sloan y Mull, 2003). Como ejemplo adicional, algn mensaje de la lista de distribucin anterior (Sweng-Gamedev, 2002) indica que en la misma compaa se ha reescrito incluso el sistema de mens de un juego a otro, a pesar de ser un elemento independiente por completo de la temtica del juego en desarrollo. Otro problema que va de la mano de la falta de arquitectura es la frecuencia con que se dan fallos en la
planicacin, que hacen que los proyectos
se retrasen numerosas veces, llegando incluso a la cancelacin debido al excesivo tiempo de desarrollo. Se puede decir que, si bien los desarrolladores
Se dice que un juego es AAA cuando tienen un alto presupuesto, su lanzamiento es
considerado un evento meditico, etc. (Wardell, 1998).
2.2. Denicin de arquitectura
experimentados consiguen terminar el producto, raras veces lo hacen segn el calendario planicado (Fristrom, 2003), principalmente debido a que la mayor parte del cdigo se de en un diseo formal. Todos estos hechos pueden resumirse en que la industria de los videojuegos ha madurado mucho en los ltimos aos, pero los procesos de desarrollo no han avanzado a la misma velocidad. Se ha pasado desde los juegos creados en garajes y con poco mercado, a desarrollos de varios millones de dlares y gran repercusin medatica y popularidad. Sin embargo, los controles de la produccin, gestin de los proyectos y arquitecturas software, a pesar de haber avanzado, no lo han hecho de manera acorde, por lo que no suelen estar a la altura del proyecto de la misma manera que lo estn en otras reas de la industria del software (Larsen, 2002). A lo largo de este captulo identicaremos los componentes bsicos que aparecen en la gran mayora de los juegos, para denir un vocabulario que utilizaremos despus cuando detallemos la arquitectura propuesta para el desarrollo de aplicaciones educativas basadas en videojuegos. Por lo tanto, el cometido de este captulo no es proponer una arquitectura genrica que pueda ser reutilizada en el desarrollo de cualquier tipo de juegos (ese es el objetivo por ejemplo de Plummer, 2004), sino hacer un anlisis de distintas arquitecturas, para poder disear una vlida en nuestro mbito de actuacin.
reescribe
de un juego a otro, y a que el xito de la
empresa se fundamenta principalmente en la experiencia individual, en vez
2.2. Denicin de arquitectura

Durante dcadas, los ingenieros del software han creado sus propios diseos empezando de cero, o reutilizando diseos de otros. Hoy en da, esa situacin ha cambiado, surgiendo una nueva disciplina conocida como
quitecto software
ar-
que utiliza un lenguaje comn a todos los ingenieros del
software para detallar diseos de alto y bajo nivel (Braude, 2001). La denicin de lo que se entiende por arquitectura software no est, sin embargo, consensuada. Algunos autores, como Braude (2001) indican simplemente que el trmino arquitectura es equivalente a diseo al ms alto nivel (Braude, 2001, pag. 150). Tambin Eoin Woods habla de
diseo
decisiones de
al decir que una arquitectura software es el conjunto de decisiones
de diseo que, si son incorrectas, pueden causar que el proyecto se cancele (Rozanski y Woods, 2005). Shaw y Garlan (1996) sin embargo, no hablan de arquitectura como tal, sino de diseo a nivel de arquitectura, entendiendo ste como el relacionado con cuestiones estructurales, como la organizacin del sistema, protocolos de comunicacin, sincronizacin y acceso a datos, asignacin de funcionalidad a cada elemento, composicin de cada uno de estos elementos, distribucin
10
Captulo 2.
fsica, escalado y rendimiento, etc. Cuando se habla de arquitectura como un diseo de alto nivel, tiene sentido hablar de patrones arquitectnicos (llamados estilos arquitectnicos por Shaw y Garlan (1996)), arquitecturas por capas, tuberas y ltros, pizarras, o modelo-vista-controlador (Buschmann et al., 1996). Una denicin ms apropiada es la expuesta por Bass et al. (2003), en la que denen la arquitectura de un programa o sistema de ordenador como la estructura o estructuras del sistema, que comprenden los elementos software, las propiedades de esos elementos visibles desde el exterior y las relaciones entre ellos. Esta forma de entender una arquitectura software es compartida por Rollings y Morris (2004), y tambin es la que aceptaremos de aqu en adelante.
una arquitectura software es la estructura de un programa, y abarca tambin el ujo de datos, deniendo las interacciones entre todos los elementos.
Resumiendo,
2.3. Arquitecturas software en juegos

Como ya queda dicho, la complejidad de los juegos ha llegado a unos lmites inimaginables hace slo unos aos. Hoy por hoy, para conseguir un juego de alta calidad, se requiere un presupuesto capaz de soportar un gran nmero de personas trabajando durante al menos ao y medio. Para corroborarlo, basten los siguientes datos:
En Noviembre de 1999 sala Unreal Tournament, despus de 18 meses de trabajo de 16 personas, un presupuesto de dos millones de dlares y 350.000 lneas de cdigo entre C++ y UnrealScript (Reinhart, 2000). El juego Vampire: the Masquerade requiri 12 desarrolladores durante 24 meses, casi dos millones de dlares y 366.000 lneas de cdigo (Huebner, 2000). Peter Molyneux puso a la venta en Marzo de 2001 su juego Black & White, despus de invertir casi seis millones de dlares en 25 desarrolladores durante tres aos, que escribieron dos millones de lneas de cdigo (Molyneux, 2001). En Junio de 2002 salo a la luz Neverwinter Nights, despus de 5 aos de desarrollo con un equipo que en algunos momentos lleg a ser de hasta 75 personas (Grieg et al., 2002). En 2003, slo portar el Splinter Cell de la plataforma XBox a Play Station 2 requiri 76 personas durante cinco meses a tiempo completo (Hao, 2003).
11
El desarrollo de juegos de nueva generacin para las nuevas consolas maneja cifras an ms escalofriantes. Para el Project Gotham Racing 3 de XBox 360, tuvieron que invertir 80.000 libras slo para comprar servidores en los que almacenar el arte del juego, y las veinte mil fotografas en las que se basaron para modelar cada una de las ciudades que aparecan en l (Gillen, 2005). El desarrollo de Call of Duty 2 para XBox 360 requiri 2 aos de trabajo de 75 personas, y tuvo un presupuesto de ms de 14 millones de dlares (Duy, 2005). Al ver estas cifras, queda claro que el desarrollo de juegos ha cambiado desde aquellas primeras aplicaciones desarrolladas para consolas, recreativas y ordenadores de 8 bits. Desde siempre, este tipo de aplicaciones han intentado aprovechar hasta el ltimo recurso del
hardware
para hacer ms llamativo el aspecto nal del
juego. Estos programas son aplicaciones
de tiempo real, donde una respuesta
dada tarde puede romper toda la sensacin de inmersin del jugador. Es necesario que el nmero de fotogramas mostrados por segundo sea elevado, para que el entorno presentado se considere interactivo y animado. Es por sto que los programadores deben conocer a la perfeccin el funcionamiento interno de todos los componentes para no desperdiciar recursos debido a una mala programacin. Cuando los recursos disponibles crecen, no decrece el esfuerzo necesario para crear los juegos. Al contrario, lo que ocurre es que aumentan sus pretensiones, lo que hace que la complejidad de programacin, generacin de modelos y recursos en general, tambin aumente. Esto conlleva un crecimiento notable tanto en el tiempo de desarrollo de un nico ttulo como en el aumento del nmero de personas del equipo. Desde el punto de vista histrico, durante la dcada de los 80 y principios de los 90, era habitual que los juegos se siguieran desarrollando en ensamblador, a pesar de los grandes avances en los compiladores. La idea generalizada era que el compilador no poda competir con un programador de ensamblador experto, por lo que los desarrollos seguan utilizndolo a pesar de aumentar signicativamente la duracin del proyecto. Durante la dcada de los 90 la situacin, por n, fue cambiando, y los estudios comenzaron a utilizar activamente lenguajes de alto nivel, especialmente C debido a sus capacidades de bajo nivel. Entre los compiladores estrella de aquella poca hay que destacar, en el mundo del PC, Watcom C. Este compilador fue ampliamente utilizado a mediados de los 90, para la programacin de juegos para MS-DOS (como Doom). Su xito radic en una muy buena calidad del cdigo generado, y en su soporte para la programacin en modo protegido del Intel 386. Desgraciadamente, Sybase, la empresa que lo cre, abandon el proyecto en 1999, ya que su principal mercado era el del mundo del PC (en Windows), y no podan competir con Microsoft.
12
Captulo 2.
Se puede decir que en aquella poca se vivi un gran salto en el proceso de desarrollo, ya que se pas de programar la prctica totalidad del juego en ensamblador, a utilizar lenguajes de alto nivel. Pensando framente, constituy un gran paso adelante, ya que los programadores tuvieron que rendirse a la evidencia de que era mejor aceptar que el cdigo ejecutado por la mquina durante el juego fuera generado por un compilador, que alargar un proceso de desarrollo debido al uso del tedioso y propenso a errores aunque ptimo ensamblador. Lo que se tard mucho ms en aceptar fue el uso de cdigo desarrollado por otros (cdigo
externo )
en el propio juego . Cada estudio, una y otra
vez, programa parte de cdigo que podra haber
comprado
a desarrolladores
externos. Es lo que en el mundo anglosajn se conoce como el
here syndrome ,
not invented
o reticencia a utilizar algo no creado en el propio estudio.
Esta reticencia se deba principalmente al hecho de pensar que el estudio poda desarrollar ese mdulo o funcionalidad de forma ms ptima que el componente comprado. Personalmente, estimo que una de las cosas que ayud a dar el salto, y a que se empezara a aceptar el incluir desarrollos externos en el propio juego fue la explosin de tarjetas grcas aceleradoras. Pronto se hizo evidente que los desarrolladores no podan optar por la programacin a bajo nivel del motor grco, accediendo directamente a las capacidades de la tarjeta. Esto era debido a que el nmero de tarjetas disponibles creca rpidamente. En este contexto surgi Windows 95, que adems impona limitaciones de acceso al el
hardware. hardware
Afortunadamente, tambin proporcionaba las libreras DirectX y la aplicacin, de tal forma que el programador no tena que
y OpenGL. stas colocaban (y an colocan) una barrera de abstraccin entre lidiar con las diferencias entre las distintas tarjetas. Las amplias ventajas de esta aproximacin hicieron que los estudios incorporaran estas libreras (externas) en sus juegos rpidamente. Sea cual sea la causa, poco a poco los estudios de desarrollo han ido aceptando la inclusin de cdigo externo en forma de libreras o mdulos completos comprados a terceros. Son lo que en ingls se conoce como COTS (Component
o the shelf ).
2.3.1.
Razones para el uso de COTS
En realidad, el uso de COTS es consecuencia de la imposibilidad de reutilizacin del cdigo en un mercado que evoluciona tan rpidamente como el de los videojuegos. El problema de la reusabilidad es que sta slo es posible si el software
No es de extraar, si se tiene en cuenta todo lo dicho anteriormente: si los estudios
no se aban del compilador, y eran reacios a reutilizar su propio cdigo entre proyectos, mucho ms difcil les resultaba utilizar cdigo de otros.
13
desarrollado se construy pensando en volver a ser usado (Tracz, 1995a); es decir, no vale con coger el cdigo creado para el ttulo anterior, y utilizarlo directamente. Es necesario que ese cdigo que se quiere volver a usar se creara con la reutilizacin en mente. Durante la dcada de los 90, cuando nosotros situamos la migracin de los estudios desde el ensamblador hacia los lenguajes de alto nivel, el rea de la reutilizacin estaba en auge. Se dedic, y an se dedica, mucho esfuerzo para generar aplicaciones que automaticen o al menos ayuden en la reutilizacin del cdigo. Sin embargo, Tracz (1995b) nombra un estudio que revelaba que el coste de desarrollo del cdigo se ve incrementado entre un 30 y un 50 por ciento si se implementa con miras a la reutilizacin. Adems, el diseo de las clases nuevas hay que hacerlo con cautela, para no caer en la
sobreingeniera
(Kerievsky, 2002), lo que provocara una prdida an ms
excesiva de recursos. Por poner un ejemplo
3 de la razn de este incremento, se puede pensar
en un juego que requiera un dado con los nmeros del 1 al 6 en sus caras. La implementacin de una tirada, requiere una simple lnea en C/C++, utilizando la funcin
rand(),
el mdulo y el incremento. Sin embargo, im-
plementar un cdigo reutilizable de un dado implica mucho ms tiempo (y por tanto, dinero). En primer lugar, es posible que el dado deseado en un futuro no tenga seis sino ms caras, por lo que el mdulo o clase
CDado
deber tener un parmetro para indicar el nmero de caras. Adems, con un nmero de caras variable, lo que aparece en cada una de ellas debera ser congurable. El cdigo de lo que antes era una mera lnea, ahora se ha convertido en un chero de denicin y otro de implementacin de una clase que habr que programar y probar, para garantizar su correcto funcionamiento. Cuando este proceso est completo (o mientras se completa), tambin habr que escribir la documentacin pertinente para facilitar la reutilizacin. Pero no todo son aspectos negativos; el notable incremento del coste en la escritura del cdigo reutilizable se compensa con el abaratamiento de los desarrollos posteriores, que simplemente tienen que hacer de
usuarios
de ese
software. De esta forma el esfuerzo dedicado en la construccin de clases o mdulos reutilizables se convierte en una inversin del estudio a medio o largo plazo. Sin embargo, el problema en la industria del videojuego es, precisamente, la dicultad de pensar a largo plazo, debido a que la ventana de mercado es muy corta. La causa es el rpido avance de las capacidades del hardware , y el hecho de que los juegos que se lanzan al mercado deben aprovechar los ltimos avances tecnolgicos para resultar atrayentes al consumidor.
3 4
Atribuido en Adolph (1999) a Luke Hohnmann. Obviamente, el ejemplo del dado en este caso no nos sirve. Para fundamentar esto,
estamos pensando en la reutilizacin de componentes ms grandes, como el motor grco o el de fsica.
14
Captulo 2.
Por lo tanto, existen dos barreras que frenan la generacin, por parte de los estudios de juegos, de cdigo altamente reutilizable:
Motivo econmico: la creacin de cdigo y componentes pensando en su reutilizacin es ms costosa. El propio mercado: por dos razones; (i) la creacin de estos componentes generalmente retrasa la salida del primer ttulo que los utiliza, algo que puede ser de vital importancia, al existir el riesgo de quedarse desfasado tecnolgicamente; (ii) la rpida evolucin del mercado hace que muchos componentes pensados para su reutilizacin queden obsoletos antes de poder volverlos a usar.
nicamente los estudios grandes que disponen de varios proyectos en paralelo pueden plantearse la posibilidad de desarrollar internamente partes del juego que reutilizarn. En ese caso, al salir al mercado varios ttulos en un corto espacio de tiempo, los componentes que se reutilizan no han quedado desfasados de un juego a otro. El resto de estudios, en general, no pueden hacer frente a la creacin de componentes reutilizables. Eso, unido a la necesidad de reducir los tiempos de desarrollo, hace que las prcticas software de dichas empresas estn migrando desde los desarrollos en los que todo el cdigo era construido por el propio estudio, a la
compra
de componentes software implementados por terceros.
De esta forma, surgieron empresas como RenderWare , que desarrolla un motor grco independiente de la plataforma utilizado por ms de 500 juegos entre los que destacan Grand Theft Auto: San Andreas o Call of Duty: Finest Hour, y como Havok
6 que tiene una familia de utilidades, como un motor
de animacin o de fsica, y que se ha utilizado en juegos como Half-Life 2 o F.E.A.R.. Conviene tambin destacar el caso especial de idSoftware y Epic Games, dos estudios de juegos que, si bien la calidad de los mismos en cuanto a guin puede ser discutible, la calidad grca que consiguen es indiscutible. Sus juegos pueden entenderse como propaganda de un producto derivado que tambin comercializan: la tecnologa grca. Ambos estudios
licencian
sus motores grcos a terceros, que los incorporan a modo de COTS en sus desarrollos. Por nombrar un ejemplo, Epic Games ha licenciado su motor a los estudio de Microsoft y Disney.
2.4. Arquitecturas dirigidas por datos

Inicialmente, el tamao de los juegos era muy pequeo, el contenido de la parte grca era mnima, y lo nico importante era sacar el mximo
5 6
http://www.renderware.com http://www.havok.com
2.4. Arquitecturas dirigidas por datos
15
660 MOVE 320,300: DRAW 320,351,1 670 MOVER 9,0: DRAWR 43,-12,0: DRAWR 0,-4: DRAWR -43,-4: DRAWR 0,20: MOVER 0,-2: DRAWR -4,0: MOVER 0,-16: DRAWR 4,0 680 MOVER 4,0: DRAWR 0,16,1: MOVER 4,-2: DRAWR 0,-14: ...
a) Captura del Laberinto del Sultn (Amsoft, 1984). b) Fragmento de cdigo original del juego
Figura 2.1: Ejemplo de juego con datos acoplados en el cdigo
rendimiento a unos escasos recursos hardware para conseguir una aplicacin que resultara mnimamente divertida. Con estos requisitos y mquinas (estamos hablando de la primera mitad de la dcada de los 80), los juegos se hacan principalmente en ensamblador, y los datos necesarios (como las posiciones de los muros del Comecocos, o la forma de pintar los fantasmas) estaban
cableados
en el cdigo. Por poner un
ejemplo real (aunque no sea en lenguaje ensamblador), la gura 2.1 muestra en su parte izquierda una captura del juego El Laberinto del Sultn, desarrollado por Amsoft en 1984. El dibujo est hecho completamente desde el cdigo, en este caso BASIC. Un fragmento de este cdigo puede verse en la parte derecha de la gura, en la que todas las instrucciones de dibujado (DRAW,
DRAWR, MOVE, MOVER)
reciben como parmetro las coordenadas .
Otra forma de acoplamiento entre cdigo y datos se daba con la existencia de los llamados
segmentos de datos (.data)
en el propio ejecutable que
almacenan los datos referenciados desde el cdigo. Sea como fuere, este fuerte acoplamiento entre el comportamiento del juego (lgica) y los datos necesarios para su ejecucin, fue separada mediante el uso de cheros. Ya durante la dcada de los ochenta aparecen juegos cuyo ncleo principal (ejecutable), una vez cargado en memoria, lea cheros de datos de los dispositivos de almacenamiento (disco duro, disquettes o incluso cintas), de los que obtena la informacin para dibujar al personaje, el mapa del nivel o las posiciones de los enemigos. Esta separacin permita que el trabajo de desarrollo pudiera dividirse entre la tarea de los programadores, que eran los responsables ltimos del ejecutable, y los artistas, que creaban los cheros con la parte grca. Hoy por hoy esta divisin es tan habitual que ya nadie piensa que en
Estas instrucciones operan con el cursor grco, movindolo, o dibujando lneas
desde su posicin hasta la indicada en el parmetro.
16
Captulo 2.
otros tiempos no fue as, y se ha pasado a una separacin an mayor: parte del propio
ejecutable, o mejor dicho, parte del cdigo que controla el juego
se
ha sacado fuera del chero ejecutable propiamente dicho. Esta separacin es posible gracias al uso de libreras de carga dinmica proporcionadas por el sistema operativo la seccin 2.7, como LUA (Ierusalimschy et al., 2006), Python (van Rossum, 2006) o UnrealScript (Sweeney et al., 2004). Este modelo ha hecho que los programadores, al contrario de lo que suceda a principios de la dcada de los 90, han dejado de ser el centro del desarrollo de juegos (Llopis, 2005a). Hoy en da, el rol del programador es muy distinto: el que construyen el
8 o mejor an, el uso de lenguajes de scripts, que veremos en
juego es creado contenido (en
por los artistas y diseadores, que son los ingls, game
content ).
De esta forma, su
tarea se ha desplazado desde ser el centro del desarrollo a estar al servicio del resto del equipo, proporcionndole los medios necesarios para crear un buen juego. Debido a la separacin clara entre cdigo y datos, han surgido distintas reas de programacin claramente diferenciadas en los estudios: Motor del juego: cdigo que va en el juego nal, pero que no es especco del juego en cuestin. Es la base de cdigo sobre la que se sustenta el juego en s; se apoya en la tecnologa subyacente, y simplica el desarrollo del resto de la aplicacin. Adems, en muchas ocasiones, permite la ejecucin del juego en distintas plataformas, como PC y consolas. Su funcionalidad tpicamente pasa por el motor grco (para presentar las escenas 2D y 3D), un motor de fsica o de colisiones, gestin del sonido, animacin, lenguajes de scripts y red. Dada su complejidad, ste es el mbito de actuacin principal de los COTS. Cdigo del juego ( game
code ): la parte de cdigo especca del juego
particular; por ejemplo, cmo reaccionan los personajes controlados por el ordenador ante ciertas situaciones, cmo se comporta la cmara, o cmo se almacenan los puntos del jugador. Esta parte del cdigo es muy importante, y en muchos casos se realiza, al menos parte de ella, en lenguajes de script. Herramientas: cuanto ms orientada a datos es la arquitectura de un juego, ms cheros de datos hay que generar, y por lo tanto, ms herramientas para ayudar en esa generacin se necesitan. En cuanto a herramientas, pueden ser simples plug-in para otras aplicaciones (como Maya o 3DStudio Max), o programas complejos para edicin de mapas (por ejemplo, Worldcraft/Hammer, UnrealEd y Sandbox). El lenguaje utilizado para crear estas herramientas no tiene por qu ser C/C++.
DLLs en Windows o
.so
en GNU Linux/Unix
2.5. Bucle principal
17
Lectura de la entrada
Lgica del juego
Simulacin fsica
Dibujado
Figura 2.2: Esquema de bucle principal bsico

La ejecucin de un juego est dirigida por lo que se conoce como el
principal
(en ingls
bucle game loop ), que es el responsable de la ejecucin de cada vivo y animado. A pesar de que la programacin
una de las tareas requeridas en cada fotograma, y que van encaminadas a crear la ilusin de un entorno del bucle principal lleva poco tiempo, su importancia es vital, ya que es el eje conductor que va estableciendo qu mdulos se ejecutan, cundo y cada cunto tiempo. El modelo de bucle principal utilizado dene, por ejemplo, si la lgica avanza en intervalos constantes o no, si la entrada del usuario es analizada casi instantneamente o su procesamiento es retrasado varios fotogramas, etc. La lista de tareas que debe realizar el bucle principal (ver gura 2.2) son: Gestin de la entrada del usuario: dado que un juego es una aplicacin inherentemente interactiva, es importante que la lectura de la entrada se realice de forma correcta. Puede involucrar desde simplemente comprobar si se ha pulsado alguna tecla, a la gestin de complicados dispositivos de entrada. En vez de distribuir la lectura de la entrada por las tareas que dependen de ella (por ejemplo, mirar el estado de las teclas cuando se va a actualizar la posicin del usuario y comprobar los eventos del ratn cuando se va a actualizar la cmara), se suelen analizar todos los dispositivos de entrada a la vez, almacenando el resultado de esas lecturas. Esos resultados son los que luego consultan las distintas tareas en el momento de su ejecucin. De esta forma, se garantiza que la aplicacin reaccionar de manera consistente en todo el fotograma. As, la lectura de la entrada pasa a ser una tarea por s misma, que suele situarse al principio del bucle de la aplicacin. En general, se ejecuta una vez en cada fotograma (o vuelta del bucle), aunque en juegos en los que la interaccin no es tan importante (como los de estrategia) puede hacerse cada varios fotogramas. Gestin de la red: en juegos multijugador, la red puede verse como otra forma de entrada, por lo que en algn momento del bucle de juego se
18
Captulo 2.
deben recopilar todos los mensajes de sta y procesarlos. Simulacin o actualizacin de la lgica del juego: es donde el juego realmente avanza. La simulacin se encarga de decidir los comportamientos de los personajes (IA), ejecutar las acciones de los mismos, actualizar el estado de los objetos, lanzar eventos que provocarn otras futuras acciones, etc. Tambin se encarga de que los personajes controlados por el jugador reaccionen ante los eventos recogidos en las fases anteriores. Simulacin fsica y gestin de colisiones: se encarga de mover los objetos de acuerdo con la simulacin fsica subyacente (velocidad y aceleracin actual), y puede encargarse de actualizar los sistemas de partculas o el avance de las animaciones de los personajes. La simulacin fsica en juegos sencillos puede llevarse a cabo dentro de la etapa anterior de simulacin de la lgica del juego, aunque hoy por hoy se tiende a separar. La ejecucin de la fsica puede provocar que los objetos simulados colisionan entre s. En ese caso, se debe reaccionar ante esas colisiones, tanto siguiendo las propiedades fsicas del mundo (por ejemplo, haciendo que una caja rebote en una pared) como las lgicas (haciendo que el jugador pierda energa si una bala colisiona contra l, etc.). Dibujado del mundo: todas las etapas anteriores van encaminadas a calcular el nuevo estado del entorno virtual: las nuevas posiciones de los objetos, sus estados de animacin, etc. En esta ltima fase del bucle principal, este estado recin calculado es utilizado para dibujar la nueva escena.
Existen algunas otras tareas de menor importancia que no han sido situadas en ninguna de las fases del bucle, y que, no obstante, no deben olvidarse, como son la actualizacin del sistema de sonido para que haga todas las mezclas necesarias, el procesado de los eventos enviados por el sistema operativo a la aplicacin/ventana (para reaccionar, por ejemplo, ante cambios de contexto, activacin del protector de pantalla, o entrada en modo ahorro de energa), o el envo de paquetes de red construidos durante la simulacin. En general, se puede decir que cada vuelta del bucle al nal tiene como resultado la creacin de un nuevo fotograma . Generalmente, se utiliza como parmetro para medir el rendimiento el nmero de vueltas por segundo que se ejecuta el bucle, o lo que es lo mismo, el nmero de fotogramas por segundo (FPS) que se dibujan en pantalla. Como lmite inferior para poder decir que la aplicacin es interactiva, suelen aceptarse los 16 fotogramas por segundo
En sistemas multihebra, el concepto de bucle principal se difumina, ya que cada
hebra puede ejecutar un bucle distinto, y slo uno de ellos termina con el dibujado de un fotograma.
19
(Valente et al., 2005), aunque el ptimo suele estar entre 50 y 60 (que suele coincidir, o al menos acercarse, a la velocidad de refresco del monitor). Existen dos alternativas bsicas en cuanto al control de los fotogramas por segundo:
Duracin del fotograma variable
El tiempo que transcurre entre la pre-
sentacin de un fotograma y el siguiente vara dependiendo de la situacin de juego. En momentos en los que se requiere gran cantidad de clculos (por picos en la inteligencia articial o fsica, o gran nmero de elementos a dibujar), los fotogramas por segundo pueden bajar, mientras que en otros momentos, pueden subir, aumentando la uidez de las animaciones, etc.
Duracin del fotograma ja
El nmero de fotogramas por segundo es
siempre el mismo. Esto es ms fcil de conseguir cuando el
hardware
al
que va destinado el juego est predeterminado y es jo. El ejemplo ms claro son las consolas. En ellas, los fotogramas se sincronizan con la actualizacin del sistema de video (25 fps en PAL y 30 en NTSC). En este caso, las tareas a ejecutar en el bucle principal deben asegurarse de que no bloquean la CPU ms tiempo del disponible. Por otro lado, la lgica del juego es la que hace avanzar el estado del entorno, simulando el paso del tiempo y el comportamiento de todas las entidades que lo pueblan. Para su actualizacin, existen tambin dos formas bsicas de simular el paso del tiempo, que tienen sentido especialmente cuando se utiliza una duracin variable de cada fotograma:
Paso de tiempo variable
Cada vez que se va a ejecutar la tarea de la
lgica/simulacin, se comprueba, utilizando el reloj del sistema, cunto tiempo ha pasado desde la actualizacin anterior. El cdigo recibe mediante un parmetro ese tiempo, y acta en consecuencia. Este mtodo de funcionamiento es el ms intuitivo y comnmente aceptado. No obstante, presenta algunas desventajas. Entre ellas, cabe destacar lo complicado que resulta corregir los errores detectados, al ser difcil de reproducir una ejecucin anterior. Tambin es cuestionable que en ciertos juegos la lgica se est ejecutando una vez cada fotograma. Por ejemplo, en un juego de estrategia en principio no es necesario plantearse las acciones a ejecutar 60 veces por segundo.
Paso de tiempo jo
Independientemente del tiempo
real
(o fsico ) que
haya pasado desde la ltima actualizacin de la lgica, la simulacin se realiza considerando que el lapso de tiempo es siempre el mismo. Si el ordenador es lo sucientemente rpido, puede darse el caso de que el bucle principal se ejecute en menos tiempo que el lapso de tiempo
20
Captulo 2.
time0 = GetTime ( ) ; do { time1 = GetTime ( ) int numLoops = 0 ;

// Tareas i n d e p e n d i e n t e s de l a s i m u l a c i n // ( g e s t i n de entrada , e t c . )
IndependentTickRun ( ) ;
while ( ( time1 time0 ) > TICK_TIME && numLoops < MAX_LOOPS) { GameTickRun ( ) ; // No e s n e c e s a r i o parmetro de tiempo . time0 += TICK_TIME; numLoops++; } f l o a t porce ntajeDeTic k ; porce ntajeDeTic k = min ( 1 . 0 f , f l o a t ( time1 time0 )/TICK_TIME ) ; GameDrawWithInterpolation ( porce ntajeDeTi ck ) ; } while ( ! bGameDone ) ;
Figura 2.3: Bucle principal con fotograma variable y tiempo jo
// S i m u l a c i n
// Dibujado con i n t e r p o l a c i n
de simulacin; en ese caso el bucle no actualiza la lgica, sino que se limita a dibujar. En ordenadores lentos puede ocurrir la situacin inversa, exigiendo al bucle actualizar la lgica varias veces por vuelta. Obviamente, desacoplar la simulacin y el dibujado implica algunas acciones ms. Si ejecutamos la simulacin 15 veces por segundo, pero mostramos 30 fotogramas, podemos estar duplicando el
frame
anterior.
Para evitarlo, antes de dibujar, habr que hacer una interpolacin de la posicin y rotacin de los objetos, as como la actualizacin de su animacin; para ello, habr que aadir una fase posterior a la simulacin y comprobacin de colisiones que sea la
estado
interpolacin del ltimo por
generado por la lgica. Para que no surjan problemas, se debe
intentar evitar las colisiones que pueden darse en la interpolacin de ese estado. Otra alternativa es hacer que el estado de la lgica vaya
delante del estado que se est dibujando. De esta forma, al dibujar, se extrapola hacia atrs la lgica, de tal forma que el problema de las
posibles colisiones se elimina. La gura 2.3 muestra el cdigo C++ simplicado de un bucle principal que utiliza este mecanismo de paso de tiempo jo Arvalo (2001). Al principio, ejecuta operaciones que no dependen del tiempo, como
2.6. Entidades del juego
21
lectura de la entrada y otras operaciones de mantenimiento. Despus ejecuta la simulacin. Como se ve, sta slo se ejecuta si el tiempo transcurrido desde la ltima simulacin (time1
de simulacin (TIME_TICK).
de la ltima simulacin.
- time0)
supera el
tiempo
Por ltimo, se realiza el dibujado del en-
torno, realizando la interpolacin de los elementos desde el momento
2.5.1.
Bucles multihebra
hardware
ha avanzado lo suciente como para permitir la
Hoy en da, el
ejecucin de hebras distintas con paralelismo
real.
Por ejemplo, en los PCs
empieza a ser habitual ordenadores capaces de ejecutar dos o cuatro hebras; la consola de Microsoft XBox 360 tiene un procesador con tres ncleos, cada uno con hyperthreading, y la Play Station 3 de Sony tiene un procesador central y siete procesadores satlite. Esto hace que los arquitectos software deban plantearse la paralelizacin de todos los mdulos del juego, para aprovechar todas estas capacidades. En el caso del PC y de la consola XBox, esta paralelizacin es relativamente sencilla (son sistemas multiprocesador
simtricos,
SMP). Sin embargo, en
la Play Station 3, las divisiones de los distintos mdulos para su paralelizacin es ms complicada. Una introduccin al problema puede encontrarse en Gabb y Lake (2005), mientras que Mnkknen (2006) propone varias soluciones. Tambin es destacable la aportacin de Rhalibi et al., en la que sugieren por primera vez el uso de grafos de dependencias de tareas para el desarrollo de juegos con ejecucin paralela (Rhalibi et al., 2006). Por ltimo, se puede consultar Turner (2007) como ejemplo real de un planicador de tareas diseado para optimizar el uso de 6 hebras Row (Volition Inc., 2006).
hardware
en el juego Saints

Un juego, o mejor, un entorno virtual gira en torno a la interaccin entre el usuario y el mundo. Debido a esto, podemos decir que existen dos categoras de objetos dentro del entorno: los objetos dinmicos y los estticos. Los objetos estticos son inmutables, y el usuario no puede hacer nada con ellos, excepto verlos y chocarse contra ellos. Ejemplos son muros, rocas, etc. Los objetos dinmicos son aquellos que hacen del entorno un mundo
vivo,
que cambian sus propiedades durante la ejecucin de la aplicacin, ya sea debido a la interaccin del usuario o de otros objetos. En el contexto de los juegos, estos tipos de objetos suelen conocerse como (Plummer, 2004). tambin pueden denominarse objetos de juego (en ingls,
entidades , aunque game objects )
22
Captulo 2.
CBaseEntity
CItem
CBaseDelay
CHealthKit
CBreakable
CBaseAnimating
CBasePlayerItem
CBaseToggle
CBasePlayerWeapon
CBaseDoor
CBaseMonster
CCrowbar
CHandGrenade
CBasePlayer
CHeadCrab
CTalkMonster
CZombie
CBarney
CScientist
Figura 2.4: Jerarqua parcial de los tipos de entidad de Half-Life 1
No existe un consenso en la denicin de lo que es una entidad, pero aqu nos quedaremos con la dada por Llopis (2005b), que la dene como una pieza autocontenida de contenido interactivo. Dada la naturaleza de las entidades, es natural aplicar el paradigma de orientacin a objetos para codicar su comportamiento. De esta forma, es habitual disponer de una jerarqua de clases para representar los distintos tipos de entidades. Por ejemplo, podemos tener la clase hereda una clase
CVehicle, CHuman, CGun, etc. De la clase que representa cualquier avatar, heredaran los distintos
moverse por el entorno. Por debajo de sta, tenemos enemigos y el propio jugador. Como ejemplo real, la gura 2.4 presenta parcialmente la jerarqua de clases utilizada en el Half-Life 1 (Valve Software, 1998). Todas las entidades heredan de otras clases, la clase que representa los objetos que pueden cogerse (items ) que aparecen en el juego (en la prctica, nicamente se implementa la clase
CMoveable,
CEntity,
de la que
que represente a cualquier entidad que puede
CBaseEntity,
de la que parten, entre
CHealthKit).
Tambin aparecen las clases
CBaseDelay
CBaseAnimating
que extienden la funcionalidad bsica de la clase base, aunque an no especican por completo su comportamiento. De la ltima parten ya todos los items que el jugador puede llevar, en particular, todas las armas. Tambin de
CBaseAnimating
hereda
CBaseToggle,
que permite a todas sus subclases
cambiar de estado. Hijas de esta son las puertas y todos los enemigos del juego.
23
Los juegos se convierten en una base de datos de entidades con un interfaz bonito, en la que el sistema de objetos almacena todas las entidades y las gestiona. En el siguiente apartado describimos cmo organizar las entidades teniendo presente su actualizacin. Posteriormente trataremos sobre la construccin de las entidades, y terminaremos el apartado con la explicacin de la arquitectura basada en componentes, la forma de estructurar las entidades u objetos del juego que se est imponiendo en la construccin de videojuegos, y que utilizamos en nuestra arquitectura para el desarrollo de aplicaciones educativas basadas en videojuegos que describimos en el captulo 5.
2.6.1.
Organizacin y actualizacin de entidades
Un videojuego tiene en todo momento una lista de todas las entidades disponibles en el entorno virtual. Dado el carcter variable y voltil de las entidades (se disparan balas, con tiempo de vida muy corto, los enemigos mueren y nacen otros, etc.), resulta mucho ms adecuado almacenarlas en una lista enlazada que en un vector esttico. De esta forma la ejecucin de sus operaciones es mucho ms eciente. La implementacin intuitiva de la fase de actualizacin de la lgica o simulacin del bucle principal que veamos en el apartado 2.5 consiste en recorrer esa lista de entidades y llamar a un mtodo de actualizacin, en el que se cede a la entidad el control de la CPU para que altere sus propiedades. En la prctica, este recorrido lineal es muy ineciente, ya que gran cantidad del tiempo las entidades no tienen que realizar ningn tipo de actividad durante su actualizacin. Mientras tanto, el motor del juego insistir en recorrer todos los elementos de una lista enlazada (con los fallos en la cach de datos que eso provocar) para llamar al cdigo del mtodo cdigo), para encontrarse un simple
update
de la
clase correspondiente (de nuevo provocando fallos de cach, esta vez en la de
return true;.
Para solventar esta ineciencia, los distintos juegos utilizan alternativas diferentes. De esta forma, los juegos de estrategia suelen utilizar un mapa basado en una rejilla, y almacenan por cada uno de sus componentes, las entidades que hay en l. Pritchar (2001) describe cmo utilizar una tcnica similar a esta para un clculo rpido de las entidades que entran dentro del campo de visin del jugador. El gnero de los FPS (rst-person
shooter,
juegos en primera persona en
donde el jugador va con un arma disparando a los enemigos), lo que se hace es dividir todo el espacio en regiones volumtricas, cada una de ellas con la lista de entidades que contiene. Estas regiones se pueden estructurar de dos formas: o bien utilizando portales (Luebke y Georges, 1995), que vienen a ser habitaciones y puertas dentro del entorno virtual, o rboles BSP (Binary Space Partitioning, Particionado binario del espacio), que es una tcnica ms general que la anterior pero ms complicada de implementar (Foley et al.,
24
Captulo 2.
1990; Abrash, 1997). Tambin se pueden utilizar quadtrees y octrees (Finkel y Bentley, 1974), que son tcnicas independientes de la geometra del entorno. En aplicaciones con un gran nmero de entidades, la gestin de cules estn activas y cuales no es de vital importancia, para ahorrar tiempo a la CPU que evita invertir recursos en la actualizacin de aquellas que no lo necesitan. Con el incremento de memoria, hoy por hoy es habitual que la aplicacin maneje varias listas de entidades, para optimizar distintos recorridos. As por ejemplo, puede tener una estructura en portales o un rbol BSP para buscar rpidamente las entidades que aparecen cerca del usuario o para descartar rpidamente las entidades que no hay que dibujar, pero utilizar una cola de prioridad en la que las entidades ms importantes (por cercana al jugador o por relevancia en el juego) aparecen antes, y que es recorrida en la etapa de actualizacin de la lgica. Para ello, se puede utilizar un sistema de tareas con distinta prioridad (McLean, 2002), o para la actualizacin de cada entidad (Dawson, 2001).
micro hebras
manejadas por el propio juego, que cede una cantidad de tiempo limitada
2.6.2.
Construccin de las entidades del juego

new
se
Si tenemos una clase por cada tipo de entidad, la creacin de un objeto de estas entidades es, en principio, tan simple como utilizar el operador de C++ con esa clase. Sin embargo, la informacin sobre qu entidades hay que crear
no
conoce en tiempo de compilacin del juego, sino que se lee de cheros externos (mapas). Por esto, se necesita un mecanismo capaz de crear objetos que representen a entidades a partir de los datos almacenados en disco. Normalmente, el chero almacenar el nombre (o clase) de la entidad y las propiedades de construccin, como la posicin o el modelo 3D. A partir de ella, habr que construir el objeto particular. La alternativa obvia es utilizar el patrn
factora
(Gamma et al., 1995).
Si consideramos como clase base de todas las entidades la clase
CEntity,
el mtodo de creacin de la factora recibira un identicador del tipo de objeto a crear, y devolver un puntero a un objeto de esa clase. La gura 2.5 muestra el cdigo simplicado. Sin embargo, esta aproximacin tiene algunos problemas:
El programador de la clase factora tiene que conocer en el momento de la creacin de la clase, qu objetos se van a poder crear (es decir, estn programadas directamente las entidades que se podrn generar). Aunque esto no parece un problema a primera vista, si tenemos en cuenta la forma de estructurar el cdigo descrita en el apartado 2.4, el cargador del mapa est situado en el
motor del juego, y es independiente
de las entidades especcas del juego en cuestin. Por lo tanto, tener
25
enum EntityType { PLAYER, ENEMY, POWERUP, WEAPON,

};
// . . . Resto de t i p o s de e n t i d a d e s
CEntity CFactoriaEntidades : : Create ( EntityType type ) { switch ( type ) { case PLAYER: return new CPlayer ( ) ; case ENEMY: return new CEnemy ( ) ; case POWERUP: return new CPowerup ( ) ; case WEAPON: return new CWeapon ( ) ; } return NULL;
// . . .
Figura 2.5: Ejemplo sencillo de factora de creacin de entidades
jado el tipo de entidades que vamos a poder crear diculta la adicin posterior de otros objetos. Un problema menor aparece durante el desarrollo del juego, ya que aadir nuevas entidades requiere aadir una nueva entrada al tipo enumerado, y un nuevo caso en la instruccin
switch.
En algunas ocasiones, lo que en el mapa ledo del disco es una entidad, en el cdigo se corresponde con la mera ejecucin de una serie de instrucciones que no necesariamente crean un objeto. Eso es debido a que el conjunto de entidades disponibles a la hora de editar el nivel no tiene por qu coincidir con el que se utiliza para gestionar los objetos del juego. Durante la edicin del nivel existen entidades que nicamente son colocadas para
crear o inicializar
datos en los servicios del motor del
juego, como el sistema de colisiones, o la IA. Por ejemplo, el diseador del nivel puede colocar lo que para l son entidades (y que como tal se graban en el chero del mapa) que indican los nodos del grafo para la bsqueda de caminos. Cuando en tiempo de carga de ese nivel, el juego se encuentra con tales entidades, lo nico que tiene que hacer es aadir la posicin que ocupa esa entidad como vrtice del grafo, sin necesidad de crear ningn objeto CNodoGrafo.
Para resolver el primero de los problemas, se utiliza una
sible.
factora exten-
La idea de esta factora es que permite registrar y deregistrar los tipos de cada una de las clases, indicados a la hora de registrar el
de objetos que es capaz de crear. Para crearlos, delega en los verdaderos
constructores
nuevo tipo de objetos.
26
Captulo 2.
c l a s s CEntity ; c l a s s CConstructorEntidad { public : virtual CEntity Create ( ) ; }; c l a s s CFactoriaEntidades { public :

CEntity Create ( EntityType type ) ; void R e g i s t e r ( CConstructorEntidad c o n s t r u c t o r , EntityType type ) ; void U n r e g i s t e r ( CConstructorEntidad c o n s t r u c t o r ) ;
private : s t d : : map<EntityType , CConstructorEntidad > c o n s t r u c t o r e s ;

};
Figura 2.6: Cdigo C++ de factora extensible
La implementacin hace uso de una tabla hash o diccionario, cuya clave es el identicador o nombre de la clase entidad, y cuyo valor es el mtodo responsable de la verdadera creacin del objeto. Un ejemplo de implementacin, basado en el de Llopis (2005b) aparece en la gura 2.6. Existe una clase que hereda de
CConstructorEntidad por cada
uno de los tipos de entidades disponibles, cada una de ellas creando un objeto de esa clase de la jerarqua. La factora permite registrar y deregistrar los constructores en tiempo de ejecucin. Cuando el cargador del mapa detecta que es necesaria la creacin de una nueva entidad de un tipo dado, utiliza la factora, que le devolver un puntero a la clase base de todas las entidades. En el ejemplo, hemos suprimido intencionadamente la denicin del tipo
EntityType.
En la gura 2.5, se dena como un tipo enumerado. En reali-
dad, se puede utilizar directamente como identicador un entero nico para cada tipo de entidad, o una cadena, de tal forma que no sea necesario centralizar en un nico sitio del proyecto toda la coleccin de identicadores. Para facilitar el registro automtico de todos los tipos de entidades disponibles en el juego, Llopis (2005b) propone hacer uso de la inicializacin esttica de C++, aunque expertos del lenguaje desaconsejan el uso de esta tcnica (Alexandrescu, 2001). Gracias a la factora extensible se evita el problema de tener jado de antemano en el propio cdigo de la factora los tipos de entidades posibles. Sin embargo, no resuelve el segundo de los problemas comentados anteriormente.
27
El cargador del mapa seguir esperando la creacin de un objeto que aadir a la lista de entidades creadas. Es posible, como comentbamos, que lo que en el mapa viene representado como entidad, no requiera un tratamiento especial dentro del cdigo, debido a que sea una simple marca o informacin a aadir a un subsistema (como puede ser un vrtice en el grafo de bsqueda de caminos). En ese caso, el constructor de la entidad que tenamos antes debera simplemente leer la posicin del mapa, y aadir un vrtice/punto al grafo de entidades global. Para poder combinar las dos cosas, una solucin es alterar la factora extensible para que lo que llambamos de la creacin
no
CConstructorEntidad,
en el momento
tenga que devolver una entidad creada a su invocador, sino
simplemente si se pudo gestionar la creacin o no. En caso de que el constructor estime que debe crearse una entidad (objeto de una clase derivada de
CEntity),
registrar esa entidad invocando al sistema gestor de entidades.
Otra alternativa no orientada objetos es hacer que ese constructor no sea un miembro de una clase, sino una mera funcin C. En ese caso, se puede incluso suprimir la existencia de la factora, haciendo uso de la tabla de smbolos del ejecutable proporcionada por el sistema operativo (Richter, 1997; Bilas, 2000). El juego Half-Life 1 (Valve Software, 1998), haca uso de este mecanismo; el motor del juego cargaba una librera dinmica (DLL) que contena toda la parte especca del juego. Esa DLL exportaba una funcin por cada uno de los distintos tipos de entidades que podan encontrarse en el mapa. El cargador del nivel en el motor del juego, al encontrar una entidad, buscaba la misma funcin con ese nombre, haciendo uso del API del sistema operativo subyacente (en este caso Windows). El ltimo paso para hacer por completo independiente el cargador (o intrprete) del chero de mapas contenido en el motor del juego y el propio cdigo del juego es hacer que la construccin de las entidades est en un lenguaje de script (ver apartado 2.7); as est hecho por ejemplo en Far Cry (Crytek Studios, 2004), cuya arquitectura est basada fundamentalmente en el uso de LUA para la implementacin de los comportamientos especcos del juego, dejando a C++ la parte del motor.
2.6.3.
Arquitectura basada en componentes
El diseo de las entidades basndose en el mecanismo de herencia es muy intuitivo. Sin embargo, existen una serie de problemas que estn provocando un cambio en su forma de programacin: Descomposicin: existen innidad de formas de descomponer el sistema de objetos de un juego, utilizando distintas clasicaciones. El problema, ya de por s complicado, de decidir qu clasicacin es ms adecuada se ve acrecentado con la naturaleza cambiante del juego. Los diseadores de contenido, segn avanza el desarrollo, van tomando decisiones que,
28
Captulo 2.
de haber sido conocidas al principio, habran llevado a estructurar la jerarqua de otra forma. Cdigo poco exible: enlazado con los comentarios anteriores, una jerarqua de clases es muy complicada de cambiar. Por lo tanto, ante apariciones de nuevos tipos de entidades no planicados, la solucin adoptada suele ser el uso de una sola clase para entidades parecidas pero distintas, la sobrecarga de mtodos que un buen diseo nunca habra permitido, etc. Clases base grandes: segn van creciendo las clases (y entidades) del juego, la jerarqua se hace ms grande. En muchas ocasiones, los programadores se encuentran con que la funcionalidad que necesitan para una clase profunda en la jerarqua, ya ha sido implementada en otra clase hermana. Pensemos, por ejemplo, en la jerarqua parcial del HalfLife 1 presentada en la gura 2.4: segn la jerarqua, no parece fcil conseguir que una puerta (CBaseDoor) pueda romperse (CBreakable). Para conseguirlo, lo ms fcil es
copiar
el cdigo de la ltima en la
primera, para proporcionarle esas caractersticas. Dado que la duplicacin no es conveniente, para evitarla, la tendencia natural es
subir
esa funcionalidad a la primera clase padre comn. Con el tiempo, eso provoca que las clases superiores de la jerarqua se llenen de mtodos que no son utilizados por todas las clases descendientes, sino slo por algunas. Como ejemplo, podemos nombrar la clase base de las entidades en el Half-Life 1, que tena 87 mtodos y 20 atributos pblicos, y la de los Sims que termin con ms de 100 funciones (Brock, 2006). A pesar de que el programador intente estructurar los cheros de denicin por subsecciones agrupando funciones relacionadas, el resultado sigue siendo cheros grandes difciles de manejar. Clases difciles de entender: para conseguir entender el comportamiento de una clase, el programador tiene irremediablemente que comprender primero las clases de toda la lnea sucesoria desde la clase base. Extensin del comportamiento: en una jerarqua como la de las entidades, es muy habitual que las clases derivadas no se limiten a
bir el comportamiento de una serie de mtodos heredados, sino que lo extiendan. Eso, irremediablemente, pasa por invocar en algn momento de la implementacin del mtodo al mismo mtodo de la clase padre.
sobreescri-
Dado que el lenguaje no proporciona ningn mecanismo para obligar al programador de la clase hija llamar recursivamente a la implementacin de la padre, se presta mucho a olvidos nicamente detectables a travs de la depuracin. Una solucin posible es utilizar el patrn Template Method (Gamma et al., 1995), pero en la prctica, dado que la jerarqua suele ser profunda y que el nmero de mtodos por clase
29
que lo requeriran es grande, utilizarlo en todos ellos supondra una sobrecarga de nombres difcil de justicar. Aparicin de herencia en diamante: la jerarqua de clases al n y al cabo es una clasicacin de las entidades utilizando un cierto criterio. En ocasiones surgen entidades que, por su naturaleza, deben formar parte de dos o ms categoras. La implementacin obvia es hacer que la nueva clase herede de
las dos
categoras, implementando la herencia en
diamante. Para implementarla, se utiliza la herencia
virtual
disponible
en C++ pero que es en general mal entendida por los programadores, introduce ineciencias (Lippman, 1996) y acarrea problemas relacionados con la herencia mltiple (Meyers, 1997, Item 43). Mayor tiempo de compilacin: la herencia es uno de los mecanismos de C++ que provocan mayor acoplamiento entre clases, no slo desde el punto de vista lgico, sino tambin fsico. Este ltimo tipo de acoplamiento es el que obliga al compilador a tener que procesar todos los cheros de cabecera de las clases padre, y al enlazador acceder a todos los cheros objeto para resolver las dependencias. Eso provoca un aumento signicativo del tiempo de generacin del ejecutable nal (Lakos, 1996). Una solucin es dividir la entidad en un conjunto de funcionalidades independientes que se separan en distintas clases. La entidad u objeto del juego pasa as a ser un mero
contenedor de punteros
a esas clases, como por ejem-
plos las que gestionan el objeto grco de la entidad, el objeto fsico, el emisor de sonido o el controlador de su lgica (o inteligencia articial). Para poder comunicar cada una de estas clases, existen dos alternativas principales: Que cada una de las clases que implementan la funcionalidad pueda tener un puntero al resto de clases con las que se tiene que comunicar. Por ejemplo, la inteligencia articial establecer distintas fuerzas en el objeto fsico, por lo tanto tendr internamente un puntero a l. De acuerdo con la simulacin fsica, sta actualizar la posicin en la que el objeto grco tendr que dibujar el modelo, por lo que el primero tendr un puntero al segundo. Utilizar un sistema de mensajes genrico, de tal forma que uno de los objetos pueda enviar mensajes al resto de ellos informando, por ejemplo, de un cambio en la posicin de la entidad. La creacin de una entidad pasa a convertirse en la creacin e inicializacin de los objetos que implementan las distintas funcionalidades que forman la entidad. Si una entidad no necesita alguna de la funcionalidad (como por ejemplo el emisor de sonido), ese puntero apuntar a
NULL.
30
Captulo 2.
La composicin viene a evitar un problema asociado con la centralizacin de todos los objetos del juego en una nica clase. Como ya hemos dicho en la seccin 2.3.1, hoy da la industria del videojuego est basada en componentes (o libreras) comprados a terceros. Dado que la gran mayora de estas libreras son utilizadas desde las entidades, sus programadores necesitan tener un gran dominio de las mismas. La descomposicin de la entidad en funcionalidades disjuntas permite tambin la especializacin de los programadores, de forma que nicamente los responsables de la programacin de una funcionalidad determinada deber conocer a la perfeccin la librera correspondiente. La generalizacin del mtodo de composicin consiste en hacer que todas las clases que implementan las distintas funcionalidades, misma clase comn, que representa un un
componente
hereden
de una
genrico. La clase que
representa la entidad, en vez de tener una serie de punteros como antes, es
contenedor de componentes genricos
(West, 2006). La denicin de una
entidad consiste en listar de qu componentes estar formada, y cmo congurarlos. La ventaja adicional es que esos componentes se pueden enganchar y desenganchar de la entidad dinmicamente, dependiendo del momento del juego. Por ejemplo, una entidad que representa un vehculo contiene los componentes necesarios para representar una simple entidad esttica, que pasa a representar al jugador (cambiando todos los componentes necesarios) cuando su avatar se sube en l. El modelo de componentes tiene dos ventajas adicionales: permite almacenar todos los componentes del mismo tipo consecutivos en memoria, lo que agiliza sus recorridos, y la divisin hace que sea ms fcil manejar diferentes hebras, cada una encargndose de una funcionalidad particular. El estilo de agregacin
puro
es llevar la idea an ms lejos, y eliminar la
necesidad de una clase que represente la entidad. En la gura 2.7, aparece la estructura en memoria de uno de estos sistemas. Cada entidad se convierte en la suma de los componentes cuyo identicador coincide. Existe un gestor para cada uno de los tipos de componente, que guarda una lista con cada uno de esos componentes, para poder actualizarlos en cada vuelta del bucle. El modelo de componentes puro permite tener las entidades almacenadas en una base de datos
10 . Cada entidad est distribuida en varias tablas,
una para guardar la informacin relacionada con las colisiones, otra con los componentes de IA, una tabla para los modelos, etc. Para terminar, el uso de un modelo basado en componentes permite la creacin de las entidades dirigida por datos. Cada tipo de entidad viene denido por la lista de componentes que son utilizados por ella, parametrizados con sus valores de inicializacin. Eso permite almacenar en bases de
10
Por ejemplo, algunos de los juegos de Electronic Arts ya llevan integrado un sistema
de base de datos (Brock, 2006), y el framework Mangalore montado sobre Nebula 2 utiliza SQLlite para guardar las entidades.
2.7. Lenguajes de script
31
Gestor de componentes Posicion Movimiento Grfico Script Objetivo Fsica
Jugador Alien Solo script Granada
Figura 2.7: Estructura de objetos utilizando componentes (West, 2006)
datos o cheros XML (eXtensible
Markup Language,
Lenguaje extensible de
marcado) la mayor parte de los datos de creacin necesarios (Garcs, 2006).

La evolucin de los juegos dirigidos por datos que guardan en cheros todos los recursos grcos fue sacar fuera del ejecutable parte del comportamiento del juego. Ya hemos visto en el apartado 2.4 que una alternativa es dividir el juego en dos partes, el
motor de juego
y el
cdigo especco.
Fijando una comunicacin entre ambos componentes, se consigue separarlos de tal manera que la parte especca puede ir en una librera de vinculacin dinmica (DLL). De esta forma, el equipo de desarrollo puede estructurarse ms fcilmente, se reducen las
restricciones fsicas
entre partes del cdigo
fuente (Lakos, 1996), lo que reduce los tiempos de compilacin y enlazado, y se permite la posterior modicacin de parte del juego, ya sea por parte del propio estudio de desarrollo, o por acionados. El uso de lenguajes de script va un paso ms all. En vez de sacar el cdigo especco del juego utilizando libreras dinmicas, se saca
cdigo.
El motor del juego se convierte as en un
intrprete
el propio
del lenguaje de
script particular, y lo invoca cuando lo necesita. Dependiendo del juego, el uso del lenguaje de script ser ms o menos anecdtico. Por ejemplo, algunos juegos lo pueden utilizar nicamente para el control de escenas entre niveles o lanzamiento de algn comportamiento predenido, mientras que otros implementan toda su lgica y comportamiento utilizndolos. La decisin de dnde poner la frontera entre el motor del juego y los
32
Captulo 2.
scripts es importante, y afecta al API resultante entre ambas partes y al rendimiento del juego. Como veremos en el apartado 2.7.1, una de las desventajas de los lenguajes de scripts es que su ejecucin es ms lenta que la del cdigo compilado. Por lo tanto, si se delega mucha funcionalidad en el lenguaje de script, se corre el riesgo de ralentizar demasiado el juego. Si, por el contrario, se cede muy poco control al script, se van perdiendo todas las ventajas, ya que muy poco cdigo podr aprovecharse ellas. Desde el punto de vista arquitectnico, el cdigo que maneja un personaje no jugador (en ingls
non-player character, NPC) era lo ltimo que quedaba
dentro del ejecutable, al haber sacado fuera tanto su modelo y animaciones como las texturas. Por lo tanto, con este ltimo paso se consigue una entidad completamente dirigida por datos, que puede empaquetarse en un nico chero y distribuirlo independientemente del juego. Es la idea que utilizan, por ejemplo en Los Sims, donde los objetos que aparecen en las extensiones no son ms que cheros de datos que contienen tanto los modelos de esos objetos como su comportamiento.
2.7.1.
Ventajas y desventajas de los lenguajes de script
Una de las principales ventajas de los lenguajes de script es que se reduce signicativamente el tiempo del ciclo de desarrollo editar - compilar - enlazar - ejecutar. Esto es debido a que normalmente un cambio de un chero de script no requiere la compilacin del cdigo del juego y su enlazado con todas las libreras, sino que basta con un simple volcado a disco del cambio. De esta forma, el ciclo que puede durar ms de dos minutos en el primer caso se reduce a unos segundos en el ltimo. Algunos motores de juegos estn incluso preparados para
recargar
el script al vuelo (o en
caliente ),
de tal
forma que no es necesario parar el juego y volverlo a lanzar. Esta reduccin en el tiempo de ciclo es posible debido a que normalmente el lenguaje de script es
interpretado, es decir, durante la ejecucin del juego, el compilado.
chero se analiza y se ejecutan sus instrucciones interpretndolas una a una. Eso trae consigo una de las desventajas principales de este tipo de lenguajes: su ejecucin es mucho ms lenta que la un lenguaje En general, un lenguaje de script interpretado no puede competir en rendimiento con el binario creado a partir del cdigo en C++. Por eso debe elegirse con cuidado qu partes del juego van a ser programadas utilizando scripts; normalmente sern aquellas que denen el comportamiento de alto nivel, y que por lo tanto no necesitan ejecutarse a menudo
11 .
Otra causa del menor rendimiento del cdigo de scripts es que los lenguajes poseen caractersticas avanzadas que suponen un consumo de CPU para su control. Por ejemplo, la recoleccin de basura, muy habitual en este
11
Con
a menudo ,
nos estamos reriendo a una frecuencia de una o ms veces por
fotograma.
33
tipo de lenguajes, hace que el motor de scripts dedique parte de su tiempo a su gestin. Sin embargo, estas caractersticas avanzadas disponibles en los lenguajes de script y que no estn en C++ son tambin una ventaja, ya que facilitan el desarrollo, reduciendo signicativamente la duracin del proyecto, y por tanto, pueden ser un punto decisivo a la hora de seleccionar uno u otro lenguaje. Si el desarrollo con lenguajes de scripts es lo sucientemente fcil, aparece otra ventaja ms: los propios diseadores o creadores de contenidos del juego pueden modicarlos para cambiar parte del comportamiento.
2.7.2.
Ejemplos de lenguajes de script

shells ),
como
Existen muchos lenguajes de script, desde los utilizados por los intrpretes de comandos (o
sh
csh
a los utilizados en la creacin de
pginas Web como JavaScript, pasando por los que sirven para procesado de textos, como awk o Perl. En el rea que tratamos, sin embargo, de todo el conjunto de lenguajes nos interesan nicamente aquellos que pueden ser incrustados en aplicaciones husped hechas en C/C++. El programador de la aplicacin tiene a su disposicin un
motor de scripts
que es capaz de interpretar ese lenguaje.
Adems, es posible hacer pblica parte de la funcionalidad implementada en la aplicacin en el lenguaje de script y viceversa. De esa forma, el cdigo del script puede llamar a funciones implementadas en C++ y viceversa. An con estas condiciones, el nmero de lenguajes disponibles es elevado. A la hora de decantarse por uno u otro lenguaje, hay que tener en cuenta, al menos las siguientes cuestiones: Caractersticas del lenguaje: dependiendo del uso que se le vaya a dar, se buscarn unas u otras. Habr que plantearse si se quiere un lenguaje de propsito general que sustituya a C++ en la implementacin del cdigo especco del juego, o uno con caractersticas especializadas para, por ejemplo, crear el interfaz del usuario o las animaciones de los personajes. En cualquier caso, tambin es posible que el juego integre distintos motores de scripts para poder soportar ms de un lenguaje. Rendimiento: tambin ligado al uso que se le vaya a dar al lenguaje, se podr pagar ms o menos precio en el rendimiento en tiempo de ejecucin. Si los scripts se van a utilizar nicamente para el sistema de mens, se podr optar por un lenguaje ms lento pero con caractersticas ms avanzadas que lo hagan una mejor herramienta de programacin. En general, el nmero de caractersticas que tiene un lenguaje es inversamente proporcional con su rendimiento. Plataforma: no todos los lenguajes de scripts estn disponibles para todas las plataformas. Si un estudio desarrolla para una plataforma es-
34
Captulo 2.
pecca, tendr que asegurarse que el lenguaje de script est disponible para ella; esto es especialmente importante cuando se desarrolla para consolas. Soporte: hoy por hoy los entornos integrados de desarrollo (IDE) para C++ son los sucientemente avanzados como para permitir una programacin y depuracin cmoda. Sin embargo, esto puede no ser cierto en el lenguaje de script elegido. Si el nmero de lneas que se programarn en l es elevado, hay que tener en cuenta si su escritura y depuracin va a resultar fcil o no, y si no lo es (especialmente la depuracin), cunto cuesta crear un sistema que lo haga sencillo. Hoy por hoy, el lenguaje de Script ms utilizado es LUA (Ierusalimschy et al., 2006). El lenguaje fue desarrollado con unos objetivos claros que encajan con los requisitos de un videojuego: simplicidad en el lenguaje, eciencia en la ejecucin, portabilidad y capacidad de ser
incrustado
en otras apli-
caciones con bajo coste de memoria (Ierusalimschy et al., 2005). Otras dos caractersticas no menos importantes son su licencia, que permite el uso del motor de scripts en cualquier desarrollo ya sea comercial o no, y las corutinas (de Figueiredo et al., 2006). Desde el principio LUA ha permitido una doble vertiente: el motor de scripts puede interpretar directamente cdigo LUA, o ste puede
12 a una mquina virtual, e interpretar ese cdigo compilado . De esta forma,

durante el desarrollo se puede utilizar el cdigo LUA directamente, para reducir el tiempo del ciclo editar - compilar - enlazar - ejecutar, y en la versin nal, los scripts pueden distribuirse compilados para mejorar la eciencia y mantener el cdigo oculto. La llegada de LUA al mundo de los videojuegos se produjo en 1998, de la mano de Grim Fandango de LucasArts, con el que el estudio abandon el sistema de scripts SCUMM que llevaban utilizando durante muchos aos. Desde l, le han seguido una lista interminable de juegos, entre los que destacan, adems de las aventuras desarrolladas posteriormente por LucasArts, otros juegos como Baldur's Gate de Bioware o Far Cry de Crytek. Otro lenguaje de propsito general utilizado en algunos juegos es Python (van Rossum, 2006). Su sintxis clara y sencilla, similar a la de C hacen de l un lenguaje fcil de aprender. El nmero de libreras disponibles hacen de Python un lenguaje potente y funcional, a lo que se le suma sus capacidades de orientacin a objetos, su licencia y su amplio soporte tanto en documentacin y tutoriales como en herramientas de depuracin. Su principal desventaja es su alto consumo de memoria, sobre todo teniendo en cuenta los entornos limitados que suponen las consolas. Por eso, la mayora
compilarse
12
Desde la versin 5.0 de LUA, esa mquina virtual ha sufrido cambios signicativos,
y se ha convertido en una mquina basada en registros, en vez de basada en una pila de operandos, por lo que, aseguran sus autores, la ejecucin del cdigo LUA es ms rpida.
35
Figura 2.8: Captura del juego Don Quijote (Dinamic, 1987)
de los juegos que utilizan Python estn disponibles nicamente en PC, como el Civilization IV. Por ltimo, nombraremos el caso de Java, un lenguaje de propsito general que, no obstante, puede utilizarse como lenguaje de script. En el apartado 2.7.3.4 veremos un ejemplo concreto de juego que lo hace. Si ninguno de los lenguajes de script disponibles se amolda a las necesidades del estudio, la ltima alternativa es desarrollar uno propio. Esta decisin hay que tomarla con cautela, ya que la implementacin de un analizador e intrprete eciente entra dentro del rea de los compiladores (de hecho, es una de las razones que llevaron a LucasArts a utilizar LUA, una vez decidieron abandonar SCUMM). An as, hay varios juegos que utilizan lenguajes especialmente diseados para ellos. La ventaja de esta aproximacin es que se puede crear un lenguaje dedicado, con caractersticas que no se encuentran en los lenguajes de propsito general, pero que facilitan la creacin de los scripts del juego. Veremos un ejemplo de esto en el apartado 2.7.3.3.
2.7.3.
Casos de uso
Los siguientes apartados describen algunos de los casos ms signicativos del uso de lenguajes de scripts en juegos.
2.7.3.1. Zork
Zork fue uno de los primeros juegos de lo que despus se vino a llamar ccin
interactiva , por lo que se le puede considerar el padre o abuelo de los
llamados juegos conversacionales (como el Don Quijote (Dinamic, 1987), que puede verse en la gura 2.8) y de las aventuras grcas (como Grim Fandango, ver apartado 2.7.3.2). En sus orgenes, estos juegos se basaban en una descripcin textual de una situacin, y una interaccin a base de texto
36
Captulo 2.
(rdenes muy sencillas), para moverse y operar sobre el entorno. Lo peculiar de este juego es el modo en que estaba implementado. Las primeras versiones (all por 1971), hacan uso de lenguajes de implementacin parecidos a Lisp. Con el incremento por parte del pblico de su inters, sus creadores formaron una empresa para explotar el xito, que convirti
serie con numerosas aventuras. En 1979, desarrollaron una mquina virtual, llamada mquina-Z , creada expresamente para facilitar la
a Zork en una programacin de aventuras textuales. La mquina virtual interpretaba instrucciones extradas del chero de historia, o chero-Z, independiente de la plataforma en la que se ejecutaba la mquina virtual. De esta forma, se convirtieron en los primeros en separar la lgica del juego (contenida en esos cheros) del propio motor, creando juegos dirigidos por datos. Eso les permiti llegar a un gran nmero de plataformas, simplemente implementando la mquina-Z para todas ellas. Para facilitar la programacin de cada una de las historias interactivas, utilizaron un lenguaje de ms alto nivel que el interpretado por la mquina virtual, conocido como ZIL (Infocom, 1989), acrnimo de
tation Language.
Zork Implemen-
Si bien el compilador nunca fue liberado por la compaa,
posteriormente un amante de las historias interactivas dise e implement un lenguaje distinto llamado Inform (Nelson, 2001), cuyo compilador genera instrucciones para la mquina-Z, haciendo posible an hoy escribir aventuras textuales nuevas utilizando un lenguaje de alto nivel. Por poner un ejemplo concreto de un juego de ccin interactiva, podemos pensar en la forma de implementar el juego espaol Don Quijote (Dinamic, 1987) desarrollado para distintos ordenadores de 8 bits. La gura 2.8 muestra una captura de un momento del juego. Una alternativa de programacin sera incrustar toda la lgica en el propio cdigo, mientras que la otra es utilizar una mquina-Z o un intrprete de un lenguaje de script especialmente diseado para la ccin interactiva, que permita denir toda la lgica de manera independiente al motor del juego que la lee, analiza e interpreta. La gura 2.9 muestra cmo podra ser el cdigo de ambas alternativas: la primera de ellas en BASIC, y la segunda utilizando Inform 6 (Nelson, 2001).
2.7.3.2. Grim Fandango

Grim Fandango (LucasArts, 1998) de LucasArts fue el primer juego en utilizar LUA. Despus de usar su sistema de scripts propietario llamado SCUMM desde 1988, la primera idea en el desarrollo de Grim Fandango era extender el sistema para soportar personajes en 3D. Al principio del desarrollo, se hizo evidente que el paso a las tres dimensiones era demasiado complicado utilizando la base de cdigo antigua, y Bret Mogilefsky, el programador jefe, decidi empezar un nuevo motor de
37
1000 REM S a l a de l a b i b l i o t e c a 1010 GOSUB 1200 ' Dibujar l a b i b l i o t e c a 1010 PRINT " Los l i b r o s p o l v o r i e n t o s d e s t a c a n en una" 1020 PRINT " e s t a n t e r i a s i t u a d a h a c i a a l a i z q u i e r d a . " 1030 PRINT "Una puerta abre e l camino h a c i a e l s u r . " 1040 PRINT "Tambien puedes o b s e r v a r que hay un" 1050 PRINT " l i b r o " 1060 GOSUB 5000 ' Leer entrada 1070 IF entrada$="INVENTARIO" OR entrada$="I " OR entrada$="INV" THEN GOSUB 6 0 0 0 : GOTO 1000 1080 IF entrada$="LEER LIBRO" AND NOT l i b r o Y a L e i d o THEN PRINT "Empieza l a aventura " : l i b r o Y a L e i d o = 1 : GOTO 1000 1090 IF entrada$="IR AL SUR" OR entrada$="SUR" GOTO 1500
a) Fragmento de cdigo en BASIC
! D e s c r i p c i o n de l a b i b l i o t e c a Room b i b l i o t e c a " B i b l i o t e c a de Alonso Quijada " with d e s c r i p t i o n [ ; p r i n t " Los l i b r o s p o l v o r i e n t o s d e s t a c a n en una e s t a n t e r i a s i t u a d a h a c i a a l a i z q u i e r d a . Una puerta abre e l camino h a c i a e l s u r . Tambien puedes o b s e r v a r que hay un l i b r o " ; ] s_to h a b i t a c i o n A l o n s o Q u i j a d a [.....] ! D e s c r i p c i n de l a h a b i t a c i n Room h a b i t a c i o n A l o n s o Q u i j a d a " H a b i t a c i n de Alonso Quijada " with d e s c r i p t i o n [ ; [.....]
b) Fragmento de cdigo en Inform Figura 2.9: Cdigo posible para el juego Don Quijote
aventuras grcas completamente nuevo. Fue as como se vio enfrentado a la decisin de elegir un nuevo lenguaje de scripts para manejar la funcionalidad del motor. El resultado nal fue un nuevo sistema para crear aventuras grcas, llamado GrimE. En la prctica, GrimE no sabe nada de las dinmicas que se utilizan en las aventuras grcas, ya que toda su lgica est fuera del motor, programada en LUA. El motor nicamente proporciona primitivas para cargar escenarios, personajes, escribir texto y grcos primitivos, y alguna otra funcin relacionada con la reproduccin de animaciones y bsqueda de caminos. Por poner algn ejemplo, algunas funciones que se hacen pblicas en LUA son
TurnActorTo, StopActorChore
CanActorSee.
Por lo tanto, como el propio Bret reconoce (Mogilefsky, 1999), gran parte
38
Captulo 2.
del juego est hecho en LUA. Haciendo un anlisis utilizando una versin modicada de Residual
13 , de los 14.894 cheros empaquetados en 1'2Gb de
datos que se utilizan en Grim Fandango, 783 corresponden con guiones LUA (compilados), que suman algo ms de 2 megabytes.
Hay que hacer notar que, al contrario de lo que ocurre con otros lenguajes de script, la evolucin de LUA est en ocasiones guiada por los propios desarrolladores de juegos (Ierusalimschy et al., 2007). Cuando se inici el proyecto de Grim Fandango, LUA estaba en la versin 2.5, y careca de muchas funcionalidades deseables para una programacin de juegos cmoda. Una de esas caractersticas era el nulo soporte para la multitarea. Es por esto que el equipo de desarrollo extendi el intrprete para soportar una especie de multitarea colaborativa que permita que cada personaje tuviera una especie de hebra que ejecutaba su comportamiento. Durante el propio desarrollo, y ante un cambio de versin en LUA, este cambio lo migraron a la versin 3.1. Estas extensiones que fueron haciendo en paralelo varios estudios y permanecan bajo secreto industrial era ampliamente demandada por toda la comunidad de usuarios de LUA, y nalmente en la versin 5.0 de 2003 se aadi la capacidad de gestionar
corutinas
de manera nativa en el
lenguaje, como un mtodo de multitarea cooperativa. La versin 5.1 tambin incorpor otra caracterstica demandada por los desarrolladores de juegos: un recolector de basura incremental, que evita las paradas temporales de todo el motor de script que se producan cuando ste empezaba a actuar.
2.7.3.3. Unreal Tournament

Unreal Tournament (Epic Games, 1999) es una serie de juegos FPS que comenz en 1999, y que an sigue en la actualidad. El motor grco que utilizan es uno de sus puntos fuertes articial sosticada. El juego permite tanto el modo de un solo jugador como el multijugador en red. Adems, su estructura facilita a los acionados la modicacin del juego, creando nuevos escenarios, objetos y personajes. La caracterstica ms destacable es que el comportamiento de estos personajes est programado utilizando un lenguaje de scripts. En este caso, despus de un anlisis cuidadoso de los lenguajes existentes (en el que analizaron por ejemplo Java y alguna versin de VisualBasic), el equipo de desarrollo termin creando un lenguaje propio, conocido como et al., 2004). El lenguaje opera a alto nivel, y soporta de forma nativa el tiempo y la red. Igual que en Java, no utiliza punteros, tiene recoleccin automtica
14 , al que se le suma una inteligencia
UnrealScript
(Sweeney
13 14
http://www.scummvm.org
De hecho, Epic, la empresa que desarrolla el juego, licencia el motor a otros estudios.
39
de basura, no soporta herencia mltiple y es fuertemente tipado. Tambin existe una clase base de todas las clases, llamada
Object.
Lo ms destacable del lenguaje es la forma en que est diseado para una fcil integracin en el proceso de desarrollo del juego, y su caracterstica para facilitar la programacin de mquinas de estados. Con respecto a lo primero, cabe mencionar tres aspectos: En la propia denicin de las clases, que implementan el comportamiento de una entidad/NPC, se pueden marcar qu atributos podrn modicarse o establecerse desde el editor de niveles del juego (UnrealEd). Cuando el diseador del nivel coloca una entidad, el editor mira el cdigo fuente asociado (programado en UnrealScript), y presenta un interfaz construido expresamente para esa clase, que permite cambiar todos sus atributos publicados al editor. Adems de las clases abstractas y nativas (aquellas cuyos mtodos son implementados por el motor en C++), existe un tipo especial de clase que no est disponible en lenguajes de propsito general, llamadas clases temporales. Estas clases son gestionadas por el mdulo de persistencia del motor de manera especial, de tal forma que cuando hay que llevar a disco el estado del juego, las ignora. Los atributos
const
declarados en las clases no indican, pese a lo que el atributo no cambia,
podra parecer, que esos atributos no cambian a lo largo de la vida del objeto, sino que
desde el cdigo del UnrealScript
es decir que son de slo lectura. Su valor es actualizado por el motor del juego; por lo tanto, su signicado es similar a lo que sera en C++ una variable con los modicadores
volatile const.
No obstante, la caracterstica ms importante del lenguaje, que no aparece en los lenguajes de programacin de propsito general, es su soporte nativo para la programacin de mquinas de estados. Las mquinas de estados son una de las tcnicas preferidas para la creacin de comportamientos de los NPC (Dybsand, 2002; Houlette y Fu, 2004; Rosado, 2004), por lo que el soporte nativo representa una ventaja. Cada clase de UnrealScript que representa a una entidad, implementa una serie de mtodos que determinan las acciones que la entidad realiza ante unos determinados eventos. Lo normal a la hora de programar la IA es que ese comportamiento dependa del estado del NPC (si se est atacando o vagando por el entorno, etc.). En vez de utilizar la instruccin
switch
en todos esos
mtodos, UnrealScript permite en cada clase la denicin de estados. Un estado no es ms que una agrupacin de mtodos que implementan las acciones a realizar en cada evento, de tal forma que un objeto puede tener activo un nico estado. El lenguaje permite herencia entre estados, igual que
40
Captulo 2.
void CEntity : : FindCover ( ) { v e c t o r 3 nearCover ;

nearCover = findNearCover ( g e t P o s i t i o n ( ) ) ; } moveTo ( nearCover ) ;
Figura 2.10: Pseudo-cdigo de un comportamiento en busca de cobertura
permite herencia entre clases normales, lo que facilita mucho su programacin, evitando repeticin de cdigo en estados que denen comportamientos parecidos. Una ventaja fundamental de tener soporte nativo de estados y mquinas de estados en el propio lenguaje es que la invocacin de los mtodos es consciente de la existencia de estos estados. De esta forma, cuando el motor invoca un mtodo de una entidad, para informar sobre la ocurrencia de un cierto evento, el mecanismo de invocacin realiza las siguientes acciones: Si el objeto (entidad invocada) tiene activo un estado actual:
Si el estado tiene un mtodo con ese nombre, se invoca, si no, si algn antecesor del estado (clases padre de la clase que dene el estado) tiene un mtodo con ese nombre, se invoca el ms especco.
Si el objeto no tiene un estado actual, o la fase anterior no encontr ningn mtodo vlido:
Si la clase tiene un mtodo con ese nombre, se invoca, si no, se busca en las clase padre, utilizando el mecanismo tradicional en orientacin a objetos.
Por ltimo, soluciona de forma elegante un problema comn cuando se utilizan scripts en lenguajes de programacin: la ejecucin de funciones que duran ms de un
frame
(acciones no instantneas). El problema se da, por
ejemplo, cuando queremos hacer que una entidad se esconda detrs de una
cobertura. El pseudo-cdigo sera parecido al que muestra la gura 2.10. La funcin moveTo recibe la posicin a la que se debe mover la entidad, calcula
la ruta para salvar los obstculos y la hace andar por ella hasta el nal. Dado que la funcin utiliza varios ciclos de juego (o vueltas al bucle principal) para ejecutarse, el mtodo bloqueara por completo el sistema. En UnrealScript han solucionado el problema por medio de lo que llaman
funciones latentes, que son funciones especiales que hace pblicas el motor y
41
cuya ejecucin puede requerir ms de un
frame.
El motor de scripts
bloquea
automticamente la ejecucin de la funcin, almacenando internamente su estado, mientras el motor ejecuta la funcin latente
moveTo.
Cuando sta
termina su ejecucin, automticamente el motor de scripts reanuda la ejecucin del mtodo. De esta forma, el cdigo del script puede tener una sucesin de funciones latentes fciles de entender y programar.
2.7.3.4. Vampire Masquerade Redemption

La peculiaridad del Vampire (Nihilistic-Software, 2000) es que su sistema de scripts est implementado en Java, un lenguaje que en principio no tiene las caractersticas ms adecuadas para ser utilizado como lenguaje de script. El equipo de desarrollo despus de haber terminado otro proyecto en donde implementaron su propio lenguaje de script, decidieron no caer en el mismo error de perder meses de desarrolladores programando y arreglando errores del sistema de scripts, por lo que hicieron un anlisis de los lenguajes existentes y se decantaron por Java. El resultado nal fue un motor de juego con unas 300.000 lneas de cdigo, y un conjunto de scripts en Java que sumaban otras 66.000 (Huebner, 2000). Para utilizar Java como lenguaje de script, aprovecharon el interfaz estndar de Sun que permite la comunicacin entre aplicaciones de Java y libreras nativas, llamado JNI (Liang, 1999). Aunque el cometido original de JNI (Java
Native Interface )
era permitir que las aplicaciones Java llamaran
a libreras desarrolladas en otro lenguaje, en este caso, el uso que le dieron fue el inverso: llamar a Java desde el motor en C++
15 .
Segn Huebner (1999), cada una de las entidades controladas por el sistema de script estaba implementada como una clase Java independiente. El motor, al leer los datos del mapa y detectar las entidades, iba cargando cada una de esas clases. Utilizando el sistema de (mirando qu mtodos implementa). El mismo RTTI es utilizado por el propio editor de niveles, para presentar al diseador las opciones precisas dependiendo del tipo de entidad que est editando. No obstante, en ese caso, dado que RTTI no permite extraer el
introspeccin
o RTTI de
Java (Eckel, 2003), detectan a qu tipos de eventos es capaz de reaccionar
nombre
de los parmetros de los mtodos (ya que se pierde en la compi-
lacin), para poder indicar las cadenas que el editor presenta al diseador, permiten al programador de la clase la creacin de atributos estticos bajo unas determinadas condiciones, que el editor leer para presentar al usuario. Por ejemplo, el editor de niveles permite al diseador indicar los parmetros que se pasarn al
constructor de la clase
que gobierna la entidad aadida.
Utilizando RTTI, lo nico que el editor podra presentar sera el nmero de
15
Como veremos en el captulo 6, nuestro sistema utiliza la misma tcnica. Puede en-
contrarse una explicacin detallada en el apndice B.
42
Captulo 2.
parmetros y su tipo. Para mejorarlo, el programador de la clase puede crear un vector de cadenas como atributo esttico, en el que se guarda una cadena por cada parmetro, almacenando su descripcin y su valor por defecto. Dado que Java carga las clases cuando se necesitan y activa el recolector de basura cuando queda poca memoria, es posible que el uso de CPU por parte de la mquina virtual presente picos inesperados que haga que el juego sufra parones espordicos. Para evitar eso, en Vampire forzaban la carga de todas las clases en el momento de la carga del nivel, y utilizaban referencias globales a todos los objetos, de tal forma que el recolector de basura no tuviera nada que liberar en ningn momento. En periodos de baja actividad del juego, liberaban las referencias de los objetos no utilizados, e invocaban manualmente al recolector de basura. De esta forma, minimizaban al mximo su impacto negativo.
2.7.3.5. Far Cry

Far Cry (Crytek Studios, 2004) es un FPS en el que el jugador se ve inmerso en una isla paradisiaca, enfrentndose a numerosos peligros. El juego puede ser jugado tanto por un nico usuario, como por varios a travs de una red. La arquitectura de Far Cry est desarrollada pensando en la fcil modicacin por parte de acionados y profesionales, mediante un editor de niveles disponible con la propia versin del juego, y un conjunto de cheros de cdigo fuente descargables y empaquetados en un kit de desarrollo (SDK). La caracterstica de Far Cry que nos interesa aqu es que hace un uso intensivo de LUA como lenguaje de script. En particular, el juego utiliza hasta 670 archivos distintos que suman un total de casi 4'6Mb de cdigo fuente
16 .
LUA est perfectamente integrado en el editor de niveles, llamado Cry Engine Sandbox (Crytek, 2004). La integracin llega hasta tal punto que ste permite editar algunos de los scripts que denen el comportamiento de las entidades, y recargarlos sin tener que reiniciar. Sin embargo, dado que LUA es un lenguaje de script de propsito general y a diferencia de lo que ocurra en el caso del Unreal Tournament, el editor no es capaz de averiguar qu propiedades debe permitir alterar. La comunicacin entre el motor del juego y el motor de scripts est distribuida por los distintos mdulos que forman parte del juego. As, el gestor de red hace pblicas sus funciones, el gestor del GUI las suyas, el mdulo de Inteligencia Articial las suyas, etc. Para evitar conictos de nombres, cada mdulo hace pblicas sus funciones en un espacio de nombres distinto
17 .
16
Esto es especialmente llamativo si lo comparamos con otros datos. Por ejemplo, el
cdigo C++ de manejo de todas las entidades de Half-Life 1 Valve Software (1998) consta de 145 archivos, que suman 2'48Mb.
17
En LUA los espacios de nombres se construyen utilizando tablas.
43
Creacin d e l o b j e t i v o compuesto c o v e r _ l o o k _ c l o s e r
AI : CreateGoalPipe ( " c o v e r _ l o o k _ c l o s e r " ) ; AI : PushGoal ( " c o v e r _ l o o k _ c l o s e r " , " timeout " , 1 , 0 . 5 , 1 . 5 ) ; AI : PushGoal ( " c o v e r _ l o o k _ c l o s e r " , " approach " , 1 , 0 . 5 ) ; AI : PushGoal ( " c o v e r _ l o o k _ c l o s e r " , " l o o k a t " , 1 , 0 , 9 0 ) ; AI : PushGoal ( " c o v e r _ l o o k _ c l o s e r " , " timeout " , 1 , 0 . 5 ) ; AI : PushGoal ( " c o v e r _ l o o k _ c l o s e r " , " l o o k a t " , 1 , 0 , 9 0 ) ;
Figura 2.11: Denicin de un objetivo compuesto en Far Cry
En el cdigo LUA de la gura 2.11 se aprecian algunas llamadas a funciones implementadas en el mdulo de inteligencia articial bsica del motor del juego. Para solucionar el problema de la ejecucin de funciones que duran ms de un fotograma (que en el apartado 2.7.3.3 llambamos funciones latentes), utilizan lo que llaman
objetivos.
El motor del juego soporta unas acciones u
objetivos bsicos o primitivos, que el programador del script puede combinar para crear un objetivo compuesto. Por ejemplo, la gura 2.11 muestra el cdigo LUA utilizado en Far Cry para denir el objetivo compuesto NPCs llamados
cover
cover_look_closer,
utilizado por los
cuando pasan a estado de alerta por haber visto u
oido algo sospechoso. El comportamiento hace que se acerquen al sonido u objeto percibido, y miren hacia los lados; las funciones a las que se llama para crear el objetivo compuesto (AI:CreateGoalPipe y la IA bsica). Para la programacin de los comportamientos de los NPCs, se utilizan mquinas de estados programadas en LUA. Aunque el lenguaje no tiene un soporte nativo para ellas, su capacidad de soportar tablas de manera eciente y cmoda para el programador, hacen que la creacin de cada estado sea relativamente sencillo. El programador nicamente tiene que crear una tabla para cada estado, con una entrada por evento que contenga la funcin a ejecutar cuando ste ocurre. En la tabla tambin se puede indicar a qu estado se debe pasar en ese momento. En la implementacin de las funciones que se ejecutan para procesar cada mensaje recibido, se puede utilizar toda la potencia de LUA para decidir qu acciones realizar y utilizar llamadas al motor para obtener informacin adicional. Finalmente, la funcin puede seleccionar los distintos objetivos (tanto los primitivos como los compuestos), e incluso seleccionar varios, que sern ejecutados en secuencia. La gura 2.12 muestra el cdigo que se ejecuta cuando la entidad
AI:PushGoal) estn
implementadas en el motor del juego (en concreto, en la parte encargada de
cover
recibe la noticacin del mdulo de percepcin de
que ha visto algo distinto al jugador. Como vemos, lo que hace es meter en la pila de objetivos a ejecutar el desenfundar el arma, congurar el modo de
44
Captulo 2.
Evento generado cuando l a e n t i d a d ve un enemigo d i s t i n t o d e l ju ga do r
OnSomethingSeen = f u n c t i o n ( s e l f , e n t i t y )
e n t i t y : R e a d i b i l i t y ( "IDLE_TO_INTERESTED" ) ; entity : SelectPipe (0 , " cover_look_closer " ) ; entity : InsertSubpipe (0 , " setup_stealth " ) ; e n t i t y : I n s e r t S u b p i p e ( 0 , "DRAW_GUN" ) ; end ,
Figura 2.12: Implementacin de un comportamiento en Far Cry
sigilo en todas sus acciones e ir a inspeccionar las inmediaciones del enemigo visto
18 .
2.7.3.6. Age of Empires II: The Age of King

El caso del juego de estrategia Age of Emires II (Ensemble-Studios, 1999) es bastante distinto de todos los anteriores. En este caso, el juego hace uso de un
motor de reglas
para la toma de decisiones de la inteligencia articial
controlada por el ordenador. El lenguaje de script utilizado, por tanto, no es un lenguaje imperativo como los anteriores, sino un lenguaje de reglas, que permite la programacin
declarativa
del comportamiento.
Por lo tanto, de entre todas las ventajas introducidas por el uso de lenguajes de script, la fundamental en este caso es el motor de inferencia que hay por detrs en la ejecucin del lenguaje. El uso de un sistema de reglas permite un modelo de razonamiento ms general, gracias a su carcter declarativo. De esta forma, los comportamientos implementados son de ms alto nivel y pueden ser reutilizados en ms de un contexto (da Silva y Vasconcelos, 2006; Combs y Ardoint, 2005). El motor de reglas acta como un intrprete de instrucciones deben satisfacerse para que se ejecuten sus acciones asociadas. Las condiciones se basan en una serie de hechos que representan el estado del juego, y que pueden entenderse como la percepcin de la inteligencia articial. Los hechos detallan la informacin sobre el jugador (como la cantidad disponible de un determinado material), sus oponentes (por ejemplo su puntuacin) y sobre el propio juego (tiempo transcurrido, condiciones para ganar, etc.). Para el motor de inferencia, se puede utilizar uno ya existente, como
if/then.
Cada una de esas instrucciones es una regla, con unas condiciones que
18
En el cdigo se aprecia que los objetivos se aaden en
orden inverso
a su ejecucin,
ya que la estructura de datos en la que se almacenan es una pila.
Resumen
45
( defrule ( food amount > 1700) ( or ( woodamount < 1100) ( or ( gold amount < 1200) ( stone amount < 6 5 0 ) ) ) ( can s e l l commodity food ) => ( chat l o c a l to s e l f " e x c e s s food ") ( r e l e a s e escrow food ) ( s e l l commodity food ) )
( defrule ( gold amount > 1250) ( woodamount < 1100) ( canbuycommodity wood ) ( commoditybuying p r i c e wood < 50) => ( chat l o c a l to s e l f " e x c e s s g o l d ; buy wood ") ( r e l e a s e escrow g o l d ) ( buycommodity wood ) )
Figura 2.13: Ejemplos del uso de un motor de reglas en un juego
CLIPS (Giarratano, 2002) o Jess (Friedman-Hill, 2005). En el caso concreto de Age of Empires, se cre uno nuevo basndose en los anteriores, con un lenguaje de denicin de reglas parecido que soporta algunos comandos tiles para el juego. Si el sistema de inferencia no es demasiado sosticado, se puede incluso programar en C++ la propia denicin de las reglas (Bourg y Seemane, 2004), aunque se pierden las ventajas asociadas a los lenguajes de scripts, como la reduccin del ciclo de desarrollo que explicbamos en la seccin 2.7.1. La gura 2.13 muestra dos ejemplos de reglas, ambas relacionadas con los recursos disponibles por el jugador controlado por el sistema de reglas. La primera se dispara para vender comida cuando tiene exceso de sta pero falta de otros recursos, mientras que la segunda se utiliza para comprar madera cuando se tiene poca, est barata y se dispone de margen de dinero suciente.
Resumen
En este captulo se han detallado los componentes ms importantes de un juego desde el punto de vista de su arquitectura interna, que ms adelante dirigirn el diseo de una arquitectura til para la creacin de sistemas educativos basados en videojuegos. Despus de una breve introduccin y una denicin de lo que entendemos por arquitectura software, la seccin 2.3 expone motivos por los que se hace necesaria la existencia de una arquitectura bien pensada en el desarrollo del software de entretenimiento y, muy posiblemente, la adquisicin por parte de los desarrolladores de componentes o libreras externas.
46
Captulo 2.
Una vez justicada la existencia de estas arquitecturas, la seccin 2.4 presenta a grandes rasgos la caracterstica ms importante y comn de todos los desarrollos actuales: la extraccin fuera del ejecutable nal de la mxima cantidad de informacin posible, o lo que es lo mismo, la idea de las arquitecturas dirigidas por datos. Tras eso, la seccin 2.5 pasa a describir los distintos modelos de bucle principal que hay y la seccin 2.6 detalla las posibilidades existentes para la gestin de todos los objetos que hacen del juego un entorno interactivo. Finalmente, la seccin 2.7 recupera la importancia de una arquitectura dirigida por datos. Para eso, detalla las posibilidades que hay para sacar fuera del ejecutable parte del cdigo del propio juego, de forma que se consigue una aplicacin fcilmente congurable. En el captulo siguiente abandonamos el mundo de los videojuegos, para adentrarnos en los programas educativos. Ms adelante, mezclaremos las dos reas para recuperar el tema original, la creacin de aplicaciones educativas basadas en videojuegos.
Notas bibliogrcas
En los ltimos aos, ha habido un incremento signicativo en el nmero de textos relacionados con la creacin de videojuegos, dirigidos tanto para un pblico acionado como para profesionales del sector. La mayora de ellos, no obstante, cubren con detalle un determinado aspecto de la programacin de juegos, sin dar ideas de la arquitectura general que se necesita. Especialmente extendidos estn las series de libros titulados
Game Programming Gems
(DeLoura, 2000, 2001; Treglia, 2002; Kirmse,
2004; Pallister, 2005; Dickheiser, 2006) y
AI Wisdom
(Ravin, 2002, 2004,
2006). Todos estos libros estn formados a partir de artculos independientes, algunos de ellos referenciados a lo largo del captulo. Algunos libros intentan dar una visin general de todos los aspectos de la programacin de juegos, como Sanchez-Crespo Dalmau (2003) o Rucker (2002), mientras que otros se centran en un nico aspecto, como la parte grca (Watt, 1999; Moller et al., 2002), inteligencia articial (Schwab, 2004), fsica (Kodicek, 2005) o scripts (Varanese, 2002). Por ultimo, cabe destacar Rollings y Morris (2004), que hace un intento de presentar una arquitectura de videojuegos. Desde un punto de vista ms acadmico, existen algunas conferencias cuyas actas son un buen foco de informacin. Por ejemplo, existen congresos dedicados a la programacin de juegos en general (como la
pers Conference 19 ),
19 20
Game Develo-
a la informtica grca (ACM SIGGRAPH
20 ) y a la
http://www.gdconf.com http://www.siggraph.org
Notas bibliogrcas
47
inteligencia articial en juegos (Articial Intelligence and Interactive Digital Entertainment Conference, AIIDE). Este creciente inters ha dado lugar, entre otros, al uso de sistemas de reglas para resolver el buscaminas (Gmez Martn y Daz Agudo, 2006), la utilizacin de planicacin en coordinacin de equipos de enemigos (Muz vila y Hoang, 2006) o el uso de razonamiento basado en casos para juegos de estrategia (Snchez Pelegrn, Gmez Martn y Daz Agudo, 2005). Por ltimo, para conocer de qu forma estn estructurados los distintos juegos, otra alternativa es inspeccionar su cdigo. Existe un gran nmero de juegos cuyo cdigo ha sido liberado, que pueden utilizarse para ver las distintas aproximaciones que utilizan para resolver los problemas planteados en este captulo. Tambin es educativo adentrarse en las SDK o kits de desarrollo que ciertos estudios hacen pblicos para permitir a jugadores acionados y empresas realizar modicaciones del juego. Gracias a estos paquetes hemos podido mostrar datos sobre el funcionamiento de Half-Life y de Far Cry.
Captulo 3
Aplicaciones educativas
El nico medio racional de educar es dar ejemplo, y si no hay otro remedio, un ejemplo que ponga sobre aviso.
Albert Einstein
En este captulo hacemos un anlisis de las arquitecturas de los programas educativos que centran nuestro foco de atencin. Para eso, empezamos por analizar la construccin de sistemas de enseanza inteligentes. Despus analizamos cmo se integran agentes en entornos virtuales para despus aplicar esa integracin a los agentes pedaggicos.
3.1. Introduccin
Desde los primeros aos de la informtica existi un inters por los sistemas de enseanza asistidos por ordenador, que a partir de 1970 cristalizan en lo que se llam Sistemas de enseanza inteligentes o Sistemas Inteligentes de Tutora
1 (Carbonell, 1970). Tanto expertos en inteligencia articial como
educadores y psiclogos los vieron como una va prometedora en la que aplicar sus tcnicas y teoras. El primer libro dedicado a ITSs aparece en 1982, de la mano de Sleeman y Brown; despus vinieron otros, hoy considerados clsicos, como Kearsley (1987); Lawler y Yazdani (1987); Wenger (1987); Polson y Richardson (1988). En la construccin de los primeros tutores inteligentes, se haca hincapi en los conocimientos que el sistema tena sobre el dominio, tcnicas pedaggicas y modelo del usuario, sin tener en cuenta la reutilizacin de todo ese esfuerzo para el desarrollo de sistemas futuros. Slo desde hace algn
En el mundo anglosajn son conocidos como
como
Intelligent Tutoring Systems, ITSs , siglas que utilizaremos de ahora en adelante.
abreviado
49
50
Captulo 3.
tiempo se est prestando atencin a la arquitectura general del sistema, a la posibilidad de reutilizar componentes, modelos cognitivos, etc. En la primera parte de este captulo haremos una descripcin de las caractersticas generales que se atribuyen a los programas educativos, para despus pasar a analizar las arquitecturas software ms comnmente utilizadas.
3.2. Descripcin de los entornos de aprendizaje

Los enfoques de aprendizaje utilizados hoy en da por numerosos educadores tienden a dar al alumno un papel activo a la hora de ensear nuevos conceptos y procedimientos. Este mtodo se basa en el enfoque constructivista, expuesto inicialmente por Piaget (1955), en el que el nfasis se pone en el papel activo que juega el estudiante en la construccin de su propio conocimiento. El mtodo del aprendiz o
learning-by-doing
(Schank y Clearyv, 1994; Ko-
lodner, 1997) se basa en este enfoque constructivista. A pesar de que la idea parece novedosa, la realidad es que ha sido la forma en la que tradicionalmente se han transmitido, generacin tras generacin, las destrezas de muchas profesiones fundamentalmente manuales. El traslado de este tipo de enseanzas desde el mundo real al ordenador consiste en aadir entornos virtuales de aprendizaje a los sistemas, creando lo que se conoce como
inmersivo .
aprendizaje
Durante aos, la comunidad persigui este tipo de aprendizaje a
base de la construccin de
micromundos
(ver por ejemplo Burton y Brown
(1982); Hollan et al. (1984); Lawler y Lawler (1987); Thompson (1987)), para posteriormente, con el avance de la capacidad de clculo, explorar los entornos virtuales tridimensionales (Rickel y Johnson, 1997). Segn Bares et al. (1998), el
aprendizaje inmersivo
se caracteriza por:
Motivacin:
para que el alumno pase tiempo utilizando el progra-
ma educativo, debe estar motivado. Bsicamente, la motivacin puede venir de dos vas (Sansone y Harackiewicz, 2000): (i) los factores externos al estudiante, como las recompensas (motivacin (ii) desde el propio estudiante (motivacin
intrnseca ).
extrnseca ),
Para conseguir
esta ltima, existen dos factores que el aprendizaje inmersivo favorece: el reto propuesto al estudiante y la curiosidad que siente hacia el problema.
Resolucin de problemas en situacin: quitando las reas en las

que se ha utilizado el mtodo del aprendiz, en general, las teoras de aprendizaje se han centrado en la memorizacin de conceptos. La aproximacin del aprendizaje inmersivo est dirigida por objetivos ms claros: la resolucin de problemas concretos. De esta forma, el estudiante va aplicando la teora a la vez que la aprende.
51
Inmersin con un papel particular:
desde el primer juego de rol
(Gygax y Arneson (1974); consultar Kim (2006) para una enumeracin exhaustiva), pareci claro que participar activamente en el desarrollo de una historia resultaba especialmente atrayente a los jugadores. Ms tarde, los juegos de rol por ordenador (por ejemplo Nihilistic-Software (2000) o BioWare-Corp (2002)) vinieron a conrmar la teora. Esta misma situacin se puede extrapolar a los entornos de aprendizaje, donde el estudiante acepta un papel activo en el mundo virtual que simula el entorno de estudio. En realidad, para llegar a los sistemas educativos con entornos de aprendizaje basados en el aprendizaje inmersivo y el uso de micromundos, se ha ido pasando por distintos tipos de sistemas ms o menos sosticados. Los ITSs son la evolucin de aplicaciones educativas ms sencillas, encuadradas dentro del rea de Computer-Aided
Instruction ,
enseanza asistida por ordenador

abreviado como CAI).
(en ingls
Los sistemas iniciales eran meros contenedores de conocimiento estructurado, igual que lo son los libros. Los autores utilizaban su conocimiento sobre el dominio y su destreza como oradores (o escritores de contenido), para representar los conceptos en la forma apropiada. De la misma forma que en un libro el autor toma ciertas decisiones pedaggicas para secuenciar el contenido en captulos, o incluso aade invitaciones a lectores avanzados a saltarse secciones, etc., los creadores de contenidos de un sistema CAI decidan el orden de presentacin. A primera vista, lo que distingue a un sistema CAI simple de otro es nicamente el contenido. Por eso, existen herramientas conocidas como generadores de tutores inteligentes, o en ingls
intelligent tutor generators
(Koda-
ganallur et al., 2006), que ayudan en la creacin de esos contenidos, independientemente del rea de conocimiento. Estas herramientas han evolucionado desde los antiguos PLATO (Wikipedia (PLATO)) y TICCIT (Alderman, 1979), hasta el moderno Macromedia AuthorWare (Adobe, 2006), sin dejar de lado los esfuerzos en el campo de la investigacin como Koedinger et al. (2004). El lector interesado puede consultar Murray (1999) para una amplia revisin de las mismas. Posteriormente, los sistemas CAI fueron evolucionando. Los ms sosticados empezaron a incluir cierta autonoma en la toma de decisiones, para convertirse en aplicaciones dinmicas, en contraposicin a la presentacin en un orden preestablecido de los contenidos. As, por ejemplo, surgieron sistemas capaces de generar ejercicios (siguiendo las ideas de Uhr, 1969) o de adaptar su nivel de dicultad dependiendo del avance del estudiante (Tennyson et al., 1984). La progresiva mejora de los sistemas CAI, aadiendo ms y ms tcnicas de inteligencia articial, llev a acuar el trmino
Intelligent Computer-Aided
52
Captulo 3.
Instruction
(ICAI) que despus fue reemplazado por el hoy aceptado ITS ya
indicado (Sleeman y Brown, 1982). La inteligencia aadida a los CAI consisti en aadir al sistema ms y ms conocimiento con el que razonar para mejorar la forma de presentar los contenidos, proporcionar pistas, gua y comentarios a los estudiantes. En concreto, los ITSs beben generalmente de tres fuentes de conocimiento: el conocimiento del dominio, el modelo pedaggico y el modelo del estudiante. Estos tres tipos de conocimiento son los responsables de decidir qu informacin dar al usuario, y son tan comunes que suelen aparecer en todos los ITSs como mdulos software perfectamente delimitados. Existe un cuarto mdulo que, si bien no tiene ningn tipo de conocimiento asociado, tambin aparece en los ITSs, que es el mdulo de comunicacin, responsable de la presentacin de los contenidos al usuario. Teniendo en cuenta la frecuencia e importancia de los tres tipos de conocimiento y del mdulo de comunicacin, en los siguientes apartados describiremos su misin y responsabilidades. Posteriormente, veremos cmo las distintas arquitecturas software prototpicas los relacionan.
3.2.1.
do,
Mdulo experto
frames, y que hoy por learning objects. La aplicacin presenta cada uno de esos cablea-
En los primeros sistemas CAI, el conocimiento a transmitir estaba almacenado en bloques que Wenger (1987) llama hoy suelen llamarse adecuadas.
bloques diseados por el experto humano cuando se dan las circunstancias
Histricamente, en la transicin que tuvo lugar hacia los ITS, el primer paso fue la representacin ce como
mdulo experto 2 .
explcita
de ese conocimiento, en lo que se cono-
Su funcin principal es la de servir de fuente del
conocimiento que hay que presentar al estudiante, generar explicaciones, responder a sus preguntas, etc. Una segunda utilidad es ser capaz de tutor humano. Existen distintas alternativas para la representacin de este tipo de conocimiento (Dhar y Pople, 1987). Dependiendo de la complejidad con la que se haga, el mdulo ser capaz de evaluar esas soluciones mejor o peor. Por ejemplo, se puede guardar una base de ejercicios acompaados de su solucin (como en Stottler y Vinkavich, 2000) y comparar la solucin del usuario con la suya. Otra alternativa es construir un modelo que contenga la estructura y el comportamiento del dominio dinmico (Davis, 1984). En ese caso, se puede hacer una evaluacin compleja de la solucin, comparando las discrepancias entre el comportamiento predicho por el modelo y el de la solucin
evaluar
la solucin aportada por el alumno automticamente, sin la necesidad de un
Hay que destacar que, a pesar de la similitud de nomenclatura, el mdulo no tiene
por qu ser un
sistema experto.
53
aportada, como hace por ejemplo Kumar (2002).
3.2.2.
En cualquier proceso comunicativo, el orador debe ser consciente del nivel de conocimiento de la audiencia. Los sistemas de enseanza inteligentes, no escapan a esto, y mejoran si tambin lo tienen en cuenta. Para eso, igual que se modela el conocimiento a ensear, los ITSs suelen incluir un modelo del usuario o estudiante. En realidad, la idea no se restringe a sistemas de enseanza, sino que se ha utilizado en gran variedad de sistemas, como en los enfocados al ltrado de informacin (Maes, 1994), comercio electrnico (Abbattista et al., 2002) o interfaces adaptables (Brusilovsky, 2001). La recoleccin de los datos utilizados para componer ese modelo puede ser explcita o implcita. El mtodo explcito consiste en preguntar directamente al usuario sus preferencias y de ah extraer el modelo, mientras que con el mtodo implcito se monitorizan sus acciones mientras interacta con el sistema. Esa coleccin de informacin despus ser utilizada para adaptar la funcionalidad del sistema, y hacerla ms amigable (Kobsa, 1995; Papatheodorou, 2001). Segn Wenger (1987), la idea de modelo de usuario en sistemas de enseanza se remonta a 1975 (Fletcher, 1975). En estas aplicaciones, el modelo del estudiante debe ser capaz de inferir, a partir de aspectos observables del comportamiento del estudiante, una paz de reconstruir el
conocimiento
interpretacin genotipo
de sus acciones y ser ca-
que ha generado esas acciones, lo que a partir del
Hollnagel (1993) llama la extraccin del
fenotipo.
En los sistemas CAI simples, el modelo del usuario puede ser una mera medida del rendimiento general del estudiante, representada incluso con un nico valor real. Sin embargo, en sistemas ms complejos o en ITSs, la medida debe disgregarse, para cubrir por separado el nivel de conocimiento de cada uno de los elementos (o conceptos) que el sistema ensea. A este respecto, puede distinguirse, por ejemplo, el modelado del conocimiento basado en los conceptos (concept-based
knowledge modeling ) based knowledge modeling ).
y el basado en temas (topic-
En cualquier caso, los tipos de modelado anteriores almacenan por cada estudiante una representacin de su conocimiento. Por el contrario, algunos sistemas (Kay, 1995; Brusilovsky, 1994), no slo guardan el perl inferido del estudiante (el genotipo), sino que tambin dejan registrados los eventos o acciones del usuario (fenotipo) que llevaron a inferir ese modelo. De esta forma, no pierden informacin, y es fcil aadir reglas nuevas al sistema de inferencia para conocer ms acerca de un usuario cuyo comportamiento ha sido registrado. Para nalizar con el modelo del usuario, resulta de especial relevancia
54
Captulo 3.
en nuestro contexto, la reciente aparicin de trabajos de investigacin en los que se intenta modelar al jugador de un videojuego, para adaptar su comportamiento e intentar mantener alto el nivel de inters que ste tiene (Spronck, 2005; Yannakakis y Maragoudakis, 2005; Houlette, 2004; Charles y Black, 2004).
3.2.3.
Mdulo pedaggico
Ya se ha mencionado que en cualquier comunicacin de contenidos se toman decisiones pedaggicas sobre la secuenciacin de dichos contenidos. Esas decisiones pueden ser estticas o dinmicas, es decir, tomadas previamente o durante la ejecucin, teniendo en cuenta las acciones del estudiante. El dinamismo en estas decisiones es lo que marca la diferencia entre un sistema educativo y un libro. En un libro, la secuencia de contenidos es una decisin del autor que plasma estticamente, y que no cambia. En una aplicacin informtica, es el propio sistema el que decide, en base a unas determinadas entradas, qu contenidos presentar al estudiante, de forma que dos usuarios distintos vern una secuenciacin de contenidos distinta. En los sistemas CAI, estas decisiones, a pesar de ser dinmicas, es decir, variar en ejecucin segn el alumno, estaban sistema o incluso no existan. En el rea de los ITSs, la seleccin de esos contenidos es responsabilidad del mdulo pedaggico (o de tutora). Teniendo en cuenta el conocimiento del dominio y el modelo del estudiante, utiliza una serie de reglas para decidir qu debe hacer el estudiante a continuacin. Idealmente, las reglas pedaggicas utilizadas deben ser generales y reutilizables independientemente del conocimiento enseado en el sistema. Si es as, el mdulo almacena un conjunto de principios generales expresados explcitamente e interpretados en el contexto especco del sistema para tomar las decisiones concretas. A nivel global, las decisiones, como hemos dicho, afectan a la secuenciacin de contenidos, la seleccin de los ejercicios a presentar, etc. Sin embargo, si el seguimiento del estudiante es ms estrecho, el mdulo tambin debe estar pendiente de las acciones que realiza el estudiante en cada momento. Con este modo de actuar, se puede conseguir que el sistema d explicaciones contextualizadas o vaya guiando al estudiante en su aprendizaje. Esto ltimo est muy relacionado con los agentes pedaggicos de las secciones 3.2.5 y 3.5. Un rea que ha despertado mucho inters, relacionada con el mdulo pedaggico es dotar al sistema de
cableadas
en el cdigo del
adaptabilidad
en el entorno de aprendizaje.
El mdulo pedaggico, que es el que hace las veces de tutor cambia el entorno dependiendo del modelo del estudiante, igual que se hace en otras reas no relacionadas con la enseanza (ver por ejemplo Gmez Gaucha et al., 2006; Gker, 2003; Gker y Thompson, 2000). Para terminar, hay que hacer notar que la creacin de un mdulo de este
55
tipo no es una tarea fcil. La pedagoga es un arte que requiere una gran versatilidad, y no existe una especicacin de sus componentes esenciales, lo que ha contribuido a retrasar la inclusin real de decisiones pedaggicas en los ITSs. Podemos decir que el conocimiento pedaggico ha sido el rea olvidada de los sistemas CAI e ITS (Heernan, 2001).
3.2.4.
Mdulo de comunicacin
Los mdulos anteriores son los responsables, en mayor o menor medida, de la seleccin de los contenidos a presentar al usuario. El mdulo de comunicacin se preocupa del formato nal que se utilizar para mostrarlo al estudiante. Se puede decir que traduce la representacin interna del conocimiento al lenguaje interpretable por el alumno. Tambin realiza el paso inverso, sirviendo de comunicacin entre el estudiante y el sistema, cuando ste recibe las interacciones de aqul. Las investigaciones en ITSs se han centrado tradicionalmente en el resto de mdulos, ms cercanos a las teoras educativas y a problemas tradicionalmente difciles como modelado de usuario o representacin del conocimiento. Sin embargo, el mdulo de comunicacin no debera olvidarse. Desde el punto de vista del usuario, el interfaz
es el sistema. Si la forma en
la que se presenta un tema lo hace difcil de interpretar, el estudiante puede sentirse sin fuerzas para terminar de leerlo. En denitiva, de su atractivo depende la aceptacin que el sistema
completo
tendr entre los usuarios.
Siendo puristas, podramos clasicar los tipos de representacin en tres tipos: los entornos unidimensionales que nicamente presentan texto, los entornos bidimensionales que complementan el texto con guras, y los entornos tridimensionales que utilizan un entorno virtual en tres dimensiones para la representacin de los contenidos. Con la progresiva mejora de los equipos, los entornos unidimensionales son ya bastante escasos, mientras que los tridimensionales abundan por doquier. Eso hace que la complejidad del mdulo de comunicacin se haya visto incrementada hasta el punto de que hoy por hoy el entorno virtual y sus habitantes no pueden ser considerados como un simple mdulo de comunicacin, sino que debe ser tratado de manera especial dentro de la arquitectura del sistema completo (de Antonio et al., 2004). El auge de los entornos tridimensionales excede el rea de los sistemas educativos. De hecho, existe toda un rea de investigacin en lo que se cono-
interfaces virtuales inteligentes o en ingls intelligent virtual environments o IVEs (Aylett y Cavazza, 2001; Aylett y Luck, 2000). Segn la
ce como denicin dada por Aylett y Cavazza, estos son entornos tridimensionales en tiempo real e interactivos que aaden algn tipo de vida o inteligencia articial. Una de las reas de investigacin en este campo, y que est relacionada con lo que decamos en la seccin anterior, consiste en la personalizacin que
56
Captulo 3.
adeca la presentacin del material al usuario; por ejemplo Chittaro y Ranon (2002) generan distintos cheros VRML para la generacin del entorno virtual dependiendo del perl del usuario. Aunque esto tiene una utilidad directa en sistemas de enseanza, tambin se utiliza en otros contextos. Es el caso de Panayiotopoulos et al. (1998), un entorno virtual inteligente donde se gua por una universidad virtual. En realidad, si el IVE est bien diseado es posible utilizarlo con cualquier n, como el sistema AdapTIVE, que puede utilizarse tanto para sistemas educativos (dos Santos y Osrio, 2004c) como para comercio electrnico (dos Santos y Osrio, 2004a). Una mejora adicional para los programas educativos que presentan entornos virtuales en los que el usuario
habita
es aadir a ellos una especie
de tutor que monitoriza las acciones del estudiante y reacciona ante ellas en el momento adecuado. Son los agentes pedaggicos que describimos en la seccin siguiente.
3.2.5.
Agentes pedaggicos
Los ITSs son sistemas educativos a los que se ha aadido cierta inteligencia articial para ayudar en el proceso enseanzaaprendizaje. En muchos casos, utilizan modelado del usuario y son capaces de adaptar las estrategias dependiendo de la situacin. Aunque los ITSs estn pensados para simular el comportamiento de un profesor, la realidad es que tradicionalmente fallaban en el modo de interaccin, pues ofrecan un estilo rgido y fuertemente dirigido por la aplicacin. Para mejorar esta situacin, se empezaron a aadir que en el contexto en el que estamos, son conocidos
gicos.
agentes inteligentes, como agentes pedag-
Estos agentes son entidades cuyo propsito fundamental es mejorar
la interaccin y comunicacin entre el sistema y el estudiante, jugando el papel de
tutor
o profesor (Johnson et al., 2000). Pueden adems adquirir
otras responsabilidades, como monitorizar al estudiante y ayudarle durante el proceso de aprendizaje. Es ms, tambin suelen intercambiar informacin con ellos, pueden adaptar la presentacin de los conceptos dependiendo de la situacin y alumno actual, etc. El concepto de agente pedaggico suele venir acompaado de un interfaz visual que dota al agente de una fuerte apariencia humana, o al menos la de un ser vivo e inteligente. Son lo que se conocen como
cos animados,
agentes pedaggi-
para distinguirlos de aquellos pocos agentes pedaggicos sin
presencia visual. Aadir un agente pedaggico animado al entorno aumenta los tipos de interaccin hombremquina que pueden realizarse y que no se tienen en sistemas educativos normales. Los agentes deben ser capaces de interactuar con el estudiante de manera creble. Dependiendo de la complejidad del agente pedaggico, ste soportar ms o menos tipos de interacciones, como por
57
Figura 3.1: Captura del sistema Steve en funcionamiento
ejemplo, hacer demostraciones interactivas, guiar dentro del entorno virtual, usar expresiones para guiar la atencin durante las conversaciones, o usar expresiones corporales para guiar la atencin (Rickel y Johnson, 2000; Rickel, 2001). Analizaremos con un poco ms de detalle cada una de ellas en los siguientes puntos.
3.2.5.1. Demostraciones interactivas

En general, demostrar cmo se realiza una tarea es mucho ms efectivo que intentar describir cmo hacerla y que el estudiante memorice cada uno de los pasos. Eso es especialmente cierto cuando la tarea involucra habilidades motoras; incluso nicamente con ver cmo se realiza hace que sea ms probable que el alumno lo recuerde en un futuro. En un entorno de aprendizaje donde el agente comparte su espacio vital con el estudiante, las demostraciones por parte del agente son incluso ms beneciosas. La demostracin pasa a ser interactiva, al contrario que lo que ocurre cuando se muestra un simple vdeo, ya que el usuario puede seguir movindose libremente por el entorno, ver la explicacin desde distintas perspectivas, interrumpir la exposicin para realizar preguntas, o incluso solicitar terminar por l mismo la tarea. Un ejemplo de agente con demostraciones interactivas es Steve (Rickel y Johnson, 1999, 2000), que habita en una simulacin virtual de un navo estadounidense donde los estudiantes aprenden procedimientos de actuacin. En la gura 3.1 se puede ver una captura en la que aparece el agente pedaggico explicando una determinada accin. Steve utiliza planicacin para adaptar sus demostraciones dependiendo del estado del entorno, proporcio-
58
Captulo 3.
nando unas demostraciones mucho ms adecuadas que vdeos de actuacin tradicionales.
3.2.5.2. Gua de navegacin

Dejar al usuario en un entorno virtual tiene el peligro de que se sienta perdido, sobre todo si el entorno es demasiado grande o contiene numerosos objetos con los que interactuar. El agente pedaggico puede servir como gua de navegacin por estos mundos virtuales, al ir mostrando las tareas a realizar y moverse de un sitio a otro para alcanzar las piezas con las que operar. Otro aspecto importante a tener en cuenta es que si el entorno de aprendizaje est basado en un espacio real, como puede ser la sala de mquinas de un barco (Rickel y Johnson, 1998), el estudiante estar aprendiendo dnde estn situados los componentes principales sin necesidad de haber estado
situ
in
en ese lugar. El alumno puede construirse un modelo espacial de la zona
de trabajo que es imposible conseguir en una clase tradicional. Otro ejemplo en el que una de las funciones del agente es la de hacer de gua por el entorno virtual es
WhizLow,
un agente pedaggico desarrollado
por Lester et al. (1999b), que habita la CPU
City,
una ciudad virtual
tridimensional que representa el interior de un ordenador. El agente, entre otras cosas, gua al estudiante por las distintas zonas de la ciudad.
3.2.5.3. Expresiones para guiar la atencin

Cuando una persona est hablando utiliza numerosas expresiones para guiar la atencin del oyente, como mover los brazos, o hacer gestos con la cara. Del mismo modo, los agentes pedaggicos pueden utilizar ciertas expresiones corporales para guiar la atencin del estudiante. En este sentido, pueden sealar a los objetos cuando estn explicando algo sobre ellos, mirar un objeto mientras lo manipulan, o mover la cabeza para dar la sensacin de que miran hacia un piloto indicador cuando quieren comprobar si est encendido o no. Por ejemplo, Nijholt y Heylen (2002) implementan un agente que mira hacia una mesa mientras apunta que en ella se puede encontrar folletos con la informacin solicitada.
3.2.5.4. Comunicacin no verbal

Todos tenemos la imagen de un nio temeroso, antes de hacer algo, mirando con cara interrogante al padre o profesor, para ver si capta alguna expresin del adulto acerca de lo acertado o desacertado de la accin que pretende realizar a continuacin.
59
En realidad, uno de los papeles principales de cualquier tutor es proporcionar
feedback
ante las acciones del estudiante, ya sea usando comunicacin
verbal o no verbal. De esta forma, el tutor inuencia al estudiante, o le hace saber si la accin que est apunto de realizar es adecuada o no. Los gestos pueden ser simples movimientos de cabeza, armando o negando, aunque tambin pueden ser muecas de agrado o desagrado. Ms an, las expresiones pueden utilizar todo el cuerpo. Por ejemplo se pueden dar saltos para mostrar alegra, o mostrar peligro alejndose del objeto que el usuario va a tocar. Este tipo de comunicacin no verbal es muchas veces ms adecuada que un comentario hablado pues es menos intrusiva, pero consigue el mismo efecto: que el estudiante se lo piense dos veces antes de dar el siguiente paso. Un ejemplo de esto es Adele, desarrollado por Shaw et al. (1999), que sonre o hace gestos armativos cuando el usuario realiza las acciones correctamente y muestra desagrado cuando se equivoca. Tambin
Herman the
Bug
(Lester et al., 1999a) muestra su contento haciendo movimientos de
alegra por la pantalla. Ambos son ejemplos de agentes pedaggicos en dos dimensiones.
3.2.5.5. Gestos durante las conversaciones

Es una parte de la comunicacin no verbal tiene la suciente importancia como para tratarla aparte. Cuando hablamos, empleamos inconscientemente una amplia variedad de gestos acompaando a la voz (Wachsmuth y Kopp, 2002). Algunos de ellos estn estrechamente ligados a ella, como mover las cejas o la cabeza al elevar la entonacin, mientras que otros ayudan a regular la conversacin, como el uso del contacto visual, cuando en una pausa el hablante pierde el contacto y mira al suelo, o lo recupera para pedir la respuesta. Un ejemplo de agente con estas caractersticas es el creado por Cassell et al. (2001), que utiliza la mirada y los gestos para controlar el turno en la conversacin, mueve la cabeza para hacer nfasis en ciertas palabras, y alguna caracterstica parecida.
Aparte de estos cinco tipos de interaccin, existen otras capacidades interesantes descritas por Rickel (2001). Por ejemplo, es importante la existencia de avatares e historias interesantes para atrapar la atencin del estudiante, como se describe en Gmez Martn et al. (2004b). Rickel tambin destaca que los agentes pueden hacer de compaeros virtuales. No obstante, pensamos que esta capacidad est ms cercana a otro tipo de agentes, que hacen de
coaprendices, es decir, avatares que ngen
aprender al mismo
tiempo que el estudiante (Goodman et al., 1998).
60
Captulo 3.
Mdulo experto Mdulo pedaggico Mdulo de comunicacin
ITS
Estudiante
Figura 3.2: Arquitectura clsica de un ITS (Wenger, 1987)
3.3. Arquitecturas de ITSs

En el apartado anterior veamos los tres tipos de conocimiento ms relevantes para un ITS y las atribuciones dadas al responsable de la comunicacin con el usuario. En este apartado, pasamos a describir tres tipos de arquitecturas tpicas en los ITSs.
3.3.1.
Arquitectura clsica de ITSs
Una vez presentados los componentes bsicos clsicos que se encuentran en la mayora de los ITSs, es fcil describir su arquitectura clsica presentada por Wenger (1987) (ver gura 3.2). En ella, se divide el sistema, precisamente, en los cuatro mdulos vistos previamente: Mdulo experto: almacena el conocimiento y posee la habilidad de solucionar los problemas del dominio. Modelo del estudiante: diagnostica la habilidad del estudiante en el dominio enseado. Mdulo pedaggico: responsable de las estrategias pedaggicas a seguir. Mdulo de comunicacin: implementa el interfaz hombremquina. Un ejemplo de escenario de interaccin entre los mdulos puede ser el siguiente: el mdulo pedaggico elige la siguiente tarea a realizar basndose en la informacin proporcionada por el mdulo del estudiante; el mdulo de
3.3. Arquitecturas de ITSs
61
comunicacin se lo muestra y traduce la entrada de ste para que pueda ser procesada por el mdulo experto, el cual intenta diagnosticar algn posible problema del alumno al resolver el problema en cuestin. Este diagnstico se utilizar para actualizar el modelo del estudiante, y repetir el ciclo.
3.3.2.
Arquitectura Modelo de conocimientoVista
Devedzic y Harrer (2005) en su esfuerzo por extraer patrones software en las arquitecturas de ITSs, identicaron lo que vinieron a llamar la arquitectura modelo de conocimientovista (en ingls
knowledgemodelview ).
Esta arquitectura se basa en la idea de que existen dos tipos distintos de mdulos, los responsables principalmente de albergar conocimiento, y los
consumidores
de esos datos:
Modelizaciones del conocimiento: que se corresponden con los tres primeros mdulos de la arquitectura clsica: el conocimiento sobre el dominio, el modelo del estudiante y el modelo pedaggico (o reglas pedaggicas). Componentes para la representacin de la informacin al usuario y para interactuar con l. En la terminologa habitual, estos componentes se conocen como
vistas
(Gamma et al., 1995).
La realidad es que esta arquitectura est muy relacionada con la variante documentovista (ver Buschmann et al., 1996, pgina 140) del patrn ms general modelovistacontrolador (Buschmann et al., 1996). La nica diferencia es que en estos patrones clsicos, nicamente existe un modelo, mientras que en un ITS se pueden tener distintos modelos simultneamente (dominio, estudiante y pedaggico). El patrn general considera que los tres tipos de conocimiento pueden formar su propio modelo, de forma que cualquier otra parte del sistema puede jugar el papel de vista de ese modelo, y ser informado cuando ocurre un cambio. Un ejemplo de un sistema que sigue esta arquitectura es la arquitectura centrada en el modelo del estudiante de Brusilovsky (1994, 1995). En ella, no obstante, existe un nico modelo, el que almacena el conocimiento que se tiene del usuario. Sobre l gira el resto de componentes, que son las vistas asociadas. Cuando alguna de ellas altera el modelo, esos cambios son redistribuidos al resto. La arquitectura establece dos tipos de vistas, aquellas que guardan el resto de tipos de conocimiento (y que Brusilovsky llama
agentes )
y el resto de mdulos o herramientas de interfaz, que permiten la
interaccin con el usuario. Igual que la anterior, otra variacin de la misma idea consiste en centrar todo el sistema en torno a la
simulacin
del entorno virtual en el que se
62
Captulo 3.
desarrolla el aprendizaje (Munro et al., 1997, 1999). En este caso, las vistas son las distintas posibles representaciones del entorno. Como veremos en el captulo 6, nuestro sistema JV M utiliza tambin la misma idea de modelo y vista.
3.3.3.
Arquitectura basada en agentes
La arquitectura clsica divide el problema de crear un sistema de tutora inteligente en cuatro mdulos claramente diferenciados con unas tareas asignadas perfectamente delimitadas. Sin embargo, el desarrollo de estos sistemas es cada vez ms complejo, especialmente cuando se le aaden entornos virtuales, por lo que se necesitan otras soluciones tomadas de la Ingeniera del Software. Una de las soluciones es recurrir a la aproximacin basada en agentes (Giraa y Viccari, 1998). En realidad los sistemas que siguen esta alternativa suelen ser variaciones de la arquitectura clsica, pero donde cada uno de los mdulos es convertido en uno o varios agentes especializados que implementan la misma funcionalidad. En ese caso, los agentes se comunican entre s para conseguir la funcionalidad completa usando mecanismos lo que Giraa y Viccari llaman
ad hoc
o plataformas de agentes como JADE (Bellifemine et al., 2001a,b), creando
sociedad interna
del sistema. A pesar de la
existencia de esta sociedad, desde el punto de vista del usuario el sistema es una aplicacin indivisible, igual que lo era con la arquitectura clsica. El uso de tecnologa de agentes en las arquitecturas de ITSs va de la mano del uso de agentes pedaggicos animados. La mayora de los sistemas que incluyen este tipo de agentes dicen estar fundamentados en una arquitectura basada en agentes. Por eso, existe el peligro de confundir el signicado de la palabra agente, ya que en unos casos se referir a alguno de los componentes del sistema, mientras que en otros se referir al personaje virtual que hace de tutor y todo lo que lleva detrs. En el caso de estos dos tipos de agentes, se habla de que en el sistema existen dos sociedades distintas, la
interna
comentada antes, y la
sociedad externa
sociedad
formada entre los agentes
virtuales cuando se comunican a travs del entorno virtual; a diferencia de la primera, esta ltima s es apreciable por el usuario. Como ejemplo de este tipo de arquitecturas podemos nombrar a Reyes y Sison (2000) donde todos los componentes son agentes, y a de Antonio et al. (2005). En sta ltima, cada uno de los mdulos de la arquitectura clsica de la seccin 3.3.1 pasa a ser un agente; adems, permite mltiples estudiantes trabajando juntos, cada uno con su agente de comunicacin (haciendo las veces de mdulo de comunicacin). Todos estos agentes se conectan con un agente central que controla la comunicacin completa, y que es el nico que se comunica con los agentes responsables de la tutora, modelo de los estudiantes y conocimiento del dominio.
3.4. Arquitectura de entornos virtuales con agentes
63
sensores percepcin entorno acciones ? agente
actuadores
Figura 3.3: Estructura de un agente simple (Russell y Norvig, 1995)

La construccin de un agente pedaggico animado inmerso en un entorno virtual tiene las dicultades tpicas de la construccin de agentes, de las aplicaciones de realidad virtual y de los sistemas de tutora inteligentes (ITSs). La construccin de ITSs ya ha sido tratada en la seccin anterior, y la construccin de entornos virtuales ha sido tratada en el captulo anterior, dentro de las arquitecturas de videojuegos. En esta seccin mostramos ejemplos de arquitecturas diseadas para aadir a los entornos virtuales agentes en general, mientras que en la seccin siguiente abordaremos los agentes pedaggicos. En realidad, los agentes en entornos virtuales recuerdan mucho a los caracteres no jugador (NPCs) controlados por la inteligencia articial de un videojuego. Sin embargo, para su implementacin no se utiliza tecnologa de agentes, por lo que desde el punto de vista del desarrollador son distintos. Cuando se habla de agentes en general, se piensa en entidades software que captan el entorno por medio de sensores y que actan sobre l a travs de una serie de actuadores (Russell y Norvig, 1995; Wooldridge, 1999). Un esquema simplista aparece en la gura 3.3. Un aspecto importante es la
autonoma,
que marca la diferencia entre
los programas tradicionales y los agentes (Franklin y Graesser, 1996). Segn Franklin y Graesser, un agente autnomo es un sistema situado dentro de un entorno del que forma parte. A lo largo del tiempo, el agente va percibiendo y actuando sobre l. Sus acciones estn dirigidas hacia la consecucin de una lista de objetivos. Las acciones son elegidas de tal forma que las situaciones futuras a las que se llega con ellas estn ms cerca del objetivo nal. En la gura 3.3, el signo de interrogacin simboliza el mdulo estratgico del agente que decide qu acciones realizar en el entorno dependiendo de lo percibido. La funcin del diseador de la inteligencia articial consiste, precisamente, en disear esa funcin que mapea las percepciones en acciones. Los agentes ms simples tendrn una simple batera de reglas condicinaccin;
64
Captulo 3.
los agentes ms sosticados mantendrn un estado interno, y decidirn sus acciones basndose en objetivos, aplicando bsqueda y planicacin. Cuando el agente tiene una representacin virtual en forma de avatar dentro de un entorno tridimensional, las acciones tienen que verse reejadas en ese personaje. Esto puede llegar al extremo de Thalmann (2001), donde la comunicacin entre los agentes (avatares virtuales)
no
se realiza utilizando
los mtodos tpicos de comunicacin entre agentes, sino que un agente se comunica con otro cambiando la forma de actuar de su avatar. El segundo avatar percibir en el entorno ese comportamiento, y lo interpretar como un mensaje. Uno de los retos ms importantes para estos sistemas es la denicin del interfaz entre la parte del agente que toma las decisiones y la parte responsable de animar su personaje. En el siguiente apartado trataremos algunos de los aspectos generales, para posteriormente describir la arquitectura de algunos sistemas que utilizan entornos virtuales con agentes animados.
3.4.1.
Interfaz entre el agente y el entorno
Como ya hemos dicho, un agente inteligente observa el entorno, guarda una representacin interna del mismo, y decide qu operaciones ejecutar sobre l para realizar las tareas para las que ha sido diseado. En los agentes en general, el nmero de actuadores que el mdulo estratgico tiene disponibles limita las acciones que puede realizar sobre el entorno en el que se encuentra. Cuando el agente est inmerso, o mejor dicho, controla un avatar que aparece inmerso en un entorno virtual, otra de las tareas del agente es el control del propio personaje. A la hora de pensar en la arquitectura, debe dejarse claro el conjunto de
primitivas
que el agente
tiene disponibles para controlarlo. Dependiendo de su nmero y complejidad, el agente podr ser ms o menos completo. Por ejemplo, si el avatar no es capaz de cambiar el gesto de la cara (para sonreir, o mover los ojos para mirar a otro sitio), no tiene sentido aadir emociones o control de la mirada al agente. Algo parecido ocurre con los sensores. Dependiendo de la cantidad de cosas que el agente pueda percibir del mundo, su comportamiento podr adecuarse convenientemente a ms o menos estados del mundo. Cuando se disea el sistema, se debe tener claro a qu tipo de situaciones se desea que el agente pueda reaccionar para que el entorno virtual pueda comunicrselo a travs de sus sensores. Cuando estudiemos los agentes pedaggicos en la seccin 3.5, listaremos los tipos de percepcin ms importantes que debera tener uno de estos agentes. Por el momento, nos limitaremos a decir que un agente inmerso en un entorno virtual necesita, al menos, conocer el entorno por el que se est moviendo para poder ir de un sitio a otro sin colisionar con nada, y conocer
65
dnde estn los objetos con los que puede interaccionar, es decir, en qu lugares estn los actuadores. Para el primer cometido hay tres aproximaciones, que explicamos por orden creciente de complejidad:
El agente no necesita saber cmo est organizado el entorno virtual. Cuando quiere realizar alguna accin sobre el mundo, se lo comunica al motor responsable de la apariencia del mundo virtual, y l se encarga de mover al avatar y hacerle interactuar con los objetos adecuados. Tiene la ventaja de que un cambio en el aspecto del mundo virtual no requiere una modicacin en el agente. Si hacemos la analoga agente virtual personaje no jugador en un videojuego, este modo de implementar el movimiento es utilizado en mucho de ellos (por ejemplo, el Unreal Tournament de Epic Games (1999)), en donde el el motor de juego subyacente.
comportamiento
se
dene en base a primitivas de movimiento de alto nivel, resueltas por
El agente nace conociendo dnde estn los objetos con los que interacta. El mtodo ms sencillo es representar este conocimiento en forma de grafo de adyacencia. Cada nodo del grafo representa un punto (localizacin) en el entorno virtual, y cada arista indica que se puede andar entre los dos nodos sin peligro de colisionar. Para ir de un lugar a otro se utiliza el algoritmo de Dijkstra (Dijkstra, 1959), o cualquier otro algoritmo de bsqueda. Este mtodo funciona nicamente para mundos estticos, o con cambios localizados que no hagan aparecer objetos en medio de las rutas entre localizaciones, que hagan variar el grafo. Lo han utilizado, por ejemplo, dos Santos y Osrio (2004b) en su entorno
AdapTIVE.
El agente no conoce la geografa del mundo. Tcnicamente, es posible extraer el plano o mapa de un laberinto utilizando las imgenes generadas por el motor grco. Utilizando mtodos de visin sinttica, Monsieurs et al. (1999) analizan las imgenes renderizadas desde el punto de vista del agente, para averiguar la distribucin de las paredes. En realidad, en ese sistema, la inteligencia de la aplicacin se centra en ser capaces de averiguar ese mapa para poder navegar por un entorno completamente desconocido. Si bien tiene una aplicacin prctica en otras reas (robtica), en agentes pedaggicos no tiene sentido utilizar estas tcnicas, pues el avatar tendra primero que aprender la estructura del mundo; al n y al cabo, no tiene sentido pensar que un tutor humano tenga primero que aprender dnde estn las cosas, antes de poder ensear como utilizarlas.
66
Captulo 3.
Visualizacin tridimensional
Modelo fsico
Avatar 1
Figura 2001b) 3.4: Arquitectura
...
de
Agente 1
SimHuman
...
Objeto 1
y Panayiotopoulos,
(Vosinakis
3.4.2.
Ejemplos de agentes en entornos virtuales

Intelligent Virtual Agents, IVA). En muchos casos, el
Durante los ltimos aos, existe mucho movimiento en el rea de agentes virtuales inteligentes (o inters se centra en dar una apariencia ms humana a los avatares controlados por tales agentes. A este respecto, existen muchos trabajos sobre emociones, mejora de animaciones de avatares, del clculo de rutas para hacerlas ms humanas, mantenimiento del contacto visual entre el agente y el usuario, etc. Nuestro inters se centra sin embargo en la arquitectura software del sistema completo que permite a los agentes interactuar con el entorno virtual y que establece el tipo de cosas que percibirn y cmo podrn actuar sobre el mundo que habitan. En el captulo anterior veamos que en el mundo de los videojuegos no se ha venido haciendo tan explcita la divisin entre el agente o entidad software que dene el comportamiento de un personaje no jugador y la representacin tridimensional del mismo.. En este apartado veremos dos ejemplos de entornos virtuales que incorporan agentes inteligentes, para ver cmo se hace esta divisin fuera del contexto de los videojuegos.
3.4.2.1. SimHuman
SimHuman (Vosinakis y Panayiotopoulos, 2001b) es una plataforma para la generacin de entornos tridimensionales en tiempo real con agentes virtuales. Permite denir escenas en tres dimensiones con agentes inteligentes y avatares controlados por el usuario. De esta forma, sirve como base a aplicaciones de entornos virtuales y sistemas de simulacin. Para representar el mundo, tanto los objetos estticos como los avatares estn almacenados en forma de coleccin de polgonos que son dibujados utilizando un mdulo especco de visualizacin. Para los personajes, adems, se tiene una biblioteca de animaciones, as como su esqueleto para poder uti-
67
Entorno
Usuario
Agente virtual
Objetivos Creencias Acciones posibles Control de movimiento
Avatar
Control de comportamiento
Control de movimiento
Geometra
Esqueleto
Animaciones
Geometra
Esqueleto
Animaciones
Figura 3.5: Estructura interna de un avatar en SimHuman (Vosinakis y Panayiotopoulos, 2001b)
lizar cinemtica inversa y ejecutar animaciones dinmicas que permiten, por ejemplo, coger objetos en movimiento (Vosinakis y Panayiotopoulos, 2001a). Esta representacin visual se ve complementada con un motor fsico que calcula en cada fotograma la nueva posicin de cada objeto, de acuerdo con su masa, posicin y velocidad actual. El mdulo adems, posee un sistema de deteccin de colisiones que detecta si dos objetos entran en contacto para alterar sus velocidades. En la arquitectura de SimHuman (ver gura 3.4), el tercer y ltimo componente es el control de cada uno de los objetos, tanto los estticos como los dinmicos. En el caso de los avatares, el control se preocupa de cambiar la animacin dependiendo del momento. Con esto, se consigue un mundo virtual poblado con una serie de avatares con apariencia humana, movimientos coherentes y que puede ejecutar una serie de acciones en un entorno tridimensional. Cada uno de los avatares que aparecen puede ser controlado por un usuario humano o por un agente. La estructura interna de cada uno de los dos tipos aparece en la gura 3.5. Independientemente de quin lo controle, cada avatar tiene un mdulo encargado de su movimiento (el motion librera de animaciones. Cuando un usuario controla uno de estos personajes, las rdenes que emite a travs del dispositivo de entrada son enviadas al controlador de movimiento que desplaza al avatar de acuerdo a ellas. Cuando el avatar es manejado por un agente inteligente, el controlador
controller ),
que tiene tres fuentes de datos: el chero con la geometra, el esqueleto y la
68
Captulo 3.
Agente 1 Agente 2 ... Agente n Mundo
Vista 1 Vista 2 ... Vista n
Figura 3.6: Estructura de mVital, segn Anastassakis et al. (2001a)
del comportamiento ( behavioural
controller )
es el que emite las rdenes.
Este controlador se crea utilizando tcnicas de programacin de agentes. En particular, el agente almacena una representacin simblica del mundo, y utiliza el ciclo sentirdecidiractuar para funcionar. La parte inteligente del agente posee un planicador en Prolog que decide qu acciones ejecutar. Su misin es elaborar los planes o secuencias de acciones que se irn ejecutando en orden. Adems, genera el estado del mundo que espera encontrar cuando termine cada una de ellas. De esta forma, si se producen cambios inesperados no producidos por sus propias acciones, puede reaccionar ante ellos. La arquitectura est pensada para que el ciclo sentirdecidiractuar se ejecute en paralelo a la simulacin del entorno virtual. De esta forma, si el planicador consume mucho tiempo decidiendo qu accin ejecutar cuando se acabe la actual, no bloquea el mundo virtual que est siendo generado.
3.4.2.2. mVITAL
La arquitectura SimHuman, aunque tiene cierto cuidado en denir cmo est implementado cada uno de los agentes inteligentes, est ms centrada en la parte de los entornos virtuales inteligentes (IVEs), de forma que permite implementar sistemas habitados por actores con apariencia humana que se mueven de forma creble en tiempo real. El mismo grupo de investigacin de SimHuman, desarroll casi simultneamente mVITAL (Anastassakis et al., 2001a), que permite crear sistemas multiagente, y aadirlos a un entorno virtual. Al contrario que SimHuman, se centran ms en la inteligencia y razonamiento. mVITAL surge como una mezcla de dos arquitecturas desarrolladas por el mismo equipo, la arquitectura DIVA (Vosinakis et al., 1999), y la arquitectura VITAL (Anastassakis et al., 2001b), esta ltima preparada para un nico agente.
69
Existen tres componentes bsicos que son ejecutados como distintas aplicaciones y conectados mediante sockets siguiendo la losofa cliente/servidor. Los componentes, que pueden verse en la gura 3.6, son el servidor del mundo, los agentes y las vistas o visores. Cada uno de los componentes almacena una representacin del mundo, que puede ser o bien orientada a objetos o simblica. El primer tipo de representacin trata el entorno como una serie de regiones interconectadas que contienen uno o ms objetos. A su vez, cada objeto tiene un nombre, una clase a la que pertenece y una serie de propiedades. Incluso, los mismos agentes se consideran objetos en este tipo de representacin. La representacin simblica utiliza una sintaxis parecida a la de los lenguajes de programacin lgicos, como por ejemplo indica que el
at(Objeto, X, Y), que Objeto est en la posicin (X, Y). Esta representacin es la uti-
lizada por los agentes, ya que su motor de inferencia est hecho en Prolog, igual que en SimHuman. El componente central de la arquitectura es el servidor del mundo, que representa el entorno virtual dentro del que operan los agentes. Se encarga de coordinar el intercambio de datos entre el resto de la aplicacin, asegurando que la percepcin que tienen los agentes del mundo coincide con la representacin visual que aparece en los visores. Para eso, manda la informacin sensorial a cada uno de los agentes conectados al entorno, y la informacin visual a cada una de las vistas. Por otro lado, cada agente que ejecuta una operacin enva la accin al servidor, para que ste la propague al resto de los elementos. La vista o visor encapsula la funcionalidad de visualizacin del sistema. Mantiene un modelo orientado a objetos del entorno, y recibe las noticaciones de cambios en el mundo desde el servidor. El agente es el componente ms importante de la arquitectura, y es el que introduce inteligencia en el sistema, para mover a los actores por el mundo. Al igual que en SimHuman, los agentes utilizan el ciclo sentirdecidiractuar. En la primera fase, el agente solicita al servidor del mundo una representacin pseudosimblica del estado, que es procesada y aadida a la base de conocimiento del agente. En la fase de decisin, el motor lgico razona sobre los contenidos de la base de conocimiento y crea un plan para conseguir alguno de los objetivos del agente. Por ltimo, en la fase de actuacin, la siguiente accin a realizar se manda al servidor del mundo, tambin en forma pseudosimblica, y se actualiza la base de conocimiento para que reeje la accin que se ha hecho. Las posibles acciones que el agente puede hacer estn prejadas: sentir (que es enviada al servidor del mundo al principio del ciclo), moverse, coger un objeto, soltarlo y usarlo. Toda la comunicacin con el servidor del mundo consiste en una de estas acciones, aunque el signicado especco puede variar en cada caso. As por ejemplo, utilizar una puerta puede ser abrirla o cerrarla,
70
Captulo 3.
mientras que utilizar un interruptor puede signicar encender la luz. En JV M, el sistema que describiremos en el captulo 6 aparecen acciones muy parecidas a estas (seccin 6.4).
3.5. Agentes pedaggicos

Como ya se ha dicho, los agentes pedaggicos surgen al unir dos reas de investigacin en principio independientes: los agentes animados que mejoran el interfaz de una aplicacin (Hayes-Roth y Doyle, 1998) y el software educativo (Carbonell, 1970; Sleeman y Brown, 1982; Wenger, 1987). La combinacin resultante son los agentes pedaggicos animados, denidos por Johnson et al. (2000) como agentes autnomos que dan soporte en el aprendizaje interactuando con los estudiantes en los entornos de enseanza interactivos. Los agentes pedaggicos monitorizan el estado entorno, eminentemente dinmico, buscando las oportunidades de enseanza que puedan surgir. Dependiendo de su complejidad, pueden ser utilizados para aprendizaje tanto individual como cooperativo, soportar interacciones complejas con el estudiante, ayudar en su motivacin, etc. En la seccin 3.2.5 veamos algunas de las ventajas que aportan a los sistemas educativos. En este momento nos planteamos qu tipo de arquitectura software debe implementarse para conseguir toda esa funcionalidad. Para empezar, describiremos qu necesidades especiales tienen los agentes pedaggicos animados que no presentaban los agentes inteligentes vistos en la seccin anterior, de forma que entendamos cmo afecta al interfaz que existir entre l y el entorno. Posteriormente pasaremos a describir la arquitectura tpica ms utilizada de agentes pedaggicos, llamada por Devedzic y Harrer (2005) el patrn gura 3.1.
generalizado de agentes pedaggicos.
Por ltimo
describiremos la arquitectura Steve, el agente pedaggico que apareca en la
3.5.1.
Interfaz entre el agente pedaggico y el entorno
En la seccin 3.4.1 describamos las generalidades del interfaz entre un entorno virtual y un agente inmerso en l. En esta seccin nos centramos en los agentes pedaggicos animados, que tienen algunas necesidades especiales que no tienen por qu necesitar los agentes animados de otros contextos. En los agentes pedaggicos animados, el avatar se encuentra inmerso en el entorno de aprendizaje que comparte con el estudiante. Igual que para los avatares de otras aplicaciones, la capacidad de percepcin limita el conocimiento que el agente tiene acerca de sus alrededores, y el conjunto de acciones que es capaz de realizar coartan su comportamiento y capacidad pedaggica. Por ejemplo, en
Herman the Bug
(Stone y Lester, 1998), el
agente es capaz de elegir la msica de fondo que sonar para acompaar
71
a sus acciones lo que, aunque no signica un incremento en su capacidad pedaggica, s aade en cierto sentido credibilidad y da ms o menos nivel de trascendencia a sus acciones, lo que al n y al cabo dene parte de su comportamiento. Johnson et al. (2000) lista de las percepciones posibles que puede necesitar un agente pedaggico:
Estado del entorno:
el agente debe conocer el estado en el que se
mueve. Para eso puede preguntrselo a algn mdulo responsable de la simulacin del mundo, o puede ser informado cada vez que algn atributo de algn objeto cambia.
Acciones del estudiante: cuando est monitorizando, debe percibir

cundo el estudiante realiza alguna accin sobre el entorno. De esta forma no tiene que inferir las acciones que ha realizado utilizando los cambios en el mundo virtual, y puede compararlas con las que habra hecho l en su lugar.
Acciones del agente:
igual que con el estudiante, el agente debe
percibir cundo el avatar que le representa en el entorno ha realizado alguna accin, debido a que en muchos casos, el agente manda las acciones a una capa que controla sus movimientos, y tiene que esperar a que su personaje en el mundo termine de realizar la accin para empezar con la siguiente.
Preguntas del usuario: en ciertas ocasiones, el estudiante puede preguntar al agente qu accin debera ejecutar a continuacin y por qu.
Posicin del estudiante y direccin en la que mira: de esta forma,

el agente puede modicar su posicin para que el usuario le vea mejor. Adems, as puede saber si el usuario est viendo el objeto que va a utilizar seguidamente en su explicacin, para en caso contrario esperar a que entre en su campo de visin antes de proseguir el discurso.
Eventos de generacin de voz: en agentes sosticados que poseen

generacin de discurso a partir de textos, puede ser interesante recibir mensajes del generador para sincronizar la posicin de los labios en cada fonema emitido.
Frases del estudiante:
en ciertos sistemas, el alumno puede comu-
nicarse con el agente mediante la voz. Un sistema de reconocimiento indicar al tutor virtual la pregunta que el usuario ha hecho. Adems, cuando la persona empieza a hablar, el intrprete, aunque obviamente an no puede decidir qu es lo que el usuario dice, puede mandar al agente un mensaje de aviso, para que ste dirija su atencin al usuario, y le mire.
72
Captulo 3.
Para alterar el mundo por el que se mueven, los agentes pedaggicos necesitan un conjunto de acciones motoras. Normalmente estas acciones caen dentro de una de estas tres categoras: control del cuerpo del avatar, control del entorno de aprendizaje y habla. El movimiento del cuerpo del personaje puede consistir simplemente en reproducir secuencias de vdeo grabadas previamente, o descomponerse en acciones primitivas como expresiones faciales, manipulacin de objetos y desplazamientos de un sitio a otro. El control del entorno de aprendizaje son aquellas manipulaciones que el avatar realiza en l. Por ejemplo, cuando el avatar se acerca a un botn y lo pulsa, se debe informar al simulador del mundo que ese botn ha sido presionado, para que se cambie su estado de forma acorde a las reglas que lo rigen; de esta forma, si el botn encenda una luz, el simulador deber hacer que la luz se ilumine, y mandar el cambio de estado al agente. Las acciones sobre el entorno no tienen por qu estar restringidas a acciones fsicas; por ejemplo el cambio de la msica de fondo que realiza (Stone y Lester, 1998) entra dentro de esta categora. Por ltimo, el habla es creada tpicamente como una cadena, que puede enviarse a un sintetizador de voz para que el estudiante lo escuche, o se le presenta como texto en la pantalla.
Herman the Bug
3.5.2.
Arquitectura de ITSs con agentes pedaggicos
Como agente que habita en un entorno virtual, un agente pedaggico animado debe ser capaz de interactuar con el entorno, por lo que se le presentan los mismos problemas o cuestiones que plantebamos en la seccin 3.4 al hablar de agentes en entornos virtuales generales. Por ello, todos los agentes pedaggicos analizados poseen al menos un componente encargado de la comunicacin. Dependiendo del sistema particular, la comunicacin estar integrada en un nico mdulo, o separada en dos, uno que agrupa las acciones que puede realizar el agente sobre el entorno (es decir, los actuadores), y otro que se encarga de la percepcin (sensores). El nivel de abstraccin de las acciones y percepciones depende, una vez ms, del sistema. En algunos casos se puede quedar en acciones de alto nivel como escribir un mensaje, mostrar una pista o actualizar una barra de progreso (Devedzic y Harrer, 2005), mientras que en otros casos consistir en rdenes de bajo nivel al avatar, como ocurra en SimHuman (Vosinakis y Panayiotopoulos, 2001b) o hace Steve (Johnson et al., 1998). Sea como sea, el subsistema de comunicacin abstrae todo el entorno virtual a la parte
cognitiva
del agente, la responsable de decidir qu acciones
realizar en l dependiendo de lo percibido. La mayora de los agentes pedaggicos hacen uso de todos los mdulos tpicos de la arquitectura bsica de ITSs. Al n y al cabo, necesitan conocer
73
Base de conocimiento
Aprendizaje
Gestor de la base de conocimiento
Mdulo pedaggico
Motor de comportamiento
Estado
Comunicacin
Figura 3.7: Arquitectura tpica de un agente pedaggico, segn Devedzic y Harrer (2005)
el conocimiento del dominio para poder ensearlo y el modelo del usuario y distintas estrategias pedaggicas para poder amoldarse al estudiante. En el patrn generalizado de agentes pedaggicos ( Generalized Pedagogical Agent , GPA) expuesto por Devedzic y Harrer (2005) estos tres tipos de conocimiento quedan agrupados en un nico mdulo del agente pedaggico que ellos llaman Knowledge
Base . En la gura 3.7, donde aparece el esque-
ma completo del patrn con los mdulos opcionales en lneas discontinuas, este conocimiento aparece bajo el nombre base de conocimiento. Particularmente, no estamos de acuerdo con ellos. Desde nuestro punto de vista, y despus del anlisis de la arquitectura de otros agentes pedaggicos y de nuestro propio sistema, el ITS el resto de elementos del sistema. A este respecto, la arquitectura de un ITS al que se le ha aadido un agente pedaggico debe seguir, a lo sumo, la arquitectura Modelo de conocimientoVista descrita en la seccin 3.3.2. De acuerdo a los sistemas estudiados, el agente pedaggico debe jugar el papel de Vista de al menos el modelo del estudiante y del conocimiento del dominio. Gracias a eso, su mdulo cognitivo posee una
no
termina en el agente pedaggico, por
lo que todo ese conocimiento debe ser externo a l, y estar disponible para
proyeccin
del conocimiento del ITS completo que
necesita. De hecho, el GPA de Devedzic y Harrer (2005) incluye un mdulo gestor de esa base de conocimiento (knowledge
base manager ), que adapta
el
conocimiento segn las necesidades del resto de mdulos del agente. Por otra parte, no consideramos obligatoria la inclusin del conocimiento
74
Captulo 3.
de tutora en el agente, ya que es habitual que ste incluya conocimiento especco sobre su forma de actuar. De hecho, en el GPA el mdulo pedaggico aparece explcitamente fuera del mdulo de la base de conocimiento, bajo el desafortunado nombre de problem
solver . Su misin es decidir si debe o no
entrar en accin, cmo hacerlo, a qu estmulos reaccionar, etc. El resto de mdulos que componen la parte cognitiva del agente depende de las capacidades que se le quieran aadir. La mayora tienen algn tipo de estado mental que determina sus acciones. Pueden tener un planicador para generar las acciones a realizar en un futuro y poder compararlas con las del estudiante, pueden tener un mdulo encargado de generar emociones, o incluso un mdulo de aprendizaje mquina que les permite modicar su conocimiento con el tiempo.
3.5.3.
Ejemplo de agentes pedaggicos: Steve
En la seccin 3.2.5 ya salieron algunos ejemplos de agentes pedaggicos y los relacionamos con las capacidades que tenan. En este apartado vamos a detallar la arquitectura completa de Steve ( Soar
Environments ).
Training Expert for Virtual
Hemos elegido analizar Steve en vez de otro agente debido
a que fue uno de los primeros agentes pedaggicos en desarrollarse, su arquitectura est muy documentada, y posee muchas de las capacidades descritas en la seccin 3.2.5, en la que listbamos algunos de los tipos de interaccin que permiten los agentes pedaggicos animados. El propsito de Steve es interactuar con estudiantes en un entorno virtual inmersivo. Se ha utilizado para entrenamiento de tareas navales. Tiene capacidades pedaggicas que le permiten responder a preguntas del estudiante como qu debo hacer ahora? y por qu?. Tambin puede demostrar las acciones l mismo y usar la mirada y gestos para dirigir la atencin del estudiante. El alumno comparte el entorno virtual con el agente, de forma que mientras el usuario est interactuando con los objetos, Steve aparece a su lado observando. Cuando el usuario no sabe cmo seguir, puede preguntarle, o pedirle que acabe l la tarea. En ese caso, segn va ejecutando cada accin, va explicando cada paso utilizando un generador de voz. En cualquier momento, el usuario puede pararle para preguntar las razones de una accin o para pedirle acabar por l mismo el ejercicio.
3.5.3.1. Arquitectura del sistema

El sistema consiste en varios componentes ejecutndose en paralelo (en distintos procesos e incluso distintas mquinas) conectados a travs de un sistema de comunicacin que distribuye los mensajes (ver gura 3.8). Resulta curioso ver que en Steve los componentes
no
son los mdulos de la
arquitectura clsica de ITSs que veamos en la seccin 3.3.1, sino que son los
75
Interfaz de usuario Interfaz visual Efectos de sonido Generador de voz Reconocedor de voz
Bus de comunicaciones
Simulador
Simulador
Figura 3.8: Arquitectura de Steve, segn Rickel y Johnson (1999)
siguientes: Simulador del mundo: controla el comportamiento de los objetos del mundo virtual. Cada objeto posee un conjunto de atributos que denen tanto su apariencia fsica en el entorno como su comportamiento. Para cada escenario particular, se puede programar el comportamiento de cada objeto con una serie de reglas y restricciones que pueden depender de otros objetos. Puede recibir mensajes solicitando cambios de atributos, lo que puede provocar que otros objetos del entorno deban cambiar su estado. En ese caso, propaga los cambios al resto de componentes. Hay que hacer notar que el simulador se encarga nicamente de controlar el estado de los objetos, no de su apariencia. Interfaz del usuario: por cada componente humano existe un interfaz del usuario que permite ver y manipular el mundo virtual. Se compone de un visor a travs del cual el usuario puede ver el entorno, un sistema de audio para percibir los sonidos, un generador de voz que convierte a sonido audible el texto dicho por el agente pedaggico, y un analizador de voz que reconoce rdenes sencillas (como qu debo hacer ahora?). Adems de este analizador, el visor tambin puede captar la entrada del usuario para interpretar cuando quiere interactuar con alguno de los objetos virtuales. Agente pedaggico: Steve es considerado un componente separado. Dada su importancia, su estructura la veremos en el apartado siguiente. Para unir a estos tres mdulos existe, como dijimos, un bus de comunicacin, que es capaz de enviar distintos tipos de mensajes. Cada uno de los componentes conectados a l puede declarar explcitamente estar interesado en unos tipos especcos, y el bus ltrar el resto.
76
Captulo 3.
Steve
Mdulo cognitivo Conocimiento del dominio Funciones pedaggicas SOAR Percepciones Percepcin Filtrado y ensamblado Monitorizacin de eventos del entorno Notificacin de eventos Bus de comunicaciones
Comandos motores Mdulo motor Traduccin a movimientos del avatar Difusin al exterior
Figura 3.9: Estructura interna de Steve, segn Johnson et al. (1998)
3.5.3.2. Arquitectura de Steve

Existen tres mdulos distintos, el mdulo de percepcin, el de accin (o movimiento), y el mdulo cognitivo, mostrados en la gura 3.9. El mdulo de percepcin se encarga de percibir el estado del simulador. Para eso recibe los mensajes que provienen del simulador y los guarda en un conjunto de pares atributovalor. Adems, tambin es responsable de almacenar dnde est cada uno de los objetos del mundo as como la posicin del propio avatar y del estudiante. Una ltima atribucin a este mdulo es conocer qu objetos estn dentro del campo de visin del usuario. De esta forma, el mdulo cognitivo podr saber, durante las demostraciones, si el estudiante est mirando los objetos con los que l est operando. El mdulo responsable de las acciones del agente descompone en acciones primitivas los deseos del mdulo cognitivo, y los enva a los visores de los estudiantes a travs del bus para que estos cambien la apariencia de Steve en el visor del usuario. Las acciones recibidas desde el mdulo cognitivo son por ejemplo decir una frase, moverse a un objeto o mirarlo, mover la cabeza para mostrar agrado, apuntar hacia un objeto o manipularlo. El mdulo las traduce a tres tipos de mensajes: aquellos dirigidos al visor para la animacin del avatar, mensajes al simulador del mundo para que cambie el estado de algn objeto, o mensajes al generador de voz de los interfaces de usuario para dar explicaciones. El mdulo cognitivo es el ms importante. Est construido sobre SOAR (Laird et al., 1987) para simular el conocimiento. Dado que SOAR soporta el modelado jerrquico de tareas, es adecuado para el modelado dirigido por objetivos y comportamientos reactivo en entornos virtuales. Adems, al incorporar un mecanismo de aprendizaje, permite mejorar el rendimiento del agente con el tiempo.
Resumen
77
Utilizando el sistema de razonamiento de SOAR, se crean las capacidades pedaggicas del agente, independientes del dominio enseado. La capa pedaggica que aparece en la gura 3.9 crea un lenguaje especco sencillo (que posteriormente traduce a reglas SOAR), con el que se puede denir el conocimiento del dominio, que en el caso de Steve es el modo en el que hay que ejecutar cada una de las tareas en el simulador. Esas tareas se representan como una jerarqua de planes; cada tarea es un conjunto de pasos que pueden ser o acciones primitivas o acciones compuestas, responsables de la estructura jerrquica. Entre los distintos pasos de una tarea, pueden existir restricciones de orden, deniendo un orden parcial entre los pasos. Adems, cada paso posee informacin relativa al objetivo del paso dentro de la tarea. Cuando el mdulo cognitivo utilizando el motor de razonamiento de SOAR y la capa pedaggica planica una tarea, es capaz de tener en cuenta las restricciones anteriores, y generar las explicaciones para cada paso si es preguntado.
Resumen
Despus de ver en el captulo anterior la forma en la que se estructuran los videojuegos, este captulo se centra en las arquitecturas de los programas educativos. Despus de una breve introduccin histrica y una descripcin de las ventajas de utilizar entornos de aprendizaje inmersivos, en la seccin 3.3 hemos analizado los componente ms comunes que presentan los sistemas de tutora inteligentes. En esta seccin hemos descrito tres arquitecturas tpicas: la arquitectura clsica, la basada en la pareja modelo de conocimientovista, y por ltimo la basada en agentes. Dado que los sistemas educativos que perseguimos tienen la capacidad de albergar agentes pedaggicos, hemos proseguido nuestro anlisis inspeccionando el tipo de problemas y soluciones encontradas en sistemas que presentan un entorno virtual inteligente al que se ha aadido un agente virtual. La seccin 3.5 termina el captulo centrndose en los sistemas de tutora inteligentes que han sido mejorados aadiendo algn agente pedaggico. Con estas bases, los captulos siguientes denirn una metodologa y una arquitectura que aune ambos mundos, para conseguir un modo eciente de implementar sistemas educativos basados en videojuegos.
Notas bibliogrcas
Dentro de la literatura sobre software educativo, el libro Wenger (1987) se ha convertido en un clsico en el mundo de los ITSs, al ser el primero que
78
Captulo 3.
estableci lo que en la seccin 3.3.1 hemos llamado
ITSs.
arquitectura clsica de
En cuanto a artculos relacionados con entornos virtuales inteligentes, un buen punto de partida son las actas de las distintas ediciones del congreso Intelligent Virtual Agents de periodicidad bianual, en aos impares. Algunas de las referencias incluidas en este captulo han sido publicadas en l. Relacionado con ITSs existe otro congreso bianual, esta vez en aos pares, Intelligent Tutoring Systems, en el que aparecen artculos relacionados con cada uno de los mdulos de la arquitectura explicada en este captulo, incluidos los agentes pedaggicos. Tampoco hay que olvidar el congreso internacional celebrado cada dos aos, International Conference on Articial Intelligence in Education, que celebr su decimotercera edicin en 2007, y la revista International Journal of Articial Intelligence in Education, en marcha desde 1989. Relacionado con el mdulo experto de la seccin 3.2.1 y las distintas posibilidades de expresar ese conocimiento, se puede consultar Gmez Martn, Gmez Martn, Gonzlez Calero y Jimnez Daz (2005b), en el que se analizan las repercusiones de esta representacin en el sistema completo. Por ltimo, relacionado con la mejora de los sistemas educativos incluyendo un agente pedaggico dentro de una historia interesante comentado en la seccin 3.2.5, se puede consultar Gmez Martn et al. (2004b).
Captulo 4
Una metodologa para la creacin de contenidos dirigidos por datos

Comienza por el comienzo dijo, muy gravemente, el Rey , y sigue hasta que llegues al nal; entonces paras.
Lewis Carroll, Alicia en el pas de las maravillas

En este captulo se presenta la metodologa de desarrollo de las aplicaciones educativas descritas en los captulos anteriores. Para eso, primero describimos a alto nivel las fases que deben seguirse durante su creacin y las herramientas de soporte necesarias. Tambin describimos nuestra propuesta de metodologa para la creacin de los contenidos que presenta la aplicacin. Por ltimo, el captulo describe dos tcnicas de uso del anlisis formal de conceptos para el anlisis de los contenidos creados.
4.1. Introduccin
Tras dos captulos en los que hemos visto las ideas generales del desarrollo de software de entretenimiento y de las aplicaciones educativas, este cuarto captulo se centra en una propuesta metodolgica para el desarrollo de sistemas educativos basados en videojuegos, centrndonos en la generacin del contenido. Lo primero que haremos es ver en qu fases est dividido el proceso de creacin de una de estas aplicaciones. El trabajo en estas fases, como veremos, involucra tanto trabajo de programacin como de creacin de contenido ldico y educativo. La divisin en fases, de hecho, la marca la evolucin de este ltimo aspecto, por lo que, a pesar de existir fases, no debe entenderse que 79
80
Captulo 4.
Metodologa de creacin de contenidos
la programacin sigue una metodologa
en cascada.
sta puede evolucionar
de manera independiente al contenido, utilizando cualquier metodologa de ingeniera del software, como el proceso unicado o las distintas metodologas giles. Dado que precisamente es el contenido del videojuego educativo la parte ms importante, nuestra propuesta metodolgica se centra en determinar el mejor mtodo para su creacin. Como veremos, cuando hablamos de estos contenidos nos estamos reriendo tanto a la forma del entorno virtual donde se desarrolla la accin como a los ejercicios y conceptos que estn siendo enseados. Posteriormente, realizamos un estudio sobre las herramientas que pueden utilizarse para dar soporte al desarrollo de este tipo de aplicaciones. En particular, describimos muchas de las utilidades que suelen ir asociadas a desarrollos software, analizando las distintas alternativas existentes para la implementacin de videojuegos educativos. Por ltimo, el captulo termina con la descripcin de dos tcnicas que hacen uso de Anlisis Formal de Conceptos para ayudar a comprobar si los contenidos creados con la metodologa propuesta son sucientes y si el nivelado del videojuego es correcto.
4.2. Proceso de creacin de un videojuego educativo

Los videojuegos son obras de creacin, que exigen la combinacin de talento, tcnica y creatividad (Arvalo, 2005). Por lo tanto, su creacin involucra, a grandes rasgos, la mezcla de dos procesos, el artstico y el tcnico. El primero es el responsable de los contenidos que aparecen en pantalla, la denicin de la jugabilidad, estructura de los mundos virtuales en que nos encontramos, etc., mientras que el segundo es el que desarrolla la tecnologa (software ) para mostrar esos contenidos. Si aadimos a los videojuegos la componente educativa, a este desarrollo hay que aadirle la creacin de los contenidos educativos que se pretenden ensear. Por lo tanto, durante el proceso de creacin de estas aplicaciones conviven tres mundos bien distintos:
Componente artstico : este componente suele junto de elementos estticos que aparecen en
entenderse como el conel entorno virtual, como
personajes o texturas. No obstante, tambin hay aqu que aadir la concepcin del juego, la denicin de la jugabilidad, guin y estructura de los entornos virtuales. De hecho, en la dcada de los 80, Crawford en su libro sobre el diseo de juegos, no dedicaba una atencin especial al primer tipo de contenido, y se limitaba a destacar la importancia del segundo.
Componente pedaggico :
es el responsable de decidir, por ejemplo, de
81
qu forma se van a presentar los contenidos o conceptos a ensear, cul es la forma ms efectiva de hacerlo para facilitar el aprendizaje, o el orden en el que se llevar a cabo.
Componente tcnico :
es la parte responsable de lidiar con la mquina
en la que se va a ejecutar la aplicacin, creando tanto las herramientas necesarias para ayudar a la construccin de los componentes anteriores, como la aplicacin que va a hacer uso de ellos. La creacin del contenido artstico y pedaggico est, por lo tanto, condicionada a la forma en la que se programe la aplicacin que utiliza ese contenido. Las secciones 4.3 y 4.4 detallan las alternativas existentes en videojuegos educativos, as como nuestra propuesta metodolgica. Las fases comnmente aceptadas en el desarrollo de un videojuego son las siguientes:
Concepto : en esta fase se dene la idea fundamental del juego. Empieza

con una simple frase que se va renando poco a poco. El grado de detalle alcanzado, no obstante, no es excesivo, para no cerrar posibilidades futuras poniendo detalles u opciones secundarias.
Preproduccin :
una vez denido el concepto, el siguiente paso es re-
narlo, haciendo una investigacin detallada sobre el tema elegido, para tener al menos un esbozo del guin y contexto histrico (si lo hay). Es en esta fase cuando se decide el aspecto visual que va a tener la aplicacin. Desde el punto de vista tcnico, en esta fase se realiza un anlisis de las libreras externas (o COTS, ver seccin 2.3.1) que se utilizarn para el desarrollo. Tambin es el momento de implementar distintos prototipos que ayudarn en la eleccin de esas libreras, y que valdrn como prueba de que las ideas de diseo creadas en la etapa anterior funcionan desde el punto de vista del entretenimiento. Al nal de la fase de preproduccin, se habrn desarrollado todas las piezas fundamentales de la aplicacin nal, como las herramientas de generacin de contenidos o exportadores, el motor grco o la parte bsica de la inteligencia articial.
Produccin :
en esta etapa, el equipo de desarrollo alcanza el tamao
mximo. Es cuando se desarrollan todos los contenidos que llevar la aplicacin nal. Eso requiere un amplio equipo de artistas y desarrolladores de niveles, que generan los componentes visuales (modelos) y los mapas o entornos en los que se desarrolla la accin. El equipo de programacin se encarga, de manera paralela, de renar las herramientas creadas en la etapa anterior, para amoldarlas a las nuevas necesidades que van surgiendo en su uso diario. Tambin se encarga de la creacin
82
Captulo 4.
de los comportamientos, gestin de entidades, etc., que irn en el juego. Al nal del proceso, se tiene una versin
completa
del juego, con todos
los mens, niveles, misiones y posibles traducciones.
Control de la calidad : en esta fase, previa al lanzamiento nal del juego,

se prueba intensivamente la aplicacin en busca de errores. Para ello gente tanto externa como interna al equipo de desarrollo comprueban si el juego funciona en todas las condiciones de ejecucin, en todas las plataformas y a lo largo de todos los niveles. Es normal que algunos de los errores detectados
no
se resuelvan por falta de tiempo. Al nal de
esta fase, se consigue la versin del juego que llegar a los compradores.
Mantenimiento y explotacin :
a pesar de que el desarrollo se hace in-
tentando asegurar la ausencia de errores, una vez terminado el juego, siempre se detectan algunos. En esta fase,
posterior
a la salida al mer-
cado, puede ser necesario sacar actualizaciones para arreglar tanto los problemas detectados posteriormente como los que quedaron sin resolver en la fase anterior al lanzamiento. En juegos multijugador masivos con mundos persistentes, que dependen de la existencia de un servidor para almacenar los datos, la etapa de mantenimiento es mucho ms larga que en otros juegos.
Para soportar todo este proceso, en un estudio de desarrollo hace falta una estructura de equipo clara. Son necesarios los departamentos tradicionales de direccin, gestin, recursos humanos y marketing, todos ellos externos al desarrollo de la aplicacin nal. Los departamentos que realmente implementan las fases anteriores son (i) el departamento de programacin, encargado de la creacin del motor de juego/tecnologa, herramientas y lgica del juego, (ii) el departamento grco, para todo el diseo artstico, modelado, texturado y animacin, y (iii) el departamento de diseo, que escribe y rena el documento que dene los elementos interactivos y narrativos, reglas, mecnicas y misiones. Existen dos departamentos adicionales que tambin intervienen en las fases anteriores, pero que habitualmente se consideran departamentos
versales
trans-
que trabajan simultneamente en todos los proyectos del estudio.
El primero de ellos es el departamento de sonido, que se encarga de disear el estilo y ambiente sonoro, componer las msicas y gestionar su grabacin; tambin es responsable del resto de efectos sonoros y voces. Un ltimo departamento es el responsable de las pruebas, conocido como el departamento de
QA
(del ingls,
quality assurance ). entretiene.
En realidad, aunque se dena explcitamente una fase para pruebas, stas tienen lugar a lo largo de todo el proceso de desarrollo. La ms importante es la comprobacin de si el videojuego de verdad Y dada su importancia, esta comprobacin se realiza desde el principio del proceso. Por
83
ejemplo, Crawford (1984) comentaba que del casi centenar de ideas de juego que haba tenido hasta ese momento (fase de concepto), haba explorado menos de 40, y nicamente ocho haban terminado en un juego desarrollado . Hoy da despus de la fase de preproduccin se prueba la jugabilidad utilizando prototipos, y se vuelve a estudiar la viabilidad del proyecto antes de entrar en la produccin. Una vez comenzada sta, las evaluaciones sobre la componente ldica del juego continan, y pueden llevar a cancelaciones de proyectos tardas si no se superan.
Si volvemos a las aplicaciones educativas sin componente ldico (es decir, que no pueden ser consideradas videojuegos), podemos hacer una analoga en el proceso de desarrollo:
Concepto :
consiste en establecer qu es lo que se quiere ensear. Dado
que normalmente las aplicaciones educativas se realizan por encargo, la eleccin del tema principal de la aplicacin vendr impuesta de antemano.
Preproduccin :
igual que en la construccin de un videojuego, en este
momento el equipo puede plantearse, si no viene impuesto por el cliente, el tipo de aplicacin que se construir. Dependiendo de la decisin tomada, se analizarn herramientas ya disponibles o se construirn herramientas propias para el desarrollo de la aplicacin completa. Por ejemplo, si se decide enmarcarse dentro del rea de
por ordenador
enseanza asistida
(CAI) que nombrbamos en la seccin 3.2, el equipo
puede decantarse por utilizar una herramienta ya consolidada como Macromedia AuthorWare (Adobe, 2006). Para otros desarrollos se puede plantear la creacin de herramientas propias. En esta fase se debe decidir con detalle de qu forma se van a presentar y a secuenciar los contenidos. Adems, si, por ejemplo, la aplicacin educativa va a consistir en un simulador, habr que desarrollar, al menos, la parte bsica de ste.
El proceso de desarrollo presentado por Crawford (1984) no es exactamente como el ex-
puesto aqu; en su caso, dena seis fases: concepto, preproduccin, diseo, pre-desarrollo, desarrollo, control de calidad y post-mortem. Como se puede ver, presta especial atencin al diseo del juego, al que dedica hasta tres fases antes de que el trabajo de programacin empiece. En particular, su primera fase consista en elegir el objetivo y ambientacin o tema del juego (
Choose a goal and a topic ), que podemos equiparar con nuestra fase de
concepto. En las dos fases siguientes se realiza una investigacin y preparacin sobre el tema y el diseo del juego, y no es hasta la cuarta fase cuando se realiza el diseo software (fase de pre-desarrollo) y programacin (fase de desarrollo). En nuestro modelo, tanto las dos fases especcas de diseo como las dos fases relacionadas con la programacin son ejecutadas en paralelo en las fases de preproduccin y produccin. Sus dos ltimas etapas son la control de calidad, y
post-mortem. El signicado de esta ltima fase no es el que se
entiende hoy en da, sino que consista simplemente en ver cmo evolucionaba el juego en el mercado, las opiniones de los crticos especializados y pblico en general.
84
Captulo 4.
Produccin :
es la fase en la que se sita el grueso de la creacin de
contenidos. Si las herramientas utilizadas tienen la madurez suciente, podrn utilizarse directamente, y la fase se limitar a la creacin de esos contenidos. Si las herramientas han sido desarrolladas especcamente para la aplicacin, es posible que requieran cambios.
Evaluacin de la aplicacin :
el propio
la evaluacin en este caso es doble. Hay en los estudiantes (Mark y Greer, 1993;
que comprobar (i) que la aplicacin funciona en todos los casos, (ii)
impacto educativo
Inoue, 2001).
Mantenimiento y explotacin : dependiendo de la aplicacin concreta la

etapa posterior al lanzamiento ser ms o menos importante y larga. Si la aplicacin genera registros durante la ejecucin, se pueden analizar estos para mejorar futuras versiones de la misma aplicacin o familia de aplicaciones. Tambin puede ser necesario revisar contenidos o arreglar errores. Algunos de los profesionales que eran necesarios para el desarrollo de videojuegos son tambin requeridos en la creacin de aplicaciones educativas. Por ejemplo, se utilizan programadores para desarrollar herramientas de creacin de contenidos o para programar extensiones (plug-in s) o retoques de las mismas. Si existe un componente de contenido multimedia, tambin se necesitarn grastas y expertos de sonido. Sin embargo, el departamento ms importante es el de expertos del dominio que son los que conocen el rea que se pretende ensear. stos son capaces de describir el contenido, y a veces incluso generarlo con las herramientas utilizadas en el desarrollo. Un equipo de psiclogos y pedagogos, adems, se asegura de que el orden en esa presentacin sea idneo para su asimilacin, al presentar una progresin de dicultad adecuada. Una vez detallados los procesos de desarrollo de videojuegos y aplicaciones educativas por separado, podemos destacar tres diferencias fundamentales: La cantidad de esfuerzo en programacin requerida: normalmente, los videojuegos requieren mucho ms trabajo de programacin que las aplicaciones educativas, en donde lo ms importante (especialmente en los CAI) es la generacin del contenido didctico. En muchas ocasiones, en la fase de produccin de la aplicacin educativa no es necesario programar, y se limita nicamente a crear esos contenidos. Los objetivos y momentos de la evaluacin de la aplicacin: el objetivo ms importante de la evaluacin de una aplicacin educativa es comprobar si sta realmente sirve para ensear al usuario/estudiante, por lo tanto debe hacerse principalmente una vez que sta est creada.
85
En un juego como hemos dicho anteriormente, la evaluacin realizada durante y despus de la produccin sirve principalmente para validar el buen comportamiento en ejecucin, pero la comprobacin de si ste
entretiene
se ha realizado mucho antes.
Los profesionales necesarios: en ambos procesos son necesarios programadores y grastas. Sin embargo, el papel del diseador del juego que detalla los niveles y misiones de un videojuego es sustituido por el del experto del dominio que dene los contenidos a presentar en la aplicacin educativa . El equipo de QA que en un videojuego comprueba si la dicultad se incrementa de manera gradual es sustituido por psiclogos y pedagogos que hacen lo propio con los contenidos educativos.
El proceso de creacin de un videojuego educativo pasa por uno de los pasos.
fusionar
ambos procesos en uno solo. En los siguientes apartados analizamos cada
4.2.1.
Concepto
En esta primera fase, los objetivos siguen siendo los mismos que en el caso del desarrollo separado: denir a grandes rasgos qu tipo de aplicacin se desea hacer. Para eso, hay que cubrir dos aspectos: Por un lado se debe seleccionar el
objetivo
del videojuego educativo,
es decir, qu pretendemos ensear con l. En el caso de una empresa dedicada a la construccin de estas aplicaciones, es muy posible que el objetivo venga impuesto por el cliente, aunque puede que la decisin sea de la propia empresa si decide crear un videojuego en vistas a un cliente potencial especco. Esta parte se corresponde con el objetivo de la fase de concepto en el desarrollo de las aplicaciones educativas. Por otro lado debe seleccionarse la
ambientacin,
que va a
envolver
el
objetivo anterior en una componente ldica. Es decir, debemos cubrir los objetivos marcados para la fase de concepto del desarrollo de un videojuego. Es destacable que el propio Crawford (1984) hace una distincin similar cuando habla de la primera fase en el diseo de un videojuego. Indica que en esa fase hay que elegir un objetivo y un tema, y pone el ejemplo del juego Eastern Front 1941, en el que el objetivo estaba relacionado con la naturaleza de las reglas y la diferencia entre la potencia blica y la efectividad, mientras que el tema o ambientacin era la guerra entre Rusia y Alemania.
En un videojuego, el diseador suele
profundidad el
rea
documentarse
para conocer con cierto grado de
en el que se desarrolla el videojuego, pero nunca llega a convertirse
en un experto del dominio.
86
Captulo 4.
4.2.2.
Preproduccin
Una vez determinados los objetivos bsicos y la idea del componente ldico, la preproduccin es el primer paso de desarrollo. En esta fase, el objetivo y la ambientacin se combinan para crear el juego educativo. Esa unin determinar el xito o el fracaso de la aplicacin. Una combinacin bien hecha
difumina
la separacin entre ambos aspectos, por lo
que aprovecha al mximo la componente de motivacin del juego mientras conserva la comunicacin efectiva de los contenidos pedaggicos. Por tanto, requiere la participacin tanto de expertos en el diseo de juegos como de pedagogos o psiclogos y expertos en el dominio a ensear. En muchos juegos educativos se utiliza la
simulacin
de los entornos rea-
les en los que se desarrollan las acciones que se quieren ensear. As es por ejemplo Tactical Iraqi (Johnson et al., 2005). En contextos educativos donde la simulacin real del entorno no es posible, se puede hacer uso de metforas (Gmez Martn, Gmez Martn, Gonzlez Calero y Palmier Campos, 2007d), como en JV M que veremos en el captulo 6 o Dimenxian . En cualquier caso, las decisiones tomadas en este punto determinarn el modo en el que se crearn los contenidos, que trataremos en secciones posteriores. El resultado de todas estas decisiones terminar con la escritura del
cumento de diseo
do-
del juego educativo, que ser el eje conductor de todo
el proceso de creacin. Esta piedra angular, tambin existente en la construccin de videojuegos tradicionales, contiene una descripcin de lo que debera ser la aplicacin nal. Para ello, debe al menos cubrir los siguientes puntos: Una introduccin que destaque los puntos fuertes y originales de la aplicacin. El mtodo en el que se va a llevar a cabo la integracin entre la parte ldica y la parte de contenido educativo, que ya hemos comentado. Una descripcin de interaccin con la aplicacin nal, para que el lector entienda cmo va a ser su funcionamiento general. Una lista de las caractersticas ms importantes, principalmente desde el punto de vista del desarrollo. Por ejemplo, indicar si la aplicacin se va a desarrollar on-line o qu tipo de controladores va a manejar el usuario. Algn boceto del aspecto nal que el diseador tiene en mente. Durante la preproduccin tambin se empieza a desarrollar parte de la aplicacin nal. Dependiendo del formato de juego elegido, es posible que
com/).
Juego para aprender lgebra desarrollado por Tabula Digita (http://www.dimenxian.
87
algunas de las herramientas necesarias para la elaboracin del contenido ya estn disponibles; en caso contrario, es en este momento cuando se crean. En esta fase, tambin se importa del desarrollo de los videojuegos la necesidad de pruebas de concepto del diseo por medio de prototipos. De esta forma, se puede averiguar lo antes posible si el videojuego educativo va a resultar atractivo a los jugadores/estudiantes o no. En caso negativo, se debern replantear las decisiones tomadas en la fase de concepto (lo que llambamos la ambientacin) y el documento de diseo donde se jaba la unin entre ella y los contenidos pedaggicos. Al nal de la fase de preproduccin, debe existir una versin ejecutable de la aplicacin que d una idea bastante el del aspecto que tendr al nal.
4.2.3.
masa
Produccin
En esta fase es donde se realiza el verdadero desarrollo de la aplicacin. Utilizando como base el resultado de la fase anterior, se construye toda la de contenidos, que en este caso consistir no slo en la parte visual y de interaccin ligadas fundamentalmente a la componente ldica, sino tambin el contenido educativo. En esta fase habr irremediablemente que anar las herramientas realizadas en la etapa anterior, y se programar el comportamiento de todos los personajes (inteligencia articial), niveles, unidades y mecnicas. Igual que en el desarrollo de videojuegos, tanto durante esta fase como en la anterior, se realizan pruebas sistemticas de la aplicacin. Los diseadores deben evaluar continuamente si el diseo creado es entretenido, y en caso negativo, tomar medidas. Esas medidas pueden ser modicaciones sencillas en las mecnicas y niveles, o pueden suponer empezar desde el principio por la ambientacin. En algn momento de la fase de produccin se consigue una versin en la que todo el esfuerzo de programacin ha terminado, y lo nico que queda es alimentar a ese motor con contenidos en forma de datos, gracias a las arquitecturas dirigidas por datos (ver seccin 2.4). Una vez completado el contenido, se da por concluida la produccin, y se pasa a la siguiente fase.
4.2.4.
Control de calidad
Una vez dado por concluido el desarrollo del videojuego educativo, se da paso a una fase en la que las pruebas se intensican, y el desarrollo que se hace es meramente para corregir los errores detectados. La fase suele llamarse fase de QA , o lo que es lo mismo validacin o garanta de calidad. El equipo de QA en realidad est activo desde las fases iniciales del desarrollo, ejecutando el producto parcial en busca de fallos, tanto de ejecucin
Como ya se ha dicho, se corresponde a las siglas inglesas de
quality assurance
88
Captulo 4.
como de discrepancia con los documentos de diseo. Cuando durante estas fases detectan algn error, informan de l al equipo de desarrollo por medio de herramientas de seguimiento de errores (descritas en la seccin 4.5.4). En esta ltima fase, una vez dado por concluido el desarrollo completo, el nico esfuerzo de programacin que se hace es aquel encaminado a la correccin de los errores, por lo que el nmero de programadores se reduce signicativamente. En este momento, es el equipo de QA en el que recae ms responsabilidad. La versin completa (conocida como versin personas
betatesters, o probeta ). El mtodo idneo de funcionamiento es que estas personas externas se comuniquen nicamente con el equipo de QA, mediante
al equipo de desarrollo (conocidos como badores de versiones
externas
beta ),
se distribuye entre
una herramienta de gestin independiente de la utilizada internamente entre el equipo de QA y el de desarrollo. El equipo de QA se encarga de clasicar, eliminar duplicados e incluso ltrar e ignorar los errores que llegan del exterior, e informar al equipo de desarrollo de todos aquellos que deberan ser arreglados.
Durante esta fase tambin se deben hacer las ltimas pruebas para
librar
nivelar
equi-
la componente ldica y pedaggica de la aplicacin.
Con respecto al nivelado de la componente ldica, nos referimos a hacer que los retos propuestos por la aplicacin se ajusten al nivel del usuario, ya que los juegos ms divertidos son aquellos jugados entre dos oponentes de un nivel similar se habrn hecho tambin en la fase de preproduccin mediante prototipos, y en la fase de produccin con versiones intermedias del videojuego nal, pero en este momento pueden utilizarse jugadores
5 (Graepel et al., 2004). Estas pruebas de nivelado del juego
reales
externos al equipo
de desarrollo. En la seccin 4.6.3 veremos cmo podemos utilizar anlisis formal de conceptos para analizar los registros generados de las partidas de estos jugadores para sacar conclusiones tiles para el nivelado. Por ltimo, respecto a la componente pedaggica, debemos comprobar si los contenidos educativos creados son sucientes o no. Gracias a la separacin entre la parte ldica y la educativa de los contenidos que detallamos en las secciones 4.3 y 4.4, veremos que en esta fase podremos tambin comprobar si los contenidos educativos son sucientes utilizando anlisis formal de conceptos.
Resulta curioso que esto ocurra incluso en la novela 2001, una odisea en el espacio,
donde el autor indica que HAL, el ordenador de a bordo poda jugar contra los astronautas a varios juegos como ajedrez y damas, pero que se dejaba ganar la mitad de las veces, para no bajar la moral.
4.3. Creacin de contenidos
89
4.2.5.
Mantenimiento y explotacin
Igual que en el caso anterior, las tareas de mantenimiento que requiere un videojuego educativo son las suma de las que requiere una aplicacin educativa y un videojuego por separado. En particular, es posible que se requieran actualizaciones para solucionar errores detectados despus de la publicacin de la aplicacin, o actualizar algunos de los contenidos educativos. Para permitir actualizaciones, el programa ha debido ser implementado prestando especial atencin a la posibilidad de tener cheros de datos con distintas versiones. En aplicaciones en red, adems, los protocolos de comunicacin tambin deben ser conscientes de esa posibilidad, y negar la comunicacin entre dos aplicaciones con actualizaciones distintas.

La arquitectura dirigida por datos que comentbamos en la seccin 2.4 establece una separacin entre el motor del juego y los datos o contenido del mismo. Las acciones que se realizan tanto en la fase de preproduccin como de produccin estn claramente marcadas por este tipo de arquitectura. Desde el punto de vista tcnico, el estudio dedica un esfuerzo considerable a mantener un motor de juego centralizado, controlado por unos pocos programadores, mientras el resto es dedicado a la creacin de cdigo especco de esa aplicacin concreta (como el comportamiento de NPCs) y a la creacin de herramientas para la generacin de contenidos para ese motor. El resto de personas se dedica a la
generacin de contenidos
de la aplica-
cin utilizando esos editores. Para eso se establece un mecanismo de gestin y control de esos contenidos, estableciendo las fases por las que van pasando los recursos, de tal forma que a las personas que los crean les sea posible ver fcilmente en el motor del juego (resultado nal) lo que est editando en la herramienta. Los buenos resultados de las arquitecturas dirigidas por datos son aprovechados al mximo cuando el gnero de la aplicacin est
consolidado,
es
decir, cuando las mecnicas, formas de interactuar con el usuario y los tipos de contenidos estn claros y no sufren modicaciones entre aplicaciones. En esos casos, el motor de la aplicacin puede cubrir toda la funcionalidad necesaria para cualquier entrada de datos, de tal forma que estos se convierten en la nica diferencia entre distintas aplicaciones. En las siguientes dos secciones describimos el modo de generar contenidos para aplicaciones educativas por un lado y para videojuegos por otro. Por ltimo, en la seccin 4.3.3 describimos las distintas alternativas de creacin de contenidos que soporta nuestra propuesta de arquitectura de videojuegos educativos.
90
Captulo 4.
Objetos de aprendizaje
Motor de contenidos (Moodle, Authorware)

Figura 4.1: Esquema de contenidos en aplicaciones educativas
4.3.1.
Contenidos en aplicaciones educativas
No cabe duda que lo ms importante de una aplicacin educativa es el conocimiento del dominio (Devedzic et al., 1998), por lo que el esfuerzo a la hora de su construccin se centra, precisamente, en la creacin del contenido relacionado con ste. Si nos centramos en los aplicaciones de enseanza asistidas por ordenador (CAI, ver seccin 3.2), desde los primeros productos se ha intentado independizar el motor de visualizacin de los propios datos, de tal forma que por un lado exista el motor que muestra los contenidos, y por otro lado estn los datos, en cheros externos (ver gura 4.1). Uno de los primeros sistemas que lo hicieron fue PLATO (Wikipedia (PLATO)). Un ejemplo ms reciente son las aplicaciones desarrolladas utilizando Authorware (Adobe, 2006), que permite editar el contenido textual y aadirle otros recursos multimedia, como imgenes y sonidos. Hoy por hoy, sin embargo, los ejemplos ms representativos son aquellos contenidos desarrollados en SCORM (Advanced Distributed Learning (ADL), 2004), que es el estndar ms importante para la creacin de contenidos de aprendizaje (u
objetos de instruccin )
reutilizables en distintos fra-
meworks o motores de aprendizaje basados en Web. Una de las consecuencias ms importantes de la existencia de este estndar es que ha permitido la creacin de contenidos de manera independiente a la aplicacin utilizada para su visualizacin. Los principales beneciados han sido los sistemas gestores de aprendizaje o LMS (abreviatura de la denominacin inglesa,
gement System ).
Estos
motores,
Learning Mana-
como Moodle (Dougiamas y Taylor, 2003),
permiten visualizar los contenidos denidos en SCORM en un navegador Web, y monitorizar al alumno durante todo el proceso de aprendizaje. Otro de los puntos importante, adems del propio contenido o exposicin
91
de los temas a ensear, es la existencia de ejercicios o preguntas, que son las que (idealmente) guan el proceso de aprendizaje. SCORM tambin permite incluir estos ejercicios o tests, y determinar, en base a sus resultados, los siguientes contenidos educativos a presentar. Si pensamos en aplicaciones educativas ms sosticadas que no se limiten a la presentacin casi secuencial de contenidos sino que incorporen mdulos inteligentes, se necesitan otros tipos de contenidos ms avanzados. Por ejemplo, el conocimiento del dominio puede venir dado por un conjunto de reglas, ontologas que mantienen los conceptos a ensear o una base de ejercicios. En esos casos, la aplicacin que visualiza los contenidos posee un
razonamiento
motor de
que aprovecha esas reglas, ontologas o ejercicios para presen-
tar explicaciones, seleccionar el contenido ms adecuado a ser presentado o resolver los ejercicios propuestos.
4.3.2.
Contenidos en videojuegos
En el rea de los videojuegos, el gnero que tradicionalmente mejor ha aprovechado la arquitectura dirigida por datos ha sido el de la narracin interactiva (dos casos particulares se detallaban en las secciones 2.7.3.1 y 2.7.3.2). Por ejemplo, LucasArts cre numerosas aventuras grcas utilizando primero su motor SCUMM y despus GrimE, a los que hacan muy pocas modicaciones entre ttulo y ttulo . Los datos en este caso son tanto la parte grca como los
scripts
que
denen la parte lgica o de comportamiento de los personajes que aparecen. Por ejemplo, en estos cheros de texto se denen los rboles de conversacin o las repercusiones que tienen las acciones del usuario sobre el entorno. Para el resto de gneros, las arquitecturas dirigidas por datos son, no obstante, tambin perfectamente aplicables. La nica diferencia es que en este caso es mucho ms complicado aprovechar sin retocar los motores para varios ttulos, ya que los gneros cambian las mecnicas introduciendo innovaciones no soportadas por las versiones anteriores de los motores. A continuacin aparece una lista de los contenidos (o datos) ms importantes necesarios para la creacin de un juego: Recursos grcos: tanto los de dos dimensiones para el interfaz del usuario (mens y HUD) como los modelos en tres dimensiones, necesarios para caracteres, entorno esttico y objetos. Para su creacin, existen gran cantidad de herramientas de modelado, como 3DStudio Max o Alias Wavefront.
El hecho de que las aventuras grcas se presten tanto a crearse nicamente con
cheros de datos ha dado lugar a investigaciones que mezclan aplicaciones de e-learning tradicionales con aventuras grcas 2D, donde cada aventura (representada con cheros de datos) representa un objeto de aprendizaje (Martnez-Ortz et al., 2006; Moreno-Ger et al., 2006).
92
Captulo 4.
Mapas: son los ms importantes, ya que guan la carga del resto de recursos. Los mapas determinan qu entidades aparecen en el entorno virtual y, por tanto, qu recursos (grcos, sonidos y scripts) ser necesario cargar. Para su edicin, se necesitan herramientas especializadas, normalmente creadas expresamente para el juego particular. Scripts: como decamos en la seccin 2.7, los scripts son parte del cdigo que dene el comportamiento del juego, denido utilizando un lenguaje de programacin que se interpreta en tiempo de ejecucin. Las herramientas necesarias para su creacin son principalmente editores de texto y un buen entorno para la depuracin que, lamentablemente, no siempre existe. Sonidos: el componente sonoro de un juego est recibiendo cada vez ms atencin por parte de los estudios. No slo nos estamos reriendo aqu a las grabaciones de voces en msica de ambiente y efectos.
o
o personajes, sino tambin a la
Los mapas son la representacin ms clara de las ideas que el diseador ha plasmado en el documento de diseo. Son cheros de datos que contienen la lista de todas las entidades (u objetos del juego, ver seccin 2.6) que aparecen en ese nivel. Opcionalmente, pueden contener tambin parte de los modelos o geometra de ese nivel (tpicamente la geometra esttica, como paredes o mobiliario con el que no se puede interactuar). La principal caracterstica de los mapas son las entidades que los diseadores de niveles colocan en el entorno. Cada una de esas entidades tiene un comportamiento perfectamente denido, en parte por el propio motor del juego y en parte por el cdigo creado en los scripts. La funcin del diseador de niveles es traducir el funcionamiento del nivel indicado en el documento de diseo a una serie de entidades colocadas estratgicamente y con unas propiedades escogidas de tal forma que su comportamiento en ejecucin cuadre con el indicado en el documento. Podemos pues decir que el diseador de niveles cablea el documento de diseo en un mapa (Eladhari, 2002). En las aventuras conversacionales, esa traduccin es ms o menos sencilla, gracias al grado de renamiento conseguido por los motores de juegos dedicados a estos gneros. Aunque la traduccin no es directa, es relativamente sencillo pasar del documento de diseo a los contenidos, por medio de variables que denen condiciones del juego, o rboles de conversaciones. En juegos ms complicados, la traduccin es ms compleja. En esos casos, el diseador tiene una batera de entidades
generales
que debe ver como
componentes atmicos con los que conseguir el comportamiento descrito en el documento de diseo. Algunas de las entidades aparecern como tal en ese documento (como los distintos enemigos o armas), mientras que otras estarn pensadas para permitir esa traduccin. Ejemplos de este ltimo tipo
93
Cdigo especfico
Modelos, scripts, sonidos...
Mapas
Motor del juego
Figura 4.2: Esquema de contenidos en juegos
de entidades especiales son los disparadores de acciones (en ingls colisiona con ellos, o las anclas (en ingls
trigger ),
utilizadas para que se ejecute una accin cuando, por ejemplo, el jugador
anchors ),
que se utilizan como
entidades invisibles utilizadas por la inteligencia articial para encontrar localizaciones especiales, como el sitio en el que colocarse para manipular la rueda de un coche (Martel, 2006). La gura 4.2 muestra un esquema a alto nivel de la estructura de un juego dirigido por datos. El motor del juego es la parte que puede aprovecharse entre distintos ttulos, mientras que el cdigo especco est desarrollado expresamente para el juego en cuestin (comportamiento de personajes y otros objetos del juego). El mapa es cargado por
el motor del juego
que
utilizar alguna de las distintas tcnicas existentes para la creacin de las entidades denidas en el cdigo especco (ver seccin 2.6.2). Este esquema deja claro que el formato de los mapas cdigo especco.
depende del motor del juego
y no del
4.3.3.
Contenidos en videojuegos educativos

ambientacin
Los videojuegos educativos presentan, en un entorno virtual en forma de juego, una serie de contenidos educativos. Dependiendo del tipo de juego elegido, es decir, dependiendo de la o forma de presentar los contenidos (ver seccin 4.2.1), stos sern textos o explicaciones en el sentido estricto de la palabra, o estarn integrados entre las entidades del juego, que los presentarn en los momentos oportunos. Si el juego basa su enseanza en la aproximacin de aprender haciendo, es probable que el entorno sea una simulacin (metafrica o no) de un entorno real donde el jugador/estudiante pone en prctica las habilidades que se pretenden ensear. En ese caso, la parte ms importante de los contenidos didcticos no son las explicaciones tericas o textuales, sino los propios
ejercicios
o situaciones a las que se debe enfrentar el alumno.
Cuando el entorno virtual del juego se convierte en el lugar de ejecucin
94
Captulo 4.
de los ejercicios, las explicaciones textuales, si las hay, debern buscar su hueco en algn sitio. En algunas aplicaciones, como Tactical Iraqi (Johnson et al., 2005), esas explicaciones estn separadas por completo del entorno (en un mdulo que llaman skill antes de entrar en el juego (que ellos llaman mission
builder ),
y el jugador/estudiante debe leerlas
game ).
En otros
casos, las explicaciones pueden estar integradas dentro del propio entorno, mediante el uso de agentes pedaggicos (como en Rickel y Johnson, 1999), HUDs (como por ejemplo en CoLoBot ), o dilogos de personajes de una aventura grca (Moreno-Ger et al., 2006). Si nos centramos en la autora de los ejercicios integrados dentro del entorno virtual o juego, podemos decir que existen dos casos:
Los ejercicios estn denidos
en los propios mapas del juego :
cada uno
de los mapas del juego es un ejercicio concreto. De esta forma, cuando dentro del ciclo de ejecucin el videojuego educativo (Gmez Martn, Gmez Martn, Gonzlez Calero y Jimnez Daz, 2005b), ste se plantea qu ejercicio debe elegir, tendr que decidir qu mapa o escenario particular ejecuta. El esquema de contenidos del juego educativo sigue siendo, por tanto, el de la gura 4.2.
Los ejercicios estn denidos independientemente del mapa o entorno en el que se ejecutan: para poder soportar esto, la arquitectura de la aplicacin subyacente debe ser capaz despus de establecer el nexo de unin entre las propiedades denidas en los ejercicios (estado inicial, circunstancias que deben darse en el entorno, etc.), y el mapa que se carga y que contiene las entidades del juego.
Existen numerosos ejemplos del primero de los casos, donde toda la tecnologa que se utiliza gira en torno a los videojuegos. Un ejemplo claro es el videojuego para entrenamiento de bomberos de Sim Ops Studios , que incluye una aplicacin llamada Core3D que permite crear escenarios y colocar en sitios especcos el fuego, gases y otros elementos, as como las vctimas de los accidentes y sus sntomas. En este caso el tutor humano es el que tiene que construir los ejercicios, creando mapas y colocando entidades, de tal forma que se de niveles, un lenguaje especco de los videojuegos. Nuestra propuesta metodolgica se basa en la segunda de las opciones, por lo que dedicamos la seccin siguiente a su exposicin detallada.
programa
el funcionamiento del ejercicio utilizando editores
7 8
http://www.ceebot.com http://www.simopsstudios.com
4.4. Metodologa de creacin de contenidos
95

4.4.1. Propuesta
Cuando se desarrolla un videojuego educativo donde se presentan distintos ejercicios que el estudiante tiene que resolver, la primera opcin es extrapolar el modo de crear los entornos virtuales en los videojuegos, y utilizar la misma tcnica para la creacin de esos ejercicios. Como veamos en la seccin anterior, eso signica que los mapas del videojuego contienen los ejercicios
cableados
en las entidades colocadas en ellos.
Sin embargo, la opcin que nosotros estimamos ms acertada es la
racin
sepa-
de esos tipos de contenidos en dos, (i) los entornos virtuales donde se
desarrolla la accin, y (ii) los ejercicios (ver gura 4.3). Este modo de actuar, separando por un lado los datos que determinan el entorno (mapas) y por otro lado los ejercicios, soporta fcilmente las distintas relaciones que pueden darse entre ejercicios y mapas:
El ejercicio consiste en un estado inicial del entorno, y un estado nal deseado al que hay que llegar. Es posible que el entorno virtual sea el mismo durante todo el aprendizaje, por lo que slo se requiere un mapa, mientras que los ejercicios son muchos. Un ejemplo en el rea de los ITS son los ejercicios que hay que hacer dentro del sistema Steve (Rickel y Johnson, 1999, 2000) que mostrbamos en la gura 3.1, o VirPlay (Jimnez Daz, Gmez Albarrn, Gmez Martn y Gonzlez Calero, 2005a). Las acciones que se hacen dentro del entorno tienen repercusiones directas en el mismo, que, como ha empezado en un estado distinto, evolucionar de forma distinta dependiendo del ejercicio.
El ejercicio consiste en practicar
situaciones
que se van aadiendo al
entorno. El ejercicio puede partir del mismo entorno virtual (mapa) siempre, pero los sucesos que ocurren dentro de l cambian de un ejercicio a otro. Ejemplos de este tipo de aplicaciones son los simuladores de conduccin, donde el estudiante siempre circula por las mismas vas, pero en ellas ocurren sucesos distintos ms o menos peligrosos. El ejercicio puede especicar las distintas situaciones que deben ocurrir durante la ejecucin, y las entidades del mapa, dependiendo de esos datos, se comportan de una u otra forma.
En el captulo 6 veremos una alternativa mixta, en la que la manipulacin de las entidades del entorno genera contenido nuevo dependiente del ejercicio.
96
Captulo 4.
Ejercicios
Cdigo especfico
Modelos, scripts, sonidos...
Motor de la aplicacin
Mapas
Figura 4.3: Esquema de los contenidos en juegos educativos con ejercicios y mapas separados
4.4.2.
Puesta en prctica
Con nuestra metodologa, existen cheros de datos distintos para los mapas y para los ejercicios. Los primeros son ledos o interpretados, igual que antes, por el motor de la aplicacin, mientras que los ejercicios son dependientes del cdigo especco, que vara con cada dominio. Para hacer posible esta separacin, los mapas estn generados de tal forma que admiten la
guracin
con-
externa de sus propiedades, dependiendo del ejercicio concreto que
se quiera ejecutar. Para conseguirlo, las entidades del juego (cdigo especco) creadas por el motor de la aplicacin al cargar el mapa, utilizan los datos del ejercicio para variar su comportamiento. En la gura 4.3 se muestra el esquema general. El modo de implementar esto es tratado en la seccin 5.11. Para la creacin de los ejercicios es posible que se requieran herramientas especializadas dependientes del dominio. Aunque la tendencia actual es utilizar XML como formato de intercambio de datos, y los ejercicios se prestan mucho a su uso, su edicin de manera manual es cuanto menos incmoda. Por lo tanto, es recomendable disponer de herramientas especializadas que graban a estos formatos, interpretables posteriormente por la aplicacin. Al tratarse de herramientas de propsito especco, pueden incluir caractersticas que hagan cmoda la creacin de los ejercicios. En cuanto a la generacin de los mapas, es necesario tambin disponer de herramientas de modelado que permitan al menos crear la forma bsica del entorno virtual (terreno y paredes), y la colocacin de las entidades que denen el comportamiento del entorno y que constituyen el nexo de unin con los ejercicios. Para la creacin de estos mapas, nuestra propuesta es implementarla en dos fases:
1. En la primera fase se crea una versin inicial del mapa, utilizando
97
una herramienta especializada que facilite la creacin de la estructura teniendo en cuenta el tipo de entorno perseguido. Por ejemplo, para un juego educativo de conduccin se puede utilizar un editor especializado en carreteras, mientras que para otro tipo de juego se puede elegir uno que se base en celdas. 2. En la segunda fase se crea la versin nal del mapa, donde aparecen todas las entidades que sern utilizadas para la conguracin procedimental del entorno, as como el resto de entidades que intervienen en la componente ldica. Tambin en esta fase se puede retocar la estructura del entorno virtual.
Con esta alternativa, se aprovecha el uso de una herramienta especializada para construir de forma rpida el entorno, antes de terminar con la tarea de colocacin de entidades, que es la que ms tiempo consume. Adems, se consigue que en las etapas tempranas del desarrollo se pueda apreciar el aspecto nal del entorno, especialmente til para el desarrollo de prototipos. Como ejemplo de puesta en prctica de esta metodologa en general, y del mtodo de creacin de mapas en particular, se puede consultar la seccin 6.7, donde se describe cmo se ha realizado la generacin de contenidos en JV M.
4.4.3.
Ventajas
La arquitectura basada en datos en el desarrollo de video-
La principal ventaja de la separacin fsica de mapas y ejercicios es la
especializacin.
juegos permite separar el papel de los programadores del de los artistas. En esta ocasin, extraer de los mapas la componente educativa permite distinguir entre el papel jugado por los diseadores y artistas y el desempeado por los expertos en el dominio. Esa especializacin tambin se obtiene en los formatos de los cheros que se utilizan. As, los mapas pueden guardarse en un formato genrico e independiente del dominio enseado, mientras que los ejercicios se guardan en un tipo de archivo especco. Dado que la descripcin de estos ejercicios puede ser de alto nivel, se podrn aplicar tcnicas de anlisis de datos sobre ellos, que ayudarn a sus autores a comprobar si se han creado sucientes o no. En concreto, en la seccin 4.6.2 proponemos el uso de anlisis formal de conceptos para hacerlo. Una ventaja no menos importante con la separacin es la
del coste
disminucin
de generacin del videojuego educativo. Independientemente del
tipo de relacin que exista entre los ejercicios y los mapas descritas en la seccin 4.4.1, lo que conseguimos con la separacin es la posibilidad de utilizar el mismo conjunto pequeo de mapas en varios ejercicios distintos. De esta forma, la conguracin o funcionamiento nal del entorno en el que el estudiante se ve inmerso se realiza
de manera procedimental.
98
Captulo 4.
Contenido manual Contenido procedimental
Coste
Cantidad de contenido
Figura 4.4: Coste de generacin de contenidos de forma manual y procedimental
Esto implica una bajada en el coste de desarrollo de la aplicacin, ya que es mucho ms fcil la generacin de ejercicios independientes del entorno de ejecucin, debido a que su creacin consiste nicamente en denir el enunciado, que, en tiempo de ejecucin, afectar al entorno en el que el jugador se ve inmerso. Hacer los ejercicios independientes del entorno, adems, permite poder utilizarlos en distintos contextos o con distintas presentaciones. En realidad, la disminucin del coste slo sucede cuando la cantidad de contenido de la aplicacin supera un umbral. Esto es debido a que la generacin o conguracin procedimental de los escenarios requiere un esfuerzo inicial superior al necesario para crear unos pocos ejercicios. En la gura 4.4 se aprecia que el coste de creacin de los primeros ejercicios utilizando tcnicas manuales es inferior que el necesario para la generacin procedimental, debido a que para esta ltima no vale con generar nicamente los mapas, sino que es necesario tambin crear los ejercicios y todo el cdigo de construccin o conguracin procedimental del entorno. Una vez pasado un umbral, el coste de ambos crece de forma lineal, pero la generacin manual lo hace de forma mucho ms pronunciada. A la conguracin procedimental del entorno se le puede aadir una mejora ms, la creacin procedimental
de los propios ejercicios.

2
Por ejemplo,
Gmez Martn, Gmez Martn, Daz Agudo y Gonzlez Calero (2005c) presentan el uso de tcnicas de adaptacin de razonamiento basado en casos para generar nuevos ejercicios en JV M. En ese caso, el coste inicial (tener los primeros ejercicios funcionando) es mucho ms grande, debido a la necesidad de implementar las tcnicas de adaptacin, pero una vez superado ese paso inicial, la funcin de coste no crece, ya que la generacin es automtica.
4.5. Herramientas necesarias para el desarrollo
99
s v er on
in
aX
Edicin final X
Al motor X
Boceto inicial
Edicin inicial
Co nv er si n aY
Edicin final Y
Al motor Y
Figura 4.5: Esquema de creacin de mapas
Por ltimo, conviene mencionar una ventaja de la separacin en dos fases de la generacin de mapas. Como veremos en el captulo siguiente las herramientas utilizadas en la segunda fase de creacin de los mapas puede venir impuesta por el motor grco utilizado en la aplicacin. El trabajo en dos fases permite reducir el trabajo no aprovechable cuando se decide un cambio de motor, pues la primera parte de creacin del mapa sirve para ambos motores (ver gura 4.5).

Para el desarrollo de una aplicacin educativa utilizando las fases y metodologa anterior, debe contarse con una serie de herramientas de soporte, algunas de ellas indispensables, y otras recomendables para maximizar el rendimiento del equipo. Este apartado hace una descripcin de las ms importantes (Gmez Martn, Gmez Martn y Jimnez Daz, 2007c), comentando las distintas alternativas existentes en cuanto a implementaciones. En algunos casos, mostramos nuestra preferencia para el caso de desarrollo de videojuegos educativos de tamao medio. En general, podemos decir que la seleccin de las herramientas a utilizar se realiza en la fase de
preproduccin
(ver seccin 4.2.2), aunque algunas de
ellas pueden incorporarse en el proceso de desarrollo en cualquier momento.
4.5.1.
Compiladores, entornos integrados de desarrollo y herramientas de construccin
No cabe duda que son las herramientas indispensables en el desarrollo. En el rea de la programacin de videojuegos, el lenguaje estrella hoy por hoy es C++, por lo que es necesario un compilador para este lenguaje. Dependiendo de la plataforma destino, ser el Microsoft Visual Studio, otro compilador proporcionado por el fabricante del
hardware.
gcc,
En cuanto a los entornos integrados de desarrollo (en ingls
development environment,
integrated
IDE), que permiten la edicin y depuracin del
100
Captulo 4.
cdigo fuente, de nuevo Visual Studio es una opcin posible, aunque tambin es utilizado comnmente CodeWarrior consolas. En general, se puede decir que la decisin de qu compilador e IDE utilizar depende de la plataforma para la que se vaya a desarrollar el videojuego educativo. Si nos limitamos a plataforma PC con el sistema operativo Windows, la balanza se inclina irremediablemente hacia Microsoft Visual Studio .NET. Una posibilidad, habitual en el mundo de los videojuegos, es crear aplicaciones para ser ejecutadas en varias plataformas. Para eso, habr que abstraer las partes dependientes del
9 en la programacin para algunas
hardware,
y programar la aplicacin en un
lenguaje que se pueda compilar en todas. Si el proyecto se desarrolla en varias plataformas, el proceso de compilacin debe congurarse para cada una de ellas. Utilizando un lenguaje portable como C++, todos los compiladores aceptarn los mismos cheros de cdigo fuente como entrada. Sin embargo, en cada plataforma, el compilador utilizado ser distinto y utilizar distintos parmetros para las opciones. Adems, los desarrolladores utilizarn distintos IDEs para la programacin del proyecto, y habr que congurar cada uno de ellos individualmente. Esto provoca que la creacin o borrado de un nuevo chero de cdigo fuente en el proyecto requiera recongurar gran cantidad de sistemas de generacin del ejecutable, ya sean los propios IDEs (en ese caso, el cambio tambin har que el nuevo chero aparezca en el rbol de cheros del IDE), o herramientas externas como
make
ant.
generan
los cheros de conguracin
Para solucionarlo, existen herramientas congurables con cheros de texto independientes de la plataforma que para los distintos sistemas de generacin; por ejemplo, generarn los
.vcproj
para ser ledos por Visual Studio, los cheros
de entrada a
make,
build.xml
para
aadir un nuevo chero al proyecto,
Makefile que sirven ant. De esta forma, cuando se quiere no se aade directamente en el entorno
.sln
de desarrollo, sino en el chero de conguracin de esa nueva herramienta independiente de la plataforma. Algunas de estas herramientas pueden servir incluso para
generar
ellas mismas el ejecutable nal dependiendo de la con-
guracin establecida. Pasan entonces de ser una herramienta utilizada como paso previo a la invocacin de la compilacin (ya sea desde el IDE o no) a ser la propia herramienta que llama al compilador, analizando previamente las dependencias y comprobando qu cheros deben compilarse y cules no. Ejemplos de estas herramientas son CMake (Martin y Homan, 2006), SCons
10 , KJam11 o Boost.Build12 . Otra alternativa es desarrollar una interna
http://www.freescale.com/codewarrior/ http://www.scons.org/ 11 http://www.oroboro.com/kjam/ 12 http://www.boost.org/tools/build/v2/index.html

10
101
sencilla, como han hecho los desarrolladores de Nebula y Mangalore
13 .
Para nuestro contexto, y gracias a que Microsoft Visual Studio .NET 2005 ha mejorado signicativamente los tiempos de comprobacin de dependencias, nos decantamos por utilizar el propio IDE para la tarea de generacin del ejecutable. Para la creacin de los cheros que lo conguran (chero de
solucin
y cheros de
proyecto ),
utilizamos CMake (Martin y Homan,
2006), lo que permite fcilmente cambiar la versin del compilador, o migrar en un futuro a otras plataformas fcilmente, al evitar tener que generar los cheros de compilacin asociados.
4.5.2.
Sistemas de control de versiones
Estos sistemas gestionan las distintas versiones por las que va pasando un chero de cdigo fuente, documento o recurso durante todo el proceso de desarrollo. La necesidad de estas herramientas est ampliamente reconocida, no slo porque sirven como medio de copia de seguridad que permite
hacia atrs
volver
ante algn fallo, sino porque permite el trabajo simultneo de
dos o ms personas. Estos sistemas de control permiten por ejemplo que dos desarrolladores modiquen distintos (o incluso los mismos) cheros simultneamente, recuperar el estado anterior de cheros o de proyectos enteros, crear ramas en el desarrollo o llevar la historia de los cambios de los cheros. Existen varias alternativas para el control de versiones, tanto comerciales como bajo licencia GPL o similares. El sistema por excelencia dentro del software libre es CVS (Vesperman, 2003), aunque hoy por hoy est siendo desbancado por Subversion (Collins-Sussman et al., 2004). Entre las herramientas comerciales, destacan SourceSafe de Microsoft Rev
16 .
14 , Perforce15 y Accu-
Para el desarrollo de videojuegos educativos de tamao medio, nos decantamos por Subversion. La poca capacidad para el trabajo colaborativo de SourceSafe y el elevado precio de Perforce y AccuRev decantan la balanza hacia las alternativas libres. Entre stas, Subversion es superior, gracias a su gestin de actualizaciones atmicas, su capacidad de no perder la historia de un chero al renombrarlo o moverlo de directorio, poco coste de las ramas o el concepto de cambio conjunto de varios cheros. Adems, la posibilidad de utilizar interfaz Web y la existencia de un buen cliente en Windows como TortoiseSVN hacen de Subversion una alternativa recomendable tanto para el almacenamiento de cdigo fuente como de recursos grcos y mapas.
13 14
http://nebuladevice.cubik.org/ http://msdn.microsoft.com/ssafe/ 15 http://www.perforce.com/ 16 http://www.accurev.com/
102
Captulo 4.
4.5.3.
Sistemas de gestin del conocimiento
El conocimiento acumulado por un equipo de desarrollo es enorme. En vez de conar en el boca a boca, es recomendable tener algn almacn centralizado que recoja toda esa informacin. Una manera tpica de recopilarla es por medio de la creacin de FAQs (del ingls,
frecuently asked questions, o
listado de preguntas frecuentes con sus respuestas), los documentos conocidos como how-to's (que contienen los procedimientos para realizar alguna tarea), tutoriales e informes tcnicos. Existen herramientas ms sosticadas, que se conocen como sistemas de gestin del conocimiento (en ingls
knowledge management systems,
KMS),
que pueden ser aplicaciones hipermedia que, incluso, pueden incluir ontologas y sistemas expertos para organizar los contenidos y mejorar el soporte para bsquedas. Para nuestro contexto creemos que este tipo de herramientas es til para minimizar las consecuencias de que un desarrollador importante abandone la empresa. Siguiendo con las metodologas giles que utilizamos para el desarrollo, la opcin ms lgica, y por la que nos decantamos es la utilizacin de pginas Wiki
17 (Leuf y Cunningham, 2001). La idea bsica de una pgina
Wiki es tan simple como un sitio Web que permite a sus visitantes aadir, modicar o eliminar contenido, abriendo la puerta a la autora de documentos de forma colaborativa. Existen numerosas implementaciones, programadas en distintos lenguajes, y con distintas caractersticas, como TWiki
20 utilizada por la Wikipedia. Para el uso que le damos como mMediaWiki

todo de centralizar el conocimiento adquirido por el equipo de desarrollo, cualquiera de ellas son perfectamente vlidas.
18 , DokuWiki19 o la famosa
4.5.4.
Sistemas de seguimiento de errores
Ya hemos visto en la seccin 4.2.4 que una de las fases del desarrollo es la comprobacin de que el programa no falla. Para gestionar estos errores, ya sea en esa fase del desarrollo o en otras, es preferible utilizar alguna aplicacin que nos ayude. Los sistemas de seguimiento de errores (en ingls
bug tracking systems ),
son soluciones software que ayudan a los programadores y departamento de calidad (QA) a informar de los errores que han encontrado. Los responsables de programacin pueden asignar distintas prioridades, y los programado-
17
Una de las primeras implementaciones de Wikis ms robustas, Wiki Web techonology,
fue creada por Ward Cuningham, uno de los fundadores del eXtreme Programming, una de las metodologas giles ms conocidas.
18 19
http://twiki.org/ http://wiki.splitbrain.org/ 20 http://www.mediawiki.org/
103
res particulares pueden ver la lista de errores que hay por resolver y auto asignarse la tarea de solucionar alguno. En ese caso, los sistemas permiten
bloquear
el error, para evitar que ms de una persona trabaje en l. Cuan-
do es resuelto, el programador que lo ha solventado puede documentando incluso sus causas y solucin.
cerrar
el error,
Una de las ventajas no comentadas del uso de un sistema de control de versiones como Subversion y Perforce es la posibilidad de aprovechar su caracterstica de cambio conjunto de varios cheros. Ambos sistemas funcionan
revisiones globales (changelists en la nomenclatura de Perforce), es decir, cada actualizacin (o commit ) provoca un cambio de revisin del almacn completo y no slo de los cheros implicados (como ocurre por ejemplo en CVS). Eso permite que el mensaje asociado al commit que soluciona un error
por pueda contener una referencia a ese error en el sistema de seguimiento de errores. De forma similar, el mensaje aadido en el sistema de seguimiento de errores al corregir un fallo puede hacer referencia al nmero de revisin concreto que solventa el fallo. Existen muchos sistemas de rastreo de errores con distintos interfaces (va web, e-mail o aplicaciones independientes) y licencias. Algunas compaas utilizan como herramienta interna una basada en Web montada en la red local de la empresa mientras que utilizan otras con un interfaz de aplicacin independiente para la comunicacin con los colaboradores externos. Como ejemplos, podemos destacar Elementool
22 y Mantis23 entre los productos libres. El primero, comercial, y Bugzilla
21 en el rea del software
muy completo, tiene un precio que para desarrollos y empresas medias puede ser excesivo. Por esa razn, la opcin escogida por nosotros es o Bugzilla o Mantis; si bien el primero tiene ms opciones, su complejidad de uso hace que Mantis, ms sencillo de utilizar, sea a veces preferida. Mantis, por ejemplo, ha sido utilizado por Pyro Studios durante el desarrollo de varios de sus productos, como Praetorians (Arvalo, 2006).
4.5.5.
Sistemas de integracin continua
La integracin continua (Fowler, 2006) es una de las prcticas aconsejadas por las metodologas giles, aunque tienen tambin cabida en otras metodologas de desarrollo distintas. Lo que proclama es la integracin frecuente del trabajo personal de cada miembro de un equipo. De esta forma, los avances que cada programador hace son aadidos en un corto periodo de tiempo a la versin completa disponible en el almacn de control de versiones. La otra alternativa, dejar pasar das o incluso semanas antes de integrar esa nueva funcionalidad, conduce a problemas serios de integracin en las
21 22
http://www.elementool.com/ http://www.bugzilla.org/ 23 http://www.mantisbugtracker.com/
104
Captulo 4.
ltimas fases del desarrollo que alargan los plazos de entrega, incrementan el coste del desarrollo y pueden incluso llevar a la cancelacin del proyecto. Las herramientas de integracin continua son aquellas que se instalan en un servidor y cuya nica tarea es comprobar si la ltima versin disponible en el servidor de cdigo fuente (CVS, Subversion o cualquier otro) es correcta. Para ello, estas herramientas permiten congurarse de tal forma que cada cierto tiempo (desde pocos segundos a varios minutos u horas), comprueban si ha habido algn cambio desde la ltima construccin o compilacin llevada a cabo. En caso de cambios, se descargan la ltima versin y prueban su validez. Cuando se detecta algn error, alerta, mediante distintos tipos de noticacin, a los responsables del fallo, comprobando qu usuarios han modicado el cdigo desde la ltima vez. La noticacin puede hacerse, dependiendo de la herramienta utilizada, mediante correo electrnico, RSS, noticacin mediante algn protocolo de mensajera instantnea u otros modos ms extraos como la activacin de sirenas. Dependiendo de la conguracin, la comprobacin de validez ser ms o
incremental, de forma que se comprueba que en los ltimos cambios no ha habido

menos sencilla. Una muy habitual es realizar una mera compilacin un problema de integracin debido al desarrollo en paralelo de distintos programadores, que nadie ha olvidado aadir cheros nuevos o cualquier otro tipo de error. Otras conguraciones realizan pruebas ms rigurosas, como compilaciones desde cero, para todas las plataformas destino, o ejecucin de la batera de tests completa que haya denidas para el proyecto. En estos casos, dado que el tiempo de estas pruebas es mayor, la herramienta se congura para que lo haga menos frecuentemente. Existen distintas herramientas de este tipo, aunque el propio las alternativas comerciales, destaca AntHill
cron
de
Linux o gestin de tareas programadas de Windows podran valer. Entre
25 CruiseControl .
24 , y entre las de cdigo abierto,
Hay que destacar que todas estas herramientas lanzan la
compilacin
de
los proyectos asociados, por lo tanto, deben hacer uso tanto de compiladores como de herramientas que dirijan la invocacin al compilador dependiendo de las dependencias y modicaciones en el cdigo fuente (ver seccin 4.5.1). Nuestra experiencia nos dice que CruiseControl (ver gura 4.6) es una alternativa perfectamente vlida, ya que es altamente congurable, soporta una gran cantidad de mtodos de noticacin y sistemas de control de versiones y dispone de interfaz web para poder comprobar el estado. Para dirigir la compilacin, hace uso de
ant, aunque sta puede congurarse para
que delegue el anlisis de dependencias a otras aplicaciones externas, como
make
24 25
o el propio Visual C++.
http://www.urbancode.com/ http://cruisecontrol.sourceforge.net/
4.6. Otras herramientas de soporte
105
Figura 4.6: Captura de CruiseControl en el proyecto JV M 2

Ya hemos destacado en la seccin 4.2.4 que durante el desarrollo de un videojuego educativo debe dedicarse una atencin especial a intentar maximizar la calidad del producto, para que salga al mercado con el mnimo nmero de errores posible. Sin embargo, cuando pensamos en correccin de errores, normalmente nos centramos en los que se producen
en ejecucin,
y que hace que el programa
se comporte de manera extraa o termine de forma inesperada. Para estos fallos, veamos en la seccin 4.5.4, existen herramientas de soporte para el seguimiento de errores, que facilitan el proceso de correccin. Sin embargo, que una aplicacin carezca de errores de ejecucin (si es que eso es posible), no signica que cubra por completo las expectativas del usuario. Los creadores de aplicaciones educativas basadas en videojuegos deben maximizar la diversin del jugador y garantizar que la aplicacin cubre todos los contenidos que se deseaban ensear. En este apartado presentamos dos tcnicas que intentan ayudar en ambos aspectos, por un lado equilibrar el juego para que la dicultad percibida por los jugadores est nivelada independientemente de su nivel de destreza y por otro lado, comprobar si los ejercicios generados para la aplicacin (segn lo descrito en la seccin 4.3.3) son sucientes para la completa comprensin de los conceptos que se estn enseando. Ambas tcnicas utilizan lo que se conoce como Anlisis Formal de Conceptos. El siguiente apartado hace una descripcin de las ideas generales de este formalismo, para abordar, en las dos secciones siguientes, cada uno de
106
Captulo 4.
los problemas particulares que resolvemos.
4.6.1.
Anlisis Formal de Conceptos

Formal Concept Analysis, FCA),
El anlisis formal de conceptos (en ingls
es un enfoque matemtico para el anlisis de datos, representacin del conocimiento y gestin de la informacin basado en las teoras de retculos de Birkho (1973). Fue creado por Wille (1982), y desde entonces ha sido utilizado en muchos y muy diversos campos, como psicologa, sociologa, medicina, biologa, lingstica o ingeniera industrial. En esta seccin nos limitaremos a hacer una descripcin breve del anlisis formal de conceptos. El lector interesado puede consultar literatura adicional. Wol (1993) es un buen texto introductorio, aunque las deniciones matemticas son mejor presentadas por Wille (1982), Ganter y Wille (1998) y Davey y Priestley (2002). El anlisis formal de conceptos se aplica a una coleccin de objetos, que son descritos por sus propiedades. Esas propiedades son denidas nicamente de forma binaria: un objeto puede poseer o no una propiedad o Por ejemplo el objeto y
caza.
len,
puede venir denido por sus atributos
atributo. mamfero
Es importante destacar que el conjunto de datos de entrada al an-
lisis formal de conceptos, por tanto, es
siempre
una relacin binaria entre
objetos y atributos que indica qu atributos tiene cada uno de los objetos. En principio, esta visin binaria de las propiedades de los objetos puede suponer una limitacin cuando se quiere aplicar FCA a dominios complejos. Para superarla, existen tcnicas que se aplican
antes
que FCA y que
se encargan traducir descripciones complejas a relaciones binarias, como la discretizacin de los valores, o el escalado conceptual (Wol, 1993). Formalmente, se dice que el FCA trabaja con un no es mas que una tripleta o entidades,
contexto formal K,
que
(G, M, I ), I GxM
donde
es el conjunto de objetos
es el conjunto de atributos o propiedades que esos objetos es una relacin binaria, que expresa
pueden tener, y por ltimo, siguiente: si
qu atributos describen cada objeto. El signicado de la relacin
es el
(g, m) I ,
entonces el objeto
tiene la propiedad o atributo
m,
o, recprocamente, el atributo
es uno de los descriptores del objeto
g.
les
26 , en el que aparecen cinco objetos (animales), descritos por cuatro atri-
La tabla 4.1 presenta un ejemplo de contexto formal llamado Anima-
butos. El contexto formal est expresado utilizando una tabla, en la que cada la representa un objeto, y cada columna un atributo. Las celdas estn marcadas nicamente cuando el objeto de esa la contiene el atributo de la columna. Si dejamos de lado por un momento FCA, podemos interpretar o denir un concepto de dos formas distintas: o bien enumerando el conjunto de
26
Ejemplo adaptado de (Wol, 1993).
107
Animales Len Gorrin guila Liebre Avestruz
Caza
Vuela
Plumas
Mamfero
Tabla 4.1: Ejemplo de contexto formal sobre animales
objetos que pertenecen a ese concepto (lo que se conoce como ese concepto (llamado
extensin ),
o enumerando el conjunto de propiedades que poseen todos los objetos de
intensin ).
En el reducido entorno descrito por el
contexto formal de la tabla 4.1, podemos decir que el concepto pjaro tiene como extensin los objetos {Gorrin, guila}, y como intensin {Vuela, Plumas}
27 .
Lo que hemos hecho nosotros de manera intuitiva con ese concepto pjaro es, precisamente, lo que hace el anlisis formal de conceptos de manera rigurosa: utilizar el contexto formal para extraer todos los
les
conceptos forma-
que pueden deducirse de l. Matemticamente, se dice que un concepto
formal es una agrupacin
maximal
de objetos que comparten propiedades.
En el ejemplo de los pjaros, todos los objetos de la extensin tienen los atributos de la intensin, y no existe ningn otro objeto que lo haga. Sin embargo, el concepto cuya extensin es {Gorrin}, y cuya intensin es {Vuela, Plumas}
no
se considera un concepto formal para ese contexto, debido a que
la extensin
no
es maximal, pues podemos aadir el objeto guila. Debido a
esta propiedad de maximalidad, existe en cierto sentido una redundancia en un concepto, ya que su extensin determina de manera unvoca su intensin y viceversa. Formalmente, pues, para FCA, un
concepto formal
es una pareja (G ,
) donde
G G
es el conjunto de objetos que pertenecen a ese concepto
(extensin del concepto), y
M M
es el conjunto de atributos comunes
maximales, deber cumplirse que el conjunto de atributos comunes de G es M , y que los objetos del contexto formal que tienen los atributos M son exactamente G . Como veamos anteriormente, se puede ver que el ejemplo del concepto
(intensin). Para que sea cierto el requisito de conjuntos formal pjaro, ({Gorrin, guila}, {Vuela, Plumas}), cumple el requisito de maximalidad, ya que los atributos comunes de los dos objetos son nicamente Vuela y Plumas, y no existen ningn otro objeto que tenga esos dos atributos. Como ejemplo adicional, existe otro concepto formal (ave de
27
Desde el punto de vista biolgico, en realidad un guila no es un pjaro, ya que
pertenece al orden de las rapaces. En esta exposicin consideraremos el concepto pjaro como aquel comnmente aceptado entre la poblacin no experta: ave que vuela.
108
Captulo 4.
presa), formado por ({guila}, {Vuela, Plumas, Caza}). El anlisis formal de conceptos extrae, pues,
todos
los conceptos for-
males de un contexto formal como el de la tabla. Entre ese conjunto de conceptos surge de manera natural una jerarqua dirigida por la relacin superconcepto-subconcepto. En esa relacin se cumple que los subconceptos tienen menos objetos (extensin ms pequea) que sus superconceptos, y, por el contrario, tienen ms atributos (intensin ms grande). Tambin se cumple que la extensin de un subconcepto est incluido en la de
todos
sus superconceptos, y recprocamente, la intensin de un superconcepto est incluida en la de sus subconceptos. Siguiendo con el ejemplo anterior, el concepto pjaro denido como hemos visto como ({Gorrin, guila}, {Vuela, Plumas}), es un superconcepto de ave de presa o ({guila}, {Vuela, Plumas, Caza}), donde se puede ver que se cumplen todas las propiedades anteriores. Formalmente, la relacin un
superconcepto -subconcepto
dene un orden par-
cial entre todos los conceptos formales, lo que matemticamente constituye
retculo. Los retculos pueden representarse en forma de grafo donde cada
uno de los nodos representa un concepto formal, y cada arista indica que los dos conceptos que une estn asociados mediante la relacin superconceptosubconcepto. En la representacin grca, la colocacin de los nodos est seleccionada de tal forma que los superconceptos siempre quedan por
ma
enci-
de todos sus subconceptos. Dado que cada uno de los nodos del retculo representa un concepto, stos
tendrn asociados su conjunto de objetos y de atributos. En la representacin grca del retculo se puede poner, asociada a cada nodo, una etiqueta que contenga la descripcin de ese concepto formal, mediante su extensin e intensin. Sin embargo, eso provocara una representacin complicada de seguir, ya que, por las propiedades vistas en el prrafo anterior, tanto los objetos como los atributos apareceran repetidos en gran cantidad de nodos, al formar parte de la extensin (o intensin) de muchos conceptos formales. Una manera de evitarlo es etiquetar los nodos de tal forma que un atributo aparecen nicamente en el concepto ms alto en la jerarqua que lo contiene en su intensin, y un objeto aparece etiquetando el nodo ms bajo en la jerarqua que lo contiene en su extensin. La gura 4.7 contiene la representacin del retculo de la tabla 4.1 que estamos utilizando como ejemplo, utilizando la representacin simplicada. Para averiguar la extensin u objetos de un concepto, hay que mirar los objetos que etiquetan al nodo que lo representa y los objetos de
conceptos descendientes Caza
todos sus
o subconceptos. Por su parte, los atributos de un
concepto son todos aquellos que aparecen al lado del nodo en el retculo, y los atributos de sus superconceptos. Por ejemplo, el concepto en el que aparece el atributo tiene como
extensin
el conjunto formado por los
objetos Len y guila, ambos pertenecientes a sus dos subconceptos. Por su
109
Avestruz
Mamfero Caza Vuela
Plumas
Liebre
Gorrin
Len
guila
Figura 4.7: Retculo generado a partir del contexto de la tabla 4.1
parte, las propiedades o atributos del concepto en el que aparece el guila sern
Caza, Vuela
Plumas, ya que todos ellos etiquetan en el retculo a sus
superconceptos. Dado que la relacin mostrada en el retculo es un orden parcial, se puede demostrar que ste tendr siempre un nico elemento (concepto o nodo) que es
superconcepto
del resto de nodos, y un elemento que hace de
de todos los dems. Estos nodos son conocidos en ingls como
bottom bottom
respectivamente. El nodo
top
subconcepto nodos top y
representa el concepto que tiene como
intensin a todos los atributos del contexto formal, mientras que el nodo representa el concepto que tiene como extensin a todos sus objetos.
El anlisis formal de conceptos ha sido utilizada con xito en muchos mbitos, escogiendo cuidadosamente los objetos y atributos adecuados para describir el problema, y utilizando distintas tcnicas sobre los conceptos o retculos generados a partir del contexto. Por ejemplo, se ha utilizado para la ayuda en la creacin de ontologas (Obitko et al., 2004), sistemas de recomendacin (du Boucher-Ryan y Bridge, 2005), anlisis de software (Lindig y Snelting, 1997; Eisenbarth et al., 2003; Snelting, 2005), extraccin de reglas de asociacin (Pasquier, 2000) o sistemas de aprendizaje mquina y clasicacin (Carpineto y Romano, 1996; Kuznetsov, 2004). Existen adems numerosas aplicaciones relacionadas con FCA (Tilley, 2004), entre las que destaca ConExp
28 (ver gura 4.8), que se distribuye
bajo licencia BSD. Esta herramienta es la que hemos utilizado como base
28
http://conexp.sourceforge.net/
110
Captulo 4.
Figura 4.8: Captura de ConExp, una herramienta para FCA
para las dos secciones siguientes, que describen con detalle los dos problemas que hemos resuelto usando FCA.
4.6.2.
Renamiento de ejercicios
La metodologa para la creacin de contenidos expuesta en la seccin 4.4 tena como resultado la total separacin de ejercicios y entornos virtuales. Gracias a esta separacin, la aplicacin contiene la batera de ejercicios que presentar expresados en un lenguaje independiente del gnero del juego. Esto permite utilizar tcnicas de anlisis de datos sobre la base de ejercicios para comprobar si sta es completa, es decir, si el estudiante, a la vista de los ejercicios, no puede deducir de ellos ninguna conclusin incorrecta. El anlisis del problema de comprobacin de si la base de ejercicios es completa o no nos llev a presentar en Daz Agudo, Gmez Martn, Gmez Martn y Gonzlez Calero (2005) una solucin general basada en el anlisis formal de conceptos. La generalizacin consiste en extrapolar los resultados obtenidos sobre la base de ejercicios de una aplicacin educativa a un sistema de razonamiento basado en casos, en la que lo que en el sistema educativo eran ejercicios, se convierten en casos, y el problema de comprobar si la base de ejercicios es completa se convierte en comprobar la
cobertura
de la base
de casos. As, como veremos a continuacin, el anlisis formal de conceptos se convierte en una tcnica que ayuda al mantenimiento de la base de casos, para renar el conocimiento contenido en ella de tal forma que maximicemos los resultados obtenidos en la fase de recuperacin del caso. En particular, FCA sirve para encontrar
huecos
en la cobertura dada por la base de casos,
es decir, casos que no estn disponibles en la base de casos pero que pueden
111
Figura 4.9: Vista parcial de la ontologa de elementos de compilacin de Java
ser necesitados en los procesos de razonamiento. La tcnica utilizada consiste en aplicar el
aprendizaje conceptual
dispo-
nible en el anlisis formal de conceptos (Wille, 1989, 1992; Stumme, 1999). Este tipo de aprendizaje es en realidad un procedimiento de adquisicin de conocimiento por renamiento sucesivo. Haciendo un anlisis de los conceptos creados por el FCA a partir de un contexto formal, se pueden inferir determinadas conclusiones o implicaciones que pueden o no ser ciertas. Analizando esas implicaciones se puede determinar que el contexto formal debe ser extendido con otros objetos o atributos. Por ejemplo, en el reducido contexto formal de la tabla 4.1, el anlisis formal de conceptos detecta que todo animal que vuela tiene plumas. El aprendizaje conceptual consiste precisamente en detectar esa implicacin y refutarla, aadiendo al contexto formal (por ejemplo) la abeja, que vuela pero no tiene plumas. Volviendo al contexto de las aplicaciones educativas, veamos cmo utilizamos esto en nuestra aplicacin, JV M presentada en el captulo 6, desarrollada utilizando la metodologa de creacin de contenidos descrita. El sistema, relacionado con la enseanza de la compilacin de lenguajes orientados a objetos, maneja como ejercicios programas en Java. El mdulo pedaggico tiene, entre otras cosas, una ontologa de conceptos relacionados con el lenguaje, que puede verse parcialmente en la gura 4.9. El concepto raz es el elemento de compilacin, cuyos subconceptos son las instrucciones (while,
if,
etc.), las expresiones (sumas, multiplicaciones y operaciones
lgicas entre otras) y las variables (ya sean variables locales, parmetros de
112
Captulo 4.
p u b l i c void f ( ) { int a ; a = 3 + 5; }
(a) Ejercicio 1
p u b l i c void f ( i n t b ) { int a ; a = 3 + b; }
(b) Ejercicio 2
p u b l i c void f ( i n t b ) { int a ; i f ( b == 0) a = 4; }
(c) Ejercicio 3
Figura 4.10: Base de ejercicios inicial antes del renamiento con FCA
mtodos o atributos). Cada ejercicio del sistema est relacionado con uno o ms conceptos de esta ontologa. Cuando el mdulo pedaggico (ver seccin 3.2.3) decide los conceptos que quiere que el usuario practique, consulta la base de ejercicios y selecciona el ms adecuado de acuerdo a la estrategia pedaggica seguida. Para utilizar el aprendizaje conceptual, expresamos los ejercicios de la base de ejercicios utilizando un contexto formal. Para ello, consideramos cada uno de los ejercicios como un como un
atributo,
objeto,
y cada concepto de la ontologa
de tal forma que un objeto tendr asociado un atributo
cuando ponga en prctica o ensee el concepto asociado a l. Para ilustrar el proceso de renamiento de la base de casos, lo ejemplicaremos utilizando como base de ejercicios la expuesta en Daz Agudo et al. (2005). Supongamos que nuestro experto en el dominio ha ideado nicamente los tres ejercicios Java para el sistema educativo que aparecen en la gura 4.10. El ejercicio 1 (gura 4.10a), por ejemplo, al utilizar una variable local
a,
pone en prctica el concepto LocalVariable, y por lo tanto tambin su
concepto padre, Variable. Dado que tiene una instruccin de asignacin, tambin est relacionado con Instruction y AssignmentInstruction. Por ltimo, el cdigo
3+5
es responsable de que el ejercicio tambin ensee los
conceptos Expression y AdditiveExpresion
29 .
La diferencia entre el ejercicio 1 y el ejercicio 2 (gura 4.10b), es que este ltimo tiene adems un parmetro, por lo que tambin ensea el concepto Parameter. Por ltimo, en el ejercicio 3 (gura 4.10c) la expresin aritmtica ha sido
29
Durante todo el ejemplo obviaremos el concepto elemento de compilacin de la
ontologa, por ser padre de todos los dems.
113
LocalVariable
AssignmentInstr
AdditiveExpr
Ejercicio 1 Ejercicio 2 Ejercicio 3
Variable
Ejercicios
Tabla 4.2: Contexto formal de la base de ejecicios inicial
sustituida por una instruccin
if
con una expresin booleana, lo que hace
que se enseen los conceptos IfInstruction y BooleanExpression, pero no se ponga en prctica AdditiveExpression. El anlisis de los tres ejercicios conduce a la creacin del contexto formal que tiene como objetos los tres ejercicios, y como propiedades la lista de todos los conceptos de la ontologa de Java mostrada en la gura 4.9. En la tabla 4.2 mostramos el contexto formal resultante, eliminando aquellos conceptos que no son puestos en prctica por ninguno de los ejercicios. Al aplicar el anlisis formal de conceptos a FCA, obtenemos seis conceptos formales cuya representacin en forma de retculo aparece en la gura 4.11. Cabe destacar de este retculo que el concepto los objetos del contexto formal tiene, al contrario de lo que es habitual,
atributos,
top, que agrupa todos cinco
debido a que todos los ejercicios ponen en prctica los conceptos
asociados a ellos. Si obtenemos las implicaciones vlidas sobre los conceptos formales extrados para comenzar con el aprendizaje conceptual, la primera implicacin que se obtiene es, precisamente, que todos los ejercicios ensean los conceptos Variable, LocalVariable, Instruction, AssignmentInstr y Expression (es decir, aparece la regla {
mentInstr, Expression }).
Variable, LocalVariable, Instruction, Assign-
En el momento de renar la base de ejercicios, el
tutor o experto humano, guiado por este aprendizaje conceptual, introduce un nuevo ejercicio o ejemplo donde esto no sea cierto. El resultado es un nuevo ejercicio, que aparece en la gura 4.12a, que nicamente ensea los conceptos Instruction y CallMethodInstruction. Una nueva iteracin del aprendizaje conceptual nos dice que en el contexto formal o base de ejercicios que tenemos, siempre que aparece una expresin booleana, tambin tenemos una variable, una variable local, un parmetro, una expresin y una instruccin de asignacin y condicional (BooleanExpression Variable, LocalVariable, Parameter, Expression, AssinmentInstr, IfInstruction ). Para romper la necesidad de la existencia de una variable lo-
BooleanExpr
IfInstruction
Instruction
Expression
Parameter
114
Captulo 4.
{Expression, AssignmentInstr, Instruction, LocalVariable, Variable}
Parameter {BooleanExpr, IfInstruction}
AdditiveExpr
Ejercicio 1
Ejercicio 3
Ejercicio 2
Figura 4.11: Retculo de la base de ejercicios inicial
cal cuando tenemos una expresin booleana, el experto introduce en la base de ejercicios uno en el que la expresin booleana se construye utilizando el valor de un parmetro, como en el ejercicio de la gura 4.12b. Con este nuevo ejercicio, extendemos el contexto formal con un quinto objeto, que tiene como atributos la lista de los conceptos que pone en prctica: Instruction, CallMethodInstruction, IfInstruction, Expression y BooleanExpression. Al calcular los conceptos formales y el nuevo retculo, se observan, entre
Variable ; BooleanExpr Parameter ; BooleanExpr LocalVariable ; BooleanExpr Instruction ; BooleanExpr AssignmentInstr ; BooleanExpr IfInstruction ; BooleanExpr Expression }. El experto analiza la primera de ellas ({BooleanExpr Variable }), y la
da por buena dentro del dominio (pues no es habitual encontrar expresiones booleanas que no involucren variables, como implicacin ({BooleanExpr
otras, las siguientes implicaciones: {BooleanExpr
Parameter })
3<6).
Al comprobar la segunda
se comprueba que sta no tie-
ne por qu cumplirse en el dominio. En nuestra reducida base de casos se cumple, debido a que en todos los ejercicios donde hemos utilizado un parmetro, hemos hecho uso de una expresin booleana. Para evitarlo, se aade un ejercicio en el que la expresin booleana utiliza un atributo del objeto en vez de un parmetro (ver gura 4.12c). Este nuevo ejercicio hace aparecer un nuevo concepto en el contexto formal que hasta este momento no habamos enseado, el concepto Attribute. La consecuencia inmediata es que FCA inere que ste aparece siempre relacionado con el concepto IfInstruction, ya que siempre que aparece el
115
p u b l i c void auxf ( ) { System . out . p r i n t l n ("En auxf ( ) " ) ; } p u b l i c void f ( ) { auxf ( ) ; }

(a) Ejercicio 4
p u b l i c void f ( i n t a ) { i f ( a > 0) System . out . p r i n t (" P o s i t i v o " ) ; }

(b) Ejercicio 5
p u b l i c void f ( ) { i f ( t h i s . age > 18) System . out . p r i n t (" mayor " ) ; }

(c) Ejercicio 6
p u b l i c void cumple ( ) { edad = edad + 1 ; }

(d) Ejercicio 7
Figura 4.12: Ejercicios aadidos mediante renamiento con FCA
primero tambin lo hace el segundo. Para romper esta dependencia, el experto introduce un nuevo ejercicio (en la gura 4.12d), para indicar que los atributos pueden aparecer sin la instruccin
if.
Al ejecutar de nuevo FCA con el ejercicio recin aadido, se detecta que siempre que aparece el concepto Attribute lo hacen tambin los de Variable, Instruction y Expression. El experto comprueba que esto es cierto en el dominio, ya que: Segn la ontologa de Java que utilizamos (gura 4.9), el concepto Attribute es un subconcepto de Variable, por lo tanto el segundo aparecer siempre que lo haga el primero. Todos los ejercicios deben tener al menos una instruccin Java. Los accesos a atributos se hacen siempre a travs de expresiones. Aunque an quedan implicaciones que no son vlidas en el dominio y que deben ser refutadas por un experto aadiendo nuevos ejercicios (casos), pararemos aqu, dando una idea de cmo seguira el proceso. La nueva implicacin no vlida detectada por el aprendizaje incremental es {BooleanExpr
truction }, ya que las expresiones booleanas aparecen siempre de la mano de if's. El experto, por tanto, deber romper la relacin introduciendo una nueva instruccin, como el while, que requiere expresiones booleanas pero no utiliza la expresin if. Eso provocar que la vieja e incorrecta dependencia se convierta en dos dependencias nuevas, {IfInstruction BooleanExpr } y {WhileInstruction BooleanExpr }, ambas correctas.
IfIns-
116
Captulo 4.
BooleanExpr
Instruction
CallMethodInstr
AssignmentInstr
LocalVariable
AdditiveExpr
IfInstruction
Parameter
Expression
Ejercicio 1 Ejercicio 2 Ejercicio 3 Ejercicio 4 Ejercicio 5 Ejercicio 6 Ejercicio 7
Variable
Ejercicios
Tabla 4.3: Contexto formal de la base de ejercicios nal
El contexto formal resultante del proceso de aadir los cuatro nuevos ejercicios mostrados en la gura 4.12 aparece en la tabla 4.3. El retculo nal asociado al contexto formal de la tabla 4.3 es el que aparece en la gura 4.8 de la pgina 110 que mostraba la herramienta ConExp. El proceso de renamiento de la base de ejercicios utilizando FCA puede, como hemos dicho, extrapolarse a bases de casos generales donde un experto quiere comprobar si la cobertura que sta proporciona es lo sucientemente extensa. En vista del ejemplo, las reglas o implicaciones que se generan utilizando FCA y que son las que dirigen el proceso de aprendizaje conceptual pueden interpretarse como ciertas, en cuyo caso no se requiere ninguna accin, o falsas, lo que provocar que el experto aada un nuevo caso a la base de casos. Para concluir, en nuestro ejemplo, las reglas pueden ser ciertas por dos razones: por ser el resultado de dependencias entre atributos debido a la jerarqua de conceptos subyacente (como en nuestro caso la regla {Local-
Variable Variable }), o por ser ciertas en el dominio, como por ejemplo {IfInstruction BooleanExpr }. En ese ltimo caso, las reglas deducidas
pueden ser utilizadas por el mdulo pedaggico para dirigir el orden en el que se presentan los conceptos al alumnos.
4.6.3.
Nivelado del juego
Como decamos en la seccin 4.2.4, el esfuerzo que necesita realizar un jugador para superar los niveles y oponentes tiene un efecto importante en el entretenimiento percibido. Los jugadores ocasionales preeren enemigos vencibles, mientras que los habituales preeren enemigos que supongan un
Attribute
117
gran reto. Para conseguir que todos los tipos de usuarios estn conformes con la dicultad del juego, lo habitual es que al principio de una partida, el jugador pueda indicar a qu
nivel de dicultad
desea enfrentarse
30 . El diseador del
juego, por tanto, decide una serie de parmetros que cambiarn entre un nivel de dicultad y otro. Esta decisin, sin embargo, no es fcil. Si bien es cierto que en juegos sencillos los parmetros que hay que cambiar son evidentes, no lo resultan tanto en otros. Por ejemplo, parece claro que en el juego del buscaminas el incremento del tamao del tablero o del nmero de minas afecta a la complejidad. Sin embargo, en juegos no triviales, el enlace o dependencia entre los parmetros del juego y su complejidad no est tan denida. Para ayudar precisamente en el nivelado del juego, presentamos en Gmez Martn, Gmez Martn, Gonzlez Calero y Daz Agudo (2006b) un uso del anlisis formal de conceptos que puede ayudar en la tarea. Para explicar el proceso, el primer paso es entender cul es el trabajo del diseador en cuanto a
nivelado
de la dicultad del juego.
Al crear un juego cuyo nivel de dicultad es esttico y elegido previamente por el jugador, el diseador debe, como primer paso, decidir entre cuntos niveles de dicultad va a poder elegir el jugador. Para eso, consideraremos
al conjunto de esos niveles, por ejemplo:
L = {f acil, normal, dif icil}

Por otro lado, el diseador tiene a su disposicin distintos parmetros que puede cambiar para establecer la dicultad del juego. Por ejemplo, en un juego FPS, puede cambiar el nmero de enemigos en el mapa, o la precisin del arma. Llamaremos al conjunto de esos parmetros de diseo elementos
pi P
tienen un dominio especco, que denotaremos con
P . Todos los D(pi ).
Por ejemplo, el dominio del parmetro que indica el nmero de enemigos del mapa son los nmeros naturales.
P = {numeroenemigos, precisionarma} D(numero

enemigos)
= N+ li L,
el valor de
La tarea del diseador en el momento de nivelar el juego, por tanto, es decidir, para cada uno de los elementos parmetros
todos
los
pi P ,
es decir, tiene que denir las funciones:
ti : L D(pi )
30
Existen investigaciones en marcha para aadir
dicultad adaptativa
en los juegos
(Spronck et al., 2006; Charles et al., 2005; Ponsen y Spronck, 2004), aunque hoy por hoy los que lo incorporan son minoritarios.
118
Captulo 4.
o, agrupndolas todas en una nica funcin del diseador):
(por representar la
tarea
t : L D(p1 ) . . . D(pn )
que es la funcin que recibe el nivel de dicultad, y proporciona la tupla con todos los valores de cada parmetro. Como ya hemos comentado, cuando el juego es sencillo, estos valores se deciden
ad hoc,
utilizando intuicin y sentido comn. Sin embargo, cuando
los juegos son ms complejos, se necesitan otros mecanismos. Uno de estos mecanismos es realizar pruebas con grupos de jugadores reales en etapas tempranas del desarrollo. El conjunto de personas (al que llamaremos
T)
se elige de tal forma que el nivel de habilidad est distribui-
do de forma uniforme, aunque son enfrentados todos a la misma
versin
del
juego, independientemente de su nivel estimado. Durante las partidas, los diseadores observan la forma en la que cada uno se desenvuelve, para ayudarle a entender
cmo la gente juega a su juego.
La aplicacin, adems, suele ser
una versin modicada que deja registrado en cheros externos informacin valiosa que posteriormente los diseadores podrn analizar. Nuestra tcnica se basa en la premisa de que somos capaces de
estimar
la
habilidad de los jugadores, teniendo en cuenta su nivel con juegos similares, su acin a los videojuegos, etc. Es decir, contamos con una funcin que nos indica el nivel de dicultad de cada jugador:
s:T L
Como hemos dicho, la versin modicada del juego genera un registro que despus podremos analizar. Formalmente, podemos establecer que esa versin especial es capaz de en adelante llamaremos
medir
un conjunto de parmetros, que de aqu
M,
como el tiempo que tarda el jugador en pasar
una fase o el nmero medio de disparos antes de acertar a un enemigo. Igual que antes, cada uno de los valores
mi M
tendr un dominio determinado,
D(mi ).
Inspeccionando los registros generados, podremos averiguar, para cada jugador, los valores de los parmetros medibles de denida la funcin:
M,
es decir, tendremos
fi : T D(mi )
o, agrupndola en una funcin general que devuelve una tupla:
f : T D(m1 ) . . . D(mn )
Los datos extrados de
deben servir a los diseadores para extraer
conclusiones, como por ejemplo que los jugadores noveles de un FPS (por
119
ejemplo, el conjunto {j |j
T, s(j ) = f acil}), necesitan mucha ms municin
que los expertos. Con esas conclusiones, el diseador decidir hacer que en los niveles fciles sea sencillo conseguir municin extra. Para que las conclusiones a las que se llegan a partir de la informacin generada pueda aplicarse, por tanto, es necesario que exista una dependencia entre los valores que medimos en el experimento (M ), y el conjunto de parmetros del juego que podemos cambiar (P ). En otras palabras, asumimos que los datos obtenidos de un jugador
j , f (j ),
seran distintos si los
hubiramos medido con valores distintos de los parmetros
P 31 .
Desgraciadamente, la cantidad de informacin recopilada en un experimento como el descrito puede ser demasiado grande para permitir a los diseadores un anlisis manual. Nuestra aportacin consiste en aplicar anlisis formal de conceptos para procesarla y proporcionar pistas que ayuden en el equilibrado del juego. En esta ocasin, utilizamos la capacidad de FCA de extraer
dependencia
reglas de
o asociacin (Hipp et al., 2000). Una regla de asociacin es una
expresin con la forma
A B A
donde tanto
como
son atributos, y
que puede interpretarse como que todos los objetos del contexto formal que contienen los atributos en contienen tambin los de
B.
Las reglas de asociacin se caracterizan por dos parmetros:
Conanza: expresa la
probabilidad
B.
de que la regla se cumpla, o en otras
palabras, el porcentaje de objetos que, teniendo todos los atributos de
A,
tienen tambin los de
Soporte: indica cuntos objetos cumplen la regla, es decir, el nmero de objetos que entre sus propiedades tienen todas las de los dos conjuntos,
B.
El valor puede darse tanto en manera absoluta (nmero de
objetos), como en porcentaje (nmero de objetos entre nmero total de objetos).
En la tabla 4.4 se muestran como ejemplo las reglas de dependencia extradas del contexto formal presentado en la tabla 4.1 que tienen una conanza de ms del 50 % y un soporte de al menos un objeto
32 .
Los algoritmos de extraccin de reglas utilizando anlisis formal de conceptos son capaces de obtener de forma eciente todas las reglas por encima de un determinado nivel de conanza y soporte. Aunque existen distintos algoritmos, en nuestro caso hemos utilizado el expuesto por Duquenne y Guigues (1986) para extraer las reglas exactas (con un cien por cien de
31 32
Como ejemplos de valores medibles
que no cumplen esto, tendramos el nmero de
veces que un jugador pausa el juego, o el nmero de saltos que da. La ltima regla de la tabla no tiene atributos en la parte izquierda; lo que indica es que todos los objetos tienen Plumas con un 60 % de conanza.
120
Captulo 4.
Regla
Conanza 100 % 100 % 66'6 % 60 %
Soporte 1 2 2 3
Vuela Plumas Plumas Vuela Plumas

Caza Plumas Vuela
Tabla 4.4: Reglas de dependencia del contexto formal de la tabla 4.1
conanza), y el de Luxenburguer (1991) para las no exactas. Para la implementacin nos hemos basado en la disponible en ConExp. El mtodo de uso consiste en generar, para cada uno de los jugadores en
un
objeto
en el contexto formal que posteriormente procesaremos. Los
atributos de ese contexto son de dos tipos: Nivel de juego: existe un atributo por cada elemento est catalogado segn la funcin
li L.
Cada
objeto tendr nicamente la propiedad que marca el nivel en el que
s. M)
son traducidos a uno o ms
Valores de los parmetros medibles: cada uno de los parmetros que se miden en el experimento (mi atributos en el contexto formal. Dado que normalmente esos parmetros son numricos, es probable que se requiera hacer escalado de sus valores (Wol, 1993), como veremos en el ejemplo que mostraremos a continuacin. Las reglas de dependencia extradas con FCA relacionan unos atributos con otros. Algunas de las reglas sern el resultado de dependencias dadas en el dominio en cuestin, como por ejemplo las resultantes del escalado de atributos, o las denidas explcitamente en el juego (por ejemplo, la que relaciona el nmero de balas gastadas con el nmero de municin recogida). Las reglas que interesan para ayudar al diseador son todas aquellas que tienen en su parte izquierda atributos relacionados con el primer grupo de atributos que mencionbamos):
nivel
del juego (el
li b1 ... bn
(conanza
del c %)
donde li representa el atributo correspondiente a ese nivel de dicultad, y
b1 ...bn son los parmetros medibles codicados para poder expresarlos dentro
del contexto formal. Como prueba de concepto, hemos ayudado a un supuesto diseador del Tetris a nivelar el juego (Gmez Martn, Gmez Martn, Gonzlez Calero y Daz Agudo, 2006b). El experimento comienza con la modicacin de un clon del tetris llamado U61 (Mauduit, 2003). La aplicacin, que se muestra en la gura 4.13, est disponible bajo licencia GPL, lo que nos permiti
121
Figura 4.13: Captura de U61, clon del tetris
modicarla para generar cheros con informacin sobre las partidas que se juegan. El conjunto de parmetros medibles (M ) que se guardan (adems del nombre del jugador) es: La puntuacin conseguida. El nmero de piezas colocadas. Para cada uno de los siete tipos de piezas que hay:
El tiempo medio en colocar cada cha. El nmero de cambios de direccin medios. Cuando una pieza est cayendo, el jugador puede elegir moverla en una u otra direccin. Si el usuario, una vez empezada a mover la cha, cambia de opinin y la empieza a mover en sentido contrario, queda registrado.
El nmero medio de veces que una cha golpea con los muros laterales o con otras chas ya colocadas previamente. Existen dos valores, uno para los choques al mover la cha hacia la izquierda, y otro hacia la derecha.
El nmero medio de veces que una cha golpea muros u otras chas cuando se rota en cada una de las dos direcciones posibles. El nmero medio de espacios dejados por la cha al colocarse en el tablero. Los huecos se miden intentando colocar la cha una posicin ms abajo de la posicin nal. Se registra un previa.
hueco
por
cada cuadrado del tetramin que no colisiona con alguna cha
122
Captulo 4.
Medio
Partidas Jugador 1 Jugador 2 Jugador 3 Jugador 4
Difcil
Fcil
<300
<400
<500
<600
<700
<800
<900
900
Tabla 4.5: Contexto formal parcial de las partidas de tetris
Para el estudio, la informacin de cada tipo de cha fue agrupada, de tal forma que para el anlisis con FCA generamos un contexto formal que nicamente tena las medias cha. Para poder crear el contexto, hicimos el
totales,
en vez de su distribucin por tipo de
escalado
de los parmetros medi-
bles. Por ejemplo, para el parmetro que indica el tiempo medio de colocacin de cada cha, creamos 8 atributos distintos, para denir los intervalos desde los 300 milisegundos hasta los 900, aadiendo tambin la posibilidad de que el valor fuera menor de 300 o mayor de 900. La tabla 4.5 muestra parcialmente el contexto formal generado en el experimento. Como vemos, existe una la/objeto por cada uno de los jugadores (partidas). Existen despus tres atributos, que se corresponden con los distintos niveles de dicultad (li
L), que en el experimento establecimos como
{facil, medio, dicil}. En la tabla se ven tambin los atributos para el parmetro que dene el tiempo medio de colocacin por cha. Como se puede ver, el primer jugador tiene una media inferior a los 300 milisegundos, el segundo est entre los 400 y los 500 milisegundos, mientras que el cuarto tarda ms de 900 milisegundos de media. Al extraer del contexto formal las reglas de dependencia ocultas en el contexto formal, surgen, como dijimos, una gran cantidad de reglas exactas debido al mecanismo de escalado, como:
<7 <8 , <9
(conf. 100 %)
Ignorando esas reglas debidas al escalado, el anlisis formal de conceptos extrae otras que s son tiles al diseador, como:
f acil medio dif icil dif icil <300 900
<800 <800 <500 <400 dif icil f acil
(conf. 85.71 %) (conf. 100 %) (conf. 100 %) (conf. 75 %) (conf. 100 %) (conf. 100 %)
Las conclusiones a las que llega el diseador son las que, en este caso,
Resumen
123
habramos podido extraer utilizando sentido comn: cambiar la velocidad a la que caen las chas (un parmetro de diseo en
P ), afecta directamente en la M ) que indica el tiempo
experiencia del jugador. Eso es debido a que ese parmetro est directamente relacionado con el parmetro medible (del conjunto relacionado con el nivel del jugador. Aunque el ejemplo anterior llega a unos resultados ms que evidentes, debemos destacar otros resultados menos intuitivos a los que podemos llegar al analizar el resto de reglas extradas (que no listamos). De ellas se puede concluir que los usuarios avanzados golpean con ms frecuencia las chas que estn colocando con las paredes y chas ya jas en el tablero que una posible decisin de diseo podra haber sido hacer que cada vez que se produjera uno de estos choques se penalizara bajando la cha una posicin. Segn las conclusiones, este cambio afectara a los jugadores avanzados, dejando la experiencia de juego prcticamente intacta para los noveles. Una ltima conclusin a la que se llega en el anlisis de los datos es que el nmero de cambios de direccin medio realizan los jugadores (es decir, el nmero de veces que dudan) no est directamente relacionado con su habilidad, por lo que el diseador no debe plantearse modicar ningn aspecto del diseo relacionado con este parmetro medido. que tarda el usuario en poner una cha, que, segn las reglas anteriores, est
33 , por lo
Resumen
En este captulo hemos detallado el proceso de desarrollo de un videojuego educativo. Hemos visto (seccin 4.2) que ste puede dividirse en cinco fases de forma similar a las comnmente aceptadas en la creacin de un videojuego con nes ldicos. En esa misma seccin, describamos los objetivos y tareas que deben realizarse en cada una de estas fases, en comparacin con lo necesario para la implementacin de una aplicacin ldica sin contenido pedaggico. Una de las diferencias ms importantes es la
creacin del contenido
o da-
tos que la aplicacin utilizar para presentar al usuario. Despus de describir brevemente distintas alternativas para su creacin en la seccin 4.3, hemos propuesto una metodologa para su creacin en la seccin 4.4. Despus hemos pasado a analizar y recomendar las herramientas de soporte ms adecuadas para el desarrollo de videojuegos educativos (seccin 4.5). Por ltimo, en la seccin 4.6 hemos visto cmo podemos hacer uso del anlisis formal de conceptos como una herramienta de anlisis auxiliar para ayudar en dos aspectos importantes que se deben comprobar del funcionamiento de una aplicacin educativa: el nivelado del nivel de dicultad del
33
Suponemos que esto es debido al uso de la repeticin de teclado.
124
Captulo 4.
juego, y la cobertura de los ejercicios disponibles en la aplicacin. En el prximo captulo describimos la propuesta arquitectnica para el desarrollo de sistemas educativos basados en videojuegos. Esta arquitectura tiene como
premisa
que el proceso de generacin de contenidos para las
aplicaciones que se rigen por ella han sido creados utilizando la metodologa expuesta en este captulo.
Notas bibliogrcas
Para una descripcin breve del proceso de desarrollo de un videojuego, se puede consultar Llopis (2005a), aunque si se desean detalles sobre la parte de diseo y nivelado del juego, denitivamente las guas son Crawford (1984) (cuyo captulo 5 es muy enriquecedor, para comprobar el avance que ha sufrido el rea), Rollings y Adams (2003) y Crawford (2003) (este ltimo una revisin del publicado en 1984). Un anlisis de las herramientas necesarias aparece en Gmez Martn, Gmez Martn y Jimnez Daz (2007c). Para la creacin de contenidos en videojuegos son ilustrativos los documentos (no acadmicos) que sirven de gua o manual de los distintos editores de mapas liberados por distintas compaas, como el del editor SandBox utilizado para Far Cry (Crytek, 2004). Para comprender hasta qu punto los editores de niveles
programan
el documento de diseo utilizando entidades,
es interesante Martel (2006). Para terminar con la literatura relacionada con la creacin de contenidos para aplicaciones educativas, la explicacin de Gmez Martn, Gmez Martn, Daz Agudo y Gonzlez Calero (2005c) resulta de especial relevancia, ya que muestra una forma de generar automticamente ejercicios, que luego pueden servir de entrada para la creacin de los entornos virtuales. Relacionado con el anlisis formal de conceptos, una bibliografa on-line bastante extensa puede encontrarse en
http://www.fcahome.org.uk.
Exis-
ten tambin algunos libros monogrcos dedicados nicamente a FCA, como Ganter y Wille (1998) y Davey y Priestley (2002). Por ltimo, destacar la existencia de dos conferencias internacionales dedicadas: la serie de conferencias internacionales en anlisis formal de conceptos (ICFCA) iniciada en 2003, y la conferencia internacional en estructuras conceptuales (ICCS), desde 1995. Con respecto al uso que damos nosotros al FCA, ya hemos dicho durante su exposicin que el anlisis de los ejercicios o contenido pedaggico ha sido presentado en Daz Agudo, Gmez Martn, Gmez Martn y Gonzlez Calero (2005), mientras que el de nivelado de juego aparece en Gmez Martn, Gmez Martn, Gonzlez Calero y Daz Agudo (2006b).
Captulo 5
Arquitectura para el desarrollo de sistemas educativos basados en videojuegos

Todo mtodo consiste en el orden y disposicin de aquellas cosas hacia las cuales es preciso dirigir la agudeza de la mente.
Ren Descartes
Este captulo presenta nuestra arquitectura de aplicaciones educativas basadas en videojuegos. Empieza marcando cules son sus objetivos, para pasar a mostrar la visin general de la misma. Posteriormente analiza cada uno de los mdulos en detalle. El captulo termina con una evaluacin. Ms adelante, en el captulo siguiente se describir una aplicacin educativa desarrollada con ella.
5.1. Introduccin
En el captulo anterior detallbamos la metodologa a seguir para el desarrollo de aplicaciones educativas basadas en videojuegos. Veamos que la divisin del contenido en dos partes claramente diferenciadas, entornos virtuales y contenidos pedaggicos (ejercicios), es beneciosa en muchos aspectos. En este captulo pasamos a describir la arquitectura software que soporta esa metodologa. Como veremos, las partes principales de las que se compone una de estas aplicaciones son las mismas ya disponibles por separado en los ITS y los videojuegos. En realidad, ya en el captulo anterior describamos una arquitectura muy general. En aquel momento, al hablar de los contenidos dividimos la aplicacin en dos grandes bloques: el motor de la aplicacin y el cdigo 125
126
Captulo 5.
Arquitectura de sistemas educativos basados en juegos
especco. La gura 4.3 reejaba que el primero de ellos lee los datos relacionados con el entorno virtual, mientras que el segundo se encarga de la informacin relacionada con el dominio educativo. Tras una enumeracin de los objetivos que perseguimos con la arquitectura, el captulo pasa a renar el esquema anterior, separando esos dos grandes bloques en otros sistemas ms pequeos, agrupando la funcionalidad y minimizando la dependencia entre ellos. Una vez descrito el esquema general renado de la arquitectura, se pasan a detallar cada uno de los mdulos. Posteriormente, se explica de qu forma la arquitectura soporta la separacin entre los dos tipos de informacin (entorno virtual y conocimiento del dominio) que propone la metodologa del captulo 4. El ltimo apartado del captulo realiza una evaluacin.
5.2. Objetivos de la arquitectura

Los objetivos principales que guan el diseo de la arquitectura expuesta en este captulo son los siguientes:
1. Minimizar la dependencia entre el conocimiento especco del dominio que se ensea y el resto del sistema. De esta forma, el conocimiento del dominio puede aprovecharse para implementar otros videojuegos educativos que enseen lo mismo pero de distinta forma. Tambin permite utilizar las partes no especcas del dominio en varios juegos educativos. En denitiva, permite la
reutilizacin,
de forma que se reduzcan
los costes de creacin de este tipo de aplicaciones. 2. Permitir que en desarrollos posteriores sean fcilmente sustituibles algunos mdulos. Principalmente se perseguir poder tecnolgico. 3. Permitir que los distintos profesionales que entran en juego durante el periodo de desarrollo puedan trabajar sin solaparse unos con otros, minimizando las dependencias entre ellos.
intercambiar
fcil-
mente aquellos mdulos susceptibles de quedar obsoletos con el avance
Todos estos objetivos pueden resumirse en uno: reducir al mnimo la dependencia entre distintas partes, para hacerlas intercambiables. Para ello, la arquitectura parte de una premisa: la metodologa de creacin de contenidos utilizada para el desarrollo
debe
ser la expuesta en el
captulo anterior. Es decir, los cheros de datos que alimentarn a la aplicacin deben estar claramente divididos en los que sirven para almacenar las propiedades del entorno virtual, y los utilizados para guardar el contenido educativo.
5.3. Visin general
127
Conceptos
Mdulo experto Ejercicios Mdulo pedaggico Mdulo de comunicacin
Subsistema de tutora Perfiles Modelo del estudiante
Vista lgica del mundo
Objetos del entorno (entidades)
Motor de la aplicacin Mapas Modelos, sonidos,...
Figura 5.1: Arquitectura general de un sistema educativo basado en videojuegos
5.3. Visin general

La gura 5.1 muestra un esquema general de la arquitectura. A primera vista, podemos distinguir dos grandes bloques: el encargado de la gestin del sistema de tutora, y el responsable de la gestin del entorno virtual. El primero de ellos (parte superior de la gura) se basa en las ideas que describimos en el captulo 3. El subsistema de tutora est formado por tres grandes mdulos encargados de tomar las decisiones pedaggicas, en base al perl o modelo del estudiante y al dominio concreto que se est enseando. Estos mdulos necesitan una serie de datos que normalmente se encuentran contenidos en cheros: los conceptos o conocimiento del dominio, los ejercicios y el perl del estudiante. El
mdulo de comunicacin
del subsistema de tutora es el que sirve
como punto de unin entre todo el subsistema y el exterior; todos los mdulos internos deben pasar por el de comunicacin para interactuar con el entorno. El resto de subsistemas, que aparecen en la parte inferior de la gura, estn relacionados con el entorno virtual. El motor de la aplicacin es el de ms bajo nivel, encargado de tareas como dibujar o leer el estado de los dis-
128
Captulo 5.
positivos de entrada. Tambin es el encargado de leer los mapas que denen el aspecto visual. Durante el captulo anterior, esta componente apareca en los diagramas bajo el nombre de
motor del juego.
Por encima de ste, aparecen los objetos o entidades del entorno. En la seccin 2.6 denamos a las entidades como una pieza autocontenida de contenido interactivo (Llopis, 2005b), denicin que puede aplicarse tanto en videojuegos como en cualquier aplicacin que utilice un entorno virtual. Podemos ver este mdulo como una capa que gestiona la apariencia o comportamiento dentro del interfaz de los objetos interactivos y autnomos. Por ejemplo, en esta capa se coloca el funcionamiento de puertas, interruptores, ascensores y otros elementos del entorno. En videojuegos, es habitual llamar a ese mdulo el
juego
cdigo especco del vista lgica
(ver seccin 2.4 y gura 4.2). En esas aplicaciones, la inteligencia artien otro
cial suele ser lo sucientemente simple como para poder codicarla directamente en este subsistema. En nuestro caso, situamos la mdulo distinto, que almacena la parte del estado del mundo relevante desde el punto de vista educativo. Gracias a eso, el subsistema de tutora tiene toda la informacin que necesita, y por lo tanto esta
vista lgica
se convierte en
el nico punto de unin entre l y el entorno virtual. Como veremos, en este mdulo tambin implementaremos la inteligencia articial de ms alto nivel de algunos de los objetos del entorno. En los apartados siguientes analizamos en detalle cada uno de estos mdulos.
5.4. Subsistema de tutora

El subsistema de tutora sigue el esquema visto en la seccin 3.2. Los cuatro mdulos que aparecen en la gura 5.1 son los siguientes:
Modelo del estudiante: contiene una representacin del estudiante. Esta representacin suele incluir una lista de los conceptos que aparentemente conoce, los ejercicios que ha resuelto previamente, o ciertos parmetros que denen su personalidad. Durante la ejecucin de la aplicacin, el modelo del estudiante es actualizado con la informacin recibida desde el resto de mdulos del subsistema de tutora. Eso incluye las posibles situaciones que se pueden dar en el entorno virtual y que llegan a travs del mdulo de comunicacin. Mdulo pedaggico: es el que decide qu ejercicio presentar al usuario a continuacin, por lo que tiene que tener acceso a la base de datos de ejercicios. Tambin tiene otras tareas relacionadas con la parte educativa. Por ejemplo, si existe una monitorizacin continua del estudiante, se encarga de emitir al mdulo de comunicacin las rdenes necesarias
129
Conceptos
Mdulo experto Base de ejercicios Ejercicio actual Consulta Mdulo pedaggico
ITS Modelo del estudiante
Gestin perfiles
...
...
Proporcionar explicacin Avance ejercicio Estudiante inactivo Establecer perfil
Figura 5.2: Vista detallada del subsistema de tutora
para que el interfaz haga llegar al usuario las explicaciones y sugerencias que parece necesitar. Mdulo experto: es el que contiene el conocimiento del dominio, consistente en los conceptos que hay que ensear, explicaciones, y modo de resolver los ejercicios. Si el mdulo no es lo sucientemente sosticado y no es capaz de resolverlos, las soluciones debern estar almacenadas en la propia base de problemas, y el mdulo experto leer de ella la solucin. En ese caso, la principal tarea del mdulo es comparar la solucin parcial aportada por el estudiante con la leda, y detectar cuando las discrepancias son excesivas. Mdulo de comunicacin: sirve de interfaz entre el subsistema de tutora y el resto de la aplicacin. La comunicacin se realiza en base a la vista lgica del mundo, y es por lo tanto una comunicacin de alto nivel. No se tienen pues en cuenta detalles como animaciones de los avatares o colisiones del personaje con el entorno, sino acciones relevantes para el mdulo de tutora, como progreso en la ejecucin del ejercicio. Aunque los mdulos aparecen separados en el esquema general, en realidad todos ellos estn comunicados, e intercambian informacin para realizar su labor. Adems, todos interactuarn en mayor o menor medida con la parte visible de la aplicacin, modicando ciertos aspectos de sta, a travs del mdulo de comunicacin, y recibiendo informacin sobre los cambios que se producen, para actualizar su visin de ella. En la gura 5.2 se pueden ver algunos ejemplos de la informacin que uye a travs del mdulo de comu-
130
Captulo 5.
nicacin. En particular, el mdulo pedaggico puede decidir que es preciso dar alguna explicacin al usuario, y as puede hacrselo saber a la vista lgica del mundo; la vista lgica puede informar del avance en la ejecucin del ejercicio, para que el mdulo experto compruebe si el estudiante va bien o no; tambin puede indicar que el estudiante lleva ocioso mucho rato sin hacer nada realmente interesante en el entorno, por si el subsistema de tutora quiere tomar alguna medida. Adems de compartir informacin entre ellos, el esquema general de la arquitectura establece que los mdulos pueden utilizar datos externos como fuente de informacin. En este sentido, el mdulo experto puede leer de disco por ejemplo los conceptos que se pretenden ensear, o cualquier otro tipo de informacin que le ayude a resolver los ejercicios que se plantearn al usuario, as como explicaciones o textos que se le proporcionan. El mdulo pedaggico, por su parte, debe tener acceso a la base de ejercicios. En nuestra arquitectura, en vez de ser el propio mdulo el encargado de leer de disco la lista de ejercicios para decidir cul es el ms adecuado, delegamos esa responsabilidad en un mdulo externo (que no aparece en la gura 5.1). Este mdulo lee todos los ejercicios y tiene el concepto de ejercicio actual. El mdulo pedaggico puede pedir al mdulo, a modo de consulta en una base de datos, que seleccione el ejercicio que ponga en prctica una serie de conceptos, que ste habr seleccionado previamente de acuerdo al perl del estudiante. El ejercicio seleccionado, ser tambin utilizado por el mdulo responsable de la vista lgica del mundo, segn veremos en la seccin 5.5. Siguiendo esta aproximacin, el mdulo de recuperacin de ejercicios puede aplicar tcnicas sosticadas, como las de adaptacin nombradas en la seccin 4.4 que, en vez de devolver ejercicios existentes en la base de datos, creaba ejercicios nuevos ajustados a la consulta, adaptando los ya existentes (Gmez Martn, Gmez Martn, Daz Agudo y Gonzlez Calero, 2005c). Por ltimo, el mdulo responsable de mantener actualizado el perl del usuario, tambin utiliza un mdulo externo encargado de la base de datos de todos los estudiantes. En esos cheros est la informacin de todos los usuarios del sistema. Cuando se inicia la aplicacin, el interfaz grco se encarga de que el usuario se identique en el sistema, para poder cargar su perl. Eso provoca que el mdulo gestor de los perles active el estudiante actual (ya sea creando un nuevo perl, o cargando de disco el existente), para que el modelo del estudiante del subsistema de tutora lo tenga disponible. Este tipo de comportamiento es el funcionamiento habitual en las aplicaciones de entretenimiento, donde un jugador, al arrancar la aplicacin, carga una partida que dej a medias en la ejecucin anterior.
5.5. Vista lgica del mundo
131
Al mdulo cognitivo
Vista lgica del mundo Avance ejercicio Simulador ... Acciones sobre el entorno
. . . . Usuario inactivo Comportamiento avatar Monitorizacin estudiante
Cambios en el entorno Percepcin Accin
Acciones
Figura 5.3: Esquema detallado del mdulo de vista lgica
5.5. Vista lgica del mundo

Para que sea posible el razonamiento que se realiza en el subsistema de tutora, es necesario que la representacin del estado del entorno virtual no sea demasiado especca. Lo mismo ocurre para poder denir el comportamiento inteligente de los objetos del entorno ms importantes desde el punto de vista del sistema educativo. En este mdulo se almacena el estado del mundo, a un nivel de abstraccin suciente como para poder aplicar las tcnicas de razonamiento adecuadas. Puede estar codicado en el lenguaje de programacin utilizado en el resto de la aplicacin, o puede hacer uso de otro tipo de tcnicas, como sistemas expertos u ontologas. En cualquier caso, la visin lgica del mundo sirve de
fachada
que oculta
los aspectos de ms bajo nivel del entorno virtual que dicultaran ese razonamiento, de tal forma que todo lo que el subsistema de tutora necesita saber para realizar su funcin se encuentra disponible en este mdulo. Para funcionar, recibe informacin de bajo nivel del entorno virtual y la abstrae para almacenar nicamente la parte relevante al subsistema de tutora. Por tanto, sirve de vista pedaggico. En este mdulo se desarrollan tres funciones principales (ver gura 5.3):
ltro
que aisla de la batera de hechos que ocurren
en el entorno virtual los que son realmente interesantes desde el punto de
Simulacin: para todas aquellas aplicaciones educativas que simulan algn aspecto de la vida real (como el manejo de una sala de mquinas) el cdigo responsable de esa simulacin est ubicado aqu. De esta forma, el mdulo almacena el estado del mundo. Cuando se ejecutan
132
Captulo 5.
ciertas acciones en el entorno virtual (como activacin de interruptores por parte del estudiante), stas provocan cambios en la visin lgica, que es actualizada por el simulador. Estas modicaciones, a su vez, son propagadas de nuevo al entorno virtual, para que se actualice su apariencia. El avance del simulador, adems, se redirige al mdulo experto del subsistema de tutora, ya que es, en ltima instancia, el que conoce cmo se debe resolver el ejercicio/situacin al que se est enfrentando el estudiante. A la vista de los datos, y con la ayuda del mdulo pedaggico, el sistema experto puede decidir parar al usuario para informarle sobre errores, darle pistas, o permitirle continuar sin realizar ninguna accin especial. Inteligencia articial de alto nivel: algunos de los objetos que aparecen en el entorno virtual son relevantes al contexto educativo utilizado. Si, por ejemplo, estamos en un entorno de simulacin de un incendio para entrenamiento de bomberos, las actuaciones del resto de bomberos y vctimas (que en el entorno aparecen como avatares) son muy importantes, ya que inuyen en el tipo de conceptos que el estudiante aprender; dependiendo de su comportamiento, el entorno puede ayudar a aprender a cmo reaccionar ante situaciones de pnico del resto de compaeros, o a desalojar una vctima que est paralizada por el miedo. La inteligencia articial de estos
objetos relevantes
desde el pun-
to de vista educativo se encuentra en este mdulo, ya que dependen fundamentalmente del ejercicio actual y de lo que dicte el subsistema de tutora. Monitorizacin del estudiante: la parte ms importante de la monitorizacin del estudiante es conocer qu acciones est realizando sobre el entorno virtual, y eso ya se hace gracias a las dos funcionalidades anteriores. No obstante, debemos hacer mencin explcita de esta tarea, pues existe otro tipo de monitorizacin que no tiene por qu estar relacionada con las acciones sobre el entorno virtual. Por ejemplo, puede ser relevante saber si el estudiante lleva mucho tiempo inactivo o si su avatar est mirando al personaje que est dndole una explicacin. En todos esos casos, este mdulo recibe las acciones que el usuario realiza sobre el entorno virtual, e informa al subsistema de tutora para que, al menos, actualice el modelo del estudiante. En la gura 5.3 se muestra un esquema de este mdulo. Como ya hemos dicho, el simulador recibe algunas de las acciones que se realizan en el entorno (aquellas que tienen que ver con las entidades que representan partes de la estructura simulada), lo que hace que el estado interno del simulador cambie; ese cambio puede generar alteraciones en el aspecto visual de algunas entidades, por lo que el simulador enva esa informacin a la capa inmediatamente inferior. Por su parte, la inteligencia de alto nivel de los avatares
133
reciben eventos de percepcin, y en base a ellos deciden qu acciones realizar. Por ltimo la monitorizacin del estudiante recibe las acciones que ste hace, y obra en consecuencia. En la gura, aparecen algunas de las invocaciones que este mdulo puede hacer sobre el subsistema de tutora (aquellas que ya mostrbamos como entradas a l en la gura 5.2), pero hay muchas ms, tanto en sentido ascendente como descendente. Por ejemplo, el mdulo experto puede pedir al simulador que anule la ltima accin ejecutada (debido a un error del estudiante) o dar rdenes concretas a un avatar (como veremos en la seccin 5.10). En la seccin siguiente, adems, veremos cmo estructurar el mdulo encargado de las entidades del juego para poder crear fcilmente la comunicacin con este mdulo. La vista lgica, recibe, al principio de la ejecucin, el ejercicio o episodio educativo al que se va a enfrentar el usuario, y se congura dependiendo de sus caractersticas. Dada su importancia, dedicamos toda la seccin 5.11 a la descripcin de cmo tanto este mdulo como el entorno virtual son congurados en base al ejercicio cargado.

Ya hemos hablado en la seccin 2.6 sobre las entidades de un juego, que forman lo que en la gura 4.2 llambamos momento, este
cdigo especco dinmicos
cdigo especco.
En aquel
era todo lo que no era motor de juego, y
por lo tanto constitua la parte ms dependiente del juego particular. En una aplicacin educativa, las entidades del juego siguen representando los objetos del entorno virtual (ya sean visibles o invisibles), que reaccionan ante distintos eventos provocados por el propio estudiante u otras entidades. Son, en denitiva, las que proporcionan la sensacin de credibilidad, de entorno
real,
al usuario. La diferencia estriba en que ahora
este mdulo no constituye el del entorno.
nal
de la implementacin, ya que por encima
reside, como hemos visto, el subsistema de tutora apoyado por la vista lgica
Igual que en los videojuegos, las entidades son creadas desde el motor de la aplicacin que es quien lee el mapa con la informacin de todo el entorno virtual. Para poder crear entidades (objetos) que estn en otro mdulo distinto y mantener, an as, la independencia entre ambos, se utiliza alguna de las tcnicas explicadas en la seccin 2.6.2, como factoras extensibles o uso de tablas de smbolos de libreras dinmicas. El motor de la aplicacin ja la forma en la que lo har, y el mdulo de las entidades seguir ese convenio. Podemos distinguir dos tipos de entidades, desde el punto de vista de la aplicacin educativa: Aquellas entidades que no son especcas del contexto educativo: En este grupo se incluyen todas las entidades genricas que pueden ser
134
Captulo 5.
reutilizadas entre distintos proyectos. Pertenecen a este grupo los elementos arquitectnicos dinmicos habituales: puertas, plataformas o ascensores. Tambin aparecen aqu interruptores, fuentes de sonido, o personajes secundarios no inuyentes en el desarrollo del aprendizaje. Entidades especcas del contexto educativo: son todas aquellas entidades que inuyen en mayor o menor medida en el proceso de aprendizaje. Podemos dividir este tipo de entidades en los mismos tres grupos en los que dividamos la funcionalidad del mdulo anterior (seccin 5.5). As, tenemos:
Entidades que representan los objetos gestionados por el simulador. Un ejemplo, como veremos en el captulo siguiente, son las que en JV M representan las estructuras de la mquina virtual de Java (JVM). Para mantener la coherencia entre el estado en el simulador y el mostrado en el entorno, se puede hacer uso del patrn observer (Gamma et al., 1995), o buscar alguna otra alternativa de actualizacin.
Entidades que son lo sucientemente relevantes en el contexto pedaggico como para que deban ser accedidas por el subsistema de tutora. En ese caso el responsable de su funcionamiento, o inteligencia de alto nivel, no est en este mdulo sino en la vista lgica del apartado anterior. Estas entidades se encargan nicamente del aspecto visual en el entorno virtual, y de su inteligencia de bajo nivel (bsqueda de caminos o percepcin bsica). La vista lgica recibir eventos de percepcin, y podr preguntar por ciertos aspectos del entorno, y ejecutar primitivas en l para cambiar el aspecto visual. Veremos en la seccin 5.7 una lista posible de las acciones que estas entidades deben hacer pblicas al mdulo superior para poder ser controladas desde fuera.
Entidad que monitoriza al estudiante. Aunque en los juegos no es habitual que exista una entidad que represente al jugador (especialmente en los de
primera persona ),
en nuestra arquitectura
situamos una entidad especca para el estudiante. sta es la encargada de informar a su parte contraria en la vista lgica, de tal forma que se pueda, en ltima instancia, actualizar el modelo del estudiante.
Para la implementacin se puede utilizar el mecanismo de herencia habitual, de tal forma que exista una clase base para todos los objetos del juego, del que van derivando el resto de clases. La herencia permite agrupar funcionalidad comn de varias clases, en la clase padre nica. Un ejemplo de jerarqua de entidades puede verse en la gura 2.4.
135
Nosotros, no obstante, aconsejamos una implementacin basada en componentes (seccin 2.6.3). Esta aproximacin convierte a cada objeto del entorno virtual en una lista de componentes con un interfaz comn, pero con funcionalidad distinta. Cada componente est encargado de una parte especca de la entidad, por ejemplo, de su representacin grca, de la gestin de sus colisiones, o de su nivel de vida. La comunicacin entre los componentes de la entidad se hace a travs de mensajes genricos. Un ejemplo con este escenario podra ser el siguiente: el motor de colisiones enva un evento de tal forma que el componente encargado de las colisiones es informado de una colisin entre el objeto del juego y, digamos, una bala; ste enva entonces un mensaje a todos los componentes del objeto para que se den por enterados; el componente encargado del nivel de vida disminuir sta en la proporcin que considere oportuno. Este modo de actuar facilita mucho la programacin, ya que los objetos pasan a ser un conjunto de componentes congurables, de tal forma que la creacin de objetos nuevos consiste en decidir cules de esos componentes ya disponibles deben pasar a formar parte del objeto y con qu parmetros. Slo en algunos casos se necesitar la programacin de componentes especcos para algunos objetos del juego. Si la arquitectura de entidades basadas en componentes supone un avance para la programacin de videojuegos (ver seccin 2.6.3), en el caso de aplicaciones que siguen nuestra arquitectura suponen una ventaja adicional. Como hemos dicho anteriormente, la diferencia entre las entidades de un videojuego y de una aplicacin educativa basada en ellos es la existencia de objetos que tienen que ver con el simulador, con el proceso de aprendizaje y con el estudiante. Adems, algunas de las entidades pueden pertenecer a varios de los grupos anteriores. Por todo esto, el mecanismo de herencia no es suciente, ya que nicamente permite un eje de variabilidad en cada nivel de la jerarqua de clases. La solucin es el uso de componentes que dividen la funcionalidad en distintas clases de tamao reducido, de tal forma que una entidad est compuesta por una lista variable de componentes. Utilizando este esquema, la programacin de las entidades sera:
Para las entidades que tienen su contrapartida en el simulador, se puede aadir un componente especializado, encargado de comunicarse con l. En la gura 5.4a aparece un esquema de una situacin en tiempo de ejecucin de JV M, el sistema descrito en el captulo 6. El objeto del entorno
pilaOperandos que representa una pila de operandos de la
mquina virtual de Java, est compuesta por tres componentes (en la prctica contiene ms; en la gura nicamente se muestran esos tres). El primero simboliza la representacin grca de la pila de operandos, el segundo la encargada de la fsica/colisiones y el tercero, el especco, encargado de la comunicacin con el simulador (en el mdulo de la
136
Captulo 5.
Entorno::pilaOperandos : GameObject
...
: EntidadGrafica
...
: CompObserverPilaOps Vista lgica (Simulador)
: EntidadFisica
(a) Ejemplo de entidad que representa a otra en el simulador
Entorno::agentePedagogico : GameObject
...
: EntidadGrafica
...
: CompIAAgente Vista lgica (Comportamiento avatar)
: SeguimientoRuta
(b) Ejemplo de entidad que representa el avatar de un agente pedaggico
Entorno::jugador : GameObject
...
: EntidadGrafica
...
: Monitorizacion Vista lgica (Monitorizacin estudiante)
: GestionEntrada
(c) Ejemplo de entidad para representar al estudiante
Figura 5.4: Ejemplos de entidades basadas en componentes
vista lgica). Esta comunicacin es bidireccional. Cuando un avatar interacta sobre el objeto del entorno, el simulador es informado; cuando el simulador cambia de estado, informa al objeto para que cambie su apariencia.
Para las entidades cuyo comportamiento est denido en la vista lgica, puede aadirse, igual que antes, un componente dedicado que se encarga de la comunicacin. Dado que la vista lgica nicamente est interesada en informacin de alto nivel, el propio componente puede encargarse de ltrar todo lo que ocurre en el entorno virtual, y enviar nicamente la informacin relevante. La vista lgica, que implementa el funcionamiento, puede utilizar el mismo componente como elemento de comunicacin, invocando la ejecucin de ciertas primitivas de alto nivel que son traducidas despus por el propio componente a primitivas sobre el entorno virtual por ese componente. En la gura 5.4b aparece un ejemplo parcial del objeto que podra representar al avatar de un agente pedaggico en el sistema (ver seccin 5.10 para ms detalles). Dispone de un componente encargado de su representacin grca y un componente capaz de hacer mover al avatar por una ruta calcula-
5.7. Comunicacin entre vista lgica y entidades
137
da. El ltimo de los componentes que aparece es el que se encarga de recibir las rdenes de comportamiento de la vista lgica y traducirlas a mensajes de acciones primitivas, y de enviar a sta los eventos de alto nivel que considere oportunos. De manera similar a la de las entidades anteriores, la entidad encargada de gestionar las acciones del estudiante tiene componentes para la gestin de la entrada, que movern su avatar de acuerdo a ella (ver gura 5.4c). Si el entorno no es en primera persona, tambin habr al menos un componente ms encargado de la parte grca. Con este escenario, se puede aadir un componente adicional, que se encargue de enviar las seales oportunas a la vista lgica del mundo cuando ocurra un evento digno de ser conocido por el subsistema de tutora.
Por ltimo, si existe alguna entidad en el entorno virtual que juegue varios de los papeles anteriores, la entidad estar formada por los dos componentes correspondientes, por lo que el esfuerzo de programacin se minimiza.

En la seccin anterior veamos que la comunicacin entre el mdulo que representa la vista lgica del sistema y el de entidades puede dividirse en tres partes: la comunicacin entre las entidades y el simulador, entre ciertas entidades y su inteligencia articial de alto nivel, y entre el avatar del estudiante y el mdulo encargado de su monitorizacin. Las tres conexiones se hacan explcitas en la gura 5.4. La comunicacin que se intercambia entre el avatar del estudiante y la vista lgica es escasa, y no requiere de mucho esfuerzo de diseo. El componente encargado de l en el entorno virtual simplemente invoca las primitivas disponibles en la vista lgica. En cuanto a la comunicacin entre las entidades del entorno y los objetos del simulador, se puede hacer uso del patrn observer, de tal forma que cuando el simulador cambia su estado interno, el objeto correspondiente encargado de su representacin es informado. En particular el componente que en la gura 5.4a llambamos
CompObserverPilaOps
puede jugar perfecta-
mente ese papel. Cuando el componente es invocado desde el simulador, ste enva los mensajes internos necesarios al resto de componentes para provocar el cambio de apariencia. En direccin contraria, cuando algn avatar interacta con el entorno, la entidad correspondiente, deber invocar las primitivas de cambio de estado del simulador, para que ste reeje la nueva situacin, e informe al entorno virtual qu cambios de apariencia se deben hacer.
138
Captulo 5.
Por su parte, hemos dicho que las entidades relevantes desde el punto de vista pedaggico, tienen su comportamiento codicado en dos sitios distintos. Por una parte, las acciones de bajo nivel, como la bsqueda de rutas, la reproduccin de frases, o la interaccin con otras entidades se sita en el mdulo de objetos del entorno. Por otra parte, la inteligencia de alto nivel, que decide dnde tiene que moverse el avatar, qu frases debe decir o con qu entidades debe interactuar, se sita en la vista lgica del mundo. En principio, podramos forzar a que el mdulo de alto nivel base sus decisiones nicamente en el estado del resto de entidades que l mismo maneja, o en el estado del simulador. En contextos simples este escenario puede ser suciente. Sin embargo, en un esquema general como el nuestro, delimitar de esta forma la informacin con la que la vista lgica cuenta sera restringir demasiado sus posibilidades de actuacin. Por esta razn, denimos una serie de
perceptores
que son enviados por el
componente correspondiente de la entidad del juego desde el entorno virtual hacia el responsable de la toma de decisiones de la vista lgica. Tambin se establece una lista de
actuadores
con los que la vista lgica podr alterar
el entorno virtual. Por ltimo, la inteligencia articial podr hacer consultas generales sobre el entorno, que tambin debern ser contestadas por el componente en cuestin. El conjunto de primitivas puede variar signicativamente dependiendo de la temtica de juego elegida. Para minimizar esa dependencia, la lista de perceptores y actuadores debe ser lo sucientemente general como para que sea til al menos para una familia de temticas, por ejemplo aquellas que se basan en las mecnicas de una aventura grca, o en un juego en primera persona. No obstante, an en el caso de necesitarse el cambio de temtica de una aplicacin educativa concreta, la arquitectura facilita la migracin. Esto es debido a que la implementacin de la comunicacin entre el entorno virtual y la vista lgica est
aislada
en un componente especco de la entidad.
Como componente que es, recibir todos los mensajes internos que llegan a l, y en particular, todos los relacionados con la
percepcin. Adems, tambin
puede enviar mensajes internos a sus componentes hermanos. Por lo tanto si las acciones y percepciones que la vista lgica espera cambian, nicamente habr que sustituir el componente encargado de la comunicacin por otro actualizado. En la tabla 5.1 aparece una lista de acciones razonable para una aplicacin basada en las mecnicas de una aventura grca. Muchas de estas acciones tienen como objeto de la accin otra entidad distinta. Por ejemplo, la accin
seguirA
tiene como parmetro a qu entidad se debe perseguir.
En vez de utilizar esos parmetros, denimos el concepto de de otra entidad, de tal forma que la accin
seguirA
entidad objetivo
utiliza como destino
esa entidad objetivo. Para cambiar la entidad objetivo, existe una accin
139
Perceptores
estudianteVisto entidadUsada entidadCogida entidadUsadaCon
Evento que indica que el estudiante est en el ngulo de visin de la entidad. Evento que indica que la entidad bajo control ha sido
utilizada cogida
por otra entidad
Evento que indica que la entidad bajo control ha sido por otra entidad
Evento que indica que la entidad bajo control ha sido tidad. Actuadores
utilizada
en combinacin con otra en-
seleccionaObjetivo irA / seguirA mirarA hablarA usar / usarCon coger seleccionarInventario
Establece el objetivo de la entidad, de acuerdo a un nombre. rdenes de movimiento hacia la entidad objetivo. Encara el avatar hacia la entidad destino. Dice una frase mirando hacia la entidad objetivo. Operaciones para manipular una entidad, o una entidad con otra. Coge un objeto del entorno, y lo guarda en el inventario. Selecciona un elemento del inventario; al avatar le aparecer en las manos.
Tabla 5.1: Acciones primitivas entre el entorno virtual y la vista lgica
especca. La base de todas las acciones es la interaccin tpica de las aventuras grcas, donde los avatares (jugador u otros NPCs) pueden interactuar con el resto de entidades utilizando principalmente cuatro operaciones, cuya semntica concreta depender de la entidad particular:
Mirar: Coger: Usar:
cuando el estudiante mira a una entidad, aparece una descripcin
de sta. un avatar puede acercarse a un objeto en el entorno virtual y reco-
gerlo, pasando a formar parte de su
inventario.
utilizar una entidad que hay en el entorno, por ejemplo un interruptor.
La semntica concreta de la operacin depender de la propia entidad. Por ejemplo, utilizar un interruptor no tiene el mismo resultado que utilizar una silla.
140
Captulo 5.
Entidades EntidadGrafica
EntidadSonido
GestionEntrada
Gestin de mapas
Gestin entrada
Motor grfico
Motor de sonido
Interfaz usuario 2D
Mdulos bsicos (Gestor de memoria, de ficheros, biblioteca matemtica, logs) Motor de la aplicacin
Figura 5.5: Vista detallada del motor de la aplicacin
Usar con:
se trata de una operacin combinada, donde se utiliza una enti-
dad del inventario con una entidad del entorno. Por ejemplo, se puede utilizar una bombilla en el inventario con un casquillo en el entorno.
Por otro lado, adems de la lista de perceptores y actuadores, es posible que la parte encargada de la inteligencia articial necesite conocer ciertos aspectos del estado de bajo nivel del entorno, como por ejemplo, la lista de entidades que entran dentro del campo de visin o la lista de entidades que pertenecen a un cierto tipo. Esas funciones tambin las puede implementar el componente, que delega su implementacin en algn otro elemento interno del mdulo.
5.8. Motor de la aplicacin

El motor de la aplicacin es el mdulo de ms bajo nivel de toda la arquitectura. Se encarga de las tareas ms especcas de la plataforma en la que se ejecuta el programa, y sobre las que se apoyan el resto de los mdulos que, gracias a ste, podrn programarse de forma independiente del sistema operativo y mquina subyacente. Aunque en el esquema general de la gura 5.1 el mdulo aparece como un bloque indivisible, en realidad est compuesto por distintos subsistemas, todos ellos sustentados sobre una serie de utilidades bsicas (ver gura 5.5):
Gestor de memoria: utilizado para pedir y liberar bloques de memoria dinmica. Disponer de un gestor propio facilita la deteccin de fugas de memoria por la no liberacin de punteros, y la monitorizacin de la cantidad de bloques que se piden por unidad de tiempo.
141
Gestor de cheros: sirve de fachada al sistema de archivos real. La ventaja es que su comportamiento puede cambiarse de forma transparente al resto de la aplicacin. En la fase de desarrollo, el gestor
monitoriza
el
uso que se hace de los cheros, comprobando el orden de acceso y otros parmetros. Esa informacin se utiliza posteriormente para mejorar el rendimiento de las operaciones de lectura, por ejemplo grabando seguidos en el soporte fsico los cheros que se leen de forma consecutiva. Tambin permite empaquetar todos los archivos en un nico chero comprimido, de tal forma que el propio gestor lo va descomprimiendo de forma transparente al resto de la aplicacin. Librera matemtica: contiene la implementacin de las funciones que normalmente son utilizadas en los subsistemas superiores del motor de la aplicacin. Por ejemplo, dispone de funciones para el tratamiento de vectores, matrices, interpolaciones, etc. La existencia de este mdulo en la parte ms baja de la arquitectura se debe a que su implementacin puede aprovechar las caractersticas del otros). Sistema de logs: se utiliza con nes de depuracin. En vez de escribir en pantalla directamente, el programador utiliza el sistema de logs para escribir informacin de depuracin. El sistema permite indicar parmetros del mensaje, como el origen, el grado de importancia, etc. El sistema de logs puede estar implementado de tal forma que escriba todos estos mensajes en pantalla, o puede ser ms sosticado y presentarlos en una ventana auxiliar que permite ltrarlos por categoras o incluso enviarlo por red a una mquina remota. En realidad, todas las utilidades bsicas descritas sirven como punto de entrada o fachada a alguna utilidad bsica del propio lenguaje o de su biblioteca estndar (memoria dinmica, operaciones aritmticas, entrada/salida a disco y escritura en el terminal). Gracias a la existencia de esta fachada, se puede mejorar la funcionalidad, sustituyendo la implementacin por una hecha a medida, con nes de depuracin u optimizacin. Por lo tanto, para sacar el mximo partido a estos mdulos, el resto de sistemas de la aplicacin deben hacer uso de ellos, en vez de seguir utilizando las funcionalidades estndar. En la prctica, sin embargo, al perseguir la mxima independencia entre los mdulos, estos sistemas base suelen utilizarse, a lo sumo, en el mdulo inmediatamente superior, el responsable de las entidades del entorno virtual. Romper la independencia y
hardware
concreto sobre el
que se ejecuta la aplicacin (instrucciones MMX, SSE o 3DNow! entre
conectar
los niveles ms abstractos de la
arquitectura (vista lgica del mundo y subsistema de tutora) para utilizar estos mdulos bsicos sera difcil de justicar. El resto de subsistemas del motor de la aplicacin se construyen sobre estos cuatro pilares bsicos. Cada uno de ellos proporciona una funcionalidad
142
Captulo 5.
diferente, como la reproduccin de un sonido, o el dibujado de un modelo tridimensional. Casi para cada uno de estos mdulos existe, en el mdulo de entidades visto en la seccin 5.6 un componente especco que se comunica con l. Si un objeto del entorno virtual tiene una representacin grca, poseer (como veamos en la gura 5.4), un componente
EntidadGrafica,
que ser el que se comunique con el motor grco. De manera similar, existe un componente para la gestin del sonido, colisiones, fsica o entrada de usuario. En la gura 5.5 queda reejado este hecho; como se ve, en la parte superior aparecen distintas clases (componentes) del mdulo de gestin de entidades, cada una haciendo referencia a un subsistema especco. Procediendo de esta forma, volvemos a minimizar el impacto que tendra la modicacin de uno de estos subsistemas. Si se cambia un mdulo por otro ms sosticado, nicamente ser necesario sustituir el componente concreto que lo manejaba en el mdulo inmediatamente superior. Gracias a la arquitectura basada en componentes, ese cambio es aprovechado automticamente por todas las entidades que utilicen ese componente. Los mdulos que aparecen en el motor de la aplicacin dependen de la complejidad de esta. Los habituales son:
Motor grco: es el responsable del dibujado tridimensional. Tambin se encarga de la creacin de la ventana, utilizando las llamadas al sistema operativo subyacente. Gestin de entrada: tanto de teclado y ratn como de otros dispositivos menos habituales, como palancas de juego (joysticks y
gamepads )
volantes. Su funcionamiento puede depender del motor grco, ya que en ocasiones los eventos de entrada son recibidos por el creador de la ventana sobre la que se realiza la entrada. Interfaz de usuario: se encarga de la presentacin de elementos en dos dimensiones, como botones, etiquetas o listas de opciones. Es utilizado por la aplicacin en los mens, informacin durante el juego, HUDs, etc. Motor de sonido: encargado de la reproduccin de los distintos tipos de sonido (msica, efectos, voces). En sistemas avanzados, ste puede incluir capacidad de sntesis de voz.
5.8.1.
Dependencia de datos
El motor de la aplicacin es el encargado de leer gran parte de los datos necesarios para la ejecucin de la aplicacin. En particular, casi cualquiera de los subsistemas requieren el uso de formatos de chero especcos para su funcionamiento.
143
As, por ejemplo, el motor grco debe leer cheros con los modelos tridimensionales, animaciones, texturas y efectos visuales; el motor de sonido los cheros de ondas; el gestor de la entrada la conguracin de los dispositivos, y el del interfaz del usuario las posiciones en pantalla de los elementos. Esto hace que cada uno de los subsistemas establezcan un formato de los cheros de entrada. En los casos en los que es posible, se utilizan formatos estndar, como por ejemplo para las texturas o cheros de audio. Sin embargo, para otra gran cantidad de datos, esos formatos son especcos del subsistema escogido. Por ejemplo, los modelos tridimensionales de los personajes estn almacenado en formatos distintos si trabajamos con el motor grco de Nebula 2 o si lo hacemos con Ogre. Eso mismo ocurre con la carga de mapas que trataremos en la seccin 5.8.2. El formato concreto que se utiliza es jado por el motor de la aplicacin. Para minimizar las consecuencias de la sustitucin de alguno de estos mdulos por otro distinto y el problema asociado del cambio de los formatos de los cheros de entrada, la generacin de contenidos debe hacerse lo menos especca posible. Las dependencias fundamentales en cuanto a formatos creadas por estos mdulos son tanto los modelos tridimensionales como los mapas. Para ambos, deben utilizarse herramientas de autora independientes del motor de la aplicacin, y aplicar herramientas de conversin desde esos formatos generales a los cheros especcos interpretados por este, como ya indicamos en la seccin 4.4. En el apartado 6.7.2 ampliamos esa descripcin, utilizando el caso concreto de JV M, la instanciacin ms importante de la arquitectura.
5.8.2.
Gestin de mapas
carga de los mapas,
que
La funcionalidad ms importante del motor de la aplicacin, desde el punto de vista de generacin de contenidos, es la apareca ya en la gura 4.2. Un mapa contiene dos tipos de informacin, (i) la lista de entidades con sus propiedades (pares atributo-valor), y (ii) los modelos estticos del entorno y de algunas de las entidades especiales. A pesar de que la parte ms importante es la lista de entidades, existen dos razones fundamentales por las que situamos su carga en este mdulo en vez de en el responsable de ellas:
Los modelos que contienen (informacin sobre el terreno, paredes de los edicios, escaleras, etc.) son dependientes del motor grco, que aparece dentro del motor de la aplicacin. Las arquitecturas de videojuegos sitan en sus mdulos equivalentes al motor de la aplicacin la funcionalidad de la carga de los mapas. Al mantener esa simetra, nuestra arquitectura permite, como veremos en
144
Captulo 5.
la seccin 5.8.3, utilizar un motor de juego como motor de la aplicacin. De esa forma podemos implementar una aplicacin educativa basada en videojuegos utilizando, por ejemplo, el motor de un juego comercial como Half-Life o Far Cry.
Por otro lado, debido a que nuestra metodologa de creacin de contenidos permite congurar los mapas en base a la informacin recogida en el ejercicio actual, debemos distinguir entre los datos ledos de disco y los datos una vez alterados en base a ese ejercicio. Aunque el mtodo de conguracin de unos con otros lo retrasaremos hasta la seccin 5.11, es importante hacer notar aqu esa distincin. El mdulo responsable de la gestin de mapas debe distinguir entre aquellos que ha
instanciado,
cargado
de disco, y aquellos que ha
es decir, aquellos para los que ha lanzado sus entidades en el
mdulo de gestin de objetos del entorno y han sido congurados en base al ejercicio actual. Esto es especialmente importante en aquellas aplicaciones educativas en las que un mismo mapa de disco puede estar instanciado varias veces pero utilizando conguraciones distintas. Un ejemplo de esto sera la aplicacin para entrenar a bomberos: cada planta de un edicio en llamas puede estar generado desde el mismo chero en disco, pero la conguracin de cada una de ellas vara segn el ejercicio. Independientemente de si la
instanciacin
se hace de un mapa nuevo
o de uno que ya se ha usado anteriormente, el gestor debe recorrer toda la lista de entidades que ste posee. Durante el proceso, ir informando al sistema de gestin de objetos para que cree los elementos necesarios para su manejo. ste es, por lo tanto, otro punto de comunicacin entre el motor de la aplicacin y el sistema situado inmediatamente por encima de l, por lo que es, potencialmente, un punto de conicto ante cambios de cualquiera de los dos mdulos. La solucin de nuestra arquitectura es la siguiente:
Cada vez que el cargador quiere procesar una entidad, llama a una funcin genrica de la capa de objetos del entorno, indicando el nombre de la entidad, y sus atributos.
La capa del entorno, en base al nombre de la entidad acta en consecuencia.
En caso de que la entidad necesite acceder a un modelo contenido en el propio mapa, llamar a una funcin concreta del cargador de mapas, que se encargar de cargar ese modelo en el motor grco y devolver una referencia a l.
5.9. Control de la ejecucin
145
5.8.3.
Implementacin
El motor de la aplicacin es, sin lugar a dudas, el mdulo que ms se presta a la incorporacin de COTS (ver seccin 2.3.1), es decir de mdulos comprados a terceros. Es por esto por lo que hemos dedicado una especial atencin a mantener la independencia entre sus mdulos y el resto del sistema. Por poner algn ejemplo, para el motor grco, se puede utilizar Ogre, Nebula o RenderWare; para el motor de sonido tenemos disponibles fmod, OpenAL o la funcionalidad ofrecida por DirectX, y para la gestin de la entrada, se puede utilizar el API del sistema operativo suybacente, DirectInput o SDL. Nuestra arquitectura, que basa la programacin de entidades en componentes, facilita mucho el intercambio de estos sistemas, ya que minimiza el punto de contacto entre stos y la gestin de entidades que tiene lugar en el mdulo superior. Una ltima posibilidad es sustituir por completo el motor de la aplicacin por un motor de juego ya existente. En muchos de los juegos comerciales de mayor xito (Half-Life, Far Cry, Doom, Unreal Tournament, etc.), los estudios que los desarrollan hacen pblicos los editores de niveles con los que se crearon los mapas para el juego original, as como el cdigo fuente de la parte de gestin de entidades. De esta forma, los acionados pueden introducir algunas modicaciones en l. Si la parte liberada es lo sucientemente amplia, la capacidad de modicacin del juego original es tal que permite cambiarlo por completo, manteniendo nicamente la parte de ms bajo nivel. Gracias a la divisin en mdulos que hemos utilizado en nuestra arquitectura, es posible implementar una aplicacin educativa basada en videojuegos utilizando esa aproximacin.
5.9. Control de la ejecucin

Decamos en la seccin 2.5 que el bucle principal de la aplicacin es el responsable de ordenar la ejecucin de cada una de las tareas necesarias para el avance de la aplicacin. Para completar la descripcin de nuestra arquitectura, resulta pues indispensable indicar dnde situamos esa gestin. Sin menoscabar el uso de hebras distintas para algunos de los mdulos, el bucle principal de la aplicacin est situado en el motor de la aplicacin que describamos en la seccin 5.8. La razn de esta posicin es que el bucle principal es un componente de muy bajo nivel que, adems, es extremadamente dependiente de todos los dems subsistemas. En efecto, estos subsistemas suelen tener unas restricciones fuertes en cuando al orden de invocacin de sus mtodos de actualizacin, por lo que lo ms adecuado es que el componente que dene ese orden se encuentre en el mismo sistema.
146
Captulo 5.
El bucle principal, adems de actualizar todo lo necesario del motor de la aplicacin (la lectura de la entrada, dibujado, reproduccin de sonidos, etc.), invoca la actualizacin de los objetos del entorno, situados en el mdulo inmediatamente superior (ver gura 5.1). Para la ejecucin de las tareas relacionadas con la vista lgica del mundo, procedemos de la misma forma. Los eventos generados por los objetos del entorno provocan llamadas a la vista lgica que recibe el control para hacer avanzar el estado del mundo o decidir la forma de comportamiento de las entidades bajo su control ante esos eventos. A su vez, el subsistema de tutora puede recibir el control por ser invocado desde el simulador (al notar, por ejemplo, que el estudiante lleva inactivo un tiempo superior a un umbral), aunque tambin recomendamos la existencia de una hebra continua que ejecute tareas de mantenimiento del subsistema.

Decamos en la seccin 3.5 que un agente pedaggico supone una mejora en el modo de comunicacin entre el sistema y el estudiante que lo utiliza. Lo habitual, indicbamos, es que estos agentes vengan representados por un avatar dentro del entorno, que acompaa al estudiante, o aparece cuando se le necesita. Nuestra arquitectura tambin permite la incorporacin de estos agentes en las aplicaciones, a pesar de no aparecer expresamente en el esquema general de la seccin 5.3. En la implementacin de estos agentes suelen existir tres mdulos: Mdulo de percepcin: detecta las acciones relevantes que suceden en el entorno virtual. Mdulo cognitivo: es el que, utilizando algn mecanismo de razonamiento, decide qu acciones realizar. Mdulo de movimiento: una vez decididas las acciones a ejecutar, es el que se encarga de hacerlas efectivas. El eje central es el mdulo cognitivo, que decide por ejemplo si es conveniente parar al estudiante para proporcionarle explicaciones, dejarle avanzar, o incluso resolver el ejercicio para que ste aprenda la solucin. Debido a esto, el mdulo est implementado en el subsistema de tutora descrito en la seccin 5.4. Las decisiones que toma este mdulo se basan en tres tipos de informacin diferentes: Avance del ejercicio: es decir, cmo va resolviendo el usuario el problema que tiene entre manos.
147
Al mdulo cognitivo
Mdulo de percepcin
Simulador
Comportamiento del avatar
Monitorizacin estudiante
... Objetos de la metfora Objetos del entorno

Figura 5.6: Esquema de implementacin del mdulo de percepcin de un agente pedaggico
Avatar del agente pedaggico
Entidad estudiante
Estado del avatar que representa al agente pedaggico: por ejemplo, si tiene bajo su campo de visin al usuario, si ste le est mirando, o le pide ayuda. Acciones del estudiante: no slo todas las que hace (ya sea para hacer avanzar el ejercicio o para comunicarse con el agente pedaggico), sino las que
no
hace, como permanecer inactivo durante mucho tiempo,
paseando por el entorno pero sin llegar a hacer nada til. Los tres tipos de datos son conocidos en el mdulo que almacena la vista lgica del mundo, gracias a la comunicacin que sta tiene con el entorno virtual y que describamos en la seccin 5.6. Con este razonamiento, pues, el mdulo de percepcin del agente pedaggico se puede situar directamente en la vista lgica, canalizando la informacin relevante que llega al mdulo hacia el subsistema de tutora. Puede verse un esquema en la gura 5.6. Por ltimo, el mdulo cognitivo dispone de un conjunto de acciones primitivas que emite desde el subsistema de tutora para que el avatar en el entorno acte. Esas acciones primitivas no tienen por qu coincidir con las que veamos que se utilizan para comunicar a la vista lgica con las entidades (ver tabla 5.1), sino que pueden ser independientes del entorno virtual utilizado y venir especicadas utilizando un vocabulario del dominio educativo particular. Por ejemplo, las acciones pueden indicar qu tipo de operaciones hay que ejecutar
sobre el simulador
de la vista lgica. El mdulo encarga-
do de la inteligencia de alto nivel del avatar, deber traducir esa orden a acciones primitivas sobre el entorno virtual, que operen con los elementos visuales equivalentes y que, al ser ejecutadas sobre l, terminen modicando
148
Captulo 5.
el simulador tal y como haya solicitado el mdulo cognitivo.

Nuestra metodologa de creacin de contenidos detallada en la seccin 4.4 se basa en la
separacin
entre los dos tipos de datos fundamentales en una
aplicacin educativa basada en videojuegos: aquellos relacionados con el conocimiento del dominio que se pretende ensear, y aquellos relacionados con la parte ldica, como son la estructura del entorno virtual, colocacin de entidades o modelos tridimensionales. Gracias a esta separacin, el experto del dominio puede dedicarse a generar los cheros que contienen los ejercicios o episodios educativos a los que el estudiante se enfrentar, mientras que el diseador de niveles se dedicar a construir el entorno virtual por el que se mover el usuario, y colocar las entidades clave dentro de l. Por ejemplo, en el juego educativo para entrenar bomberos, el experto del dominio puede decidir que en un ejercicio debe aparecer un edicio con un nmero de plantas determinado, con el fuego situado en una planta concreta y con unas caractersticas dadas. Por su lado, el diseador de los niveles, utilizando un editor de entornos virtuales, dene la arquitectura de toda la calle, coloca los elementos urbanos, y decide en qu lugar ir el edicio que tendr fuego. Cuando el ejercicio se carga, se congurarn las propiedades del edicio, y se colocar el fuego donde proceda. Para que esta separacin sea posible, la arquitectura subyacente debe ser capaz de soportar esta conguracin en funcin del episodio educativo que hay entre manos. El proceso desde que un usuario entra en el sistema hasta que la aplicacin est completamente lanzada es el siguiente: El subsistema de tutora, concretamente el mdulo pedaggico, decide las caractersticas deseadas del siguiente ejercicio. El gestor de ejercicios selecciona aqul que ms se aproxime al solicitado. Si, como puede ocurrir, el gestor es capaz de aplicar tcnicas de
adaptacin, es posible que el ejercicio seleccionado se cree en ese momento a partir de otros ejercicios disponibles en la base de ejercicios.
El cambio en el ejercicio actual provoca un cambio en el estado de la lgica del mundo, especialmente en el
simulador.
El motor de la aplicacin carga el mapa que contiene la descripcin del entorno virtual. Si el mapa es muy congurable, podremos tener un mapa nico, independiente del ejercicio, y por lo tanto el motor de la aplicacin siempre cargar el mismo. Eso ocurre, por ejemplo, en
149
JV M, descrito en el captulo 6. Si el mapa no es lo sucientemente congurable (siguiendo con el ejemplo de los bomberos, podramos tener ejercicios con incendios en uno o dos edicios, y el diseador del nivel ha optado por crear dos mapas independientes), deber existir una relacin entre los ejercicios y los mapas utilizados en el entorno. El motor de la aplicacin, al
instanciar
el mapa cargado desde disco,
va llamando a las funciones de creacin de objetos del entorno en el mdulo inmediatamente superior, segn lo hemos descrito en la seccin 5.8.2. Esas funciones llamadas por cada entidad crean los objetos del juego. Con la arquitectura de componentes, la creacin de estos objetos provocar la construccin de todos los componentes que lo forman. De entre todas las posibles entidades nos interesan las siguientes:
Aquellas que inuyen en el episodio educativo: son las que representan una parte del simulador que aparece en la vista lgica. Como vimos en la gura 5.4a, estas entidades tendrn un componente especco que se encarga de la comunicacin con su representante en el simulador. En el momento de la construccin de ese componente, l mismo se encargar de, en base al estado del simulador en ese momento, establecer su apariencia inicial (recordemos que el estado del simulador ha sido congurado a partir del ejercicio en un paso previo).
Aquellas cuyo comportamiento de alto nivel est controlado por la vista lgica: en ese caso, el componente especco (ver gura 5.4b), emitir la orden a la vista lgica para que cree el controlador concreto, y se da a conocer, de tal forma que en lo sucesivo puedan comunicarse para informar sobre la percepcin o sobre las acciones a ejecutar en el entorno virtual.
Aquella que dene el punto inicial del estudiante en el mapa: en ese caso, la entidad que se crea es la que representa al estudiante (gura 5.4c). El componente especco de esta entidad se encarga, igual que en el caso anterior, de informar a la vista lgica de su existencia para comenzar as la comunicacin.
Al nal del proceso, por lo tanto, todas las entidades del entorno virtual estarn creadas y conguradas en base a los datos contenidos en el mapa, y en base al estado del simulador. Conviene, antes de terminar, matizar cmo debe el motor de la aplicacin averiguar qu mapa debe cargar e
instanciar
dependiendo del ejercicio
actual. Hemos dicho que, idealmente, el entorno virtual es lo sucientemente
150
Captulo 5.
congurable como para que todos los ejercicios puedan ejecutarse a partir del mismo mapa inicial. En JV M por ejemplo, esto se cumple. En caso de no ser posible crear un mapa lo sucientemente congurable, debe implementarse algn mecanismo de
emparejamiento
que, dado un
ejercicio, indique qu mapa hay que cargar. Para intentar resolver el problema de la manera menos intrusiva posible, ese emparejamiento
no
debera
hacerse en el propio ejercicio. Es decir, el problema de la conguracin no debe recaer sobre el autor del ejercicio. Lo que marca qu mapa hay que cargar son las propias
propiedades
del ejercicio (por ejemplo, el nmero de
edicios incendiados), por lo que la relacin tiene que realizarse en base a esas caractersticas. La solucin es implementar esa decisin en un mdulo aparte que conoce las causas de la necesidad de varios mapas, y decide de acuerdo a ellas, a partir de las propiedades del ejercicio seleccionado.
5.12. Evaluacin
La arquitectura que hemos presentado en este captulo no es el resultado de un mero diseo en papel, sino que se ha llevado a la prctica en distintas instanciaciones, que prueban su versatilidad. Los ejes de variabilidad que hemos probado han sido los siguientes (ver tabla 5.2): Cambio del motor de la aplicacin:
En un prototipo inicial, el motor grco utilizado fue WildMagic , sobre OpenGL y utilizando GLUT como librera para gestionar la entrada. Los mapas no eran ledos desde disco, sino que estaban programados directamente en el cdigo; los modelos animados se cargaban de cheros con el formato usado en el juego Quake 3.
En otra instanciacin de la arquitectura, utilizamos Nebula 1, un motor de juegos que se encarga de la gestin de entrada, el dibujado tanto tridimensional como bidimensional, y otra serie de caractersticas. La carga de los mapas se haca desde cheros tambin utilizaban el formato de este juego.
bsp,
formato utilizado en el juego Half-Life 1, y los modelos animados
Por ltimo, cambiamos a Nebula 2, una versin renovada del motor anterior. Los cambios de funcionamiento que tiene con respecto a la versin previa son lo sucientemente signicativos como para que la conversin exitosa pueda entenderse como un logro de la arquitectura. Los mapas se cargan o bien desde un
bsp
o des-
de un XML (ver apartado 6.7.2 para ms detalles), y los modelos animados utilizan el formato propietario del propio motor grco.
http://www.geometrictools.com/
Resumen
151
Motor de la aplicacin Mecnicas Contexto educativo Mapas Modelos animados
Prototipo WildMagic + GLUT Aventura grca Ninguno Cableado (Quake 3)

md3
JV2 M 1 Nebula 1 / Nebula 2 Aventura grca JVM (Half-Life 1) (Half-Life 1)

mdl bsp
JV2 M 2 Nebula 2 Accin JVM

bsp / XML
VirPlay Nebula 1 Aventura grca Patrones de diseo (Half-Life 1) (Half-Life 1)

mdl bsp
(Nebula 2)
n2
Tabla 5.2: Distintas instanciaciones de la arquitectura
Cambio de la temtica del juego: como veremos en el captulo siguiente, el proyecto JV M tiene dos versiones, cuyo fondo es el mismo (la enseanza de la mquina virtual de Java, y el proceso de compilacin), pero cuyas mecnicas en cuanto a juego son distintas:
La primera versin est claramente inspirada en las aventuras grcas, y por lo tanto, las acciones que tanto el estudiante como el agente pedaggico que habita el entorno hacen son las de mirar, coger, usar y usar con, descritas en la seccin 5.6.
La segunda versin es similar a un juego de accin, donde el estudiante lleva un arma, y tiene que eliminar enemigos para hacerse con los objetos necesarios para terminar el ejercicio.
Cambio de dominio: como ya hemos dicho, la arquitectura la hemos utilizado en JV M, una aplicacin educativa para ensear la mquina virtual de Java. Adems, tambin ha sido utilizada en el desarrollo del primer prototipo de VirPlay (Jimnez Daz, Gmez Albarrn, Gmez Martn y Gonzlez Calero, 2005b), una aplicacin educativa que, utilizando
role play,
ensea la interaccin entre los distintos objetos que
intervienen en distintos patrones de diseo.
Resumen
En este captulo hemos presentado la arquitectura para el desarrollo de aplicaciones educativas basadas en videojuegos. Tras una introduccin, la seccin 5.2 detalla los objetivos que guiaron el diseo de la arquitectura. Posteriormente, la seccin 5.3 hace una descripcin general, enumerando los mdulos que la forman. A continuacin, las distintas secciones van de-
152
Captulo 5.
tallando cada uno de esos mdulos. Posteriormente se dedica un apartado al control de la ejecucin y la incorporacin de agentes pedaggicos en las aplicaciones. Una vez descrita por completo la arquitectura, el captulo recupera el aspecto ms importante de la metodologa descrita en el captulo anterior. En particular, se indica el modo de unir los dos tipos de informacin fundamentales, a saber, ejercicios y entornos virtuales. Por ltimo, la seccin 5.12 presenta una evaluacin, mostrando brevemente las distintas instanciaciones de la arquitectura que hemos implementado en forma de distintas aplicaciones educativas. En particular, se ha indicado qu mdulos han sido reemplazados de una implementacin a otra. El captulo siguiente har una descripcin extensa del uso de la arquitectura en JV M. En particular, describiremos con detalle la implementacin concreta de cada uno de los mdulos.
Notas bibliogrcas
Las decisiones arquitectnicas que hemos tomado en este captulo se han fundamentado en lo visto en los captulos 2 y 3, as como en los objetivos marcados en la seccin 5.2. Una versin preliminar de la arquitectura fue presentada en Gmez Martn et al. (2003). Para una descripcin extendida, se puede consultar Gmez Martn, Gmez Martn y Gonzlez Calero (2007a) y Gmez Martn, Gmez Martn y Gonzlez Calero (2007b). Por su parte, Jimnez Daz, Gmez Albarrn, Gmez Martn y Gonzlez Calero (2005c) describe en detalle la aplicacin VirPlay y da una explicacin de cmo se ha utilizado la arquitectura propuesta en este captulo en su implementacin.
Captulo 6
Sistema educativo para la enseanza de la mquina virtual de Java

Opt por la memorizacin mecnica, aunque saba que, en el mejor de los casos, slo le brindara una educacin hueca.
Carl Sagan. Contact
En este captulo se describen las dos versiones JV2 M, el sistema educativo que permite aprender la mquina virtual de Java y cmo el cdigo Java es compilado para ella. Este sistema ha sido creado utilizando la metodologa y arquitectura descritas en los dos captulos anteriores.
6.1. Introduccin
El captulo anterior est dedicado a la arquitectura general propuesta para la creacin de un sistema educativo basado en videojuegos. El mximo exponente de esta arquitectura es JV M, un sistema para la enseanza de la mquina virtual y la compilacin de Java. En este captulo nos centramos en este sistema, detallando la forma en que han sido instanciados los mdulos ms importantes descritos de manera general en el captulo anterior. Tambin prestaremos atencin a la parte metodolgica descrita en el captulo 4, en particular cmo realizamos la creacin de contenidos. Como quedaba reejada en la seccin de evaluacin del captulo anterior (seccin 5.12), JV M ha ido pasando por distintas versiones, que han ido 153
154
Captulo 6.
Sistema educativo para la enseanza de la JVM
provocando la sustitucin de los distintos mdulos afectados. En la siguiente seccin se describen las metforas utilizadas para la representacin de la JVM en las dos versiones principales. Para su total comprensin, es necesario al menos un conocimiento supercial de la estructura de la JVM, por lo que el apndice A realiza una introduccin a sus componentes principales. Una vez descritos ambos sistemas, el captulo detalla cada uno de los mdulos que propona la arquitectura para la construccin de sistemas educativos basados en videojuegos (captulo 5). En particular, visita cada uno de los mdulos, indicando de qu forma se han implementado en JV M. El captulo termina indicando de qu forma se han creado los contenidos que utiliza JV M. Como se podr comprobar el mtodo utilizado es el propuesto en la metodologa de creacin de contenidos del captulo 4.
6.2. Descripcin general

Nuestro objetivo es implementar un sistema educativo basado en videojuegos para ensear la estructura de la mquina virtual de Java (JVM) y la forma en la que el cdigo fuente desarrollado en Java es compilado para generar las instrucciones que ella entiende. Para ello, suponemos que los usuarios del sistema conocen la programacin imperativa en general y Java en particular. Con el sistema sern capaces de aumentar su conocimiento en programacin orientada a objetos y el proceso de compilacin para una mquina de tipo pila como la JVM. El sistema, no obstante, no cubre todos los conceptos de la mquina virtual y del lenguaje Java. En la seccin 6.2.3 detallaremos exactamente cules de los aspectos no son cubiertos. El sistema presenta un entorno virtual que simula la JVM, por lo que ha sido bautizado como JV M, para indicar la idea de una mquina virtual
virtualizada.
En ese entorno virtual, el estudiante es representado mediante un avatar con el cual interacta con el resto de objetos. El tipo de objetos, utilidad y signicado concreto es dependiente del diseo del juego utilizado. Como explicbamos en la seccin 4.2.1, antes de abordar la implementacin de un videojuego educativo se debe pasar por una fase de
reexin
en la que
se decide, adems del mbito que se desea ensear, las caractersticas del juego que van a servir como mtodo de aprendizaje. En concreto, se debe determinar el tipo de juego, mecnicas que tendr, acciones del usuario, etc. JV M ha pasado por dos versiones principales, JV M 1 y JV M 2, con diseos muy distintos. La primera versin se basa en las mecnicas de una aventura grca al estilo de la saga de Monkey Island o Grim Fandango (LucasArts, 1998), mientras que la segunda es un juego de accin. En ambos casos, no obstante, los episodios de aprendizaje consisten en enfrentar al alumno con un programa realizado en Java que debe
ejecutar
en
155
(a) Pantalla de seleccin de usuario en 2 JV M 2
2 (b) Pantalla de men de JV M 2 donde
se muestra el usuario activo
Figura 6.1: Capturas de JV M 2 relacionadas con la seleccin de usuario
la mquina virtual simulada. Para ello, tendr que
instrucciones de la mquina virtual (bytecodes ), y hacer que se ejecuten cada una de ellas en el entorno de acuerdo con la metfora. Las dos versiones de JV M ejecutan el ciclo de aprender-haciendo (Gmez Martn, Gmez Martn y Gonzlez Calero, 2005a). Para eso, en primer lugar, el usuario se identica en el sistema (gura 6.1). Una vez seleccionado el perl, el sistema elige el ejercicio ms conveniente para su nivel de maestra, y se le enfrenta a l en el entorno virtual. Desde el punto de vista
compilar
el cdigo Java a
externo,
las diferencias fundamentales entre am-
bas versiones de JV M radican en el diseo o mecnicas del juego (Gmez Martn, Gmez Martn, Gonzlez Calero y Palmier Campos, 2007d). La primera versin (JV M 1) est basada en las aventuras grcas, especialmente aquellas que disponen de escenarios en tres dimensiones realizadas por LucasArts, como Escape from Monkey Island o Grim Fandango. Por su parte, la segunda versin (JV M 2) utiliza mecnicas de juegos de accin; el estudiante/jugador est equipado con un arma, y debe eliminar a otros personajes que hay en el entorno para conseguir recursos que le permitan ejecutar el cdigo Java. En las dos secciones siguientes describimos cada una de las dos versiones. Posteriormente, detallamos qu caractersticas concretas de la JVM no son cubiertas por ninguna de nuestras aplicaciones educativas.
6.2.1.
Descripcin de JV2 M 1
En ambas versiones prcticamente todos los componentes de la JVM estn representados por objetos en el entorno virtual, aunque dado que la ambientacin y modo de interaccin es distinta, la forma de representacin diere.
156
Captulo 6.
(a) Jugador enfrente del edicio que representa el
frame
(b) Cdigo mquina y Java en el interior del
activo
frame
(c) Frame hundindose en la pila, para dejar hueco para la llegada del siguiente
(d) Nuevo frames
frame
apilndose en la pila de
Figura 6.2: Distintas capturas de JV M 1 relacionadas con la pila de frames
En la primera versin, el usuario se pasea por un entorno exterior donde aparecen algunos edicios a los que tambin puede entrar. La forma de representar las distintas estructuras de la JVM (listadas en la seccin A.2) es la siguiente:
Heap: el conjunto de objetos creados en la mquina virtual es representado mediante un
barrio
de edicios, cada uno de ellos simbolizando
uno de los objetos creados. El estudiante/jugador puede entrar en cada edicio para poder acceder a los valores de los atributos del objeto al que representa.
rea de mtodos: en vez de tener un espacio fsico donde se encuentra

el cdigo de todos los mtodos, el entorno virtual dispone de otro
barrio,
esta vez de clases, donde cada edicio representa una clase cargada en la mquina virtual. Cada uno de los edicios representa a una de ellas, de tal forma que cuando el estudiante entra en el edicio de una clase, puede acceder al cdigo de sus mtodos de esa clase y al valor de sus
157
atributos estticos.
Pila de frames: en el entorno aparece nicamente un edicio que representa el
frame
activo en ese momento (gura 6.2a). Dentro de l,
se puede consultar el cdigo del mtodo (gura 6.2b), ver sus variables locales y manipular la pila de operandos. Para las invocaciones a mtodos nuevos (o terminar la ejecucin del mtodo activo), el estudiante debe salir fuera del edicio. Al crear un
frame
nuevo, el edicio desapa-
rece bajo tierra (gura 6.2c), y cae uno nuevo, simulando la accin de
apilar
un nuevo registro de activacin en la pila (gura 6.2d). Cuando
un mtodo termina, se realiza el proceso inverso.
rea de constantes: en nuestra metfora, no existe un rea de constantes explcitamente, sino que las referencias son tra el cdigo, se ven los operandos inventario.
resueltas
en el mo-
mento de inicializacin del ejercicio, de tal forma que, cuando se mues-
reales
(y no las referencias), y en
caso de que el usuario las necesite, aparecen automticamente en su
Contador de programa: igual que en el caso del rea de constantes,

no
existe una representacin metafrica como tal del contador de programa. El jugador/estudiante es el nico que conoce en realidad cul es la instruccin que se est ejecutando. En los primeros ejercicios, donde aparece tanto el cdigo Java como el cdigo compilado, la instruccin mquina que hay que ejecutar aparece remarcada (como puede verse en la gura 6.2b), pero no consideramos eso como contador del programa, ya que el usuario no puede interactuar con l.
Dependiendo del tipo de instruccin mquina de la JVM, los pasos que tiene que realizar el estudiante en el entorno dieren:
Instrucciones de carga, almacenamiento y manipulacin de la pila: son las instrucciones que copian datos desde el rea de variables
locales de un indica el
frame
a su pila de operandos y viceversa. Independiente-
mente de la direccin, todas las instrucciones tienen un parmetro que
nmero
de variable local implicada. El estudiante interacta
moviendo las cajas que representan los valores.
Instrucciones aritmticas y de conversin de tipos:
los clcu-
los nales de estas operaciones son ejecutados por un personaje en el entorno que juega el papel de unidad aritmtico-lgica (ALU ); el personaje aparece parcialmente en la gura 6.2b, entre el cdigo Java y los
bytecodes. El estudiante interacta con l para solicitarle que realice
las distintas operaciones.
158
Captulo 6.
(a) Estudiante y rrio de clases
Javy dirigindose al ba-
(b) Estudiante enfrente de Framauro
(c) Estudiante interactuando con la pila de operandos
(d) Estudiante hablando con
Javy
Figura 6.3: Capturas de JV M 1
Creacin y acceso a objetos: para la creacin de objetos (edicios en

el barrio que representa al
heap ), se solicita la creacin a otro avatar del
entorno. Una vez creado, la manipulacin de sus atributos se realiza en el interior de ese edicio. Si los atributos son estticos, se debe operar dentro del edicio que representa a la propia clase.
Instrucciones de salto: dado que es el propio estudiante el que est

ejecutando el cdigo objeto, es l mismo el que hace las veces de contador de programa. Por lo tanto, las operaciones de salto no se ejecutan
explcitamente,
sino que simplemente la porcin de cdigo afectada se
repite o se deja de ejecutar.
Invocacin de mtodos: es el propio estudiante el que debe ejecutar

el mecanismo de
resolucin
de los mtodos, buscando el mtodo en la
clase a la que pertenece el objeto que recibe el mensaje, y efectuando la bsqueda entre las clases padre hasta que se encuentra. Una vez encontrado el mtodo real a ejecutar, y con una referencia a l, se confa en un avatar del entorno llamado Framauro (gura 6.3b) que
159
est situado a la entrada del
frame.
frame
activo, para que construya el nuevo
Para la ejecucin de todas las instrucciones, el estudiante cuenta con la ayuda de
Javy
(ver gura 6.3d), un agente pedaggico con el que el
usuario puede entablar una conversacin, y a quin, en ltima instancia, puede solicitar que termine de resolver el ejercicio. La forma en la que el usuario interacta en JV M 1 con el entorno (esto incluye al propio
Javy),
se basa, como ya se ha comentado, en las aventuras
grcas. De esta forma, el usuario puede realizar una serie de operaciones sobre los objetos del entorno (ver el apartado 6.5 para ms detalles). La parte ms destacada de la manipulacin es que la ejecucin de una nica instruccin de la JVM puede requerir interactuar con varios objetos del entorno, cada uno representando una estructura de la JVM diferente. Cada uno de los pasos u operaciones que hay que realizar sobre el entorno los hemos llamado este puede
microinstrucciones. Cuando el estudiante pide ayuda a Javy, indicarle qu microinstruccin debe ejecutar a continuacin, o
ejecutarla por l mismo.
6.2.2.
Descripcin de JV2 M 2
2
El prototipo de JV M 1 si bien vino a demostrar que la arquitectura y metodologa descrita en los captulos 4 y 5 es factible, tambin reej que la ejecucin de una nica instruccin mquina poda llevar demasiado tiempo, ya que exiga al estudiante interactuar con varios objetos distintos. Para aliviar este problema, optamos por cambiar por completo el diseo del juego, y abordar la implementacin de otra aplicacin educativa distinta con la misma arquitectura y objetivos pedaggicos. El nuevo diseo se basa en juegos de accin. El entorno en el que el estudiante se mueve es una nave espacial que representa, de forma metafrica, el estado de la mquina virtual, y donde tambin existen otros personajes a los que el estudiante tiene que eliminar. Desde el punto de vista pedaggico, el mecanismo bsico es el mismo que en la versin anterior. El usuario es enfrentado a un cdigo Java que debe compilar y ejecutar. La diferencia fundamental a este respecto es que en JV M 1 el estudiante debe ejecutar cada una de las instrucciones ejecutando
microinstrucciones
sobre el entorno, mientras que en esta nueva versin la
ejecucin consiste simplemente en teclear en un terminal las instrucciones mquina (ver gura 6.4a). Lo que s se mantiene igual es que los valores que se almacenan en la JVM (tanto en la pila de operandos, variables locales como atributos) estn representados por cajas. Mediante una visin de rayos X, el estudiante puede comprobar el valor de cada una de esas cajas (gura 6.4b).
160
Captulo 6.
(a) Estudiante utilizando el terminal para ejecutar instrucciones
(b) Estudiante comprobando el contenido de una caja de la pila de operandos
Figura 6.4: Capturas de JV M 2
La forma de representar en esta nueva metfora las estructuras de la JVM listadas en la seccin A.2.2 es:
Heap: representado por una sala de la nave espacial, todos los atributos
de un objeto particular se encuentran agrupados en un conjunto de cajas. El estudiante puede almacenar una copia de algunos de esos datos en el inventario, o modicar su contenido.
rea de mtodos: igual que en JV2 M 1, el rea de mtodos se encuentra distribuida por clases. Existe una habitacin por cada clase cargada en la JVM, colocadas de tal forma que es fcil identicar la jerarqua entre ellas. Dentro de la clase un terminal da acceso al cdigo Java de todos los mtodos que implementa esa clase.
Pila de frames:
un
en este caso, cada uno de los
piso
nivel
frames
consiste en
distinto del entorno. Para crear un nuevo registro de
activacin, hay que utilizar el ascensor que da acceso a l. Para bajar a un mtodo cuya ejecucin se ha interrumpido, simplemente se baja de piso.
Contador de programa:
igual que en JV M 1, no existe un repre-
sentante virtual del contador de programa, ya que es el propio usuario el que sabe por qu instruccin va.
rea de constantes: las constantes que en JV2 M 1 aparecan automticamente en el inventario del jugador, ahora estn representadas por objetos del entorno que hay que recolectar para poder utilizarlos en las instrucciones tecleadas en el terminal. Con esta metfora, la mayora de las instrucciones mquina se ejecutan directamente teclendolas desde el terminal (gura 6.4a), una vez que se dispone de los recursos (argumentos) necesarios.
161
Figura 6.5: Ayuda en JV M 2
Javy,
el agente pedaggico de la versin anterior ha sido sustituido por
una ayuda semntica que permite al usuario desde el terminal lanzar preguntas al sistema (gura 6.5). El funcionamiento de esa ayuda semntica queda fuera del alcance de este trabajo, y es descrito por Gmez Martn (2007). La principal diferencia entre las metforas de JV M 1 y JV M 2 es la forma en la que se ejecutan las instrucciones. Mientras que en el primero se trata de la manipulacin de objetos, en la segunda prcticamente todas las instrucciones son ejecutadas mediante el terminal. Si el usuario intenta ejecutar una instruccin para la que an no ha conseguido los recursos (parmetros) necesarios, el terminal avisa del error. Como resumen de las diferencias entre las metforas de las dos versiones de JV M, la tabla 6.1 presenta una comparacin entre la forma de representar en ellas las distintas estructuras de la JVM.
6.2.3.
Aspectos de la JVM no cubiertos

bytecodes directamente interpretables
Las dos aplicaciones educativas sirven para ensear el funcionamiento interno de la JVM, as como la forma en la que el cdigo Java se compila a cdigo objeto o lo que es lo mismo, a los por la mquina virtual. Sin embargo, ninguna de las dos versiones cubre todos los aspectos de la mquina virtual indicados en el apndice A. Las simplicaciones ms importantes llevadas a cabo son las siguientes: La JVM permite varias hebras en ejecucin simultneamente, duplican-
162
Captulo 6.
JVM Clases (cdigo de mtodos) Heap Frame Pila de operandos Variables locales Tabla de constantes Instrucciones mquina Manipulacin de la pila Aritmticas y conversin de tipos Creacin de objetos Salto (invokevirtual )
Metfora JV2 M 1 Barrio de clases Barrio de objetos Edicio Cajas en una mesa Armario Inventario Manipulacin de cajas Avatar (ALU) Avatar Framauro
JV2 M 2 Habitaciones Habitaciones Nivel de la nave Cajas Cajas Avatares a capturar Terminal Terminal Terminal Ascensor
2 2
Tabla 6.1: Resumen de las metforas de JV M 1 y JV M 2
do la estructura de la pila de registros de activacin. Nuestra aplicacin educativa slo permite una hebra. En ambas metforas disponemos de una zona donde aparecen todas las clases cargadas. En realidad, se ocultan o simplican muchos detalles que la JVM permite. En particular, el estudiante no es responsable de asegurar que las clases que se utilizan estn ya cargadas. Tampoco se permite distintos cargadores de clases, algo que s es factible en la JVM para conseguir distintos
universos de clases
independientes entre
s para aumentar la seguridad. La JVM dispone de excepciones a dos niveles: excepciones que lanza el programador, y excepciones de la propia mquina virtual, lanzadas o bien por errores graves del programa (clase no encontrada, divisin por cero, acceso invlido a un array) o bien de la propia mquina virtual (falta memoria). Ninguno de estos tipos es tratado por nuestra aplicacin. La mquina virtual de Java es capaz de ejecutar las instrucciones listadas en el apndice A. Sin embargo, esas instrucciones
no
son sucientes
para implementar cualquier programa (sin ir ms lejos, no hay instrucciones relacionadas con la entrada/salida). El resto de funcionalidad se consigue a base de la implementacin de mtodos en cdigo nativo. Son mtodos de clases que, en vez de estar implementados en Java, estn implementados en otro lenguaje distinto (normalmente C/C++) y que utilizan los recursos del sistema operativo subyacente para realizar su funcin. Nuestra aplicacin educativa
no
permite salirse del cdigo
163
Java, por lo que los mtodos nativos y todo lo que ello implica (pila de ejecucin para estos mtodos, implementacin del interfaz con el cdigo nativo o JNI) no son tratados. Dada la restriccin anterior, la mquina virtual en la que el estudiante ejecuta las instrucciones, tampoco dispone del conjunto de clases de la librera de Java, pues una gran parte de ellas (las de ms bajo nivel) terminan haciendo uso de los mtodos nativos. Por ltimo, y relacionado con el hecho de no disponer de la librera de Java, surge el caso especial de la clase
java.lang.Object. sta es una
clase de especial importancia tanto en la librera como en el propio lenguaje Java y la JVM, ya que todas las clases heredan automticamente de ella. Dado que nuestra implementacin olvida la librera de Java completa, tampoco tiene esta clase. Eso es debido a que la clase
Object
tiene una serie de mtodos que abren la puerta a otras
nuevas clases que obligaran a incluir muchas clases donde se mezcla la implementacin de la mquina virtual, los mtodos nativos y la librera de Java . Sin embargo, desde el punto de vista pedaggico, no nos podemos permitir el lujo de eliminar la clase por completo, ya que es una parte demasiado importante del lenguaje Java. Para disponer de la clase
Object
pero no necesitar la implementacin de todos sus
mtodos, exigimos a todos los ejercicios que dispongan de una clase
articial
papel de
de la que heredan el resto de clases, y que viene a jugar el
java.lang.Object.

Ya dijimos en la seccin 5.8 del captulo anterior que ste es el mdulo de ms bajo nivel de toda la aplicacin, sobre la que se apoyan el resto de sistemas. Tiene subsistemas bsicos, como el gestor de memoria, de cheros, funciones matemticas y gestin de mensajes de depuracin/log. El resto de la aplicacin puede utilizar estos sistemas para facilitar la implementacin. Como dijimos en la seccin 5.8, es aconsejable que al menos el resto de los subsistemas del propio motor de la aplicacin y el gestor de entidades los usen. La arquitectura es capaz de soportar un cambio completo del motor de la aplicacin, de tal forma que se puedan utilizar motores de juego cuyo interfaz est documentado, como por ejemplo el de Half-Life o Far Cry.
Por ejemplo el mtodo
getClass
devuelve un
java.lang.Class,
punto de entrada al
sistema de informacin de tipos en tiempo de ejecucin.
164
Captulo 6.
Figura 6.6: Captura de JV M 1 preliminar, utilizando WildMagic
Para la implementacin de JV M, no obstante, hemos utilizado un motor de aplicacin propio, formado por distintos mdulos, cada uno de ellos realizados desde cero, o basndonos en otras libreras o motores. A continuacin aparece la descripcin de la implementacin de los ms importantes.
6.3.1.
Motor grco
Se encarga de la parte de dibujado del entorno virtual, as como de la creacin de la ventana donde se muestra todo el interfaz de usuario. En nuestro caso, la evolucin de JV M nos ha llevado a utilizar hasta tres motores grcos distintos, que describimos a continuacin:
WildMagic:
fue el primer motor grco que utilizamos. Est desa-
rrollado en C++ y se distribuye bajo licencia LGPL . Su documentacin viene en forma de libros publicados por el programador principal (Eberly, 2000, 2004), por lo que en general es fcil su uso, gracias a la extensa documentacin. La gura 6.6 muestra una captura temprana de JV M 1 utilizando ste motor.
Nebula 1: este motor es producto de la poltica de una empresa alemana
3 que decidi liberar el cdigo del motor que utilizaban en sus
juegos comerciales, con el n de que ste mejorara gracias a las contribuciones externas. La principal ventaja con respecto al motor anterior y que motiv la migracin es el nmero de capacidades ofrecidas no disponibles en WildMagic. Nebula no es un simple motor grco, sino que incluye tambin otros subsistemas nombrados en la arquitectura,
2 3
http://www.geometrictools.com/ La empresa es RadonLabs, http://www.radonlabs.de/.
165
Figura 6.7: Modelo de Half-Life cargado con Nebula 1
como un gestor de cheros, memoria y log o control de la entrada. Adems, dispone de soporte nativo para lenguajes de scripts como TCL, lo que permite el desarrollo rpido de aplicaciones sencillas (Gmez Martn y Gmez Martn, 2005).
Nebula 2: es la evolucin del motor grco anterior. El cdigo fuente

tambin est disponible y se distribuye bajo una licencia que, igual que en el caso anterior, permite su uso por terceros sin coste adicional. A pesar de compartir el nombre con la versin anterior, los cambios entre ambas versiones son notables , principalmente en el motor grco debido al soporte de los
pipeline
grcos programables (shaders ). Una
comparacin entre ambas versiones puede extraerse de Gmez Martn y Gmez Martn (2006). Para minimizar el impacto provocado por los cambios en el motor grco, se ha utilizado, como veremos a continuacin, una
fachada
formada por un
conjunto de clases independientes del motor utilizado. Esta fachada oculta al resto de la aplicacin (y con esto no solo nos referimos al cdigo especco , sino tambin al resto del motor de la aplicacin) las peculiaridades concretas del mismo. Esa fachada, no obstante, nicamente supone una barrera en cuanto al cdigo, pero, lamentablemente, no en cuanto a los datos. El motor grco impone unas restricciones sobre los modelos que es capaz de dibujar, y por consiguiente, tambin respecto a los formatos de los cheros que los contienen. Puede ocurrir incluso que el motor no sea capaz de leer ningn tipo de
4 5
http://nebuladevice.cubik.org/what-is-n2/features/
En este apartado del motor de la aplicacin recuperaremos el signicado original de
cdigo especco que veamos en la gura 4.2, es decir todo lo que no es motor de la aplicacin.
166
Captulo 6.
Figura 6.8: Creacin de un modelo para Nebula 2
chero concreto; en ese caso, se debe ampliar el motor para que sea capaz de interpretar alguno. Para poder presentar personajes con WildMagic, extendimos el motor para soportar modelos de Quake 3 (ver gura 6.6), un juego que dispona de personajes animados por
keyframes ; Nebula 1 fue extendido para dibujar
modelos de Half Life (gura 6.7) cuyas animaciones utilizaban huesos, ahorrando as memoria durante la ejecucin; por ltimo, en Nebula 2 utilizamos el formato del propio motor grco, ya que existe un plug-in comercial que permite grabar los modelos creados en Maya a cheros directamente interpretables por l (gura 6.8). Veremos en la seccin 6.7.2 que la existencia de estos plug-in exportadores de modelos permiten mantener independiente el trabajo de los diseadores del motor nal utilizado; en nuestro caso, nos permiti utilizar en Nebula 2 algunos de los modelos creados para ser dibujados en Nebula 1. Retomando el mecanismo de proteccin del
cdigo
frente a esos cam-
bios, hemos mencionado que utilizamos un diseo de clases que actan como fachada. En particular, la fachada evita los siguientes cambios: Cambios en la inicializacin/destruccin: cada uno de los motores grcos anteriores requieren una serie de pasos distintos tanto al principio como al nal de la aplicacin. Cambios en el bucle principal: el motor de la aplicacin incluye el control de la ejecucin o bucle principal (que veremos en la seccin 6.3.6). En cada vuelta del bucle, como ya tratamos en el apartado 5.9, se debe invocar al motor grco, para que dibuje el fotograma correspondiente, teniendo en cuenta todas las entidades registradas. La forma de invocacin concreta es dependiente del motor grco, por lo que una fachada que lo oculte evita el cambio en el bucle principal.
167
CServer CCamera -_currentCamera -_instance +Init() +Release() +BeginRender() +EndRender() +Trigger() CMap -_currentMap +Render() +AddEntity() +RemoveEntity()
CEntity +Render() +SetTransform() +SetVisible() +SetModel()
0..*
CAnimatedEntity +SetAnimation() +SetAttach()
CBSPModelEntity +SetBSPModel()
Figura 6.9: Clases pblicas del motor grco de JV M
Cambios en el cdigo especco: los objetos de juego con representacin grca, deben invocar al motor grco para que cargue los modelos concretos. La forma de invocar al motor vara entre uno y otro. El diseo de clases que se publicita al resto de la aplicacin desde el motor grco consta, principalmente, de las seis clases mostradas en la gura 6.9 . La ms importante,
CServer
es un singleton con inicializacin explci-
ta. Su misin principal es almacenar todas las referencias al motor grco lanzado, y ocultar los detalles de su inicializacin y destruccin. Tiene tres mtodos que son llamados en cada vuelta del bucle principal: na) y
Trigger
que
realiza funciones de mantenimiento (como procesar los eventos de la venta-
BeginRender
EndRender
que son mtodos invocados justo antes y para el dibujado o la presentacin
despus del dibujado. Estos dos mtodos son requeridos por todos los motores grcos, para congurar el nal de la escena. Destaca que el servidor de la clase
hardware
no
tiene un mtodo para dibujar la escena. El
dibujado concreto es responsabilidad de la clase
CMap.
CEntity
y sus derivadas, y
La primera de ellas representa a una entidad u objeto grco que detallaremos a continuacin. La segunda es una simple agrupacin de entidades. La peculiaridad es que el motor grco tiene en cada momento uno de estos
mapas
activos. Desde el bucle principal de la aplicacin, se invoca al dibujado
de ese mapa activo que, sucesivamente, va llamando al mtodo de dibujado de todas las entidades registradas en l. Por lo tanto, la clase vuelta del bucle, simplemente se llama al mtodo
CMap
es la que
permite la independencia del bucle principal con el motor grco: en cada
Render
del mapa actual,
el cual llamar al mismo mtodo de todas las entidades, cuyo cdigo, ahora
namespace
Tanto en la gura como en la explicacin que sigue, se ha omitido el nombre del
namespace
Graphics.
utilizado; todas las clases descritas a continuacin pertenecen al mdulo o
168
Captulo 6.
s, ser especco del motor grco. En cuanto a las entidades grcas, stas representan los modelos que se dibujan. La clase base,
CEntity
tiene mtodos para establecer la posicin
y rotacin, establecer su visibilidad, as como para indicar el nombre del chero que contiene el modelo grco . La clase, adems, es extendida por otras clases especcas, que permiten caractersticas avanzadas. Por ejemplo,
CAnimatedEntity
su parte,
sirve para modelos de personajes animados, permitiendo permite cargar modelos grcos desde cheros
cambiar la animacin o adjuntar otros modelos como armas o escudos. Por
CBSPModelEntity
de mapas BSP, cuya importancia quedar reejada en la seccin 6.3.3. Para nalizar, la ltima clase
pblica
de la fachada es la que representa
la cmara utilizada, que ja la posicin desde la que se est viendo la escena dibujada, y que contiene los mtodos habituales de control de posicin y apertura de lentes. La implementacin traduce esas rdenes generales al lenguaje especco utilizado por el motor grco subyacente.
6.3.2.
Gestin de entrada
La captura de los eventos de entrada del usuario (pulsacin de teclas, movimiento de ratn y/o palancas de juego) es realizado tambin en el motor de la aplicacin.
En nuestro caso, en la primera versin utilizamos GLUT
Utility Toolkit ),
8 (The
OpenGL
una librera pensada para aplicaciones que hacen uso de
OpenGL para renderizar (como utilizbamos con WildMagic). La librera procesa los eventos de usuario y permite su captura por parte de la aplicacin. Posteriormente, con la sustitucin de WildMagic por Nebula 1 y ms tarde por Nebula 2, cambiamos el sistema de captura, para pasar a utilizar el proporcionado por Nebula. En este sentido, Nebula dispone de una
de eventos
ante ellos.
cola
que la aplicacin puede procesar en el bucle principal para actuar
Independientemente de cmo se acceda al
hardware
para leer la entrada,
el motor de la aplicacin proporciona la funcionalidad necesaria para que el cdigo especco, mediante el patrn observer (Gamma et al., 1995) sea informado de la entrada del usuario y reaccione ante ella. En concreto, las cuatro clases ms importantes aparecen en la gura 6.10. Hay dos clases que sirven de otras dos a modo de
interfaz
s
gestores
de la entrada por teclado y ratn, y
que deben implementar todas las clases que
quieran ser informadas de los eventos, y que se registran en las primeras.
Obsrvese que el chero
es dependiente del motor grco subyacente, al tener la
dependencia de datos antes comentada. Sin embargo, el nombre del chero utilizado vendr a su vez de otro chero de datos (mapa) que deber cambiarse en caso de cambio de motor. Lo que no habr que alterar ser el cdigo fuente de otra parte de la aplicacin, garantizando la independencia con respecto al motor del resto del cdigo.
http://www.opengl.org/resources/libraries/glut/
169
CKeyboardManager -_instance +RegisterObject() +DeregisterObject() 0..*
CKeyboardListener +KeyDown() +KeyUp()
CMouseManager -_instance +RegisterObject() +DeregisterObject() 0..*
CMouseListener +MouseMove() +MouseButtonDown() +MouseButtonUp()
Figura 6.10: Clases relacionadas con la entrada de JV M
Esta forma de comunicacin entre el motor de la aplicacin y el cdigo especco se ha mantenido desde la versin preliminar con WildMagic, de forma que el cdigo especco no se ha visto afectado por el cambio de procedimiento de lectura. En todas las versiones el bucle principal de la aplicacin detecta la entrada (de formas distintas en cada caso), y la redirige al gestor correspondiente para que el cdigo especco sea informado.
6.3.3.
Cargador de mapas
Ya dijimos en la seccin 5.8.2 que es el motor de la aplicacin el que se encarga de la carga del mapa o nivel, donde estn todos los datos del entorno. Este mdulo impone tambin una fuerte restriccin en cuanto a los cheros que se van a poder utilizar para guardar los mapas. Tradicionalmente, los distintos motores de juego utilizados por los estudios utilizan sus propios cheros de datos, generados por los editores que ellos mismos desarrollan. En nuestro caso, hemos optado por un diseo de clases que permite el soporte de distintos tipos de mapas (ver gura 6.11), y lo hemos instanciado para cheros
bsp utilizados en juegos como Half-Life o Quake y para cheros cuyos
datos estn en XML. La posibilidad de aadir soporte para distintos mapas nos permite cambiar a voluntad los editores que se utilizan para crear estos mapas. Ms adelante en la seccin 6.7.2 explicamos cmo hemos creado los de para JV M. Lo ms importante del cargador de mapas es que ste debe ser independiente completamente del cdigo especco. Una cosa es leer el mapa de disco y comprobar que su formato es correcto, y otra bien distinta es objetos del juego que ste posee. Una vez que el cargador ha comprobado que el chero se adhiere correctamente al formato establecido, debe proceder a la creacin de las entidades correspondientes. Una opcin utilizada habitualmente es el uso de factoras extensibles, como la descrita en la seccin 2.6.2. Sin embargo, el mtodo ms general es simplemente invocar a una funcin del cdigo especco a la que
lanzar
los
170
Captulo 6.
CMapLoader
CMapFile 1 1
-_listaEntidades
CMapEntity +getMapModel() +getAtributo()
interfaz CMapLoaderObserver +OnBeginMapLoading() +OnEndMapLoading() +InitEntity(CMapEntity*)()
CMapBSPFile
CMapXMLFile
-_listaModelos CMapModel * +createGraphicsEntity() *
...
CMapBSPModel
CMapXMLModel
...
Figura 6.11: Diseo de clases del cargador de mapas
se le da toda la informacin de la entidad contenida en el mapa. El cdigo especco entonces decidir crear los objetos de juego correspondientes. Esta independencia entre el cargador de los mapas y el cdigo especco es una de las caractersticas que permitirn posteriormente congurar el entorno virtual en base al ejercicio utilizado, como se describe en el apartado 6.6.2. El diagrama de clases utilizado en el cargador de mapas es mostrado en la gura 6.11. En l, vemos que existe una clase
CMapFile
que representa la
informacin contenida en un mapa o nivel ledo de disco. La clase contiene un mtodo para construir un objeto de la clase a partir del nombre del chero. Para soportar los distintos cheros de mapa soportados, se utilizan clases derivadas creadas especcamente para cada uno de ellos. De esa forma forma el nico punto de la aplicacin que habra que modicar si se cambia el
pipeline
de contenidos (ver apartado 6.7) y se generan los mapas con otro
formato, es, precisamente, el cargador. Cada mapa ledo de disco dispone de una lista de entidades, y una lista de modelos. Ya explicamos en la seccin 5.8.2 la razn de que el propio mapa incluya informacin de modelos: algunas entidades tienen modelos estticos (arquitectura del nivel) o representan el terreno. En vez de hacer referencia a modelos en cheros externos distintos al del mapa, se empaqueta tanto la informacin de las entidades como de los propios modelos en un nico chero. En el diseo de clases, la informacin de cada entidad se almacena en un objeto de la clase
CMapEntity, que contiene (i) la lista de pares atributoCMapModel,
valor en la que se basar el cdigo especco para crear los objetos de juego y (ii) el modelo asociado a esa entidad, si ste existe. Por ltimo, para representar el modelo, disponemos de la clase
para representar el modelo guardado en el mapa asociado a una entidad. Cada tipo de mapa soportado tiene asociada una clase derivada de sta, que es capaz de construir la entidad grca asociada a ese modelo a partir de la
171
informacin contenida en el chero. Para el soporte de cheros
9 por Valve . El formato del chero permite
bsp,
hemos hecho uso de una librera creada
empaquetar
tanto la lista de en-
tidades como el modelo de los objetos estticos del mundo (arquitectura y objetos como puertas, interruptores, papeleras o farolas). Por lo tanto, en
CMapModel representa un modelo cargado desde el propio bsp. El mtodo que construye la entidad grca crea un objeto de la clase Graphics::CBSPModelEntity vista en la seccin 6.3.1.
este caso un objeto Por su parte, en el soporte para mapas contenidos en XML, esos modelos estticos
no
se almacenan en el propio XML, sino en cheros de datos ex-
ternos. Las entidades con modelos estticos hacen referencia a esos cheros, y el cargador de mapas los lee automticamente al analizar el XML y crear los
CMapEntity
asociados.
Para la comunicacin entre el cargador de mapas del motor de la aplicacin y el cdigo especco, existe un interfaz,
CMapLoaderObserver,
que
tiene tres mtodos de noticacin de eventos relacionados con la carga, dos para indicar que sta va a comenzar o ha terminado, y un tercero, el ms importante, invocado una vez por cada entidad del mapa. El cdigo especco, entonces, crear los objetos de juego asociados a cada una de las entidades. El cdigo fuente ms relevante aparece en la seccin C.1.
6.3.4.
Motor de sonido
10
Para la implementacin del motor de sonido, hemos utilizado OpenAL
(Lengyel, 2006), que proporciona una API de audio multiplataforma desarrollada por Creative Labs para el renderizado eciente de audio posicional y multicanal en tres dimensiones. La librera ha sido utilizada con xito en juegos de renombre como Doom 3 y Quake, algunos ttulos de la saga UnrealTournament o Escape from Monkey Island. Igual que en el caso del motor grco, sobre OpenAL se crea el concepto de entidad sonora que el cdigo especco puede manejar. Ese objeto entidad permite reproducir un sonido determinado, as como posicionar la fuente para permitir sonido tridimensional.
6.3.5.
Motor de colisiones
El motor de colisiones realiza los clculos necesarios para detectar si dos objetos del entorno virtual han colisionado, para que stos reaccionen de forma coherente a las reglas del propio entorno. El motor de colisiones mantiene, pues, una representacin propia de cada uno de los objetos (lo que se suele denominar
malla de colisin ),
con la que
9 10
El estudio que desarroll Half-Life. Disponible en
http://www.openal.org/
172
Captulo 6.
CAppBaseState +OnAttach() +OnDettach() +OnActivate() +OnDeactivate() +OnSuspend() +OnResume() +RunTick() +Render() +OnQuitRequested() +OnKeyPressed() +OnKeyUnpressed() +OnMouseMove() +OnMouseClick()
CApplication +Init() +Run() +End() +RequestQuit()
CAppStateManager +AddState() +RemoveState() +SetState()
1..*
CJVVM1App
CJVVM2App
CAppGameState
CAppVideoState
CAppMenuState
Figura 6.12: Diseo de clases de la aplicacin
realiza sus clculos, y que normalmente es una simplicacin o aproximacin
burda
del objeto que se dibuja.
DEtection ),
Para el motor de colisiones hemos utilizado Opcode (OPtimized
COllision
que tambin ha sido utilizado en otros motores de juego como
CrystalSpace
11 o Irrlicht12 .
Igual que ocurre en todos los casos anteriores, lo importante para mantener la independencia entre ste y el resto de la aplicacin, es proporcionar el concepto de
entidad de colisin
por encima de Opcode. El cdigo especco
puede crear este tipo de entidades para su benecio. Por ejemplo, y en particular, la clase
CMapModel descrita en la seccin 6.3.3, al igual que dispone del mtodo createGraphicsEntity() (ver gura 6.11), tiene un mtodo que
construye la entidad de colisin a partir del modelo contenido en el mapa.
6.3.6.
Control de ejecucin
dueo
de la hebra principal del programa,
El motor de la aplicacin es el
por lo que es el que dirige su ejecucin completa. En particular, implementa el bucle principal del que se habl en las secciones 2.5 y 5.9. Dado que la aplicacin puede estar en
estados
distintos, el bucle principal
ejecutado puede variar dependiendo del momento. Por citar un ejemplo, el bucle debe ejecutar unas tareas diferentes cuando est en el men del usuario a las que invoca cuando est reproduciendo un vdeo a pantalla completa o en el propio juego. Para facilitar esta gestin, la aplicacin (CApplication) est implementada utilizando el patrn estado descrito por Gamma et al. (1995). El patrn convierte a la aplicacin en una mquina de estados, en este caso gestionada
11 12
Disponible en http://www.crystalspace3d.org. http://irrlicht.sourceforge.net
173
por la clase
CAppStateManager.
Los estados (CAppBaseState)
extraen
del
bucle principal todas aquellas tareas especcas o dependientes de l. De esta forma, las tareas comunes a todos ellos (mantenimiento del gestor de memoria, procesado de eventos de ventana, etc.) pueden quedarse bajo el control de la aplicacin, mientras que el resto son implementadas en clases externas que puede intercambiarse en tiempo de ejecucin. La idea puede incluso generalizarse an ms. Como se ve en la gura 6.12 en la implementacin de JV M, existe una clase
CApplication general de la
2
que heredan las aplicaciones particulares. De esta forma, toda la gestin de los estados se puede reutilizar en distintas aplicaciones. La diferencia entre las distintas aplicaciones (por ejemplo entre JV M 1 y JV M 2) est en: Mtodos de inicializacin y destruccin (Init y
End): en ellos la aplica13 . Tambin
cin inicializa todos los mdulos o motores internos y cede el control al cdigo especco para que haga lo propio. Si dos aplicaciones utilizan mdulos distintos, su inicializacin y destruccin variar sern distintos los estados de la aplicacin que construyen. Bucle principal (Run): en este mtodo se invocan las distintas tareas generales, as como los mtodos del estado activo. Si bien esta segunda parte es general y comn a todas las aplicaciones, la primera puede necesitar modicaciones si las diferencias entre ellas son signicativas. En nuestro caso, tenemos dos clases distintas, una para cada versin de JV M. La nica diferencia que existe entre ambas en la funcin de entrada al programa (main) es la clase a la que pertenece la nica instancia creada de la aplicacin:
i n t main ( i n t argc , char argv [ ] ) { CJVVMApp theApp ("JVVM" ) ; bool i n i t C o r r e c t o ; theApp . SetCommandLineArgs ( argc , argv ) ; i n i t C o r r e c t o = theApp . I n i t ( ) ; i f ( initCorrecto ) theApp . Run ( ) ; }
13
theApp . End ( ) ;
En ocasiones, no obstante, no hay diferencias a pesar de cambios en los motores, si
stos disponen por encima de una fachada como la explicada para el motor grco en la seccin 6.3.1.
174
Captulo 6.
En cuanto a los mtodos de los estados que son invocados por la aplicacin distinguimos cuatro tipos: De inicializacin y destruccin: cuando el estado es do es
enganchado
a la
aplicacin, es decir, cuando se aade como estado de la misma, y cuan-
desenganchado,
la aplicacin invoca a los mtodos correspon-
dientes. En el de inicializacin, el estado construir las estructuras que necesitar durante la ejecucin. De activacin y desactivacin: en general, los estados son creados al principio de la aplicacin, de tal forma que la vida de estos objetos coincide con la ejecucin del programa. No obstante, el estado no est
activo
durante todo ese tiempo, sino nicamente en ciertos momentos.
Existen ciertas estructuras que no tiene sentido mantener en memoria cuando el estado est inactivo, por lo que la aplicacin le
avisa
cuan-
do ste es activado y desactivado. Esos mtodos permiten al estado crear estructuras nicamente tiles durante el periodo de actividad, o realizar otras tareas concretas. Por ejemplo, el estado en el que se encuentra la aplicacin cuando est mostrando el men, puede lanzar la reproduccin de sonido de fondo cuando se activa, y pararlo en su desactivacin. De noticacin de eventos: en particular, cuando la aplicacin detecta eventos de entrada de usuario (pulsacin de teclas, movimiento del ratn), stos son redirigidos al estado particular para su gestin. Cuando se est en el estado del juego (CAppGameState en la gura), el propio estado se encarga de enviarlos a su vez a los gestores de la entrada descritos en la seccin 6.3.2. De implementacin de las tareas especcas del bucle principal: en JV M son dos, la ejecucin de la lgica, y la de dibujado. Cada estado de la aplicacin proceder en ellos de forma distinta. Por ejemplo, el estado del men no implementa nada de lgica, y el dibujado consiste simplemente en mantener en pantalla las opciones, mientras que el estado del juego invoca al cdigo especco en la primera, y dibuja las entidades registradas en el motor grco en la segunda.
De manera simplicada, el bucle principal nal es el siguiente: en cada vuelta del bucle, la aplicacin, por medio del gestor de estados, comprueba si debe realizar una transicin; si es as, se llama a los mtodos de desactivacin y activacin correspondientes. Posteriormente, actualiza el tiempo de la aplicacin, para averiguar cunto tiempo ha transcurrido. Despus de realizar una serie de operaciones de mantenimiento del propio motor de la aplicacin (gestor de memoria, procesado de los eventos de la ventana, etc.), comprueba la entrada de usuario e informa al estado activo si hay algn
175
aplicacion CApplication Loop 1: 1.1: DoTransitions 1.2: UpdateTime():void
clock CAppClock
graphicsServer CServer
gameState CAppGameState
1.3: Trigger():bool
1.4: ParseEvents 1.4.1: OnKeyPressed(int,float,float):bool
1.5: RunTick():void 1.6: Render():void
Figura 6.13: Diagrama de secuencia del bucle principal de JV M
evento. Acto seguido, invoca la actualizacin de la lgica implementada en el estado, y por ltimo el mtodo de dibujado. El proceso completo aparece en la gura 6.13
14 .
Otra responsabilidad relacionada con el control de la ejecucin enmarcado dentro del motor de la aplicacin es la
gestin del tiempo.
Cuando el estado
lanza la ejecucin de su lgica debe conocer, como ya hemos dicho en otras ocasiones, cunto tiempo ha transcurrido desde la ltima actualizacin, para que actualice sus entidades (posiciones, etc.), de acuerdo a ese tiempo
15 .
Aunque en el diagrama del bucle principal ya apareca la actualizacin del reloj, el diseo de clases involucrado merece una descripcin detallada. Para minimizar el impacto ante cambios de plataforma y facilitar algunos aspectos que veremos enseguida, la gestin del tiempo est implementada de tal forma que
separa
el
reloj fsico
fuente
de la que se lee la hora, y el reloj
lgico que maneja la aplicacin (ver gura 6.14).
14 15
De todas las tareas de mantenimiento, nicamente aparece la de gestin del servidor Esto es debido a que el bucle principal descrito es de tipo fotograma y paso de tiempo
grco. variable (descritos ambos en la seccin 2.5).
176
Captulo 6.
CAppClock interfaz ITimeSource +GetTime() CApplication 1 +UpdateTime() +AddClock() +RemoveClock() 1..* CClock CConstTimeSource CNebulaTimeSource CLogDecoratorTimeSource -outputFile +Pause() +Resume() +Scale() +UpdateTime() +GetLastFrameTime() +GetTime() 1
Figura 6.14: Diagrama de clases que gestionan la hora de la aplicacin en JV M
La implementacin, basada en Llopis (2004), tiene una clase abstracta que representa la
fuente
de la hora (ITimeSource). Dependiendo de la
plataforma, la clase derivada usada utilizar las funciones de uno u otro sistema operativo. En nuestro caso, en vez de utilizar las funciones del sistema operativo subyacente, delegamos la responsabilidad a Nebula (la clase implementada es
CNebulaTimeSource),
que dispone de un reloj que tambin
utiliza para actualizar los sistemas de partculas y otros de sus subsistemas. La fuente de tiempo es la que dicta al reloj de la aplicacin (CAppClock) la hora que debe regir la ejecucin de cada vuelta del bucle. La actualizacin de la hora, que vena reejada en la gura 6.13 en la invocacin al mtodo
CAppClock::UpdateTime,
Esa hora almacenada en
delega en la fuente concreta para obtener el
tiempo.
tos relojes
(CClock), permiten ser pausados e incluso escalados, de tal forma que avancen ms rpido o ms despacio que el reloj real. El cdigo especco puede entonces basar su actualizacin en varios relojes lgicos a distintas velocidades, para conseguir, por ejemplo, el
lgicos
CAppClock
sirve de
reloj base
para los distin-
que el motor de la aplicacin permite. Esos relojes lgicos
tiempo bala 16 .
La separacin entre la fuente de tiempo y el reloj de la aplicacin permite, adems, repetir ejecuciones de la aplicacin para solucionar errores que parecen ocurrir de manera arbitraria, pero que en realidad estn relacionados con las pequeas variaciones de tiempo entre fotogramas que se producen en distintas ejecuciones de la aplicacin. Utilizando el patrn decorador (Gamma et al., 1995), la propia fuente puede grabar a disco el tiempo en el que empieza cada fotograma (en la gura 6.14 apareca en la clase
CLogDecoratorTimeSource). En ejecuciones sucesivas, se puede utilizar una

fuente de tiempo que simplemente lea de chero la secuencia de horas de la ejecucin anterior, eliminando el indeterminismo introducido por esas varia-
16
Tambin las entidades grcas que aparecen en la gura 6.9 tienen referencias al reloj
lgico que deben utilizar para actualizar sus animaciones.
177
ciones de tiempo. Una vez jadas las responsabilidades del control de la ejecucin (bucle principal y gestin del tiempo) y la forma de implementarlos, veamos cmo son utilizados en JV M. La aplicacin completa tiene tres estados distintos implementados: Men: que permite la seleccin del perl del estudiante y comienzo del juego. Vdeo: para reproducir secuencias al principio de la aplicacin, etc. Puede ser congurado para que al pulsar una tecla (es decir, cuando el bucle principal invoca a su mtodo
OnKeyPressed),
termine la
reproduccin y salte a otro estado distinto. Juego: en su activacin provoca la carga del mapa concreto que tiene el escenario, y su conguracin dependiendo del estado del subsistema de tutora. Cuando se invoca desde el bucle principal la ejecucin de su lgica, se traslada al cdigo especco, que se encargar de actualizar las entidades, la vista lgica y el subsistema de tutora. Para el dibujado, confa en el motor grco, donde se mandan dibujar todas las entidades grcas registradas por el cdigo especco. Cuando recibe eventos de entrada, los redirige a los gestores (CKeyboardManager y CMouseManager) que informan a las partes del cdigo especco interesadas. La parte ms importante desde el punto de vista arquitectnico, sin duda, es qu mecanismos proporciona el motor de la aplicacin (y en particular el control de la ejecucin) al cdigo especco para ser invocado en cada vuelta del bucle. En nuestro caso, disponemos de dos mecanismos: Invocacin en cada vuelta del bucle (o fotograma): el cdigo especco puede
engancharse
para ser invocado por ste en cada vuelta del bucle
principal, justo antes del dibujado. La forma de hacerlo es mediante un observer. Este mecanismo es utilizado por mdulos generales del cdigo especco, como veremos en la seccin 6.4.1. Temporizador: ya hemos mencionado alguna vez que los objetos del juego deben
actualizarse
cada cierto tiempo, para que tomen decisio-
nes sobre su comportamiento. La opcin ms fcil es invocar un mtodo de actualizacin en cada vuelta del bucle. Sin embargo, la mayora de estas entidades no requieren tanta frecuencia para poder dar una sensacin de credibilidad. Por eso, por eciencia, el motor de la aplicacin proporciona un temporizador, que permite a las entidades registrarse de tal forma que son avisadas cuando transcurren un nmero determinado de milisegundos. El diseo de clases que lo permite se muestra en la gura 6.15.
178
Captulo 6.
CTemporizadorApp CClock -_instance +AddEvent() +AddCiclicalEvent() +RemoveEvent() 0..*
CTemporizadorInterface +TemporizadorExpirado() +TemporizCallMeIn() +TemporizCallMeEach() +TemporizDontCallMeMore()
void CTemporizadorInterface::TemporizCallMeIn(long mSecs) { CTemporizadorApp::GetInstance().AddEvent(this, mSecs); } void CTemporizadorInterface::TemporizCallMeEach(long mSecs) { CTemporizadorApp::GetInstance().AddCiclicalEvent(this, mSecs); } void CTemporizadorInterface::TemporizDontCallMeMore(long mSecs) { CTemporizadorApp::GetInstance().RemoveEvent(this); }
Figura 6.15: Diseo de clases del temporizador de la aplicacin en JV M
6.4. Gestin de entidades

Como indicbamos en la seccin 5.6, en este mdulo se sitan las entidades del juego, que representan los objetos sean visibles o invisibles). Algunas de estas entidades sern los representantes en el entorno virtual de los objetos que aparecen en la sistema el
dinmicos
del entorno virtual (ya
vista lgica
que describiremos en la sec-
cin 6.5. Debido a esto, en la implementacin de JV M hemos llamado a este
mdulo gestor de los objetos del interfaz Interface Manager ).
o mdulo OIM (Object
6.4.1.
Funciones principales
comienzo
de lo que
En la arquitectura para videojuegos educativos descritas en el apartado anterior, situbamos el control de las entidades como el en juegos vinimos a llamar
cdigo especco.
En general, se entiende que la principal funcin de esta capa es el control de todas las entidades que dan vida al juego. Sin embargo, desde el punto de vista de nuestra metodologa y arquitectura, la funcin ms importante es la
conguracin
del entorno virtual con respecto al ejercicio.
Ya vimos en los captulos anteriores que uno de los aspectos ms importantes de nuestra arquitectura es que permite la separacin de los dos tipos de datos necesarios para el desarrollo del videojuego educativo: los contenidos de instruccin y los entornos virtuales. De esta forma se consigue que el mismo entorno virtual (costoso de construir) pueda ser reutilizado por distintos ejercicios y viceversa.
179
Pues bien, la funcionalidad que permite la modicacin o adaptacin del entorno virtual en base al ejercicio seleccionado se sita en este mdulo de gestin de entidades. En concreto, en la inicializacin de los objetos de juego dependientes del contexto educativo, stos comprueban el estado de la vista lgica que ja el ejercicio y se conguran en consecuencia. Con esta estructura, el diseador del nivel o entorno virtual no determina por completo el comportamiento nal del mapa, sino que deja algunos de sus aspectos abiertos. En el caso del ejemplo que explicbamos en el apartado 5.11 de entrenamiento de bomberos, el diseador del nivel coloca entidades en el entorno virtual que simbolizan puntos donde pueden aparecer vctimas. El experto del dominio, por su parte, crea ejercicios concretos con una cantidad de vctimas determinadas. Cuando el mapa se lanza, la inicializacin de las entidades que denen las localizaciones de las vctimas pueden crear los avatares correspondientes, o pueden, al comprobar que el ejercicio no requiere ningn afectado ms, no crear ningn otro objeto de juego. En JV M, existen varias entidades que se conguran en su inicializacin en base al ejercicio actual. Por ejemplo, las entidades que representan la pila de
frames
(que en JV M 1 se traduce en un edicio volante y en JV M 2
en distintas plantas de una nave espacial) en su inicializacin comprueban el nmero de registros de activacin suspendidos; por su parte, la pila de operandos (guras 6.3c y 6.4b) crea tantas cajas como existan en el momento del lanzamiento del mapa. En la seccin 6.4.3 veremos un ejemplo concreto de conguracin de entidades a partir del ejercicio, en particular, cmo las manadas conguran su nmero de individuos dependiendo del mtodo en ejecucin. Para la gestin de todas las entidades, tanto las que se conguran a partir del ejercicio actual como las que no, la capa OIM dispone de una lista de todos los mapas que hay lanzados en la aplicacin. La necesidad de tener
ms de un
2
mapa se debe a que, en el contexto educativo y la metfora
seleccionada, es posible que tengamos
varios
mapas activos a la vez. Por
ejemplo, en JV M 2 existe un mapa para el nivel que representa un varios mapas lanzados que provienen
frame,
y otro para la sala de una clase cargada; incluso se da el caso de tener
congurados
representan
del mismo chero,
pero que han sido
de forma distinta. Por ejemplo, todos los niveles de la nave que
frames
o todas las salas que representan clases.
Dentro de la lista de mapas, existe uno que es el mapa actual en el que se encuentra el usuario. Pasar de un mapa a otro puede ocurrir o bien mediante
teletransportadores
2
(entidades especiales que lanzan el cambio de mapa con
su uso), o bien al salir fuera de las fronteras fsicas del mapa (por ejemplo, en JV M 1 hay un cambio de mapa cuando el usuario atraviesa la puerta que da acceso al
frame
actual que apareca en la gura 6.2a).
Cada uno de los mapas tiene una lista de todas las entidades u objetos del
180
Captulo 6.
juego que contiene. La capa OIM crea el aplicacin le informa (mediante el
mapa OIM cuando el motor de la observer CMapLoaderObserver mostrado

17 . A partir
en la gura 6.11) del comienzo de la carga de un mapa desde disco
de ese momento, todas las entidades que se inicialicen se crearn en el mapa que se est lanzando, hasta el momento en el que el cargador de mapas del motor de la aplicacin indique que ha terminado la carga. Con esto, terminamos la descripcin de las funciones ms importantes de la capa OIM: gestin de las entidades que conforman el entorno virtual y creacin y conguracin de las mismas en base al mapa y al ejercicio actual. Sin embargo, para denir el comportamiento de las entidades, la capa OIM dispone de otros mdulos, que pasamos a describir en la seccin siguiente.
6.4.2.
Mdulos OIM
Adems del control de los mapas y sus entidades, el mdulo OIM contiene otra serie de submdulos de soporte que facilitan la programacin de esas entidades. Estos submdulos no se sitan dentro del motor de la aplicacin porque su funcionamiento concreto es
especco
del juego en cuestin. Para
su ejecucin por tanto, deben ser invocados por ste, utilizando alguno de los dos mecanismos comentados previamente: activacin de un temporizador, o en cada vuelta del bucle mediante un observer. En el caso de JV M, existen tres mdulos auxiliares de importancia: Percepcin: en JV M 1 se encarga fundamentalmente de controlar las opciones que tiene disponibles el usuario cuando se acercaba a los distintos elementos activos del entorno (ver gura 6.3c). Por lo tanto, implementa la
percepcin del estudiante :
cuando ste tiene dentro del
campo de visin algn elemento activo, avisa a la entidad para que acte en consecuencia (aadiendo la opcin en la lista de opciones). En JV M 2 es til para la programacin de los NPCs. Bsqueda de rutas: para cada mapa lanzado, este mdulo almacena un grafo con nodos. Las entidades pueden preguntar cmo ir de una posicin a otra del entorno y el mdulo, utilizando pedaggico, encuentre el camino hacia el estudiante. Gestin de manadas: ya hemos nombrado las manadas como ejemplo de entidades que se conguran en base al ejercicio. Para determinar el modo en que se comportan sus individuos una vez creados, utilizamos las ideas expuestas por Reynolds (1999) usando un mdulo externo, de
A ,
calcula el ca-
2 mino. Se utiliza, por ejemplo, en JV M 1 para que Javy, el agente
17
Aunque la creacin del mapa no se muestra en el diagrama de la secuencia de la
gura 6.20, s puede verse las invocaciones desde el cargador de mapas para avisar del comienzo y n de la carga del mapa
181
CGestorManadas +Update() +addManada() +deleteManada()
CManada -_centro -_orientacion +addIndividuo() +deleteIndividuo() +Update() CReglaBasica 0..* +getDireccion()
0..*
CReglaOrientacion CReglaAlejamiento CReglaCohesion CReglaEvasion
CReglaHuida
Figura 6.16: Diagrama de clases del gestor de manadas de JV M
tal forma que luego las entidades establecen su posicin de acuerdo a lo que ste dicta. Para que estos mdulos funcionen que algunas de las entidades
tambin
deben ser inicializados de
acuerdo a la informacin contenida en el mapa durante la carga, de forma
del mapa
no se convierten en objetos de juego,
sino en informacin de inicializacin de estos mdulos. Como ejemplo detallado de esto, veamos cmo funciona el gestor de las manadas, cuyo diagrama de clases aparece en la gura 6.16. Como se puede ver, el gestor (CGestorManadas) contiene una lista con todas las manadas (CManada) que gestiona. Por su parte, cada manada est formada por una lista de individuos, de los que guarda sus posiciones y orientaciones. Esas posiciones y orientaciones se deciden de acuerdo a unas
reglas
concretas, cada
una con un peso especco diferente. En nuestro caso, existen cinco reglas distintas, que intentan, por ejemplo, que los individuos tiendan a acercarse al centro de la manada y a tener la misma direccin que ella, a no acercarse demasiado al resto de individuos o intentar evitar al jugador. Para poner todo esto en funcionamiento, el gestor de manadas es invocado en cada vuelta del bucle desde el motor de la aplicacin, lo que provoca la actualizacin de todas las manadas y, por consiguiente, de todos sus individuos. En JV M 2, adems, las manadas siguen una ruta determinada. En particular, existe por cada manada un
grafo
por el que patrulla. Para ello, el
centro de la manada se va moviendo por las distintas aristas del grafo, haciendo que todos los individuos de la manada se muevan en esa direccin. Para almacenar los grafos se utiliza un mdulo auxiliar que utiliza los tipos de datos proporcionados por la librera
boost18 .
Toda esta infraestructura para la gestin de las manadas, sin embargo, es intil si no hay alguien que construya alguna manada cuando se carga un mapa. Para ello, el diseador del nivel debe aadir al mapa dos tipos de informacin distintos:
18
http://www.boost.org/
182
Captulo 6.
Figura 6.17: Manadas en funcionamiento en JV M 2
El grafo por el que patrullan las manadas: consiste en colocar entidades puntuales que marcan las posiciones de los vrtices (entidad
waypoint), y una entidad que dene las aristas que tiene el grafo (entidad waypointGraph). El grafo viene dado mediante una cadena con
las aristas codicadas utilizando los nombres de los vrtices
19 .
La informacin de la manada: mediante otra entidad distinta (manada). sta contiene algunos de los atributos generales de la manada, como los modelos grcos que utilizan sus individuos, o el nombre del grafo por el que patrullan.
Cuando el cargador de mapas del motor de la aplicacin lee esas entidades, invoca al mtodo y
CreateEntity
del mdulo OIM (gracias al interfaz
de la gura 6.11 explicado en la pgina 171). Para las entidades
waypointGraph,
waypoint
se registra la informacin asociada del grafo en el m-
dulo correspondiente, que ser procesada al nalizar la carga del mapa (OnEndMapLoading), ya que hasta ese momento no se garantiza que todos los vrtices se hayan ledo. Por su parte, la entidad
manada
crea y registra
la manada en el gestor, crea la inteligencia articial de la manada, que mover su centro por el grafo y crea sus individuos. Estos dos ltimos pasos son descritos con detalle en la seccin 6.4.7. El resultado nal puede verse en la gura 6.17, donde aparece una captura de la versin de depuracin de JV M 2 con lneas azules representando el grafo que sigue la manada, y
19
La codicacin concreta es una lista de parejas, cada una compuesta por un vrtice,
y una lista con sus vrtices adyacentes, de forma que, al ser un grafo bidireccional o no dirigido, se pueden omitir componentes. Por ejemplo, la cadena A{B el grafo de tres vrtices, todos ellos interconectados.
C}B{C}
representa
183
Figura 6.18: Edicin de manadas en Worldcraft
lneas blancas que parten del centro de cada uno de los individuos hasta el centro de la manada.
6.4.3.
Conguracin de entidades segn el ejercicio
Una vez detallado el mdulo de gestin de las manadas, podemos ejemplicar el proceso que siguen para congurar sus propiedades en base al ejercicio. Como ya comentamos, en JV M 2 el jugador tiene que conseguir los recursos necesarios para ejecutar el mtodo. Cada recurso est oculto en un miembro de la manada, por lo que el nmero de individuos que sta posee inicialmente depende del ejercicio. Ya hemos visto que para que las manadas aparezcan en el nivel, el diseador ha tenido que colocar en el mapa los puntos por donde sta pasear, as como una entidad
manada que es la responsable, precisamente, de la crea-
cin de los individuos. En la gura 6.18 aparece una captura en el momento de la edicin; en ella, se puede ver seleccionada la entidad responsable de la creacin de las manadas (cubo seleccionado en la vista de la esquina superior izquierda), junto con sus propiedades. El editor despus graba un chero que el motor de la aplicacin, y en particular el cargador de mapas, leer durante la ejecucin; la gura 6.19 muestra la parte relacionada con las manadas. Ya en tiempo de ejecucin de la aplicacin, el proceso de conguracin de las manadas, que termina con el nmero de individuos necesarios para el
184
Captulo 6.
... <e n t i t y classname=" waypoint " targetname="A1" o r i g i n=" 84 1456 4"/> <e n t i t y classname=" waypointGraph " o r i g i n=" 111 1775 0" graph="B1{A1 E1 D1}C1{A1 D1 E1}F1{D1 G1}G1{E1}" targetname="GrafoManada1"/> <e n t i t y classname="manada" c o n t r o l=" waypoints " r a d i o=" 128 " g r a f o="GrafoManada1" model=" a l i e n / a l i e n . n2"/> ...
Figura 6.19: Cdigo parcial de un mapa
ejercicio (gura 6.17), es el siguiente: El subsistema de tutora selecciona el siguiente ejercicio a presentar al usuario, utilizando el perl del estudiante y la base de ejercicios. En nuestro caso, el ejercicio est compuesto, entre otras cosas, del cdigo en Java de una o ms clases. La vista lgica del mundo se congura en base a ese ejercicio. En JV M, se utiliza la descripcin del ejercicio para congurar la mquina virtual: se cargan las clases con sus mtodos, y se lanza la ejecucin del programa hasta el punto en el que el estudiante debe comenzar a ejecutar. El mapa con el entorno virtual es cargado. Aqu entra en juego el motor de la aplicacin, en particular, el cargador de mapas descrito en la seccin 6.3.3, que va leyendo todas las entidades. Una de esas entidades ser la entidad ra 6.19. La lectura de esa entidad provoca la creacin de un nuevo objeto de juego responsable del control de la manada (se ver en detalle este control en el apartado 6.4.7). En la inicializacin de la entidad, el objeto pregunta a la vista lgica (mquina virtual) qu recursos son necesarios para la ejecucin del mtodo actual (por ejemplo, si el mtodo tiene una instruccin del tipo c
manada
que aparece en la gu-
= 3 + 5;,
los recursos sern tanto las constantes 3 y 5 como
el nombre de la variable
c.
El control de la manada crea un individuo por cada recurso. El proceso completo puede verse a modo de diagrama de secuencia en la gura 6.20.
185
cargador mapas Aplicacion 1: seleccionarEjercicio
OIM
manada
subsistema tutoria
vista logica
JVM
1.1: InicializaEstado 1.1.1: JVM::CargaEstado 2: LoadMap
2.1: OnBeginMapLoader 2.2: InitEntity 2.2.1: Init
2.2.1.1: getRecursosMetodoActual 2.2.1.2:[1..n] creaIndividuo
2.3: OnEndMapLoader
Figura 6.20: Diagrama de secuencia de la inicializacin de una manada
6.4.4.
Objetos OIM
OIMObject.
objects ), estn implementados en
Las entidades del juego, o como los hemos llamado en ocasiones en los captulos anteriores objetos del juego (game
2 JV M en la clase
Objetos de esta clase existen para representar
los NPCs que se mueven por el entorno, as como el resto de componentes activos (visibles o no), como trampillas o terminales. Para la gestin de estos objetos, la capa OIM dispone de una clase que almacena toda la informacin relativa a un particular, contiene: El reloj de la aplicacin (CClock, ver seccin 6.3.6) que se utiliza como base para todas las entidades de ese mapa. Los mapas grco y de colisin, es decir las referencias a objetos del motor de la aplicacin, donde se aaden las entidades grcas y de colisin de todos los
mapa lanzado (OIM::CMap).
En
OIMObject
de ese mapa.
El grafo utilizado para la bsqueda de caminos de los NPCs en ese mapa. El grafo se inicializa de forma anloga a los grafos de las manadas explicados en la seccin anterior. Los grafos de las manadas, as como el gestor de manadas utilizado en ese mapa. Dos listas de objetos OIM, una que contiene las entidades activas y otra con las inactivas o suspendidas. La diferencia fundamental entre
186
Captulo 6.
void OIM::CMap::Activate() { for each oimObject in _entidadesActivas oimObject->OnActivate(); for each oimObject in _entidadesInactivas oimObject->OnActivate(); }
OIM::CMap +Activate() +Deactivate() +Tick() +SuspendEntity() +ResumeEntity() -_entidadesActivas
-_mapWhereIAm
OIM::OIMObject +OnActivate() +OnDeactivate() +Tick() +OnSuspend() +OnResume()
0..* -_entidadesInactivas 0..*
void OIM::CMap::SuspendEntity(OIMObject *entity) { if (entity in _entidadesActivas) { _entidadesActivas.remove(entity); _entidadesInactivas.add(entity); entity->OnSuspend(); } }
void OIM::CMap::Tick() { for each oimObject in _entidadesActivas oimObject->OnActivate(); }
Figura 6.21: Relacin entre mapas y objetos OIM
ambas es que las entidades suspendidas no necesitan ser actualizadas en cada vuelta del bucle, sino que estn esperando a que se produzca algn evento, como la expiracin de un temporizador.
Todas estas estructuras son inicializadas cuando el motor de la aplicacin indica que se va a proceder a la carga de un nuevo mapa. Si alguna de ellas requiere clculos posteriores (como por ejemplo preclculos relacionados con los grafos de las manadas del mapa), stos son realizados cuando el motor de la aplicacin informa de la nalizacin. Una vez lanzado el mapa, la interaccin con el entorno virtual puede comenzar. En ese momento, el bucle principal de la aplicacin estar realizando todas las tareas de mantenimiento y en cada vuelta del bucle invocar a un mtodo
Tick
de la capa OIM y a todos los objetos cuyo cronmetro
haya expirado. En cada
Tick, la capa OIM invoca a los mdulos internos (en particular,
gestin de manadas y percepcin). Acto seguido, cede el control al objeto que representa el mapa actual, el cual recorre toda la lista de entidades activas (OIMObject), llamando a sus mtodos de actualizacin respectivos; el esquema del proceso puede verse en la gura 6.21. Relacionado tambin con la gestin de los mapas, ya hemos dicho que puede haber varios lanzados pero solamente uno activo cuyas entidades se actualizan. Cuando se produce un cambio de mapa activo, el mdulo OIM invoca a los mtodos
Activate y Deactivate del mapa activado y desactivado
respectivamente, que a su vez avisan a todas sus entidades para permitirles realizar acciones concretas, como registrarse o deregistrarse del cronmetro de la aplicacin. Aparte de servir de
contenedor
de entidades, los mapas de la capa OIM
tambin son utilizados por las propias entidades para buscarse entre s y poder comunicarse entre ellas. Esta comunicacin es indispensable para con-
187
seguir la sensacin de que el entorno reacciona de manera coherente a sus propias reglas. Por ejemplo, un interruptor puede activar un ascensor, o el propio ascensor, al llegar a su destino, puede abrir las puertas situadas en el piso alcanzado. Para poder hacer esto, existe un mecanismo de comunicacin entre entidades, utilizando
seales.
En juegos con interaccin sencilla y clara, como
2 ocurre en JV M 1, esas seales quedaban reducidas a cinco, por lo que para

la implementacin del sistema de envo se ha optado por la creacin en la clase
OIMObject
de los cinco mtodos correspondientes. La lista concreta de
las cinco seales posibles enviadas entre entidades aparece a continuacin; de ellas, las tres ltimas slo pueden ser generadas por la entidad del jugador o la entidad de
Javy,
el agente pedaggico
20 :
Touch:
lanzada cuando una entidad
toca
a otra. Habitualmente es la
entidad del estudiante/jugador la que provoca esta seal, aunque no es necesario. Se utiliza en aquellas entidades donde el contacto provoca la ejecucin de una accin. Por ejemplo, la forma de detectar que el jugador sobrepasa la frontera de un mapa es colocando una entidad no visible en ella; cuando sta detecta el contacto con el estudiante, ejecuta el cambio de mapa.
Use: la idea inicial es lanzarla cuando el estudiante utiliza

hablar
esa entidad,
por ejemplo, al activar un interruptor. Sin embargo, su semntica se puede extender y utilizar para diversos nes. Por ejemplo, se puede utilizar para a un personaje.
La seal puede ser lanzada no solo desde el usuario, sino tambin desde otras entidades. Por ejemplo, un interruptor puede lanzar la seal a la puerta, para que esta se abra; a su vez, la puerta puede tambin
usar
a
una entidad emisora de sonido, para que reproduzca el efecto de en el entorno; sta genera la seal para interactuar con los
las bisagras girando. Un ltimo ejemplo es la entidad que representa
Javy
objetos, de la misma forma que lo hara la entidad del jugador.
UseWith:
este tipo de seal s es especco de la mecnica de JV M 1
y otras aventuras grcas. La seal es enviada por el jugador cuando desea utilizar una entidad del entorno con otra que tiene en el inventario. As, en este tipo de juegos, el usuario puede utilizar una llave con una puerta, una esponja con una bisagra operandos (ver gura 6.3c).
21 o una caja con la pila de
20
Algunas de estas seales las detallbamos en la seccin 5.7; en aquel momento las lla-
mbamos
que otra entidad la toca, etc. En este apartado esa percepcin la convertimos en una entre entidades.
perceptores, ya que conceptualmente se puede entender que una entidad percibe seal
21
Como en Escape from Monkey Island.
188
Captulo 6.
Take: lanzada por la entidad del estudiante cuando quiere coger
el ob-
jeto para guardarlo en el inventario. No son muchas las entidades que responden a esta seal; nicamente lo hacen aquellos objetos interactivos que permiten almacenarse en el inventario, como la caja situada encima de la pila de operandos.
LookAt:
igual que en los dos casos anteriores, este tipo de accin es
especca de las aventuras grcas. En el caso de JV M 1, la seal, generada por la entidad del estudiante, se utiliza cuando ste realiza la accin de
mirar
al objeto del entorno. La accin que la entidad reali-
za suele ser escribir una pequea explicacin en la pantalla relativa al objeto al que representa. Por ejemplo, la gura 6.3b muestra la explicacin que aparece cuando el estudiante que se utiliza para crear y destruir
mira frames.
a Framauro, el personaje
En juegos con mecnicas ms complejas, no obstante, las seales de comunicacin son un mecanismo ms general que no puede reducirse a cinco mtodos. En esos casos, la informacin de una seal es almacenada en una estructura, construida por la entidad que lanza la seal. Para el envo, se utiliza un mtodo genrico que recibe como parmetro la informacin de esa seal, donde se analiza y se acta en consecuencia. La implementacin de este envo y recepcin de seales es similar al que describimos en la seccin siguiente, cuando hablamos de los componentes.
6.4.5.
Implementacin mediante componentes
Ya indicamos en el captulo anterior que este mdulo distingue entre tres tipos de entidades: las entidades genricas que no dependen del dominio, aquellas entidades relevantes para el contexto educativo, y la entidad que monitoriza el estudiante. En JV M, existen objetos de juego de los tres tipos: Entidades genricas: por ejemplo, en JV M 1 existen entidades que representan localizaciones para las distintas cmaras que pueden pin-
charse
durante el juego; en ambas versiones hay entidades para indicar
dnde empieza el jugador o el trnsito de qu zonas provocan el cambio de mapas; por ltimo, en JV M 2 hay entidades que permiten al jugador teletransportarse a otras localizaciones, y puertas que dan acceso a ascensores. Entidades especcas del dominio: en ambas versiones hay objetos que representan a la pila de operandos, valores concretos, objetos o clases. La mayora de estas entidades son
observadoras
de la vista lgica de
la JVM implementada en el mdulo descrito en la seccin 6.5, de tal forma que los cambios que suceden en ella se reejan en el entorno virtual.
189
CPuertoComunicacion CMsg +Acepta() +Pon() +Procesa() +ProcesaMensajesPendientes()
void CPuertoComunicacion::Pon(Msg *msg) { if (this->Acepta(msg)) _colaMensajes.add(msg); } void CPuertoComunicacion::ProcesaMensajesPendientes() { for each msg in _colaMensajes this->Procesa(msg); _colaMensajes.erase(); }
IComponent -_myOimObject +Tick() +Deactivate() +Activate() +Suspend() +Resume() +Init() * 1 OIMObject -_components +Tick() +SendMessage() +AddComponent() +RemoveComponent() void OIMObject::Tick() { for each component in _componentes component->Tick(); }
Figura 6.22: Diseo de clases involucradas en la implementacin mediante componentes
Entidad de monitorizacin del estudiante: la entidad responsable de la representacin del avatar en el entorno virtual es tambin responsable de esta monitorizacin, avisando a la vista lgica y en ltima instancia al subsistema de tutora sobre eventos signicativos, como el comienzo de una conversacin con
Javy.
La implementacin de todas estas entidades se realiza utilizando componentes. Cada entidad (OIMObject) est formada por una lista de componentes (IComponent) capaces de recibir mensajes y reaccionar ante ellos. Cuando dad (durante la carga de un mapa mediante el mtodo la gura de la pgina 170), el el motor de la aplicacin pide al mdulo la inicializacin de una nueva enti-
lanzador
InitEntity
visto en
de las entidades comprueba, a partir
de la clase de la entidad, qu componentes es necesario crear desde el mapa y guardados en la clase gura.
22 . La inicia-
lizacin de esos componentes se realiza de acuerdo con los datos cargados
CMapEntity que apareca en la misma
Las clases principales involucradas en la implementacin por componentes aparece en la gura 6.22. Aunque la parte ms importante es la clase
IComponent
empezaremos nuestra descripcin con la forma de enviar men-
sajes ya que, como hemos indicado anteriormente, el funcionamiento de los componentes se basa en ellos para la comunicacin. En el diseo de clases, existe una clase genrica,
CMsg, de la que heredan CUpdatePosition que
todos los tipos de mensaje. Cada una de las clases nuevas aade los atributos o datos asociados al mensaje; por ejemplo, la clase representa un mensaje enviado a los componentes para que actualicen la posicin de la entidad tiene como atributo la informacin de la nueva posicin.
22
Para averiguarlo, se utiliza un chero XML externo.
190
Captulo 6.
Para descubrir, dado un mensaje, a qu clase pertenece, existe un mecanismo parecido a RTTI que permite averiguar si un determinado mensaje es de una clase o no. Como mecanismo de comunicacin, cualquier clase que quiera ser capaz de recibir mensajes, debe heredar de la clase todo
CPuertoComunicacion. Su mPon implementa el envo diferido de mensajes, aadiendo el mensaje que ProcesaMensajesPendientes. Acepta, que indica si la mensaje concreto, y Procesa que
23 .
recibe como parmetro a una cola con todos los pendientes por procesar, que son analizados cuando se invoca al mtodo clase est interesada en recibir un tipo de Las clases derivadas deben sobreescribir el mtodo
recibe un mensaje como parmetro y acta en consecuencia
Los componentes, para poder ser receptores de los mensajes, heredan precisamente de esta clase mtodos La el
24 , de tal forma que cada uno implementa los
Acepta y Procesa de forma distinta. clase IComponent contiene adems otros

de la seccin anterior (como
mtodos importantes para o
la gestin de la entidad. En particular, todos los mtodos que aparecan en
OIMObject
Activate
Tick),
estn tambin
implementados en cada uno de los componentes. Cuando el objeto del juego es invocado lo redirige a todos sus componentes, para que acten consecuentemente. La clase
OIMObject es adems extendida con otros mtodos de gestin de
los componentes, como los habituales para aadir y eliminar componentes, as como mtodos que permiten enviar mensajes a todos ellos, y que son utilizados por los propios componentes cuando quieren indicar algn evento a sus hermanos. En la siguiente seccin mostramos algunos ejemplos de componentes utilizados en JV M, con sus mensajes respectivos. Posteriormente, mostramos algunos ejemplos de uso de estos componentes para conseguir el comportamiento de algunas entidades concretas.
6.4.6.
clase
Ejemplos de componentes
2
En JV M existen numerosos componentes, todos ellos heredando de la
IComponent, que son agrupados durante la ejecucin en los distintos OIMObject para crear el comportamiento completo de cada entidad del juego.
De forma general, podemos distinguir los siguientes tipos de componentes, dependiendo de su funcin: Componentes que dan acceso a distintos motores o proporcionan atri-
23
Dado que
Procesa
es un mtodo pblico, tambin sirve para enviar a un objeto un
mensaje que ser procesado mensajes.
inmediatamente,
en vez de esperar al anlisis de todos los
24
Esto provoca que, a pesar de lo que parece indicar el nombre
IComponent,
la clase
no
es un interfaz, sino una clase con algunos mtodos implementados.
191
butos a la entidad: aaden a la entidad a la que representan por ejemplo la posibilidad de dibujar un modelo o generar un sonido. Estos componentes manejan entidades de alguno de los motores de la aplicacin (grco, sonido, colisin) y alteran sus propiedades dependiendo de los mensajes recibidos. Tambin situamos aqu los componentes que aaden atributos concretos al objeto del juego. Estos componentes tienen una importancia vital, ya que en la seccin anterior vimos que los
OIMObject
son meros contenedores de componentes. Por lo tanto, si
queremos por ejemplo que nuestra entidad tenga una posicin o un nivel de salud, debemos aadirle sendos componentes que se responsabilicen de ellos.
Componentes que dan acceso a la vista lgica: ya sala alguno en la gura 5.4 de la pgina 136. Son aquellos que o bien reciben eventos de la vista lgica para actualizar la representacin visual, o bien la invocan para cambiar alguna de sus propiedades.
Gestin de la entrada: aade a un objeto la habilidad de procesar la entrada del usuario y reaccionar ante ella. El componente, adems de heredar de
IComponent
suele registrarse en el motor de la aplicacin
para recibir los eventos de la entrada, segn lo explicado en la seccin 6.3.2. Normalmente este tipo de componentes se asigna a la entidad que controla el avatar del jugador. Cuando detecta pulsaciones de tecla o movimientos del ratn, manda los mensajes de cambio de posicin correspondientes al resto de componentes.
Componente de inteligencia articial especcos: los distintos NPCs tienen distintas estrategias de comportamiento. Por ejemplo, el avatar que representa a
Javy
delega su comportamiento de alto nivel a la
vista lgica, por lo que el componente sirve de comunicacin entre ambos mdulos. El comportamiento de otros NPCs est implementado con mquinas de estado, utilizando un componente especco. Cuando se decide qu accin realizar, el componente de comportamiento enva mensajes al resto.
Componente de seguimiento de rutas: utilizado por los NPCs para ir de un sitio a otro. Cuando la inteligencia articial decide moverse a un punto en el mapa, enva un mensaje que es recogido por este componente, que durante una serie de fotogramas va moviendo a la entidad por el camino calculado de la implementacin de la
25 . Uno de estos componentes es el responsable
funcin latente moveTo
que apareca en la
seccin 2.7.3.3 cuando hablbamos de lenguajes de script.
25
Enviando los mensajes de cambio de posicin correspondientes.
192
Captulo 6.
CMsg
CSetPosition
CUpdatePosition
CSetAnimation
CTouched
CMuerto
CSetXRayMessage
(a) Jerarqua parcial de los mensajes entre componentes
IComponent
CSalud
CTransformable
CRutaGrafo
CGraphicComponent
CTouchedWithMouse +TouchWithMouse()
CPosCentroManada
CMiembroManada
CActorComponent
XRayMessage
2 (b) Jerarqua parcial de componentes en JV M 2
Figura 6.23: Jerarqua de clases de componentes y mensajes en JV M 2
Del primer tipo de componentes el ms signicativo es que aade al
CTransformable, OIMObject asociado un atributo que indica su posicin y orien-
tacin. Ambos datos son convenientemente inicializados con la informacin leda del mapa. Durante la ejecucin, si algn componente (por ejemplo el encargado de la IA) desea cambiar la posicin de la entidad, debe enviar un mensaje del tipo posicin, con
CSetPosition
para que ste componente la reciba. Ac-
to seguido, l informar al resto de componentes del cambio efectivo de la
CUpdatePosition.
Uno de los componentes que reaccionan ante este mensaje es el responsable del modelo grco de la entidad. Este componente, que ya apareca en la gura 5.4 de la pgina 136 bajo el nombre EntidadGraca, ha sido implementado por la clase
CGraphicComponent.
En su inicializacin, utili(ver gura 6.9). Ade-
za las propiedades del mapa para crear la entidad en el motor grco de la aplicacin, utilizando la clase
Graphics::CEntity
ms del mensaje para cambio de la posicin en el motor, el componente acepta un segundo tipo de mensaje para hacer visible o invisible la entidad grca, y un tercero para cambiar el modelo. El componente, adems, es especializado por otras clases que permiten controlar entidades ms complejas. Por ejemplo,
CActorComponent
aade la posibilidad de controlar entidades
animadas (como actores) que permiten adjuntar otros modelos (para coger armas). Para ello, el mtodo de inicializacin crea una entidad grca animada (Graphics::CAnimatedEntity), y es capaz de procesar mensajes de para el cambio de animacin y para aadir modelos a sus huesos.
193
En principio, ninguno de los componentes anteriores realiza ninguna accin especial en cada vuelta del bucle, a excepcin de comprobar su cola de mensajes para operar. Como un ejemplo de un componente que realiza alguna operacin ms es
CMiembroManada,
un componente que aparece en las
entidades que representan personajes de una manada. En su inicializacin, recibe la manada a la que pertenece (CManada en la gura 6.16) y el nmero de individuo al que representa. En cada actualizacin, pregunta al gestor de la manada en qu posicin debe aparecer el personaje y la actualiza, enviando un mensaje del tipo entidad. Por ltimo debemos poner un ejemplo de componente que, igual que
CUpdatePosition a todos los componentes de la
CGraphicComponent,
no hace nada en su actualizacin (Tick), pero es invo-
cado por otros mdulos distintos, mediante el interfaz correspondiente. Uno de estos componentes es
CVarGroupComponent.
observador
En este caso, en la actuali-
zacin no se realiza ninguna operacin especial y ni siquiera se procesan sus mensajes pendientes, ya que no reacciona ante ninguno de ellos. La nica utilidad de esta clase es hacer de de la vista lgica, de tal forma que cuando una variable local concreta de la mquina virtual cambia de valor, el componente es informado mediante la invocacin de un mtodo del comportamiento de la caja en el entorno virtual, como veremos en la siguiente seccin. La gura 6.23 muestra la jerarqua parcial de los mensajes y componentes de JV M. Algunos de ellos han sido explicados en esta seccin, mientras que otros aparecern en la seccin siguiente, cuando mostremos cmo funcionan tres entidades concretas de JV M 2.
26 . Cuando recibe la noticacin, enva un mensaje que provoca el cambio
6.4.7.
Ejemplos de entidades de juego

2
Una vez que hemos ejemplicado algunos de los componentes implementados en JV M, describiremos la forma en la que se conguran tres de los muchos objetos de juego que aparecen en JV M 2. En nuestra descripcin utilizaremos algunos de los componentes ya detallados, as como algn otro componente nuevo.
6.4.7.1. Caja que representa una variable local

En JV M los valores de la JVM se representan mediante cajas en el mundo virtual; esto es cierto tanto para los valores almacenados en la pila de operandos como para variables locales y atributos. Centrndonos en las variables locales en JV M 2, stas aparecen agrupa-
26
2 Hablaremos ms sobre la implementacin concreta de la mquina virtual en JV M en
la seccin 6.5.
194
Captulo 6.
cajaVariableLocal : OIMObject
: CGraphicsComponent
: CCollisionComponent
: XRayMessage
: CCajaVarGroupObserver
Figura 6.24: Componentes utilizados en las variables locales
das formando una pila de cajas, cada una de ellas simbolizando una variable local. El responsable de la pila de cajas es un objeto de juego (implementado tambin con su correspondiente coleccin de componentes) que recibe noticaciones de la JVM cuando se crean nuevas variables locales en el
me
actual. Cuando esto sucede, el propio objeto del juego
crea
fra-
otra entidad
nueva que representa la caja. Desde el punto de vista del usuario, cada una de ellas es un simple elemento esttico que no puede atravesarse y con una nica particularidad: cuando se activa la visin de rayos X y el visor se sita encima, aparece un texto que indica su contenido. Para conseguir este comportamiento, el objeto OIM que representa esta entidad dispone de los siguientes componentes (gura 6.24):
Componente grco: en este caso, el modelo es una caja en la que aparece el tipo de datos que oculta (I para enteros, F para reales, etc.). Componente de colisin: que aade la entidad de colisin al motor correspondiente, de tal forma que el usuario no pueda atravesar la caja. Adems, este componente es avisado por el motor de la aplicacin cuando el puntero del ratn colisiona con ella. En ese momento, enva un mensaje del tipo
CTouched al resto de los componentes de la entidad. CTouched, es procesaCTouchedWithMouse. Cuando lo recibe,
Componente para rayos X: el mensaje anterior, do por un componente llamado
comprueba que el contacto ha sido con el ratn (utilizando las propiedades del mensaje), y en ese momento, invoca a un mtodo de la propia clase que realiza una accin determinada. El mtodo, inicialmente vaco, es sobreescrito por el componente
XRayMessage,
cuya misin es
poner un mensaje de texto en el visor de Rayos X cuando se activa. El texto concreto que se escribe es congurable desde el exterior, utilizando un mensaje de tipo
CSetXRayMessage.
observadores
que son
Componente observador de las variables locales: como explicaremos en la seccin 6.5, la mquina virtual permite noticados ante cambios de estado de la JVM. En concreto, permite
195
el registro de clases para ser avisadas ante cambios en los valores de las variables locales de un
frame.
Para que la entidad que representa que cuando
una caja sea capaz de cambiar su comportamiento ante estos cambios, se congura con el componente
CCajaVarGroupObserver
recibe noticacin de algn cambio hace dos cosas: enva un mensaje de cambio del mensaje de rayos X, para que el texto que aparezca reeje el nuevo contenido, y, en algunas ocasiones, enva un mensaje de
cambio de modelo,
cuando la variable ha cambiado el
tipo 27 .
Lo interesante de este ejemplo no es nicamente reejar cmo se utilizan los distintos componentes para forma la entidad, sino ver la posibilidad de variacin. Como ya hemos dicho, las cajas son ampliamente utilizadas en JV M. En particular, tambin se muestran cajas para reejar el estado de la pila de operandos del
frame, como puede verse en la gura 6.4b. Cada una de no

cambia durante todo su ciclo
estas cajas tiene el mismo comportamiento que las de las variables locales, con la nica diferencia de que su estado de vida. Por lo tanto, su conguracin de componentes es exactamente la misma que la citada anteriormente, pero sin el componente observador. Por su parte, las cajas que representan atributos de instancia o de clase tienen una conguracin similar, pero el componente observador recibe noticaciones de cambios de valores en el atributo, en vez de en la variable local.
6.4.7.2. Inteligencia articial de las manadas

En la seccin 6.4.2 veamos que para que aparezca una manada en el entorno virtual, el diseador tena que aadir al mapa varias entidades de distintos tipos (waypoint, uso de las clases manadas. En esta seccin describimos otro punto importante de las manadas, que ya sala en la gura 6.20: el objeto del juego que se crea cuando se carga el mapa. En particular, veremos cmo se realiza su implementacin utilizando componentes. La funcin de este objeto de juego es doble:
waypointGraph y manada, todas ellas pueden verse

y
en el cdigo de la gura 6.19). Tambin veamos que para su control, se hace
CGestorManadas
CManada,
ambas dentro del gestor de
Ser el responsable de la inteligencia articial de la manada: entendemos por inteligencia articial la que establece las reglas de comportamiento que rigen a sus individuos (ver gura 6.16) y la que se encarga
27
El cambio de modelo es necesario para que se cambie la apariencia de la caja y muestre
el tipo correctamente. Por su parte, una variable local en la JVM puede cambiar de tipo cuando el ujo de ejecucin sale fuera del mbito de esa variable, y entra dentro del mbito de otra; la mquina virtual aprovecha el espacio fsico de la primera para la segunda.
196
Captulo 6.
iaManada1 : OIMObject
: CConfigManadaRecursos
: CRutaGrafo
: CPosCentroManada
Figura 6.25: Componentes utilizados en la IA de las manadas
de
mover la manada completa,
haciendo que su centro siga la ruta del
grafo con el que se ha congurado. Es el responsable de la creacin de los individuos iniciales de la manada. Como dijimos en la seccin 6.4.3, en JV M 2 el nmero de individuos depende
del ejercicio actual, ya que debe existir al menos un individuo
por cada recurso que se necesita para compilar el mtodo particular. Para poder realizar estas dos funciones, el objeto del juego de la manada consta de los siguientes componentes (gura 6.25): Un componente que hace que la posicin del centro de la manada est actualizada con la posicin de la entidad: para eso, hemos creado un nuevo componente, Cuando se recibe un mensaje del tipo
CPosCentroManada que hereda de CTransformable. CSetPosition, adems de rea-
lizar las operaciones habituales, se avisa al gestor de la manada, para que cambie su centro. Ese centro afectar posteriormente al comportamiento de los individuos, gracias a la existencia de una regla que intenta mantenerlos cerca de l
28 .
Un componente que sigue la ruta de un grafo: en este caso el componente recibe en su inicializacin el nombre del grafo y consigue su descripcin preguntando al mdulo correspondiente. Cuando el componente se activa hace que la posicin de la entidad cambie, recorriendo las aristas del grafo. Por lo tanto, en cada vuelta del bucle emite el mensaje
CSetPosition
a todos sus componentes hermanos para que de la idea de manada, y por lo tanto puede
acten en consecuencia. Cabe destacar que este componente es completamente
independiente
utilizarse para controlar la posicin de cualquier entidad, por ejemplo de un soldado patrullando. Un componente que congura la manada: al crearse la entidad para la IA de la manada, el propio objeto del juego
debe
registrar la manada
28
Existe otra posibilidad de diseo distinta, que consiste en crear un componente inde-
pendiente de
CTransformable que, al recibir el mensaje CUpdatePosition cambie el centro
de la manada; ambas opciones son vlidas.
197
en el gestor. Para eso, se crea el componente lleve a cabo. Sus funciones son varias:
CConfigManadaRecursos
que es destruido inmediatamente despus de que la inicializacin se
Crear la manada inicial en el gestor de manadas: de acuerdo a las propiedades establecidas en el propio mapa por el diseador, crea la manada congurando las reglas que se utilizarn.
Crear los individuos iniciales: es decir, el componente es el que implementa la conguracin del entorno en base al ejercicio descrita en el apartado 6.4.3.En su inicializacin, comprueba el mtodo en ejecucin en el
frame
activo y, en base a los recursos que se
necesitan para su ejecucin, crea los individuos de la manada que los llevan. La creacin de los individuos se hace por partida doble: por un lado en el gestor de manadas se indica el nmero de individuos que hay que controlar, y por otro lado, se crean los objetos del juego que representan a cada uno de ellos. Los componentes con los que se conguran estos objetos del juego son tratados posteriormente.
Activar el componente de seguimiento de ruta mediante un grafo: es decir, enviar el correspondiente mensaje para que la posicin de la entidad siga ese grafo. La
activacin explcita
del componente
permite que otras entidades (como el NPC patrullando que nombrbamos antes) dispongan del mismo componente de seguimiento de aristas del grafo, que desactivan momentneamente para realizar otra tarea distinta. A la vista de esta lista de componentes, es interesante advertir que este objeto de juego
no
contiene un componente de representacin grca ni de
colisin, al contrario de los ejemplos nombrados hasta ahora.
6.4.7.3. Individuo de la manada

Cada uno de los individuos de la manada (que pueden verse en la gura 6.17) son modelos animados (actores) cuya posicin viene determinada externamente por el controlador de la manada (CManada). Cada uno de los individuos oculta un recurso necesario para la ejecucin del mtodo del
zarlos
frame
en el que se encuentra. Adems, el jugador puede
ca-
utilizando su arma. Cuando el individuo muere, el objeto que ocultaba
pasa al inventario del jugador. Los componentes con los que est congurado el
OIMObject
responsable
de cada una de estas entidades son los siguientes (gura 6.26): Componente grco: en este caso, como es un avatar con animaciones, se utiliza un nes.
CActorComponent, ya que permite controlar las animacio-
198
Captulo 6.
invididuo1Manada1 : OIMObject
: CActorComponent
: CCollisionComponent
: CSalud
: CMiembroManada
: CRecursoOculto
Figura 6.26: Componentes utilizados en los individuos de las manadas
Componente de colisin: que instala una malla de colisin en el motor de colisiones, de tal forma que el estudiante no pueda
atravesar
al
personaje. Tambin se utiliza para que se detecten las colisiones con el disparo, de tal forma que se sepa cundo el avatar est siendo
cazado.
Componente de nivel de vida: aporta un nuevo atributo a la entidad que es la
salud
o nivel de vida que tiene. Cuando recibe un mensaje
de noticacin de colisin con el disparo, el nivel baja, hasta que llega a cero. En ese momento, el componente enva un mensaje del tipo
CMuerto.
Componente de pertenencia a una manada: el avatar que aparece en el entorno
no
es el responsable de decidir en su posicin y direccin, sino
que sto viene determinado por las propiedades de la manada (clase
CManada).
Debido a esto, el componente que ja la
posicin) de la entidad
pregunta
transformacin
(o
en cada vuelta del bucle a su manada
correspondiente en qu posicin debe aparecer el individuo. El componente lo hemos implementado en la clase de
CTransformable.
29 .
CMiembroManada
que hereda para que
En cada actualizacin, comprueba la nueva po-
sicin y la enva con el mensaje del tipo actualicen
CUpdatePosition
el resto de componentes (en particular el grco y el de colisin) se
Una segunda funcin de este componente es detectar cundo el personaje ha muerto (mensaje
CMuerto). Cuando sto ocurre, se lo comunica
a la manada para que sea eliminando de sta. Componente que gestiona el recurso oculto: hemos dicho que cada individuo oculta un recurso necesario para la ejecucin del
frame
actual.
Para eso, existe un componente que, ante un mensaje indicando que el personaje ha muerto, mete ese recurso en el inventario del jugador.
29
Igual que en el caso de la inteligencia articial de las manadas vista anteriormente,
el diseo de clases podra haberse hecho de tal forma que diente de mensaje
CMiembroManada fuera indepenCTransformable, de tal forma que el primero en cada vuelta del bucle enva un CSetPosition, que es traducido por el segundo a otro de CUpdatePosition.
6.5. Vista lgica
199
Todos estos componentes son congurados en el momento de creacin de la inteligencia articial de la manada. En particular, son preestablecidos por la manada los siguientes valores: modelo del avatar (para todos los individuos el mismo modelo, que viene como informacin en el mapa del nivel), recurso que oculta (extrado de la informacin del mtodo activo), nivel de salud (constante establecida en el mapa) y manada y nmero de individuo por el que preguntar la posicin a la clase
CManada.
6.5. Vista lgica

Recordemos, segn lo visto en la seccin 5.5 que en este mdulo se almacena el estado del mundo a un nivel de abstraccin lo sucientemente alto como para poder aplicar las tcnicas de razonamiento adecuadas. Tambin aqu situamos el comportamiento inteligente de los objetos del entorno ms importantes desde el punto de vista del sistema educativo, as como la monitorizacin del estudiante. En el caso de JV M, en la vista lgica es donde se encuentra la implementacin de la mquina virtual de Java simplicada de acuerdo a lo indicado en la seccin 6.2.3. En cuanto a las otras dos funciones (comportamiento inteligente del algn objeto y monitorizacin del estudiante), tanto en JV M 1 como en JV M 2 consisten prcticamente en meros ma de tutora. Con respecto al comportamiento inteligente de objetos del entorno importantes, nicamente en JV M 1 existe un objeto del entorno importante y relevante desde el punto de vista del sistema educativo: el agente pedaggico. En la vista lgica se sitan lo que llamamos mdulo de percepcin y mdulo de movimiento. La primera de ellas recibe los eventos de alto nivel que ocurren en el entorno (el usuario quiere hablarnos, por ejemplo), y lo redirige al mdulo cognitivo del agente situado en el subsistema de tutora. El mdulo de movimiento hace lo propio. Cuando recibe las rdenes a realizar por el agente, las divide en acciones primitivas en el entorno virtual, y las manda al avatar (entidad) en la capa inferior. En particular, algunas de las rdenes pueden ser directamente las ejecutar en la mquina virtual; el mdulo de movimiento
puentes
desde el mdulo OIM al subsiste-
microinstrucciones que hay que traduce esas micro-
instrucciones en operaciones sobre el entorno (usar X con Y), y las enva. La monitorizacin del estudiante por su parte recibe las acciones que ste realiza sobre el entorno (en concreto, sobre los objetos que representan estructuras de la mquina virtual), e informa de ellos al subsistema de tutora. ste actualiza el progreso del ejercicio y toma las decisiones que estima oportunas. En cuanto a la implementacin de la mquina virtual, sta cubre sus
200
Captulo 6.
CHeap -_heap 1 JVM -_classes 1 1 1 1 CLoadedClassTable 1
-_objects
CJavaObject
* 1 1 1 CJavaClass 1 1 * 1 1 1 1 1 * CFieldTable CField -type
CMethodTable 1
rren -_cu od tMeth *
CMethod -signature
* -_frameStack 1 CFrameStack 1 -_frames CFrame 1 * 1 1 1 -_localVars CVarGroup 1 CJVMInstr * -_instrs COperandStack 1
Figura 6.27: Diseo de clases de la implementacin de la JVM en JV M
estructuras bsicas. Dispone de una lista de clases cargadas, una lista de objetos creados y una pila de
frames.
Las clases tienen una lista de mtodos
(con sus instrucciones mquina asociadas), y una tabla con todos los campos de la clase (tanto estticos o de clase, de los que se almacena tambin su valor, como de instancia, de los que nicamente se almacena su nombre y tipo). Los objetos contienen una referencia a la clase a la que pertenecen, y una tabla de sus campos con los valores. Los
frames
contienen una referencia al
mtodo que estn ejecutando, as como una pila de operandos y un conjunto de variables locales. El diseo de clases utilizado en JV M aparece en la gura 6.27. La implementacin incluye un cargador de clases especial, que interpreta el chero que contiene el ejercicio que debe resolver el usuario. En ese chero aparecen todas las clases necesarias, con las que el cargador inicializa la mquina virtual. Lo ms relevante, no obstante, de la implementacin es que gran parte de las clases que representan estructuras de la JVM permiten
observadores,
de tal forma que elementos externos a la propia implementacin pueden ser informados sobre cambios en su estructura interna. As, por ejemplo la pila de operandos (cuya implementacin aparece en la seccin C.3.1) informa cuando se apila o desapila algn valor, los campos avisan cuando sus valores se alteran, el heap emite un mensaje cuando algn objeto es creado, y las variables locales informan cuando se crean nuevas o cambian los valores de las antiguas. De esta forma, los objetos del juego o entidades del mdulo OIM (seccin 6.4) son avisadas cuando ocurre alguno de estos cambios para que alteren la representacin de esa estructura particular en el entorno virtual. La ta-
6.5. Vista lgica
201
Clase
CHeap CLoadedClassTable CFrameStack COperandStack CVarGroup CField
Descripcin Informa de la creacin de nuevos objetos. Informa ante la carga de nuevas clases. Informa ante la creacin o destruccin de un nuevo frame. Informa cuando en la pila de operandos se apila o desapila un nuevo valor. Informa cuando algn valor en el grupo de variables locales es alterado. Informa cuando un campo (de clase o de objeto) es modicado externamente.
Tabla 6.2: Clases de la JVM que permiten observadores
bla 6.2 resume cules de las clases de la gura 6.27 notican sus cambios de estado a terceros.
6.5.1.
Ejecucin de instrucciones de la JVM en JV2 M 1

2
La metfora de JV M 1 exige que el estudiante En este sentido, exista el concepto de aquellos
ejecute
por l mismo las que son todos
instrucciones de la mquina virtual, manipulando los objetos del entorno.
pasos atmicos
microinstrucciones,
que los avatares pueden realizar sobre l.
Por tanto, el estudiante debe manipular cajas (datos) y hablar con personajes para que se ejecuten cada una de las microinstrucciones en la mquina virtual, encaminadas a la ejecucin completa de una instruccin mquina. Algunas instrucciones se componen nicamente de una microinstruccin (por ejemplo, apilar un valor constante), mientras que otras pueden involucrar numerosas instrucciones (por ejemplo, la invocacin a un mtodo). Independientemente del nmero de pasos, lo que debe quedar claro es que es
el propio estudiante
(o en su defecto el agente pedaggico) quien
ejecuta
las instrucciones mquina. Por lo tanto, en la prctica, la implementacin de la mquina virtual en JV M 1
no
requiere la capacidad de ejecucin de
las instrucciones, ya que eso se hace desde fuera. Exige, eso s, que ciertos mtodos que en condiciones normales no seran accesibles sean pblicos. Esto es necesario para que desde fuera de la implementacin sea posible ejecutar una a una esas microinstrucciones, accediendo a sus estructuras internas.
6.5.2.
Ejecucin de instrucciones de la JVM en JV2 M 2

2
En el diseo de JV M 2, liberamos al estudiante de la ejecucin de cada uno de los pasos primitivos o atmicos. En vez de hacer eso, simplemente debe
teclear
en el terminal del entorno el mnemnico de la instruccin mquina
que desea ejecutar (ver gura 6.4a).
202
Captulo 6.
Debido a esto, ya no es el estudiante (o el agente pedaggico) el que debe conocer qu estructuras deben alterarse en la JVM para implementar cada una de esas instrucciones, sino que ese conocimiento debe estar codicado en este mdulo, la
vista lgica.
2
de la mquina virtual (JVMExecutor), dentro de la vista lgica. En particular, seccin 5.5
Por lo tanto, en JV M 2, se ha creado un ejecutor de las instrucciones
dentro de los tres tipos de responsabilidades de este mdulo indicados en la
30 , la ejecucin de las instrucciones recae en la inteligencia articial
o comportamiento de alto nivel de la entidad que representa al terminal en el entorno virtual. Cuando el terminal detecta que est siendo utilizado por el estudiante, lo que ste escribe es redirigido a la vista lgica para su procesado.

El funcionamiento interno del subsistema de tutora de JV M no forma parte de este trabajo, sino que es ampliamente descrito por Gmez Martn (2007). En esta seccin aparece una breve descripcin, que trata nicamente los aspectos relevantes desde el punto de vista arquitectnico.
6.6.1.
Inicializacin
Cuando la aplicacin se lanza, el subsistema recibe momentneamente el control para que pueda ejecutar sus funciones de inicializacin (igual que ocurre con el resto de mdulos). En ese momento el subsistema carga cheros externos que contienen el conocimiento dependiente del dominio pero independiente del estudiante particular que utilizar el sistema. Tambin es en ese momento cuando se inicializan los gestores de los ejercicios y de los perles de usuario que aparecan en la gura 5.2. En ambas versiones de JV M se carga en este momento una ontologa sobre los conceptos que se deben ensear, que incluye tanto las estructuras de la JVM como los conceptos de compilacin del lenguaje Java (gura 4.9). Por su parte, el gestor de ejercicios comprueba cuntos hay disponibles para poder despus seleccionarlos en base a las estrategias pedaggicas. Adems de esa informacin, cada una de las dos versiones de JV M necesitan informacin especca:
JV2 M 1: debido a la existencia de Javy, el agente pedaggico, y al modo de ejecucin de las instrucciones el subsistema de tutora de JV M 1 necesita un tipo de conocimiento concreto no necesario en la versin posterior. En particular
Javy
necesita conocer las microinstrucciones
30
Recordemos que eran (i) simulacin, (ii) inteligencia articial de alto nivel y (iii)
monitorizacin del estudiante.
203
necesarias para ejecutar cada una de las instrucciones mquina. Tambin se cargan las explicaciones que el agente proporciona cuando se mantiene una conversacin con l.
JV2 M 2: en este caso, la ejecucin de las instrucciones mquina no son

desglosadas en varias etapas, por lo que no es necesario un conocimiento tan concreto. Sin embargo, en esta versin se ha incluido una ayuda sintctica y semntica que permite a los jugadores lanzar preguntas en lenguaje natural. Para la implementacin de esta ayuda, se ha utilizado jCOLIBRI (Recio-Garca et al., 2005) un framework implementado en Java para la creacin de sistemas CBR (Case-based
reasoning,
Razo-
namiento basado en casos); en particular, se ha utilizado la extensin para CBR textual (Recio, Daz Agudo, Gmez Martn y Wiratunga, 2005). Dado que jCOLIBRI est implementado en Java, el subsistema de tutora en su inicializacin
lanza
la mquina virtual de Java
31 . Para
evitar alargar la inicializacin completa de la aplicacin, se utiliza una hebra secundaria que se lanza en el momento de la inicializacin, de forma que la aplicacin puede empezar a ejecutarse (presentando el men de opciones, por ejemplo) antes de terminar la lectura completa de todas las ontologas de trminos e indexado de textos necesarios. Los detalles exactos de implementacin aparecen en el apndice B. La inicializacin, no obstante, no est completa hasta que el usuario no se identica en el sistema. Al arrancar la aplicacin, sta presenta un men al jugador que le permite crear un nuevo perl, o seleccionar uno ya existente (ver gura 6.1). Ese perl se redirige hacia el subsistema de tutora utilizando la monitorizacin del estudiante de la vista lgica. El subsistema de tutora avisa al gestor de perles de la seleccin, para que cargue el perl concreto. Ese perl ser posteriormente utilizado para seleccionar el siguiente ejercicio a presentar al usuario.
6.6.2.
Ejercicios
Cuando el usuario establece el perl, el subsistema de tutora decide qu conceptos debe poner en prctica el estudiante en el siguiente ejercicio utilizando la estrategia pedaggica que considere oportuna. Con esos conceptos, formula una consulta al gestor de ejercicios, que recupera el ms parecido de su base de ejercicios. La seleccin del ejercicio ser la que posteriormente determine el aspecto nal que tendr el entorno virtual en el que el usuario se ve inmerso. Esto es as gracias a la metodologa de creacin de contenidos que describamos en el captulo 4.
31
No confundir esta JVM con la implementada en la vista lgica del sistema. La JVM
a la que nos referimos aqu es la implementada por Sun, que puede utilizarse desde una aplicacin en C++.
204
Captulo 6.
2
En JV M, los ejercicios estn almacenados en cheros XML, que contienen tanto el cdigo Java como el cdigo compilado para la mquina virtual. Aunque escapa al mbito de este trabajo, indicar que esos ejercicios tambin tienen explicaciones y referencias a otras ontologas externas sobre el dominio, que son aprovechadas por el mdulo pedaggico y mdulo experto. El proceso de inicializacin comienza cuando el subsistema de tutora selecciona el siguiente ejercicio. En ese momento, inicializa la vista lgica del sistema de acuerdo a l. En nuestro caso, esta inicializacin consiste, precisamente, en hacer que el cargador de clases de la JVM implementada en la vista lgica
cargue
las clases que se necesitan en el ejercicio. Una vez
cargadas, el subsistema tambin
establece
el estado inicial de la mquina
virtual. As, si el ejercicio comienza la ejecucin en la funcin determinada clase, el subsistema tambin crea el ejecucin de ste hasta que se llega a ese punto.
frame
main
de una
para la ejecucin de
ese mtodo. Si el ejercicio comienza en otro punto del programa, lanza la
Una vez congurado, el motor de la aplicacin comienza la carga de un mapa (entorno virtual), al principio de la partida. En ese momento,
avisa
la gestin de entidades del comienzo inminente en la carga de un mapa, y procede a la creacin de los objetos del juego. stos basarn su inicializacin en el estado de la misma, como ya hemos descrito en la seccin 6.4.3.
6.6.3.
Ejecucin durante la partida
Durante el juego el subsistema de tutora tambin debe ejecutarse cada cierto tiempo para mantener actualizada toda su informacin y tomar las decisiones que considere oportunas en base a los acontecimiento que suceden en el entorno virtual. Esta ejecucin en JV M se realiza de dos formas distintas: En algunos momentos, la vista lgica ejemplos de invocaciones directas:
invoca
al subsistema de tutora,
avisndole de los eventos relevantes. En la gura 6.28 aparecen tres
El simulador o implementacin de la mquina virtual informa al sistema experto de la ejecucin de una instruccin o microinstruccin. El sistema experto entonces es capaz de comprobar si el estudiante est actuando correcta o incorrectamente.
El avatar de
Javy
que representa al agente pedaggico en el en-
torno virtual (en JV M 1), informa al subsistema de tutora que el estudiante desea establecer una conversacin con l.
El encargado de la monitorizacin del estudiante indica que ste lleva inactivo demasiado tiempo, o que se ha seleccionado un perl nuevo (invocado cuando la aplicacin est en el men).
6.7. Generacin de contenidos
205
Mdulo experto Mdulo pedaggico
Subsistema tutora Modelo del estudiante
...
...
Vista lgica del mundo Instruccin ejecutada.. JVM
Inicio conversacin... Agente pedagogico
Usuario inactivo Cambio perfil... Monitorizacin estudiante
Figura 6.28: Ejemplos de invocaciones de la vista lgica al subsistema de tutora
El subsistema de tutora para no depender de la vista lgica en cuanto al control de ejecucin tambin dispone de una hebra independiente. Cuando el subsistema es inicializado, ste lanza una nueva hebra de larga duracin que ser la responsable de las decisiones del subsistema cuyo tiempo de respuesta sea largo. As, los mdulos del subsistema involucrados pueden ejecutarse concurrentemente al resto de la aplicacin, sin bloquear sta. En JV M, la hebra se encarga de las decisiones de alto nivel del comportamiento del agente pedaggico entre otras cosas.

La arquitectura para el desarrollo de aplicaciones educativas presentada en el captulo 5 es una arquitectura
dirigida por datos.
Recordemos de la
seccin 2.4 que este tipo de organizacin elimina la mayora de los datos utilizados por la aplicacin del chero ejecutable, para almacenarlos en cheros externos. La metodologa para la creacin de contenidos dirigidos por datos que veamos en el captulo 4 se basaba en la clara divisin en dos partes de esos datos: por una lado aquellos relacionados con el conocimiento especco del dominio, y por otro lado la generacin de los niveles o del entorno virtual. En los dos apartados siguientes describimos cmo se ha realizado la crea-
206
Captulo 6.
(a) Herramienta de edicin de ejercicios 2 para JV M
(b) Herramienta de edicin de ontologas 2 para JV M
Figura 6.29: Capturas de dos herramientas de generacin de conocimiento del dominio en JV M
cin de ambos contenidos en JV M.
6.7.1.
Generacin del conocimiento del dominio
Este conocimiento es especco del dominio que se est enseando y de la forma en la que funciona el subsistema de tutora. Cuando describamos el mdulo utilizado en JV M en la seccin 6.6, indicbamos que su funcionamiento interno no pertenecen a este trabajo, sino que son descritos por Gmez Martn (2007). De forma similar, las caractersticas exactas de los datos que se precisan para expresar el conocimiento enseado en JV M, tambin pertenece a ese trabajo. Desde el punto de vista arquitectnico, lo nico importante es que todos esos datos se almacenan en cheros externos al propio ejecutable, lo que permite la reutilizacin de parte del mdulo. Para la generacin de todo ese conocimiento, se desarrollaron diversas herramientas, que permiten la creacin tanto de los ejercicios Java (gura 6.29a) como de las ontologas que el subsistema de tutora utiliza (gura 6.29b).
6.7.2.
Generacin del entorno de aprendizaje
El entorno virtual en el que suceden los episodios de aprendizaje est formado principalmente por dos tipos de cheros de datos: (i) los modelos animados de los personajes y dems entidades y (ii) los mapas que contienen la informacin de las entidades y el modelo de las estructuras estticas del entorno. Dejando de un lado los modelos que utilizamos en la versin preliminar de JV M con WildMagic (gura 6.6), el resto de modelos de JV M han sido creados utilizando Alias|Wavefront Maya, un software para modelado 3D que
207
ha sido utilizado en la creacin de numerosas pelculas y juegos. Para poder cargar los modelos generados en Maya en el motor grco utilizado, hemos hecho uso de sendos plug-ins:
JV2 M 1: recordemos que esta versin utiliza Nebula 1 y modelos con

el formato de Half-Life. En este caso, realizamos una modicacin un plug-in desarrollado por Reality Factory que carga el motor grco.
33 que permite grabar a un
32 de
tipo de archivo especial que nalmente se utiliza para crear el chero
JV2 M 2: en este caso, Nebula 2 dispone de un plug-in comercial para

Maya que permite exportar directamente los modelos a los cheros nativos del motor (ver gura 6.8). La existencia de estos plug-in mejora la independencia entre el motor grco utilizado por la aplicacin y la herramienta de generacin de los contenidos. Para ambas versiones se utiliz la misma herramienta de modelado, pero utilizando distintos exportadores. Por tanto, si se desea cambiar el motor grco conservando los modelos, nicamente se requiere la existencia de exportadores en Maya para l. Si el nuevo exportador no impone restricciones excesivas en las caractersticas del modelo (como conguracin del esqueleto o propiedades de las texturas) los modelos creados en el programa de modelado podrn ser exportados al nuevo motor fcilmente. De hecho, aunque estamos diciendo continuamente que JV M 1 utiliza Nebula 1, podemos decir que tambin existi temporalmente una versin con Nebula 2 como motor grco que presentaba los modelos de JV M 1 exportados para Nebula 2. Por su parte, el formato de los cheros de mapa es impuesto por el motor de la aplicacin
34 . Por ejemplo, el motor del juego de Far Cry exige
mapas creados con su editor SandBox (Crytek, 2004), el motor de Unreal Tournament (Epic Games, 1999) utiliza los mapas generados con UnrealEd, mientras que la saga de Half-Life (Valve Software, 1998) es capaz de interpretar mapas creados con Worldcraft o Hammer. Esto hace que la sustitucin de un motor de aplicacin por otro suponga no solo cambios en el cdigo sino la regeneracin completa del entorno de aprendizaje, debido a que los formatos de los editores son incompatibles entre s. En nuestro caso, la implementacin del motor de la aplicacin es propia, por lo que el formato en el que leemos los mapas no viene impuesto desde
32 33 34
Disponible en
http://gaia.fdi.ucm.es/grupo/projects/javy/devzone.html http://www.realityfactory.info
Esto es especialmente cierto si el cdigo fuente del motor no est disponible; si ste
es abierto, se podr incluir soporte para otros formatos, aunque en algunos casos el motor grco puede imponer unas limitaciones que hagan imposible el uso de algunos de ellos.
208
Captulo 6.
2 (a) Boceto del mapa principal de JV M 2
(b) Captura del editor GV Map Editor 2 usado en JV M 2
(c) Captura de Worldcraft utilizado en 2 JV M 2
Figura 6.30: Generacin de mapas en JV M
fuera. Ya explicamos en la seccin 6.3.3 que el cargador de los mapas es lo sucientemente general como para poder soportar distintos formatos de forma transparente al resto de la aplicacin. A pesar de esta versatilidad en cuanto a la poca imposicin en los formatos de los mapas, la creacin de los mapas de JV M ha sido realizada intentando minimizar el impacto que tendra la sustitucin de nuestro motor de la aplicacin por otro distinto. En particular, el proceso de creacin de los mapas en JV M 2 ha utilizado dos editores distintos. El primero de ellos es independiente del formato nal de los mapas, y permite realizar la versin inicial. Mediante un conversor, entonces, se graba en un formato directamente interpretable por un segundo editor con el que se generar el mapa. Ese segundo editor es utilizado para renar el mapa y darle el aspecto nal. El chero generado ser por ltimo interpretado por el motor de la aplicacin. De esta forma, si el motor de juego actual es sustituido por otro, la versin inicial del mapa puede ser reutilizada.
Resumen
209
Con este planteamiento, las etapas por las que se ha pasado para la creacin de los entornos en JV M 2 son las siguientes:
Diseo sobre papel del mapa: este boceto aparece en el documento de diseo del juego (gura 6.30a). Contiene una idea del mapa y de la colocacin de las entidades ms importantes.
Creacin de la versin inicial del mapa: utilizando el boceto, se genera una primera versin del mapa. Dado que JV M 2 se desarrolla en interiores, utilizamos un editor basado en cuadrcula llamado GV Map Editor
35 (ver gura 6.30b), que facilita la creacin de los muros y de-
ms componentes arquitectnicos. El editor tambin permite colocar las entidades fundamentales del nivel.
Conversin a formato especco: en este caso, el propio editor permita grabar directamente en el formato soportado por el segundo editor.
Creacin de la versin denitiva del mapa: utilizando en este caso Worldcraft (gura 6.30c), que nalmente graba los cheros en el formato
bsp
utilizado. De esta forma, JV M permitira de forma fcil
remplazar el motor de la aplicacin por el utilizado en Half-Life, que soporta estos mapas de manera nativa.
Resumen
En este captulo hemos descrito la implementacin de la aplicacin ms importante desarrollada con la metodologa y arquitectura descritas en los captulos 4 y 5 respectivamente. En particular, el captulo comenzaba con una breve descripcin de JV M 1
2 y JV M 2, las dos versiones de una aplicacin para el aprendizaje de las estructuras de la mquina virtual de Java y la forma en la que un programa escrito en Java es compilado a cdigo mquina de la misma. Posteriormente, se ha hecho un repaso a cada uno de los mdulos de la arquitectura que describamos de forma general en el captulo 5, detallando la implementacin concreta utilizada. Finalmente, se ha descrito la forma en la que hemos generado los contenidos utilizados en JV M, utilizando la metodologa de creacin de contenidos descrita tambin de forma general en el captulo 4.
35
Este editor fue desarrollado por los alumnos del Mster de Videojuegos de la Univer-
sidad Complutense de Madrid durante el curso 2005-2006.
210
Captulo 6.
Notas bibliogrcas
La metfora utilizada en JV M 1 que veamos en la seccin 6.2.1 ha sido descrita en Gmez Martn, Gmez Martn y Gonzlez Calero (2005d) y Gmez Martn, Gmez Martn y Gonzlez Calero (2006a). Por su parte, JV M 2 es descrito en Gmez Martn, Gmez Martn, Palmier Campos y Gonzlez Calero (2006c). Por ltimo, una comparativa entre ambas versiones, que destaca la importancia de una buena seleccin de metforas durante la fase de diseo es Gmez Martn, Gmez Martn, Gonzlez Calero y Palmier Campos (2007d). Con respecto a la arquitectura, ha sido descrita, aunque no de forma tan exhaustiva como en este captulo, en Gmez Martn, Gmez Martn y Gonzlez Calero (2007a) y Gmez Martn, Gmez Martn y Gonzlez Calero (2007b). Una variacin de la arquitectura es descrita en Peinado Gil, Gmez Martn y Gmez Martn (2005), aunque en este caso su uso no es para la creacin de videojuegos educativos, sino para la implementacin de programas de entretenimiento con una fuerte componente narrativa. Por ltimo, la descripcin completa de la forma en la que est implementado el subsistema de tutora de JV M forma parte del trabajo de Gmez Martn (2007).
Captulo 7
Conclusiones y trabajo futuro

Quien crea que llegu al puerto denitivo es que no comprende el espritu del verdadero homo viator.
Pedro Jess Fernndez, Pen de Rey
A lo largo de los captulos de esta memoria hemos descrito una arquitectura y metodologa para el desarrollo de aplicaciones educativas basadas en videojuegos. En este ltimo captulo pasamos a describir las que consideramos aportaciones ms importantes de este trabajo, as como las posibles lneas de continuacin y trabajo futuro.
7.1. Conclusiones
El trabajo aqu presentado se enmarca dentro de las aplicaciones educativas. Dentro de este amplio campo encontramos tanto aquellas aplicaciones de enseanza tradicionales, basadas en la mera presentacin de contenido multimedia, como los sistemas educativos basados en videojuegos donde el usuario-estudiante
juega
un papel activo dentro de su propio aprendizaje que
se adorna con contenidos ldicos que incrementan la motivacin. El primer tipo de aplicaciones, ms sencillo, se ha utilizado ampliamente durante las ltimas dcadas. El orecimiento de estos sistemas ha sido posible gracias a su simplicidad. En la mayora de los casos, la interaccin entre el usuario y el programa est limitada a unos pocos mecanismos, igual que lo est la forma en la que la aplicacin puede presentar los contenidos. Gracias a esta acotacin de las posibilidades, durante el proceso de autora se dispone de un conjunto de operaciones establecidas de los que no se puede salir. De esta forma, ha sido posible la construccin de aprendizaje) es mostrado por un
editores
de generacin de
contenidos cuyo producto nal (el conjunto de cheros con los objetos de
visor
genrico. Con la mera ejecucin de 211
212
Captulo 7.
ese visor congurado para interpretar el conjunto de contenidos, se dispone de un sistema que permite a un usuario interactuar con la coleccin de datos para aprender los conceptos del dominio deseados. Esta clara divisin entre los contenidos o datos que utiliza el programa y el propio visor aparece tambin en otros campos. En general, se puede decir que esta separacin es posible en dominios consolidados donde existe mucha experiencia previa de desarrollo de aplicaciones no dirigidas por datos. Gracias a esa experiencia, se han podido establecer los lmites de lo que se permite hacer al usuario y lo que no, es decir, el conjunto de operaciones que puede realizar, as como las herramientas que tiene disponibles el diseador para variar los contenidos ofrecidos. Por nombrar algn ejemplo distinto al ya visto, podemos recordar las aplicaciones de
ccin interactiva
que pre-
sentaban una historia de ccin (inicialmente de forma textual) donde el usuario poda introducir rdenes para hacerla avanzar; rpidamente se hizo un anlisis de las mismas, se acot el tipo de rdenes que se podan aceptar y se crearon lenguajes para generacin de las historias interactivas que eran interpretados por los
motores
correspondientes.
El principal problema cuando se extrapola este modelo de creacin de contenidos a aplicaciones educativas basadas en videojuegos es que la heterogeneidad de los mismos no permite establecer claramente las primitivas de variabilidad. Esto es debido a que en las aplicaciones existen dos tipos de contenidos: por un lado existen los contenidos pedaggicos y por otro lado, los entornos virtuales que determinan la jugabilidad. A la dicultad de determinar los ejes de variabilidad de estos contenidos tan heterogneos, se le aade la necesidad de actuacin de expertos distintos: aquellos que generan el contenido educativo (expertos en el dominio que se ensea) y los que generan los entornos virtuales (diseadores de niveles). La principal aportacin de esta tesis consiste en proponer una solucin para este problema de generacin de aplicaciones educativas basadas en videojuegos, a travs de dos ideas fundamentales:
La denicin de una metodologa de creacin de contenidos donde se separa claramente el trabajo realizado por ambos expertos. La creacin de una arquitectura que permite el desarrollo de estas aplicaciones donde el contenido ha sido generado por separado.
Estas ideas se concretan en una serie de resultados que constituyen las aportaciones de nuestro trabajo:
Se ha estudiado el proceso de creacin de videojuegos tradicionales, detectando los problemas ms importantes en cuanto a arquitectura y generacin de contenidos se reere.
7.1. Conclusiones
213
Se ha analizado la naturaleza de las aplicaciones educativas, y sus mtodos de construccin y generacin de contenidos. Se ha identicado el problema de la creacin de contenidos en las aplicaciones que aunan ambas reas, las aplicaciones educativas basadas en videojuegos. Se ha denido una metodologa para la creacin de estas aplicaciones, deniendo las etapas de desarrollo, el tipo de profesionales que deben participar, y los tipos de contenidos que deben generar. La metodologa resuelve el problema de interaccin entre los distintos profesionales, permitiendo la creacin de contenidos por separado. La separacin de ambos tipos de datos permite la reutilizacin de los mismos, con la reduccin de costes que ello supone. Por ejemplo, el mismo entorno virtual puede utilizarse en distintos ejercicios. Hemos visto como la existencia separada de entorno y ejercicios permite tambin el uso de distintas tcnicas de extraccin de informacin sobre ellos para analizar sus propiedades e identicar y resolver posibles problemas en los mismos. Se ha comprobado que el anlisis formal de conceptos puede ser utilizado para comprobar la cobertura del conjunto de ejercicios creados por el experto del dominio. Hemos descrito un nuevo uso del anlisis formal de conceptos para el anlisis de las partidas de un juego, ayudando as a los creadores de los mapas o entornos virtuales en el momento de del juego. Se ha denido una arquitectura software que soporta la metodologa expuesta. Hemos descrito como esta arquitectura permite congurar el comportamiento de la aplicacin en funcin del entorno virtual y de los ejercicios presentados. Se ha mostrado la aplicabilidad de la metodologa y arquitectura por medio de diversas aplicaciones educativas. Se ha detallado la instanciacin de la arquitectura que ha dado lugar a dos aplicaciones educativas para el aprendizaje de la mquina virtual de Java y cmo el cdigo escrito en ese lenguaje es compilado para ella, JV M 1 y JV M 2.
nivelar
la dicultad
214
Captulo 7.
Utilizando el contexto de la aplicacin anterior, hemos descrito cmo el uso de
componentes
para la programacin de las entidades del juego fa-
cilita considerablemente el desarrollo de la aplicacin y la reutilizacin de parte del cdigo en otras aplicaciones. Por ltimo, tambin hemos utilizado JV M para detallar un ejemplo real de conguracin del entorno virtual en base a los ejercicios.
7.2. Trabajo futuro

Para nalizar esta memoria, vamos a comentar las lneas de continuacin ms interesantes, desde nuestro punto de vista, del trabajo aqu presentado. En primer lugar, la separacin del contenido en contenido pedaggico y jugabilidad puede suponer problemas si no se maneja con cautela. A pesar de que la metodologa y arquitectura permiten una separacin completa de ambos tipos de datos, es cierto que existen algunas dependencias entre ellos. Por ejemplo, es necesaria la existencia de unas entidades concretas en el entorno para poder congurar el ejercicio. Por tanto, debe garantizarse que la comunicacin entre el equipo de creacin de contenidos de instruccin y los diseadores de los niveles estn perfectamente coordinados. Para esta coordinacin hemos propuesto el uso de herramientas de trabajo colaborativo, como los sistemas de control de versiones y de gestin del conocimiento. Sin embargo, prevemos una futura lnea de trabajo en sistemas automticos de mantenimiento de la
coherencia.
El sistema trabajara con descripciones de
alto nivel de las restricciones o exigencias de los ejercicios y de las capacidades que ofrecen los distintos entornos virtuales creados por los diseadores. De esta forma, en tiempo de ejecucin se podra garantizar la correcta conguracin de los escenarios. La existencia de estas descripciones de las propiedades de los entornos virtuales y de los ejercicios permitira tambin la existencia de una coleccin de entornos distintos. Utilizando un mecanismo deductivo se pueden aplicar bsquedas sobre esa coleccin. En ese caso, el mdulo que dado un ejercicio devuelve el entorno virtual que debe utilizarse que comentbamos en la pgina 150, utiliza esa bsqueda inteligente para obtenerlo. El mdulo podra utilizarse para que un mismo ejercicio se resolviera en distintos entornos. Otra posible lnea de actuacin es facilitar la construccin de las entidades del juego. La utilizacin de una arquitectura basada en componentes permite la denicin de objetos de juego en cheros externos, de tal forma que no es necesario regenerar el ejecutable de la aplicacin para disponer de nuevos objetos. Sin embargo, y siguiendo con la misma idea que antes, es posible hacer una descripcin de los
servicios
ofrecidos por cada componente, de
tal forma que se pueden utilizar mecanismos deductivos y/o de planicacin para construir, a partir de la descripcin de comportamiento de una entidad,
7.2. Trabajo futuro
215
qu componentes deben agruparse y cmo deben congurarse. Por ltimo, la divisin de los contenidos en dos cheros independientes nos ha permitido la aplicacin de una tcnica como el anlisis formal de conceptos para extraer propiedades interesantes de ellas. Sin embargo, creemos que esa lnea est solamente esbozada y que existen muchas posibilidades de ampliacin, para sacar an ms conclusiones tiles.
Apndice A
Mquina virtual de Java

Este apndice presenta una breve descripcin del funcionamiento de la mquina virtual de Java (JVM). Es un pequeo resumen de la especicacin completa de Sun, y se ofrece aqu para poder entender el captulo 6, dedicado a JV2 M, una aplicacin educativa sobre la estructura interna de JVM y la forma en la que Java es compilado.
A.1. Introduccin
Java (Gosling et al., 2005) es un lenguaje de propsito general, orientado a objetos y concurrente. Su sintaxis es similar a la de C y C++, aunque elimina muchas de las caractersticas que hacen a stos complejos. Sin embargo el xito de Java no se debe nicamente a esa simplicidad, sino a su portabilidad. El cdigo compilado de Java no depende de ninguna arquitectura. En un tiempo donde las redes de ordenadores se han popularizado tanto, esta caracterstica es muy apreciable. Un programa hecho en Java se puede ejecutar en cualquier mquina que disponga de un intrprete de Java. En realidad, podemos decir que no es un intrprete en el sentido clsico de los intrpretes, donde se analiza el cdigo fuente o una representacin abreviada mediante tokens del mismo, y se ejecuta lnea a lnea. El cdigo fuente de Java
se compila.
Pero el cdigo objeto obtenido no son instruc-
ciones para una arquitectura Intel/Windows, Solaris/Unix o Alpha/Linux, sino para una mquina virtual que se especic a la vez que el propio lenguaje, y que es conocida como la Mquina Virtual de Java (Java Virtual Machine o JVM). Las caractersticas de la JVM han sido establecidas por Sun Microsystems (Lindholm y Yellin, 1999). Los creadores de Java, adems, han hecho un esfuerzo por crear un conjunto de clases que forman las
libreras
de Java que un programador puede
asumir que estarn disponibles en todos los entornos donde se ejecute el programa. Por lo tanto, para que un programa Java pueda ejecutarse en 217
218
Apndice A.
una arquitectura determinada, es necesaria la implementacin de la JVM y del conjunto de estas clases, algunas de ellas implementadas utilizando los servicios propios del sistema operativo y mquina en cuestin.
A.2. Estructura de la mquina virtual

Al igual que una mquina real, la mquina virtual de Java est dividida en varias partes. Tiene una zona de memoria para albergar objetos dinmicos, una pila con los entornos de ejecucin de los mtodos, etc. En la especicacin (Lindholm y Yellin, 1999), se detallan cada una de estas partes, las instrucciones que es capaz de ejecutar y en qu cambia cada una de ellas el estado de la mquina. Es decir, lo que se dene es, a parte del formato del chero donde se guarda el cdigo Java compilado, el conjunto de instrucciones que posee la mquina y su cometido. Y eso es lo que debe ser capaz de realizar una implementacin: leer los cheros e implementar exactamente la semntica del cdigo para la JVM que contiene. Sin embargo, no hay restricciones a la hora de decidir cmo implementar una JVM. Una implementacin podra coger la especicacin literalmente, y para cada estructura de datos vislumbrada, construir un tipo de datos o una clase que la represente. Tambin podra traducir, en tiempo de carga de cada clase, el cdigo de cada instruccin en instrucciones nativas de la CPU donde se va a ejecutar (conocido como
just-in-time code generation,
o JIT).
A.2.1.
Tipos de datos
Igual que en el lenguaje, en la mquina virtual existen dos tipos de datos: tipos primitivos y referencias, que contendrn, como su nombre indica, valores primitivos y referencias respectivamente. Aunque el lenguaje Java es fuertemente tipado, la mquina virtual espera que casi todas las comprobaciones de tipos se hagan antes de comenzar a ejecutar, por el compilador primero y por la propia mquina virtual en tiempo de carga de las clases despus. Por eso en las implementaciones, las variables de tipos primitivos no estn marcadas con el tipo que tienen. Cuando la mquina va a ejecutar una instruccin que suma dos enteros, coge los valores de la memoria y hace la suma, sobreentendiendo que esos dos valores referenciados en los operandos eran en realidad enteros. Los tipos primitivos son los mismos y tienen los mismos rangos de valores que en el lenguaje Java. No obstante, aunque el tipo
boolean
existe, se da
poco soporte para l: no existe ninguna instruccin en la JVM que lo utilice. Las expresiones son compiladas utilizando instrucciones asociadas al tipo entero, donde el valor 0 representa
false.
Existe otro tipo primitivo que no
tiene correspondencia con ningn tipo en el lenguaje, pero que es utilizado en tres instrucciones mquina, el llamado
returnAddress que representa un
219
puntero al
opcode
de una instruccin.
Las referencias, igual que en el lenguaje, pueden serlo a objetos, a a
arrays
o a interfaces. Sus valores son referencias a objetos creados dinmicamente o
null.
Pueden verse como punteros a las estructuras de datos que guardan
informacin de los objetos. Aunque la JVM no necesita guardar para cada referencia de qu tipo es, s necesita saber a qu clase pertenece el objeto al que apunta.
A.2.2.
reas de datos en tiempo de ejecucin
Estas zonas de datos se utilizan durante la ejecucin de un programa. Algunas de ellas son especcas de cada hebra, mientras que otras son comunes a todas. Por tanto, algunas se construyen al principio de la ejecucin de la mquina virtual, y otras se crean cuando la aplicacin crea hebras:
dan las instancias de las clases y los vectores (arrays ) creados. En la especicacin no se establece ninguna restriccin a cmo manejar este espacio de memoria (si es de tamao jo o no, etc.), as como no se hace mencin a cmo almacenar cada una de las instancias de las clases, aunque s indica que debe ser controlado por un recolector de basura que elimine los objetos que no son accesibles desde la aplicacin (accesibles desde ningn mtodo en ejecucin).
Heap: es una zona global, comn a todas las hebras, donde se guar-
rea de mtodos: es donde se guarda el cdigo de cada uno de los

mtodos de las clases cargadas en la mquina virtual.
Pilas de la JVM:
cada una de las hebras tiene una pila. En ella
se guardan los registros de activacin de los mtodos pendientes de ejecutar que, en nomenclatura de la JVM, se llaman importancia, los detallaremos ms adelante.
frames.
Por su
Contador de programa: tambin es privado para cada hebra, e indica qu instruccin se est ejecutando. En cada mtodo se reinicia la cuenta, es decir, la primera instruccin de un mtodo es siempre la instruccin cero. El contador de programa indica qu instruccin se debe ejecutar dentro del mtodo actual. La informacin sobre cul es el mtodo no se guarda en el contador de programa, sino en cada
frame.
rea de constantes:
en cada chero
class
existe un rea de cons-
tantes con nombres y valores que son referenciados en los campos de dichas clases o desde las instrucciones de cada mtodo. De esta forma, una instruccin de llamada a un mtodo, hace referencia a una entrada en esa tabla de constantes que contendr el nombre del mtodo, en vez de tener el propio nombre como argumento. As, los nombres son compartidos por distintas instrucciones, ahorrando espacio en disco.
220
Apndice A.
Pila para mtodos nativos:
la mquina virtual permite hacer lla-
madas a mtodos no implementados en Java, cargados de una librera externa. Estos mtodos son conocidos como mtodos han sido compilados para la mquina
real
nativos,
ya que
en la que se ejecuta la JVM.
Para su ejecucin, se dispone de una pila para cada hebra.
Los registros de activacin o
frames
son el elemento ms importante para
la ejecucin de los mtodos de Java. Un llama a un mtodo, un nuevo
frame
permite almacenar datos,
resultados parciales, valores devueltos y lanzar excepciones. Cada vez que se
frame
es creado en la pila de la hebra. Ese
frame
posee un rea para almacenar las variables locales del mtodo, una pila de operandos y una referencia a la tabla de constantes del mtodo que se est ejecutando. El tamao de las variables locales y de la pila de operandos se conoce de antemano, y es guardado por el compilador en el chero compilado (y ms adelante comprobado en tiempo de carga), por tanto, el utilizar estos datos para no desaprovechar espacio. Una vez ms, debemos hacer notar que estas estructuras son las que marca la especicacin. En este sentido, el documento divide la mquina virtual en estas partes y explica el funcionamiento de la JVM a partir del funcionamiento de cada una de ellas, indicando con qu valores son inicializadas, cundo se escribe en ellas y cundo se utilizan. Sin embargo, la implementacin particular de una JVM puede prescindir de alguna de las estructuras debido a que la funcionalidad que dan la consiguen de otra forma. Por ejemplo, en muchas implementaciones el rea de constantes es suprimida; los campos de las instrucciones, en vez de tener una referencia a ese rea, contienen directamente la constante, para un acceso ms rpido. Si el funcionamiento de cara al exterior es el indicado por la especicacin, se puede decir que la implementacin cumple esa especicacin, independientemente de si internamente tiene las estructuras marcadas o no.
frame
puede
A.2.3.
Conjunto de instrucciones
Uno de los aspectos que ms llama la atencin de las instrucciones mquina de la JVM es el gran nmero de instrucciones dedicadas para cada una de las operaciones. As, existen mltiples instrucciones de suma, resta, etc. La razn es simple: cada una de ellas permite operar con valores de distintos tipos, por lo que hay una instruccin para sumar enteros, otra para sumar enteros largos, otra para reales, reales de doble precisin, etc. Cuando la operacin admite distintos tipos, para distinguir entre todas las versiones, el mnemnico dispone de un la nomenclatura de la tabla A.1. Las instrucciones pueden agruparse en varias categoras que explicamos a continuacin.
prejo
que indica el tipo, segn
221
Prejo Tipo
i int
l long
s short
b byte
c char
f float
d double
a reference
Tabla A.1: Prejos utilizados en las instrucciones de la JVM
A.2.3.1. Operaciones de carga y almacenamiento

Son las responsables de mover valores desde las variables locales a la pila de operandos (carga) o viceversa (almacenamiento). La carga se realiza con las instrucciones
{i,l,f,d,a}load
{i,l,f,d,a}load_[n].
En el primer caso, el nmero de la variable local a cargar es un parmetro de la instruccin, y en el segundo caso viene en el cdigo de la instruccin (n entre 0 y 3). El almacenamiento es equivalente, utilizndose en este caso las instrucciones
{i,l,f,d,a}store
{i,l,f,d,a}store_[n].
Existen otras operaciones que cargan valores constantes en la pila. Esos valores pueden ser operandos de la instruccin, o estar codicados en el opcode. Por ejemplo existen instrucciones especcas para apilar valores enteros entre -1 y 5 (iconst_m1,
iconst_[i] ), para apilar el 0 y el 1 de tipo long, etc.
A.2.3.2. Instrucciones aritmticas

Como norma general, cogen dos operandos de la pila de operandos, operan con ellos y dejan en la cima el resultado. No existen operaciones para los tipos
byte, short, char ni boolean. Para operar con ellos, se utilizan las
{i,l,f,d}add, {i,l,f,d}sub, {i,l,f,d}mult, {i,l,f,d}div, {i,l,f,d}neg, {i,l}or, {i,l}and, {i,l}xor e iinc (incre-
instrucciones que trabajan con los enteros. Las operaciones son
{i,l,f,d}rem
(mdulo),
menta una variable local). Adems, hay operaciones de desplazamiento a nivel de bits de enteros y de enteros largos, tanto a derecha como a izquierda y teniendo en cuenta el signo o no:
{i,l}shl, {i,l}shr, {i,l}shr
(no existe
{i,l}ushl ).
Por ltimo, existen instrucciones de comparacin que dejan en la pila un valor entre -1 y 1 dependiendo del resultado.
A.2.3.3. Instrucciones de conversin de tipos

Cogen de la pila el dato, lo convierten al tipo destino y lo vuelven a apilar. Las instrucciones se representan de la forma tipo origen, y
el destino (y 2 representa la preposicin inglesa to ). y
a2b,
donde
signica el
Las instrucciones para conversin de tipos que soporta la mquina virtual son
i2l, i2f, i2d, l2f, l2d, f2d, i2b, i2c, i2s, l2i, f2s, f2l, d2i, d2l
d2f.
222
Apndice A.
A.2.3.4. Creacin y acceso a objetos

Existen instrucciones especcas para la creacin de objetos y de as como para el acceso a cada posicin de estos ltimos: Creacin de una instancia de una clase: Creacin de un
arrays,
new.
array
(vector) de tipos primitivos, de referencias o un
array multidimentsional:
newarray, anewarray, multianewarray. geteld,
Acceso a los campos de las clases (estticos) y de los objetos:
puteld, getstatic, putstatic.

Acceso a un componente de un operandos:
{b,c,s,i,l,f,d,a}aload.
array, array
y almacenarlo en la pila de
Almacenar un componente de un
desde la pila de operandos:
{b,c,s,i,l,f,d,a}astore.
Obtener la longitud de un vector:
arraylength. array
deter-
Comprobar si una referencia apunta a una clase o tipo de minado:
instanceof, checkcast.
A.2.3.5. Instrucciones con la cima de la pila

Algunas instrucciones operan directamente sobre la cima de la pila. Por ejemplo,
pop
mientras que
pop2 eliminan uno swap los intercambia.

y
o dos elementos de la cima de la pila,
Por ltimo, existe una batera de instrucciones que permiten duplicar algunos elementos de la cima de la pila. Dependiendo del nmero de ellos (uno o dos) y de dnde lo inserte (en la cima de la pila, o inmediatamente debajo de ella), disponemos de
dup, dup2, dup_x1, dup2_x1, dup_x2
dup2_x2.
A.2.3.6. Instrucciones de salto

En este grupo situamos tanto los saltos condicionales como los incondicionales. La JVM tambin dispone de unas instrucciones especcas creadas para la compilacin de la instruccin
switch.
Saltos condicionales: existe un grupo de saltos condicionales que saltan o no dependiendo del resultado de la comparacin de un entero con el valor cero (ifeq,
it, ie, ifne, ifgt y ifge ), o del resultado de la comparacin de dos enteros en la pila (if_icmpeq, if_icmpne, if_icmplt, if_icmpgt, if_icmple, if_icmpge, if_cmpeq y if_cmpne ). Por ltimo, tambin existen dos saltos que dependen de si una referencia es null o no (ifnull y ifnonull ).
223
Salto incondicional: adems del comn ancha, y
goto_w ),
goto
(y su versin con direccin de Java,
existen tres instrucciones para los saltos incondicio-
nales necesarios debido a la construccin
ret.
finally
jsr, jsr_w
Instruccin
switch:
dependiendo de lo dispersos que sean los distin-
tos casos o posibilidades dentro de los
lookupswitch.
case,
se utiliza
tableswitch
Las instrucciones de invocacin a mtodos tambin pueden considerarse instrucciones de salto, ya que rompen la ejecucin en orden del programa. Sin embargo, dada su importancia, las tratamos de modo independiente.
A.2.3.7. Invocacin de mtodos

Existen cuatro instrucciones distintas para hacer llamadas mtodos. Las diferencias entre ellas (especialmente entre las tres primeras) son bastante
sutiles,
ya stas radican principalmente en cmo buscan el mtodo en la
jerarqua de clases.
invokevirtual :
Llama al mtodo de un objeto, haciendo la resolucin
del mtodo que se espera en un lenguaje orientado a objetos, es decir, si el mtodo no existe en la clase a la que pertenece el objeto, lo busca en la clase padre.
invokeinterface :
ma parecida al
Se utiliza para llamar a un interfaz. Funciona de for-
invokevirtual,
buscando la implementacin en la clase
a la que pertenece el objeto que recibe el mensaje y, si no existe, en la clase padre. La diferencia fundamental son las comprobaciones de acceso realizadas. En este caso, la instruccin recibe no solo el nombre del mtodo, sino tambin el nombre del interfaz al que pertenece, comprueba que la clase implementa ese interfaz y alguna otra comprobacin inherente a este tipo de invocaciones.
invokespecial : como su nombre indica sirve para realizar llamadas especiales a distintos mtodos. Por ejemplo, se utiliza para llamar a los
constructores de las clases, a mtodos privados o a un mtodo de la clase padre a la que pertenece el objeto.
invokestatic :
utilizado para ejecutar mtodos estticos de una clase.
A.2.3.8. Instrucciones para excepciones

La nica instruccin relacionada con el lanzamiento de excepciones es
athrow,
que recibe la referencia al objeto de la excepcin que se lanzar.
224
Apndice A.
La captura de excepciones, al ser un mecanismo controlado por la JVM y externo a la propia ejecucin de las instrucciones, se encuentra situado en la informacin esttica del propio mtodo. Para la implementacin del
las instrucciones de salto incondicional
finally, ya hemos comentado que se utilizan jsr, jsr_w y ret.
A.2.3.9. Instrucciones de sincronizacin

Java permite al programador la ejecucin de varias hebras concurrentemente, y la existencia de monitores para su programacin segura. Cada objeto Java posee un
monitor
utilizado para la sincronizacin. Para
el control de estos monitores, la mquina virtual dispone de dos instrucciones para bloquearlos y desbloquearlos, que son respectivamente.
monitorenter
monitorexit
Apndice B
Gestor de scripts en Java desde C++
Este apndice contiene una pequea descripcin del mdulo ScriptSystem de JV2 M, que permite la invocacin de mtodos creados en clases Java desde una aplicacin como la nuestra, implementada en C++.
B.1. Introduccin
Aunque JV M est implementado en C++, existe una parte de la implementacin del subsistema de tutora (seccin 6.6) que est implementada en Java. En particular, decamos en la pgina 203 que el sistema de ayuda de JV M 2 utiliza jCOLIBRI para la implementacin de la ayuda semntica y sintctica. Para la comunicacin entre C++ y Java, JV M dispone de un mdulo llamado
ScriptSystem
que est asociado al mdulo de tutora, y que se
inicializa cuando ste. El mdulo consta de una serie de clases que crean una instancia de la mquina virtual, permiten la carga de clases Java, la creacin de objetos y la invocacin a sus mtodos. Los siguientes apartados describen lo ms signicativo del mdulo.
B.2. JNI: Java Native Interface

Los diseadores de Java crearon un mecanismo para conseguir que las aplicaciones de Java pudieran llamar a mtodos de C/C++. Este mecanismo 225
226
Apndice B.
utiliza una coleccin de APIs de C++ conocidos como Java Native Interface (JNI). As, se puede llamar a mtodos denominados nativos (implementados en C/C++), desde Java. Gran cantidad de los mtodos de la librera de Java estn implementados haciendo uso de estos mtodos nativos. Por ejemplo, la lectura de cheros, soporte de red, dibujado en pantalla, etc. Todas estas funcionalidades de Java estn escritas en C/C++, haciendo uso del sistema operativo subyacente. Por lo tanto, la realidad es que JNI fue una estandarizacin de un interfaz que los propios desarrolladores de Sun necesitaban para poder implementar toda la librera de Java . Adems, los mtodos desarrollados en C/C++ pueden a su vez, basar su implementacin en llamadas a otros mtodos Java. Es decir, JNI permite desde C++ llamar a mtodos Java. Esta capacidad es la que se aprovecha en JV M, dando la vuelta a la utilidad inicial de JNI: en vez de utilizarlo para, desde aplicaciones Java, llamar a mtodos en C++, lo usaremos para poder llamar a Java desde aplicaciones en C++. JNI es distribuido con la mquina virtual de Java desde la versin 1.1 del JDK. Viene en forma de librera dinmica (DLL o .so), que tiene funciones que pueden invocarse desde una aplicacin en C/C++. De hecho, la forma normal de ejecutar la mquina virtual (ejecutable
java),
no es ms que un
simple programa de C que interpreta los argumentos de la lnea de comandos, y llama a la mquina virtual de Java utilizando esa DLL que implementa el interfaz JNI. Al instalar JDK 1.5, se instala (en el directorio en el enlazado el chero
$JDKROOT$/include) el .h $JDKROOT$/
que contiene las funciones de JNI. Adems, el proyecto en C++ debe incluir
lib),
JVM.
jvm.lib
(que aparece en el directorio
para que enlace estticamente la DLL con la implementacin de la
El programa debe inicialmente crear una mquina virtual utilizando una funcin del JNI. Despus cargar las clases que necesite, y ejecuta los mtodos deseados. Por ltimo, destruye la mquina virtual, para eliminarla de la memoria. El proceso de creacin de una JVM es relativamente costoso en tiempo, por lo que JV M la arranca al principio de su ejecucin, y la mantiene activa hasta su nalizacin. Para ocultar las peculiaridades de JNI al resto del sistema, hemos implementado la clase mquina virtual. Adems, sobrecarga el operador echa de C++ (->), para poder llamar a las funciones de JNI utilizando un objeto de la clase. El cdigo de la clase aparece en la seccin C.2.1.
JavaIntfz::JVM,
que utiliza JNI para crear y destruir la
Y de hecho, fue uno de los puntos de conicto con Microsoft, que intentaron establecer
su propio mecanismo de comunicacin, para facilitar las llamadas a objetos COM.
B.3. ScriptManager
227
B.2.1.
Soporte para hebras
La mquina virtual de Java permite que distintas hebras se ejecuten sobre ella. Es ms, tambin permite que varias hebras de C++ invoquen a mtodos suyos simultneamente. Lo normal es utilizar JNI de tal forma que la mquina virtual tenga el control completo de la aplicacin, y de vez en cuando llame a mtodos nativos de C++. Eso puede provocar que, si en Java se han creado hebras, se estn ejecutando
simultneamente
varios mtodos nativos.
En nuestro caso, la aproximacin es a la inversa, por lo que el tratamiento de hebras tambin. Ms concretamente, estamos utilizando Java desde C++, es decir, en C++ hemos creado una JVM, y llamamos a mtodos de sus objetos. Esa aplicacin (JV M) puede crear distintas hebras en C++, y llamar a mtodos Java desde todas ellas. Para hacerlo posible, la JVM, y en particular JNI, requiere que cada nueva hebra que quiera llamar a la JVM sea previamente reconocida por la JVM, o mejor dicho sea vinculada (attach ) a la JVM, llamando a un mtodo de JNI denominado programa. (JNIEnv). En la creacin de la JVM, se crea el primer entorno automticamente para la hebra invocante. Si se quieren otras hebras, hay que indicrselo a la JVM (mediante la corespondiente llamada a JNI), para que se cree otro entorno de ejecucin (JNIEnv) para esa nueva hebra. Cuando una hebra no va a volver a utilizar la mquina virtual, tiene que El soporte de hebras en JNI se realiza mediante el entorno
AttachCurrentThread.
Si una hebra no vinculada a la
JVM llama a alguno de los mtodos, provocar la interrupcin abrupta del
de ejecucin
desvincularse
La clase
de ella, utilizando el mtodo
DettachCurrentThread, que
elimina o libera ese entorno de ejecucin.
JVMIntfz::JVM proporciona soporte para hebras, permitiendo a 2 distintas hebras (que en JV M creamos con la librera pthread) vincularse y desvincularse de la mquina virtual. El operador -> anteriormente citado
detecta en qu hebra se est, y devuelve el entorno de ejecucin de esa hebra, de tal forma que las llamadas a JNI se realizan automticamente utilizando el entorno adecuado.
B.3. ScriptManager
un El gestor de los scripts est implementado en la clase CScriptManager. Es singleton con inicializacin y destruccin explcita de la nica instancia, mediante los mtodos estticos Init y Release, para evitar problemas por El objeto gestor en su inicializacin crea una mquina virtual de Java, poniendo como classpath el directorio
el orden de inicializacin de los singleton.
./scripts,
donde se encuentran las
228
Apndice B.
2
clases Java que utiliza JV M. El gestor permite la carga de clases en la mquina virtual (ver el apartado B.3.1), y la construccin de objetos a partir del nombre de la clase (apartado B.3.2), as como la invocacin tanto de mtodos estticos como dinmicos (ver la seccin B.5). Por ltimo, dada la importancia de las cadenas en el lenguaje Java (java.lang.String), tambin dispone de una clase para la El cdigo de la denicin de la clase aparece en la seccin C.2.2. traduccin sencilla entre ellas y las cadenas nativas de C++ (std::string).
B.3.1.
ScriptClass
CScriptClass (ver su denicin en el apartado C.2.3) representa
carga una clase en Java, devuelve como manejador
La clase tual,
una clase de la mquina virtual de Java. Cuando el gestor de la mquina vir-
CScriptManager,
un puntero a un objeto de
CScriptClass.
no
puede crear un objeto de
En realidad, el usuario del sistema de scripts El mtodo objeto
esta clase, sino que siempre tiene que hacerlo a travs del
nunca
CScriptManager::getScriptClass devuelve un puntero a un CScriptClass que no es propiedad del invocador, es decir, el usuario
2
CScriptManager.
tendr que liberar este tipo de objetos .
La clase tiene dos funciones principales:
La creacin de objetos de la propia clase: llamando al constructor por defecto, y devolviendo un objeto de la clase C++ describiremos en el apartado B.3.2. Invocacin a mtodos estticos. Las llamadas a los mtodos (en general, tanto estticos como de instancia) tiene la importancia suciente como para que le dediquemos el apartado B.5 completo, por lo que no lo describimos aqu.
CScriptObject
que
Desde el punto de vista de la implementacin interna del gestor de scripts, la clase
CScriptClass
tambin es la responsable de buscar si existen los
mtodos pedidos (a partir del nombre del mtodo y su signatura) en la clase, y de guardar las referencias JNI en una cach interna.
B.3.2.
ScriptObject
CScriptObject
(ver su denicin en la seccin C.2.4) simboliza
La clase
un objeto de la mquina virtual de Java. Internamente, el
almacena una referencia JNI al objeto de la mquina virtual (jobject), que
CScriptObject
Como hemos dicho anteriormente, el
CScriptManager mantiene internamente una lista
de todas las clases cargadas, y se liberan al nal.
B.4. Cadenas en Java
229
libera en su destructor. Eso provoca que si la JVM lo considera oportuno, sea liberado por el recolector de basura. Segn esto, dos objetos de
CScriptObject
podran referenciar al mis-
mo objeto Java (ya veremos un ejemplo de cmo puede darse esto en el apartado B.5 de invocacin de mtodos). La sobrecarga del operador (comprobando si representan al mismo objeto Java). Para crear un objeto Java y conseguir un puntero a un objeto C++ de esta clase, el usuario del mdulo utilizar el mtodo clase
==
se
asegura de que la comparacin entre objetos C++ se haga de forma correcta
CScriptManager
o de
CScriptClass
CrearObjeto
de la
(el primero recibe el nombre de
la clase). Ambos piden memoria para el objeto y devuelven un puntero a un objeto de esta clase. Los mtodos disponibles para invocar a los mtodos de Java son descritos en el apartado B.5.
B.4. Cadenas en Java

Las cadenas son un tipo casi primitivo en Java. A pesar de que son una clase propia dentro del classpath (java.lang.String), su mera localizacin en el paquete de la JVM. Por esa razn, y porque es una clase muy utilizada, el mdulo de comunicacin con Java dispone de una clase, Esta clase hereda de
java.lang parece indicar que es una clase con privilegios dentro CStringScript,
que facilita su uso.
CScriptObject,
por lo tanto se puede llamar a todos
sus mtodos de la misma forma que con cualquier otro objeto. La ventaja de utilizar esta clase especializada es que dispone de un nuevo mtodo,
getCadena,
que devuelve la cadena en C++ (std::string). El propio ges-
tor, adems, tiene un mtodo para crear una cadena en vez de un objeto genrico, a partir de su representacin en C++.
B.5. Invocacin de mtodos

La parte ms importante del interfaz con Java es la posibilidad de invocar mtodos. Aunque en este apartado hablaremos de los mtodos de objeto (o de instancia), las explicaciones se pueden extrapolar a los mtodos estticos (la diferencia es que desde C++, unos se llaman utilizando la clase
CScriptObject
(o
y los otros
CScriptClass).
Para llamar a los mtodos Java, se utiliza la familia de mtodos
InvokeStaticXXX).
InvokeXXXX
La lista completa es la siguiente:
void InvokeVoid ( const char name , const char s i g n a t u r e , . . . ) ; bool InvokeBoolean ( const char name ,
230
Apndice B.
const char s i g n a t u r e , . . . ) ; int I n v o k e I n t ( const char name , const char s i g n a t u r e , . . . ) ; double InvokeDouble ( const char name , const char s i g n a t u r e , . . . ) ; f l o a t I n v o k e F l o a t ( const char name , const char s i g n a t u r e , . . . ) ; C S t r i n g S c r i p t I n v o k e S t r i n g ( const char name , const char s i g n a t u r e , . . . ) ; CScriptObject InvokeObject ( const char name , const char s i g n a t u r e , . . . ) ;
Todos ellos reciben como primer parmetro el nombre del mtodo Java, como segundo parmetro la signatura (o prototipo), y a continuacin una lista de parmetros variable (y opcional), que sern pasados al mtodo Java invocado. Para indicar el tipo (en el segundo parmetro) se utiliza una cadena con una codicacin especial, que permite representar cualquier tipo de Java (ya sean tipos bsicos, clases o mtodos). La tabla B.1 reeja el mtodo de codicacin y el ejemplo de un mtodo con tres parmetros (un entero, una cadena y un
array
de enteros) que devuelve un valor binario.
Hay que hacer notar que, obviamente, los parmetros que se indican en la funcin de C++ son valores
en C++.
Por lo tanto, si se llama a un
mtodo que recibe un booleano, se pasar como parmetro una variable o valor booleana en C++, que tendr su correspondiente tamao en bytes. Lo mismo si se tienen que pasar
ints, floats, etc. Esta caracterstica puede ser long

o
un foco de problemas cuando el tamao de los datos en C++ no es el mismo que el de Java (como ocurre con los tipos gestor de comunicacin
no
char).
Debido a esto, el
soporta aquellos tipos de datos que tienen rango
de representacin distinto en ambos mundos. Si un mtodo recibe como parmetro una referencia a un objeto, se utiliza como parmetro el mtodo JNI. Los mtodos Java pueden devolver distintos tipos (o nada, o mtodo para llamar a mtodos Java que devuelvan derla manejar con
puntero al CScriptObject. La implementacin interna del InvokeXXXX, hace la conversin de C++ a Java antes de llamar a
bool,
etc.).
Por eso, hay un mtodo por cada posible tipo devuelto. Destaca tambin un
String, para luego poCStringScript, en vez de con el genrico CScriptObject. Por ltimo, hay que decir que el InvokeObject es lo sucientemente inteligente como para construir un nuevo CScriptObject con el valor devuelto. Eso hace posible que dos CScriptObject distintos referencien al mismo objeto Java. Por ejemplo, se consigue con la simple llamada a un mtodo (poco til pero vlido como ejemplo) como myself.
ClasePrueba myself() { return this; }
B.6. Uso de Java en JV M
231
Signatura Z B C S I J F D Lpaquete/paquete/nombre_clase; [signatura (signaturas)tipo_devuelto

(ILjava/lang/String;[I)Z
Tipo de Java boolean byte char short int long oat double clase tipo[] tipo_devuelto (signaturas) (funcin) Ejemplo
boolean func (int, String, int [])
Tabla B.1: Codicacin de tipos de Java en cadenas.
B.6. Uso de Java en JV2M

Como hemos comentado anteriormente, el subsistema de tutora de JV M utiliza Java para implementar la ayuda semntica que se ofrece al usuario. La ayuda, implementada en el subsistema de tutora, se inicializa al principio de la aplicacin. Desde C++ est representada por la clase los siguientes mtodos:
CHelp, que contiene
InitHelp:
comienza la inicializacin de la ayuda. Provoca la creacin
de la clase Java
help.Help,
que, utilizando jCOLIBRI, implementa la
ayuda sintctica y semntica. sta inicializacin es bastante costosa en tiempo, por lo que se ejecuta en una hebra distinta que aprovecha el soporte de hebras visto en el apartado B.2.1.
ReleaseHelp: elimina el objeto Java, para que la mquina virtual pueda liberar todos sus recursos.
InitializationComplete:
terminado).
devuelve un valor binario que indica si la
ayuda se ha terminado de inicializar (es decir, la hebra secundaria ha
AskForHelp:
clase java
recibe una cadena en C++ (std::string), que traduce ste devuelve a su vez la cadena (Java) con el
a una cadena Java para invocar al mtodo con el mismo nombre de la
help.Help.
mensaje a proporcionar al estudiante que es a su vez convertido a una cadena C++ que se presenta al usuario.
Apndice C
Cdigo representativo de JV2M
Este apndice contiene secciones representativas de cdigo C++ de JV2 M, referenciadas desde el texto.

C.1.1. Maps::CMapFile
/ @file MapFile . h la declaracin un de la clase que representa una mapa
Contiene cargado La clase que
desde
fichero . toda la informacin gestionan Martn leda las del mapa , lanzar de el tal mapa
contiene puede los Marco
forma
posteriormente que
utilizarse todas
para
( creando @au thor
objetos Antonio
entidades ) .
Gmez
/
#i f n d e f #d e f i n e MapFile_H MapFile_H
#i n c l u d e <v e c t o r > #i n c l u d e < s t r i n g > // Predeclaracin Maps { CMapEntity ; class de clases
namespace
233
234
Apndice C.
Cdigo representativo de JV M
class class } namespace / Clase disco . El
CMapModel ; CMapLoader ;
Maps {
que
almacena
la
informacin
completa
de
un mapa
ledo
de
constructor que
de
la de
clase crear y
es
protegido , es la mtodo
por puede del
lo
que el
la
nica la a otras
forma
existe del
objetos Este delegar
utilizando carga
mtodo
factora extensin clases . La as clase como
createMapFromFile . fichero ,
analizar fichero
almacena una Marco lista
una con
lista todos Gmez
con los
todas
las
entidades que tiene .
del
fichero ,
modelos
@au thor
Antonio {
Martn
/
class CMapFile public : // // Clase lista CMapLoader de friend , para poder tener acceso a la
entidades . CMapLoader ;
friend / Carga El que
class
un mapa Si no
desde no se
fichero , ha lo ya si ese que
devuelve cargar mapa ya el se
la
clase en
que
lo
representa . mtodo momento
podido
mapa , carg un evitar
d e v u e l v e NULL . algn externo
comprueba por mapas del los
anterior ,
debe
existir para carga . la
gestor
mantenga
cargados , que se
duplicaciones . @param name Nombre @return mapa . @note forma del Para que la a carga , una u utiliza de la otra la extensin del la fichero de tal dependiendo misma , redirige interpretacin Puntero al mapa objeto que contiene informacin del
fichero
clase . std : : s t r i n g &name ) ;
/
static / Mtodos @return que devuelve del el nombre del mapa . nombre mapa . const Es { return p uro , _nombreMapa ; para hacer } la CMapFile
createMapFromFile ( c o n s t
/
const /// /// s t d : : s t r i n g &getName ( ) de la clase .
Destructor clase
virtual
abstracta .
virtual
~CMapFile ( ) = 0 ;
235
protected : /// /// Constructor crear {} datos para guardar la coleccin de entidades . de la es clase . Es a protegido ; la nica forma de
objetos
invocando
createMapFromFile .
CMapFile ( ) /// Tipo de
typedef ///
s t d : : v e c t o r <Maps : : CMapEntity > de entidades del mapa
TListaEntidades ;
Coleccin
TListaEntidades /// Tipo de
_listaEntidades ; para guardar la coleccin de modelos .
datos
typedef ///
s t d : : v e c t o r <Maps : : CMapModel> de los modelos del mapa
TListaModelos ;
Coleccin
TListaModelos /// }; } // namespace // Nombre del
_listaModelos ; mapa
std : : s t r i n g
_nombreMapa ;
Maps
#e n d i f
MapFile_H
C.1.2. Maps::CMapEntity
/ @file MapEntity . h la de declaracin un mapa . Antonio Gmez Martn de la clase que representa una entidad
Contiene cargada @au thor
Marco
/
#i f n d e f #d e f i n e MapsMapEntity_H MapsMapEntity_H
#i n c l u d e <map> #i n c l u d e < s t r i n g > #i n c l u d e // // // // " Base / V e c t o r 3 . h" de clases de el sus que sern As , ( si de amigas podrn ya los de esta : objetos las de que entidades
Predeclaracin todos este los tipo .
cargadores Tambin a
mapas . modelos
crear
modelo
un mapa ,
guardan class class class
punteros Maps {
tienen ) .
namespace
CMapBSPFile ; CMapModel ; CMapFile ;
236
Apndice C.
namespace / Clase Una que
Maps {
almacena de El
la
informacin es
de
una una
entidad lista tipo , de
de de
un mapa . atributos lo que tipo . cargar son el Por la
entidad tiene
un mapa valor
simplemente tener a acceder son y la
c l a v e v a l o r . clase Los mapa eso
puede
distinto valores en no el
por
mtodos de esta desde
para clase de
distinto de
objetos todos
creados luego que
momento su
concreto los y
fichero ,
debera a ellos
modificarse . contenido las clases
mtodos
clase
alteran
protegidos , amigas . La del forma de
nicamente
pueden
acceder
guardar se de y cuyo lo
las en
parejas una es un el
a t r i b u t o v a l o r hash cuya se simple usuario de eso en esa no es buffer
es
bastante es el al nombre vuelo . ( si
primitiva : dependiendo Las los
guardan que
tabla
clave
atributo ,
valor
( char
que ,
quiera las en a Las un
convierte los
e n t i d a d e s NO s o n hay ) almacenados ( CMapModel ) . un puntero propiedad
encargadas el mapa . objeto De de entidades , decir ,
guardar se caso clase de
modelos otra en
encarga que ,
clase
distinta almacenan caso , el es
tener por
modelos , ningn la clase en
suyo
( es
borrado
destructor ). CMapEntity {
/
class public : / Sirve @param @return para comprobar Nombre true si de si un la el atributo atributo existe o no . atrib clave / atributo . existe . const ;
Devuelve
/
bool // / Devuelve atributo que el el valor una de de la un atributo . terminada podr al atributo valor la Normalmente utilizar . por del el que se de pregunta . El ese mtodo puntero ; el valor , atributo . la vida del el ser cadena del c o n <c o d e > '\\0 ' </ c o d e > , existsKey ( const de acceso std : : s t r i n g generales a &a t r i b ) los
Mtodos
atributos
cliente Puntero este pero el
clase
@param nombre Nombre @return que puede ni invoca
constante su no valor
mtodo NO t i e n e mientras despus . no
propiedad debe
utilizar
dure
propio
atributo , @note Si char
Tampoco
modificar
eliminarlo . atributo existe , d e v u e l v e NULL . const ;
/
const
getAtributo ( const
s t d : : s t r i n g &nombre )
237
/ Devuelve @return @note Si el valor real de un del no atributo atributo . existe , se devuelve 0.0 f const ; de tipo real . @param nombre Nombre Valor el atributo atributo .
del
/
float / Devuelve @return @note Si el valor de un del del no atributo de tipo entero . @param nombre Nombre Valor el entero atributo atributo . atributo . existe , se devuelve 0. const ; getAtributoFloat ( const s t d : : s t r i n g &nombre )
/
int / Devuelve @return @note o no Si el valor del se de un del no atributo de tipo vector . @param nombre Nombre Valor el atributo atributo . puede interpretarse 0.0 f , 0.0 f ) std : : s t r i n g &nombre ) como vector , getAtributoInt ( const s t d : : s t r i n g &nombre )
atributo . (0.0 f ,
existe ,
devuelve
/
Base : : TVector3 const ; // / Devuelve @return nombre de el la tipo de la de entidad a la o la clase de entidad . que contiene el Referencia clase constante cadena Mtodos de acceso a atributos "especiales " getAtributoVector ( const
entidad . const ;
/
const / Devuelve lo es , @return la posicin (0 , de de 0, la la 0). entidad , si es que existe . entidad si esta es puntual . Si no devuelve Posicion s t d : : s t r i n g &g e t E n t i t y T y p e ( )
/
Base : : TVector3 / Permite fichero @return entidad acceder del mapa si Puntero (NULL al al no modelo objeto de que la es entidad que lo contenido el modelo en de el la origen ( si tiene ). getOriginalPosition () const ;
representa
existe ). const ;
/
const /// CMapModel
getModelo ( )
de la clase
Destructor
~CMapEntity ( ) ;
238
Apndice C.
protected : /// /// /// /// /// Constructor cargador alguna de los del @param mapa de El la clase protegido , crearlo representa para el mapa , por si alguno poder implementar para que slo el
mapa pueda objeto lo
que
subclase mtodos .
necesita
CMapEntity ( c o n s t / Establece recibe el @param @param '\\0 '. atributo valor el
CMapFile
mapa ) ;
valor
de
una
clave . que
Hace
una
copia que que
del
valor con
que
( segundo
parmetro ) , Nombre que del se
interpreta
termina se
atributo / clave quiere utilizar .
establece .
Valor
/
void setKeyValue ( c o n s t const // // / Establece @param el tipo Tipo de de entidad . la entidad . std : : s t r i n g tipo ) ; tipo Funciones char para s t d : : s t r i n g &a t r i b u t o , ); los valores de los atributos
valor
establecer
"especiales "
/
void / Establece @param pos la posicin origen de de la la entidad . entidad . Posicin inicial setEntityType ( const
/
void / Establece @param el modelo Modelo inicial de la entidad . modelo inicial . CMapModel los setOriginalPosition ( const B a s e : : T V e c t o r 3 &p o s ) ;
/
void // setModelo ( const amigas :
modelo ) ;
de mapas
Clases
todos
cargadores
friend private : /// ///
class
CMapBSPFile ;
Tipo
de
datos
privado
para
guardar const
la
tabla
con
la
informacin s t d : : map<s t d : : s t r i n g , que contiene los char de
typedef ///
>
la
TTablaAtributos ; entidad .
Tabla
atributos
TTablaAtributos // // Atributos en la
_atribs ; de la entidad , que no se guardan
" especiales "
tabla .
239
///
Tipo
de
entidad _entityType ; inicial de la entidad
std : : s t r i n g /// Posicin
Base : : TVector3 /// Puntero al
_origenInicial ; modelo .
const /// }; } //
CMapModel
_modelo ;
copia no implementado &);
Constructor
CMapEntity ( c o n s t
CMapEntity
namespace //
Maps
#e n d i f
MapsMapEntity_H
C.1.3. Maps::CMapModel
/ @file MapModel . h la declaracin un fichero en de la clase que representa un modelo
Contiene cargado La clase que
desde no
que
contiene
un mapa . fsicamente otras clases al que modelo , lo
permite
principio para y poder de
acceder crear
sino
tiene
mtodos
utilicen @au thor @date
( entidad Marco
grfica
colisin ).
Antonio 2007
Gmez
Martn
Marzo ,
/
#i f n d e f #d e f i n e // MapsMapModel_H MapsMapModel_H de { clases
Predeclaracin Graphics CEntity ;
namespace class } namespace class class } //
Collision
CCollisionShape ; CCollisionContext ;
Declaracin
de
la
clase
namespace / Clase que
Maps {
almacena
la
informacin
de
un
modelo
contenido
en
un
240
Apndice C.
fichero
de
mapa . estos modelos y su representan tcnica geometra especfica esttica puede del mapa
Normalmente ( como BSPs ) . Los mapa Los que As , otro objetos las optimizada
paredes ) ,
representacin
geomtrica
estar
utilizando
alguna
( tpicamente ,
de
esta desde
clase
son y
creados luego no
en no
el
momento
de
cargar
el
concreto mtodos sus es que
fichero , la
debera en
modificarse . acceder del a
que
tiene a ese
clase que en
permiten
realidad mdulos
todas
propiedades , crear
sino modelo un en de el
nicamente los que lo
permiten
crear
clases juego . y
representan posible lo
distintos
objeto
represente colisin . tipo de
grficamente ,
represente clase hija
mundo de por cada
Existe pueda
una
sta
mapa
que
se
cargar . CMapModel {
/
class public : / Crea sus maya su la entidad Entidad grfica grfica la etc . asociada asociada entidad al al si modelo . modelo . ser hay Dependiendo un BSP , una en problema de @return
caractersticas , esttica , creacin .
grfica
D e v u e l v e NULL
algn
/
virtual return } / Crea hay de una algn La forma Forma forma en de de de colisin de asociada al modelo . al modelo , a o NULL algn si @return @note colisin asociada ser Graphics : : CEntity 0;
createGraphicsEntity ()
const
error . colisin de deber aadida mapa forma objeto .
colisin
/
virtual const /// C o l l i s i o n : : CCollisionShape { return de 0; la } clase {};
createCollisionEntity
()
Destructor
virtual protected : /// ///
~CMapModel ( )
Constructor cargador {}
de
la mapa
clase pueda
protegido , crearlo
para
que
slo
el
del
CMapModel ( ) private : ///
Constructor
copia
no
implementado
241
CMapModel ( c o n s t }; } // namespace Maps
CMapModel
&);
#e n d i f
// MapsMapModel_H
C.1.4. Maps::CMapLoaderObserver
/ @file MapsLoaderObserver . h de la clase observer del cargador de mapas
Definicin
Maps : : CMapLoader . @au thor Marco Antonio Gmez Martn
/
#i f n d e f #d e f i n e MapsLoaderObserver_H MapsLoaderObserver_H
#i n c l u d e < s t r i n g > // Predeclaracin Maps { CMapEntity ; class } // Definicin de la clase de clases
namespace
namespace / Interface por el ellos . @au thor
Maps {
que
implementa de mapas
el
cdigo se
especfico procede a
para la
ser
avisado de uno de
cargador Marco
cuando
carga
Antonio
Gmez {
Martn .
/
class / Funcin llamada cuando se va del a empezar la carga del mapa . @param nombreMapa Nombre mapa s t d : : s t r i n g &nombreMapa ) CMapLoaderObserver public :
/
virtual = 0; / Funcin llamada void cuando se ha terminado la carga del mapa . void OnBeginMapLoading ( c o n s t
/
virtual / Funcin del mapa llamada que se por est el cargador por cada una de las entidades cargando . OnEndMapLoading ( ) = 0 ;
242
Apndice C.
@param @return del
entityInfo Devuelve y por lo
Informacin false si no se tanto ,
sobre se ha debe
la
entidad . realizar la carga la creacin completa .
podido cancelar
mapa ,
/
virtual = 0; }; } // namespace Maps bool InitEntity ( const Maps : : CMapEntity
entityInfo )
#e n d i f
C.1.5. Maps::CMapLoader
/ @file MapsLoader . h de que la clase la que implementa del el cargador en el de mapas
Definicin genrico , especfico . @au thor
lanza
activacin
mapa
cdigo
Marco
Antonio
Gmez
Martn
/
#i f n d e f #d e f i n e MapsLoader_H MapsLoader_H
#i n c l u d e < s t r i n g > // Predeclaracin Maps { CMapLoaderObserver ; class } / Contiene disco . La al de Utiliza cargados solicita realiza @au thor una base de un de datos nuevo con todos ya los de ha mapas tal (" f s i c o s ") forma que no si se se desde cargar la carga Marco disco ( Maps : : CMapsBD ) , mapa y nuevo . Gmez Martn implementacin para de resto la est hecha de de tal a forma de la que permite de aadir clases soporte nuevos formatos mapas , manera independiente las clases necesarias para la carga de mapas desde de clases
namespace
aplicacin ,
gracias
jerarqua
Maps : : CMapFile
y Maps : : CMapModel .
sido
cargado ,
Antonio
/
namespace / Clase carga cdigo que carga un y lanza o un nuevo Se haya mapa desde si se tambin como d i s c o . ha podido de realizar al la de la informar Devuelve valor booleano no . se que indicando encarga Maps {
correctamente especfico
registrado
observer
243
carga y de
del
mapa . de
Ese de las la
cdigo carga
especfico de un mapa , que ste
ser as
avisado como
en
el la
inicio creacin
finalizacin cada una
para
entidades Gmez
contiene .
@au thor
Marco
Antonio {
Martn
/
class CMapLoader public : / Carga sido La lo carga que que del mapa mtodo se realiza de acuerdo todos a su extensin , tipos por de este permite cargar aquellos un mapa a cargado partir de un no fichero . se vuelve Si a el fichero ya ha previamente , hacer .
mapas El
permita informa ste acuerdo
CMapFile : : c r e a t e M a p F r o m F i l e ( ) . al a cdigo las especfico sus de la carga del de mapa ,
mtodo que de
para 
i n i c i a l i c e / cree
entidades ledas
( objetos del mapa .
juego ) @param @return el mapa
propiedades del fichero .
fileName Si por todo
Nombre va
bien ,
devuelve
true ;
si
no
se
puede
leer
cualquier
razn ,
devuelve
false . &f i l e N a m e ) ;
/
static / Registra cargador de un de nuevo mapas que en ser de observer para el la carga un del mapa . ya El que es nicamente informado . al objeto al que recibir que y que las carga . el puntero objeto anteriormente dejar de hacerlo las notificaciones admite cdigo observer , bool loadMap ( c o n s t std : : s t r i n g
suponer
nicamente Puntero
especfico
estar
interesado @param @return estaba (NULL si
observer Devuelve
notificaciones
recibiendo no
exista
ninguno ) .
/
inline static CMapLoaderObserver
addObserver ( observer
);
CMapLoaderObserver
/ Deregistra cargas @param @note tiene de el observer Puntero que al no reciba objeto estaba las que notificaciones dejar de la de las no mapas . recibir
observer Si el
notificaciones . observador efecto . void removeObserver ( CMapLoaderObserver private : registrado , operacin ningn static
/
inline
observer
);
244
Apndice C.
/ Puntero los al nico de observador del registrado para ser informado de eventos carga mapa .
/
static }; CMapLoaderObserver CMapLoaderObserver
_observer ;
CMapLoader : : antiguo
addObserver (
CMapLoaderObserver CMapLoaderObserver return } void if } } // namespace Maps antiguo ; = _observer ; _observer = o b s e r v e r ;
observer
);
CMapLoader : : r e m o v e O b s e r v e r ( CMapLoaderObserver ( _ o b s e r v e r == o b s e r v e r ) _observer = 0 ;
observer )
#e n d i f / @file MapsLoader . cpp de la clase del del en cargador el de mapas genrico , que
Implementacin lanza la
activacin Marco
mapa
cdigo
especfico .
@au thor
Antonio
Gmez
Martn
/
#i n c l u d e #i n c l u d e #i n c l u d e #i n c l u d e using " MapsLoader . h " " MapsLoaderObserver . h" " MapFile . h" "MapsBD . h " Maps ;
namespace
CMapLoaderObserver bool
CMapLoader : :
_observer = 0 ; &f i l e N a m e ) {
CMapLoader : : loadMap ( c o n s t CMapFile el
std : : s t r i n g
const //
mapFile ;
mapa del disco , si no lo estaba , ya true ) ;
Cargamos
m a p F i l e = CMapsBD : : G e t P t r S i n g l e t o n ( )
>G e t M a p F i l e ( f i l e N a m e
if ( ! mapFile ) return // false ; al observer de que vamos a empezar
Avisamos
C.2. Gestor de scripts en Java
245
// if
la
carga
de
un
nuevo
mapa
( _observer ) _observer >OnBeginMapLoading ( f i l e N a m e ) ;
// //
Recorremos
las
entidades ,
llamando
la
funcin it , end ;
de
construccin
CMapFile : : T L i s t a E n t i d a d e s : : c o n s t _ i t e r a t o r for ( it it if
= mapFile >_ l i s t a E n t i d a d e s . b e g i n ( ) , != end ; { ( ! _observer >I n i t E n t i t y ( i t ) ) return false ;
end = m a p F i l e >_ l i s t a E n t i d a d e s . end ( ) ; ++i t ) if } // // if Avisamos la carga al de observer un nuevo de que hemos terminado
( _observer )
mapa
( _observer ) _observer >OnEndMapLoading ( ) ;
return }
true ;

C.2.1. JVMIntfz::JVM
/ @file JavaIntfz . h que contiene desde clases Antonio el un interfaz programa con en la mquina se virtual crear de Java .
Fichero De esta para
fo r m a ,
en C++,
puede
una JVM
utilizar Marco
implementadas Gmez Martn
Java .
@au thor
/
#i f n d e f #d e f i n e // // JAVAINTFZ_H JAVAINTFZ_H este smbolo a si el gestor JNI debe permitir que varias
Define hebras
accedan
l a JVM.
#d e f i n e JVMINTFZ_SUPPORT_THREAD #i n c l u d e < j n i . h> #i n c l u d e < s t d l i b . h> #i f d e f #e l s e #e n d i f _WIN32 '; ' ': ' / UNIX #d e f i n e PATH_SEPARATOR
#d e f i n e PATH_SEPARATOR
246
Apndice C.
#i n c l u d e < s t r i n g > #d e f i n e USER_CLASSPATH " . " #i f d e f // // / where Prog . c l a s s is
JVMINTFZ_SUPPORT_THREAD se soportan de hebras , los distintos JNIEnv se guardan
#i n c l u d e Cuando en una lista parejas ( idHebra , JNIEnv )
#i n c l u d e #i n c l u d e < l i s t > #e n d i f namespace / Clase al la que representa con y de as , o la mquina y virtual con el muchos todo en la de una de Java . Debe o ser llamando en permanece inicializada creacin An init () , memoria pueden ms la virtuales destruida destroy () ( de que tiempo misma JavaIntfz {
destructor .
Una JVM consume
recursos
tiempo
durante crearse de
activa ). varias
una
aplicacin
mquinas dos
( totalmente
independientes ) ,
utilizando La clase
objetos
clase . distintas de la h e b r a s C++, el soporte o no macro
soporta este es
existencia supone a
Como t o d o para
control
sobrecarga ,
hebras
configurable
travs
JVMINTFZ_SUPPORT_THREAD. @au thor Marco Antonio Gmez
/
class JVM { public : / Constructor que no : , #e n d i f {}; / Destructor ; creados . elimina todos los recursos de l a JVM q u e haya se jvm de la a clase . init (). idJavaLangClass ( 0 ) , getNameID ( 0 ) No crea la mquina virtual hasta llama
/
JVM( ) #i f n d e f (NULL) , JVMINTFZ_SUPPORT_THREAD e n v (NULL)
/
~JVM( ) / Crea la mquina classpath true si virtual . CLASSPATH c o n l a JVM s e ha el que debe trabajar l a JVM @param @return { destroy ( ) ; } ;
creada . podido crear .
247
/
bool / Libera todos los recursos de l a JVM. i n i t ( std : : s t r i n g classpath );
/
void #i f n d e f /// bool /// void destroy ( ) ; JVMINTFZ_SUPPORT_THREAD Registra la hebra como usuaria { return de JNI AttachCurrentThread ( ) Deregistra la hebra false ;} de JNI
como
usuaria {}
DettachCurrentThread ( )
JNIEnv } #e l s e /// bool /// void
o p e r a t o r >()
env ;
return
Registra
la
hebra
como
usuaria
de
JNI
AttachCurrentThread ( ) ; Deregistra la hebra como usuaria de JNI
DettachCurrentThread ( ) ;
JNIEnv #e n d i f / Devuelve @param @return por
o p e r a t o r >();
el
nombre de
de la
la
clase , Java
dado
su
identificador
JNI .
clazz Nombre clase comleto ( java . u t i l . Vector
ejemplo ) . getClassName ( j c l a s s clazz );
/
std : : s t r i n g protected : / Informacin de la mquina virtual creada con JNI .
/
JavaVM #i f n d e f / Entorno de ejecucin de la mquina virtual .
jvm ;
JVMINTFZ_SUPPORT_THREAD
/
JNIEnv #e l s e typedef typedef / Entornos de ejecucin de la mquina virutal , uno por hebra . s t d : : p a i r T I n f o P o r H e b r a ; s t d : : l i s t <T I n f o P o r H e b r a> T L i s t a E n t o r n o s ;
env ;
/
TListaEntornos listaEntornos ;
248
Apndice C.
///
Cach
del
ltimo cache ;
entorno
utilizado
TInfoPorHebra / Objeto lista de de
exclusin entornos y
mutua a la
para cache .
controlar
el
acceso
la
/
pthread_mutex_t #e n d i f /// Identificador de la clase java . lang . Class mutex ;
jclass /// /// };
idJavaLangClass ; del mtodo getName de la clase
Identificador
java . lang . Class getNameID ;
jmethodID
/ Convierte del JNI : el nombre de de Java una al de clase nombre la desde el punto de por vista programador className Nombre de interpretado original por JNI
java . u t i l . Vector la
>
java / u t i l / Vector . clase interpretable
@param @return
Nombre
clase
/
std : : s t r i n g } #e n d i f / @file J a v a I n t f z . cpp que contiene un la en implementacin en C ++ c r e a r Java . Martn de la clase JVM, que getNativeClassName ( const s t d : : s t r i n g &c l a s s N a m e ) ;
Fichero permite clases @au thor
desde
programa
una JVM p a r a
utilizar
implementadas Marco Antonio
Gmez
/
#i n c l u d e using " J a v a I n t f z . h" std ;
namespace
#i n c l u d e < a s s e r t . h> namespace JavaIntfz { classpath ) {
b o o l JVM : : i n i t ( s t r i n g JNIEnv jint
env ;
vm_args ;
res ;
JavaVMInitArgs
249
// //
Establecemos la estructura
la de
versin los
que
queremos ,
inicializamos
argumentos .
vm_args . v e r s i o n = JNI_VERSION_1_4 ; J N I _ G e t D e f a u l t J a v a V M I n i t A r g s (&vm_args ) ; // // Rellenamos ( opcin el classpath c l a s s . p a t h= <c l a s p a t h > ) .
D j a v a .
JavaVMOption
options [ 1 ] ;
vm_args . n O p t i o n s = 1 ; o p t i o n s [ 0 ] . o p t i o n S t r i n g = new char [ c l a s s p a t h . length ( ) + 1]; " D j a v a . c l a s s . p a t h =% s", s t r l e n (" D j a v a . c l a s s . p a t h =") + s p r i n t f ( options [ 0 ] . optionString , c l a s s p a t h . c_str ( ) ) ; vm_args . o p t i o n s = o p t i o n s ; vm_args . i g n o r e U n r e c o g n i z e d = JNI_TRUE ; // Creamos [] l a JVM ( v o i d )& env , &vm_args ) ; ( options [ 0 ] . optionString ) ; false ;
r e s = JNI_CreateJavaVM(&jvm , delete if ( r e s < 0) return
// //
Cargamos
java . lang . Class . de
La
utilizaremos
en
la
implementacin
getClassName .
i d J a v a L a n g C l a s s = env >F i n d C l a s s ( " j a v a / l a n g / C l a s s " ) ; if ( idJavaLangClass ) this >getNameID = env >GetMethodID ( idJavaLangClass , " getName " , " ( ) Ljava / lang / S t r i n g ; " ) ; // Guardamos el entorno creado
#i f n d e f #e l s e
JVMINTFZ_SUPPORT_THREAD
this >e n v = e n v ; cache = TInfoPorHebra ( p t h r e a d _ s e l f ( ) , l i s t a E n t o r n o s . push_back ( c a c h e ) ; p t h r e a d _ m u t e x _ i n i t (&mutex , #e n d i f return } v o i d JVM : : d e s t r o y ( ) if { { true ; NULL ) ; env ) ;
( idJavaLangClass )
( t h i s )> D e l e t e L o c a l R e f ( i d J a v a L a n g C l a s s ) ; idJavaLangClass = 0 ; } #i f d e f JVMINTFZ_SUPPORT_THREAD
250
Apndice C.
p t h r e a d _ m u t e x _ d e s t r o y (&mutex ) ; #e n d i f if ( jvm ) {
jvm >DestroyJavaVM ( ) ; jvm = NULL ; } } s t d : : s t r i n g JVM : : g e t C l a s s N a m e ( j c l a s s // // // // La un de referencia objeto de la de ese a clazz objeto , la clazz ) { como al mtodo el nombre getNameID ) ;
interpretamos Llamamos nos
java . lang . Class . que
getName
devolver
clase . name = ( t h i s )> C a l l O b j e c t M e t h o d ( c l a z z , debera ser un java / lang / String . . . NULL ) ;
jobject // name
const
char
cadena
= ( t h i s )>G e t S t r i n g U T F C h a r s ( ( j s t r i n g ) name ,
std : : s t r i n g
r e t ( cadena ) ; cadena ) ;
( t h i s )> R e l e a s e S t r i n g U T F C h a r s ( ( j s t r i n g ) name , ( t h i s )> D e l e t e L o c a l R e f ( name ) ; return } #i f d e f JVMINTFZ_SUPPORT_THREAD { ret ;
b o o l JVM : : A t t a c h C u r r e n t T h r e a d ( ) p t h r e a d _ m u t e x _ l o c k (&mutex ) ; JNIEnv int if
nuevoEntorno ;
NULL ) ;
res ; ( r e s < 0) // Error { al adjuntar la hebra !
r e s = jvm >A t t a c h C u r r e n t T h r e a d ( ( v o i d )& n u e v o E n t o r n o ,
p t h r e a d _ m u t e x _ u n l o c k (&mutex ) ; return } cache . f i r s t = pthread_self ( ) ; false ;
cache . second = nuevoEntorno ; l i s t a E n t o r n o s . push_back ( c a c h e ) ; p t h r e a d _ m u t e x _ u n l o c k (&mutex ) ; return } v o i d JVM : : D e t t a c h C u r r e n t T h r e a d ( ) { true ;
251
p t h r e a d _ m u t e x _ l o c k (&mutex ) ; TListaEntornos : : i t e r a t o r TListaEntornos : : i t e r a t o r // // Siempre la que tiene != que inicializ end ) ; it >f i r s t ) ) ; el it = listaEntornos . begin ( ) ; la primera hebra , que es
end = l i s t a E n t o r n o s . end ( ) ; mdulo .
quedar
assert ( it
a s s e r t ( ! pthread_equal ( p t h r e a d _ s e l f ( ) , // for Buscamos (++ i t ; if la it hebra != end ; ++i t ) {
( pthread_equal ( p t h r e a d _ s e l f ( ) , jvm >D e t a c h C u r r e n t T h r e a d ( ) ; listaEntornos . erase ( it ); p t h r e a d _ m u t e x _ u n l o c k (&mutex ) ; return ;
it >f i r s t ))
} } // Si hemos llegado no aqu , la hebra intenta no esta registrada . de l a JVM" ) ;
a s s e r t ( " Hebra
registrada
desvincularse
p t h r e a d _ m u t e x _ u n l o c k (&mutex ) ; } JNIEnv
JVM : :
operator
>()
p t h r e a d _ m u t e x _ l o c k (&mutex ) ; pthread_t current ;
current = pthread_self ( ) ; // if Miramos JNIEnv return } // No est ; buscamos en la lista it , end ; en la cach cache . f i r s t ) ) {
( pthread_equal ( current ,
ret
ret ;
= cache . second ;
p t h r e a d _ m u t e x _ u n l o c k (&mutex ) ;
TListaEntornos : : c o n s t _ i t e r a t o r for ( it it // // if
= listaEntornos . begin ( ) , end ; ++i t ) la hebra y lo es { la de la
end = l i s t a E n t o r n o s . end ( ) ;
!= Si
lista ,
actualizamos
la
cach
devolvemos it >f i r s t )){ ; = cache . second ;
( pthread_equal ( current , cache = JNIEnv return
it
ret
ret ;
p t h r e a d _ m u t e x _ u n l o c k (&mutex ) ; } }
252
Apndice C.
// //
Si ha
llegamos
este como
punto , hebra a
la
hebra
a c t u a l NO s e Damos error ! registrado .");
encontrado
registrada . l a JVM s i n
p t h r e a d _ m u t e x _ u n l o c k (&mutex ) ; a s s e r t ( " Hebra r e t u r n NULL ; } #e n d i f std : : s t r i n g getNativeClassName ( const r e t ( className ) ; loc = ret . find ( ' . ' ) ; != s t d : : s t r i n g : : npos ) 1, "/"); loc ); { s t d : : s t r i n g &c l a s s N a m e ) { accediendo haberse
std : : s t r i n g std : : size_t while ( loc
ret . replace ( loc , } return } } // namespace ret ;
loc = ret . find ( '. ' ,
C.2.2. ScriptSystem::CScriptManager
/ @file ScriptManager . h el gestor la de Scripts de sus ( en Java ) . una y la El cometido llamada a inicial de de mtodos del
Contiene gestor Java , sus y es
sencillo ;
simplemente
lanza clases
mquina
virtual
admite
carga
objetos . Marco Antonio Gmez Martn
@au thor
/
#i f n d e f SCRIPT_MANAGER_H #d e f i n e SCRIPT_MANAGER_H #i n c l u d e " J a v a I n t f z . h"
#i n c l u d e <map> #i n c l u d e < s t r i n g > #i n c l u d e <v e c t o r > #i n c l u d e < a s s e r t . h> // Predeclaracin de clases {
namespace class class class
ScriptSystem
CScriptClass ; CScriptObject ; CStringScript ;
253
} // / Namespace el control @au thor bajo del el que se de encuentran scripts Martn las clases de relacionadas Java ) . con sistmea Antonio ( ejecucin Declaracin de la clase
Marco
Gmez {
/
namespace / Clase con gestora de todo y el sistema de scripts . Es un singleton Init () y inicializacin destruccin explcita , mediante ScriptSystem
Release ( ) . El sistema de por con scripts lo que Init ()) cuando debe si una estar hebra al tanto no de sea las la de hebras que lo tendr a que que lo
utilizan , inicializa llamar al
( que sin
quiere deje Gmez de
utilizarlo , utilizarlo .
previamente
mtodo
AttachThread ( ) ,
olvidarse
llamar
DettachThread ( ) @au thor Marco
Antonio {
Martn
/
class CScriptManager public : / Mtodo al a de inicializacin de la para liberar que para se del los que singleton . Al final , que recursos . el la Debe se Se le el no la en llamarse debe llamar por que pasa principio Release () , las un aplicacin .
parmetro utilizando conocer A de las el
rutas
queramos
formen de
classpath , tenga la plataforma ) . variable el
vector ,
invocante indicada
carcter pasadas ,
separador
( especfico
rutas
aadir de rutas con se
e n t o r n o CLASSPATH . distintas todas ha al las que formarn
@param numRutas Nmero classpath . @param @return virtual @note mquina args Array ser de
cadenas si no
rutas . inicializar la mquina de la
Devuelve de Java ) .
falso por
podido
( posiblemente Esta
problemas ser un
inicializar ya que la
funcin
puede
lenta , tiempo
carga
virtual
requiere
elevado .
/
static / Liberacin de los recursos . bool I n i t ( s t d : : v e c t o r <s t d : : s t r i n g > r u t a s ) ;
/
static / Indica que la hebra invocante quiere utilizar el sistema void Release ( ) ;
254
Apndice C.
de La la
scripts . hebra que
Es
necesario a se si la ha
debido podido el
exigencias
de en
Java . caso si negativo , no
llama
I n i t ( ) NO d e b e
utilizarlo . de del scripts ,
@return quiere
Indica generar
inicializar ; sistema abrupta
h e b r a NO p o d r
utilizar
terminacin
programa .
/
bool / Solicita de La hebra la que desvinculacin llam al de la hebra invocante llamar a del este sistema mtodo . scripts . I n i t ( ) NO d e b e r a AttachCurrentThread ( ) ;
/
void / Devuelve @return la La instancia al Init (). instancia de la clase . (); nica de la clase . Debe haberse llamado previamente DettachCurrentThread ( ) ;
/
inline / Devuelve de @param @return acceder el objeto Nombre al clase que de representa la clase o NULL en el una clase en el sistema scripts . clazz a la ( como si no java . u t i l . Vector ) . se ha podido Puntero objeto static CScriptManager
getPtrSingleton
indicada
parmetro . std : : s t r i n g &nombre ) ;
/
CScriptClass / Devuelve scripts , ( es se que ha el a objeto partir de y un por de al que de un representa una clase nativo Ese en de el la sistema clase mtodo tendr de identificador JNI ) . su de si fuera es la
getScriptClass ( const
decir , JNI ,
identificador desde tanto , lo
identificador algn que el JNI . ha podido de clases est , de de cargadas la la este crea clase . mtodo acceder i n v o c a d o r NO d e b e
podido
obtener
utilizando usuario clase no El se
nativo @param @return a la liberar @note por Por el l lo nueva ,
encargarse Puntero el
eliminar objeto en el el
referencia
local .
jniClassId
Identificador
o NULL es
clase
indicada puntero ; y ya
parmetro . en la su
puntero liberado busca
propiedad lista Si el no de lo
CScriptManager , El a ver si en de
ser est
destructor .
CScriptManager
en el
disponible . los con casos es
duplicando tanto , como
internamente todos
identificador usuario el
encargado
liberar
DeleteLocalRef
identificador
pasado
parmetro .
/
CScriptClass / Creacin de un objeto en la mquina virtual .
getScripClassFromJniId ( j c l a s s
jniClassId );
255
El
invocador clazz
deber Nombre
liberar de al la
el o
objeto . 0 si no se ha podido crear .
@param @return
clase .
Referencia
objeto ,
/
CScriptObject / Crea un nuevo cad objeto al de script de cadena . si no se pudo crear . @param @return Cadena inicial objeto , o NULL
CrearObjeto ( const
std : : s t r i n g
&c l a z z ) ;
Referencia
/
CStringScript friend friend friend protected : / Objeto que representa la mquina virtual de Java . class class class
CrearCadena ( c o n s t
CScriptObject ; CScriptClass ; CStringScript ;
std : : s t r i n g
&c a d ) ;
/
J a v a I n t f z : : JVM jvm ; typedef / Listas maneja . formato de de las clases ( no Java de de las cargadas , clases como con su clase map ) que la el etc . Los nombres Java ( clave del siguen s t d : : map<s t d : : s t r i n g , C S c r i p t C l a s s > TMapaClases ;
JNI ) ,
j a v a . u t i l . Vector ,
/
TMapaClases / Funcin JNI global en que sus o ayuda mtodos bien las en la invocacin o es a en de mtodos nativos referencias por a lo que oculta tipos de invoca . los del Java . espera El parmetros jobject , bien clasesCargadas ;
( jboolean , objetos . toda los la
etc . ) , de
decir , los
interfaz para
proporcionado referencias mtodos creadas de
por
ScriptSystem objetos , los lista Java . se que utilizan de una de al
gestin de C ++ o
mtodos
invocar las Esta una de de de Tipo Array pero el en
Java
nativos
clases
ScriptManager
( CScriptObject argumentos @param @param mismos array @param el no
).
funcin lista datos
traduce del
de C ++ a Lista
argumentos mtodo en C . se
signature jniParams parmetros se indica indica se si
@param cParams
parmetros salida
que
rellenar JNI . El Si que
con
interpretables siguiente del array
por
tamao la entran
parmetro . anterior . de los en
jniParamsSize que produce la
Tamao hay un ms
signatura array , ser @return
parmetros el por
fallo . fue bien ; o mtodo tamao puede del fallar de por salida array
Cierto correcta
todo
signatura ,
demasiado
pequeo .
256
Apndice C.
bool
translateParams ( const jvalue
char
signature
, unsigned
va_list int
cParams ,
jniParams
jniParamsSize ) ;
private : /// Constructor privado ( la clase es un singleton ) CScriptManager ( ) ; / Destructor privado ( la clase es un singleton )
/
~CScriptManager ( ) ; / Mtodo @param pasar @return de a construccin Cadena se ha se l a JVM q u e Cierto si en dos el fases . classpath de Java el que se classpath con
crear . podido inicializar objeto .
/
bool /// }; // Implementaciones i n i t ( const Puntero al s t d : : s t r i n g &c l a s s p a t h ) ; nico objeto creado .
static
CScriptManager
_instance ;
CScriptManager return } } // namespace
CScriptManager
: : getPtrSingleton () no
a s s e r t ( _ i n s t a n c e && " C S c r i p t M a n a g e r _instance ;
inicializado !");
ScriptSystem
#e n d i f
C.2.3. ScriptSystem::CScriptClass
/ @file ScriptClass .h de de la clase ScriptClass , ( en que la representa mquina una clase de en
Declaracin el sistema
scripts Antonio
subyacente Gmez
virtual
Java ) .
@au thor
Marco
Martn
/
#i f n d e f #d e f i n e #i n c l u d e SCRIPT_CLASS_H SCRIPT_CLASS_H " J a v a I n t f z . h"
#i n c l u d e <map> #i n c l u d e < s t r i n g > // Predeclaracin de clases {
namespace
ScriptSystem
257
class class class } //
Declaracin
de
la
clase {
namespace / Clase decir , el que
ScriptSystem
representa clase no el de
una
clase y
en el
el
sistema
de
scrips en dos recibe
( es pasos : como o
una
l a JVM ) . nada , la se del ha de si
Tiene
construccin mtodo y Init ()
constructor
hace de
parmetro falso La
nombre
clase mdulo
( Java ) ,
devuelve se la
cierto
dependiendo el mtodo
podido
inicializar . realiza clase de
construccin
fuera
ScriptSystem
mediante
factora
getScriptClass
ScriptSystem : : ScriptManager . @au thor Marco Antonio { Gmez Martn
/
class / Devuelve de la el identificador del nativo mtodo segn la codificacin propia de ( de l a JVM) de un mtodo clase . tipo El Tipo del mtodo del CScriptClass public :
@param nombre Nombre @param @return l a JVM/ JNI .
identificador
mtodo . s t d : : s t r i n g &nombre , const ;
/
jmethodID getNativeMethod ( c o n s t const jclass / Creacin @return de un objeto al de la clase . de script . const ; mtodos el la estticos del de de Java El Despus Puntero Objecto getNativeClass () s t d : : s t r i n g &t i p o ) { return
const
claseJvm ; }
/
CScriptObject // // // // Mtodos El de CrearObjeto ( ) invocacin name tipo , su de
parmetro los
indica segn
nombre del
mtodo .
signature vienen
codificacin
Java .
posibles const
parmetros
mtodo .
void
c h a r name , signature , . . . ) ; b o o l I n v o k e S t a t i c B o o l e a n ( c o n s t c h a r name , const char signature , ...); i n t I n v o k e S t a t i c I n t ( c o n s t c h a r name , const char signature , ...); InvokeStaticVoid ( const char
258
Apndice C.
double float
InvokeStaticDouble ( const const const char char char char InvokeStaticFloat ( const
char , , , ,
name ,
...); ...); char char
signature
char
name , name , name ,
signature signature signature
CStringScript CScriptObject
InvokeStaticString ( const const const InvokeStaticObject ( const
...); ...);
protected : / Constructora @param de la clase . Gestor de scripts : s c r i p t M a n a g e r ( sm ) {}; utilizado . scriptManager
/
C S c r i p t C l a s s ( CScriptManager
sm )
claseJvm ( 0 ) , / Mtodo @param ( no @return de inicializacin Nombre o de la si por ejemplo falso
( inicializacin clase se ha Java con
en el
dos
fases ). Java
clazz
formato
JNI ) ,
java . u t i l . Vector . podido inicializar .
Cierto
/
bool / Mtodo de la de inicializacin , el no desde dentro se del utilizando JNI . propio la en vez de de el nombre debera pues de de todos clase , forma , identificador garantiza Este mtodo solo I n i t ( const std : : s t r i n g &c l a z z ) ;
llamarse otra los
gestor
scripts ,
correcta de la
liberacin en JNI .
recursos . jniClassId Cierto o Identificador falso si se ha clase podido hacer .
@param @return
/
bool / Destructora la clase de la de clase . l a JVM. Se encarga de descargar Java InitFromJniId ( j c l a s s jniClassId );
/
~CScriptClass ( ) ; friend private : /// Referencia a la clase en l a JVM class CScriptManager ;
jclass ///
claseJvm ; de scripts bajo el que se situa la clase .
Gestor
CScriptManager typedef
scriptManager ;
jmethodID> TMapaMetodos ;
s t d : : map<s t d : : s t r i n g ,
259
/ " Cach " / t a b l a obtenidos . La hash clave con es los la identificadores concatenacin de de mtodos nombre+s i g n a t u r a .
/
mutable // No // // // TMapaMetodos la metodos ; copia para de objetos de la CScriptClass , a la ya que
permitimos la de
requerira cargada entre
duplicacin
referencia " compartir "
clase
l a JVM,
evitar
referencias
clases . CScriptClass &); CScriptClass &);
CScriptClass ( const const }; } // namespace
C S c r i p t C l a s s &o p e r a t o r =( c o n s t
ScriptSystem
#e n d i f
C.2.4. ScriptSystem::CScriptObject
/ @file ScriptObject . h de la de clase scripts ScriptObject , subyacente Martn que representa virtual un de objeto Java ) .
Declaracin en el
sistema Marco
( mquina
@au thor
Antonio
Gmez
/
#i f n d e f #d e f i n e #i n c l u d e SCRIPT_OBJECT_H SCRIPT_OBJECT_H " J a v a I n t f z . h"
#i n c l u d e <map> #i n c l u d e < s t r i n g > // Predeclaracin de clases {
namespace class class class } //
ScriptSystem
Declaracin
de
la
clase {
namespace / Clase decir , el que un
ScriptSystem
representa objeto no el de
un
objeto nada , y
en el
el
sistema
de
scripts en que dos
( es pasos : de
l a JVM ) . y
Tiene
construccin mtodo o Init () falso
constructor
hace
intenta
construir
objeto ,
devuelve
cierto
dependiendo
260
Apndice C.
si
se
ha
podido se de
o la
no .
La
construccin mediante el
fuera
del
mdulo o
ScriptSystem createObject de Las que la clase
realiza clase
mtodo
factora
S c r i p t S y s t e m : : CScriptManager ,
ScriptSystem : : CScriptClass . a el los mtodos Java se realizan utilizando el la tipo
llamadas de devuelve Marco
familia
mtodos
InvokeXXXX ,
donde
e l XXXX i n d i c a
mtodo
invocado . Gmez Martn
@au thor
Antonio {
/
class CScriptObject public : / Destructora objeto de de la clase . Se encarga de " eliminar " el l a JVM.
/
virtual / Comparacin representan Se necesita ser pueden de al dos objetos . objeto ya sin y Comprueba en que l a JVM. las referencias JNI lo mismo . representar si los dos objetos mismo ~CScriptObject ( ) ;
sobrecargar distintas ,
embargo ,
/
bool // // // // o p e r a t o r ==( c o n s t de CScriptObject de mtodos el la &); Java del mtodo . de El Despus Java .
Mtodos El
invocacin name tipo , su
parmetro los
indica segn
nombre del
signature vienen
codificacin
posibles
parmetros char
mtodo .
name , signature , . . . ) ; b o o l I n v o k e B o o l e a n ( c o n s t c h a r name , const char signature , ...); i n t I n v o k e I n t ( c o n s t c h a r name , const char signature , ...); d o u b l e I n v o k e D o u b l e ( c o n s t c h a r name , const char signature , ...); f l o a t I n v o k e F l o a t ( c o n s t c h a r name , const char signature , ...); C S t r i n g S c r i p t I n v o k e S t r i n g ( c o n s t c h a r name , const char signature , ...); C S c r i p t O b j e c t I n v o k e O b j e c t ( c o n s t c h a r name , const char signature , ...);
void InvokeVoid ( c o n s t const char friend protected : / Constructora @param de la clase . al objeto que representa l a JVM jvmIntfz Puntero class CScriptClass ;
261
/
C S c r i p t O b j e c t ( CScriptManager
sm )
: objJvm ( 0 ) {};
s c r i p t M a n a g e r ( sm ) , / Factora liberar de la la JNI . de clase , El construye se al el objeto que se un de est objeto l a JVM. a en
partir su El
de
una de el ser
referencia responsable @param sm @param obj
objeto
preocupar ,
destructor , usuario
referencia liberar JNI
objeto . utilizando
ScriptManager Objeto
/
static CScriptObject
c r e a t e F r o m J N I O b j e c t ( C S c r i p t M a n a g e r sm ,
obj ) ;
jobject / Mtodo @param @return de inicializacin Clase o de la si falso
( inicializacin que se se ha crear podido el
en
dos
fases ).
clase
objeto .
Cierto
inicializar .
/
bool / Mtodo JNI ( el de inicializacin en su vez se de el supone ( inicializacin nombre ya de la construido , del en es dos el fases ) , identificador no se utilizando llamar @param @return a clase , I n i t ( const C S c r i p t C l a s s &c l a s e ) ;
objeto
decir , en
constructor ) . Identificador si se ha objeto JNI . o falso podido hacer .
jniObjectId Cierto
/
bool InitFromJniId ( j o b j e c t class jniObjectId ) ;
friend ///
CScriptManager ; al objeto en l a JVM
Referencia objJvm ; al
jobject ///
Puntero
script
manager
utilizar
CScriptManager /// Clase a la
scriptManager ;
que pertenece el objeto
const // No // //
CScriptClass permitimos la de la
clazz
copia
; de objetos de la CScriptObject , al ya que
requerira cargado
duplicacin para
referencia " compartir " &);
objeto
l a JVM,
evitar
referencias . &);
CScriptObject ( const const }; } // namespace
CScriptObject
C S c r i p t O b j e c t &o p e r a t o r =( c o n s t
CScriptObject
ScriptSystem
#e n d i f
262
Apndice C.
C.3. Mquina virtual de Java

C.3.1. JJVM::COperandStack
/ @file OperandStack . h de la clase que implementa la pila de operandos
Definicin de l a JVM.
@au thor
Marco
Antonio
Gmez
Martn
Pedro
Pablo
Gmez
Martn
/
#i f n d e f #d e f i n e JJVM_OperandStackH JJVM_OperandStackH
#i n c l u d e <v e c t o r > #i n c l u d e < l i s t > #i n c l u d e "JVMTypes . h "
n a m e s p a c e JJVM { / La un de Los pila valor la de de operandos de cualquier tipos almacena tipo de los operandos Cada de algunas long la y de las guardar double . instrucciones ( Estos dos l a JVM ( i a d d , contribuyen en etc . ) . l a JVM, dos entrada en puede
incluyendo
unidades
profundidad
pila ). de la clase no comprueban para resto errores , como pila vaca .
mtodos la
Aunque tambin Tambin @au thor
clase
tiene el
mtodos al
funcionar de
como
una
pila ,
permite permite Marco
acceso
elementos . de los cambios . Gmez Martn
registrar
observadores Martn ,
Antonio {
Gmez
Pedro
Pablo
/
class COperandStack public : /// Constructor COperandStack ( ) ;
inline ///
Destructor {};
~COperandStack ( ) / Devuelve ocupan @return la
profundidad unidades . de
de la
la
pila .
Los
tipos
long
double
dos
Profundidad getSize ()
pila .
/
inline int const ;
263
/ Devuelve @return el Una tipo del objeto que en la cima . el tipo (JJVM\JVMTypes . h ) constante indica
/
inline / Devuelve @param dos el tipo del debe objeto en la en la del la posicin valor . mayor . el tipo (JJVM\JVMTypes . h ) indicada . Si el tipo utiliza pos Posicin Una pila JVMType g e t T y p e I n T o p ( ) const ;
posiciones ,
utilizarse que
@return /
inline /
constante
indica
JVMType g e t T y p e ( i n t
pos )
const ;
Devuelve y borra e l e n t e r o @r etu rn E n t e r o en l a cima . /

jint // // // // Se popInt ( ) ; omiten los mtodos para
de
la
cima
de
la
pila .
los y
tipos jref de que
long ,
float , Mtodos ocupan
double , para ms de
returnAddress a
acceder una
elementos hay const ; const ; const ;
la
pila .
Si el
stos ms alto .
posicin , pos ) pos ) pos ) pos )
utilizar
jint jlong jfloat jdouble jretAddr jref inline } inline } inline } inline } inline } inline } void void jref jlong jint
getInt ( int getLong ( i n t
getFloat ( int getDouble ( i n t
const ; pos ) const ; const ;
getReturnAddress ( i n t getReference ( int topInt () const { pos )
return
getInt ( g e t S i ze () topLong ( )
1);
{
const
return
getLong ( g e t S i z e () topFloat ()
1);
{
jfloat
const
return
getFloat ( g e t S i z e () topDouble ( )
1);
{
jdouble
const
return
getDouble ( g e t S i z e ()
1);
const {
jretAddr
topReturnAddress ( )
return
getReturnAddress ( g e t S i z e () topReference () const {
1);
return
getReference ( g e t S i z e ()
1);
pushInt ( j i n t ) ; pushLong ( j l o n g ) ;
264
Apndice C.
void void void void
pushFloat ( j f l o a t ) ; pushDouble ( j d o u b l e ) ; pushReturnAddress ( jretAddr ) ; pushReference ( j r e f ) ;
/ Iterador pila , del valores . que El permite en iterador recorrer los no todos los elementos tamaos en la de pila de sus a mitad la teniendo cuenta distintos cambios
soporta
recorrido . de uso : {
Ejemplo it while ... i t ++; }
= s t a c k . getIteratorUpDown ( ) ; ( ! i t . end ( ) ) s t a c k . getType ( i t ) ;
/
class CIterator { {} const { return cont ; } public : CIterator () operator bool protected : COperandStack bool int up2down ; cont ; class COperandStack ; C I t e r a t o r& o p e r a t o r ++( i n t ) ; int () end ( ) ;
stack ;
friend }; //
class
CIterator
CIterator CIterator / Interface
getIteratorUpDown ( ) ; getIteratorDownUp ( ) ;
observador {
de
cambios
de
la
pila
de
operandos .
/
class / Observer public :
F u n c i n l l a m a d a d e s p u s d e un @param s t a c k P i l a c a m b i a d a . /
virtual / void push ( c o n s t
push .
COperandStack &s t a c k ) = 0 ;
F u n c i n l l a m a d a d e s p u s d e un @param s t a c k P i l a c a m b i a d a . /
virtual }; // class void pop ( c o n s t Observer
pop .
COperandStack &s t a c k ) = 0 ;
265
/ Aade un @param @return nuevo true si observer Nuevo fue todo de la pila . newObserver observador . bien . newObserver ) ;
/
bool / Elimina @param @return un observer . Observer fue que ser eliminado . si todo bien . oldObserver ) ; oldObserver true addObserver ( Observer
/
bool removeObserver ( Observer
protected : struct jint }; void void /// void /// void int push ( c h a r get ( char Enva el OperandContent cont ; type ; {
JVMType
data data ,
int int
size , size , a
JVMType int pos ) los
type ) ; const ;
evento
" push "
todos
observers
emitPush ( ) Enva el
const ; " pop " a todos los observers
evento
emitPop ( ) length ;
const ;
s t d : : v e c t o r <O per and Con ten t>
stack ; observers ;
s t d : : l i s t </ COperandStack : : / O b s e r v e r > }; COperandStack : : COperandStack ( ) } int } JVMType COperandStack : : g e t T y p e I n T o p ( ) return } JVMType COperandStack : : g e t T y p e ( i n t if ( ( 0 <= p o s ) return } || s t a c k [ pos ] . type ; pos ) stack [ length const COperandStack : : g e t S i z e ( ) return length ; const { : length (0)
1]. type ;
const
( pos < l e n g t h ) )
r e t u r n JJVM : : TYPE_ERROR;
266
Apndice C.
//
n a m e s p a c e JJVM
#e n d i f / @file O p e r a n d S t a c k . cpp de la clase que implementa la pila de operandos
Implementacin de l a JVM. Marco
@au thor
Antonio
Gmez
Martn
Pedro
Pablo
Gmez
Martn
/
#i n c l u d e #i n c l u d e " OperandStack . h" "JVMTypes . h " // memcpy ( . . . )
#i n c l u d e <memory> using n a m e s p a c e JJVM ;
// // MTODOS POP // jint COperandStack : : p o p I n t ( ) d; { jint
d = getInt ( length length
1);
s t a c k . pop_back ( ) ; emitPop ( ) ; return } jlong COperandStack : : popLong ( ) d; { jlong length d;
d = getLong ( l e n g t h
1);
=2;
s t a c k . pop_back ( ) ; s t a c k . pop_back ( ) ; emitPop ( ) ; return } // Omitidos popFloat , popDouble , popReturnAddress y popReference d;
// // MTODOS GET // jint COperandStack : : g e t I n t ( i n t d; s i z e o f (d) , pos ) ; d; pos ) const { jint
g e t ( ( c h a r )&d , return } // Omitidos
getLong ,
getFloat ,
getDouble ,
getReturnAddress
267
//
getReference
// // MTODOS PUSH // void } // // Omitidos y pushLong , pushFloat , pushDouble , pushReturnAddress COperandStack : : p u s h I n t ( j i n t d) {
p u s h ( ( c h a r )&d ,
s i z e o f ( d ) , TYPE_INT ) ;
pushReference
// // OTROS MTODOS // COperandStack : : C I t e r a t o r CIterator i t . stack = it ; this ; COperandStack : : g e t I t e r a t o r U p D o w n ( ) {
i t . up2down = t r u e ; i t . cont = length return } // it ;
1;
getIteratorUpDown COperandStack : : g e t I t e r a t o r D o w n U p ( ) {
COperandStack : : C I t e r a t o r CIterator i t . stack = if it ; this ; false ;
i t . up2down = i t . cont = else else if
( l e n g t h == 0 )
1;
( g e t T y p e S i z e ( g e t T y p e ( 0 ) ) == 8 )
i t . cont = 1 ; i t . cont = 0 ; return } // it ;
getIteratorDownUp COperandStack : : a d d O b s e r v e r ( Observer newObserver ) {
bool
o b s e r v e r s . push_back ( n e w O b s e r v e r ) ; return } // true ;
addObserver COperandStack : : r e m o v e O b s e r v e r ( Observer oldObserver ) {
bool
o b s e r v e r s . remove ( o l d O b s e r v e r ) ;
268
Apndice C.
return } //
true ;
removeObserver
// // MTODOS PROTEGIDOS // void COperandStack : : p u s h ( c h a r ( size != 0) { aux ; size > : s i z e o f ( aux . c o n t ) size ; data , toCopy ) ; ?
data
int
size ,
JVMType
type )
while
OperandContent int toCopy =
s i z e o f ( aux . c o n t )
memcpy ( ( c h a r )& aux . c o n t , aux . t y p e = t y p e ; s t a c k . push_back ( aux ) ; l e n g t h ++; size } emitPush ( ) ; } void if COperandStack : : g e t ( c h a r
toCopy ;
d a t a += toCopy ;
data
int {
size ,
int
pos )
const
( ( 0 <= p o s ) && ( p o s < l e n g t h ) ) int pos numPos = ( s i z e
1)/4;
numPos ; ( size != 0) { aux = s t a c k [ p o s ] ; size > : s i z e o f ( aux . c o n t ) size ; toCopy ) ; ?
while
OperandContent int toCopy =
s i z e o f ( aux . c o n t ) memcpy ( d a t a , size } } } // get d a t a += toCopy ;
( c h a r )& aux . c o n t ,
toCopy ;
p o s ++;
void
COperandStack : : e m i t P u s h ( )
const
{ it =
s t d : : l i s t <COperandStack : : O b s e r v e r > : : c o n s t _ i t e r a t o r observers . begin ( ) ; while ( it != o b s e r v e r s . end ( ) ) {
269
( i t )>p u s h ( t h i s ) ; ++i t ; } } // emitPush COperandStack : : emitPop ( ) observers . begin ( ) ; while ( it != o b s e r v e r s . end ( ) ) { const { it =
void
s t d : : l i s t <COperandStack : : O b s e r v e r > : : c o n s t _ i t e r a t o r
( i t )>pop ( t h i s ) ; ++i t ; } } // emitPop
// // Implementacin COperandStack : : C I t e r a t o r // COperandStack : : C I t e r a t o r& COperandStack : : C I t e r a t o r : : o p e r a t o r ++( i n t ) if ( ! end ( ) ) if cont else if { ( ! end ( ) && (JJVM : : g e t T y p e S i z e ( s t a c k >g e t T y p e ( c o n t ) ) == 8 ) ) c o n t ++; } } return } bool if COperandStack : : C I t e r a t o r : : end ( ) ( up2down ) return else return } c o n t >= s t a c k >g e t S i z e ( ) ; c o n t == { { JJVM : : g e t T y p e S i z e ( s t a c k >g e t T y p e ( c o n t ) ) / 4; ( up2down ) {
c o n t ++;
this
1;
Bibliografa
Como un ganso desplumado y esculido, me preguntaba a m mismo con voz indecisa si de todo lo que estaba leyendo hara el menor uso alguna vez en la vida.
James Clerk Maxwell, sobre su educacin en Cambridge

Abbattista, F., Degemmis, M., Fanizzi, N., Licchelli, O., Lops, O., Semeraro, G. y Zambetta, F. Learning user proles for content-based
ltering in e-commerce. En
e Applicazioni . Edition) .
Workshop Apprendimento Automatico: Metodi
Sienna, Italia, 2002.
Abrash, M. Michael Abrash's Graphics Programming Black Book (Special

Coriolis Group Books, 1997. ISBN 1-576-10174-6.
Adobe.
Macromedia authorware 7. 2006. Disponible en
com/products/authorware/
1999. Disponible en
http://www.adobe.
(ltimo acceso, Agosto, 2007).
Adolph, S.
Whatever happened to reuse?
Software Development magazine , http://www.ddj.com/dept/architect/184415752
Advanced Distributed Learning (ADL),
editor. Sharable Content Object Reference Model (SCORM) 2004, 2nd Edition, Overview . ADL CoLaboratory, 2004. Disponible en http://www.adlnet.gov/ (ltimo acceso, Agosto, 2007).
Agile Alliance.
nible en
Manifesto for agile software development. 2001. Dispo(ltimo acceso, Agosto, 2007).
http://agilemanifesto.org
Alderman, D. L.
Evaluation of the TICCIT computer-assisted instructio-
nal system in the community college. pginas 517, 1979. ISSN 01635735.
ACM SIGCUE Bulletin ,
vol. 13(3),
Alexandrescu, A. Modern C++ Design: Generic Programming and Des-
ign Patterns Applied .

431-5.
Addison-Wesley Professional, 2001. ISBN 0-20170-
271
272
Bibliografa
Amsoft.
El laberinto del sultan (ttulo original, Sultan's maze). 1984. Virtual agent
Anastassakis, G., Panayiotopoulos, T. y Ritchings, T.

societies with the mVITAL intelligent agent system. En
Proceedings of the Third International Workshop on Intelligent Virtual Agents (IVA'01) (editado por A. de Antonio, R. Aylett y D. Ballin), vol. 2190 de Lecture Notes in Articial Intelligence (subserie de LNCS) , pginas 210223. SpringerVerlag, 2001a. y
Anastassakis, G., Ritchings, T.
Proceedings of the Joint German/Austrian Conference on Articial Intelligence (editado por F. Baader, G. Brewka y T. Eiter), vol. 2174 de Lecture Notes in Computer Science , pginas 381395. Springer-Verlag, 2001b.
agent systems as intelligent virtual environments. En y
Panayiotopoulos, T.
Multi
de Antonio, A., Ramrez, J., Imbert, R.
4th International Central and Eastern European Conference on Multi-Agent Systems (editado por M. Pechoucek, P. Petta y L. Z. Varga), vol. 3690 de Lecture Notes in Computer Science , pginas 8291. Springer-Verlag, 2005. ISBN
tual environments for training: An agent-based approach. En 3-540-29046-X.
Mndez, G.
Intelligent vir-
de Antonio, A., Ramrez, J., Imbert, R., Mndez, G. y Aguilar, R. A. A software architecture for intelligent virtual environments applied to education.
Taracap ,
2001.
Revista de la Facultad de Ingeniera, Universidad de

Publicado por Flipcode,
vol. 13(1), 2004. ISSN 0717-1072. Main loop with xed time steps.
Arvalo, J.
Disponible en
cgi?show=63823
Arvalo, J.
http://www.flipcode.org/cgi-bin/fcarticles.
(ltimo acceso, Octubre, 2006).
Videojuegos: Arte, diversin, ingeniera, negocio. Charla im-
partida en la Facultad de Informtica de la Universidad Comlutense de Madrid, 2005. Disponible en
2005UCMVideojuegos.zip
Arvalo, J.
http://www.iguanademos.com/Jare/docs/
Desarrollo de videojuegos. Charla impartida en la Universidad
http://www.iguanademos. com/Jare/docs/UPC2006-DesarrolloDeVideojuegos.ppt (ltimo accePolitcnica de Catalua, 2006. Disponible en y
so, Agosto, 2007).
Astrachan, O., Mitchener, G., Berry, G.
En Proceedings of the twenty-ninth SIGCSE technical symposium on Computer science education (SIGCSE'98) , pginas 153160. ACM Press, New York, NY, USA, terns: an essential component of CS curricula. 1998. ISBN 0-89791-994-7.
Cox, L.
Design pat-
Bibliografa Aylett, R. Cavazza, M.
273
Intelligent virtual environments - A state-ofManchester, UK, 2001.
the-art report. En
Eurographics Conference .
Aylett, R.
Luck, M.
Applying articial intelligence to virtual reality:
Intelligent virtual environments. pginas 332, 2000.
Applied Articial Intelligence , vol. 14(1),

y
Bares, W. H., Zettlemoyer, L. S.
Proceedings of the 4th International Conference on Intelligent Tutoring Systems (ITS'98) , pginas
learning environments for situated learning. En 7685. Springer-Verlag, London, UK, 1998. ISBN 3-540-64770-8. y
Lester, J. C.
Habitable 3D
Bass, L., Clements, P.
Practice .
Kazman, R.,
editores.
Software Architecture in
AddisonWesley, 2003. y
Bellifemine, F., Poggi, A.
Rimassa, G.
Developing multi-agent sys-
tems with a FIPA-compliant agent framework.
Experience ,
Software - Practice And
vol. 31(2), pginas 103128, 2001a. y
Bellifemine, F., Poggi, A.
Rimassa, G.
JADE: a FIPA2000 compliant
agent development environment. En
conference on Autonomous agents ,

ISBN 1-58113-326-X.
Proceedings of the fth international
pginas 216217. ACM Press, 2001b.
Bilas, S. Game Programming Gems , BioWare-Corp.

pack). 2002.
captulo A generic function-binding
interface, pginas 5667. Charles River Media, 2000. ISBN 1-58450-049-2. NeverWinter Nights + Shadow of Undrentide (expansion
Birkhoff, G. Lattice Theory . du Boucher-Ryan, P.
American Mathematical Society, tercera
edicin, 1973. ISBN 0-821-81025-1. y
AI-2005, the XXV SGAI International Conference on Innovative Techniques and Applications of Articial Intelligence
formal concept analysis. En (editado por M. Bramer, F. Coenen y T. Allen), pginas 205218. Springer, Cambridge, UK, 2005. ISBN 978-1-84628-225-6.
Bridge, D.
Collaborative recommending using
Bourg, D. M.
5.
Seemane, G. AI for Game Developers ,
captulo Rule-
Based AI, pginas 212227. Charles River Media, 2004. ISBN 0-596-00555-
Braude, E. J. Software Engineering. An Object-Oriented Perspective .

Wiley & Sons, Inc., 2001.
John
Brock, K.
position.
Mensaje en sweng-gamedev: Strategies/patterns for com2006. Disponible en
http://lists.midnightryder.
274
Bibliografa
com/pipermail/sweng-gamedev-midnightryder.com/2006-October/ 006087.html (ltimo acceso, Noviembre, 2006).

Brusilovsky, P.
Student model centered architecture for intelligent learEn ning environment.
4th International Conference on User Modeling ,
pginas 3136. Hyannis, MA, USA, 1994.
Brusilovsky, P.
Intelligent learning environments for programming: The En
case for integration and adaptation. por J. Greer), pginas 18. 1995.
Proceedings of the 7th World Conference on Articial Intelligence in Education (AI-ED'95) (editado
Adaptive hypermedia.
Brusilovsky, P.
Interaction ,
User Modeling and User-Adapted
vol. 11, pginas 81110, 2001. y
Burton, R. R.
Brown, J. S.
An investigation of computer coaching
for informal learning activities. En England, 1982.
Intelligent Tutoring Systems
(editado
por D. Sleeman y J. S. Brown), pginas 7998. Academic Press, London,
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Sommerlad, P. y Stal, M. Pattern-Oriented Software Architecture ,
vol. 1: A System of Patterns. John Wiley and Sons, primera edicin, 1996.
Carbonell, J. R.
AI in CAI: an articial intelligence approach to
computer-assisted instruction.
tems ,
IEEE Transactions on Man-Machine SysA lattice conceptual clustering system and
vol. 11(4), pginas 190202, 1970. y
Carpineto, C.
95122, 1996.
Romano, G.
its application to browsing retrieval.
Machine Learning , vol. 24(2), pginas
Cassell, J., Bickmore, T. W., Campbell, L., Vilhjlmsson, H. H. y Yan, H. More than just a pretty face: conversational protocols and
the aordances of embodiment. pginas 5564, 2001.
Knowledge-Based Systems ,
vol. 14(1-2),
Charles, D.
Proceedings of the International Conference on Computer Games: Articial Intelligence, Design and Education ,
player-centric digital games. En pginas 2935. 2004.
Black, M.
Dynamic player modelling: A framework for
Charles, D., McNeill, M., McAlister, M., Black, M., Moore, A., Stringer, K., Kcklich, J. y Kerr, A. Player-centred game design:
Player modelling and adaptive digital games. En Proocedings of Digital Games Research Association (DIGRA) Conference: Changing Views Worlds in Play . 2005.
Bibliografa Chittaro, L. Ranon, R.
275
Dynamic generation of personalized VRML En
content: a general approach and its application to 3D e-commerce. pginas 145154. ACM Press, 2002. ISBN 1-58113-468-1.
Proceeding of the seventh international conference on 3D Web technology ,

Collins-Sussman, B., Fitzpatrick, B. W.
y
Control with Subversion .

y 2005.
Pilato, C. M. Version
O'Reilly, 2004. ISBN 0-596-00448-6. Declarative versus imperative paradigms
Combs, N.
Ardoint, J.-L.
in games AI.
Disponible en
WS04-04NCombs.pdf
ISBN 0-078-81117-1.
http://www.roaringshrimp.com/
Mcgraw-Hill, 1984.
Crawford, C. The Art of Computer Game Design .

Disponible en
http://www.vancouver.wsu.edu/ fac/peabody/game-book/Coverpage.html (ltimo acceso, Agosto, 2007).

New Riders Games, 2003. ISBN 0-131-46099-4.
Crawford, C. Chris Crawford on Game Design . Crytek. CryEngine Sandbox - Far Cry Edition . Crytek Studios. Davey, B. A.
y Far Cry. 2004.
Crytek GmbH, 2004.
Priestley, H. A. Introduction to Lattices and Order .
Cambridge University Press, segunda edicin, 2002. ISBN 0-521-36766-2.
Davis, R.
Diagnostic reasoning based on structure and behavior.
Intelligence ,
Articial
vol. 24(1-3), pginas 347410, 1984. ISSN 00043702.
Dawson, B. Game Programming Gems 2 , captulo Micro-Threads for Game

Object AI, pginas 258254. 50054-9. Charles River Media, 2001. ISBN 1-584-
DeLoura, M.,
editor.
Game Programming Gems . Game Programming Gems 2 .
Charles River Media,
2000. ISBN 1-584-50049-2.
DeLoura, M.,
editor.
2001. ISBN 1-584-50054-9.
Devedzic, V.
y Harrer, A. Software patterns in ITS architectures. International Journal of Articial Intelligence in Education , vol. 15, pginas 6394, 2005. ISSN 15604306.
Devedzic, V., Radovic, D.
Jerinic, L.
On the notion of components
for intelligent tutoring systems. En
lligent Tutoring Systems (ITS'98) Science ,
4th International Conference on InteLecture Notes in Computer
(editado por B. P. Goettl, H. M. Hal,
C. L. Redeld y V. J. Shute), vol. 1452 de
pginas 504513. Springer-Verlag, 1998. ISBN 3-540-64770-8.
276
Bibliografa Pople, H. E.
Dhar, V.
Rule-based versus structure-based models for
explaining and generating expert behavior.
Communication ACM ,
vol.
30(6), pginas 542555, 1987. ISSN 00010782.
Daz Agudo, B., Gmez Martn, M. A., Gmez Martn, P. P. y Gonzlez Calero, P. A. Formal concept analysis for knowledge renement
in case based reasoning. En
AI-2005, the XXV SGAI International Conference on Innovative Techniques and Applications of Articial Intelligence
(editado por M. Bramer, F. Coenen y T. Allen), pginas 233245. Springer, 2005. ISBN 978-1-84628-225-6.
Dickheiser, M., editor. Game Programming Gems 6 .

2006. ISBN 1-584-50450-1.
Dijkstra, E. W.
A note on two problems in connexion with graphs. vol. 1, pginas 269271, 1959.
merische Mathematik ,
Nu-
Dinamic.
Don quijote. 1987. y
Dougiamas, M.
create an open source course management system. En World Conference on Educational Multimedia, Hypermedia and Telecommunications (editado por P. Kommers y G. Richards), pginas 171178. 2003.
Taylor, P.
Moodle: Using learning communities to
Duffy, J.
mortem.
Postcard from the Montreal game summit: Call of duty 2 post2005. Disponible en
20051104/duffy_01.shtml
Duquenne, V.
y
http://www.gamasutra.com/features/
(ltimo acceso, Agosto, 2007). Famille minimale dmplication informatives
Guigues, J.
rsultant dn tableau de donnes binaries.
Humaines ,
Mathmatiques et Sciences
captulo A Finite-State
vol. 24(95), 1986.
Dybsand, E.
AI Game Programming Wisdom ,
Machine Class. Charles River Media, 2002. ISBN 1-584-50077-8.
Eberly, D. H. 3D Game Engine Design: A Practical Approach to Real-
Time Computer Graphics .
Morgan Kaufmann, 2000. ISBN 1-558-605932.
Eberly, D. H. 3D Game Engine Architecture: Engineering Real-Time Ap-
plications with Wild Magic . Morgan Kaufmann, 2004. ISBN 0-122-29064X.

de ejecucin. Prentice Hall, 2003.
Eckel, B. Piensa en Java ,
captulo 12, Identicacin de tipos en tiempo
Eisenbarth, T., Koschke, R.

code. 210224, 2003.
IEEE Transactions on Software Engineering ,
Simon, D.
Locating features in source vol. 29(3), pginas
Bibliografa
277
Eladhari, M. Object Oriented Story Construction in Story Driven Compu-
ter Games .
Proyecto Fin de Carrera, Department of History of Literature
and History of Ideas, Stockholm University, 2002.
Ensemble-Studios.
nible en
Age of empires II: The age of king.
1999.
Dispo-
http://www.microsoft.com/latam/juegos/Age2/default.asp
Unreal tournament. 1999. y
(ltimo acceso, Marzo, 2007).
Epic Games.
de Figueiredo, L. H., Celes, W.
gramming Gems 6 ,
Ierusalimschy, R. Game Pro-
captulo Programming advanced control mechanisms
with Lua coroutines, pginas 357370. Charles River Media, 2006. ISBN 1-584-50450-1.
Finkel, R. A.
0001-5903.
Bentley, J. L.
Quad trees: A data structure for retrieval vol. 4(1), pginas 19, 1974. ISSN
on composite keys.
Acta Informatica ,
Fletcher, J. D.
Modeling of learner in computer-based instruction. vol. 1, pginas 118126, 1975. y
nal of Computer-Based Instruction ,
Jour-
Foley, J. D., van Dam, A., Feiner, S. K.
Graphics: Principles and Practice .

12110-7.
Hughes, J. F. Computer
ISBN 0-201-
Addison-Wesley, 1990.
Fowler, M.
Continuous integration. 2006. Disponible en http://www. martinfowler.com/articles/continuousIntegration.html (ltimo acceso, Agosto, 2007).
Franklin, S.
Third International Workshop on Agent Theories, Architectures and Languages , vol. 1193 de Lecture Notes in Computer Science , pginas 2135. Springer, 1996. ISBN 3-540-62507-0.
xonomy for autonomous agents. En JESS, the rule engine for the Java platform. 2005.
Graesser, A.
Is it an agent, or just a program? A ta-
Friedman-Hill, E.
Disponible en
http://herzberg.ca.sandia.gov/jess/docs/61/ (ltimo
acceso, Marzo, 2007).
Fristrom, J.
ponible en
Manager in a strange land: Most projects suck. 2003. Dis-
pfv.htm
Gabb, H.
ble en
http://www.gamasutra.com/features/20031017/fristrom_
Threading 3D game engine basics. 2005. Disponi-
(ltimo acceso, Agosto, 2007). y
http://www.gamasutra.com/features/20051117/gabb_01.shtml
Lake, A.
278
Bibliografa Vlissides, J. Design Patterns:

Addison-Wesley Profes-
Gamma, E., Helm, R., Johnson, R.

sional, primera edicin, 1995.
Elements of Reusable Object-Oriented Software .
Ganter, B.
dations .
Wille, R. Formal Concept Analysis: Mathematical Foun-
Springer, 1998. ISBN 3-540-62771-5. captulo Flexible Object-
Garcs, S. AI Game Programming Wisdom III ,

9.
Composition Architecture. Charles River Media, 2006. ISBN 1-584-50457-
Giarratano, J. C.
CLIPS user's guide.
2002.
Disponible en
//www.ghg.net/clips/download/documentation/usrguide.pdf (ltimo
acceso, Agosto, 2007).
http:
Gillen, K.
The rst generation of the next generation: A project Gotham
racing 3 postmortem. 2005. Disponible en
features/20050906/gillen_01.shtml
Giraffa, L. M. M.
y
http://www.gamasutra.com/
(ltimo acceso, Agosto, 2007). The use of agents techniques on
XVIII International Conference of the Chilean Computer Science Society , pginas 7683. IEEE Computer Sointelligent tutoring systems. En ciety, Los Alamitos, CA, USA, 1998. ISSN 1522-4902.
Viccari, R. M.
Gker, M. H.
Adapting to the level of experience of the user in mixed-
Workshop on Mixed Initiative Case-Based Reasoning, at the 5th International Conference on Case Based Reasoning (ICCBR'03) (editado por D. Aha). 2003.
initiative web self-service applications. En y
Gker, M. H.
recommendation. En
Advances in Case-Based Reasoning. Proceedings of the 8th European Workshop on Case-Based Reasoning (EWCBR'00) (editado por E. Blanzieri y L. Protinale), vol. 1898 de Lecture Notes in Articial Intelligence (subserie de LNCS) . Springer, 2000. ISBN 3-540-67933-2.
y
Thompson, C. A.
Personalized conversational case-based
Gmez Gaucha, H., Daz Agudo, B.

peraments. En 2006.
Gonzlez Calero, P. A.
Automatic personalization of the human computer interaction using tem-
Proceedings of the 15th Int. Florida Articial Intelligence Research Society Conference (FLAIRS'06) . AAAI Press, Florida, USA,
Gmez Martn, M. A. y Daz Agudo, B.
Evaluacin de estrategias de ra-
zonamiento para sistemas basados en reglas. En
de Enseanza Universitaria de la Informtica ,

Thomson, 2006. ISBN 84-9732-545-1.
JENUI'06: XII Jornadas
pginas 303310. Editorial
Bibliografa Gmez Martn, M. A. Gmez Martn, P. P.
279
Uso de aplicaciones de
ejemplo en las clases de informtica grca. En
de Enseanza Universitaria de la Informtica ,

Thomson, 2005. ISBN 84-9732-421-8.
JENUI'05: XI Jornadas
pginas 421428. Editorial
Gmez Martn, M. A., Gmez Martn, P. P. y Gonzlez Calero, P. A. Aprendizaje basado en juegos. La Revista Icono 14 , (4), 2004a.
ISSN 1697-8293.
Gmez Martn, M. A., Gmez Martn, P. P. y Gonzlez Calero, P. A. Game-driven intelligent tutoring systems. En Entertainment Com-
puting, Third International Conference (ICEC'04) (editado por M. Rauterberg), vol. 3166 de Lecture Notes in Computer Science , pginas 108
113. Springer, 2004b. ISBN 3-540-22947-7.
Gmez Martn, M. A., Gmez Martn, P. P. y Gonzlez Calero, P. A. Game-based learning as a new domain for case-based reasoning.
En
1st Workshop on Computer Gaming and Simulation Environments, at 6th International Conference on Case-Based Reasoning (ICCBR) (editado
por D. W. Aha y D. Wilson), pginas 175184. Chicago, IL, US, 2005a.
Gmez Martn, M. A., Gmez Martn, P. P. y Gonzlez Calero, P. A. Dynamic binding is the name of the game. En Entertainment Com-
puting (ICEC 2006), 5th International Conference (editado por R. Harper, M. Rauterberg y M. Combetto), vol. 4161 de Lecture Notes in Computer Science , pginas 229232. Springer, 2006a. ISBN 978-3-540-45259-1. ISSN
0302-9743.
Gmez Martn, M. A., Gmez Martn, P. P. y Gonzlez Calero, P. A. Aprendizaje activo en simulaciones interactivas. Revista Iberoame-
ricana de Inteligencia Articial ,
vol. 11(33), pginas 2536, 2007a.
Gmez Martn, M. A., Gmez Martn, P. P. y Gonzlez Calero, P. A. Data driven software architecture for game-based learning systems.
En
Learning with Games
(editado por M. Taisch y J. Cassina), pginas
229236. 2007b. ISBN 978-88-901168-0-3.
Gmez Martn, M. A., Gmez Martn, P. P., Gonzlez Calero, P. A. y Daz Agudo, B. Adjusting game diculty level through formal
concept analysis. En
AI-2006, the XXVI SGAI International Conference on Innovative Techniques and Applications of Articial Intelligence (editado por M. Bramer, F. Coenen y T. Allen), pginas 217230. Springer, 2006b. ISBN 978-1-84628-662-9.
Gmez Martn, M. A., Gmez Martn, P. P., Gonzlez Calero, P. A. y Jimnez Daz, G. JV2 M, un sistema de enseanza de la compilacin de Java. En
I Simposio Nacional de Tecnologas de la Informacin
280
Bibliografa
y de las Comunicaciones en la Educacin, SINTICE 2005

437-4.
(editado por
M. Ortega Cantero), pginas 259266. Thomson, 2005b. ISBN 84-9732-
Gmez Martn, M. A., Gmez Martn, P. P.
Jimnez Daz, G.
Integrating a support tool infrastructure in development courses. En te de publicacin, 2007c.
International Symposium on Computers in Education (SIIE'07) . Pendien-
9th
Gmez Martn, M. A., Gmez Martn, P. P., Palmier Campos, P. y Gonzlez Calero, P. A. Not yet another visualization tool: Learning compilers for fun. En
Education (SIIE'06)
8th International Symposium on Computers in
(editado por L. Panizo Alonso, L. Snchez Gonzlez,
B. Fernndez Manjn y M. Llamas Nistal), pginas 264271. Universidad de Len, Len, Spain, 2006c. ISBN 84-9773-301-0.
Gmez Martn, P. P. Modelo de enseanza basado en casos: de los tutores
inteligentes a los videojuegos .

y
Tesis Doctoral, Facultad de Informtica,
Universidad Complutense de Madrid, 2007.
Gmez Martn, P. P.
Proceedings of the 11th annual SIGCSE conference on Innovation and technology in computer science education (ITiCSE'06) , pginas 250254. ACM Press, New
lopment to demonstrate computer graphics concepts. En York, USA, 2006. ISBN 1-59593-055-8.
Gmez Martn, M. A.
Fast application deve-
Gmez Martn, P. P., Gmez Martn, M. A., Daz Agudo, B. y Gonzlez Calero, P. A. Opportunities for CBR in learning by doing.
En
Proceedings of Case-Based Reasoning Research and Development, 6th International Conference on Case-Based Reasoning, ICCBR 2005 (editado por H. Muoz Avila y F. Ricci), vol. 3620 de Lecture Notes in Articial Intelligence, subseries of LNCS , pginas 267281. Springer, Chicago, IL,
US, 2005c. ISBN 978-3-540-28174-0.
Gmez Martn, P. P., Gmez Martn, M. A. y Gonzlez Calero, P. A. Javy: Virtual Environment for Case-Based Teaching of Java Virtual
Machine. En
7th International Conference, Knowledge-Based Intelligent Information and Engineering Systems (KES 2003) , vol. 2773 de Lecture Notes in Articial Intelligence, subseries of LNCS , pginas 906913.
Springer, 2003. ISBN 3-540-40803-7. y
Gmez Martn, P. P., Gmez Martn, M. A. P. A. Learning-by-doing through metaphorical
simulation. En 9th International Conference, Knowledge-Based Intelligent Information and Engineering Systems, KES 2005 (editado por R. Khosla, R. J. Howlett y L. C. Jain), vol. 3682 de Lecture Notes in Articial Intelligence, subseries
Gonzlez Calero,
Bibliografa
281
of LNCS ,
pginas 5564. Springer, Melbourne, Australia, 2005d.
ISBN
978-3-540-28895-4. ISSN 0302-9743.
Gmez Martn, P. P., Gmez Martn, M. A., Gonzlez Calero, P. A. y Palmier Campos, P. Using metaphors in game-based education.
En
Technologies for E-Learning and Digital Entertainment. Second International Conference of E-Learning and Games (Edutainment'07) (editado
por K. chuen Hui, Z. Pan, R. C. kit Chung, C. C. Wang, X. Jin, S. Gbel y E. C.-L. Li), vol. 4469 de
Lecture Notes in Computer Science ,
pginas
477488. Springer-Verlag, 2007d. ISBN 3-540-73010-9.
Gonzlez Calero, P. A., Gmez Martn, P. P. y Gmez Martn, M. A. Nuevas tecnologas, nuevas oportunidades. Comunicacin y Peda-
goga ,
vol. 216, pginas 7176, 2006. ISSN 1136-7733. y
Goodman, B., Soller, A., Linton, F.
Gaimari, R.
Encouraging stu-
dent reection and articulation using a learning companion.
Journal of Articial Intelligence in Education ,

1998.
International
vol. 9, pginas 237255,
Gosling, J., Joy, B., Steele, G.
Specication .
Bracha, G. The Java Language
Prentice Hall, 3rd edicin, 2005. ISBN 0-321-146780.
Graepel, T., Herbrich, R.
y Gold, J. Learning to ght. En International Conference on Computer Games: Articial Intelligence, Design and Education (CGAIDE 2004) (editado por Q. Mehdi, N. Gough, S. Natkin y D. Al-Dabass), pginas 193200. Microsoft Campus, 2004.
Grieg, S., Muzyka, R., Ohlen, J., Ohlen, T.

mortem: Bioware's neverwinter nights. ceso, Agosto, 2007). 2002.
Zeschuk, G.
Disponible en
Post-
//www.gamasutra.com/features/20021204/grieg_pfv.htm
Gygax, G.
1974. y
http:
(ltimo ac-
Arneson, D. Dungeons & Dragons .
Tactical Studies Rules,
Hao, W. D.
nible en
Postmortem: Tom Clancy's splinter cell.
2003.
Dispo-
pfv.htm
http://www.gamasutra.com/resource_guide/20030714/hao_
y
Hayes-Roth, B.
and Multi-Agent Systems ,
Doyle, P.
Animate characters.
Autonomous Agents
vol. 1(2), pginas 175204, 1998.
Heffernan, N. T. Intelligent Tutoring Systems have Forgotten the Tutor:
Adding a Cognitive Model of Human Tutors .
Tesis Doctoral, School of
Computer Science, Carnegie Mellon University, Pittsburgh, EEUU, 2001.
282
Bibliografa Nakhaeizadeh, G.
Hipp, J., Gntzer, U.
Algorithms for association
rule mining - a general survey and comparison.
tions Newsletter ,
ACM SIGKDD ExploraSTEAMER: An interacti-
vol. 2(1), pginas 5864, 2000. ISSN 1931-0145. y
Hollan, J. D., Hutchins, E.

pginas 1527, 1984.
Weitzman, L.
ve inspectable simulation-based training system.
AI Magazine ,
vol. 5(2),
Hollnagel, E.
The phenotype of erroneous actions.
of Man-Machine Studies ,
International Journal
vol. 39(1), pginas 132, 1993. ISSN 0020-7373. captulo Player Mode-
Houlette, R. AI Game Programming Wisdom II ,

ling for Adaptive Games, pginas 557566. ISBN 1-584-50289-4.
Charles River Media, 2004.
Houlette, R.
Fu, D. AI Game Programming Wisdom II ,
captulo The ISBN
Ultimate Guide to FSMs in Games. 1-584-50289-4.
Huebner, R. Huebner, R.
Using java as an embedded game scripting language. 1999. Postmortem of Nihilistic software's Vampire: The masquerade
redemption. 2000. Disponible en
20000802/huebner_pfv.htm
mentation of lua 5.0.
http://www.gamasutra.com/features/
y
Ierusalimschy, R., de Figueiredo, L. H.

pginas 11591176, 2005.
Journal of Universal Computer Science ,

y
Celes, W.
The implevol. 11(7),
rence Manual .
of Lua. En
Celes, W. Lua 5.1 RefeCeles, W.
Lua.org, 2006. ISBN 8-590-37983-3. y The evolution
The Third ACM SIGPLAN of Programming Languages Conference (HOPL-III) . 2007. Writing Interactive Fiction But Couldn't Find Anyone Still Working Here to Ask . Infocom, Inc., 1989.
Methodological issues in the evaluation of intelligent tutoring
Infocom. Learning ZIL or Everything You Always Wanted to Know About
Inoue, Y.
systems. 2001.
Educational Technology Systems ,
vol. 29(3), pginas 251258,
Jimnez Daz, G., Gmez Albarrn, M., Gmez Martn, M. A. y Gonzlez Calero, P. A. Software behaviour understanding supported by dynamic visualization and role-play. pginas 5458, 2005a. ISSN 0097-8418.
SIGCSE Bulletin ,
vol. 37(3),
Bibliografa
283
Jimnez Daz, G., Gmez Albarrn, M., Gmez Martn, M. A. y Gonzlez Calero, P. A. Understanding object-oriented software through virtual role-play.
En ICALT'05: Proceedings of the 5th IEEE International Conference on Advanced Learning Technologies , pginas 875 877. IEEE Computer Society Press, Los Alamitos, California, USA, 2005b. ISBN 0-7695-2338-2.
Jimnez Daz, G., Gmez Albarrn, M., Gmez Martn, M. A. y Gonzlez Calero, P. A. ViRPlay: Playing roles to understand dynamic
behavior. En 9th Workshop on Pedagogies and Tools for the Teaching and Learning of Object Oriented Concepts, at 19th European Conference on Object Oriented Programming (ECOOP) . 2005c. y
Johnson, W. L., Rickel, J., Stiles, R.
Munro, A.
Integrating pe-
dagogical agents into virtual environments.
Virtual Environments ,
Presence: Teleoperators and

Animated pedagogical
vol. 7(6), pginas 523546, 1998. y
Johnson, W. L., Rickel, J. W.
International Journal of Articial Intelligence in Education , vol. 11, pginas

agents: face-to-face interaction in interactive learning environments. 4778, 2000. y
Lester, J. C.
Johnson, W. L., Vilhjalmsson, H.
12th International Conference on Articial Intelligence in Education (AIED'05) . IOS Press,

language learning: How much game, how much AI. En 2005. The UM toolkit for cooperative user models.
Marsella, S.
Serious games for
Kay, J.
User-Adapted Interaction ,
editor.
User Modeling and
vol. 4(3), pginas 149196, 1995.
Kearsley, G.,
and Methods .
2002.
Articial Intelligence and Instruction. Applications Software Development magazine , http://www.ddj.com/dept/architect/184414835

2006. Disponible en
Addison-Wesley, 1987. Stop over-engineering!
Kerievsky, J.
Disponible en
Kim, J. H.
Roleplaying game page.
darkshire.net/~jhkim/rpg/
editor.
http://www.
(ltimo acceso, Agosto, 2007). Charles River Media,
Kirmse, A.,
Game Programming Gems 4 .
2004. ISBN 1-584-50295-9.
Kobsa, A.
Supporting user interfaces for all through user modeling.
En
Proceedings of the 6th International Conference on HumanComputer Interaction (HCI) , pginas 155157. 1995.
284
Bibliografa Rosenthal, D.
Kodaganallur, V., Weitz, R.
Tools for building
intelligent tutoring systems. En Proceedings of the 39th Annual Hawaii International Conference on System Sciences (HICSS'06) Track 2 , vol. 2. IEEE Computer Society, Los Alamitos, CA, USA, 2006. ISSN 1530-1605.
Kodicek, D. Mathematics and Physics for Programmers .

Media, 2005. ISBN 1-584-50330-0.
Charles River
Koedinger, K. R., Aleven, V., Heffernan, N., McLaren, B. y Hockenberry, M. Opening the door to non-programmers: Authoring in-
telligent tutor behaviour by demonstration. En Proceedings of the 7th International Conference on Intelligent Tutoring Systems (ITS'04) (editado por J. C. Lester, R. M. Vicari y F. Paraguau), vol. 3220 de Lecture Notes in Computer Science , pginas 162174. Springer-Verlag, 2004. Educational implications of analogy: A view from case-
Kolodner, J. L.
based reasoning.
American Psychologist ,
vol. 52(1), pginas 5766, 1997.
Kumar, A. N.
En
Model-based reasoning for domain modeling in a web-based
intelligent tutoring system to help students learn to debug C++ programs.
Proceedings of the 6th International Conference on Intelligent Tutoring Systems (ITS'02) (editado por S. A. Cerri, G. Gouardres y F. Paraguau), vol. 2363 de Lecture Notes in Computer Science , pginas 792801.
Springer-Verlag, 2002.
Kuznetsov, S. O.
Machine learning and formal concept analysis.
En
International Conference on Formal Concept Analysis (ICFCA'04) (editado por P. Eklund), vol. 2961 de Lecture Notes in Articial Intelligence (subserie de LNCS) , pginas 287312. Springer-Verlag, 2004. ISBN 9783-540-21043-6. y
Laird, J. E., Newell, A.

for general intelligence. 1987. ISSN 0004-3702.
Articial Intelligence ,
Rosenbloom, P. S.
SOAR: An architecture
vol. 33(1), pginas 164,
Lakos, J. Large Scale C++ Software Design .

0-201-63362-0.
Addison Wesley, 1996. ISBN
Larsen, S.
Playing the game: Managing computer game development. 2002.
Disponible en
http://www.blackwood.dk/PDF/PlayingTheGame-IE.pdf
y
Lawler, R. W.
Lawler, G. P.
Computer microworlds and reading:
an analysis for their systematic application. En
education
Articial intelligence and
(editado por R. W. Lawler y M. Yazdani), pginas 95115. Ablex
Publishing Corp., Norwood, NJ, USA, 1987.
Bibliografa Lawler, R. W. Yazdani, M.,
285
editores.
cation .
Articial Intelligence and EduCharles River Media, 2006.
Ablex Publishing, 1987.
Lengyel, E. The OpenAL Programming Guide .

ISBN 1-584-503831.
Lester, J. C., Stone, B. A.

vironments.
Stelling, G. D.
Lifelike pedagogical vol. 9(12),
agents for mixed-initiative problem solving in constructivist learning en-
User Modeling and User-Adapted Interaction ,

y
pginas 144, 1999a. ISSN 0924-1868.
Lester, J. C., Zettlemoyer, L. S., Grgoire, J. P.
Bares, W. H.
Explanatory lifelike avatars: Performing user-centered tasks in 3D learning environments. En Proceedings of the Third International Conference on Autonomous Agents . ACM Press, 1999b.
Leuf, B.
Web . tion .
Cunningham, W. The Wiki Way: Quick Collaboration on the
Addison-Wesley Professional, 2001.
Liang, S. Java(TM) Native Interface: Programmer's Guide and SpecicaPrentice Hall, 1999. ISBN 0-20132-577-2. y
Lindholm, T.
Yellin, F.
The Java Virtual Machine Specication .
Addison-Wesley Professional, 2nd edicin, 1999.
Lindig, C.
Snelting, G.
Assessing modular structure of legacy code on
mathematical concept analysis. En
Engineering (ICSE'97) ,
0-201-83454-5.
International Conference on Software

Addison Wesley, 1996. ISBN
pginas 349359. IEEE Computer Society, 1997.
Lippman, S. B. Inside the C++ Object Model . Llopis, N. Game Programming Gems 4 ,
Finger on the Pulse of the Game. 1-584-50295-9.
captulo The Clock: Keeping Your ISBN
Llopis, N. Introduction to Game Development ,
captulo Teams and Proces-
ses, pginas 163182. Charles River Media, 2005a. ISBN 1-584-50377-7.
Llopis, N. Introduction to Game Development , captulo Game Architecture,

pginas 267296. Charles River Media, 2005b. ISBN 1-584-50377-7.
LucasArts.
Grim fandango. 1998. y
Luebke, D. P.
Georges, C.
Portals and mirrors: Simple, fast evaluation
of potentially visible sets.
En
Symposium on Interactive 3D Graphics ,
pginas 105106. ACM SIGGRAPH, 1995.
286
Bibliografa
Luxenburguer, M.
1991.
Implications partielles dans un contexte.
tiques, Informatique et Sciences Humaines ,
Mathma-
vol. 113(29), pginas 3555,
Maes, P.
Agents that reduce work and information overload. vol. 37(7), pginas 3040, 1994.
tions of the ACM ,

y tutoring systems. 129153, 1993.
Communica-
Mark, M. A.
Greer, J. E.
Evaluation methodologies for intelligent
Articial Intelligence in Education , vol. 4(23), pginas

captulo An Analysis of
Martel, E. AI Game Programming Wisdom III ,

2006. ISBN 1-584-50457-9.
Far Cry: Instincts' Anchor System, pginas 555566. Charles River Media,
Martin, K.
Hoffman, B. Mastering CMake .
Kitware, Inc., 2006. ISBN
1-930-93416-5.
Martnez-Ortz, I., Moreno-Ger, P., Sierra, J. L. y FernndezManjn, B. Production and deployment of educational videogames as
assessable learning objects. En Innovative Approaches for Learning and Knowledge Sharing, First European Conference on Technology Enhanced Learning (EC-TEL 2006) (editado por W. Nejdl y K. Tochtermann), vol. 4227 de Lecture Notes in Computer Science , pginas 316330. SpringerVerlag, 2006.
Mauduit, C.
U61. 2003. Disponible en
http://www.ufoot.org/u61
(lti-
mo acceso, Agosto, 2007).
McLean, A. AI Game Programming Wisdom ,

ISBN 1-584-50077-8.
captulo An Ecient AI
Architecture using Prioritized Task Categories. Charles River Media, 2002.
Meyers, S. Eective C++: 50 Specic Ways to Improve Your Programs
and Design .
Addison Wesley, 1997. ISBN 0-201-92488-9. Lua in Grim fandango. 1999. Disponible en
Mogilefsky, B.
www.grimfandango.net/?page=articles&pagenumber=2
Diciembre, 2006). y
http://
(ltimo acceso,
Moller, T., Haines, E.
Akenine-Moller, T. Real-Time Rendering .
AK Peters, 2002. ISBN 1-568-81182-9.
Molyneux, P.
ponible en
Postmortem: Lionhead studios'black & white. 2001. Dis-
pfv.htm
http://www.gamasutra.com/features/20010613/molyneux_
Bibliografa Mnkknen, V.
ble en
287
Multithreaded game engine architectures. 2006. Disponi-
shtml
http://www.gamasutra.com/features/20060906/monkkonen_01.
y
Monsieurs, P., Coninx, K.
Flerackers, E.
1999.
Collision avoidance and
map construction using synthetic vision. En
tual Agents (Virtual Agents'99) .
Workshop on Intelligent Vir-
Moreno-Ger, P., Martnez-Ortz, I., Sierra, J. L. y FernndezManjn, B. Language-driven development of videogames: The e-game
experience. En Fifth International Conference on Entertainment Computing (ICEC 2006) (editado por R. Harper, M. Rauterberg y M. Combetto), vol. 4161 de Lecture Notes in Computer Science , pginas 153164.
Springer-Verlag, 2006. ISBN 3-540-45259-1.
Munro, A., Johnson, M. C., Pizzini, Q. A., Surmon, D. S., Towne, D. M. y Wogulis, J. L. Authoring simulation-centered tutors with
RIDES.
International Journal of Articial Intelligence in Education ,
vol.
8, pginas 284316, 1997.
Munro, A., Surmon, D. S., Johnson, M. C., Pizzini, Q. A. y Walker, J. P. An open architecture for simultaion-centered tutors. En Proceedings
of the 9th Conference on Articial Intelligence in Education (AIED'99) ,

pginas 360367. 1999. Authoring intelligent tutoring systems: An analysis of the state vol.
Murray, T.
of art.
International Journal of Articial Intelligence in Education ,

y
10, pginas 98129, 1999.
Muz vila, H.
Hoang, H. AI Game Programming Wisdom III ,
ca-
ptulo Coordinating Teams of Bots with Hierarchical Task Network Planning, pginas 417427. Charles River Media, 2006. ISBN 1-584-50457-9.
Nelson, G. The Inform's Designer Manual .
The Interactive Fiction Library
(IFLibrary.org), cuarta edicin, 2001. ISBN 0-9713119-0-0.
Nihilistic-Software. Nijholt, A.
y
Vampire: The Masquerade Redemption. 2000. Multimodal communication in inhabited virtual
Heylen, D.
environments.
International Journal of Speech Technology , vol. 5, pginas

y
343353, 2002. ISSN 1381-2416.
Obitko, M., Snasel, V.
analysis. En Proceedings of the International Workshop on Concept Lattices and their Applications (CLA'04) (editado por V. Snasel y Belohlavek), pginas 111119. VSB-Technical University of Ostrava, Dept. of Computer Science, 2004. ISBN 80-248-0597-9.
Smid, J.
Ontology design with formal concept
288
Bibliografa
Pallister, K.,
editor.

y
2005. ISBN 1-584-50352-1.
Panayiotopoulos, T., Zacharis, N.

ce in a virtual university. En
IMACS/IFAC International Symposium on Soft Computing in Engineering Applications, SOFTCOM '98 . 1998.
Machine learning in user modeling. En
Vosinakis, S.
Intelligent guidan-
Papatheodorou, C.
Learning and Its Applications
Machine
(editado por G. Paliouras, V. Karkaletsis
y C. D. Spyropoulos), vol. 2049 de
Lecture Notes in Computer Science ,
pginas 286294. Springer-Verlag, 2001. ISBN 3-540-42490-3.
Pasquier, N.
Mining association rules using formal concept analysis. En pginas
International Conference on Conceptual Structures (ICCS'2000) ,

y
259264. Shaker Verlag, 2000.
Peinado Gil, F., Gmez Martn, P. P.
Gmez Martn, M. A.
A En
game architecture for emergent story-puzzles in a persistent world. 2005.
DIGRA 2005 - Changing Views: Worlds in Play - Electronic Proceedings .

Piaget, J. The Construction of Reality in the Child .
Books, 1955. New York: Basic
Plummer, J. A Flexible and Expandable Architecture for Computer Games .

Proyecto Fin de Carrera, Arizona State University, 2004.
Polson, M.
ring Systems .
y
Richardson, J.,
editores.
Foundations of Intelligent Tuto-
Lawrence Erlbaum Associates, 1988.
Ponsen, M.
Computer Games: Articial Intelligence, Design and Education (CGAIDE'04) (editado por Q. Mehdi, N. Gough, S. Natkin y
nary learning. En captulo A High-Performance Charles
Spronck, P.
Improving adaptive game ai with evolutio-
D. Al-Dabass), pginas 389396. 2004.
Pritchar, M. Game Programming Gems 2 ,

River Media, 2001. ISBN 1-584-50054-9.
Tile-based Line-of-sight and Search System, pginas 279286.
Ravin, S.,
editor.
AI Game Programming Wisdom . AI Game Programming Wisdom II .
2002. ISBN 1-584-50077-8.
Ravin, S.,
editor.
2004. ISBN 1-584-50289-4.
Ravin, S., editor. AI Game Programming Wisdom III .

2006. ISBN 1-584-50457-9.
Bibliografa
289
Recio, J. A., Daz Agudo, B., Gmez Martn, M. A. y Wiratunga, N. Extending jCOLIBRI for textual CBR. En Proceedings of Case-
Based Reasoning Research and Development, 6th International Conference on Case-Based Reasoning, ICCBR 2005 (editado por H. Muoz-Avila y F. Ricci), vol. 3620 de Lecture Notes in Articial Intelligence, subseries of LNCS , pginas 421435. Springer, Chicago, IL, US, 2005. ISBN 978-3540-28174-0. ISSN 0302-9743.
Recio-Garca, J. A., Snchez-Ruiz, A. A., Daz-Agudo, B. y Gonzlez-Calero, P. A. jCOLIBRI 1.0 in a nutshell. a software tool for
designing cbr systems. En
Based Reasoning
Reinhart, B.
ponible en
Proccedings of the 10th UK Workshop on Case
(editado por M. Petridis), pginas 2028. CMS Press,
University of Greenwich, 2005. Postmortem: Epic games' Unreal Tournament. 2000. Dis-
pfv.htm
http://www.gamasutra.com/features/20000609/reinhart_
y
Reyes, R. L.
Sison, R. C.
CBR-Tutor: A case-based reasoning approach
to an internet agent-based tutoring system. En
on Computers in Education (ICCE'00) ,

Reynolds, C.
International Conference
En
vol. 2, pginas 14131420. 2000.
Steering behaviors for autonomous characters. pginas 763782. 1999. y
Developers Conference ,
Game
Rhalibi, A. E., Merabti, M.
multithreading and multiprocessor architecture. En Proceedings of the I International Conference on Technologies for E-Learning and Digital Entertainment (Edutainment'06) (editado por Z. Pan, R. Aylett, H. Diener, X. Jin, S. Gbel y L. Li), vol. 3942 de Lecture Notes in Computer Science , pginas 669679. Springer-Verlag, 2006.
Shen, Y.
Improving game processing in
Richter, J. Programacin avanzada en Windows .

ISBN 84-481-1160-5.
Microsoft Press, 1997.
Rickel, J.
Intelligent virtual agents for education and training: Opportu-
Proceedings of the Third International Workshop Intelligent Virtual Agents (IVA'01) (editado por A. de Antonio, R. Aylett y D. Ballin), vol. 2190 de Lecture Notes in Computer Science , pginas
nities and challenges. En 1522. Springer-Verlag, 2001. ISBN 3-540-42570-5. y
Rickel, J.
Proceedings of the Eighth World Conference on Articial Intelligence in Education , pginas 294301. IOS Press., 1997.
preliminary report. En y
Johnson, W. L.
Intelligent tutoring in virtual reality: A
Rickel, J.
a reality. En 2
Johnson, W. L.
STEVE: A pedagogical agent for virtual (editado
International Conference on Autonomous Agents
290
Bibliografa
por K. P. Sycara y M. Wooldridge), pginas 332333. ACM Press, New York, 1998. ISBN 0-89791-983-1.
Rickel, J.
Johnson, W. L.
Animated agents for procedural training in
virtual reality: Perception, cognition, and motor control.
Intelligence ,
Rickel, J.
y
Applied Articial
vol. 13, pginas 343382, 1999. Task-oriented collaboration with embodied (editado por
Johnson, W. L.
agents in virtual worlds. En
Embodied conversational agents
J. Cassell, J. Sullivan y S. Prevost), pginas 95122. MIT Press, Cambridge, MA, USA, 2000. ISBN 0-262-03278-3.
Rollings, A.
Design .
Adams, E. Andrew Rollings and Ernest Adams on Game
New Riders Games, 2003. ISBN 1-592-73001-9. y
Rollings, A.
Group, 1999.
Morris, D.
Game Architecture and Design .
Coriolis
Rollings, A. y Morris, D. Game Architecture and Design: A new edition .

New Riders Publishing, segunda edicin edicin, 2004.
Rosado, G. AI Game Programming Wisdom II ,

1-584-50289-4.
captulo Implementing
a Data-Driven Finite-State Machine. Charles River Media, 2004. ISBN
van Rossum, G. Python Reference Manual, Release 2.5 .

Foundation, 2006.
Python Software
Rozanski, N.
Stakeholders Using Viewpoints and Perspectives .

sional, 2005.
Woods, E. Software Systems Architecture: Working With

Addison Wesley Profes-
Rucker, R. Software Engineering and Computer Games .

2002. ISBN 0-201-76791-0.
Addison Wesley,
Russell, S. J.
Norvig, P. Articial Intelligence: A Modern Approach .
Prentice Hall, primera edicin, 1995. ISBN 0-13-103805-2.
Sanchez-Crespo Dalmau, D. Core Techniques and Algorithms in Game
Programming .
New Riders Games, 2003. ISBN 0-131-02009-9. y
Snchez Pelegrn, R., Gmez Martn, M. A.

CBR module for a strategy videogame.
En 1st Workshop on Computer Gaming and Simulation Environments, at 6th International Conference on Case-Based Reasoning (ICCBR) (editado por D. W. Aha y D. Wilson),
Daz Agudo, B.
pginas 217226. Chicago, IL, US, 2005.
Bibliografa Sansone, C.
291
The Search for Optimal Motivation and Performance .

2000. ISBN 0-12-619070-4. y
Harackiewicz, J. M. Intrinsic and Extrinsic Motivation:

Academic Press,
dos Santos, C. T.
28th Annual International Computer Software and Applications Conference (COMPSAC'04) ,

environment and its application in e-commerce. En
Osrio, F. S.
AdapTIVE: An intelligent virtual
vol. 1, pginas 468473. IEEE Computer Society, Los Alamitos, CA, USA, 2004a. ISSN 0730-3157.
dos Santos, C. T.
En
Osrio, F. S.
Integrating intelligent agents, user
models, and automatic content categorization in a virtual environment.
Proceedings of the 7th International Conference on Intelligent Tutoring Systems (ITS'04) (editado por J. C. Lester, R. M. Vicari y F. Paraguau), vol. 3220 de Lecture Notes in Computer Science , pginas 128139.
Springer-Verlag, 2004b.
dos Santos, C. T.
En AVI '04: Proceedings of the working conference on Advanced Visual Interfaces , pginas environment and its application in distance learning. 362365. ACM Press, New York, NY, USA, 2004c. ISBN 1-58113-867-9.
Osrio, F. S.
An intelligent and adaptive virtual
Schank, R.
Clearyv, C. Engines for Education .
Lawrence Erlbaum
Associates, Hillsdale, NJ, 1994.
Schwab, B. AI Game Engine Programming .

ISBN 1-584-50344-0.
Shaw, E., Johnson, W. L.

web. En
Proceedings of the third annual conference on Autonomous Agents ,

y
Ganeshan, R.
Pedagogical agents on the
pginas 283290. ACM Press, 1999. ISBN 1-58113-066-X.
Shaw, M.
ging Discipline .
Garlan, D. Software Architecture. Perspectives on an EmerPrentice Hall, 1996. y
da Silva, F. S. C.
Advances in Articial Intelligence, proceedings of the International Joint Conference IBERAMIA-SBIA, vol. 4140 de Lecture Notes in Computer Science , pginas 451461. Springer-Verlag, 2006. ISBN
articial intelligence. En 978-3-540-45462-5. y
Vasconcelos, W. W.
Rule schemata for game
Sleeman, D. H.
Brown, J. S.,
editores.
Intelligent Tutoring Systems .

Disponible en
Academic Press, London, 1982.
Sloan, J.
newdoom.com/newdoomfaq.php
Mull, W.
Doom 3 faq.
2003.
http://www.
292
Bibliografa
Snelting, G.
Concept lattices in software analysis.
En
me y R. Wille), vol. 3626 de
Analysis, Foundations and Applications (editado por B. Ganter, G. StumLecture Notes in Computer Science , pginas
272297. Springer-Verlag, 2005. ISBN 3-540-27891-5. y
Formal Concept
Spronck, P., Ponsen, M., Sprinkhuizen-Kuyper, I.

Adaptive game ai with dynamic scripting. pginas 217248, 2006.
Machine Learning ,
Postma, E.
vol. 63(3),
Spronck, P. H. M. Adaptive Game AI . Stone, B. A. Lester, J. C.
Tesis Doctoral, Dutch Research
School for Information and Knowledge Systems, 2005. y Dynamically sequencing an animated peda-
gogical agent. En
Readings in agents , pginas 156163. Morgan Kaufmann

Vinkavich, M.
Tactical action ocer intelligent tu-
Publishers Inc., San Francisco, CA, USA, 1998. ISBN 1-55860-495-2.
Stottler, R. H.
En Proceedings of the Industry/Interservice, Training, Simulation & Education Conference (I/ITSEC 2000) . 2000. toring system (TAO ITS). Conceptual knowledge discovery with frequent concept lattices.
Stumme, G.
Informe Tcnico FB4-Preprint 2043, TU Darmstadt, 1999.
Sweeney, T., Hendriks, M.
Prestenback, R.
Unrealscript lan-
guage reference. 2004. Disponible en
UnrealScriptReference
Sweng-Gamedev.
2002. Disponible en
http://udn.epicgames.com/Two/
Software engineering, as it applies to game development.
http://lists.midnightryder.com/listinfo.cgi/ sweng-gamedev-midnightryder.com (ltimo acceso, Agosto, 2007).

y
Tennyson, R., Christensen, D.
Park, S.
The Minnesota adaptive
instructional system: An intelligent CBI system.
Based Instruction ,
Thalmann, D.
Journal of ComputerEn
vol. 11(1), pginas 213, 1984.
The foundations to build a virtual human society.
Proceedings of the Third International Workshop Intelligent Virtual Agents (IVA'01) (editado por A. de Antonio, R. Aylett y D. Ballin), vol. 2190 de Lecture Notes in Computer Science , pginas 114. Springer-Verlag, 2001.
ISBN 3-540-42570-5. Exhibitor list. 2006. Disponible (ltimo
The Electronic Entertainment Expo.

en acceso, Mayo, 2006).
http://www.e3expo.com/exhibitors/exhibitor-list.aspx
Thompson, P. W.
Mathematical microworlds and intelligent computerEn
assisted instruction.
tions and Methods
Articial Intelligence and Instruction: Applica-
(editado por G. Kearsley), pginas 83109. Addison-
Wesley, Boston, MA, USA, 1987.
Bibliografa Tilley, T.
293
International Conference on Formal Concept Analysis (ICFCA'04) (editado por P. Eklund), vol. 2961 de Lecture Notes in Articial Intelligence (subserie de LNCS) , pginas 104111.
Tool support for FCA. En Springer-Verlag, 2004. ISBN 978-3-540-21043-6.
Tracz, W. Confessions of a Used Program Salesman: Institutionalizing
Software Reuse .
Addison Wesley, 1995a. ISBN 0201633698.
Tracz, W.
Confessions of a used-program salesman: lessons learned. En
Symposium on Software Reusability archive, Proceedings of the 1995 Symposium on Software reusability , pginas 1113. ACM Press, New York,
EEUU, 1995b. ISBN 0-89791-739-1. editor.
Treglia, D.,
2002. ISBN 1-584-50233-9.
Turner, R.
Saints Row multiprocessing architecture. 2007.
En
the Game Developers Conference (GDC'07) .

interaction with students. En
Proceedings of
Uhr, L.
Teaching machine programs that generate problems as a function of
Proceedings of the 24th National Conference ,

Real time game loop models for single-
pginas 125134. ACM Press, New York, NY, USA, 1969.
Valente, L., Conci, A. y Feij, B.

player computer games. En
Simpsio Brasileiro de Jogos para Computador e Entretenimento Digital (SBGAMES) . 2005.

Half life. 1998. Course Technology PTR, 2002.
Valve Software.
Varanese, A. Game Scripting Mastery .

ISBN 1-931-84157-8.
Vesperman, J. Essential CVS . Volition Inc.
O'Reilly, 2003. ISBN 0-596-00459-1.
Saints Row. 2006. y
Vosinakis, S., Anastassakis, G.
Proceedings of the Second International Workshopf on Intelligent Virtual Agents (IVA'99) . 1999. ISSN 1467-2154.
buted intelligent virtual agents. En y
Panayiotopoulos, T.
DIVA: Distri-
Vosinakis, S.
Panayiotopoulos, T.
Design and implementation of En (editado por
synthetic humans for virtual environments and simulation systems.
Advances in Signal Processing and Computer Technologies

gineering, pginas 315320. WSES Press, 2001a.
G. Antoniou, N. Mastorakis y O. Planlov), Electrical and Computer En-
Vosinakis, S.
Panayiotopoulos, T.
SimHuman: A platform for real-
time virtual agents with planning capabilities. En
Proceedings of the Third
294
Bibliografa
International Workshop on Intelligent Virtual Agents (IVA'01) (editado por A. de Antonio, R. Aylett y D. Ballin), vol. 2190 de Lecture Notes in Articial Intelligence (subserie de LNCS) , pginas 210223. SpringerVerlag, 2001b.
Wachsmuth, I.
versational agents.
En GW '01: Revised Papers from the International Gesture Workshop on Gesture and Sign Languages in Human-Computer Interaction , pginas 120133. Springer-Verlag, London, UK, 2002. ISBN 3-540-43678-2.
Kopp, S.
Lifelike gesture synthesis and timing for con-
Wardell, B.
http://www. stardock.com/stardock/articles/Trenches/Trenches1198.html (lFrom the trenches. 1998. Disponible en timo acceso, Agosto, 2007). Addison Wesley, tercera edicin,
Watt, A. H. 3D Computer Graphics .

1999. ISBN 0-201-39855-9.
Wenger, E. Articial Intelligence and Tutoring Systems: Computational
and Cognitive Approaches to the Communication of Knowledge .

Kaufmann, 1987. Evolve your hiearchy.
Morgan
West, M.
2006.
Game Developer , vol. 13(3), pginas 5154,
Wikipedia
(PLATO). Entrada: Plato system. Disponible en
wikipedia.org/wiki/PLATO_System
concepts .
Ordered Sets, 1982.
http://en.
Wille, R. Restructuring lattice theory: an approach based on hierarchies of
Wille, R.
En
Knowledge acquisition by methods of formal concept analysis.
Proceedings of the conference on Data analysis, learning symbolic and numeric knowledge (editado por E. Diday), pginas 365380. Nova Science
Publishers, 1989. Concept lattices and conceptual knowledge systems.
Wille, R.
and mathematics with applications ,
Computers
vol. 23(69), pginas 493515, 1992.
ISSN 0898-1221.
Wolff, K. E.
A rst course in formal concept analysis: How to understand
line diagrams.
Advances in Statistical Software ,
pginas 429438, 1993.
Wooldridge, M.
Intelligent agents. En Multiagents Systems. A Modern Approach to Distributed Articial Intelligence (editado por G. Weiss), pginas 2777. MIT Press, 1999.
Bibliografa Yannakakis, G. N. Maragoudakis, M.
295
Player modeling impact on
En Proceedings of the 10th International Conference on User Modeling (editado por L. Ardissono, P. Brna y A. Mitrovic), vol. 3538 de Lecture Notes in Articial Intelligence (subserie de LNCS) , pginas 7478. Springer-Verlag, 2005. ISBN 3-540player's entertainment in computer games. 27885-0.
Lista de acrnimos
AI . . . . . . . . . . . . . Articial Intelligence,
Inteligencia Articial Particionado binario del espacio
BSP . . . . . . . . . . . Binary Space Partitioning,
CAI . . . . . . . . . . . Computer-Aided Instruction,

nador
Enseanza asistida por orde-
CBR . . . . . . . . . . Case-based reasoning,
Razonamiento basado en casos
COTS . . . . . . . . . Component o the shelf CVS DLL

.......... ..........
Concurrent Versions System Dynamic Linking Library,

Biblioteca de Enlace Dinmico
E3
............ ..........
The Electronic Entertainment Expo Frecuently asked questions

Anlisis formal de conceptos
FAQ
FCA . . . . . . . . . . Formal Concept Analysis, FPS . . . . . . . . . . . First Person Shooters, FPS . . . . . . . . . . .
Accin en primera persona
Fotogramas por segundo
GPA . . . . . . . . . . Generalized Pedagogical Agent GPL . . . . . . . . . . General Public License GrimE . . . . . . . . Grim Edit IA . . . . . . . . . . . . .
Intelingecia Articial
ICAI . . . . . . . . . . Intelligent Computer-Aided Instruction IDE . . . . . . . . . . . Integrated development environment,

desarrollo 297 Entorno integrado de
298
Bibliografa
ITS
...........
Intelligent Tutoring System, Sistema Inteligente de Tutora

Agente virtual inteligente
IVA . . . . . . . . . . . Intelligent Virtual Agent,
IVE . . . . . . . . . . . Intelligent Virtual Environment, Entorno virtual inteligente JIT JNI
........... ...........
Just-in time code generation Java Native Interface

Mquina virtual de Java Sistema de gestin del co-
JVM . . . . . . . . . . Java Virtual Machine,
KMS . . . . . . . . . . Knowledge management system,

nocimiento
LGPL . . . . . . . . . Lesser General Public License LMS . . . . . . . . . . Learning Management System,

zaje Sistema gestor de aprendi-
NPC . . . . . . . . . . Non-Player Character,
Personaje no jugador
NTSC . . . . . . . . . National Television System Commitee OIM

..........
Object Interface Manager

Lnea alternada en fase
PAL . . . . . . . . . . . Phase Alternating Line,
PLATO . . . . . . . Programmed Logic Automated Teaching Operations QA . . . . . . . . . . . . Quality assurance SCORM

......
Sharable Content Object Reference Model

Utilidad de creacin de guiones para Maniac Mansion
SCUMM . . . . . . Script Creation Utility for Maniac Mansion, SDK . . . . . . . . . . Software Development Kit,
Kit de desarrollo software Multiproceso simtrico Lenguaje extensible de mar-
SMP . . . . . . . . . . Symmetric Multi-Processing,
XML . . . . . . . . . . eXtensible Markup Language,

cado
ZIL
...........
Zork Implementation Language,

cin de Zork
Lenguaje de implementa-
Qu te parece desto, Sancho? Dijo Don Quijote Bien podrn los encantadores quitarme la ventura, pero el esfuerzo y el nimo, ser imposible. Segunda parte del Ingenioso Caballero Don Quijote de la Mancha Miguel de Cervantes
Buena est dijo Sancho ; frmela vuestra merced. No es menester rmarla dijo Don Quijote, sino solamente poner mi rbrica. Primera parte del Ingenioso Caballero Don Quijote de la Mancha Miguel de Cervantes

Tesis Sistemas Educativos Basados en Videojuegos

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tesis Sistemas Educativos Basados en Videojuegos

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD COMPLUTENSE DE MADRID

FACULTAD DE INFORMTICA Departamento de Ingeniera del Software e Inteligencia Artificial

ARQUITECTURA Y METODOLOGA PARA EL DESARROLLO DE SISTEMAS EDUCATIVOS BASADOS EN VIDEOJUEGOS

MEMORIA PARA OPTAR AL GRADO DE DOCTOR PRESENTADA POR

Marco Antonio Gmez Martn

Bajo la direccin del doctor Pedro Antonio Gonzlez Calero

Arquitectura y metodologa para el desarrollo de sistemas educativos basados en videojuegos

Arquitectura y metodologa para el desarrollo de sistemas educativos basados en videojuegos

Memoria que presenta para optar al ttulo de Doctor en Informtica

Pedro Antonio Gonzlez Calero

Dirigida por el Doctor

En todo hombre hay escondido un nio que quiere jugar

Inicio de las Leyes Orgnicas. Juan Carlos I

Miguel de Cervantes, Don Quijote de la Mancha

de forma que se reduzcan

mente aquellos mdulos susceptibles de quedar obsoletos con el avance

Razones para el uso de COTS . . . . . . . . . . . . . .

Arquitecturas dirigidas por datos . . . . . . . . . . . . . . . . Bucle principal 2.5.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Arquitectura basada en componentes . . . . . . . . . .

Ejemplos de lenguajes de script . . . . . . . . . . . . . Casos de uso . . . . . . . . . . . . . . . . . . . . . . .

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.2. 3.2.3. 3.2.4. 3.2.5. 3.3.

Modelo del estudiante

Mdulo pedaggico . . . . . . . . . . . . . . . . . . . . Mdulo de comunicacin . . . . . . . . . . . . . . . . . Agentes pedaggicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Arquitecturas de ITSs 3.3.1. 3.3.2. 3.3.3.

Arquitectura clsica de ITSs . . . . . . . . . . . . . . . Arquitectura Modelo de conocimientoVista . . . . . . Arquitectura basada en agentes . . . . . . . . . . . . . . . . . . . . .

Arquitectura de entornos virtuales con agentes 3.4.1. 3.4.2.

Interfaz entre el agente y el entorno . . . . . . . . . . . Ejemplos de agentes en entornos virtuales . . . . . . .

Agentes pedaggicos 3.5.1. 3.5.2. 3.5.3.

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . .

4. Metodologa de creacin de contenidos

Creacin de contenidos . . . . . . . . . . . . . . . . . . . . . . 4.3.1. 4.3.2. 4.3.3. Contenidos en aplicaciones educativas . . . . . . . . .

Contenidos en videojuegos . . . . . . . . . . . . . . . . Contenidos en videojuegos educativos . . . . . . . . .

Metodologa de creacin de contenidos . . . . . . . . . . . . . 4.4.1. 4.4.2. 4.4.3. Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . Puesta en prctica . . . . . . . . . . . . . . . . . . . .

Herramientas necesarias para el desarrollo 4.5.1. 4.5.2. 4.5.3. 4.5.4. 4.5.5.

Compiladores, IDEs y herramientas de construccin

Otras herramientas de soporte . . . . . . . . . . . . . . . . . . 105

4.6.1. 4.6.2. 4.6.3.

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

5. Arquitectura de sistemas educativos basados en juegos

Gestin de mapas . . . . . . . . . . . . . . . . . . . . . 143 Implementacin . . . . . . . . . . . . . . . . . . . . . . 145

Control de la ejecucin . . . . . . . . . . . . . . . . . . . . . . 145 . . . . . . . . . . . . . . . . . . . . . . . . 146 . . . . . . . . . . . 148

5.10. Agente pedaggico

5.11. Relacin entre entorno virtual y ejercicios

5.12. Evaluacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

6. Sistema educativo para la enseanza de la JVM

Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Descripcin general . . . . . . . . . . . . . . . . . . . . . . . . 154

Aspectos de la JVM no cubiertos . . . . . . . . . . . . 161 . . . . . . . . . . . . . . . . . . . . . . 163

Motor de la aplicacin 6.3.1. 6.3.2. 6.3.3. 6.3.4. 6.3.5. 6.3.6.

Motor de colisiones . . . . . . . . . . . . . . . . . . . . 171 Control de ejecucin . . . . . . . . . . . . . . . . . . . 172

6.4.3. 6.4.4. 6.4.5. 6.4.6. 6.4.7. 6.5.

Conguracin de entidades segn el ejercicio . . . . . . 183 Objetos OIM . . . . . . . . . . . . . . . . . . . . . . . 185

Implementacin mediante componentes . . . . . . . . . 188 Ejemplos de componentes . . . . . . . . . . . . . . . . 190

Ejemplos de entidades de juego . . . . . . . . . . . . . 193 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Vista lgica 6.5.1. 6.5.2.

Subsistema de tutora 6.6.1. 6.6.2. 6.6.3. Inicializacin Ejercicios

Ejecucin durante la partida . . . . . . . . . . . . . . . 204 . . . . . . . . . . . . . . . . . . . . 205 . . . . . . . 206

Generacin de contenidos 6.7.1. 6.7.2.

Generacin del conocimiento del dominio

Generacin del entorno de aprendizaje . . . . . . . . . 206

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

7. Conclusiones y trabajo futuro

A. Mquina virtual de Java

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . .

Arquitectura clsica de ITSs . . . . . . . . . . . . . . . Arquitectura Modelo de conocimientoVista . . . . . . Arquitectura basada en agentes . . . . . . . . . . . . . . . . . . . . .

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . .

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

5.12. Evaluacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Conguracin de entidades segn el ejercicio . . . . . . 183 Objetos OIM . . . . . . . . . . . . . . . . . . . . . . . 185

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Notas bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Bucle principal con fotograma variable y tiempo jo

learning ) o juegos serios (serious games ) (Gmez Martn, G-

colorean, las animaciones, msicas y efectos sonoros denen el conte-

planicacin, que hacen que los proyectos

2.2. Denicin de arquitectura

2.2. Denicin de arquitectura

al decir que una arquitectura software es el conjunto de decisiones

para hacer ms llamativo el aspecto nal del

estamos pensando en la reutilizacin de componentes ms grandes, como el motor grco o el de fsica.