Sunteți pe pagina 1din 7

Desarrollo de un agente autnomo jugador de Super Mario

Adrin Amor Martn


100072611 Ingeniera de Telecomunicacin Universidad Carlos III de Madrid

Cristina Garca Muoz


100072663 Ingeniera de Telecomunicacin Universidad Carlos III de Madrid

100072611@alumnos.uc3m.es

100072663@alumnos.uc3m.es

RESUMEN
En este documento se va a detallar cmo realizar un agente, basado en rboles de decisin, que sea capaz de jugar de forma autnoma al juego Super Mario en el marco del concurso Mario AI 2011.

Descripcin de categoras y temas.


[Agente]: Un agente es un sistema informtico que demuestra que percibe su entorno a travs de sensores y es capaz de actuar sobre dicho entorno mediante efectores. [Super Mario]: Videojuego de plataformas muy popular desde la dcada de los 80, diseado por Shigeru Miyamoto.

de los 80. Una de las razones de este espectacular crecimiento es la capacidad de generar jugadores automticos mejores que el propio humano, de manera que el jugador se debe esforzar en superar a la mquina. Esto se convierte en un fenmeno social (se habla incluso de la llamada generacin gamer) y provoca tambin un incremento en la investigacin en inteligencia artificial, ya que muchos juegos compiten en demostrar que su jugador no humano es mejor que cualquier otro (como puede observarse con la guerra anual entre juegos de ftbol). De esta manera, se producen cada vez jugadores ms inteligentes, llegando a imponer niveles de dificultad que slo son resolubles despus de mucha experiencia en el juego. De esta manera, se vio de manera casi inmediata que la fuerza bruta para implementar un jugador automtico (es decir, explorar todas las posibilidades hasta el final para ver si con cierto movimiento podemos llegar a la derrota o a la solucin) es, adems de poco eficiente, irrealizable en la prctica debido a la limitacin de los sistemas de computacin del momento. Se impone as investigar sobre tcnicas de bsqueda que permitan resolver problemas, ya sean relacionados con derrotar a un jugador humano o llegar a la solucin de, por ejemplo, las torres de Hanoi. Todas estas tcnicas para llegar a una solucin deben maximizar la eficiencia de clculo, para lo que las opciones que se deben evaluar deben ser las ms inteligentes posibles, e intentar llegar a la solucin ptima. De esta manera, una primera aproximacin son los rboles de decisin en los que se contemplan todas las posibilidades de actuacin y se elige la ms ventajosa (ya sea con una funcin de evaluacin o heurstica, es decir, basada en la prctica); otra aproximacin son las redes neuronales, que construyen asociaciones entre las entradas del problema y las salidas, de manera que buscan la solucin ms eficiente; y otra aproximacin son mquinas de estados, que es otra manera de hacer jugadores razonablemente inteligentes. Se evalan todas las entradas en cada mquina y se llega a un estado de actuacin; el objetivo es llegar al estado final que es la solucin. A estos efectos se implementan los llamados autmatas de Moore y de Mealy, que no contemplaremos en este trabajo por considerar que un agente no puede ser perfectamente definido por estas mquinas de estados. Una vez que situados en el contexto histrico actual, y haber planteado las opciones que tenemos a la hora de hacer un jugador automtico, uno de los entretenimientos que sirve para ahondar en el concepto de inteligencia artificial es generar un agente, que sea capaz de hacer cosas que un ser humano, si no es experto, normalmente no consigue. En esta lnea surge el concurso Mario

Palabras clave.
Agente, rboles de decisin, inteligencia artificial, Super Mario.

1.

INTRODUCCIN.

