Um player para General Game Playing baseado em busca em árvores de Monte Carlo

(1)

Instituto de Computa¸

c˜

ao

Departamento de Ciˆ

encia da Computa¸

c˜

ao

CARLOS BRUNO PIUCCI GARCIA S ´

A

UM PLAYER PARA GENERAL GAME PLAYING

BASEADO EM BUSCA EM ARVORES DE MONTE

CARLO

Niter´

oi-RJ

2017

(2)

ii CARLOS BRUNO PIUCCI GARCIA S ´A

UM PLAYER PARA GENERAL GAME PLAYING BASEADO EM BUSCA EM ARVORES DE MONTE CARLO

Trabalho submetido ao Curso de Bacharelado em Ciência da Computa¸cão da Universidade Federal Fluminense como requisito parcial para a obten¸cão do t´ıtulo de Bacharel em Ciência da Computa¸cãoo.

Orientadora: Aline Marins Paes Carvalho

Niter´oi-RJ 2017

(3)

(4)

Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF

S111 Sá, Carlos Bruno Piucci Garcia

Um player para General Game Playing baseado em busca em árvores de Monte Carlo / Carlos Bruno Piucci Garcia Sá. – Niterói, RJ : [s.n.], 2017.

65 f.

Projeto Final (Bacharelado em Ciência da Computação) – Universidade Federal Fluminense, 2017.

Orientadora: Aline Marins Paes Carvalho.

1. Inteligência artificial. 2. Jogo em computador. I. Título. CDD 006.3

(5)

(6)

vi

Agradecimentos

Aos meus pais, pelo financiamento, incentivo e apoio incondicional que tornaram poss´ıvel a conclusão desta jornada. A minha orientadora Aline Paes, pelo empenho de-dicado à elabora¸cão deste trabalho. À Universidade Federal Fluminense pelo ambiente criativo e amigável que proporciona. A todos que direta ou indiretamente fizeram parte da minha forma¸cão, o meu muito obrigado.

(7)

Resumo

Neste trabalho será abordado o tópico de General Game Playing (GGP) que é uma subárea da Inteligência Artificial, e consiste em desenvolver formas de modelar e resolver jogos de modo genérico. O objetivo principal deste trabalho é desenvolver um agente jogador de General Game Playing, capaz de jogar jogos arbitrários modelados na linguagem de Game Description Language (GDL), os quais nunca tenha se deparado an-teriormente, mas ainda assim escolhendo movimentos válidos e apresentando um n´ıvel de jogo convincente, ou seja, que não fa¸ca escolhas aleatórias de movimentos. O agente desenvolvido neste trabalho, implementado em uma camada acima de um conhecido arca-bou¸co de GGP é capaz de jogar com um ser humano e com outros agentes de GGP. Para verificar se de fato o agente desenvolvido possui as habilidades requeridas em GGP, foram executados testes, consistindo de partidas entre os agentes, de diversos jogos. Diferentes métodos de escolha de movimentos e variadas configura¸cões das constantes envolvidas na implementa¸cão foram experimentadas, a fim de investigar a consequência da varia¸cão destes componentes. O agente jogador de GGP desenvolvido neste trabalho apresentou um comportamento satisfatório, pois foi capaz de jogar os diversos jogos que lhe foram apresentados cometendo somente 0,27% de movimentos ilegais dentre todos os movimen-tos que executou. Assim, neste trabalho foi poss´ıvel obter um agente jogador capaz de jogar corretamente jogos que nunca havia presenciado antes.

(8)

viii

Abstract

In this work the subject is the General Game Playing topic which is a subarea of Artificial Inteligence, that consist of developing ways to modelate and solve any game. The main goal of this work is developing an agent of General Game Playing, which can play arbitrary games modeled in Game Description Language, games that the agent has never seen before, still choosing valid moves. The developed agent in this work, implemented over a layer above a GGP base code is capable of playing against a human or other GGP agents. To check if in fact the agent has the required skills for GGP, tests were runned, which was matches between the agents, of several games. Several move picking methods and several constant configurations were experimented to investigate de consequence of varying these components. The GGP agent developed in this work reached a good behavior, because it was capable of playing several games with only 0,27% of ilegal move rate. Therefore, in this work it was possible to obtain an agent capable of playing correctly games that it has never played before.

(9)

Sum´

ario

Resumo vii

Abstract viii

Lista de Figuras xi

Lista de Tabelas xii

1 Introdu¸c˜ao 1

1.1 Objetivos . . . 2

1.2 Solu¸c˜ao Proposta . . . 2

1.3 Organiza¸c˜ao do Texto . . . 3

2 Fundamenta¸c˜ao Te´orica 4 2.1 General Game Playing . . . 4

2.2 Game Description Language (GDL) . . . 8

2.3 Monte Carlo Search . . . 11

2.4 Monte Carlo Tree Search . . . 17

3 Um player de General Game Playing 19 4 Estudo de Caso 38 4.1 Jogos variados . . . 39

4.2 Calibra¸c˜ao da constante do algoritmo MCTS . . . 41

4.3 Impacto do pr´e-processamento da ´arvore . . . 47

(10)

x

5 Conclus˜oes 50

(11)

Lista de Figuras

2.1 Grafo de um jogo single-player . . . 6

2.2 Grafo de um jogo multi-player . . . 7

2.3 Arvore expandida na MCS . . . .´ 13

2.4 Etapa de explora¸c˜ao da MCS . . . 14

2.5 C´alculo do valor-objetivo dos estados-folha . . . 15

3.1 M´odulos do arcabou¸co de GGP . . . 20

3.2 Vis˜ao geral da implementa¸c˜ao do agente de GGP . . . 20

3.3 Diagrama de classe da interface com o interpretador de GDL . . . 23

3.4 Comunica¸c˜ao do agente com a base de GGP . . . 24

3.5 Fluxograma de uma partida . . . 30

3.6 Diagrama de classe da implementa¸c˜ao do agente de GGP . . . 30

3.7 Composi¸c˜ao da ´arvore de estat´ısticas . . . 31

4.1 Evolu¸c˜ao das instˆancias de espa¸co de estados pequeno . . . 43

4.2 Evolu¸cão das instâncias de espa¸co de estados médio . . . 45

4.3 Evolu¸c˜ao das instˆancias de espa¸co de estados grande . . . 46

(12)

xii

Lista de Tabelas

4.1 Erros do agente jogador de GGP . . . 39

4.2 Estat´ısticas dos erros do agente jogador . . . 40

4.3 Resultados das partidas de Pawn Whopping . . . 42

4.4 Resultados em ordem cronol´ogica de Pawn Whopping . . . 44

4.5 Resultados das partidas de Connect Four . . . 44

4.6 Resultados em ordem cronol´ogica de Connect Four . . . 45

4.7 Resultados das partidas de Breakthrough . . . 46

4.8 Resultados em ordem cronol´ogica de Breakthrough . . . 47

(13)

Cap´ıtulo 1

Introdu¸

c˜

ao

A Inteligência Artificial é o campo da Ciência da Computa¸cão que busca for-mas de desenvolver sistefor-mas capazes de resolver problefor-mas. Não há consenso sobre a defini¸cão da Inteligência Artificial. Algumas abordagens têm como objetivo simu-lar o comportamento ou pensamento humano. Outras abordagens têm o foco no de-sempenho da inteligência artificial, isto é, se ela executa corretamente o que foi pro-jetada para executar [Russel e Norvig 2004]. Muitas áreas da Inteligência Artificial se focam em resolver problemas espec´ıficos, porém a área de General Artificial Inteligence (GAI) mantém o foco em descobrir formas de representar e resolver problemas gen´ eri-cos [Goertzel e Pennachin 2007]. Um tópico recente dentro da GAI é o General Problem Solving, que consiste em estudar a natureza dos problemas, os mecanismos de solu¸cão de problemas e estruturas que todos os problemas têm em comum, para que seja poss´ıvel explorar maneiras de se elaborar algoritmos capazes de solucionar qualquer problema com que se deparem, sem ter conhecimento prévio sobre eles. Um subconjunto deste tópico é o General Game Playing (GGP), que consiste em projetar agentes que sejam capazes de jogar qualquer jogo, sem ter conhecimento prévio dele, analogamente a resolver qual-quer problema. Jogos são bastante similares a problemas no âmbito da abstra¸cão de seu universo através de estruturas matemáticas.

Uma solu¸cão de General Game Playing tem pontos favoráveis e pontos desvanta-josos. Por um lado, um agente de GGP não transcende um agente inteligente elaborado para um jogo espec´ıfico, pois o agente de GGP não tem informa¸cões sobre o jogo, en-quanto o agente espec´ıfico tem embutido em sua implementa¸cão estratégias e heur´ıstica que o conduzem a um n´ıvel de jogo muito superior ao de um agente de GGP no jogo para

