…então crianças, estejam dispostas a estudar MESMO se resolverem fazer mestrado. Que venham as provas e trabalhos! -_-

Mais dois livros para minha biblioteca pessoal

PS: Não vou fazer promessas de quando vou postar algo útil no blog. Tenho várias coisas na cabeça e pouco tempo ou disposição para “materializá-las” em posts. Principalmente a minha nova vida (almost) GUI-less.

O artigo também não é recente, datando de 1999, mas alguns interesses em pesquisa apontados, como exploração de técnicas de machine learning, arquiteturas inteligentes, projeto de interfaces, representação de conhecimento, navegação de agentes e interação humano-computador, ainda são atuais.

A abordagem do artigo, no entanto, é interessante. Ao invés de usar linguagens de script, os autores preferiram conectar os bots do jogos à máquina de inferência SOAR para resolução do ciclo de decisão (percepção, raciocínio e atuação). Sua justificativa é que o Soar permite uma decomposição simples das ações do agente em uma hierarquia de operadores, que no alto nível representam os objetivos do agente e, no baixo nível, ações atômicas para que os objetivos sejam alcançados.

A abordagem do artigo até é interessante, mas em algumas buscas rápidas na internet não consegui encontrar outras abordagens deste tipo, a não ser pelo projeto Soar/Games. Mesmo assim, a notícia mais recente facilmente encontrada sobre eles fala de uma interface para o Half-life, o que parece não ser muito novo, também…

Para implementação de Co-fields, dois problemas de coordenação foram propostos:

• Definição de um ponto de encontro para os bots no mapa;
• Um conjunto de bots (predadores) encurralando o jogador (presa).

No primeiro caso, a política de coordenação expressa que cada bot percorre “para baixo” o campo até que convirjam para o ponto combinado. No segundo, os bots “descem” o campo da presa (para alcançá-la) e, ao mesmo tempo, “sobem” o campo dos outros predadores, para que fiquem separados. O efeito final é que ao invés de simplesmente se aproximarem da presa, os predadores a circundam.

A terceira seção trata da implementação propriamente dita, mas aparentemente, me parece que o artigo referenciado é mais completo para apresentar os Co-fields. Ainda assim, existe, em alto nível, ma apresentação das modificações feitas no ambiente e nos bots para que a abordagem de co-fields funcionasse.

No fim das contas, esse é o tipo de coisa quando se usa vários serviços gratuitos. Um dia ainda terei a disposição (financeira, inclusive) de rodar meus servidores, mas tenho a impressão que nem assim as coisas vão mudar muito… Oh vida.

A maior contribuição deste artigo é justamente por sua proposta, pois condensa em poucas páginas diversas técnicas para a movimentação de agentes em jogos e sua leitura é sugerida. A estrutura seguida é, basicamente, a seguinte:

1. Introdução - com apresentação do problema da IA em jogos, categorização dos métodos de steering;
2. Steering de longa distância - steering com A* puro, pathfinding suavizado, representação do mundo, tratamento de objetos dinâmicos, sumário
3. Steering local - steering emergente, problemas de implementação de “Force Based Emergent Steering“
4. Steering híbrido
5. Steering veicular
6. Conclusões

Enfim, é um artigo bem interessante com várias considerações sobre questões de implementação dessas técnicas.

Ainda instalei uma extensão do firefox para postar direto da barra de endereços, o que faz com que o sistema fique bem direto para postar. Desse jeito, até vale a pena.

1. Como o MAPF se comporta comparado a soluções tradicionais?
2. Até que nível a abordagem MAPF é configurável com respeito a mudanças no ambiente?

Uma justificativa para o uso de videogames é que eles formam plataformas de teste perfeitas para sistemas multiagentes. O ambiente pode ser competitivo e os NPCs devem se comportar de maneira racional e autônoma. Além do mais, as unidades atuam em um ambiente que possibilita comunicação explícita e colaboração para que certas tarefas sejam resolvidas.

Um dado interessante sobre o artigo é que ele é completo ao apresentar suas seções.

A seguinte metodologia foi estruturada para o projeto de uma solução MAPF:

1. Identificação de objetos
2. Identificação de forças do jogo
3. O processo de atribuição de forças para os objetos
4. Granularidade de tempo e espaco no ambiente
5. Os agentes do sistema
6. A arquitetura do sistema multiagentes (MAS)

Para validação do modelo, a engine de RTS ORTS foi usada, com foco em dois jogos de dois jogadores:

• Batalha de tanques, onde cada jogador possui 50 tanques e 5 bases, com o objetivo de destruir as bases do oponente. Os mapas, neste modo de jogo são gerados dinamicamente;
• Combate tático, onde cada jogador possui 50 soldados com o objetivo de destruir todos os soldados do oponente. Os soldados são posicionados aleatoriamente no mapa.

Implementação de MAPF no ORTS

A implementação de MAPF no ORTS seguiu a metodologia supracitada. Sobre os campos projetados, alguns destaques:

• Quatro forças básicas: evitar colisão com objetos em movimento, caçar as forças inimigas e, para a batalha de tanques, evitar colisões com montes e defender as bases - daí três tipos de campos: navegação, estratégico e tático;
• O campo de navegação é gerado repelindo terreno estático;
• O campo estratégico é atrativo, levando as unidades em direção aos oponentes e situando-as em posição de ataque;
• As próprias unidades, bases e ovelhas geram pequenos campos repelentes
• Todos os campos gerados por objetos são pesados e somados para formar um campo total usado pelos agentes para seleção de ações

Arquitetura do MAS

O controle tático foi dividido em dois nívels. Para que os agentes ataquem tanto unidades quanto bases, um dos seguintes requisitos deve ser satisfeito:

• Deve-se possuir, no mínimo, o dobro de tanques que o adversário;
• O oponente deve possuir menos de seis tanques;
• O oponente deve possuir apenas uma base restante.

Caso esses requisitos não sejam satisfeitos, o objetivo tático é atacar apenas unidades do oponente e o campo potencial gerado pelas bases inimigas é repelente.

O artigo também descreve a existência de um coordenador de ataques, responsável por otimizar os ataques às unidades do oponente, destruindo o máximo de unidades inimigas em por unidade de tempo.

Experimentos

A inteligência artificial desenvolvida participou do torneio de 2007 do ORTS e se colocou na sexta posição de nove oponentes. A justificativa dos autores é a de que os times anteriores usavam abordagens mais tradicionais para o desenvolvimento de caminhos, enquanto o deles era o de investigar quão bom era o MAPF.

Discussão

Apesar de serem bons na robótica, em jogos os campos potenciais são menos controláveis que algoritmos tradicionais de pathfinding, além de o A* possuir melhorias específicas que geram bons resultados. Além do mais, agentes navegando apenas com campos potenciais podem ficar presos em ótimos locais.

Sobre o problema de máximos locais, uma abordagem baseada na trilha de feromônios, como os usados pelas formigas, pode ajudar a resolver este problema.

A conclusão a que se chega é que é possível implementar MAPF em jogos RTS e possuir um desempenho satisfatório. No entanto, os autores afirmam que mais pesquisa é necessária sobre como soluções baseadas em MAPF devem ser realizadas.

De qualquer forma, meu foco atualmente está em estudar o ORTS e, para minha proposta de dissertação, me baseio em estudos do artigo “Using Multi-agent Potential Fields in Real-time Strategy Games” e sua árvore de pais para fazer uma prospecção sobre o assunto.

Até agora, os “pais” na hierarquia de artigos identificados são:

• The long and short of steering in computer games
• Field-based Motion Coordination In Quake 3 Arena
• Towards a Game Agent
• Co-Fields: A Physically Inspired Approach to Motion Coordination
• Intelligent Agents in Computer Games
• Learning human-link movement behavior for computer games

E basicamente é isso. Updates sobre os artigos e outras coisas em breve.

EDIT: Sobre as notas do período passado, “A” em “Projeto e Análise de Algoritmos” e “B” em “Conceitos e Projetos de Sistemas Paralelos e Distribuídos”.

“O Teatro Mágico: Segundo Ato” ´é o mais recente album de Anitelli e sua trupe. As composições escolhidas colocam em debate o homem e a sociedade na qual vive. Para Anitelli: “No primeiro cd (Entrada para Raros), a trupe estava imersa num universo paralelo, num lugar onde tudo era possível, falávamos de lutar pelos nossos ideais, pelos sonhos.