Una de las principales inquietudes del ser humano es conseguir hacer entes que se muevan artificialmente, es decir, que simulen (e incluso mejoren) el comportamiento humano. As, a lo largo de la Edad Media se desarrollaron autmatas como el hombre de palo de Juanelo Turriano, en Toledo, y artificios como El Turco, que era capaz de jugar al ajedrez de manera autnoma (aunque se descubriera poco despus que era un engao). Con el auge de la computacin se empieza a tener una capacidad de procesamiento similar a la del ser humano, de manera que se desarrollan programas que intentan simular un jugador automtico. La lnea de investigacin que ms se desarroll en el siglo XX fue la de desarrollar un autmata capaz de vencer a un ser humano al ajedrez, de manera que se empiezan a disear estrategias en la dcada de los 50 por, entre otros, Shannon y Turing, y el refinamiento de estas estrategias consiguen que, en 1998, se produzca la derrota del campen mundial del momento, Gary Kasparov, a manos de una mquina llamada Deep Blue. Debemos destacar tambin el auge de la industria del videojuego que, si bien nace con la creacin del Pong (juego muy simple entre dos personas), experimenta un gran incremento desde la dcada

Figura 1. Pong original.

AI Championship, o Mario AI Competition, consistente en proporcionar una interfaz fcil de usar para el usuario de manera que ste se encargue, nicamente, de generar un agente que se pase todas las pantallas posibles. Posteriormente ahondaremos en las posibilidades que se nos dan a la hora de elegir el nivel que queremos que juegue nuestro agente, pero la libertad es casi infinita. As, se convoca un concurso intentando escoger al agente que demuestre un mejor comportamiento en la interfaz que se proporciona al usuario. En este documento detallaremos cmo es la interfaz y qu podemos utilizar para que nuestro jugador juegue de manera autnoma de manera similar a como lo hara un humano; las estrategias que podemos seguir a la hora de conseguir el objetivo (que es que se pase la pantalla con la mayor puntuacin posible), evaluando su dificultad y la estrategia que seguiremos finalmente; y las reglas que hemos usado, finalmente, para conseguir un agente lo ms complejo posible.

Figura 2. Matriz de observaciones (levelScene). Conocer dnde estn los enemigos, y qu tipo de enemigos podemos tener, es decir, si podemos eliminarlos saltando sobre ellos o disparndoles, o no les podemos eliminar. Esto se da mediante la matriz de byte enemies, que tiene la misma dimensin que levelScene, es decir, [19x19]. As, los valores ms relevantes que tenemos son: o 80 para un goomba. Se puede eliminar saltando o disparando sobre l.

2.

INTERFAZ CON EL ENTORNO.

Antes de nada, lo que tenemos que analizar es qu necesitamos del escenario para que nuestro agente sobreviva. As, a primera vista necesitamos: Conocer cmo es el escenario, dnde estn las cadas (que en el cdigo se llamarn gaps), dnde podemos saltar, romper ladrillos, conseguir monedas, bonus Todo esto se nos da en la matriz levelScene; es una matriz de tipo byte que incluye todos los elementos relativos al escenario, es decir, dnde est el suelo, los ladrillos y que tiene como dimensiones [19x19], de manera que Mario slo es capaz de ver 10 posiciones delante suya (ya que Mario est en el centro de esta matriz). Los valores relevantes que debemos tener en cuenta en una primera aproximacin son: o o 0 si no hay nada. -60 para el suelo. Debemos destacar que este valor no es constante desde que empieza el suelo hasta el final, sino que tenemos un -60 en la primera lnea de suelo y ms hacia abajo, 0. Esto es importante a la hora de detectar gaps para nuestro cdigo. -62 para suelo que se puede acceder saltando desde abajo (es decir, el agente no se cae si est encima pero puede sobrepasarlo saltando). -20 para ladrillos que se pueden romper. -22 para ladrillos que no se pueden romper (cuadrados con interrogacin en los que se consigue un bonus). -90 para tuberas.

Figura 3. Goomba. o 84 para una bala, que solo sale si tenemos los caones activados. Se puede eliminar de la misma manera que el goomba, saltando sobre l o disparando.

Figura 4. Bala. o 81 y 82 para un koopa. Un koopa se puede eliminar disparndole, y si se salta sobre l dejar un caparazn sobre el que, si salta, se desplazar a lo largo de la pantalla destruyendo todo lo que encuentre en su camino.

o o

