Repositorio Institucional de Documentos

Proyecto de fin de Carrera Ingenier´ıa en Inform´atica Curso 2012/2013 Nuevas funcionalidades en la arquitectura Cera-Cranium para el control de un agente inteligente en el entorno del videojuego Unreal Tournament 2004 Carlos Vicente Gonz´alez Director: Manuel Gonz´alez Bedia Co-Director: Francisco Ser´on Arbeloa Departamento de Inform´atica e Ingenier´ıa de Sistemas Escuela de Ingenier´ıa y Arquitectura Universidad de Zaragoza Junio de 2013 Nuevas funcionalidades en la arquitectura Cera-Cranium para el control de un agente inteligente en el entorno del videojuego Unreal Tournament 2004 RESUMEN En este proyecto se pretende implementar un agente inteligente (bot) para videojuegos de acci´on en primera persona, que tome decisiones utilizando un controlador basado en una arquitectura cognitiva. Las arquitecturas cognitivas [1], desde su origen, han buscado modelar el comportamiento y estructura de agentes inteligentes considerados como modelos integrados, es decir, arquitecturas donde se articulen procesos de razonamiento, planificaci´on, aprendizaje, etc. de un modo unificado. Utilizando como base la arquitectura CERA-CRANIUM[18] se pretende mejorar dicha arquitectura para cumplir la definici´on de arquitectura cognitiva dada por Vernon, Meta y Sandini [17] y mejorar su valoraci´on en la escala ConScale[10] de evaluaci´on de implementaciones de conciencia artificial. El entorno de simulaci´on elegido para este proyecto es el videojuego Unreal Tournament 2004 (UT2004). Esta elecci´on vino motivada por la existencia del concurso a nivel mundial ”BotPrize”, consistente en la implementaci´on de un bot para UT2004 que simule el comportamiento humano. Las herramientas utilizadas son el videojuego UT2004 junto con la ampliaci´on Gamebots 2004 (que permite ejecutar bots en el videojuego) y la plataforma Pogamut 3, que permite programar al agente virtual en el lenguaje de programaci´on Java, y conectarlo y recibir informaci´on del videojuego. De entre las nuevas implementaciones realizadas podr´ıamos destacar la integraci´on de un sistema de toma de decisiones para controlar el funcionamiento del bot basado en Soar[2] que reproduce mecanismos de cambio de estrategia ante el reconocimiento de modificaciones en el entorno, aprendiendo de su propia experiencia mediante“aprendizaje por refuerzo”as´ı como una mejor simulaci´on del comportamiento humano gracias a la implementaci´on de algunos comportamientos de inspiraci´on emocional. Para comprobar la efectividad de estas mejoras, se ha preparado un experimento siguiendo los est´andares del concurso “BotPrize”. i Para Laura, aunque no entienda absolutamente nada. iii Agradecimientos A mi familia y amigos, por su apoyo y comprensi´on durante todos estos a˜nos, especialmente a Mateo, Alfonso y Mario por continuar a mi lado cuando esta aventura acabe. A Manuel y Paco por darme la oportunidad de trabajar en este proyecto y a David, Dani y Carlos por haberme ayudado a sobrellevar el proceso y haber colaborado como conejillos de indias. Y por ´ultimo, aunque no por ello menos importante, a Alan Turing. Sin ´el nada de esto ser´ıa posible. Muchas gracias a todos. v ´ Indice general I Memoria XV 1. Introducci´on 1 1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Motivaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Tecnolog´ıas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4. Contenido de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5. Planificaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Estado del arte: Definici´on y an´alisis de arquitecturas cognitivas 5 2.1. Definici´on de arquitectura cognitiva . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Arquitecturas actuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. CERA-CRANIUM y CC-Bot2 9 3.1. CERA-CRANIUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. CC-Bot2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Evaluaci´on de CERA-CRANIUM y CCBot2 . . . . . . . . . . . . . . . . . . . . . . 15 3.3.1. Evaluaci´on de CERA-CRANIUM como arquitectura cognitiva . . . . . . . . 15 3.3.2. Evaluaci´on ConScale de CCBot2 . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.3. Evaluaci´on global y trabajo a realizar . . . . . . . . . . . . . . . . . . . . . 16 4. Descripci´on del nuevo modelo: CCBotSoar 19 4.1. Adaptaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.1. Soar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2. Memoria de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3. Sistema de toma de decisiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.3.1. Aprendizaje por refuerzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.3.2. Gesti´on de emociones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 vii xiv Parte I Memoria xv Cap´ıtulo 1 Introducci´on El objetivo de este proyecto es el desarrollo de un agente aut´onomo virtual (bot, ver Glosario) para videojuegos de acci´on en primera persona (FPS) y m´as en concreto para el entorno de simulaci´on Unreal Tournament 2004. Dicho comportamiento “estar´a controlado” por una versi´on mejorada de la arquitectura CERA-CRANIUM[18], basada en la Teor´ıa del Espacio de Trabajo Global[19], tratando de alcanzar un nivel superior en la escala de medici´on de la conciencia artificial ConScale[10] y espec´ıficamente, aumentar de un nivel de conciencia ”reactivo” (nivel 2) a uno “adaptativo” (nivel 3) as´ı como dotar al sistema de algunas de las caracter´ısticas de los niveles posteriores “atencional”, “ejecutivo” y “emocional” (4, 5 y 6). Entre las nuevas implementaciones se encuentran: 1. mecanismos de evaluaci´on de propio rendimiento en la consecuci´on de m´ultiples objetivos (memoria medio-largo plazo) y del estado global propio 2. representaci´on de los efectos de este estado en el comportamiento (sentimientos) 3. cambio de contexto entre los objetivos perseguidos Adem´as de la evaluaci´on te´orica realizada en base a ConScale, se realizar´a una evaluaci´on pr´actica mediante un experimento controlado en el que se analizar´a la “humanidad” (en t´erminos de los criterios del concurso BotPrize) que otorgan jugadores reales al comportamiento de este nuevo bot en comparaci´on con su versi´on previa. El videojuego Unreal Tournament 2004, es un juego de c´odigo abierto que dispone de un conjunto de librer´ıas que permiten la creaci´on de bots de forma independiente al entorno gr´afico, dicho conjunto de librer´ıas se llaman Pogamut[3](versi´on 3.4) y est´an escritas en Java. 1.1. Objetivos El proyecto fin de carrera que se describe en este documento tiene los siguientes objetivos: Evaluaci´on de la arquitectura CERA-CRANIUM seg´un la definici´on de Vernon, Meta y Sandini[17] sobre una arquitectura cognitiva. Evaluaci´on del bot CCBot2 en la escala ConScale de habilidades cognitivas. Implementaci´on de nuevas funcionalidades utilizando como base las dos evaluaciones anteriores, las posibles carencias y las potenciales mejoras de CERA-CRANIUM y el CCBot2. 1 Analizar experimentalmente el comportamiento del nuevo bot. Obtener conocimientos y experiencia en el uso de tecnolog´ıas y herramientas para el desarrollo software en la ingenier´ıa, como pueden ser Java1, SVN2, as´ı como aprender a trabajar con herramientas desconocidas para m´ı como son Pogamut, jSoar o los lenguajes que utilizan las diferentes arquitecturas cognitivas; y otras que conozco pero no utilizo habitualmente como los sistemas basados en reglas. Introducirse en el ´ambito de la investigaci´on de la inteligencia artificial utilizando datos de otros ´ambitos relacionados,como la psicolog´ıa. 1.2. Motivaci´on Han sido muchos los motivos que me han llevado a la elecci´on del desarrollo de un sistema de toma de decisiones que controle el comportamiento de un agente aut´onomo virtual (bot) del videojuego Unreal Tournament 2004 como mi Proyecto Fin de Carrera. De entre todos ellos los principales han sido: La existencia de un concurso a nivel mundial “BotPrize”3(Anexo B) que consiste en la implementaci´on de un bot para el Unreal Tournament 2004 que simule el comportamiento humano. La posibilidad de profundizar en una arquitectura ganadora del “BotPrize” como es CERACRANIUM, su paradigma cognitivo y su funcionamiento. Me brindaba la posibilidad de adentrarme en el mundo de la inteligencia artificial, los videojuegos y la psicolog´ıa, ya que ten´ıa inter´es en temas de emociones, aprendizaje, motivaci´on o las arquitecturas cognitivas, y son temas que no se tratan en profundidad en la carrera. Me ofrec´ıa una forma interesante de adquirir conocimientos y experiencia en herramientas y tecnolog´ıas como Java y tambi´en en herramientas completamente desconocidas como Pogamut y jSoar. Este ha sido un proyecto donde he podido poner en pr´actica muchos conocimientos adquiridos durante la carrera, as´ı como abordar el uso de nuevas herramientas y tecnolog´ıas desconocidas. Antes de definir mi futuro laboral quer´ıa tener una experiencia m´as ligada al mundo de la investigaci´on que al mundo empresarial. Por ´ultimo, existe la posibilidad de que mi trabajo ayude y sea utilizado por otras personas: Unido al desarrollo de este proyecto se ha propuesto la creaci´on de un concurso de caracter´ısticas similares a BotPrize a nivel universitario que se desarrollar´a durante el curso 2013/2014. La nueva versi´on del bot participa adem´as en un estudio comparativo realizado por el profesor Juan Peralta de la Universidad Aut´onoma de Barcelona en una versi´on preliminar de lo que ser´a este “BotPrize universitario”. 1.3. Tecnolog´ıas utilizadas Para la implementaci´on de los bots se ha utilizado el videojuego Unreal Tournament 2004 junto con la ampliacion GameBots2004 (que permite ejecutar bots en el videojuego) y la plataforma 1http://www.java.com 2http://es.wikipedia.org/wiki/Subversion 3http://botprize.org/ 2 Pogamut 3 que permite programar al agente virtual en el lenguaje de programacion Java, conectarlo y recibir informacion del videojuego mediante un plugin para Netbeans (ver Anexo A). El programa UnrealED, incluido en la instalacion del videojuego, ha sido utilizado para el dise˜no de un mapa expecial para el entrenamiento del bot. Por ´ultimo, se ha utilizado JSoar para desarrollar el sistema de toma de decisiones. JSoar es una implementaci´on en Java de la arquitectura cognitiva Soar en forma de biblioteca para la construcci´on de sistemas basados en agentes. Para m´as informaci´on sobre las tecnolog´ıas utilizas en este proyecto y las ventajas e inconvenientes encontradas durante el desarrollo del proyecto derivadas de dichas tecnolog´ıas consultar el Anexo F. 1.4. Contenido de la memoria A continuaci´on se presenta un resumen de los contenidos de esta memoria: El cap´ıtulo 1 es en el que nos encontramos y sirve de introducci´on al resto de la documentaci´on. El cap´ıtulo 2 trata sobre el estado del arte del Proyecto y en ´el se analiza la definici´on de arquitectura cognitiva de Vernon, Meta y Sandini [17] as´ı como una clasificaci´on de algunas de las arquitecturas cognitivas m´as importantes en la actualidad. En el cap´ıtulo 3 se encuentra la descripci´on de la estructura y funcionamiento de la arquitectura cognitiva CERA-CRANIUM y de su implementaci´on CCBot2 as´ı como la evaluaci´on de ambas en funci´on de la definici´on dada en el cap´ıtulo 2 y de la escala ConScale de habilidades cognitivas. En el cap´ıtulo 4 se explican las nuevas implementaciones desarrolladas en el bot CCBotSoar (Memoria de Objetos, Sistema de Toma de Decisiones, Mapa de Peligro y Modelo de Riesgo) y su integraci´on en el sistema as´ı como una nueva an´alisis del bot en la escala ConScale para comprobar el avance producido gracias a estas nuevas implementaciones. El cap´ıtulo 5 contiene un breve resumen del entrenamiento recibido por CCBotSoar, asi como la definici´on y resultados de los experimentos realizados. En el cap´ıtulo 6 se muestra una conclusi´on general sobre el desarrollo del proyecto, posibles l´ıneas futuras y valoraci´on personal del proyecto. Por ´ultimo, encontraremos las siguientes secciones:  Glosario: Contiene la definici´on de algunos t´erminos mencionadas en la memoria.  Bibliograf´ıa: Fuentes de informaci´on consultadas para realizar el proyecto.  Anexos: Informaci´on adicional del proyecto referenciada desde apartados anteriores. Incluye el manual de Pogamut, informaci´on sobre el Bot Prize, ConsScale, un resumen de las clases y m´etodos de la implementaci´on CCBotSoar y las tecnolog´ıas utilizadas en el desarrollo de este proyecto. 3 1.5. Planificaci´on Durante los meses de duraci´on del proyecto, se han realizado labores de documentaci´on y formaci´on en las tecnolog´ıas y plataformas usadas, prestando especial atenci´on a Soar, CERACRANIUM, ConScale y las distintas definiciones aceptadas de una arquitectura cognitiva as´ı como la implementaci´on CCBot2. Adem´as, se han investigado diferentes tipos de recursos (redes neuronales, sistemas de razonamiento basado en casos, modelos de infotaxis, etc) que, aunque finalmente no se utilizaron, fue necesario conocer no s´olo para barajar varias opciones sino tambi´en para enriquecer el planteamiento de las nuevas implementaciones. El diagrama de Gantt correspondiente a la realizaci´on del proyecto se muestra en la figura 1.1. Figura 1.1: Diagrama Gantt del proyecto 4 Cap´ıtulo 2 Estado del arte: Definici´on y an´alisis de arquitecturas cognitivas En este cap´ıtulo se presenta una definici´on de arquitectura cognitiva basada en la comparaci´on de dos paradigmas (emergente y cognitivista) y se analizan algunas de las arquitecturas cognitivas actuales m´as importantes con el fin de enriquecer dicha definici´on. 2.1. Definici´on de arquitectura cognitiva Se puede definir una arquitectura cognitiva como el esquema o patr´on para estructurar los elementos funcionales que configuran a un agente inteligente. Las arquitecturas cognitivas proponen procesos computacionales que act´uan como ciertos sistemas cognitivos (como podr´ıan ser un “ser humano”) o, m´as a menudo, actos inteligentes bajo determinada definici´on. El t´ermino arquitectura implica un enfoque que intenta modelar no solo el comportamiento, sino tambi´en las propiedades estructurales del sistema modelado. Las arquitecturas cognitivas existentes pueden clasificarse en dos grupos principales: Por un lado, la aproximaci´on cognitivista, basada en informaci´on simb´olica procesada por sistemas representacionales[14]. Las aproximaciones cognitivistas se corresponden con la cl´asica y a´un com´un visi´on de que “la cognici´on es un tipo de computaci´on simb´olica, racional, encapsulada, estructurada y algor´ıtmica” y de que un sistema cognitivo “instancia estas representaciones f´ısicas como c´odigos cognitivos y sus comportamientos son una consecuencia causal de las operaciones que acarrean estos c´odigos” [21]. Por otro los sistemas conexionistas, din´amicos y enactivos (todos ellos basados en una mayor o menor extensi´on de los principios de auto-organizaci´on [20]) agrupados bajo el nombre general de sistemas emergentes. Estos sistemas discuten contra la visi´on del procesado simb´olico y se posicionan a favor de tratar la cognici´on como emergente, auto-organizada y din´amica [22, 23]. Existe adem´as un tercer grupo denominado de arquitecturas denominadas h´ıbridas que combinan las caracter´ısticas de ambos paradigmas. En el Cuadro 2.1 se desarrolla la comparaci´on entre los paradigmas cognitivista y emergente en funci´on de doce caracter´ısticas distintas: Operatividad computacional, Infraestructura de la 5 representaci´on, Grounding sem´antico, restricciones temporales, Epistemolog´ıa global, Corporeidad, Percepci´on, Acciones, Anticipaci´on, Adaptaci´on, Motivaci´on y Relevancia de la autonom´ıa. En el paradigma cognitivo, el foco de atenci´on en una arquitectura cognitiva se centra en los aspectos en los que la cognici´on es constante a trav´es del tiempo y que resulta relativamente independiente de la tarea [34, 31, 32]. Ya que las arquitecturas cognitivas representan la parte fija de la cognici´on, no pueden conseguir nada de su funcionamiento interno y necesitan adquirir o ser provistas de conocimiento para realizar cualquier tarea. Esta combinaci´on de una arquitectura cognitiva dada y una serie de conocimientos particulares se conoce habitualmente como modelo cognitivo. En la mayor´ıa de los sistemas cognitivistas el conocimiento incorporado al modelo se determina por el dise˜nador humano, aunque existe un incremento en el uso del machine learning para aumentar y adaptar este conocimiento. La especificaci´on de una arquitectura cognitiva consiste en sus conjeturas representacionales, las caracter´ısticas de sus recuerdos, y los procesos que operan con esos recuerdos. La arquitectura cognitiva define la manera en la que un agente cognitivo gestiona la eliminaci´on de sus fuentes [33]: Para las aproximaciones cognitivistas, estas fuentes son el sistema computacional en el que se realiza el procesado de s´ımbolos f´ısicos. La arquitectura especifica los formalismos para la representaci´on del conocimiento y la memoria utilizada para almacenarlos, los procesos que act´uan sobre ese conocimiento y los mecanismos de aprendizaje que se adquieren. Habitualmente, tambi´en tiene la posibilidad de programar el sistema para que los sistemas inteligentes puedan ser instanciados en una especie de dominio de aplicaci´on [34]. Para las aproximaciones emergentes, la necesidad de identificar una arquitectura surge de la complejidad intr´ınseca que caracteriza a un sistema cognitivo, y la necesidad de dotar de alg´un tipo de estructura en la que enmarcar los mecanismos de percepci´on, acci´on, adaptaci´on, anticipaci´on, y motivaci´on que permiten que el desarrollo ontogen´etico durante el ciclo de vida del sistema. Es esta complejidad la que distingue una arquitectura cognitiva emergente de un simple control rob´otico conexionista que habitualmente aprenden asociaciones mediante tareas espec´ıficas, por ejemplo, la red auto-organizativa de Konohen citada en [35]. En cierto modo, la arquitectura cognitiva de un sistema emergente se corresponde con las capacidades innatas de las que est´a dotada por la filog´enesis del sistema, las cu´ales no debe aprender pero que, por supuesto, puede evolucionar. Estas capacidades b´asicas facilitan la ontog´enesis del sistema, representan el punto de partida inicial para el sistema cognitivo y aseguran la base y los mecanismos para su consiguiente desarrollo aut´onomo, un desarrollo que influir´a directamente en la propia arquitectura. 2.2. Arquitecturas actuales La Figura 2.1 muestra un resumen de todas las arquitecturas en las que se han analizado una a una las doce caracter´ısticas de los sistemas cognitivos que se describieron anteriormente. Se han omitido las cinco primeras caracter´ısticas – Operatividad computacional, Infraestructura de representaci´on, Nociones sem´anticas, Restricciones temporales y Epistemolog´ıa global – porque se pueden inferir directamente desde el propio paradigma en el que el que se basa el sistema: cognitivista (C), emergente (E) o h´ıbrido (H). Una “×” indica que esta caracter´ıstica es clave en la arquitectura, “+” indica que existe esta caracter´ıstica y un espacio en blanco indica que esta caracter´ıstica no est´a presente en la arquitectura. Se asigna una “×” en la columna de Adaptaci´on si y solo si el sistema es capaz de desarrollar (en el sentido de crear nuevos marcos o modelos de representaci´on) y no simplemente aprender (en el sentido de estimar par´ametros de un modelo) [36]. 6 Figura 2.1: Comparativa de arquitecturas (extra´ıdo de [17]) 2.3. Conclusiones Un sistema cognitivo de desarrollo estar´a constituido por una red de subsistemas multifuncionales distribuidos que cooperan y compiten, cada uno de los cuales posee su propia infraestructura de codificaci´on o representaci´on, que alcanzan juntos un objetivo com´un de comportamiento efectivo controlados por alg´un tipo de mecanismo de auto-sincronizaci´on o circuito de modulaci´on. Esta red forma la configuraci´on filogen´etica y sus habilidades innatas. Una arquitectura cognitiva de desarrollo debe ser capaz de adaptarse mediante el aprendizaje y, a´un m´as importante, a trav´es de la modificaci´on de gran parte de la estructura y la organizaci´on del propio sistema de manera que sea capaz de alterar sus situaciones din´amicas bas´andose en la experiencia, para expandir su repertorio de acciones y adaptarse a nuevas circunstancias. Este desarrollo debe estar controlado por factores tanto explorativos como sociales, el primero referido al descubrimiento de novedades en el mundo exterior y el potencial de las propias acciones del sistema, y el segundo con la interacci´on entre agentes, las actividades compartidas, y patrones mutuamente construidos mediante comportamiento compartido. Existe una gran variedad de paradigmas de aprendizaje que se pueden utilizar para un desarrollo efectivo, incluyendo, pero no necesariamente limitado a, aprendizaje sin supervisi´on,aprendizaje por refuerzo yaprendizaje surpevisado. Puesto que los sistemas cognitivos no son s´olo adaptativos sino adem´as anticipativos, es crucial que tenga (filogenia) o desarrolle (ontogenia) alg´un mecanismo para ensayar escenarios hipot´eticos y un mecanismo que module el comportamiento actual del sistema. 7 Finalmente, la curva (c) ilustra el bucle de control de alto nivel, en el cual una tarea ha sido ejecutada conscientemente. Estos tres tipos de bucles de control no se encuentran en exclusi´on mutua; de hecho, los mismos perceptos contribuir´an habitualmente a diferentes bucles que tendr´an lugar a diferentes niveles. En esta implementaci´on, los procesadores especializados se crean en el propio c´odigo, y se asignan din´amicamente a la correspondiente capa CERA. El Workspace correspondiente a cada capa ser´a el encargado de gestionar la informaci´on proveniente de cada uno de estos procesadores y de la comunicaci´on con el resto del sistema. Counscious-Robots bot en acci´on Lo que viene a continuaci´on es un fragmento de un t´ıpico flujo de perceptos que en ´ultima instancia genera el comportamiento del bot (figura 7): 1. El procesador EnemyDetector detecta un nuevo enemigo, y crea un nuevo percepto “enemigo detectado”. 2. El percepto “enemigo detectado” se recibe ordenadamente en el procesador SelecEnemyToS- hoot, el cual se encarga de seleccionar el enemigo al que vamos a disparar. Cuando se elige el enemigo, se genera la correspondiente acci´on de disparo. 3. Dos procesadores reciben la acci´on de disparar, una a cargo de apuntar al enemigo y disparar y la otra que crea nuevas acciones de movimiento para evitar el fuego enemigo. Figura 3.6: Esquema simplificado del flujo de perceptos y acciones (extra´ıdo de [18]) Este es un ejemplo muy simple de como funciona el bot. Sin embargo, lo habitual es tener escenarios m´as complejos en los cuales multitud de enemigos est´en atacando al bot simult´aneamente y el objetivo seleccionado podr´ıa ser cualquiera de ellos. En estos casos, los mecanismos de atenci´on juegan un papel clave. El diagrama de la Figura 3.7 representa de forma esquem´atica y m´as en profundidad la estructura global de la arquitectura CERA-CRANIUM y m´as en concreto de la implementaci´on del CC-Bot2. 14 Figura 3.7: Diagrama general de CCBot2 3.3. Evaluaci´on de CERA-CRANIUM y CCBot2 En esta secci´on evaluaremos el modelo CERA-CRANIUM en funci´on de la definici´on de arquitectura cognitiva construida en el Cap´ıtulo 3 y tambi´en el nivel ConScale (Ver anexo) de la implementaci´on CCBot2. Estas evaluaciones nos ayudar´an a definir una hoja de ruta para elegir qu´e mejoras debemos a˜nadir tanto a la arquitectura en general como espec´ıficamente al bot. 3.3.1. Evaluaci´on de CERA-CRANIUM como arquitectura cognitiva Puesto que la arquitectura CERA-CRANIUM est´a basada en la Teor´ıa del Espacio Global de Trabajo de Baars y no presenta diferencias significativas de funcionamiento con respecto a la arquitectura Global Workspace de Shanaman [37, 38], asumimos que las caracter´ısticas de CERACRANIUM se corresponden con las de Global Workspace a efectos del an´alisis de la tabla anterior. Como se puede observar, la ´unica caracter´ıstica que no aparece referenciada en CERACRANIUM es la de Adaptaci´on, por lo que ser requiere de manera casi obligatoria la integraci´on de alg´un mecanismo adaptativo. Es importante que esta mejora se realize en el conjunto global de la arquitectura y no en una implementaci´on concreta para que la posterior evoluci´on de estas implementaciones no se vea sujeta a las limitaciones de dicha implementaci´on y la explotaci´on de CERA-CRANIUM aplicada a distintos ´ambitos se pueda realizar de manera transparente. 3.3.2. Evaluaci´on ConScale de CCBot2 En la siguiente figura se presentan los resultados obtenidos al aplicar el Proceso de Evaluaci´on Simplificado (PSE) sobre la implementaci´on CC-Bot2. El cuadro contiene en su primera columna la lista de habilidades que abarca este modelo y m´as abajo se indica el valor del CQS, en la segunda columna se representan los perfiles cognitivos del modelo y finalmente, en la tercera columna, se muestra el nivel conceptual de ConsScale alcanzado. Es conveniente resaltar que el PSE simplemente proporciona una aproximaci´on de lo que podr´ıa ser el nivel real ConsScale de una implementaci´on. CC-Bot2 cumple con algunas caracter´ısticas de los niveles 3, 4 y 5. Sin embargo, se clasifica como un agente de nivel 2 porque ConScale requiere el cumplimiento completo de los niveles 15 Figura 3.8: Evaluaci´on PSE del CCBot2 inferiores para poder ser calificado como perteneciente a un determinado nivel i. El ´ındice CQS de un agente reactivo puro es 0.18. Sin embargo, la puntuaci´on de CCBot2 (0.51) indica que el agente presenta capacidades cognitivas adicionales (como se puede observar en el perfil cognitivo asociado que aparece en la Tabla 13). Asimismo, CC-Bot est´a lejos de alcanzar el nivel 4, para el cual el CQS asociado ser´ıa de 12.21 o superior. En la Tabla 3.1 se enumera la lista de habilidades cognitivas ya implementadas en el modelo CCBot-2. CS Requisito 2,1 Capacidad de producir respuestas motoras fijas o reactivas (reflejos). 3,1 Adquisici´on aut´onoma y adaptativa de nuevas respuestas reactivas. 3,2 Uso de los sensores propioceptivos para generar respuestas adaptativas. 3,3 Selecci´on de informaci´on sensorial relevante. 3,4 Selecci´on de informaci´on motora relevante. 3,5 Selecci´on de informaci´on relevante en memoria. 3,6 Evaluaci´on (positiva o negativa) de objetos o sucesos seleccionados. 4,1 Aprendizaje por prueba y error. Re-evaluaci´on de los sucesos seleccionados. 4,5 Representaci´on espacial relativa (depictive) de los objetos percibidos. 5,2 Persecuci´on de m´ultiples metas. 5,4 Aprendizaje por refuerzo aut´onomo. Tabla 3.1: Requisitos ConScale cumplidos Nuestro objetivo es, de manera casi inmediata, implementar la habilidad cognitiva restante para poder completar el nivel 3 y, una vez superada esta barrera, analizar los diferentes requisitos de los niveles 4, 5 y (en menor medida) 6, para implementar algunos de ellos y conseguir el mayor avance posible en la escala. En la Tabla 3.2 se recogen todo estos requisitos. 3.3.3. Evaluaci´on global y trabajo a realizar Es esencial que la arquitectura CERA-CRANIUM posea la caracter´ıstica de Adaptaci´on. La opci´on m´as viable para implementar esta opci´on es crear una arquitectura h´ıbrida basada en CERACRANIUM e integrar un m´odulo de comportamiento cognitivista. De esta manera se mantienen todas las propiedades de la arquitectura base y la propia estructura de CERA-CRANIUM nos permite realizar una integraci´on casi modular de este nueva caracter´ıstica. La integraci´on de esta caracter´ıstica en el sistema facilitar´a adem´as el desarrollo de algunos de los requisitos de los niveles 4, 5 y 6 de ConScale para la nueva implementaci´on. El resto de requisitos han sido analizados y de entre ellos se han elegido los que a priori complementar´ıan esta caracter´ıstica de adaptaci´on y no requerir´ıan una nueva reestructuraci´on de la arquitectura cognitiva. 16 CS Requisito 3,7 Selecci´on de los contenidos que necesitan ser almacenados en memoria. 4,2 Comportamiento dirigido hacia determinados objetivos, como seguimiento y escape o acercamiento y alejamiento de enemigos. 4,3 Evaluaci´on del propio rendimiento en la consecuci´on de una meta simple, descartando las acciones que no contribuyen a las metas perseguidas. 4,4 Capacidad b´asica de planificaci´on: c´alculo de las n siguientes acciones secuenciales. 5,1 Evaluaci´on del rendimiento en la consecuci´on de m´ultiples metas. 5,3 Habilidad para cambiar de contexto entre m´ultiples tareas. 5,5 Capacidad avanzada de planificaci´on teniendo en cuenta todas las metas activas. 5,6 Capacidad para generar contenidos mentales seleccionados con significados basados en la interacci´on del agente con el medio (grounded meaning). 6,1 Evaluaci´on del estado propio (emociones globales). 6,2 Las emociones globales causan efectos en el cuerpo del agente. 6,3 Representaci´on de los efectos de las emociones en el organismo (sentimientos). 6,4 Capacidad para mantener un mapa preciso y actualizado del esquema corporal. 6,5 Aprendizaje abstracto (generalizaci´on de lecciones aprendidas). 6,6 Capacidad para representar un flujo de perceptos integrados que incluyan el estado propio. Table 3.2: Requisitos ConScale Implementables 17 18 Cap´ıtulo 4 Descripci´on del nuevo modelo: CCBotSoar En este cap´ıtulo se detallan las mejoras realizadas en la arquitectura para desarrollar la caracter´ıstica de adaptaci´on (el Sistema de Toma de Decisiones) y las nuevas implementaciones complementarias como son la Memoria de Objetos y la simulaci´on de emoci´on “Riesgo”. 4.1. Adaptaci´on De entre las cuatro arquitecturas cognitivas analizadas en el Cap´ıtulo 2 que presentan la caracter´ıstica de adaptaci´on, Soar y ACT-R son las m´as utilizadas y representativas del paradigma y tambi´en las m´as sencillas de integrar en un sistema h´ıbrido. A la hora de elegir una de ellas como herramienta para el desarrollo de esta nueva caracter´ıstica: Ambas tienen capacidades deliberativas y de aprendizaje y por lo tanto cumplen las caracter´ısticas deseadas, posibilitan la representaci´on del estado del bot, tienen mecanismos para la comunicaci´on con un entorno externo a la arquitectura cognitiva que ser´a el videojuego Unreal Tournament 2004 y disponen de diferentes m´etodos de aprendizaje. Como se va a utilizar Pogamut para la implementaci´on del bot es necesario que la arquitectura seleccionada disponga de una versi´on en Java para facilitar as´ı la conexi´on entre Pogamut y la arquitectura. Ambas disponen de versi´on en java, jSoar1yjACT-R2, luego esto no nos obliga a utilizar una arquitectura concreta. ACT-R presenta frente a Soar la ventaja de ser h´ıbrida, no obstante, su mecanismo de aprendizaje de nuevas producciones no es tan potente como el chunking de Soar. Soar ademas dispone de un mecanismo integrado de aprendizaje por refuerzo. Como el bot esta centrado en la capacidad de aprender de sus propias experiencias este hecho diferencial entre Soar y ACT-R es el que decanta la balanza hacia Soar. Soar es la arquitectura seleccionada para el desarrollo del sistema de toma de decisiones del bot. Para m´as informaci´on sobre Soar se puede consultar el Anexo D y el manual de Soar disponible con cada distribuci´on de Soar3. 1http://code.google.com/p/jsoar/ 2http://jactr.org/ 3http://code.google.com/p/soar/wiki/SoarTutorial 19 4.1.1. Soar Soar (State, Operator And Result)es una arquitectura cognitiva basada en la teor´ıa de la mente propuesta por Newell[2], para el desarrollo de sistemas que exhiben un comportamiento inteligente. Es definida por sus creadores como una arquitectura de prop´osito general en el sentido de que Soar no tiene intenci´on de tratar ´unicamente el problema de la inteligencia humana sino de tratar el problema de la inteligencia en general. El proyecto Soar comenz´o en la Universidad Carnegie Mellon por Newell, Laird y Rosenbloom como un test para las teor´ıas de la cognici´on de Newell[2]. Su dise˜no esta basado en la hip´otesis de que toda conducta orientada a unos objetivos, puede ser tratada como la selecci´on y aplicaci´on de unos operadores sobre un estado: 1. el estado es la representaci´on de la situaci´on actual del problema a resolver, 2. los operadores transforman el estado haciendo cambios en la situaci´on actual y 3. el objetivo es la situaci´on que se desea alcanzar durante la resoluci´on del problema. Soar consta fundamentalmente de un interfaz de entrada/salida que interactua en cada ciclo de ejecuci´on y posee tres tipos de memoria. Memoria de trabajo: Esta compuesta por los Working Memory Elements (WME) que son tuplas “identificador-atributo-valor” que contienen la representaci´on del estado actual. Permiten la organizaci´on jer´arquica y atributos con m´ultiples valores. Se ve afectada por las decisiones del ciclo de ejecuci´on y por la interfaz de entrada/salida. Memoria de producci´on: Contiene el denominado conocimiento a largo plazo compuesto por producciones (es decir, reglas del tipo “if  then” o “condici´on ->acci´on”). En cada ciclo se disparan las producciones cuyas condiciones coinciden con el estado representado en la memoria de trabajo. Memoria de preferencias: Guarda las preferencias asignadas a los operadores, que determinan su elecci´on durante el ciclo de ejecuci´on. Interfaz de entrada/salida: Es la conexi´on de Soar con el entorno externo en el cual se ejecuta. El interfaz de entrada actualiza al comienzo de cada ciclo de ejecuci´on los WME que Soar tiene en la memoria de trabajo y el interfaz de salida al final de cada ciclo se encarga de transmitir al entorno la acci´on a realizar. El funcionamiento de Soar esta basado en una secuencia de acciones llamada execution cycle (ciclo de ejecuci´on) que se ejecuta continuamente. Este ciclo aplica el operador vigente y selecciona el pr´oximo operador a aplicar hasta que la meta sea alcanzada (Figura 4.1). En cada ciclo de ejecuci´on se selecciona un ´unico operador. Si en un ciclo de ejecuci´on no es posible resolver la selecci´on del operador Soar alcanza un impasse, que genera un nuevo subestado para la resoluci´on del impasse. Se produce as´ı una descomposici´on de objetivos. Cuando los sucesivos subestados se van resolviendo, la arquitectura almacena todo el proceso en una nueva producci´on. Cuando se resuelve un impasse, Soar “aprende” ya que almacena el conocimiento sobre como resolver el impasse en una producci´on. ´ Este es el principal mecanismo de aprendizaje en Soar, llamado chunking. La nueva producci´on, llamada chunk, tiene como condiciones los elementos del estado que generaron el impasse y como acci´on los cambios en la memoria de trabajo o en las preferencias que resolvieron el impasse, y es almacenado en la memoria de producci´on con el resto de producciones. 20 Figura 4.1: Ciclo de ejecuci´on de Soar (extra´ıdo de [2]) Soar dispone de un sistema de aprendizaje por refuerzo que modifica el conocimiento sobre la selecci´on de operadores mediante un sistema de recompensas. Este sistema de aprendizaje por refuerzo esta integrado con la memoria de producciones. Utiliza las preferencias num´ericas que son modificadas mediante las recompensas en funci´on de nuestros intereses para as´ı aprender qu´e operador es m´as conveniente seleccionar en un estado u otro. Para m´as informaci´on sobre Soar se puede consultar el Anexo D y el manual de Soar disponible con cada distribuci´on. 4.2. Memoria de objetos Durante el transcurso de una partida de Unreal Tournament 2004 (y en la de casi cualquier otro juego FPS) la posici´on de los objetos (munici´on, salud y otros objetos especiales) sea siempre la misma. Los jugadores habitualmente recuerdan la posici´on de estos objetos ya sea por que ´estos se encuentran en puntos estrat´egicos muy f´aciles de identificar (y m´as cuando la mayor´ıa de los mapas tienen cierta simetr´ıa) o porque por el propio desarrollo de la partida, consiguen acordarse. Implementar este comportamiento en nuestro bot mejorado es tan sencillo como crear un nuevo procesador de perceptos. Este nuevo procesador (bautizado como RememberItems en la actual implementaci´on) captura los perceptos de “objeto recogido” y almacena sus posiciones en dos listas diferentes: una para todos los objetos que incrementan o recuperan nuestra salud, as´ı como los distintos tipos de escudos de energ´ıa y otra para el resto de objetos (principalmente municiones yarmas, aunque tambi´en se incluyen potenciadores de disparo) El procesador gestiona y actualiza estas listas con cada nuevo objeto recogido almacenando la posici´on del objeto aunque no su tipo, pues en algunos casos el juego crea puntos en los que los objetos que se pueden recoger cambian a lo largo del tiempo y tampoco ser´ıa realista que un jugador recordase exactamente el tipo de objeto concreto que aparece en un punto. El mismo procesador puede capturar perceptos sobre el nivel de salud y munici´on, de manera que cuando estos niveles se encuentran por debajo de un m´ınimo (definidos globalmente y utilizados por, por ejemplo, el procesador que nos ayuda a huir de los enemigos) propondr´a al sistema una acci´on de movimiento dirigida hacia el objeto m´as cercano que se corresponda con su necesidad (salud o munici´on). El siguiente diagrama representa gr´aficamente el funcionamiento interno de este procesador. 21 Figura 4.2: Procesador RememberItems 4.3. Sistema de toma de decisiones Como extensi´on a la nueva caracter´ıstica de Adaptaci´on y como parte de la creaci´on de una memoria a largo plazo se ha implementado un sistema de toma de decisiones centrado en la capacidad de aprender de sus propias experiencias e implementado “emociones” en su comportamiento. En particular, el sistema ha sido desarrollado en base a los conceptos de motivaci´on, drive, emoci´on y aprendizaje por refuerzo. Los conceptos de motivaci´on y drive forman parte de la representaci´on del estado bot, m´as concretamente del estado interno del bot. Este sistema de ha realizado utilizando como inspiraci´on el sistema de toma de decisiones desarrollado en [39], a˜nadiendo las modificaciones necesarias para su funcionamiento como m´odulo anejo a la estructura de CERA-CRANIUM, facilitando as´ı su integraci´on en la arquitectura. 4.3.1. Aprendizaje por refuerzo El bot y el entorno interact´uan continuamente, el bot selecciona acciones y el entorno responde a dichas acciones y presenta nuevos estados para el bot. A cada instante, el bot calcula una funci´on desde los estados a cada una de las acciones. A esta funci´on se le llama pol´ıtica de aprendizaje. Los m´etodos de aprendizaje por refuerzo especifican c´omo el agente cambia su comportamiento como resultado de su experiencia. El objetivo del bot es maximizar la cantidad de recompensas que recibe a lo largo del tiempo [8]. La valoraci´on de los comportamientos cuando el bot est´a en un cierto estado, se realiza utilizando algoritmos de aprendizaje por refuerzo. El bot aprender´a qu´e acci´on escoger cuando se encuentra en un estado determinado. El refuerzo utilizado para valorar el resultado de una acci´on es el appraisal, definido en funci´on de la variaci´on que experimenta el bot en su mood. El mood es una funci´on de las necesidades del agente, por lo que este refuerzo mide el efecto de la acci´on realizada en las necesidades del bot. Las variaciones positivas y negativas del mood est´an inspiradas en 22 las emociones de felicidad y tristeza respectivamente. El bot, por lo tanto, utiliza estas emociones para valorar sus propias acciones y aprender cu´ales son las m´as apropiadas en cada estado. A pesar de haberse convertido en uno de los algoritmos de aprendizaje m´as usados, Q-learning no sirve en nuestro entorno, ya que el videojuego Unreal Tournament es un entorno muy ca´otico que cambia muy r´apido, entonces en el momento de realizar la pol´ıtica de Q-learning la mejor opci´on del estado futuro puede tener un Q-valor muy elevado pero en realidad ese estado no llega a producirse porque ha cambiado el entorno muy r´apido. En su lugar utilizamos el algoritmo denominado Sarsa [11], δt=α[rt+1 +γQ(st+1, at+1)−Q(st, at)] donde: Q(st, at) es el Q-valor de la pareja estado-acci´on en el ciclo t. Q(st+1, at+1)es el Q-valor de la pareja estado-acci´on elegidos en el siguiente ciclo de decisi´on. rt+1 es la recompensa total obtenido durante el siguiente ciclo de ejecuci´on. αes la tasa de aprendizaje, controla cuanta importancia se le da a la recompensa m´as reciente. γes el factor de descuento, define cuanto afectan las recompensas futuras. cuya diferencia con Q-learning radica en que para Sarsa los valores se actualizan en el siguiente ciclo de ejecuci´on considernado el estado al que el sistema ha llegado y, en ese, eligiendo la mejor opci´on. Debido a las caracter´ısticas ca´oticas del entorno se ha elegido Sarsa como algoritmo de aprendizaje por refuerzo. 4.3.2. Gesti´on de emociones Las emociones son tratadas en base a la teor´ıa de Schachter y Singer [13], que propone que las emociones son una entidad producto de dos aspectos: alteraci´on personal y valoraci´on cognitiva. Los fen´omenos emocionales est´an formados por una respuesta gen´erica del sistema aut´onomo (“arraisal”) y por la evaluaci´on cognitiva de tal alteraci´on (“appraisal”). Las emociones son interpretaciones cognitivas de ciertas situaciones. Magna Arnold [12] entiende que las emociones son la combinaci´on de ambos factores: 1. la valoraci´on mental del da˜no o beneficio potencial de una situaci´on, y 2. la tendencia a la acci´on que nos acerca a las situaciones evaluadas positivamente o que nos aleja de las situaciones no deseables evaluadas negativamente. La toma de decisiones ser´a aprendida a trav´es de la propia experiencia del bot (sus “´exitos” y sus “fracasos”). A trav´es de ellos, mediante el aprendizaje por refuerzo, el bot aprende las pol´ıticas de comportamiento adecuadas. Las emociones asociadas a estos procesos se inspiran en emociones b´asicas como el “mood”. Como funci´on de refuerzo se utiliza el appraisal que est´a relacionado con la variaci´on del mood del bot. Los drives o necesidades del bot var´ıan su valor en cada paso de ejecuci´on siguiendo cada drive una din´amica determinada. Dicho conjunto de din´amicas intenta dotar de “personalidad” al bot y, la variaci´on del conjunto generar´a bots con diferentes personalidades. Estos valores del drive, junto con los valores de los est´ımulos externos sirven para calcular la intensidad de las motivaciones relacionadas con cada drive. La motivaci´on de mayor intensidad es la motivaci´on dominante y va a ser la que determine el estado interno del bot. Este estado interno junto con el estado externo, determina el estado global del bot. 23 Figura 4.5: Acciones antiguo propuestas y el m´odulo de jSoar en su fase de Input del ciclo de ejecuci´on lee la informaci´on de este vector de entrada y la introduce en su representaci´on del estado. De esta forma Soar dispone del estado del bot y por lo tanto, de las parejas “estado-acci´on” necesarias para el sistema de aprendizaje por refuerzo. Cada ciclo se actualizar´a el estado y se recompensar´a o penalizar´a la acci´on elegida. Para evitar que el m´odulo de Soar desarrolle un comportamiento paralelo a la arquitectura, se eliminar´an de Soar las acciones propuestas que hayan sido finalmente elegidas. En el vector de salida, el m´odulo de jSoar durante la fase Output del ciclo de ejecuci´on escribe qu´e acci´on ha resultado seleccionada de entre las propuestas, y la capa f´ısica lee dicha acci´on del vector y la ejecuta. Las acciones no elegidas no se eliminan autom´aticamente, sino que aguardar´an en la cola de propuestas hasta que la sean seleccionadas o hasta que la arquitectura decida que son demasiado antiguas. Figura 4.6: Esquema general de la conexi´on. 30 El mecanismo de aprendizaje por refuerzo de Soar requiere “resetearse” cada vez que se aplica para actualizar los Q-valores de las parejas estado-acci´on. En nuestro sistema el refuerzo es aplicado cada vez que hay una variaci´on positiva o negativa del mood y cuando muere el bot. Se ha desarrollado una funci´on que resetea jSoar para actualizar los Q-valores. Cada vez que haya que aplicar el refuerzo se le comunica a jSoar a trav´es del vector de entrada indicando cual es la recompensa o penalizaci´on sobre el ´ultimo par estado-acci´on ejecutado, entonces jSoar devolver´a como acci´on “Reset”a trav´es del vector de salida de la conexi´on para que pogamut ejecute la rutina de “reinicio” de jSoar y los Q-valores sean actualizados. De esta forma se integra el proceso de aprendizaje por refuerzo en la conexi´on de Pogamut y jSoar, y no supone m´as que a˜nadir una rutina de “reinicio” de jSoar para que los valores sean actualizados. Como ya se ha dicho, este proceso supone un ciclo de pogamut perdido durante la ejecuci´on, que es utilizado para“reiniciar”el mecanismo de aprender, pero que no supone ning´un problema ya que, durante este ciclo, el bot repetir´a la ´ultima acci´on realizada, simulando as´ı, adem´as, el retraso en la velocidad a la hora de tomar decisiones y la propia inercia derivada de este. Puesto que la memoria de producciones de Soar se reinicia cada vez que iniciamos una partida, el sistema dispone de un archivo en el que se van cargando todas las nuevas reglas creadas durante el transcurso de una partida para poder cargarlas en la siguiente. De esta manera simulamos una memoria a largo plazo que se ir´a enriqueciendo a cada partida que juegue nuestro bot, llegando a crear una suerte de personalidad propia en funci´on de sus experiencias pasadas. En las Figuras 4.8 y 4.7 se resume de manera gr´afica la integraci´on del Sistema de Toma de Decisiones (STD) en los flujos top-down y bottom-up de la arquitectura CERA-CRANIUM. Figura 4.7: Integraci´on del STD en el flujo bottom-up 4.7. Detalles sobre la implementaci´on Todas estas nuevas implementaciones desarrolladas se han realizado de la manera m´as gen´erica posible para respetar el esp´ıritu original de la arquitectura CERA-CRANIUM. El sistema de toma de decisiones y m´as en concreto el m´odulo encargado de calcular el Estado (tanto interno como externo) del bot y sus Motivaciones pueden modificarse de manera totalmente independiente no 31 Figura 4.8: Integraci´on del STD en el flujo bottom-up s´olo a la arquitectura en general sino tambi´en al m´odulo de comunicaci´on con Soar, posibilitando si se desea en un futuro a˜nadir o cambiar la informaci´on utilizada o su funcionamiento. Aprendizaje por refuerzo: Los valores de la tasa de aprendizaje (α= 0,3 ) y del factor de descuento (γ= 0,8) de Sarsa son los valores por defecto de Sarsa. Sistema de toma de decisiones: 1. Aunque en un principio se pens´o en realizar el control del estado como un procesador CERA-CRANIUM, el hecho de que los procesadores compitan entre ellos complicaba su funcionamiento, ya que era posible que otro procesador ”cogiera” un percepto (por ejemplo de presencia de enemigos) y el procesador de estado no pudiera procesarlo en el momento necesario. Esto provocaba un peligroso desfase entre el estado que el sistema enviaba al sistema de toma de decisiones y el verdadero estado del bot. 2. Los valores de los par´ametros est´ımulo motivacional (wi= 1), valor del l´ımite de activaci´on de la motivaci´on (Ld= 2) y mood ideal (W bideal = 100) han sido fijados bas´andose en los resultados experimentales obtenidos en [39]. Se consigue de esta manera que el bot no se emocione con las novedades, pero tampoco las ignore. Modelo de Riesgo: 1. Los valores utilizados para los pesos en el c´alculo de la f´ormula son αmax = 0,15, αmin = 0,15, αnext = 0,35 y αprev = 0,35. La raz´on por la que se han establecido mayores pesos a las puntuaciones “siguiente” y “anterior” que a las correspondientes a las puntuaciones “m´axima” y “m´ınima” de la partida, es porque en un comportamiento humano el jugador intentar´a quedar siempre en la mejor posici´on posible aunque no pueda ganar, de manera que sentir´a m´as inter´es por cu´anto le queda para subir o bajar un puesto en la clasificaci´on de la partida. 2. Para evitar sobrecargar la ejecuci´on del bot, el valor de Riesgo se actualizar´a ´unicamente cuando recibamos el evento de que ha muerto otro jugador o cuando sea ´el mismo el que ha muerto (por otra parte, son estos los ´unicos casos en los que se actualiza la clasificaci´on en las partidas DeathMatch). 32 3. El valor Riesgo tendr´a siempre un valor R[1,2]. Se establecido el radio de selecci´on de acciones inicial a la mitad de la activaci´on m´axima para evitar problemas al aplicar el modificador. En el Anexo E se describen brevemente las clases y m´etodos m´as importantes utilizados en la implementaci´on de CCBotSoar (acciones, perceptos, procesadores, etc). 4.8. Evaluaci´on ConScale de CCBotSoar En el siguiente cuadro resumen se recogen las habilidades cognitivas (CS) de la escala ConS- cale que se cumplen gracias a estas nuevas implementaciones. Se a˜nade adem´as la definici´on de los perfiles de comportamiento (BP) espec´ıficos para FPS definidos (Cuadro 4.6) CS BP Implementaci´on 3,7 El bot almacena en su memoria la posici´on de los botiquines y de los kits de munici´on. El bot va directamente a las posiciones recordadas cuando necesita munici´on o recuperar su salud. Memoria de Objetos 4,2 El bot muestra comportamientos dirigidos y sostenidos hacia sus enemigos, como perseguirlos, dispararlos continuadamente o huir de ellos. Sistema de Toma de Decisiones (Aprendizaje por Refuerzo) 4,3 Las acciones del bot que no contribuyen a las metas perseguidas son descartadas. Sistema de Toma de Decisiones (Aprendizaje por Refuerzo) 5,1-5,3 Algunos comportamientos del bot se interrumpen debido a ciertas circunstancias y luego se retoman. Adicionalmente, el bot estima hasta qu´e punto las metas se est´an alcanzando en base a las estrategias empleadas. Los comportamientos m´as efectivos se repiten con m´as frecuencia que los comportamientos que suelen conllevar resultados pobres. Sistema de Toma de Decisiones (Motivaciones - Aprendizaje por Refuerzo) 5,6 El bot genera de forma aut´onoma representaciones internas de alto nivel de los sucesos que tienen lugar a su alrededor. Mapa de Peligro / Modelo de Riesgo 6,1-6,2-6,3 El bot entra en un estado determinado dependiendo de la evaluaci´on que realiza del propio rendimiento. El comportamiento global del bot se ve modulado por el estado emocional en el que se encuentra. Sistema de Toma de Decisiones (Motivaciones) Cuadro 4.6: Avance en ConScale Con esta nueva configuraci´on podemos calcular, gracias a la herramienta calculadora de ConS- cale (http://www.consscale.com/es/calculadora/calculadora-fps.html) los par´ametros del perfil cognitivo de CCBotSoar (Figura 4.9): Aunque la implementaci´on satisface la mayor´ıa de los requisitos de los niveles 4 y 5 (todos excepto uno en cada nivel) y algunos de nivel 6 (la mitad, para ser exactos) se clasifica como nivel 3. ConsScale requiere el completo cumplimiento de todas las habilidades cognitivas de un 33 Figura 4.9: Perfil Cognitivo CCBotSoar nivel i y tambi´en de todos los niveles inferiores para poder clasificar un agente como perteneciente al nivel i. El ´ındice CQS de un agente puro de nivel 4 es 12.21. La puntuaci´on de este agente (7.21) indica que existen caracter´ısticas adicionales pero el agente est´a lejos de un agente de nivel 4 que puntuar´ıa 12.21 o m´as. Si bien puede parecer que este incremento no es significativo, debemos fijarnos en el valor CLS para comprender que, realmente, estamos m´as cerca de alcanzar el nivel 4 de lo que pensamos. El valor CLS (Cumulative Level Score) combina las puntuaciones de todos los niveles en una medida ´unica que sigue una progresi´on logar´ıtmica. El CLS de los niveles 3 y 4 es, respectivamente, 1.25 y 1.361. El valor CLS de nuestro bot alcanza el 1.33, lo que nos indica que nos encontramos a muy poca distancia del nuevo objetivo, que ser´ıa el nivel 4. La explicaci´on es tan simple como que tanto en el nivel 4 como en el nivel 5, tan s´olo necesitar´ıamos cumplir un ´unico requisito a˜nadido para completarlos. 34 Cap´ıtulo 5 Entrenamiento y experimentos En este cap´ıtulo se explica el procedimiento utilizado para el entrenamiento del bot y los experimentos necesarios para comprobar si el avance en la escala ConScale se corresponde con un incremento en la “humanidad” del bot. 5.1. Entrenamiento Como se ha mencionado en el Cap´ıtulo 4, nuestro bot implementa una memoria a largo plazo basada en el almacenamiento externo de las reglas de selecci´on creadas por Soar durante el transcurso de una partida. Puesto que el dise˜no anterior del sistema no contemplaba la posibilidad del aprendizaje por refuerzo, nuestro bot se encuentra en un estado de t´abula rasa con respecto a su sistema de toma de decisiones. Mediante este entrenamiento se pretende conseguir que nuestro bot tenga, a la hora de ser juzgado y comparado con otros, una memoria b´asica como jugador de Unreal Tournament 2004. 5.1.1. Entrenamiento espec´ıfico A lo largo del proceso de desarrollo y testeo de las nuevas implementaciones se hizo patente que debido a la integraci´on del sistema basado en reglas el bot a veces actuaba de manera extra˜na, siendo su principal error visible el de no disparar a los enemigos aunque estuvieran a su alcance y simplemente apuntarles. La raz´on de este comportamiento es que nuestro sistema basado en reglas necesita un entrenamiento para aprender, al menos de una manera b´asica, como debe actuar en una serie de situaciones como podr´ıa ser la expuesta. Precisamente es este comportamiento de pasividad ante la presencia de enemigos una de las caracter´ısticas que podr´ıa causar una baja puntuaci´on del bot en un concurso de “humanidad” como es el BotPrize. Para solucionar este problema, el CCBotSoar ha recibido primero un entrenamiento espec´ıfico en un mapa personalizado construido con el Unreal Editor (ver Anexo F). Se han realizado diez partidas en este escenario utilizando como enemigos diferentes tipos de bots “pasivos”. Definimos un bot pasivo como un bot que no ataca a sus enemigos. En nuestro caso se han elegido dos bots ya predefinidos como arquetipos en el paquete de instalaci´on de Pogamut para Unreal Tournament 2004: un bot vac´ıo y est´atico que no hace nada (EmptyBot) y bot de navegaci´on que recorre el mapa siguiendo los puntos definidos en este (NavigationBot). Al no ser atacado por el resto de contrincantes, nuestro bot tiene plena libertad para explorar todas las posibles acciones que desee 35 sin consecuencia y, en ´ultima instancia, reforzar´a los comportamientos de ataque a enemigos pues le reportar´an un mayor beneficio que vagar por el escenario. En el Cuadro 5.1 se explican los enemigos utilizados durante las partidas de entrenamiento espec´ıfico: Partida Enemigos 1-3 3 EmptyBot 4 2 EmptyBot + 1 NavigationBot 5 1 EmptyBot + 2 NavigationBot 6-8 3 NavigationBot 9-10 3 NavigationBot + 1 EmptyBot Cuadro 5.1: Enemigos durante partidas entrenamiento El esquema de este mapa y una captura durante las sesiones de entrenamiento se encuentran en la Figura 5.1. Figura 5.1: Escenario de Entrenamiento Especial (Esquema y Captura) 5.1.2. Entrenamiento general Junto a este entrenamiento espec´ıfico se ha realizado un entrenamiento m´as general haciendo competir al CCBotSoar en partidas contra bots gen´ericos de Unreal Tournament 2004. Un total de 20 partidas se han llevado a cabo durante esta fase de entrenamiento y en cada una de ellas, nuestro bot se enfrentaba a 4 bots controlados por el juego y a un jugador humano, el autor de este proyecto. Se han elegido escenarios enfocados a la participaci´on de como m´ınimo 4 jugadores y como m´aximo 8. Esto nos asegura un marco de experimentaci´on lo suficientemente abierto como para que el bot pueda interaccionar no s´olo con el resto de jugadores sino tambi´en con el entorno del mapa y lo suficientemente acotado como para que se mantenga la intensidad de la partida, lo que no ser´ıa posible si el escenario es tan grande que los encuentros entre jugadores son espor´adicos. Los enfrentamientos 1 contra 1 se han descartado como parte del entrenamiento pues nos interesa saber como se desenvuelve el bot en entornos d´onde la informaci´on sensorial es fugaz y variable y que presenten retos a su estructura cognitiva, lo que no sucede en este tipo de escenarios. 36 5.2. Experimentos Hemos comprobado te´oricamente en la secci´on 4.8 que el nuevo bot CCBotSoar es, cognitivamente hablando, superior a CCBot2. Pero aunque la escala ConScale ha sido probada anteriormente, no deja de ser una escala te´orica que ha demostrado en varias ocasiones no tener efectos inmediatos en la percepci´on del bot como “humana” desde una perspectiva exterior. 5.2.1. Preparaci´on del sistema Para la realizaci´on de este experimento se ha necesitado montar previamente la infraestructura necesaria. Esta infraestructura se podr´a utilizar adem´as posteriormente para el BotPrize universitario organizado por las universidades de Zaragoza, U-TAD (Madrid), Aut´onoma de Barcelona y Edith Cowan University (Perth, Western Australia). La infraestructura establecida se compone de 4 equipos conectados a la red. Aunque en un principio se pens´o en crear una red local para la conexi´on de los 4 equipos, el potencial uso global del sistema termin´o por descartar esta opci´on. Uno de los equipos servir´a como servidor del sistema y los otros 3 ser´an ser´an los utilizados por los jueces para participar en las rondas del experimento/concurso. El servidor necesita, adem´as de la instalaci´on del juego Unreal Tournament 2004 que se realizar´a en todos los equipos del sistema, una base de datos que almacenar´a, mediante el uso de varios scripts, los resultados obtenidos durante las rondas. Para este fin se ha instalado XAMPP, ya que adem´as del servicio MySQL para la creaci´on de la base de datos, dispone de un servidor Apache desde el que se pueden ejecutar los scripts para generar los resultados. La partida lanzada por el servidor se proteger´a con una contrase˜na para evitar el acceso de usuarios ajenos al experimento/concurso. Para participar en la partida, los jueces simplemente tendr´an que buscar el servidor de juego (llamado “BOTPRIZE”) en la lista de servidores online que aparecen en la pesta˜na correspondiente de partidas multijugador de Unreal Tournament 2004 (Join Game →Internet) y buscar el tipo de juego GameBotsDeathMatch. Las partidas no tiene un m´ınimo de jugadores por lo que una vez introducida la contrase˜na de acceso entrar´a al juego. Los bots que se quieran evaluar se pueden ejecutar tanto en la m´aquina servidor como conect´andolos de manera remota. Antes de proceder a la realizaci´on de los experimentos se realizaron pruebas para probar la robustez del sistema (estado de la red, conexiones de bots y jueces, recogida de resultados, etc) y se organizaron varios simulacros para ense˜nar a los jueces el funcionamiento del experimento. 5.2.2. Experimento y resultados El objetivo del siguiente experimento es comprobar si realmente este avance en ConScale se corresponde con un incremento en la percepci´on de “humanidad” que tendr´ıan otros jugadores humanos del CCBotSoar. Para ello se ha utilizado un planteamiento muy similar al utilizado en el BotPrize para determinar el ganador del concurso y comprobar si alguno de los participantes ha superado el test de Turing. En l´ıneas generales, el procedimiento para realizar el experimento es el siguiente: Se crea una partida utilizando las modificaciones de Unreal Tournament 2004 para poder emular las normas del concurso BotPrize (disponibles en la web). Estas modificaciones tienen como principal objetivo transformar el arma LinkGun para su utilizaci´on como herramienta de “marcado”. Utilizando los disparos primario y secundario de este arma, se “marca” a los 37 rivales en la partida como “bot” o “humano” respectivamente. El juego almacena informaci´on sobre las“marcas” que los jugadores humanos aplican a los bots y a otros jugadores humanos. Se realizan 10 partidas de 5 minutos cada una en 10 escenarios distintos, y en ellas participaran 5 jugadores: 3 jugadores humanos, el CCBot2 y el CCBotSoar. Durante la partida ninguno de los jugadores humanos sabr´a si sus enemigos son bots u otros jueces pues el propio servidor cambia los nombres de todos los participantes por otros gen´ericos para crear una interfaz ciega que permita realizar el experimento de manera correcta. Una vez terminada la ronda de partidas, se utiliza dos scripts PHP (tambi´en disponible en la web de BotPrize) que sintetizan los datos almacenados en el log especial. En la Figura 5.2 se puede ver una captura realizada durante el experimento. Frente a los enemigos aparece la ´ultima “marca” asignada por el juez. Figura 5.2: Captura del experimento Los Cuadros 5.2, 5.3 y 5.4 presentan los resultados obtenidos tras la finalizaci´on del experimento. Los valores h-count y b-count reflejan el n´umero de veces que un bot o un juez han sido marcados como “humano” o “bot”. bot name h-count b-count humanness % CCBotSoar 15 44 25.4237 % CCBot2 11 42 20.7547 % Cuadro 5.2: Nivel de humanidad de los bots 38 player name h-count b-count humanness % juez1 50 36 58.1395 % juez3 32 31 50.7937 % juez2 15 20 42.8571 % Cuadro 5.3: Nivel de humanidad de los jueces human name accuracy % juez3 57.6923 % juez2 56.0403 % juez1 49.7110 % Cuadro 5.4: Precisi´on de evaluaci´on de los jueces Como se puede apreciar, el porcentaje de humanidad del CCBotSoar es superior al del CCBot2 en casi un 5 %. Por lo tanto, queda comprobado experimentalmente que las implementaciones realizadas no s´olo producen un aumento te´orico en la humanidad del bot sino que tambi´en aumentan la humanidad real que otros jugadores humanos aprecian en ´el. A´un as´ı, y como se esperaba, el nivel alcanzado no es suficiente para acercarse al porcentaje de humanidad que presentan los jueces, que rondan el 50 %. El porcentaje de humanidad obtenido por el CCBot2 durante el BotPrize de 2010 (edici´on en la que result´o ganador) fue de un 31.81 %. La diferencia apreciable con el porcentaje obtenido durante este experimento se debe a que las condiciones del experimento, a pesar de ser similares, no son exactamente las mismas. En el concurso BotPrize 2010 participaron muchos m´as bots y por tanto muchos m´as jueces, de manera que las situaciones en las que es m´as identificable que el bot es efectivamente un bot, normalmente cuando un juez se encuentra a solas con el bot, son menos habituales que otras m´as ca´oticas en las que participan varios enemigos (bots y jueces) donde es mucho m´as complicado diferenciarlos. 39 Ontogenia: desarrollo de un agente. En los sistemas cognitivos se llama ontogenia a las caracter´ısticas que puede desarrollar un agente de manera complementaria a las que ya pose´ıa por su filogenia. Respawn: regeneraci´on autom´atica del bot cada vez que lo matan en una partida y ´esta a´un no se ha acabado. 46 Bibliograf´ıa [1] Langley, P., Laird, J.E., and Rogers, S. (2009). Cognitive architectures: Research issues and challenges. Cognitive Systems Research, 10:141-160. (document) [2] Laird, J. E., Newell, A., and Rosenbloom, P. S. (1987). Soar: an architecture for general intelligence. Artificial Intelligence, 33(1):1–64. (document), 4.1.1, 4.1 [3] Gemrot, J., Kadlec, R., B´ıda, M., Burkert, O., P´ıbil, R., Havl´ıcek, J., Zemc´ak, L., Simlovic, J., Vansa, R., Stolba, M., Plch, T., and Brom, C. (2009) Pogamut 3 Can Assist Developers in Building AI (Not Only) for Their Videogame Agents. Agents for Games and Simulations: Lecture Notes in Computer Science, 5920:1-15. 1 [4] Ray, D. (2009). jSoar: A pure Java implementation of Soar. In The 29th Soar Workshop. Ann Arbor, MI. [5] Turing, A.M. (1950). Computing Machinery and Intelligence. Mind 49: 433-460. [6] Arrabales, R., Ledezma, A., and Sanchis, A. (2009). Establishing a roadmap and metrics for conscious machines development. Proceedings of the 8th IEEE International Conference on Cognitive Informatics. 3.1 [7] Berridge, K. C. (2004). Motivation concepts in behavioural neuroscience. Physiology and Behaviour, 81:179–209. 4.3.3 [8] Sutton, R. S. and Barto, A. G. (1998). Reinforcement Learning: An Introduction. MIT Press, Cambridge, MA, A Bradford Book. 4.3.1 [9] Rolls, E. (2003). Emotions in Humans and Artifacts, chapter Theory of emotion, its functions, and its adaptive value. MIT Press. 4.3.3 [10] R. Arrabales, A. Ledezma, A. Sanchis. (2009) Assessing and characterizing the cognitive power of machine consciousness implementations. (document), 1 [11] Grze´s, M., and Kudenko, D. (2008). Robustness Analysis of SARSA(λ): Different Models of Reward and Initialisation. Proceeding AIMSA ’08 Proceedings of the 13th international conference on Artificial Intelligence: Methodology, Systems, and Applications:144 - 156 4.3.1 [12] Arnold, M. (1960). Emotions and Personality. Nueva York. Columbia University Press. 4.3.2 [13] Schachhter, S. and Singer, J. (1962). Cognitive, social and physiological determinants of emotional state. Psychological Review, 59:379-399. 4.3.2 47 [14] F. J. Varela, “Whence perceptual meaning? A cartography of current ideas,” in Understanding Origins – Contemporary Views on the Origin of Life, Mind and Society, ser. Boston Studies in the Philosophy of Science, F. J. Varela and J.-P. Dupuy, Eds. Kluwer Academic Publishers, 1992, pp. 235–263. 2.1 [15] Arrabales Moreno, R. and Sanchis de Miguel, A. ”A Machine Consciousness Approach to Autonomous Mobile Robotics”. In: 5th International Cognitive Robotics Workshop. AAAI-06. Boston, MA. July 2006. [16] Arrabales Moreno, R. Ledezma Espino, A. and Sanchis de Miguel, A. ”Modelling Consciousness for Autonomous Robot Exploration”. In 2nd International Work- Conference on the Interplay between Natural and Artificial Computation, IWINAC 2007. Lecture Notes in Computer Science Series, Vol. 4527. pp. 51-60. [17] Vernon, D. Etisalat Univ. Coll., Sharjah Metta, G.; Sandini, G.“A Survey of Artificial Cognitive Systems: Implications for the Autonomous Development of Mental Capabilities in Computational Agents” in Evolutionary Computation, IEEE Transactions on, Volume 11, Issue 2 (document), 1.1, 1.4, 2.1, 2.1, 6.1 [18] Arrabales Moreno, Ra´ul. “Evaluation and Development of Consciousness in Artificial Cognitive Systems”Universidad Carlos III de Madrid. Departamento de Inform´atica. Febrero 2011. (document), 1, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6 [19] Baars, B.J. 1997, ”In the Theatre of Consciousness: Global Workspace Theory, A Rigorous Scientific Theory of Consciousness”, Journal of Consciousness Studies, no. 4, pp. 292-309. 1, 3.1 [20] A. Clark, Mindware – An Introduction to the Philosophy of Cognitive Science. New York: Oxford University Press, 2001. 2.1 [21] Z. W. Pylyshyn, Computation and Cognition, 2nd ed. Bradford Books, MIT Press, 1984. 2.1 [22] E. Thelen and L. B. Smith, A Dynamic Systems Approach to the Development of Cognition and Action, ser. MIT Press / Bradford Books Series in Cognitive Psychology. Cambridge, Massachusetts: MIT Press, 1994. 2.1 [23] J. A. S. Kelso, Dynamic Patterns – The Self-Organization of Brain and Behaviour, 3rd ed. MIT Press, 1995. 2.1 [24] J. L. Krichmar and G. M. Edelman,“Principles underlying the construction of brainbased devices,” in Proceedings of AISB ’06 - Adaptation in Artificial and Biological Systems, ser. Symposium on Grand Challenge 5: Architecture of Brain and Mind, T. Kovacs and J. A. R. Marshall, Eds., vol. 2. Bristol: University of Bristol, 2006, pp. 37–42. 2.1 [25] H. Gardner, Multiple Intelligences: The Theory in Practice. New York: Basic Books, 1993. 2.1 [26] D. Vernon, “The space of cognitive vision,” in Cognitive Vision Systems: Sampling the Spectrum of Approaches, ser. LNCS (In Press), H. I. Christensen and H.-H. Nagel, Eds. Heidelberg: Springer-Verlag, 2006, pp. 7–26. 2.1 [27] W. J. Freeman and R. N ´ u˜nez, “Restoring to cognition the forgotten primacy of action, intention and emotion,” Journal of Consciousness Studies, vol. 6, no. 11-12, pp. ix–xix, 1999. 2.1 48 [28] C. von Hofsten, “An action perspective on motor development,” Trends in Cognitive Science, vol. 8, pp. 266–272, 2004. 2.1 [29] —, “On the development of perception and action,” in Handbook of Developmental Psychology, J. Valsiner and K. J. Connolly, Eds. London: Sage, 2003, pp. 114–140. 2.1 [30] G. Sch ¨ oner, “Development as change of dynamic systems: Stability, instability, and emergence,” in Toward a New Grand Theory of Development? Connectionism and Dynamic Systems Theory Re-Considered, J. P. Spencer, M. S. C. Thomas, and J. L. McClelland, Eds. New York: Oxford University Press, 2006. 2.1 [31] W. D. Gray, R. M. Young, and S. S. Kirschenbaum, “Introduction to this special issue on cognitive architectures and human-computer interaction,”Human-Computer Interaction, vol. 12, pp. 301–309, 1997. 2.1 [32] F. E. Ritter and R. M. Young, “Introduction to this special issue on using cogniti- ve models to improve interface design,” International Journal of Human-Computer Studies, vol. 55, pp. 1–14, 2001. 2.1 [33] A Survey of Cognitive and Agent Architectures, http://ai.eecs.umich.edu/cogarch0/. 2.1 [34] P. Langley, “An adaptive architecture for physical agents,” in IEEE/WIC/ACM International Conference on Intelligent Agent Technology. Compiegne, France: IEEE Computer Society Press, 2005, pp. 18–25. 2.1 [35] M. Jones and D. Vernon, “Using neural networks to learn hand-eye co-ordination,” Neural Computing and Applications, vol. 2, no. 1, pp. 2–12, 1994. 2.1 [36] J. Weng, “Developmental robotics: Theory and experiments,” International Journal of Humanoid Robotics, vol. 1, no. 2, pp. 199–236, 2004. 2.2 [37] M. P. Shanahan, “A cognitive architecture that combines internal simulation with a global workspace,” Consciousness and Cognition, 2006, to Appear. 3.3.1 [38] M. P. Shanahan and B. Baars, “Applying global workspace theory to the frame problem,” Cognition, vol. 98, no. 2, pp. 157–176, 2005. 3.3.1 [39] Gavalda Pina, Angel “Control de un agente inteligente basado en una arquitectura cognitiva para el entorno del videojuego Unreal Tournament 2004” Proyecto Fin de Carrera. Especialidad en Ingenieria en Informatica. Escuela de Ingenier´ıa y Arquitectura, Universidad de Zaragoza, Julio, 2012. 4.3, 2 49 50 Parte II Anexos 51 Anexo A Manual de Pogamut 3 A.1. Instalaci´on y Servidor A.1.1. Instalaci´on En esta secci´on se describe el proceso de instalaci´on, as´ı como el software necesario para la misma. 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 versi´on Demo de http://apacudn.epicgames.com/Two/UnrealEngine2Runtime22262002.html  UDK is una versi´on libre de Unreal Engine 3. Est´a incluido en el paquete de instalaci´on de Pogamut 3. JDK y Netbeans  Descarga conjunta en http://www.oracle.com/technetwork/java/javase/downloads/jdk netbeansjsp-142931.html Pogamut 3  Descargar ”Pogamut 3 Java instaler full” en la secci´on Downloads de la p´agina oficial http://diana.ms.mff.cuni.cz/main/tiki-index.php?page=Download Proceso de Instalaci´on Para no tener problemas en el proceso de instalaci´on de todos los elementos que necesitamos, seguir el siguiente orden, ya que al instalar Pogamut se nos pedir´a la ubicaci´on de UT2004, UE2 y Netbeans. 1. Instalar el videojuego Unreal Tournament 2004. 53 2. Instalar JDK y NetBeans. En Windows 7 instalar Netbeans directamente en C:/ en lugar de en la ubicaci´on por defecto, debido a problemas con los permisos. 3. Instalar Unreal Engine 2 Runtime. 4. Por ´ultimo, instalar Pogamut. Realizar la instalaci´on como aparece por defecto, es decir, con todos los elementos seleccionados, ya que todos son necesarios para que todo funcione correctamente. Si hemos instalado los programas en la ruta por defecto, el instalador de Pogamut los detectar´a autom´aticamente. En caso contrario tendremos que buscar la ruta en la que hayamos instalado el programa requerido por el proceso de instalaci´on. A.1.2. Ejecuci´on del bot en UT2004 En esta secci´on se describe c´omo configurar correctamente el servidor de UT2004, de forma que luego podamos conectar nuestro bot al mismo sin problemas. Tambi´en se describe el proceso de conexi´on de dicho bot al servidor utilizando NetBeans. Configuraci´on del servidor Para crear un servidor en UT2004, la forma m´as sencilla es hacerlo desde el propio juego. Para ello, abrimos UT2004 y seleccionamos la opci´on Alojar Partida. Una vez hecho esto, debemos seleccionar el tipo de juego. Para que ´este sea compatible con nuestro bot, debemos elegir uno de los tipos de juego personalizados, situados al final de la lista (Figura A.1). Lo m´as com´un es seleccionar el tipo “GameBots DeathMatch”. Una vez hecho esto, configuramos el juego a nuestro gusto. En la secci´on “Reglas de servidor” debemos tener siempre en cuenta las siguiente consideraciones (Figura A.2): Activar la opci´on “Servidor LAN” para mejorar el rendimiento si estamos trabajando con ordenadores conectados en LAN. Deseleccionar la opci´on “Anunciar servidor” para evitar problemas con copias ilegales de UT2004. Activar “Ignore UTAN Bans” para evitar problemas con copias ilegales de UT2004. Por ´ultimo, podemos crear dos tipos de servidores: Mixto: nada m´as crear el servidor, pasar´ıamos directamente a jugar en ´el y, posteriormente, podr´ıamos conectar otros bots contra los que jugar´ıamos. Esta opci´on no permite visualizar los acontecimientos que ocurren en el servidor, como es el caso del “servidor dedicado” Dedicado: este tipo de servidor permite visualizar en modo texto la configuraci´on del servidor y los acontecimientos que ocurren, tales como la conexi´on de un jugador o bot, la muerte y resurrecci´on de los mismos, etc. Si queremos, desde el mismo ordenador, conectarnos para jugar en el servidor, s´olo tenemos que ejecutar otra vez UT2004 y conectarnos a ´el como jugadores. 54 Figura A.1: Modos de juego GameBots Conexi´on del bot al servidor Lo primero que debemos hacer es abrir nuestro proyecto en NetBeans. Una opci´on inteligente ser´ı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” en NetBeans, seleccionamos 00-Emptybot situado en la carpeta Samples/Pogamut UT2004 y le damos un nombre. Nuestro proyecto quedar´a guardado por defecto en Documentos/NetBeansProyects. La figura A.3 muestra como acceder al c´odigo fuente de dicho proyecto. A continuaci´on, en la pesta˜na “Services” hacemos click derecho sobre “UT2004 Servers” y seleccionamos “Add server” (Figura A.4). En el di´alogo que aparece (Figura A.5) elegimos un nombre para el servidor y, en cuanto a la URI, tenemos dos opciones: Si el servidor est´a en el mismo ordenador desde el cual vamos a conectar el bot, escribimos localhost (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 estar´a preparado para ejecutar el bot sobre el servidor. En caso de aparecer un tri´angulo amarillo con una exclamaci´on sobre el servidor que hemos creado, revisar la configuraci´on del mismo, ya que posiblemente no tengamos problemas para acceder a ´el desde el ordenador donde est´a alojado el servidor pero s´ı desde uno externo. Por defecto, siempre aparecer´a el puerto 3001 al poner la IP. ´ Esto se debe a que los puertos por defecto son: 3000 para BotConnection, 3001 para ControlServer y 3002 para SpectatorConnection Ahora, el servidor esta en ejecuci´on y la IDE sabe como conectarse a ´el. Para ejecutar el bot simplemente corremos el bot mediante el bot´on con el tri´angulo verde de “play”. Si todo funciona, el bot se conectar´a al servidor y Netbeans nos mostrar´a la informaci´on referente a su ejecuci´on. Si queremos inspeccionar el bot desde el juego, tenemos dos opciones. 55 Todos estos pasos se explican m´as en detalle ahora al conocer las funciones iniciales que se ejecutan en este protocolo de comunicaci´on. prepareBot(): Se ejecuta antes de conectar al bot con el entorno y despu´es de construir el UT2004Bot, es el sitio id´oneo para inicializar los m´odulos de pogamut que se vayan a usar mas adelante. getInitializeCommand(): Se utiliza para darle al agente las propiedades iniciales tales como nombre, localizaci´on inicial, skin, etc. Este m´etodo es usado por pogamut para obtener el objeto Initialize que contiene todos los par´ametros generales del bot. botInitialized(GameInfo info, ConfigChange config, InitedMessage init): Primera vez que el bot tiene informaci´on sobre el mundo, aunque todav´ıa no ha sido creado. Se llama a esta funci´on una vez que el servidor ha enviado el mensaje INITED (clase de java: InitedMessage). Esto significa que el comando INIT ha sido ejecutado correctamente y la comunicaci´on entre el bot y el servidor es correcta. En este momento ya es posible establecer nuevas comunicaciones entre el bot y el servidor, aunque el bot no haya sido todav´ıa creado en el entorno, por lo que los comandos de movimiento no se pueden ejecutar, pero s´ı los de informaci´on del juego (GameInfo), configuraci´on del sistema actual (ConfigChange) y mensajes de inicializaci´on (InitedMessage). botSpawned(GameInfo info, ConfigChange config, InitedMessage init, Self self): Se ejecuta cuando aparece el bot en el juego, justo al entrar en el entorno del juego. Significa que la representaci´on gr´afica del bot ya es visible en el entorno. logic(): M´etodo principal del sistema, se ejecuta peri´odicamente por un thread interno asociado al agente. Esto le da la posibilidad al agente de ser proactivo y le permite actuar sin necesidad de est´ımulos externos. Todo lo que se ejecute dentro del m´etodo debe ser procesado r´apidamente ya que se ejecuta cada 0.25 segundos. A.3.2. Clase ModuleController En esta secci´on vamos a centrarnos en todos los componentes contenidos en la clase UT2004ModuleController. Doce de sus componentes son m´odulos completos y complejos que permiten recoger y enviar informaci´on sobre el bot y sobre su entorno. Estos son dichos m´odulos: Players: Informaci´on sobre el resto de jugadores. Todos los objetos de este tipo se autoactualizan a lo largo de la partida hasta que son destruidos. Este m´odulo permite al agente conocer toda la informaci´on sobre el resto de jugadores, informar sobre la posici´on, la visibilidad, el armamento, salud, bonificadores, etc. Game: Informaci´on general sobre el juego. Con este m´odulo se puede saber: el tipo de partida (DeathMatch, equipos, captura de bandera, etc), el nombre del mapa, tiempo total de la partida, n´umero m´aximo de equipos y salud, armadura y adrenalina iniciales, etc. Info: Informaci´on sobre el paradero del agente. Este m´odulo permite saber todo sobre el agente: nombre, ID, equipo, localizaci´on, velocidad actual, salud, armadura, adrenalina, etc. Items: Informaci´on sobre los objetos que se encuentran en el mapa. Se pueden obtener: mapas con todos los items del escenario y diferentes filtros (por ejemplo, s´olo los visibles, s´olo de un tipo (salud, armas), etc). Senses: Informaci´on sobre lo que siente y percibe el agente. Permite controlar todo lo que afecta al bot (por ejemplo, informar d´onde fue golpeado, el ´ultimo elemento recogido, el ´ultimo da˜no causado, ´ultimo da˜no recibido, si ve proyectiles que vienen hacia ´el, etc). 62 Weaponry: Informaci´on sobre el inventario del agente. Este m´odulo permite al bot saber la cantidad de munici´on del arma actual (disparo primario y secundario) o de todas las armas del inventario, caracter´ısticas del arma que est´a usando, etc. Shoot: Clase que contiene las acciones de disparo avanzadas que puede realizar el agente (por ejemplo, disparar arma primaria o secundaria a un objetivo, o a una localizaci´on, recargar arma, dejar de disparar, etc). Move: Clase que contiene opciones de movimiento para el agente y que puede utilizar conjuntamente con el resto de opciones de movimiento (Raycasting,navigation points, etc.) Dispone de m´etodos para esquivar disparos u objetivos, saltar, ir a una localizaci´on determinada, correr, detenerse, poner el foco de atenci´on en un objeto o jugador, etc. PathPlanner: Junto con pathExecutor es otra forma de moverse. Se encarga de calcular la ruta de acceso a un punto usando como apoyo los puntos de navegaci´on del mapa del juego. A partir de dos puntos del mapa es el responsable de encontrar la ruta que se debe seguir para ir de un punto a otro. PathExecutor: Se encarga de ejecutar el pathPlanner que ha sido calculado previamente siguiendo la ruta. ListenerRegistrator: Es el m´etodo encargado de autoinicializar los listeners por medio de AnnotationListenerRegistrator. Se encarga de proporcionar una manera sencilla y pr´actica de registrar los listeners. Descriptors: Es un m´odulo 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, etc). Config: m´odulo de memoria especializado en la configuraci´on del agente dentro de UT2004 (velocidad de rotaci´on, retraso de env´ıos s´ıncronos, raytracing, invulnerabilidad, respawn autom´atico, recogida autom´atica de ´ıtems, etc). Raycasting: soporte para la creaci´on de rayos que permiten detectar objetos en la escena. El rayo se pone verde cuando el camino est´a libre y rojo cuando hay obst´aculos en la direcci´on y longitud del rayo. Lo que consiguen los rayos es que el bot circule solo por las zonas donde los rayos son verdes. Body: maneja los comandos que pueden ser usados como entrada de datos en el bot.  Action: Proporciona los comandos de acci´on del bot. o Arrogar armas o Iteraci´on con elementos del entorno (recoger ´ıtems) o Otros comandos que no han podido ser clasificados en otras categor´ıas (renacer).  Communication: Proporciona los comandos de comunicaci´on. o Enviar mensajes (privados, globales o de equipo). o Recibir mensajes (privados, globales o de equipo).  ConfigureCommands: Permite cambiar los atributos del bot. Nombre, skin, velocidad de movimiento y de rotaci´on, invulnerabilidad, etc.  AdvancedLocomotion: M´odulo “move”, explicado a continuaci´on.  AdvancedShooting: M´odulo “shoot”, explicado a continuaci´on.  SimpleRayCasting: Control b´asico de rayos. Similar al m´odulo comentado anteriormente de “rayCasting”. Su funcionalidad es la misma, el uso de rayos para detectar por donde puede moverse el bot y por donde no puede hacerlo. 63 Random: m´odulo generador de n´umeros aleatorios especialmente ´utiles a la hora de llevar a cabo una toma de decisiones. Act: forma parte de IAct, que es el entorno encargado de gestionar todas las acciones y comandos que se pueden realizar en este mundo. Ligado a World (IVisionWorldView) ya que los dos juntos forman todo el entorno del juego, uno se encarga de las acciones (IAct) y el otro del entorno y los eventos que suceden en ´el (IVisionWorldView). World: forma parte de IVisionWorldView, que es el entorno encargado de gestionar el entorno y todos los eventos que se producen en ´el. Ligado a Act. A.3.3. Otros comandos interesantes Anotaci´on de java: @JProp Anotaci´on que se coloca delante de las variables java que quieras monitorizar en tiempo de ejecuci´on. En tiempo de ejecuci´on podemos acceder a estas variables, para modificarlas y ver su comportamiento 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 todos comandos que se pueden introducir en GameBots. Al usar java con Netbeans no es necesario introducir los comandos de manera literal. Java nos permite tener una clase para cada uno de los comandos 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 m´as compleja con la que poder utilizarlos sin tener que preocuparnos de tener que llamar a cada uno de los comandos de manera literal. Ahora vamos a poner la lista de todas las clases de comandos, la mayor´ıa se entienden por si mismas as´ı que no es necesario explicarlas, aun as´ı dentro del javadoc de pogamut hay un extensa explicaci´on de los campos y las funciones que componen cada una de las clases (una por comando). Adem´as en el javadoc se puede ver con que comando de GameBots est´a relacionada cada clase. 64 Act AddBot AddInventory AddRay Combo CommandPlayer Configuration ConfigurationObserver Console ContinuousMove DialogBegin DialogCancel DialogEnd DialogItem DisconnectObserver Dodge DriveTo EndPlayers EnterVehicle FactoryUse FastTrace GetAllInvetories GetAllNavPoints GetAllStatus GetGameInfo GetItemCategory GetMaps GetPath GetPlayers GetSelf GetSpecialObjects GetVisibleObjects GiveInventory ChangeAttribute ChangeMap ChangeTeam ChangeWeapon CheckReachability Initialize InitializeObserver Jump Kick LeaveVehicle MovePassword Reply Pause Pick Ping PlaySound Quit Ready Record RemoveRay Respawn Rotate SendMessage SetCrouch SetDialog SetGameSpeed SetLock SetPassword SetPlayerControl SetRoute SetSendKeys SetSkin SetWalk Shoot ShowText SpawnActor StartAnimation StartPlayers Stop StopRecord StopShooting Throw Trace TurnTo A.4. Eventos A.4.1. Interacci´on con el mundo Las interfaces IworldView junto con Iact representan la API b´asica para acceder al mundo. 65 Informaci´on 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  AliveMessage  AutoTraceRay  BombInfo  ConfigChange  DominationPoint  FlagInfo  GameInfo  IncomingProjectile  InitedMessage  Item  ItemCategory  Mover  MyInventory  NavPoint  Player  Self  TeamScore  Vehicle. Eventos (IWorldEvent): cz.cuni.amis.pogamut.base. communication.worldview.event:  Eventos de Objetos (IWorldObjectEvent): cz.cuni.amis.pogamut.base. communication.worldview.object  Eventos no asociados a ning´un objeto (utilizados directamente de IWorldEvent). La lista de eventos es la siguiente. Observar que esta lista cuenta tambi´en con los eventos pertenecientes a objetos, ya que podr´ıamos querer, por ejemplo, ser conscientes de todos los objetos que apareciesen en pantalla, para lo que usar´ıamos WorldObjectAppearedEvent. En el siguiente apartado se muestra una informaci´on m´as detallada de los eventos pertenecientes a IWorldEvent. Cuando queramos utilizar uno de estos eventos u objetos debemos incluir su correspondiente librer´ıa. Para ello consultar en la API la librer´ıa concreta de cada uno. Una vez explicado qu´e informaci´on podemos obtener del mundo y de qu´e manera, vamos a ver c´omo manipularla, es decir, cu´al es la forma m´as sencilla de recibir dicha informaci´on. La clase UT2004BotModuleController autoinicializa AnnotationListenerRegistrator. ´ Esto quiere decir que no ser´a necesario manipular los listeners manualmente, es decir, tener que a˜nadirlos, elminarlos, etc. adem´as de reprogramarlos, saber c´omo iterar para seleccionar el adecuado en cada momento, etc. En vez de eso, AnnotationListenerRegistrator permite registrar los listeners de forma muy sencilla y pr´actica, y ´el mismo se encargar´a de iterar entre todos los listeners registrados. Una vez registrado el listener, definimos una funci´on que realice las acciones deseadas en cada caso. Hay cinco diferentes tipos de listeners que podemos registrar. Los dos ´ultimos son dif´ıciles de usar, puesto que es dif´ıcil obtener el strig correspondiente al id espec´ıfico del objeto, pero es necesario saber de su existencia, aunque todav´ıa desconocemos c´omo utilizarlos y si ser´an necesarios: EventListener: reacciona al evento que nosotros definamos por medio del campo eventClass. Por ejemplo:  Reg: @EventListener(eventClass = Bumped.class), reacciona a eventos de la clase Bumped.  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 ocurridos a la clase Player.  Proc: protected void player(Player object) { ObjectClassEventListener: reacciona a eventos de una clase concreta (de entre los eventos asociados a objetos) que ocurren a objetos de una clase concreta. 66  Ej: @ObjectClassEventListener(eventClass = WorldObjectAppearedEvent.class, object- Class = Player.class), reacciona cuando un jugador cualquiera ”aparece” en nuestro campo de visi´on.  Proc: protected void playerAppeared(WorldObjectAppearedEvent<Player>event) { ObjectListener: similar a ObjectClassListener para un objeto concreto, es decir, un objeto con 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 un objeto con un id determinado dentro una clase concreta. Informaci´on que enviamos (Actions) Como hemos dicho, nuestro bot ser´a de la clase UT2004BotModuleControler, contenida en cz.cuni.amis.pogamut.ut2004.bot.impl. Para dar ´ordenes al mismo no usaremos directamente la interfaz IAct, es decir, pese a que somos libres de utilizar el m´etodo act (perteneciente como hemos dicho a la clase UT2004BotModuleControler), las acciones las enviaremos, de manera m´as sencilla e intuitiva, mediante el m´etodo body. El m´etodo body est´a dividido en los siguiente m´etodos: 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 module. ConfigureCommands getConfigureCommands() Returns cz.cuni.amis.pogamut.ut2004.bot.commands.ConfigureCommands command module. AdvancedLocomotion getLocomotion() Returns cz.cuni.amis.pogamut.ut2004.bot.commands.AdvancedLocomotion command module. AdvancedShooting getShooting() Returns cz.cuni.amis.pogamut.ut2004.bot.commands.AdvancedShooting command module. SimpleRayCasting getSimpleRayCasting() Returns cz.cuni.amis.pogamut.ut2004.bot.commands.SimpleRayCasting command module. La clase UT2004BotModuleControler ofrece tambi´en los m´etodos shoot para acceder directamente a body.getShooting() y move para body.getLocomotion(). Para acceder a los mismos, debemos incluir las librer´ıas correspondientes a cada clase contenida en Action, Comunication, ConfigureCommands, AdvancedLocomotion, AdvancedShooting y SimpleRayCasting. Para ello consultar la API. A.4.2. Descripci´on de los eventos En este apartado se trata de explicar de manera resumida los eventos m´as importantes que tendremos que utilizar durante la implementaci´on de nuestro bot. Debemos tener en cuenta las siguientes consideraciones: Muchos de los eventos son utilizados para la conexi´on con el servidor y cosas por el estilo, lo cual ya est´a implementado y no necesitamos para implementar nuestro bot. 67 Algunos de los eventos indican el principio y el final de la llegada de un lote s´ıncrono de datos. (no s´e si es necesario o est´a ya implementado en la clase que controle cada lote) Nuestra implementaci´on est´a orientada al tipo de partida DeathMatch sin chat, por lo que no tendremos en cuenta eventos referentes a equipos, banderas, chat, etc. Lotes s´ıncronos Comienzo y finalizaci´on de la transmisi´on de lotes s´ıncronos HandShakeStart / HandShakeEnd ItemCategoryStart / ItemCategoryEnd 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 68 Puntos de Navegaci´on NavPointNeighbourLink NavPointListStart / NavPointListEnd NavPointNeighbourLinkStart / NavPointNeighbourLinkEnd Mapa MapFinished MapChange MapList MapListEnd MapListObtained MapListStart MapPointListObtained Player PlayerDamaged PlayerInput PlayerJoinsGame PlayerKilled PlayerLeft PlayerListObtained PlayerScore ComboStarted Mutator Mutator MutatorListObtained Sonidos HearNoise HearPickup VolumeChanged 69 Mover MoverListEnd MoverListObtained MoverListStart Dialog DialogCommand DialogFailed DialogOk Veh´ıculos EnteredVehicle LockedVehicle Disparar ShootingStarted ShootingStopped Bot BotDamaged BotFirstSpawned BotKilled Bumped ChangedWeapon FallEdge JumpPerformed Landed Spawn Thrown WallCollision ZoneChangedBot 70 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 funci´on getPath(). Una vez enviada esta petici´on, se nos devuelve un lote PathList cuyo comienzo y final est´a delimitado por PathListStart y PathListEnd respectivamente. Path PathList PathListStart / PathListEnd Otros ObjectSelected BeginMessage EndMessage FactoryUsed FastTraceResponse GBEvent InitCommandRequest KeyEvent ListObtained ReadyCommandRequest TraceResponse Trigger WorldEventIdentityWrapper 71 de proporcionar un nivel concreto, sino que establece de forma precisa el grado de desarrollo (que podr´ıa estar en cualquier punto entre dos niveles can´onicos). En ConsScale se definen 13 niveles diferentes de conciencia funcional. Cada nivel se caracteriza en base a criterios arquitect´onicos y de comportamiento. A continuaci´on se proporciona una descripci´on de las principales caracter´ısticas de cada nivel, la definici´on de los componentes arquitect´onicos abstractos y las habilidades cognitivas espec´ıficas asociadas a los niveles de ConsScale. Figura C.1: Niveles ConsScale Nivel -1. Sin Cuerpo Definido (Disembodied) Este es un nivel inicial de referencia que se corresponde con implementaciones muy simples que ni siquiera tienen una definici´on clara de las fronteras que separan el agente del entorno que lo rodea. En otras palabras, este nivel se refiere a implementaciones que no pueden ser consideradas como agentes y se pueden confundir f´acilmente con el resto del entorno. Desde el punto de vista del desarrollo cognitivo propuesto en ConsScale, las entidades de nivel -1 podr´ıan considerarse como “proto-agentes”. Aunque este nivel no se use de forma pr´actica en la evaluaci´on de posibles implementaciones, su definici´on sirve para poner de manifiesto la importancia del cuerpo (B) como requisito b´asico para la descripci´on de un agente situado. No hay habilidades cognitivas caracter´ısticas de este nivel. Una analog´ıa tomada del mundo biol´ogico para los individuos de este nivel ser´ıa la consideraci´on de un amino´acido como parte de una prote´ına. El resto de la escala consiste en un conjunto de doce niveles (del 0 al 11, ambos inclusive), en la que los niveles m´as altos incluyen 78 como parte de su propia definici´on a todos los niveles inferiores. Usando estos niveles, se puede caracterizar cualitativamente el desarrollo cognitivo de un agente artificial. Nivel 0. Aislado (Isolated) Al igual que el nivel -1, el nivel 0 es un nivel de referencia conceptual que permite resaltar la importancia de la interacci´on con el entorno (situatedness), cuya base se encuentra en la existencia de un cuerpo. En este nivel, aunque hay una clara distinci´on entre la propia implementaci´on (su cuerpo) y el entorno, hay una falta total de procesamiento aut´onomo y no existen sistemas sensoriales ni motores. Por lo tanto, una entidad de nivel 0 consiste ´unicamente en un cuerpo inerte que no presenta ninguna funcionalidad ni interacci´on activa con el medio (excepto la inevitablemente provocada por las propiedades f´ısicas de la entidad). En este nivel tampoco hay habilidades cognitivas caracter´ısticas. Un cromosoma aislado podr´ıa considerarse como una analog´ıa v´alida para este nivel. Nivel 1. Pre-funcional (Decontrolled) Este nivel se refiere a aquellas implementaciones en las que los subsistemas correspondientes a sensores y actuadores est´an presentes, pero o bien no funcionan o no existe una relaci´on funcional entre ellos. Como ni la adquisici´on de informaci´on ni la generaci´on de acciones funcionan o no est´an relacionadas, todav´ıa no se pueden definir habilidades cognitivas caracter´ısticas a este nivel. Una bacteria muerta podr´ıa ser una analog´ıa plausible tomada del mundo biol´ogico. Nivel 2. Reactivo (Reactive) En este nivel, tanto los subsistemas de sensores como los actuadores son funcionales y est´an relacionados entre ellos mediante funciones predefinidas. El comportamiento de estos agentes est´a caracterizado por la producci´on de respuestas reactivas fijas en base a los datos de entrada capturados por los sensores. Por lo tanto, la ´unica capacidad cognitiva caracter´ıstica de este nivel es la de un agente situado que responde al entorno siempre con los mismos reflejos. Una analog´ıa biol´ogica para este nivel podr´ıa ser un virus. El nivel 2 de ConsScale se corresponde con un agente reactivo cl´asico que carece de memoria expl´ıcita y tampoco dispone de mecanismos de aprendizaje. Es a partir del nivel 2, cuando los agentes empiezan a utilizar el propio entorno que les rodea como medio para cerrar el bucle de retroalimentaci´on entre la acci´on y la percepci´on. Por lo tanto, todos los agentes de nivel 2 o superior pueden considerarse agentes situados. Aunque la escala se centra principalmente en la evaluaci´on de agentes individuales, es importante destacar que incluso en el nivel 2 pueden existir procesos adicionales de aprendizaje y adaptaci´on en el plano evolutivo (suponiendo que los agentes sean capaces de replicarse, mutar y evolucionar). Por ejemplo, aunque las reglas de control reactivas son fijas en un ´unico individuo de nivel 2, podr´ıa aparecer un proceso de adaptaci´on de las respuestas reactivas a lo largo de sucesivas generaciones en una poblaci´on de agentes de nivel 2. Nivel 3. Adaptativo (Adaptive) A este nivel las acciones del agente se generan din´amicamente en funci´on tanto de la memoria como de la informaci´on que se obtiene del entorno por medio de los sensores. Las habilidades cognitivas caracter´ısticas de este nivel son la capacidad b´asica para aprender nuevos reflejos y el uso de sensores propioceptivos para la generaci´on de comportamientos b´asicos como los de orientaci´on y posicionamiento. La lombriz de tierra ser´ıa una analog´ıa biol´ogica ilustrativa para este nivel. 79 Un agente de nivel 3 se corresponde con la forma m´as simple de un agente deliberativo. En este nivel, el estado interno del agente se mantiene en un sistema de memoria. La coordinaci´on sensoriomotora (R) se genera en funci´on de la informaci´on percibida y la informaci´on recordada. En este nivel, tambi´en se considera la presencia de sensores propioceptivos, aunque esto por s´ı solo no es suficiente para generar autoconciencia. Los mecanismos de percepci´on propioceptiva permiten que parte del estado interno del agente forme parte de la entrada de la funci´on de coordinaci´on sensoriomotora. Los agentes de nivel 3 tambi´en tienen mecanismos de aprendizaje que les permiten descubrir nuevos comportamientos reactivos. Es decir, la respuesta a un determinado estado del entorno no es fija, sino que es una funci´on de la informaci´on adquirida por S y el estado interno del agente (M). El nivel 3 tambi´en se puede ver como una evoluci´on del nivel 2 en la que ha aparecido la capacidad de aprender nuevos reflejos. Nivel 4. Atencional (Attentional) A este nivel el comportamiento del agente est´a modulado por la influencia que ejerce un mecanismo de atenci´on. La atenci´on selecciona contenidos espec´ıficos del repertorio total de contenidos disponibles a trav´es de los sensores y de la memoria. Adem´as, los contenidos seleccionados se eval´uan positiva o negativamente, constituyendo esto la semilla de las emociones. Las capacidades cognitivas t´ıpicas de un agente de nivel 4 permiten la producci´on de comportamientos de ataque y de escape (o de acercamiento y alejamiento). Los peces podr´ıan constituir una analog´ıa biol´ogica para este nivel. Gracias al mecanismo de atenci´on los procesos de aprendizaje se pueden dirigir expl´ıcitamente hacia determinados objetos o sucesos. Adem´as, los procesos de aprendizaje impl´ıcito, como la adquisici´on de nuevos reflejos (caracter´ıstica del nivel anterior), tambi´en se dan al mismo tiempo. Los agentes de nivel 4 son capaces de dirigir la atenci´on (usando el componente Att) a un subconjunto seleccionado de los contenidos percibidos del entorno (Ei), mientras que otras variables ambientales, que son adquiridas en S, no son procesadas expl´ıcitamente en R. Los objetos o sucesos seleccionados por el foco de atenci´on son evaluados autom´aticamente en base a las metas del propio agente. Esto permite que las respuestas subsiguientes del agente hacia esos est´ımulos se adapten (este mecanismo se puede considerar la base para el desarrollo de las emociones). Los agentes atencionales son capaces de desarrollar comportamientos dirigidos, como los de ataque o escape, y tambi´en son capaces de implementar mecanismos de aprendizaje por prueba y error. La habilidad de prestar atenci´on hacia est´ımulos espec´ıficos permite la formaci´on de comportamientos dirigidos. Por ejemplo, un agente puede desarrollar comportamientos claramente relacionados con objetivos espec´ıficos, como la persecuci´on o la hu´ıda. Adicionalmente, los agentes de nivel 4 tienen mecanismos primitivos para las emociones ya que los objetos a los que se presta atenci´on son evaluados elementalmente como positivos o negativos. Una emoci´on positiva desencadena un comportamiento de acercamiento o un v´ınculo hacia el objeto seleccionado. Por el contrario, una emoci´on negativa desencadena un comportamiento de alejamiento y refuerzo de las fronteras entre el agente y el objeto seleccionado. Adicionalmente, aparece en este nivel una nueva relaci´on entre la memoria y las emociones. Como se ha demostrado con los organismos biol´ogicos, las emociones influyen en gran medida en la selecci´on de los contenidos que se almacenan en memoria. En resumen, un agente de nivel 4 puede considerarse una evoluci´on de un agente de nivel 3 en el que ha aparecido la capacidad de atenci´on. Nivel 5. Ejecutivo (Executive) Los agentes de este nivel son capaces de intercalar m´ultiples metas ya que son capaces de almacenar en memoria distintos conjuntos de trabajo. Las habilidades cognitivas caracter´ısticas de este nivel son el cambio de contexto (habilidad para pasar de una tarea a otra) y el aprendizaje 80 emocional b´asico. La capacidad de cambio de contexto implica que el agente puede suspender la realizaci´on de una tarea dada para retomarla m´as tarde, estableciendo prioridades entre todas las tareas pendientes. El agente puede perseguir m´ultiples metas, asignando m´as tiempo y esfuerzo a aquellas que reportan mayores beneficios emocionales. Los mam´ıferos cuadr´upedos son una analog´ıa biol´ogica ilustrativa para este nivel. Un agente de nivel 5 se caracteriza por una capacidad de razonamiento m´as compleja y una representaci´on m´as rica del estado interno que permite la implementaci´on de mecanismos de cambio de contexto. La consecuci´on de m´ultiples metas se consigue gracias a un mecanismo de coordinaci´on que es capaz de mover el foco de atenci´on de forma efectiva de una tarea a otra. Un agente de nivel 5 tambi´en est´a dotado de un mecanismo que permite evaluar el propio desempe˜no en la consecuci´on de las metas pendientes. Se trata del mecanismo de auto-evaluaci´on del propio estado (SsA), que puede ser identificado como las emociones. La presencia de emociones asociadas a objetos, sucesos, y ahora tambi´en a las propias acciones del agente, permite el desarrollo de procesos de aprendizaje por refuerzo. Un agente de nivel 5 es aquel que exhibe capacidades de cambio de contexto y aprendizaje emocional b´asico (aprendizaje por refuerzo). Otras caracter´ısticas de un agente ejecutivo son la capacidad de planificaci´on avanzada y la aplicaci´on de las emociones al cambio de contexto: el agente tiende a asignar m´as tiempo y esfuerzo a aquellas tareas que resultan m´as gratificantes para ´el. En resumen, un agente de nivel 5 se puede considerar como una evoluci´on de un agente de nivel 4 en la que ha aparecido la capacidad de perseguir m´ultiples metas y intercalar la realizaci´on de m´ultiples tareas. Nivel 6. Emocional (Emotional) Este nivel se caracteriza por la capacidad de desarrollar el estadio 1 de la Teor´ıa de la Mente o TdM: “Yo s´e”. La TdM es la capacidad de atribuir estados mentales a uno mismo y a otros sujetos. En el nivel 6 de ConsScale los sentimientos aparecen como representaciones de los cambios que experimenta el organismo debido a las emociones. El sentido de “yo s´e” aparece en el agente gracias a la representaci´on de las relaciones existentes entre las emociones y los estados del organismo. La habilidad cognitiva caracter´ıstica del nivel 6 es la capacidad de aprendizaje emocional. El agente generaliza las lecciones aprendidas y las aplica a su comportamiento global. Adem´as, las emociones se asignan tambi´en al propio yo y al proceso de auto-monitorizaci´on, produciendo una auto-evaluaci´on continua que da lugar al “yo s´e”. Los monos son una analog´ıa biol´ogica plausible para el nivel 6. El nivel 6 es el primer nivel de la escala ConsScale en el que se puede considerar que un agente es hasta cierto punto consciente (pero no autoconsciente). La principal caracter´ıstica de este nivel es, como se ha mencionado anteriormente, el desarrollo del estadio 1 de la TdM. Aparecen las emociones complejas, que se construyen como combinaciones de las emociones b´asicas presentes en los niveles anteriores. Estas emociones no eval´uan s´olo est´ımulos externos o el propio estado interno, sino que se generan emociones de fondo que eval´uan la relaci´on del agente con su entorno. Como en este nivel los agentes cuentan con una representaci´on precisa de su estructura corporal y sus capacidades f´ısicas, es m´as f´acil establecer una separaci´on entre el yo y el resto del mundo. Por ejemplo, un robot antropom´orfico de nivel 6 actualizar´a su modelo del yo al descubrir la diferencia existente entre tocar con la mano un objeto extra˜no y tocar su propio cuerpo. En el segundo caso, se produce una notificaci´on de los sensores de contacto de la zona del cuerpo que toca la mano al mismo tiempo que se ejecuta la acci´on. Esta capacidad permite establecer una distinci´on clara entre los objetos que se pueden controlar directamente (el propio cuerpo) y los que no. La sensaci´on correspondiente al “yo s´e” aparece en el agente gracias a la representaci´on que se genera de la respuesta del organismo a las emociones. Existe un modelo impl´ıcito del yo que permite asociar las emociones con el desempe˜no del propio agente. Usando estas representaciones el agente es capaz de generalizar en sus procesos de aprendizaje. Mientras que un agente de nivel 81 5 s´olo aprende las reglas espec´ıficas de una tarea y adaptar su comportamiento consecuentemente, un agente de nivel 6 es capaz de usar las emociones complejas para aprender lecciones b´asicas que se pueden generalizar a todo su comportamiento, independientemente de la tarea que se realice (generalizaci´on de lecciones aprendidas). Por ejemplo, desarrollar un miedo a manejar cargas de m´as de 500 kilogramos podr´ıa hacer que un hipot´etico robot de carga de nivel 6 evitase tanto las tareas conocidas como nuevas tareas que involucren el levantamiento y transporte de ese tipo de cargas. Es decir, el agente habr´ıa aprendido la lecci´on de que en general (´el) no es capaz de manejar cargas tan pesadas. Nivel 7. Autoconsciente (Self-Conscious) La autoconciencia se adquiere cuando el agente es capaz de desarrollar el estadio 2 de desarrollo de la TdM:“yo s´e que yo s´e”. La presencia de un modelo expl´ıcito del yo en el agente hace posible el auto-reconocimiento. De hecho, los mecanismos de aprendizaje ahora pueden operar en el dominio del propio futuro anticipado. El agente puede planear acerca de s´ı mismo (ya que el propio agente puede ser parte del plan) y luego aprender si el plan fue eficiente para ´el o no. Aprender a usar herramientas es una capacidad cognitiva caracter´ıstica de este nivel, ya que ser actor en el plan es un factor clave para el uso de herramientas. Los humanos de 18 meses de edad son una analog´ıa biol´ogica plausible para este nivel. El nivel 7 de ConsScale se corresponde con la aparici´on de la autoconciencia. En este nivel el agente es capaz de desarrollar pensamientos de orden superior, es decir, pensamientos sobre pensamientos, y m´as espec´ıficamente pensamientos sobre uno mismo. Consecuentemente, los agentes de nivel 7 se encuentran en el estadio 2 del desarrollo de la TdM: “yo s´e que yo s´e”. Esto requiere la presencia de un modelo expl´ıcito del yo, que a su vez permite la planificaci´on avanzada incluyendo al propio yo en los planes. En el nivel 7 los mecanismos de aprendizaje operan tambi´en en el dominio del futuro anticipado. El agente puede realizar planes sobre s´ı mismo, y despu´es de ejecutarlos, evaluar si el plan confeccionado fue beneficioso para el agente o no. Es m´as, un agente de nivel 7 tiene capacidad de imaginaci´on. Es decir, puede planificar en base a los resultados de simulaciones internas, que son capaces de predecir los resultados de las posibles acciones del agente. Al existir un s´ımbolo expl´ıcito para el yo, el agente de nivel 7 es capaz de reconocerse a s´ı mismo. Por lo tanto, el test de comportamiento caracter´ıstico para este nivel ser´ıa la prueba del espejo (ver Apartado 2.3.2). El comportamiento de los agentes de este nivel tambi´en se caracteriza por la capacidad de usar herramientas. Nivel 8. Emp´atico (Empathic) La intersubjetividad es la caracter´ıstica principal de este nivel, en el que el agente no s´olo est´a dotado de un modelo interno mejorado que incluye el yo, sino que tambi´en tiene la habilidad de modelar a otros como yos intencionales. El desarrollo del estadio 3 de TdM, “yo s´e que t´u sabes”, hace posible los comportamientos sociales. Los chimpanc´es son una analog´ıa biol´ogica ilustrativa para este nivel. En el nivel 8 las representaciones internas del agente se enriquecen al contemplarse la intersubjetividad. Adem´as del modelo del yo, caracter´ıstico del nivel anterior, el individuo mantiene de forma an´aloga modelos actualizados de otros individuos (otros). Es decir, el agente asigna a otros individuos un modelo de subjetividad (se aplica un modelo del yo tambi´en a otros individuos). Esta capacidad es la base de la interacci´on social compleja. Tanto la intersubjetividad como la capacidad de mantener un esquema corporal actualizado (la cual estaba presente ya en el nivel 6 de ConsScale), son necesarias para el aprendizaje del 82 uso de herramientas mediante imitaci´on e incluso para la fabricaci´on de nuevas herramientas. Los agentes de nivel 8 tambi´en se caracterizan por ser capaces de colaborar con otros agentes en la persecuci´on de una meta com´un. Este tipo de agentes pueden desarrollar planes que tienen en cuenta la dimensi´on social. Es decir, la relaci´on existente entre el modelo del yo y los modelos de otros individuos subjetivos. La necesidad de estas habilidades cognitivas se ha puesto de manifiesto en el dise˜no de agentes BDI que sean capaces de colaborar entre ellos y/o con humanos. Nivel 9. Social (Social) En este nivel el modelo interno de otros yos se perfecciona gracias al desarrollo total de la capacidad de TdM, “yo s´e que t´u sabes que yo s´e”. Esto significa que el comportamiento caracter´ıstico de este nivel viene definido por el desarrollo de estrategias Maquiav´elicas sofisticadas (o inteligencia social), entre las que se incluyen comportamientos sociales como la mentira, la astucia o el liderazgo. Adem´as, los agentes de nivel 9 cuentan con capacidades ling¨ u´ısticas y comunicaci´on precisa. Los agentes de este nivel ser´ıan capaces de desarrollar una cultura propia. Los humanos de 4 a˜nos de edad son la analog´ıa biol´ogica para este nivel. En el nivel 9, la TdM est´a totalmente desarrollada, por lo tanto los agentes est´an fuertemente influidos por su entorno social. Adem´as, el desarrollo de una cultura proporciona nuevas posibilidades de aprendizaje. Un agente social A (en t´erminos de la escala ConsScale) ser´ıa consciente de que otro agente B podr´ıa conocer las creencias, los deseos y las intenciones de A. Este tipo de agentes tambi´en se caracterizan por sus capacidades avanzadas de comunicaci´on, que junto con el desarrollo de la TdM, les hace capaces de, por ejemplo, contar mentiras intencionadamente. Existen modelos matem´aticos de la din´amica de la inteligencia Maquiav´elica que se podr´ıan usar potencialmente para descubrir este tipo de comportamientos en agentes artificiales. Nivel 10. Androide (Human-Like) Tal y como indica el nombre de este nivel, la analog´ıa biol´ogica correspondiente es el ser humano adulto. Las caracter´ısticas de este nivel son la capacidad para formar una cultura compleja y la comunicaci´on verbal precisa. Esto implica la capacidad de uso de herramientas externas complejas para el aprendizaje. La fluidez entre la inteligencia social y la inteligencia t´ecnica permite la extensi´on del conocimiento usando medios externos (como la comunicaci´on escrita). Los avances tecnol´ogicos son posibles en este nivel. Los agentes de nivel 10, al igual que los humanos, son capaces de modificar su entorno de forma extrema. El nivel 10 representa a la clase de agentes dotados con un nivel de conciencia equiparable al humano. Esto implica que los grupos de este tipo de agentes pueden formar una cultura compleja o formar parte de la cultura humana. El Test de Turing, en cualquiera de sus formas o variantes, es una prueba obvia para los agentes de este nivel. Nivel 11. Super-Consciente (Super-Conscious) Este ´ultimo nivel est´a caracterizado por la habilidad de sincronizar y coordinar varios flujos de conciencia en el mismo yo f´ısico. No hay ejemplos conocidos de esta habilidad en el mundo biol´ogico. Un agente super-consciente es aquel capaz de manejar internamente varios flujos de conciencia, coordinando al mismo tiempo un ´unico cuerpo y su correspondiente sistema de atenci´on concurrente. Los agentes de este tipo requieren un mecanismo de coordinaci´on entre los distintos flujos de conciencia y un mecanismo de acceso sincronizado a los recursos f´ısicos. Un agente de este tipo 83 ser´ıa capaz, por ejemplo, de mantener varias conversaciones conscientes simult´aneas utilizando diferentes l´ıneas de comunicaci´on. Adem´as, podr´ıa usar la informaci´on obtenida de una conversaci´on en cualquiera de las otras de forma pr´acticamente inmediata. C.2. Proceso de Evaluaci´on de ConsScale Este proceso de evaluaci´on est´a orientado a agentes implementados y proporciona una medida precisa del nivel de desarrollo cognitivo. Sin embargo, requiere mucho m´as tiempo y esfuerzo en su realizaci´on. Figura C.2: Proceso de evaluaci´on ConsScale (PSE) La realizaci´on de un Proceso de Evaluaci´on Est´andar (PEE) requiere disponer del agente que se quiere evaluar y tambi´en una definici´on de pruebas adaptada al dominio de problema correspondiente, de manera que habitualmente se utiliza el Proceso de Evaluaci´on Est´andar (PSE). Como muestra la figura anteior, la evaluaci´on se basa en los componentes arquitect´onicos del agente y sus capacidades cognitivas. Los componentes arquitect´onicos se pueden identificar a trav´es de la inspecci´on interna de la implementaci´on. Las habilidades cognitivas presentes en el agente se pueden evaluar gracias a la definici´on y ejecuci´on de pruebas de comportamiento espec´ıficas adaptadas para el dominio de problema seleccionado. Las habilidades cognitivas descritas para cada nivel de la escala ConsScale se refieren a capacidades gen´ericas. Por lo tanto, la lista de habilidades cognitivas no se pueden usar directamente para realizar una evaluaci´on est´andar. Se requiere de un proceso de instanciaci´on para poder aplicar la escala a un dominio de aplicaci´on concreto. El proceso de instanciaci´on consiste b´asicamente en dise˜nar pruebas conductuales, espec´ıficas para el dominio correspondiente, que permitan determinar la presencia de las habilidades cognitivas consideradas en cada nivel de la escala. Una vez que se dispone de la lista de componentes arquitect´onicos y habilidades cognitivas presentes en el agente se puede aplicar la escala para obtener el nivel nominal de conciencia, el perfil cognitivo y el ´ındice CQS (usando por ejemplo la Calculadora ConsScale). 84 Anexo D Soar Este manual ha sido extra´ıdo de The Soar User’s Manual Version 9.3.1 (soar.googlecode.com/files/SoarManual931.pdf) This chapter describes the Soar architecture. It covers all aspects of Soar except for the specic syntax of Soar’s memories and descriptions of the Soar user-interface commands. This chapter gives an abstract description of Soar. It starts by giving an overview of Soar and then goes into more detail for each of Soar’s main memories (working memory, production memory, and preference memory) and processes (the decisi´on procedure, learning, and input and output). D.1. An Overview of Soar The design of Soar is based on the hypothesis that all deliberate goal -oriented behavior can be cast as the selection and application of operators to a state. A state is a representation of the current problem-solving situation; an operator transforms a state (makes changes to the representation); and a goal is a desired outcome of the problem-solving activity. As Soar runs, it is continually trying to apply the current operator and select the next operator (a state can have only one operator at a time), until the goal has been achieved. The selection and application of operators is illustrated in Figure D.1. Figura D.1: Soar is continually trying to select and apply operators. Soar has separate memories (and dierent representations) for descriptions of its current situation and its long-term knowledge. In Soar, the current situation, including data from sensors, results of intermediate inferences, active goals, and active operators is held in working memory. Working memory is organized as objects. Objects are described in terms of their attributes; the values of the attributes may correspond to sub-objects, so the description of the state can have a hierarchical organization. (This need not be a strict hierarchy; for example, there’s nothing to prevent two objects from being \substructure” of each other.) The long-term knowledge, which species how to respond to dierent situations in working memory, can be thought of as the program for Soar. The Soar architecture cannot solve any problems 85 without the addition of long-term knowledge. (Note the distinction between the \Soar architecture” and the \Soar program”: The former refers to the system described in this manual, common to all users, and the latter refers to knowledge added to the architecture.) A Soar program contains the knowledge to be used for solving a specic task (or set of tasks), including information about how to select and apply operators to transform the states of the problem, and a means of recognizing that the goal has been achieved. D.1.1. Problem-Solving Functions in Soar All of Soar’s long-term knowledge is organized around the functions of operator selection and operator application, which are organized into four distinct types of knowledge: Knowledge to select an operator : 1. Operator Proposal: Knowledge that an operator is appropriate for the current situation. 2. Operator Comparison: Knowledge to compare candidate operators. 3. Operator Selection: Knowledge to select a single operator, based on the comparisons. Knowledge to apply an operator : 4.Operator Application: Knowledge of how a specic operator modies the state. In addition, there is a fth type of knowledge in Soar that is indirectly connected to both operator selection and operator application: 5. Knowledge of monotonic inferences that can be made about the state (state elaboration). State elaborations indirectly aect operator selection and application by creating new descriptions of the current situation that can cue the selection and application of operators. These problem-solving functions are the primitives for generating behavior in Soar. Four of the functions require retrieving long-term knowledge that is relevant to the current situation: elaborating the state, proposing candidate operators, comparing the candidates, and applying the operator by modifying the state. These functions are driven by the knowledge encoded in a Soar program. Soar represents that knowledge as production rules. Production rules are similar to \ifthen” statements in conventional programming languages. (For example, a production might say something like \if there are two blocks on the table, then suggest an operator to move one block ontop of the other block”). The \if” part of the production is called its conditions and the \then” part of the production is called its actions. When the conditions are met in the current situation as dened by working memory, the production is matched and it will re, which means that its actions are executed, making changes to working memory. The other function, selecting the current operator, involves making a decisi´on once sucient knowledge has been retrieved. This is performed by Soar’s decisi´on procedure, which is a xed procedure that interprets preferences that have been created by the retrieval functions. The knowledgeretrieval and decision-making functions combine to form Soar’s decisi´on cycle. When the knowledge to perform the problem-solving functions is not directly available in productions, Soar is unable to make progress and reaches an impasse. There are three types of possible impasses in Soar: 1. An operator cannot be selected because none are proposed. 86 2. An operator cannot be selected because multiple operators are proposed and the comparisons are insucient to determine which one should be selected. 3. An operator has been selected, but there is insucient knowledge to apply it. In response to an impasse, the Soar architecture creates a substate in which operators can be selected and applied to generate or deliberately retrieve the knowledge that was not directly available; the goal in the substate is to resolve the impasse. For example, in a substate, a Soar program may do a lookahead search to compare candidate operators if comparison knowledge is not directly available. Impasses and substates are described in more detail in Section 2.6. SECCION D.1.2. An Example Task: The Blocks-World We will use a task called the blocks-world as an example throughout this manual. In the blocksworld task, the initial state has three blocks named A, B, and C on a table; the operators move one block at a time to another location (on top of another block or onto the table); and the goal is to build a tower with A on top, B in the middle, and C on the bottom. The initial state and the goal are illustrated in Figure D.2 Figura D.2: The initial state and goal of the “blocks-world” task. The operators in this task move a single block from its current location to a new location; each operator is represented with the following information: the name of the block being moved the current location of the block (the \thing” it is on top of) the destination of the block (the \thing” it will be on top of) The goal in this task is to stack the blocks so that C is on the table, with block B on block C, and block A on top of block B. D.1.3. Representation of States, Operators, and Goals The initial state in our blocks-world task |before any operators have been proposed or selected |is illustrated in Figure D.3. A state can have only one operator at a time, and the operator is represented as substructure of the state. A state may also have as substructure a number of potential operators that are in consideration; however, these suggested operators should not be confused with the current operator. 87 “acceptable” or “require” preference). There may also be others, for example to say that the value is “best”. D.4.1. Preference semantics Only a single value can be selected as the current operator, that is, all values are mutually exclusive. In addition, there is no implicit transitivity in the semantics of preferences. If A is indierent to B, and B is indierent to C, A and C will not be indierent to one another unless there is a preference that A is indierent to C (or C and A are both indierent to all competing values). Acceptable (+) An acceptable preference states that a value is a candidate for selection. All values, except those with require preferences, must have an acceptable preference in order to be selected. If there is only one value with an acceptable preference (and none with a require preference), that value will be selected as long as it does not also have a reject or a prohibit preference. Reject (-) A reject preference states that the value is not a candidate for selection. Better (>), Worse (<)A better or worse preference states, for the two values involved, that one value should not be selected if the other value is a candidate. Better and worse allow for the creation of a partial ordering between candidate values. Better and worse are simple inverses of each other, so that A better than B is equivalent to B worse than A. Best (>)A best preference states that the value may be better than any competing value (unless there are other competing values that are also “best”). If a value is best (and not rejected, prohibited, or worse than another), it will be selected over any other value that is not also best (or required). If two such values are best, then any remaining preferences for those candidates (worst, indifferent) will be examined to determine the selection. Note that if a value (that is not rejected or prohibited) is better than a best value, the better value will be selected. (This result is counterintuitive, but allows explicit knowledge about the relative worth of two values to dominate knowledge of only a single value. A require preference should be used when a value must be selected for the goal to be achieved.) Worst (<)A worst preference states that the value should be selected only if there are no alternatives. It allows for a simple type of default specication. The semantics of the worst preference are similar to those for the best preference. Indifferent (=) An indifferent preference states that there is positive knowledge that it does not matter which value is selected. This may be a binary preference, to say that two values are mutually indierent, or a unary preference, to say that a single value is as good or as bad a choice as other expected alternatives. When indifferent preferences are used to signal that it does not matter which operator is selected, by default, Soar chooses randomly from among the alternatives. Numeric-Indifferent (= number) A numeric-indifferent preference is used to bias the random selection from mutually indierent values. This preference includes a unary indierent preference, so an operator with a numeric-indifferent preference will not force a tie impasse. When a set of operators are determined to be indierent based on all other asserted preference types and at least one operator has a numericindi erent preference, the decisi´on mechanism will choose an operator based on their numeric-indierent values and the exploration policy. When a single operator is given multiple numeric-indierent preferences, they are either averaged or summed into a single value based on the setting of the numeric-indifferent-mode command. Numeric-indierent preferences that are created by RL rules can be adjusted by the reinforcement learning mechanism. In this way, it’s possible for an agent to begin a task 94 with only arbitrarily initialized numeric indierent preferences and with experience learn to make the optimal decisions. Require (!) A require preference states that the value must be selected if the goal is to be achieved. Prohibit (˜) A prohibit preference states that the value cannot be selected if the goal is to be achieved. If a value has a prohibit preference, it will not be selected for a value of an augmentation, independent of the other preferences. If there is an acceptable preference for a value of an operator, and there are no other competing values, that operator will be selected. If there are multiple acceptable preferences for the same state but with dierent values, the preferences must be evaluated to determine which candidate is selected. If the preferences can be evaluated without con ict, the appropriate operator augmentation of the state will be added to working memory. This can happen when they all suggest the same operator or when one operator is preferable to the others that have been suggested. D.5. Soar’s Execution Cycle: Without Substates The execution of a Soar program proceeds through a number of cycles. Each cycle has ve phases: 1. Input: New sensory data comes into working memory. 2. Proposal: Productions fire (and retract) to interpret new data (state elaboration), propose operators for the current situation (operator proposal), and compare proposed operators (operator comparison). All of the actions of these productions are I-supported. All matched productions re in parallel (and all retractions occur in parallel), and matching and ring continues until there are no more additional complete matches or retractions of productions (quiescence). 3. Decision: A new operator is selected, or an impasse is detected and a new state is created. 4. Application: Productions re to apply the operator (operator application). The actions of these productions will be O-supported. Because of changes from operator application productions, other productions with I-supported actions may also match or retract. Just as during proposal, productions re and retract in parallel until quiescence. 5. Output: Output commands are sent to the external environment. The cycles continue until the halt action is issued from the Soar program (as the action of a production) or until Soar is interrupted by the user. D.6. Impasses and Substates When the decisi´on procedure is applied to evaluate preferences and determine the operator augmentation of the state, it is possible that the preferences are either incomplete or inconsistent. The preferences can be incomplete in that no acceptable operators are suggested, or that there are insucient preferences to distinguish among acceptable operators. The preferences can be inconsistent if, for instance, operator A is preferred to operator B, and operator B is preferred to operator A. Since preferences are generated independently, from dierent production instantiations, there is no guarantee that they will be consistent. 95 D.6.1. Impasse Types There are four types of impasses that can arise from the preference scheme. Tie impasse: A tie impasse arises if the preferences do not distinguish between two or more operators with acceptable preferences. If two operators both have best or worst preferences, they will tie unless additional preferences distinguish between them. Conflict impasse: A con ict impasse arises if at least two values have con icting better or worse preferences (such as A is better than B and B is better than A) for an operator, and neither one is rejected, prohibited, or required. Constraint-failure impasse: A constraint-failure impasse arises if there is more than one required value for an operator, or if a value has both a require and a prohibit preference. These preferences represent constraints on the legal selections that can be made for a decisi´on and if they con ict, no progress can be made from the current situation and the impasse cannot be resolved by additional preferences. No-change impasse: A no-change impasse arises if a new operator is not selected during the decisi´on procedure. There are two types of no-change impasses: state no-change and operator no-change:  State no-change impasse: A state no-change impasse occurs when there are no acceptable (or require) preferences to suggest operators for the current state (or all the acceptable values have also been rejected). The decisi´on procedure cannot select a new operator.  Operator no-change impasse: An operator no-change impasse occurs when either a new operator is selected for the current state but no additional productions match during the application phase, or a new operator is not selected during the next decisi´on phase. There can be only one type of impasse at a given level of subgoaling at a time. Given the semantics of the preferences, it is possible to have a tie or con ict impasse and a constraintfailure impasse at the same time. In these cases, Soar detects only the constraint-failure impasse. The impasse is detected during the selection of the operator, but happens because one of the other four problem-solving functions was incomplete. D.7. Learning When an operator impasse is resolved, it means that Soar has, through problem solving, gained access to knowledge that was not readily available before. Therefore, when an impasse is resolved, Soar has an opportunity to learn, by summarizing and generalizing the processing in the substate. One of Soar’s learning mechanisms is called chunking; it attempts to create a new production, called a chunk. The conditions of the chunk are the elements of the state that (through some chain of production rings) allowed the impasse to be resolved; the action of the production is the working memory element or preference that resolved the impasse (the result of the impasse). The conditions and action are variablized so that this new production may match in a similar situation in the future and prevent an impasse from arising. Chunks are very similar to justications in that they are both formed via the backtracing process and both create a result in their actions. However, there are some important distinctions: 96 1. Chunks are productions and are added to production memory. Justications do not appear in production memory. 2. Justications disappear as soon as the working memory element or preference they provide support for is removed. 3. Chunks contain variables so that they may match working memory in other situations; justications are similar to an instantiated chunk. D.8. Input and Output Many Soar users will want their programs to interact with a real or simulated environment. For example, Soar programs may control a robot, receiving sensory inputs and sending command outputs. Soar programs may also interact with simulated environments, such as a flight simulator. Input is viewed as Soar’s perception and output is viewed as Soar’s motor abilities. When Soar interacts with an external environment, it must make use of mechanisms that allow it to receive input from that environment and to eect changes in that environment; the mechanisms provided in Soar are called input functions and output functions. Input functions add and delete elements from working memory in response to changes in the external environment. Output functions attempt to eect changes in the external environment. Input is processed at the beginning of each execution cycle and output occurs at the end of each execution cycle. 97 98 Anexo E Clases y m´etodos de CERA-CRANIUM y CCBotSoar En este anexo se resumen las clases y m´etodos m´as importantes utilizados para la nueva implementaci´on de la arquitectura CERA-CRANIUM y del CCBotSoar y pretende servir como manual de referencia para una mejor comprensi´on de la estructura del agente. E.1. CCBotSoar Clase principal del bot. E.1.1. Eventos Enventos que maneja la clase CCBotSoar. Todos ellos env´ıan informaci´on a SinglePercept para su posterior procesamiento. BumpedHandler: Detecci´on del choque. itemPickedUp: Detecci´on de Recogida de objeto. hearNoise: Detecci´on de Sonido de alrededor. playerAppeared: Detecta cuando un jugador entra dentro del campo visual. playerUpdated: Este evento recarga la posici´on del jugador que es visible. (Despu´es de haber sido detectado por el evento ”playerAppeared”) PlayerFirstEncountered: Guarda los datos de los jugadores que encuentra pero solo una vez por jugador. PlayerDestroyed: Destruye el jugador cuando un jugador se desconecta. (Error en la ejecuci´on de este evento (No se ejecuta)) 99 Funciones Funciones utilizadas por la clase CCBotSoar prepareBot: Se inicializa el bot y se prepara toda la estructura para el razonamiento. getInitializeCommand: Inicializamos el bot con un traje y nombre(nick). botInitialized: Inicializamos los rayos que ir´a creando el bot para la b´usqueda de intersecciones. botSpawned: Indica que hemos aparecido en el mundo en la consola del bot. resetLastKnowInformation: Resetea toda la informaci´on del bot tanto posici´on como armas... logic: Desde aqu´ı detectamos parte de la percepci´on : Donde se mira, donde se va a mirar, la vida de la cual disponemos y el momento en que cambia, los rayos para determinar posibles caminos, el arma que se tiene seleccionada, la munici´on y los objetos visibles. Y al final ejecutamos una acci´on con todos esos datos. Los datos anteriores se env´ıan a SinglePercept. botKilled: Detectamos la causa de la muerte y se lo enviamos a SinglePercept y reseteamos los valores anteriores con resetLastKnowInformation. main: Detecta si se quiere el bot para un servidor online o local y Genera el bot y lo inicializa. submitPhysicalPercept: Recibe la informaci´on a procesar y la env´ıa a la correspondiente funci´on para que ella se encargue de enviar la informaci´on a las correspondientes funciones. getTime: Funci´on que devuelve el tiempo del bot. E.2. Clases extra (conscious.robots.extra) FileManager: Clase encargada de leer/escribir todos los archivos externos que se quieran utilizar (principalmente para escribir los archivos Soar para la memoria a largo plazo). E.2.1. Risk Clase que gestiona la variable Riesgo para la modificaci´on del radio de selecci´on de activaci´on en el workspace. [Max/Min/Next/Prev]Coef: Pesos para el c´alculo del riesgo. CalculateRisk (Game game, AgentInfo info): Calcula el valor de la variable Riesgo obteniendo todas las puntuaciones necesarias. E.3. Acciones (conscious.robots.actions) E.3.1. Action Priority: Crea un sistema de prioridades para detectar cual es m´as importante. 100 Iindex: Indice de la acci´on(coordenadas obsolutas). CreationTime: Indicamos el tiempo de creaci´on de la acci´on. ExecTime: Cogemos el tiempo de ejecuci´on. Activation: Indicamos el nivel de activaci´on. Compare: Compara dos acciones dependiendo de su prioridad. ActionFactoryInterface: Crea una interfaz para agrupar las distintas funcionalidades de un objeto en subconjuntos m´as manejables. (Todos ellos devuelven SimpleAction). E.3.2. SimpleAction (extensi´on de Action) Type: STRAFE TO, MOVE, LOOK AT, MOVING LOOKING, SHOOT, STOP SHOOTING, SELECT WEAPON, JUMP, NOOP CreateSelectWeapon CreateStrafeToAction CreateMovingLookingAction CreateLookAtAction CreateStopShootingAction CreateShootAction CreateMoveAction CreateJumpAction ActionPriorityComparator JumpAction: Ejecutar un salto o un doble salto. MovingLooking: Mover y mirar a la vez. SelectWeapon: Enviamos el arma que tenemos seleccionada. ShootAction: Disparar. Podemos elegir disparo primario o secundario. StopShootingAction: Parar de disparar. E.3.3. Acciones complejas (extensi´on de Action) Type: GO TO, MOVE TO, LOOK AT, SHOOT TO, STOP SHOOT, SHOOT ENEMY, MOVE CLOSER. LookComplexAction: Mirar a la acci´on m´as compleja MoveCloserComplexAction: Moverse cerca del lugar de la acci´on compleja. MoveComplexAction: Moverse a hacia la acci´on m´as compleja. MovementPlannerComplexAction: Movimiento planeado seg´un la acci´on compleja ShootEnemyComplexAction: Indica la posici´on, nombre y prioridad del enemigo. StrafeToAction: Destrozar a tiros. getFocus: Tiene la posici´on del foco al que nos estamos moviendo. 101 E.4. Razonamiento CERA (conscious.robots.cera) Jindex: Calculos de coordenadas, distancias, rotaciones... Proprioception: Informaci´on interna del cuerpo (AGENT COLLISION RADIUS, radio de coli- si´on del agente con el resto de elementos del juego). ActionPriorityComparator: Compara dos acciones dependiendo de su prioridad. CeraStats: Crea los nombres de las capas. Cera: Clase que define las caracter´ısticas de CERA. LogInfo/LogError: Informaci´on al archivo de log. E.4.1. CeraContext J: Localizaci´on relativa. T: Tiempo general. Relevance: Relevancia del contexto. ActivationTime: Tiempo en el que fue activado. E.4.2. CeraLayer setParentLayer: Prepara las capas superiores. RegisterProcessor: Coloca los procesos que van a la zona de trabajo de la capa. GetWorkspace: Recoge las capas de la zona de trabajo. SubmitPercept: Envia la percepci´on a la zona de trabajo de la capa. SubmitPercepts: Env´ıa una lista de percepciones a la capa. SubmitAction: Sera sobre escrita por otra funci´on. SubmitActions: Sera sobre escrita por otra funci´on. IsItTimeTo: Indica que es tiempo de hacer una acci´on base seg´un el tiempo. getChildLayer: Recoge las referencias de los hijos de la capa. E.4.3. CeraCore (extensi´on de CeraLayer ) IncrementTick: Aumenta el reloj del nuecleo. Process[Control/Control]Percept: Procesa los percepciones de control y misi´on. ProcessA[Novelty/Restart]: Procesa una novedad o un nuevo contexto de reinicio. ResetLayers: Reinicia la capa principal. SwitchContext: Cambia el contexto actual por una localizaci´on indicada de percepci´on. SendContextCmd: Env´ıa un comando que activa las capas inferiores. 102 DiscardOldPercepts: Elimina las percepciones antiguas. DiscardLessActivePercepts: Elimina las percepciones con menos actividad. SendCommand: Envia un comando informando de un excepci´on porque no se puede soportar. E.4.4. CeraException CeraException: Constructor de una excepci´on. CeraException: Mensaje de excepci´on. E.4.5. CeraMission (extensi´on de CeraLayer) CeraMission: Constructor que crea capas de misisones. IncrementTick: Incrementa el tiempo de reloj de esta capa. getTick: Recoge el tiempo. SubmitSimpleAction: Devuelve el canal m´as bajo asociado a la zona de trabajo. SubmitComplexAction: Devuelve el canal m´as bajo asociado a la zona de trabajo. SendCommand: Env´ıa el comando indicado a la zona de trabajo. ResetLayer: No hay nada que resetear. CeraPhysical: sistemas sensitivos y motores espec´ıficos. setMissionLayer: Prepara la capa superior (misi´on). IncrementTick: Prepara el reloj de la capa f´ısica. DiscardOldActions: Desecha las acciones complejas. PurgeExecQueue: Elimina acciones en ejecuci´on de la cola que tienen poca prioridad. GenerateTimePercept: Genera el tiempo de percepci´on y lo env´ıa a la zona de trabajo. getTick: Recoge el tiempo de la capa f´ısica. SubmitComplexAction: Env´ıa una acci´on compleja a la zona de trabajo de la capa. getNextActionsSoar: Carga en el sistema Soar las acciones propuestas y recoge la elegidad por el sistema de reglas (utiliza la funci´on avanceSoar y tambi´en la funci´on actualizarEstadoBot). getNextActionsOnePerType: Devuelve una colecci´on de acciones a ejecutar (funcionamiento previo del CCBot2). SendCommand: Env´ıa un comando especificado a la zona de trabajo y a la capa. ResetLayer: Reiniciamos la capa f´ısica. 103 SubmitResults: Env´ıa las nuevas percepciones o acciones a la zona de trabajo. run: Elimina los datos antiguos y prepara los datos nuevos. start: Inicia el proceso de informaci´on. stop: Elimina el proceso de informaci´on. Get[Input/Output][Single/Complex/Mission/Control]PerceptTypes: Listas de perceptos. GetActionInputTypes: Lista que contiene los tipos de las acciones de entrada. NotifyPercept: Indica que hay nuevas percepciones. NotifyComplexAction: Indica que hay nuevas acciones complejas. Las siguientes funciones, a˜naden los distintos tipos al procesador si este est´a dispuesto: Add[Input/Output][Single/Complex/Mission/Control]PerceptType AddInputComplexActionType - AddOutput[Simple/Complex]ActionType ProcessComplexAction: Llama a la siguiente acci´on compleja para procesarla. ProcessPercept: Llama a las siguiente percepci´on para procesarla. ProcessResult [get/set][Simple/Complex]Actions: Recoge/prepara prepara la lista de acciones (simples o complejas). [get/set]Percepts: Recoge/prepara las percepciones. ProcessResult: Constructor que crea las listas de acciones y percepciones. add[Simple/Complex]Action: A˜nade una nueva acci´on. addPercept: A˜nade una nueva percepci´on. E.8.2. Lista de procesadores AttackDetector: Indica que nos atacan cuando la vida nos baja. AttackingMovement: Indica los movimientos de ataque. AvoidObstacle: Indica que hay un obst´aculo. BackupReflex: Crea una copia de golpear y destrozar a tiros. ChasePlayer: Indica que vamos a perseguir a un enemigo. CloseTargetLocation: Indica que tenemos un enemigo cerca. Curiosity: Indica que tenemos curiosidad y vamos a observar EnemyDetector: Indica que se ha detectado un enemigo. GazeGenerator: Indica si hemos visto algo. GetVisibleItem: Indica los objetos visibles. GoToMalignusPoint: Indica que vamos a un punto maligno. 110 JumpObstacle: Indica un obst´aculo a saltar. KeepEnemiesFar: Indica que nos tenemos que mover a un lugar lejos de enemigos. TooCloseToPlayers: Estamos cerca de un enemigo, debemos correr. LocationReached: Indica si hemos alcanzado el punto al que quer´ıamos llegar. MoveCloserPosition: Indica que nos movemos cerca de un objetivo. MoveLooking: Indica hacia donde nos miramos al movernos. MoveToPoint: Indica el moverse a un punto, seg´un un plan establecido. NotMoving: Indica que no nos movemos al mismo punto de antes. ObstacleDetector: Detecta si hay obst´aculos. ObstacleDetectorNR: Constructor que detecta si hay obst´aculos. PlayerDissappearDetector: Constructor que indique que ha desaparecido un jugador. PlayersNoveltyDetector: Constructor que indica que algo no programado a ocurrido. RandomJumpGenerator: Constructor que indica un salto aleatorio con un 1 % de probabilidad cada 5 minutos. RandomMove: Constructor que indica un movimiento aleatorio en caso de chocarnos contra algo. RestartDetector: Constructor que indica el reseteo de todo cuando hemos muerto. RunAwayFromPlayers: Constructor que inicia todos los par´ametros parra huir del jugador. SelectBestWeapon: Constructor que indica el mejor arma del inventario. SelectEnemyToShoot: Constructor que indica a quien queremos disparar. ShootEnemy: Indica que disparamos a un enemigo. ShootTo: Elige a quien disparar y se disparar. StuckDetector: Indica que nos hemos chocado. RememberItems: Almacena la posici´on de los objetos de la partida e incita a ir hacia ellos cuando los niveles de salud y munici´on son bajos. Wander: Genera acciones de movimiento continuamente. E.9. Entrenamiento (training) Este paquete contiene varios tipos de bots predefinidos para utilizarlos en el entrenamiento del bot. 111 112 Anexo F Tecnolog´ıas utilizadas En este cap´ıtulo se detallan las tecnolog´ıas utilizadas durante el desarrollo de este proyecto y las ventajas y desventajas de su uso. F.1. JSoar JSoar es una implementaci´on en Java de Soar. Soar es una arquitectura cognitiva para el desarrollo de los sistemas que exhiben un comportamiento inteligente. JSoar es esencialmente una biblioteca para la construcci´on de sistemas basados en agentes aunque se tiene que escribir tanto el c´odigo Soar para definir el comportamiento del agente como el c´odigo Java para conectar el agente al entorno, los interfaces, etc. Por tanto, aunque JSoar es una implementaci´on de Soar, para utilizar esta tecnolog´ıa eficientemente es necesario saber programar en Soar. Algunas caracter´ısticas de JSoar: APIs (ver Glosario) en Java. Soporta metalenguaje (JRuby, Jython, Rhino (JavaScript), Groovy, Scala, Clojure, etc). C´odigo base y herramientas sencillas de utilizar que permiten una r´apida iniciaci´on. Integraci´on limpia con los sistemas software. JSoar requiere Java 1.6 para funcionar, pues utiliza caracter´ısticas de Java no disponibles en las versiones anteriores a la 1.6. El API de JSoar est´a dividido en una serie de clases e interfaces. Aunque esto hace las pruebas y las ampliaciones m´as sencillas, puede llevar a la confusi´on y a un c´odigo m´as detallado de lo necesario. Con el mismo esp´ıritu que las clases de “ayuda” de Java, “java.´util.Collections” y “java.´util.Arrays”, JSoar ofrece una serie de clases que casi siempre deben tener prioridad sobre las clases hom´ologas de libre programaci´on por el desarrollador. Son las siguientes: Wmes: M´etodos para buscar y filtrar WMEs (ver Glosario). InputWmes: M´etodos para a˜nadir y actualizar Input WMEs (ver Glosario). Symbols: M´etodos para convertir s´ımbolos en y desde objetos Java. SoarCommands: M´etodos para ejecutar comandos del interprete de Soar. 113 SoarEvents: M´etodos para manejar eventos Soar. La creaci´on de un proyecto JSoar depende mucho del entorno de trabajo, mecanismo de construcci´on y de c´omo se quiere que encaje con el sistema. Dicho esto, un proyecto est´andar de JSoar se puede crear de la siguiente manera: Se inicializa el IDE con el que se va a trabajar, en este caso Netbeans. Se crea un nuevo proyecto Java. Se a˜nade jSoar-core-X.X.X.jar y jSoar-debugger-X.X.X.jar al proyecto. Se crea una clase que contenga la funci´on main y se crea un agente de JSoar. En lo referente a las ventajas de esta tecnolog´ıa, destacamos que ofrece dos tipos de agentes a desarrollar: (1) el “thread agent” para programaci´on en diferentes hilos de ejecuci´on, ya que tiene un hilo de ejecuci´on personal y (2) el “Raw agent” para programaci´on sin hilos de ejecuci´on; la distribuci´on de JSoar viene con unas librer´ıas Java que incluyen todo el c´odigo fuente (esto es ´util generalmente para depurar y averiguar lo que hacen los diferentes m´etodos cuando el javadoc no es suficientemente completo). JSoar dispone tambi´en de un debugger para comprobar el correcto funcionamiento de los agentes. Sin embargo es necesario se˜nalar que es una tecnolog´ıa en desarrollo al igual que Pogamut y hay funcionalidades que no funcionan correctamente (esto ocurre, por ejemplo, con el thread agent y con el debugger, que s´olo funciona con el thread agent luego ninguna se ha podido utilizar en este trabajo). Las dudas en el uso de esta tecnolog´ıa se han resuelto mediante la comunicaci´on v´ıa email con su creador, Dave Ray, con el fin de solventar los problemas que iban surgiendo durante el desarrollo. F.2. UnrealED UnrealED (Unreal Editor) es un software incluido en el videojuego que permite la creaci´on y modificaci´on de mapas para el videojuego Unreal Tournament, se ha utilizado este editor para la implementaci´on de los mapas con los que se realizaron las diferentes pruebas y experimentos. Gracias a esta herramienta disponemos de mapas sencillos que se adaptan a las caracter´ısticas que requieren nuestros experimentos facilitando as´ı la consecuci´on e interpretaci´on de los resultados. El motivo de la elecci´on de esta herramienta es poder disponer de un m´etodo para crear y modificar mapas en el entorno del proyecto. En lo referente a las ventajas y desventajas, la principal desventaja es que la documentaci´on sobre la herramienta es escasa, aparte de que existe un editor diferente para cada videojuego de la saga Unreal Tournament lo que dificulta todav´ıa m´as la b´usqueda de documentaci´on sobre el manejo de la herramienta. M´as en particular, se utiliza un concepto para la creaci´on de objetos que, en vez de generar elementos en el vac´ıo sustrae el elemento que se quiere crear del espacio. 114