(14)

2 o qual é especialista. Por outro lado, o agente de GGP tem a vantagem de ser capaz de jogar qualquer jogo que possa ser modelado através de uma linguagem de modelagem de jogos. Dessa forma, o agente de GGP não tem como principal objetivo alcan¸car o maior n´ıvel de jogo poss´ıvel, mas sim de eliminar a necessidade de se projetar e implementar um agente espec´ıfico para cada jogo que existe. Em um ambiente de GGP, é suficiente descrever o jogo e então se tem um agente-coringa que jogará quantos jogos o fornecerem. Além disto, o campo de General Game Playing, que já é fascinante por si só, motiva a cria¸cão de técnicas melhores e mais consistentes de aprendizado de máquina, deteçcão de padrão, e racioc´ınio.

1.1 Objetivos

Neste trabalho será abordado o problema de General Game Playing seguindo uma modelagem de agente inteligente. Assim, o foco será em desenvolver um agente capaz de jogar qualquer jogo de tabuleiro com espa¸co de estados discreto, sem obter nenhum conhecimento sobre o jogo além das regras que o regem; nem mesmo o nome do jogo é fornecido ao agente.

O objetivo principal deste trabalho é apresentar uma solu¸cão para o problema de GGP e executar experimentos para analisar e compreender o comportamento de um agente de GGP e o quão bem ele pode jogar um jogo sobre o qual não tem nenhuma informa¸cão. Como objetivo secundário, serão realizados, experimentos para calibrar parâmetros do algoritmo adotado como base para a constru¸cão do agente de GGP deste trabalho. Para tanto, será estudado um arcabou¸co de código para o desenvolvimento de agentes de GGP e apresentar os seus módulos essenciais para a implementa¸cão de um agente.

1.2 Solu¸

c˜

ao Proposta

Neste trabalho será apresentado um agente de General Game Playing constru´ıdo com base no algoritmo Monte Carlo Tree Search [Chaslot et al. 2008] adaptado para o contexto de GGP. O agente será capaz de executar uma fase de pré-processamento para construir uma árvore de jogo inicial que será utilizada para extrair informa¸cões já no in´ıcio da partida, o que deverá fortalecer o n´ıvel de jogo do agente de GGP deste trabalho. O algoritmo Monte Carlo Tree Search foi escolhido por ser adequado ao contexto de GGP

(15)

pois trata-se de um algoritmo que toma decisões com base em informa¸cões estat´ısticas, ou seja, não é necessário que se tenha qualquer conhecimento sobre estratégias e heur´ısticas inerentes ao jogo em questão. Na solu¸cão apresentada neste trabalho, serão tratadas estruturas comuns a qualquer jogo de tabuleiro, ou seja, seu espa¸co de estado. Será utilizada uma linguagem espec´ıfica para a modelagem de jogos deste gênero, a Game Description Language [Love et al. 2008]. O algoritmo da solu¸cão proposta então percorre o espa¸co de estados através do modelo em GDL do jogo, obtendo somente as informa¸cões mais elementares acerca de cada estado poss´ıvel do jogo, se é terminal ou não e, caso seja terminal, se é uma vitória ou não. Toda a implementa¸cão da solu¸cão proposta é feita em cima do arcabou¸co de código utilizado neste trabalho, oferecido na cadeira de General Game Playing pela Universidade de Stanford, dispon´ıvel no github 1_{. Toda a}

interpreta¸cão da linguagem GDL é feita através do interpretador que vem embutido como um dos módulos deste arcabou¸co de código, portanto a solu¸cão proposta não engloba construir um interpretador de GDL, mas sim utilizá-lo.

1.3 Organiza¸

c˜

ao do Texto

O restante texto deste trabalho está organizado em quatro cap´ıtulos. No segundo cap´ıtulo é fornecido o embasamento teórico do trabalho, onde serão detalhados cada um dos tópicos relevantes para este trabalho. No terceiro cap´ıtulo é fornecido um detalha-mento sobre a implementa¸cão do trabalho, onde é explicado como o trabalho foi desen-volvido e é apresentada a sua arquitetura. No cap´ıtulo quatro são apresentados os ex-perimentos executados, a compila¸cão dos dados obtidos e a interpreta¸cão dos resultados. No quinto cap´ıtulo estão as conclusões acerca do trabalho desenvolvido e temas poss´ıveis para trabalhos futuros.

(16)

Cap´ıtulo 2

Fundamenta¸

c˜

ao Te´

orica

Neste cap´ıtulo são apresentados os conceitos necessários para compreender como funciona um agente de General Game Playing. É mostrada a estrutura que pode ser uti-lizada para abstrair qualquer jogo de tabuleiro com espa¸co de estados finito, e também de que maneira esta estrutura é capaz de fazê-lo. É abordada a Game Description Language (GDL), que é uma linguagem com o propósito de modelar as regras de jogos que possuam espa¸co de estados finito. São apresentados os algoritmos Monte Carlo Search e Monte Carlo Tree Search, e como podem ser aplicados a um contexto de general game playing.

2.1 General Game Playing

General Game Playing é um tópico da área de Inteligência Artificial que trata do problema de desenvolver agentes capazes de jogar qualquer jogo. Porém, esse ainda é um problema em aberto, de forma que não há um agente realmente capaz de jogar qualquer jogo, mas sim agentes que consigam jogar uma classe de jogos que tenham uma estrutura em comum, por exemplo, um agente de GGP capaz de jogar jogos de tabuleiro.

Um agente de GGP pleno deve ser capaz de aprender de maneira autônoma como jogar, ou seja, compreender a mecânica do jogo e as regras, e também deve ser capaz de desenvolver suas estratégias para alcan¸car a vitória sem a interven¸cão de qualquer agente externo, humano ou não humano. Um agente de GGP pode compreender a mecânica do jogo e suas regras através da observa¸cão do mesmo sendo jogado por outros agentes, porém ainda é mais usual desenvolver agentes de GGP parciais que não são capazes de aprender como jogar, portanto necessitam da descri¸cão das regras e da mecânica do jogo

(17)

em alguma linguagem. A linguagem comumente utilizada para modelar os jogos chama-se Game Description Language (GDL), portanto a maioria dos agentes de GGP devem ser capazes de interpretar a GDL.

Agentes de GGP se deparam com jogos arbitrários nunca jogados por eles ante-riormente, jogos single-player, jogos multi-player, jogos simples (como o Cubo Mágico), jogos complexos (por exemplo o xadrez), jogos determin´ısticos ou estocásticos, jogos com informa¸cões parciais ou completas, etc. Por este motivo, um agente de GGP não pode de-pender de algoritmos espec´ıficos para cada jogo que exista. Detectar qual é o jogo que foi passado ao agente descrito em GDL não é uma tarefa trivial. Além disso, seria um esfor¸co muito grande para o programador desenvolver algoritmos para todos os jogos conhecidos e incorporá-los no agente de GGP. Há também o problema de que novos jogos podem surgir. Geralmente em competi¸cões de GGP são fornecido aos agentes uma varia¸cão nunca vista de algum jogo conhecido, e não seria poss´ıvel para o desenvolvedor alterar o seu agente no momento da competi¸cão, e este agente não seria essencialmente um agente de GGP por não ser capaz de jogar aquele jogo com o qual acabou de se deparar. Portanto, um agente de GGP deve possuir algoritmos baseados em sua própria capacidade de desenvolver es-tratégias de jogo, ao invés de algoritmos que incorporem a inteligência do programador através de conhecimento prévio sobre o jogo. Capacidades desejáveis de agentes de GGP são representa¸cão de conhecimento, racioc´ınio e tomada de decisões racionais.

Apesar de um agente de GGP ser capaz de jogar uma quantidade não determinada de jogos, estes jogos devem compartilhar uma estrutura abstrata para que seja poss´ıvel um agente de GGP jogar qualquer jogo que seja uma instância desta estrutura. Os jogos que um agente de GGP é capaz de jogar devem assumir uma quantidade finita de estados. Dentre todos os estados que o jogo pode assumir, alguns são distintos, deve haver exatamente um estado chamado inicial, que é a configura¸cão em que o jogo se encontra antes que qualquer a¸cão seja feita no jogo por qualquer agente que o esteja jogando, e há um ou mais estados designados estados finais, que são estados para os quais não há mais nenhuma a¸cão a ser tomada e denotam o fim da partida. Cada jogo tem uma quantidade fixa de jogadores que não pode mudar durante a partida. Cada jogador tem uma quantidade finita de a¸cões poss´ıveis para um dado estado, e a cada estado é associado um valor-objetivo para cada um dos jogadores.

(18)