Es importante saber que la interfaz nos da varias posibilidades de zoom, es decir, que podemos especificar si queremos, por ejemplo, que se nos informe de qu tipo de ladrillos tenemos, o simplemente se nos diga que hay un ladrillo, o un obstculo. Esto es til cuando se empieza a codificar un agente, pero si se quiere aadir un poco de complejidad es necesario usar el zoom ms detallado que hay. Podemos ver un esquema del comportamiento de la matriz en la figura 2.

91 para las flores que saltan de las tuberas. Se puede eliminar saltando por debajo de ellas o disparando.

Figura 5. Flor.

De nuevo se puede hacer una distincin entre el zoom que queremos, de manera que se distingue entre enemigos que son destructibles saltando sobre ellos, o aquellos que no se pueden destruir, como Spiky:

continuacin, debemos determinar cul ser estrategia de comportamiento para nuestro agente.

nuestra

3. POSIBLES ESTRATEGIAS DE COMPORTAMIENTO.


A continuacin vamos a detallar posibles estrategias de comportamiento que fueron evaluadas para hacer nuestro agente, y justificaremos, finalmente, la estrategia elegida.

3.1

Redes neuronales.

Una red neuronal es capaz de modelar la relacin existente entre las entradas a la red y sus salidas. De esta manera, lo que tenemos que escoger es qu queremos como entrada, y qu queremos como salida, ya que la relacin entre ellos se encargar de definirlo el modelo de red neuronal que utilicemos, como, por ejemplo, el perceptrn. Figura 6. Spiky. Debemos destacar, tambin, que la matriz enemies y levelScene se pueden usar en la misma matriz, llamada mergedObservation, que contiene los mismos valores pero concatenando ambas matrices. Posicin en la que se encuentra Mario. Sus coordenadas dentro de la matriz levelScene y enemies se nos da con marioCenter, array de dos posiciones en la que la primera posicin corresponde a la coordenada Y de Mario, y la segunda, a la coordenada X. Posicin absoluta sobre el escenario total en la que se encuentra Mario. Esto se da con marioFloatPos, array de dos posiciones en la que, en una posicin se nos da la coordenada X absoluta de Mario sobre el escenario completo, y en la coordenada Y, la altura de Mario sobre el fondo de la pantalla. Posicin absoluta sobre el escenario en la que se encuentran los enemigos. Esto se da con enemiesFloatPos, que es un array en el que se da el identificador del enemigo y su posicin segn las caractersticas que hemos descrito anteriormente. Como entrada querramos saber, por ejemplo, si Mario puede saltar, si Mario puede disparar, si Mario est en peligro de caer, o si tiene un gap cercano, si Mario ve enemigos en fin, las entradas deberamos definirlas con cuidado, mientras que las salidas estn claras: sern las acciones que debe tomar Mario, es decir, si salta, si se mueve a la izquierda, si se agacha, si se para bsicamente, definir el array action que debemos devolver en el mtodo getAction(). En cuanto a la manera que tendramos de aprender, deberamos basarnos en unos datos de entrenamiento, es decir, deberamos jugar con l para que vea cul es la reaccin de Mario en los casos contemplados y que establezca relaciones entre entradas y salidas. A esta fase se la llama de entrenamiento, y debera ser programada en otras partidas, mientras que una vez que supere esta fase debera ser capaz de jugar por s solo de manera adecuada. Este modelo no fue el que utilizamos porque lo vimos complejo (debemos programar dos fases, la de entrenamiento para generar el modelo, y la de juego en s, aunque aprendera con el tiempo) y computacionalmente costoso al tratarse de una red neuronal. Por ello, esta estrategia fue descartada.

3.2

Bsqueda A*

