M etodo de Monte-Carlo Tree Search (MCTS) para … · Monte-Carlo Tree Search independiente del...

$Page 1: M etodo de Monte-Carlo Tree Search (MCTS) para … · Monte-Carlo Tree Search independiente del problema y fuera usado para dotar de \inteligencia" al juego del ... Diagrama de tiempos$
Proyecto Final de CarreraIngenierıa Informatica

Curso 2011-2012

Metodo de Monte-Carlo Tree Search (MCTS)para resolver problemas de alta complejidad:

Jugador virtual para el juego del Go

Beatriz Nasarre Embid

Junio de 2012

Director: Dr. Francisco Seron ArbeloaCo-Director: Dr. Manuel Gonzalez Bedia

Departamento de Informatica e Ingenierıa de SistemasEscuela de Ingenierıa y Arquitectura

Universidad de Zaragoza


A todos los que haceis cumplir mis suenos

Todo aquello que hoy es una realidad,antes era solo parte de un sueno imposible

(William Blake)


Agradecimientos

Quiero agradecer a mis directores, Paco y Manolo su ayuda y dedicacion durante estos meses.Concretamente a Paco, por darme la oportunidad de trabajar este proyecto tan interesante, porla confianza depositada en mı y por todos tus consejos y a Manolo por transmitirme ese interespor los sistemas cognitivos.

Tambien quiero dar las gracias a mis amigos de clase que me han ayudado ano tras ano, dis-frutando de su companıa, compartiendo los buenos y malos momentos y dandome ese empujoncitocuando lo necesitaba.

Gracias a todos los que formais AEGEE por transmitirme siempre esa energıa, carino, motiva-cion, trabajo e ilusion.

Quiero agradecer tambien los Adebaneros el compartir conmigo esos buenos momentos.

Finalmente, dar las gracias a mi familia, por apoyarme siempre, estar ahı y ensenarme a lucharpor lo que quiero.


Derechos de autor

Los derechos de la presente obra pertenecen a Dª.Beatriz Nasarre Embid, al Dr.D.Francisco JoseSeron Arbolea y al Dr.D.Manuel Gonzalez Bedia, del Departamento de Informatica e Ingenierıa deSistemas de la Escuela de Ingenierıa y Arquitectura de la Universidad de Zaragoza.

Queda prohibida la reproduccion total o parcial de esta obra, por cualquier medio, sin el permisoescrito de los autores.


Ficha tecnica

Tıtulo Metodo de Monte-Carlo Tree Search (MCTS)para resolver problemas de alta complejidad:Jugador virtual para el juego del Go

Autora Beatriz Nasarre Embid

DNI 17754254

Especialidad Informatica

Directores Francisco Seron Arbeloa y Manuel Gonzalez Bedia

Departamento Departamento de Informatica e Ingenierıa deSistemas

Centro Escuela de Ingenierıa y Arquitectura

Universidad Universidad de Zaragoza

Fecha Junio 2012


i

Metodo de Monte-Carlo Tree Search (MCTS)para resolver problemas de alta complejidad:

Jugador virtual para el juego del Go

RESUMEN

La resolucion de ciertos tipos de problemas aun supone un reto para la Inteligencia Artificial.Algunos de ellos son los problemas de juegos, donde uno o varios jugadores compiten por lograrun mismo objetivo.

El Go es un juego de mesa estrategico para dos jugadores. Se origino en China y su historia seremonta hace mas de 2500 anos. A pesar de la simplicidad de sus reglas, el Go, supone aun un retopara la Inteligencia Artificial, incapaz de realizar mediante ordenador un jugador capaz de vencera los humanos expertos en el juego.

El metodo Monte-Carlo Tree Search (MCTS) estudiado, en contraste con los algoritmos clasicos,no necesita ninguna funcion heurıstica de evaluacion de posicion, ya que realiza una exploracionaleatoria del espacio de busqueda, construyendo gradualmente en memoria un arbol de juego atraves de los resultados de exploraciones anteriores. Este algoritmo resulta interesante para unagran cantidad de dominios, ha conseguido muy buenos resultados en problemas de juegos de todotipo, especialmente en el juego del Go.

En este proyecto se ha realizado la implementacion del juego del Go. Para ello se ha creado unaestructura logica que permite controlar de una forma mas facil las reglas del juego.

Un requisito importante del modulo del metodo Monte-Carlo Tree Search a implementar fueque se pudiese aplicar a distintos problemas, no solo al juego del Go. Este hecho, ha influido tantoen su estructura, diseno, como en las estrategias elegidas en el modulo implementado.

Tras la realizacion de este proyecto se ha conseguido un modulo que implementase el metodoMonte-Carlo Tree Search independiente del problema y fuera usado para dotar de “inteligencia”al juego del Go, permitiendo que el usuario se enfrentase a un jugador virtual. La aplicacioncreada permite realizar este enfrentamiento de forma grafica e interactiva gracias a su interfaz. La“inteligencia” del juego aun sin poder medirse puede apreciarse en las jugadas realizadas por elmismo, siendo todo un reto para personas no expertas en el juego.

El modulo MCTS desarrollado pretende usarse en alguno de los campos de trabajo en los queesta trabajando el Grupo de Informatica Grafica Avanzada (GIGA) de la Universidad de Zaragoza.Uno de ellos es el campo de los videojuegos, en el cual la Inteligencia Artificial esta cobrando cadavez mas importancia.


Indice general

1. Introduccion 11.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Juego del Go 32.1. Elementos del juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1. Tablero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2. Piedras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3. Jugadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1. Captura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2. Suicidio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3. Ko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3. Recuento de puntos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.1. Clasificacion de los jugadores . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4. Complejidad e Inteligencia Artificial . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Implementacion del juego del Go 113.1. Las clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2. El Go y el usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3. El Tablero y las Reglas del juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.1. Libertad del bloque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.2. Validez de una jugada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.3. Colocacion de una pieza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.4. Recuento de territorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4. Los Bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.1. La estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.2. Las operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4. Algoritmo MCTS 194.1. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2. El algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3. Las fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3.1. Seleccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3.2. Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3.3. Simulacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3.4. Retropropagacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4. Seleccion del movimiento final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iii

iv INDICE GENERAL

5. Implementacion del metodo MCTS 255.1. Las clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1.1. NodoUCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.1.2. Contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.1.3. SimulacionUCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.1.4. SimulacionUCTGo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2. Reutilizacion de simulaciones anteriores . . . . . . . . . . . . . . . . . . . . . . . . 30

6. Aplicacion 336.1. Esquema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2.1. Ventana Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2.2. Ventana de reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.3. Ventana de opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.4. Ventana de juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2.5. Tablero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.3. Valor del coeficiente UCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7. Conclusiones 397.1. Marco de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.2. Resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.3. Diagrama de tiempos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.4. Lıneas de trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.5. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.6. Valoracion personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

A. Gestion del proyecto 43A.1. Metodologıa de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43A.2. Fases del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A.3. Gestion de tiempo y esfuerzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.4. Supervision del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46A.5. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

B. Requisitos 49

C. Aplicaciones MCTS 51C.1. Deterministas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

C.1.1. Deterministas de un jugador . . . . . . . . . . . . . . . . . . . . . . . . . . 51C.1.2. Deterministas de dos jugadores . . . . . . . . . . . . . . . . . . . . . . . . . 52C.1.3. Deterministas multijugadores . . . . . . . . . . . . . . . . . . . . . . . . . . 52

C.2. Estocasticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52C.2.1. Estocasticos de un jugador . . . . . . . . . . . . . . . . . . . . . . . . . . . 52C.2.2. Estocasticos de dos jugadores . . . . . . . . . . . . . . . . . . . . . . . . . . 53C.2.3. Estocasticos de varios jugadores . . . . . . . . . . . . . . . . . . . . . . . . 53

C.3. Juegos de proposito general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

D. Ejemplo de simulacion 55D.1. La estructura del nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55D.2. Forma del arbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56D.3. Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

D.3.1. Primera iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56D.3.2. Segunda iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

INDICE GENERAL v

D.3.3. Tercera iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60D.3.4. Iteraciones de la cuarta a decima . . . . . . . . . . . . . . . . . . . . . . . . 61D.3.5. Decimoprimero iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61D.3.6. Iteraciones de la decimosegunda a la decimocuarta . . . . . . . . . . . . . . 62D.3.7. Decimoquinta iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62D.3.8. Decimosexta iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63D.3.9. Iteraciones de la de la decimoseptima a la vigesima . . . . . . . . . . . . . . 64D.3.10.Futuras iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

D.4. Eleccion del mejor nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66D.5. Numero de simulaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

E. Validacion 69E.1. Go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

E.1.1. Reglas y bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70E.1.2. Recuento de puntuaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

E.2. MCTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86E.2.1. Eficiencia del metodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86E.2.2. Avanzar cuando el arbol es vacıo . . . . . . . . . . . . . . . . . . . . . . . . 86E.2.3. Avanzar cuando el arbol es no vacıo . . . . . . . . . . . . . . . . . . . . . . 87E.2.4. Mezcla de las anteriores: Avanzar sobre arbol vacıo y no vacıo. . . . . . . . 88

E.3. Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89E.3.1. Pruebas de funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 89E.3.2. Pruebas de usabilidad e inteligencia del juego . . . . . . . . . . . . . . . . . 90

F. Manual de usuario 91F.1. Ventanas y navegacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91F.2. Ventana de inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92F.3. Ventana de opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92F.4. Ventana de juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93F.5. Ventana de reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Glosario 97

vi INDICE GENERAL

Capıtulo 1

Introduccion

El problema de busqueda en arboles es un problema en el cual los estados se representan comonodos de un arbol, y las acciones pueden ser representadas como ejes entre los nodos. Se defineun arbol como un grafo acıclico donde cada nodo tiene un conjunto de cero o mas nodos hijos, yal menos un nodo padre. 1 Distinguimos tres tipos de problemas relacionados con el mundo de losjuegos2[1, 2, 3]: 1) Problemas sin oponentes (llamados tambien problemas de optimizacion, juegosde un jugador o puzles); 2) Problemas con un oponente (juegos de dos jugadores, en los que selucha contra el oponente o se colabora con el) y 3) Problemas con multiples oponentes (juegosmultijugador donde se puede crear coaliciones).

Sin embargo, tambien se pueden clasificar segun intervengan algun elemento aleatorio (Pro-blemas estocasticos[5]) o no (Problemas deterministas[4]). La Tabla 1.1 muestra un esquema deejemplos para estos problemas.

Un jugador Dos jugadores Multi-jugadores

Determinista Problema del viajante Go, ajedrez Damas chinasEstocastico Problema de navegacion Backgammon Catan Simplificado

Cuadro 1.1: Problemas de busqueda en arboles

Un algoritmo de busqueda toma un problema (ej. un juego) como entrada y devuelve unasolucion en forma de una secuencia de acciones (ej. secuencia de movimientos). Muchos algoritmosde busqueda se han desarrollado durante el ultimo siglo. Durante decadas, el algoritmo αβ [6]hasido el estandar de la busqueda en arboles para juegos de dos jugadores. Este algoritmo requiere unafuncion de evaluacion3 para dar resultados satisfactorios. Sin embargo, esta funcion de evaluacionno esta disponible para el Go (juego elegido para el proyecto), donde el efecto de colocar una pieza essolo visible a largo plazo. Como consecuencia, los mejores programas de Go en 2005 utilizaron unacombinacion de la busqueda αβ, sistemas expertos, heurısticos y patrones, donde la metodologıausada era completamente dependiente del dominio. Una alternativa que emergio sobre esta epoca,fue usar las simulaciones de Monte-Carlo como alternativa a la funcion de evaluacion de posicion,que pronto darıa lugar a una nueva tecnica, el metodo Monte-Carlo Tree Search (MCTS) en espanol

Busqueda en Arbol de Monte-Carlo. En 2006 comenzaron a surgir las distintas versiones de estemetodo, segun las estrategias que se usasen en el. Hoy en dıa el metodo MCTS aun sigue siendotema de investigacion interesante.

1Russell and Norvin 19952Los problemas de juegos son aquellos en que uno o varios jugadores compiten por lograr un mismo objetivo.3Es una funcion que estima con un valor numerico cada una de las posiciones analizadas en algoritmos de

busqueda en arboles. [7, 8]

1

2 CAPITULO 1. INTRODUCCION

1.1. Contexto

Este proyecto ha sido desarrollado en el GIGA (Grupo de Informatica Grafica Avanzada) en laUniversidad de Zaragoza, utilizando las instalaciones del Laboratorio del Instituto de Investigacionde Ingenierıa de Aragon. El estudio del metodo Monte-Carlo Tree Search plateado pretende analizarlas posibilidades del mismo, con objeto de analizar su uso en otras de las ramas de trabajo delgrupo. El juego del Go se ha visto como un buen instrumento para la ilustracion y comprensiondel metodo. Hasta el momento, el grupo no habıa realizado ningun estudio previo en este campo,por lo que el codigo implementado no se apoya en otro anterior.

1.2. Objetivos

El objetivo del proyecto es la realizacion en lenguaje Java de un jugador virtual que sea capazde enfrentarse en el juego del Go a un jugador humano, aplicando el metodo MCTS. El proyectoconsta de cinco grandes tareas que pasamos a detallar a continuacion:

1. Estudio del juego del Go y el uso de la Inteligencia Artificial en el.

2. Estudio del metodo MCTS y sus diversas variantes.

3. Implementacion del juego del Go.

4. Implementacion del metodo MCTS, intentando que dicha implementacion sea lo mas generalposible, de cara a poder utilizarse en otros problemas interesantes para los directores de esteproyecto.

5. Implementacion de un programa que enfrente al usuario y al ordenador en el juego del Go.

El apendice B de requisitos se explica en mas detalle los objetivos de las tareas de implementacion.

1.3. Estructura del documento

El resto del documento se organiza de la siguiente manera: el capıtulo 2 presenta el juego delGo; el capıtulo 3 se explica la implementacion realizada de este; en el capıtulo 4 se explica el metodoMCTS; en el capıtulo 5 la implementacion de este; en el capıtulo 6 se explica la implementacionde la aplicacion y el capıtulo 7 muestra las conclusiones obtenidas.

Se incluyen como apendices:

1. Gestion de proyecto: incluye metodologıa del desarrollo, fases realizadas, gestion del tiempoy esfuerzos, supervision y herramientas utilizadas.

2. Requisitos: explica los objetivos de una manera mas detallada.

3. Aplicaciones MCTS: explica algunas de las aplicaciones del metodo MCTS y algunos de suslogros en estos campos.

4. Ejemplo de simulacion: explica paso a paso como se desarrolla una simulacion MCTS

5. Validacion: explica como se ha llevado a cabo la validacion y pruebas realizadas

6. Manual de usuario: contiene el manual de usuario de la aplicacion

Capıtulo 2

Juego del Go

El Go es el juego de mesa estrategico mas antiguo del mundo1. Millones de personas en Orientejuegan al Go, y en Occidente el numero de jugadores sigue creciendo. Podrıa decirse que el Go estan popular en Oriente como el ajedrez en Occidente. El objetivo del juego es simple: controlarterritorio y rodear al enemigo. Famoso por la simplicidad de sus reglas y la complejidad estrategicaque este esconde, el Go, se considera un elemento muy importante en la cultura oriental.

Hay mucho escrito sobre la historia del Go, su relacion con la ciencia, el arte, la filosofıa y laeducacion. Numerosos estudios demuestran que su aprendizaje y su practica facilitan el desarro-llo de la inteligencia, pensamiento logico, creatividad, habilidad para tomar decisiones acertadas,creacion de estrategias y muchas otras destrezas. Tanto es ası que el Go se ensena en West Point,la Academia militar estadounidense, y en universidades japonesas se permite el ingreso sin examena los jugadores de Go que acrediten un cierto nivel.[12]

En Japon, China, Corea y Taiwan algunos de sus jugadores profesionales gozan de un granprestigio nacional y ganan importantes sumas de dinero. Debido a la gran importancia de lascompeticiones de este juego, existen empresas dedicadas exclusivamente a retransmitir y analizarlos partidos de Go.

El Go ademas tiene su espacio en la cultura y la ciencia. Aparece en publicaciones (novelas,mangas, artıculos cientıficos y psicologicos...), television (series como Andromeda o Mentes crimi-nales, el anime Hikaru no Go ...), e incluso cine (The Go Master, Una mente maravillosa, Tron,The Valiant Ones ...) .[10]

Figura 2.1: Imagen de la pelıcula “Una mente maravillosa”

1Originado en China hace mas de 2500 anos

3

4 CAPITULO 2. JUEGO DEL GO

2.1. Elementos del juego

Para poder jugar se necesitan un tablero, las piedras o piezas y dos jugadores.

Figura 2.2: Partida de Go

2.1.1. Tablero

El Go se juega sobre un tablero cuadrado formado por una cuadricula de lıneas horizontales yverticales. El estandar es 19x19, pero se puede jugar con cualquier otro tamano. Los tamanos mascomunes para partidas rapidas suelen ser 9x9 o 13x13. El tamano preferido por los principiantes es9x9 ya que suele ser mas estimulante al inicio jugar mas numero de partidas que jugar una partidamuy larga. Por simplicidad en los ejemplos se ilustraran las reglas con tableros pequenos, comopuede ser uno de 5x5.

Una interseccion es un punto donde se cruza una lınea horizontal con una lınea vertical. Entableros grandes como 19x19 se marcan unos puntos de referencia sobre las intersecciones tal cualse observa en la Figura 2.3.

Figura 2.3: Tablero de 19x19

Dos intersecciones se dicen adyacentes si son distintas y estan conectadas por una lınea ho-rizontal o vertical sin ninguna otra interseccion entre ellas. La Figura 2.4 muestra a la izquierdados imagenes de intersecciones adyacentes y a la derecha una imagen de dos intersecciones noadyacentes.

2.1.2. Piedras

Las piedras son las fichas del juego. Cada jugador utiliza las piedras de un color (negro oblanco). Tradicionalmente se juega con 181 piedras negras y 180 piedras, esto es casi siempre masque suficiente, pero si llegasen a faltar podrıan usarse piedras extra. La forma de las piedras puedeapreciarse en la figura 2.5.

Las piedras se colocan sobre las intersecciones y una vez colocada una pieza esta no puedemoverse.

2.1. ELEMENTOS DEL JUEGO 5

Figura 2.4: Adyacencia de intersecciones.

Figura 2.5: Piedras

Las piedras verticalmente y horizontalmente adyacentes del mismo color forman un grupo.Para ser adyacentes deben estar conectadas por las lıneas de la cuadrıcula directamente, sin otrasintersecciones intermedias. La figura 2.6 muestra una situacion posible del tablero, donde cadanumero corresponde a un grupo diferente. Aparecen por tanto, cuatro grupos de piedras negras ycuatro grupos de piedras blancas.

Figura 2.6: Grupos de piedras.

Se llama libertad de una piedra a una interseccion libre adyacente a ella. Un grupo tiene laslibertades que tengan todas las piedras que lo conforman.

