Interfaz gráfica y solucionador de puzzles Sokoban con IA, Apuntes de Informática

¡Descarga Interfaz gráfica y solucionador de puzzles Sokoban con IA y más Apuntes en PDF de Informática solo en Docsity! TRABAJO FIN DE GRADO ESTUDIO DE TÉCNICAS DE RESOLUCIÓN PARA EL JUEGO DEL SOKOBAN Autor: Raquel Herráez Jiménez Tutor: Carlos Linares López Leganés, octubre de 2015 Departamento de Ingeniería Informática i iv "Un programador es la persona considerada experta en ser capaz de sacar, después de innumerables tecleos, una serie infinita de respuestas incomprensibles calculadas con precisión micrométrica a partir de vagas asunciones basadas en discutibles cifras tomadas de documentos inconcluyentes y llevados a cabo con instrumentos de escasa precisión, por personas de fiabilidad dudosa y cuestionable mentalidad con el propósito declarado de molestar y confundir al desesperado e indefenso departamento que tuvo la mala fortuna de pedir la información en primer lugar." IEEE Grid Newsmagazine v vi Agradecimientos Durante estos 4 años de carrera han sido muchas las personas que he conocido y me han aportado pequeños y grandes momentos en esta etapa. Ahora que el grado termina, me encuentro echando la vista atrás y recordando todos esos momentos. Compañeros de primero con los que el primer día de clase te perdías en el edificio 1 porque el paso a ras de suelo hasta el edificio 7 estaba cerrado por las obras. Compañeros con los que descubrías todo lo relacionado con la Universidad, con los que recorrías las calles de Leganés o con los que te comprabas algo en la cafetería o el hipermercado. Compañeros que ya habían cursado la asignatura y te aconsejaban y ayudaba. Compañeros nuevos que conocías en segundo porque eran del nuevo turno al que te cambiabas, habían cursado la asignatura el año anterior o porque venían de otra universidad. Compañeros con los que hablabas hasta las cuatro de la mañana porque no lograbais que una parte de la práctica funcionara. Compañeros con los que perdías un poco el contacto porque dejaban la carrera o con los que coincidías menos porque tenían asignaturas pendientes o se quedaron en el otro turno. Compañeros a los que empezabas a conocer más porque te los presentaban otros compañeros y con los que surgía una buena amistad. Compañeros a los que veías menos porque a partir de tercero tenían otra mención de la carrera pero con los que seguías quedando para comer en la cafetería o ir a tomar pizza. Compañeros de primero a los que no has visto en dos años por no tener asignaturas en común y a los que de repente te encuentras en un aula informática y revivís los viejos tiempos. Compañeros con los muchos días pasas hasta doce horas diarias entre clases y prácticas, de 9 a 21, y a los que ves más que a tu propia familia. Compañeros que se van durante un año entero de Erasmus a Bélgica o de Movilidad no Europea a Corea del Sur. Compañeros que vienen de Brasil durante un año y con los que enseguida creas una magnífica relación, sorprendiéndote de la cantidad de aficiones compartidas. Compañeros con los que sólo has hablado un par de veces pero que cuando estáis todos reunidos en el aula 4.0.F18 os ayudáis mutuamente y de forma desinteresada para resolver un problema complejo de una práctica. Todos estos compañeros han sido una parte vital en la carrera. Algunos sólo los conocí por hablar un par de veces y otros se convirtieron en amigos, pero todos son una parte para recordar. Son demasiados nombres para escribirlos, algunos de los cuales no llegué a conocer o se han olvidado con el tiempo, pero hasta el último de ellos se encuentra descrito en los párrafos anteriores. Todos han contribuido a la persona que he sido estos años, y por eso les debo un agradecimiento a estos compañeros. ix Índice 1 Introducción ............................................................................................................. 1 1.1 Motivación ......................................................................................................... 1 1.2 Etapas del Proyecto ........................................................................................... 3 1.3 Glosario de Términos ......................................................................................... 5 1.4 Organización del Documento ............................................................................ 6 2 Estado del Arte ......................................................................................................... 7 2.1 Juego del Sokoban ............................................................................................. 7 2.1.1 Introducción ............................................................................................... 7 2.1.2 Origen ......................................................................................................... 7 2.1.3 Tipos de Casillas .......................................................................................... 8 2.1.4 Reglas .......................................................................................................... 9 2.1.5 Deadlocks .................................................................................................... 9 2.1.6 Modalidades ............................................................................................... 9 2.1.7 Notación XSB para niveles ........................................................................ 11 2.1.8 Notación LURD para soluciones ............................................................... 12 2.1.9 Importancia para la Investigación ............................................................ 13 2.2 Algoritmos de Búsqueda .................................................................................. 15 2.2.1 Búsqueda no Informada ........................................................................... 15 2.2.1.1 Búsqueda en Amplitud o Breadth First Search (BFS) ........................ 16 2.2.1.2 Búsqueda en Profundidad o Depth First Search (DFS) ...................... 16 2.2.1.3 Búsqueda en Profundidad Iterativa o Iterative Deepening Depth First Search (IDDFS) .................................................................................................... 17 2.2.2 Búsqueda Informada ................................................................................ 18 2.2.2.1 A*....................................................................................................... 18 2.2.2.2 IDA* ................................................................................................... 19 3 Objetivos ................................................................................................................. 21 4 Desarrollo ............................................................................................................... 22 4.1 Decisiones Tomadas......................................................................................... 22 4.2 Análisis ............................................................................................................. 24 4.2.1 Casos de Uso ............................................................................................. 24 x 4.2.1.1 Solucionar Niveles ............................................................................. 25 4.2.1.2 Jugar .................................................................................................. 26 4.2.1.3 Mostrar Soluciones ........................................................................... 26 4.2.1.4 Salir .................................................................................................... 28 4.2.2 Requisitos ................................................................................................. 29 4.2.2.1 Requisitos Funcionales ...................................................................... 29 4.2.2.2 Requisitos No Funcionales ................................................................ 35 4.3 Diseño .............................................................................................................. 40 4.3.1 Definición de las Clases ............................................................................ 40 4.3.2 Clases Asociadas a los Casos de Uso ........................................................ 51 5 Pruebas y Resultados .............................................................................................. 52 5.1 Solución Encontrada y Optimalidad ................................................................ 52 5.2 Tiempo de Ejecución y Mejor Solución ............................................................ 53 5.3 Nodos Generados ............................................................................................ 56 5.4 Nodos Expandidos............................................................................................ 58 6 Presupuesto ............................................................................................................ 61 6.1 Presupuesto Inicial ........................................................................................... 61 6.2 Presupuesto Final ............................................................................................. 63 7 Conclusiones ........................................................................................................... 65 8 Líneas Futuras ......................................................................................................... 66 9 Bibliografía .............................................................................................................. 68 10 ANEXOS ................................................................................................................... 69 10.1 ANEXO I: Summary ........................................................................................... 69 10.1.1 Introduction .............................................................................................. 69 10.1.1.1 Motivation ......................................................................................... 69 10.1.1.2 Project Stages .................................................................................... 72 10.1.1.3 Keywords ........................................................................................... 74 10.1.1.4 Document Organization .................................................................... 75 10.1.2 Corpus ....................................................................................................... 76 10.1.2.1 Chosen Decisions ............................................................................... 76 10.1.3 Conclusions ............................................................................................... 78 10.2 ANEXO II: 61 Kids Problems ............................................................................. 79 xi 10.3 ANEXO III: Resultados Completos .................................................................... 90 10.3.1 Amplitud ................................................................................................... 90 10.3.2 Profundidad .............................................................................................. 93 10.3.3 Profundidad Iterativa ............................................................................... 98 10.3.4 A* ............................................................................................................ 101 10.3.5 IDA* ........................................................................................................ 104 10.4 ANEXO IV: Manual de Usuario ....................................................................... 107 10.4.1 Requisitos del Sistema ............................................................................ 109 10.4.2 Ejecución del Software para resolver tableros ....................................... 109 10.4.3 Interfaz de Juego y Visualización de Resultados .................................... 110 10.4.3.1 Jugar ................................................................................................ 111 10.4.3.2 Mostrar Solución ............................................................................. 113 xiv Ilustración 63: Nivel 55 ................................................................................................... 88 Ilustración 64: Nivel 56 ................................................................................................... 88 Ilustración 65: Nivel 57 ................................................................................................... 88 Ilustración 66: Nivel 58 ................................................................................................... 89 Ilustración 67: Nivel 59 ................................................................................................... 89 Ilustración 68: Nivel 60 ................................................................................................... 89 Ilustración 69: Nivel 61 ................................................................................................... 89 Ilustración 70: Símbolo del Sistema en Windows 8 ..................................................... 107 Ilustración 71: Buscar Símbolo del Sistema .................................................................. 108 Ilustración 72: Terminal en Ubuntu .............................................................................. 108 Ilustración 73: Terminal en Debian .............................................................................. 108 Ilustración 74: Navegación por Directorios en CMD .................................................... 109 Ilustración 75: Ejecución de sokoban.py ...................................................................... 110 Ilustración 76: Pasos para Jugar una partida de Sokoban ............................................ 111 Ilustración 77: Pasos para visualizar una secuencia de solución de una instancia ...... 113 xv Índice de Tablas Tabla 1: Ejemplo de Deathlock ......................................................................................... 9 Tabla 2: Notación XSB ..................................................................................................... 11 Tabla 3: Notación LURD .................................................................................................. 12 Tabla 4: Tipos de Búsquedas .......................................................................................... 15 Tabla 5: Pseudocódigo de Amplitud ............................................................................... 16 Tabla 6: Pseudocódigo de Profundidad .......................................................................... 17 Tabla 7: Pseudocódigo de Profundidad Iterativa ........................................................... 18 Tabla 8: Pseudocódigo de A* ......................................................................................... 19 Tabla 9: Pseudocódigo de IDA* ...................................................................................... 20 Tabla 10: Caso de Uso CU-01 .......................................................................................... 25 Tabla 11: Caso de Uso CU-02 .......................................................................................... 26 Tabla 12: Caso de Uso CU-03 .......................................................................................... 26 Tabla 13: Caso de Uso CU-04 .......................................................................................... 26 Tabla 14: Caso de Uso CU-05 .......................................................................................... 27 Tabla 15: Caso de Uso CU-06 .......................................................................................... 27 Tabla 16: Caso de Uso CU-07 .......................................................................................... 28 Tabla 17: Caso de Uso CU-08 .......................................................................................... 28 Tabla 18: Requisito Funcional RF_01 .............................................................................. 29 Tabla 19: Requisito Funcional RF_02 .............................................................................. 30 Tabla 20: Requisito Funcional RF_03 .............................................................................. 30 Tabla 21: Requisito Funcional RF_04 .............................................................................. 31 Tabla 22: Requisito Funcional RF_05 .............................................................................. 31 Tabla 23: Requisito Funcional RF_06 .............................................................................. 32 Tabla 24: Requisito Funcional RF_07 .............................................................................. 32 Tabla 25: Requisito Funcional RF_08 .............................................................................. 33 Tabla 26: Requisito Funcional RF_09 .............................................................................. 33 Tabla 27: Requisito Funcional RF_10 .............................................................................. 34 Tabla 28: Requisito Funcional RF_11 .............................................................................. 34 Tabla 29: Requisito No Funcional RNF_01 ..................................................................... 35 Tabla 30: Requisito No Funcional RNF_02 ..................................................................... 36 xvi Tabla 31: Requisito No Funcional RNF_03 ..................................................................... 36 Tabla 32: Requisito No Funcional RNF_04 ..................................................................... 37 Tabla 33: Requisito No Funcional RNF_05 ..................................................................... 37 Tabla 34: Requisito No Funcional RNF_06 ..................................................................... 38 Tabla 35: Requisito No Funcional RNF_07 ..................................................................... 38 Tabla 36: Requisito No Funcional RNF_08 ..................................................................... 39 Tabla 37: Requisito No Funcional RNF_09 ..................................................................... 39 Tabla 38: Requisito No Funcional RNF_10 ..................................................................... 40 Tabla 39: Clase Sokoban ................................................................................................. 42 Tabla 40: Clase Menú ..................................................................................................... 43 Tabla 41: Clase BusqNoInf .............................................................................................. 44 Tabla 42: Clase Amplitud ................................................................................................ 45 Tabla 43: Clase Profundidad ........................................................................................... 45 Tabla 44: Clase ProfundidadIterativa ............................................................................. 45 Tabla 45: Clase BusqInf ................................................................................................... 46 Tabla 46: Clase AStar ...................................................................................................... 47 Tabla 47: Clase IDAStar ................................................................................................... 47 Tabla 48: Clase Resolucion ............................................................................................. 47 Tabla 49: Clase EstEsc ..................................................................................................... 48 Tabla 50: Clase Estado .................................................................................................... 49 Tabla 51: Funciones del Conjunto de Reglas .................................................................. 50 Tabla 52: Relación entre Casos de Uso y Clases ............................................................. 51 Tabla 53: Número de Problemas Resueltos ................................................................... 52 Tabla 54: Mejor solución para cada nivel en función del tiempo .................................. 54 Tabla 55: Nodos Generados ........................................................................................... 57 Tabla 56: Nodos Expandidos .......................................................................................... 59 Tabla 57: Presupuesto Inicial – Costes Materiales ......................................................... 61 Tabla 58: Presupuesto Inicial – Costes Personales ......................................................... 62 Tabla 59: Presupuesto Inicial – Total .............................................................................. 62 Tabla 60: Presupuesto Final – Costes Materiales ........................................................... 63 Tabla 61: Presupuesto Final – Costes Personales .......................................................... 64 Tabla 62: Presupuesto Final – Total ............................................................................... 64 Página 1 de 114 1 Introducción El Sokoban es uno de los juegos de tableros más interesantes que existe por el gran abanico de posibilidades que ofrece para los estudios. Es por eso que en este proyecto se tratará de estudiar una pequeña parte de todo lo que abarca este juego. En este apartado de Introducción se pretende presentar la motivación para la realización de este proyecto, las diferentes etapas que han tenido lugar a lo largo del mismo y un glosario de términos usados a lo largo de este documento. Se terminará detallando la organización empleada para estructurar la presente memoria. 1.1 Motivación A lo largo de las últimas décadas, la Inteligencia Artificial ha ido ganando una gran cantidad de usos para resolver diversos problemas, tanto en campos de investigación como en la vida cotidiana. Podemos encontrar videojuegos que utilizan Inteligencia Artificial para definir el comportamiento de personajes o realizar el cálculo de óptimo de rutas de movimiento. Encontramos la Inteligencia Artificial también en las predicciones de búsquedas o sugerencias de publicidad al navegar por internet, así como en el análisis de datos. Y en la sociedad actual no nos parece extraño encontrar máquinas que contesten cuando realizamos una llamada telefónica a un servicio técnico. La Inteligencia Artificial o IA, es una rama de la Informática que suele definirse como la ciencia encargada de dotar de inteligencia a las máquinas o como el estudio y diseño de sistemas inteligentes. Esta disciplina se ha convertido en un elemento muy importante en la actualidad, sobre todo en los campos relacionados con la Industria, la Tecnología y los Negocios. Y es que la IA permite resolver algunos de los problemas más difíciles que existen en los campos de la Informática. Uno de estos difíciles problemas es el del juego del Sokoban. Este juego se ha demostrado que pertenece a la clase de complejidad PSPACE-Complete [1], que se cree que es una clase de complejidad aun mayor que la del grupo de problemas NP-Completo, a la que pertenecen algunos problemas sobre otros puzles de tablero como es el caso de la consistencia del Buscaminas [2] o el de la solución con menor número de movimientos en el 15-puzle [3]. El Sokoban es un juego por lo general de un único agente o jugador en el que un personaje puede empujar una serie de bloques por el tablero de juego, pudiendo empujar únicamente una caja cada vez. Existen unas casillas especiales, llamadas metas, donde deben colocarse los bloques para completar el juego. Página 2 de 114 Con esta investigación y desarrollo se pretende implementar distintos algoritmos de búsqueda que sean capaces de encontrar soluciones para este popular juego y analizar cada una de las técnicas empleadas para realizar una comparativa entre ellas. Además, se pretende realizar también una interfaz gráfica para que los usuarios puedan también jugar a los distintos niveles y visualizar las soluciones halladas por los algoritmos de búsqueda. Este juego supone además una motivación a nivel personal, ya que el Sokoban es un juego que conocí durante mi primer año de carrera durante la asignatura de programación, y me sirvió para aprender los contenidos básicos de los lenguajes de programación en general y del lenguaje Java en particular. En aquella práctica final de la asignatura teníamos que implementar el juego en la primera fase como una impresión del tablero por pantalla con algunas funciones y estructuras básicas y en la segunda fase con métodos y clases más avanzados que podían hacer uso de una Interfaz gráfica suministrada por el profesor. En aquel entonces el juego me encantó en todos los sentidos y sentí algo de pena al no poder aprender en esa ocasión como realizar la parte gráfica con un lenguaje de programación. Así que este Trabajo Final de Grado ha supuesto para mí la ocasión perfecta para volver al juego que supuso mi iniciación en la carrera, la oportunidad de incluir la parte gráfica que en aquel entonces me parecía algo muy lejano de realizar, y al mismo tiempo una oportunidad para aprender un nuevo lenguaje de programación. Si en aquel entonces mis conocimientos de Java se debían sólo a pequeñas entregas de la asignatura, en esta ocasión el proyecto me supondrá aprender desde cero el lenguaje Python. Página 3 de 114 1.2 Etapas del Proyecto Antes de empezar a desarrollar la interfaz gráfica y los algoritmos de resolución mencionados en el apartado anterior, es necesario desarrollar el juego de forma básica, es decir, definir los distintos movimientos posibles y reglas que lo componen y asegurarse de que funciona todo correctamente. Después ya se puede proceder a crear una interfaz más vistosa y a implementar los distintos algoritmos de resolución. Las etapas del proyecto han sido las siguientes:  Etapa 1: Definición de Objetivos. Se fijaron los objetivos que querían alcanzarse con la realización del proyecto.  Etapa 2: Investigación sobre Python 2 [4], aprender su funcionamiento básico antes de proceder a trabajar con el lenguaje.  Etapa 3: Definición básica del juego del Sokoban. Se definieron en Python las reglas que permiten jugar a un tablero de Sokoban sencillo escrito en un fichero de texto. El tablero representa cada una de las casillas con un carácter ASCII y lo muestra por línea de comandos, solicitando una letra (W, D, X, A) que representa el movimiento realizado. El programa comprueba si el movimiento puede realizarse, en cuyo caso modifica el tablero siguiendo las reglas y lo muestra por pantalla, o indica que el movimiento no se puede realizar (bien porque la tecla no es correcta o el movimiento no está permitido).  Etapa 4: Búsqueda de los niveles a emplear para el estudio. Se procedió a buscar el conjunto de tableros de Sokoban sobre los que se tratará de encontrar soluciones. Se optó por emplear uno de los conjuntos empleados por Andreas Jughanns en su Tesis Doctoral [5], la colección Kids Problems. Este y otros conjuntos suelen encontrarse con un formato concreto de caracteres ASCII para cada casilla, por lo que se adaptaron las reglas para emplear la notación más extendida. El fichero original, que contenía los 61 tableros en un mismo archivo y con comentarios no necesarios para esta tarea, se limpió y se dividió con un pequeño programa Python en 61 ficheros independientes que serán los que se leerán para trabajar sobre cada uno de los niveles.  Etapa 5: Al realizarse la búsqueda de niveles en la etapa anterior y descubrirse las notaciones empleadas, se decidió seguir profundizando en conocer los nombres de las notaciones y conocer más aspectos sobre el dominio del juego del Sokoban, las noticiones utilizadas, estudios existentes y se desarrolló el Estado del Arte del Documento. También se realizó el apartado de Presupuesto Inicial. Página 6 de 114 1.4 Organización del Documento La estructura del documento será la siguiente: 1. Introducción: En este apartado, en el que nos encontramos actualmente, se da una primera visión del documento, hablando de la motivación tras la realización del trabajo. También se definen las distintas etapas del proyecto, los términos más importantes y la organización que se empleará en el presente documento. 2. Estado del arte: en la segunda sección de la memoria se introducirá la situación relacionada con el entorno del problema que se plantea, hablando del juego así como de distintas técnicas de resolución empleadas en la Inteligencia Artificial. 3. Objetivos: este capítulo expondrá, como su nombre indica, los objetivos que se espera alcanzar mediante la realización del proyecto. 4. Desarrollo: este apartado, que supone el núcleo del trabajo, tratará todos los pasos realizados en este proyecto, hablando de distintas versiones empleadas, modificaciones realizadas y decisiones tomadas. Se hablará de la parte encargada de la resolución de los tableros, así como de la interfaz gráfica del juego. 5. Pruebas y Resultados: en el capítulo de pruebas se comprobarán los distintos algoritmos empleados y se analizarán los resultados obtenidos a partir de los mismos. 6. Presupuesto: está sección recogerá los distintos costes que se derivan de la realización del presente proyecto. 7. Conclusiones: se trata de un apartado en el que se recogerán los datos extraídos de la totalidad del trabajo y se comprobará si se han alcanzado los objetivos previstos. 8. Líneas Futuras: se mencionarán posibles mejoras o modificaciones que podrían realizarse en un futuro a los pasos realizados en este estudio. Para terminar el documento incluirá unos apartados de Anexos y Bibliografía, que contendrán información adicional sobre los contenidos tratados y mostrarán las fuentes de las que se ha obtenido información, respectivamente. Página 7 de 114 2 Estado del Arte Antes de comenzar a desarrollar el proyecto, es necesario comprender las bases del juego del Sokoban, en el que se centra el siguiente trabajo, así como realizar un estudio de la situación en la que se encuentra todo el entorno que está relacionado directa o indirectamente con el tema a tratar. Por tanto, en este capítulo se definirá el juego, se hablará de distintos métodos de búsqueda, y se procederá a explicar otros estudios del mismo ámbito, así como avances logrados o posibles en un futuro. 2.1 Juego del Sokoban EL objetivo de esta sección será la de tratar en profundidad el tema del Sokoban, desde su historia, propiedades de las casillas, reglas, bloqueos y distintas modalidades de juego. Además, se hablará también de las notaciones más empleadas para representación de niveles y soluciones. 2.1.1 Introducción El Sokoban es un popular juego de lógica que consiste en un tablero con distintos tipos de casillas. El jugador debe recorrer el tablero moviendo distintas cajas o piedras hasta unas zonas especialmente diseñadas para este fin. El juego termina cuando todas las cajas están colocadas sobre las metas. 2.1.2 Origen Sokoban, que significa “Guardián del Almacén” en japonés, es un juego creado por Hiroyuki Imabayashi en 1981 y publicado por su compañía, Thinking Rabbit [7] en un pack de 20 niveles lanzado para NEC PC-8801 en el año 1982. A continuación se muestra la distribución del primer nivel de esta colección original lanzada por Thinking Rabbit: Página 8 de 114 Ilustración 1: Nivel de Sokoban 2.1.3 Tipos de Casillas Un nivel de Sokoban está compuesto por un conjunto de casillas de distintos tiempos. Cada una de estas casillas tiene unas propiedades especiales:  Jugador: El encargado del almacén. Puede desplazarse por las casillas libres y por las bases, además de empujar cajas.  Cajas: Son objetos distribuidos por el tablero y que deben llevarse hasta las bases. Las cajas o piedras pueden desplazarse por el tablero cuando el encargado las empuja, pero solo pueden estar sobre casillas vacías o metas.  Metas: son las casillas diseñadas para que se coloquen las cajas sobre ellas. Son caminables por el jugador.  Muros: Definen los límites del tablero y no pueden atravesarse por ningún objeto.  Casillas Vacías: casillas por las que el jugador puede desplazarse con normalidad y empujar cajas. Además, para efectos prácticos y de diseño, cuando un jugador o una caja se encuentran sobre una meta, representan cada uno otro tipo de casilla. Página 11 de 114 2.1.7 Notación XSB para niveles La notación XSB es la más extendida para representar los distintos tableros de Sokoban [9]. Esta notación representa cada casilla del juego con un carácter ASCII. La correspondencia entre caracteres y casillas es la que puede observarse a continuación: Casilla Carácter Jugador @ Jugador sobre meta + Caja $ Caja sobre meta * Meta . Casilla libre ‘ ‘ (espacio) / - / _ Muro # Tabla 2: Notación XSB El carácter empleado desde los inicios del estándar para las casillas vacías ha sido el espacio (‘ ‘), pero debido a que algunos correos o sitios web eliminan varios espacios consecutivos, es común emplear los guiones (- y _) para representar estas casillas. En archivos de texto el carácter más extendido para representar las celdas de suelo vacío sigue siendo el espacio. Página 12 de 114 2.1.8 Notación LURD para soluciones La notación LURD es la más empleada para representar soluciones de tableros de Sokoban. Cada una de las letras indica la dirección en la que se ha movido el jugador, representada por la primera letra del nombre del movimiento en inglés. Además, se distinguen dos tipos de movimientos del jugador en cada dirección: movimiento en el que el jugador se desplaza a una casilla vacía o movimiento en el que el jugador empuja una caja. Los movimientos a una casilla se representan con una letra minúscula, mientras que los movimientos que implican empujar una caja son mostrados con la letra en mayúscula [9]. A continuación se muestra una tabla que recoge todas las representaciones de movimientos: Movimiento Empuja Caja Representación Izquierda No l Sí L Arriba No u Sí U Derecha No r Sí R Abajo No d Sí D Tabla 3: Notación LURD Página 13 de 114 2.1.9 Importancia para la Investigación En 1997 Culberson demostró que el juego del Sokoban es PSPACE-Complete [1]. Esto implica que el juego cumple las características propias de los problemas pertenecientes a esta clase de complejidad computacional. Los problemas PSPACE-Completo son los más difíciles de entre los que se encuentran en la clase PSPACE, ya que encontrar una solución para un problema de la clase PSPACE-Completo supone encontrar una solución para todos los problemas de la clase PSPACE. La clase PSPACE se define como el conjunto de problemas que son decidibles en espacio polinómico por una Máquina de Turing Determinista [10]. Por su parte, los problemas PSPACE-Completo se definen como aquellos problemas que pertenecen a la clase PSPACE y que cumplen que todos los problemas de la clase PSPACE son transformables a ellos en tiempo polinómico. O lo que es lo mismo, los problemas que pertenecen a PSPACE y que se cumple que existe otro problema PSPACE-Completo reducible al problema en cuestión. A continuación se incluye una imagen que muestra la relación entre las clases de complejidades más conocidas. Ilustración 3: Clases de Complejidad Se conoce que en esta relación de clases se cumple que 𝑃 ⊆ 𝑁𝑃 ⊆ 𝑃𝑆𝑃𝐴𝐶𝐸 ⊆ 𝐸𝑋𝑃𝑇𝐼𝑀𝐸 y que además se verifica que 𝑃 ⊊ EXPTIME, por lo que al menos una de las otras relaciones entre los conjuntos es de inclusión propia, es decir, que al menos uno de los pare P-NP, NP-PSPACE o PSPACE-EXPTIME son distintos. De este modo, el problema de saber si P=PSPACE, al igual que ocurre con el famoso problema sobre si P=NP, es un problema matemático no resuelto. Otra relación interesante es la de las clases NP-Completo y PSPACE-Completo, ya que de encontrarse una igualdad entre estas clases, se podrían realizar reducciones entre los problemas de las mismas, algunos de la importancia de SAT (NP-Completo) y Planning (PSPACE-Completo). Página 16 de 114 2.2.1.1 Búsqueda en Amplitud o Breadth First Search (BFS) La Búsqueda en Amplitud es un tipo de búsqueda no informada en la que los nodos del espacio de estados son expandidos por niveles, de izquierda a derecha. Hasta que todos los nodos de un mismo nivel no han sido expandidos, no se procede a expandir el siguiente nivel [12]. Características:  Completitud: encuentra solución si existe y el factor de ramificación es finito.  Optimalidad: es óptimo si el coste de los operadores es el mismo.  Eficiencia: buena para metas cercanas.  Desventajas: alto consumo de memoria. Amplitud (inicial): insertarPrincipio(abierta, inicial) éxito = False Mientras (abierta!=vacia) y no exito: c = extraerPrimero(abierta) si meta(c): exito = True En caso contrario: generarSucesores(c) para cada sucesor n: insertarFinal(abierta,n) Tabla 5: Pseudocódigo de Amplitud 2.2.1.2 Búsqueda en Profundidad o Depth First Search (DFS) En la Búsqueda en Profundidad, los nodos se van expandiendo hasta llegar a la profundidad máxima. Si no se encuentra una solución al llegar a esta profundidad, realiza Backtracking, es decir, vuelve al nodo anterior y escoge el siguiente descendiente de ese nodo para continuar la búsqueda [12]. Página 17 de 114 Características:  Completitud: no se asegura que se encuentren soluciones, porque puede caer en ciclos.  Optimalidad: Al no ser completo, tampoco es óptimo.  Eficiencia: bajo consumo de memoria y mejor para metas alejadas.  Desventajas: funciona mal cuando hay ciclos. Profundidad (inicial): insertarPrincipio(abierta, inicial) exito = False Mientras (abierta!=vacia) y no exito: c = extraerPrimero(abierta) Si meta(c): exito = True En caso contrario: generarSucesores(c) para cada sucesor n: insertarPrincipio(abierta, n) Tabla 6: Pseudocódigo de Profundidad 2.2.1.3 Búsqueda en Profundidad Iterativa o Iterative Deepening Depth First Search (IDDFS) Este tipo de búsqueda utiliza como base la búsqueda en profundidad limitada (Depth Limited Search, DLS), es decir una búsqueda en profundidad que se ejecuta sólo hasta una cierta profundidad. En cada iteración se realiza la búsqueda en profundidad limitada, aumentando en una cantidad la profundidad que se empleará en la siguiente iteración del algoritmo. De este modo, se combinan las ventajas de BFS y DFS [12]. Características:  Completitud: se asegura la completitud.  Optimalidad: es óptimo si el incremento de la profundidad se realiza en intervalos de una unidad.  Eficiencia: tiempo algo mayor al de amplitud.  Desventajas: puede generar muchos estados repetidos. Página 18 de 114 ProfundidadIterativa (inicial): profMax = Incremento exito = False mientras éxito == False: exito = ProfundidadLimitada(inicial, profMax) profMax += Incremento ProfundidadLimitada (inicial, profMax): insertarPrincipio(abierta, inicial) Mientras (abierta!=vacia) y no EXITO: c = extraerPrimero(abierta) Si meta(c): EXITO = True En caso contrario: Si profundidad (c) es menor que profMax: generarSucesores(c) para cada sucesor n: insertarPrincipio(abierta, n) Tabla 7: Pseudocódigo de Profundidad Iterativa 2.2.2 Búsqueda Informada En este tipo de búsqueda se cuenta con cierta información del entorno, que se emplea para que los algoritmos de búsqueda visiten primero los nodos más prometedores. Con esta información que se tiene es posible definir una función heurística que aproxime el coste de llegar desde un estado concreto hasta la meta. Esta heurística suele representarse como h(n), y se calcula para cada nodo del árbol. Por otra parte se definen además las heurísticas admisibles, que son las que nunca sobreestiman el coste real de encontrar la solución. El empleo de una heurística admisible en algoritmos como A* e IDA* garantizará encontrar soluciones óptimas. 2.2.2.1 A* El algoritmo A* es un método de búsqueda informada en el que los nodos sucesores son visitados según el coste de una función calculada para cada estado. Esta función, f(n) se obtiene de la suma de g(n), el coste real hasta ese estado, y h(n), la heurística calculada en ese estado para llegar al nodo meta. De este modo, el algoritmo visitará primero los nodos con menor valor de f(n) por ser los más prometedores [12]. Página 21 de 114 3 Objetivos Entre los objetivos personales que se pretenden alcanzar durante la realización del trabajo, se encuentran el de conocer un lenguaje de programación nuevo y profundizar en él, siendo Python el lenguaje escogido finalmente en este caso. Durante una de las asignaturas del curso se propuso una práctica opcional en Python, un lenguaje que no empleado antes durante el curso, y tras buscar la información básica necesaria para la práctica opcional, decidí aprender más sobre este lenguaje. Por otra parte, durante la carrera se trata poco la visualización de elementos gráficos al programar en algún lenguaje, así que con este proyecto se pretende también adquirir conocimientos para mostrar interfaces y elementos gráficos escritos en el lenguaje Python. Como objetivos específicos que se pretenden alcanzar en el transcurso del proyecto, se encuentran los siguientes:  Elaboración de un juego de Sokoban en el lenguaje de programación Python.  Implementación de distintas técnicas de inteligencia artificial que sean capaces de resolver diferentes tableros del juego.  Medir la calidad e idoneidad de cada una de las técnicas empleadas, en bases a distintos parámetros medidos, como son: o Capacidad o no de solucionar cada uno de los distintos tableros o Número de pasos del jugador o Movimientos de cajas empleados o Tiempo empleado para encontrar la solución o Nodos generados/expandidos durante la búsqueda o Utilización de espacio en memoria o Optimalidad o no de las soluciones o Etc.  Obtención de soluciones que consistan en una serie de pasos para llegar desde el estado inicial del problema a un estado meta.  Desarrollo de una interfaz gráfica en Python que permita jugar partidas o mostrar las soluciones encontradas. Página 22 de 114 4 Desarrollo 4.1 Decisiones Tomadas A la hora de implementar los distintos algoritmos, la primera decisión que había que tomar era el lenguaje de programación a utilizar. Se optó por emplear Python, por ser un lenguaje que no se emplea en ninguna práctica obligatoria de la carrera y del que yo no tenía conocimientos. El lenguaje llamó mi atención cuando en una asignatura del grado se propusieron varias prácticas optativas, una de las cuales utilizaba Python de forma sencilla. Por aquel entonces ya estaba planeando el lenguaje a emplear en el proyecto, teniendo como principales candidatos los lenguajes C++ (del que tengo conocimientos básicos) y Python (del que no conocía nada). Aproveché la ocasión para conocer el lenguaje y me gustó bastante, así que me decidí por él. Dentro de Python había otra decisión que tomar, y era la de emplear Python 2 o Python 3. Tras investigar un poco se optó por Python 2, ya que es la versión más documentada y extendida, aunque Python 3 cada vez gana más fuerza y está también bastante extendido. Por otra parte, se decidió emplear la librería Numpy para facilitar la lectura de datos de fichero con un determinado formato y para trabajar fácilmente con ellos en una matriz bidimensional que represente el tablero de juego. La siguiente decisión era elegir el método para desarrollar la interfaz gráfica del juego, optándose por emplear Pygame. Este conjunto de módulos para Python está basado en la librería SDL y permite crear juegos y programas multimedia [6]. A la hora de ejecutar los distintos algoritmos, como puede que algunos no encuentren soluciones o tarden un tiempo demasiado elevado, se ha optado por fijar un tiempo máximo de ejecución para cada uno de ellos de 30 minutos. Respecto a los algoritmos de búsqueda empleados para la búsqueda de soluciones en los distintos tableros de juegos, se han utilizado principalmente los métodos de búsqueda en Amplitud, Profundidad, Profundidad Iterativa, A* e IDA*. En estos algoritmos se han realizado distintos tipos de mejoras para reducir los tiempos de búsqueda y poder así el éxito en la búsqueda de soluciones. En los algoritmos de Amplitud y Profundidad, para evitar la generación de estados repetidos que pueden crear bucles (en especial en el caso de la búsqueda en Profundidad, que estos bucles lo hacen no completo) se creó una lista en la que se almacenan los estados generados. De este modo sólo se consideran los nuevos y se evita caer en ciclos. Página 23 de 114 Por otra parte se ha definido una función que encuentra un gran número de Deadlocks, evitándose de este modo expandir nodos que jamás llegarán a una solución. En concreto, esta función comprueba si hay piedras con muros en dos lados contiguos (en una esquina) o si se da el caso de que dos o más cajas estén contiguas en una pared. Estas modificaciones consiguieron mejorar en una gran cantidad el éxito en la búsqueda de soluciones y se redujo en una magnitud elevada los tiempos para encontrar soluciones. Con las mejora de lista de nodos generados se pasó en algunos casos (Test 24) de no encontrar soluciones con amplitud y profundidad para tiempos de 10 minutos a encontrar soluciones en 64 y 15 segundos, respectivamente. Además, al emplearse la detección de Deadlocks se pasó a encontrar un mayor número de soluciones con todos los métodos (profundidad Iterativa en Test 24 no hallaba solución en 10 minutos, pasa a encontrar una en algo más de 5) y a reducir los tiempos de los que ya las encontraban, pasando a ser de media unas 6 veces menor (Test 24: A* pasa de 39 a 7 segundos e IDA* pasa de 182 a 30. Amplitud y Profundidad pasan a 18 y 2 segundos, respectivamente). Para los algoritmos de Búsqueda Informada se ha considerado una Heurística que calcula la distancia de cada piedra a la base más próxima, las suma y añade la distancia del jugador a la caja más alejada. También se considera si el tablero se encuentra en situación de Deadlock, sumando en ese caso un valor de 1000000 o 0 en caso contrario. Esta Heurística es admisible ya que nunca sobrestima el coste para llegar a la meta desde un estado concreto:  En el caso de las distancias a las bases, en el mejor de los casos los bloques acabarán en las bases a las que se les calculó la distancia, resultando el coste igual al esperado. En el resto de casos, acabarán alguna en otra base, que tendrá un coste igual o mayor al calculado, por lo que la heurística tendrá siempre un valor menor.  Si consideramos la distancia del jugador a la piedra más alejada, para poder resolver el tablero, el jugador tiene que llevar todas las piedras a las bases, por lo que más tarde o más temprano el jugador deberá dirigirse a la piedra más alejada para moverla, por lo que esta parte también es admisible.  Por último, la condición añadida para los Deadlock también es admisible, ya que si no hay Deadlock no añade ningún coste adicional al calculado, por lo que sigue siendo admisible, y si hay Deadlock la solución nunca será alcanzada (se puede considerar coste infinito) por lo que al añadir 1000000 sigue siendo menor que el coste real. Se pretendía que la parte de búsqueda de soluciones fuera llamada desde la propia interfaz gráfica, pero el funcionamiento de la misma se entorpecía mucho al pasar demasiado tiempo sin llamar al bucle de juego mientras los algoritmos buscaban soluciones. Página 26 de 114 4.2.1.2 Jugar Identificador CU-02 Nombre Seleccionar Jugar Actores El usuario que tras ejecutar la aplicación decide que desea jugar una partida de Sokoban. Objetivos El usuario selecciona y acepta la opción de “Jugar” en el menú. Precondiciones --- Postcondiciones Se ofrece una lista de niveles posibles para jugar. Tabla 11: Caso de Uso CU-02 Identificador CU-03 Nombre Escoger Nivel para Jugar. Actores La persona que quiere escoger el nivel para jugar. Objetivos El usuario selecciona el número de nivel deseado para jugar. Precondiciones El usuario debe haber seleccionado en la pantalla anterior la opción de jugar. Postcondiciones Se visualiza el tablero del nivel escogido. Tabla 12: Caso de Uso CU-03 4.2.1.3 Mostrar Soluciones Identificador CU-04 Nombre Seleccionar Mostrar Solución Actores La persona que está usando el sistema y decide visualizar la soluciones de niveles de Sokoban. Objetivos El usuario selecciona y acepta la opción de “Mostrar Solución” en el menú. Precondiciones --- Postcondiciones Se ofrece una lista de niveles posibles para visualizar. Tabla 13: Caso de Uso CU-04 Página 27 de 114 Identificador CU-05 Nombre Escoger Nivel para Mostrar Solución Actores La persona que quiere escoger el nivel del cual mostrar una solución. Objetivos El usuario selecciona el número de nivel del que se mostrarán soluciones. Precondiciones El usuario debe haber seleccionado en la pantalla anterior la opción de “Mostrar Solución”. Postcondiciones Se visualiza mostrará la elección del algoritmo de búsqueda. Tabla 14: Caso de Uso CU-05 Identificador CU-06 Nombre Escoger Algoritmo Actores Usuario que desea visualizar la solución hallada por un algoritmo concreto para el nivel escogido. Objetivos El usuario selecciona uno de los algoritmos de búsqueda disponibles en el menú. Precondiciones El usuario debe haber seleccionado en la pantalla anterior la el nivel a emplear. Postcondiciones Se visualiza el tablero del nivel escogido con la secuencia de movimientos para resolverlo. Tabla 15: Caso de Uso CU-06 Página 28 de 114 Identificador CU-07 Nombre Volver a Selección de Nivel Actores Usuario que desea elegir otro nivel distinto para visualizar su solución. Objetivos El usuario selecciona la opción de “Volver” en el menú de selección de Algoritmos. Precondiciones El usuario se encuentra en la pantalla de selección del Algoritmo para mostrar la solución. Postcondiciones Se muestra el menú de selección del nivel para mostrar. Tabla 16: Caso de Uso CU-07 4.2.1.4 Salir Identificador CU-08 Nombre Seleccionar Salir Actores Una persona que decide abandonar la interfaz gráfica del programa. Objetivos El usuario selecciona y acepta la opción de “Salir” en el menú o cierra la ventana del programa. Precondiciones --- Postcondiciones Se finaliza el programa. Tabla 17: Caso de Uso CU-08 Página 31 de 114 Id RF_04 Prioridad  Alta  Media  Baja Necesidad  Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción Los usuarios del programa tendrán la posibilidad de visualizar soluciones generadas. Tabla 21: Requisito Funcional RF_04 Id RF_05 Prioridad  Alta  Media  Baja Necesidad  Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción Se podrá salir del programa en cualquier momento. Tabla 22: Requisito Funcional RF_05 Página 32 de 114 Id RF_06 Prioridad  Alta  Media  Baja Necesidad Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción En los menús habrá una opción para salir del programa. Tabla 23: Requisito Funcional RF_06 Id RF_07 Prioridad  Alta  Media  Baja Necesidad  Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción Los usuarios podrán escoger el nivel sobre el que jugar. Tabla 24: Requisito Funcional RF_07 Página 33 de 114 Id RF_08 Prioridad  Alta  Media  Baja Necesidad  Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción Se podrá seleccionar el nivel para mostrar sus soluciones. Tabla 25: Requisito Funcional RF_08 Id RF_09 Prioridad  Alta  Media  Baja Necesidad  Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción Se podrá seleccionar la solución a mostrar de las encontradas por los algoritmos. Tabla 26: Requisito Funcional RF_09 Página 36 de 114 Id RNF_02 Prioridad  Alta  Media  Baja Necesidad  Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción Si no se encuentra una solución, se fijará el valor a “None”. Tabla 30: Requisito No Funcional RNF_02 Id RNF_03 Prioridad  Alta  Media  Baja Necesidad  Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción Se podrá definir el tiempo máximo de ejecución de los algoritmos. Tabla 31: Requisito No Funcional RNF_03 Página 37 de 114 Id RNF_04 Prioridad  Alta  Media  Baja Necesidad  Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción El tiempo de respuesta de la interfaz no será superior a 1 segundo. Tabla 32: Requisito No Funcional RNF_04 Id RNF_05 Prioridad  Alta  Media  Baja Necesidad  Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción Para poder visualizar las soluciones de los tableros debe haberse ejecutado la búsqueda de soluciones primero. Tabla 33: Requisito No Funcional RNF_05 Página 38 de 114 Id RNF_06 Prioridad  Alta  Media  Baja Necesidad  Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción Para cada nivel a solucionar se generará un txt detallado con los resultados de los distintos algoritmos. Tabla 34: Requisito No Funcional RNF_06 Id RNF_07 Prioridad  Alta  Media  Baja Necesidad  Esencial  Deseable  Opcional Fuente  Cliente  Desarrollador. Descripción Se generará un fichero con el resumen de soluciones encontradas para cada nivel y de número de niveles resueltos con cada método. Tabla 35: Requisito No Funcional RNF_07 Menu casino dimX:int dimY:int opciones:slring [] seleccionado: string nweles:int 11 nivelzint metodos:string [] busqueda: string solucion:string [] screen:Surface TepresentariNicio() representarJUGAR() representarSELECCION(tipo :int) representarMETODO() representarMOSTRAR() update() tiene 1. Sokoban casila sine width: int height:int timerfioat pasos:int cajas_movidas: Int cerrado: boolean victoria: boolean anchura: int altura:int screen:Surtace cargarGraficos() drawBoard(tahlera:numpy.array) update(tablerc:numpy.array) partidacanada() 7 Utiliza 1 +] Comurto de 7 pegas = Utiliza = = 1 SN Buin CBERumpyamay Estado Pis aÑaTa solucion:Estado mstancia: numpyamay Mc mumpy.array pasos:int movimientoOrigen:char solucion: cajas_movkas nt padre:Estado [] TN tiempo: float pasostint cajes- movidas in generadas: nt Tiene cajas_movdas mt ¿Micne ttempo:float expandkdos sine 1 US profundidad: int AS generados :Int ruta:char (] fine o mexTime:float : ' ganerarSucesores (estado: Estado) A generarfuta(lita: Estado [] ) o calcularHeuristica(estado:Estado) 9 salta: = Az 1 Tiene ResoidOn tiene So contenidos :EstEsc 1] Y a insertando: FstFse L 1 [| auscartablero:mumpy.array, tpo:strng tempor |" resolver() 7 Tiene 10 E mumeroInE soluciones: strin Atar IDAStEr al OUNAE RETA 3 e buscar(] cajas: 1] O busca Eo dis(heuris Uca: nl) pasos:int ([] asada EU 550 generadas:int 1] AAA expandulosint () Ilustración 5: Diagrama de Clases Página 41 de 114 Página 42 de 114 A continuación se procederá a describir en detalle cada una de las clases. Se comentarán también las funciones que se incluyen en “Conjunto de Reglas”. Nombre Sokoban Responsabilidades Genera la representación gráfica y mecánica que permite jugar con un nivel de juego. Atributos  casilla: atributo de tipo entero que refleja el tamaño del lado de la casilla en pixeles.  width: atributo entero que representa la longitud del tablero en píxeles.  height: altura en pixeles del nivel de Sokoban  time:variable auxiliar, mide el tiempo al comienzo de la partida en segundos y se utiliza para obtener el tiempo de ejecución al restar los tiempos medidos en distintos intervalos. Es un decimal.  pasos: entero que refleja los pasos del jugador.  cajas_movidas: entero para representar el número de empujones de cajas.  cerrado: variable booleana para saber si se ha cerrado la ventana y saber cuándo parar el bucle de juego.  victoria: estado booleano para saber si se ha Ganado la partida o no.  anchura: ancho de la ventana de juego en píxeles  altura: entero que recoge el alto de ventana en píxeles  screen: objeto de tipo Surface de Pygame que representa la salida a dibujar por pantalla. Operaciones  cargarGraficos(): asigna los ficheros de imágenes a las variables que los emplearán.  drawBoard(tablero: numpy.array): recibe un tablero de Sokoban y la dibuja en pantalla.  update(tablero: numpy.array): es la función principal del juego que se ejecuta en un bucle para actualizar en cada instante la pantalla. Actualiza el rompecabezas según los eventos ocurridos (teclas) y llama a drawboard(). Comprueba si se ha completado la partida o se ha cerrado la ventana.  partidaGanada(): función que es llamada cuando el tablero está resuelto. Muestra un mensaje indicando la victoria. Tabla 39: Clase Sokoban Página 43 de 114 Nombre Menu Responsabilidades Es la clase encargada de generar el menú de la Interfaz Gráfica. Atributos  casilla: atributo de tipo entero que refleja el tamaño del lado de la casilla en pixeles.  dimX: atributo entero que representa la longitud de la ventana en casillas.  dimY: altura en casillas de la ventana.  anchura: ancho de la ventana de juego en píxeles  altura: el alto de ventana en píxeles.  estado: entero que representa el menú actual de la interfaz.  opciones: array de strings con las opciones del primer menú.  seleccionado: opción que se muestra resaltada en el primer menú.  niveles: array de enteros que representa los distintos niveles en el menú de selección de nivel.  nivel: entero que indica el valor resaltado en la selección de niveles.  metodos: array de strings con los algoritmos de búsqueda del menú de selección de algoritmo.  busqueda: string del algoritmo seleccionado.  solucion: array de strings con las soluciones de los distintos métodos para el nivel seleccionado.  screen: objeto de tipo Surface de Pygame que representa la salida a dibujar por pantalla. Operaciones  representarINICIO(): carga el menú de inicio.  representarJUGAR(): utiliza la clase Sokoban para gestionar el modo de juego a una partida.  representarSELECCION(tipo:int): muestra la pantalla de selección de nivel. El parámetro indica si es nivel para jugar o para resolver.  representarMETODO(): gestiona el menú de selección del algoritmo de búsqueda.  representarMOSTRAR(): función encargada de emplear la clase Sokoban y pasarle los eventos de tecla según las solución del algoritmo.  update(): es la función principal del menú que se ejecuta en un bucle para actualizar en cada instante la pantalla. Comprueba el estado actual para llamar a la función correspondiente. Tabla 40: Clase Menú Página 46 de 114 Nombre BusqInf Responsabilidades Clase de la que heredan los algoritmos de búsqueda informada. Contiene los atributos y funciones comunes a todos ellos. Atributos  inicial: tablero de tipo numpy.array que representa el estado inicial de juego sobre el que se realizará la búsqueda.  solucion: instancia de la clase Estado que representa el estado solución.  pasos: entero que refleja los pasos del jugador del al resolverse el juego.  cajas_movidas: entero para representar el número de empujones de cajas de la solución.  tiempo: variable auxiliar, mide el tiempo al comienzo de la partida en segundos y se utiliza para obtener el tiempo de ejecución al restar los tiempos medidos en distintos intervalos. Es un número decimal.  generados: número de nodos generados durante la búsqueda.  expandidos: entero que representa el número de nodos expandidos durante el algoritmo.  ruta: array de caracteres donde cada uno de ellos representa un movimiento de la solución.  maxTime: el máximo tiempo que ejecutará el algoritmo. Operaciones  generarSucesores(estado: Estado): función que recibe un estado y con ayuda de las funciones de las reglas de juego calcula los estados alcanzables en un paso desde ese estado.  generarRuta(lista:Estado[]): recibe un array de objetos Estado y genera el array de caracteres de la solución que genera esa ruta.  calcularHeuristica(estado:Estado): calcula la heurística del estado recibido. Tabla 45: Clase BusqInf Página 47 de 114 Nombre AStar Responsabilidades Clase que representa un algoritmo de Búsqueda en A*. Hereda de la clase BusqInf. Atributos  Los mismos que la clase BusqInf. Operaciones  Las mismas que la clase BusqInf.  buscar(): ejecuta el algoritmo de Búsqueda en A*. Tabla 46: Clase AStar Nombre IDAStar Responsabilidades Clase que representa un algoritmo de Búsqueda en IDA*. Hereda de la clase BusqInf. Atributos  Los mismos que la clase BusqInf. Operaciones  Las mismas que la clase BusqInf.  buscar(): ejecuta el algoritmo de Búsqueda en IDA*.  dls(profundidad:int): ejecuta una búsqueda en profundidad limitada. Tabla 47: Clase IDAStar Nombre Resolucion Responsabilidades Clase que invoca los algoritmos de Búsqueda sobre el conjunto de niveles. Atributos  contenidos: array de EstEsc que almacena las distintas líneas de datos para escribir en el fichero datos.txt.  insertando: EstEsc en el que se están almacenando los resultados de las búsquedas para el nivel actual. Operaciones  buscar(tablero: numpy.array, tipo: string, tiempo: int): invoca el algoritmo tipo sobre tablero con tiempo máximo tiempo.  resolver(): para cada instancia en la carpeta “levels” invoca buscar() con cada algoritmo. Tabla 48: Clase Resolucion Página 48 de 114 Nombre EstEsc Responsabilidades Clase utilizada para almacenar la información relativa a los datos de ejecución de los algoritmos sobre un nivel. Atributos  numero: número del nivel al que corresponde la información.  soluciones: array de strings con las correspondientes soluciones halladas para ese nivel.  tiempos: array con los tiempos de los algoritmos.  cajas: array de int para almacenar las cajas movidas por los distintos algoritmos.  pasos: array del número de pasos dados por el jugador hasta llegar a ese estado desde el inicial. Una posición por cada uno de los algoritmos.  generados: array del número de nodos generados por los algoritmos.  expandidos: array de nodos expandidos por los algoritmos. Operaciones  No tiene. Tabla 49: Clase EstEsc Página 51 de 114 4.3.2 Clases Asociadas a los Casos de Uso En esta sección se relacionarán los casos de uso definidos en el capítulo Casos de Uso con las clases identificadas en el apartado Definición de las Clases. Las funciones de “Conjunto de Reglas” son utilizadas en todos los Casos de Uso excepto CU-08 Caso de Uso Clases que intervienen CU-01  Resolucion  EstEsc  BusqInf  AStar  IDAstar  BusqNoInf  Amplitud  Profundidad  ProfundidadIterativa  Estado CU-02  Menu  Sokoban CU-03  Menu  Sokoban CU-04  Menu  Sokoban CU-05  Menu  Sokoban CU-06  Menu  Sokoban CU-07  Menu  Sokoban CU-08  Menu  Sokoban Tabla 52: Relación entre Casos de Uso y Clases Página 52 de 114 5 Pruebas y Resultados A continuación de procederá a analizar los resultados obtenidos con los distintos algoritmos y se compararán las soluciones según las siguientes características:  Solución encontrada o no  Optimalidad  Tiempo de ejecución  Nodos Expandidos y Generados  Uso de Memoria En el ANEXO III: Resultados se encuentran todos los datos obtenidos de las distintas ejecuciones de los algoritmos. En este apartado se procederá a analizar dichos resultados. 5.1 Solución Encontrada y Optimalidad En primer lugar se analizará el número de problemas que se ha logrado resolver con cada una de las técnicas empleadas así como el número de problemas para los que se ha alcanzado una solución con alguna de los algoritmos del estudio. Problemas Resueltos Amplitud 51/61 Profundidad 53/61 Profundidad Iterativa 35/61 A* 52/61 IDA* 41/61 Total Resueltos 55/61 Tabla 53: Número de Problemas Resueltos Así, como puede observarse en la Tabla 2, hay un total de 6 problemas para los que no se ha hallado ninguna solución. Estos conjuntos de Test son las instancias 51, 52, 55, 57, 58 y 61. La lista completa de los problemas con su representación pueda encontrarse en el ANEXO II: 61 Kids Problems. Página 53 de 114 Por otra parte, puede verse que el método que más soluciones ha encontrado es la búsqueda en profundidad. Este algoritmo apenas encontraba soluciones antes de aplicar la mejora mencionada en el Decisiones Tomadas, consiguiéndose una gran mejora en la probabilidad de encontrar soluciones. Sin embargo, aunque este método encuentra un gran número de soluciones, en algunos casos en tiempos muy bajos, no puede asegurarse que estas soluciones sean óptimas, por lo que en caso de haberse encontrado la solución con otro método que asegura optimalidad, se preferirá dicha solución. De los problemas resueltos por el Algoritmo de Búsqueda en Profundidad, hay un total de 3 problemas que no has sido resueltos por ningún otro algoritmo: 1, 50 y 59. 5.2 Tiempo de Ejecución y Mejor Solución En vista de los resultados anteriores, se han analizado con Excel los resultados, creando una función que busca para cada problema el algoritmo que encuentra solución en un menor tiempo, de entre los que aseguran que se encuentra una solución óptima, y en caso de no encontrarse solución entre estos algoritmos, el mejor será el de profundidad, si ha encontrado una solución. La siguiente tabla refleja los resultados de este análisis: Amplitud Profundidad Profundidad Iterativa A* IDA* Mejor Solución 1 None 112.3095299 None None None Profundidad 2 0.863171559 0.436729747 28.74760294 0.640660255 6.383325092 A* 3 18.79831147 3.53422438 9.408098346 0.809477594 0.501524177 IDA* 4 2.138465127 1.176407786 5.253758119 0.393853776 0.543395429 A* 5 17.04847476 8.048066447 626.8593114 4.008276446 11.98368991 A* 6 0.557234418 0.550037241 4.441087175 0.526635985 1.337081364 A* 7 3.418728939 1.229099084 15.57166844 1.374596557 3.155372987 A* 8 285.7781213 136.8900028 None 35.97795843 605.6267748 A* 9 2.568935388 16.99686273 3.900334519 0.347841907 0.561499513 A* 10 34.643381 3.400090007 667.1194829 15.7543747 105.4315372 A* 11 11.99543876 16.68756399 51.07917305 2.597830793 4.499110527 A* 12 10.74599498 18.26070702 65.93348544 2.875217923 14.36945464 A* 13 1.507203675 0.190395876 9.252064666 1.121910867 3.092724784 A* 14 1.142136556 0.553274363 32.87167097 1.195597295 19.17239096 Amplitud 15 25.53950377 8.196494633 158.4099635 6.751073284 19.33427923 A* 16 60.81368455 63.67956523 None 44.98288012 None A* 17 6.780900225 2.709171254 171.9417373 4.166550054 64.49574551 A* 18 None None None 319.8914213 519.9634704 A* 19 202.0855481 32.21772504 None 21.59357459 81.33361922 A* 20 1769.723384 1782.276134 None 1139.248365 None A* 21 26.23239092 11.34940609 272.3941171 12.00706928 27.65959944 A* 22 8.481752629 13.75600865 None 7.697919638 943.6302855 A* 23 22.84414825 9.52830892 299.4279711 6.915928517 29.27268362 A* 24 18.36280736 2.822628533 351.1528581 7.548715171 30.64599641 A* Página 56 de 114 5.3 Nodos Generados En la siguiente tabla y gráfico se recoge la cantidad de nodos generados y expandidos. En el caso del gráfico, el eje Y tiene un escalado logarítmico para apreciar mejor los datos, ya que la diferencia entre magnitudes es muy grande en algunos casos. Nivel Amplitud Profundidad Profundidad Iterativa A* IDA* 1 5529 649 252193 7461 256944 2 75 52 4880 88 1387 3 564 162 2658 125 205 4 163 105 1403 79 222 5 483 275 88482 297 2650 6 58 58 716 68 285 7 197 86 2612 130 794 8 2009 1173 351075 1013 87794 9 190 353 1066 67 197 10 715 125 77321 609 15661 11 432 348 10504 236 1311 12 397 365 11111 240 2902 13 125 32 1964 137 923 14 96 55 4387 119 3051 15 627 223 27886 400 4342 16 882 767 206853 950 210252 17 303 128 24146 281 10635 18 5490 4120 260371 3280 84447 19 1779 621 210943 737 10163 20 4965 4195 242303 5935 241381 21 603 364 34011 551 5014 22 328 334 233009 397 113875 23 581 277 43458 412 5846 24 514 143 46728 425 5900 25 20 25 104 23 70 26 397 245 186003 480 36531 27 52 52 183 44 82 28 766 381 251566 615 19723 29 675 210 216795 863 240575 30 968 239 29556 600 6862 31 1015 201 166848 1151 53826 32 139 32 815 96 246 33 716 204 126786 327 5015 34 733 657 189298 701 20720 35 688 196 169464 783 155242 36 265 120 9193 243 2037 37 916 810 218386 1032 213678 Página 57 de 114 38 580 256 160038 581 16911 39 327 383 65810 248 28066 40 573 495 110149 608 13005 41 213 127 40201 263 11874 42 304 133 25860 342 5544 43 1340 614 178680 1136 183913 44 651 445 100140 514 8365 45 449 238 73174 471 18807 46 325 178 134771 356 151069 47 606 349 10410 208 1282 48 399 94 3790 208 1074 49 3758 4551 268084 2070 79160 50 6616 283 420458 7969 250885 51 5473 4221 259786 7149 203526 52 6449 2989 285281 7928 221328 53 234 120 43415 263 16399 54 2004 1472 106128 2210 122343 55 5408 3591 261511 7214 249573 56 3422 2997 177544 2954 199021 57 6074 4747 418998 7643 291121 58 6117 4821 398207 7590 278805 59 5987 977 286524 7436 237634 60 2040 1083 288985 2242 206392 61 5925 4341 304369 7328 213535 Tabla 55: Nodos Generados Ilustración 7: Nodos Generados 10 100 1000 10000 100000 1000000 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 Nodos Generados G_Amp G_Pro G_PIt G_ASt G_IDA Página 58 de 114 En este caso se distingue con bastante claridad que el algoritmo que menos nodos genera es el de búsqueda en profundidad. Esto es debido en una gran parte a la mejora de la lista de nodos generados que evita que se generen nodos repetidos, evitado así los bucles. Tras este algoritmo se encuentra A*, con una diferencia mínima respecto al algoritmo de Primero en Amplitud. Profundidad Iterativa e IDA* son los que más nodos generan, lo cual es comprensible si se tiene en cuenta que en cada nueva iteración vuelve a generar el árbol. 5.4 Nodos Expandidos Al igual que en el caso anterior, ahora se muestran los nodos expandidos por los métodos de búsqueda. Nivel Amplitud Profundidad Profundidad Iterativa A* IDA* 1 4873 550 154169 4492 133111 2 73 43 3588 54 871 3 470 153 1567 65 100 4 144 95 911 43 121 5 445 258 56920 164 1459 6 53 52 556 45 183 7 175 79 2139 77 468 8 1890 1101 213229 537 48982 9 153 333 659 39 107 10 661 95 53731 400 9700 11 375 339 6902 146 737 12 349 352 7315 148 1720 13 118 26 1580 89 553 14 91 47 3914 87 2286 15 571 202 18292 256 2524 16 852 724 157080 666 148091 17 282 116 18739 203 7369 18 5028 3961 162355 1912 44747 19 1673 602 132988 425 5778 20 4922 4087 156469 3775 141144 21 577 347 24871 340 3016 22 320 322 177043 286 79173 23 547 248 29857 254 3384 24 484 117 33373 266 3503 25 18 24 92 14 39 26 389 219 138680 323 23440 27 44 49 130 23 39 28 704 360 173015 369 11593 29 667 174 151466 584 142469 Página 61 de 114 6 Presupuesto 6.1 Presupuesto Inicial Recurso Precio Tiempo de vida Tiempo uso en proyecto Precio en el proyecto Portátil Lenovo G505 489€ 60 meses 9 meses 73,35€ Microsoft Windows 8.1 106,10€ 60 meses 9 meses 15,92€ Microsoft Office Proffesional Plus 2013 539€ 60 meses 9 meses 80,85€ USB Toshiba 16GB 8€ 60 meses 9 meses 1,20€ Notepad++ 0€ - 9 meses 0€ Python 2.7.9 0€ - 9 meses 0€ NumPy 1.9.1 0€ - 9 meses 0€ Pygame 1.9.2a0 0€ - 9 meses 0€ TOTAL 171,32€ Tabla 57: Presupuesto Inicial – Costes Materiales Página 62 de 114 Rol Coste/Hora Horas Totales Coste Total Jefe de Proyecto 49€/h 16h 784€ Analista / Programador 32€/h 280h 8690€ TOTAL 9474€ Tabla 58: Presupuesto Inicial – Costes Personales Tipo Coste Total Costes Materiales 171,32€ Costes Personales 9474€ TOTAL 9645,32€ Tabla 59: Presupuesto Inicial – Total Por tanto el presupuesto esperado inicialmente es de 9645,32€. Página 63 de 114 6.2 Presupuesto Final Recurso Precio Tiempo Amortización Tiempo uso en proyecto Precio en el proyecto Portátil Lenovo G505 489€ 60 meses 9 meses 73,35€ Microsoft Windows 8.1 106,10€ 60 meses 9 meses 15,92€ Microsoft Office Proffesional Plus 2013 539€ 60 meses 9 meses 80,85€ USB Toshiba 16GB* 8€ 60 meses 7,5 meses 8€ USB Lexar 32GB 12,99€ 60 meses 1,5 meses 0,32€ Notepad++ 0€ - 9 meses 0€ Python 2.7.9 0€ - 9 meses 0€ NumPy 1.9.1 0€ - 9 meses 0€ Pygame 1.9.2a0 0€ - 9 meses 0€ TOTAL 178,44€ Tabla 60: Presupuesto Final – Costes Materiales *El USB Toshiba, con un tiempo de vida estimado en 5 años, dejó de funcionar a los 7,5 meses del comienzo del proyecto, por lo que no llegó a amortizarse y supuso el coste íntegro en el periodo del desarrollo. Además, tuvo que ser reemplazado por otra memoria, cubriéndose en este caso únicamente la parte proporcional a su tiempo de uso en el proyecto. Página 66 de 114 8 Líneas Futuras Son muchas las expansiones y mejoras que se pueden realizar en este proyecto o en otros que se centren en un tema similar, ya que este es un campo de estudio muy amplio. Muchas son las ideas que has surgido después de haber finalizado el proyecto. Hay una innumerable cantidad de algoritmos que podrían dar buenos resultados en un problema como este. O podrían ejecutarse técnicas de Aprendizaje Automático, como el Aprendizaje por Refuerzo con técnicas de Clustering o el Aprendizaje Incremental, de modo que se desarrollaran agentes que aprendieran a partir de una gran colección de instantes de juego y así decidir cuál es el mejor movimiento a realizar en una situación dada. Otra posible funcionalidad extra que podría diseñarse para proyectos futuros sería la de permitir la creación de distintos tableros de juego, ya se manualmente o automáticamente a partir de algunos parámetros. Sería además interesante estudiar distintos modos para integrar la parte de ejecución de los algoritmos en la interfaz gráfica, para que de este modo esté el proyecto más unificado y todas las funcionalidades se puedan acceder desde el mismo programa. Tal vez esta parte podría abrirse en una nueva ventana sin bucle de juego para poder seguir trabajando con la interfaz gráfica o se podrían estudiar otras formas de desarrollar la parte gráfica, como Panda3D. También se ha tomado muy en cuenta la posibilidad de crear una versión del sistema en Python 3, ya que está bastante extendido. Tras realizar distintas pruebas con las dos partes del programa, se percibió que había algunas características que se podían mejorar para hacer más cómodo su uso a los usuarios. Por ejemplo, en el menú de selección de niveles se debería incluir alguna opción para volver al menú principal o en las partidas se podría incluir alguna funcionalidad para volver al menú o reiniciar la partida en caso de caer en una situación de Deadlock que no permita acabar el juego, ya que en la versión actual la única solución es cerrar la interfaz. También podría estudiarse el control de menús por medio del ratón. Respecto a la parte del programa de ejecución de algoritmos, también hay muchas mejoras posibles. Un ejemplo sería la de permitir al usuario decidir si quiere sólo resolver algún nivel concreto y con unos algoritmos deseados o poder fijar de forma simple el tiempo máximo de ejecución de los algoritmos de búsqueda, que actualmente sólo es posible modificando el código. Página 67 de 114 Quizás una mejora interesante sería la de generar ejecutables de Windows para que usuarios que no cuenten con Python 2.7 y los paquetes empleados en el proyecto puedan ejecutar los archivos sin necesidad de realizar ninguna instalación. En esta ocasión no se realizó debido a que muchos programas generadores de ejecutables no soportan las librerías empleadas y/o no permiten proyectos con varios archivos de Python, aunque con un estudio en profundidad podría ser posible adaptar estos programas o generar los ejecutables a mano. Página 68 de 114 9 Bibliografía [1] J. C. Culberson, Sokoban is PSPACE-Complete, Edmonton, Alberta (Canada): University of Alberta - Department of Computing Science, 1997. [2] R. Kaye, «Minesweeper is NP-complete,» Mathematical Intelligencer, vol. 22, nº 2, pp. 9-15, 2000. [3] D. Ratner y M. K. Warmuth, «Finding a shortest solution for the N*N-extension of the 15-puzzle is intractable,» J. Symbolic Comp, nº 10, pp. 111-137, 1990. [4] «Python 2.7.10 Documentation,» Python Software Foundation US, [En línea]. Available: https://docs.python.org/2/index.html. [Último acceso: 13 Septiembre 2015]. [5] A. Jughanns, Pushing the Limits: New Developments in Single-Agent Search, Edmonton, Alberta (Canada): University of Alberta - Department of Computing Science, 1999. [6] «Pygame,» [En línea]. Available: http://pygame.org/wiki/about. [Último acceso: 22 Septiembre 2015]. [7] «Sokoban Perfect Plus,» Thinking Rabbit, [En línea]. Available: http://sokoban.jp/. [Último acceso: 20 Septiembre 2015]. [8] E. Sever, «Sokoban·Erim,» [En línea]. Available: http://www.erimsever.com/sokoban8.htm. [Último acceso: 26 Septiembre 2015]. [9] Y. Chang, «Sokoban.org,» 13 Julio 2013. [En línea]. Available: http://sokoban.org/about_sokoban.php. [Último acceso: 20 Septiembre 2015]. [10] Departamento de Ingeniería Informática - UC3M, Apuntes de Teoría Avanzada de la Computación, Leganés, Madrid (España). [11] M. Fryers y M. Greene, «Sokoban,» Eureka, nº 54, 1995. Página 71 de 114 This investigation's intention is to implement different search algorithms capable of finding solutions to this popular game and to analyze each of the used techniques to make a comparison between them. In addition, it's intended the design a graphic interface so that way users can also play with the different levels and to be able to visualize the solutions found by the search algorithms. This game is also a personal motivation, because Sokoban is a game that I discovered while I was in my first year of the degree during the Programming subject, and it helped me to learn the basics contents of programming languages generics and Java language particulars. The final assignment of the subject consisted on two phases. The first one consisted on implementing the game as a printing of characters in the screen, using some basic functions and structures. At second phase we used more advanced methods and classes and we used a graphic interface created by our teacher. That was the moment I fell in love with everything about the game and I felt a little sorry for not learning at that time how to create the graphic design with a programming language. This End-of-Degree Project means to me the perfect opportunity to go back to the game that marked the start of my degree, so this is the perfect chance to include a graphic interface that at that time I considered out of my range and, at the same time, this is a opportunity to learn a new programming language. If at that time my Java knowledge was reduced to some little assignments over the subject duration, this time the project will help me to learn Python from scratch. Página 72 de 114 10.1.1.2 Project Stages Before starting the development of the graphic interface and the solvers stated in the previous section, it’s mandatory to present a basic view of the game, namely, it’s necessary to define the different movements allowed and the rules that compound it. It has to be checked that all the components are working properly, and then a more colorful interface can be created and the different solvers can be implemented. The Project stages are the following ones:  Stage 1: Aim definition. The desired goals of the project’s realization were stated.  Stage 2: Investigating about Python 2 [4], learning its basic operation before starting to work with the language.  Stage 3: Basic definition of the Sokoban game. The rules that control a simple Sokoban level written in a text file were defined in Python. The instance represents every square with an ASCII character, and the instance is showed in a command line, asking for a letter input (W, D, X, A) that represents the different movements realized. The program checks if the movement is valid, in which case the instance is modified by the games rules and displayed in the screen, or in case that the movement can’t be accepted, it shows a message stating the reason (an invalid key or a movement not allowed).  Stage 4: search of the levels that will be used in this research. Some Sokoban levels that could be used to solve were searched. It was decided to use the ones that Andreas Jughanns used in his PhD thesis [5], the Kids Problems’ set. This and other sets over the internet are usually written in a special ASCII notation called XSB Format, so the rules had to be adapted so they could work with the new format. The Original file had all the Kids Problems in the same archive, so the file had to be cleaned and divided into 61 independent files, one for each level, with a Python program created for this purpose.  Stage 5: after the search of level was over and after learning about the format notations at the previous stage, it was decided to continue investigating in that field and learn more about the specifics of the Sokoban game domain, and so the State of the Art section was written. The Initial Budget was written too.  Stage 6: game in graphic mode. After studying about Pygame programming and practicing a little with Pygame [6], the implementation of the first graphic representation was realized, game loops were defined, and it was designed the key reading events and the different functionalities that use the previously designed rules. Página 73 de 114  Stage 7: Solver design. At this stage the search algorithm that will solve the puzzles were implemented and some improvements were added, reducing the execution times and the expanded and generated nodes.  Stage 8: A complete menu design. As the final part of the implementations, a complete menu was created for the graphic interface, allowing to play the 61 levels and showing the results of the search algorithms.  Stage 9: drafting of the remaining parts of the document. Página 76 de 114 10.1.2 Corpus 10.1.2.1 Chosen Decisions When implementing the different algorithms, the first decision made was the programming language used. It was decided to use Python, being a language that is not used in any mandatory practice of the degree and I had no previous knowledge of the language. This language caught my attention when in a subject were proposed several optional practices, one of which used some simple Python. By then I was already planning the language to be used in the project, with the main candidates beeing C ++ (of which I have basic knowledge) and Python (which I knew nothing). I took that opportunity to learn the language and I really liked Python, so I decided to use it. After opting for Python, I had another decision to make, and was to use Python 2 or Python 3. After some research I chose Python 2, since it is the most documented and extended version, but Python 3 is gaining strength and is also quite widespread. Moreover, it was decided to use the library Numpy to facilitate reading data file with a specific format and to easily work with them a two-dimensional array representing the game board. The next decision was to choose the method to develop the graphical interface of the game, going for Pygame. This set of modules for Python is based on the SDL library and allows you to create games and multimedia programs [6]. When executing the various algorithms, as some may not find solutions or spent too long times, a maximum execution time was of 30 minutes was decided. Regarding the search algorithms used for finding solutions in different game boards, they ones being used are in breadth first search, depth first search, iterative deepening depth first search, A * and IDA*. These algorithms have different kinds of improvements to reduce search times so they become better in finding solutions. Breadth first search and Depth first search, to prevent the generation of repeated statements that can create loops (especially in the case of depth search, these loops can prevent the algorithm to end) a list of generated states has been created. This way, only the new nodes are considered and avoids falling into cycles. Página 77 de 114 On the other hand, a function which finds a large number of Deathlocks has been defined, thereby avoiding to expand nodes that will never reach a solution. Specifically, this function checks stones with walls on two adjacent sides (at a corner) or the case in which two or more adjacent boxes are next to a wall. These modifications managed to improve success in finding solutions rate and the time spent to find solutions dropped a high magnitude. Before the improvement of the list of generated nodes, there were some cases (Test 24) that didn’t find solutions in breadth and depth search with a 10-minute limit and with this improvement the algorithms found solutions in 64 and 15 seconds respectively. In addition, when used the Deadlocks detection, a larger number of solutions was found with all methods (Iterative depth in Test 24 could find no solution in 10 minutes, and with the Deadlocks detection finds a solution in a little more than 5 minutes) and reduced the time to find solutions, becoming about 6 times lower (Test 24: A* lowers from 39 to 7 seconds and IDA * goes from 182 to 30. Breadth and depth get 18 and 2 seconds, respectively). For Informed search algorithms have been considered a heuristic that calculates the distance of each stone to the nearest base, adds this distances and then adds the distance from the player to the farthest box. It is also considered whether the board is in a Deadlock position, adding a value of 1 million if there is a deadlock or 0 otherwise. This heuristic is admissible because it never overestimates the cost to reach the goal from a particular state: • For distances to the bases, at the best case all the blocks end in the base that used to calculate the distance, being equal to the expected cost. In other cases, they end up on some other goal, so it will have a cost equal to or greater than calculated, so that the heuristic will always have a lower value. • Considering the distance from the player to the farthest stone to solve the board, the player has to take all the stones to the bases, so sooner or later the player must go to the farthest stone to move it, so this part is admissible too. • Finally, the added condition for Deadlock is admissible too, because if there is a Deadlock, it doesn’t add any additional cost to the calculated, so it is still admissible, and if there is a Deadlock, the solution will never be reached (can be considered infinite cost) so adding 1000000 is still lower than the actual cost. It was intended that part of the search for solutions was called from within the GUI, but the operation spent too much time without calling the game loop algorithms while seeking solutions and gave some problems. Página 78 de 114 10.1.3 Conclusions Once developed the entire project, it is time to analyze it as a whole, checking if the objectives set out in paragraph Objetivos (Goals) has been achieved and analyzing the results of the Pruebas y Resultados (Tests and Results) section. First, all the explicit project objectives have been achieved. It has been implemented a game Sokoban, different algorithms that use Artificial Intelligence techniques to generate solutions that consist of a series of steps to get from the initial state to the final state and has also met the goal of developing a GUI that allows to play Sokoban levels and visualize the solutions found by the algorithms. Regarding the objective of measuring the quality of the algorithms based on various parameters, it can be said that this part has also been completed. In the area of Pruebas y Resultados (Testing and Results) various algorithms were compared according to generated solutions. Thus, it has been observed that although the depth-first algorithm solves more levels, it doesn’t ensure optimality, so it’is appropriate to consider other algorithms. The second algorithm that solves most problems is A *, which assures optimal solutions because it uses an admissible heuristic and also, in the list of algorithms that ensure optimality, it’s the one that employs a shorter time. Thus, a the best algorithm could be to use A* to find optimal solutions, and if not found, use depth first search to try to get at least a non-optimal solution. Comparisons were also made of nodes generated and expanded, though their importance is somewhat lower than that mentioned in the preceding paragraph. Finally, memory usage studies were not performed, but the definition of algorithms that are known to carry higher memory usage are Breadth First Search and A*, and in this project the memory used for Breadth First Search is even greater because it uses a list of generated nodes to avoid repeated states. Thus, if I had to choose an algorithm for its lower memory usage and that assures optimal solutions I would choose IDA *, because it solves more problems that the other option, Iterative Deepening Depth First Search. Regarding the personal goals I wanted to achieve with the project, they can also be considered achieved. After the project I can say that I can use the Python language with some ease. In addition, I have also been able to make a GUI for the program, which was another objective, and although mastering this part is not as high as that achieved with Python, I can consider to have acquired knowledge that will allow further improvement.