Control de un agente inteligentemediante Redes Neuronales en elentorno del videojuego UT2004

PROYECTO DE FIN DE CARRERA

Autor: Sergio Moreno Ruiz

Director: Manuel Gonzalez Bedia

Codirector: Francisco Seron Arbeloa

Ingenierıa en InformaticaCurso 2011-2012

Departamento de Informatica e Ingenierıa de Sistemas

Centro Politecnico Superior

Universidad de Zaragoza

Febrero de 2012

Control de un agente inteligente mediante Redes Neuronales en elentorno de simulacion UT2004

RESUMEN

En este proyecto se pretende obtener agentes sinteticos (bots) para videojuegos de accion enprimera persona, de forma que su comportamiento no sea definido directamente por el programador,sino que estos sean capaces de adquirirlo mediante aprendizaje automatico. Para ello, se ha optadopor una estrategia de aprendizaje basada en Redes Neuronales Recurrentes de Tiempo Continuo(CTRNN) (Beer, 1995a).

Las CTRNNs permiten al agente iniciar una accion independientemente de su situacion inme-diata y organizar su comportamiento anticipandose a eventos futuros (Beer, 1995b). Parte funda-mental de este proyecto es que las CTRNNs sean capaces de aprender por sı mismas, para lo cualdeben de ser capaces de adaptarse a un comportamiento dado mediante algoritmos geneticos y, sise requiere, de aprender y adaptarse a las circunstancias a lo largo del tiempo de ejecucion del botal que controlan.

El objetivo principal de este proyecto es el de estudiar y aprovechar las capacidades de lasCTRNNs para obtener comportamientos para los bots de un videojuego de accion en primerapersona que serıan imposibles utilizando redes neuronales feed-forward (con comportamiento pu-ramente reactivo). Para ello, se realizaran cuatro experimentos orientados a la obtencion de cuatrobots controlados por CTRNNs:

1. En primer lugar se buscara obtener dos bots con diferentes comportamientos de navegacionque requieran memoria a corto plazo: (a) un primer bot con comportamiento de navega-cion y evitacion de obstaculos y (b) un segundo bot con capacidad de seguir la trayectoriade movimiento de un bot enemigo, incluso cuando lo pierde momentaneamente de vista aldesaparecer este tras un muro, para lo cual tendra que poder “predecir” su reaparicion.

2. En segundo lugar se buscara obtener un tercer bot con el que estudiar la capacidad de lasCTRNN de aprender durante el tiempo de vida del bot sin variar ninguno de sus parametros.

3. Por ultimo, una vez estudiadas las propiedades de las CTRNNs para diferentes bots, sebuscara obtener un cuarto bot cuyo comportamiento sea combinacion de los obtenidos parael primer y el tercer bot.

El videojuego para el cual se programaran los bots es Unreal Tournament 2004 (UT2004) el cualcuenta con la plataforma Pogamut 3, la cual permite programar el control de los bots en el lenguajede programacion Java. Al tratarse de un trabajo pionero, el objetivo previo a la realizacion de esteproyecto consistira en estudiar dicha plataforma (sus ventajas y limitaciones), ası como realizarun manual adecuado para programadores (dado que Pogamut, al principio de este proyecto, nocontaba con uno). Con ello se pretende asentar las bases para futuros proyectos en el area de IAen videojuegos utilizando Pogamut.

i

Indice general

I Memoria XI

1. Introduccion 11.1. Objetivo y alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Contexto en el que se realiza el proyecto . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Metodologıa: CTRNNs que aprenden . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4. Trabajo a realizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.7. Planificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Tecnicas para la evolucion de redes neuronales dinamicas en el entorno de si-mulacion UT2004 72.1. El entorno de simulacion UT2004 y Pogamut 3 . . . . . . . . . . . . . . . . . . . . 72.2. Redes Neuronales Recurrentes de Tiempo Continuo . . . . . . . . . . . . . . . . . . 82.3. Evolucion Diferencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4. Diseno de los experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3. Aprendizaje evolutivo para la obtencion de CTRNNs con comportamientos denavegacion 133.1. Configuracion general de los experimentos . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1. Diseno del bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.2. Configuracion de las CTRNNs . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.3. Configuracion del algoritmo de Evolucion Diferencial . . . . . . . . . . . . . 15

3.2. Experimento 1: Navegacion y evitacion de obstaculos en un entorno no estructurado 163.2.1. Descripcion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.2. Diseno del experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.3. Resultados del experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.4. Analisis del comportamiento del bot . . . . . . . . . . . . . . . . . . . . . . 19

3.3. Experimento 2: Seguimiento de trayectorias . . . . . . . . . . . . . . . . . . . . . . 203.3.1. Descripcion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.2. Diseno del experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.3. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4. Conclusiones: memoria a corto plazo en CTRNNs con recurrencias entre sus nodos 23

4. Aprendizaje en CTRNNs sin plasticidad sinaptica durante el tiempo de vidadel bot 254.1. Descripcion del experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2. Aprendizaje evolutivo para la obtencion de la CTRNN . . . . . . . . . . . . . . . 264.3. Analisis del comportamiento de aprendizaje del bot . . . . . . . . . . . . . . . . . 284.4. Analisis de las dinamicas del sistema CTRNN-entorno . . . . . . . . . . . . . . . . 30

iii

4.5. Conclusiones: capacidad de memorizacion en CTRNNs con tiempos de activacionmultiescala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5. Combinacion de CTRNNs para la obtencion de un sistema escalable 355.1. Metodo utilizado y el problema de la escalabilidad . . . . . . . . . . . . . . . . . . 355.2. Diseno del experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3. Resultados del experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4. Conclusiones: combinacion de comportamientos de CTRNNs . . . . . . . . . . . . 38

6. Conclusiones 416.1. Resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2. Recurrencias entre los nodos de la red para comportamientos con necesidad memoria

a corto plazo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.3. Activacion multiescalada en el tiempo para un comportamiento de aprendizaje en

tiempo de ejecucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.4. Combinacion de CTRNNs para comportamientos complejos . . . . . . . . . . . . . 436.5. Algoritmos Geneticos y CTRNNs en UT2004 utilizando Pogamut . . . . . . . . . . 436.6. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.7. Valoracion personal y problemas encontrados . . . . . . . . . . . . . . . . . . . . . 44

II Anexos 45

A. Inteligencia Artificial y Videojuegos 47

B. Redes neuronales 49B.1. Introduccion a las Redes Neuronales . . . . . . . . . . . . . . . . . . . . . . . . . . 49B.2. Descripcion matematica de las CTRNN . . . . . . . . . . . . . . . . . . . . . . . . 50B.3. Analisis de las dinamicas de un agente controlado por CTRNN con su entorno . . 51B.4. Redes de Elman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

C. Algoritmos Geneticos 55C.1. Introduccion a los Algoritmos Geneticos . . . . . . . . . . . . . . . . . . . . . . . . 55C.2. Descripcion de la tecnica de Evolucion Diferencial . . . . . . . . . . . . . . . . . . 56C.3. Espacio “Fitness” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

D. Manual Pogamut 3 61D.1. Instalacion y Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

D.1.1. Instalacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61D.1.2. Ejecucion del bot en UT2004 . . . . . . . . . . . . . . . . . . . . . . . . . . 62

D.2. Modos de movimiento del bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65D.2.1. Bot de Navegacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67D.2.2. Bot con raycasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

D.3. Implementacion del bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68D.3.1. Clases principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68D.3.2. Clase ModuleController . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71D.3.3. Otros comandos interesantes . . . . . . . . . . . . . . . . . . . . . . . . . . 83

D.4. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85D.4.1. Interaccion con el mundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85D.4.2. Descripcion de los eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90D.4.3. Eventos clasificados por grupos . . . . . . . . . . . . . . . . . . . . . . . . . 91

iv

Indice de figuras

1.1. Arquitectura de Pogamut, donde “IDE” es NetBeans 6.9.1 y “Local Parser” se tratade un middleware entre GameBots2004 y el cliente, cuyo proposito es simplificarel envıo y recepcion de mensajes de GameBots2004 y minimizar la utilizacion delancho de banda transmitiendo unicamente la informacion que ha cambiado. . . . . 4

1.2. Diagrama de Gantt de las actividades realizadas. . . . . . . . . . . . . . . . . . . . 5

2.1. Valor de salida en una CTRNN. Izquierda: Un nodo autoconectado. Derecha:Funcion sigmoidea aplicada para calcular la salida de una neurona. . . . . . . . . . 9

3.1. Vehıculo de Braitenberg y su version real y simulada. [A] Representacion esquemati-ca del un Vehıculo de Braitenberg. [B] Robot Khepera, cuya arquitectura es similara un Vehıculo de Braitenberg. [C] Bot de UT2004 con arquitectura similar a unVehıculo de Braitenberg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2. Comparacion entre una arquitectura feed-forward y otra con conexiones recursivas.Izquierda: Un sistema de control basado en un vehıculo de Braitenberg con cone-xiones feedforward simetricas se mueve hasta la esquina inferior izquierda, dondese detiene al encontrar las mismas intensidades en los sensores de ambos lados (laspequenas oscilaciones se deben al ruido sensorial). Derecha: El controlador evolu-cionado hace uso de la recursividad para evitar el punto muerto. . . . . . . . . . . 16

3.3. Mapa para el experimento para la obtencion de un bot controlado por una CTRNNcon capacidad de navegacion y evitacion de obstaculos. . . . . . . . . . . . . . . . . 17

3.4. Grafica con los resultados de la funcion “fitness” obtenidos durante el proceso deevolucion para la obtencion de una CTRNN con capacidad de navegacion y evitacionde obstaculos. La lınea azul muestra el valor obtenido por el mejor individuo de cadageneracion. La lınea discontinua roja muestra la media de todos los individuos decada generacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5. CTRNN con comportamiento de navegacion y evitacion de obstaculos en un entornono estructurado para un bot con estructura de robot Khepera adaptada. . . . . . . 19

3.6. Ejemplo grafico del comportamiento de un bot controlado por la CTRNN resultadodel experimento 1 para el modelo 1. [A] El bot localiza un obstaculo. [B] El botreacciona y evita el obstaculo. [C] El bot ha evitado correctamente el obstaculo sincolisionar contra el. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.7. Mapa para la comprobacion del correcto funcionamiento de un bot controlado poruna CTRNN con capacidad de navegacion y evitacion de obstaculos, el cual ademassea capaz de evitar puntos muertos. . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.8. Mapa para el segundo experimento. . . . . . . . . . . . . . . . . . . . . . . . . . . 213.9. Grafica con los resultados de la funcion “fitness” obtenidos tras el proceso de evo-

lucion para la obtencion de una CTRNN con capacidad de seguimiento de las tra-yectorias de movimiento de otros bots. La lınea azul muestra el valor obtenido porel mejor individuo de cada generacion. La lınea discontinua roja muestra la mediade todos los individuos de cada generacion. La lınea discontinua vertical muestra latransicion de la primera fase (fase de localizacion) a la segunda (fase de seguimiento). 23

v

3.10. Ejemplo grafico del comportamiento de dos bots controlados por la CTRNN resul-tado de la primera fase del experimento 2. . . . . . . . . . . . . . . . . . . . . . . . 23

3.11. CTRNN con comportamiento de seguimiento de trayectorias de movimiento de otrosbots para un bot con estructura de robot Khepera adaptada. . . . . . . . . . . . . 24

3.12. Ejemplo grafico del comportamiento de un bot controlado por la CTRNN resultadodel experimento 2. [A] El bot sigue la trayectoria de su objetivo. [B] El objetivo seoculta tras un muro. [C] El objetivo reaparece y el bot ha sido capaz de seguir sutrayectoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1. Entorno de simulacion para el experimento. (A) Entorno de simulacion teorico bi-dimensional, con un gradiente de alturas, en el que la base “enemiga” puede ser lo-calizada en una de las dos franjas representadas por regiones a puntos. (B) Entornode simulacion en UT2004, en el que el gradiente es la altura a la que se encuentrael bot, y las franjas roja y azul representan donde se encuentran las bases “alta” y“baja” respectivamente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2. Grafica con los resultados de la funcion “fitness” obtenidos tras el proceso de evolu-cion para la obtencion de una CTRNN con capacidad de aprendizaje en tiempo deejecucion del bot. La lınea azul muestra el valor obtenido por el mejor individuo decada generacion. La lınea discontinua roja muestra la media de todos los individuosde cada generacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3. Parametros para la mejor CTRNN con 4 neuronas totalmente interconectadas y au-toconectadas. Los nodos estan sombreados segun sus bias. El grosor de las conexionesexcitatorias (negras) e inhibitorias (grises) es proporcional al peso de las mismas.Las constantes de tiempo estan representados por el tamano del nodo, siendo lasneuronas mas lentas las mas grandes. . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4. Actividad de la CTRNN para una secuencia de ejecucion. De arriba a abajo lastrazas corresponden a la senal de base (B), la senal de altura (A), y las salidas delas neuronas (oi). Las dos ultimas neuronas controlan el motor de la derecha (rm)e izquierda (lm). Las barras horizontales de color gris oscuro en la traza de alturadeterminan donde puede encontrarse la base enemiga segun el entorno A-ent o B-ent.Las lıneas discontinuas verticales finas marcan las diferentes ejecuciones (cuando elbot se vuelve a ejecutar desde el centro del mapa). Las lıneas discontinuas verticalesgruesas marcan la transicion entre entornos. . . . . . . . . . . . . . . . . . . . . . . 30

4.5. Diagrama de bifurcacion en ausencia de bases. Cuatro proyecciones bidimensiona-les del diagrama 5-dimensional, una por cada una de las neuronas de la CTRNN.Las lıneas solidas representan puntos estables de equilibrio, mientras que las lıneasdiscontınuas representan puntos de equilibrio inestables. . . . . . . . . . . . . . . . 31

4.6. Diagrama de bifurcacion en presencia de la base enemiga. Cuatro proyecciones bi-dimensionales del diagrama 5-dimensional, una por cada una de las neuronas de laCTRNN. Las lıneas solidas representan puntos estables de equilibrio, mientras quelas lıneas discontınuas representan puntos de equilibrio inestables. Las lıneas grisesverticales muestran los rangos de altura donde puede encontrarse la base enemiga. 32

5.1. CTRNN compuesta por las obtenidas en los experimentos del experimento 1 delcapıtulo 3 y el del capıtulo 4. La neurona 1 esta autoconectada, recibe los valoresde los sensores base de la CTRNN de la derecha y los valores de los sensores si

proporcionados por los rayos del sistema “raytracing” de la CTRNN de la izquierda,y se encarga de seleccionar una de las dos CTRNNs para ejecutar las accion del bot. 36

5.2. Mapas para el experimento de obtencion de una CTRNN como combinacion de otrasCTRNNs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

vi