La Tabla 2.1 muestra las libertades que tiene cada grupo de piezas para la situacion del tableroreflejada en la Figura 2.7.

2.1.3. Jugadores

En Go compiten dos jugadores, llamados Negro y Blanco.

El Negro usara piedras de color negro y comenzara la partida.

El Blanco usara piedras de color blanco y tendra una puntuacion extra adicional por haberempezado mas tarde. Esta puntuacion extra es pactada antes del comienzo de la partida ytiene un valor decimal que impide el empate.

Si los jugadores tienen distinto grado, el jugador mas debil sera el Negro. Este podrıa colocar inclusopre-colocar varias piedras a modo de handicap antes de que comience el juego para compensar


Grupo 1 2 3 4 5 6 7Libertades c,d,h d,e,f,g,h g,h a,b c d,h f,e

Cuadro 2.1: Tabla de libertades para el ejemplo de Figura 2.7

Figura 2.7: Ejemplo de libertades

la diferencia de fuerzas. Este handicap normalmente suele consistir en comenzar la partida pre-colocando las piedras sobre los puntos de referencia del tablero mencionados en el apartado anterior.

Si los jugadores no se ponen de acuerdo acerca de los colores con que jugar, entonces unocualquiera coge una o varias piedras del monton y el otro jugador tiene que adivinar si el numeroes “par” o “impar”. Si lo acierta este jugador jugara con piedras negras y en caso de fallar jugaracon piedras blancas.

2.2. Reglas

La mecanica general del juego es la siguiente, la partida comienza con el tablero vacıo, primerojuegan Negras (jugador con piedras negras) y despues se juega alternativamente Blancas y Negras,como se observa en la Figura 2.8. Durante su turno, cada jugador puede colocar una pieza (piedra)o pasar (perder su turno). En competiciones el tiempo por turno esta delimitado y medido concronometro. La partida finaliza cuando los dos jugadores pasan consecutivamente, momento en elque se hace el recuento de puntos para ver quien es el ganador.

Figura 2.8: Ejemplo de inicio del juego

En cuanto a la colocacion de una piedra, las piedras se colocan sobre las intersecciones libresdel tablero siempre que no incumplan las reglas de suicidio y Ko, las cuales se explicaran masadelante. Ademas la colocacion de una pieza puede tener como efecto la captura de piedras deljugador contrario tal y como se explica a continuacion.

2.2.1. Captura

Una piedra o grupo de piedras se captura cuando al colocar una piedra del oponente se pierdela ultima libertad que la piedra o grupo poseıa, es decir, se queda sin intersecciones adyacentes

2.2. REGLAS 7

libres. La piedra o grupo de piedras capturado se elimina del tablero y se guarda hasta que lapartida finalice. Las figuras 2.9 y 2.10 muestran algunos ejemplos de captura.

Figura 2.9: Ejemplos de captura

La figura 2.9 contiene dos ejemplos en los que se captura una sola piedra blanca al colocar unapiedra negra sobre la interseccion a. En el ejemplo de la figura 2.10 la piedra colocada, sobre lainterseccion a, es de color blanco y produce la captura de un grupo formado por cuatro piedrasnegras.

Figura 2.10: Ejemplo de captura

2.2.2. Suicidio

No esta permitido la colocacion de una piedra que suponga la eliminacion de libertades de unapiedra o grupo de piedras del jugador que tenga el turno, ya que estas piedras morirıan y supondrıaun suicidio. La Figura 2.11 muestra un par de ejemplos de situaciones de suicidio, en los que colocarla piedra sobre la interseccion a supondrıa una auto-captura (suicidio) y por lo tanto no es unajugada valida.

La excepcion, es que en la jugada se capture piedras enemigas, porque quedarıan interseccionesadyacentes libres y la piedra colocada seguirıa viva. Esto se puede observar en la Figura 2.12;aparentemente al colocar la piedra negra sobre la interseccion a supondrıa la desaparicion delgrupo de negras, pero como las libertades del grupo de blancas desaparecerıan, el jugador Negroes el que captura al grupo de Blancas.

2.2.3. Ko

Los jugadores no tienen permitido hacer un movimiento que devuelva al juego a su posicioninmediatamente anterior, debido a que crearıa un ciclo y podrıa darse una situacion de Ko o infini-tud. Una vez realizado un movimiento distinto, el jugador podra realizar el movimiento prohibidoanteriormente si se diese la situacion.


Figura 2.11: Ejemplos de suicidio.

Figura 2.12: Ejemplo de captura con falso suicidio

La Figura 2.13 ilustra este concepto; inicialmente tenemos una situacion del tablero donde laultima piedra colocada es blanca distinta a b, seguidamente se coloca una piedra sobre la inter-seccion a. Si el jugador blanco colocase la piedra sobre la interseccion b, se volverıa a la situacioninicial, por lo tanto debe colocar su piedra en otro lugar. Despues de que juegue el jugador negrosi la interseccion b esta libre, el jugador blanco puede colocar su piedra sobre b.

Figura 2.13: Idea de Ko

2.3. Recuento de puntos

Una vez finalizada la partida (al pasar los dos jugadores consecutivamente), se toma la situaciondel tablero en ese momento y se procede al recuento de la puntuacion.

En la situacion final, una interseccion vacıa se dice que pertenece al territorio de un jugador siesta conectada solo con piedras de ese jugador (negras/blancas) o con intersecciones vacıas. Con laexcepcion de que cuando el tablero esta vacıo las intersecciones no pertenecen a ningun jugador.Cada jugador recibe un punto por interseccion vacıa dentro de su territorio.

Veamos un ejemplo, en la Figura 2.14 se muestra la situacion final de una partida sobre tablero9x9. En ella las intersecciones con letra a pertenecen al territorio del jugador negro y las intersec-ciones con letra b pertenecen al territorio del jugador blanco. La interseccion con letra c al estaren contacto con piedras de ambos jugadores no pertenece al territorio de ninguno. La puntuacion

2.3. RECUENTO DE PUNTOS 9

de territorios es de 18 para negras y de 14 para blancas. Esta puntuacion se utiliza en el calculode la puntuacion final.

Figura 2.14: Territorios

Existen dos modos de recuento: el japones y el chino; ambos emplean los territorios y la com-pensacion que posee el blanco2. En el japones se incluye las piedras capturadas y en el chino elnumero de piedras sobre el tablero. El cuadro 2.2 muestra las formulas de recuento de puntos paralos jugadores negro y blanco para el sistema japones y chino.

Negro Blanco

JaponesPtosTerritorioNegro

+ NºPiedrasBlancasCapturadas

PtosTerritorioBlanco+ NºPiedrasNegrasCapturadas

+ Compensacion

ChinoPtosTerritorioNegro

+ NºPiedrasNegrasEnTablero

PtosTerritorioBlanco+ NºPiedrasBlancasEnTablero

+ Compensacion

Cuadro 2.2: Formulas de recuento de puntos

Continuando con el ejemplo de la Figura 2.14, se calcula la puntuacion final para cada colorsegun los dos modos de recuento. Se sabe que al inicio de partida se pacto dar 2,5 puntos decompensacion al jugador blanco y que durante el transcurso de ella el jugador blanco capturo 3piedras negras y el negro 2 piedras blancas. Calculando la puntuacion final usando las formulasanteriores, tal y como muestra la Tabla 2.3, el jugador Negro ganarıa fuera cual fuera el sistemade puntuacion usado para el recuento.

Sistema/Jugador Negro Blanco

Japones 18+2=20 14+3+2,5=19,5Chino 18+26=44 14+22+2,5=38,5

Cuadro 2.3: Puntuaciones finales

2.3.1. Clasificacion de los jugadores

En Go, el rango de un jugador indica su habilidad en el juego. Los rangos se miden medianteun sistema de grados de kyu y dan, un sistema que tambien ha sido adoptado por diversas artesmarciales.

2Compensacion por haber empezado mas tarde, es decimal y se pacta al comienzo de la partida.


Los grados de kyu (abreviados k) son considerados grados de estudiante. Su numero disminuyea medida que el nivel de juego aumenta, de modo que el 1er kyu (equivalente a cinturon negro enartes marciales) es el grado de kyu mas fuerte. Los grados de dan (abreviados d) se considerangrados de maestro, y se incrementan de 1er a 7o dan. Los jugadores profesionales obtienen un gradoespecial de dan, el dan profesional (abreviado p), cuyo maximo grado es el 9o dan. El cuadro 2.4muestra los rangos del juego, donde 8d y 10p son tıtulos especiales.

Tipo de rango Rangos Etapa

kyu de doble dıgito 30-21k Principiantekyu de doble dıgito 20-11k Jugador ocasional

kyu de un solo dıgito 10-1k Intermedio/Jugador de clubdan Amateur 1-7d Jugador experto

dan Profesional 1-9p Profesionales

Cuadro 2.4: Rangos del Go

2.4. Complejidad e Inteligencia Artificial

El Go plantea un enorme desafıo para los programadores. Mientras que los programas de orde-nador de ajedrez mas fuertes derrotan a los mejores jugadores humanos (por ejemplo, el programaDeep Frit en 2006, ejecutandose en un ordenador portatil, batio al campeon mundial sin perderuna sola partida), los mejores programas de Go alcanzan solo el nivel de Dan amateur. ¿A que sedebe esto? 1) El numero de casillas del tablero es mucho mayor3; 2)El colocar una pieza en la faseinicial puede afectar al juego cientos de movimientos mas tarde (cosa que no sucede en el ajedrez);3) No existe forma sencilla de evaluar una posicion4; 4) Tiene caracterısticas que pueden ser leıdasmas facilmente por humanos que por ordenadores.5

Incluso los mejores programas de Go, siempre se ayudan de la paralelizacion y de ordenadorespotentes para poder realizar los calculos lo mas rapidamente posible. Los tableros pequenos de 9x9dejaron de ser un reto en 2008 cuando el programa MoGo fue capaz de ganar algunas partidascontra jugadores profesionales. Para tableros 19x19 este mismo programa fue capaz de vencer aciertos jugadores partiendo de la ventaja de 9 de handicap (maximo permitido), que le permitecolocar 9 de sus piezas antes de comenzar la partida. Poco a poco, han ido surgiendo distintosprogramas que enfrentandose a jugadores profesionales los van venciendo en partidas cada vez conhandicaps menores. En partidas sin handicap la cosa se complica, el mejor resultado se alcanzo enMarzo de 2012 el nivel obtenido fue de 6 dan (amateur).

3El numero de casillas del Go es de 361 en contraste con 64 del ajedrez; siendo el numero de movimientospermitidos por turno muy alto, y tambien las combinaciones posibles. Adelantarse ocho movimientos supondrıa 512quintillones de combinaciones posibles (5 dıas en los ordenadores mas potentes).

4En los juegos basados en captura (como ajedrez), normalmente una posicion puede ser evaluada relativamentetemprano calculando quien tiene una ventaja material o mas piezas activas. El Go es una excepcion.

5Aunque no hay rigurosas evidencias que garanticen esta hipotesis, parece que los rasgos que tiene el Go, hacenmas facil para los humanos la“lectura”(predecir posibles variaciones) de largas secuencias de movimientos, resultandoirrelevantes para un programa de ordenador.

Capıtulo 3

Implementacion del juego del Go

La solucion implementada ademas de las funcionalidades basicas del juego (poner pieza, pasar,obtener resultados), presenta unas funciones que permiten definir ciertos valores (tamano, tipo derecuento, penalizacion) antes de que se inicialice el juego. Si no se llamada a estas funciones, eljuego Go creado posee los valores por defecto.

En este bloque se presentan las clases implementadas, los estados del juego, las ideas generalesde implementacion de las reglas y el sistema de bloques que implementa los grupos.

3.1. Las clases

La figura 3.1 presenta el diagrama de clase del juego Go implementado. La importancia enel juego del concepto de grupo da lugar a dos clases llamadas Bloques y ConjBloques. Las reglasdel juego se controlan en la clase Tablero y las cuestiones mas generales en la clase Go. La clasepuntuacionGo se emplea simplemente como registro para almacenar el recuento de puntos.

Figura 3.1: Diagrama de clases del Go

11

12 CAPITULO 3. IMPLEMENTACION DEL JUEGO DEL GO

3.2. El Go y el usuario

La clase Go se encarga de interactuar con el usuario, permitiendole: cambiar las condicionesdel juego, jugar (colocando pieza o pasando) y obtener el resultado. Como es logico, no se podraobtener el resultado si aun no ha finalizado la partida, o cambiar las condiciones del juego una vezcomenzada esta. Podemos decir entonces que una partida de Go se encuentra en distintos estados,segun las acciones realizadas en el.

Las acciones principales que suponen el paso de un estado a otro son: 1) ColocarPieza(x,y)que coloca una piedra en la interseccion pasada por argumento, 2) Pasar() que pasa el turno y 3)NuevaPartida() que vacıa el tablero y da turno al jugador negro para comenzar una nueva partida.

El turno es otro tema importante. Las acciones de Pasar() o ColocarPieza(x,y) se aplican a unjugador segun sea su turno. En la implementacion se ha controlado que no se produzca un paso deturno cuando la accion no sea valida y que se asignen las piedras capturadas a un jugador u otrosegun corresponda el turno.

La Figura 3.2 muestra un diagrama con los distintos estados del juego segun las accionesrealizadas en cada momento. En el diagrama se pueden apreciar claramente las tres zonas deestados que se dan en el juego:

Figura 3.2: Diagrama de estados del Go

1. Inicio: En este estado es posible cambiar las condiciones iniciales. Desde el, se pasa al estado“Pieza colocada”si se realizan las acciones ColocarP ieza(x, y) o NuevaPartida(); o al estado“Pasar” si se realiza la accion Pasar(); al realizar cualquier otra accion se permanece en elestado de “Inicio”.

2. Juego: Es la zona central del diagrama, compuesta por dos estados: “Pieza colocada” y “Pa-sado”. El estado “Pieza colocada” indica que la ultima accion valida1 ha sido la colocacionde una pieza, y el estado “Pasado” indica que la ultima accion valida ha sido pasar. El pasode unos estados a otros corresponde con estas ideas, aunque se pasara al estado “Acaba-da” cuando se llame a Pasar() desde el estado “Pasado”, que correspondera con el fin de lapartida.2

1Corresponde a una jugada valida. Por ejemplo, si se intenta colocar la piedra en una posicion no correcta, seindica que esta no es valida pero se mantiene en el estado actual, ya sea “Pieza colocada” o “Pasado”.

2Una partida finaliza cuando se pasa dos veces consecutivas.

3.3. EL TABLERO Y LAS REGLAS DEL JUEGO 13

3. Acabada: En este estado la partida ya ha acabado y es posible obtener los resultados de esta.Si se llama a NuevaPartida() se volvera al estado de“Pieza colocada”descrito anteriormente.

3.3. El Tablero y las Reglas del juego

La clase Tablero es la clase central del juego, contiene la informacion de la posicion del tableroademas de los grupos que existen dentro de el. Se encarga de controlar todo el proceso de colocacionde pieza, captura, suicidio y Ko. Podemos decir que es, en sı, el cuerpo del juego. Sus unicoscomponentes son:

Una matriz de juego: Es una matriz cuadrada de enteros que representa el tablero real deljuego. Segun el valor del entero se indica que la interseccion o posicion esta libre u ocupadapor una piedra de un color. La figura 3.3 muestra la matriz de juego para una situacionconcreta del tablero, en la implementacion realizada el valor 0 corresponde a la interseccionvacıa, 1 a la piedra negra y 2 a la piedra blanca .

Figura 3.3: Matriz del juego.

Una matriz estado anterior : que no es mas que una matriz de las mismas caracterısticas quela anterior, que guarda el estado anterior del tablero y se utiliza para poder satisfacer la regladel Ko.

Un conjunto de bloques: que guarda todos los bloques del tablero. Este conjunto de bloquesdebe actualizarse cada vez que se realice una modificacion sobre la matriz anterior para sercoherente con el juego y es muy util a la hora de comprobar la posibilidad de colocacion deuna pieza, captura, suicidio y en sı todas las acciones que necesiten comprobar las libertades.Esta clase se explica en el apartado 3.4.

3.3.1. Libertad del bloque

En muchas ocasiones necesitamos saber si un bloque es libre o no. Por ello la funcion Bloque-Libre, a partir de una posicion del tablero, mira si el bloque de esa piedra es libre. Para ello vacomprobando para cada una de las posiciones que lo componen si alguna tiene una interseccionadyacente libre hasta encontrar alguna. Si encuentra alguna el bloque completo sera libre y sino,no lo sera.

3.3.2. Validez de una jugada

La funcion de JugadaValida comprueba si de acuerdo a las reglas del Go es posible colocar lapieza o no. Devuelve un entero en vez de un booleano para ası poder precisar si el motivo de que


la jugada no sea valida es que es un suicidio o es Ko. El algoritmo 3.1 muestra el pseudocodigo deesta funcion.

Algoritmo 3.1 Pseudo-codigo de Jugada validaDatos: fila, columna, color

Resultado: entero/* ¿Esta dentro del tablero?*/

si (!DentroTablero(fila,columna)) devuelve FALSE; FinSi/* ¿Esta libre?*/

si (!EstaLibre(fila,columna)) devuelve FALSE; FinSi/* ¿Es suicidio?*/

si (EsSuicidio(fila,columna,color)) devuelve SUICIDIO; FinSi/* ¿Es Ko?*/

si (EsKo(fila,columna,color)) devuelve KO; FinSi/* Todo correcto */

devuelve TRUE;

Suicidio: Para comprobar si es suicidio o no, primero se coloca temporalmente la piedra en lamatriz de juego, pero no en el conjunto de grupos y antes de devolver la solucion se vuelve adejar la casilla vacıa. Esto permite comprobar de forma sencilla las consecuencias que tendrıaesta jugada. Primero se comprueba si mata a otros, en caso afirmativo no serıa suicidio.Segundo, en el caso de no matar a otros, se comprueba si tiene libertad. En caso de no tenerlibertad estarıamos en un suicidio. Para comprobar si tiene libertad lo que se hace es mirarsi alguna de sus intersecciones adyacentes es libre o si alguno de sus bloques adyacentes eslibre.

Ko: Para comprobar si se da la situacion de Ko, se coloca la pieza en el tablero (trabajandosobre una copia) y si el tablero de esta coincide con la matriz de estado anterior tendremosuna situacion de Ko y la jugada no sera valida.

3.3.3. Colocacion de una pieza

La funcion ColocarPieza(x,y) tiene como precondicion que la jugada sea valida y realiza lasacciones correspondientes a la colocacion de una pieza:

1. Actualizacion de los tableros: Copia la matriz de juego sobre la matriz de estado anterior, yactualiza sobre la matriz de juego la posicion correspondiente con el tipo de piedra dado.