Una vez que conocemos todas las variables que podemos usar para determinar el comportamiento de nuestro agente, lo que debemos evaluar es qu debemos cambiar en el cdigo para que haga lo que nosotros queremos. De esta manera, se nos dan unos agentes ya hechos (pero casi sin inteligencia asociada) y podemos observar que lo que debemos modificar es el mtodo getAction(), que devuelve un array de boolean cuyo significado es el comportamiento que va a hacer Mario en cada momento, es decir, si va a ir a la izquierda, derecha, correr y disparar (es la misma tecla), agacharse y saltar. Para definir eso habr que poner a true las acciones que queremos que haga en las posiciones correspondientes del array, y a false las acciones que queremos que no haga. Con esto podemos controlar el comportamiento de nuestro agente cada vez que se llama a getAction(), que es en un intervalo de tiempo lo suficientemente pequeo para ser capaz de pasarse la pantalla. As, una vez familiarizados con el entorno de trabajo, ya conocemos todo lo que podemos usar para crear nuestro agente, es decir, toda la informacin relevante que influir en su comportamiento con el escenario y con los enemigos. A

La siguiente solucin que nos planteamos seriamente fue hacer una bsqueda heurstica, pues est claro que en nuestro problema, que no es un problema cerrado, debemos tener en cuenta el factor heurstico. As, podemos usar una funcin de evaluacin bestfirst como la bsqueda A*. La bsqueda avariciosa (greedy search) la descartamos por poder atascarse en bucles infinitos si las estimaciones no son del todo correctas, as que nos decantamos por la investigacin sobre A*. Como ya hemos dicho, A* hace una bsqueda best-first que evita expandir caminos que ya son muy costosos de por s, para no desperdiciar recursos de computacin. En cada nodo tiene que evaluar una cierta funcin f(n) que es: f(n) = g(n) + h(n) donde f(n) es el coste estimado total hasta la meta pasando por el nodo n (que es el que estamos evaluando), g(n) el coste sufrido hasta alcanzar el nodo n, y h(n) el coste estimado total hasta la meta pasando por n. A* es capaz de alcanzar la solucin ptima (el camino ms corto hacia la meta) si conseguimos que la funcin heurstica no sobreestime el coste real.

Una vez planteado el modelo que se debera usar, debemos plantearnos las siguientes dudas: Cul es la meta? Obviamente, no es la meta final, ya que Mario no es capaz de acceder a ella desde el principio, por lo que lo ms razonable es escoger el punto de suelo que se encuentre ms a la derecha de nuestra matriz levelScene, y evaluar el camino hacia all tomando el camino ms corto posible. Qu funcin heurstica debemos emplear? Aqu es donde est la calidad del algoritmo A*; en realidad, deberamos evaluar si hay un enemigo, si hay un gap poniendo por delante de todo la supervivencia. Pongamos un ejemplo: est claro que si avanzamos hacia la derecha y hay un enemigo, no deberamos avanzar y, en vez de eso, deberamos quedarnos parados o saltar. De esta manera, al camino que sea avanzar le ponemos un coste sensiblemente superior al de saltar o quedarnos parados, descartando esa opcin, y posteriormente decidiremos en qu direccin debemos ir. se es un simple ejemplo de funcin heurstica, sin embargo, si lo pensamos un poco, la complejidad no hace ms que incrementarse, ya que debemos tener en cuenta el enemigo que tenemos delante: si salta, lo ms conveniente es quedarse parado, o retroceder un poco y saltar sobre l; si no salta, lo ms inteligente es saltar para intentar eliminarlo; si somos capaces de disparar, deberamos dispararle para destruirlo y adems de todas las reglas que en una primera exploracin se nos ocurren, debemos tener en cuenta el movimiento que van a seguir nuestros enemigos, es decir, si van a saltar, si van a moverse hacia nosotros, o hacia el otro lado, si son ms rpidos o ms lentos; es decir, debemos conocer el sentido de su marcha pues es intil saltar sobre un goomba que no viene hacia nosotros, por ejemplo. As, deberamos hacer un seguimiento de cada enemigo para tener una funcin heurstica buena. El algoritmo, por tanto, debera calcular el camino menos costoso, para lo que cada casilla de la matriz mergedObservation (si consideramos escenario y enemigos a la vez) es un nodo, evaluando la funcin para cada casilla y considerando cul es el camino que nos puede llevar hacia la meta. Para ello, necesitamos una estimacin futura de lo que va a pasar hasta que lleguemos hacia la meta para que la funcin heurstica est bien definida. No vamos a hablar sobre temas de implementacin porque sta no fue la solucin que escogimos, aunque fue la solucin ganadora en el concurso de 2009. No fue escogida porque para que funcionara adecuadamente debamos implementar un simulador de cada elemento en pantalla, es decir, todos los enemigos, las bolas de fuego que lanzamos para ser precisos y eso es algo cuya complejidad excede el espritu de este trabajo; adems, la implementacin de un algoritmo A* tampoco es trivial (debemos evaluar la funcin en cada nodo) ni algortmica ni computacionalmente. Por ello, la solucin que escogemos, finalmente, es la de los rboles de decisin.

