BO-L-N364

21
Análisis y Diseño de Algoritmos II – 2009 Trabajo Práctico Especial Se propone implementar una serie de funciones de evaluación heurística que serán utilizadas como parte de un algoritmo de búsqueda parcial que intentará resolver el juego “Pacman”. Introducción al juego El juego se presenta como un laberinto, que contiene paredes que constituyen obstáculos para el movimiento, puntos que es posible comer y fantasmas (enemigos) que persiguen al Pacman. El objetivo es comer la totalidad de los puntos del laberinto sin ser alcanzado por los fantasmas. Figura 1. Diagrama mostrando los elementos que forman parte del juego. La versión del juego que utilizaremos tiene las siguientes características: Se pierde cuando el Pacman es alcanzado por un fantasma. Se gana cuando el Pacman consigue comer todos los puntos del escenario. Los fantasmas y el Pacman se desplazan a la misma velocidad. El escenario contiene únicamente puntos comunes (a diferencia del juego original que contiene además píldoras de poder, que nos permiten comer a los fantasmas). Los posibles movimientos de todos los personajes son hacia casilleros contiguos; en las direcciones hacia arriba, abajo, derecha e izquierda. Únicamente el Pacman puede tomar la decisión de no moverse, siempre que esté bloqueado por una pared en la dirección en la que se estaba desplazando.

description

pdf