2. Union de la pieza al conjunto de bloques: Comprueba si los bloques adyacentes son del mismotipo y en funcion de ello crea un bloque nuevo, se une a uno ya existente o fusiona varios si seencuentra en la posicion de union. En la figura 3.4 se pueden observar las situaciones posiblescuando es turno de blancas. Colocando la piedra blanca en la posicion a, se crearıa un bloquenuevo, colocandola en la posicion b se unirıa a la piedra blanca de abajo, colocandola enla posicion c unirıa los bloques izquierdo y derecho y colocandola en la posicion d unirıa elbloque de abajo y el de su derecha.

3. Captura: Finalmente se comprueba si se captura alguno de los grupos del oponente, viendosi en las posiciones adyacentes hay bloques no libres. En caso afirmativo, se eliminan delconjunto de bloques los bloques capturados, poniendo las casillas correspondientes comolibres y devuelve el recuento de las piezas capturadas.

3.4. LOS BLOQUES 15

Figura 3.4: Union de la pieza al conjunto de bloques

3.3.4. Recuento de territorios

Para el recuento de territorios lo primero que se hace es crear bloques con los grupos de inter-secciones libres conectados entre si y luego para cada uno de ellos se comprueba si estan rodeadospor piedras de un solo color o ambas. En funcion del resultado se sumaran o no a la puntuacionde cada color. La clase PuntuacionGo es un registro que permite que se devuelvan los valores delos dos colores usando una unica funcion.

3.4. Los Bloques

En el juego del Go, los grupos formados por la conexion entre piedras juegan un papel funda-mental, por ello, se han implementado unas clases particulares que los gestionen. En este apartadoprimero se explica la estructura usada para la gestion de los bloques, profundizando en cada unade las clases y posteriormente el funcionamiento de algunas de las operaciones llevadas a cabo conlos bloques.

3.4.1. La estructura

La gestion de los bloques es una tarea complicada. Para cada una de las acciones propuestaspor el usuario no se debe recalcular todos los grupos, sino que se necesita un registro que puedaalmacenarlos y conservarlos. La clase implementada ademas permite acceder rapidamente al grupode cada pieza y se usa para realizar comprobaciones de libertad de grupos.

Se han implementado dos clases, una clase Bloques, que representa en si un grupo de tableroy una clase ConjBloques que almacena todos los grupos o bloques existentes y se encarga degestionarlos eficientemente. Veamos en detalle en que consiste cada una de ellas:

Bloques: Esta clase representa un grupo del tablero. De forma que un bloque contiene todaslas posiciones (x,y) que ocupan las piedras que forman el grupo, podemos ver un ejemplo enla figura 3.5.

ConjBloques: Esta clase se apoya en la clase anterior para gestionar todos los bloques quehay sobre el tablero. Esta formada por los siguientes elementos:

� Un vector de bloques: Es un vector que contiene todos los bloques o grupos que haysobre el tablero.

� Una matriz de bloques: Es una matriz del mismo tamano que la matriz de juego dondecada uno de sus elementos indica la posicion que ocupa el bloque de esa pieza en elvector de bloques. Si una posicion concreta no pertenece a ningun grupo, es que lacasilla esta vacıa y se marca con -1. Para comprenderlo mejor fijemonos en la Figura3.6, donde las piedras conectadas entre si poseen el mismo valor en la matriz de bloques


Figura 3.5: Un bloque representa un grupo de piedras del tablero

Figura 3.6: Estructura de almacenamiento de los grupos de piezas

ya que pertenecen al mismo grupo. La interconexion entre la matriz de bloques y elvector de bloques es lo que da rapidez al sistema a cambio de necesitar un trabajo demantenimiento.

3.4.2. Las operaciones

Debido a la simplicidad de los metodos de la clase bloques (anadir una piedra al bloque, com-probar si una piedra esta dentro de el u obtener la piedra que ocupa la posicion i del bloque), nosvamos a centrar en las operaciones de la clase ConjBloques. Dentro de la clase ConjBloques vamosa ver las acciones que modifican la informacion de los bloques, y por tanto necesitan una gestionque mantenga la consistencia de la estructura:

Figura 3.7: Crear Bloque

Crear bloque: Crea un nuevo bloque con la posicion dada, lo anade al final del vector debloques y actualiza la matriz de bloques con el valor correspondiente. La figura 3.7 ilustra

3.4. LOS BLOQUES 17

con un ejemplo de colocacion de una piedra blanca sobre la posicion 0,2 partiendo de la figuraanterior.

Anadir a bloque: A partir de una posicion y un ındice del bloque, busca el bloque con esteındice y anade la posicion dada a este, luego actualiza la matriz de bloques con el ındicedel bloque. La figura 3.8 muestra el efecto de colocar una piedra negra sobre la posicion 1,3partiendo de la figura anterior.

Figura 3.8: Anadir a Bloque

Eliminacion de bloque: A partir del ındice del bloque, se elimina este del conjunto de bloquesy se actualizan los valores de la matriz de bloques. La actualizacion consiste en poner comovacıas todas las posiciones que tengan como valor el ındice del bloque y decrementar enuna unidad todas cuyos ındices sean superiores al ındice del bloque eliminado. La figura 3.9muestra el ejemplo de eliminacion del bloque 7 partiendo de la figura anterior. Observamosque el bloque 8 al tener un ındice superior a 7 se decrementa su ındice en la matriz de bloques.

Figura 3.9: Eliminacion de un bloque


Fusion de bloques: Fusiona el bloque i con el bloque j, siendo estos distintos. Es decir, copialos elementos del bloque j sobre el bloque i, elimina el bloque j y actualiza los valores de lamatriz de bloques. En esta matriz se decrementan en una unidad los valores que sean mayoresque j, se actualizan los valores de j a i (si i<j) o a i-1 (si i>j). La figura 3.10 muestra el pasode colocar una piedra negra sobre la posicion 0,2 partiendo de la figura anterior. Esta piedrasera el punto de union entre los bloques 0 y 2. Como primer paso, se anade al primer bloque(bloque 0) y como segundo se realiza la fusion entre los bloques 0 y 2. Depende como llamemosa la funcion tenemos los dos casos explicados. En el primero con i = 0 < j = 2, la fusionse realiza primero anadiendo los elementos del bloque 2 al bloque 0, segundo eliminando elbloque 2 del vector de bloques y finalmente actualizando los valores de la matriz de bloquesde los bloques con ındice mayor o igual a dos. Para i = 2 > j = 0, la fusion se realizaprimero anadiendo los elementos del bloque 0 al bloque 2, segundo eliminando el bloque 0del vector de bloques y finalmente actualizando los valores de la matriz de bloques de losbloques con ındice mayor o igual a cero, es decir, todos los bloques no vacıos. Al ser i>j elbloque resultante pasa a tener ındice 1 en vez de ındice 2.

Figura 3.10: Fusion de bloques

Capıtulo 4

Algoritmo MCTS

Monte-Carlo Tree Search (MCTS) es el primer metodo de busqueda que no requiere una funcionde evaluacion de posicion[7, 8], en contraste con la busqueda αβ[6] . Esta basado en una explo-racion aleatoria del espacio de busqueda, pero usa los resultados de previas exploraciones. Paraello MCTS construye gradualmente un arbol en memoria, que mejora sucesivamente estimando losvalores de los movimientos mas prometedores. MCTS es aplicable si al menos se satisfacen estastres condiciones: 1) La puntuacion del juego esta acotada; 2) Las reglas son conocidas (informa-cion completa[18]) y 3) Las simulaciones terminan relativamente rapido (la longitud del juego eslimitada).

Gracias a la estructura de arbol y un alto numero de simulaciones aleatorias, el metodo MCTSpuede estimar a largo plazo el potencial de cada movimiento. La tecnica MCTS se ha incorporadorecientemente en algoritmos para juegos, obteniendo bastantes buenos resultados. Se utiliza en:Problemas de gestion, optimizacion de rendimiento en bibliotecas, SameGame, Morpion Solitario,Dominio de Navegacion, El juego de las amazonas, Lines of Action (LoA), Damas chinas, Colonosdel Catan, Juegos de proposito general, y en particular, el Go. Desde un punto de vista masglobal, el MCTS es tambien atractivo para muchos mas dominios en los que se necesita mejorarel “atasco en la adquisicion de conocimiento”. Los detalles de las aplicaciones del algoritmo y loslogros mejorados se explican con mas detalle en el apendice C.

En esta seccion se presentan la estructura del arbol y las cuatro etapas principales del MCTS:seleccion, expansion, simulacion y retropropagacion. Cada etapa tiene asociada una estrategia,implementada con una polıtica especıfica.

El apendice D muestra con detalle un ejemplo de simulacion para el juego del Go, en el que sepuede seguir visualmente cada una de las fases con objeto de facilitar la comprension del mismo.

4.1. Estructura

Una partida se representa como un arbol, en la que cada nodo corresponde a un estado parti-cular. El nodo raız representa la posicion de inicio de partida. Los hijos de cada nodo son estadosalcanzables en un movimiento.

En un arbol MCTS cada nodo i representa una posicion alcanzada (tambien llamado estado)de una partida. Un nodo contiene al menos las siguientes informaciones:

� vi es el valor actual de la posicion, dependiendo el problema representara una cosa u otra.� ni es el contador de visitas que ha sufrido esa posicion.� Ci es el contenido asociado al problema concreto en el que estemos trabajando, que representa

un movimiento realizado desde el estado del nodo padre.Por ejemplo para el juego del Go, cada contenido Ci representa una jugada (colocacion de

piedra en una interseccion concreta o pasar), vi el numero de partidas ganadas desde ese nodo.

19

20 CAPITULO 4. ALGORITMO MCTS

Figura 4.1: Estructura MCTS

4.2. El algoritmo

MCTS consiste en cuatro pasos principales, repetidos tantas veces como tiempo disponible haya.En una de las iteraciones se parte de la situacion inicial de la partida (situacion de la partida en elmomento de la simulacion), pero se conserva el arbol MCTS, completandose durante las distintasfases y simulaciones.

Figura 4.2: Esquema general MCTS

Las fases del algoritmo son las siguientes:� Seleccion: El arbol se recorre desde el nodo raız hasta alcanzar un nodo hoja.� Expansion: Se anaden nodos al arbol MCTS segun una estrategia de expansion.� Simulacion: Se realiza una partida simulada partiendo del nodo o estado alcanzado en las

fases anteriores. Durante esta partida simulada, el programa juega solo, realizando los movimientosde todos los jugadores que intervienen hasta que la partida finalice y se obtenga un resultado, conel que actualizara los valores del nodo.

� Retropropagacion: El resultado de la simulacion se propaga hacia los nodos atravesados pre-viamente.

Cuando el tiempo o numero de simulaciones haya finalizado, el movimiento elegido en el pro-grama sera el mas prometedor teniendo en cuenta la informacion almacenada.

El pseudocodigo del MCTS se muestra en el Algoritmo 4.1. En este, A es el arbol que con-tiene todos los nodos del arbol de busqueda. Seleccionar(NodoN) es el procedimiento que de-vuelve un hijo del nodo N . Expandir(NodoN) es el procedimiento que anade segun las estra-tegia de expansion los nodos al arbol, devolviendo el nodo desde el que realizar la simulacion.JugarPartidaSimulada(NodoN) es el procedimiento que realiza una simulacion de la partidadesde el nodo devuelto en la expansion y devuelve un resultado R. Retropropagacion(IntegerR)

4.3. LAS FASES 21

Algoritmo 4.1 Pseudocodigo del MCTSDatos: nodoRaiz

Resultado: mejorMovimiento

MientrasQue (haya_tiempo) hacer

nodoActual←nodoRaiz/* Seleccion */

MientrasQue (nodoActual∈ A)hacernodoActual←Seleccionar(nodoActual)

Fin/* Expansion del nodo */

nodoActual←Expandir(nodoActual)/* Simulacion de una partida*/

R←JugarPartidaSimulada(nodoActual)/* Retropropagacion del resultado */

MientraQue(nodoActual∈ A)hacerRetropropagacion(nodoActual, R)nodoActual =nodoActual.padre

Fin

Fin

Devuelve mejorMovimiento =MejorHijo(nodoRaiz)

es el procedimiento que actualiza el valor del nodo dependiendo del resultado R de la ultima partidasimulada. MejorHijo(NodoN) devuelve el hijo mas prometedor segun los valores de estos.

En los siguientes apartados se explica detalladamente cada una de las fases y la seleccion delmovimiento final.

4.3. Las fases

Como hemos visto, el metodo MCTS repite una serie de pasos o fases hasta llegar a un numerode simulaciones o tiempo dado. En este apartado, analizaremos cada una de las fases ası comodistintas estrategias a seguir en cada una de ellas.

La explotacion y exploracion del espacio de busqueda son elementos clave de cualquier metodode busqueda y optimizacion. Mientras la explotacion guıa la busqueda hacia las mejores solucionesencontradas hasta el momento, la exploracion favorece el descubrimiento de regiones sin explorar yevita una convergencia antes de tiempo. Lograr un balance entre estos dos objetivos es un problemade vital importancia que enfrentan la mayorıa de las tecnicas de busqueda y optimizacion actuales.

4.3.1. Seleccion

Figura 4.3: Seleccion


En la fase de seleccion, se avanza desde la raız del arbol hasta alcanzar un nodo hoja tal y comomuestra la Figura 4.3.

Se toma una rama u otra dependiendo de la estrategia de seleccion que se emplee y la informa-cion almacenada en el nodo en ese momento, como el valor y el numero de visitas.

A continuacion se detallan algunas de estas estrategias:

OMC (Objective Monte-Carlo): Donde se calcula la urgencia 1 de cada uno de los movimientos(nodos) posibles y se juega un movimiento u otro segun los valores de urgencia calculados yel numero de visitas realizadas.

PBBM (Probability to be Better than Best Move): Similar a la anterior, pero tiene en cuentala desviacion tıpica[22] del mejor movimiento a la hora de calcular la urgencia.

UCT (Upper Confidence bounds apllied to Trees): Es la estrategia mas usada y ha dado lugara diversas variantes. La estrategia UCT calcula para cada uno de los movimientos posiblesuna combinacion de dos valores, la tasa de exito de ese nodo y un numero asociado a larelacion del numero de veces que se ha visitado el nodo en relacion a un nodo padre. El valorde la tasa de exito esta relacionado con la explotacion y el valor del numero asociado estarelacionado con la exploracion. Dependiendo del coeficiente empleado en la combinacion deambos valores, se puede dar mayor prioridad a la explotacion o a la exploracion.

Todas estas estrategias de seleccion, son independientes del juego y no usan ningun dominio delconocimiento. La estrategia UCT es una de las mas usadas debido a su simplicidad y eficiencia.Por ello, es la que se ha usado en la implementacion realizada.

4.3.2. Expansion

El paso de expansion anade nodos al arbol MCTS. En la mayorıa de los problemas en los que noes posible almacenar en memoria el juego completo es necesario poseer una estrategia de expansion.

Segun cuando se expande podemos encontrar estas dos estrategias:

Siempre: Se expande sea cual sea las veces visitadas

Al alcanzar un nº de visitas: Se expande solo cuando se alcanza un numero mınimo MINde visitas ni.

Figura 4.4: Modelo de expansion

La no expansion hasta que no se alcance un numero mınimo de simulaciones, permite ahorrarespacio en memoria, pudiendo evitar en muchos casos crear ramas innecesarias. El nodo raız setrata como un caso especial, al reflejar la situacion de partida no es util realizar simulacionesdirectamente sobre el, por lo que siempre se expande. La Figura 4.4 muestra el esquema en donde

1Es un valor proporcional a la probabilidad de que un movimiento sea mejor al actual mejor movimiento[1]

4.3. LAS FASES 23

el nodo hoja Ni solo se expande si el numero de visitas ni alcanza un mınimo MIN . En el caso deexpandirse, puede crear un solo hijo o todos ellos tal y como explicamos a continuacion.

Segun el numero de hijos a expandir se tienen estas dos estrategias:

Crear un solo hijo: Ocupa menos memoria, pero durante cada iteracion del proceso de se-leccion se debera calcular si hay mas movimientos posibles que partan de ese nodo y no hansido anadidos, lo que supone una carga de procesado considerable.

Crear todos los hijos de golpe: Ocupa mas espacio en memoria, pero solo se calculan todoslos movimientos posibles alcanzables desde el nodo actual una vez. En este caso se debeseleccionar un nodo cualquiera de los creados, desde el cual se realizara la simulacion.

En la implementacion realizada se ha decidido expandir todos los nodos de golpe cuando se hayavisitado el nodo un numero mınimo de veces.

4.3.3. Simulacion

A partir del nodo hoja Ni dado por la fase anterior, se realiza una partida simulada. Duranteesta partida simulada, el programa juega solo, realizando movimientos de todos los jugadores queintervienen de forma aleatoria hasta que la partida finalice y obtenga un resultado R. Podemos vereste proceso en la Figura 4.5.

Figura 4.5: Actualizacion de valores

Las estrategias que se utilizan consisten o bien utilizar los movimientos aleatorios o combinar laaleatoriedad con una heurıstica asociada al problema concreto. En estos casos es necesario buscarun equilibrio entre la exploracion, que da la aleatoriedad, y la explotacion, que dirige hacia unmovimiento mas prometedor.

Debido a que se desea generar un algoritmo MCTS generico independiente del problema, se hadecidido utilizar la estrategia aleatoria.

4.3.4. Retropropagacion

En el paso de Retropropagacion se realiza la actualizacion de los valores de los nodos, actua-lizando primero el nodo hoja, luego el nodo padre de este y ası consecutivamente hasta alcanzarla raız del arbol, tal y como muestra la Figura 4.6. La actualizacion de cada nodo, consiste enincrementar en una unidad el numero de visitas ni y actualizar su valor vi usando el resultado Rde la simulacion.

Veamos distintas estrategias existentes de actualizacion del valor vi de un nodo:

Simples: Se actualiza en funcion unicamente del resultado obtenido.

Max: Adquiere el valor maximo de sus hijos.

Media: Adquiere la media de sus valores hijos.


Figura 4.6: Retropropagacion

Mezcla: Combina las estrategias de valor maximo y media.

MCTS-Solver: Considera a un nodo ganador si alguno de sus hijos lo es y perdedor si todossus hijos lo son.

En este proyecto se ha seleccionado el metodo “Simple”, dadas las caracterısticas del problemaseleccionado, el juego del Go.

4.4. Seleccion del movimiento final

Despues de las simulaciones, es el momento de elegir el mejor movimiento a realizar, la eleccionvendra dada por el “mejor hijo” de la raız. Hay distintas formas de elegir que hijo es el mejor:

1. Valor maximo: Es el hijo que tenga el mayor valor vi.

2. Mas robusto: Es el hijo que tiene un mayor contador de visitas ni.

3. Robusto-Valor maximo: Es el hijo que tiene tanto el mayor valor vi , como el numero devisitas ni.

4. Mas seguro: Es el hijo que maximiza un lımite inferior del intervalo de confianza[23, 1].

Segun el problema puede ser mas conveniente usar un metodo u otro. Experimentos aplicadosal Go relacionados por expertos con los distintos metodos muestran que no hay una diferenciasignificativa entre ellos si hay un suficiente numero de simulaciones por movimiento jugado. Sinembargo, si el tiempo de simulacion por movimiento es corto (ej. 1 seg), la eleccion por Valormaximo da unos resultados significativamente peores que el resto de los metodos.

