Aulas 14 e 15 - Projeto

Human-Like Non-Player Characters in UT2004 Arena

Resumo

Nas atividades anteriores apresentamos três arquiteturas cognitivas: Soar, CLARION e LIDA. Para cada  arquitetura desenvolvemos uma breve introdução teórica e um experimento com o WorldServer3D. Nesta atividade escolhemos uma quarta arquitetura cognitiva: o Pogamut. e para realizar o experimento escolhemos um outro ambiente de interação: o Unreal Tournament (edição 2004: UT2004 - formato Single Player). A escolha em apresentar o Pogamut se deve a três pontos: (1) no comparativo de 2010 da BICA, o Pogamut é a única proposta de arquitetura cognitiva que faz uso explícito do termo memória espacial (associada a uma memória episódica), (2) o Pogmut é também um middleware que pode ser utilizado como plataforma de prototipação rápida de personagens não jogadores (Non-Player Characters - NPCs) ligado explicitamente a ferramentas de produção comercial (p.ex., o setor de produção de jogos) como o UDK, (3) a relação explícita do Pogamut com ferramentas de produção comercial o torna interessante como plataforma de aprendizagem (de técnicas de inteligência artificial e tópicos em ciências cognitivas) em cursos de graduação (voltadas ao setor de produção: engenharias, computação) como na disciplina Human-like artificial agents - NAIL068. O roteiro desta apresentação segue esquema similar ao da exposição sobre o LIDA: apresentamos os conceitos básicos da arquitetura e exploramos um exemplo de implementação. 

Apresentação

Nas atividades anteriores apresentamos três arquiteturas cognitivas: Soar (Aulas: 2, 3, 4, 5, 6 e 7), CLARION (Aulas, 8 e 10) e LIDA (Aulas 12 e 13); com atividades associadas ao ambiente WorldServer3D (Aulas 1, 7 e 10). Nesta atividade estudamos o Pogamut em conjunto com o Unreal Tournament (edição 2004: UT2004 - formato Single Player).

A escolha em apresentar o Pogamut se deve a três pontos:

• No comparativo da Biologically Inspired Cognitive Architectures Society  (BICA) de 2010, veja  [ aqui ], o Pogamut é a única proposta de arquitetura cognitiva que faz uso explícito do termo memória espacial (associada a uma memória episódica) [ Brom ] e [ Gemrot ].
• O Pogmut é também um middleware que pode ser utilizado como plataforma de prototipação rápida de personagens não jogadores (Non-Player Characters - NPCs) ligado explicitamente a ferramentas de produção comercial (setor de produção de jogos) como o UDK, [Gemrot (a) ] e  [ Gemrot (b) ]. Além disso, como middleware, é um dos poucos que oferece possibilidades de integração com outras arquiteturas cognitivas, [ Gemrot (b) ], como o Soar, ACT-R, LIDA e CERA-CRANIUM.   
• A relação explícita do Pogamut com ferramentas de produção comercial o torna interessante como plataforma de aprendizagem (de técnicas de inteligência artificial e tópicos em ciências cognitivas) em cursos de graduação (voltadas ao setor de produção: engenharias, computação) como na disciplina Human-like artificial agents - NAIL068.

O primeiro aspecto é explorado na Seção 2 e os outros dois na Seção 3. O formato desta atividade segue o padrão das outras: (1) iniciamos com uma curta introdução sobre o uso de personagens não jogadores (Non-Player Characters - NPCs) em jogos de computador no estudo (e produção) da inteligência artificial; (2) fazemos uma breve apresentação da arquitetura cognitiva Pogamut; (3) expomos a plataforma UT2004 (usamos a versão "Editor's choice", mais especificamente: "Editor's choice Edition" instalada no Ubuntu) e tratamos da comunicação entre o Pogamut e o UT2004; (4) discorremos sobre a implementação da simulação feita no Ubuntu 12.04 LTS (Precise Pangolin) - 64 bit; (5) colocamos nossas considerações. 

1. Introdução

É comum o uso de jogos, de diferentes tipos, como instrumentos para avaliar competências e habilidades. Ainda hoje, jogos como o xadrez e o go são considerados "jogos que exigem grande capacidade de raciocínio". De fato, os jogos de tabuleiro foram utilizados como "arena de teste para avaliar sistemas de inteligência artificial"; tornou-se histórica a série de jogos ocorrida em 1977 entre o Deep Blue e o então campeão Garry Kasparov. Atualmente, os jogos de tabuleiro não despertam tanto interesse, como no início do estudo a Inteligência Artificial (IA) - o go pode ser considerado uma exceção. Essa mudança de interesse tem diversos motivos: a proposta de diferentes perspectivas sobre a noção de inteligência (já não mais festá restrita unicamente ao "processo de raciocínio"); o surgimento de novas e diferentes tecnologias (robótica, sistemas de tempo real, processadores específicos - GPU, etc); a multidisciplinaridade associada ao tema (p.ex., o envolvimento das ciências cognitivas, neurociência computacional); etc. 