5.3. Grafica con los resultados de la funcion “fitness” obtenidos tras el proceso de evolu-cion para la obtencion de una CTRNN capaz de elegir entre el comportamiento deuna de las CTRNNs que la componen para con capacidad de navegacion y evitacionde obstaculos. La lınea azul muestra el valor obtenido por el mejor individuo de cadageneracion. La lınea discontinua roja muestra la media de todos los individuos decada generacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

B.1. CTRNN formada por un nodo autoconectado. . . . . . . . . . . . . . . . . . . . . 51B.2. Graficas para el analisis de las dinamicas del sistema agente-entorno de una CTRNN

formada por una unica neurona autoconectada. [A1] Analisis de la convergencia delvalor de activacion a un unico punto fijo estable para los parametros θ=0, w=-20 y un valor de entrada constante I=-10. [A2] Diagrama de bifurcacion para losparametros θ=0, w=-20. [B1] Analisis de la convergencia del valor de activacion atres puntos fijos (dos estables y uno inestable) para los parametros θ=0, w=20 y unvalor de entrada constante I=-10. [B2] Diagrama de bifurcacion para los parametrosθ=0, w=20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

B.3. CTRNN totalmente interconectada y recurrente en la capa intermedia . . . . . . . 53B.4. Codificacion del genotipo de una CTRNN totalmente interconectada y recurrente

en la capa intermedia con 6 neuronas de entrada, 4 intermedias y 2 de salida. . . . 54

C.1. Evolucion Diferencial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58C.2. Espacio “Fitness” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

D.1. Modos de juego GameBots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62D.2. Configuracion del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63D.3. Codigo en NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64D.4. Anadir servidor UT2004 a NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . 65D.5. Host del servidor UT2004 en NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . 65D.6. Modo espectador en UT2004 desde NetBeans . . . . . . . . . . . . . . . . . . . . . 66D.7. Consola del comandos con opciones propias de Pogamut 3 para UT2004 . . . . . . 66

vii

viii

Indice de tablas

3.1. Valores mınimos y maximos para los parametros de las CTRNNs de los experimentos 153.2. Codificacion del genotipo de una CTRNN totalmente interconectada, autoconectada

y simetrica con 6 neuronas de entrada y 2 de salida. Los genes correspondientes alos pesos de las conexiones han sido codificados de forma ordenada, de modo queel gen 2 corresponde a la conexion u10 y (debido a la simetrıa) a la u25, el gen 3a las conexiones u11 y u24, y ası sucesivamente. En cuanto a los pesos w, el gen 8corresponde a las autoconexiones y el 9 a las interconexiones entre las neuronas desalida. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3. Configuracion del experimento para el primer bot . . . . . . . . . . . . . . . . . . . 183.4. Configuracion del experimento para el segundo bot . . . . . . . . . . . . . . . . . . 22

4.1. Codificacion del cromosoma de una CTRNN con neuronas totalmente interconecta-das y autoconectadas con 4 neuronas y 2 entradas. . . . . . . . . . . . . . . . . . . 27

4.2. Configuracion del experimento para el tercer bot . . . . . . . . . . . . . . . . . . . 28

5.1. Configuracion del experimento para el cuarto bot . . . . . . . . . . . . . . . . . . . 385.2. Parametros para la mejor CTRNN que permite selecionar entre los comportamientos

de navegacion y esquivacion de obstaculos por un lado, y de busqueda y memoriza-cion de la localizacion de la base enemiga por el otro. . . . . . . . . . . . . . . . . 39

ix

Parte II

Anexos

45

Anexo A

Inteligencia Artificial y

Videojuegos

La Inteligencia Artificial es una rama de la Informatica que trata de resolver problemas deforma parecida a como los resuelven los humanos.

Los primeros proyectos en Inteligencia Artificial estuvieron orientados hacia la busqueda de tec-nicas universales para la solucion de problemas (Norvig y Russell, 2003). Esta apuesta se abandonopoco tiempo despues, cuando se tomo conciencia de la dificultad que suponıa, pasado a caracteri-zar el area el desarrollo de un conjunto de tecnicas concretas, adaptadas a problemas especıficos ydependientes de dominios particulares de trabajo.

En concreto, la IA aplicada a los videojuegos surgio a finales de los anos 50, en juegos como lasDamas, Ajedrez o Go, en general juegos, donde se pretendıa que los programas fueran capaces dejugar mediante aprendizaje (esto es, sin tener ningun conocimiento, fueran adquiriendolos jugandopartidas). Esto supuso una gran revolucion y, a partir de ese momento, la aplicacion de tecnicasde IA en los videojuegos ha tenido mas relevancia, debido a que los juegos empezaron a dejarde ser “jugador contra jugador”, por lo que el usuario quiere sentir que la maquina tenga uncomportamiento humano o de un nivel de dificultad adecuado.

Esto junto con otros motivos que comentamos a continuacion (Laird y van Lent, 2000), con-forman la base de necesidades que han permitido a la IA conseguir un mayor protagonismo en laindustria del videojuego.

1. Los desarrolladores de videojuegos empiezan a reconocer la necesidad del nivel humano deIA.

2. La industria de los videojuegos es muy competitiva, y uno de los componentes de esa com-petitividad es la tecnologıa. La IA es a menudo mencionada como la proxima tecnologıa quemejorara los videojuegos y determinara cuales de ellos seran exitos.

3. El perfil de los desarrolladores de juegos ha cambiado sustancialmente en poco tiempo. Eltıtulo de programador de IA es ya un componente mas en los equipos de desarrollo de video-juegos.

4. Se supone que el hardware de los juegos con potencias de calculo de gama alta para la IAseran una realidad en los juegos de los proximos cinco anos. Con los nuevos PC’s y las nuevasgeneraciones de consolas que son capaces de mover todos los graficos sin la CPU, no serıa deextranar que en unos anos se dediquen a implementar procesadores de IA en los videojuegos,lo que permitira poder desarrollar muchas mas tecnicas ya que un procesador independientemueva todas las ordenes y hechos.

Ademas de estos motivos, hay otro muy importante, y es que la IA todavıa no es perfecta, yhay que perfeccionarla. Por ello, la conexion entre la comunidad universitaria de investigadores de

47

Inteligencia Artificial y los desarrolladores de videojuegos se ha fortalecido en los ultimos anos. Lacooperacion entre estos dos grupos es beneficiosa para ambos. Los desarrolladores se han percatadode la creciente demanda de una mejora de la IA en sus videojuegos. Por otro lado, los investigadoresnecesitan entornos donde poder probar sus modelos.

Existe un fuerte contraste entre las tecnicas usadas en la industria del videojuego y por losinvestigadores. Las tecnicas mas usadas en la industria son las maquinas de estados finitas, arbolesde comportamiento y en los ultimos anos algoritmos de planificacion. Por el otro lado, los investiga-dores estan mas centrados en las redes neuronales, algoritmos geneticos y metodos de aprendizajeen maquinas, pero estos metodos son a penas utilizados todavıa en videojuegos comerciales.

48

Anexo B

Redes neuronales

B.1. Introduccion a las Redes Neuronales

Las redes neuronales son sistemas computacionales que se basan en una estructura conexionistay paralela (salvo que habitualmente son simuladas en un ordenador con arquitectura von Neumann)inspirada en los sistemas nerviosos naturales. La estructura de la red neuronal es un grafo, dirigidoo no, con o sin ciclos, cuyos nodos se denominan neuronas artificiales. Estas realizan una sumaponderada (con valores llamados pesos que multiplican cada conexion entre neuronas o axon) delas salidas de ciertas neuronas, que si sobrepasa un cierto umbral, genera que la neurona disparesu salida (Maass, 1997).

En el mundo de las redes neuronales hay gran variedad de disenos. En algunos modelos lasalida de la neurona es proporcional a la suma menos el umbral, aunque el modo mas frecuentees expresar la dependencia en terminos de una funcion sigmoidea, como la que corresponde a laformula B.2.

Las redes neuronales mas antiguas se estructuran en capas (los antiguos perceptrones multi-capa) y la activacion se propaga en un solo sentido. El disenador elige, tras estudiar el problema,el numero de capas, el numero de neuronas de cada capa y el tipo y cantidad de conexiones en-tre capas (por ejemplo, todas con todas o por grupos). El punto fuerte de este tipo de redes esestablecer un mapeo directo entre entrada y salida, aproximar una funcion entre puntos de dosespacios n-dimensionales. Sin embargo, cada vez se encuentran mas redes neuronales recurrentes(con ciclos) en las que puede haber o no estructura de capas. La forma en que la informacion fluyepor los ciclos de la redes neuronales le proporciona un tipo de tratamiento temporal de la informa-cion. Las primeras solamente conectaban la salida a las neuronas de entrada, pero actualmente seusan las llamadas fully-recurrent, que se pueden definir como un grafo dirigido sin restricciones deconectividad (Beer, 1996).

Lo habitual es que la actualizacion de las neuronas sea sıncrona, que es lo apropiado cuandola tarea de la red neuronal es el reconocimiento y clasificacion de patrones, pero ultimamente seesta estudiando las redes neuronales que usan el tiempo como uno de los multiples soportes dela informacion que procesan, ya que una de las caracterısticas que se deben extraer consiste enla relacion temporal entre caracterısticas. Su funcionamiento es totalmente asıncrono, con unasconexiones interneuronales que producen retardos en las entradas de las neuronas. Hay otros mo-delos en los que las neuronas son planteadas como Sistemas Dinamicos continuos, y por tanto sucomportamiento se describe con ecuaciones diferenciales (Beer, 1995a).

Otros tipos de red neuronal de extendido uso son las de tipo estadıstico y de agrupamiento(clustering) como las Self-Organizing Maps (SOM, mapas autoorganizativos o redes de Kohonen(1982)), o las Learning Vector Quantization (LVQ). Estas redes distan demasiado de la inspiracionbiologica de un sistema nervioso en cuanto a funcionamiento, aunque no en cuanto a funcionalidad(diferentes en cuanto a forma, no en el fondo) y se separan del esquema de diseno de un individuo

49

con un sistema nervioso artificial evolucionado en el marco de la Vida Artificial.Las redes neuronales son capaces de aprender variando los pesos de las conexiones, lo que

produce que realicen diferentes mapeos entre entrada y salida, o diferentes trayectorias en el espaciode estados determinadas por el valor de activacion de cada neurona. Estos mapeos y trayectoriasson la base que les permite realizar labores de reconocimiento y clasificacion de patrones. Hay dosformas de hacer que aprenda una red neuronal: presentandole patrones de entrada y salida, o solode entrada y suministrando una senal se supervision positiva o negativa. Despues de cada patronse modifican los pesos para que se acerque a la respuesta correcta con esos patrones. Sistemas deaprendizaje mas modernos varıan la estructura de la red neuronal una vez determinada para uncierto individuo (en tiempo ontogenetico).

Una de las caracterısticas principales de las redes neuronales es su resistencia al ruido, es decir,a la imprecision de los datos de entrada, que no consiguen perturbar su comportamiento, y da larespuesta adecuada. Otra caracterıstica muy importante es que las redes neuronales son capaces deresponder correctamente ante entradas no presentadas durante la fase de entrenamiento, es decir,improvisan. Dicho de otra forma, las redes neuronales tienen distintas capacidades de interpolacion(segun sea su estructura) para producir una salida tambien interpolada, o la correspondiente a lamas cercana a la entrada dada.

Muchas veces ocurre que la red sufre un sobreentrenamiento, y no es capaz de generalizar ointerpolar (Mataric y Cliff, 1996). Esto es debido a un entorno demasiado simple, con lo que lared neuronal lo aprende demasiado bien. Este aspecto tecnico de exceso de convergencia de la redconlleva a plantearse modelos apropiados al entorno.

B.2. Descripcion matematica de las CTRNN

En esta seccion apartado se muestra la representacion matematica de las CTRNNs.En primer lugar se tiene en cuenta el comportamiento de una neurona de la red. La activacion

se suele interpretar como la frecuencia de activacion media de esa neurona en el intervalo △t deactualizacion.

En primer lugar, su actualizacion sıncrona. Se actualiza a cada vuelta del ciclo a la salida atide la neurona i en el instante t en funcion del valor suma s de esa neurona en ese instante. Si seexpresa

ati = f(st−1

i ) (B.1)

donde st−1

i =∑N

j=1wija

t−1

j + θi

es el valor de la suma ponderada (con los pesos sinapticos w) de las salidas a de las neuronasen el instante t−1. A esta suma se le anade el valor θi, umbral de activacion de la neurona i (bias).

Existen multitud de funciones de activacion en la literatura especializada. Las CTRNNs, uti-lizan normalmente la funcion sigmoidea

f(s) = σ(s) =1

1 + e−αs(B.2)

donde el valor α indica la rapidez del crecimiento sigmoidal.Las CTRNNs se obtienen al hacer tender △t hacia cero en las redes sigmoideas anteriormente

descritas. Su descripcion matematica se puede ver en la formula B.3. La funcion sigmoidea B.4 seaplica al final de un paso o al principio del siguiente, lo que es equivalente.

yi =1

τi

∗

−yi +

N∑

j=1

wji ∗ σ(yj + θj) + Ii

i = 1, 2, . . . , N (B.3)

50

σ(x) =1

1 + ex(B.4)

En B.3 Ii representa una entrada externa y τ hace que cada una de las neuronas dependadel tiempo, ya que para diferentes valores la caıda del nivel de activacion de la neurona es masrapida o lenta. La velocidad de actualizacion de la red neuronal debe ser notablemente mayor (elintervalo entre dos actualizaciones sera menor) que el valor de τ para no obtener comportamientosno deseados.

B.3. Analisis de las dinamicas de un agente controlado por

CTRNN con su entorno

Antes de analizar las tecnicas necesarias para analizar las dinamicas de un agente controladopor una CTRNN con su entorno, se debe entender como funciona la activacion de una neurona enuna CTRNN. Para ello, se va a utilizar una CTRNN formada por una unica neurona autoconectadacomo la de la figura B.1.

Figura B.1: CTRNN formada por un nodo autoconectado.

A diferencia de una red neuronal feed-forward, la cual realiza un mapeo directo entre entraday salida de la red (para un mismo valor de entrada, el valor de salida sera siempre el mismo, elcual a su vez es el estado de la neurona), el comportamiento de una CTRNN corresponde al deun sistema dinamico. Para comprender dicho comportamiento, se suponen dos CTRNN diferentesdefinidas a partir de los valores de sus parametros, tomando como modelo la CTRNN formada poruna sola neurona autoconectada de la figura B.1. Tras someterlas a un valor de entrada constantea lo largo de varios ciclos de ejecucion, se observan los siguientes fenomenos:

Para un valor bias de 0 (θ = 0) y un peso de valor -20 en el peso de la autonexion (w=-20),si se somete a la neurona a un valor constante de entrada de -10 (I =-10), el valor de y