Un rbol de decisin constituye un mecanismo de aprendizaje mediante induccin supervisada, como las redes neuronales (aunque con menos complejidad a priori). De esta manera, buscamos encontrar las reglas que mejor modelan la relacin entre las entradas, que en nuestro caso es el entorno (tanto escenario como enemigos) y las salidas, que es el comportamiento de Mario, es decir, si decidimos que salte, que vaya a la izquierda, a la derecha... La gran ventaja que tiene este tipo de algoritmo es que supone una buena aproximacin al problema (aunque nosotros nos quedemos aqu por falta de tiempo) para aplicar un algoritmo ms elaborado, aunque con rboles se puede conseguir un resultado ms que aceptable; no hace falta un gran salto inicial para empezar a obtener resultados, esto es, que pase pantallas muy sencillas. As, la manera de trabajar ser ir aumentando la inteligencia del agente en funcin de la dificultad de la pantalla, introduciendo reglas y, por tanto, expandiendo el rbol que debemos evaluar. Otra ventaja con la que contamos es que la implementacin no es muy costosa computacionalmente, ya que bsicamente se trata de evaluacin de condiciones if-else; adems, su implementacin es sencilla algortmicamente, ya que al tratarse de este tipo de condiciones, es fcilmente entendible. El gran problema de usar estos tipos de algoritmos es que no son tan generales como pueda ser el algoritmo A*, ya que se programan en base a pantallas, es decir, de forma heurstica. De esta manera, puede llegar a ocurrir que sea ptimo para una pantalla pero que sea incapaz de pasarse otra pantalla completamente distinta; por ello, nuestro objetivo a la hora de implementar este rbol es la generalizacin, es decir, que no haya sobreentrenamiento en nuestro modelo de aprendizaje. Esto lo mostraremos con varias pantallas con escenarios muy diversos. Una vez que hemos decidido usar esta estructura por su sencillez y los resultados aceptables que se obtienen, debemos pensar en ciertos aspectos: Prioridades, es decir, qu entrada es ms importante para garantizar la supervivencia del agente. Esto, traducido a rboles de decisin, es qu condicin vamos a evaluar primero, si la condicin de que haya un enemigo delante o la condicin de que haya un gap por el que nos podamos caer. Acciones a tomar, esto es, que si vemos, por ejemplo, un enemigo que no salte, nuestra decisin sea saltar sobre l o esquivarlo. Para ello deberamos prever el movimiento del enemigo, como ya discutimos en la seccin 3.2; el problema es que este simulador fsico no es fcil (se requieren muchas horas para calibrarlo) as que estas reglas se determinarn de forma heurstica para el caso en el que haya enemigos. Objetivos, es decir, si preferimos, por ejemplo, caminar por encima de una fila de ladrillos porque haya una fila de monedas o por el suelo porque haya ms enemigos a los que podemos matar, o simplemente garantizar nuestra supervivencia que es a lo que este concurso se limita.

3.3

rboles de decisin.

En primer lugar, debemos referirnos a esta estrategia como un punto medio entre hacer un algoritmo muy elaborado, como el algoritmo A*, y hacer una estrategia completamente heurstica, es decir, ir parcheando el agente para que se pase una sola pantalla.