Diante dessas mudanças, alguns estudiosos consideram um novo cenário para o estudo a IA: os jogos de computador interativos envolvendo personagens não jogadores (ou non-player characters - NPCs). O desafio é desenvolver NPCs com comportamento similar ao humano, [ Laird ]. Este cenário difere dos jogos restritos ao universo dos tabuleiros, estamos tratando de outro universo, jogos First Person Shooter (FPS), Massively Multiplayer Online Role-Playing (MMORP) ou Real-Time Starategy (RTS).   Os NPCs devem racionar em tempo real, exibir comportamento adequado (que o tornem convincente como um jogador, [ Byl ]), devem ser sociáveis, hábeis, engajar o jogador humano ao jogo, etc. Afinal, o que os jogadores humanos desejam são adversários hábeis, flexíveis, imprevisíveis, que se adaptem a estratégias de jogo (para jogos envolvendo grupos), raciocinem sobre ações e utilizem diferentes estratégias em diferentes situações de jogo,  [ Byl ]. Isso tudo parece corroborar seguinte fala: "... interactive computer games provide a rich environment for incremental research on human-level AI", [ Laird ].

Juntamente com os desafios científicos associados aos diversos tópicos envolvidos no estudo da "Inteligência Artificial" (das ciências cognitivas, da neurociência, física, matemática, computação, etc)  temos as demandas do setor de produção tecnológica (das engenharias). No setor de jogos, espera-se que os avanços tecnológicos favoreçam a produção de NPCs com algumas características fundamentais para gerar comportamentos similares aos dos jogadores humanos: percepção, memória, capacidade de gerar conhecimento, memória episódica (ter um relato da vida), emoção, capacidade de comunicação, etc. Um dos desafios do setor de produção de jogos de computador é ampliar (quantitativamente e qualitativamente) a diversidade de plataformas de avaliação da performance de NPCs. Citamos duas iniciativas de, digamos, engajamento na melhoria de NPCs: o prêmio Loebner  e o Botprize. O Prêmio Loebner é uma competição anual entre chatterbots. Ganha o chatterbot considerado o mais "próximo ao comportamento humano". O ALICE venceu esta competição por três vezes, o vencedor de 2012 foi o Chip Vivant. O Botprize é um torneio com jogos FPS. Assim como o prêmio Loebner, o BotPrize é considerado como sendo uma adaptação do teste de Turing: can a computer be programmed to behave like a human? Can an artificial bot have personality, fallibility and cunning? O vencedor de 2010 foi o CERA-CRANIUM-Bot2 (ou CC-Bot2 [ Arrabales ], baseado no CERA-CRANIUM cognitive architecture), o de 2011 foi o ICE-CIG, em 2012 tivemos um empate técnico entre o UT^2 [ Schrum ] e  MirrorBot [ Thawonmas ] (vídeos de outros bots do torneio [  aqui ], vídeos do UT^2 no UT2004 [ aqui ]). A Figura 1 mostra o esquema de avaliação no BotPrize (jogadores, humanos e NPCs, podem se conectar ao jogo remotamente; é mantido o anonimato):

Dentre as características fundamentais mencionadas temos a percepção, mecanismos de memória e raciocínio, que estão incorporadas às arquiteturas cognitivas estudadas anteriormente. Essas características são componentes associadas à noção de inteligência, logo seria interessante tê-las como parte da arquitetura de um NPC. Nas seções seguintes expomos a arquitetura cognitiva Pogamut e a estrutura do experimento com o UT2004.   

2. A Arquitetura Cognitva Pogamut

No Pogamut o conhecimento e as experiências são repreentadas por regras e operadores. Os principais componentes da arquitetura estão representados na Figura 2.

Similar ao Soar, o conhecimento procedural é codificado em forma de regras (neste caso: regras reativas) e as memórias episódicas e espacial em forma de estruras em grafos. Esta é uma das poucas arquiteturas que faz uso explícito do termo "memória espacial" associada a uma memória episódica. O framework computacional do Pogamut oferece componentes como: memória de trabalho (memória declarativa), memória episódica (declarativa juntamente com uma rede de ativação) , memória procedural (regras), memória perceptual (representa um conjunto de objetos percebidos pelo agente) e um mapa-cognitivo (baseado em grafos e na teoria bayesiana). Os aparatos motores e sensórios incluem, por exemplo, a visão (de natureza representacional simbólica e sub-simbólica) - são conceitos similares ao do CLARION: a forma simbólica refere-se ao conhecimento explícito (como feito no Soar) e a forma sub-simbólica refere-se ao conhecimento implícito (implementado, por exemplo, por uma rede neural artificial:o conhecimento está distribuído dentro da rede ).