6 turno da partida, e o estado do jogo é atualizado em detrimento de todas as a¸cões tomadas no turno em andamento. Há uma a¸cão especial, designada noop, para o caso em que algum agente decida não tomar qualquer outra a¸cão dispon´ıvel ou não possua a¸cões dispon´ıveis. Dada esta estrutura abstrata compartilhada entre os jogos poss´ıveis de serem jo-gados por um agente de GGP, podemos modelar qualquer jogo como um grafo em que os vértices são os estados do jogo e as arestas são as a¸cões que podem ser tomadas, cada vértice tem um valor associado que é o valor-objetivo. Como dito anteriormente, existem vértices especiais, que são o vértice que representa o estado inicial e os vértices que re-presentam os estados finais. Este grafo pode ser visto portanto como uma máquina de estados.

Na Figura 2.1 temos o exemplo de um grafo para um jogo de um ´unico jogador. Neste exemplo temos um jogo com oito estados poss´ıveis, sendo o estado s1 inicial e os

estados s4 e s8 finais. Cada estado do jogo tem um valor associado que ´e o valor-objeto do

estado. A fun¸cão de transi¸cão do jogo é exprimida pelas arestas do grafo. Por exemplo, se o jogo estiver no estado s2 e o agente de GGP tomar a a¸cão b, o jogo transita do estado

s2 para o estado s3. Se o agente tivesse escolhido a a¸c˜ao a, o jogo teria mudado para o

estado s6.

Figura 2.1: Grafo de um jogo single-player

Na Figura 2.2 temos o exemplo de um grafo para um jogo de vários jogadores. Neste caso, há uma aresta para cada combina¸cão de movimentos dos jogadores, simulta-neamente. Em cada vértice do grafo há agora os valores-objetivo para cada jogador. Se

(19)

o jogo estiver no estado s6 e ambos os jogadores tomarem a a¸c˜ao a, o jogo transita de

estado pela aresta marcada com a combina¸cão de a¸cões tomadas pelos jogadores, ou seja, a/a, e o jogo muda o estado para s7. Se os jogadores tivessem tomado as a¸cões a e b, o

jogo teria transitado para o estado s2.

Figura 2.2: Grafo de um jogo multi-player

Embora abstrair os jogos tratados em GGP como uma estrutura em grafo seja conveniente pela simplicidade e facilidade de modelagem, na prática não é conveniente representar os jogos dessa forma por causa da grande quantidade de estados distintos que podem possuir. O xadrez, por exemplo, possui uma quantidade de estados distintos em torno de 1030_{. Construir um grafo para o caso do xadrez seria impratic´}_{avel, tanto}

pelo tempo de constru¸cão do grafo quanto pela quantidade de memória que a simples representa¸cão do jogo em um grafo consumiria.

Na grande maioria dos jogos os estados podem ser fragmentados em entidades fundamentais. No xadrez, por exemplo, os estados podem ser fragmentados em pe¸cas, casas, linhas, colunas diagonais etc. Esta propriedade nos permite definir as a¸cões legais do jogo em termos dessas entidades mais fundamentais, ou seja, ao invés de precisar definir para cada poss´ıvel estado as poss´ıveis transi¸cões, poder´ıamos definir em fun¸cão dessas entidades fundamentais regras que determinam quais são as a¸cões legais, e essas defini¸cões aplicar-se-iam a quaisquer estados válidos do jogo. Essa forma compacta de representar jogos é exatamente a forma usada em GDL, de maneira que os estados são gerados conforme a necessidade. [Genesereth e Thielscher 2014]

(20)

8

2.2 Game Description Language (GDL)

A GDL é uma linguagem baseada em lógica, que permite modelar as regras de qualquer jogo que tenha espa¸co de estados discreto e finito. Esta linguagem permite que sejam feitas consultas sobre o jogo, como por exemplo o estado inicial, o estado atual, quem é o jogador da vez, se alguém venceu etc. Através de proposi¸cões lógicas, a GDL permite que o estado do jogo seja transitado para um próximo estado poss´ıvel. A finalidade desta linguagem é oferecer uma maneira de modelar jogos de modo a permitir a constru¸cão de agentes de General Game Playing.

GDL é uma linguagem declarativa, como Datalog e Prolog, porém há algumas diferen¸cas, a semântica da GDL é puramente declarativa, garante decidibilidade para qualquer pergunta de implica¸cão lógica para qualquer descri¸cão na linguagem e possui palavras reservadas espec´ıficas para defini¸cão de jogos.

A GDL possui dois componentes essenciais, entidades e relacionamentos. As enti-dades representam os objetos que se presume que existam no jogo. O conjunto de todas as entidades que podem ser utilizadas no jogo é chamado de dom´ınio do jogo. O nome das entidades são strings com qualquer combina¸cão de caracteres alfanuméricos e alguns poucos caracteres não alfanuméricos (e.g. ’ ’). O nome de uma entidade não pode come-¸car com uma letra maiúscula. Para exemplificar, considere o jogo da velha. Neste jogo as entidades seriam os papeis no jogo, ou seja, cada um dos jogadores, por exemplo player1 e player2, os ´ındices das linhas e colunas 1, 2 e 3, e os valores que podem aparecer em cada célula do tabuleiro, x, o e b (b significa branco no caso deste exemplo).

Os relacionamentos representam propriedades dos objetos ou rela¸cões entre eles. O conjunto de todos os relacionamentos definidos no jogo é chamado de assinatura do jogo. A aridade de um relacionamento é o número de objetos envolvidos no relacionamento, a aridade de um relacionamento é uma propriedade inerente a ele e nunca muda. Considere o exemplo do jogo da velha dado para exemplificar as entidades, poder´ıamos inserir na assinatura do jogo o relacionamento célula de aridade três, e este relacionamento junto com as entidades de jogadores da vez, linhas, colunas e valores poss´ıveis nas células, obtemos a proposi¸cão de que uma célula numa dada linha e coluna possui o valor especificado. Por exemplo, célula(1, 2, x) define que a célula na linha 1 e coluna 2 possui o valor x. Podemos adicionar na assinatura também o relacionamento controle que indica de qual jogador é a vez. Por exemplo, controle(player1) determina que é a vez do jogador player1.

(21)

Um game schema possui um conjunto de entidades, um conjunto de relacionamen-tos e uma associa¸c˜ao de aridades para cada um dos relacionamentos contidos na assinatura do jogo [Genesereth e Thielscher 2014].

Uma proposi¸cão é uma estrutura que consiste em um relacionamento da assinatura do jogo com aridade n, representando n entidades no dom´ınio do jogo. As proposi¸cões são escritas em GDL utilizando a nota¸cão matemática tradicional. Por exemplo, se R é um relacionamento contido na assinatura do jogo e a e b são entidades do dom´ınio do jogo, então R(a, b) é uma proposi¸cão. Em GDL as proposi¸cões são particionadas em 3 classes disjuntas, as proposi¸cões base que compõem os estados do jogo, as a¸cões que determinam os movimentos legais para cada estado do jogo, ou seja, as transi¸cões de estado, e as proposi¸cões sensoriais (percep¸cões) que são parte da versão GDL-II. Este tipo de proposi¸cão é útil para adicionar a no¸cão de jogo incompleto, ou seja, jogos em que os agentes de GGP não conhecem completamente os estados do jogo. Há o caso especial de um relacionamento de aridade zero, noop, que determina que nenhuma a¸cão será tomada. Para completar o exemplo do jogo da velha, poder´ıamos adicionar a¸cões marcar de aridade 2, que indicariam a a¸cão de marcar a célula na linha e coluna especificadas na a¸cão marcar [Love et al. 2008].

A base proposicional de um jogo é o conjunto que contém todas as proposi¸cões que podem ser formadas utilizando relacionamentos e entidades contidos no game schema. Para exemplificar, considere que temos um jogo cujo assinatura possui os relacionamentos J e K, sendo que J tem aridade 1 e K aridade 3, e o dom´ınio possui as entidades a e b. A base proposicional deste jogo é o conjunto J(a), J(b), K(a, a, a), K(a, a, b), K(a, b, a), K(a, b, b), K(b, a, a), K(b, a, b), K(b, b, a), K(b, b, b). Cada proposi¸cão da base proposicional deve assumir o valor verdadeiro ou falso. [Genesereth e Thielscher 2014]

Um estado num jogo é determinado por um subconjunto da base proposicional, ou seja, um jogo estar num determinado estado significa que de todas as proposi¸cões da base proposicional, algumas são verdadeiras e as demais são falsas. O jogo transita de um estado atual para o próximo estado através das a¸cões de todos os jogadores participantes da partida, ou seja, depois que todos os jogadores já fizeram a escolha de um movimento legal dentro do conjunto de a¸cões dispon´ıveis. Mesmo que não seja a vez de um deter-minado jogador, ele precisa escolher algum movimento, que nesse caso o único dispon´ıvel seria noop. Quando as a¸cões são tomadas e um movimento é efetuado, as proposi¸cões base