Con todo esto en nuestra cabeza, pasamos sin ms dilacin a la explicacin del cdigo realizado.

4. REGLAS DEL RBOL DE DECISIN.


El cdigo desarrollado dota al agente de una serie de habilidades para superar los obstculos que pueda encontrarse a lo largo de

distintas pantallas de nivel medio-alto. En este apartado analizaremos en orden creciente de prioridad las herramientas con las que cuenta Mario para salir airoso de las trampas que aparecen en su camino. La base de la que partimos permite al agente correr mientras dispara bolas de fuego de manera intermitente. Los mtodos a continuacin descritos modifican los valores base de manera apropiada para hacer que el agente se adapte a las situaciones detectadas. Para obtener el mximo rendimiento de este planteamiento se hace necesario un estudio previo de los peligros que van a acechar al jugador automtico a lo largo de los recorridos que atraviesa. Una vez estudiados se puede establecer un orden de actuacin para dar ms prioridad a la resolucin de los problemas ms graves. La mejor manera de identificar de forma real el mayor nmero de situaciones posibles es jugar manualmente experimentando los problemas y viendo cmo pueden solventarse. Fruto de este estudio previo del entorno pudimos descubrir que las fuentes de fallo ms habituales sin tener en cuenta las criaturas que puedan aparecer son: Hoyos: en principio bastara con saltar al detectar una aproximacin a uno de ellos, sin embargo pudimos comprobar que en ocasiones es necesario ajustar el impulso ya que la superficie disponible para aterrizar el salto no es infinita. Combinaciones de obstculos y escalones con hoyos: los hoyos presentan una dificultad mayor si van detrs de un escaln de bajada, ya que por el impulso de avanzar ya caes al vaco. Adems si el hoyo est detrs de un obstculo corremos el peligro de saltar ms de la cuenta y precipitarnos por el gap. Bloqueo entre ladrillos: cuando hay ladrillos en ocasiones el espacio que hay entre ellos y el suelo no permite avanzar por lo que el agente se queda atascado como si se tratase de un callejn. En particular ocurre cuando los ladrillos no pueden romperse. En la figura vemos que el hueco que queda es de una unidad y al ser el agente grande no entra, por lo que tiene que dar la vuelta y saltar por encima.

Figura 8. Escaleras con gap. Considerando todos estos retos sumados a la posibilidad de aparicin de criaturas y balas, se establece un mtodo por solucin requerida. Las reglas que se encuentran implementas en nuestro agente son, por prioridad: Evitar flor de las tuberas: esta amenaza se resuelve de forma pasiva, parndose hasta que la planta est escondida. En este caso detecto las flores con una antelacin de tres cuadros para tener un margen de frenada ya que no es posible pararse en seco. Evitar enemigo saltando Bloqueo: como respuesta al peligro de quedar atascado manifestado anteriormente, ya sea por la existencia de ladrillos o por la colocacin de un can, se implementa este mtodo. En cada consulta del mtodo getAction() se intenta detectar si nos encontramos en situacin de bloqueo. Detectamos bloqueo cuando tenemos un objeto sobre nosotros que nos impide saltar y adems el hueco que hay por delante es nulo o insuficiente. Si descubrimos que estamos en ese punto nos servimos de unos contadores para dar varios pasos en sentido contrario, volver a girar y saltar sobre el objeto que nos impeda el salto. Enemigo no saltarn, destructible saltando sobre l: si el enemigo no salta, y lo detectamos justo delante (o una casilla ms adelante) de Mario, saltamos para intentar eliminarlo. Parar salto: es un mtodo crucial ya que nos permite hacer un ajuste menos fino de la potencia de los saltos. Cuando el agente est en pleno salto se hace un barrido por el suelo y si se detecta que el hueco se termina en los dos prximos cuadros, el salto se frena y con la inercia que lleva es suficiente para caer sobre la superficie detectada. Esto soluciona los problemas que aparecan cuando haba que aterrizar sobre una superficie pequea. Frenar: este es otro de los mtodos que ms a menudo salvan a nuestro agente. Cuando tenemos un escaln de bajada seguido de un hoyo no basta con pararse ya que como no se consigue frenar en seco la inercia que llevas slo de avanzar hace que te precipites. Cuando se juega manualmente este problema se resuelve anticipndose a la situacin lo que nos da tiempo para conseguir frenar y caer de manera casi vertical. Sin embargo para el jugador automtico decidimos detectar la situacin con un par de casillas de antelacin y ajustar la cantidad de frenada en funcin de la altura que tenga el escaln. De