evoluciona tal y como puede observarse en la grafica de la figura B.2-A1. A partir de unvalor inicial aleatorio de y, el sistema tiene un unico punto de atraccion (y=-10), llamadopunto de equilibrio, al cual, si se somete a la CTRNN un valor de entrada y=-10 durante unnumero suficiente de ejecuciones de la red, acabara convergiendo. Al existir un unico puntode equilibrio, podemos afirmar que el sistema dinamico es monoestable para los valores de lared y de entrada establecidos.

Para un valor bias de 0 (θ=0) y un peso de valor 20 en la autonexion (w=20), si se somete ala neurona a un valor constante de entrada de -10 (I =-10), se obtiene la grafica de la figura

51

Figura B.2: Graficas para el analisis de las dinamicas del sistema agente-entorno de una CTRNNformada por una unica neurona autoconectada. [A1] Analisis de la convergencia del valor de ac-tivacion a un unico punto fijo estable para los parametros θ=0, w=-20 y un valor de entradaconstante I=-10. [A2] Diagrama de bifurcacion para los parametros θ=0, w=-20. [B1] Analisis dela convergencia del valor de activacion a tres puntos fijos (dos estables y uno inestable) para losparametros θ=0, w=20 y un valor de entrada constante I=-10. [B2] Diagrama de bifurcacion paralos parametros θ=0, w=20.

B.2-A2. A partir de un valor inicial aleatorio de y, el sistema tiene tres puntos de atraccion,dos estables (10 y -10) y uno inestable (el 0). Como puede verse, si el valor inicial de y espositivo el valor de y convergera a 10, si es positivo a -10 y, en caso de ser 0, el sistemaconvergera a 0. No obstante, si se produjese una mınima perturbacion en el caso de que elvalor inicial de y fuese 0, como consecuencia el valor de y convergerıa a uno de los 2 puntosde equilibrio estables. En este caso, dada la existencia de dos puntos de equilibrio, el sistemadinamico se denomina biestable para los valores de la red y de entrada establecidos.

Para analizar las dinamicas de una CTRNN con su entorno, se utilizaran los diagramas de bifur-cacion (Beer, 1995a) del sistema dinamico modelado por dicha CTRNN, los cuales muestran todoslos puntos de equilibrio de la CTRNN con respecto a un rango de valores de entrada a la red. Siobservamos los diagramas de las figuras B.2-B1 y B.2-B2, se deduce de ellas que las dinamicas dela red cambian en funcion de los valores de entrada I.

En la figura B.2-B1 se puede ver el correspondiente a la CTRNN de una sola neurona autoco-nectada definida por los valores θ=0 y w=-20. Como puede comprobarse, el sistema dinamico quemodela es monoestable para todo I entre [-30,50]. En cuanto al diagrama de bifurcacion de la figuraB.2-B2, este corresponde a la CTRNN definida por los valores θ=0 y w=20 y. En este diagrama,

52

las lıneas continuas representan puntos estables de equilibrio, mientras que las lıneas discontinuasrepresentan los inestables. Como se puede ver, este sistema dinamico es biestable para valores deI comprendidos entre [-17,-7], y monoestable para valores menores que -17 y mayores que -7.

Para obtener los diagramas de bifurcacion de un sistema dado se utilizara el modulo Dynamica