La seleccion elegida en este proyecto ha sido la de “Mas robustez”, porque su simplicidad deimplementacion, menor consumo de tiempo y por presentar mismas prestaciones que otros metodosal aplicarse al juego del Go.

Capıtulo 5

Implementacion del metodoMCTS

En esta seccion se explica la solucion final desarrollada. Recordemos que uno de los objetivosera que el modulo del metodo MCTS a implementar fuese generico, de forma que pudiese aplicarsea distintos problemas, no solo al juego del Go.

Si se quiere conocer en mas detalle como ha sido la evolucion seguida en la implementacion delmetodo, en el apendice A se describe la metodologıa seguida y los grandes pasos dados antes dellegar a la solucion final.

5.1. Las clases

La Figura 5.1 muestra el diagrama de clases MCTS del metodo MCTS implementado.Veamos mas a fondo cada una de las clases, sin entrar en detalle en la clase Go ya explicada en

la seccion anterior.

5.1.1. NodoUCT

Esta clase representa un nodo del arbol MCTS. Con la referencia al nodo padre y a los nodoshijos que el nodo posee se consigue la estructura del arbol MCTS necesaria para realizar lassimulaciones. Este nodo, es un nodo generico y debe instanciarse en el momento de su creacion,tanto el tipo de contenido (asociado a las acciones o movimientos del problema a resolver) comoel tipo de valor (que debe ser de tipo numerico y se usara en las distintas fases del metodo).

La figura 5.2 muestra la representacion grafica del nodo que implementa la clase.

5.1.2. Contenido

La clase Contenido, ilustrada por la figura 5.3, no es mas que una estructura con la que seinstanciara al nodo del arbol MCTS y que representa una accion asociada al juego del Go: Pasaro colocar una pieza en una posicion concreta.

Esta estructura esta formada por un booleano que indica si la accion es pasar (en caso de ser elbooleano cierto) o colocar una pieza (en caso de ser booleano falso) y por dos valores enteros (x,y)que indican donde la pieza seria colocada.

El tipo valor en el caso del juego del Go representa el numero de partidas ganadas (representadaspor un entero). Por lo que el nodo se instancia con el tipo entero para el tipoValor y con el tipoContenido para el tipoContenido.

25

26 CAPITULO 5. IMPLEMENTACION DEL METODO MCTS

Figura 5.1: Diagrama clases MCTS

Figura 5.2: Representacion grafica del nodo

5.1.3. SimulacionUCT

En el capıtulo 4 se explico el algoritmo MCTS, sus principales estrategias en las distintas fases ylas opciones elegidas. El cuadro 5.1 muestra una recapitulacion de estas estrategias y las solucioneselegidas. Las estrategias elegidas son: UCT para la fase de seleccion, expandir creando todos losnodos al alcanzar un numero mınimo de visitas en la fase de expansion, actualizar los valores delos nodos usando solo el resultado proporcionado por la simulacion o nodos anteriores en la fase deretro-propagacion y usar la estrategia de robustez para la seleccion del movimiento final a realizar.

La solucion implementada presenta unas funciones que permiten definir el valor del coeficienteUCT y nº de simulaciones antes de expandir. Si no se llama a estas funciones se usan los valorespor defecto.

Debido a que se pretende dar al metodo un caracter general para que pueda utilizarse endistintos problemas, se han creado un numero importante de funciones abstractas. Estas funcionesse deben implementar en las clases hijas (en nuestro caso en la clase SimulacionUCTGo) y debenimplementar la funcionalidad que se requiera asociada al problema que quiera resolver (en nuestrocaso es el juego del Go). Estas funciones suelen ser bastante simples, pero son de gran importancia.

5.1. LAS CLASES 27

Figura 5.3: Contenido del nodo para el juego del Go

Estrategias Elegido

Seleccion - OMC- PBBM- UCT- UCB-TUNED

UCT

Expansion ¿Cuando?- Siempre- Al alcanzar un nº min de visitas¿Cuanto?- Hijo por juego simulado- Todos los hijos de golpe

Al alcanzar un nº min devisitas.

Crear todos los hijos degolpe.

Simulacion - Movimientos aleatorios- Movimientos pseudo-aleatorios

Aleatorios

Retropropagacion - Simples- Max- Media- Mix- MCTS-Solver

Simple

Movimiento final - Valor maximo- Mas robusto- Robusto-Valor maximo- Mas seguro

Mas robusto

Cuadro 5.1: Recapitulacion de soluciones elegidas

Veamos ahora con mas detalle la implementacion de cada una de las cuatro fases del metodo:

Seleccion: El algoritmo UCT que sirve para seleccionar un nodo u otro tiene en cuenta unatasa de exito del nodo y un numero relacionado con el numero de visitas. Ambos valorestendran como valor mınimo cero. En cuanto al calculo de la tasa de exito, dependiendo delproblema, se pueden considerar mas favorables unos valores u otros, por lo que no hay unaforma general de calcularla. La figura 5.4 muestra algunos ejemplos de casos posibles y suscorrespondientes implementaciones de la funcion que calcula la tasa de exito.

Expansion: Como ya se ha dicho, el nodo se expande solo al alcanzar un numero mınimode visitas (numero definido antes de que comience la primera iteracion). Veamos como selleva a cabo esta expansion. Tal y como muestra la figura 5.5, se anaden solo los movimientos(contenidos) que sean validos a partir del estado actual. Para ello se crea una funcion abstractaque devuelve las posibles acciones en una lista de contenidos. Se crearan tantos nodos hijoscomo contenidos haya devuelto esta funcion, poniendose el contador de visitadas a 0 y elvalor del nodo con un valor numerico inicial (indicado tambien por otra funcion abstracta).Se tomara uno de ellos de manera aleatoria para continuar con la fase de simulacion si elnodo no se ha expandido.


Figura 5.4: Ejemplos de implementacion de la funcion TasaExito

Figura 5.5: Expansion implementada

Simulacion: La fase de simulacion consiste en realizar una simulacion aleatoria para obtenerun resultado. El algoritmo 5.1 muestra el pseudocodigo de la simulacion aleatoria, las cuatrofunciones que aparecen en el son abstractas ya que dependen del problema concreto. Se haincluido la funcion de inicio de la simulacion, ya que, en ocasiones es necesario realizar algunasinicializaciones o almacenar cierta informacion para la obtencion correcta del resultado (porejemplo el turno en el caso del Go).

Algoritmo 5.1 Pseudo-codigo Simulacion AleatoriaResultado: tipoValor

InicioSimulacionAleatoria();

MientrasQue (NoAcabadaSimulacion()) hacer

RealizarAccionAleatoriaEnSimulacion();

Fin

Devuelve Resultado();

Retropropagacion: Consiste en propagar el resultado obtenido en la fase de simulacion, desdeel nodo hoja hasta la raız del arbol. Para ello deberemos actualizar el contenido de los nodos:Incrementando en uno el contador de visitas y actualizando el valor de este. El nuevo valorsera calculado en una funcion abstracta y dependera del problema que se este resolviendo,del resultado obtenido en la simulacion y del valor anterior del nodo, tal y como muestra lafigura 5.6.

Ademas el valor propagado al nodo padre puede variar tambien dependiendo del problema,por lo se usara una funcion abstracta para que indique cual es el valor. La propagacion serealiza de la manera ilustrada en la figura 5.7.

5.1. LAS CLASES 29

Figura 5.6: Actualizacion del nodo

Figura 5.7: Propagacion del resultado

Al finalizar una iteracion del metodo se vuelve a la posicion inicial del problema, al depender deeste se implementa en la clase hija.

Es necesario que las iteraciones no se repitan infinitamente, por lo tanto se han implementadodos formas distintas de controlar esto. La primera, fijando el numero de simulaciones a uno concreto,y la segunda limitando el tiempo. Esta segunda, ha sido implementada mediante un thread que sedestruye al pasar el tiempo fijado.

Como mejor hijo, tal y como se ha explicado en la parte teorica, se toma el hijo con mayornumero de visitas.

5.1.4. SimulacionUCTGo

Esta clase contiene todo lo necesario para poder aplicar el metodo MCTS al juego del Go.Para ello, almacena la situacion de partida del juego (Go inicial), una partida donde realizara lassimulaciones y un entero que guarda el turno antes de comenzar las simulaciones (cuya utilidaddescribiremos mas adelante).

La clase ademas implementa todas las funciones abstractas de la clase SimulacionUCT, veamosa continuacion el contenido de estas segun la fase en la que intervienen:

Seleccion: La funcion que calcula la tasa de exito es simplemente una division entre el numerode partidas ganadas (valor del nodo) y en numero de partidas simuladas (visitadas).

Expansion: Para devolver el vector con las acciones posibles, mira si es posible colocar lapieza en cada una de las posiciones del tablero; cuando lo es anade la accion al vector deacciones, la accion Pasar siempre es posible, por lo que se anade tambien al vector. En cuantoel valor inicial para los nuevos nodos creados, se pone que es 0, ya que representa el numerode partidas ganadas hasta el momento.

Simulacion: La simulacion consiste en realizar jugadas validas aleatorias sobre el tablerohasta que la partida finalice. La figura 5.8 muestra un ejemplo de simulacion aleatoria para


una partida de Go sobre tablero 3x3, donde la situacion inicial de la simulacion es el tablerocon una piedra negra colocada.

Figura 5.8: Ejemplo de simulacion aleatoria

La funcion resultado devuelve 1 (cierto) si el jugador que tenıa el turno antes de comenzar lasimulacion ha ganado (en el ej. si es negro) o 0 (false) si ha perdido. Pero esto solo lo podemossaber si hemos guardado antes este valor en la funcion de inicializacion de la simulacion. Elatributo de la clase turno antes simulacion aleatoria almacena este valor para poderse usaren la funcion resultado.

Retropropagacion: Como el valor del nodo representa el numero de partidas ganadas, seincrementa en una unidad este valor si la partida ha sido ganada o no se incrementa si lapartida se ha perdido.

En la estructura del arbol cada nivel representa un movimiento de piedras de un color,alternando negras y blancas, por lo que si un hijo pierde la simulacion, el padre la gana. Lomismo sucede en el caso de ganar la partida, si el hijo la gana, el padre la pierde, por loque la implementacion de la funcion (ValorPadreRetropropagacion) no es mas que negar laentrada.

Al finalizar la iteracion se debe volver a la situacion inicial, realizando una copia de la partida Goinicial sobre la partida de simulacion.

5.2. Reutilizacion de simulaciones anteriores

Uno de los objetivos perseguidos, era que las simulaciones pudiesen partir de distintas situa-ciones iniciales y el poder aprovechar la informacion obtenida en simulaciones anteriores (dentrodel mismo problema y ejecucion). Veamos mejor la idea con un ejemplo. Para el juego de Go, lasituacion de partida seria el tablero vacıo, tras hacer la simulacion, nos propondrıa un movimiento,lo realizarıamos, el oponente realizarıa tambien su movimiento pertinente y nos volverıa a tocar.Llegado a este punto necesitamos saber que jugada realizar.

La solucion buscada para cumplir estos objetivos ha sido, informar de la realizacion de unaaccion sobre el problema (o partida) real mediante la funcion Avanzar(Contenido). Esta funcion serallamada tantas veces como avances se hayan realizando, pasandoles el contenido correspondiente acada uno de ellos. Esta funcion consta de dos pasos principales que detallamos a continuacion:

1. Realizar un movimiento: Si la accion o movimiento asociada al contenido proporcionado esvalida, se aplica y se almacena el estado actual como estado inicial, de forma que al comenzarcada iteracion del metodo comience del estado almacenado y no del vacıo. Si la accion no esvalida, no se realiza el paso 2 y no se produce ningun cambio.

2. Avanzar por el arbol : Una vez aplicada la accion, se avanza por el arbol segun el contenidoproporcionado. El avance se realizara comparando el contenido de los nodos del arbol con el

5.2. REUTILIZACION DE SIMULACIONES ANTERIORES 31

contenido pasado por entrada a la funcion. Una vez encontrado el nodo que corresponde almovimiento, este pasara a ser la nueva raız, desechando ası otras ramas del arbol y ahorrandoespacio en memoria. Hay que observar que al crear todos lo hijos de golpe, si la jugada es

Figura 5.9: Avance caso raız con hijos

valida y la raız tiene hijos, uno de sus hijos siempre va a tener el contenido proporcionadoen la jugada. Si la raız no posee hijos, se crea un nuevo nodo raız con ese contenido. Estosultimos casos son ilustrados en la figura 5.9, donde se ve el efecto que tiene en el arbol alavanzar con contenido 1,1, y la figura 5.10, donde se ve el efecto que tiene en el arbol avanzarcon contendio 1,2 .

Figura 5.10: Avance caso raız sin hijos

En las dos fases explicadas anteriormente se usan funciones abstractas implementadas en laclase hija por la dependencia que tienen con el problema, por ejemplo la comprobacion de que lajugada es valida o la comparacion de contenidos.


Capıtulo 6

Aplicacion

La aplicacion del Go implementada permite de una forma visual jugar al juego del Go contrael ordenador, seleccionar las opciones de juego y dispone de informacion complementaria de ayudapor si fuera necesaria para el seguimiento del juego o simplemente para recordar las reglas.

Este apartado muestra el esquema de clases implementado, la interfaz creada, sus funcionali-dades y el valor UCT seleccionado.

6.1. Esquema

En cuanto a la implementacion, se ha creado una clase para cada una de las ventanas y unaespecializacion de las clases Go y Tablero. La figura 6.1 muestra la relacion que existe entre estasclases.

Figura 6.1: Diagrama de clases para la Aplicacion

6.2. Interfaz

La interfaz esta formada por las ventanas de: Inicio, reglas, opciones y juego; ademas de la clasetablero, que genera el tablero de la ventana de juego. A continuacion se explica un poco mas endetalle cada uno de estos elementos.

6.2.1. Ventana Inicio

Corresponde a la clase Go Interfaz Menu, que crea la ventana de inicio o menu mostrada porla figura F.2. Ademas asocia los botones a las ventanas correspondientes: El boton “Jugar” crea

33

34 CAPITULO 6. APLICACION

la ventana opciones (objeto de la clase Go Interfaz Opciones), el de “Reglas” la ventana de reglas(objeto de la clase Go Interfaz Reglas) y el boton “Salir” cierra las ventanas y finaliza el programa.

Figura 6.2: Ventana de Inicio

6.2.2. Ventana de reglas

Corresponde a la clase Go Interfaz Reglas, que crea la ventana de ayuda mostrada en la figura6.3. Esta ventana esta formada por un directorio arbol y por un texto. El texto va variando segunla parte del arbol seleccionada, mostrando informacion relacionada con el.

Figura 6.3: Ventana de Reglas

6.2.3. Ventana de opciones

Figura 6.4: Ventana de opciones

6.2. INTERFAZ 35

Corresponde a la clase Go Interfaz Menu, que crea la ventana de seleccion de opciones mostradaen la figura F.3. Al cliquear el boton “Confirmar” se crea una nueva partida de Go (Interfaz) conlas opciones seleccionadas. Pulsar el boton “Cancelar” cierra la ventana de opciones y el boton“Ayuda” abre la ventana de Reglas por la seccion de ayuda en opciones.

El Go (interfaz) creado, ademas de realizar las tareas del Go correspondientes, crea la claseTablero en su especializacion de interfaz que sera usada por la ventana de juego. Ademas anadeuna serie de funciones como por ejemplo almacenar el color de piedras de la maquina.

6.2.4. Ventana de juego

Corresponde a la clase Go Interfaz Juego, que crea la ventana de juego mostrada en la figuraF.4. Esta ventana esta formada por tres elementos principales:

Botones: Permiten salir de la partida pulsando “Abandonar”, abrir la ventana de reglas pul-sando el boton “Reglas” o pasar turno pulsando sobre el boton “Pasar”.

Tablero: El tablero es incorporado por la ventana de juego en la interfaz de la ventana, perola gestion de este y su dibujado se realizan en su propia clase.

Otros elementos: Ademas de esos elementos principales, la ventana dispone de otros elementosque complementan al juego, como son el fondo y la informacion de piedras capturadas, eltemporizador de cada turno y los mensajes de ayuda.

Figura 6.5: Ventana de juego

Al finalizar la partida tal y como muestra la figura 6.6 muestra un mensaje con la puntuacionfinal.


Figura 6.6: Ventana emergente mostrando la puntuacion final

6.2.5. Tablero

La parte relacionada con la interfaz del tablero se lleva a cabo en la clase Tablero interfaz, quees una clase hija de la clase Tablero.

Al inicializar el tablero, se crea la parte grafica: Se carga el fondo del tablero, las letras ynumeros de guıa y las lıneas (cuadrıcula). Las piedras se gestionan usando una matriz de imagenes.Si la interseccion correspondiente a los ındices de la matriz esta libre, la matriz de imagenes noalmacenara en ella nada (valor null), en cambio si hay una piedra colocada en esta interseccion,se almacena la imagen de esa piedra. Posteriormente se pueden eliminar estas piedras (debido auna captura) marcando las imagenes como no visible y marcandolas como libres en la matriz deimagenes.

Ademas esta clase implementa la accion de colocar pieza. Captura los clic producidos sobre eltablero y actua en consecuencia: Coloca la pieza si la jugada es valida, avisa al usuario si no esposible realizar la jugada o no realiza ninguna accion si no es el turno del jugador o se ha cliqueadofuera del rango de las intersecciones1. La figura 6.7 muestra un mensaje emergente en caso de poderrealizarse la jugada por ser suicidio o por ser Ko.

Figura 6.7: Ventana emergente Movimiento no valido

1Se llama rango de interseccion al area cercana a la interseccion, de forma que cliquear dentro de este areasignifica haber cliqueado en la propia interseccion.

6.3. VALOR DEL COEFICIENTE UCT 37

6.3. Valor del coeficiente UCT

La estrategia UCT selecciona los mejores movimientos encontrados hasta el momento perotambien explora otros movimientos menos prometedores.2

Algoritmo 6.1 Formula UCT para el nodo Ni

V alorUCT (Ni) = tasaExitoi + C ×√

ln(np)ni

Comenzando por la raız, UCT busca un camino de movimientos a traves del arbol calculando elvalor de cada posicion candidata de acuerdo a la tasa de exito (tasaExitoi) , el valor del coeficienteC , el numero de visitas del nodo ni y el numero de visitas del nodo padre np, tal y como muestrala formula 6.1. Si hay hijos de un nodo que no se han visitado ninguna vez (ni = 0), se elige uno deellos aleatoriamente. Como este metodo no asume ningun conocimiento, lo natural es que se visitecada uno de ellos al menos una vez.

Es necesario definir el valor del coeficiente UCT (C) que sera usado en la fase de selecciondel MCTS. Tenemos que determinar un compromiso entre explotacion y expansion. Si el valor espequeno se dara mas importancia a la explotacion, en cambio si el valor es grande se da importanciaa la exploracion.