Figura 7. Bloqueo. Bloqueo con caones: la situacin de los caones cuando tambin hay ladrillos impide el paso y el salto del agente de la misma manera. Obstculo final demasiado alto: el final del escenario por defecto presenta una colina alta que obliga al agente a subir ayudndose de otras colinas intermedias. Escaleras: las escaleras presentan un problema ya que suelen tener un hoyo detrs y deben estar muy ajustadas para no sobrepasarlas como tambin apuntbamos con los obstculos anteriormente.

esta forma cambiamos de direccin durante un nmero de intervalos proporcional a la cantidad de frenada calculada y con ello conseguimos que caiga en tierra firme.

Figura 10. Colina alta final. En ese caso lo que hacemos es volver atrs hasta que encontramos una estructura de ese tipo y llegamos a una altura suficiente desde la que podamos saltar y alcanzar la meta.

Figura 9. Escaln con gap. Gap: el mtodo que detecta los hoyos y asigna una intensidad de salto que es por defecto la mxima ya que contamos con el mtodo de parar salto para ajustar mejor la potencia del salto. Obstculo delante: contamos con dos mtodos que detectan que hay obstculos delante y uno adicional que identifica el tipo de obstculo de manera que si es uno con un hoyo detrs, la intensidad que se le pone al salto es la mnima para que lo supere sin pasarse. Gap salvable: para que el agente recorriese las pantallas de forma ms fluida introdujimos este mtodo que detecta cuando podemos saltar para acortar el camino aunque no haya un hoyo entre medias del origen y el destino del salto. De forma emprica establecimos unos lmites de lo que Mario es capaz de saltar y con ello cada vez que detecta que saltando puede llegar acortando el recorrido. Viene bien cuando hay tuberas ya que en muchas ocasiones estn emparejadas y acorta bastante. Subir ladrillo: este mtodo detecta cuando hay ladrillos por delante a una altura a la que pueda llegar con un salto el agente de forma que ste se mueva por las zonas ms altas para coger monedas, evitar criaturas y posibles bloqueos por debajo de las filas de ladrillos. Bala: si detectamos una bala encima de Mario, o encima y a la derecha de Mario, esperamos a que pase antes de proseguir nuestro camino. Colina alta final: en esta competicin de Mario se ha habilitado la opcin de que el final sea en alto, es decir, sobre una colina muy alta que no es alcanzable saltando con Mario, sino que tiene que volver atrs y saltar desde ms arriba. Estamos hablando, por ejemplo, de esta situacin:

5.

RESULTADOS OBTENIDOS.

Como ya explicamos en la introduccin, la posibilidad de personalizacin del nivel al que juega Mario es muy grande. Listaremos aqu algunas de las que hemos usado para mostrar el comportamiento de nuestro agente: -le: define los enemigos que queremos que aparezcan en la pantalla. Al contrario de lo que pone en la pgina oficial, [1], ya no se hace una mscara a nivel de bit sino que requiere un String. De esta manera, si ponemos le g, los nicos enemigos que aparecern sern goombas. Debemos destacar que esta opcin est definida de forma distina a la que viene en la pgina oficial del campeonato, que propone hacer mscaras de bits cuando aqu funcionan Strings concatenados. De esta manera las opciones que tenemos aqu (y son importantes a la hora de caracterizar si Mario reconoce bien a cada enemigo) son: 1. 2. 3. 4. 5. 6. g: para los goombas. gw: para los goombas voladores. rk: para los koopa rojos. gk: para los koopa verdes. s: para spiky. De igual manera que se hace para los goombas, si se le aade una w al final de cada cadena, se convierten en voladores.