(22)

10 mudam o valor, algumas se tornam verdadeiras e outras falsas, esta mudan¸ca de valores das proposi¸cões base é o que caracteriza a transi¸cão de um estado para outro e, conse-quentemente, há um novo conjunto de poss´ıveis a¸cões. Para qualquer estado poss´ıvel, um movimento tomado leva a outro estado único, não pode haver ambiguidade na transi¸cão de estados.

A GDL tem algumas limita¸cões adicionais que restringem o escopo da linguagem a fim de evitar que se possa modelar jogos com defini¸cões problemáticas. Estas limita¸cões estão listadas a seguir:

• Termination: Um jogo descrito em GDL termina se para qualquer a¸cão legal par-tindo do estado inicial do jogo algum estado final é alcan¸cável.

• Jogabilidade: Um jogo descrito em GDL é jogável se, e somente se, todos os jogadores têm pelo menos um movimento legal em qualquer estado não-terminal que seja alcan¸cável a partir do estado inicial do jogo.

• Winnability: Um jogo descrito em GDL é strongly winnable se, e somente se, para algum jogador existe uma sequência de a¸cões individuais que conduzem o jogo a um estado terminal em que o valor-objetivo é maximal para esse dado jogador. Um jogo descrito em GDL é weakly winnable se, e somente se, para todos os jogadores há uma sequência de a¸cões conjuntas dos jogadores que conduzem a um estado terminal em que o valor-objetivo é maximal para o dado jogador.

• Bem-formado: Um jogo descrito em GDL é bem-formado se termina, é jogável e é weakly winnable.

Em GDL existem objetos constantes que são os números de 0 a 100, úteis para definir o valor-objetivo dos estados. Existem também relacionamentos fixos da linguagem que são os mesmos para quaisquer jogos e têm uma semântica especificada pela linguagem. Esses relacionamentos e os objetos constantes são o vocabulário independente de jogo. A seguir há uma lista dos dez relacionamentos fixos da linguagem e suas semânticas:

• role(a) Este relacionamento determina os jogadores, sendo a o jogador.

• base(p) Este relacionamento determina as proposi¸cões base do jogo, sendo p uma proposi¸cão que será considerada base.

(23)

• input(r, a) Este relacionamento binário determina que a é uma a¸cão válida para o jogador r.

• init(p) Este relacionamento determina que a proposi¸c˜ao p ´e verdadeira para o estado inicial do jogo.

• true(p) Este relacionamento determina que a proposi¸c˜ao p ´e verdadeira no estado atual.

• does(r, a) Este relacionamento indica que o jogador r executa a a¸c˜ao a no estado atual.

• next(p) Este relacionamento indica que a proposi¸cão p é verdadeira no próximo estado.

• legal(r, a) Este relacionamento indica que a a¸c˜ao a ´e legal no estado atual para o jogador r.

• goal(r, n) Este relacionamento determina o valor-objeto n do estado atual para o jogador r.

• terminal Este relacionamento determina que o estado atual é terminal [Love et al. 2008]. Um jogo descrito em GDL deve satisfazer as seguintes condi¸cões: (1) Um jogo em GDL deve fornecer defini¸cões completas dos relacionamentos independentes de jogo role, base, input e init. (2) Deve definir relacionamentos goal, legal e terminal em termos de relacionamentos true. (3) Deve definir relacionamentos next em termos de relacionamentos true e does [Genesereth e Thielscher 2014].

2.3 Monte Carlo Search

Para um agente de GGP tomar decisões é necessário que ele fa¸ca considera¸cões com base no estado atual do jogo, e então projetar futuros cenários através da simula¸cão de poss´ıveis sequências de movimentos seus e de seus adversários ou aliados no jogo.

Uma possibilidade seria percorrer toda a árvore de estados do jogo e fazer considera-¸cões sobre os seus estados terminais e construir as decisões do agente com o conhecimento de quais a¸cões levam à derrota, vitória ou empate. Porém, essa abordagem apresenta

(24)

12 uma forte limita¸cão computacional, pois a maioria dos jogos apresenta uma quantidade exacerbada de estados distintos, e seria inviável visitar cada poss´ıvel estado a partir do estado atual em decorrência do tempo necessário para fazer esta computa¸cão.

Há uma alternativa para a busca na árvore de estados completa do jogo, que consiste em visitar parcialmente a árvore e em determinado ponto da busca parar de aprofundar na árvore e fazer alguma considera¸cão heur´ıstica em cima do estado que se alcan¸cou até aquele ponto da busca. Estas considera¸cões heur´ısticas - também chamadas de utilidade do estado - quando bem elaboradas podem estimar com precisão satisfatória o quão interessante ou indesejável é o estado que está sendo considerado. Com isso o agente de GGP pode tomar decisões coerentes e apresentar um n´ıvel de jogo consistente e desafiador. O problema desta abordagem para o caso do GGP reside na necessidade de se elaborar heur´ısticas que dependem de conhecimento espec´ıfico sobre o jogo e portanto não são interessantes para um player genérico. Há então a necessidade de se encontrar uma abordagem que não dependa do jogo, mas que apresente tomadas de decisões que sejam consistentes e relevantes, independente do jogo que esteja sendo jogado.

A busca probabil´ıstica é uma abordagem interessante para o caso de general game playing, pois não necessita estimar nenhuma utilidade para estados que não sejam ter-minais, ou seja, a busca probabil´ıstica considera para seu cálculo de utilidade somente estados terminais, e baseia-se somente em vitória, derrota ou empate. Desta maneira pode-se abstrair quaisquer caracter´ısticas espec´ıficas de cada jogo, e a busca torna-se ge-nérica o suficiente para ser implementada num agente de GGP. Para este trabalho será utilizada uma abordagem baseada em Monte Carlo.

A Monte Carlo Search (MCS) é uma busca probabil´ıstica baseada na abordagem Monte Carlo de simula¸cão do jogo. A busca consiste em, a partir de um dado estado, tomar a¸cões aleatórias até alcan¸car um estado terminal do jogo, e então repete-se esse processo uma determinada quantidade de vezes e verifica-se a quantidade de vezes em que o processo chegou a um estado terminal em que o agente que está desempenhando a simula¸cão Monte Carlo obtém êxito e vence o jogo, e adota-se como valor do estado atual a propor¸cão entre os sucessos e a quantidade de vezes que o processo foi executado.

A MCS incorpora uma das etapas da busca heur´ıstica, e então substitui a etapa da aplica¸cão da heur´ıstica de avalia¸cão de um estado pela etapa da avalia¸cão do estado através da sucessiva aplica¸cão de movimentos aleatórios até o estado terminal. Portanto

(25)

a MCS ´e um m´etodo que consiste de duas etapas:

• Expansão: Nesta etapa utiliza-se o mesmo método utilizado na busca heur´ıstica, ou seja, a busca come¸ca num dado estado s0, e para cada estado válido subsequente

a partir do estado s0 a busca o expande, mantendo-o em mem´oria e armazenando

os resultados da explora¸cão de cada estado expandido a partir dele. A busca então constrói a árvore de estados do jogo nesta etapa, até uma dada profundidade. Na Figura 2.3 está ilustrada a etapa de expansão, em que a árvore é constru´ıda até uma determinada profundidade.

Figura 2.3: ´Arvore expandida na MCS

• Explora¸cão: Nesta etapa não há mais expansão da árvore de estados do jogo. A partir da árvore constru´ıda na etapa de expansão, para cada folha da árvore será executada a explora¸cão. Determina-se a quantidade de vezes que a etapa de explora¸cão será executada para cada uma das folhas da árvore. O processo consiste em escolher a¸cões aleatórias partindo de um estado-folha até encontrar um estado terminal do jogo, e então se verifica se este estado é uma vitória para o agente que está executando a MCS, se é uma derrota ou empate. Na sequência de movimentos aleatórios até um estado terminal, para cada passo escolhe-se somente uma a¸cão para cada player. O resultado é então retornado e armazenado, até que todas as itera¸cões para um dado estado-folha da árvore sejam executadas. A Figura 2.4 ilustra como esta etapa acontece, na imagem é ocultado o caminho aleatório que cada itera¸cão faz, e é exibido somente cada estado terminal alcan¸cado e seu valor-objetivo, que é dado por zero em caso de derrota ou 100 em caso de vitória.

(26)

14

Figura 2.4: Etapa de explora¸c˜ao da MCS