para el programa Mathematica desarrollado por Randall Beer (http://mypage.iu.edu/˜rdbeer/).

B.4. Redes de Elman

El tipo de CTRNNs conocidas como redes de Elman, han sido utilizadas en sus trabajos porautores como Beer (1996) y Foreano y Mondada (1994). Surgen tras analizar como quedarıa la redneuronal tras el proceso de evolucion para cognitivos simples. Ademas, mas tarde serıan utilizadoscon exito por Bourquin (2004) en su trabajo para comportamientos similares a los deseados en estetrabajo.

En este modelo de CTRNNs todas las neuronas de la capa intermedia estan totalmente inter-conectadas (conexion de cada neurona con todas las demas en ambas direcciones), autoconectadas(conexion recurrente de la neurona a sı misma) y conectadas a su vez a todos los sensores (todaslas neuronas recibıan las entradas de los sensores), mientras que las neuronas de salida, las cua-les carecen de recurrencia y autoconexiones, se limitan a calcular la salida a partir de las senalesrecibidas de las neuronas intermedias.

La figura B.3 muestra como serıa una de estas CTRNNs con cuatro neuronas intermedias ydos de salida.

Figura B.3: CTRNN totalmente interconectada y recurrente en la capa intermedia

La Figura B.4 muestra como serıa la codificacion de una CTRNN con estructura de red deElman con 6 neuronas de entrada, 4 intermedias y 2 de salida, para el algoritmo de EvolucionDiferencial.

A pesar de haber sido utilizadas con exito en trabajos anteriores de otros autores, el tamano deestas redes neuronales es considerablemente mayor al de las utilizadas en los experimentos de esteproyecto. Ello supondra, por tanto, una mayor carga de calculo para obtener la salida en cada ciclo.Esto habra de tenerse en cuenta a la hora de plantear los experimentos, ya que a estos calculoshay que anadir el procesamiento grafico del videojuego UT2004 ası como de los numerosos calculosnecesarios por parte de Pogamut 3 (el cual a su vez no permite el calculo en paralelo de las salidasde las neuronas debido a su tratamiento interno de los threads).

53

Neuronas intermedias 0 y 3

τ θ u v0 1 2 3 4 5 6 7 8 9 10 11

Neuronas de intermedias 1 y 2

τ θ u v12 13 14 15 16 17 18 19 20 21 22 23

Neuronas de salida 0 y 1

τ θ w24 25 26 27 28 29

Figura B.4: Codificacion del genotipo de una CTRNN totalmente interconectada y recurrente enla capa intermedia con 6 neuronas de entrada, 4 intermedias y 2 de salida.

54

Anexo C

Algoritmos Geneticos

C.1. Introduccion a los Algoritmos Geneticos

Aunque las primeras nociones pueden encontrarse hace mas tiempo, los algoritmos geneticosfueron impulsados definitivamente por los trabajos de John Holland (1975). Se consideran untipo particular de algoritmos evolutivos y, por tanto, una tecnica destacada en el contexto de lacomputacion evolutiva. Son mecanismos de optimizacion o busqueda en un espacio de estadosmultidimensional, cuya mayor utilidad se demuestra en problemas en los que la solucion es elresultado de un proceso no lineal, aplicado a un conjunto de parametros que definen dicho espaciode estados multidimensional (Goldberg, 1989). Dicho conjunto de parametros definen una posiblesolucion al problema, y son un punto en el espacio de estados, denominado tambien genotipo. Eneste tipo de problemas es imposible aislar las variables para obtener su valor optimo por separado.

Se tiene un conjunto de posibles soluciones al problema (puntos en el espacio de estados), quedenominamos poblacion. Se asigna a cada elemento de la poblacion (individuo) un valor relativoque mide lo que se acerca a la solucion optima, segun la expresion de su genotipo, es decir, segun sufenotipo. Este valor se denomina de adecuacion o “fitness”, y se calcula con una funcion del mismonombre. Si el espacio de estados es de dimension n, el “paisaje de adecuacion” (fitness landscape)es un conjunto de puntos en un espacio de n+1 dimensiones, que puede ser continuo y formar unasuperficie (como un paisaje), o ser rugoso o completamente inconexo, lo que influye en la capacidadde busqueda en el algoritmo genetico. De entre todas las soluciones posibles se escogen, en funcionde su adecuacion, las mejores y se genera la descendencia, que sustituye a los individuos no elegidoso a todos los de la poblacion anterior. Se puede mantener una elite de individuos que pasa a lasiguiente generacion sin modificaciones. La descendencia se obtiene a partir de procesos de mutaciony cruce o recombinacion de los parametros que definen cada individuo: a partir de dos producimoscon el cruce uno o dos conjuntos de parametros, mezclando los valores segun un proceso aleatorioo fijo (independiente de lo que signifiquen los parametros). Ademas, se introduce otra cantidad dealeatoriedad con la mutacion, que consiste en variar un cierto valor al azar. Cuando la funcion deadecuacion nos indica que una solucion es optima, o suboptima, se puede detener el proceso.

El algoritmo se adapta al problema que se desea solucionar. Se pueden variar los metodos deseleccion, emparejamiento, cruce, mutacion, generacion de la poblacion inicial y otros especıficosdel problema. Debido a su flexibilidad tambien produce problemas de ajuste de parametros, comola presion selectiva que lleva a maximos locales de los que el algoritmo no sale, y el fenomeno con-trario, que consiste en que el algoritmo no descarta esquemas que no producen ventaja evolutiva.El Teorema de los Esquemas (Goldberg, 1989) demuestra (bajo ciertas condiciones) que los esque-mas (subconjuntos de los parametros) que aporten un aumento en el valor de adecuacion se iranseleccionando y su numero se multiplicara exponencialmente hasta predominar en la poblacion. Esdecir, que el algoritmo mejora la poblacion hacia soluciones optimas.

El concepto de esquema se basa en un patron en el que encajan parte de los individuos de una

55

poblacion que se evoluciona mediante algoritmos geneticos (Holland, 1975). El teorema pruebaque los esquemas que contribuyen mas que los demas a que un individuo obtenga mejor valor deadecuacion percolan (transmitan una perturbacion a practicamente todos los elementos de unared en un sistema conexionista, dependiendo de un cierto valor crıtico de p, la probabilidad deque la perturbacion se transmita de un elemento a su vecino), se extienden por toda la poblacion.Analogamente, los que menos aportan, desaparecen. El problema es que para que funcionen elcruce y la mutacion los esquemas deben destruirse, por lo que existen dudas sobre la la validez enel transcurso de las iteraciones (Holland, 1975; Goldberg, 1989; Vose et al., 2003).

Si se usan estrictamente las definiciones, se denomina Algoritmos Geneticos a los algoritmosevolutivos en los que la informacion se codifica en una tira de ceros y unos de tamano fijo. Segunel lugar que ocupan los dıgitos binarios, tienen asignado un significado concreto. Este tipo decodificacion es muy incomodo a la hora de evolucionar estructuras de tamano variable, por lodifıcil que resulta codificar informacion variable en estructuras de tamano fijo.

C.2. Descripcion de la tecnica de Evolucion Diferencial

La Evolucion Diferencial, propuesta por (Prize, 1999), es un Algoritmo Evolutivo en el cuallas variables del problema a optimizar estan codificadas como un vector de numeros reales, cuyalongitud es igual al numero de variables del problema.

Se compone principalmente de cuatro pasos:

Inicializacion: La poblacion inicial de individuos (denominados vectores) se genera de formaaleatoria, considerando los valores mınimos y maximos de cada variable

Mutacion: Se utiliza un operador especial de mutacion que realiza una combinacion lineal con lasdiferencias entre pares de vectores (r1 y r2) y un vector llamado vector base (r3), todos ellosseleccionados de manera aleatoria de entre los vectores que componen la poblacion. Comoresultado, se genera un vector llamado vector de mutacion.

Recombinacion: Una vez obtenidos los vectores de mutacion, cada uno de ellos se recombinaracon su respectivo vector de la poblacion padre, denominado vector padre (el cual esta sujetoa ser reemplazado), para producir un vector hijo, el cual ocupara la misma posicion que surespectivo padre en la poblacion hijo.

Seleccion: Una vez que se tiene al vector hijo, se realiza una seleccion entre los vectores padree hijo de forma determinista, es decir, el mejor de ellos permanecera en la poblacion de lasiguiente generacion.

Debido a la tecnica de seleccion utilizada por la Evolucion Diferencial, una de las ventajas res-pecto a los algoritmos geneticos tradicionales es que la siguiente generacion siempre tendra uncomportamiento igual o mejor que su antecesora.

Ademas, como puede notarse, la Evolucion Diferencial no utiliza una distribucion de probabi-lidad fija para su operador de mutacion como una estrategia evolutiva. De hecho, su operador demutacion utiliza la distribucion actual de los vectores en la poblacion, lo que permite adaptar lamutacion a la situacion de busqueda propia que tenga el algoritmo, lo cual parece ser una de susprincipales ventajas (Prize, 1999).

La version estandar de la Evolucion Diferencial se muestra en el Algoritmo C.1. La cantidadmaxima de generaciones Gmax, el tamano de la poblacion NP y los parametros F y CR son definidospor el usuario. El parametro CR [0,1] controla la influencia del vector de mutacion en la generaciondel vector hijo. Valores cercanos a 1 implican que el vector hijo sera muy parecido al vector demutacion. Por el contrario, valores cercanos a 0 indican que el vector hijo sera muy parecido alvector padre. El parametro F ¸(0,1] permite escalar las diferencias entre vectores para calcularel vector de mutacion. La funcion randint(min,max) regresa un numero entero entre min y max,

56

Algoritmo C.1 Algoritmo de Evolucion Diferencial.

Begin

G = 0Crear aleatoriamente la poblacion inicial xG∀i, i = 1, .., NP

Evaluar f(xG)∀i, i = 1, .., NP

For G = 1 to Gmax Do

For i = 1 to NP Do

Seleccionar aleatoriamente r1 6= r2 6= r3jrand = randInt(1, D)For j = 1 to D Do

If ((randj [0, 1) < CR) or (j = jrand)) then

uij,G+1

= xr3j,G + F (xr1

j,G − xr2j,G)

Else

uij,G+1

= uij,G

End if

End For

If (f(uiG+1

) ≤ f(xiG)) then

xiG+1

= uiG+1

Else

xiG+1

= xiG

End if

End For

G = G+ 1

End For

End

mientras que rand[0,1) es una funcion que devuelve un numero real entre 0 y 1. Ambas funcionesestan basadas en una distribucion uniforme de numeros aleatorios.

Una representacion mas grafica del algoritmo puede verse en la Figura C.1.

C.3. Espacio “Fitness”

La eleccion de la funcion “fitness” tiene consecuencias muy importantes en la posibilidad deevolucion del bot, dinamicas del proceso evolutivo y por ultimo en la salida del proceso evolu-tivo. Desafortunadamente, no hay una manera de definir una funcion de adecuacion a partir deuna descripcion del resultado esperado. Normalmente, uno define una funcion basada en su pro-pia experiencia. A continuacion, prueba su idoneidad a base de prueba y error (cuyo consumo detiempo es uno de los mayores problemas en la evolucion de agentes). Modifica gradualmente suvalor introduciendo variables y constantes adicionales. Estas variables y constantes no son facilesde elegir, ya que no hay un conocimiento total del comportamiento del robot una vez ha evolu-cionado. Podrıa decirse que disenar una funcion de adecuacion aplicable para un comportamientodeseado es normalmente mas facil que disenar el programa correspondiente. No obstante el gradode conocimiento de un comportamiento esperado es inversamente proporcional a la necesidad deaplicacion de estrategias evolutivas.

En esta seccion, se define el espacio “Fitness” como estructura para describir, evaluar y compa-rar funciones objetivo. Puede ser utilizado como guıa para elegir entre funciones alternativas, pero

57

Figura C.1: Evolucion Diferencial.

no proporciona una estrategia especıfica para disenar funciones objetivo para problemas especıfi-cos. El Espacio “Fitness” esta definido por tres dimensiones, tal y como podemos ver en la FiguraC.2, las cuales se detallan a continuacion:

Figura C.2: Espacio “Fitness”

La dimension funcional-basada en el comportamiento (functional-behavioral) indicasi la funcion objetivo considera componentes que pueden medirse directamente acerca decomo funciona el sistema o si considera los resultados del comportamiento del mismo. En unrobot movil, por ejemplo, una funcion objetivo funcional podrıa depender de la frecuenciay amplitud de las oscilaciones del controlador obtenido mediante evolucion, mientras queuna funcion objetiva basada en el comportamiento serıa mas adecuada si la consideramosproporcional a la distancia recorrida en un cierto periodo de tiempo.

La dimension explıcita-implıcita (explicit-implicit) define el numero de variables y cons-tantes incluidas en la funcion. Por ejemplo, una funcion implıcita seleccionarıa solo robots

58

que no se queden sin energıa despues de un cierto tiempo, mientras que una funcion explı-cita incluiria variables y constantes que evaluaran varios componentes del comportamientodeseado, tales como que el robot se aproxime a un recargador de energıa, su velocidad, laactividad de ciertas neuronas del controlador, etc.

La dimension externa-interna (external-internal) indica si las variables y constantes in-cluidas en la funcion objetivo se calculan usando informacion disponible para el agente. Porejemplo, la distancia absoluta entre robots es una variable externa al agente, mientras quela informacion que puede obtener de sus sensores o la velocidad de sus motores son variablesinternas.

La lınea diagonal entre los extremos FEE (Funcional,Explıcita,Externa) y BII(Basada en el com-portamiento, implıcita, interna) en el Espacio“Fitness”define una continuidad entre la optimizacionpor parte de la ingenierıa tradicional y la sıntesis de los sistemas de vida artificial respectivamente.

59

60

Anexo D

Manual Pogamut 3

D.1. Instalacion y Servidor

D.1.1. Instalacion

En esta seccion se describe el proceso de instalacion, ası como el software necesario para lamisma.

Prerrequisitos

Una copia del videojuego Unreal Tournament 2004 (UT2004)

Unreal Engine 2 Runtime (UE2) and Unreal Development Kit (UDK)

❼ UE2 es gratuito para uso no comercial. Es posible descargar la version Demo dehttp://apacudn.epicgames.com/Two/UnrealEngine2Runtime22262002.html

❼ UDK is una version libre de Unreal Engine 3. Esta incluido en el paquete de instalacionde Pogamut 3.

JDK y Netbeans

❼ Descarga conjunta en http://www.oracle.com/technetwork/java/javase/downloads/jdknetbeans- jsp-142931.html

Pogamut 3

❼ Descargar ”Pogamut 3 Java instaler full” en la seccion Downloads de la pagina oficialhttp://diana.ms.mff.cuni.cz/main/tiki-index.php?page=Download

Proceso de Instalacion

Para no tener problemas en el proceso de instalacion de todos los elementos que necesitamos,seguir el siguiente orden, ya que al instalar Pogamut se nos pedira la ubicacion de UT2004, UE2y Netbeans.

1. Instalar el videojuego Unreal Tournament 2004.

2. Instalar JDK y NetBeans.

En Windows 7 instalar Netbeans directamente en C:/ en lugar de en la ubicacion pordefecto, debido a problemas con los permisos.

61

3. Instalar Unreal Engine 2 Runtime.

4. Por ultimo, instalar Pogamut.

Realizar la instalacion como aparece por defecto, es decir, con todos los elementos se-leccionados, ya que todos son necesarios para que todo funcione correctamente.

Si hemos instalado los programas en la ruta por defecto, el instalador de Pogamut losdetectara automaticamente. En caso contrario tendremos que buscar la ruta en la quehayamos instalado el programa requerido por el proceso de instalacion.

D.1.2. Ejecucion del bot en UT2004

En esta seccion se describe como configurar correctamente el servidor de UT2004, de formaque luego podamos conectar nuestro bot al mismo sin problemas. Tambien se describe el procesode conexion de dicho bot al servidor utilizando NetBeans.

Configuracion del servidor

Para crear un servidor en UT2004, la forma mas sencilla es hacerlo desde el propio juego.Para ello, abrimos UT2004 y seleccionamos la opcion Alojar Partida. Una vez hecho esto, debemosseleccionar el tipo de juego. Para que este sea compatible con nuestro bot, debemos elegir unode los tipos de juego personalizados, situados al final de la lista (Figura D.1). Lo mas comun esseleccionar el tipo “GameBots DeathMatch”.

Figura D.1: Modos de juego GameBots

Una vez hecho esto, configuramos el juego a nuestro gusto. En la seccion “Reglas de servidor”debemos tener siempre en cuenta las siguiente consideraciones (Figura D.2):

62

Activar la opcion “Servidor LAN” para mejorar el rendimiento si estamos trabajando conordenadores conectados en LAN.

Deseleccionar la opcion “Anunciar servidor” para evitar problemas con copias ilegales deUT2004.

Activar “Ignore UTAN Bans” para evitar problemas con copias ilegales de UT2004.

Figura D.2: Configuracion del servidor

Por ultimo, podemos crear dos tipos de servidores:

Mixto: nada mas crear el servidor, pasarıamos directamente a jugar en el y, posteriormente,podrıamos conectar otros bots contra los que jugarıamos. Esta opcion no permite visualizarlos acontecimientos que ocurren en el servidor, como es el caso del “servidor dedicado”

Dedicado: este tipo de servidor permite visualizar en modo texto la configuracion del servidory los acontecimientos que ocurren, tales como la conexion de un jugador o bot, la muerte yresurreccion de los mismos, etc. Si queremos, desde el mismo ordenador, conectarnos parajugar en el servidor, solo tenemos que ejecutar otra vez UT2004 y conectarnos a el comojugadores.

Conexion del bot al servidor

Lo primero que debemos hacer es abrir nuestro proyecto en NetBeans. Una opcion inteligenteserıa construir nuestro bot sobre “EmptyBot”, un proyecto de ejemplo incluido por Pogamut,que serıa el equivalente al “Hello world” de los bots. Para ello seleccionamos “nuevo proyecto” enNetBeans, seleccionamos 00-Emptybot situado en la carpeta Samples/Pogamut UT2004 y le damosun nombre. Nuestro proyecto quedara guardado por defecto en Documentos/NetBeansProyects. Lafigura D.3 muestra como acceder al codigo fuente de dicho proyecto.

63

Figura D.3: Codigo en NetBeans

A continuacion, en la pestana “Services” hacemos click derecho sobre “UT2004 Servers” yseleccionamos “Add server” (Figura D.4). En el dialogo que aparece (Figura D.5) elegimos unnombre para el servidor y, en cuanto a la URI, tenemos dos opciones:

Si el servidor esta en el mismo ordenador desde el cual vamos a conectar el bot, escribimoslocalhost (si localhost no funciona probar con 127.0.0.1:3001 en su lugar).

Escribir la IP del ordenador donde se encuentra el servidor.

Una vez hecho esto, hacemos click en Close y todo estara preparado para ejecutar el bot sobreel servidor. En caso de aparecer un triangulo amarillo con una exclamacion sobre el servidor quehemos creado, revisar la configuracion del mismo, ya que posiblemente no tengamos problemaspara acceder a el desde el ordenador donde esta alojado el servidor pero sı desde uno externo.

Por defecto, siempre aparecera el puerto 3001 al poner la IP. Esto se debe a que los puertospor defecto son:

3000 para BotConnection

3001 para ControlServer

3002 para SpectatorConnection

Ahora, el servidor esta en ejecucion y la IDE sabe como conectarse a el. Para ejecutar el botsimplemente corremos el bot mediante el boton con el triangulo verde de “play”. Si todo funciona,el bot se conectara al servidor y Netbeans nos mostrara la informacion referente a su ejecucion. Siqueremos inspeccionar el bot desde el juego, tenemos dos opciones.

Abrir el juego y conectarnos al servidor como jugadore o espectador.

Desde NetBeans, hacer click derecho sobre el servidor y seleccionar Spectate (Figura D.6).

Por ultimo, GAMEBOTS2004 incluye funcionalidades especiales, tales como la visualizacion delos navegadores y las lıneas de movimiento, los rayos para detectar obstaculos, etc., los cuales pode-mos activar y desactivar a nuestro antojo mediante un menu al que podemos acceder presionandoALT + H durante la ejecucion del juego (Figura D.7).

64

Figura D.4: Anadir servidor UT2004 a NetBeans

Figura D.5: Host del servidor UT2004 en NetBeans

D.2. Modos de movimiento del bot

Existen dos maneras prefijadas para tratar el movimiento de los bots.

1. Navegacion: El bot se mueve eligiendo un punto de navegacion en el mapa y calculando la

65

Figura D.6: Modo espectador en UT2004 desde NetBeans

Figura D.7: Consola del comandos con opciones propias de Pogamut 3 para UT2004

ruta a seguir para alcanzar dicho punto de navegacion (navpoint).

2. Raycasting: El bot se mueve basandose en la geometrıa del mundo, analizandola a travesde rayos en busca de intersecciones.

A continuacion se explica en detalle ambas implementaciones, las cuales podrıan ser usadas enparalelo, creando un bot mas completo.

66

D.2.1. Bot de Navegacion

El mapa esta cubierto por nodos llamados puntos de navegacion (navpoints). En teorıa cadanavpoint esta situado en un sitio seguro y alcanzable por el bot. Los puntos conectados estanunidos por una lınea. Para que el bot sea capaz de ir de un sitio A a un sitio B, vamos a necesitaruna planificador de ruta: Path planner.

En Pogamut existen distintos interfaces de Path planner, siendo UT2004A StarPathPlannerel planificador por defecto. Este planificador usa el algoritmo A* para el calculo de rutas, siendoexactamente el mismo que el de los bots nativos de UT. Tambien existe otra implementaciondeclarada en FloydWarshallPathPlanner, la cual precalcula todas las rutas posibles entre todos losnodos al principio, lo cual tiene un coste inicial considerable. Cabe decir que podemos implementarnuestro propio algoritmo planificador.

Una vez tenemos la ruta calculada ya solo nos queda ejecutarla, de ello se encarga el Pathexecutor. Este modulo contiene el Path navigator que es el que se encargar de recorrer la rutacalculada anteriormente, evitar obstaculos, abrir puertas, esperar ascensores,etc. El navegador pordefecto es UT2004PathNavigator. En este caso, tambien podemos crear nuestro propio navegador.

Veamos un ejemplo de implementacion:

Algoritmo D.1 Ejemplo de bot de navegacion

protected void goToRandomNavPoint() {targetNavPoint = pickRandomNavPoint();// find path to the random navpoint, path is computed asynchronously// so the handle will hold the result onlt after some timeIPathFuture<ILocated> pathHandle = pathPlanner.computePath(info.getLocation(), targetNav-Point);// make the path executor follow the path, executor listens for the// asynchronous result of path planningpathExecutor.followPath(pathHandle);}

En el ejemplo podemos ver como crea un punto de navegacion al azar, y encontramos la rutahasta dicho punto. Una vez la tenemos con followPath hacemos que el bot siga la ruta calculada.

Podemos declarar un listener dentro del Path Executor, para ser notificados acerca del estadodel bot mientras ejecuta la ruta. Esto sera util para saber si el bot se ha atascado, si el bot hallegado a su destino o incluso si la ejecucion de la ruta ha fallado.

Para hacer un uso mas simple y potente de la navegacion a traves de navpoints del bot,podemos usar la libreria Jungigation. Las principales ventajas de son:

Exclusion de lıneas prohibidas: Ası evitaremos el calculo de una mala ruta.

Planificacion avanzada basada en los objetos del mapa

Saber exactamente el tiempo en segundos de la ruta.

El principal anadido de esta librerıa es que el planificador de ruta solo usa caminos que han sidoprobados y que se sabe con seguridad que el bot puede ir por ellos. Para ello hemos tenido quepreviamente usar una utilidad para calcular dichas rutas, por lo que esta funcionalidad no serainteresante a no ser que implementemos un bot con aprendizaje.

A la hora de testear nuestro bot con navegacion, podemos seguir a traves de UT a nuestro bot,haciendo visibles en el mapa (ALT+G) los puntos y lıneas de navegacion. Otra forma es visualizarel mapa de navegacion desde Netbeans.

67

D.2.2. Bot con raycasting

Como hemos dicho anteriormente el raycasting se base en rayos, a traves de los cuales veremossus intersecciones con el mundo/mapa. Para usar raycasting en nuestro bot, debemos seguir trespasos:

1. Activar raycasting y visualizacion de rayos: podemos hacerlo de dos formas, o biencomputar continuamente las intersecciones de los rayos con el mundo (Autotrace=true) obien definir nuestros rayos y calcular solo las intersecciones que nos interesen (DrawTraceLi-ne=true).

2. Inicializar rayos: definimos los rayos que deseemos a traves de AddRay, pasandole comoparametros principales el nombre, el vector de direccion y la longitud del rayo. Podemos creartantos rayos como queramos.

3. Manejar resultados: una vez que el rayo ha sido lanzado, UT nos devuelve el resultadoen un mensaje. Podemos tratarlos de dos maneras: Creando un listener y que nos notifiquecuando un rayo ha recibido algo del entorno o bien comprobando la presencia de algun objetoperiodicamente, por ejemplo en el metodo logic().

Cuando ya hayamos sido notificados, definiremos las funciones de actuacion que nos interesen y elobjeto de AutoTrace ray sera actualizado automaticamente.

D.3. Implementacion del bot

Crear un bot Una vez que ya tenemos el servidor conectado a Netbeans es el momento deempezar a programar el bot. Para eso lo primero es entender que nos da Netbeans con su plantillabasica, y a partir de ahı desarrollar nuestro propio codigo.

D.3.1. Clases principales

En este apartado vamos a explicar las clases esenciales para crear un bot, desde la que seencarga de dar vida al bot a la que le permite moverse.

cz.cuni.amis.pogamut.ut2004.utils.SingleUT2004BotRunner

Esta clase es la encargada de lanzar un thread de ejecucion para hacer correr al bot. Se situadentro del main principal. Primero se establecen los parametros con el servidor (host y port).Pueden ser de manera manual o que sea la propia clase que los encuentre. Despues de establecerlos parametros se llama a startAgent() que es la encargada de lanzar el thread de ejecucion. Seacaba cuando se elimina al bot de la partida.

cz.cuni.amis.utils.exception.PogamutException

En todas las funciones donde se ejecutan instrucciones de pogamut se anade esta clase paracapturar excepciones. Unicamente se encarga de tratar cualquier excepcion de pogamut que sepueda producir dentro de la funcion. En las funciones iniciales solo esta definido en main() y enlogic()

cz.cuni.amis.pogamut.ut2004.bot.impl.UT2004BotModuleController

Esta clase contiene el controlador mas avanzado del sistema. Tiene todos los modulos utilespara manejar el bot. Es la clase principal. Antes de pasar a explicar los modulos vamos a comentarlas funciones iniciales del bot que se encargan de establecer la secuencia inicial de ejecucion. Estasecuencia inicial de ejecucion se corresponde a este protocolo de GameBots2004:

68

1. Llama a this.prepareBot()

2. → Recibe un mensaje HELLO BOT, siendo el primer mensaje dentro de UT2004, el cual seencarga de pedir la conexion de un bot con el servidor. Si el servidor esta lleno se termina laconexion.

3. ← Envıa un mensaje READY. Como respuesta el servidor te envıa al juego un mensaje NFOcon informacion sobre la partida.

4. Ahora es cuando se establece la comunicacion con GameBots2004.

5. → Captura el evento InitCommandRequested confirmando que la inicializacion esta prepa-rada.

6. Ejecuta this.getInitializeCommand().

7. ← Envıa el comando INIT que se ha creado en la funcion anterior, con los parametros inicialesdel bot.

8. → Recibe el mensaje ConfigChange.

9. →Recibe el mensaje InitedMessage.

10. Llama a this.botInitialized().

11. . . . se recibe el primer mensaje SLF mostrando la informacion que el bot ya puede conocerde sı mismo, al haber sido introducido ya en el sistema. Tambien recibe el mensaje END paraterminar la comunicacion sıncrona con el servidor.

12. Ejecuta this.botSpawned().

13. El bot pasa a correr dentro del entorno por medio de la funcion logic().

Todos estos pasos se explican mas en detalle ahora al conocer las funciones iniciales que se ejecutanen este protocolo de comunicacion.

prepareBot()

Incluida en la clase cz.cuni.amis.pogamut.ut2004.bot.impl.UT2004BotController.

Se encarga de establecer la configuracion del mundo antes de saber nada sobre el UT2004.Simplemente prepara el sistema virtual. Se ejecuta antes de conectar al bot con el entorno perodespues de construir el UT2004Bot.

getInitializeCommand()

Incluida en la clase cz.cuni.amis.pogamut.ut2004.bot.impl.UT2004BotController.

Aquı es donde caracterizamos a nuestro bot con las opciones que deseemos. Envıa un objetoInitialize que contiene todos los parametros generales del bot.

Para poder tratar con este objeto hay que importar la clase Initialize que esta dentro de laliberıa cz.cuni.amis.pogamut.ut2004.communication.messages.gbcommands al igual que el resto decomandos de pogamut que veremos mas adelante.

La clase Initialize se corresponde al comando de GameBots2004 INIT.

69

botInitialized(GameInfo info, ConfigChange config, InitedMessage init)

Incluida en la clase cz.cuni.amis.pogamut.ut2004.bot.impl.UT2004BotController.Primera vez que el bot tiene informacion sobre el mundo, aunque todavıa no ha sido creado.Se llama a esta funcion una vez que el servidor ha enviado el mensaje INITED (clase de java:

InitedMessage). Esto significa que el comando INIT (Initialize) ha sido ejecutado correctamente yla comunicacion entre el bot y el servidor es correcta. En este momento ya es posible establecernuevas comunicaciones entre el bot y el servidor por medio de comandos, aunque todavıa el botno ha sido creado en el entorno, ası que los comandos de movimiento no se pueden ejecutar.

Contiene los primeros parametros de configuracion del bot dentro del entorno, informacion deljuego en ese momento (GameInfo), configuracion del sistema actual (ConfigChange) y mensajesde inicializacion (InitedMessage).

Hay que importar las clases GameInfo, ConfigChange e InitedMessage dentro de la libre-rıa cz.cuni.amis.pogamut.ut2004.communication.messages.gbinfomessages, al igual que el resto demensajes que genera pogamut.

El parametro GameInfo info se corresponde con el mensaje NFO de GameBots2004, el cual seenvıa como respuesta al comando READY. Contiene informacion sobre el tipo de juego, el mapa,numero de equipos. . .

El parametro ConfigChange config se corresponde con el mensaje CONFCH de GameBots2004,el cual se envıa cada vez que la configuracion del bot cambia.

El parametro InitedMessage init se corresponde con el mensaje INITED de GameBots2004, elcual se envıa una vez que el comando INIT ha sido recibido correctamente. Contiene informacionde los atributos del bot, como su velocidad, maxima salud. . .

botSpawned(GameInfo info, ConfigChange config, InitedMessage init, Self self)

Incluida en la clase cz.cuni.amis.pogamut.ut2004.bot.impl.UT2004BotController.Se ejecuta cuando se crea el bot por primera vez, justo al entrar en el entorno del juego. Cuando

el bot renace despues de haber sido matado no ejecuta esta funcion.Se puede llamar de manera automatica activando la opcion ManualSpawn en el comando INIT

o de manera manual dentro de botInitialized con la funcion respawn().El parametro Self self se corresponde con el mensaje SLF de GameBots2004, el cual envıa

informacion sobre el estado del bot, en este caso, nada mas haber sido creado. La clase se importadesde cz.cuni.amis.pogamut.ut2004.communication.messages.gbinfomessages.

Logic()

Incluida en la clase cz.cuni.amis.pogamut.ut2004.bot.impl.UT2004BotLogicController. Funcion principal del sistema. Entra justo despues de crear el bot

con botSpawned.. Solo se sale de ella cuando tiene lugar algun evento externo (se muere el bot) ocuando se elimina al bot de la partida. Todo lo que se ejecute dentro debe ser procesado rapidamenteya que se ejecuta iterativamente cada 0.25 segundos, por lo que no es recomendable hacer buclesen su interior.

botKilled(BotKilled event)

Incluida en la clase cz.cuni.amis.pogamut.ut2004.bot.impl.UT2004BotController. Se activa cuando se produce un evento avisandote de que tu bot ha

muerto. Se genera un mensaje asıncrono dentro del sistema que hace que salgas de la logic(). Estemensaje asıncrono se corresponde con el mensaje DIE de GameBots2004.

Entre otras cosas, puede avisar con un log de usuario que nuestro bot ha muerto, cambiarla apariencia del bot o cualquier otro cambio que queramos antes de que renazca y vuelva a lapartida.

70

Para poder ejecutar la funcion es necesario importar la clase BotKilled desde cz.cuni.amis.pogamut.ut2004.communication.messages.gbinfomessages, para poder cargar la clase que contieneel mensaje.

D.3.2. Clase ModuleController

En esta seccion vamos a centrarnos en todos los componentes contenidos en la claseUT2004ModuleController.

Doce de sus componentes son modulos completos y complejos que permiten recoger y enviarinformacion sobre el bot y sobre su entorno. Estos son dichos modulos:

Game

Info

Players

Descriptors

Items

Senses

Weaponry

Config

RayCasting

Body

❼ Shoot

❼ Move

A parte de estos modulos existen otros componentes muy importantes para ayudar con el manejodel bot pero que no se les puede considerar modulos propiamente dichos.

Random

PathPlanner

PathExecutor

ListenerRegistrator

Act

World

A continuacion vamos a explicar todos (los modulos y el resto de componentes), incluyendo lamayorıa de acciones que se pueden realizar con ellos.

71

Game

Se encuentra dentro de esta librerıa: cz.cuni.amis.pogamut.ut2004.agent.module.sensor.Modulo de memoria especializado en obtener informacion general sobre el juego.Se puede usar a partir de botInitialized(), ya que es la primera vez que se tiene informacion sobre

el mundo debido a los mensajes que ya han ido llegando por parte del servidor como GameInfoe InitedMessage. El modulo se abastece entre otras de la informacion proporcionada por estosmensajes.

Requiere la clase bot como parametro.Con este modulo podemos saber:

Tipo de juego (DeathMatch, Capturar bandera, etc).

Nombre del mapa en el que se jugara.

Tiempo total y el tiempo que habra para jugar antes de cambiar de escenario.

Numero maximo de equipos y puntuaciones de los equipos (o jugadores).

Salud, armadura y adrenalina que dispondra el bot al inicio y la maxima que puede llegar aconseguir.

Estado de inicio del bot (parado o en movimiento)

A parte de tener informacion sobre el juego, dispone de una serie de listeners que permiten ac-tualizar el modulo cada vez que uno de los mensajes que afectan al modulo llega. Estos son loseventos/mensajes que controla el modulo por medio de los listeners:

GameInfo.

InitedMessage.

BeginMessage.

MutatorListObtained.

FlagInfo.

Info

Se encuentra dentro de esta librerıa: cz.cuni.amis.pogamut.ut2004.agent.module.sensor.Es un modulo de memoria especializado en informacion general sobre el paradero del agente.Se puede usar a partir de botSpawned() ya que es la primera vez que el bot existe y recibe

informacion sobre su estado por medio del mensaje Self.Aparte de la clase bot, tambien requiere como parametro el modulo Game.Con este modulo podemos saber todo esto sobre el bot:

u nombre y su equipo.

Que jugadores y equipos son enemigos y quienes son amigos.

Localizacion:

❼ Donde esta.

❼ Distancia a la que esta de un lugar.

❼ Comprobacion de si esta en una localizacion exacta.

❼ Posicion a la que se encuentra respecto al suelo para saber si esta en un tejado

❼ en algun lugar elevado.

72

Rotacion sobre el sistema de coordenadas en el que se encuentra, permitiendo la direcciona-lidad del bot.

Velocidad actual.

Posicion en la que se encuentra:

❼ En movimiento

❼ Agachado

❼ Andando

❼ Frente un objeto . . .

Comprobar si posee habilidades especiales o bonos:

❼ Multiplicador de dano.

❼ Invisibilidad.

❼ Otros mutators definidos al iniciar el servidor de la partida.

Salud, armadura y adrenalina actual.

Cuales son sus armas en uso (primaria y secundaria).

Cantidad de municion en cada arma en uso (primaria y secundaria).

Comprobacion de si esta disparando o no y que arma esta usando.

Puntuaciones propias (puntos, muertes. . . ).

Caracterısticas fısicas del mapa y el entorno que le afectan:

❼ Friccion del suelo.

❼ Friccion de fluidos.

Saber si esta dentro del agua o no.

Saber si el lugar donde esta le produce dano (lava. . . ) y la cantidad de dano producido pordicho elemento.

Saber si esta en un lugar que le produce la muerte (casi) instantanea.

Tipo de dano que le esta produciendo el lugar.

Comprueba si el lugar donde esta le prohıbe usar su inventario (armas u objetos)

Comprueba si el lugar donde esta afecta al disparo de proyectiles (viento. . . )

Maxima velocidad alcanzable en el suelo, en el aire, en un escalon, en el agua, cayendose oesquivando objetos.

Ratio de aceleracion. ❼ Informa si se puede mover mientras esta en el aire.

Informa sobre el punto de navegacion mas cercano.

Informa sobre el punto de navegacion visible mas cercano.

Informa sobre el objeto mas cercano.

Informa sobre el objeto visible mas cercano.

73

Informa sobre el jugador mas cercano.

Informa sobre el jugador visible mas cercano.

A parte de todo esto, tambien dispone de una serie de listeners que se encargan de actualizar losdatos del modulo.

Estos son los eventos/mensajes que controla el modulo por medio de los listeners:

BotKilled (numero de suicidios).

PlayerKilled.

InitedMessage.

PlayerScore.

TeamScore.

VolumeChanged.

Self.

ConfigChange.

Players

Se encuentra dentro de esta librerıa: cz.cuni.amis.pogamut.ut2004.agent.module.sensor.Es un modulo de memoria especializado en informar sobre otros jugadores. Todos los objetos

de este tipo se auto-actualizan a lo largo del tiempo hasta que son destruidos.Se puede usar a partir de botInitialized(), ya que es la primera vez que el bot tiene informacion

sobre el mundo.Requiere la clase bot como parametro.Este modulo permite al bot conocer todo esto sobre el resto de jugadores:

Comprobar si puede alcanzar a otros enemigos, amigos o jugadores.

Mapa con todos los enemigos, amigos o jugadores que son alcanzables.

Comprobar si puede ver a otros enemigos, amigos o jugadores.

Mapa con todos los enemigos, amigos o jugadores que son visibles.

Mapa (id+player) de todos los enemigos o amigos.

Informar sobre el enemigo, amigo o jugador mas cercano.

Informar sobre el enemigo, amigo o jugador visible mas cercano.

Ultimos datos sobre un jugador.

Datos sobre un jugador, enemigo o amigo elegido de manera aleatoria.

Comprobar si un equipo o jugador es amigo o enemigo.

Tambien dispone de una serie de listeners que se encargan de actualizar los datos del modulo. Estosson los eventos/mensajes que controla el modulo por medio de los listeners:

Player.

PlayerLeft.

Self.

Para tener informacion sobre como han muerto los jugadores usar el modulo “senses”.

74

Descriptors

Se encuentra dentro de esta librerıa: cz.cuni.amis.pogamut.ut2004.agent.module.sensor.Es un modulo sensorial que informa de las caracterısticas generales de cualquier Item, en este

caso son la categorıa a la que pertenece (Weapon, Ammo, Health, Armor, Shield, Adrenaline, Other)y el grupo al que pertenece (Assault Rifle, Minigun. . . , Health, Mini Health. . . , Small Armor,Super Armor, Adrenaline, Udamage, Key. . . ).

El conjunto de las categorıas que puede tener un ıtem esta dentro de un mapa hash formadopor el nombre de la categorıa y el tipo de ıtem que es. Ocurre lo mismo con los grupos.

Suele combinarse con el modulo ıtems por medio de mapas hash para tener una informacioncompleta sobre los ıtems del escenario y su descriptor asociado.

Este modulo se puede usar a partir de botInitialized(), ya que es la primera vez que el bot tieneinformacion sobre el mundo.

Requiere la clase bot como parametro.

Items

Se encuentra dentro de esta librerıa: cz.cuni.amis.pogamut.ut2004.agent.module.sensor.Es un modulo de memoria especializado en objetos que se encuentran en el mapa.Se puede usar a partir de botInitialized(), ya que es la primera vez que el bot tiene informacion

sobre el mundo.Aparte de la clase bot, tambien requiere el modulo Info como parametro.Con este modulo se pueden obtener:

Mapas con todos los items del escenario. Tambien se puede restringir la busqueda a los objetosvisibles o a los alcanzables. Incluso se puede reducir mas pidiendo solo los ıtems que tenganun tipo, una categorıa un grupo o un id determinado.

Obtener un unico ıtem.

Mapas con la lista de puntos donde salen los items. Se puede restringir pidiendo solo los ıtemsque tengan un tipo, una categorıa un grupo o un id determinado.

Mapas con la lista de puntos donde ahora mismo hay ıtems disponibles. Se puede restringirpidiendo solo los ıtems que tengan un tipo, una categorıa un grupo o un id determinado.

Tambien dispone de una serie de listeners que se encargan de actualizar los datos del modulo. Estosson los eventos/mensajes que controla el modulo por medio de los listeners:

Item.

MapPointsListObtained.

NavPoint.

EndMessage.

ItemPickedUp.

Senses

Se encuentra dentro de esta librerıa: cz.cuni.amis.pogamut.ut2004.agent.module.sensor.Es un modulo de memoria especializado en la parte sensorial del agente.Se puede usar a partir de botInitialized(), ya que es la primera vez que el bot tiene informacion

sobre el mundo.Aparte de la clase bot requiere como parametros a los modulos Info y Players.Con este modulo podemos controlar todo esto sobre el bot:

75

Saber como murio.

Informar sobre el jugador que le ha golpeado.

Informar sobre la localizacion donde fue golpeado o donde se choco con un objeto del mapa.

Ultimo elemento recogido.

Ultimo dano que ha causado.

Ultimo dano que le han hecho.

Ultimo tiro que le impacto.

Coordenadas donde se ha escuchado un ruido y el tipo de ruido que lo ha producido.

Informar sobre la muerte de un jugador

Comprobar si alguna de estas acciones ha sucedido (ahora o recientemente):

❼ Ha muerto recientemente.

❼ Ha obtenido adrenalina recientemente.

❼ Le estan hiriendo.

❼ Esta golpeando a otro jugador.

❼ Esta causando dano a alguien.

❼ Esta chocando con un elemento del mapa.

❼ Esta cayendo por un borde.

❼ Esta escuchando algun ruido.

❼ Ha recogido algun elemento recientemente.

❼ Algun jugador acaba de morir.

❼ Esta siendo danado por algun jugador.

❼ Esta viendo algun proyectil.

Este modulo conecta un monton de listeners y proporciona muchos metodos para saber el actualestado del bot.

Estos son los eventos/mensajes que controla el modulo por medio de los listeners:

Bumped.

WallCollision.

FallEdge.

HearNoise.

HearPickup.

BotDamaged.

IncomingProjectile.

PlayerDamaged.

PlayerKilled.

AdrenalineGained.

BotKilled.

ItemPickedUp.

BeginMessage.

76

Weaponry

Se encuentra dentro de esta librerıa: cz.cuni.amis.pogamut.ut2004.agent.module.sensomotoric.Es un modulo de memoria especializado en el inventario del bot (armas y municion).Se puede usar a partir de botInitialized(), ya que es la primera vez que el bot tiene informacion

sobre el mundo.Aparte de la clase bot, requiere como parametro el modulo Descriptors con la informacion

referente al tipo de arma.El modulo le permite al bot saber:

La cantidad de municion del arma actual (disparo primario y secundario) o de todas lasarmas del inventario.

Caracterısticas del arma que esta usando.

Armas cuerpo a cuerpo que dispone.

Permite cambiar el arma por otra disponible en el inventario.

Si alguna de estas condiciones se cumple:

❼ Tiene municion en el arma actual

❼ Tiene algun arma de cuerpo a cuerpo en el inventario.

❼ Tiene algun arma de disparar en el inventario.

❼ Tiene algun arma.

❼ Tiene municion en el arma primaria o secundaria.

❼ Tiene el arma en el inventario y esta cargada.

Dispone de una serie de listeners que se encargan de actualizar los datos del modulo.Estos son los eventos/mensajes que controla el modulo por medio de los listeners:

AddInventoryMsg.

ItemPickedUp.

WeaponUpdate.

SelfUpdate.

Thrown.

BotKilled.

Config

Se encuentra dentro de esta librerıa: cz.cuni.amis.pogamut.ut2004.agent.module.sensomotoric.Es un modulo de memoria especializado en la configuracion del agente dentro de UT2004.Este modulo se puede usar a partir de botInitialized(), ya que es la primera vez que el bot tiene

informacion sobre el mundo.Se necesita la clase bot.Este modulo permite realizar todo esto:

Obtener y modificar la configuracion general del bot dentro del juego (todos los camposcargados con Initialize).

Consultar o modificar la velocidad de rotacion del bot. Girara mas o menos rapido segun elvalor que se elija.

77

Cambiar el retraso entre envıos sıncronos (de 0.1 a 2 segundos).

Comprobar y modificar el uso de raytracing.

Comprobar y modificar el uso invulnerabilidad.

Comprobar y modificar la regeneracion automatica del bot cada vez que lo maten. Si se activa,cada vez que el bot muera renacera instantaneamente, en el otro caso habra que llamar a lafuncion “respawn” en algun momento para que renazca el bot.

Activar o no la focalizacion del bot en un objetivo siempre que lo haya detectado. Si se activapermite al bot desplazarse a una localizacion pero mirando hacia otro lado.

Activar o no todos los mensajes sıncronos. Si no se activa hay alguno de los mensajes sıncronosdel sistema que no se habilitan para una mayor fluidez del juego.

Activar o no la recogida automatica de ıtems. Si no se activa, hay que ejecutar el comandoPick cada vez que se quiera recoger un ıtem del escenario.

En este modulo solo hay un listener que controla un unico evento/mensaje:

ConfigChange.

RayCasting

Soporte para la creacion de rayos que permiten detectar objetos en la escena. El rayo se poneverde cuando el camino esta libre y rojo cuando hay obstaculos en la direccion y longitud del rayo.Lo que consiguen los rayos es que el bot circule solo por las zonas donde los rayos son verdes.

Requiere la clase bot como parametro.A la hora de crear un rayo hay que introducir estos campos que determinan su forma:

Direccion del rayo. Indica en que direccion apunta, tomando como punto (0,0,0) el bot.

Longitud del rayo, a mayor longitud mas lejos detecta objetos pero tambien es mas facil quese bloquee el bot al tener todos los rayos en rojo.

Elegir entre los 2 tipos de rayos posibles:

❼ Rapido pero escaso de informacion.

❼ Lento pero mas completo.

Condicion booleana para activar o no el vector normal con respecto al suelo. Si se activa hayque tener en cuenta para la direccion del rayo la normal con respecto al suelo.

Condicion booleana para tener en cuenta como obstaculos a los agentes dentro del juego osolo tener en cuenta la geometrıa.

Despues de inicializar todos los rayos hay que preparar los rayos para que escuchen lasrespuestas.

raycasting.getAllRaysInitialized().addListener(new FlagListener<Boolean>())

Con esta lınea inicializa los rayos y activa el listener flag que se encarga de avisar cuandoalguno de los rayos toca algo (se vuelve rojo).

Los rayos creados son de tipo “AutoTraceRay”. Cada uno de estos rayos te permite saber:

La localizacion exacta del objeto detectado.

78

El tiempo global en el cual el objeto fue visto o actualizado por ultima vez.

Si ha sido golpeado el rayo por algun objeto.

El vector normal del plano donde el rayo ha sido golpeado.

Este modulo se puede usar a partir de botInitialized(), ya que es la primera vez que el bot tieneinformacion sobre el mundo.

Body

Esta es la clase que contiene a este modulo: cz.cuni.amis.pogamut.ut2004.bot.command. Com-pleteBotCommandsWrapper.

Maneja los comandos que pueden ser usados como entrada de datos en el bot, todos ellospertenecientes a cz.cuni.amis.pogamut.ut2004.communication.messages.gbcommand.

Requiere la clase bot como parametro. Dentro de este modulo existen otros 6 modulos:

Action Proporciona los comandos de accion del bot. o Arrogar armas o Iteracion con elementosdel entorno (recoger ıtems) o Otros comandos que no han podido ser clasificados en otrascategorıas (renacer).

Communication Proporciona los comandos de comunicacion. o Enviar mensajes (privados, glo-bales o de equipo). o Recibir mensajes (privados, globales o de equipo).

ConfigureCommands Permite cambiar los atributos del bot. Nombre, skin, velocidad de movi-miento y de rotacion, invulnerabilidad, etc.

AdvancedLocomotion Modulo “move”, explicado a continuacion.

AdvancedShooting Modulo “shoot”, explicado a continuacion.

SimpleRayCasting Control basico de rayos. Similar al modulo comentado anteriormente de“ray-Casting”. Su funcionalidad es la misma, el uso de rayos para detectar por donde puede moverseel bot y por donde no puede hacerlo.

Este modulo se puede usar a partir de prepareBot(), permitiendo usar alguna de sus funciones antessiquiera de tener el escenario cargado.

Shoot

Esta es la clase que contiene a este modulo: cz.cuni.amis.pogamut.ut2004.bot.command. Ad-vancedShooting.

Son acciones de disparo avanzadas que puede realizar el bot (no te dan informacion, soncomandos que tu mandas al sistema para que el bot dispare). Estos son las acciones de disparo:

Disparar arma actual con el modo seleccionado a un jugador o a un objeto. Si se gira entre15➸ o 30➸ como mınimo dejara de disparar al objetivo. Seguira al objeto hasta que llegue otrainstruccion que le haga cambiar su foco de atencion.

Disparar arma actual con el modo seleccionado a una localizacion concreta. Si se gira entre15➸ o 30➸ como mınimo dejara de disparar al objetivo.

Disparar arma primaria a un jugador o a un objeto. Si se gira entre 15➸ o 30➸ como mınimodejara de disparar al objetivo. Seguira al objeto hasta que llegue otra instruccion que le hagacambiar su foco de atencion.

Disparar arma primaria a una localizacion concreta. Si se gira entre 15➸ o 30➸ como mınimodejara de disparar al objetivo.

79

Recargar arma primaria

Disparar arma secundaria a un jugador o a un objeto. Si se gira entre 15➸ o 30➸ como mınimodejara de disparar al objetivo. Seguira al objeto hasta que llegue otra instruccion que le hagacambiar su foco de atencion.

Disparar arma secundaria a una localizacion concreta. Si se gira entre 15➸ o 30➸ como mınimodejara de disparar al objetivo.

Recargar arma secundaria

Parar de disparar el arma actual.

Parar de disparar completamente sin tener en cuenta el modo de disparo.

En este modulo solo hay un listener que controla un unico evento/mensaje:

BeginMessage.

Move

Esta es la clase que contiene a este modulo: cz.cuni.amis.pogamut.ut2004.bot.command. Ad-vancedLocomotion.

Son movimientos avanzados que puede realizar el bot (no te dan informacion, son comandosque tu mandas al sistema para que el bot se mueva). Estos son los movimientos:

Esquivar disparos u objetivos, realizando un salto en la direccion indicada.

Salto simple o Salto doble en la direccion que se encuentra.

Ir de una localizacion (con vector de direccion incluido) a otra localizacion. Primero llega ala localizacion inicial. Evita tener que realizar dos moveTo ya que entre uno y otro tiene unaparada.

Correr de manera continua hace delante, hasta que le entre otro comando que le haga cambiarla velocidad.

Moverse a una localizacion desde la que esta ahora mismo .

Cambiar la velocidad de giro, la velocidad de carrera y la velocidad de andar.

Parar el bot en seco. Elimina cualquier movimiento o giro que estuviera haciendo.

Girar la cara hacia un objeto o jugador. Poner el foco de atencion en dicho objeto o jugador.

Rotar horizontal o verticalmente el bot una cantidad de grados dados, para cambiar la vistadel bot .

Disparar a derecha/izquierda una determinada distancia.

Random

Modulo generador de numeros aleatorios especialmente utiles a la hora de llevar a cabo unatoma de decisiones.

80

PathPlanner

Esta es la librerıa que contiene a este modulo: cz.cuni.amis.pogamut.base.agent.navigation.

Se encarga de calcular la ruta de acceso a un punto usando como apoyo los puntos de navegaciondel mapa.

A partir de dos puntos del mapa es responsable de encontrar la ruta generica, incluso si noencuentra ninguna ruta te avisa de ello por medio de la excepcion cz.cuni.amis.pogamut.Client.navigation.PathNotConstructable.

Hay varias formas de implementar esta ruta, como pueden ser el algoritmo de Dijkstra, A*. . .

El metodo A* ya esta implementado dentro de pogamut. Se encuentra en la misma librerıaque el PathPlanner. A* se dedica a buscar el camino mas corto y a enviarlo a traves de mensajesde GameBots. Debido a las restricciones que tiene el PathPlanner solo puede devolver paths conun tamano maximo de 16 elementos.

Aun ası no es necesario seguir este metodo generico incluido dentro de pogamut. El programa-dor puede incluir su propio planificador de rutas y que el bot siga su planificador en vez de seguirel planificador por defecto.

Otro aspecto interesante es que permite gestionar de manera asıncrona el path. De esta maneranada mas empezar te da la ruta mas rapida que ha podido encontrar pero conforme va avanzandopor el path si encuentra otra ruta mejor, actualiza el path y sigue por esa nueva ruta. De estamanera es mas eficiente ya que reacciona rapido a la hora de buscar un path pero sobre la marchasigue intentado mejorar ese path.

Lo peor de seguir el PathPlanner de pogamut es que siempre sigue los puntos de navegacionpor lo que siempre va de punto a punto y no resulta muy realista, ası que aunque es una funcionbastante util, usarla tal como viene no ayuda a crear un bot humano.

Se inicializa con la funcion initializePathFinding() y si el path usado no es el generico se debesobrescribir este metodo para poder introducir el planificador propio.

Este modulo se puede usar a partir de botSpawned(), ya que necesita que el bot este cargadoen el mapa para poder empezar a calcular los puntos de navegacion.

Todo esto sobre el pathPlanner esta mas desarrollado en la parte del documento dedicada almovimiento.

PathExecutor

Esta es la librerıa que contiene a este modulo: cz.cuni.amis.pogamut.base.agent.navigation.

Se encarga de ejecutar el pathPlanner que haya sido calculado previamente.

Carga los listeners necesarios para detectar cuando ha llegado a uno de los puntos.

Cuando ha llegado a uno de los puntos del path vuelve a pedir el pathPlanner por si ha sidoactualizado mientras estaba en ejecucion. Con ese nuevo path vuelve a moverse hasta el siguientepunto y ası hasta completar todo el pathPlanner calculado.

El pathExecutor es de tipo UTPathExecutor, encargado de enviar los mensajes de GameBotspara que el bot actue.

Es capaz de saber el Id del proximo objetivo, ya sea un objeto del mapa, una persona o unpunto concreto del mapa. Normalmente sigue los puntos de navegacion pero el punto final notiene porque ser un punto de navegacion, puedes apuntar a un player que se esta moviendo y elpathPlanner se va actualizando siguiendo los puntos de navegacion y una vez se pare el player,con el ultimo mensaje del pathExecutor llegar al player aunque no este situado en un punto denavegacion.

Este modulo se puede usar a partir de botSpawned(), ya que necesita que el bot este cargadoen el mapa para poder empezar a calcular los puntos de navegacion.

Todo esto sobre el pathExecutor esta mas desarrollado en la parte del documento dedicada almovimiento.

81

ListenerRegistrator

Es el metodo encargado de autoinicializar los listeners por medio de AnnotationListenerRegis-trator. Se encarga de proporcionar una manera sencilla y practica de registrar los listeners, inclusoencargandose de iterar entre todos los listeners registrados.

Hay 5 tipos de listeners diferentes:

EventListener

ObjectClassEventListener

ObjectClassListener

ObjectEventListener

ObjectListener

Ademas de registrar los listeners puede:

Eliminar los listeners que han sido creados.

Saber si un listener ha sido creado.

Saber la cantidad de listeners creados.

Todo este mundo de los eventos esta mejor explicado en otra parte del documento.

Act

Forma parte de IAct, que es el entorno encargado de gestionar todas las acciones y comandosque se pueden realizar en este mundo. Ligado a world (IVisionWorldView) ya que los dos juntosforman todo el entorno del juego, Uno se encarga de las acciones (IAct) y el otro del entorno y loseventos que suceden en el (IVisionWorldView).

En resumen Act es el encargado de controlar las acciones que se ejecutan como consecuenciade unos listeners.

No se usa mucho ya que todo lo que desde Act se puede hacer, es lo mismo que te permitenhacer todos los modulos antes comentados.

Por ejemplo:

body.getCommunication().sendGlobalTextMessage(”Hello world!”);

es lo mismo que usar,

getAct().act(new SendMessage().setGlobal(true).setText(”Hello world!”);

En este caso dentro de body.getCommunication() ya estan definidos todos los tipos de mensajesque se pueden enviar con funciones como sendGlobalTextMessage creadas, ası que es mucho masintuitivo a la hora de programar, por este motivos usaremos siempre la primera opcion y dejaremosel Act como recurso generico.

World

Forma parte de IVisionWorldView, que es el entorno encargado de gestionar el entorno y todoslos eventos que se producen en el. Ligado a act.

Este componente se relaciona con los eventos y los listeners que son en otra parte del docu-mento.

82

D.3.3. Otros comandos interesantes

Anotacion de java: @JProp

Anotacion que se coloca delante de las variables java que quieras monitorizar en tiempo deejecucion. En tiempo de ejecucion podemos acceder a estas variables, para modificarlas y ver sucomportamiento en el juego, desde “Servidores→ UT2004 servers→ Name Server→ Bot pogamut→ Introspection → Properties.

GBCOMMANDS

Esta librerıa cz.cuni.amis.pogamut.ut2004.communication.messages.gbCommands contiene to-dos comandos que se pueden introducir en GameBots. Al usar java con Netbeans no es necesariointroducir los comandos de manera literal. Java nos permite tener una clase para cada uno de loscomandos que se pueden manejar. Con esto cada vez que se use en una clase un comando

acciones que se pueden realizar en GameBots pero java nos da una interfaz mas compleja conla que poder utilizarlos sin tener que preocuparnos de tener que llamar a cada uno de los comandosde manera literal.

Ahora vamos a poner la lista de todas las clases de comandos, la mayorıa se entienden por simismas ası que no es necesario explicarlas, aun ası dentro del javadoc de pogamut hay un extensaexplicacion de los campos y las funciones que componen cada una de las clases (una por comando).Ademas en el javadoc se puede ver con que comando de GameBots esta relacionada cada clase.

Act

AddBot

AddInventory

AddRay

Combo

CommandPlayer

Configuration

ConfigurationObserver

Console

ContinuousMove

DialogBegin

DialogCancel

DialogEnd

DialogItem

DisconnectObserver

Dodge

DriveTo

EndPlayers

EnterVehicle

83

FactoryUse

FastTrace

GetAllInvetories

GetAllNavPoints

GetAllStatus

GetGameInfo

GetItemCategory

GetMaps

GetPath

GetPlayers

GetSelf

GetSpecialObjects

GetVisibleObjects

GiveInventory

ChangeAttribute

ChangeMap

ChangeTeam ChangeWeapon

CheckReachability

Initialize

InitializeObserver

Jump

Kick

LeaveVehicle

Move

PasswordReply Pause

Pick Ping

PlaySound

Quit

Ready

Record

RemoveRay

Respawn

84

Rotate

SendMessage

SetCrouch

SetDialog

SetGameSpeed SetLock SetPassword

SetPlayerControl

SetRoute

SetSendKeys

SetSkin

SetWalk

Shoot

ShowText

SpawnActor StartAnimation

StartPlayers

Stop

StopRecord

StopShooting

Throw

Trace

TurnTo

D.4. Eventos

D.4.1. Interaccion con el mundo

Las interfaces IworldView junto con Iact representan la API basica para acceder al mundo.

Informacion que recibimos (Listeners)

La interfaz IWorldView (cz.cuni.amis.pogamut.base.communication.worldview) nos ofrece tan-to los sentidos del bot y como memoria simple. El mundo es representado por:

Objetos (IworldObject): cz.cuni.amis.pogamut.base.communication.worldview.object ➒ Ali-veMessage ➒ AutoTraceRay ➒ BombInfo ➒ ConfigChange ➒ DominationPoint ➒ FlagInfo ➒

GameInfo ➒ IncomingProjectile ➒ InitedMessage ➒ Item ➒ ItemCategory ➒ Mover ➒ MyInven-tory ➒ NavPoint ➒ Player ➒ Self ➒ TeamScore ➒ Vehicle.

Eventos (IWorldEvent): cz.cuni.amis.pogamut.base. communication.worldview.event

❼ Dos Categorıas:

85

◦ Eventos de Objetos (IWorldObjectEvent): cz.cuni.amis.pogamut.base. communica-tion.worldview.object

⋄ WorldObjectAppearedEvent

⋄ WorldObjectDestroyedEvent

⋄ WorldObjectDisappearedEvent

⋄ WorldObjectFirstEncounteredEvent

⋄ WorldObjectUpdatedEvent

⋄ WorldObjectEvent (cualquiera de los eventos por parte del objeto)

◦ Eventos no asociados a ningun objeto (utilizados directamente de IWorldEvent).La lista de eventos es la siguiente. Observar que esta lista cuenta tambien conlos eventos pertenecientes a objetos, ya que podrıamos querer, por ejemplo, serconscientes de todos los objetos que apareciesen en pantalla, para lo que usarıamosWorldObjectAppearedEvent.

⋄ AddInventoryMsg

⋄ AdrenalineGained

⋄ AnimationBotID

⋄ AnimationEnd

⋄ AnimationPort

⋄ AnimationStop

⋄ BeginMessage

⋄ BotDamaged

⋄ BotFirstSpawned

⋄ BotKilled

⋄ Bumped

⋄ ComboStarted

⋄ DialogCommand

⋄ DialogFailed

⋄ DialogOk

⋄ EndMessage

⋄ EnteredVehicle

⋄ FactoryUsed

⋄ FallEdge

⋄ FastTraceResponse

⋄ GamePaused

⋄ GameResumed

⋄ GBEvent

⋄ GlobalChat

⋄ HandShakeEnd

⋄ HandShakeStart

⋄ HearNoise

⋄ HearPickup

⋄ HelloBotHandshake

⋄ HelloControlServerHandshake

⋄ HelloObserverHandshake

⋄ ChangedWeapon

⋄ InitCommandRequest

86

⋄ ItemCategoryEnd

⋄ ItemCategoryStart

⋄ ItemDescriptorObtained

⋄ ItemListEnd

⋄ ItemListStart

⋄ ItemPickedUp

⋄ JumpPerformed

⋄ KeyEvent

⋄ Landed

⋄ ListObtained

⋄ LockedVehicle

⋄ LostInventory

⋄ MapFinished

⋄ MapChange

⋄ MapList

⋄ MapListEnd

⋄ MapListObtained

⋄ MapListStart

⋄ MapPointListObtained

⋄ MoverListEnd

⋄ MoverListObtained

⋄ MoverListStart

⋄ Mutator

⋄ MutatorListEnd

⋄ MutatorListObtained

⋄ MutatorListStart

⋄ MyInventoryEnd

⋄ MyInventoryStart

⋄ NavPointListEnd

⋄ NavPointListStart

⋄ NavPointNeighbourLink

⋄ NavPointNeighbourLinkEnd

⋄ NavPointNeighbourLinkStart

⋄ ObjectSelected

⋄ PasswdOk

⋄ PasswdWrong

⋄ Password

⋄ Path

⋄ PathList

⋄ PathListEnd

⋄ PathListStart

⋄ PlayerDamaged

⋄ PlayerInput

⋄ PlayerJoinsGame

⋄ PlayerKilled

87

⋄ PlayerLeft

⋄ PlayerListEnd

⋄ PlayerListObtained

⋄ PlayerListStart

⋄ PlayerScore

⋄ Pong

⋄ ReadyCommandRequest

⋄ Reachable

⋄ RecordingEnded

⋄ RecordingStarted

⋄ ShootingStarted

⋄ ShootingStopped

⋄ Spawn

⋄ TeamChanged

⋄ TeamChat

⋄ Thrown

⋄ TraceResponse

⋄ Trigger

⋄ VolumeChanged

⋄ WallCollision

⋄ WeaponUpdate

⋄ WorldEventIdentityWrapper

⋄ WorldObjectAppearedEvent

⋄ WorldObjectDestroyedEvent

⋄ WorldObjectDisappearedEvent

⋄ WorldObjectEvent

⋄ WorldObjectFirstEncounteredEvent

⋄ WorldObjectUpdatedEvent

⋄ ZoneChangedBot

En el siguiente apartado se muestra una informacion mas detallada de los eventos pertenecientesa IWorldEvent.

Cuando queramos utilizar uno de estos eventos u objetos debemos incluir su correspondientelibrerıa. Para ello consultar en la API la librerıa concreta de cada uno.

Una vez explicado que informacion podemos obtener del mundo y de que manera, vamos a vercomo manipularla, es decir, cual es la forma mas sencilla de recibir dicha informacion.

La clase UT2004BotModuleController autoinicializa AnnotationListenerRegistrator. Esto quie-re decir que no sera necesario manipular los listeners manualmente, es decir, tener que anadirlos,elminarlos, etc. ademas de reprogramarlos, saber como iterar para seleccionar el adecuado en cadamomento, etc. En vez de eso, AnnotationListenerRegistrator permite registrar los listeners de for-ma muy sencilla y practica, y el mismo se encargara de iterar entre todos los listeners registrados.Una vez registrado el listener, definimos una funcion que realice las acciones deseadas en cada caso.

Hay cinco diferentes tipos de listeners que podemos registrar. Los dos ultimos son difıciles deusar, puesto que es difıcil obtener el strig correspondiente al id especıfico del objeto, pero es nece-sario saber de su existencia, aunque todavıa desconocemos como utilizarlos y si seran necesarios:

EventListener: reacciona al evento que nosotros definamos por medio del campo eventClass.Por ejemplo:

88

❼ Reg: @EventListener(eventClass = Bumped.class), reacciona a eventos de la clase Bum-ped.

❼ Proc: protected void bumped(Bumped event) {

ObjectClassListener: reacciona a todos los eventos ocurridos a una clase de objeto concreta,definida por medio del campo objectClass. Por ejemplo:

❼ Reg: @ObjectClassListener (objectClass = Player.class), reacciona a eventos ocurridosa la clase Player.

❼ Proc: protected void player(Player object) {

ObjectClassEventListener: reacciona a eventos de una clase concreta (de entre los eventosasociados a objetos) que ocurren a objetos de una clase concreta.

❼ Ej: @ObjectClassEventListener(eventClass = WorldObjectAppearedEvent.class, object-Class = Player.class), reacciona cuando un jugador cualquiera ”aparece” en nuestrocampo de vision.

❼ Proc: protected void playerAppeared(WorldObjectAppearedEvent<Player> event) {

ObjectListener: similar a ObjectClassListener para un objeto concreto, es decir, un objetocon un id determinado dentro una clase concreta.

ObjectEventListener: similar a ObjectClassEventListener para un objeto concreto, es decir,un evento de una clase concreta (de entre los eventos asociados a objetos) que ocurre a unobjeto con un id determinado dentro una clase concreta.

Informacion que enviamos (Actions)

Como hemos dicho, nuestro bot sera de la clase UT2004BotModuleControler, contenida encz.cuni.amis.pogamut.ut2004.bot.impl. Para dar ordenes al mismo no usaremos directamente lainterfaz IAct, es decir, pese a que somos libres de utilizar el metodo act (perteneciente como hemosdicho a la clase UT2004BotModuleControler), las acciones las enviaremos, de manera mas sencillae intuitiva, mediante el metodo body.

El metodo body esta dividido en los siguiente metodos:

Action getAction()

❼ Returns cz.cuni.amis.pogamut.ut2004.bot.commands.Action command module.

Communication getCommunication()

❼ Returns cz.cuni.amis.pogamut.ut2004.bot.commands.Communication command modu-le.

ConfigureCommands getConfigureCommands()

❼ Returns cz.cuni.amis.pogamut.ut2004.bot.commands.ConfigureCommands command mo-dule.

AdvancedLocomotion getLocomotion()

❼ Returns cz.cuni.amis.pogamut.ut2004.bot.commands.AdvancedLocomotion command mo-dule.

AdvancedShooting getShooting()

89

❼ Returns cz.cuni.amis.pogamut.ut2004.bot.commands.AdvancedShooting command mo-dule.

SimpleRayCasting getSimpleRayCasting()

❼ Returns cz.cuni.amis.pogamut.ut2004.bot.commands.SimpleRayCasting command mo-dule.

La clase UT2004BotModuleControler ofrece tambien los metodos shoot para acceder directamentea body.getShooting() y move para body.getLocomotion().

Para acceder a los mismos, debemos incluir las librerıas correspondientes a cada clase conte-nida en Action, Comunication, ConfigureCommands, AdvancedLocomotion, AdvancedShooting ySimpleRayCasting. Para ello consultar la API.

D.4.2. Descripcion de los eventos

En este apartado se trata de explicar de manera resumida los eventos mas importantes quetendremos que utilizar durante la implementacion de nuestro bot. Debemos tener en cuenta lassiguientes consideraciones:

Muchos de los eventos son utilizados para la conexion con el servidor y cosas por el estilo, locual ya esta implementado y no necesitamos para implementar nuestro bot.

Algunos de los eventos indican el principio y el final de la llegada de un lote sıncrono dedatos. (no se si es necesario o esta ya implementado en la clase que controle cada lote)

Nuestra implementacion esta orientada al tipo de partida DeathMatch sin chat, por lo queno tendremos en cuenta eventos referentes a equipos, banderas, chat, etc.

Los mas importantes

AddInventoryMessage: Enviado cuando conseguimos una nueva arma o municion para unarma que todavıa no tenemos (notifica nuevo objeto en nuestro inventario, no cuando lo recogemos).

AdrenalineGained: obtenemos adrenalina, recogiendola o matando a alguien.BotDamaged: nuestro bot ha sido danado.BotKilled: nuestro bot ha muerto.Bumped: nuestro bot es tocado por otro actor.ComboStarted: el jugador observado inicia un combo (el combo empieza cuando la adrenalina

llega a 100 y se va gastando al usarlo).FallEdge: enviado cuando estamos al borde de un precipicio. Si el bot estaba corriendo, el

mensaje llega cuando el bot esta ya cayendo. Si el bot estaba andando, cuando el mensaje llegaestamos al borde del precipicio (no podemos caer cuando andamos).

HearNoise: se dispara cuando oımos un sonido, lo cual puede ser un jugador caminando odisparando, una bala impactando contra el suelo, un ascensor subiendo y bajando, etc. Podemosconocer donde se produce el ruido y por que es producido.

HearPickup: oyes a otro jugador recogiendo un objeto del suelo.ChangedWeapon: enviado cuando el bot cambia el arma (el cambio de arma sera muy

probablemente debido a un comando introducido por nosotros mismos). Podemos saber que armausabamos antes del cambio y que arma usamos actualmente.

ItemPickedUp: cuando recogemos un item (no tiene por que anadirse a nuestro inventario,puede ser adrenalina o vida).

JumpPerformed: Enviado cuando el jugador observado salta.KeyEvent: enviado cuando presionamos una tecla. Imagino que sera util si queremos modificar

nuestro bot en tiempo de ejecucion.Landed: el bot toma tierra despues de una caıda.

90

PlayerDamaged: nuestro bot hiere a otro jugador.PlayerJoinsGame: un jugador se une al juego.PlayerKilled: otro jugador ha muerto, y podemos obtener informacion acerca de su muerte.PlayerLeft: un jugador abandona la partida.ShootingStarted: el jugador observado comienza a disparar.ShootingStopped: el jugador observado deja de disparar.Spawn: recibido cada vez que el bot resucita.VolumeChanged: alguna parte del cuerpo del bot ha cambiado de zona (al agua, lava, etc.).WallColission: el bot ha colisionado contra un muro.ZoneChangebot: el bot cambia de zona, es decir, el cuerpo completo del bot esta en una sola

zona despues de que no era ası.

Respuesta a comandos (pueden no ser necesarios)

Posiblemente el comando que los utilice ya incluye su tratamiento.EnteredVehicle / LockedVehicle: enviado como respuesta al comando ENTER, si hemos

conseguido entrar al vehıculo (y por tanto comenzamos a conducirlo) o no (esta ocupado o nopodemos cogerlo), respectivamente

FactoryUsed: respuesta al comando USE(FactoryUse).FastTraceResponse: respuesta al comando FASTTRACE.LostInventory: hemos perdido un item del inventario (arrojamos un arma, etc.).Reachable: booleano como contestacion a un comando checkreach, es decir, nos dice si se

puede acceder directamente a alcanzar un objeto (simplemente caminando).Thrown: respuesta al comando THROWN, es decir, cuando tiramos un arma.TraceResponse: respuesta al comando TRACE.Trigger: respuesta cuando activamos algun disparador. Podemos saber que y si realmente lo

hemos hecho nosotros.WeaponUpdated: el bot cambia de arma. Aquı exportamos el estado del arma anterior,

para tener informacion correcta de las armas de nuestro inventario, lo cual serıa un problema porel retraso del paquete sıncrono. (posiblemente ya tratado en la memoria de inventario)

Especiales (curiosos al menos)

ObjectSelected: referentes a un comportamiento alternativo del bot, el cual no es util paraun bot propiamente dicho pero podrıa llegar a ser util segun en que consista nuestro trabajo deinvestigacion. Esta funcion se activa pulsando ALT + LEFT SHIFT. Con esto, podemos apuntarun objeto de los visibles en pantalla con el cursor del raton. Una vez hecho esto podemos identificarobjetos, para lo cual sirve este evento.

PlayerInput: permite al jugador cuando apunta a nuestro bot con el cursor, darle ordenes deforma numerica (0-9).

Descartados

Los referentes a animation, dialog, handshake, inventory, map, mutators, navPoint, password,path, etc.

D.4.3. Eventos clasificados por grupos

Lotes sıncronos

Comienzo y finalizacion de la transmision de lotes sıncronos

HandShakeStart / HandShakeEnd

ItemCategoryStart / ItemCategoryEnd

91

ItemListStart / ItemListEnd

MutatorListStart / MutatorListEnd

MyInventoryStart / MyInventoryEnd

PathListStart / PathListEnd

PlayerListStart / PlayerListEnd

Eventos de objetos

Eventos especiales referentes a objetos. (ya explicados)

WorldObjectEvent (superclase de los siguientes, es decir, cualquier evento de objeto)

WorldObjectAppearedEvent

WorldObjectDestroyedEvent

WorldObjectDisappearedEvent

WorldObjectFirstEncounteredEvent

WorldObjectUpdatedEvent

Items / Inventary

AdrenalineGained

AddInventoryMsg

ItemDescriptorObtained

ItemPickedUp

LostInventory

WeaponUpdate

Reachable

Puntos de Navegacion

NavPointNeighbourLink

NavPointListStart / NavPointListEnd

NavPointNeighbourLinkStart / NavPointNeighbourLinkEnd

Mapa

MapFinished

MapChange

MapList

MapListEnd

MapListObtained

MapListStart

MapPointListObtained

92

Player

PlayerDamaged

PlayerInput

PlayerJoinsGame

PlayerKilled

PlayerLeft

PlayerListObtained

PlayerScore

ComboStarted

Mutator

Mutator

MutatorListObtained

Sonidos

HearNoise

HearPickup

VolumeChanged

Mover

MoverListEnd

MoverListObtained

MoverListStart

Dialog

DialogCommand

DialogFailed

DialogOk

Vehıculos

EnteredVehicle

LockedVehicle

Disparar

ShootingStarted

ShootingStopped

93

Bot

BotDamaged

BotFirstSpawned

BotKilled

Bumped

ChangedWeapon

FallEdge

JumpPerformed

Landed

Spawn

Thrown

WallCollision

ZoneChangedBot

Grabar

Respuesta a los comandos REC y STOPREC respectivamente.

RecordingStarted

RecordingEnded

Estado del juego

Se pone y se quita la pausa del juego.

GameResumed

GamePaused

Path

En la clase Path se encuentra la funcion getPath(). Una vez enviada esta peticion, se nosdevuelve un lote PathList cuyo comienzo y final esta delimitado por PathListStart y PathListEndrespectivamente.

Path

PathList

PathListStart / PathListEnd

94

Otros

ObjectSelected

BeginMessage

EndMessage

FactoryUsed

FastTraceResponse

GBEvent

InitCommandRequest

KeyEvent

ListObtained

ReadyCommandRequest

TraceResponse

Trigger

WorldEventIdentityWrapper

95

96

Bibliografıa

[1] Arkin, R., 1998. Behavior-Based Robotics. MIT Press, Cambridge, MA.

[2] Beer, R. D. (1990). Intelligence as Adaptative Behavior. Academic Press.

[3] Beer, R. D. (1995a). On the dynamics of small continuous-time recurrent neuralnetworks. Adaptative Behavior, 3(4) : 459-509.

[4] Beer, R. D. (1995b). A dynamical systems perspective on agent-environment inter-action. Artificial Intelligence, 72, 173–215.

[5] Beer, R. D. (1996). Towards the Evolution of Dynamical Neural Networks for Mini-mally Cognitive Behavior. Adaptive Behavior 3(4) : 469-509.

[6] Beer, R. D. y Gallagher, J. (1992). Evolving Dynamical Neural Networks for AdaptiveBehavior. Adaptive Behavior, 1(1), 91–122.

[7] Blynel, J., y Floreano, D. (2002). Levels of dynamics and adaptive behavior in evo-lutionary neural controllers. En Hallam, B., Floreano, D., Hallam, J., Hayes, G., yMeyer, J.-A. (Eds.), 7th International Conference on Simulation on Adaptive Beha-vior (SAB’2002) Edinburgh, UK.

[8] Bourquin, Y. (2004). Tank Wars! Evolving Steering and Aiming Behaviour for Com-puter Game Agents. Essay in Adaptive Systems, University of Sussex.

[9] Braitenberg V. (1984). Vehicles. Cambridge, MA: MIT Press.

[10] Brooks, R. (1990). Elephants don’t play chess. Robotics and Autonomous Systems,6, 3–15.

[11] Chapman, N (1999). http://homepages.paradise.net.nz/nickamy/neuralbot/.

[12] Cliff, D., Harvey, I. y Husbands, P. (1993). Explorations in evolutionary robotics.Adaptive Behavior 2(1): 73-110.

[13] Collins, R. J. y Jefferson, D. R. (1991). Representations for artificial organisms. En J.-A. Meyer, H. Roitblat and S. Wilson, eds., From Animals to Animats 1: Proceedingsof the Second International Conference on the Simulation of Adaptive Behavior (pp.382-390). Cambridge: MIT Press.

[14] de Falco, I., della Cioppa, A., Donnarumma, F., Maisto, D., Prevete, R., Tarantino,E. (2008). A Dierential Evolution Approach to CTRNN Parameter Learning. ECAI2008: 783-784

[15] de Garis, H. (1992). Steerable GenNets: The genetic programming of steerable beha-viors in GenNets. En F.J. Varela and P. Bourgine, eds., Toward a Practice of Au-tonomous Systems: Proceedings of the First European Conference on Artificial Life(pp. 272-281), Cambridge: MIT Press.

97

[16] Floreano, D. y Mondada, F. (1994). Automatic Creation of an Autonomous Agent:Genetic Evolution of a Neural-Network Driven Robot. En D. Cliff, P. Husbands, J.Meyer y S. Wilson, eds., From Animals to Animats III: SAB’94. MIT Press-BradfordBooks, Cambridge, MA.

[17] Funahashi, K. y Nakamura, Y. (1993). Approximation of dynamical systems by con-tinuous time recurrent neural networks. Neural Networks 6: 801-806.

[18] Gemrot, J., Kadlec, R., Bida, M., Burkert, O., Pibil, R., Havlicek, J., Zemcak, L.,Simlovic, J., Vansa, R., Stolba, M., Plch, T., Brom C. (2009). Pogamut 3 Can AssistDevelopers in Building AI (Not Only) for Their Videogame Agents, In Agents forGames and Simulations, LNCS 5920, Springer. pp. 1-15.

[19] Goldberg, D. E. (1989). Genetic Algorithms in Search, Optimization and MachineLearning. Addison-Wesley, Reading, MA.

[20] Harvey, I., Di Paolo, E., Wood, R., Quinn, M., Tuci, E.A. (2005). Evolutionaryrobotics: A new scientific tool for studying cognition. Artificial Life, 11(1-2) : 79-98.

[21] Holland, J. (1975). Adaptation in Natural and Artificial Systems. U. Michigan Press.

[22] Harvey, I., Husbands, P. y Cliff, D. (1994). Seeing the light: Artificial evolution,real vision. En D. Cliff, P. Husbands y J.-A. Meyer, eds., From Animals to Animats3. Proceedings of the Third International Conference on Simulation of AdaptiveBehavior, 392–402. MIT Press, Cambridge, MA.

[23] Hedgecock y Rusell, R. (1975). Normal and mutant thermotaxis in the nematodeCaenorhabditis elegans. Proceedings of the National Academy of Science of the USA,72(10), 4061-4065.

[24] Izquierdo, E. (2008). The dynamics of learning behaviour: A situated, embodied, anddynamical systems approach. PhD thesis. COGS, University of Sussex.

[25] Jakobi, N. (1998). Minimal Simulations For Evolutionary Robotics. PhD thesis.COGS, University of Sussex.

[26] Kadlec, R. (2008). Evolution of intelligent agent behaviour in computer games. PhDthesis. Academy of Sciences of the Czech Republic

[27] Kohonen, T. (1982). Self-organized formation of topologically correct feature maps.Biological Cybernetics, 43, 59–69.

[28] Koza, J. R. (1992). Genetic programming: on the programming of computers bymeans of natural selection. MIT Press, Cambridge, MA.

[29] Laird, J. E., van Lent, M. (2000). Human-level AI’s Killer Application: InteractiveComputer Games. En Proceedings of AAAI 2000, Austin, USA, pp. 1171-1178.

[30] Langton, C. G. (1989). Artificial Life: the proceedings of an interdisciplinary works-hop on the synthesis and simulation of living systems. Addison-Wesley, RedwoodCity, CA. Workshop held September, 1987 in Los Alamos, New Mexico.

[31] Maass W. (1997). Networks of spiking neurons: the third generation of neural networkmodels. Neural Networks. 10, 1659-1671.

[32] Mataric M. y Cliff D. (1996). Challenges en Evolving Controllers for Physical Robots.Evolutional Robotics, special issue of Robotics and Autonomous Systems, 19(1), 67-83.

98

[33] Miller, G. F. y Cliff, D. (1994). Protean behavior in dynamic games: Arguments forthe coevolution of pursuit-evasion tactics. In D. Cliff, P. Husbands, J. Meyer and S.Wilson, eds., From Animals to Animats 3: Proceedings of the Second InternationalConference on the Simulation of Adaptive Behavior (pp. 411-420). Cambridge: MITPress.

[34] Nolfi, S y Floreano, D. (2000). Evolutionary Robotics: the biology, intelligence, andtechnology of self-organizing machines. The MIT Press, Cambridge, MA.

[35] Pavlov, I. (1927). Conditioned Reflexes. Oxford University Press, London.

[36] Price, K.V. (1999). An Introduction to Differential Evolution. En Corne, D., Dorigo,M. y Glover, F. (eds), New Ideas in Optimization, McGrawHill, London. pp. 79-108.

[37] Russell, S. J. y Norvig, P. (2003), Artificial Intelligence: A Modern Approach (2nded.), Upper Saddle River, New Jersey: Prentice Hall, ISBN 0-13-790395-2.

[38] Skinner, B. F. (1950). Are theories of learning necessary?. Psychological Rewew, 57,193-216.

[39] Spiessens, P. y Torreele, J. (1992). Massively parallel evolution of recurrent networks:An approach to temporal processing. In F.J. Varela and P. Bourgine, eds., Toward aPractice of Autonomous Systems: Proceedings of the First European Conference onArtificial Life (pp. 70-77), Cambridge: MIT Press.

[40] Stanley, K. O., Bryant, B. D. y Miikkulainen, R (2005). Evolving Neural NetworkAgents in the NERO Video Game. En Proceedings of the IEEE 2005 Symposium onComputational Intelligence and Games (CIG’05).

[41] Vose, M. D., Wright, A. H. y Row, J. E. (2003). Implicit Parallelism. En E. Cantu-Paz, ed., Proceedings of GECCO 1003–1014. Springer.

[42] Werner, G. M. y Dyer, M. G. (1991). Evolution of communication in artificial orga-nisms. En C. G. Langton, C. Taylor, J. D. Farmer and S. Rasmussen, eds., ArtificialLife II (pp. 659-687). Reading, MA: Addison-Wesley.

[43] Yamauchi, B. y Beer, R. D. (1994). Sequential behavior and learning in evolveddynamical neural networks. Adaptive Behavior 2(3): 219-246.

99