Não sei se tem alguém aí que curte, mas saiu o CD novo do Teatro Mágico, também na política “Não tem grana pra comprar? Baixe no site!” do disco anterior. Ainda estou no processo de avaliação do disco, para descobrir de quais mais e menos gosto. De uma maneira geral, gostei das melodias.

O press-release do disco está disponível em http://www.oteatromagico.mus.br/novo/discos/ e lá há um link para a trama virtual, onde se pode baixar as músicas. Aliás, esse CD conta com a participação do “inunoxidável” Zeca Baleiro na faixa Xanéu n.5, que ficou muito boa, por sinal.

Uma coisa chata é que na trama virtual é necessário fazer login pra baixar. Como não gosto disso, coloco as URLs diretas abaixo (estranhamente, basta olhar o source das páginas e achar o link direto para download. esses webmasters… tsc tsc tsc :D):

01 - Amadurecência
02 - O mérito e o monstro
03 - Cidadão de papelão
04 - Pena
05 - Opus erectus (allegro ma nem tanto)
06 - Sina Nossa
07 - Si atromiso
08 - Criado mudo
09 - Sonho de uma flauta
10 - (!)
11 - Eu não sou chico mas quero tentar
12 - #@s!?@
13 - Alguma coisa
14 - Abaçaiado
15 - Xanéu N. 5
16 - A metamorfose, ou os insetos anteriores, ou o processo
17 - A primeira semana
18 - F. Chopin (Opus 64. C#m)
19 - “…”

O site do Teatro mudou e eu preferia a versão anterior. Alguém sabe onde encontro as cifras e lestras de músicas? Ainda não achei…

Pra variar um pouco, outra vulnerabilidade no Adobe Flash foi descoberta e já está sendo explorada em vários sites. Basicamente, é possível carregar um arquivo do flash no navegador capaz de execução arbitrária de código. O arquivo malicioso faz o favor de baixar malware para máquinas de vítimas e fazer um auê danado, normalmente o alvo são usuários do Windows (novidade), mas ainda assim é um problema grave, por que eu acabo tendo que me relacionar com pessoas que usam essa coisa. Segundo o camarada do ZDnet, cerca de 20.000 páginas web já contam com esse presente de grego.

Como se não bastassem as falhas sempre descobertas no Flash, ele é um programa que só funciona decentemente no Windows e, além disso, gera um monte de problemas como impossibilidade de tradução automática de conteúdo (pois o texto não é texto, mas Flash!) ou exibição de conteúdo para pessoas com dificuldades visuais ou navegadores menos poderosos (viva o Links!). Eu sei que quase ninguém lê o blog, mas se houver algum designer ou web developer por aí, por favor NÃO USE FLASH! Ele é lento, feio e dá problemas

Na verdade verdadeira, esse lance todo de navegador web é uma coisa meio perigosa. Afinal, nós usamos um programa para acessar páginas com código de pessoas que não conhecemos executando código em nossos computadores. Ainda mais com plugins Java, JavaScript, Flash e tantos outros plugins. Eu não tenho solução pra isso, mas usar computador é um lance meio estranho, eita.

Update: Saiu no secunia. Gravidade do problema 5/5, ou “extremamente crítico”.

Mas o que mais me incomoda é que vira e mexe me mandam informações sensíveis assim, do nada (e eu até acabo passando alguns emails assim mesmo, com dados de acesso para um servidor ou outro). O interessante é que esse tipo de situação poderia ser evitado melhorando o email, ou detonando a tecnologia atual de email e começando uma nova. Sei lá, eu sei que esse lance é meio ideal mesmo, mas seria ótimo se pudéssemos usar chaves privadas e públicas para envio e recebimento de email. Ia ser legal e pouparia muitas dores de cabeça (e scams, phishing etc).

Eu ainda acho que deveria ser necessário um pouco de conhecimento para poder usar as ferramentas, sejam elas carros, computadores, fogões ou qualquer outra coisa… Oh vida.

Acontece que neste fim de semana ocorreu um encontrão de jovens ali na paróquia e, aparentemente, a missa das 19:30 foi também a missa de encerramento do encontrão (e, para completar, hoje também é a missa da Santíssima Trindade). Como era de se esperar, ao final da missa, os jovens da comunidade fizeram sua festa característica e ouvi músicas como “Ontem de manhã” (faz, pelo menos, seis anos que eu não ouvia qualquer menção dessa música), “Seu amor é demais” e “Louvado seja o meu Senhor”. Esta última, provavelmente a primeira música da Igreja que eu aprendi a tocar.

Quando começaram a dedilhar as primeiras notas de “Ontem de manhã”, pensei “nó, será que é essa música mês?” (o sotaque mineiro se apoderou de mim) e fui remetido aos tempos do encontro de adolescentes e lembrei das panelinhas e os conflitos vividos naquela época (acredite-me, foram muitos). O interessante é que eu nunca havia feito a ligação entre um pedaço de um verso da música (”Jesus Cristo, super astro”) e a obra de Andrew Loyd Weber, Jesus Christ Superstar. Claro que não tem nada a ver, mas não pude deixar de relacionar essas duas coisas.

O legal disso tudo é que, ouvindo alguns animados (e desafinados) tomarem o microfone para cantar “por todas as suas criaturas” etc. me relembrou da esperança em Deus às vezes bombardeada devido à aridez religiosa dos meios onde normalmente me encontro. Foi legal ver essa animação mais uma vez, tanto que até deu vontade de estar ali no meio da bagunça. Oh vida…

Mas, quer saber? Isso não é nostalgia no sentido estrito da palavra, só uma boa lembrança (se você não sabe a diferença, procure no dicionário :D). Afinal, ainda estou curtindo bastante as coisas e, se Deus quiser, vou passar o resto da vida gostando de jogar videogame e ficando à toa com os amigos. O problema é que isso está se tornando cada vez menos freqüente. Mas isso é uma questão de “consertar” a vida hoje e não em ficar evocando o passado.

Ficam, então, as sábias palavras do pessoal da vila do seu Barriga: “Se você é jovem ainda, amanhã velho será. A menos que o coração sustente a juventude que nunca morrerá”.

PS: Tinha nada pra fazer sábado à noite e ouvi o workshop “How to make yourself do anything”. Apesar de ser auto-ajuda, foi bem legal e foi gratuito. No final o camarada propôs a venda de uns outros kits dele (nem injeção na testa é gratuita, né?), aí eu já não ouvi mais. Mas não perdi aquelas duas horas e meia. Se estiver de bobeira, dê uma ouvida (principalmente se você tiver problemas com: lack of focus; procrastination, perfeccionism, and other self-sabotage; not knowing what to choose as a goal in the first place). “Nothing happens without a deadline”.

Some time ago I bought a macbook (I didn’t want my money to go to MS, then I preferred to “give” it to Apple) and started to use Mac OS X to see if it was as good as people said. I found out that although it is a nice OS, I still preferred Linux (slackware) + GNOME, then I installed slackware + DLG on the macbook and now I rarely boot into OSX.

While I was using that thing, I got used to the “open” command line application. Its behavior is quite simple, you type “open ” then it would figure out what was the filetype associated to that file and the default application that was supposed to open that file. Then, it would simply open the file inside that application.

Every now and then, when I was working with the command line (which tends to be VERY frequent), I remembered that the “open” command didn’t exist (at least by default) in Linux and got frustrated. I even looked for similar tools, but wasn’t able to find one. Knowing that programs like Nautilus already implemented such behavior, it was clear that it should be available to the rest of the GNOME desktop.

Well, I was lucky, as gnomevfs implemented everything I needed to create my own “open” command. The only hard part was to figure out what the functions did, since they were mostly undocumented.

I don’t know if anybody is interested in such an application, but since I wrote mine (in a quick, dirty and undocumented way) and found it useful, I thought that it would be nice to share it. If you want to take a look at it, please check http://dlg64.redos.si/trac/browser/open/trunk/open, download it to your PC, make it executable and run it.

O artigo inicia dizendo que existe uma “moda” em usar ambientes de simulação como benchmarks que habilitam a avaliação desses sistemas em diferentes cenários de testes. O RTSCup, por sua vez, se encaixa nesse grupo de ferramentas para avaliação de diversas técnicas de inteligência artificial para implementação de times como sistemas multiagentes.

Após isso, o artigo justifica o uso de RTS como sistemas multiagentes por serem atraentes do ponto de vista da inteligência artificial, principalmente por que o time deve considerar:

• O ambiente do jogo;
• A limitação de percepção dos jogadores através da neblina de guerra;
• Raciocínio sobre personagens com diferentes funções.

Além disso:

• cada agente possui informação incompleta sobre o problema;
• não existe um sistema de controle global;
• os dados são descentralizados;
• a computação é assíncrona

No artigo também é citado que o uso de benchmarks não é recomendado para avaliação de sistemas de múltiplos agentes, mas justifica o uso de simuladores de RTS como úteis para avaliação de técnicas de IA e novos algoritmos. Também comenta sobre a competição RoboCup Rescue.

Sobre as vantagens do uso de RTS como benchmarks, se destacam a necessidade de uma inteligência capaz de encontrar caminhos, patrulhar, alocar recursos, prever ações, coordenar tarefas e o processo de tomada de decisões táticas e estratégicas.

Depois, o artigo apresenta os simuladores e competições principais, avalia seus pontos fortes e fracos e, com isso, justifica a criação do projeto RTSCup como alternativa aos existentes.

A partir daí, é apresentado o projeto, sua arquitetura e tudo o mais. São apresentados os diversos simuladores comuns a jogos RTS. Apesar de o artigo dizer que todos os times em um jogo RTS possuem uma religião, isso não é bem verdade, pois em jogos como Command & Conquer, esse fator não está presente.

A arquitetura do RTSCup parece ser interessante e flexível e, provavelmente, é escalável, constituindo um bom projeto. Da maneira como foi implementado, os clientes podem ser escritos em qualquer linguagem, dando grande flexibilidade aos pesquisadores. Os jogos também possuem características parametrizadas, facilitando a criação de novos ambientes de simulação.

Perguntas sem respostas

• Apesar de apresentar deméritos dos outros sistemas de RTS, esse artigo não apresenta quão bem o RTSCup se compara aos outros;
• O artigo fala muito pouco sobre como o RTSCup pode ser usado e fala pouco sobre sua interface de programação;
• Também não deixa claro qual o nível de granularidade usado para programar um agente do ambiente.

Link para o artigo.

Notas

[1] O SBGAMES é um simpósio brasileiro e os autores do artigo também são. Ainda assim, o artigo foi escrito em um “inglês” que poderia ser melhor escrito do que efetivamente foi. Isso prejudicou em muito minha leitura, pois ela não fluiu de maneira suave - outro artigo que sofre do mesmo problema é o “RTSAI: a game tool for IA research”, que terminarei de ler caso tenha paciência para suportá-lo

Segundo resultados apresentados, o algoritmo proposto consegue coordenar um grande número de agentes diferentes de maneira integrada e escalável. Para isso, eles usaram três idéias:

• Encapsular todas as interações de coordenação, inclusive informações, tarefas e recursos compartilhados, em tokens;
• Os agentes usam modelos locais de decisão para determinar quando e como passar os tokens (para isso eles modelam um processo de decisão de Markov parcialmente observável);
• Usar toda a informação disponível para a criação de modelos do time, especificamente usando o movimento de um token para informar o movimento de outros tokens.

Para resolver o problema de coordenação em larga escala, os pesquisadores usaram uma “rede de conhecidos” (um agente conhece apenas poucos agentes e suas interações de tokens se darão entre estes e esse). Também apresentam o algoritmo desenvolvido para modelagem do raciocínio dos agentes, fazem referências à matemática usada por eles e apresentam os resultados experimentais.

Link para o artigo

Além de possuir algumas referências interessantes que aumentam a base de conhecimento em planejamento de personagens, Orkin discute as considerações que devem ser feitas quando se projeta NPCs que planejam em tempo real. Todas as considerações são feitas baseadas nas experiências vividas no desenvolvimento do jogo.

Alguns resultados interessantes foram obtidos, como em situações do jogo, membros de um esquadrão preferirão atender a um objetivo de prioridade mais alta que tentar responder ao chamado do esquadrão. Como exemplo, um NPC preferirá correr de uma granada prestes a explodir para salvar sua vida a mander a formação para cobrir um aliado.

De uma maneira geral, a arquitetura dos agentes é composta de um “quadro negro” (que eu ainda não sei o que é), sua memória, um conjunto de subsistemas e alguns sensores. Os sensores são arquiteturados tanto como dirigidos por eventos quanto usando polling. Dependendo da aplicação.

Para computação, o planejador de tarefas usa sensores para amortizar o custo de operações computacionais caras por muitos quadros e armazenas os resultados na memória corrente. Orkin também discute os erros cometidos durante o projeto do jogo e a implementação corrente.

Além de distribuir o processamento, os agentes realizam cache das computações como fatos na memória para evitar que computações caras sejam repetidas de maneira desnecessária.

Além disso, os agentes são modelados com valores de confiança para poder ponderar sobre os fatos, possuem conhecimento centralizado, coleta de lixo de memória, usam planejamento usando o algoritmo A*, discutem sobre as dependências entre ações que os agentes podem executar para que seu raciocínio seja correto e apresenta exemplos de como os agentes refazem seu planejamento.

Link para o artigo.

No artigo são descritos os experimentos, os marcos visuais (gerados pela biblioteca ARToolkiPlus), o software distribuído usado para a localização dos robôs e as conclusões de que os experimentos demonstraram um alto nível de exatidão e de que o uso de marcos visuais geométricos permitiu o desenvolvimento de um sistema de localização escalável.

Link para o programa do evento onde foi publicado.

Três conceitos são discutidos no artigo: modelos comportamentais (os programas que funcionam como cérebros dos personagens autônomos), estruturas de dados espaciais usadas para acelerar as consultas de localidade e técnicas usadas para conduzir a animação a partir dos modelos comportamentais. Neste artigo, Reynolds também apresenta um estudo de caso, chamado Pigeons in the park.

Reynolds também apresenta as estruturas de dados usadas para representar os pombos de seu estudo de caso e descreve seu projeto. Como em artigos anteriores, usando massas pontuais para facilitar a simulação. Descreve que os personangens de Pigeons in the Park reagem ao usuário de duas maneiras: com reações contínuas e discretas. Na forma contínua, os pombos tentam estar sempre distantes do veículo do usuário. Na maneira discreta, os pombos reagem a estímulos como o bater de palmas, que causam a dispersão do bando.

Reynolds também discute sobre o tempo das reações dos personagens e a área de efeito gerada pelo personagem do jogador. Também faz uma discussão sobre o desempenho em tempo real da simulação como um todo. Discute sobre quais quadros são habilitados com raciocínio dos pombos e as consultas de localidade, apresentando sua técnica de particionamento do espaço.

Link para o artigo.

Reynolds define o agente estudado no artigo e descreve outros tipos de agentes possíveis. Também apresenta a hierarquia de comportamentos de movimentação, divididos em três níveis:

1. Seleção de ação: estratégia, objetivos e planejamento
2. Guia: determinação de caminho
3. Locomoção: animação e articulação

Este artigo foca na camada número 2 (traduzida por mim como guia, mas deve existir uma tradução melhor para Steering).

Reynolds também apresenta trabalhos relacionados nos ramos de robótica, inteligência artificial e vida artificial e depois parte para a discussão da locomoção, onde apresenta seu modelo de “veículo”, que possui massa, posição, velocidade, força máxima, velocidade máxima e orientação e é pontual, portanto não possui dimensões.

Depois, Reynolds parte para apresentar os comportamentos de guia (com nomes em inglês): Seek, Flee, Pursuit, Evasion, Offset pursuit, Arrival, Obstacle avoidance, wander, Path following, explore, forage, wall following, flow field following, separation, cohesion, alignment, flocking e leader following. Depois, trata sobre a combinação de comportamentos e, por fim, conclui.

Sobre esse artigo, vale a pena dizer que o livro AI Game Programming by example, de Matt Buckland, possui implementações desses comportamentos e pode ser uma fonte melhor nesse sentido.

Link para o artigo.

Tags: flocking, steering, artificial life, artificial intelligence