Após conclu´ıda a explora¸cão para os estados-folha da árvore é calculado o valor-objetivo de cada um deles. Este cálculo é simples, basta somar os resultados de cada itera¸cão da explora¸cão e dividir pela quantidade de itera¸cões executadas. A Figura 2.5 ilustra o cálculo do valor-objetivo de cada um destes estados-folha.

A etapa de explora¸cão pode ser interpretada como uma maneira de se determinar um valor heur´ıstico, com o diferencial de não demandar conhecimento algum acerca do jogo em questão, portanto a exclusividade da MCS é a forma de determinar a utilidade de um estado, que consiste num método probabil´ıstico, mantendo a mecânica da etapa de expansão, ou seja, a gera¸cão da árvore parcial (a árvore de estados do jogo que contém somente uma parte dos estados e para em determinada profundidade). Porém na MCS esta ´

arvore tem menos estados que numa abordagem de busca heur´ıstica com conhecimento espec´ıfico sobre o jogo, pois na MCS haverá ainda a etapa de explora¸cão, que embora seja considerada leve, ainda demanda algum tempo adicional de computa¸cão.

O MCS é um método otimista, ou seja, considera que o seu oponente tem um n´ıvel baixo de jogo, pois assume que o oponente toma decisões aleatoriamente, e isto é intr´ınseco ao método, quando na realidade o seu oponente pode ser um jogador experiente que consegue enxergar excelentes estratégias a partir de um dado estado. Por exemplo,

(27)

Figura 2.5: C´alculo do valor-objetivo dos estados-folha

para um determinado estado a partir do qual será feita uma explora¸cão, todas as itera¸cões podem conduzir a um estado terminal favorável ao agente de GGP, e pode haver um ´

unico estado terminal que é um caso em que o agente em questão perde, o oponente pode enxergar isso e se aproveitar dessa fragilidade do método. Porém, mesmo com essas desvantagens, o método Monte Carlo é poderoso e bastante satisfatório para o caso de general game playing [Chaslot et al. 2008] [Browne et al. 2012].

O Algoritmo 1 apresenta uma implementa¸cão da MCS que utiliza 4 itera¸cões para a explora¸cão de estados-folha.

(28)

16 function maxscore (role,state,level) if findterminalp(state,game) then

return findreward(role,state,game); end

if level>levels then

return montecarlo(role,state,4); end

var actions = findlegals(role,state,game); var score = 0;

for var i=0; i<actions.length; i++ do

var result = minscore(role,actions[i],state,level); if result==100 then return 100; end if result>score then score = result; end end return score;

function montecarlo (role,state,count) var total = 0; for var i=0; i<count; i++ do

total = total + depthcharge(role,state); end

return total/count;

function depthcharge (role,state) if findterminalp(state,game) then return findreward(role,state,game);

end

var move = seq(); for var i=0; i<roles.length; i++ do var options = findlegals(roles[i],state,game);

move[i] = randomelement(options); end

var newstate = simulate(move,state); return depthcharge(role,newstate);

(29)

2.4 Monte Carlo Tree Search

A Monte Carlo Tree Search é uma árvore utilizada para facilitar a MCS. Em ambos os métodos a árvore de estados do jogo é gerada de maneira incremental, a diferen¸ca entre os dois métodos reside na forma como esta árvore é gerada.

Enquanto na busca Monte Carlo Search cada etapa é executada uma única vez, a Monte Carlo Tree Search é executada em ciclos, com cada ciclo possuindo quatro etapas, a cada ciclo uma etapa de cada vez. A árvore parcial de estados no caso da MCTS é chamada de Árvore de Estat´ısticas, ela armazena - para cada nó - a quantidade de visitas que o nó recebeu e as informa¸cões estat´ısticas que o nó possui sobre poss´ıveis resultados do jogo decorrentes da sua escolha.

Neste trabalho será utilizado o algoritmo MCTS com fun¸cão de avalia¸cão Upper Confidence Bound for Trees (UCT), em que é utilizado o limite estat´ıstico Upper Confi-dence Bound na etapa de sele¸cão. Abaixo estão listadas e abordadas as quatro etapas da MCTS [Love et al. 2008].

• Sele¸cão: Nesta etapa da busca a árvore de estados do jogo é percorrida com base em informa¸cões estat´ısticas previamente coletadas e armazenadas em cada nó. A busca come¸ca na raiz e vai aprofundando n´ıvel a n´ıvel, em cada n´ıvel escolhendo um dos filhos. Cada escolha pode ser interpretada como um Multi-Armed Bandit Problem [Katehakis e Jr 1987]. O algoritmo utilizado para a escolha do filho pelo qual a busca seguirá é o Upper Confidence Bound. Esta escolha é feita de maneira a favorecer nós pouco visitados adicionando à utilidade estimada do nó um valor que é maior conforme a quantidade de vezes que o nó foi visitado é menor. Esta etapa é conclu´ıda quando a busca alcan¸ca um nó cujo nem todos os filhos possuem informa¸cões estat´ısticas, então a MCTS passa para a sua segunda etapa.

• Expansão: Nesta etapa a busca encontra-se em um nó cujo nem todos os filhos possuem informa¸cões estat´ısticas associadas, portanto é escolhido aleatoriamente um desses filhos e ele é adicionado à Árvore de Estat´ısticas.

• Simula¸cão: Nesta etapa é executada a mesma simula¸cão da MCS, porém é tomado como raiz o nó que foi adicionado na etapa de expansão imediatamente anterior à simula¸cão.

(30)

18 • Back-propagation: Esta é a última etapa de cada ciclo, em que o resultado da etapa anterior é considerado para que se fa¸ca a atualiza¸cão da Árvore de Estat´ısticas.

´

E percorrido o caminho de volta até a raiz, neste processo é incrementado o contador de visita de cada nó neste caminho, inclusive a raiz. Nesta etapa atualiza-se também o valor de utilidade de cada nó somando o resultado da simula¸cão ao valor de

utili-dade que já se encontra armazenado no nó [Bradberry 2015 (accessed September 19, 2016)]. Ao término de cada execu¸cão da MCTS a árvore gerada pode ser preservada para

a próxima execu¸cão do algoritmo, desta forma a cada vez que a MCTS for executada a estimativa de utilidade de cada nó se tornará mais confiável. Essa estratégia é especial-mente importante para contextos em que o tempo de execu¸cão é bastante limitado, como por exemplo uma competi¸cão de GGP.

A varia¸cão da MCTS, chamada UCT, tem a vantagem de oferecer um bom balan-ceamento entre a expansão e a explora¸cão da Árvore de Estat´ısticas do jogo, evitando que em muitos ciclos repetidos se execute somente expansão de nós não visitados ou explora¸cão de nós já visitados.

A MCTS torna-se mais consistente conforme tem mais tempo para executar a busca. Quando o tempo dispon´ıvel para sua execu¸cão aproxima-se do infinito, as decisões tomadas pela MCTS tendem a ser perfeitas. Conforme o tempo dispon´ıvel para a execu¸cão do algoritmo aumenta, a Árvore de Estat´ısticas torna-se cada vez maior, portanto há a possibilidade de que não haja memória o suficiente para comportar novos nós gerados na ´

arvore, neste caso uma maneira de contornar este problema seria trocar para a execu¸cão de uma varia¸cão da MCTS que não gera novos nós e trabalha somente na explora¸cão de nós já visitados para melhorar a confiabilidade de suas estimativas de utilidade.

(31)

Cap´ıtulo 3

Um player de General Game Playing

Para a implementa¸cão deste trabalho foi utilizada arcabou¸co de implementa¸cão do curso de General Game Playing da Universidade de Stanford, que está dispon´ıvel no github1_{. Este arcabou¸co oferece alguns componentes ´}_{uteis para o desenvolvimento, teste}

e experimenta¸cão de um agente de GGP. Esta base de código do interpretador de GGP e aparatos úteis são escritos na linguagem Java, a mesma que foi utilizada para o desenvol-vimento do agente de GGP deste trabalho. A IDE escolhida para o desenvoldesenvol-vimento do agente de GGP neste trabalho foi o Eclipse, por ter tutorial sobre a configura¸cão da base de código com o Eclipse e também por ser gratuita.

A implementa¸cão do agente jogador de GGP deste trabalho, constru´ıda em cima do arcabou¸co de GGP, é muito dependente dos módulos deste arcabou¸co, pois o agente jogador deste trabalho é uma extensão das interfaces do arcabou¸co e funciona acoplado ao mesmo, para que possa ser integrado adequadamente aos módulos fornecidos no ar-cabou¸co. Portanto, este cap´ıtulo terá uma profundidade técnica grande, pois é essencial compreender detalhes do arcabou¸co utilizado para que se compreenda plenamente a im-plementa¸cão do agente deste trabalho.