A memória episódica tem como base o sistema de aprendizado (não é fornecida nenhuma referência externa). A estratégia considera que: (1) se a ativação de um neurônio tiver grande influência na ativação de um outro neurônio, a ligação entre estes dois neurônios deve ser reforçada e (2) se a ativação de um neurônio não influencia a ativação de um segundo neurônio, a ligação entre estes dois neurônios deve ser enfraquecida ou até mesmo removida. A arquitetura contempla o aprendizado (episódico e espacial) em tempo real. Os experimentos com o Pogamut envolvem cenários que tratam de tomadas de decisões, resoluções de problemas, aprendizado, exploração e navegação espaciais.

Os Módulos de um Bot Pogamut no UT2004

A criação de um bot em Pogamut é modular (instâncias de variáveis), as variáveis (módulos) básicas são: 

• world: que trata da visão global do mundo (ambiente inicial). Permite obter todos os objetos (instâncias): bots (outros personagens), pontos de navegação, objetos do ambiente (alimento, armas, etc). Também permite registrar listeners sobre objetos e eventos.  
• info: mantém informações referentes ao estado interno do bot: saúde, adrenalina, velocidade de movimentação,  munição, parceiros (em jogos de esquipes), etc;  veja o manual do UT2004 [ aqui ].
• bot: representa uma instância do bot, mantém todas as informações de um dado bot em relação ao jogo em execução: identificação (nome) com o Pogamut e seu posicionamento no mapa .
• weaponry: armazena todas as informações sobre o armamento que está sendo utilizado pelo bot: munição (primária e secundária) - novamente, recomendamos a leitura do manual do UT2004 [ aqui ].
• pathPlanner: variável associada ao bot que mantém o plano de rotas. Permite calcular, usando o método o computePath, o caminho entre duas posições no mapa (dentro da rede de caminhos) . A Figura 3 mostra exemplos de um mapa e de uma rede de caminhos dentro do UT2004. O computePath recebe um nó objetivo (pertencente a rede de caminhos) e devolve um conjunto (seqüência) de nós de navegação que formam o caminho da posição corrente do bot ao destino.   

Figura 3. UT2004: mapa e rede de caminhos monitorados pelo NetBeans em tempo real.

• pathExecutor: esta variável trata de executar o caminho calculado pelo planificador. Determina ao bot os nós da seqüência de um dado caminho a seguir. Também mantém um histórico que permite ao bot retroceder no caminho executado.
• game: esta variável armazena toda informaçõa referente ao jogo em execução: nome do mapa, tipo da partida, características do jogo, tempo de jogo, pontuação (no DeathMatch é o número de bots abatidos), etc - novamente, recomendamos a leitura do manual do UT2004 [ aqui ].   
• players: mantém as informações de todos jogadores da partida em andamento. Permite a um dado bot determinar quais são os bots inimigos, a qual time pertence, a posição mais próxima de um bot (inimigo ou não) visível, etc. 
• senses: trata das informações sensoriais do bot, inclusive se está ou não morto. Informa sobre eventos sonoros (passos, seus próprios passos), visuais, etc.
• body: trta dos comandos de controle e ação: SimpleRayCasting, Action, AdvancedLocomotion, AdvancedShooting e Communication. Por exemplo, o SimpleRayCasting é um módulo que permite avisar sobre ocorrencias de colisões com objetos do mundo.

A Estrutura de um Bot Pogamut

A estrutura de um bot Pogamut depende de seis métodos elementares. Os quatro abaixo são executados para inicializar o bot. 

• prepareBot: este método é executado antes da conexão do bot com o jogo. Serve para inicializar os módulos do bot, por exemplo, o pathExecutor.   
• getInitializeCommand: este método é executado logo após o prepareBot. Serve para definir os atributos do bot: identificação, posição no mapa, quais os bots amigos (se for o caso), etc. Este método cria o objeto Initialize onde configura todos os atributos do bot (é o objeto retornado pelo método).
• botInitialized:  este método é executado logo após o getInitializeCommand. Responde (com um INITED) a solicitção (ao INIT) do bot para a conexão. Isto não significa que a figura do bot aparece no ambiente de jogo, apenas que a conexão entre o bot e o servidor foi estabelecida.    Este método possui trê parâmetros referentes a: informação do jogo (tipo de jogo, mapa, etc); estado corrente do bot (inclui o que foi definido pelo método getInitializedCommand()) e as variáveis do bot ( velocidade de movimento, saude, etc). Também são configurados outros atributo ainda não definidos pelo método getInitializeCommand.
• botSpawned: este é o último método da seqüência de inicialização, é executado após o   botInitialized. Neste momento a figura do bot surge no mapa pela  primeira vez. Rece o parâmetro self que contém informações sobre o estado corrente do bot e sua localização no mapa. 
• logic: este método é chamado logo após o término da inicialização. O logic é chamado periodicamente pelo Pogamut: quatro vezes a cada segundo. O método é responsável pela inteligência do bot, é ele que determina o comportamento do bot em relação a busca de energia (alimento), armas, munição, enfrentamento de bots inimigos, etc. 
• botKilled: este método é executado quando o bot morre durante uma partida, sua execução reinicializa as variáveis internas para poder ser, mais uma vez, executado pelo método logic.