Explotacion (Valores comprendidos entre 0 y 1): dan mas importancia al movimiento masprometedor. La importancia dada sera mayor cuanto menor sea el valor.

Igualdad (Valor 1): da igual importancia a la explotacion como a la exploracion.

Exploracion (Valores mayores de 1): da mas importancia a la exploracion. La importanciasera mayor cuanto mayor sea el valor.

En esta implementacion se ha optado por la igualdad (valor 1), ya que explora un numero suficientede veces cada rama, pero una vez dirigido hacia la solucion desarrolla solo la rama mas prometedora,mientras esta de buenos resultados. La figura 6.8 muestra los datos obtenidos en una simulacionde Go sobre tablero 3x33. Como se puede observar en la grafica el aumentar el valor del factordisminuye el nº de visitas de la rama mas prometedora, pero aumenta el del resto de ramas,notandose cada vez mas cuales son los siguientes movimientos mas prometedores. Debido a lasimetrıa del tablero, el movimiento mas prometedor para tableros 3x3 es tanto el (0,1) ,(1,0) (1,2)como el (2,1).

2Esto lo hace mediante la formula del algoritmo 6.1, es decir sumando un numero a la tasa de exito de cadamovimiento, menor conforme el nodo haya sido mas veces visitado. Este numero tambien crece cuando el nodo padreha sido visitado pero se ha seleccionado otro de los nodos hijos. Esto significa que la tasa de exito + el numerocrecera hacia movimientos no explorados de forma que en ciertos momentos la suma del nodo sera mayor que ladel resto de movimientos que tienen tasas de exito superiores. Si el movimiento funciona (es exitoso), se incrementala tasa de exito y podra proximamente ser seleccionado de nuevo. Si falla (no es exitoso), la tasa de exito decrecejunto con el numero y el movimiento debera esperar un tiempo mayor antes de que sea seleccionado de nuevo. Unmovimiento puede tambien seleccionarse si el resto de movimientos resultan fallidos y por lo tanto las tasas de exitodel resto de competidores descienden.

3Con 50000 iteraciones, tablero 3x3, 0.5 de penalizacion, numero de simulaciones antes de expandir 30 y modode recuento Japones


Figura 6.8: Nº de visitas en simulaciones 3x3 para distintos factores

Capıtulo 7

Conclusiones

7.1. Marco de trabajo

En primer lugar, este proyecto ha implicado tomar contacto con un juego y un metodo desco-nocidos hasta el momento por mı. Se ha realizado un trabajo de comprension de la naturaleza eimportancia tanto para el juego Go, como para el metodo MCTS.

Se ha visto que el metodo MCTS necesita que la informacion sea perfecta y abarca todos loscampos donde esta condicion se cumple: Juegos deterministas o estocasticos de uno, dos o tresjugadores. En todos ellos se han obtenido resultados que incluso superan en algunos aspectos alos mejores programas hasta el momento. Su caracter general, permite ademas obtener buenosresultados en programas de proposito general.

En cuanto a la aplicacion del metodo MCTS al juego del Go (juego determinista de dos juga-dores), se sabe que se ha obtenido una gran mejora con respecto a programas que usaban otrosmetodos, pero aun ası necesita el apoyo de potentes ordenadores y sigue sin ser capaz de vencer alos humanos mas expertos. El gran numero de casillas y jugadas posibles en cada turno hace quelas combinaciones posibles de movimientos sean increıblemente grandes, ofreciendo aun un granreto para la informatica.

El motivo de este trabajo ha sido conocer el comportamiento del metodo MCTS de cara autilizarlo en otros problemas interesantes para los directores de este proyecto.

7.2. Resultados obtenidos

El objetivo del proyecto era la realizacion en lenguaje Java de un jugador virtual que fueracapaz de enfrentarse en el juego del Go a un jugador humano, aplicando el metodo MCTS. Elproyecto constaba de estas cinco grandes tareas:

1. Estudio del juego del Go y el uso de la Inteligencia Artificial en el.

2. Estudio del metodo MCTS y sus diversas variantes.

3. Implementacion del juego del Go.

4. Implementacion del metodo MCTS, intentando que dicha implementacion sea lo mas generalposible, de cara a poder utilizarse en otros problemas interesantes para los directores de esteproyecto.

39

40 CAPITULO 7. CONCLUSIONES

5. Implementacion de un programa visual que enfrente al usuario y al ordenador en el juego delGo.

Todas estas tareas se han realizado satisfactoriamente, cumpliendose ademas los objetivos detalla-dos de las tareas de implementacion recogidos en el apendice B.

7.3. Diagrama de tiempos

El diagrama de la figura 7.1 muestra los tiempos dedicados en las principales fases del proyecto.Este diagrama junto con todo lo relacionado en la gestion del proyecto (metodologıa, fases, gestionde tiempo y esfuerzos, supervision del proyecto y herramientas utilizadas) aparece explicado en elapendice A.

Figura 7.1: Diagrama de tiempos

7.4. Lıneas de trabajo futuro

En la creacion del modulo MCTS se eligieron unas estrategias concretas para cada una delas fases. Por lo que una lınea futura podrıa ser la modificacion de este modulo eligiendo unasestrategias distintas. A partir del modulo MCTS implementado podrıa tambien implementarseuna version no generica de el, donde se usasen simulaciones pseudoaleatorias (en vez de aleatorias)de acuerdo con el problema a tratar, que condujesen de una forma mas rapida a la solucion. Ademasresultarıa muy interesante la paralelizacion del metodo.

En cuanto al juego Go implementado, una de las lıneas futuras serıa poder permitir un handicap,para compensar la diferencia de niveles antes de comenzar una partida.

En cuanto a la aplicacion que enfrenta en el juego del Go al usuario con un jugador virtual(ordenador) una lınea futura serıa crear un servidor que enfrentase tanto a jugadores humanoscomo jugadores virtuales.

Como trabajo futuro, se contempla el poder aplicar el metodo a cualquiera de sus diversoscampos. Concretamente dentro del GIGA (Grupo de Informatica Grafica Avanzada) en los camposde trabajo con los que se trabaja, como pueden ser el de los videojuegos o el calculo de la iluminacionde una escena.

7.5. PROBLEMAS ENCONTRADOS 41

7.5. Problemas encontrados

Aquı se enumeran los principales problemas encontrados:

Comprension del metodo MCTS: La compresion del metodo resulto bastante costosa, practi-camente un mes. La documentacion encontrada sobre el tema explicaba el metodo de formageneral, pero carecıa de ejemplos concretos que facilitasen su comprension. El encontrar unpseudo-codigo en internet[19] supuso un avance importante, ya que se aplicaba a un ejemploconcreto. Las ideas presentadas por este pseudo-codigo se emplearon en la implementacionde la primera version. La ejecucion de esta version sirvio para ver paso a paso como se pasabapor las distintas fases del metodo, alcanzando con ello su total comprension. Despues de elloya se pudo comenzar a estudiar a fondo cada una de las fases viendo cual era mas convenientepara la solucion buscada en este PFC.

Estrategias a usar en el metodo MCTS implementado: El decantarse por una estrategia uotra en cada una de las fases fue tambien una labor no siempre facil.

Generalizacion del modulo MCTS: Uno de los objetivos del proyecto era que el modulo MCTSimplementado fuese lo mas generico posible. Este hecho supuso entrar en profundidad en cadauna de las fases y ver como se podıa hacer lo mas genericas posible. Se vio que la estructurahasta entonces utilizada dependıa mucho del problema aplicado (juego del Go) por lo quefue necesario enfocar de forma diferente tanto la estructura como las fases del metodo.

Recuento de puntuacion en el juego del Go: En la mayorıa de documentacion encontrada,se define el sistema de recuento del Go como el explicado en el capıtulo 2. Sin embargo, eninternet se encontraban imagenes sobre el recuento de puntuaciones que no siempre coincidıacon esta definicion. Este hecho resulto bastante desconcertante, y hubo que intentar averiguarcual era el sistema correcto de recuento.

Finalmente se descubrio[16] que una variacion de la version japonesa del juego bastante exten-dida, es que para contar los territorios se tiene en cuenta el concepto de “Vida y muerte”[17]1.Esto hace que al finalizar la partida algunas piedras sean “retiradas” debido a que serıan ma-tadas en un futuro y se tienen en cuenta a la hora del recuento de la misma forma que laspiedras capturadas. El problema es que con este metodo hay situaciones en las que no se sabesi los territorios pertenecen a un jugador u otro.

En el sistema Chino, se da por hecho que los jugadores pasan porque no tienen mas movi-mientos posibles, o estos provocarıan una misma puntuacion tras el recuento. De forma quesi los jugadores pasan teniendo mas movimientos posibles significa que asumen la puntuaciondel tablero segun las reglas explicadas en el capıtulo 2.

Se decidio dejar el sistema de recuento explicado en el capıtulo 2, debido a la complejidadque supone en la implementacion de la variante japonesa aquı explicada y un aparentementeincumplimiento de dos de las condiciones para que se aplicase el metodo MCTS2 .

El lenguaje Java: Al iniciar este proyecto solo se conocıan los aspectos mas basicos del lengua-je, por lo que en ocasiones resulto algo mas costoso de lo normal descubrir como implementarciertas cuestiones. Concretamente no se conocıa nada de la parte grafica ni de los threads.Pero gracias a la librerıa grafica Java Swing[27] fue mucho mas sencillo desarrollar sobre todola labor estetica.

1Se define un grupo de piedras como ”vivo”, si tiene posibilidad de permanecer en el tablero, o ”muerto”, si elgrupo sera ”capturado”. La idea basica puede expresarse sencillamente ası: Un grupo debe tener dos ojos (libertadesinternas seguras) para vivir.

2No hay conocimiento completo (las reglas de recuento no son claras) y las simulaciones no terminarıan rapido.

42 CAPITULO 7. CONCLUSIONES

7.6. Valoracion personal

La realizacion del proyecto me ha resultado muy positiva. Las reuniones con el director y co-director han sido muy utiles a la hora de saber que direccion tomar, he trabajado muy a gusto conellos y me he sentido apoyada en todo momento.

El tema, pese a ser algo nuevo para mı, me ha parecido muy interesante; tanto el metodo MCTSaun por explotar y muy util en numerosos campos; como el Go, juego curioso que resulta a la vezinquietante por el hecho de que aun sea un reto para la informatica.

En definitiva, la experiencia ha sido muy enriquecedora y gratificante. La realizacion de esteproyecto me ha permitido conocer ciertos campos muy interesantes que desconocıa, completandotambien mi formacion en cuanto a aptitudes y conocimientos.

Apendice A

Gestion del proyecto

A.1. Metodologıa de desarrollo

La creacion de la solucion final ha seguido un proceso evolutivo, concretamente el modelo encascada con realimentacion mostrado en la figura A.1. Este ha sido aplicado en las tres grandestareas de implementacion (Go, MCTS y aplicacion), las fases del modelo son las siguientes:

Analisis: Fase en la que se establecen los requisitos funcionales y no funcionales.

Diseno: Fase en la que se desarrollan los diagramas de clase y de estados con el fin desatisfacer los requisitos de la fase anterior.

Implementacion: Fase en la que se escribe el codigo siguiendo el diseno creado.

Pruebas: Fase en la que se prueban los elementos creados, tanto simples, como otros mascomplejos, para verificar el correcto funcionamiento del codigo implementado.

Cada una de las fases depende directamente de la anterior. En ocasiones al llegar a una fase, seha visto que era necesario modificar cosas de las fases anteriores, produciendose por lo tanto unaretroalimentacion.

Figura A.1: Modelo en cascada con retroalimentacion

43

44 APENDICE A. GESTION DEL PROYECTO

A.2. Fases del proyecto

Veamos cuales han sido las principales fases del proyecto y una breve descripcion de estas:

1. Estudio del Go: Fase en la que se estudio el juego del Go, conociendo sus reglas basicas,jugando al juego y estudiando los logros de la inteligencia artificial en este campo.

2. Estudio del Metodo Monte-Carlo Tree Search: Fase en la que se estudio el meto-do Monte-Carlo Tree Search, tanto su proceso general, como el conocimiento de distintasposibilidades para cada una de las fases que este posee.

3. Implementacion del Go: Fase en la que se implemento el juego del Go en su modelo deinformacion perfecta. Primero las funciones mas simples y recuento de puntuaciones, segundola estructura de los bloques, seguido de la implementacion de la captura, suicidio y finalizandocon la regla del Ko.

Figura A.2: Evolucion del modulo UCT

4. Implementacion del metodo Monte-Carlo Tree Search: Fase en la que se creo elmodulo del metodo Monte-Carlo Tree Search. Inicialmente se realizo una version base, secontinuo elaborando una version que interactuase con el modulo que implementaba el juegoGo, seguida de la version generica (donde se generalizo el modulo para aplicarlo en distintosdominios), finalizando por la incorporacion de la funcionalidad de reutilizacion de simulacio-nes y el poder partir de distintos problemas. Las figuras A.2 y A.3 muestran el proceso deevolucion, tanto de los modulos del metodo como de la estructura del nodo.

Figura A.3: Generalizacion del nodo

5. Aplicacion: Fase en la que se implemento la aplicacion que usa el modulo generico MCTSfinal que enfrenta un jugador humano a uno virtual en el juego del Go. A esta fase pertenecetambien la creacion de la interfaz y la implementacion de las funcionalidades correspondientes.

6. Memoria: Fase en la que se escribio la memoria del proyecto.

A.3. GESTION DE TIEMPO Y ESFUERZO 45

A.3. Gestion de tiempo y esfuerzo

La distribucion en el tiempo de cada una de las fases puede verse en el diagrama de Gantt1

que recoge la figura A.4. Como observamos el proyecto se ha desarrollado entre Octubre y Junio.Algunas fases han sido mas largas que otras debido a la dificultad encontrada en ellas. Ademasdurante el primer cuatrimestre el avance fue mas lento debido a la compaginacion del proyecto conotros estudios.

Figura A.4: Diagrama de Gantt

Como puede verse en la imagen, hay una franja temporal en la que coinciden el estudio delmetodo e implementacion del mismo. Esto se debe a que esta implementacion sirvio para la com-prension total del metodo. Tambien se puede observar que, en la implementacion del Go, la regladel Ko fue incorporada al codigo mas tarde; ya que la idea de como enfocarlo surgio con posteriori-dad. Se puede observar claramente la dependencia entre la segunda version del MCTS (MCTS-Go)con la implementacion del juego del Go.

En cuanto al tiempo dedicado al proyecto es aproximadamente unas 600 horas. Las horas paracada una de las fases aparecen en la tabla A.1. Las partes de implementacion del Go y del metodoMCTS son las que mas tiempo han empleado. El calculo de horas incluye para cada tarea lasdistintas fases de la metodologıa usada (Analisis, Diseno, Implementacion y Pruebas). Ademas, laretroalimentacion realizada, ha provocado que el paso por las distintas fases se repita en numerosasocasiones, principalmente en la implementacion del modulo MCTS. En cambio, el desarrollo de laaplicacion se ha realizado en un tiempo mucho menor.

Horas estimadas

Estudio del Go 40Estudio MCTS 85

Implementacion del Go 126Implementacion MCTS 240

Aplicacion 52Memoria 64

Total 607

Cuadro A.1: Horas dedicadas

1Herramienta grafica cuyo objetivo es mostrar el tiempo de dedicacion previsto para diferentes tareas o actividadesa lo largo de un tiempo total determinado.


En la figura A.5 podemos ver el porcentaje de tiempo empleado por cada una de las fases. Seobserva, que la implementacion del Go y del metodo MCTS suponen un 60 % del total de horas,en contraste con el desarrollo de la aplicacion que supone solo un 9 %.

Figura A.5: Porcentaje del trabajo

A.4. Supervision del proyecto

Durante la realizacion del proyecto se ha contado con la supervision del director y co-director,con los que se ha realizado reuniones periodicamente. En ellas, se presentaban los avances, y seconsultaban las distintas dudas surgidas. La periocidad de las reuniones ha sido variable. Inicial-mente las reuniones fueron semanales hasta la completa comprension del metodo Monte-Carlo TreeSearch y posteriormente ya fueron cada dos semanas o mensuales. En estas reuniones se presentabaun PowerPoint con el siguiente contenido:

Recapitulacion de lo alcanzado anteriormente

Presentacion en detalle de los avances conseguidos desde la ultima reunion, explicando lasideas aplicadas.

Resumen de los avances.

Presentacion de dudas y posibles soluciones.

Presentacion del trabajo a realizar en las proximas semanas.

A.5. Herramientas utilizadas

En cuanto a la realizacion del proyecto se han utilizado distintas herramientas para facilitar laelaboracion del mismo. Las cuales se enumeran a continuacion:

Eclipse: Como entorno de programacion y ejecucion.

GanttProject: Para realizar los diagramas de Gantt.

VisualParadigm for UML: Para la realizacion de los diagramas de clases y estados.

Microsoft Excel: Para la creacion de graficas.

Microsoft PowerPoint: Para la creacion de las presentaciones de las reuniones y figuras comoesquemas o tableros presentes en la memoria.

A.5. HERRAMIENTAS UTILIZADAS 47

Photoshop CS3: Para la creacion de la textura del tablero de la interfaz y el fondo de lapantalla de juego.

LYX: Como entorno para la escritura de la memoria en lenguaje LATEX.


Apendice B

Requisitos

Tres de los objetivos del proyecto consistıan en la implementacion de distintos elementos: Eljuego del Go, el metodo MCTS y una aplicacion que enfrentase el usuario al ordenador en el juegodel Go. Para cada uno de estos objetivos se marcaron una serie de requisitos a cumplir.

Los requisitos son de dos tipos: 1) Funcionales: Que definen el comportamiento interno delsoftware: calculos, detalles tecnicos, manipulacion de datos y otras funcionalidades especıficas y 2)No funcionales: Que especifican criterios que pueden usarse para juzgar la operacion de un sistema.

Los requisitos marcados en el proyecto se recogen en los cuadros: B.1 para el juego del Go, B.2para el metodo MCTS y B.3 para la aplicacion.

Codigo Descripcion

RF-0 Se debe permitir elegir entre modo de recuento chino o japones.RF-1 Se debe poder elegir entre tableros de distinta dimension.RF-2 Se podra seleccionar el valor de compensacion.RF-3 Una vez comenzada la partida no podran ser modificadas las

opciones anterioresRF-4 Permitira al usuario, “colocar pieza” o “pasar”RF-5 Se deberan respetar las reglas del juego (captura, suicidio,Ko...)RF-6 Se podra volver a comenzar una partida en cualquier momento

del juego.RF-7 Al comenzar una nueva partida se guardan las opciones definidas

anteriormente.RNF-0 Debera funcionar en tiempo realRNF-1 Debe ser implementado en lenguaje Java

Cuadro B.1: Requisitos del Go

En los cuadros aparecen numerados cada uno de los requisitos, se nombran con RF a losrequisitos funcionales y con RNF a los requisitos no funcionales. Por ejemplo en el cuadro B.1aparecen 8 requisitos funcionales y 2 requisitos no funcionales.