Transcript of BO-L-N364

  • Anlisis y Diseo de Algoritmos II 2009

    Trabajo Prctico EspecialSe propone implementar una serie de funciones de evaluacin heurstica que sern utilizadas como parte de un algoritmo de bsqueda parcial que intentar resolver el juego Pacman.

    Introduccin al juegoEl juego se presenta como un laberinto, que contiene paredes que constituyen obstculos para el movimiento, puntos que es posible comer y fantasmas (enemigos) que persiguen al Pacman. El objetivo es comer la totalidad de los puntos del laberinto sin ser alcanzado por los fantasmas.

    Figura 1. Diagrama mostrando los elementos que forman parte del juego.

    La versin del juego que utilizaremos tiene las siguientes caractersticas: Se pierde cuando el Pacman es alcanzado por un fantasma. Se gana cuando el Pacman consigue comer todos los puntos del escenario. Los fantasmas y el Pacman se desplazan a la misma velocidad. El escenario contiene nicamente puntos comunes (a diferencia del juego original que

    contiene adems pldoras de poder, que nos permiten comer a los fantasmas). Los posibles movimientos de todos los personajes son hacia casilleros contiguos; en las

    direcciones hacia arriba, abajo, derecha e izquierda. nicamente el Pacman puede tomar la decisin de no moverse, siempre que est

    bloqueado por una pared en la direccin en la que se estaba desplazando.

  • Los fantasmas que comienzan dentro de la casa, salen de ella a intervalos determinados de tiempo.

    Los fantasmas alternan entre dos modos de juego distintos: persecucin y asustadizo, a intervalos predefinidos de tiempo. Luego de varios intervalos, los fantasmas mantienen el modo persecucin hasta el final del juego, como se ve a continuacin.

    Figura 2. Tiempo de duracin (en segundos) de los modos asustadizo (verde) y persecucin (rojo) de los fantasmas.

    En cada modo de juego, los fantasmas intentan alcanzar un casillero objetivo. Se presenta una tabla que indica cmo se determina el casillero objetivo de acuerdo al modo de juego:

    Fantasma \ Modo de juego Persecucin Asustadizo

    BlinkyEl casillero objetivo es la posicin actual del Pacman. El casillero objetivo es

    la esquina superior derecha.

    PinkyEl casillero objetivo se encuentra a cuatro pasos de la posicin actual del Pacman, en la direccin en la que se est desplazando.

    El casillero objetivo es la esquina superior izquierda.

    Inky

    A partir de la posicin actual del Pacman se obtiene el casillero a dos pasos de distancia, en la direccin en la que se est desplazando. Luego, se traza una lnea desde la posicin de Blinky hasta dicho casillero, y se extiende el doble de longitud en esa direccin. El casillero objetivo, es donde termina la lnea.

    El casillero objetivo es la esquina inferior derecha.

    ClydeCuando se encuentra a ms de ocho pasos de distancia, el casillero objetivo es la posicin actual del Pacman. Si se encuentra a menos de ocho pasos, el casillero objetivo es la esquina inferior izquierda (modo asustadizo).

    El casillero objetivo es la esquina inferior izquierda.

    Figura 3. Lgica de movimiento de los fantasmas en modo persecucin.

    Figura 4. Lgica de movimiento de los fantasmas en modo asustadizo.

    7 20 7 20 5 20 5 ...

  • Fundamentos tericosSe plantea el problema de desarrollar algoritmos que obtengan la sucesin de movimientos que debe realizar el Pacman para jugar de la mejor forma posible. Para facilitar el desarrollo se provee la una parte de la implementacin de estos algoritmos la cual se basa en la estrategia de bsqueda parcial.A continuacin describiremos los fundamentos tericos para entender por qu la misma resulta adecuada para resolver este problema en particular.

    La propuesta para resolver el problema es utilizar el concepto de grafo para modelar la dinmica del juego. De esta forma cada configuracin o estado del laberinto se considerar un vrtice. Luego, teniendo en cuenta que los movimientos de los enemigos son determinsticos, consideramos que slo los movimientos vlidos que puede realizar el Pacman, a partir de un estado, constituirn los arcos hacia nuevos estados. La configuracin de los nuevos estados ser la obtenida a partir de procesar el movimiento del Pacman y cada uno de los movimientos que realizan los fantasmas hasta que el Pacman pueda moverse otra vez. (Ver figura 5)

    Una vez que conseguimos modelar con un grafo el desarrollo del juego, vemos que es posible aplicar los algoritmos clsicos de recorrido (DFS, BFS) adaptados a la bsqueda del estado objetivo (es decir una configuracin del laberinto donde el Pacman comi todos los puntos). Esta adaptacin lleva a lo que se conoce como algoritmos de bsqueda por fuerza bruta, ya que exploran sistemticamente los estados, generando los mismos en el orden que define cada tipo de recorrido. Vemos entonces que la base de estas estrategias de bsqueda son los recorridos simples sobre grafos a los cuales se les agrega una condicin para detenerse en el momento en que se alcanza el estado objetivo.

    DFS(EstadoJuego E, Solucin S):Si E es el estado objetivo

    Devolver la solucin con los pasos ejecutados hasta el momentoSino

    Si E no fue visitado anteriormenteMarcar a E como visitadoPara cada movimiento vlido, M, del Pacman en E

    Generar el nuevo estado E' ejecutando M y procesando los turnos de los enemigosAgregar M a SDFS(E', S)Si se encontr solucin

    Terminar y devolver la solucinSino

    Volver el estado actual a E, y sacar a M de S

    Pseudocdigo de ejemplo de la bsqueda en profundidad aplicada a la resolucin del problema.

    Existen algoritmos de bsqueda ms avanzados que utilizan informacin adicional, especfica al contexto del problema, para orientar la bsqueda de la solucin. Este tipo de algoritmos se denomina de bsqueda heurstica, ya que su objetivo es reducir el tiempo del proceso al orientar la exploracin de los estados esperando evaluar una cantidad menor que las estrategias por fuerza bruta. El hecho de que se los llame heursticos se debe a que en general no es posible garantizar una mejora para todos los posibles escenarios. Uno de los algoritmos de bsqueda heurstica ms populares es el A* (A estrella).

    La complejidad temporal de los algoritmos anteriormente mencionados est determinada por el tamao del espacio de bsqueda (que es el nombre que se le da al grafo o rbol utilizado para modelar el desarrollo del juego). El tamao del espacio de bsqueda se encuentra en el orden de bn, donde:

    b: es el factor de ramificacin (nmero de acciones o movimientos promedio que se pueden realizar a partir de cada estado);

    n: es la cantidad de pasos de la solucin.

  • Fig

    ura

    5. E

    stad

    os g

    ener

    ados

    a p

    artir

    de

    los d

    istin

    tos

    mov

    imie

    ntos

    del

    Pac

    man

    .

  • Bsqueda parcial

    Una forma de caracterizar a los algoritmos de bsqueda es en base a la forma en la que organizan las etapas de planificacin de la solucin y la ejecucin. Bajo este criterio, los algoritmos como el DFS, BFS y el A* se denominan algoritmos de bsqueda completa porque calculan la solucin en un nico paso de planificacin, y luego se realiza la ejecucin de la misma.

    Figura 6. Modo de operacin de los algoritmos de bsqueda completa.

    Una limitacin de este tipo de estrategias surge cuando el espacio de bsqueda es demasiado grande, haciendo que el tiempo de la planificacin se vuelva inviable.

    El juego que estamos tratando es uno de los casos donde la complejidad del problema lleva a un espacio de bsqueda muy grande. Aunque no contamos con el factor de ramificacin ni la longitud de la solucin exactos, sabemos las cotas inferiores de cada uno. El factor de ramificacin es al menos 2 y la longitud de la solucin ptima no puede ser inferior a 244 (el nmero de puntos), por lo que el espacio de bsqueda se encuentra en el orden de los 2244 estados.Es claro que los algoritmos de bsqueda exhaustiva no son una opcin viable para la resolucin de este problema, y si bien los algoritmos de bsqueda completa heursticos podran reducir considerablemente la cantidad de planificacin, esto depender exclusivamente de la calidad de la funcin de evaluacin heurstica utilizada. Sin embargo, el trabajo para construir una funcin de evaluacin, de la calidad requerida, puede ser muy dificultoso o impracticable.

    Los algoritmos de bsqueda parcial alternan etapas de planificacin (de tiempo acotado) y etapas de ejecucin de lo que parecen ser los mejores pasos (basndose en la informacin limitada con la que se cuenta) para llegar a una solucin.

    Figura 7. Modo de operacin de los algoritmos de bsqueda parcial.

    Este es el tipo de algoritmos de bsqueda que se utilizar para la resolucin de este trabajo. Surgen consecuencias importantes a partir de esta decisin:

    Dado que existen acciones que no se pueden revertir (por ejemplo aquellas que hacen que los fantasmas encierren al Pacman o lo coman) no siempre se hallar una solucin.

    De encontrarse una solucin, en general, la misma no ser ptima.

    Durante la etapa de planificacin se determinar cul de las acciones, que es posible realizar a continuacin, podra llevar con probabilidad ms alta a una resolucin satisfactoria del problema. Es fundamental restringir la profundidad de bsqueda para poder responder dentro de los lmites de tiempo impuestos. Si bien el tiempo de ejecucin de los algoritmos de bsqueda es exponencial respecto a la frontera de bsqueda, la misma est acotada por una constante y por lo tanto tambin lo est el tiempo de ejecucin. Dado que la profundidad de bsqueda es limitada, es necesario contar con un mtodo para evaluar los estados no-objetivo. Es esencial para el funcionamiento de esta estrategia la utilizacin de heursticas que permitan estimar el costo de alcanzar un objetivo desde un estado intermedio.

    Planificacin Ejecucin

    Planificacin ...Ejecucin Planificacin Ejecucin Planificacin Ejecucin

  • Uno de los principios ms importantes de la bsqueda parcial es la utilizacin de la estrategia del menor compromiso para los movimientos. Es decir, la informacin obtenida en cada etapa de planificacin slo se utilizar para determinar el prximo movimiento. La razn es que luego de ejecutar la accin, se supone que la frontera de bsqueda se expandir, lo cual puede llevar a una eleccin para el segundo movimiento diferente a la que arroj la primera bsqueda.

    Sin embargo, para realizar una secuencia de decisiones no es suficiente con la informacin devuelta por el algoritmo de planificacin. La estrategia bsica de repetir el algoritmo de planificacin para cada decisin resulta inadecuada al ignorar la informacin relacionada con los estados anteriores. El problema radica en que, al volver a un estado previamente visitado, se entrar en un ciclo infinito. Esto es algo que suceder con frecuencia, debido a que las decisiones se basan en informacin limitada y por lo tanto direcciones que al principio parecan favorables pueden resultar equivocadas al reunir ms informacin durante la exploracin. En general, se desea evitar entrar en ciclos infinitos y a la vez permitir volver a estados ya visitados cuando parezca favorable.

    Funciones de evaluacin heurstica

    Las funciones de evaluacin heurstica (o simplemente heursticas) permiten estimar el costo del camino ptimo entre dos estados. Esta definicin es la utilizada en el contexto de problemas de bsqueda desde la perspectiva de un nico jugador (o agente). Para juegos de dos jugadores tambin se utilizan heursticas, pero las mismas son estimaciones de la utilidad de los estados teniendo en cuenta la perspectiva de ambos jugadores.En general, los estados evaluados sern un estado no terminal y el estado objetivo. En este tipo de juegos, donde las condiciones que determinan los estados objetivos permanecen invariables, el parmetro principal de la evaluacin es el estado no terminal. La distancia estimada es la correspondiente a una configuracin donde se alcanza el objetivo a travs del cumplimiento de dichas condiciones.

    Se llama esttica a una funcin heurstica que tiene como parmetro slo la configuracin de un estado. Dichas funciones tienen en cuenta ciertas variables para calcular la estimacin de la distancia. Frecuentemente la funcin heurstica es una combinacin lineal de las variables consideradas, que se pesan de algn modo para obtener un valor en trmino de las unidades elegidas.Se puede extender a la funcin evaluacin esttica a travs de una bsqueda limitada por el tiempo (o profundidad), en la cual se aplica a los estados de la frontera la evaluacin esttica sumndole el costo real que implica llegar a cada uno de ellos desde la raz. De esta forma se obtiene una evaluacin ms precisa que una heurstica esttica ya que reduce la incertidumbre.A la hora de disear una funcin heurstica se debe hacer un balance entre:

    el costo computacional de cada evaluacin; la calidad de la estimacin retornada.

    Objetivo del trabajoEl objetivo del trabajo es desarrollar funciones de evaluacin heurstica (estticas) para que las utilice un algoritmo de bsqueda parcial que ya se encuentra disponible junto con el resto del juego descripto en la introduccin. A su vez, se requiere un anlisis de los resultados obtenidos al utilizarlas con distintos niveles de profundidad para la bsqueda realizada durante la planificacin de cada accin.

    El resto de las secciones explicarn las caractersticas de la aplicacin, as como el soporte para el desarrollo de las funciones que se deben implementar. Tambin se describir en detalle el algoritmo de bsqueda utilizado. Por ltimo, se presentarn los requisitos de entrega del trabajo.

  • Descripcin de la aplicacinAl ejecutar la aplicacin se nos presentar la siguiente pantalla, en la cual se detallan los modos de juego iniciales que podemos elegir.

    Figura 8. Pantalla inicial del juego.

    Modo de juego: Manual

    En este modo de juego se podr jugar controlando al Pacman mediante los siguientes controles: Mover hacia arriba: flecha arriba Mover hacia abajo: flecha abajo Mover hacia la derecha: flecha derecha Mover hacia la izquierda: flecha izquierda

    Para obtener una experiencia de juego similar al juego original, el Pacman continuar ejecutando la ltima accin indicada, siempre que sea posible, es decir, mientras que un obstculo no se interponga en su camino o se le indique que realice una nueva accin.Adems, en este modo de juego, el Pacman comenzar su recorrido realizando un movimiento haca la izquierda.

    Modos de simulacin

    Al seleccionar cualquier de los dos modos de juego de simulacin, que se explicarn a continuacin, se presentar en primera instancia una pantalla que permitir seleccionar la funcin de evaluacin heurstica a utilizar. Luego se presentar una pantalla que permitir seleccionar la profundidad de la bsqueda.

    Figura 9. Men de seleccin de heursticas. Figura 10. Men de seleccinde profundidad de la bsqueda..

  • Modo de juego: Simulacin completa

    En este modo de juego se realiz una simulacin completa del juego, intercalando las etapas de planificacin y ejecucin, como se explic anteriormente, hasta que se termina el juego. Una vez terminada la simulacin, el juego reproducir las acciones obtenidas en las etapas de planificacin permitiendo ver los movimientos elegidos. Adems, se generar un archivo de texto con las acciones que formaron parte de la solucin. El nombre del archivo se indicar por consola, como se ve en la pantalla siguiente.

    Figura 11. Generacin del archivo con la solucin generada.

    Modo de juego: Simulacin interactiva

    Este modo de juego es similar al anterior, solo que despus de cada etapa de planificacin se visualizar por pantalla la ejecucin de la accin obtenida, junto con la consecuencia de realizar dicha accin.Como lo indica su nombre, este modo nos permite ver de forma interactiva como se realiza cada paso de planificacin y su posterior ejecucin.Al igual que el modo anterior, la solucin encontrada se almacenar en un archivo de texto generado automticamente.

    Modo de juego: Reproducir la ltima solucin

    Al finalizar la ejecucin de la solucin en los modos de simulacin completa o interactiva se presentar una nueva opcin en el men de seleccin de modo de juego. sta nueva opcin permitir volver a reproducir la ltima solucin encontrada.

    Figura 12. Pantalla inicial del juego con opcin de reproducir la ltima solucin.

    Modo de juego: Reproducir archivo de solucin

    Por ltimo, se permite otro modo de juego, en el cual se puede reproducir una solucin previamente almacenada en un archivo de texto. Este archivo de texto debe contener una accin por lnea, respetando el formato de los archivos de texto generados automticamente por la ejecucin de los modos de juego de simulacin.

  • Para utilizar este modo de juego se debe indicar por parmetro el nombre del archivo de texto que contiene la solucin. Si el archivo pudo ser cargado correctamente se presentar la siguiente opcin.

    Figura 13. Pantalla inicial del juego con opcin de reproducir a partir de archivo de solucin.

    Comandos generales

    En todos los modos de juego se permite realizar un pausado y posterior reanudacin del juego; para esto se utiliza la barra espaciadora.Tambin se permite interrumpir cualquier ejecucin del juego y retornar al men seleccin del modo de juego, desde cualquier pantalla, mediante la tecla escape.

    Salida por consola

    Durante el desarrollo del proyecto se podr utilizar la consola para visualizar mensajes de control. Estos mensajes se visualizarn en una consola asociada a la ventana principal de la aplicacin como se ve en la imagen siguiente.

    Figura 14. Consola para visualizar los mensajes de control.

    Adems, se podr guardar la salida de la aplicacin en un archivo de texto, redireccionando la salida. Por ejemplo:

    C:\pacman\pacman.exe > salida.log

    Importante: para poder ejecutar la aplicacin desde una consola se debe copiar el ltimo ejecutable creado desde el proyecto Code::Blocks (ubicado generalmente en bin\Debug), dentro del directorio raz del proyecto. Esto se debe a que el ejecutable necesita la carpeta data (y los archivos dll).

  • Soporte provisto para el desarrollo de los algoritmosPara la implementacin de los algoritmos se dispone de un proyecto que consiste en la implementacin completa del juego Pacman. El mismo incluye la lgica del juego (reglas, configuracin y comportamiento de cada uno de los personajes), as como una interfaz de usuario que permite controlar al Pacman manualmente y tambin, a travs de las soluciones obtenidas por los distintos algoritmos que se van a implementar.

    Los tipos de datos principales que se proveen para la realizacin de los algoritmos son: LogicObject: representa todos los jugadores y objetos del juego: el Pacman, los enemigos,

    las paredes y los puntos. GameSpace: permite acceder a los objetos del juego a travs de sus coordenadas en el

    laberinto. GameState: guarda una configuracin determinada del juego. Es decir es el estado en el que

    se encuentran cada uno de los objetos del juego en un momento dado. GameSimulator: Permite gestionar los estados por los que atraviesa el juego. En particular:

    avanzar el juego hasta que nos toque el turno nuevamente; deshacer los cambios en el juego luego de un movimiento; llevar la simulacin a un estado determinado que hayamos generado anteriormente.

    La descripcin completa de cada uno de los mtodos que conforman estos tipos de datos principales se encuentra en la documentacin HTML provista.

    Constantes del juego

    Las constantes utilizadas en el juego se encuentran en el archivo Pacman.h.

    /* * Variables globales del juego */const unsigned int DOT_COUNT = 1001;const unsigned int DESTROYED_DOTS = 1002;const unsigned int SCATTERED_MODE = 1003;/* * Elementos del juego. */const std::string PACMAN = "Pacman";const std::string DOT = "Dot";const std::string BLINKY = "Blinky";const std::string PINKY = "Pinky";const std::string INKY = "Inky";const std::string CLYDE = "Clyde";const std::string GHOST = "Ghost"; //Subtipo utilizado para identificar a los fantasmas.const std::string WALL = "Wall"; //Subtipo utilizado para identificar a las paredes que componen el laberinto.

    /* * Atributos de los personajes del juego. */const unsigned int DIRECTION = 1000;const unsigned int INSIDE_HOUSE = 1001;// Posibles direcciones de los personajes del juego.typedef enum {UP, DOWN, LEFT, RIGHT} Direction;

  • Acceso a los objetos lgicos del juego

    Hay dos formas de acceder a los objetos lgicos del juego: a travs de su tipo o subtipo utilizando el mtodo getObjects (en el caso de ser un nico

    objeto se puede utilizar getObject directamente) del juego (cuyo tipo es Game). a travs de sus coordenadas o posicin, opcionalmente filtrando por el tipo o subtipo,

    utilizando el mtodo getObjects del espacio de juego (que es una instancia de la clase GameSpace). El espacio del juego es accesible desde el juego.

    Los tipos y subtipos de los objetos lgicos estn definidos en las constantes del juego.

    Ejemplos

    Obtener el Pacman:

    const LogicObject * pacman = game->getObject(PACMAN);

    Obtener todos los fantasmas del juego:

    //Se define un conjunto de subtipos y se le agrega el subtipo GHOST.set ghostSubtype;ghostSubtype.insert(GHOST);

    list ghosts;game->getObjects(LogicObject::Type(ghostSubtype), ghosts);

    Obtener los elementos del juego que estn dentro de una regin:

    list objects;game->getGameSpace().getObjects(Rectangle(1,1,5,4), objects);

    Obtener slo los fantasmas que estn dentro de una regin:

    //Se define un conjunto de subtipos y se le agrega el subtipo GHOST.set ghostSubtype;ghostSubtype.insert(GHOST);

    list objects;game->getGameSpace().getObjects(Rectangle(1,1,10,10),

    LogicObject::Type(ghostSubtype), objects);

    Variables globales del juego

    El juego mantiene ciertas caractersticas como variables globales. Las mismas se encuentran almacenadas en una estructura de variables, accesible desde el juego. Los identificadores de estas variables estn definidos en las constantes del juego.

    Obtener los puntos restantes del juego:

    game->getVariables().getInteger(DOT_COUNT);

    Obtener el modo en el que se encuentran los fantasmas:

    game->getVariables().getBoolean(SCATTERED_MODE);

  • Atributos de los personajes del juego

    Los objetos lgicos, al igual que el juego, mantienen sus caractersticas particulares como variables. En el caso de los objetos lgicos estas variables se denominan atributos. Los atributos estn identificados por constantes del juego y pueden ser de cualquier tipo.

    Obtener la direccin del fantasma Pinky:

    const LogicObject * pinky = game->getObject(PINKY);Direction direction;pinky->getAttribute(DIRECTION, direction);

    Otra forma equivalente es acceder a los atributos del juego y luego a la direccin mediante el mtodo get del tipo de dato Variables:

    const LogicObject * pinky = game->getObject(PINKY);Direction direction;pinky->getAttributes().get(DIRECTION, direction);

    Determinar si Pinky est dentro de la casa o no:

    const LogicObject * pinky = game->getObject(PINKY);bool insideHouse;pinky->getAttribute(INSIDE_HOUSE, insideHouse);

    Otra forma equivalente es acceder a los atributos del juego y luego al valor buscado mediante el mtodo getBoolean del tipo de dato Variables.Este tipo de acceso es til cuando el atributo a obtener es de un tipo bsico conocido.

    const LogicObject * pinky = game->getObject(PINKY);pinky->getAttributes().getBoolean(INSIDE_HOUSE)

  • Implementacin del algoritmo de bsqueda parcialA continuacin se presenta un pseudocdigo del proceso de bsqueda, de forma simplificada:

    Mientras no termine el juego: Realizar la etapa de planificacin para obtener la prxima accin a

    ejecutar. Procesar la accin obtenida, actualizando el estado del juego hasta que

    se pueda realizar otra accin asegurndose de que no se produzcan ciclos.

    Almacenar la accin como parte de la solucin.

    En el modo de juego de simulacin interactiva, adems de ejecutar la accin y almacenarla como parte de la solucin, se actualizar la visualizacin del juego al mismo tiempo que se ejecuta la bsqueda. En este modo, se reemplaza el control manual por un control automtico que ejecuta un ciclo del algoritmo para determinar cada paso. De esta forma se puede ver el tiempo de respuesta del algoritmo para tomar una decisin y su impacto en la fluidez del juego.Esto contrasta con el modo de simulacin completa que guarda la solucin despus de llevar a cabo el proceso de bsqueda anterior. Luego se muestra la solucin, iniciando el juego con la visualizacin y un control automtico para el Pacman que ejecuta las acciones directamente, evitando la planificacin (igual a lo que sucede en el modo de reproduccin de la solucin desde archivo).

    El proceso de bsqueda parcial descripto anteriormente ser implementado a travs del A* de Tiempo Real (Real Time A* o RTA*). Este algoritmo de control es el encargado de evaluar las acciones mediante funciones de evaluacin heurstica, lo cual se denomina etapa de planificacin, como ya se mencion. De esta forma decide que accin se llevar a cabo a continuacin (en la etapa de ejecucin). Adicionalmente el algoritmo implementa una estrategia que evita que se caiga en ciclos infinitos permitiendo volver a estados ya visitados slo cuando es conveniente.

    Durante la etapa de planificacin se suelen utilizar funciones de evaluacin de estados extendidas mediante bsqueda (cuyo tiempo ser acotado a travs de un lmite en la profundidad). Existen varias modificaciones a los algoritmos de bsqueda heurstica completa para poder utilizarlos como funciones de evaluacin. De todos ellos se opt por el Minimin que realiza un proceso similar al del algoritmo Minimax modificado para la evaluacin desde el punto de vista de un nico jugador.Hay dos parmetros que afectan el comportamiento de este algoritmo, la profundidad, que determina la frontera de bsqueda, y la funcin de evaluacin heurstica esttica, utilizada para evaluar los estados en la misma. Como ya se mencion, es posible configurar estos parmetros de forma dinmica ya que se presentan como opciones antes del inicio de la simulacin.

    La caracterstica ms importante a destacar, de la implementacin, es que ambos algoritmos son mtodos de una clase llamada PacmanRTAPathfinder (cuyo cdigo se encuentra en los archivos PacmanRTAPathfinder.h y PacmanRTAPathfinder.cpp). Los mismos utilizan el soporte de simulacin provisto por la clase GameSimulator, la cual provee las funciones necesarias para manipular los estados del juego al nivel de abstraccin requerido para que la implementacin de los algoritmos sea sencilla.

    A continuacin se presentar la implementacin de ambos algoritmos, junto con una breve descripcin del funcionamiento y caractersticas principales.

  • Real-Time A* (RTA*)

    RTA* es un algoritmo para controlar la fase de ejecucin de la bsqueda parcial y es independiente del algoritmo de planificacin. El algoritmo guarda el valor de cada estado visitado durante la etapa de ejecucin en una tabla de hash. A medida que la bsqueda avanza se actualizan estos valores utilizando tcnicas derivadas de la programacin dinmica.

    La propiedad ms importante de RTA* es que, en espacios finitos y si el estado objetivo se puede alcanzar, se garantiza que se encontrar una solucin. Adems, el espacio requerido es lineal respecto al nmero de movimientos realizados, ya que slo lleva una lista de los estados previamente visitados. El tiempo de ejecucin tambin es lineal respecto a los movimientos ejecutados. Esto se debe a que, aunque el tiempo de planificacin es exponencial respecto a la profundidad de bsqueda, el tiempo est acotado por una constante al limitar la profundidad de bsqueda.

    El proceso de bsqueda que realiza el algoritmo es el siguiente: A los estados que no fueron visitados se les aplica la funcin de evaluacin heurstica,

    posiblemente extendida mediante una bsqueda. Para los estados que se encuentran en la tabla se utiliza el valor heurstico f guardado en ella. El vecino con el menor valor f es elegido para ser el nuevo estado actual y la accin para

    alcanzar ese estado es ejecutada. El estado anterior se guarda en la tabla y se le asocia el segundo mejor valor f de los vecinos

    ms el costo para regresar al mismo desde la nueva posicin.

    Los primeros dos puntos se corresponden a la etapa de planificacin mientras que los ltimos dos estn relacionados con la etapa de ejecucin de la bsqueda parcial.

    La implementacin del RTA* se encuentra repartida en los mtodos processCycle y getAction de la clase PacmanRTAPathfinder. El mtodo processCycle coordina el proceso de bsqueda parcial. El mismo invoca a la funcin getAction, que lleva a cabo la planificacin, y luego realiza los pasos necesarios para la ejecucin.

  • El mtodo processCycle

    Consiste en una iteracin del ciclo de bsqueda, es decir, una etapa de planificacin seguida de la ejecucin de una accin. Para determinar una solucin completa slo se requieren invocaciones sucesivas hasta que se termine el juego:

    void getSolution(PacmanPathfinder * pathfinder, list & solution){

    while (!pathfinder->isGameOver()) {solution.push_back(pathfinder->processCycle());

    }}

    Como ya se dijo, primero se realiza la planificacin a travs de la funcin getAction. As se determina la siguiente accin a realizar (bestAction). Adems de la accin se obtienen la evaluacin heurstica del estado al que se pasar al realizar la misma (bestF), as como el valor heurstico de la segunda mejor opcin (secondBestF).

    Algunas aclaraciones relevantes a esta parte del algoritmo: Cuando la profundidad de bsqueda es lo suficientemente grande, es posible encontrar que,

    independientemente de lo que se haga, se va a perder el juego. Esto puede ocurrir an cuando falta realizar varias acciones para perder en forma efectiva. El problema es que la planificacin, al no considerar que es deseable prolongar el juego, devuelve la primer accin evaluada y como consecuencia es frecuente que se pierda antes de tiempo.La solucin implementada consiste en detectar esta situacin (bestF >= LOSE_VALUE) y volver a realizar una planificacin limitando la profundidad de bsqueda a un nivel. De este modo, se reemplazar el primer resultado obtenido por una accin que permita seguir jugando (si es que existe).

    Otra verificacin necesaria concierne al valor heurstico del estado vecino asociado a la segunda mejor accin encontrada. Hay casos en los que hay una sola opcin viable y el resto (incluyendo la segunda mejor) lleva a perder el juego. Como el valor que se asocia al estado actual es el segundo mejor f encontrado, si se guarda el mismo cuando ocurre esta situacin se estar guardando una evaluacin incorrecta del mismo (ya que volver al mismo nos llevar a perder).Para no incurrir en este error, se agreg al algoritmo una verificacin que detecta el problema (secondBestF >= LOSE_VALUE) y corrige el valor de la segunda mejor evaluacin heurstica de los estados vecinos, reemplazndolo por el mejor.

    Para llevar acabo la simulacin de la ejecucin de las acciones en el juego, registrar los estados visitados y asociarles los valores heursticos que requiere el RTA*, se utiliza un simulador principal llamado controlSim (instancia de la clase GameSimulator). ste es el simulador principal del proceso (ms adelante se ver que durante la planificacin se utiliza un segundo simulador). El mismo es un atributo de la clase PacmanRTAPathfinder, porque se debe mantener su estado entre las diferentes invocaciones al mtodo.

    Antes de ejecutar la accin que llevar a un cambio de estado se debe guardar el valor heurstico que reflejar el costo de volver al estado actual (controlSim.setStateValue(..., secondBestF + 1)).

    Por ltimo, se realiza la accin (controlSim.getPlayer()->performAction(...)) y se actualiza el juego para llevarlo al prximo estado donde es posible tomar una decisin (controlSim.update()).

  • Action::Type PacmanRTAPathfinder::processCycle(){

    unsigned int bestF, secondBestF;Action::Type bestAction = getAction(maxDepth, bestF, secondBestF);

    if (bestF >= LOSE_VALUE) {bestAction = getAction(1, bestF, secondBestF);

    }

    if (secondBestF >= LOSE_VALUE) {secondBestF = bestF;

    }

    const GameState * controlState = controlSim.getCurrentState();unsigned int visitedId = controlSim.getVisited(controlState);if (visitedId == 0) {

    controlSim.addVisited(controlState);controlSim.setStateValue(controlState->getId(), secondBestF + 1);

    } else {controlSim.setStateValue(visitedId, secondBestF + 1);

    }

    controlSim.getPlayer()->performAction(bestAction);controlSim.update();

    return bestAction;}

    El mtodo getAction

    Es la parte del algoritmo donde se determina la siguiente accin a ejecutar. La misma utiliza la funcin de evaluacin heurstica extendida mediante bsqueda para obtener la accin que llevar al Pacman a un estado ms cercano a ganar el juego.El proceso de planificacin requiere de la simulacin del juego al igual que la ejecucin, como ya se explic antes. Si bien se desean mantener los estados visitados entre las bsquedas realizadas por la funcin de evaluacin, los mismos no se deben mezclar con los estados visitados durante el proceso de ejecucin. Es por eso que para la planificacin se utiliza un simulador llamado planSim, que se sincroniza al comienzo de esta etapa con el simulador principal controlSim.

    La planificacin consiste en realizar la evaluacin de los estados vecinos al estado actual.Para generar estos estados, primero se obtienen las acciones del Pacman (player->getActions(...)). Luego, para cada accin se verifica si se puede realizarla en el estado actual del juego(player->canPerformAction(..)); en caso afirmativo ejecuta la misma (player->performAction(..)) y actualiza el estado del juego (planSim.update()). Una vez realizada la evaluacin de una configuracin del juego es necesario volver al estado previo (planSim.undoUpdate()) para ejecutar desde all la siguiente accin.

    Para la evaluacin de los estados se tiene en cuenta si los mismos ya fueron visitados o no durante el proceso de ejecucin (realizado por processCycle que guarda esta informacin en el controlSim), ya que el algoritmo RTA* requiere un tratamiento particular para cada caso:

    Si el estado no fue visitado (controlSim.getVisited(...) == 0) se utiliza la funcin de evaluacin heurstica extendida mediante bsqueda (minimin).

    Si el estado ya fue visitado (controlSim.getVisited(...) != 0) se recupera el valor heurstico asociado al estado (controlSim.getStateValue(...)).De esta forma, es que el RTA* toma en consideracin los ciclos y permite retornar a los estados visitados en forma controlada.

  • Action::Type PacmanRTAPathfinder::getAction(unsigned int depth, unsigned int & bestF, unsigned int & secondBestF)

    {GameSimulator planSim;planSim.setGame(controlSim.getGame());planSim.setPlayer(controlSim.getPlayer());planSim.setSimulatorController(controlSim.getSimulatorController());

    LogicObject * player = planSim.getPlayer();list playerActions;player->getActions(playerActions);

    bestF = MAX_F;secondBestF = MAX_F;Action::Type bestAction = player->getDefaultActionType();

    list::iterator action = playerActions.begin();while (action != playerActions.end()) {

    if (player->canPerform(*action)) {player->performAction(*action);planSim.update();

    unsigned int f = MAX_F;unsigned int visitedId =

    controlSim.getVisited(planSim.getCurrentState());if (visitedId == 0) {

    f = minimin(planSim, depth, 1);} else {

    f = controlSim.getStateValue(visitedId);}

    if (f < bestF) {secondBestF = bestF;bestF = f;bestAction = *action;

    } else if (f < secondBestF) {secondBestF = f;

    }

    planSim.undoUpdate();}action++;

    }

    return bestAction;}

  • Minimin

    El algoritmo Minimin realiza una bsqueda en profundidad asignando un valor heurstico a cada estado encontrado en la frontera de bsqueda, determinada por el lmite en la profundidad. Estos valores se suben hasta la raz de la bsqueda (es decir, al estado inicial evaluado). Para ello, cada nodo intermedio determina su valor retornando el valor del menor de sus hijos. Al final de la bsqueda, el valor de la raz ser el correspondiente a la menor de las evaluaciones de los nodos de la frontera.El valor heurstico asignado a los estados de la frontera debe ser una estimacin de la distancia que existe a un estado donde se gana el juego, partiendo del estado raz y pasando por el estado evaluado (f). Para reflejar correctamente este valor, a la evaluacin heurstica esttica de los estados (h) de la frontera de la bsqueda se les debe sumar el costo real del camino que se recorri para llegar a ellos desde la raz (g).

    La funcin recursiva correspondiente al algoritmo es el mtodo minimin de la clase PacmanRTAPathfinder. El mismo toma como parmetro principal, al estado del juego a evaluar gestionado por un simulador (planSim). Adicionalmente se pasan la profundidad de bsqueda mxima que es posible alcanzar (depth), as como el nivel actual o costo del camino acumulado (g).

    Como se ve en el cdigo que sigue, hay dos condiciones de corte indispensables, las cuales son: El estado evaluado corresponde a un final del juego (planSim.isGameOver()).

    En este caso se puede determinar directamente el valor real de dicho estado. Si se gan el juego, el valor a devolver es la cantidad de pasos acumulados desde la raz dada por g. Por el contrario, si se perdi se sabe que a travs de dicho estado nunca se alcanzar una resolucin satisfactoria y se retorna un valor muy grande dado por la constante LOSE_VALUE.

    Se alcanz el lmite de la profundidad permitida (g >= depth).Como ya se dijo, este es el caso general donde se determina el valor heurstico f = h + g de los estados de la frontera de bsqueda. Aqu es donde se utiliza la funcin de evaluacin heurstica esttica que estima la distancia a un estado objetivo (h) y se le suma el valor del nivel actual (g).

    Luego de la verificacin de las condiciones de corte, se realizan dos controles de ciclos: Ciclos en el camino actual de la bsqueda (planSim.isInPath(currentState)).

    En principio no sera necesaria debido a que en algn momento se terminar la bsqueda debido al lmite en la profundidad (y en el caso del juego considerando la profundidad en la que se dan dichos ciclos no es prctica). De todos modos, se agrega por completitud.En este caso se corta la bsqueda y se evita que la evaluacin de dicho estado entre en consideracin al devolver un valor muy grande dado por la constante MAX_F.

    Ciclos a estados ya expandidos (planSim.getVisited(currentState) != 0).Cuando las profundidades de bsqueda son lo suficientemente grandes o bajo ciertas condiciones (como cuando los fantasmas estn asustados) es frecuente llegar a un mismo estado a travs de secuencias de acciones (o caminos de bsqueda) diferentes. Esto se evidencia ms an si no se realiza la poda de acciones que se explica ms adelante.Aqu se tom la decisin de hacer un compromiso entre la memoria utilizada y el costo de procesar partes del espacio de bsqueda ya exploradas. Es as que se incorpor una tabla de transposiciones (transposition table) donde se almacenan los valores heursticos (planSim.setStateValue(.., minF - g)) de los estados ya expandidos por la bsqueda. Cuando se determina que el estado actual ya fue visitado por otro camino, se usa el valor guardado previamente (planSim.getStateValue(..) + g) como una aproximacin a la evaluacin heurstica (mejor que h + g, pero menos precisa que f) que se obtendra al explorar nuevamente dicho estado.

    El resto del proceso consiste en expandir el estado actual, a partir de la generacin y evaluacin (recursiva) de los estados que pueden alcanzarse al ejecutar las acciones (player->perfomAction(...)) y actualizar el juego utilizando el simulador (planSim.update()). Como puede observarse, durante el ciclo de evaluacin de los estados hijo se va seleccionando el menor; de esta forma, al finalizar la expansin se obtendr el mnimo, que es el valor heurstico asociado al estado.

  • Por ltimo, es importante mencionar que se realiza una poda en las acciones (implementada en el mtodo pruneActions), para reducir el espacio de bsqueda. Las acciones que se eliminan (slo para la bsqueda de la planificacin) son la accin que permitira retroceder (esto depende la direccin del Pacman en cada estado) y la posibilidad de detenerse (en las intersecciones del laberinto).Con la poda de acciones se favorece una exploracin ms rpida, en detrimento de la precisin de las evaluaciones obtenidas (debido a que con menos combinaciones de acciones se estn generando muchos menos estados en la frontera de bsqueda). Sin embargo, una consecuencia de la poda es que, en el mismo tiempo, se puede llegar a profundidades mayores por lo que, en general, se est permitiendo obtener evaluaciones mejores (en este juego en particular, es preferible anticipar una secuencia de pasos ms larga que todas las posibles combinaciones de caminos).

    unsigned int PacmanRTAPathfinder::minimin(GameSimulator & planSim, unsigned int depth, unsigned int g)

    {if (planSim.isGameOver()) {

    if (planSim.getGameOverResult() == GameSimulator::WIN) {return g;

    } else {return LOSE_VALUE;

    }} else if (g >= depth) {

    return (*h)(planSim.getGame()) + g;} else {

    const GameState * currentState = planSim.getCurrentState();if (planSim.isInPath(currentState)) {

    return MAX_F;} else {

    unsigned int visitedId = planSim.getVisited(currentState);if (visitedId != 0) {

    return planSim.getStateValue(visitedId) + g;} else {

    LogicObject * player = planSim.getPlayer();list playerActions;player->getActions(playerActions);

    pruneActions(player, playerActions);

    unsigned int minF = MAX_F;list::iterator action = playerActions.begin();while (action != playerActions.end()) {

    if (player->canPerform(*action)) {player->performAction(*action);planSim.update();

    unsigned int f = minimin(planSim, depth, g + 1);if (f < minF) {

    minF = f;}

    planSim.undoUpdate();}action++;

    }

    planSim.addVisited(currentState);planSim.setStateValue(currentState->getId(), minF - g);

    return minF;}

    }}

    }

  • Implementacin de los algoritmos para las funciones de evaluacin heurstica

    Cada uno de los algoritmos deber ser implementado cumpliendo la siguiente interfaz:

    unsigned int h(const Game * game)

    Parmetros: game: permite acceder a los objetos lgicos, el espacio del juego y las variables globales

    necesarias para analizar la configuracin del estado actual del juego.

    En los archivos PacmanHeuristics.h y PacmanHeuristics.cpp, se encuentran definidas las funciones de evaluacin cuya implementacin por defecto deber reemplazarse con los algoritmos propios.

    unsigned int h1(const Game * game){

    return game->getVariables().getInteger(DOT_COUNT);}

    unsigned int h2(const Game * game){

    ...}

    ...

    Para asociar cada opcin del men de seleccin de heurstica con la funcin que implementar dicha heurstica, se utiliza un vector de pares (configurado en el archivo main.cpp) el cual se pasa como parmetro a la funcin runPacman encargada de iniciar la aplicacin. Cada par contendr un puntero a una funcin y un nombre a visualizar en la pantalla (que tambin se utilizar para generar el nombre del archivo de la solucin).De esta forma se puede construir dinmicamente el men de seleccin de heursticas de acuerdo al nmero de funciones implementadas.

    vector heuristics;heuristics.push_back(make_pair(&h1, "Heuristica1"));heuristics.push_back(make_pair(&h2, "Heuristica2"));heuristics.push_back(make_pair(&h3, "Heuristica3"));heuristics.push_back(make_pair(&h4, "Heuristica4"));heuristics.push_back(make_pair(&h5, "Heuristica5"));heuristics.push_back(make_pair(&h6, "Heuristica6"));

    Para que esto funcione correctamente se realiza una definicin de tipos, indicando que una funcin de tipo HeuristicEvaluation ser aquella que cumpla con la interfaz de las funciones h descripta. Es decir, deber retorna un valor unsigned int y recibir por parmetro una referencia constante a un objeto de la clase Game.

    typedef unsigned int (*HeuristicEvaluation)(const Game * game);

  • Requisitos de la entregaFecha y lugar de entrega: Martes 1 de diciembre de 2009, en el Laboratorio 1 del Pabelln de Cs. Exactas de 13hs a 16hs.Fecha y lugar de la defensa: A confirmar. Se publicar en el pgina de la ctedra en una fecha posterior a la entrega del trabajo.

    Importante: Si bien no se va a realizar una primera entrega, se recomienda que dos semanas despus del comienzo del trabajo (semana del 16 y 18 de noviembre) se entregue (o discuta con el ayudante asignado) un borrador que detalle, por lo menos, de que forma van a cumplir con cada uno de los puntos requeridos en el informe.

    Implementacin

    Se deber entregar un proyecto que compile correctamente el cdigo de los algoritmos y permita generar la aplicacin para la prueba de los mismos. As mismo, se solicita la entrega de un ejecutable de ese proyecto.Se debern implementar como mnimo seis funciones de evaluacin heurstica distintas.Se considerarn distintas a dos funciones de evaluacin que utilicen las mismas variables pero con cambios significativos en el peso, factor o relacin entre dichas variables.

    Informe

    Se deber entregar un informe impreso que abarque los siguientes contenidos: Resumen del trabajo realizado, comentando brevemente el contexto del problema, el

    objetivo del trabajo y principalmente las tareas que involucr el desarrollo del mismo. Implementacin

    Cdigo y explicacin breve de cada funcin de evaluacin heurstica y del algoritmo Minimin.

    Explicacin de cualquier decisin de implementacin que considere relevante. Explicacin detallada de las heursticas

    Explicar las hiptesis bajo las cuales se basaron las heursticas implementadas. Explicar los pasos y pruebas que determinaron la forma especfica de cada funcin de

    evaluacin (variables, pesos o factores, combinacin de las mismas, etc). Anlisis y presentacin de resultados

    Cada funcin de evaluacin deber ser probada con, al menos, tres valores distintos de profundidad que se consideren significativos (se deber justificar la eleccin).

    Realizar un anlisis emprico de las funciones de evaluaciones, considerando mtricas como tiempo de planificacin, espacio de bsqueda total, calidad de la solucin y cualquier otro parmetro que considere relevante.

    Presentar de la forma ms clara posible (grficos, tablas, etc) los resultados generales y particulares de cada prueba realizada.

    Realizar una comparacin e interpretacin de los resultados presentados, incluyendo una conclusin en base a las hiptesis en las cuales se basaron las evaluaciones heursticas.

    Incluir una explicacin del comportamiento del Pacman de acuerdo a cada funcin de evaluacin utilizada. Mencionar si este comportamiento justifica o no la hiptesis de la evaluacin heurstica.

    Conclusin Conclusiones extradas del trabajo. Opinin particular y grupal del trabajo prctico especial (metodologa de trabajo, tema,

    contenidos, etc).

    Anlisis y Diseo de Algoritmos II 2009Trabajo Prctico EspecialBsqueda parcialFunciones de evaluacin heursticaModo de juego: ManualModos de simulacinModo de juego: Reproducir la ltima solucinModo de juego: Reproducir archivo de solucinComandos generalesSalida por consolaConstantes del juegoAcceso a los objetos lgicos del juegoVariables globales del juegoAtributos de los personajes del juegoReal-Time A* (RTA*)MiniminImplementacinInforme