Nas seções seguintes apresentamos as plataformas UT2004 em conjunto com o Pogamut e um exemplo de bot Pogamut.

3. UT2004: Unreal Tournament 2004 e Pogamut

O UT2004 é uma plataforma de jogo FPS que permite criar experimentos de controle de bots em diversos cenários. O UT2004 oferece cenários (tipos de disputa) que envolvem combates individuais entre bots (deathmatch) -  controlados por jogadores humanos ou não -, combates entre grupos de bots (team deathmatch), disputas do tipo tomar a bandeira  inimiga (capture the flag), levar uma bomba até o quartel inimigo (bombing run), ou de estratégia (double domination), etc. Cada um desses cenários pode ser usado para explorar diferentes arquiteturas de bots. No caso de bots autônomos a execução é feita pela mod GameBots2004. O GameBots2004 (ou GameBots) é uma modificação (mod) do UT2004 , escrita em UnrealScript, que fornece um protocolo de texto para controle de bots em conexões com servidores de jogos UT2004. O usuário do GameBots pode controlar os bots via comandos de texto e receber informações (mensagens) do servidor de jogo em formato de texto. Atualmente este mod é parte integrante do Pogamut 3. Também é possível usar o editor do UT (UDK) para criar os próprios mapas para a simulação dos experimentos, como exemplo citamos o USARSim: um simulador robótico baseado no UT2004, eis um vídeo de demonstração.

O Pogamut é uma plataforma Java própria para desenvolver agentes virtuais em Java ou POSH. Os agentes podem ser integrados a ambientes como UT2004, USARSim, UnrealEngine2Runtime (versão gratuita do UnrealEngine2) e DEFCON (jogo de estratégia em tempo real), também é possível integrar ao UnrealEngine3. Para o nosso experimento utilizamos o Java via NetBeans com o Apache-Maven. A Figura 4 mostra a estrutura do Pogamut 3.

Como mostra a Figura 4, o Pogamut 3 é uma caixa de ferramentas que integra o UT2004, GameBots2004, a biblioteca GaviaLib, o bot Pogamut e uma IDE (no caso o NetBeans). Cada uma dessas componentes pode ser utilizada separadamente. As ocorrências (informações) no UT2004 são exportadas (via TCP/IP) utilizando o protocolo de texto do GameBots, as mensagens são tratadas pela biblioteca Java Gavalib (desse modo um bot Pogamut pode tratar objetos Java). Após interpretar e processar as informações, o bot responde na forma de comandos do jogo (via TCP/IP). No caso de conexões remotas, a troca de mensagens segue o protocolo JMX com um plugin Pogamut instalado no NetBeans.    

Desse modo, o GameBots atua como um servidor TCP/IP (define um protocolo de texto) para que cliente possa executar as respostas do bot no UT2004 e para que o bot seja informado sobre os eventos (mensagens assíncronas) ou estados (mensagens síncronas) do mundo. Uma vez feita a conexão, o GameBots envia informações sobre o jogo e o mapa que o UT2004 está executando. Em seguida, envia os pontos de navegação (NavPoints) e objetos contidos no mapa. A troca de mensagens (informações sobre o ambiente e envio de comando dos bots) é habilitada somente após o GameBots receber um INIT (que gera os bots no ambiente de jogo). O tratamento das mensagens é feita pela biblioteca Gavlib, grosso modo, é uma interface entre o Pogamut e o UT2004; a Figura  5 mostra a estrutura do Gavialib. 

Figura 5. Estrutura da biblioteca Gavialib. Fonte [ Gemrot (b) ]

Por fim, toda a dinâmica do bot no ambiente do UT2004 pode ser acompanhada (e depurada) em tempo real através do NetBeans, via protocolo JMX.

Nosso interesse no uso do Pogamut 3 está na possibilidade de implementar exemplos de bots que carregam algum tipo de aparato cognitivo, por exemplo, um sistema de memória episódica. Integrar ao bot um sistema de controle baseado num modelo sustentado por algum modelo de teoria cognitiva (concretizado em um framework computacional, como, o Soar, CLARION, LIDA, ACT-R, etc). Esses exemplos de bots serviriam como amostra para análise de comportamento. Eventualmente, poderiam ser úteis como forma de prototipação-rápida de NPCs, por exemplo, para determinar se o comportamento do NPC é ou não plausível em relação a um dado jogo.