49

50 APENDICE B. REQUISITOS

Codigo Descripcion

RF-0 Debera poder adaptarse al problema, en lo que se refiere acontenido y valor.

RF-1 Debe permitir realizar sucesivas simulaciones hasta un numerotope o un tiempo lımite dado.

RF-2 Debe permitir avanzar por las ramas del arbol segun contenidos(movimientos) dados.

RF-3 Debe permitir reutilizar el arbol en simulaciones y busquedasposteriores.

RF-4 Antes de comenzar la simulacion se tienen que poder modificarlos valores de todas las constantes usadas en el metodo.

RF-5 Debe ser generico y poderse usar en distintos problemas(incluido el Go) como particularizacion del modulo generico.

Cuadro B.2: Requisitos del modulo MCTS

En el cuadro B.2 los seis requisitos son funcionales y en B.3 aparecen seis requisitos funcionalesy uno no funcional.

Codigo Descripcion

RF-0 El sistema debe poseer una interfaz que permita al usuario jugarinteractivamente al juego del Go contra un jugador virtual.

RF-1 Antes de comenzar el juego se debera poder seleccionar lasopciones del Go ademas de tiempo lımite por turno, color depiezas en el juego y nombre del usuario.

RF-2 El jugador virtual usara el metodo Monte-Carlo Tree Search(MCTS) para seleccionar la jugada a realizar.

RF-3 Al finalizar la partida se mostrara el resultado segun el modo derecuento anteriormente seleccionado.

RF-4 La ventana de juego debera mostrar al menos: un tablero, laspiezas colocadas, numero de piezas capturadas y el tiempo que lequeda a cada jugador.

RF-5 Las ventanas dispondran de elementos de ayuda como ventanaso textos indicativos.

RNF-0 La interfaz deber permitir al usuario jugar de una formaagradable y sencilla.

Cuadro B.3: Requisitos de la aplicacion

Apendice C

Aplicaciones MCTS

El metodo implementado en este PFC se ha aplicado solo al juego del Go. Este apendice muestrade forma resumida distintas aplicaciones realizadas por expertos en distintos dominios, si deseaprofundizar en cualquiera de ellos use las referencias bibliograficas, estan enlazadas a los artıculoscorrespondientes. Los dominios que trataremos seran exclusivamente los que tengan informacionperfecta.

Veremos a continuacion que el metodo MCTS ha conducido a los mejores programas en variosde los dominios y ademas es muy atractivo para muchos otros. MCTS parece permitir superarel problema de adquisicion de conocimiento permitiendo hacer de una forma mas sencilla estaadquisicion en muchos campos.

C.1. Deterministas

C.1.1. Deterministas de un jugador

El metodo MCTS se ha aplicado a problemas de gestion y produccion (Production ManagementProblems) obteniendo resultados bastante aceptables[29].

Otra aplicacion fue el juego SameGame, con el que se gano el record mundial de este juego usan-do variantes del MCTS[30]. Ademas estos metodos superaban tambien las mejores puntuacioneshumanas para el Morpion Solitario[31].

Figura C.1: SameGame y Morpion Solitario

Considerando los problemas de optimizacion como juegos de un jugador, se han usado variantesMCTS en la optimizacion de librerıas para diferentes plataformas (Library Performance Turing).

51

52 APENDICE C. APLICACIONES MCTS

C.1.2. Deterministas de dos jugadores

Para juegos deterministas de dos jugadores como el ajedrez y las damas, el uso de αβ con unafuncion de evaluacion fuerte fue la base para la construccion de un fuerte jugador de InteligenciaArtificial. Sin embargo, donde el MCTS ha tenido mas exito es en el campo del Go, cuyos programasganan los torneos de las olimpiadas de computacion desde 2006.

Ademas del Go, MCTS se usa tambien para otros juegos deterministas de dos jugadores, co-mo Amazons (Juego de las amazonas)[33] o LinesOfAction(LOA)[34], en el primero ganaron lasolimpiadas de 2008 y 2009 y en el segundo se ha conseguido el mismo nivel que el mejor juego delmundo.

Figura C.2: Amazons y LinesOfAction

C.1.3. Deterministas multijugadores

En 2008 Sturtevant aplico MCTS en juegos multijugador como Las Damas Chinas, Spades andHearts (Picas y corazones). En las damas chinas demostro que MCTS era capaz de superar losmetodos de busqueda estandard maxny paranoid equipados con una fuerte funcion de evaluacion.Para las versiones de Spades and Hearts, MCTS se posiciono al mismo nivel que el estado del arte.

Figura C.3: Damas chinas y Spades and Hearts

C.2. Estocasticos

C.2.1. Estocasticos de un jugador

Las primeras aplicaciones de MCTS para juegos estocasticos de un jugador fueron en el dominiode navegacion[35].

El dominio de navegacion es un problema estocastico que busca el menor camino entre dospuntos bajo condiciones de viento variable. Este problema fue tratado usando el metodo UCT con

C.2. ESTOCASTICOS 53

el que se consiguio que se necesitasen significativamente menos simulaciones para alcanzar el mismorendimiento que los programas existentes hasta entonces.

C.2.2. Estocasticos de dos jugadores

Uno de estos juegos es el Backgammon[36], en el que un programa con seleccion UCT y simu-laciones completamente aleatorias fue capaz de encontrar la mejor forma de comenzar el juego enun tercio del tiempo que otros programas, pero sin embargo, era significativamente mas debil quelos programas del estado del arte.

Figura C.4: Backgammon

C.2.3. Estocasticos de varios jugadores

La popularidad de los juegos modernos de estrategia de tablero esta incrementandose desde quenacieron el la decada de los 90. Los juegos de estrategia de tablero, son de especial interes para losinvestigadores de la inteligencia artificial, ya que suponen un puente entre los juegos clasicos detablero (deterministas de dos jugadores) y los videojuegos.

Se aplico el MCTS al juego multijugador Colonos del Catan[37], aumentando el algoritmo conun conocimiento limitado del juego. En los experimentos, en los que las reglas fueron cambiadaspara conseguir una estocastica perfecta informacion del juego, se obtuvo que el programa eracapaz de derrotar convincentemente al mejor programa de codigo abierto de Inteligencia Artificialdisponible, y que es un razonable fuerte jugador para los humanos.

Figura C.5: Colonos del Catan

54 APENDICE C. APLICACIONES MCTS

C.3. Juegos de proposito general

El proposito de los juegos de proposito general es crear agentes inteligentes que automaticamenteaprendan como jugar a diferentes juegos a un nivel experto sin intervenciones de los humanos. Elmas exitoso agente en el pasado habıa usado la tradicional busqueda en arboles de juego combinadacon funciones heurısticas de aprendizaje automatico para evaluar los estados de juego. Sin embargodesde 2007, los programas MCTS han ganado los torneos de juegos de proposito general usandoUCT, con un algoritmo de aprendizaje online para las simulaciones[38].

Apendice D

Ejemplo de simulacion

Para comprender mejor el metodo MCTS, en este apendice se explica un ejemplo de simulacionpara el juego del Go de tamano 3x3, que expande sus nodos cuando se han visitado dos veces.Primero se explica la estructura del nodo, luego se explica en detalle las veinte iteraciones realizadasy finalmente se explica algunas ideas, por si estas no quedasen claras o no se visualizasen duranteel ejemplo.

Decir que durante las simulaciones, se trabaja sobre una copia del Go, realizando acciones sobreesta copia sin tocar la partida de Go en la que se juega con el adversario. En cada iteracion, primerose vuelve a copiar sobre la copia el estado del Go proporcionado al inicio de la simulacion MCTS, yse trabajara sobre esta copia realizando sobre ella los movimientos segun la seleccion que realcemosy los movimientos aleatorios de la simulacion aleatoria. Durante este ejemplo al hablar de partidadel Go, se referira a la copia del Go sobre la que se trabaja.

Como se observara mas adelante el arbol se mantiene, actualizandose tras las distintas itera-ciones.

D.1. La estructura del nodo

Figura D.1: Nodo MCTS del Go

El nodo MCTS consta de dos partes: Datos para el algoritmo MCTS y Contenido. Tal y comomuestra la figura D.1, para el caso del Go, como datos para el algoritmo MCTS tenemos el numerode partidas ganadas (de las simuladas a partir de ese nodo u hijos) y numero de simulacionesrealizadas (desde el o sus hijos). En cuanto a la informacion correspondiente al juego, es deciral contenido, en el Go corresponde con las acciones de colocar pieza y pasar; que se representamediante un booleano que indica si la accion consiste en pasar o no y las coordenadas x,y queindican la posicion donde se ha colocado la pieza, usando como punto de referencia es la esquinasuperior izquierda del tablero. Durante el resto de la explicacion usaremos la version abreviada del

55

56 APENDICE D. EJEMPLO DE SIMULACION

nodo, mostrada en la figura D.2. Donde el nodo sera de un color u otro dependiendo del turno deljugador que realiza la accion (negro/blanco).

Figura D.2: Simplificacion del nodo MCTS Go

Un caso especial es la representacion del nodo raız aunque no se haya realizado ninguna accion(colocacion de pieza o pasar), es decir, al inicio de la partida. En el Go se ha representado con elsiguiente contenido: Pasar=false, x=-1, y-1. En las figuras del ejemplo, se indica que un nodo esraız del arbol cuando este senalado por una flecha naranja. La figura D.3 muestra la raız del arbolpara tablero vacıo.

Figura D.3: Raız para comienzo de la partida

Ademas durante el ejemplo se acompana la representacion del arbol en las figuras con un dibujoque se indica la situacion del tablero y el turno, en el Go usado para la simulacion. En la figuraD.4 muestra la situacion del tablero y turno al comienzo de una partida.

Figura D.4: Situacion tablero y turno

D.2. Forma del arbol

En el juego del Go, se alterna turno de negras y de blancas. Como el arbol representa las jugadasrealizadas por estos (salvo el nodo raız), el arbol por lo tanto tambien alterna color: primer niveljugador negro, segundo jugador blanco, tercero negro... En la figura D.5 se puede ver esta idea.

D.3. Iteraciones

D.3.1. Primera iteracion

Comenzamos con la primera iteracion. Partimos de la situacion de inicio de partida del Go(tablero vacıo y turno para el jugador negro, tal y como indica la figura D.4), en la que el arbol

D.3. ITERACIONES 57

Figura D.5: Forma del arbol

Figura D.6: Raız para comienzo de la partida

solo posee un nodo raız, tal y como muestra la figura D.3.

1. Seleccion: Como el nodo raız no tiene hijos, no se selecciona ninguno de ellos y no se avanza.La situacion de la partida y del arbol permanecen iguales.

2. Expansion: La raız siempre se expande, por lo tanto se crean todos sus hijos. Y sobre los hijoscreados, se selecciona uno cualquiera. En la simulacion realizada, el nodo seleccionado ha sidoel de colocar una pieza en la posicion 1,0 , cuya accion sera aplicada a la partida del Go dela simulacion. La Figura D.7 ilustra la creacion de los hijos (cada hijo corresponde a unajugada posible que puede realizar el jugador negro, el cual poseıa el turno, representados conun negro grisaceo) y la seleccion del nodo 1,0 (representado por un negro puro) realizandola colocacion de la piedra negra sobre la interseccion 1,0 del tablero y pasando el turno aljugador blanco.

Figura D.7: Efectos de la fase de expansion

3. Simulacion: La simulacion parte del nodo anteriormente seleccionado, es decir, de la situaciondel tablero obtenida despues de la fase de expansion. A partir de esta se van realizandoacciones validas aleatoriamente (colocar pieza/pasar) sobre la partida de Go hasta que finalice


la partida (pasar dos veces consecutivas) y se obtenga el resultado. La Figura D.8 muestraun ejemplo posible del que se obtiene como resultado que gana el jugador Negro.

Figura D.8: Ejemplo de simulacion aleatoria

4. Retropropagacion: En esta fase se retropropaga el resultado desde la hoja a la raız. Como haganado el jugador negro y este corresponde con el color del nodo del que parte la simulacion,se incrementa tanto el contador de numero de visitadas ni como el de ganadas vi. En laretropropagacion , en el caso del juego del Go, el que un jugador gane supone que el otropierda; y al alternar jugada de negras y blancas, el ganar uno supone la perdida del otro, porlo que si el hijo gana, el padre pierde. Al perder se incrementa solo el numero de visitadasni pero no el de ganadas vi. La Figura D.9 muestra la situacion del arbol tras la fase deretropropagacion.

Figura D.9: Iteracion 1:Retropropagacion

D.3.2. Segunda iteracion

Al comienzo de la iteracion, el Go vuelve a la situacion de partida (tablero vacıo y turno denegras), pero se conserva el arbol generado en la simulacion anterior. La figura D.10 muestra tantoel arbol como la situacion del juego al comienzo de la segunda iteracion. Veamos como se desarrollala segunda iteracion en cada una de las fases:

Figura D.10: Iteracion 2: Situacion de partida

1. Seleccion: Se calcula el valor UCT para cada uno de los nodos segun la formula UCT. Esta,tiene como divisor el numero de visitas ni que en la mayorıa de casos es 0. Se controla esta

D.3. ITERACIONES 59

division por 0 dando a estos nodos un valor aleatorio muy grande. Esto fuerza a que cadanodo sea seleccionado una vez antes de volverse a seleccionar cualquier otro con contador devisitas mayor. En esta iteracion en concreto, quiere decir, que se seleccionara cualquier nodosalvo el 1,0. En el ejemplo el nodo seleccionado ha sido el 2,1, como puede observarse en lafigura D.11.

Figura D.11: Iteracion 2: Seleccion

2. Expansion: El nodo seleccionado no se ha visitado ninguna vez (ni= 0) por lo que no alcanzael numero de visitas mınimo para expandirse (ni= 2) y no se expande, quedando el arbol yla partida en el mismo estado.

3. Simulacion: En este paso se realiza una simulacion aleatoria partiendo de situacion actual dela partida (tablero vacıo con piedra negra sobre interseccion 2,1). La imagen D.12 muestraesta simulacion , en la que negras pierde.

Figura D.12: Iteracion 2: Simulacion aleatoria

4. Retropropagacion: El resultado obtenido (negras pierde) se propaga desde la hoja a la raızactualizando los nodos. Incrementa los contadores de visitas ni de ambos en 1. Al perdernegras, el valor vi (que representa partidas ganadas) no se incrementa, pero si el del nodopadre. La figura D.13 ilustra estas actualizaciones.

Figura D.13: Iteracion 2: Retropropagacion


D.3.3. Tercera iteracion

La figura D.14 muestra tanto el arbol como la situacion del juego al comienzo de la terceraiteracion. Veamos como se desarrolla la iteracion en cada una de las fases:


1. Seleccion: Como sigue habiendo nodos que aun no han sido visitados ninguna vez, se seleccionauno de estos, en este ejemplo el 0,0. Tal y como muestra la figura D.15.


2. Expansion: El nodo seleccionado no se ha visitado ninguna vez (ni= 0) por lo que no alcanzael numero de visitas mınimo para expandirse (ni= 2) y no se expande, quedando el arbol yla partida en el mismo estado.

3. Simulacion: En este paso se realiza una simulacion aleatoria partiendo de situacion actual dela partida (tablero vacıo con piedra negra sobre interseccion 0,0) de la misma forma que enlas iteraciones anteriores. En este caso negras pierde.

4. Retropropagacion: El resultado obtenido (negras pierde) se propaga desde la hoja a la raızactualizando los nodos, tal y como ilustra la figura D.16.


D.3. ITERACIONES 61

D.3.4. Iteraciones de la cuarta a decima

Estas iteraciones se realizan de forma identica a las anteriores. En la cuarta iteracion se haseleccionado el nodo 0,2 y la simulacion aleatoria ha dicho que gana negras. En la quinta el nodo2,0, perdiendo. En la sexta, el nodo Pasar, perdiendo. En la septima el nodo 1,1 ganado. En laoctava el nodo 2,2 perdiendo. En la novena el nodo 2,1 perdiendo y en la decima el nodo 0,1ganando.

D.3.5. Decimoprimero iteracion

La figura D.17 muestra tanto el arbol como la situacion del juego al comienzo de la decimopri-mera iteracion. Veamos como se desarrolla la iteracion en cada una de las fases:


1. Seleccion: Se han visitado ya todos los nodos al menos una vez, por lo que a partir de ahorase va a aplicar siempre el algoritmo UCT sobre estos nodos. Como el contador de visitasni es para todos el mismo, tendran un valor mayor UCT los nodos que hayan ganado lassimulaciones realizadas. Y se selecciona uno de estos, en este caso, el nodo 0,1 por ser elprimero que tiene el mayor valor. La figura D.18 muestra la seleccion del mismo.


2. Expansion: El nodo seleccionado ha sido visitado una sola vez (ni= 1) por lo que no alcanzael numero de visitas mınimo para expandirse (ni= 2) y no se expande, quedando el arbol yla partida en el mismo estado.


4. Retropropagacion: El resultado obtenido (negras pierde) se propaga desde la hoja a la raızactualizando los nodos, tal y como ilustra la figura D.19.



D.3.6. Iteraciones de la decimosegunda a la decimocuarta

Estas iteraciones se realizan de forma identica a la anterior. En la iteracion decimosegunda seselecciona el nodo 0,2, perdiendo la partida. En la decimotercera, se selecciona el nodo 1,0 ganando.En la decimocuarta se selecciona el nodo 1,1 perdiendo.

En estas iteraciones se aplica la formula UCT, por ejemplo el nodo 1,0 al ganar la partidatendra una tasa de exito mayor al resto de nodos, afectando a su valor UCT calculado.

D.3.7. Decimoquinta iteracion

La figura D.20 muestra tanto el arbol como la situacion del juego al comienzo de la decimoquintaiteracion. Veamos como se desarrolla la iteracion en cada una de las fases:


1. Seleccion: Como muestra la figura D.21 se selecciona el nodo 1,0.


2. Expansion: El nodo seleccionado ha sido visitado dos veces (ni= 2) alcanzando ası el numerode visitas mınimo para expandirse (ni= 2) , expandiendose. Al expandirse crea tantos hijoscomo situaciones alcanzables desde el nodo inicializando los valores ni y vide sus nodos acero. En la partida del Go el turno es del jugador blanco, por lo que estos nodos representan

D.3. ITERACIONES 63

jugadas del jugador blanco. De todos los nodos creados se selecciona uno al azar, en este casose ha seleccionado el 2,0 tal y como muestra la figura D.22. Se realizan las acciones acordescon esta seleccion, es decir colocar una piedra blanca sobre la posicion 2,0 y el turno pasa aljugador negro.

Figura D.22: Iteracion 15: Expansion


4. Simulacion: La simulacion parte del nodo anteriormente seleccionado, es decir, de la situaciondel tablero obtenida despues de la fase de expansion (tablero vacıo con negra en posicion 0,1 yblanca en posicion 2,0 siendo turno de negras). La figura D.23 muestra la simulacion aleatoriaque se ha producido, en la que el jugador blanco es el ganador.