Neste trabalho foram utilizados cinco componentes dentre os componentes dispo-n´ıveis na base de GGP. Na Figura 3.1 são apresentados de forma genérica os componentes da base de GGP. São eles: (1) o player, que se conecta ao (2) servidor para participar de uma partida e roda um dos agentes de GGP dispon´ıveis, (3) o Kiosk que permite partidas de um humano contra o agente de GGP, (4) o interpretador de GDL, que é o cerne do GGP, (5) e uma interface de classes para facilitar a utiliza¸cão do interpretador de GDL,

1_{https://github.com/hardiecate/ggp-base}

(32)

20

Figura 3.1: M´odulos do arcabou¸co de GGP

para que não seja necessário dispender tempo e esfor¸co trabalhando diretamente com a complexidade da linguagem crua. O módulo da GDL é utilizado para encapsular o jogo, ou seja, através deste módulo o agente poderá compreender as regras do jogo. A interface encapsula a implementa¸cão do agente, e através dela o agente consegue interagir com os outros módulos da base de código. Na Figura 3.2 é apresentada uma visão geral sobre a arquitetura do agente de GPP através de um diagrama simplificado. A seguir são listados os módulos da base de GGP com uma breve descri¸cão de cada um:

• Kiosk : Este componente é útil para testes rápidos e manuais, pois permite uma partida entre um humano e o agente de GGP que está sendo desenvolvido. Com esta ferramenta, é poss´ıvel rodar o agente de GGP na sua fase de desenvolvimento

(33)

para verificar se o agente faz escolhas coerentes, para aferir o n´ıvel e consistência de jogo do agente e também para verificar se o agente de GGP escolhe movimentos válidos. Também é útil para procurar erros na implementa¸cão. Esta ferramenta permite a configura¸cão do agente de GGP, ou seja, pode-se definir o tempo que o agente terá para se preparar para a partida e também o tempo que o agente terá para tomar a decisão de qual movimento efetuará. O jogador humano sempre pode tomar o tempo que desejar para movimentar, o Kiosk não oferece a configura¸cão de limitar o tempo do jogador humano. Por exemplo, uma partida pode ser configurada para o jogo de xadrez, fornecendo ao agente jogador 20 segundos de prepara¸cão para a partida e 10 segundos para a escolha do movimento, porém o jogador humano terá tempo indeterminado para estas tarefas.

• Server : Este componente hospeda uma partida entre players. A sua fun¸cão é receber dos players participantes de uma partida os movimentos que escolheram, verificar se o movimento é permitido, atualizar o estado do jogo no hospedeiro, informar aos participantes qual é o novo estado do jogo e solicitar ao próximo participante da vez que fa¸ca seu movimento. O hospedeiro então é responsável por gerenciar as parti-das, verificar se os movimentos são válidos, decidir quem é o próximo participante a fazer um movimento e informar quem é o vencedor e quem são os perdedores. Existem jogos em que os participantes fazem movimentos simultaneamente, ou seja, vários jogadores escolhem um movimento num mesmo turno, e o servidor é capaz de gerenciar estes casos também, embora o escopo deste trabalho não aborde esse tipo de jogo.

• Player : O player é o cliente. A sua fun¸cão é rodar remotamente um dos agentes de GGP desenvolvidos na base de GGP, conectar com o servidor, iniciar a partida, fazer a comunica¸cão com o servidor e repassar as solicita¸cões do servidor ao agente de GPP. Portanto o player é uma interface entre o agente de GGP desenvolvido e o hospedeiro da partida, atuando como um facilitador desta comunica¸cão, descartando a necessidade de se investir tempo estudando os protocolos de rede utilizados e estabelecendo uma conexão estável e segura.

• Interpretador de GDL: Este componente é o cerne deste trabalho. Toda a base para a interpreta¸cão da GDL é oferecida neste módulo da base de GGP. O player

(34)

22 recebe do servidor a descri¸cão do jogo em GDL e então utiliza o interpretador para instanciar a configura¸cão inicial do jogo, que é composta pelas proposi¸cões base, e depois para rodar as transi¸cões de estado do jogo conforme o agente desempenha suas decisões. Este módulo fornece também todo o suporte ao agente de GGP para que ele possa simular movimentos e construir sua árvore de estat´ıstica, através de proposi¸cões de transi¸cão de estados e dos relacionamentos para verificar informa¸cões como o jogador da vez, se um estado é terminal ou não etc.

• Interface com o Interpretador : Este componente é um facilitador para a implemen-ta¸cão do agente de GPP. Para o agente de GGP conseguir simular ramos da árvore de estados do jogo, precisaria rodar proposi¸cões utilizando o interpretador e tam-bém fazer consultas de relacionamentos, o que adicionaria bastante dificuldade a sua implementa¸cão por ter que lidar diretamente com a GDL crua. Por exemplo, considerando o caso do jogo da velha, para verificar o estado atual o agente teria que verificar para cada célula se ela está vazia, preenchida com cruz ou preenchida com bola, para isto deveria para cada célula verificar qual das três proposi¸cões pos-s´ıveis tem o valor true, ou seja, cell(linha, coluna, vazio), cell(linha, coluna, cruz) e cell(linha, coluna, bola). Este componente oferece uma interface entre o interpre-tador e o agente de GGP, com classes e interfaces prontas que possuem métodos que já executam os comandos de GDL necessários para se obter uma informa¸cão que necessita, ou para fazer determinados tipos de transi¸cão de estados, pulando a complexidade da linguagem GDL e fornecendo a informa¸cão solicitada já processada e simplificada. Este módulo também oferece uma máquina de estados pronta que deverá ser utilizada para que o agente de GGP percorra o espa¸co de estados do jogo, removendo a necessidade de se dedicar esfor¸co e tempo para a implementa¸cão desta estrutura essencial para o desenvolvimento do agente.

Para a etapa de testes de n´ıvel de jogo do agente de GGP e calibra¸cão de constantes foram utilizados dois componentes em conjunto, o player e o servidor, além do interpre-tador de GDL que é sempre utilizado por qualquer outro componente por ser essencial para que haja GGP. Como o servidor permite programar uma fila de partidas para serem executadas uma após a outra, bastou-se deixar os players conectados ao servidor e deixar as partidas acontecerem e seus históricos serem armazenados.

(35)

Figura 3.3: Diagrama de classe da interface com o interpretador de GDL

A Figura 3.4 exibe um modelo de alto n´ıvel da intera¸cão do agente de GGP de-senvolvido neste trabalho com o arcabou¸co de GGP utilizado. O arcabou¸co encapsula a GDL, ou seja, o agente não faz requisi¸cões diretamente em linguagem lógica, mas sim através de métodos dispon´ıveis no arcabou¸co que compilam as requisi¸cões necessárias em GDL para a consulta que representam. O arcabou¸co é capaz de solicitar ao agente de GGP que fa¸ca um movimento, e o informa o tempo limite para tomar uma decisão. O agente de GGP consulta no arcabou¸co as informa¸cões que preicsa para tomar sua decisão, como por exemplo o estado atual do jogo, quais movimentos são válidos, se um dado estado é terminal etc. Assim que o agente está pronto para escolher o movimento, ele pode comunicar à base de GGP o movimento escolhido.

Antes de entrar em detalhes sobre a implementa¸cão do agente de GGP e sobre classes e métodos importantes da base de código, é importante apresentar uma classe que funciona como esqueleto para o agente de GGP, a classe StateM achineGamer. A ideia desta classe é representar um agente de GGP e padronizar a sua interface para que outros módulos da base de código possam se comunicar adequadamente com o mesmo. Existe um método que permite que seja solicitado ao agente jogador de GGP que um movimento seja feito, dado um tempo limite para a escolha do movimento. Existe um método para solicitar que o agente se prepare para come¸car a partida, dado um tempo

(36)

24

Figura 3.4: Comunica¸c˜ao do agente com a base de GGP

limite de prepara¸cão. É poss´ıvel atualizar o estado da máquina de estados alocada para um agente jogador de GGP. Quando um player esta interagindo com o servidor da partida, ou seja, atuando como um intermediador da comunica¸cão do agente jogador de GGP com o servidor, então o player precisa acessar a máquina de estados do agente jogador para atualizá-la quando receber do servidor a notifica¸cão de que o estado do jogo mudou, ou seja, outro agente jogador participante da partida fez algum movimento.

Na Figura 3.3 estão apresentados o diagrama da classe StateM achineGamer e os relacionamentos entre as classes da interface sobre o interpretador de GDL. A seguir há uma lista dos métodos mais importantes da classe com a explica¸cão de sua fun¸cão e utilidade na implementa¸cão do agente de GGP. Os métodos que têm utilidade interna `

a classe, e não são utilizados pelo agente de GGP direta ou indiretamente, não serão abordados.

• public abstract StateMachine getInitialStateMachine(): Este método retorna a m´ a-quina de estados que será utilizada pelo agente de GGP, já configurada com o estado inicial, ou seja, o conjunto de proposi¸cões-base. A base de código permite que se crie uma máquina de estados personalizada, é poss´ıvel fazer otimiza¸cões no desempenho da máquina de estados ou adapta¸cões para se adequar melhor às necessidades do agente de GPP. No caso deste trabalho, como o objetivo não é criar o agente mais otimizado poss´ıvel, foi utilizada uma máquina de estados padrão que é disponibili-zada na própria base de código. Esta máquina de estados padrão fornece todas as funcionalidades essenciais para a implementa¸cão do agente de GGP deste trabalho.

(37)

• public abstract void stateMachineMetaGame(long timeout): Este método é chamado para solicitar ao agente de GGP que inicie a fase de prepara¸cão para a partida, é fornecido o tempo limite para esta prepara¸cão.

• public abstract Move stateMachineSelectMove(long timeout): Este método solicita ao agente de GGP que comece o processamento do movimento que escolherá. Espera-se um movimento válido escolhido pelo agente. É fornecido o tempo limite que o agente tem para tomar a decisão de qual movimento efetuar. No momento em que este método é chamado, a máquina de estados do agente já deve ter sido atualizada para o estado atual da partida, senão o movimento escolhido será inconsistente ou incorreto, porém quem cuida dessa atualiza¸cão é o intermediador da partida, seja o Player ou o Kiosk.

• public abstract void stateMachineStop(): Quando o intermediador do agente de GGP entende que a partida deve ser terminada, este método é chamado. Nesta fase o agente de GGP fará o processamento final e armazenamento de aprendizado caso tenha alguma abordagem desta natureza implementada. Pode também armazenar a árvore de estat´ısticas.

• public abstract void stateMachineAbort(): Quando o intermediador da partida pre-cisa abortar a partida por qualquer razão, o agente de GGP é informado através deste método. Alguns dos motivos que podem causar a chamada deste método são runtime error, queda de conexão, fechamento inesperado do servidor etc. Este m´ e-todo é útil para que o agente de GGP preserve qualquer dado que possa aproveitar da partida parcial que estava participando.

• public final MachineState getCurrentState(): Retorna o estado atual em que se encontra a m´aquina de estados do agente de GGP.

• public final Role getRole(): Retorna com qual papel o agente de GGP está jogando. Por exemplo, no jogo da velha há dois papéis, X e O.

• public final StateMachine getStateMachine(): Retorna a máquina de estados do agente de GGP. Este método é utilizado tanto pelo intermediador quando precisa atualizar o estado da máquina de estados do agente, quanto pelo próprio agente

(38)

26 para fazer simula¸cões de sucessões de movimentos e possibilitar a constru¸cão de sua ´

arvore de estat´ısticas.

Na base de código existem classes que funcionam como uma interface entre o inter-pretador de GDL e a implementa¸cão do agente jogador de GGP. Estas classes encapsulam a complexidade de ter que lidar diretamente com proposi¸cões em linguagem lógica. Por-tanto, neste trabalho a implementa¸cão do agente foi feita sobre esse módulo, que integra a solu¸cão proposta ao motor da linguagem GDL, tornando os detalhes da interpreta¸cão da linguagem GDL transparente ao desenvolvedor.

A classe StateMachine representa o espa¸co de estados do jogo. Através desta classe é poss´ıvel obter informa¸cões sobre o estado atual do jogo, quem é o jogador da vez, verificar se um dado estado é terminal, verificar se alguém venceu dado um estado arbitrário que perten¸ca ao espa¸co de estados do jogo. Esta classe permite também verificar quais são os movimentos permitidos, dado o estado atual ou dado um estado arbitrário válido, ou seja, que perten¸ca ao espa¸co de estados do jogo. Com a utiliza¸cão da classe StateMachine é poss´ıvel percorrer o espa¸co de estados do jogo através das transi¸cões de estados. A seguir há uma lista dos métodos da classe StateMachine que são essenciais à implementa¸cão do agente de GGP. Os métodos que têm funcionalidade interna à classe e não são utilizados diretamente na implementa¸cão do agente não serão abordados.

• public abstract void initialize(List<Gdl> description): Este método não é utilizado diretamente pelo agente de GGP, porém é utilizado para inicializar a máquina de estados com as proposi¸cões-base e as regras do jogo descrito, em outras palavras, ele recebe uma lista de comandos em GDL para gerar o modelo de transi¸cão e o estado inicial. Este método é utilizado pelo Player ou Kiosk.

• public abstract int getGoal(MachineState state, Role role): Este método retorna um valor contido no intervalo [0, 100], que representa a utilidade do estado fornecido para o papel fornecido. Este valor depende da descri¸cão do jogo em GDL, geralmente os valores são 0, caso o estado fornecido seja terminal e o papel fornecido tenha perdido, 100, caso o estado seja terminal e o papel fornecido tenha vencido, e 50, caso o estado seja terminal e tenha acontecido um empate ou caso o estado não seja terminal.

(39)

• public abstract boolean isTerminal(MachineState state): Dado um estado arbitrário pertencente ao espa¸co de estados do jogo, ou seja, um estado válido, este método retorna true caso o estado seja terminal e false caso contrário.

• public abstract List<Role> getRoles(): Este m´etodo retorna a lista de todos os pap´eis dispon´ıveis no jogo. Por exemplo no jogo da velha retornaria uma lista com dois elementos, X e O.

• public abstract MachineState getInitialState(): Este método retorna o estado inicial do jogo, ou seja, o estado constru´ıdo com as proposi¸cões-base definidas na descri¸cão do jogo em GDL.

• public abstract List<Move> getLegalMoves(MachineState state, Role role): Este m´etodo recebe um estado dentre os poss´ıveis estados do espa¸co de estados do jogo e um papel e processa uma lista de movimentos v´alidos a partir do dado estado e o dado papel.

• public abstract MachineState getNextState(MachineState state, List<Move> mo-ves): Este método faz a transi¸cão de um dado estado arbitrário para um outro estado, seguindo os movimentos passados como uma lista de movimentos, desde que todos os movimentos sejam válidos. A lista de movimentos contém um movimento para cada papel do jogo, a ordem dos movimentos na lista deve seguir a ordem da lista de papéis adquirida chamando o método getRoles(). Mesmo que seja um jogo em que somente um jogador executa um movimento por turno, para os papéis que não podem executar nenhum movimento deve ser passado NOOP.

• public MachineState getNextStateDestructively(MachineState state, List<Move> mo-ves): Faz o mesmo que o método getNextState, porém não preserva o estado passado para o fim de economizar memória. Portanto depois que este método for chamado, o estado passado não será mais válido.

• public List<List<Move> > getLegalJointMoves(MachineState state): Este m´etodo recebe um dado estado que perten¸ca ao espa¸co de estados do jogo e retorna um produto cartesiano de todas as possibilidades de movimentos a partir deste estado. O produto cartesiano ´e retornado em forma de uma lista de listas de movimentos. Cada lista de movimentos tem um movimento para papel do jogo, a ordem dos

(40)

28 movimentos é a mesma ordem retornada pelo método getRoles(). Para jogos em que somente um jogador desempenha um movimento por turno, a cardinalidade da lista de listas de movimentos será a mesma da lista de movimentos válidos do jogador da vez.

• List<List<Move> > getLegalJointMoves(MachineState state, Role role, Move move): Este método retorna um subconjunto do produto cartesiano retornado pelo método anterior, com a restri¸cão de que filtrará somente as tuplas em que o dado papel efe-tua o dado movimento passados para os parâmetros do método. Este método só faz sentido para jogos em que mais de um papel pode efetuar um movimento por turno, sua utiliza¸cão seria verificar todos os poss´ıveis movimentos de outros participantes da partida caso um dos participantes já tenha escolhido seu movimento.

• List<MachineState> getNextStates(MachineState state): Este método expande um estado fornecido, desde que o estado seja válido. A lista de estados retornada pode conter estados repetidos, caso seja um jogo em que mais de um participante pode efetuar um movimento por turno, desde que seja poss´ıvel dentro do modelo de transi-¸cão do jogo duas ou mais combina¸cões de movimentos dos participantes transitarem de um estado para um outro mesmo estado.

• public Map<Move, List<MachineState> > getNextStates(MachineState state, Role role): Dado um estado válido e um papel dispon´ıvel na descri¸cão do jogo, este m´ e-todo retorna um mapeamento entre cada movimento válido para o papel fornecido a partir do estado fornecido, e uma lista de próximos estados para o qual aquele movimento a partir do estado fornecido pode transitar. Caso seja um jogo em que somente um jogador efetua um movimento por turno, a lista terá sempre cardina-lidade um, caso contrário a lista pode conter mais de um próximo estado poss´ıvel decorrente das múltiplas possibilidades de movimento simultâneo dos outros parti-cipantes da partida.

• public Map<Role, Integer> getRoleIndices(): Este m´etodo retorna um mapeamento entre os pap´eis no jogo e seus ´ındices.

• public List<Integer> getGoals(MachineState state): Dado um estado, retorna um valor de utilidade deste estado para cada papel dispon´ıvel no jogo, a ordem da lista

(41)

´

e a mesma ordem retornada pelo m´etodo getRoles().

• public MachineState getRandomNextState(MachineState state): A partir do estado fornecido, retorna um outro estado do espa¸co de estados do jogo escolhido aleato-riamente, desde que haja uma transi¸cão direta do estado fornecido para o estado obtido pelo método. Este método é útil para fazer a simula¸cão aleatória do algoritmo MCTS.

• public MachineState performDepthCharge(MachineState state, final int[] theDepth): Este método é um atalho para a etapa do algoritmo MCTS de simula¸cão, onde su-cessivos movimentos são feitos aleatoriamente até que se alcance um estado terminal do jogo. Ao concluir a simula¸cão, este método retorna o estado terminal encontrado. A classe MachineState representa um estado do espa¸co de estados do jogo. Esta classe armazena um conjunto de proposi¸cões em GDL que configuram o estado que o objeto desta classe está representando. A seguir estão listados os métodos da classe MachineState importantes para a implementa¸cão deste trabalho:

• public boolean equals(Object o): Este método retorna true caso o objeto passado como argumento é um objeto da classe MachineState e representa o mesmo estado do espa¸co de estados do jogo que está sendo representado pelo objeto do qual o método foi chamado.

• public String toString(): Este método converte o estado representado para um string com proposi¸cões em GDL. A utilidade deste método na implementa¸cão deste traba-lho foi auxiliar na depura¸cão do código quando era necessário verificar o conteúdo de um conjunto de estados.

A classe Role representa um papel numa partida do jogo. A finalidade desta classe é encapsular consultas em GDL sobre os papéis do jogo para tornar toda a parte da GDL transparente ao desenvolvedor. Os principais métodos desta classe para este trabalho são os mesmos que os da classe MachineState, equals(Object o) e toString(). O método toString() retorna o nome do papel em uma string, por exemplo num jogo de xadrez poderia retornar ”black” ou ”white”.

A classe Move representa um potencial movimento, ou seja, uma transi¸cão de um estado do espa¸co de estados do jogo para outro, que seja válida. Na prática esta

(42)

30

Figura 3.5: Fluxograma de uma partida

classe armazena um termo da linguagem GDL, um objeto do tipo GdlTerm. A classe StateMachine utiliza o conte´udo da classe Move para efetuar uma transi¸c˜ao de estado.

Na Figura 3.5 está apresentado um fluxograma do funcionamento de todo o pro-cesso de uma partida, desde as solicita¸cões do servidor até as respostas ao servidor. O

(43)

servidor solicita o pré-processamento ou a escolha de um movimento, a comunica¸cão é feita com o player. O player aciona o agente jogador de GGP. O agente jogador executa o algoritmo MCTS, ao passo que atualiza a árvore de estat´ısticas. O agente responde ao player, e então o player responde ao servidor.

O agente de GGP deste trabalho consiste de três classes. Duas delas, a classe StateTree e a classe Node são componentes da estrutura de dados necessária para a im-plementa¸cão do agente jogador de GGP. A classe MonteCarloTreeSearchGamer contém a implementa¸cão do algoritmo Monte Carlos Tree Search e utiliza as outras duas classes da implementa¸cão. Na Figura 3.6 são apresentados a arquitetura da implementa¸cão do agente e os relacionamentos entre as suas classes e as classes da interface com o interpretador de GDL.

A árvore de estat´ısticas do algoritmo MCTS consiste das classes StateTree e Node. Na Figura 3.7 é exibida a composi¸cão da árvore. A árvore consiste de instâncias da classe Node, que são os nós. A classe StateTree gerencia a estrutura da árvore e dá a visão de um objeto singular. Esta árvore armazena estados já visitados e estat´ısticas sobre os estados visitados, como a quantidade de vezes que o estado foi visitado e a quantidade

(44)

32 de vitórias que o agente jogador obteve na etapa de simula¸cão, ao visitar o ramo do estado em questão. Os estados contidos na árvore de estat´ısticas, bem como os seus dados estat´ısticos associados, são armazenados na classe Node. Além destas informa¸cões, a classe Node calcula o U CT do nó. A seguir há uma lista dos principais atributos da classe Node e suas descri¸cões:

• state: Este atributo armazena o estado do espa¸co de estados do jogo que este n´o representa

• transitionMove: Este atributo armazena o movimento que foi feito a partir do estado armazenado em seu n´o-pai, para que fosse alcan¸cado o seu estado armazenado. Caso o n´o seja a raiz, este atributo armazena o valor null.

• parent : Este atributo armazena o nó-pai deste nó. Caso o nó seja a raiz, este atributo recebe o valor null.

• children: Este atributo é um conjunto de nós-filhos. Como este trabalho trata de um contexto em que o espa¸co de estados é desconhecido, por ser uma abordagem de general game playing, a cardinalidade dos nós é arbitrária, além disso a ordem dos filhos não é relevante, portanto é utilizada a estrutura de dados de conjunto. • visitCount : Este atributo armazena a quantidade de vezes que a busca da etapa de

sele¸c˜ao passou por este n´o.

• winCount : Este atributo contabiliza quantas vezes a etapa de simula¸cão obteve um resultado de vitória, dentre toda as vezes que a busca na etapa de sele¸cão passou por este nó.

• explored : Indica se este nó já foi visitado pelo menos uma vez, pois ele pode ter sido criado e adicionado à árvore na fase de expansão e não ter sido visitado nenhuma vez ainda. Esta informa¸cão é importante, pois na fase de sele¸cão, quando a busca está num nó que nem todos os filhos foram explorados ainda, escolhe-se arbitrariamente um nó-filho que ainda não tenha sido explorado.

• isTerminal : Este atributo indica se o nó em questão é um nó terminal.

Os métodos da classe Node têm a finalidade de oferecer as funcionalidades neces-sárias às classes StateTree e MonteCarloTreeSearchGamer. Alguns dos métodos da classe

(45)

Node executam fun¸cões essenciais para algumas das etapas do algoritmo MCTS, princi-palmente nas etapas de sele¸cão, expansão e back-propagation. A seguir, há uma lista com os métodos da classe Node utilizados na implementa¸cão do algoritmo MCTS:

• public boolean areChildrenCreated(): Verifica se os nós-filho já foram criados. Os nós filhos quando são criados na fase de expansão, já são criados todos de uma única vez, porém incialmente estão como não explorados.

• public boolean areAllChildrenExplored(): Verifica se todos os nós-filhos foram explo-rados. Na fase de sele¸cão é escolhido sempre um nó não explorado, a não ser que todos os nós-filhos já tenham sido explorados, neste caso é escolhido um nó-filho segundo o critério de UCB do algoritmo.

• public boolean createChildren(): Este método faz a etapa de expansão. Ao ser chamado, todos os nós-filhos do nó em questão são criados de uma vez, todos são configurados como não explorados. Caso o nó já tenha os nós-filhos criados, ou seja, um nó terminal da árvore de estados do jogo, nenhuma a¸cão é executada.

• public Node selectBestChild(): Retorna o melhor filho segundo o crit´erio de UCB do algoritmo. Caso nem todos os filhos tenham sido ainda visitados, retorna o valor null.

• public Node selectBestScoreChild(): Retorna o melhor filho utilizando como critério somente a propor¸cão de quantidade de vitórias para a quantidade de visitas. Se os nós-filhos ainda não foram criados, retorna o valor null.

• public Node getRandomUnexploredChild(): Este método seleciona aleatoriamente um dos nós-filhos que não tenham sido ainda explorados. Sua fun¸cão é selecionar um nó-filho na etapa de expansão do algoritmo. Caso os nós-filhos ainda não tenham sido criados, retorna o valor null. Caso todos os nós filhos já tenham sido criados, ´

e lan¸cada uma exce¸c˜ao.

• public void updateChildrenUCBVal(): Atualiza o valor do coeficiente UCB de todos os n´os-filhos que j´a foram visitados pelo menos uma vez.

• public int simulate(int probes): Este método executa a etapa de simula¸cão do algo-ritmo MCTS, ou seja, a partir do estado que o nó carrega, são feitas transi¸cões de