Dois exemplos de uso do Pogamut com diferentes arquiteturas cognitivas: o PojACT-R e o CC-Bot2 [ Arrabales ]. O primeiro envolve a arquitetura ACT-R, mais especificamente, uma variante chamada jACT-R. O segundo, mais recente envolve a arquitetura CERA-CRANIUM (CC) - os autores utilizaram o IKVM.NET para gerar uma implementação funcional integrando a arquitetura CC (implementada em .NET) e o Pogamut (implementado em Java). O modelo CERA-CRANIUM é baseado no GWT, ou seja, tem a mesma fundamentação conceitual do LIDA - Aulas 12 e 13. A Figura 6 mostra a estrutura Pogamut-CC, o CERA-CRANIUM como sistema de controle do bot, envolvendo um jogador e um espectador humanos.

Apesar desse conjunto de ferramentas, do Java para montar a infraestrutura do bot  e do Pogamut 3 para conectá-lo bot ao UT2004 (uma rica arena de testes), ser atrativo para a implementação e avaliação do comportamento de bots em situações diversas, há alguns cuidados a considerar. Por exemplo, o tempo dos ciclos no UT2004 não são regulares. Desse modo, é necessário desenvolver um controle externo, especialmente para bots cujo sistema de controle está vinculado à uma arquitetura cognitiva: consomem tempo elaborando (raciocinando) internamente suas ações.       

Nas seções seguintes relatamos o processo de instalação e configuração do UT2004 e Pogamut 3 numa máquina com  Ubuntu 12.04.

Instalação do UT2004 no Ubuntu 12.04 LTS

A seguir um roteiro (passo-a-passo) de instalação do UT2004, versão "Editor's choice", no Ubuntu 12.04. É necessário ter o conteúdo do DVD do UT2004 "Editor's choice" (com a respectiva chave do produto). A versão que estamos usando é a da extinta Midway Games. 

• Faça o download do instalador (repositório local): ut2004_3369.midway.dvd-3.run (via torrent: ut2004_3369-english.midway.dvd-3.run). Modifique o arquivo para executável (via terminal: sudo chmod +x ./ut2004_336.midway.dvd-3.run) e execute-o (via terminal: sudo ./ut2004_336.midway.dvd-3.run). O uso do sudo é opcional.
• Deve abrir a seguinte sequência de janelas: (1) da licença, (2) das opções para o local de instalação, (3) da chave do produto.  
• Após inserir a chave do produto e pressionar o botão "Continue", abre-se a janela de início do processo de extração de arquivos. Pressione o botão de início de instalação e aguarde alguns segundos. Em seguida, abra um terminal, identifique o processo de setup (via terminal: ps -a) e mate-o (via terminal: sudo kill -9 .setup-número-do-processo) - NÃO mate o processo ut2004_3369-eng. Isso libera uma outra janela de início do processo de extração de arquivos (muito parecido com o anterior). NÃO ATIVE as opções Install a symbolic link into the path e Startup menu entries, pressione o botão de início de instalação. Novamente, temos uma janela exibindo o início do processo de extração de arquivos. O início da extração de arquivos pode demorar (alguns minutos, ... muitos minutos), depende da configuração do equipamento em que se está efetuando a instalação - vai parecer que a máquina "travou", mas  ... aguarde! A Figura 7 mostra algumas das janelas do processo de instalação (para aumentar o tamanho da figura, coloque o cursor do mouse sobre a figura e use o botão direito para escolher "Ver Imagem"): 

• Ao final da extração de arquivos é exibida uma janela indicando o local da instalação e uma mensagem para o comando de execução: Type 'ut2004' to start the program. 
• Ao ativar a execução ./t2004 pode ocorrer o seguinte "erro": 

                   

 ./ut2004: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

Nesse caso é preciso verificar as dependências em relação ao pacote libstdc++.so.5. Veja a lista em archlinux ou então opte por instalar o pacote (via terminal: sudo apt-get -f install libstdc++5 libaio1 libsdl-mixer1.2  libsdl-net1.2  libsdl-ttf2.0-0 xaw3dg libmikmod2 oss-compat).

Finalmente, para executar o UT2004 basta usar (via terminal): ./ut2004 ou padps ./ut2004 (ação com som). Para facilitar as várias execuções crie um launcher. Crie um arquivo ut2004.desktop no diretório .local/share/Applications e edite o código abaixo (converta-o num "executável"):

       
[Desktop Entry]
Type=Application
Terminal=false
StartupNotify=true
Icon= ...  digite o caminho para o arquivo ".xpm" (há um no local ond foi instalado o ut2004)
Name=UT2004
Exec= ... digite o caminho para o arquivo "ut2004.sh" (com som: digite: padsp " ...caminho... ") 
Categories=Application; 
    

Teste o ícone. Deve exibir a tela de abertura do UT2004 (vide Figura 8).

Instalação do Pogamut no Ubuntu 12.04 LTS

O Pogamut é um middleware Java que permite o controle de bots em diversos ambientes de jogos, nosso interesse está no uso do UT2004. A comunicação para o controle do bot é feita via socket interfaceado pelo GameBots2004 (um mod para o UT2004 contido no Pogamut 3). Utilizamos a versão 3.5.1 do Pogamut 3, obtenha o arquivo [ aqui ] - repositório SVN [ aqui ], trata-se de um arquivo ".jar", para proceder a intstalação digite: java -jar PogamutUT2004Installer-3.5.1.jar. A Figura 9 mostra algumas etapas da instalação:

Na última etapa o instalador exibe uma mensagem referente à permissão de acesso para a execução do arquivo install-all.bat. A execução do install-all.bat  refere-se à instalação dos arquétipos Maven contidos no pacote Pogamut (vide subdiretório ut2004). Cada arquétipo está numa pasta que contem um arquivo pom.xm, para instalar um arquétipo basta executar o comando (via terminal): mnv -f pom.xml install.

Conexão do bot ao UT2004 via Pogamut

Nesta seção, verificamos se a instalação do Pogamut tem acesso ao UT2004. Para proceder a checagem ativamos o Netbeans criando um novo projeto com as opções Maven e Project from Archetype. As informações necessária para o maven são:

                             
Group ID: cz.cuni.amis.pogamut.ut2004.examples         
Artifact ID: 00-empty-bot-archetype 
Version: 3.5.1-SNAPSHOT           
Repository: http://diana.ms.mff.cuni.cz:8081/artifactory/repo
       

O exemplo do projeto pode ser obtido [ aqui ], basta descompactar e abrir com o NetBeans.  A Figura 10 mostra a IDE NetBeans com o proneto 00-empty-bot-archetype.

A requisição de acesso ao servidor de jogo UT é feito com o GameBots2004: ative o arquivo ucc.bin que está no diretório System (uma das subpastas do diretório onde foi instalado o UT2004). Para a ativação use os seguintes comandos:

                
chmod +x ./ucc-bin   // Caso seja necessário

sudo ./ucc-bin server DM-TrainingDay?game=GameGots2004.BotDeathMatch?timelimit=999999 
                    
                   

Caso o servidor de jogo solicite uma chave de acesso, obtenha uma chave  [ aqui ] (deve receber uma string na forma SRVER-XXXXX-XXXXX-XXXXX) e inclua a chave na pasta System. Basta digitar: 

                
echo "SRVER-XXXXX-XXXXX-XXXXX" > ./cdkey 
                    
                    

Após executar o comando de requisição, o servidor envia uma sequência de mensagens, veja a Figura 11. Observe os números das portas de acesso (destaques em verde).

A Figura 12 mostra a conexão do UT2004 via GameBots, as duas últimas opções (Bombing Run e Capture the Flag Game) são os tipos de jogos via GameBots.

Para exemplificar como estabelecer a conexão NetBeans-UT2004 utilizamos um exemplo do navigation-bot, veja arquétipo  [ aqui ]. Quase todo os exemplos, referentes ao UT2004, contidos no repositório de artefatos do Pogamut  está embutido na instalação do pacote Pogamut 3.5.1. O exemplo que utilizamos é uma variante do navigation-bot, desenvolvida por R. Kadlec, J. Gemrot e Čestmír Houšťka (CollectorBot) para a discplina Human-like artificial agents - NAIL068 (veja outros exemplos [ aqui ]). A Figura 13 exibe a IDE NetBeans com o CollectorBot carregado, uma vez em execução faça a conexão com o servidor de jogo UT2004. Para efetivar a conexão basta colocar o cursor do mouse sobre o UT2004 Servers, ative, com o botão direito do mouse, a inclusão (Add Server) e inclua as seguintes informações (veja na Figura 11 qual porta escolher: Bot Server, Control Server ou Observing Server):

                                      
Server Name: UT2004local        
URI: localhost:3001 ou localhost:3002, localhost:3003. 
Map: ... (é selecionado automaticamente)           

               

Escolha a opção spectate (para aumentar o tamanho da figura basta colocar o cursor do mouse sobre a figura e utilizar o botão direito para escolher: "Ver Imagem"):

Figura 13. Conexão com o UT2004.

Com a conexão estabelecida, ativamos o UT2004:

                                      
./ut2004 127.0.0.1
                          
               

A Figura 14 mostra o carregamento do ambiente DM-Training Day e, após a escolha pela opção spectate, o ambiente de jogo é ativado com o bot na arena. No quadro da direita vemos as mensagens do bot em amarelo (parte inferior esquerda) e em  verde os informes sobre a localização, rotação e velocidade (parte superior) enviadas pelo sistema.  

Figura 14. UT2004: DeathMatch - Training Day

A seguir utilizamos o CollectorBot como base para implementar um aparato cognitivo na arquitetura do agente UT2004.

4. Exemplo de Aplicação: um NPC Pogamut no UT2004

A seguir trechos de código do CollectorBot (veja em CollectorBot.java - de E. Kadlec e Jakub Gemrot). O CollectorBot é um exemplo de bot que vagueia (anda randomicamente) pelo ambiente, ele também está programado para seguir um bot. Abaixo exibimos a codificação da estrutura de controle do bot.

        
public class CollectorBot extends UT2004BotModuleController {    