Figura D.23: Iteracion 15: Simulacion aleatoria

5. Retropropagacion: El resultado obtenido (blancas gana) se propaga desde la hoja a la raızactualizando los nodos, tal y como ilustra la figura D.24. En nodo hoja es blanco, por lotanto se incrementa en una unidad tanto numero de ganadas vi como el contador de visitasni. Propagamos el resultado al nodo padre, al ser negro y ganar el blanco, se actualiza elcontador de visitas ni, pero no el contador de ganadas vi. Es decir, si el nodo hijo gana, elpadre pierde. Se actualiza el nodo raız incrementando ambos valores en una unidad.

D.3.8. Decimosexta iteracion

La figura D.25 muestra tanto el arbol como la situacion del juego al comienzo de la decimosextaiteracion. Veamos como se desarrolla la iteracion en cada una de las fases:

1. Seleccion: Como muestra la figura D.26 se selecciona el nodo 0,1.




2. Expansion: El nodo seleccionado se ha visitado dos veces (ni= 2) alcanzando ası el numerode visitas mınimo para expandirse (ni= 2) y expandiendose. Al expandirse crea tantos hijoscomo situaciones alcanzables desde el nodo inicializando los valores ni y vide sus nodos acero. En la partida del Go el turno es del jugador blanco, por lo que estos nodos representanjugadas del jugador blanco. De todos los nodos creados se selecciona uno al azar, en este casose ha seleccionado el 0,0 tal y como muestra la figura D.27. Se realizan las acciones acordescon esta seleccion, es decir colocar una piedra blanca sobre la posicion 0,0 y el turno pasa aljugador negro.

3. Simulacion: En este paso se realiza una simulacion aleatoria partiendo de situacion actual dela partida (tablero vacıo con piedra negra sobre interseccion 0,1 , blanca sobre 0,0 y turno deblancas) de la misma forma que en las iteraciones anteriores. En este caso blancas gana.

4. Retropropagacion: El resultado obtenido (blancas gana) se propaga desde la hoja a la raızactualizando los nodos, tal y como ilustra la figura D.28.

D.3.9. Iteraciones de la de la decimoseptima a la vigesima

En la iteracion decimoseptima se ha seleccionado el nodo 0,2 , que se expande, eligiendo el nodopasar y perdiendo la simulacion. En la decimoctava, se selecciona en nodo 1,1 que se expande,eligiendo el nodo 1,0 y perdiendo la simulacion. En la decimonovena se selecciona el nodo 0,1, el

D.3. ITERACIONES 65


Figura D.27: Iteracion 16: Expansion

cual no se expande y pierde la simulacion. En la vigesima iteracion se selecciona el nodo 1,2, elcual no se expande y pierde la simulacion.

D.3.10. Futuras iteraciones

El ejemplo se ha realizado solo para veinte simulaciones, debido a que solo pretende ilustrar elmetodo. Sin embargo hay algunos conceptos que este no se reflejan en el ejemplo y que explicamosa continuacion.

Seleccion: En el paso de seleccion se avanza desde la raız hasta las hojas, decidiendo en cadauno de ellos que hijo seleccionar. El camino tomado puede conducir a que se atraviesen variosniveles, tal y como muestra la figura D.29.

Expansion: Conforme nos vamos acercando al final de la partida, el numero de jugadasposibles suele ser menor. Puede llegar el caso en que no se pueda realizar ninguna jugada,por lo tanto el nodo al expandirse no cree ningun hijo. En el juego del Go indica que lapartida ha finalizado (se ha pasado dos veces consecutivas).

Simulacion aleatoria: Las simulaciones aleatorias mostradas en el ejemplo eran relativamente



Figura D.29: Seleccion en el Go

cortas. El numero de movimientos realizado antes de acabar la partida puede ser muy pequenoo muy grande, dependiendo de la situacion de partida y hacia donde se dirija esta con losmovimientos realizados.

Retropropagacion: En la retropropagacion se recorren tantos nodos como nivel tenga la hoja.Esto quiere decir que se actualizan mas nodos o menos dependiendo el nivel al que se encuentrela hoja.

D.4. Eleccion del mejor nodo

En el ejemplo realizado, tras realizar las veinte iteraciones del metodo se ha obtenido el arbolrepresentado en la figura D.30. Como solo se necesita observar los nodos del primer nivel, el restose representan en la figura con un tamano menor.

Para la eleccion del mejor nodo, se observan los valores de los nodos alcanzables desde la raız,

D.5. NUMERO DE SIMULACIONES 67

tanto el contador de visitas nicomo el numero de partidas ganadas vi. El metodo implementadopara seleccionar el mejor nodo ha sido el de “Mas robustez” que elige el nodo que tiene un mayornumero de visitas ni

1. En este caso corresponden a los nodos: 0,1 , 0,2 , 1,0 y 1,1. El nodo 0,1 altener un valor vimenor se descarta. Elegir uno de los otros tres, dados los resultados conocidos,resulta indiferente, se elegirıa por ejemplo el primero, en este caso el 0,2.

Figura D.30: Arbol generado tras la simulacion de veinte iteraciones

D.5. Numero de simulaciones

En el ejemplo ilustrado se han realizado 20 iteraciones del metodo, un numero realmente pe-queno. Es necesario usar un numero significativo de iteraciones (dependiendo del problema podraconvenir uno u otro), es difıcil saber el numero apropiado por ello es muy util limitar este con eltiempo2.

1En caso de que varios tengan el mismo nodo cogera el que mayor valor tenga. Si ademas hay varios con el mismovalor elegira uno cualquiera de ellos.

2Hacer todas las iteraciones que se pueda en un tiempo dado.


Apendice E

Validacion

E.1. Go

Para validar el juego del Go, lo que se ha hecho ha sido forzar distintas situaciones y comprobadoque los resultados sean correctos. Al ser progresiva la implementacion se ha ido probando poco apoco las funcionalidades anadidas en cada caso. Para la comprobacion se ha visualizado por pantallael contenido de la matriz tablero, matriz de bloques y conjunto de bloques segun conviniese.

Figura E.1: Codigo que prueba los bloques

69

70 APENDICE E. VALIDACION

E.1.1. Reglas y bloques

Debido a que para crear ciertas situaciones se necesita colocar un gran numero de piezas yver el proceso de cada una resultarıa costoso. Se fueron realizando pruebas de forma incrementalanadiendo cada vez algunas lıneas de codigo para forzar situaciones a partir de ejemplos anteriores.El ejemplo que se muestra a continuacion ilustra el funcionamiento de bloques, las reglas de captura,suicidio y la del Ko. El codigo de la prueba correspondiente aparece en la figura E.1.

Para seguir el desarrollo del ejemplo se muestra paso a paso, la traza obtenida por pantallajunto con una ilustracion que muestra el tablero y los grupos de piedras. Ademas se acompana deexplicaciones para la total comprension de la prueba. Durante las explicaciones se emplea tantola palabra bloque como la palabra grupo, para hablar de los grupos de piedras conectados debidoa su adyacencia, explicado en la parte teorica del juego. En las figuras siguientes se agrupan lostableros de cuatro en cuatro y de dos en dos, igual que las salidas para hacer que ocupen menosespacio y sea mas sencilla su lectura.

Figura E.2: Jugadas (1-3)

La figura E.2 muestra la situacion del tablero y los grupos para las primeras jugadas. En lafigura E.3 se ven las trazas obtenidas para cada una de las situaciones anteriores. Como vemos separte de tablero vacıo, en el que no hay ningun grupo. A continuacion se coloca una piedra negracreando el primer grupo formado por una unica pieza. Luego el blanco coloca su piedra, creandoun nuevo grupo (con ındice 1) y le sigue el negro colocando una piedra adyacente a la blanca, peroal ser de distinto color forma un grupo nuevo.

E.1. GO 71

Figura E.3: Trazas jugadas (1-3)


La figura E.4 muestra la situacion del tablero y los grupos para las jugadas siguientes. En lafigura E.5 se ven las trazas obtenidas para cada una de las situaciones anteriores. Como vemos enla jugada 6, la pieza blanca colocada se une al bloque ya existente.




La figura E.6 muestra la situacion del tablero y los grupos para las jugadas siguientes. En la

E.1. GO 73

figura E.7 se ven las trazas obtenidas para cada una de las situaciones anteriores. Como vemosla jugada 8, no es valida ya que supone la eliminacion de libertades y por lo tanto suicidio. Latraza indica tambien que la accion no es valida y no realiza cambio en el tablero ni los grupos. Enla jugada 10, con la colocacion de la piedra negra se realiza una fusion entre dos grupos de colornegro, actualizando los valores de los ındices de los grupos segun corresponda. Algo similar ocurreen la jugada 11, la colocacion de la piedra blanca genera tambien una fusion y actualizacion de losındices de los grupos.


La figura E.8 muestra la situacion del tablero y los grupos para las jugadas siguientes. En lafigura E.9 se ven las trazas obtenidas para cada una de las situaciones anteriores.





La figura E.10 muestra la situacion del tablero y los grupos para las jugadas siguientes. En lafigura E.11 se ven las trazas obtenidas para cada una de las situaciones anteriores. Como vemosen la jugada 14, se produce una fusion entre los dos grupos de blancas existentes.

E.1. GO 75



La figura E.12 muestra la situacion del tablero y los grupos para las jugadas siguientes. En lafigura E.13 se ven las trazas obtenidas para cada una de las situaciones anteriores. Como vemosen la jugada 15, la pieza negra se une al grupo ya existente.





E.1. GO 77



La figura E.16 muestra la situacion del tablero y los grupos para las jugadas siguientes. En lafigura E.17 se ven las trazas obtenidas para cada una de las situaciones anteriores. Como vemos lajugada 20 no es posible, ya que supondrıa un suicidio tanto para el grupo 2, como el 5.




La figura E.18 muestra la situacion del tablero y los grupos para las jugadas siguientes. En lafigura E.19 se ven las trazas obtenidas para cada una de las situaciones anteriores. Como vemosen la jugada 22, la pieza negra produce la muerte tanto del grupo 2 como del 5, retirandose todaslas piedras de estos grupos del tablero.

E.1. GO 79







La figura E.22 muestra la situacion del tablero y los grupos para las jugadas siguientes. En lafigura E.23 se ven las trazas obtenidas para cada una de las situaciones anteriores. Como vemosen la imagen al colocar la piedra blanca en la jugada 25 se captura una piedra negra. En la jugada26, el jugador negro quiere colocar una pieza para matar a la piedra blanca, pero esta jugada noes posible, debido a que el tablero volverıa a la situacion anterior (jugada 24) infringiendo la reglade Ko.

E.1. GO 81



La figura E.24 muestra la situacion del tablero y los grupos para las jugadas siguientes. En lafigura E.25 se ven las trazas obtenidas para cada una de las situaciones anteriores. Como vemosen la jugada 27 coloca pieza el jugador negro ya que la jugada anterior no era valida.



Figura E.26: Jugada (29)

La figura E.26 muestra la situacion del tablero y los grupos para las jugadas siguientes. En lafigura E.27 se ven las trazas obtenidas para cada una de las situaciones anteriores. Ahora si quepuede colocar el jugador negro la pieza en esta posicion, sin incumplir la regla del Ko, ya que lasituacion del tablero no corresponde a la de la jugada anterior (jugada 27).

E.1. GO 83

Figura E.27: Trazas jugada (29)

E.1.2. Recuento de puntuaciones

Comprobemos ahora que el recuento de puntos es correcto. Para el recuento se usa un sistemade bloques pero en vez de bloques de piedras se crean bloques de casillas libres. Si ese conjuntode casillas libres esta rodeado por piezas de un solo jugador ese bloque pertenecera a ese jugador.Comenzaremos viendo la salida de bloques y puntuacion para el ejemplo anterior.

Figura E.28: Territorios del recuento de puntuaciones

Tal y como mesta la figura E.28 y la figura E.29, hay 8 bloques de vacıas. Algunos de ellosno pertenecen a ningun jugador y otros al jugador negro. En este ejemplo el jugador blanco noconsigue ningun territorio. En el dibujo del tablero las intersecciones marcadas con a, indican quepertenecen a territorios del jugador negro y las marcadas con c a ninguno de los dos jugadores.Observemos que como durante la partida se habıan capturado diversas piezas estas se tienen encuenta para el calculo de la puntuacion final.

Veamos ahora otro ejemplo. La situacion final del tablero viene representada por la figura E.30,en ella las intersecciones marcadas por a pertenecen al territorio del jugador negro, las interseccionesmarcadas por b al territorio del jugador blanco y las intersecciones marcadas por c a ninguno de


Figura E.29: Recuento de puntuaciones para el ejemplo anterior

los dos jugadores. El codigo se ha elaborado de forma que no se produce ninguna captura, ademaslo omitimos debido a su gran extension y carencia de interes.

Figura E.30: Situacion de prueba puntuacion

En la figura E.31 podemos ver la traza que se muestra por pantalla en lo que respecta al calculode territorios. Podemos ver los bloques de conjuntos vacıos creados y su asignacion a los jugadores.

E.1. GO 85

Figura E.31: Bloques prueba territorios

En la figura E.32 vemos las puntuaciones obtenidas tanto para modo de recuento japones(arriba) como chino (abajo).

Figura E.32: Puntuacion prueba territorios


E.2. MCTS

Como sistema de validacion, por un lado se ha realizado un numero determinado de simulacionesy comprobado que en cada uno de los pasos se realizan las acciones pertinentes. La clase disponede un booleano que si es activado muestra poco a poco cada uno de los pasos de la simulacionrealizada. Activado este flag, los resultados se muestran poco a poco, avanzando conforme se pulsela tecla enter, haciendo ası mas facil seguir la simulacion. El Apendice D contiene un ejemplo desalida de simulacion que se apoya en distintas imagenes para hacer mas sencillo el seguimiento deeste y su comprension.

Por otro lado, se ha forzado a que se diesen distintas situaciones “especiales” y visto si losresultados obtenidos son los adecuados. Estas situaciones corresponden a probar la parte de re-utilizacion del arbol para diversas simulaciones y permitir realizar la simulacion desde distintospuntos, es decir, todo lo relacionado con el apartado 5.2 de la memoria.

Como el tamano del tablero no interviene en estas pruebas, hemos tomado un tablero 2x2 debidoa que a tamano menor es mucho mas sencillo seguir el ejemplo, e incluso podemos representar elarbol de forma grafica. El nodo se extendera cuando se hayan visitado al menos dos veces.

E.2.1. Eficiencia del metodo

La eficiencia del metodo MCTS no ha podido ser testada, ya que no se dispone de jugadoresprofesionales a quien enfrentarse, ni de ordenadores tan potentes como los usados en las compe-ticiones reales, pero si que se ha visto que posee cierta inteligencia segun las jugadas realizadas,sobre todo en tamanos de tablero pequenos o con tiempos grandes de procesado.

En las pruebas realizadas a los usuarios, recogidas en la seccion E.3.2 de este mismo capıtulo,se realizan varias preguntas asociadas a la inteligencia proporcionada por el metodo al juego. Seobserva que todos los usuarios consideran al jugador virtual como “inteligente”.

E.2.2. Avanzar cuando el arbol es vacıo

Partiendo de tablero vacıo, veamos el efecto que produce las operaciones primero de avance yluego busqueda en el arbol. La figura E.33 muestra el ejemplo grafico de lo que sucede y la figuraE.34 muestra la traza obtenida. Como vemos en la traza se mantiene lo que la figura representa.

Figura E.33: Avance y busqueda a partir de arbol vacıo

E.2. MCTS 87

Figura E.34: Traza del ejemplo (Avance y busqueda a partir de arbol vacıo)

E.2.3. Avanzar cuando el arbol es no vacıo

En este ejemplo, primero se ha realizado una busqueda para que el arbol se cree y luego se haavanzado sobre el. Finalmente se ha realizado otra busqueda (despues de avanzar) para verificarque todo ha funcionado correctamente. La figura E.35 muestra el ejemplo grafico de lo que sucedey la figuraE.36 muestra la traza obtenida. Como vemos en la traza se mantiene lo que la figurarepresenta. Como el numero de simulaciones realizadas no es muy alto, no todos los nodos llegana expandirse, si el nodo con el que se avanzas fuera uno que no llego ha expandirse, funcionacompletamente igual, este nodo pasa a ser raız y al no tener hijos pues el arbol tendra solo un nodohasta que se llame a la funcion de simulacion.




E.2.4. Mezcla de las anteriores: Avanzar sobre arbol vacıo y no vacıo.

Partiendo de tablero vacıo, veamos el efecto que produce las operaciones primero de avance,luego busqueda en el arbol, luego de nuevo busqueda, avance y busqueda otra vez. La figura E.37muestra el ejemplo grafico de lo que sucede (obviando la ultima busqueda) y la figuraE.38 muestrala traza obtenida.


E.3. APLICACION 89


E.3. Aplicacion

Las pruebas de la aplicacion pueden dividirse en dos grandes bloques: pruebas de funcionamientoy pruebas de usabilidad. Veamos cada una de ellas.

E.3.1. Pruebas de funcionamiento

En estas pruebas se ha probado que la aplicacion realiza las acciones que le fueron encomenda-das. A continuacion detallamos las principales pruebas realizadas.

Navegacion entre ventanas: Se comprobo que cada ventana se abre una ventana cuando setiene que abrir o se cierra cuando se tiene que cerrar.

Opciones seleccionadas: Las opciones de la partida de Go que se juega en la ventana de juegodeben corresponder a las opciones seleccionadas en la ventana anterior (ventana de opciones).Para ello se han seleccionado las opciones y comprobado que efectivamente corresponden.En la ventana de juego viendo la interfaz se comprobo que el nombre del jugador, tamanodel tablero, color de piedras del jugador y tiempo lımite coincidıa con el seleccionado. Yal finalizar la partida en la ventana emergente, que el tipo de recuento y la penalizacioncorrespondıan con los seleccionados en la ventana de opciones. Esta prueba fue llevada a caboen varias ocasiones probando a seleccionar opciones distintas a las anteriores y cambiandosolo algunas de ellas.


Tiempo limite: Se comprobo que el contador del reloj se decrementaba en cada segundo yque al sobrepasar el tiempo lımite se pasase el turno al otro jugador.

Acciones teclado: Se cliqueo en diversos puntos del tablero y se vio si actuaba correctamente:Cliqueando en intersecciones, en puntos muy cercanos a ellas, en zonas fuera del rango deestas o en los bordes del tablero. Todas ellas realizadas cuando es el turno del jugador humanoy siendo el turno del ordenador. Ademas se probo que se visualizasen las piedras cuando fueraconveniente, mostrarse al colocar una pieza o desaparecer en caso de captura y que no dejaserealizar movimientos prohibidos. Para ello se trabajo con un tablero pequeno, haciendo queestas situaciones se pudiesen dar mas rapido, y se forzo a que ocurriesen para ası testear queefectivamente funcionaban como debıan.

Boton pasar: Se comprobo que si se cliqueaba el boton “Pasar” pasaba el turno al siguientejugador, realizando tambien la accion correspondiente al juego del Go y finalizando la partidasi se hubiera pasado anteriormente.

