Guia de programação do VirtuALog

Transcrição

Universidade do Vale do Rio dos Sinos – UNISINOS
Guia do
VirtuALog 0.5
Programação de Agentes Virtuais 3D em Prolog
João Carlos Gluz – Abril de 2015
Pós-Graduação em Computação Aplicada - PIPCA
VirtuALog – Programação de Agentes Virtuais 3D em Prolog
João C. Gluz
Sumário
1. Introdução.........................................................................................................................................3
2. Inteligência para os NPCs................................................................................................................5
3. Arquitetura do VirtuALog................................................................................................................6
4. Instalação, Inicialização e Ajuda do VirtuALog...............................................................................8
5. Programação de Avatares no VirtuALog........................................................................................10
5.1. Antes de começar a programar................................................................................................10
5.2. Conexão com o avatar.............................................................................................................13
5.3. Observação do ambiente.........................................................................................................13
5.3.1. Observando as propriedades do próprio avatar...............................................................14
5.3.2. Observando as entidades do ambiente............................................................................14
5.3.3. Busca/localização de entidades no ambiente..................................................................15
5.4. Movimentação pelo ambiente.................................................................................................16
5.4.1. Movendo o avatar de posição..........................................................................................16
5.4.2. Movendo a disposição do corpo do avatar......................................................................17
5.4.3. Alterando o modo de movimentação...............................................................................18
5.5. Comunicação com outros avatares e agentes..........................................................................18
5.6. Ações sobre o ambiente..........................................................................................................19
5.7. Ações sobre o próprio avatar..................................................................................................20
5.8. Percepções do Avatar..............................................................................................................22
5.8.1. Consultas à base de percepções.......................................................................................23
5.8.2. Percepção das propriedades............................................................................................25
5.8.3. Percepções de eventos.....................................................................................................29
6. Um Exemplo de Programação: Feira de Ciências Virtual..............................................................31
BIBLIOGRAFIA................................................................................................................................36
2
João C. Gluz
1. Introdução
Um ambiente virtual imersivo 3D simula um ambiente ou cenário tridimensional de forma a recriar
um mundo baseado em determinadas regras (físicas, lógicas, geométricas, etc.) fazendo com que
seres humanos interagindo em tais ambientes percebam uma pseudo-realidade que pode ser bem
próxima da realidade em termos visuais [Kumar et al., 2008; Messinger et al., 2009]. Tais ambientes
podem se tornar meios de interação digital realistas, criativos e dinâmicos, e com um amplo
potencial lúdico e pedagógico para fins educacionais. Isso inclui, desde aplicação de simuladores e
cenários simulados, passando por laboratórios virtuais (interfaceados ou não com equipamentos
reais) e chegando em jogos sérios e comunidades sociais mediadas pelo ambiente 3D. A realidade
virtual tridimensional imersiva também é a forma de interação dos jogos de maior sucesso
atualmente. Assim como a interação através das novas mídias digitais de redes sociais, a interação
em realidade virtual tridimensional em jogos é parte da lingua franca digital de boa parte, senão da
maioria, da população jovem atual. Este fator torna ainda mais interessante a perspectiva de utilizar
ambientes virtuais imersivos 3D em educação, não apenas pelos aspectos lúdicos e realistas, mas, se
devidamente concebido, pela atratividade e facilidade de uso que este tipo de ambiente oferece para
uma ampla parte da população jovem e em idade escolar.
Além dos elementos que simulam objetos físicos, um mundo virtual contém diferentes tipos de
agentes externos ao simulador, mas capazes de controlar suas representações internas no simulador,
usualmente denominadas de avatares. Além de agentes humanos externos, que no caso de mundos
virtuais educacionais poderiam incluir personagens como estudantes, professores, monitores, etc.,
também é possível incluir agentes artificiais externos no mundo virtual. Tais tipos de agentes são
comumente denominados de robôs virtuais, bots ou NPCs (do inglês, "Non Player Characters").
O controle de um NPC está efetivamente a cargo de um agente artificial ou agente de software
[Weiss, 2013]. Embora várias definições tenham surgido para os agentes artificiais, há uma
definição em particular que se firmou em trabalhos mais recentes [Bordini, et al. 2007; Wooldridge,
2009; Weiss, 2013] e que é a utilizada neste trabalho: um agente artificial é um sistema
computacional, situado em um determinado ambiente, que é capaz de executar ações de forma
autônoma, a fim de satisfazer seus objetivos. Os agentes individuais de um dado sistema
multiagente podem ser projetados e desenvolvidos de várias formas distintas.
O ambiente de programação VirtuALog permite a construção de agentes animados pedagógicos,
que podem operar como NPCs em mundos virtuais compatíveis com o OpenSimulator ou o
SecondLife. O ambiente VirtuALog estende a linguagem Prolog, incluindo mecanismos de
programação de agentes inteligentes, que seguem o modelo BDI (do inglês, “Belief – Desire –
Intention”), e de comunicação entre agentes, além de suportar a execução de ações e a detecção de
percepções em mundos virtuais tridimensionais.
3
João C. Gluz
IMPORTANTE:
(a) O VirtuALog é um ambiente experimental, ainda em processo de evolução e que pode passar
por novos desenvolvimentos e melhorias, com modificações significativas nas operações descritas
neste guia. Isso é válido tanto para o próprio código do VirtuALog, quanto de seus subsistemas
componentes, como o AgentLog, JavaLog e MonoLog.
(b) A versão atual do ambiente VirtuALog e seus subsistemas componentes está disponibilizada
sob licença GNU LGPL e pode ser utilizada para desenvolvimento de aplicações experimentais
para fins de pesquisa, por exclusiva conta e risco dos pesquisadores interessados. Assim, não existe
nenhuma garantia dos implementadores do VirtuALog e seus subsistemas componentes de que
essas aplicações possam ser utilizadas para fins de pesquisa ou em modo de produção, para fins
comerciais ou não. Também não há nenhuma garantia dos implementadores do VirtuALog e seus
subsistemas componentes que as funcionalidades e operações descritas neste guia funcionem sem
problemas ou que não tenham erros.
(c) De nenhuma forma os implementadores do VirtuALog e seus subsistemas componentes podem
ser julgados culpados de qualquer dano direto, indireto, incidental, colateral, especial ou
consequente por qualquer tipo de uso do VirtuALog e seus subsistemas componentes, mesmo se
avisados da possibilidade de ocorrência de algum tipo de dano.
(d) De qualquer forma, aceitamos quaisquer contribuições e sugestões que possam ajudar a corrigir
erros, melhorar a qualidade do VirtuALog ou trazer novas funcionalidades e features importantes
para este ambiente.
O uso do VirtuALog ou seus subsistemas componentes para o desenvolvimento de qualquer tipo
de aplicação implica na reconhecimento e aceitação das cláusulas (a), (b), (c) e (d) declaradas
acima.
4
João C. Gluz
2. Inteligência para os NPCs
A complexidade crescente das aplicações computacionais, tem levado ao surgimento de novos
modelos de projeto e desenvolvimento de sistemas de computação, dentre eles o modelo baseado
em agentes. A tecnologia de agentes tem adquirido nos últimos anos uma importância cada vez
maior em muitos aspectos da computação, principalmente na área de Inteligência Artificial
Distribuída (IAD) que é formada pela intersecção entre as áreas de Inteligência Artificial e
Computação Distribuída.
A área de Inteligência Artificial tem alcançado grandes progressos desde a década de 1970. Vários
métodos de resolução de problemas, planejamento de ações e mecanismos de aprendizagem foram
propostos, testados, analisados e utilizados [Russel e Norvig, 2010]. Uma característica que se
tornou comum nestes desenvolvimentos é a utilização de uma metáfora de computação baseada no
comportamento de um ser humano como um agente inserido em um ambiente: um agente que
percebe fatos e eventos, raciocina, planeja e toma decisões, age sobre o ambiente e interage com
outros agentes, além de buscar aprender novos conhecimentos e habilidades [Russel e Norvig,
2010].
O modelo de agentes surge como um paradigma integrador dessas tecnologias. Além disso, o
modelo de arquitetura de uma aplicação orientada a agentes é tipicamente distribuído em um
conjunto de agente, formando um Sistema Multiagente. Os Sistemas Multiagente são caracterizados
pela comunicação e, ao menos em termos da IAD, cooperação entre diversos agentes que interagem
em busca de um objetivo, que pode ser comum a todos.
Dessa forma, no VirtuALog assume-se que o controle de um NPC está efetivamente a cargo de um
agente artificial ou agente de software [Weiss, 2013]. Muito embora várias definições tenham
surgido para os agentes artificiais inteligentes ou não, há uma definição em particular que se firmou
em trabalhos mais recentes [Bordini, et al. 2007; Wooldridge, 2009; Weiss, 2013] e que é a utilizada
no VirtuALog: um agente artificial é um sistema computacional, situado em um determinado
ambiente, que é capaz de executar ações de forma autônoma, a fim de satisfazer seus objetivos. Na
figura abaixo, é ilustrado um agente e sua interação com o ambiente em que está inserido.
Figura 1: Conceito de agente [Wooldridge, 2009].
Um agente inteligente é um refinamento de um agente de software. Um agente inteligente é
basicamente um agente de software com capacidade de inteligência, podendo ser definido como um
agente com percepção dinâmica do ambiente e capacidade de representação de conhecimento e
raciocínio (inferência) para interpretação das percepções, planejamento e decisão das ações
5
João C. Gluz
autônomas que deverão ser feitas para cumprir o seu objetivo, além da avaliação dos resultados
dessas ações [Wooldridge, 2009].
Agentes individuais de um dado sistema multiagente podem ser projetados e desenvolvidos de
várias formas distintas. Uma arquitetura de agentes individuais bastante difundida, é baseada em um
modelo de agente racional com atitudes mentais de crença, desejo e intenção (modelo BDI, do
inglês "Belief-Desire-Intention") [Bordini et al., 2007]. O modelo BDI representa uma arquitetura
cognitiva para agentes inteligentes, baseada em estados mentais, e tem sua origem no modelo de
raciocínio prático humano [Bratman et al, 1988]. O nome atribuído ao modelo é justificado pelos
seus estados mentais: crença, desejo e intenção (belief, desire and intention). Uma arquitetura
baseada no modelo BDI representa seus processos internos através dos estados mentais acima
citados, e define um mecanismo de controle que seleciona de maneira racional o curso das ações
[Rao, A.S.; Georgeff, M., 1991].
Importante:
Detalhes específicos sobre como programar agentes BDI em Prolog e sobre como organizar
Sistemas Multi-Agente (SMA) formados por vários agentes trabalhando de forma cooperativa
[Weiss, 2013; Wooldridge, 2009] podem ser encontrados no Guia do AgentLog 0.5: Programação
de Agentes BDI em Prolog.
Este guia estará centrado em ensinar a programar agentes capazes de operar como NPCs de um
mundo virtual 3D, ou seja, como um agente BDI pode controlar um avatar em particular.
3. Arquitetura do VirtuALog
A Figura 2 mostra os principais componentes arquiteturais do VirtuALog.
Figura 2: Arquitetura do VirtuALog
A camada de Agentes Virtuais implementa as extensões de Prolog que permitem a criação de
agentes inteligentes como capacidade de ação em ambientes (mundos) tridimensionais simulados.
Tais extensões são oferecidas na forma operadores e predicados Prolog. O componente principal
dessa camada é o sistema VirtuALog que gerencia a conexão do agente Prolog com seu
6
João C. Gluz
correspondente avatar situado em um mundo virtual rodando em um simulador. Este sistema está
integrado a dois outros subsistemas:
•
Subsistema SymPAL (Symbolic Perception-Action Logic) que provê a interface lógica
para as ações e percepções do avatar no ambiente 3D.
•
Subsistema AgentLog (Agent Programming in Prolog) que implementa a extensão
BDI do Prolog para manipular crenças e objetivos, além de prover o serviço de
comunicação simbólica inter-agentes e o serviço de paralelismo por threads para
cada agente. Essas extensões transformam Prolog em uma linguagem de
programação baseada no modelo BDI, similar à linguagem AgentSpeak(L) [Bordini
et al., 2007]).
A camada de Interoperação gerencia a interface de programação das linguagens (e máquinas
virtuais) Java e Mono/C#. A biblioteca JPL [Singleton et al., 2015] é formada por uma API
(Application Programming Interface) de mais de 30 predicados Prolog que implementam os
serviços de interoperação de baixo-nível provendo o acesso as classes, métodos e objetos de Java. O
módulo JavaLog foi desenvolvido especificamente para a camada de Agentes Virtuais e gerencia a
interoperação com Java apenas com o operador '::' que permite além da criação e instanciação de
objetos de Classes Java, o acesso a todos os métodos e variáveis públicas da classe.
A biblioteca SWICLI [Miles, 2015] é similar a biblioteca JPL, fornecendo os serviços de acesso de
baixo nível para as classes, métodos e objetos da linguagem C#/Mono. O módulo MonoLog
implementa o operador '#' com as mesmas funcionalidades do operador '::' do módulo JavaLog,
apenas que agora aplicadas as classes e objetos C#/Mono.
A Figura 3, mostra exemplos de código Prolog utilizando essa interface de interoperação de altonível.
join_to_running_comm_platform :% Obtem a instancia unica da JADE runtime
'jade.core.Runtime' :: instance([]) => Runtime,
% Cria o container dos agentes Prolog
new :: 'jade.core.ProfileImpl'([]) => Profile,
Profile :: setParameter(
['container-name','PrologAgentsContainer']),
Runtime :: createAgentContainer([Profile]) =>
ContainerController,
assert(prologAgentsContainer(
ContainerController)).
:- using # 'OpenMetaverse',
using # 'VirtuaLogClient'.
connect_avatar(Agid,First,Last,Pass,URL) :\+ avid(Agid,_),
'OpenMetaverse.VirtuaLogClient.ClientManager'
# 'Instance' => CMI, ,
new # array(string,[First,Last,Pass,URL]) =>
Args,
CMI # do_login([Args]) => Avid,
assert(avid(Agid, Avid)).
(a) Examplo de código Prolog utilizando JavaLog
(b) Examplo de código Prolog utilizando MonoLog
Figura 3: Exemplos de código Prolog com interoperação em Java (a) e Mono/C# (b)
O painel (a) da Figura 3 apresenta um pequeno trecho de código do módulo AgentLog, que
estabelece a conexão com uma plataforma Jade que já esteja em execução. Neste exemplo pode-se
ver a utilização do operador '::' para para acesso a métodos públicos estáticos ( 'jade.core.Runtime'
:: instance([])) ou dinâmicos (Runtime :: createAgentContainer([Profile])) e também para a
criação de novos objetos (new :: 'jade.core.ProfileImpl'([])). O operador '=>' é uma extensão
funcional utilizada na camada de agents virtuais Prolog, retornando no lado direito deste operador o
valor do resultado da avaliação funcional do termo situado à esquerda do operador, quer seja uma
chamada de método Java ou Mono/C#. O exemplo do painel (b) foi retirado do módulo VirtuALog
e ilustra uma parte do processo de conexão (login) do agente Prolog ao avatar situado no simulador.
A forma de uso é muito similar ao exemplo Java, a maior diferença é o uso do operador '#' para
7
João C. Gluz
desempenhar na interoperação como Mono/C#, as mesmas funcionalidades do operador '::' para
Java.
A camada de Serviços is formada por um conjunto de bibliotecas e frameworks não pertencentes a
linguagem Prolog, que fornecem serviços necessários para as demais camadas do VirtuALog. Os
serviços de comunicação inter-agente utilizados pelo subsistema AgentLog são fornecidos pela
plataforma Jade [Bellifemine et al., 2007]. Essa plataforma foi desenvolvida em Java e
disponibiliza serviços de comunicação em nível de conhecimentos para agentes distribuídos em
uma rede local (essencialmente um cluster de agentes). Jade suporta a linguagem de comunicação
simbólica FIPA-ACL [FIPA, 2002], implementando todos os serviços de comunicação entre
agentes definidos pelo padrão FIPA (http://www.fipa.org). A classe PrologJadeAgent foi
desenvolvida em Java especificamente para suportar os os mecanismos de criação, instanciação e
comunicação de agentes necessários para o módulo AgentLog.
Os serviços de acesso e manipulação de mundos virtuais 3D utilizados pelo módulo SymPAL são
fornecidos pela biblioteca LibOpenMetaverse (http://libomv.sourceforge.net/). A biblioteca
LibOpenMetaverse, desenvolvida em C#/Mono, implementa o lado cliente do protocolo de
comunicação com um simulador compatível com o SecondLife, incluindo o simulador
OpenSimulator. A classe VirtuaALogClient, que foi desenvolvida em C#, implementa um cliente
OpenMetaverse capaz de se comunicar com um servidor OpenSimulator ou SecondLife remoto.
Esta classe é utilizada pela camada de agentes do Prolog para o estabelecimento de conexões com
avatares OpenSimulator/SecondLife (operações de login/logout) e para o acesso aos comandos e
informações de estado destes avatares.
4. Instalação, Inicialização e Ajuda do VirtuALog
A versão atual do ambiente VirtuALog foi implementada no sistema operacional Linux sobre o
SWI-Prolog. Assim as instruções a seguir são direcionadas para instalação do VirtuALog apenas
para este tipo de sistema operacional e para essa implementação do Prolog.
Para sua execução o VirtuALog necessita de uma instalação do SWI-Prolog, versão 6.6.4 ou
superior. É necessário que estejam instalados o suporte à integração Java e a integração C#/Mono
no SWI-Prolog.
O suporte de baixo nível para a integração do Java ao SWI-Prolog é implementado pela biblioteca
JPL que deve ser instalada em conjunto com o SWI-Prolog. No SWI-Prolog para a distribuição
Ubuntu do sistema Linux, existe um pacote denominado de swi-prolog-java que já contém a
biblioteca JPL, porém em outras distribuições do SWI-Prolog é necessário descobrir como instalar o
JPL.
De forma semelhante o suporte de baixo nível para a integração do C#/Mono ao SWI-Prolog é
implementado pela biblioteca SWICLI. Porém, diferente da JPL, a biblioteca SWICLI não está
integrada nas distribuições do SWI-Prolog. Para resolver esse problema, o arquivo contendo a
distribuição do VirtuALog incorpora os arquivos fonte e os arquivos compilados da versão 1.0.2 da
biblioteca SWICLI no subdiretório swicli-1.0.2. Para instalar a biblioteca SWICLI no SWI-Prolog
pode se utilizar o arquivo shell script install-linux.sh localizado no subdiretório swicli-1.0.2. Esse
arquivo shell define onde está localizado o diretório de instalação do SWI-Prolog pela variável de
ambiente SWI_HOME_DIR:
SWI_HOME_DIR=/usr/lib/swi-prolog
8
João C. Gluz
Caso o SWI-Prolog esteja localizado em outro diretório, ou com uma distribuição que não utilize os
diretório $SWI_HOME_DIR/lib/i386-linux/ para armazenar as bibliotecas de 32 bits, ou os
diretórios $SWI_HOME_DIR/lib/x86_64-linux/ ou $SWI_HOME_DIR/lib/amd64/ pra armazenar as
bibliotecas de 64 bits, então a instalação do SWICLI deve ser feita manualmente. O subdiretório
swicli-1.0.2/lib/i386-linux contém a versão de 32 da biblioteca SWICLI e o subdiretório swicli1.0.2/lib/amd64 contém a versão de 64 bits da biblioteca SWICLI. Tais arquivos devem ser
instalados no diretório apropriado do diretório $SWI_HOME_DIR/lib/ do SWI-Prolog. O
subdiretório swicli-1.0.2/bin contém os arquivos Swicli.Library.dll e Swicli.Library.dll.config
independentes de tipo de arquitetura que devem ser instalados no diretório
$SWI_HOME_DIR/library/ do SWI-Prolog.
Para instalar o VirtuALog basta descompactar o arquivo virtualog-V.R.zip que contém a versão V
revisão R do ambiente VirtuALog. Este arquivo deve ser descompactado no diretório raiz do
usuário, criando o diretório virtualog-V.R.
O VirtuALog pode ser executado através do shell script runvirtualog.sh. Este shell script inicializa
as variáveis de ambiente necessárias para a execução do VirtuALog e depois executa o SWIProlog, consultando o virtualog.pl que carrega todo o ambiente do VirtuALog, além dos suportes à
interface de programação Java (javalog.pl) e programação C# (monolog.pl).
O arquivo runvirtualog.sh define a variável JRE_DIR, que deve indicar qual é o diretório do
ambiente de execução Java (JRE de Java Runtime Environment) a ser utilizado pelo AgentLog com
o seguinte valor:
JRE_DIR=/usr/lib/jvm/java-7-openjdk-amd64/jre
Se o ambiente de execução Java estiver instalado em outro diretório, então a variável JRE_DIR
deve ser atualizada de acordo.
Da mesma forma este arquivo também define a variável SWI_HOME_DIR com a localização do
diretório de instalação do SWI-Prolog:
SWI_HOME_DIR=/usr/lib/swi-prolog
Se o SWI-Prolog estiver instalado em outro diretório, então a variável SWI_HOME_DIR deve ser
atualizada de acordo.
A distribuição do VirtuALog já traz incluída uma distribuição da biblioteca JADE, na versão 4.3.1.
Se essa versão da JADE for utilizada para fins de comunicação então nada precisa ser alterado no
arquivo runvirtualog.sh. Porém se for utilizada uma outra versão então a variável CLASSPATH
definida no arquivo runvirtualog.sh precisa ser atualizada de acordo com o diretório onde está
contida essa outra versão da JADE.
Também está contida no diretório mono-3.12.1 da distribuição do VirtuALog a versão 3.12.1 já
compilada da biblioteca Mono de suporte ao C# no Linux. É essa versão da Mono que deve ser
utilizada pelo VirtuALog., tal como configurado no arquivo runvirtualog.sh.
A interface de comunicação do VirtuALog com o simulador 3D compatível com o OpenSimulator é
implementada com o auxílio da biblioteca LibOpenMetaverse. Para tanto foi desenvolvido um
programa cliente dessa biblioteca, o programa VirtuaLogClient, que é fornecido em conjunto com a
versão 0.9.2 da biblioteca LibOpenMetaverse, contida no diretório libopenmetaverse-0.9.2 da
distribuição do VirtuALog.
Se tudo estiver configurado corretamente no arquivo runvirtualog.sh, o VirtuALog estará
carregado e pronto para a execução quando aparecer o prompt do interpretador Prolog.
9
João C. Gluz
Pode-se consultar quais os agentes VirtuALog que estão em execução em um dado momento
através da chamada ao predicado agentlog_agents, que listará quais agentes estão em execução.
Importante:
A ajuda aos predicados e operações implementados pelo VirtuaALog pode ser obtida através do
predicado vhlp. Este predicado pode ser chamado sem argumentos, listando, então, os predicados e
operações do VirtuALog. O predicado de ajuda também pode ser chamado na forma vhlp(Opt)
onde a opção Opt indica um predicado ou operação que se deseje obter informações.
5. Programação de Avatares no VirtuALog
O ambiente de programação VirtuALog permite a construção de agentes inteligentes, que podem
operar como NPCs ou bots em mundos virtuais compatíveis com o OpenSimulator ou o SecondLife.
Este ambiente estende a linguagem Prolog, incluindo além dos serviços de programação de agentes
BDI (implementados pelo subsistema AgentLog), predicados e operações que permite a execução de
ações e a detecção de percepções em mundos virtuais tridimensionais. O VirtuALog também
gerencia a conexão do agente Prolog com o seu avatar em um determinado mundo virtual
executando em um simulador.
Entretanto, para que se possa começar a programação do agente Prolog que irá controlar um dado
avatar é necessário que este avatar tenha ter sido previamente registrado no mundo virtual com um
nome e senha específicos.
As seções a seguir mostram como se pode programar um agente VirtuALog para controlar um avatar
que tenha sido previamente registrado.
5.1. Antes de começar a programar
Um agente Prolog pode controlar um avatar em um mundo virtual 3D. O VirtuALog suporta
apenas uma conexão um-para-um entre agente e avatar, ou seja, um avatar pode se conectar e
controlar diretamente apenas um avatar do mundo virtual. Se uma aplicação utiliza mais de um
avatar, então terão que ser utilizados agentes distintos, um para cada avatar.
O avatar que será conectado ao agente deve ter sido previamente registrado no mundo virtual. Com
as informações de nome e senha de acesso do avatar, o agente Prolog pode se conectar e iniciar o
controle do avatar.
Após o estabelecimento da conexão está disponível a interface lógica para as ações e percepções do
avatar através interface da interface lógica SymPAL - Symbolic Perception-Action Logic). A SymPAL
implementa o acesso às ações do avatar através do operador ':>', enquanto que percepções do avatar
podem ser consultadas pelo operador '<:'. Tanto as ações quanto as percepções são expressas através
de fórmulas lógicas definidas pela ontologia do VirtuALog.
As ações podem ser executados no avatar através do operador ':>' aplicado sobre uma das ações
possíveis de serem executadas pelo avatar. Uma ação é executada através de uma consulta no
formato:
:> Action.
onde Action é um termo Prolog que identifica uma das ações possíveis de serem executadas pelo
10
João C. Gluz
avatar.
Quando a invocação do operador de execução de ação tem sucesso isso implica que a ação foi bem
sucedida, pelo menos de acordo com as informações disponíveis à biblioteca LibOpenMetaverse,
que solicitou a execução da ação ao simulador. Algumas ações também retornam informações que
podem ser obtidas através do operador funcional '=>'. Este operador pode ser aplicado ao fim da
operação de execução em consultas Prolog no formato:
:> Action => Results.
onde Action é uma ação e Results uma variável que irá conter o resultado da execução da ação. Note
que as ações podem resultar em vários resultados, assim Results é uma lista Prolog contendo esses
resultados. Se a ação não retorna nenhum resultado, então Results será a lista vazia [].
As ações que podem ser executadas pelos avatares foram classificadas nas categorias de
movimentação, observação, comunicação modificação e pessoais (ver Figura 4).
•
A categoria de movimentação inclui as várias ações que solicitam ao avatar se mover de
posição no simulador, assim como modificar sua disposição física (estar sentado, direcionarse a algum outro avatar, etc.).
•
A categoria de observação inclui ações que permitem obter informações a respeito do avatar,
além de informações sobre outros objetos e avatares situados no ambiente.
•
Na categoria de modificação estão incluídas as ações que alteram propriedades do ambiente,
possibilitando a criação de novos objetos, movimentação e rotação de objetos no ambiente,
além das alterações das dimensões, cores e texturas desses objetos se isso for permitido ao
avatar .
•
Na categoria de ações pessoais as ações que modificam aspectos do avatar, como a sua
roupa e características físicas. Essas ações também permitem
•
A categoria de interação inclui as operações que permitem a comunicação com outros
avatares, incluindo participação em grupos. As ações dessa categoria permitem o
gerenciamento dos relacionamentos de amizades e grupos onde está inserido.
Figura 4: Categorias de Ações
Não foram implementados na atual versão do VirtuALog ações de gerência de bens e
transferências financeiras.
Através das ações de observação é possível perceber quais são as entidades existentes no ambiente
(ver Figura 5). Os tipos de entidades que podem ser percebidos em um mundo virtual e que
11
João C. Gluz
possuem identificadores únicos (UID) que os distinguem uns dos outros são os seguintes: avatares,
objetos físicos que podem ser primitivos ou compostos, bens, regiões, lugares, grupos, papéis e
texturas. Mais detalhes sobre essas entidades podem ser obtidos nas seção 5.8.
Figura 5: Categorias de entidades percebidas no ambiente
As ações de observação alteram o estado das percepções do agente, modificando a base de
percepções do agente a respeito do estado do agente ou do ambiente que o cerca. O resultado da
execução de qualquer uma das operações de observação é uma lista de percepções a respeito do
ambiente que é automaticamente adicionada na base de percepções do agente. Percepções, como
recepções de mensagens, alertas de colisões, mudanças de região, também são geradas de forma
automática pelo simulador do mundo virtual e armazenadas na base de percepções.
A base de percepções está incluída na base de crenças do agente, porém, diferente das demais
crenças, as percepções são armazenadas com um registro de tempo da sua ocorrência. Este registro
pode ser utilizado para consultar as percepções que foram observadas em um dado período de
tempo. Caso a informação de horário não seja informada, as consultas às percepções retornam a
última percepção registrada pelo agente. O subsistema VirtuALog também implementa um
mecanismo que elimina percepções antigas, após um dado período de tempo que pode ser
configurado pelo programador.
Consultas à base de percepções são feitas com o operador '<:' aplicado a um termo que representa
uma percepção. Uma consulta à base de percepções tem o seguinte formato:
<: Percept.
onde Percept é um termo Prolog usado como filtro das percepções que se quer recuperar da base de
percepções. Opcionalmente pode-se utilizar o operador '@@' em conjunto com o operador de
consulta de percepções pode-se obter o tempo em que a percepção foi registrada na base de
percepções. Assim uma consulta no formato:
<: (Percept) @@ Time
12
João C. Gluz
onde Percept é um filtro de percepções e Time uma variável, obter em Time o tempo em que a
percepção foi registrada na base de percepções (para mais detalhes veja a seção 5.8).
5.2. Conexão com o avatar
A conexão do agente com o avatar é realizada através da chamada ao predicado:
connect_avatar(First, Last, Pass, URL)
onde First e Last são o nome e sobrenome do avatar registrado no simulador, Pass sua senha e URL
o endereço de rede do simulador que pode estar na Internet, rede local ou no próprio computador
local. A chamada para este predicado deve ser realizada dentro de uma das threads do agente que irá
controlar o avatar. Caso a chamada seja feita fora das threads do agente, então pode-se utilizar o
predicado:
connect_avatar(Agid, First, Last, Pass, URL)
onde o argumento extra Agid é o identificador do agente no interpretador Prolog.
Após o estabelecimento da conexão está disponível a interface lógica para as ações e percepções do
avatar (interface SymPAL - Symbolic Perception-Action Logic). Ações podem ser executados no
avatar através do operador ':>'. Quando a invocação deste operador tem sucesso isso implica que a
ação foi bem sucedida, pelo menos de acordo com as informações disponíveis à biblioteca
LibOpenMetaverse, que solicitou a execução da ação ao simulador. Algumas ações também
retornam informações que podem ser obtidas através do operador funcional '=>'.
Para finalizar a conexão com o avatar, basta executar a chamada do predicado:
disconnect_avatar
sem argumentos, dentro de uma das threads do agente que está controlando este avatar ou chamar
disconnect_avatar(AgId), onde AgId é o identificador do agente que está controlando o avatar.
5.3. Observação do ambiente
A categoria de observação inclui ações que permitem obter informações a respeito do avatar, além
de informações sobre outros objetos e avatares situados no ambiente. As observações estão
relacionadas aos diversos tipos de entidades que podem existir em um mundo virtual 3D (ver as
seção 5.8 e para mais detalhes a respeito da ontologia que o VirtuALog usa para organizar essas
entidades).
O resultado de uma ação de observação pode ser recuperado através do operador '=>' aplicado à
execução da operação. O resultado é retornado sempre em uma lista. Por exemplo, a operação
look(my_pos) recupera a posição corrente do avatar, retornando essa posição em um termo com o
formato pos(X,Y,Z), que é o único termo retornado na lista de resultados dessa ação. Assim uma
expressão como:
:> look(my_pos) => [pos(X,Y,Z)].
compara (unifica) o resultado da operação look(my_pos) uma uma lista que contém apenas o termo
pos(X,Y,Z). Isso fará com que os variáveis X,Y,Z seja unificadas com os valores das coordenadas
X,Y,Z da posição do avatar.
Os resultados das ações de observação são sempre armazenados na base de percepções do agente,
devidamente registradas com a informação do instante de tempo em que ocorreu a
13
João C. Gluz
observação/percepção.
As observações estão divididas em três subcategorias: observações de entidades relacionadas ao
próprio avatar, observações de entidades ambiente e busca por entidades no ambiente. As ações de
cada subcategoria são descritas a seguir.
5.3.1. Observando as propriedades do próprio avatar
A Tabela 1 a seguir define as ações que permite observar as propriedades relacionados ao próprio
avatar.
Tabela 1: Ações de observação do próprio avatar
Ação
Descrição
look_my(loc)
Obtém a localização atual do avatar na forma loc(R,X,Y,Z), onde R identifica o nome da
região e X,Y,Z a posição dentro da região.
look_my(pos)
Obtém a posição atual do avatar na forma pos(X,Y,Z)
look_my(region)
Obtém o identificador da região onde o avatar está localizado e várias propriedades a
respeito dessa região. Os termos retornados tem os formatos: UID:region ou
UID:region_property(Value), onde UID é o identificador único da região, region_property
é um átomo que identifica alguma propriedade da região e Value um termo com o valor da
propriedade.
look_my(inventory)
Obtém informações a respeito dos itens contidos no inventário de bens do avatar. Os
termos retornados tem o formato: UID:folder, UID:folder_property(Value), UID:item ou
UID:item_property(Value), onde UID é o identificador único de um diretório (folder) ou
item do inventário, folder_property e item_property são um átomos que identificam,
respectivamente alguma propriedade de diretório ou de item e Value um termo com o
valor da propriedade.
look_my(folder(Path))
Obtém informações a respeito de um diretório (folder) do avatar, cujo caminho é dado por
Path. Os termos retornados tem o mesmo formato de look_my(inventory).
look_my(item(Path))
Obtém informações a respeito de um item contido em algum diretório do avatar, cujo
caminho é dado por Path. Os termos retornados tem o mesmo formato UID:item ou
UID:item_property(Value) usados em look_my(inventory).
5.3.2. Observando as entidades do ambiente
A Tabela 2 a seguir define as ações que permitem observar as propriedades das entidades existentes
no ambiente.
Tabela 2: Ações de observação do próprio avatar
Ação
Descrição
look(height(X,Y))
Obtém a altura do terreno nas coordenadas X,Y em um termo na forma
height_at(X,Y,Z), onde Z é a altura do terreno nas coordenadas X,Y.
look(wind)
Obtém a velocidade do vento atual na região em um termo na forma wind_speed(S),
onde S é a velocidade do vento em metros/segundo.
look(avatar(UID))
Obtém propriedades a respeito de um avatar próximo identificado por UID. Os termos
retornados tem os formatos: UID:avatar ou UID:avatar_property(Value), onde UID é
o identificador único do avatar, avatar_property é um átomo que identifica alguma
propriedade do avatar e Value um termo com o valor da propriedade.
look(avatar(first(F),last(L)))
Obtém propriedades a respeito de um avatar próximo cujo nome é F e sobrenome L.
14
João C. Gluz
Os termos retornados tem o mesmo formato de look(avatar(UID)).
look(obj(UID))
Obtém propriedades básicas a respeito de um objeto próximo identificado por UID.
Os termos retornados tem os formatos: UID:obj ou UID:obj_property(Value), onde
UID é o identificador único do objeto, obj_property é um átomo que identifica
alguma propriedade do objeto e Value um termo com o valor da propriedade.
look(obj(UID), constrdata)
Obtém propriedades de construção visual de um objeto próximo identificado por
UID. Os termos retornados tem o mesmo formato de look(obj(UID)).
look(obj(UID), metadata)
Obtém os metadados de um objeto próximo identificado por UID. Os termos
retornados tem o mesmo formato de look(obj(UID)).
look(obj(UID), physdata)
Obtém propriedades físicas de um objeto próximo identificado por UID. Os termos
retornados tem o mesmo formato de look(obj(UID)).
look(light_obj(UID))
Obtém propriedades sobre a luz, se o objeto identificado por UID for um objeto do
tipo luz. Os termos retornados tem o mesmo formato de look(obj(UID)).
look(flex_obj(UID))
Obtém propriedades de flexibilidade, se o objeto identificado por UID for um objeto
flexível. Os termos retornados tem o mesmo formato de look(obj(UID)).
look(sculpt_obj(UID))
Obtém propriedades relacionadas a objetos do tipo sculpt, se o objeto identificado por
UID for um objeto desse tipo. Os termos retornados tem o mesmo formato de
look(obj(UID)).
look(asset(UID))
Obtém as propriedades de um dado bem (asset). Os termos retornados tem os
formatos: UID:asset ou UID:asset_property(Value), onde UID é o identificador único
do bem, asset_property é um átomo que identifica alguma propriedade do bem e
Value um termo com o valor da propriedade.
5.3.3. Busca/localização de entidades no ambiente
A Tabela 3 a seguir define as ações de busca/localização de entidades existentes no ambiente.
Tabela 3: Ações de busca de entidades
Ação
Descrição
look_for(avatars)
Procura por avatares que são visíveis ao avatar controlado pelo agente.s termos
retornados tem os formatos: UID:avatar ou UID:avatar_property(Value), onde UID é
o identificador único do avatar, avatar_property é um átomo que identifica alguma
propriedade do avatar e Value um termo com o valor da propriedade.
look_for(objs, R mt)
Procura por objetos existentes em um raio de R metros em relação a posição do avatar
controlado pelo agente. Os termos retornados tem os formatos: UID:obj ou
UID:obj_property(Value), onde UID é o identificador único do objeto, obj_property é
um átomo que identifica alguma propriedade do objeto e Value um termo com o valor
da propriedade.
look_for(objs, R mt, with(S))
Procura por objetos existentes em um raio de R metros em relação a posição do avatar
controlado pelo agente. O nome desses objetos deve conter o string S. Os termos
retornados tem o mesmo formato de look_for(objs, R mt).
look_for(agents)
Detecta avatares que parecem ser agentes artificiais ou bots (ou NPCs). Os termos
retornados tem o mesmo formato de look(avatar(UID)). Os termos retornados tem o
mesmo formato de look_for(avatars), exceto que os avatares retornados também terão
a propriedade UID:agent, indicando que são agentes.
look_for(attachs)
Busca pelos acessórios (attachments) atuais do avatar. Os termos retornados tem os
formatos: UID:attachment ou UID:attach_property(Value), onde UID é o
identificador único do acessório, attach_property é um átomo que identifica alguma
propriedade do acessório e Value um termo com o valor da propriedade.
15
look_for(regions)
João C. Gluz
Busca quais são as regiões existentes no simulador. Os termos retornados tem o
mesmo formato de look(obj(UID)). Os termos retornados tem os formatos:
UID:region ou UID:region_property(Value), onde UID é o identificador único da
região, region_property é um átomo que identifica alguma propriedade da região e
Value um termo com o valor da propriedade.
5.4. Movimentação pelo ambiente
A categoria de movimentação inclui as várias ações que solicitam ao avatar se mover de posição no
simulador, assim como modificar sua disposição física (estar sentado, direcionar-se a algum outro
avatar, etc.).
São exemplos desta categoria ações como: move_to(pos(X,Y,Z)), que solicita para o avatar se
movimentar para a posição pos(X,Y,Z) situada na região local, forward(N sec) e back(N sec), que
solicitam ao agente, respectivamente, mover-se para frente ou para trás por N segundos,
turn_to(pos(X,Y,Z)), que solicita ao avatar direcionar sua face para a posição pos(X,Y,Z); sit e stand
que solicitam que o avatar se sente ou que fique em pé, fly e nofly que ativam/desativam o modo de
vôo do avatar, além de tele_to(loc(R, X, Y, Z)) que solicita o teleporte do avatar para a posição
X,Y,Z na região R.
No exemplo de código a seguir, um agente se move da sua posição atual para uma nova posição,
depois verifica se há um avatar em um raio de 2 metros ao seu redor e caso isso seja verdadeiro,
orienta sua face para este avatar:
...
:> move_to(pos(110,220,34)),
:> look_for(avatars, 2 mt) => [avatar(UID)|_],
:> look(avatar(UID)) => Props,
member(UID:pos(X,Y,Z)), Props ),
:> turn_to(pos(X,Y,Z)),
...
A seguir são apresentadas as várias ações de movimentação que o avatar pode executar.
5.4.1. Movendo o avatar de posição
A Tabela 4 a seguir define as ações que permitem mover o avatar de posição e o modo como é feita
essa movimentação (caminhando, voando, teleporte).
Tabela 4: Ações de movimentação de posição
Ação
Descrição
move_to(pos(X,Y,Z))
Solicita para o avatar se movimentar para a posição X,Y,Z da região local.
tele_to(loc(R, X, Y, Z))
Solicita o teleporte do avatar para a posição X,Y,Z na região R.
tele_to(landmark(UID))
Solicita o teleporte do avatar para a landmark identificada por UID.
fly_to(pos(X,Y,Z))
Solicita que o avatar voe até a posição posição X,Y,Z situada na região local
fly_to(pos(X,Y,Z), N sec)
Solicita que o avatar voe até a posição X,Y,Z por um máximo de N segundos.
forward
Movimento mínimo para frente.
forward(N sec)
Movimento para frente por um período de N segundos.
forward(M mt)
Movimento para frente por pelo menos M metros.
16
back
Movimento mínimo para trás.
back(N sec)
Movimento para trás por um período de N segundos.
back(M mt)
Movimento para trás por pelo menos M metros.
left
Movimento mínimo para a esquerda.
left(N sec)
Movimento para a esquerda por um período de N segundos.
left(M mt)
Movimento para a esquerda por pelo menos M metros.
right
Movimento mínimo para a direita.
right(N sec)
Movimento para a direita por um período de N segundos.
right(M mt)
Movimento para a direita por pelo menos M metros.
João C. Gluz
Nas ações de movimentação que não indicam o modo de movimentação (move_to, forward, back,
left e right), se caminhando, andando ou correndo, a ação será executada no modo corrente.
Exemplos:
:>
:>
:>
:>
:>
move_to(pos(10,20,30)).
tele_to(loc(reg1, 10, 20, 30)).
forward(3 mt).
forward(3 sec).
left( 3 mt).
5.4.2. Movendo a disposição do corpo do avatar
A Tabela 5 a seguir define as ações que permitem mover a disposição do corpo do avatar, incluindo,
por exemplo, a orientação da face (e do corpo) em uma direção, ou se o avatar está sentado ou em
pé.
Tabela 5: Ações de orientação do corpo
Ação
Descrição
turn_to(pos(X,Y,Z))
Direciona a face do avatar para a posição X,Y,Z.
turn_to(avatar(UID))
Direciona a face do avatar para o avatar identificado por UID.
turn_to(obj(UID))
Direciona a face do avatar para o objeto identificado por UID.
turn_to(dir(N dg))
Direciona a face do avatar para a direção dada por N graus .
turn_to(dir(R))
Direciona a face do avatar para a direção dada por R radianos.
turn_to(dir(Dir))
Direciona a face do avatar para a direção com nome Dir. O valor de Dir pode ser: south,
north, east, west.
sit
Tenta sentar o avatar no objeto mais próximo.
sit_on(obj(UID))
Tenta sentar o avatar no objeto identificado por UID.
stand
Faz o avatar ficar em pé, se estiver sentado.
crouch
Solicita que o avatar se abaixe (ou se agache).
nocrouch
Solicita que o avatar se levante, se estiver abaixado (ou agachado).
Exemplos:
17
:>
:>
:>
:>
:>
:>
João C. Gluz
turn_to(pos(10,20,30)).
turn_to(avatar('179cdabd-398a-9b6b-1391-4dc333ba321f')).
turn_to(obj('bdacdabd-308a-9b6b-1291-4de334ba321f')).
turn_to(heading(45 dg)).
turn_to(heading(0.5)).
turn_to(dir(south)).
5.4.3. Alterando o modo de movimentação
A Tabela 6 a seguir define as ações que permitem alterar o modo de movimentação do avatar.
Tabela 6: Ações de alteração de estado de movimentação
Ação
Descrição
follow(avatar(First,Last)) Começa a seguir o avatar identificado pelo nome First e sobrenome Last.
follow(avatar(UID))
Começa a seguir o avatar identificado por UID.
nofollow
Para de seguir um avatar, se isto estiver ocorrendo.
jumping
Começa a executar saltos.
nojumping
Para de executar saltos.
jump
Executa um salto.
run
Faz o avatar em modo de movimentação terrestre por corrida.
norun
Faz o avatar sair do modo de movimentação terrestre por corrida.
fly
Faz o avatar entrar em modo de movimentação aérea (por voo).
nofly
Faz o avatar sair do modo de movimentação aérea (por voo).
walk
Faz o avatar em modo de movimentação terrestre por caminhada.
nowalk
Faz o avatar sair do modo de movimentação terrestre por caminhada.
Exemplos:
:>
:>
:>
:>
:>
:>
jump.
nojump.
sit.
fly.
nofly.
stand.
5.5. Comunicação com outros avatares e agentes
A Tabela 7 a seguir define as ações de comunicação do avatar.
Tabela 7: Ações de comunicação
Ação
Descrição
say(Txt)
Envia a mensagem de texto Txt ao canal de chat público com nível de áudio simulado
normal, alcança avatares em um raio de 10 a 20 metros..
say(Txt, Channel)
Envia a mensagem de texto Txt ao canal de chat identificado por Channel com nível de
áudio simulado normal. Channel é um valor numérico, 0 é o canal público.
shout(Txt)
Envia a mensagem de texto Txt ao canal de chat público com nível de áudio simulado alto
18
João C. Gluz
('grita' a mensagem), alcança avatares em um raio de 100 metros..
shout(Txt, Channel)
áudio simulado alto. Channel é um valor numérico, 0 é o canal público.
whisper(Txt)
Envia a mensagem de texto Txt ao canal de chat público com nível de áudio simulado
baixo ('sussura' a mensagem), alcança avatares em um raio de 5 metros.
whisper(Txt, Channel)
áudio simulado baixo. Channel é um valor numérico, 0 é o canal público.
Além das ações de comunicação que podem ser executadas com o operador ':>' específico da lógica
SymPAL, o ambiente VirtuALog também implementa novos atos comunicativos (tipos de
mensagem) que podem ser utilizados pelas operações de envio ('>>') e recepção ('<<') de
mensagens do subsistema AgentLog. Esses novos tipos de mensagens também podem ser recebidos
pelos predicados tratadores de eventos suportados pelo AgentLog através do operador '&&'. A tabela
8 define o formato das operações de envio e recepção dessas novas mensagens.
Tabela 8: Operações de envio e recepção de mensagens instantâneas
Operação de envio
Descrição
imsg(Txt) >> AvFirst+AvLast
Envia a mensagem instantânea de texto Txt ao avatar com nome AvFirst e
sobrenome AvLast.
imsg(Txt) >> AvName
Envia a mensagem instantânea de texto Txt ao avatar com nome completo
AvName, já formado pelo nome seguido do sobrenome.
group_imsg(Txt) >> GpName
Envia a mensagem instantânea de texto Txt ao grupo de nome GpName.
Operação de recepção
Descrição
imsg(Txt) << AvName // Tmt
Espera pela mensagem instantânea de texto Txt por um período máximo de
tempo (um timeout) definido por Tmt de um avatar com nome completo
AvName, já formado pelo nome seguido do sobrenome.
imsg(Txt) << AvName
Espera pela mensagem instantânea de texto Txt sem limite de tempo (sem
timeout) de um avatar com nome completo AvName, já formado pelo nome
seguido do sobrenome.
group_imsg(Txt) << GpName // Tmt
Espera pela mensagem instantânea de texto Txt por um período máximo de
tempo (timeout) definido por Tmt de um grupo com nome GpName.
group_imsg(Txt) << GpName
Espera pela mensagem instantânea de texto Txt sem limite de tempo (sem
timeout) de um grupo com nome GpName.
5.6. Ações sobre o ambiente
A Tabela 9 a seguir define as ações que permitem fazer modificações no ambiente. Note que essas
alterações somente serão possíveis se o avatar tiver permissões para esse tipo de ação.
Tabela 9: Ações de modificação de entidades no ambiente
Ação
Descrição
touch(obj(UID))
Toca o objeto identificado por UID.
move(obj(UID),pos(X,Y,Z))
Move o objeto identificado por UID para a posição X,Y,Z dentro da mesma região.
resize(obj(UID),scale(X,Y,Z))
Altera o tamanho (escala) do objeto identificado por UID . Os valores X,Y,Z
definem a noca escala do objeto nos eixos X, Y e Z.
19
João C. Gluz
rotate(rot(R,P,Y))
Faz uma rotação do corpo do avatar. R, P e Y definem os ângulos de rotação de roll
(ângulo de Euler X), pitch (ângulo de Euler Y) e yaw (ângulo de Euler Z) do avatar
em radianos.
rotate(rot(Rg dg,Pg dg,Yg dg))
Faz uma rotação do corpo do avatar. Rg, Pg e Yg definem os ângulos de rotação de
roll (ângulo de Euler X), pitch (ângulo de Euler Y) e yaw (ângulo de Euler Z) do
avatar em graus.
rotate(obj(UID),rot(R,P,Y))
Faz uma rotação do objeto identificado por UID. R, P e Y definem os ângulos de
rotação de roll (ângulo de Euler X), pitch (ângulo de Euler Y) e yaw (ângulo de
Euler Z) do avatar em radianos.
rotate(obj(UID),
rot(Rg dg,Pg dg,Yg dg))
Faz uma rotação do objeto identificado por UID. Rg, Pg e Yg definem os ângulos de
rotação de roll (ângulo de Euler X), pitch (ângulo de Euler Y) e yaw (ângulo de
Euler Z) do avatar em graus.
rez(prim(PT),pos(X,Y,Z))
Cria um novo objeto primitivo (um 'prim') na posição X,Y,Z. PT identifica o tipo do
objeto primitivo e pode ser uma das seguintes opções: box, cylinder, prism, sphere,
torus, tube, ring, sculpt, mesh, unknown.
rez(prim(PT),pos(X,Y,Z),Attrs)
Cria um novo objeto primitivo (um 'prim') na posição X,Y,Z. PT pode assumir os
mesmos valores que em rez(prim(PT),pos(X,Y,Z)), Attrs é uma lista de atributos do
novo objeto que pode conter os seguintes tipos de termos: scale(X,Y,Z), a escala
(tamanho) do objeto sendo criado, rot(R,P,Y), a rotação em radianos do objeto sendo
criado, R,P,Y definem, respectivamente, os ângulos de roll, pitch e yaw do objeto,
rot(Rg dg,Pg dg,Yg dg), também define a rotação do objeto, mas Rg, Pg e Yg
definem os ângulos de roll, pitch e yaw em graus.
rez(tree(TT),pos(X,Y,Z))
Cria uma nova árvore ('linden') na posição X,Y,Z. TT identifica o tipo de árvore e
pode ser uma das seguintes opções: pine1, oak, tropicalbush1, palm1, dogwood,
tropicalbush2, palm2, cypress1, cypress2, pine2, plumeria, winterpine1,
winteraspen, winterpine2, eucalyptus, fern, eelgrass, seasword, kelp1, beachgrass1,
kelp2
rez(tree(TT),pos(X,Y,Z),Attrs)
Cria uma nova árvore ('linden') na posição X,Y,Z. TT pode assumir os mesmos
valores que em rez(tree(TT),pos(X,Y,Z)), Attrs é uma lista de atributos do novo
objeto que pode conter os mesmos termos descritos em
rez(prim(PT),pos(X,Y,Z),Attrs).
rez(grass(GT),pos(X,Y,Z))
Cria uma nova grama na posição X,Y,Z. GT identifica o tipo de grama e pode ser
uma das seguintes opções: grass0, grass1, grass2, grass3, grass4, undergrowth1
rez(grass(GT),pos(X,Y,Z),Attrs)
Cria uma nova grama na posição X,Y,Z. GT pode assumir os mesmos valores que
em rez(grass(GT),pos(X,Y,Z)), Attrs é uma lista de atributos do novo objeto que pode
conter os mesmos termos descritos em rez(prim(PT),pos(X,Y,Z),Attrs).
5.7. Ações sobre o próprio avatar
A Tabela 10 a seguir define as ações efetuadas sobre as entidades e acessórios diretamente ligados
ao avatar.
Tabela 10: Ações de modificação do avatar
Ação
Descrição
import(XMLFile)
Importa objetos primitivos ('prims') definidos em um arquivo XML para o inventário
do avatar. XMLFile é o caminho do arquivo no computador cliente que está
executando o VirtuALog.
20
João C. Gluz
export(obj(UID),XMLFile)
Exporta o objeto definido por UID para um arquivo XML. XMLFile é o caminho do
arquivo no computador cliente que está executando o VirtuALog.
wear(folder(Path))
Veste o avatar com uma nova roupa, ou seja, faz o avatar usar os itens de roupa
definidos no diretório Path do inventário do avatar. O diretório Path deve conter
objetos que podem ser vestidos (wearable).
wear(item(Path))
Faz o avatar usar o item de roupa localizado no caminho Path do inventário do
avatar. O item localizado em Path deve ser um objeto que podem ser vestido
(wearable).
take_off(item(Path))
Faz o avatar retirar a roupa definida pelo item localizado no caminho Path, que está
atualmente sendo utilizada pelo avatar.
take_off(wear(UID))
Faz o avatar retirar a roupa definida por UID, que está atualmente sendo utilizada
pelo avatar.
upload_texture(item(Path),
LocalFile)
Carrega um arquivo de imagem para um item do inventário do avatar. Path é o
caminho do item no inventário do avatar. LocalFile é o caminho do arquivo de
imagem no computador cliente que está executando o VirtuALog.
upload_animation(LocalFile)
Carrega um arquivo de animação (um arquivo script .lsl) para o inventário do avatar.
LocalFile é o caminho do arquivo de animação no computador cliente que está
executando o VirtuALog.
attach(Position,item(Path))
Conecta o item localizado no caminho Path do inventário do avatar para a posição
do corpo do avatar identificada por Position, que pode ser uma das seguintes opções:
default, chest, skull, left_shoulder, right_shoulder, left_hand, right_hand, left_foot,
right_foot, spine, pelvis, mouth, chin, left_ear, right_ear, left_eyeball, right_eyeball,
nose, right_upper_arm, right_forearm, left_upper_arm, left_forearm, right_hip,
right_upper_leg, right_lower_leg, left_hip, left_upper_leg, left_lower_leg, stomach,
left_pec, right_pec, hud_center2, hud_top_right, hud_top, hud_top_left, hud_center,
hud_bottom_left, hud_bottom, hud_bottom_right, neck, root
play(StdAnimation)
Faz o avatar executar uma animação padrão identificada por StdAnimation. As
animações padrões são: afraid, aim_bazooka_r, aim_bow_l, aim_handgun_r,
aim_rifle_r, angry, away, backflip, belly_laugh, blow_kiss, bored, bow, brush, busy,
clap, courtbow, crouch, crouchwalk, cry, customize, customize_done, dance1,
dance2, dance3, dance4, dance5, dance6, dance7, dance8, dead, drink,
embarrassed, express_afraid, express_anger, express_bored, express_cry,
express_disdain, express_embarrassed, express_frown, express_kiss, express_laugh,
express_open_mouth, express_repulsed, express_sad, express_shrug, express_smile,
express_surprise, express_tongue_out, express_toothsmile, express_wink,
express_worry, falldown, female_walk, finger_wag, fist_pump, fly, flyslow, hello,
hold_bazooka_r, hold_bow_l, hold_handgun_r, hold_rifle_r, hold_throw_r, hover,
hover_down, hover_up, impatient, jump, jump_for_joy, kiss_my_butt, land,
laugh_short, medium_land, motorcycle_sit, muscle_beach, no, no_unhappy,
nyah_nyah, onetwo_punch, peace, point_me, point_you, pre_jump, punch_left,
punch_right, repulsed, roundhouse_kick, rps_countdown, rps_paper, rps_rock,
rps_scissors, run, sad, salute, shoot_bow_l, shout, shrug, sit, sit_female, sit_generic,
sit_ground, sit_ground_staticrained, sit_to_stand, sleep, smoke_idle, smoke_inhale,
smoke_throw_down, snapshot, stand, standup, stand_1, stand_2, stand_3, stand_4,
stretch, stride, surf, surprise, sword_strike, talk, tantrum, throw_r, tryon_shirt,
turnleft, turnright, type, walk, whisper, whistle, wink, wink_hollywood, worry, yes,
yes_happy, yoga_float.
play(item(Path))
Faz o avatar executar uma animação contida em um item do inventário do avatar
localizado no caminho Path.
download(item(Path),LocalFile) Salva um item do inventário do avatar, localizado no caminho Path para um arquivo
local do computador localizado no caminho LocalFile.
upload(LocalFile,item(Path))
Carrega um arquivo local do computador localizado no caminho LocalFile para um
21
João C. Gluz
item do inventário do avatar, localizado no caminho Path.
delete(folder(Path))
Elimina (deleta) um diretório do inventário do avatar. Path é o caminho do diretório
a ser eliminado.
delete(tem(Path))
Elimina (deleta) um item do inventário do avatar. Path é o caminho do item a ser
eliminado.
create(folder(Path))
Cria um novo diretório no inventário do avatar. Path é o caminho do diretório a ser
criado.
5.8. Percepções do Avatar
O VirtuALog define uma representação lógica para cada uma das entidades que podem existir em
um mundo virtual compatível com o OpenSimulator. Em princípio a cada entidade do mundo
virtual deve corresponder uma entidade lógica que pode ser reconhecida pelo VirtuALog. No
contexto do VirtuALog, essas entidades são organizadas em uma ontologia de entidades lógica,
cuja hierarquia de classes é apresentada na Figura 6. São essas as entidades lógicas que podem ser
percebidas pelos avatares no ambiente virtual 3D.
Figura 6: Entidades que podem ser percebidas em um ambiente virtual 3D
Todas essas entidades lógicas possuem identificadores únicos de 128 bits gerados pelo simulador
3D compatível com o OpenSimulator/SecondLife. Esses identificadores são representados por
átomos Prolog no formato:
'hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh'
onde os valores h são dígitos hexadecimais. A seguir são apresentados alguns exemplos de
identificadores representados por átomos Prolog:
'179cdabd-398a-9b6b-1391-4dc333ba321f'
'bdacdabd-308a-9b6b-1291-4de334ba321f'
As entidades lógicas percebidas até o momento estão representadas na base de percepções por
termos no formato:
UID:Class @@ Time
22
João C. Gluz
onde UID é o identificador único de 128 bits da entidade no ambiente virtual, tal como definido
acima, Class é um átomo que identifica a classe da entidade, de acordo com a hierarquia de classes
apresentada na Figura 6 e Time indica o instante de tempo em que foi feita a observação da
entidade. O operador ':' é usado como operador de pertinência indicando que a entidade UID
pertence a classe Class (ou alternativamente, que a entidade UID é do tipo Class). O operador '@@'
é utilizado como marcador do instante de tempo quando a entidade foi percebida e registrada na
base de percepções.
Também pode ser utilizada a notação Class(UID) para consultar se uma entidade UID do tipo Class
está armazenada na base de crenças.
A tabela 11 a seguir lista as classes (tipos) de entidades lógicas que podem ser percebidas pelo
avatar e armazenadas na base de percepções e a quais entidades do mundo virtual correspondem
essas entidades lógicas.
Tabela 11: Entidade lógicas
Classe de Entidade
Lógica
Descrição
obj
Objeto percebido no mundo virtual, pode ser um objeto primitivo ('prim') ou um objeto
composto.
avatar
Avatar percebido no mundo virtual.
region
Região existente no mundo virtual que foi percebida pelo avatar.
folder
Um diretório (folder) no inventário do avatar.
item
Um item do inventário do avatar.
group
Um grupo de pessoas existente no mundo virtual, que foi percebido peloa avatar.
role
Um papal que pode ser assumidas por pessoas de um dado grupo.
place
Um lugar (uma localização) existente no mundo virtual que foi percebida pelo avatar.
asset
Um bem existente no mundo virtual e percebido pelo avatar. Pode ser um bem do próprio
avatar (item do inventário, roupa, parte do corpo, etc.)
texture
Uma textura que pode ser aplicada a superfície de um objeto. Essa textura pode fazer parte
de um objeto do ambiente, ou ser um bem do próprio avatar.
attachment
Um objeto que é utilizado como acessório do avatar.
light
Um objeto que representa uma luz ou fonte de luz (ver ref. SecondLife/OpenSimulator)
flexible
Um objeto flexível.
sculpt
Um objeto do tipo sculpt (ou mesh) (ver ref. SecondLife/OpenSimulator)
friend
Um outro avatar que está relacionado como amigo do avatar.
agent
Um outro avatar que foi classificado como agente artificial.
5.8.1. Consultas à base de percepções
As consultas à base de percepções são feitas através do operador '<:' aplicado a um filtro seletor de
percepções Percept, resultando em expressões no formato:
<: Percept
que irá buscar na base de percepções por percepções que se encaixam (unificam) com o filtro
Percept.
23
João C. Gluz
Um filtro de percepções é formado ou por expressões no formato:
UID:Class
que denota a classe Class da entidade identificada por UID ou então por expressões no formato:
UID:Property
que denota uma propriedade da entidade identificada por UID. Class pode assumir um dos valores
listados na Tabela 11, enquanto que Property é uma das propriedades definidas na Tabela 13.
Por exemplo, para consultar se foi percebido algum objeto da classe avatar basta fazer uma consulta
com o formato:
<: UID:avatar.
onde '<:' é o operador de consulta à base de percepções, avatar o identificador da classe dos
avatares (ver Tabela 11) e UID uma variável que será unificada com os identificadores de entidades
da classe avatar que foram percebidos até o momento. Note que não é obrigatório o uso do
marcador de tempo “@@ Time”, ao fim da consulta à base de percepções.
Por meio do retrocesso (backtrack) do Prolog, poderão ser recuperadas todas os avatares percebidos
até o momento.
Importante:
Somente através das operações de busca/pesquisa (ver seção 5.3.3) tais como look_for(avatars) ou
look_for(objs, R mt) é que poderão ser percebidas e registradas na base de percepções as entidades
virtuais existentes no ambiente. No caso das entidades existentes no inventário do avatar é
necessário executar a operação look_my(inventory) que trará as informações sobre os diretórios e
itens contidos no inventário.
Case seja necessário obter o instante de tempo quando foi feita a observação, pode-se utilizar uma
consulta que inclua o marcador de tempo como uma variável:
<: (UID:avatar) @@ Time.
Note que no caso de uso de marcadores de tempo o uso dos parênteses é obrigatório. Neste caso
será retornado na variável Time o instante de tempo em que a percepção foi armazenada na base de
percepções.
Também pode-se empregar marcadores de tempo que permitem indicar os períodos ou instantes de
tempo em que se deseja verificar se foram registradas as percepções. Para tanto é possível utilizar
nas consultas à base de percepções expressões com os formatos apresentados na Tabela 12.
Tabela 12: Expressões temporais utilizadas nas consultas às percepções
(Percept) @@ last
Recupera as percepções que foram realizadas na última observação e que se
encaixa no filtro Percept.
(Percept) @@ after(Time)
Recupera percepções registradas após o instante de tempo Time e que se
encaixam no filtro Percept.
(Percept) @@ past(N sec)
Recupera percepções registradas nos últimos N segundos e que se encaixam no
filtro Percept.
(Percept) @@ before(Time)
Recupera percepções registradas antes do instante de tempo Time e que se
24
(Percept) @@ prior(N sec)
João C. Gluz
Recupera percepções registradas antes dos últimos N segundos e que se
5.8.2. Percepção das propriedades
Cada uma das entidades do mundo virtual possui uma série de propriedades que também são
representadas na ontologia de entidades lógicas do VirtuALog.
As propriedades das entidades lógicas percebidas até o momento estão representadas na base de
percepções por termos no formato:
UID:property(Val1,Val2,...,Valn) @@ Time
onde UID é o identificador único de 128 bits da entidade no ambiente virtual, property é um átomo
Prolog correspondente ao nome de uma propriedade da entidade (ver Tabela 12), Val1,Val2,...,Valn
são termos Prolog com os valores da propriedade e Time o instante de tempo em que a propriedade
foi registrada na base de percepções..
No caso das percepções de propriedades o operador ':' é usado como operador de relação indicando
que a propriedade property com valores Val1,Val2,...,Valn está relacionada a entidade lógica
(indivíduo ou instância) identificado por UID.
A Tabela 13 lista as propriedades pertencentes a cada classe de entidade.
Tabela 13: Propriedades das entidades lógicas
Classe
Propriedade
Descrição
entity
creator_id(UID)
Metadado contendo o identificador UID do criador da entidade.
group_id(UID)
Metadado contendo o identificador UID do grupo da entidade.
region_id(UID)
Metadado contendo o identificador UID da região da entidade.
material(Mat)
Metadado com o tipo de material do objeto. Mat define o tipo de
material que pode ser: stone, metal, glass, wood, flesh, plastic,
rubber, light.
texture_id(UID)
Metadado contendo o identificador UID de uma textura da entidade.
creation_date(DateTime)
Metadado contendo a data e hora em que esta entidade foi criada.
DateTime no formato UTC (Coordinated Universal Time).
date_time(DateTime)
Metadado contendo a data e hora atual da entidade. DateTime no
formato UTC (Coordinated Universal Time).
description(Txt)
Metadado contendo a descrição textual da entidade.
flags(LF)
LF é a lista de flags da entidade
loc(R,X,Y,Z)
Localização da entidade, onde R identifica o nome da região e X,Y,Z a
posição dentro da região.
local_id(LID)
LID é o identificador local da entidade.
name(Name)
Name é o nome da entidade (um string).
permissions(PM)
PM é a máscara de permissões da entidade.
pos(X,Y,Z)
Posição da entidade na região atual. X,Y e Z são as coordenadas da
posição.
region_name(NameRgn)
NameRgn é o nome da região onde está a entidade (um string).
25
João C. Gluz
sale_price(Price)
Price é o preço de venda do bem.
first_name(First)
First contém o nome (ou primeiro nome) do avatar.
group_name(GpName)
GpName é o nome do grupo ao qual o avatar pertence.
is_offline
Se presente indica que o avatar está offline (não está conectado).
last_name(Last)
Last contém o sobrenome (o parte final do nome) do avatar.
part_texture(Part,UID)
UID identifica uma textura associada a parte do avatar identificada
por Part.
region_handle(H)
H é o 'handle' da região onde o avatar está situado.
member_count(N)
O número de membros do grupo é N.
role_count(N)
O número de papeis existentes do grupo é N.
has_role(UID)
O grupo possui um papél identificado por UID.
handle(H)
H é o 'handle' da região.
terrain_base(I,UID)
UID é o objeto usado como terreno base de índice I da região.
terrain_detail(I,UID)
UID é o objeto usado como detalhamento do terreno de índice I da
região.
water_height(L)
O nível da água na região é L.
world_pos(X,Y)
As coordenadas da região no grid do simulador são X e Y.
access(TL)
TL define o tipo ou nível de acesso da região.
role
title(Tit)
O título atribuído ao papel é Tit.
asset
path(Path)
Path é o caminho do bem no inventário do agente.
last_owner_id(UID)
UID é o identificador do último dono deste bem.
sale_type(ST)
ST é o tipo da venda.
transaction_id(UID)
Identificador de transação utilizado para atualizar o UID do bem
(AssetUID) em requisições ao servidor.
asset_id(UID)
UID é o identificador único do item.
asset_type(AT)
AT é o tipo do bem/item, pode ser: unknown, texture, sound,
callingcard, landmark, clothing, object, notecard, folder, rootfolder,
lsltext, lslbytecode, texturetga, bodypart, trashfolder, snapshotfolder,
lostandfoundfolder, soundwav, imagetga, imagejpeg, animation,
gesture, simstate, favoritefolder, link, linkfolder, ensemblestart,
ensembleend, currentoutfitfolder, outfitfolder, myoutfitsfolder, mesh,
inbox, outbox, basicroot
inventory_type(IT)
IT é o tipo de item de inventário, pode ser: unknown, texture, sound,
callingcard, landmark, object, notecard, category, folder,
rootcategory, lsl, snapshot, attachment, wearable, animation,
gesture, mesh
is_group_owned
Se presente, indica que o item é possuído por um grupo.
avatar
group
region
item
26
obj
João C. Gluz
accel(X,Y,Z)
Aceleração do objeto no espaço 3D.
ang_veloc(X,Y,Z)
Velocidade angular do objeto.
coll_plane(X,Y,Z,W)
Plano de colisão do objeto.
density(D)
D é o coeficiente de densidade do objeto (1000 para densidade
normal).
face_texture(I,UID)
UID é a textura da face de índice I do objeto.
material(Mat)
Mat define o tipo de material do objeto, que pode ser: stone, metal,
glass, wood, flesh, plastic, rubber, light.
friction(F)
F é o coeficiente de fricção do objeto.
grav_mult(G)
G é o multiplicador de gravidade (1 para gravidade normal)
parent_id(UID)
UID identifica o objeto pai deste objeto, usado em objetos compostos.
path_begin(FloatVal)
path_end(FloatVal)
path_radius_offset(FloatVal)
path_revols(FloatVal)
path_scale_x(FloatVal)
path_scale_y(FloatVal)
path_shear_x(FloatVal)
path_shear_y(FloatVal)
path_skew(FloatVal)
path_taper_x(FloatVal)
Propriedades que contém os dados de construção do objeto.
Para mais detalhes consulte a documentação do
OpenSimulator/SecondLife.
path_taper_y(FloatVal)
path_twist(FloatVal)
path_twist_begin(FloatVal)
prof_begin(FloatVal)
prof_begin_scale(X,Y)
prof_end(FloatVal)
prof_end_scale(X,Y)
prof_hollow(FloatVal)
restit(R)
R é o coeficiente de restituição (restitution).
rot(R,P,Y).
Rotação do corpo do objeto. R, P e Y definem os ângulos de rotação
de roll (ângulo de Euler X), pitch (ângulo de Euler Y) e yaw (ângulo
de Euler Z) do avatar em radianos.
scale(X,Y,Z)
Tamanho (escala) do objeto. Os valores X,Y,Z definem a noca escala
do objeto nos eixos X, Y e Z.
text(Txt)
Metadado textual associado ao objeto.
veloc(X,Y,Z)
Velocidade atual do objeto no espaço 3D.
owner_id(UID)
UID identifica o dono do objeto.
category(Cat)
Cat é a categoria do objeto, pode ser: invalid, none, owner, group,
other, selected, temporary.
27
flexible
João C. Gluz
path_curve(PAC)
Tipo de caminho curvo usado na construção visual do objeto, pode
ser: line, circle, circle2, test, flexible
prim_code(PC)
Código de primitiva do objeto, pode ser: avatar, grass, new_tree,
none, particle_system, prim, tree
prim_type(PT)
Tipo de primitiva do objeto, pode ser: box, cylinder, mesh, prism,
ring, sculpt, sphere, torus, tube, unknown
prof_curve(PRC)
Perfil de curva usado na construção visual do objeto, pode ser: circle,
square, isotriangle, equaltriangle, righttriangle, halfcircle
prof_hole(HT)
HT define o tipo de 'buraco' (hole), pode ser: same, circle, square,
triangle
shape_type(ST)
ST define o tipo de forma física, pode ser: prim, none, convexhull
tree_species(TT)
TT identifica o tipo de árvore e pode ser uma das seguintes opções:
pine1, oak, tropicalbush1, palm1, dogwood, tropicalbush2, palm2,
cypress1, cypress2, pine2, plumeria, winterpine1, winteraspen,
winterpine2, eucalyptus, fern, eelgrass, seasword, kelp1, beachgrass1,
kelp2
flex_drag(FloatVal)
flex_force(X,Y,Z)
flex_gravity(FloatVal)
flex_softness(IntVal)
flex_tension(FloatVal)
Propriedades relacionadas a objetos primitivos flexíveis.
flex_wind(FloatVal)
light
light_color(R,G,B,A)
light_cutoff(FloatVal)
light_falloff(FloatVal)
light_intensity(FloatVal)
light_radius(FloatVal)
Propriedades relacionadas a objetos primitivos de luz.
lightmap_params(X,Y,Z)
lightmap_texture(UID)
sculpt
sculpt_inverted
sculpt_mirrored
sculpt_texture(UID)
Propriedades relacionadas a objetos primitivos do tipo sculpt ou mesh.
sculpt_type(ScT)
attachment
attach_point(Point)
Point identifica a posição de conexão do acessório, pode assumir os
mesmos valores de Position na ação attach(Position,item(Path))
apresentada na tabela 10.
Note que pela herança de propriedades de classes, as entidades que estão abaixo na hierarquia de
classes definida na Figura 6, herdam as propriedades das classes que estão acima. Assim, pelo fato
28
João C. Gluz
da classe entity ter, por exemplo, a propriedade name(Name), então todas as demais classes que são
subclasses dessa classe (classes que estão abaixo da classe entity na hierarquia de classes
apresentada na Figura 6) também possuem essa propriedade.
Para descobrir quais são as propriedades de uma dada entidade identificada por UID, basta usar uma
variável após o operador ':' e fazer uma consulta com a seguinte estrutura:
<: UID:Prop .
onde Prop é uma variável. Neste caso, por meio do backtrack (retrocesso) do Prolog poderão ser
encontradas todas as propriedades relacionadas à entidade identificada por UID.
É importante observar que, mesmo se uma classe tem uma determinada propriedade, isso não obriga
que um objeto (uma instância ou indivíduo) dessa classe tenha essa propriedade definida. Dessa
forma, no exemplo da propriedade name(Name) vinculada a classe entity, um objeto desta classe ou
de alguma subclasse de entity como avatar ou obj, pode ou não ter seu nome definido por essa
propriedade.
Importante:
Da mesma forma que no caso das percepções de entidades vista no início da seção 5.8, somente
através das operações de observação de entidades (ver seção 5.3.2) ou de propriedades do avatar
(ver seção 5.3.1), tais como look(obj(UID)), look(avatar(UID)) ou look_my(item(Path)) é possível
ter acesso às propriedades de uma entidade no mundo virtual e trazer essas propriedades para a
base de percepções.
No exemplo de código apresentado na seção 5.4 de movimentação pelo ambiente, um agente se
move da sua posição atual para uma nova posição, depois verifica se há um avatar em um raio de 2
metros ao seu redor e caso isso seja verdadeiro, orienta sua face para este avatar. Utilizando
consultas às percepções, o código apresentado na seção 5.4 poderia ser reescrito da seguinte forma:
...
:>
:>
<:
:>
<:
:>
move_to(pos(110,220,34)),
look_for(avatars, 2 mt),
(UID:avatar) @@ last,
look(avatar(UID)),
(UID:pos(X,Y,Z)) @@ last,
turn_to(pos(X,Y,Z)),
...
No código acima, após a movimentação do avatar até a nova posição e a busca pelos avatares
próximos dessa posição é feita uma consulta pelas percepções realizadas na última operação de
observação
(<: (UID:avatar) @@ last). Se houver algum avatar percebido na última
observação, o código segue em execução e é feita uma observação das propriedades desse avatar
(:> look(avatar(UID))), recuperada a última posição observada do avatar ( <:
(UID:pos(X,Y,Z)) @@ last) e feito o redirecionamento da face para essa posição.
5.8.3. Percepções de eventos
Eventos gerados no ambiente 3D também podem ser tratados pelos predicados tratadores de
eventos (ou handlers, em inglês) implementados pelo AgentLog (ver o Guia do AgentLog 0.5:
Programação de Agentes BDI em Prolog para mais detalhes).
Predicados tratadores de evento são definidos com o operador '&&' aplicado a um identificador de
29
João C. Gluz
agente AgId e a um seletor de eventos SimEvSelector que podem ser gerados pelo simulador 3D,
resultando em expressões com o formato “AgId && SimEvSelector” que devem ser utilizadas na
cabeçalho das regras que compõem o predicado tratador de eventos. Assim uma regra de um
predicado tratador de eventos tem o formato:
AgId && SimEvSelector :- Predicate.
onde Predicate é a expressão lógica que define o predicado que irá tratar eventos selecionados por
SimEvSeletor e destinados ao agente AgId.
A tabela 14 a seguir mostra os tipos de eventos especificamente gerados pelo simulador de mundos
virtuais 3D e que também podem ser processados pelos predicados tratadores de eventos. Cada tipo
de evento definido na coluna mais a esquerda pode ser utilizado como um seletor de eventos em um
predicado tratador de eventos.
Tabela 14: Eventos que podem ser gerados pelo simulador do mundo virtual 3D
Tipo (Seletor) do Evento
Descrição
imsg(Txt) << AvName
Recepção de uma mensagem instantânea de texto Txt do avatar com nome
completo AvName, formado pela concatenação do (primeiro) nome com o
sobrenome.
group_imsg(Txt) << GpName
Recepção de uma mensagem instantânea de texto Txt do grupo com nome
GpName'.
say(Txt, Channel)
Recepção de uma mensagem de texto Txt ao canal de chat identificado por
Channel com nível de áudio simulado normal (raio de 5 metros). Channel é
um valor numérico, 0 é o canal público.
shout(Txt, Channel)
Channel com nível de áudio simulado alto (raio de 100 metros). Channel é
whisper(Txt, Channel)
Channel com nível de áudio simulado baixo (raio de 5 metros). Channel é
collision(AggrUID, CollType, Magn,
CollTime,VictUID)
Evento enviado pelo simulador indicando que houve uma colisão com o
avatar. AggrUID é o identificador único do causador da colisão ('agressor'),
CollType é o tipo da colisão, pode ser: none, bump, llpushobject,
selectedobjectcollide, scriptedobjectcollide, physicalobjectcollide. Magn é
um valor numérico indicando a força da colisão, CollTime é o tempo da
colisão registrado no simulador e VictUID o identificador único do avatar
que sofreu a colisão (a 'vítima').
region_crossed(NewRgn, OldRgn)
Evento enviado pelo simulador indicando que o avatar passou da região de
nome OldRgn para a região de nome NewRgn.
alert_msg(AlertMsg)
Evento de alerta enviado pelo simulador usualmente indicando uma falha
recente em alguma ação como a tentativa de entrar em uma área (parcel)
com acesso negado. AlertMsg é a mensagem textual de alerta.
group_invitation(AvUID, AvName,
GroupInfo, RgnName)
Evento indicando a recepção de um convite para particição em um grupo.
AvUID e AvName contém, respectivamente, o identificador e o nome do
avatar que está fazendo o convite, GroupInfo é um texto contendo
informações sobre o grupo e RgnName o nome da região.
kill_objs(LocalIdList, RgnName)
Evento enviado pelo simulador indicando que os objetos da região com
nome RgnName cujos identificadores locais estão registrado na lista
LocalIdList não estão mais visíveis ou não existem mais (foram “derezzed”)
mov_update(UID, RgnName,
TimeDilat, MovUpdList)
Evento enviado pelo simulador quando um objeto identificado por UID,
localizado na região de nome RgnName com dilatação temporal TimeDilat
30
João C. Gluz
sofre uma alteração em sua movimentação. MovUpdList é uma lista com os
novos valores das propriedades de movimentação. São elementos possíveis
dessa lista os seguintes termos: accel(X,Y,Z), ang_veloc(X,Y,Z), avatar,
coll_plane(X,Y,Z,W), local_id(LID), pos(X,Y,Z), rot(X,Y,Z), state(S),
textures(TextureUID), veloc(X,Y,Z). O termo avatar, se presente indica que o
objeto é um avatar.
++ (<: Percept)
Adição de uma nova percepção na base de percepções. O uso de parêntesis
em torno de <: Percept é obrigatório. Percept é um termo Prolog no formato
UID:property(Val1,...,Valn) ou UID:class, onde UID é um identificador de
entidade, class um identificador de classe de entidade, property um
identificador de propriedade de entidade e Val1,...,Valn são termos Prolog
com os valores da propriedade.
-- (<: Percept)
Exclusão de uma percepção da base de percepções. O uso de parêntesis em
torno de <: Percept é obrigatório. Percept tem o mesmo formato usado no
seletor de eventos de inclusão na base de percepções ++ (<: Percept).
O instante de tempo em que ocorreu o registro do evento na base de percepções pode ser obtido
como um parâmetro opcional associado ao operador '@@'. Assim a expressão “AgId &&
SimEvSelector @@ Time” também pode ser utilizada nos cabeçalhos das regras dos predicados
tratadores de eventos gerados pelo simulador 3D para obter o instante de tempo Time quando o
evento foi registrado na base de eventos.
Note que no caso da utilização do operador '@@' nos eventos de eliminação de percepções:
-- (<: Percept) @@ OrigTime
é obtido em OrigTime o instante de tempo original em que ocorreu a percepção que avgora está
sendo excluída da base de percepções.
6. Um Exemplo de Programação: Feira de Ciências Virtual
A Figura 7 ilustra um possível cenário de uso do VirtuALog, onde um mundo virtual é construído
para apresentar uma feira de Ciências de Ensino Médio. Além dos materiais, objetos e avatares de
agentes disponíveis em cada estande da mostra, devem projetados e implementados agentes que irão
servir de guias e de expositores virtuais dessa mostra. Avatares correspondentes a estes agentes
devem ser previamente configurados no simulador, em conjunto com a criação da estrutura "física"
virtual da feira que inclui estandes da exposição, painéis para posters, móveis, materiais de
exposição, a região onde será realizada a mostra, os elementos decorativos desta região, etc.
31
João C. Gluz
Figura 7: Organização do Cenário de Uso
Agentes (e seus correspondentes avatares) guias tem a função de acompanhar e atender alunos e
professores (os "usuários" da feira) que chegam para a mostra virtual de Ciências, oferecendo um
serviço de guia dos vários estandes e posters que compõem a mostra, além de responder perguntas
gerais sobre a feira. Os agentes guia ficam circulando no espaço da feira, passando a interagir com
os usuários quando se aproximam a menos de dois metros de um usuário, que já não esteja com
outro guia, ou quando um usuário se aproxima a menos de dois metros e pede ajuda (note que a
ajuda é oferecida apenas se o usuário aceitar).
A Figura 8 mostra uma possível cena de interação na feira virtual, ilustrando esse tipo de situação,
quando o Guia A oferece ajuda para um usuário através de interações executadas por meio do
sistema de mensagens instantâneas do simulador.
Figura 8: Exemplo de interação na feira virtual.
Agentes expositores ficam situados em um estande correspondente, respondendo as questões feitas
por usuários que se dirigem a eles por mensagens instantâneas. Também podem oferecer ajuda caso
um usuário se aproxime a menos de dois metros do estande. Os estandes e seus correspondentes
guias são identificados, assim os agentes expositores também podem oferecer respostas e
32
João C. Gluz
explicações por meio do canal de chat público, desde que consiga reconhecer que a mensagem está
dirigira ao estande com um nível de áudio simulado normal ou alto.
Neste tipo de configuração de cenário virtual para fins educacionais duas capacidades são
fundamentais para cada agente e avatar correspondente: (a) reconhecimento de termos e
comandos/solicitações em linguagem natural e (b) capacidade de reconhecimento do ambiente ao
seu redor, incluindo demais avatares presentes no ambiente, com a identificação se são ou não
agentes artificiais da feira.
Além disso, no caso dos agentes guias é necessária uma capacidade de movimentação natural pelos
espaços da feira. Neste exemplo, a estrutura física virtual da feira foi projetada para facilitar essa
circulação (ver Figura 9). A feira é organizada em um espaço circular central, com os estandes e os
posters dividindo o espaço aproximadamente pela metade. Uma mesa de conferências foi
posicionada no centro do espaço da feira para reuniões, discussões e apresentações dos alunos e
professores.
Conforme pode ser visto na Figura 7, o mecanismo de processamento de linguagem natural foi
"terceirizado" para um agente externo, não responsável pelo controle dos avatares. A comunicação
com este agente é feita por meio da plataforma JADE, permitindo que esse agente execute em uma
máquina separada, não causando impacto no desempenho na operação dos agente expositores ou
guias. Note que as características de implementação deste tipo de agente não serão consideradas
neste artigo, porém existe uma ampla literatura sobre implementação de mecanismos de
reconhecimento de linguagem natural (inclusive em Prolog), pelo menos no reconhecimento de
solicitações e comandos simples. O contexto das conversações é mantido pela adição em cada
mensagem trocada com este agente, dos identificadores do agente, do usuário e do instante de
tempo da interação, além do conteúdo textual desta.
Por outro lado a seguir veremos com VirtuALog permite implementar mecanismos práticos de
reconhecimento do ambiente e movimentação pelo mesmo. O código a seguir exemplifica o plano
lógico principal de um agente guia, cuja meta (goal) é passada como parâmetro do predicado
start_agent():
executar_objetivos_do_guia :sleep(5),
(houve_interacao_usuario(UserId) -> atender_usuario(UserId);
(existe_usuario_perto(UserId) -> atender_usuario(UserId);
true)),
circular_pela_feira,
executar_objetivos_do_guia.
Neste plano lógico pode-se observar que as ações do guia se dividem em: parar e descansar um
pouco (5 segundos), atender um usuário que requisitou atenção, descobrir se existe um usuário por
perto e oferecer ajuda, ou senão circular um pouco mais pela feira. O código a seguir ilustra como
se pode descobrir que algum usuário solicitou ajuda ou se há algum usuário por perto em
VirtALog:
houve_interacao_usuario(UserId) :<: (imsg(Msg) << UserId) @@ past(5 sec),
existe_usuario_perto(UserId).
existe_usuario_perto(UserId) ::> look_for(avatars, 2 mt),
<: (avatar(UserId)) @@ last,
\+ ?? virtualog_agent(UserId),
\+ ?? fazendo_tour(_,UserId).
33
João C. Gluz
Figura 9: Estrutura física virtual da feira.
Da mesma forma que as percepções as últimas mensagens (até um limite configurável de tempo)
ficam armazenadas na base de crenças do agente. Assim para saber se algum usuário tentou contatar
o agente guia basta verificar se houve alguma mensagem instantânea dirigida ao agente nos últimos
5 segundos (que é justamente o tempo de "descanso" do agente) e se quem enviou a mensagem
ainda está por perto. Para descobrir se alguem está por perto, basta observar se existem avatares em
um raio de 2 metros e verificar se eles não são agentes (\+ ?? virtualog_agent(UserId)) ou se
já são usuários fazendo o tour (\+ ?? fazendo_tour(_,UserId)). O plano lógico geral para o
atendimento dos usuários pelo agente guia é ilustrado a seguir:
atender_usuario(UserId) :this_agent(Agid),
gera_texto(apresentacao_guia,Agid,UserId,MsgApr),
imsg(MsgApr) >> avatar(UserId),
gera_texto(oferta_guia,Agid,UserId,MsgServ),
imsg(MsgServ) >> avatar(UserId), !,
imsg(Resp) << avatar(UserId) // 10,
get_time(RTime),
request(parse(Resp,RTime,Agid,Userid, expect([sim,nao,ajuda(Tema)]))
>> analisador_lingua_portuguesa, !,
inform(parse_result(Resp)) << analisador_lingua_portuguesa / 5 sec,
atender_usuario(UserId,Resp).
atender_usuario(UserId) :atender_usuario(UserId,nao).
atender_usuario(UserId,sim) :fazer_tour(UserId).
atender_usuario(UserId,ajuda(Tema)):tema_conhecido(Tema),
ajudar_usuario_tema(UserId,Tema).
34
João C. Gluz
atender_usuario(UserId,_) :this_agent(Agid),
gera_texto(obrigado_e_tchau,Agid,UserId,MsgApr),
imsg(MsgApr) >> avatar(UserId).
O plano acima supõe a existência de um módulo de geração de texto, invocado pelo predicado
gera_texto(), capaz de gerar mensagens coloquiais específicas, mas não muito repetitivas, a partir
de informações de contexto, como o agente que quer se comunicar e o avatar destinatário. De posse
destas mensagens, basta enviá-las ao avatar do usuário como mensagens instantâneas imsg(),
utilizando os operadores de envio de mensagens '>>'. Depois o agente espera por uma resposta do
usuário por até 10 segundos (imsg(Resp) << avatar(UserId) // 10) e, caso a receba, solicita
análise sintática desta mensagem, esperando receber três respostas básicas: sim, confirmando que o
usuário quer o tour, não, indicando que o usuário não quer ajuda nem tour ou a solicitação de ajuda
a algum tema específico. Os cortes Prolog (!) foram colocados para evitar o reenvio de mensagens
ao usuário caso não se receba o retorno das respostas. Neste caso o agente guia simplesmente
agradece, dá adeus e volta ao seu laço principal. Os planos lógicos completos para fazer o tour ou
ajudar o usuário em algum tema não serão apresentados aqui, porém o início do plano de tour é
apresentado a seguir:
fazer_tour(UserId) :this_agent(Agid),
:> look(my_pos) => PosAtual,
ponto_mais_perto_tour(PosAtual,ProxPos,ProxPonto),
gera_texto(vamos_comecar_tour,Agid,UserId,MsgInic),
imsg(MsgServ) >> avatar(UserId), sleep(1),
gera_texto(favor_me_siga,Agid,UserId,MsgInic),
imsg(MsgServ) >> avatar(UserId), sleep(1),
:> move_to(ProxPos),
assert(fazendo_tour(Agid,Userid)),
comecar_tour(UserId,ProxPonto).
comecar_tour(UserId,Ponto) :- ...
Por simples falta de espaço não será possível ilustrar o código que define o comportamento de
circulação do agente guia, nem os planos do agente expositor. No caso da circulação do expositor,
este é um plano relativamente simples, por conta do layout simples da feira (Figura 5), basta seguir
lentamente uma trilha circular entre a mesa central e a circunferência de posters e estandes,
trocando eventualmente de direção para o comportamento não ficar muito monótono. No caso dos
expositores, a maior complexidade está relacionada aos planos dos objetivos de ajuda/explanação
de temas específicos (que também não ilustrados no caso do agente expositor). Estes planos seguem
um roteiro similar ao processo de diálogo do plano de atender_usuario(), mas com mais opções de
interação. Pode-se também enriquecer a explanação com objetos e materiais animados capazes de
fazer apresentações multimídia. Tais entidades podem ser criadas no simulador, vinculadas aos
avatares expositores específicos e, então, sua ativação/desativação pode ser controlada pelo
agente/avatar usando as ações do VirtuALog.
35
João C. Gluz
BIBLIOGRAFIA
Austin, J. How to do Things with Words. Oxford: Clarendon, 1962.
Bellifemine, F; Caire, G.; Greenwood, G. Developing Multi-Agent Systems with JADE. John
Wiley & Sons, 2007.
Bond, A. H.; Gasser, L. (eds) Readings in Distributed Artificial Intelligence. Morgan Kaufmann,
San Mateo, CA, 1988.
Bordini, R.; Dastani, M.; Dix, J; Seghrouchni, A. (Eds). Multi-Agent Programming Languages,
Platforms and Applications. Springer, 2005.
Bordini, R; Hübner, J.; Wooldridge, M. Programming Multi-Agent Systems in Agentspeak Using
Jason (Wiley Series in Agent Technology). John Wiley & Sons. 2007.
Bratman, M. E.; Israel, D. J.; Pollack. Plans and Resource-Bounded Practical Reasoning.
Computational Intelligence, v.4, n.3, p.349-355. 1988.
Chaib-Draa, B; Dignum, F. Trends in agent communication language. Computational Intelligence.
v.2, n.5, p.1-14. 2002.
Coppin, J. Artificial Intelligence Illuminated. Jones and Bartlett Publ. 2004. ISBN 0-7637-32303.
Dastani, M.; Riemsdijk, M. B. v.; Mey, J.-J. C. Programming Multi-Agent Systems in 3APL. In:
Bordini, R.; Dastani, M.; Dix, J; Seghrouchni, A. (Eds). Multi-Agent Programming
Languages, Platforms and Applications. Springer, 2005.
FIPA. SC00037: FIPA Communicative Act Library Specification. FIPA, 2001. Available at
http:// www.fipa.org/specs/fipa00036/.
Georgeff, M.; Pell, B. et al. The Belief-Desire-Intention Model of Agency. Proceedings of the 5th
International Workshop on Intelligent Agents V, Agent Theories, Architectures, and
Languages.
Lecture
Notes
in
Computer
Science.
London,
UK:
Springer-Verlag. v.1555: p.1-10, 1999.
Hennessy, John L.; Patterson, David A. Computer Architecture: a Quantitative Approach. 4th
ed. Morgan Kaufmann, 2006.
Jennings, N.R., An Agent-Based Approach for Building Complex Software Systems. Comm. the
ACM, v. 44, n. 4, p. 35-41, Apr. 2001.
Kumar, S.; Chhugani, J.; Changkyu, K.; Daehyun, K.; Nguyen, et al. Second Life and the new
generation of Virtual Worlds, Computer, v. 41, n. 9. 2008.
Labrou, Y.; Finin, T. A semantics approach for KQML - a general purpose communication language
for sofware agents. Int. Conf. on Inf. and Knowledge Management (CIKM94).
Proceedings. Gaithersburg, Maryland, 1994.
Labrou, Y.; Finin T.; Peng Y. Agent communication languages: the current landscape. IEEE
Intelligent Systems, p.45-52, Março-abril de 1999.
36
João C. Gluz
Messinger, P. R.; Stroulia, E.; Lyons, K.; Bone, K.; Niu, R. H. et al. Virtual Worlds - past, present
and future: New directions in social computing, Decision Support Systems, v. 47, n. 3,
June, 2009
Miles, D. SWI-Prolog 2-Way interface to .NET/Mono, 2015. Available at http://www.swiprolog.org/contrib/NetMono.html.
Newell, A. The Knowledge Level. Artificial Intelligence, 18(1):87-127, 1982.
Rao, A. S.; Georgeff, M. Modeling rational agents within a BDI-architecture. Int. Conf. on
Principles of Knowledge Representation and Reasoning (KRR91), Proceedings.
Cambridge, Massachusetts: Morgan Kaufmann, p. 473-484, 1991.
Rao, A. S. AgentSpeak(L): BDI agents speak out in a logical computable language. 7th European
workshop on Modelling autonomous agents in a multi-agent world: agents breaking away
(MAAMAW '96). Proceedings. Springer-Verlag, New York, Inc. Secaucus, NJ, USA,
1996.
Russel, S. J.; Norvig, P. Artificial Intelligence: A Modern Approach. Second Edition. Pearson.
2010.
Singleton, P.; Dushin, F.; Wielemaker, J. JPL: A bidirectional Prolog/Java interface, 2015.
Available at http://swi-prolog.org/packages/jpl/.
Silberschatz, A.; Galvin, P.; Gagne, G. Operating Systems Concepts. 8th e. John Wiley, 2009.
Searle, J. Speech Acts: An Essay in the Philosophy of Language. Cambridge University Press,
1969.
Tanenbaum, Andrew S.; Wetherall, David J. Computer Networks. 5th ed. Pearson, 2011.
Weiss, G. Multiagent Systems. 2nd Ed. MIT Press, 2013.
Winikoff, M. JACK Intelligent Agents: An Industrial Strength Platform. In Bordini, R.; Dastani, M.;
Dix, J; Seghrouchni, A. (Eds). Multi-Agent Programming Languages, Platforms and
Applications. Springer, 2005.
Wooldridge, M. An Introduction to MultiAgent Systems. 2nd ed. John Wiley & Sons.
Wooldridge, M.; Jennings, N. Intelligent Agents: Theory and Practice. Knowledge Engineering
Review, v. 10, n. 2, 1995.
37

Guia de programação do VirtuALog

Transcrição

Documentos relacionados

um sistema de realidade virtual desktop para o ensino de

Mini Curso 6 - crie avatar

Desenhos Clássicos

MACHINIMAS, setembro de 2009

cases de crowdsourcing

Estudo e análise da viabilidade técnica

Dicas para as Redes Sociais aqui

Tendências Outono-Inverno 2015

cultura de moda - Riis Park Beach Bazaar

Amor - anandatour.com.br