   . . . 
           
    // Main method that controls the bot - makes decisions what to do next.
    // It is called iteratively by Pogamut engine every time a synchronous batch
    // from the environment is received. 
    // This is usually 4 times per second - it is affected by visionTime variable, 
    // that can be adjusted in GameBots init file in UT2004/System folder.
    @Override
    public void logic() {
        if (!navigation.isNavigating() && waitForItems.tryUse()) {
            collectNextItem();
        }

        return;
    }

   . . . 

    public static void main(String args[]) throws PogamutException {
      // wrapped logic for bots executions, suitable to run single bot in single JVM
      //      
      // we're forcingly setting logging to aggressive level FINER so you can see 
      // (almost) all logs that describes decision making behind movement of the bot 
      // as well as incoming environment events
      new UT2004BotRunner(CollectorBot.class, 
                   "CollectorBot").setMain(true).setLogLevel(Level.FINER).startAgent();
    }

}
              

Abaixo temos as estruturas de dados utilizadas:  

                                           
package com.mycompany.collectorbot;

   . . . 

@AgentScoped
public class CollectorBot extends UT2004BotModuleController {    
        
   // Items that the bot cannot pick up
   protected TabooSet<Item> tabooItems;

   // Cooldown that ensures that once all items are collected, the bot waits for some 
   // time before trying again.
   protected Cooldown waitForItems;
        
   // The closest navigation point to the bot.
   protected NavPoint currentNavPoint;
        
   // Item we are navigating to
   protected Item targetItem;

   // Path auto fixer watches for navigation failures and if some navigation link is 
   // found to be unwalkable, it removes it from underlying navigation graph.
   protected UT2004PathAutoFixer autoFixer;
    
   . . . 

} 
   

                

A inicialização do bot é feita do seguinte modo: 

public class CollectorBot extends UT2004BotModuleController {    

   . . . 
        
 // Here we can modify initializing command for our bot.
 @Override
 public Initialize getInitializeCommand() {
     return new Initialize().setName("NavigationBot");
 }

 // The bot is initialized in the environment a physical representation of the bot 
 // is present in the game.
 @SuppressWarnings("unchecked")
 @Override
 public void botInitialized(GameInfo gameInfo, 
                            ConfigChange config, 
                            InitedMessage init) {
    // Initialize the set of uncollectable items
    tabooItems = new TabooSet<Item>(bot);

    // auto-removes wrong navigation links between navpoints
    autoFixer = new UT2004PathAutoFixer(bot, pathExecutor, fwMap, navBuilder);        
        
    // Adds a listener to the path executor for its state changes, it will allow 
    // you to react on stuff like "PATH TARGET REACHED" or "BOT STUCK"
    pathExecutor.getState().addStrongListener(new FlagListener<IPathExecutorState>() {
        @Override
        public void flagChanged(IPathExecutorState changedValue) {
            pathExecutorStateChange(changedValue.getState());
        }
    });
        
    waitForItems = new Cooldown(3000);  
    waitForItems.clear();
 }
    
 // The bot is initilized in the environment - a physical representation of the
 // bot is present in the game.
 @Override
 public void botFirstSpawn(GameInfo gameInfo, 
                           ConfigChange config,//config information about configuration
                           InitedMessage init, //information about configuration
                           Self self) {
     // receive logs from the navigation so you can get a grasp on how it is working
     pathExecutor.getLog().setLevel(Level.ALL);
 }
    
 // This method is called only once right before actual logic() method is called for 
 // the first time.
 @Override
 public void beforeFirstLogic() {
 
   . . . 
 }
 . . . 

}
                                   

O direcionamento do bot segue as seguinte regras: 

                
public class CollectorBot extends UT2004BotModuleController {    

   . . . 
        
    // Path executor has changed its state (note that 
    //
    // {@link UT2004BotModuleController#getPathExecutor()} is internally used by
    // {@link UT2004BotModuleController#getNavigation()} as well!).
    protected void pathExecutorStateChange(PathExecutorState state) {
        switch(state) {
        case PATH_COMPUTATION_FAILED:
            // if path computation fails to whatever reason, just try another navpoint
            collectNextItem();
            break;                    
            
        case TARGET_REACHED:
            collectNextItem();
            break;                    
        
        case STUCK:
            // the bot has stuck! ... target nav point is unavailable currently
            tabooItems.add(targetItem, 60);                    
            break;
            
        case STOPPED:
            // path execution has stopped
            targetItem = null;
            break;
        }
    }
   . . . 

}     
    

Abaixo alguns métodos auxiliares:

                  
public class CollectorBot extends UT2004BotModuleController {    

   . . . 
        

    // If we pick up an item, tabooize it
    @EventListener(eventClass = ItemPickedUp.class)
    protected void pickedUpItem(ItemPickedUp event) {
        // If adreanaline is full, start combo, so that we can collect more
        tabooItems.add(items.getItem(event.getId()), 60);
    }
    