E.3.2. Pruebas de usabilidad e inteligencia del juego

El problema de probar esta aplicacion, sobre todo la inteligencia del juego, es que se necesitagente conocedora del Go. Solo se han encontrado cuatro usuarios que sepan jugar, los cuales poseenun nivel bastante bajo (algunos acaban de aprender a jugar y otros ya lo tienen bastante olvidado).

Los usuarios a los que se les ha realizado la evaluacion coinciden en que la el programa esmuy sencillo de usar, ademas de tener una interfaz muy agradable. El funcionamiento les parecebueno, considerando el jugador virtual bastante inteligente, dos de los usuarios no fueron capacesde vencer al ordenador en ninguna de las partidas jugadas. Tambien se ha detectado que en tablerospequenos parece que realice jugadas mas inteligentes, si es cierto que ninguno los usuarios ha jugadoninguna partida completa en tableros grandes y que en estas los efectos se ven reflejados muchasjugadas mas tarde, por lo que tampoco es realmente fiable esta informacion. Para finalizar, todoshan concluido con que les gusta la aplicacion, eso sı, algunos se sentıan frustrados por no conseguirvencer ninguna partida.

Apendice F

Manual de usuario

En este apendice se explica como usar la aplicacion que permite jugar al Go enfrentandoseal ordenador. Para ello veremos de que ventanas esta formado, la navegacion entre ellas y comorealizar la interaccion con el programa.

F.1. Ventanas y navegacion

La interfaz de la aplicacion esta formada por cuatro ventanas:

Ventana de inicio: Es el menu del juego.

Ventana de opciones: Permite seleccionar las opciones de la partida a jugar.

Ventana de juego: Es donde se juega la partida contra el ordenador.

Ventana de reglas: Da informacion acerca de las reglas y opciones a elegir.

La figura F.1 muestra el esquema de navegacion entre ellas.

Figura F.1: Navegacion entre ventanas

91

92 APENDICE F. MANUAL DE USUARIO

F.2. Ventana de inicio

Esta ventana corresponde al menu del juego, se abre al ejecutar la aplicacion y permaneceabierta mientras se este usando la aplicacion.

Figura F.2: Ventana de Inicio

Desde ella se pueden realizar las siguientes acciones:

Jugar una partida: Pulsando al boton “Jugar”. Esto hace que se abra la ventana de opcionesexplicada en la seccion F.3

Acceder a las reglas del Go: Pulsando el boton “Reglas”. Esto hace que se abra la ventana dereglas explicada en la seccion F.5

Abandonar el juego: Pulsando el boton “Salir”. Se abandona el juego cerrando todas lasventanas de la aplicacion.

F.3. Ventana de opciones

En esta ventana se eligen las opciones antes de jugar la partida, acorde con la figura F.3. Lasopciones a elegir son las siguientes:

1. Color de piedras del usuario: Pudiendo elegir entre Negro o Blanco marcando la opcioncorrespondiente.

2. Sistema de recuento: Permite elegir entre el modo de recuento de puntuacion Japones o Chinomarcando la casilla correspondiente.

3. Nombre del jugador: Permite insertar el nombre del jugador humano (usuario)

4. Tamano del tablero: Se elige seleccionando el tamano deseando sobre el desplegable.

5. Penalizacion: Permite decir que beneficio (puntuacion extra) tiene el jugador blanco porempezar mas tarde la partida, se elige seleccionando del desplegable la cantidad deseada.

6. Tiempo lımite por turno: Corresponde al tiempo del que dispone cada jugador para realizaruna accion durante su turno del juego (Colocar pieza/Pasar).

Ademas tiene estos tres botones:

Continuar: Permite comenzar la partida de Go; para ello, cierra la ventana de opciones yabre la ventana de juego con las opciones seleccionadas.

F.4. VENTANA DE JUEGO 93

Cancelar: Cierra la ventana de opciones.

Ayuda: Abre la ventana de reglas en la seccion de ayuda de opciones.

Figura F.3: Ventana de opciones

F.4. Ventana de juego

Figura F.4: Ventana de juego

Esta formada por ocho zonas (correspondiente a las zonas marcadas en la figura F.4):

1. Tablero: Corresponde al tablero del juego. Durante su turno, puede colocar una piedra pul-sando sobre una interseccion libre. Cuando sea el turno del ordenador este podra colocar unapiedra de su color.


2. Tiempo del usuario: Durante su turno, aparece sobre la zona marcada en 2 un tempori-zador, que indica el tiempo que le queda para realizar una accion. Pasado este tiempo (eltemporizador marque cero) se interpretara como que su accion ha sido “Pasar”.

3. Tiempo del ordenador: Cuando sea el turno del ordenador, aparecera sobre la zona marcadacon 3 un temporizador, que indica el tiempo que le queda al ordenador para poder realizarsu accion, de la misma forma que el tiempo de usuario.

4. Nº de piedras del ordenador capturadas: Indica cuantas piedras ha capturado el jugador alordenador1.

5. Nº de piedras del jugador capturadas: Indica cuantas piedras ha capturado el ordenador aljugador2.

6. Mensaje de turno: Mensaje en el que indica de quien es el turno.

7. Mensaje de ultima jugada: Mensaje que indica cual es la ultima jugada realizada.

8. Botones: Cliqueando en ellos realiza las acciones que indicamos a continuacion:

a) Pasar: Cuando es el turno del usuario pasa el turno y si es el turno del ordenador avisade que no es posible pasar mediante la ventana emergente que muestra la figura F.5.

b) Abandonar: Abandona la partida.

c) Reglas: Abre la ventana de reglas.

Figura F.5: Mensaje “No puedes pasar”

La partida comienza nada mas abrirse la ventana y por tanto tambien se pone en marcha eltemporizador del jugador negro, que es el encargado de comenzar. Durante su turno cada jugadorpuede:

Colocar una piedra: Cliqueando sobre las intersecciones libres del tablero, siempre que secumplan las reglas de suicidio y Ko. Si la colocacion de esta pieza incumple alguna de estasreglas, se avisa mediante una ventana emergente (como la de la figura F.6 para el caso desuicidio) y el tiempo sigue decrementandose.

Figura F.6: Mensaje de suicidio

Pasar: Cliqueando sobre el boton “Pasar” o esperando a que se acabe el tiempo del turno.

1Junto al contador hay un cuenco sobre el que se iran anadiendo piedras (imagenes) dependiendo del nº depiedras capturadas.

2Se anaden tambien imagenes de piedras dependiendo de la captura de estas

F.5. VENTANA DE REGLAS 95

Una vez hayan pasado consecutivamente los dos jugadores (usuario y ordenador) el programamuestra una ventana emergente (figura F.7) con el resultado de la partida y cierra la ventana dejuego.

Figura F.7: Mensaje resultado de la partida

F.5. Ventana de reglas

Esta formado por dos zonas tal y como muestra la figura F.8:

1. Directorio arbol: Tiene clasificada la informacion en forma de arbol, mediante carpetas des-plegables y archivos. Si queremos abrir un archivo o carpeta, cliquearemos sobre el nombrede esta. Si queremos desplegar una carpeta para ver sus componentes, basta con hacer dobleclic sobre ella o pulsar sobre el circulito que hay a la izquierda (este ultimo sirve tanto paradesplegar como para recoger).

2. Texto: Muestra un texto u otro dependiendo de lo que se haya seleccionado en el directorio.

Figura F.8: Ventana de reglas


Glosario

PFC: Proyecto fin de carreara

GIGA: Grupo de Informatica Grafica Avanzada

Negras / Negro: Jugador con piedras negras

Blancas / Blanco: Jugador con piedras blancas

kyu: grado de Go correspondiente a estudiante, abreviado k

dan: grado de Go correspondiente a experto, abreviado d

MCTS: Metodo de Monte-Carlo Tree Search (Busqueda en arboles de Monte-Carlo)

UCT: Upper Confidence bounds applied to Trees

RF: Requisito funcional

RNF: Requisito no funcional

97


Bibliografıa

[1] G.M.J-B.Chaslot. Monte-Carlo Tree Search, 2010.http://www.unimaas.nl/games/files/phd/Chaslot thesis.pdf

[2] Teorıa de juegos http://es.wikipedia.org/wiki/Teor%C3%ADa de juegos

[3] Algoritmos de juegos http://www.gran-angular.net/wp-content/uploads/2008/07/algoritmos-de-juegos.pdf

[4] Sistema determinista http://es.wikipedia.org/wiki/Sistema determinista

[5] Sistema estocastico http://es.wikipedia.org/wiki/Estoc%C3%A1stico

[6] Poda αβ http://es.wikipedia.org/wiki/Poda alfa-beta

[7] Funcion de evaluacion http://www.fenach.cl/docs/memoria/node47.html

[8] Funcion de evaluacion. Wikipedia. http://es.wikipedia.org/wiki/Funci%C3%B3n de evaluaci%C3%B3n

[9] Go. Wikipedia espanola. http://es.wikipedia.org/wiki/Go

[10] Go - Game. Wikipedia inglesa. http://en.wikipedia.org/wiki/Go %28game%29

[11] Computer Go. Wikipedia inglesa. http://en.wikipedia.org/wiki/Computer Go

[12] Por que aprender a jugar al go por Franklin Bassarskyhttp://www.go.org.ar/page.php?name=porque

[13] Camino interactivo hacia el Go http://www.thinkchile.com/playgo/

[14] KGS Go http://www.gokgs.com/tutorial/index.jsp

[15] Asociacion del Go de Andalucıa http://www.andalucia-go.org/index.php?page=main

[16] Go rules. Wikipedia inglesa. http://en.wikipedia.org/wiki/Rules of Go#End 2

[17] Go vida y muerte http://es.wikipedia.org/wiki/Vida y muerte %28go%29

[18] Informacion completa http://es.wikipedia.org/wiki/Informaci%C3%B3n completa

[19] Sensei’s Library, Web colaborativa sobre el juego del Go. http://senseis.xmp.net/

[20] Yenny Noa Vargas, Estrategias para mejorar el Balance entre Ex-ploracion y Explotacion en Optimizacion de Enjambre de Partıculashttp://www.yorku.ca/sychen/research/theses/2011 Yenny MSc.pdf

[21] Random Search Algorithms http://www.wpi.edu/Pubs/E-project/Available/E-project-041808-104235/unrestricted/Random Search Algorithms Final Presentation.pdf

99

http://www.unimaas.nl/games/files/phd/Chaslot_thesis.pdf

http://es.wikipedia.org/wiki/Teor%C3%ADa_de_juegos

http://www.gran-angular.net/wp-content/uploads/2008/07/algoritmos-de-juegos.pdf

http://www.gran-angular.net/wp-content/uploads/2008/07/algoritmos-de-juegos.pdf

http://es.wikipedia.org/wiki/Sistema_determinista

http://es.wikipedia.org/wiki/Estoc%C3%A1stico

http://es.wikipedia.org/wiki/Poda_alfa-beta

http://www.fenach.cl/docs/memoria/node47.html

http://es.wikipedia.org/wiki/Funci%C3%B3n_de_evaluaci%C3%B3n

http://es.wikipedia.org/wiki/Go

http://en.wikipedia.org/wiki/Go_%28game%29

http://en.wikipedia.org/wiki/Computer_Go

http://www.go.org.ar/page.php?name=porque

http://www.thinkchile.com/playgo/

http://www.gokgs.com/tutorial/index.jsp

http://www.andalucia-go.org/index.php?page=main

http://www.andalucia-go.org/index.php?page=main

http://en.wikipedia.org/wiki/Rules_of_Go#End_2

http://es.wikipedia.org/wiki/Vida_y_muerte_%28go%29

http://es.wikipedia.org/wiki/Informaci%C3%B3n_completa

http://senseis.xmp.net/

Part�culas http://www.yorku.ca/sychen/research/theses/2011_Yenny_MSc.pdf

Part�culas http://www.yorku.ca/sychen/research/theses/2011_Yenny_MSc.pdf

http://www.wpi.edu/Pubs/E-project/Available/E-project-041808-104235/unrestricted/Random_Search_Algorithms_Final_Presentation.pdf

http://www.wpi.edu/Pubs/E-project/Available/E-project-041808-104235/unrestricted/Random_Search_Algorithms_Final_Presentation.pdf

100 BIBLIOGRAFIA

[22] Desviacion estandar. Desviacion tıpica. http://es.wikipedia.org/wiki/Desviaci%C3%B3n est%C3%A1ndar

[23] Intervalo de confianza http://en.wikipedia.org/wiki/Confidence interval

[24] G.M.J-B. Chaslot, S. Bakkes, I. Szita, and P. Spronck. Monte-Carlo Tree Search:A New Framework for Game AI. In Proceedings of the Fourth Artificial Intelli-gence and Interactive Digital Entertainment Conference. AAAI Press, Menlo Park,CA, 2008. http://sander.landofsand.com/publications/Monte-Carlo Tree Search -A New Framework for Game AI.pdf

[25] The Monte-Carlo Revolution in Go, JFFoS’2008: Japanese-French Frontiers of Scien-ce Symposium. http://remi.coulom.free.fr/JFFoS/JFFoS.pdf

[26] The Java Tutorials http://docs.oracle.com/javase/tutorial/java/

[27] Lesson: Using Swing Components http://docs.oracle.com/javase/tutorial/uiswing/components/index.html

[28] G.M.J.B. Chaslot, M.H.M. Winands, and H.J. van den Herik. Parallel monte-carlo tree search. Proceedings of the Conference on Computers and Games2008 (CG 2008), volume 5131 of Lecture Notes in Computer Science, pa-ges 60-71. Springer, Berlin Heidelberg, 2008. http://www.personeel.unimaas.nl/m-winands/documents/multithreadedMCTS2.pdf

[29] G.M.J-B. Chaslot, S. de Jong, J-T. Saito, and J.W.H.M. Uiterwijk. Monte-CarloTree Search in Production Management Problems. In Proceedings of the 18th Be-NeLux Conference on Artificial Intelligence, Namur, Belgium, pages 91-98, 2006.http://www.personeel.unimaas.nl/G-chaslot/papers/pmp.pdf

[30] Maarten P.D. Schadd, Mark H.M. Winands, H. Jaap van den Herik, Guillaume M.J-B. Chaslot, and Jos W.H.M. Uiterwijk. Single-Player Monte-Carlo Tree Search, 2008.http://www.informatik.uni-freiburg.de/∼ki/teaching/ws0910/gamesem/schadd-et-al-2008.pdf

[31] Christopher D.Rosin. Nested Rollout Policy Adaptation for Monte Carlo Tree Search,2011. http://www.chrisrosin.com/rosin-ijcai11.pdf

[32] Arpad Rimmel. Thesis : Improvements and Evaluation of the Monte-Carlo TreeSearch Algorithm, 2009. http://www.lri.fr/∼rimmel/Files/ArpadRimmelThese.pdf

[33] Julien Kloetzer, Hiroyuki Iida, and Bruno Bouzy. The Monte-Carlo Approachin Amazons, 2007. http://web.mi.parisdescartes.fr/∼bouzy/publications/KIB-MCAmazons-CGW07.pdf

[34] Mark H.M. Winands, Yngvi Bjornsson, and Jahn-Takeshi Sai-to. Monte-Carlo Tree Search in Lines of Action, 2010.http://www.ru.is/faculty/yngvi/pdf/WinandsB10a.pdf

[35] Levente Kocsis and Csaba Szepesvari. Bandit based Monte-Carlo Planninghttps://web.engr.oregonstate.edu/∼afern/classes/cs533/notes/uct.pdfhttps://web.engr.oregonstate.edu/∼afern/classes/cs533/notes/uct.pdf

[36] Fran�cois Van Lishout, Guillaume Chaslot, and JosW.H.M. Uiterwijk. Monte-Carlo Tree Search in Backgammonhttp://orbi.ulg.ac.be/bitstream/2268/28469/1/vanlishout backgammon.pdf

[37] I. Szita; G.M.J-B. Chaslot, P. Spronck. Monte-Carlo Tree Search in Settlersof Catan. In Proceedings of the Twelfth International Advances in Compu-ter Games Conference (ACG’09), Pamplona, Spain, May 11-13, 2009. In Press.http://www.personeel.unimaas.nl/g-chaslot/papers/ACGSzitaChaslotSpronck.pdf

http://es.wikipedia.org/wiki/Desviaci%C3%B3n_est%C3%A1ndar

http://en.wikipedia.org/wiki/Confidence_interval

http://sander.landofsand.com/publications/Monte-Carlo_Tree_Search_-_A_New_Framework_for_Game_AI.pdf

http://sander.landofsand.com/publications/Monte-Carlo_Tree_Search_-_A_New_Framework_for_Game_AI.pdf

http://remi.coulom.free.fr/JFFoS/JFFoS.pdf

http://docs.oracle.com/javase/tutorial/java/

http://docs.oracle.com/javase/tutorial/uiswing/components/index.html

http://www.personeel.unimaas.nl/m-winands/documents/multithreadedMCTS2.pdf

http://www.personeel.unimaas.nl/m-winands/documents/multithreadedMCTS2.pdf

http://www.personeel.unimaas.nl/G-chaslot/papers/pmp.pdf

http://www.informatik.uni-freiburg.de/~ki/teaching/ws0910/gamesem/schadd-et-al-2008.pdf

http://www.informatik.uni-freiburg.de/~ki/teaching/ws0910/gamesem/schadd-et-al-2008.pdf

http://www.chrisrosin.com/rosin-ijcai11.pdf

http://www.lri.fr/~rimmel/Files/ArpadRimmelThese.pdf

http://web.mi.parisdescartes.fr/~bouzy/publications/KIB-MCAmazons-CGW07.pdf

http://web.mi.parisdescartes.fr/~bouzy/publications/KIB-MCAmazons-CGW07.pdf

http://www.ru.is/faculty/yngvi/pdf/WinandsB10a.pdf

https://web.engr.oregonstate.edu/~afern/classes/cs533/notes/uct.pdf

https://web.engr.oregonstate.edu/~afern/classes/cs533/notes/uct.pdf

http://orbi.ulg.ac.be/bitstream/2268/28469/1/vanlishout_backgammon.pdf

http://www.personeel.unimaas.nl/g-chaslot/papers/ACGSzitaChaslotSpronck.pdf

BIBLIOGRAFIA 101

[38] Hilmar Finnsson, Yngvi Bjornsson. CadiaPlayer: Search-Control Tech-niques http://posgrado.escom.ipn.mx/biblioteca/CadiaPlayer%20Search-Control%20Techniques.pdf

http://posgrado.escom.ipn.mx/biblioteca/CadiaPlayer%20Search-Control%20Techniques.pdf

http://posgrado.escom.ipn.mx/biblioteca/CadiaPlayer%20Search-Control%20Techniques.pdf

Date post:	12-Oct-2018
Category:	Documents
Upload:	vukhuong
View:	214 times
Download:	0 times

M etodo de Monte-Carlo Tree Search (MCTS) para … · Monte-Carlo Tree Search independiente del...

Documents