De esta manera, si tenemos por ejemplo grkwgk en la pantalla lo que tendremos es enemigos que son, nicamente, goombas, koopas rojos voladores y koopas voladores. Parece trivial insistir en esto, pero no est bien documentado (hay que mirar el cdigo que da la competicin) y puede ahorrar ms de un quebradero de cabeza. -lg [on/off]: define si se quiere que haya gaps en nuestro nivel o no, es decir, si Mario puede morir por caer en un hoyo que no haya contemplado. -ltb [on/off]: define si queremos que haya tuberas en nuestro nivel (tuberas en las que pueden salir flores como las que se detallaron en el apartado 2).

-lc [on/off]: con esto podemos hacer que en la pantalla haya caones (de los que salen balas) o no. -ld <nmero>: define la dificultad del nivel. -lt <nmero>: define el tipo de escenario en el que queremos jugar: si es el estndar, en el castillo no tiene mucha ms repercusin en el nivel salvo el fondo de escenario. -ll <longitud>: con esto puedes especificar la longitud deseada del nivel. -ls <valor>: define la semilla del nivel. El nivel se genera aleatoriamente, pero los nmeros aleatorios dependen de una semilla; pues bien, con esto podemos cambiar la semilla generando tantos niveles distintos (con dificultad similar) como queramos.

No hemos probado muchos escenarios ms por falta de tiempo, aunque creemos que con el tiempo invertido los resultados de nuestro agente son razonablemente buenos y generales, puesto que sobrevive de manera admirable a ciertas pantallas que un humano no se pasara fcilmente, como hemos podido comprobar. De esta manera, el techo de nuestro agente est en un nivel de dificultad 4 tanto con enemigos (con koopas, aunque es lo mismo con goombas y con una combinacin de los dos) como sin ellos.

6.

REFERENCIAS.

[1] Pgina oficial de Mario AI Championship 2011: http://www.marioai.com/. [2] Historia del Pong: http://es.wikipedia.org/wiki/Pong. [3] Historia sobre Inteligencia Artificial: http://es.wikipedia.org/wiki/Inteligencia_artificial. [4] Historia sobre jugadores automticos de ajedrez: http://es.wikipedia.org/wiki/Ajedrez_por_computadora. [5] Reflexiones sobre la generacin gamer: http://www.cookingideas.es/como-motivar-a-la-generaciongamer-cambiando-las-notas-de-clase-por-puntos-deexperiencia-20110111.html. [6] Apuntes de la asignatura Inteligencia en Redes de Comunicaciones, 5 IT. [7] Informacin sobre el algoritmo A*: http://en.wikipedia.org/wiki/A*_search_algorithm. [8] Resumen de la primera competicin de Mario AI: http://en.wikipedia.org/wiki/A*_search_algorithm. [9] Agente basado en algoritmo A* (ganador de Mario AI 2009): http://www.youtube.com/watch?v=DlkMs4ZHHr8.

Con la adecuada manipulacin de esas opciones, observamos que nuestro agente es lo suficientemente inteligente para superar: El escenario por defecto. El escenario por defecto, con nivel de dificultad 2, slo goombas, con una semilla de 256 y una longitud de 200. El escenario por defecto, con nivel de dificultad 3, slo goombas, con una semilla de 985, con caones y con una longitud de 150. El escenario por defecto, sin enemigos salvo flores y balas, dificultad 4, con caones y tuberas. El escenario por defecto, con goombas voladores y no voladores, semilla de 3 y longitud de escenario de 150. El escenario por defecto con koopas verdes y rojos, semilla de 1780, nivel de dificultad de 1 y longitud de escenario 250. El escenario por defecto, con koopas verdes y rojos, semilla de 2, nivel de dificultad 4 y longitud de escenario de 145.

Columns on Last Page Should Be Made As Close As Possible to Equal Length

S-ar putea să vă placă și