    private void collectNextItem() {
        currentNavPoint = getNavigation().getNearestNavPoint(bot);
        
        Item toCollect = getNearestPickableItem(currentNavPoint);
        if (toCollect == null) return;
        
        IPathFuture<NavPoint> path = getPathPlanner().computePath(bot, toCollect);
        getPathExecutor().followPath(path);
        
        tabooItems.add(toCollect, 180);  // Tabooize item automatically. 
        targetItem = toCollect;          // We would do so anyway   
    }
        
    private Item getNearestPickableItem(NavPoint whereFrom) {
      Map<UnrealId, Item> allItems = items.getAllItems();
      Set<Item> spawnedItems = tabooItems.filter(allItems.values());
       
      if (spawnedItems.isEmpty()) {
         body.getCommunication().sendGlobalTextMessage("Damn, nothing to collect, 
                                                        what now!?");
         waitForItems.use();  // Don't try again in some time
         return null;
      }
        
      float closestDist = Float.MAX_VALUE;
      Item closestItem = null;
      for (Item it: spawnedItems) {           
         if (fwMap.getDistance(whereFrom, it.getNavPoint()) < closestDist) {
            closestDist = fwMap.getDistance(whereFrom, it.getNavPoint());
            closestItem = it;
         }
      }
        
        return closestItem;
    }
        
   // Called each time our bot die. Good for reseting all bot state dependent variables.
   @Override
   public void botKilled(BotKilled event) {
       navigation.stopNavigation();        
       currentNavPoint = null;
       tabooItems.clear();  // Clear the taboo set of items because now the bot can 
                             // collect e.g. health again.
   }
    
   . . . 
        
    
}
             

5. Considerações

O Pogamut, como arquitetura cognitiva, tem seu foco em em construções de modelos cognitivos envolvendo sistemas de memória episódica e memória espacial. Os fundamentos dos conceitos adotados pela arquitetura Pogamut são os mesmos de propostas como o Soar, CLARION e ACT-R. O Pogamut, como proposta de modelo cognitivo, não desfende nenhum posicionamento diferenciado, como é feito no LIDA e CERA-CRANIUM que são propostas de arquiteturas do modelo cognitivo GWT que defende o conceito de "consciência" (ou do "processo consciente") sob a perspectiva da cognição. Por outro lado,  como middleware, o Pogamut, aparentemente, parece ser um dos poucos que permite integrar diferentes propostas de arquiteturas ao seu framework. Também parece ser um dos poucos que integra ao seu arcabouço, com menção explícita, ferramentas de produção comercial (p.ex., o UDK). Essa é uma característica interessante para o uso do Pogamut como plataforma de aprendizagem: o fato de "estar integrado" a plataformas "profissionais de produção" - algo que motiva, cria o engajamento, o estudante a explorar os conceitos subjacentes as arquiteturas cognitivas (não só da arquitetura Pogamut, já que serve também de middleware). 

Referência Bibliográfica

[ Anderson ] Anderson, J. R. How can the human mind occur in the universe? Oxford University Press, 2009.

[ Arrabales] Arrabales, R. e Muñoz, J. Conscious-like bot wins the 2K bot prize. ERCIM News, 2011. Edição online: pp. 34-35 em [ pdf ].

[ Brom ] Brom, C., Pešková, K. e Lukavský, J. What does your actor remember? Towards characters with a full episodic memory. LNCS 4871, pp. 89–101, 2007. Veja artigo [ aqui ].

[ Byl ] Byl, P. B. Programming believable characters for computer games. Charles River Media Game Development, 2004. Veja o capítulo 1  [ aqui ].

[ Gemrot (a) ] Gemrot, J.,  Kadlec, R., et all.  Pogamut 3 can assist developers in building AI for their videogame agents. Proceedings of the First International Workshop on Agents for Games and Simulations, 2009. Veja artigo [ aqui ]

[ Gemrot (b) ] Gemrot, J.,  Kadlec, R., et all. Pogamut 3 can assist developers in building AI (not only) for their videogame agents. Lecture Notes in Computer Science Volume 5920, 2009, pp 1-15. Veja artigo [ aqui ].

[ Laird ] Laird, J. E. e van Lent, M. Human-level AI's killer application Interactive computer games. AI Magazine Vol. 22, Num.2, 2001. Veja artigo [ aqui ]

[ Schrum ] Schrum, J., Karpov, I. V. e Miikkulainen, R.  UTˆ2: Human-like behavior via neuroevolution of combat behavior and replay of human traces. Proceedings of the IEEE Conference on Computational Intelligence and Games, pp.: 329--336, 2011. Veja artigo [ aqui ]

[ Thawonmas ] Thawonmas, R., Murakami, S. e Sato, T. Believable judge bot that learns to select tactics and judge opponents. IEEE, 2011. Veja artigo [ aqui ]