Eaters
Eaters é um jogo do estilo Pac Man onde eaters são movimentados por um mapa bi-dimensional no qual há alimento, paredes e eaters. Um eater pode se mover para norte, sul, leste ou oeste e pular uma parede ou outro eater. Se um eater se mover para um quadrado ocupado por um alimento, ele 'come' o alimento e ganha os pontos fornecidos por este alimento. Se ele colide com outro eater a pontuação de ambos passa a valer a média de suas pontuações e ambos são teleportados para célular aleatórias no mapa.
No pacote do SOAR são fornecidos uma interface gráfica e arquivos .soar para diferentes comportamentos dos eaters. Nesta interface, pode-se criar eaters, carrega-los com diferentes comportamentos e executar a simulação. Quando um novo Eater é criado, é possível atrela-lo a um Soar Debugger para inspecionar seu funcionamento.
Uma configuração inicial do ambiente com um eater e a janela de debugger é exibida abaixo. A seguir, uma imagem da execução do comportameto move-to-food.soar fornecido pelo tutorial.
Como previsto pelo tutorial, o agente chega a um momento em que o agente entra em um loop onde não é capaz de selecionar operadores para alterar seu estado e cria sub estados indefinidamente. Isso ocorre por causa da forma como move-to-food é implementado (um eater só se move se há comida imediatamente adjacente a ele.
Uma execução passo a passo com nível de watch em 5 exibe as seguintes características:
1) Fase de input:
Lendo-se o log de baixo para cima (pela ordem de execução das ações) vemos que existem:
- um objeto E2 com atributos x, y, score e name: representa o eater
- um objeto I2 com atributos eater, random e my-location: este é o input-link do atributo io do estado. É onde o estado do mundo é percebido.
- ao o objeto my-location, são associados objetos north, south, east e west: as céluas adjacentes a my-location.
- para cada uma das células adjacentes, criam-se seus próprios objetos north, south, east e west de forma aparentemente recursiva enquanto a nova célula a ser criada estiver dentro do campo de visão do eater, a uma distância de duas células de my-location.
- depois que todas as células percebidas são criadas, são associados atributos content com os valores wall, normalfood, bonusfood ou eater
- no caso de ser um eater, também é associada a propriedade content-name
Abaixo, screenshots do detalhamento do debugger que permitiu estas deduções. Na imagem da esquerda, vê-se o caráter aparentemente recursivo da criação das céluas e limitado a uma distância de duas células (indo para oeste a partir de M1 temos M1 => W1 => W2 e W2 não possui propriedade west)
Fase de proposição
Agentes do tipo move-to-food propõe operadores para movimentação para norte, sul, leste ou oeste quando a respectiva célula nesta posição contem um alimento.Esta dedução foi feita através dos seguintes dados copiados do Soar Debugger:
--- propose phase --- Firing propose*move-to-food --> (O1 ^direction north +) (O1 ^name move-to-food +) (S1 ^operator O1 =) (S1 ^operator O1 +) | Operador para mover para o norte |
Firing propose*move-to-food --> (O2 ^direction east +) (O2 ^name move-to-food +) (S1 ^operator O2 =) (S1 ^operator O2 +) | Operador para mover para o leste |
Firing propose*move-to-food --> (O3 ^direction west +) (O3 ^name move-to-food +) (S1 ^operator O3 =) (S1 ^operator O3 +) | Operador para mover para o oeste |
=>WM: (138: S1 ^operator O3 +) =>WM: (137: S1 ^operator O2 +) =>WM: (136: S1 ^operator O1 +) =>WM: (135: O3 ^direction west) =>WM: (134: O3 ^name move-to-food) =>WM: (133: O2 ^direction east) =>WM: (132: O2 ^name move-to-food) =>WM: (131: O1 ^direction north) =>WM: (130: O1 ^name move-to-food) | As mudanças que ocorreram na Working memory |
Percebe-se que não foi proposta uma operação para mover o agente para o sul. Isto ocorreu por causa da configuração das células percebidas pelo agente. Como se pode ver na figura a seguir, na célula ao sul não há comida, só uma parede.