UNIVERSIDADE DE LISBOA

Transcrição

1 UNIVERSIDADE DE LISBOA Faculdade de Ciências Departamento de Informática VIDEO JOGOS EVOLUTIVOS Rui Guilherme Mendes Esteves Nogueira PROJECTO MESTRADO EM ENGENHARIA INFORMÁTICA Especialização em Arquitetura, Sistemas e Redes de Computadores 2013

2

3 UNIVERSIDADE DE LISBOA Faculdade de Ciências Departamento de Informática VIDEO JOGOS EVOLUTIVOS Rui Guilherme Mendes Esteves Nogueira PROJECTO MESTRADO EM ENGENHARIA INFORMÁTICA Especialização em Arquitetura, Sistemas e Redes de Computadores Trabalho orientado pelo Prof. Doutor Luís Manuel Ferreira Fernandes Moniz e pelo Prof. Doutor Paulo Jorge Cunha Vaz Dias Urbano 2013

4

5 Agradecimentos Em primeiro lugar, gostaria de agradecer aos melhores Pais do mundo, que com muito amor, esforço e dedicação sempre me mantiveram no bom caminho (a bem ou a mal), sem que nunca nada me faltasse. Agradeço aos meus dois irmãos, Raquel e David que sempre foram uma inspiração a seguir e são o motivo do meu maior orgulho. Aos meus tios, que nunca conseguirei agradecer por tudo o que fizeram por mim. Aos meus avós, que nunca deixaram e nunca deixaram de estar presentes na minha vida. Quero agradecer ao meu amigo e colega João Gomes, que não só fez a loucura de aceitar o meu desafio de vir fazer o mestrado comigo, como me acompanhou durante este longo e tortuoso caminho, e que apesar dos brutais sacrifícios que tivemos de fazer nunca vacilou. Nunca teria chegado até aqui sem o teu apoio e companheirismo. Agradeço aos meus dois orientadores Prof. Luís Moniz e ao Prof. Paulo Urbano por me orientarem neste projeto e se mostrarem sempre disponíveis para ajudar e contribuir para o sucesso deste. Em especial, ao Prof. Luís Moniz, que sempre que precisei encontrei uma porta aberta e uma disponibilidade e apoio louváveis. Ao meu grande amigo, colega do JACK ASS e parceiro do crime, Hélder Gil, pela sua amizade ao longo destes anos todos. Agradeço aos meus amigos de faculdade, que durante a licenciatura colaboraram comigo no estudo e na execução de dezenas de projetos e noitadas loucas de estudo. Agradeço em particular ao Alentejano, Gadelhudo, Partnere, Gordo, Mais velho, Pato, Diogo Simões, Eduardo, Reis e Rui Teixeira. A vossa amizade e o companheirismo que construímos durante este tempo foram muito importantes para mim e que nunca irei esquecer. A dedicação e espírito de grupo fantástico que empregamos em tudo o que fizemos, apoiando-nos e motivando-nos uns aos outros, resultou num percurso académico exemplar à custa também de muito esforço e dedicação. Aos meus colegas de trabalho que me apoiaram e me ajudaram todos os dias da semana, todas as semanas do mês e todos os meses do ano Por fim, mas de maneira nenhuma menos importante, pelo contrário, um muito obrigado à minha amiga, confidente, amante, paixão e namorada Marlene de Jesus. Que

6 devido à minha falta de tempo, sacrificou-se e me aturou ao longo destes anos todos. Nunca poderei compensar o teu apoio, dedicação e sorriso, que nunca me deixaram fraquejar. Pronto também agradeço aos gatos Mojo Jojo Smeagol e Leia Chacha - As Bestas da Destruição! A todos estes e aos demais que de alguma forma direta ou indireta possam ter contribuído para o meu sucesso, o meu mais sincero obrigado!

7

8 A todos aqueles que não são especialmente dotados ou talentosos, mas que possuem algo bem mais valioso, perseverança e força de vontade

9

10 Resumo Num jogo de computador, o requisito mais básico de um agente artificial é ser capaz de navegar no ambiente do jogo. O sistema de navegação é responsável por fornecer o melhor caminho entre dois pontos no ambiente e pela movimentação do agente através do caminho com a possibilidade de correção e redefinição do mesmo. Este trabalho propõe um processo de geração automática da representação espacial de ambientes de jogo dinâmicos suportados em grelha, procura do melhor caminho e movimentação do agente artificial ao longo do caminho Palavras-chave: Jogos de vídeo, geração processual de conteúdo, representação do ambiente, grafos de navegação, grafos em grelha, quadtree, algoritmos de procura A*, algoritmos de procura Fringe Search, inteligência artificial. i

11 ii

12 Abstract In a computer game, the most basic requirement of a non-player character is to be able to navigate through the game environment. The navigation system has to provide the best path between to points in the environment, the actual movement through the path and deal with eventual correction and redefinition of the path. Our proposal is to design a process to generate a grid supported by the spatial representation of a dynamic environment, search for the best path, and construct the movement sequence of a NPC over the path. Keywords: Video games, procedural content generation, environment representation, navigation graphs, graphs based on grid, quadtree, search algorithms A*, Fringe search, artificial intelligence. iii

13 iv

14 Conteúdo Capítulo 1 Introdução Motivação Objetivos Contribuições Enquadramento institucional Organização do documento Sumário... 5 Capítulo 2 Trabalho relacionado Geração processual de conteúdo Vantagens Desvantagens Aproximações híbridas Características Sistema de navegação Locomoção Representação do ambiente Algoritmos de procura em grafos Sumário Capítulo 3 Metodologia de investigação Delineamento do estudo Questões e hipóteses de investigação Material e Métodos Caracterização da amostra Instrumentos Procedimentos Metodologia estatística Sumário v

15 Capítulo 4 Trabalho realizado Análise do problema Geração automática e em tempo de execução de grafos Ambientes de jogo com dimensões diferentes Múltiplos agentes Diferentes tipos de unidades Deteção de obstáculos dinâmicos Desenho da solução Sistema de navegação Implementação Sistema de navegação Ferramenta de prova de conceito Ferramenta de avaliação Sumário Capítulo 5 Resultados Apresentação de resultados Inicialização da camada de representação do ambiente Inicialização da camada de procura de caminhos Adição de objetos antes do início do jogo Tamanho do espaço de pesquisa Quantização Localização Procura de caminho Conexão de vizinhos Adição de objeto Sumário Capítulo 6 Discussão de resultados e conclusão Discussão de resultados Conclusão vi

16 6.3 Limitações Trabalho futuro Bibliografia vii

17 viii

18 Lista de Figuras Ilustração 1 - Sistema de navegação e as suas componentes Ilustração 2 - Ambiente de jogo base Ilustração 3 - Grafo de navegação baseado em pontos de passagem Ilustração 4 - Grafo de navegação baseado em pontos de visibilidade Ilustração 5 - Grafo de navegação baseado em pontos de visibilidade com geometria expandida Ilustração 6 - Geometria das conexões das células em grelha Ilustração 7 - Grafo de navegação baseado em grelha com células quadradas Ilustração 8 - Grafo de navegação baseado em grelha com células hexagonais Ilustração 9 - Quadrantes e quadtree correspondente Ilustração 10 - Grafo de navegação baseado em quadtree Ilustração 11 - Grafo de navegação baseado em quadtree inválido Ilustração 12 - Ambiente de jogo subdividido em polígonos navegáveis Ilustração 13 - Grafo de navegação baseado em malha de navegação Ilustração 14 - Algoritmo de procura Dijkstra's Ilustração 15 - Algoritmo de procura melhor-primeiro Ilustração 17 - Algoritmo de procura A* Ilustração 18 - Logotipo do Blender Ilustração 19 - Logotipo do jmonkey Engine Ilustração 19 - Logotipo do Ogre Ilustração 20 - Logotipo do Panda3D Ilustração 21 - Logotipo do Torque Game Engine Ilustração 22 - Logotipo do Unreal Development Kit Ilustração 23 - Logotipo do Unity Ilustração 24 - Menu de configuração Ilustração 26 - Arquitetura subdividida em três módulos distintos Ilustração 26- Exemplo de abstração multidimensional da grelha e atribuição de Id's para cada célula Ilustração 27 - Exemplo de abstração linear da grelha e atribuição de Id's para cada célula Ilustração 28 - Determinação de vizinhos do nó (i, j) Ilustração 29 - Disposição dos vizinhos do nó (i, j) num array linear Ilustração 31 Conversão do número Morton (Id) na coordenada x e z Ilustração 32 - Simulação de 600 NPC s com esquema de divisão baseado em Grelha e algoritmo de procura A* Ilustração 33 - Simulação de 2 NPC s com o esquema de divisão baseado em quadtree e algoritmo de procura Fringe Search Ilustração 34 - Média do tempo de processamento na inicialização da camada de representação do ambiente: Esquema de divisão Vs. Dimensão do ambiente Ilustração 35 - Gráfico do consumo de memória na inicialização da camada de representação do ambiente: Esquema de divisão Vs. Dimensão do ambiente Ilustração 36 - Gráfico do tempo de processamento na inicialização da camada do algoritmo de procura em grafos: Algoritmo de procura em grafos Vs. Dimensão do ambiente Ilustração 37 - Gráfico do tempo de processamento na inicialização da camada do algoritmo de procura em grafos no modo de execução com threadpool: Algoritmo de procura em grafos Vs. Dimensão do ambiente Ilustração 38 Gráfico da média do consumo do tempo de processamento na adição de objetos antes da execução do jogo: Esquema de divisão Vs. Dimensão do ambiente Ilustração 39 - Gráfico da média do consumo do tempo de processamento na adição de objetos antes da execução do jogo no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente Ilustração 40 - Gráfico da média do tamanho do espaço de procura: Esquema de divisão Vs. Dimensão do ambiente Ilustração 41 - Gráfico da média do tempo de processamento na localização: Esquema de divisão Vs. Dimensão do ambiente Ilustração 42 - Gráfico da média do tempo de processamento na localização: Esquema de divisão Vs. Densidade de objetos Ilustração 43 - Gráfico da média do tempo de processamento na quantização no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente ix

19 Ilustração 44 - Gráfico da média do tempo de processamento na quantização no modo de execução com threadpool: Esquema de divisão Vs. Densidade de objetos Ilustração 45 - Gráfico da média do tempo de processamento na localização: Esquema de divisão Vs. Dimensão do ambiente Ilustração 46 - Gráfico da média do tempo de processamento na localização no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente Ilustração 47 - Gráfico da média dos resultados do nº de nos visitados na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente Ilustração 48 - Gráfico da média dos resultados do nº de nos visitados na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente Ilustração 49 - Gráfico da média dos resultados do nº de nos visitados na procura de caminho: Algoritmo de procura Vs. Densidade de objetos Ilustração 50 Gráfico da média dos resultados do nº de nós expandidos na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente Ilustração 51 - Média dos resultados do nº de nós expandidos na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente Ilustração 52- Gráfico da média do tempo de processamento na procura de caminho no modo de execução: Esquema de divisão Vs. Dimensão do ambiente Ilustração 53 - Gráfico da média do tempo de processamento na procura de caminho: Esquema de divisão Vs. Densidade de objetos Ilustração 54 Gráfico da média dos resultados do tempo de processamento na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente Ilustração 55 Gráfico da média dos resultados do tempo de procura de caminho: Algoritmo de procura Vs. Densidade de objetos Ilustração 56 - Gráfico da média dos resultados do tempo de processamento na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente no modo de execução com threadpool Ilustração 57 - Gráfico da média dos resultados do tempo de procura de caminho: Esquema de divisão Vs. Densidade de objetos no modo de execução com threadpool Ilustração 58 - Gráfio da média dos resultados do tempo de processamento na procura de caminho no modo de execução com threadpool: Algoritmo de procura Vs. Dimensão do ambiente Ilustração 59 - Gráfico da média dos resultados do tempo de procura de caminho no modo de execução com threadpool: Algoritmo de procura Vs. Densidade de objetos Ilustração 60 - Gráfico da média do tempo de processamento da conexão de vizinhos: Esquema de divisão Vs. Dimensão do ambiente Ilustração 61 - Gráfico da média do tempo de processamento da conexão de vizinhos no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente x

20 xi

21 Lista de Tabelas Tabela 1 - Esquema de divisão de grafos de navegação baseados pontos de visibilidade Tabela 2 - Esquema de divisão de grafos de navegação baseados em grelha Tabela 3 - Esquema de divisão de grafos de navegação baseados em grelha Tabela 4 - Esquema de divisão de grafos de navegação baseados em malha de navegação Tabela 5 - Tamanho mínimo da célula e número máximo de nós com base no tamanho do ambiente Tabela 6 - Tamanho do ambiente e densidade de objetos no ambiente de jogo Tabela 7 - Objetivos vs. tipo de esquema de divisão Tabela 8 - Lista de atributos físicos de um NPC usados pela camada de locomoção Tabela 9 - Lista de atributos de procura de caminho de um NPC usados pela camada de locomoção Tabela 10 - Lista de atributos comportamentais de um NPC usados pela camada de locomoção Tabela 11 - Lista de variáveis auxiliares usadas na camada locomoção Tabela 12 - Pseudo-código da rotina de pedido de resolução de caminho da camada locomoção Tabela 13 - Pseudo-código do ouvinte de eventos de resposta de caminhos da camada locomoção Tabela 14 - Pseudo-código da rotina de determinação do próximo movimento do NPC Tabela 15 - Métodos suportados pelo gestor da camada de representação do ambiente Tabela 16 - Quadrantes e código de orientação Tabela 17 - Lista de atributos do gestor da camada de algoritmos de procura em grafos Tabela 18 - Lista de métodos do gestor da camada de algoritmos de procura em grafos Tabela 19 - Lista de atributos do algoritmo de procura em grafos genérico Tabela 20 - Lista de métodos do algoritmo de procura em grafos genérico Tabela 21 - Lista de atributos da estrutura de pedido de resolução de caminho Tabela 22 - Lista de atributos da estrutura de resposta de resolução de caminho Tabela 23 - Pseudo-código do método FindPath para o algoritmo de procura em grafos A* Tabela 24 - Pseudo-código do método DoIteration para o algoritmo de procura em grafos A* Tabela 25 - Pseudo-código do método FindPath para o algoritmo de procura em grafos Fringe Search* 85 Tabela 26 - Pseudo-código do método DoIteration para o algoritmo de procura em grafos Fringe Search* Tabela 27 - Parâmetros que compõe uma entrada do ficheiro XML Tabela 28 - Operações suportadas pela ferramenta de avaliação Tabela 29 - Especificação de ambiente de testes Tabela 30 - Resultados do tempo de processamento na inicialização da camada de representação do ambiente Tabela 31 - Média do tempo de processamento na inicialização da camada de representação do ambiente: Esquema de divisão Vs. Dimensão do ambiente Tabela 32 - Resultados do consumo de memória na inicialização da camada de representação do ambiente Tabela 33 - Média do consumo de memória na inicialização da camada de representação do ambiente: Esquema de divisão Vs. Dimensão do ambiente Tabela 34 - Resumo dos resultados da inicialização da camada de representação do ambiente no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente Tabela 35 - Resultados do tempo de processamento na inicialização da camada de procura de caminhos Tabela 36 - Média do tempo de processamento na inicialização camada de procura de caminhos: Algoritmo de procura em grafos Vs. Dimensão do ambiente Tabela 37 - Resultados do consumo de memória na inicialização da camada de procura de caminhos Tabela 38 - Média os resultados do consumo de memória na inicialização da camada de procura de caminhos Tabela 39 - Resultados do tempo de processamento na inicialização da camada de procura de caminhos no modo de execução com threadpool Tabela 40- Média do tempo de processamento na inicialização da camada de procura de caminhos no modo de execução com threadpool: Algoritmo de procura vs. dimensão do ambiente de jogo Tabela 41 - Resultados do consumo de memória na inicialização da camada de procura de caminhos no modo de execução com threadpool Tabela 42 Média dos resultados do consumo de memória na inicialização da camada de procura de caminhos no modo de execução com threadpool Tabela 43 - Resultados do tempo de processamento na adição de objetos antes do início do jogo xii

22 Tabela 44 - Média do consumo do tempo de processamento na adição de objetos antes do início do jogo: Esquema de divisão Vs. Dimensão do ambiente Tabela 45 - Média do tempo de processamento na adição de objetos antes do início do jogo: Esquema de divisão Vs. Densidade de objetos Tabela 46 - Resultados do tempo de processamento na adição de objetos antes do início do jogo no modo de execução com threadpool Tabela 47 - Média do tempo de processamento na adição de objetos antes do início do jogo no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente Tabela 48- Média do tempo de processamento na adição de objetos antes do início do jogo no modo de execução com threadpool: Esquema de divisão Vs. Densidade de objetos Tabela 49 - Número máximo de nós por dimensão de ambiente e por densidade de objetos Tabela 50 - Resultados do tamanho do espaço de pesquisa Tabela 51 Média dos resultados do tamanho do espaço de pesquisa: Esquema de divisão Vs. Dimensão do ambiente Tabela 52 - Resultados do tempo de processamento na quantização Tabela 53 Média dos resultados do tempo de processamento na quantização: Esquema de divisão Vs. Dimensão do ambiente Tabela 54 - Média dos resultados do tempo de processamento na quantização: Esquema de divisão Vs. Densidade de objetos Tabela 55 - Resultados do tempo de processamento na quantização no modo de execução threadpool Tabela 56 Média dos resultados do tempo de processamento na quantização no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente Tabela 57 - Média dos resultados do tempo de processamento na quantização no modo de execução com threadpool: Esquema de divisão Vs. Densidade de objetos Tabela 58 - Resultados do tempo de processamento na localização Tabela 59 Média dos resultados do tempo de processamento na localização: Esquema de divisão Vs. Dimensão do ambiente Tabela 60 - Resultados do tempo de processamento na localização no modo de execução com threadpool Tabela 61 - Média dos resultados do tempo de processamento na localização no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente Tabela 62 - Nº nós visitados na procura de caminho Tabela 63 - Média dos resultados do nº de nos visitados na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente Tabela 64 - Média dos resultados do nº de nos visitados na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente Tabela 65 - Média dos resultados do nº de nos visitados na procura de caminho: Algoritmo de procura Vs. Densidade de objetos Tabela 66 - Média dos resultados: Esquema de divisão vs. Algoritmo de procura Tabela 67 - Nº nós expandidos na procura de caminho Tabela 68 - Média dos resultados do nº de nós expandidos na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente Tabela 69 - Média dos resultados do nº de nós expandidos na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente Tabela 70 Custo e tamanho do caminho na procura de caminho Tabela 71 - Resultados do tempo de processamento na procura de caminho Tabela 72 Média dos resultados do tempo de processamento na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente Tabela 73 - Média dos resultados do tempo de procura de caminho: Esquema de divisão Vs. Densidade de objetos Tabela 74 Média dos resultados do tempo de processamento na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente Tabela 75 - Média dos resultados do tempo de procura de caminho: Algoritmo de procura Vs. Densidade de objetos Tabela 76 - Resultados do tempo de processamento na procura de caminho no modo de execução threadpool Tabela 77 Média dos resultados do tempo de processamento na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente no modo de execução threadpool Tabela 78 - Média dos resultados do tempo de procura de caminho: Esquema de divisão Vs. Densidade de objetos no modo de execução com threadpool xiii

23 Tabela 79 Média dos resultados do tempo de processamento na procura de caminho no modo de execução com threadpool: Algoritmo de procura Vs. Dimensão do ambiente Tabela 80 - Média dos resultados do tempo de procura de caminho no modo de execução com threadpool: Algoritmo de procura Vs. Densidade de objetos Tabela 81 - Resultados do tempo de processamento na conexão de vizinhos Tabela 82 - Média dos resultados na conexão de vizinhos: Esquema de divisão Vs. Dimensão do ambiente Tabela 83 - Resultados do tempo de processamento na conexão de vizinhos no modo de execução com threadpool Tabela 84 Média de resultados do tempo de processamento na conexão de vizinhos no modo de execução com threadpool Tabela 85 - Resultados do tempo de processamento de adição de objeto Tabela 86 - Média dos resultados de adição de objeto: Esquema de divisão Vs. Dimensão do ambiente Tabela 87 - Média dos resultados do tempo adição de objeto: Esquema de divisão Vs. Densidade de objetos Tabela 88 - Resultados do tempo de processamento de adição de objeto no modo de execução com threadpool Tabela 89 Média dos resultados do tempo de processamento de adição de objeto no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente xiv

24 xv

25 Lista de Equações Equação 1 - Cálculo do custo de n Equação 2 Tamanho do espaço de procura em grelhas Equação 3 - Profundidade máxima em quadtree Equação 4 Tamanho mínimo da célula em quadtree Equação 5 Id em grelha Equação 6 - Obtenção da coluna através do Id Equação 7 - Obtenção da coluna através da coordenada x Equação 8 - Obtenção da linha através do Id Equação 9 - Obtenção da linha através da coordenada z Equação 10 Obtenção da coordenada x Equação 11 - Obtenção da coordenada z Equação 12 - Determinação do espaço de procura numa Quadtree Equação 12 - Determinação de Id de um nó da quadtree Equação 14 Obtenção de h(n) xvi

26 Capítulo 1 Introdução 1.1 Motivação Cada vez mais os jogos de vídeo têm-se assumido como o instrumento preferido de diversão do ser humano, abrangendo uma faixa etária cada vez mais alargada. Da guerra à estratégia, passando pelo desporto e pela aventura, a aproximação do mundo virtual dos jogos de vídeo à realidade é cada vez maior. Os jogos de vídeo não só disponibilizam um leque alargado de escolhas, como também a forma a que chegam ao utilizador é bastante diversificada (computador pessoal, telemóveis, televisão inteligente, baseados na web, entre outros). O facto de uma grande variedade de meios digitais poderem ser usados para disponibilizar e comercializar jogos de vídeo, levou a que no ano de 2012, a comercialização de vídeo jogos tenha ultrapassado os lucros da indústria de cinema de Hollywood, com uma previsão de aumento de lucros para os próximos anos. Ao sucesso dos jogos de vídeo comerciais, está ligada à sua capacidade de diversão, que depende da sua jogabilidade e do seu realismo, e é também consequência direta da qualidade da imersão e experiência de jogo proporcionada ao utilizador. O desenvolvimento de um vídeo jogo comercial demora bastante tempo e implica um investimento de milhões de euros. A maior parte do tempo de desenvolvimento é despendida na criação de cenários realistas e de mecânicas de jogo. O aumento da exigência dos consumidores por conteúdos multimédia de larga escala, sem que seja comprometido o detalhe gráfico e o realismo, obrigam a indústria de desenvolvimento de jogos a procurar formas alternativas de desenvolvimento e distribuição, para isso, é necessário automatizar processos e diminuir o tempo de desenvolvimento. As técnicas de geração processual de conteúdo (PCG) têm-se destacado como uma alternativa na geração automática de conteúdos em larga escala e a baixo preço. A sua oferta de conteúdos em quantidade, qualidade e diversidade é quase ilimitada. Contudo, não basta apenas gerar conteúdos, é necessário continuar a assegurar o realismo e a jogabilidade do jogo de vídeo. 1

27 Deste modo, a inteligência artificial de um jogo torna-se um fator preponderante no realismo e jogabilidade, uma vez que grande parte do sucesso dos jogos de vídeo está ligada à satisfação do jogador de ganhar à máquina e, mais atualmente, a cooperação com esta para alcançar e superar objetivos (Kishimoto & Artificial, 2004). É necessário então assegurar que os agentes inteligentes artificiais (Jogadores Não Humano Non Player Character - NPC) consigam interagir corretamente com os conteúdos gerados pela PCG, principalmente se o conteúdo gerado é um cenário. O NPC tem como requisito básico, movimentar-se corretamente dentro do ambiente de jogo, recorrendo ao sistema de navegação para isso. O sistema de navegação de um NPC pode ser dividido em dois componentes principais: a locomoção, responsável pelo movimento físico do agente no ambiente do jogo; e o pathfinding, responsável pela procura de caminhos válidos entre dois pontos. Este último componente, pathfinding, pode ser decomposto em duas componentes: a representação do ambiente de jogo e as técnicas de procura de caminho (Anguelov, 2011). O problema do pathfinding é comum a outras áreas de estudo, tais como a de redes e a de robótica. Contudo, enquanto os fundamentos da representação do ambiente são similares, as técnicas de procura estão sujeitas aos requisitos de tempo real de múltiplos agentes resultando no aumento de limitações a este problema (Anguelov, 2011). Apesar de existir uma literatura alargada sobre pathfinding, esta não está direcionada para a representação do meio ambiente e à procura de caminhos em ambientes sem processamento prévio e dinâmico. 1.2 Objetivos O principal objetivo deste estudo é explorar e rever um conjunto de técnicas de pathfinding que possam ser aplicadas de forma automática (sem qualquer intervenção do jogador ou programador), e as quais ofereçam um desempenho suficiente para serem usadas em tempo de execução, com vista à navegação de agentes artificiais. É pretendido, desta forma, suportar a geração processual no momento de ambientes de jogos de vídeo. A solução deve ainda cumprir com os seguintes requisitos principais: suportar múltiplos agentes; suportar diferentes tamanhos de ambientes de jogo, sem aparente redução do desempenho do jogo de vídeo; possibilitar a deteção de obstáculos estáticos e dinâmicos. Foi ainda estabelecido como requisitos secundários que a solução explorada deve: 2

28 suportar ambientes de relevo diferenciado; suportar diferentes tipos de unidades (ex.: agentes de diferente tamanho). Os objetivos e requisitos desta investigação limitam consideravelmente as técnicas que podem ser utilizadas. Embora possam ser feitas algumas alterações e melhorias às técnicas empregues, não é o objetivo deste estudo inovar qualquer técnica em particular, mas sim articular um conjunto de "técnicas de estado da arte" e verificar e comparar os seus resultados, de acordo com os objetivos e requisitos descritos. Tendo em conta que não é possível encontrar uma solução geral ideal para todos os casos, é objetivo deste estudo o desenvolvimento de uma solução que possa ser empregue de forma satisfatória à generalidade das situações. 1.3 Contribuições A contribuição primária deste estudo é a compreensão sobre a problemática da navegação de agentes em ambientes de jogo dinâmicos, e com cenários de diferentes dimensões, em que a impossibilidade de usar técnicas que envolvem pré-processamento agrava consideravelmente o problema de gerir a navegação de agentes em ambientes de grande dimensão. Este desafio assume uma maior relevância quando se observa que, ano após ano, os ambientes de jogo aumentam em detalhe visual, tamanho e complexidade. Por outro lado, o objetivo de suportar a geração processual de conteúdos (PCG) nomeadamente de ambientes de jogos de vídeo, procura: diminuir o tempo e custos envolvidos no desenvolvimento dos jogos de vídeo; aumentar a longevidade e variedade de jogos; suportar novos paradigmas da tecnologia (tecnologia móvel e baseada na web); Para além das contribuições associadas à PCG, a pesquisa bibliográfica demonstra que a maioria da bibliografia direcionada aos jogos de vídeo não é suportada em dados científicos, mas sim na experiência de programadores de vídeo jogos. Em parte, este fenómeno pode ser explicado pelo facto de o conhecimento não ser partilhado pelas empresas que desenvolvem jogos de vídeo comerciais. Desta forma, este estudo procura dar uma maior relevância à área e contribuir de alguma forma para uma melhor compreensão da temática, nomeadamente: fornecer uma visão alargada do estado atual do pathfinding em vídeo jogos, sobre este tópico; o uso maioritário do algoritmo de procura em grafos A* (Hirt, Gauggel, Hensler, Blaich, & Bittel, 2011) e algoritmos de procura que envolvem pré- 3

29 processamento faz com que existam poucas informações sobre soluções que explorem outras técnicas. Este estuda visa colmatar essa lacuna; fornecer dados exploratórios e comparativos entre diversas técnicas de representação de ambiente de jogo e algoritmos de procura em grafos; a bibliografia muitas vezes fala de técnicas e procedimentos sem fornecer dados e detalhes de implementação (ex.: algoritmo Fringe Search e a determinação de vizinhos numa quadtree). Este estudo visa fornecer dados e detalhes concretos de implementação de um sistema de navegação de agentes; demasiadas vezes os estudos referem uma técnica inovadora, falhando posteriormente em estudos de replicação e comparação de dados. Pretendemos fornecer dados relativos ao algoritmo de procura em grafo Fringe Search. Queremos enfatizar a importância dos dados colhidos do algoritmo Fringe Search com estrutura de dados quadtree. Outro aspeto importante da avaliação é a comparação dos resultados, entre usar uma ou mais threads nas instâncias de pathfinding. Procuramos fornecer dados válidos para esta questão, uma vez que este assunto ainda levanta algum debate dentro da comunidade do desenvolvimento de jogos. 1.4 Enquadramento institucional Projeto realizado em regime externo à faculdade com o suporte do LabMAg, Laboratório de Modelação de Agentes Inteligentes, uma das unidades de investigação do Departamento de Informática da Faculdade de Ciências da Universidade de Lisboa. Ao longo da realização do presente trabalho foram realizadas diversas reuniões de supervisão sob a orientação atenta do Prof. Doutor Luís Manuel Ferreira Fernandes Moniz e do Prof. Doutor Paulo Jorge Cunha Vaz Dias Urbano. 1.5 Organização do documento A organização do documento segue a estrutura especificada pela cadeira de projeto em que a presente investigação se insere. O documento está organizado da seguinte forma: Capítulo 1 introdução ao tema, onde são expostas as motivações, objetivos e contribuições dos autores para a conceção do presente estudo. É ainda feito um enquadramento institucional e resumo do trabalho realizado. Capítulo 2 apresentação de trabalhos e investigações, relevantes e atuais, ao campo de estudo da investigação. Este capítulo encontra-se dividido em dois 4

30 subcapítulos. O primeiro subcapítulo é introdutório à geração processual de conteúdo. O segundo subcapítulo aborda o sistema de navegação de um NPC, sendo dado um maior enfâse ao pathfinding, nomeadamente às diferentes abordagens existentes para representar o espaço físico do ambiente dos jogos de vídeo. Capítulo 3 descrição da metodologia de investigação, nomeadamente especificação dos objetivos e delineamento do estudo, material e métodos e o planeamento de atividades. Capítulo 4 descrição do trabalho realizado e demonstra a solução proposta pelos autores. Capítulo 5 apresentação e análise dos resultados obtidos e caracterização da amostra. Capítulo 6 discussão dos resultados, finalizado com uma conclusão onde são apontados rumos futuros com base no trabalho desenvolvido. 1.6 Sumário Secção introdutória ao presente trabalho, onde é descrita a sua motivação, objetivos e contribuições. Este trabalho procura suportar a geração processual de conteúdos, nomeadamente de ambientes de jogo. O processo de geração de ambientes de jogo tem como requisito o automatismo e tempo de execução. Este estudo pretende suportar esta funcionalidade e os requisitos associados, através do desenvolvimento de um sistema de navegação de NPC s. O estudo para além de contribuir para uma melhor compreensão da temática e dos requisitos envolvidos, procura fornecer dados e comparar um conjunto de diversas técnicas de representação de ambiente de jogo e algoritmos de procura em grafos, usadas no desenvolvimento do sistema de navegação. A secção é finalizada com uma descrição sumária dos diversos capítulos que compõem o documento. 5

31 Capítulo 2 Trabalho relacionado 2.1 Geração processual de conteúdo Os avanços tecnológicos têm tornado os consumidores de multimédia mais exigentes quanto ao detalhe gráfico, realismo e conteúdos multimédia de larga escala. Esta exigência tem sido respondida tradicionalmente com um aumento do número de artistas especializados e projetos cada vez mais longos. Tal resposta faz aumentar os já elevados custos de desenvolvimento que acabam por ser pagos pelo consumidor final (Kelly & Mccabe, 2006; Kelly, 2008). Por outro lado, à medida que a qualidade gráfica e realismo crescem, aumentam também as dificuldades de entrada de novas empresas competitivas no mercado, acabando por fazer diminuir a inovação (Kelly, 2008). Tornou-se assim importante encontrar alternativas que permitam gerar conteúdos em larga escala, a baixo preço e sem que isso se reflita no detalhe gráfico e realismo do conteúdo. Uma potencial solução é o uso das técnicas de geração processual de conteúdos (Ebert et. al cit. por Kelly, 2008 e Kelly & Mccabe, 2006). As técnicas processuais de conteúdo em jogos consistem na aplicação de computadores para gerar automaticamente conteúdos de todo o tipo. Este conjunto de técnicas pode ser definido como a automatização do processo de criação de conteúdos através de um conjunto de instruções computacionais (Ramteke, 2011). Estas desmarcam-se das aproximações tradicionais que se baseiam na criação de conteúdos estáticos para definir o ambiente. Os conteúdos estáticos são inflexíveis, difíceis de modificar e limitados na sua reutilização, as técnicas processuais oferecem a possibilidade de gerar conteúdos mais flexíveis e reutilizáveis (Kelly, 2008). Embora estas técnicas já venham a ser empregues no campo dos vídeo jogos há mais de 20 anos, a sua aplicação resumia-se à geração aleatória de conteúdos com um papel secundário nos vídeo jogos (Cardamone, Yannakakis, Togelius, & Lanzi, 2011). Nos últimos tempos estas técnicas têm assumindo um papel mais preponderante, sendo usadas na geração de elementos principais como mapas, sons, níveis e outros aspetos (Cardamone et al., 2011), sendo atualmente cada vez mais explorada pela indústria 6

32 multimédia: filmes, anúncios comerciais, televisão e videojogos (Kelly & Mccabe, 2006; Kelly, 2008). A PCG aplicada à área dos videojogos pode ser usada na geração de geometrias, texturas, comportamentos de agentes, animações, cenários, personagens, sons, músicas, itens, vegetação, terrenos, entre outros (Cardamone et al., 2011). Hoje em dia é possível criar mundos virtuais inteiros de forma processual (Kelly, 2008; Pandromeda, 2006 cit. por Kelly & Mccabe, 2006). De seguida iremos abordar as vantagens e desvantagens destas técnicas Vantagens As técnicas PCG estão associadas a um conjunto de vantagens: Aumento da longevidade dos jogos. Apesar dos milhões gastos no desenvolvimento de vídeo jogos comerciais estes possuem uma longevidade curta., Um jogo do tipo atirador em primeira pessoa (First person shooter - FPS) por exemplo, possui apenas uma duração média de 10 horas no modo de jogador único e alguns mapas no modo de jogadores múltiplos (Cardamone et al., 2011). Se novos conteúdos puderem ser gerados com uma variedade suficiente em tempo real, então é possível criar jogos com inúmeros cenários (Togelius et al., 2011). Jogos sem repetições. A PCG confere a capacidade de o vídeo jogo se adaptar ao desempenho, experiência, capacidade e preferências de um ou vários jogadores (Cardamone et al., 2011). A capacidade de gerar mapas em tempo de execução permite dar aos jogadores novos desafios. Por exemplo, depois de um jogador ter finalizado a estória principal de um jogo de interpretação de personagem (Roleplaying game - RPG) tem poucas razões para o voltar a jogar ao jogo, com a geração de mapas o jogador pode explorar novos locais desconhecidos ou até mesmos os mesmos locais mas com algumas modificações (ex.: Mass effect 3 ). Transposição de limitações técnicas como o espaço em disco ou memória (como por exemplo os jogos elite e kkrieger ). À medida que os jogos se tornam mais complexos e detalhados, o espaço ocupado em disco aumenta proporcionalmente ao seu conteúdo (Kelly & Mccabe, 2006). Estas técnicas podem ser vistas como técnicas de compressão de dados (ex.: o jogo FPS kkrieger ou o jogo RPG elite ) que através de algoritmos determinísticos transformam parâmetros de entrada dede tamanho reduzido em conteúdos diversos e complexos (Kelly, 2008; Togelius, Yannakakis, Stanley, & Browne, 2011). Esta capacidade é extremamente útil nos dias de hoje quando pensamos em transferência de conteúdos pela rede ou na capacidade limitada de hardware dos dispositivos móveis. 7

33 Grandes paisagens a custos razoáveis. Mapas muito extensos podem ser difíceis de criar: cada árvore, casa, carro, entre outros elementos além de criados necessitam de ser posicionados. Mesmo com uma grande equipa de designers, este processo pode ser longo (ex.: Grand Theft Auto ). Os projetos muito longos são um risco para as produtoras devido aos custos que acarretam, perda de competitividade comparando a companhias com ciclos de desenvolvimento mais rápido, lançamento de produtos semelhantes, tecnologia usada tornar-se ultrapassada entre outros. Possibilidade de ir além da imaginação do desenhador. É possível criar novos tipos de jogos com mecânicas de jogo construídas inteiramente a partir da PCG (Togelius et al., 2011) Desvantagens Apesar das vantagens no uso das técnicas PCG, existem também desvantagens que devem ser enumeradas: Limitação na liberdade de desenho. Como todos os conteúdos são gerados por algoritmos é difícil gerar elementos específicos. A geração de conteúdos baseada unicamente em algoritmos não possibilita indicar o aparecimento de elementos específicos e se a sua aparência ou ordem de aparecimento corresponde à história do jogo. Caso do jogo não possuir estória este aspeto deixa de ser importante. Look and feel de paisagens genéricas. Se os algoritmos não estiverem corretamente configurados, o seu resultado pode ser paisagens que se repetem ou que não constituem um desafio de exploração a longo prazo. Um designer humano é capaz de criar paisagens atraentes ao olho humano e excitantes de explorar. Os algoritmos podem ser afinados por programadores experientes, mas isto por sua vez também constitui um custo. Áreas inacessíveis e mapas partidos. Da mesma forma que um designer humano pode errar, um algoritmo pode não estar correto. Isto pode originar por exemplo mapas em que não seja possível ganhar, por exemplo, não permitam o jogador alcançar objetos chave ou mapas que são seja possível ganhar (Togelius et al., 2011) Aproximações híbridas Os conteúdos gerados de forma processual muitas vezes não são adequados para o jogo. Por outro lado os conteúdos criados por humanos geralmente apresentam uma qualidade muito superior. Contudo, não existe nenhuma razão para que ambos os métodos não possam coexistir (Ramteke, 2011; Wu, 2008). A combinação entre designers humanos e PCG pode ser usada por exemplo para geração de mapas de larga 8

34 escala que sejam interessantes e que proporcionem uma boa experiência de jogo ao utilizador. Isto pode ser conseguido de diversas formas: Cenários gerados através da PCG, com adição posterior ao mapa de salas criadas por designers humanos. Estas salas são desenhadas para caber no mapa auto gerado, desta forma embora o seu conteúdo possa não ser modificável a sua localização é. O jogador apenas se iria aperceber da repetição destas salas se repetisse o jogo (ex.: Diablo ). Mapas criados por designers humanos e posteriormente povoado pela PCG. Os designers criam o mapa e a PCG cria as paisagens como por exemplo árvores (ex.: Elders Scrolls: Oblivion ). Mapas gerados em tempo de execução. Os mapas são gerados em tempo de execução, contudo os algoritmos usados estão configurados para colocar elementos importantes da estória. Desta forma a personagem começa sempre na mesma posição e acaba sempre em localizações pré-definidas. A inclusão de outras secções críticas estão cuidadosamente restritas para evitar conflitos. Isto limita a aleatoriedade, mas por outro lado assegura que estes elementos sejam colocados corretamente (ex.: Valion ) (Togelius et al., 2011) Características Ao longo de mais de duas décadas diversas técnicas de PCG têm sido aplicadas no desenvolvimento de diversos aspetos dos vídeo jogos, contudo a comunidade académica poucos esforços realizou para estudar estas técnicas. Não existe assim nenhum corpo teórico ou taxonomia que suporte a PCG. Para um melhor entendimento da área iremos enumerar um conjunto de distinções para clarificar alguns aspetos da utilização da PCG, que julgamos ser pertinentes e uteis na clarificação do estudo da PCG. Os autores referem que estas distinções devem ser encaradas como um continuum e não como distinções dicotómicas, possíveis de serem alteradas no futuro com o amadurecimento do conhecimento na área. Online vs. Offline A aproximação online é usada durante a execução do jogo por exemplo o servidor sugere diariamente novos mapas a um grupo de jogadores com base no tipo de jogo de cada um deles. Outro exemplo é a criação de um segundo nível do jogo após o primeiro ter sido completado. Este segundo nível simplesmente não existe antes disso (Togelius et al., 2011). A aproximação offline é usada para criar conteúdos de jogo antes do seu lançamento comercial. Um exemplo disto é a criação de grandes zonas de vegetação ou 9

35 secções de jogo que necessitam de uma grande carga de trabalho por partes dos designers (Blanchard & Jesper, 2012; Togelius et al., 2011). Conteúdos necessários vs. Conteúdos opcionais Existem conteúdos que são necessários para que o jogador possa progredir no jogo. Por exemplo os caminhos devem permitir a passagem do jogador, monstros serem mortos, regras cruciais ao jogo, etc. (Blanchard & Jesper, 2012; Togelius et al., 2011). Conteúdos opcionais são descritos como conteúdos sobre o qual o jogador pode escolher, como por exemplo armas ou salas que o jogador pode entrar ou ignorar (ex.: Borderlands ). A grande diferença entre estes dois tipos de conteúdos é que o conteúdo necessário deve obrigatoriamente de estar sempre correto ou o jogador não é capaz de completar o jogo. Alguns tipos de conteúdos podem ser opcionais ou necessários em alguma parte do jogo (ex.: grutas). Desta forma a análise sobre se um conteúdo é opcional ou não deve ser feita de partida a partida (Togelius et al., 2011). Sementes aleatórias vs. Vetores de inicialização Os algoritmos PCG normalmente recorrem a um conjunto de parâmetros para criar conteúdos expandidos de um determinado tipo baseando-se numa representação compacta. Esta representação pode variar bastante e descrever conteúdos de quase todo o tipo. Os parâmetros podem ser usados como uma forma de controlo ou aleatoriedade do conteúdo criado. A semente é uma representação compacta de um conteúdo que através de um sistema de geração de números aleatórios irá gerar o conteúdo com base na semente e nos números aleatórios indicados por parâmetro de entrada (Blanchard & Jesper, 2012; Togelius et al., 2011). O vetor de inicialização corresponde a um vetor multidimensional de parâmetros de valor real que o algoritmo usa como parâmetro de entrada (Togelius et al., 2011). Quer a sementes aleatórias, quer os vetores de inicialização, podem ser usados em simultâneo (Blanchard & Jesper, 2012). Geração estocástica vs. Geração determinística A geração de conteúdos baseada em parâmetros pode ser caracterizada pelo seu resultado. 10

36 Na geração estocástica, o algoritmo de geração de conteúdos com base nos mesmos parâmetros de entrada gera resultados diferentes. Este tipo de geração permite gerar conteúdos dinâmicos. Na geração determinística, o algoritmo de geração de conteúdos gera sempre o mesmo resultado com base no mesmo parâmetro de entrada. A geração é baseada no que o parâmetro realmente representa (Blanchard & Jesper, 2012). Algoritmos inteiramente determinísticos podem ser vistos como um processo de compressão de dados. O jogo de atirador em primeira pessoa kkrieger é um exemplo disso, apesar da sua grande componente gráfica apenas ocupa 95 Kb em disco rígido, segundo os seus criadores caso não tenham sido empregues técnicas PCG o jogo ocuparia entre 200 a 300 MB em disco rigido (ex.: o jogo kkrieger ) (Togelius et al., 2011). A escolha entre estas duas aproximações é uma questão de design. Contudo, na maioria das vezes é mais fácil personalizar um sistema que não recorre a uma aproximação de geração determinística (Blanchard & Jesper, 2012). Algoritmo construtivo vs. Algoritmo gerar-testar Na geração de conteúdos é possível distinguir dois tipos principais de algoritmos. No algoritmo construtivo, a geração do conteúdo ocorre apenas uma só vez, sendo esta final, não sendo alvo modificações de posteriores. Esta aproximação é a melhor opção para a geração de conteúdos online onde a velocidade e performance são um problema. Na aproximação construtiva é importante que o conteúdo gerado esteja correto uma vez que não há espaços para correções (Blanchard & Jesper, 2012). No algoritmo por aproximações, o conteúdo é gerado e depois testado de acordo um determinado critério. Se o conteúdo gerado não preenche um determinado critério, todo ou parte do conteúdo será regerada. Este processo irá repetir-se até que todos os critérios estejam reunidos. Este método permite o sistema errar e assegurar que o conteúdo final esta sempre correto (é necessário que caso os critérios estejam corretos). O aspeto negativo desta aproximação é que a execução de muitas iterações durante a geração pode demorar muito tempo o que não satisfaz a geração online (Blanchard & Jesper, 2012). Não serão abordados algoritmos de PCG uma vez que sai da esfera de interesse do presente estudo. 11

37 2.2 Sistema de navegação Cada vídeo jogo é único, e cada jogo requer uma implementação única da inteligência artificial para suportar as mecânicas específicas desse jogo (ex:. tipo de jogo). O sistema de navegação é apenas uma das componentes da inteligência artificial. Contudo existem aspetos comuns entre os diversos jogos. Neste capítulo iremos descrever esses aspetos baseando-nos no tipo de jogo atirador em primeira pessoa e jogos em terceira pessoa uma vez que partilham os mesmos pressupostos. O sistema de AI de um jogo de vídeo constitui uma camada específica do motor de jogo, onde está incluído o sistema de navegação. O sistema de navegação pode ser dividido em duas componentes principais (ver Ilustração 1): locomoção (encarregue pelo movimento efetivo do agente) e pathfinding (responsável pelo planeamento de caminhos no ambiente do jogo de vídeo). A componente pathfinding por sua vez pode ser subdividida em duas componentes: representação do ambiente e algoritmos de procura (Anguelov, 2011). Sistema de Navegação Locomoção Pathfinding Representação do ambiente Algoritmos de Procura Ilustração 1 - Sistema de navegação e as suas componentes Locomoção A componente locomoção está encarregue do movimento efetivo do agente, é o sistema de controlo do movimento, esta determina como o NPC se deve mover no ambiente de jogo. As funcionalidades suportadas por esta componente variam de implementação para implementação, consoante o contexto e complexidade da IA do jogo de vídeo. As suas principais funções são: fazer pedidos de resolução de caminho à camada pathfinding quando existe a necessidade de planear uma rota; e executar os planos retornados pelo pathfinding. 12

38 Esta componente não determina para onde o agente se deve mover, mas sim como o fazer. Esta solicita pedidos de caminho entre dois pontos e é responsável por assegurar que o agente se move de forma correta de um ponto para outro. Para a realização eficaz do plano retornado pelo pathfinding o NPC deve ser capaz de identificar obstáculos (objetos do ambiente de jogo ou outros NPC s) e validar o caminho devolvido, A identificação de obstáculos e validação do caminho é um problema complexo que varia consoante o tipo de jogo, complexidade da inteligência artificial do agente e o realismo do jogo. Existem diversas abordagens, as quais apenas iremos referir algumas: dotar o NPC de sensores como por exemplo fazer raycasting para a identificação de obstáculos. se o mapa de navegação dispor de informação da área navegável, a repetição periódica de pedidos de caminho permite ao NPC descartar caminhos que podem não estar atualmente corretos Representação do ambiente Para os algoritmos de procura de caminhos poderem desempenhar a sua função, é necessário em primeiro lugar que estes consigam entender o ambiente, e isto implica que o ambiente esteja guardado de forma simples e que permita realizar procuras de forma fácil e rápida. O detalhe visual do ambiente de jogo 3D é irrelevante para o planeamento de caminhos e o formato que este se encontra guardado não é adequado à procura de caminhos. Desta forma, os programadores de jogos para a procura de caminhos, recorrem a abstrações simples do ambiente complexo do vídeo jogo. Estas abstrações contêm toda a informação essencial para a navegação do NPC e que possibilitam a procura de caminhos (Anguelov, 2011). O seu objetivo não é descrever toda a geometria navegável, mas sim fornecer marcas que servem como localizações e a forma como lá chegar (Borovikov, 2011). Abstração de grafo de navegação A representação do ambiente assume a forma de grafo uma vez que é uma estrutura de dados simples, capaz de conter todos os dados de navegação. Um grafo é definido por dois conjuntos finitos: vértices (nós) e arestas (conexões). Os vértice contêm os dados enquanto as arestas fazem a ligação entre dois vértices. Um vértice pode ter uma ou mais arestas que o conecta com outros vértices do grafo. Os grafos que contem dados de navegação e que representam um ambiente de jogo são chamados de grafos de navegação (navgraph). Estes grafos delimitam o espaço de procura para algoritmos de procura. Cada nó do grafo representa uma localização possível do 13

39 ambiente 3D e contem as propriedades dessa localização e uma lista de localizações (nós) acessíveis diretamente a partir desse nó (Anguelov, 2011). Cada aresta representa a conexão entre as duas áreas, e esta por sua vez está associada a um custo que no caso mais simples representa a distância entre os dois nós que conecta (Buckland, 2004). Em resumo, a geometria do mapa e a capacidade de movimento do agente são traduzidos em nós, conexões e em funções de custo que os valoriza (Millington & Funge, 2009). Geralmente os navgraph são incluídos no jogo de vídeo durante a fase de desenvolvimento, com o objetivo de evitar o consumo de recursos (tempo de execução e memória) na sua geração durante a execução do jogo de vídeo. Esta decisão é a mais apropriada, nos jogos de vídeo em que cenários são imutáveis. Esquema de divisão Embora a ideia de construir um grafo de navegação a partir de um ambiente complexo pareça simples, a implementação da teoria à prática está associada a inúmeros problemas (Buckland, 2004). Para a construção do grafo é necessário dividir o espaço do jogo em regiões e conectá-las. Os diversos métodos que permitem fazer isto designam-se por esquemas de divisão (division schemes). Propriedades Cada esquema de divisão possui três importantes propriedades: quantização/localização (quantization/localization), geração (generation) e validade (validity). Quantização/localização Os grafos de navegação são mais simples que o ambiente de jogo, desta forma é necessário recorrer a um mecanismo que traduza as localizações no ambiente de jogo em nós no grafo, a isso se chama quantização. Esta propriedade é usada por exemplo quando um NPC decide alcançar um item dentro do ambiente de jogo, neste caso é necessário converter a sua posição e a posição do item em nós do grafo. A localização é o processo inverso da quantização, em que é usado um mecanismo que traduza os nós no grafo em localização no ambiente de jogo. Após um algoritmo de procura determinar um caminho entre dois pontos, o agente necessita de saber as coordenadas desses pontos no ambiente de jogo. Geração A propriedade geração distingue cada método relativamente ao seu grau de automatismo que pode variar entre manual ou automático. O processo automático é 14

40 caracterizado por gerar menos nós para cobrir o cenário, resultando em mapas de navegação mais simples que permitem processar respostas mais rápidas. O processo manual caracteriza-se por gerar grafos mais complexos (maior número de nós), mas que oferece melhores resultados em relação ao realismo do comportamento dos NPCs uma vez que o processo é específico a cada mapa do jogo. Validade A validade refere-se à capacidade do agente de realizar o plano traçado. Se um plano delineia um percurso ao longo da conexão do nó A ao nó B, então o agente deverá ser capaz de realizar esse movimento. Se a quantização das regiões à volta de A e B não permitem esse movimento então o grafo de navegação criou um plano de navegação inútil. Um esquema de divisão é válido se todos os pontos, de duas regiões conectadas, possam ser alcançados entre elas. A maioria dos esquemas de divisão não verifica a validade, podendo ainda haver diversos níveis de validade (Millington & Funge, 2009). Tipos Ilustração 2 - Ambiente de jogo base. Existem três principais tipos de esquema de divisão: baseados em pontos de passagem, baseados em malha de navegação e baseados em grelha. O método de abstração usado para representar o ambiente de jogo irá determinar o tamanho e complexidade do grafo (Anguelov, 2011). 15

41 Para permitir entender melhor para cada um método de abstração é fornecido um exemplo da sua aplicação com base no ambiente de jogo mostrado na Ilustração 4. Baseado em pontos de passagem O método de abstração baseado em pontos de passagem é considerado como o método tradicional de criar grafos de navegação uma vez que era o método usado nos jogos de vídeo antigos como os jogos de aventura animada e first person shooter (FPS), ex.: Monkey Island, Half-Life 2. Este tipo de abstração consiste na adição de pontos de passagem (nós) de forma manual ou automática ao cenário, sendo posteriormente ligados (arestas) de forma manual ou automática formando desta forma o grafo de navegação. As abordagens inteiramente manuais, embora confiram ao agente artificial um movimento menos artificial, não são consideradas como perfeitas uma vez que não garantem a cobertura total do ambiente. Em comparação, as abordagens automáticas caracterizam-se por cobrir eficazmente todo o espaço navegável, contudo este tipo de abordagem está associada a um grande custo computacional e à possibilidade de originarem um elevado número de nós redundantes resultando no aumento do espaço de procura. Por norma assiste-se ao uso das duas abordagens, de forma a obter o melhor dos dois mundos e a compensar os pontos negativos de cada abordagem (Tozour, 2008). Podemos dar como exemplo de abordagem automática os algoritmos: art gallery (onde se recorre à abstração de uma galeria de arte em que o algoritmo determina o número mínimo de guardas necessários para que todas as paredes da galeria estejam no raio de visão dos guardas), os pontos de visibilidade e geometria expandida (estas duas ultimas são abordadas com maior detalhe mais à frente). Embora as técnicas enunciadas possibilitem diversos graus de automatização é sempre necessário algum tipo de intervenção humana (Tozour, 2008). 16

42 Ilustração 3 - Grafo de navegação baseado em pontos de passagem. Vantagens Apesar de ser necessário inúmeros pontos de passagem para garantir o movimento adequado dos agentes artificiais, o grafo de navegação resultante desta abordagem potencialmente possui o menor espaço de procura quando comparados com as demais abordagens. Existe a possibilidade de incluir informação adicional nos nós que compõe o grafo de navegação, como por exemplo atributos de orientação, ou tipos de animação que o agente deve realizar face a esse objeto. Esta característica é útil quando se pretende incluir pontos pré-definidos no ambiente de jogo, como assinalar pontos de abrigo, de passagem, de patrulha ou até mesmo, pontos chaves da estória do jogo. É possível por exemplo incluir um ponto de passagem numa porta com um atributo de orientação, desta forma um NPC ao aproximar-se saberá como se orientar face à porta de forma a poder abri-la corretamente. No caso de haver a necessidade de incluir pontos pré-definidos que identifiquem posições chave no mapa, as outras abordagens para além do próprio grafo de navegação necessitam de uma segunda representação baseada em pontos de passagem que indiquem à AI como usar o ambiente de jogo (Tozour, 2008). Desvantagens A única informação que os agentes artificiais possuem do mundo são os pontos de passagem e as arestas que os une. Os agentes são assim forçados a manterem-se no caminho delineado como se estivessem a deslocar-se num trilho de caminho-de-ferro. Isto implica que o agente ao movimentar-se ao longo do trajeto caminhe com uma aparência artificial ( zig-zag ) ou não opte pelo caminho ótimo (Tozour, 2008). 17

43 A informação limitada que o agente dispõe do ambiente de jogo dificulta a aplicação desta abordagem a ambientes dinâmicos. O agente ao verificar que o caminho está obstruído tem de adotar um novo caminho, invés de se desviar do obstáculo (Tozour, 2008). Por outro lado caso ocorra um evento de alteração do ambiente de jogo, a geração automática de pontos de passagem não oferece garantias quanto à validade do caminho gerado (Anguelov, 2011). Impossibilidade de usar o mesmo grafo de navegação para agentes com propriedades diferentes como o peso, tamanho, taxa de viragem e outros parâmetros. Muitas vezes é necessário usar diferentes grafos de navegação baseados no tamanho, forma e capacidade de movimentação de cada agente (Tozour, 2008). Problemas na simulação de multidões uma vez que todos os elementos movemse através das arestas, o que não é natural (Tozour, 2008). Impossibilidade de prever o resultado das animações do agente. O agente ao realizar uma animação pode entrar numa posição inválida como uma parede ou precipício. (Tozour, 2008). Técnicas de colocação de pontos Pontos de visibilidade Os gafos de navegação baseados em pontos de visibilidade (POV) são uma variante dos grafos de navegação baseados em pontos de passagem. Os grafos de navegação baseados em POV são criados através da colocação automática de pontos de inflexão (pontos em que a direção do caminho altera) nos vértices dos polígonos convexos, assinalando desta forma as obstruções do cenário. Estes pontos de inflexão são posteriormente conectados através da verificação da linha de visão (Anguelov, 2011). Esquema divisão de Os pontos de inflexão ocorrem naturalmente no caminho mais curto, estes podem ser transformados em nós e usados na procura de caminhos. A ligação entre pontos de inflexão pode ser feita através da técnica de raycasting em que a conexão entre dois pontos acontece se o raio colidir como a geometria de um. A ideia é verificar se um ponto pode ver o outro (Millington & Funge, 2009). Quantização e localização Uso do dominó de Dirichlet (Millington & Funge, 2009). 18

44 Validade Uso do dominó de Dirichlet (Millington & Funge, 2009). Tabela 1 - Esquema de divisão de grafos de navegação baseados pontos de visibilidade. Ilustração 4 - Grafo de navegação baseado em pontos de visibilidade. Vantagens Este tipo de grafo de navegação é fácil de expandir de forma a incluir outros nós que forneçam informações para além dos dados de conectividade (Buckland, 2004). Desvantagens Espaço de procura e fator de ramificação grande quando comparado com grafos de navegação baseados em pontos de passagem. Obstáculos com uma geometria complexa (ex.: pilares circulares) podem gerar grafos com um grande número conexões devido à geração de múltiplos pontos de inflexão próximos uns dos outros (Anguelov, 2011). Geralmente é necessário a intervenção humana para juntar diversos pontos de inflexão com o objetivo de reduzir o espaço de procura. Em cenários grandes e complexos o designer do mapa, pode gastar muito tempo a criar e a afinar os pontos de inflexão. Geometria expandida A técnica de geometria expandida é uma técnica que permite colocar pontos de inflexão de forma automática. Se o ambiente do jogo for constituído por polígonos é possível usar a informação presente nessas formas geométricas para automaticamente criar um grafo POV permitindo poupar imenso tempo no caso de grandes ambiente de 19

45 jogo. Este processo é feito da seguinte forma, primeiro são expandidos os polígonos por uma quantidade proporcional ao raio dos agentes do jogo, de seguida os vértices definidos, por estas geometrias expandidas, são adicionados como nós ao grafo de navegação. Por último, é executado um algoritmo para testar a linha de visão entre os vértices, e são acrescentadas as arestas ao grafo. Como os polígonos estão expandidos por uma quantidade maior ou igual ao raio do agente, um agente pode procurar o grafo de navegação resultante para criar caminhos sem esbarrar contra paredes. Apesar do automatismo desta técnica, ainda é necessário a intervenção humana para remover a redundância de pontos de inflexão (Buckland, 2004). Ilustração 5 - Grafo de navegação baseado em pontos de visibilidade com geometria expandida. Baseado em grelha Grafos de navegação baseados em grelha são criados através da imposição de uma grelha sobre o ambiente de jogo, dividindo o ambiente em regiões regulares designadas por telhas (tiles) ou células. A conversão da grelha em grafo é feita através da geração de um nó abstrato por cada célula da grelha e de seguida, através da geometria de conexão das células em grelha (propriedade de vizinhança), são determinadas as arestas. A geometria de conexão de células é determinada pelo tipo de células usado para formar a grelha, este tipo pode variar entre células quadradas com 4 ou 8 vizinhos, células hexagonais com 6 vizinhos (ver Ilustração 6). Sendo a célula quadrada com 8 vizinhos a mais popular (Anguelov, 2011). 20

46 Célula quadrada (4 vizinhos) Célula quadrada (8 vizinhos) Célula hexagonal (6 vizinhos) Ilustração 6 - Geometria das conexões das células em grelha. Cada célula dispõe de um limiar de navegabilidade que é usado para determinar se uma célula é navegável ou está obstruída. No caso de uma célula ter atingido esse limiar então a célula é considerada como obstruída e o agente não irá tentar mover-se para elas caso contrário é considerado como navegável (Millington & Funge, 2009). Desta forma, ao contrário das outras abordagens, os grafos de navegação baseados em grelha contêm a informação quer das áreas navegáveis, quer das áreas obstruídas. Este tipo de grafo possui assim a representação total do ambiente de jogo, incluindo todas as posições possíveis. No que diz respeito a ambientes de jogo dinâmicos, a reflexão de alterações do ambiente no grafo de navegação têm baixos custos, uma vez que apenas implicam o recálculo do indicador de navegabilidade das células que englobam a área afetada, não ocorrendo a modificação ou a reconstrução do grafo. A representação simples de todo o ambiente de jogo, assim como atualizações sem custos, tornam esta abordagem na primeira escolha a ser usada em jogos de estratégia em tempo real (Real-time strategy - RTS) (Anguelov, 2011). 21

47 Ilustração 7 - Grafo de navegação baseado em grelha com células quadradas. Ilustração 8 - Grafo de navegação baseado em grelha com células hexagonais. Esquema divisão de Os nós do grafo de navegação representam as células do ambiente de jogo. Cada célula no mundo do jogo tem um conjunto de vizinhos (baseado no tipo de célula), as arestas do grafo de navegação representam os vizinhos imediatos (Millington & Funge, 2009). Quantização e localização Na quantização a determinação da célula em que um determinado ponto do ambiente se localiza é rápida. Na localização pode ser usado um ponto de representação da célula 22

48 (normalmente o centro da célula) para converter o nó numa localização dentro do ambiente. Desta forma, a quantização e a localização são constantes (Millington & Funge, 2009). Geração A geração dos grafos baseados em telha é automática, devido a estes serem regulares (têm sempre o mesmo número de conexões) (Millington & Funge, 2009). Validade Pode ocorrer erros de validade quando a célula está parcialmente bloqueada mas ainda não atingiu o limiar de navegabilidade (Millington & Funge, 2009). Tabela 2 - Esquema de divisão de grafos de navegação baseados em grelha. Vantagens Pode ser aplicada em ambientes dinâmicos, qualquer alteração ao ambiente resulta numa operação de custo baixo uma vez que apenas implica o recálculo do limiar de navegabilidade dos nós da área afetada e não requer qualquer alteração ou reconstrução do grafo (Anguelov, 2011). Jogos de mesa, de estratégia em tempo real (real-time strategy - RTS) ou de interpretação de personagens (role-playing game - RPG) são normalmente divididos em células onde são colocados os modelos 3D. Esta grelha pode ser facilmente convertida de forma a representar um grafo de navegação (Buckland, 2004; Millington & Funge, 2009). Os grafos de navegação podem ser gerados automaticamente no momento sem qualquer intervenção de programadores e em tempo de execução. De todas as abordagens é a que necessita de menos envolvimento por parte do programador (Millington & Funge, 2009). A posição do início e do fim do caminho existe como nós no grafo de navegação, não requerendo procuras adicionais para descobrir o nó do grafo mais próximo a estas localizações. Este método é simples e eficiente uma vez que a geometria de conexão das células em grelha é constante e não necessita de examinações complexas do ambiente (ao contrário dos grafos de navegação baseados em malha de navegação) (Anguelov, 2011). 23

49 Desvantagens Os grafos resultantes deste método contêm o maior espaço de procura em comparação com as outras abordagens, uma vez que englobam os espaços navegáveis e obstruídos (Anguelov, 2011). Existência de células de igual tamanho para representar um espaço vazio (Yahja, Stentz, Singh, & Brumitt, 1998). Os agentes possuem um número limitado de ângulos de direção consoante o número de vizinhos associados à tipologia da célula. Desta forma, é possível observar alterações abruptas de direção durante a movimentação, é possível usar outras técnicas para atenuar este efeito, contudo sem garantias que o caminho suavizado convirja para o caminho ótimo (Yahja et al., 1998). O fator de ramificação depende do tipo da célula, quanto maior o fator de ramificação pior o desempenho e o custo de memoria na procura de caminhos. Se a célula tiver 8 vizinhos, então o grafo irá ter o maior fator de ramificação (Anguelov, 2011). Por exemplo um mapa com células 100 x 100 necessita de um grafo com 10,000 nós e 78,000 arestas aproximadamente. O caminho gerado com base neste tipo de abstração é considerado sub-ótimos uma vez que o caminho está limitado ao centro das células que compões o caminho (Hirt et al., 2011). Quadtree A quadtree é uma estrutura de dados em árvore em que cada nó interno tem exatamente quatro nós filhos, cada um representa um quadrante (sudoeste SW, sudeste SE, nordeste NE e noroeste NO) (ver Ilustração 9). Norte Oeste NW SW Sul NE SE Este SW Ilustração 9 - Quadrantes e quadtree correspondente. SE NE NW Esta estrutura é geralmente usada na divisão do espaço 2D caracterizando-se por dividir o espaço em 4 regiões uniformes, podendo cada uma destas regiões ser subdividida recursivamente em 4 regiões. O número de divisões é geralmente designado 24

50 por profundidade. Cada célula tem um limiar (capacidade máxima) que ao ser alcançado irá gerar a subdivisão dessa região em 4 regiões. Embora a quadtree possa ser catalogada como um método de abstração baseado em grelha, esta é uma estrutura de dados inteiramente diferente, sendo a sua principal diferença o uso de células não regulares. Os grafos de navegação baseados em quadtree são criados pela imposição desta estrutura ao ambiente de jogo, dividindo-o em regiões de tamanho não regular (células), até uma profundidade máxima definida. Tal como as células da grelha existe um indicador que assinala a navegabilidade das células. Quando é adicionado um objeto ao ambiente de jogo a quadtree irá dividir essa região até a profundidade máxima possível e irá assinalar a região ocupada pelo objeto como obstruída e as restantes regiões resultantes como navegáveis. As quadtrees que apresentam este comportamento designam-se por quadtree adaptativas. Desta forma, é possível representar o ambiente jogo de forma mais precisa possível com o menor número de nós (Hirt et al., 2011). As quadtree possuem inúmeras aplicações e diversas implementações. Contudo nem todas estas aplicações e implementações implicam a procura de vizinhos. A nossa pesquisa bibliografia não revelou estudos científicos que abordam especificamente a procura de vizinhos em jogos de vídeo, a maioria de algoritmos e implementações não contempla esta funcionalidade e a maioria dos estudos que abordam a problemática são destinados ao processamento de imagem. Podemos definir o nó B como vizinho de A quando estes partilham uma fronteira. Ao contrário do que acontece nas grelhas, a determinação de vizinhos numa quadtree não pode recorrer à geometria de conexão das células, uma vez que as células podem não ser regulares. Trata-se assim de um problema não trivial. 25

51 Ilustração 10 - Grafo de navegação baseado em quadtree. Esquema de divisão Quantização e localização Os nós do grafo de navegação representam as células não regulares do ambiente de jogo. Cada célula no mundo do jogo tem um conjunto de vizinhos (aqueles cujo partilham fronteira), as arestas do grafo de navegação representam os vizinhos imediatos. Na quantização a determinação da célula em que um determinado ponto do ambiente se localiza é rápida. Na localização pode ser usado um ponto de representação da célula (normalmente o centro da célula) para converter o nó numa localização dentro do ambiente. Desta forma, a quantização e a localização são constantes. Geração Validade A geração dos grafos baseados em quadtree é automática. (Millington & Funge, 2009). Pode ocorrer erros de validade quando: a célula está parcialmente bloqueada mas ainda não atingiu o limiar de navegabilidade; o ângulo de direção entre o ponto médio da célula de origem ao ponto médio da célula vizinha de destino passa por um vizinho ocupado (ver Ilustração 11). Tabela 3 - Esquema de divisão de grafos de navegação baseados em grelha. 26

52 Ilustração 11 - Grafo de navegação baseado em quadtree inválido. Vantagens O baixo número de nós permite reduzir a memória e tempo requerido na procura de caminhos (Hirt et al., 2011). Desvantagens Tal como no esquema de divisão baseados em grelha o caminho gerado é considerado sub-ótimo uma vez que o caminho está limitado ao centro das células (Hirt et al., 2011). Baseado em malha de navegação Os grafos de navegação baseados em malha de navegação (navmesh) têm-se tornado bastante popular entre os programadores de jogos e podem ser encontrados em diversos vídeos jogos comerciais (ex.: HALO 2 e 3, F.E.A.R., Counter-Strike: Source, Jak and Daxter, e Uncharted: Drake s Fortune ). Esta técnica utiliza uma rede de polígonos convexos chamada de malha de navegação (navmesh), que representa o chão do ambiente e descreve as áreas onde é possível caminhar no jogo. Os polígonos convexos têm a propriedade de permitir viajar sem impedimento a partir de qualquer ponto do polígono para outro ponto do polígono. O ambiente de jogo pode ser então representado como um grafo, em que cada nó representa um polígono convexo, sendo usado geralmente como coordenada de localização o ponto central do polígono (Borovikov, 2011). 27

53 Existem diversas técnicas de subdivisão do ambiente em malha de navegação, contudo saem do âmbito deste estudo. Na subdivisão, são usadas normalmente formas geométricas triangulares devido ao seu baixo número de conexões (número de atestas menor ou igual a 3), o que resulta em um baixo fator de ramificação no grafo final e por outro lado confere flexibilidade na representação de ambientes de jogo complexos (Anguelov, 2011). Ilustração 12 - Ambiente de jogo subdividido em polígonos navegáveis. Ilustração 13 - Grafo de navegação baseado em malha de navegação. 28

54 Esquema de divisão O ambiente de muitos jogos de vídeo é constituído inteiramente por polígonos, cada polígono pode ser usado como um nó no grafo de navegação. Cada nó é conectado aos nós (polígonos) que partilham uma aresta em comum. A criação da malha de navegação envolve o programador, uma vez que é necessário identificar os polígonos que constituem o chão do ambiente de jogo. O programador inclui então etiquetas que podem incluir diversas informações (Millington & Funge, 2009). Quantização e localização A identificação do polígono a que um ponto corresponde pode ser feita através da pesquisa do espaço procura ou através do pressuposto de coerência. A assunção de coerência postula que se se souber a localização do agente na última frame é então possível que este se encontre no mesmo polígono ou no polígono vizinho. Validade Para a localização de um determinado polígono, pode ser escolhido um ponto qualquer desse polígono, contudo por norma é escolhido o centro da geometria (válido para triângulos ou figuras geométricas côncavas) (Millington & Funge, 2009). As regiões formadas por malhas de navegação podem ser problemáticas, devido ao pressuposto que através de um ponto de uma região se pode aceder a qualquer ponto de uma outra região a que esteja conectado, contudo isto pode não se verificar (Millington & Funge, 2009). Tabela 4 - Esquema de divisão de grafos de navegação baseados em malha de navegação. Vantagens Estas técnicas geralmente geram um número mínimo de nós necessários para representar o ambiente, garantindo ao mesmo tempo uma cobertura do ambiente quase perfeita (Anguelov, 2011). O número baixo de nós e o baixo fator de ramificação confere aos grafos baseados em navmesh um espaço de procura pequeno (Anguelov, 2011; Borovikov, 2011). Este tipo de técnicas gera a representação de área navegável mais fiel de ambientes de jogo complexos (Anguelov, 2011). Jogos 3D, como a maioria dos FPS, são construídos inteiramente por polígonos, desta forma é possível usar algoritmos que usem estes polígonos (Buckland, 2004). 29

55 As malhas de navegação podem ser atualizadas em tempo de execução, contudo isto constitui um desafio devido às restrições de desempenho. Permite um elevado grau de automatização aos agentes artificiais (Anguelov, 2011). O agente ao detetar obstáculos através de técnicas como o raycasting pode ajustar o seu trajeto de forma a evitar o obstáculo, mas mantendo-se dentro da malha de navegação e no trajeto mais perto (Tozour, 2008). O agente dispõe de informação das zonas em que pode caminhar, podendo o seu trajeto ser suavizado (diminuindo o efeito do andar robótico ) desde que seja certificado de que o agente não saia da malha de navegação (Tozour, 2008). É necessário um menor envolvimento de programadores do que a abordagem baseada em pontos de passagem, uma vez que o papel deste é reduzido a identificar a malha poligonal que constitui o terreno (Millington & Funge, 2009). Esta abordagem permite usar o mesmo grafo para diversos tipos de unidade, o percurso é calculado e posteriormente é adaptado, por exemplo, às dimensões do agente. No que diz respeito às animações dos agentes, é possível prever se a localização do agente no final da animação é válida, através da comparação da posição final com a malha de navegação (Tozour, 2008). Desvantagens A subdivisão inicial do chão do ambiente de jogo requer um grande custo computacional e sendo esta a principal razão dos grafos de navegação baseados em malhas de navegação serem geralmente gerados de forma offline. Os grafos baseados nesta técnica possuem uma grande desvantagem em ambientes dinâmicos devido ao grande custo computacional envolvido na geração da malha de navegação. Uma alteração ao ambiente de jogo irá resultar na subdivisão em diversas partes da região do polígono alterado e por sua vez a reconstrução do grafo de navegação dessa região (Anguelov, 2011). Uma possível forma de lidar com este problema é usar pequenas porções da malha, uma de cada vez (Borovikov, 2011) Algoritmos de procura em grafos A abstração de grafo de navegação tem como principal objetivo fornecer uma estrutura simples que possibilite realizar procuras rápidas. Os algoritmos de procura em grafos têm por objetivo procurar o caminho mais curto de um nó do grafo (vértice inicial) a outro nó do grafo (vértice final). O pathfinding recorre a algoritmos de procura de grafos para descobrir o caminho ótimo ou próximo de ótimo. Caso exista um caminho entre os dois nós e se este for o 30

56 caminho com o menor custo possível então diz-se que estamos perante um caminho ótimo. O pathfinding está condicionado à complexidade do algoritmo (heurísticas) e ao tamanho do espaço de procura. No contexto dos jogos de vídeo o pathfinding está relacionado com a forma como as entidades chegam a um determinado objetivo tendo para isso de lidar com obstáculos (Koefoed-hansen, 2012). Neste contexto o pathfinding tem de respeitar o requisito de tempo real de múltiplos agentes e está sujeito à limitação de memória e desempenho do sistema de computacional, devendo, desta forma, os custos de processamento e memória serem minimizados (Anguelov, 2011). Dijkstra s O algoritmo Dijkstra s foi apresentado por Edsger Dijkstra em 1959 como um método de encontrar o caminho mais curto de um vértice inicial a um vértice final numa árvore de suporte (weighted graph) (Anguelov, 2011). O algoritmo Dijkstra s recorre a duas listas, uma que guarda os vértices já visitados (lista fechada) e a segunda que contém um conjunto de nós candidatos (lista aberta). A cada iteração o algoritmo começa por examinar (expandir) o nó com a menor distância ao vértice inicial dentro da lista dos nós candidatos. Caso o vértice expandido não seja o nó final, este é retirado da lista aberta e adicionado à lista fechada, os vértices adjacentes (nós vizinhos) a este vértice que ainda não foram examinados são então adicionados à lista aberta. O processo é repetido até o vértice final ser encontrado. O algoritmo irá falhar no caso de o vértice ter um custo negativo. Quando o vértice final é encontrado, como o primeiro nó examinado é sempre o vértice com a distância menor ao vértice inicial, o caminho encontrado é o caminho ótimo (Koefoed-hansen, 2012). A grande desvantagem apontada a este algoritmo é o grande custo resultante das operações à lista fechada e aberta. Cada vez que um nó é selecionado da lista aberta é necessário procurar pela lista inteira pelo vértice mais próximo do vértice inicial. Da mesma forma que sempre que é adicionado um vértice à lista aberta é necessário verificar se ele já existe na lista fechada. De forma a reduzir o custo de computação de operações à lista aberta e fechada várias otimizações podem ser feitas, e estas mesmas otimizações fazem parte de algoritmos como o A*. Um exemplo de otimização da lista aberta é o uso de uma lista ordenada, para que o primeiro vértice da lista seja sempre o próximo nó a ser expandido. Relativamente à lista fechada, cada vértice pode guardar uma variável que assinale se o vértice já foi adicionado ou não à lista aberta. Esta otimização evita a implementação de uma lista fechada bastando apenas verificar o estado do vértice (Anguelov, 2011). 31

57 - Vértice inicial -Vértice final + perto do vértice inicial + longe do vértice inicial Ilustração 14 - Algoritmo de procura Dijkstra's. Melhor-primeiro Este algoritmo tem um comportamento similar ao Dijkstra s contudo possuiu uma heurística que verifica a distância do vértice inicial ao vértice final. Invés do algoritmo expandir o vértice mais perto do vértice inicial, começa por expandir o vértice mais perto do vértice final (ganancioso). Este algoritmo não assegura que seja encontrado o caminho mais curto, contudo é mais rápido que o algoritmo Dijkstra s uma vez que a sua heurística guia a procura em direção ao nó final. O algoritmo melhor-primeiro tem a desvantagem de uma vez que é ganancioso, tenta mover-se diretamente para o nó final mesmo que o caminho não seja o correto. - Vértice inicial -Vértice final + perto do vértice final + longe do vértice final Ilustração 15 - Algoritmo de procura melhor-primeiro. 32

58 A* O algoritmo A* foi apresentado em 1968 por Hart et. al (cit. por Anguelov, 2011) como uma alternativa superior ao algoritmo Dijkstra s. O A* baseia-se no algoritmo Dijkstra s e nas heurísticas do algoritmo melhor-primeiro. Este destaca-se pela sua flexibilidade e possibilidade de utilização em diversos contextos. Este algoritmo recorre a heurísticas, tal como o algoritmo Dijkstra s favorece os vértices mais próximos ao vértice inicial e ao mesmo tempo tal como o algoritmo melhor-primeiro favorece os vértices perto do nó final. Dependendo da heurística escolhida o A* garante o caminho ótimo ou quase ótimo. O A* atribui um custo f(n) a cada vértice expandido, este custo é igual custo do caminho do vértice inicial ao vértice n g(n) mais o custo estimado do vértice n ao vértice final h(n). Equação 1 - Cálculo do custo de n. O custo estimado é determinado por uma heurística que representa a menor distância possível entre o vértice n e o vértice final. É desta forma que o A* elimina caminhos mais longos quando um caminho é descoberto. O algoritmo de procura A* apresenta uma eficiência ótima para determinadas heurísticas, porém, na prática, o A* apresenta um problema relativamente ao consumo de memória e tempo. Este problema é agravado se os caminhos tiverem de ser calculados com uma elevada frequência. A complexidade do processo de procura de caminho aumenta com o tamanho do ambiente e a precisão requerida (Hirt et al., 2011). - Vértice inicial -Vértice final + H - G - H + G Ilustração 16 - Algoritmo de procura A*. 33

59 Fringe Search O algoritmo Fringe Search foi introduzido por Björnsson et al. em 2005 (Björnsson, Enzenberger, Holte, & Schaeffer, 2005) como uma solução aos problemas inerentes à variante do A* o Iterative Deepening A* (IDA*). Segundo os autores a procura do melhor primeiro associado ao A* tem o seu preço em recursos computacionais. A ordenação da lista de nós abertos do A* é bastante dispendiosa, este problema não é solucionável com o baixo armazenamento de nós como acontece no IDA*, uma vez que o algoritmo acaba por ter visitar os mesmos nós diversas vezes. Enquanto o A* recorre a uma lista de nós abertos para manter a fronteira de procura, o Finge Search guarda um conjunto de nós a ser usado em cada iteração. Este conjunto não necessita de ser ordenado o que constitui uma vantagem face ao A* e ao IDA* O Fringe Search tal como o A* determina um custo f(n) a cada vértice que expande, baseado na mesma fórmula: o custo do caminho do primeiro vértice ao vértice corrente g(n), mais a heurística para estimar o custo do vértice corrente ao vértice final h(n). A estrutura de dados usada pelo algoritmo Fringe Search pode ser conceptualizada como duas listas: agora (now) lista destinada para a iteração atual; depois (later) lista destinada para a próxima iteração. Esta estrutura de dados guarda ainda o vértice da cabeça da lista agora designado por head. O algoritmo Fringe Search guarda um limiar de procura. Durante a etapa inicial do algoritmo a lista agora é preenchida com o vértice raiz (root), a lista depois é inicializada a vazio e o limiar de procura é valorizado com o maior número possível. Na etapa seguinte, o algoritmo repete os seguintes passos: O vértice head é examinado e duas ações podem ocorrer: se f(head) é maior que o limiar, então o nó head é removido da lista agora e colocado no fim da lista depois. Isto significa que o vértice head não é necessário ser considerado nesta iteração, sendo guardado para a próxima iteração; 34

60 se f(head) é menor ou igual ao limiar, então iremos expandir o vértice head, sendo os seus vizinhos adicionados ao inicio da lista agora. O vértice head é descartado depois deste passo. No final de cada iteração, caso o vértice final não tenha sido encontrado, o limiar de procura é aumentado, a lista depois é copiada para a lista agora sendo posteriormente inicializada a vazio. A principal diferença entre o algoritmo A* é que o algoritmo Fringe Search,é que no último não ocorre a ordenação das suas listas o que resulta num ganho significativo em relação ao A*, que muitas vezes necessita de manter a ordem das listas. Esta diferença pode justificar os resultados dos estudos que indicam que o Fringe Search em grelhas apresenta uma performance superior ao A* de cerca de 25%. Contudo, são apontadas também algumas desvantagens a este algoritmo: necessidade de maior quantidade de memória alocada, uma vez que, para cada nó encontrado é também armazenada o nó anterior. Este consumo é ainda maior quando comparado com o A*, uma vez que o número de nós visitados é significativamente maior (Björnsson et al., 2005). repetição de visitas ao mesmo vértice; visita de vértices considerados como irrelevantes para a iteração corrente. Isto é, vértices que apresentam um valor f(n) muito alto, que só são necessários nas próximas iterações, onde o limiar de procura é mais alto. Apesar das desvantagens, o custo de cada visita é constante em comparação com o pior cenário na ordenação da lista do A* que apresenta uma complexidade logarítmica (Björnsson et al., 2005). 2.3 Sumário Esta secção pode ser dividida em duas partes: geração processual de conteúdo e sistema de navegação. Na primeira parte foi enfatizada a importância da geração processual de conteúdo, tendo sido descrito as vantagens e desvantagens associadas a este tipo de técnicas. Esta parte da secção foi finalizada com a descrição das características que podem ser usadas na classificação das diversas técnicas de geração processual de conteúdo. Na segunda secção foi discutida a necessidade de converter o ambiente de jogo 3D complexo em grafos de navegação indicados utilizados pelos algoritmos de procura. 35

61 Foram apresentados três métodos de abstração principais do ambiente de jogo. Para cada um dos métodos foi dado um exemplo e destacadas as suas vantagens e desvantagens. Na primeira abordagem o navgraph é construído pela adição e ligação de pontos de passagem através de um processo manual e/ou automático. Este método oferece o espaço de procura mais pequeno das três técnicas, contudo a necessidade obrigatório da intervenção humana e o tempo de processamento inerente ao processo de adição/ligação de pontos de passagem faz desta abordagem imprópria para ser aplicada a ambientes criados em tempo de execução e ambientes dinâmicos. A segunda técnica é a mais simples e consiste em adicionar uma grelha com células de tamanho regular ao ambiente de jogo e posteriormente calcular a navegabilidade de cada célula. Neste método a ligação das células é feita através da geometria de conceção. Este método tem o efeito negativo de gerar o espaço de procura maior das três técnicas abordadas, contudo os ganhos inerentes a esta abordagem, nomeadamente a geração e atualização rápida, tornam esta técnica aplicável a ambientes gerados em tempo de execução e ambientes dinâmicos. A última técnica consiste em usar a malha de polígonos do chão do ambiente de jogo como nós do grafo e conectar cada nó com base nas arestas comuns. Esta abordagem permite gerar mapas de navegação de grande qualidade, contudo a criação e atualização desta malha é uma operação dispendiosa em recursos computacionais fazendo esta técnica inapropriada para os objetivos do presente estudo. Para além disso, foi ainda discutido uma variedade de algoritmos de procura em grafos. Verificou-se a relação que o processamento dos algoritmos e os custos de memória estão associados ao número de nós expandidos. A diminuição do espaço de procura pode resultar na diminuição do custo de processamento e memória. O algoritmo Dijkstar s foi o primeiro algoritmo de procura em grafos abordado. Devido à pesquisa do espaço de procura não ser orientada ao vértice final, o algoritmo acaba por explorar um grande número de vértices resultando num grande custo de processamento e memória, o que o faz deste algoritmo não indicado para o pathfinding em vídeo jogos. 36

62 O segundo algoritmo explorado, o melhor-primeiro é uma melhoria ao algoritmo anterior uma vez que direciona a pesquisa do espaço de procura ao vértice final. Contudo como tenta mover-se diretamente para o vértice final sem ter em consideração o caminho já efetuado pode levar o algoritmo a desperdiçar poder de processamento e memória a explorar um caminho incorreto. O A* é o algoritmo de procura em grafos mais popular, este fato justifica-se devido à sua eficiência e à possibilidade de otimização do algoritmo em termos de custo de memória e processamento. Por último, o algoritmo Fringe Search mostrou-se ser mais rápido do que o A* com um custo de memória mais alto. Este algoritmo pode ser considerado como uma boa opção para a resolução de caminhos quando a memória não é um limite. 37

63 Capítulo 3 Metodologia de investigação 3.1 Delineamento do estudo Estudo de carácter correcional e comparativo de dois esquemas de divisão do ambiente de vídeo jogos (esquema de divisão baseado em grelha e baseado em quadtree) e dois algoritmos de procura em grafos (A* e Fringe Search). Num primeiro momento pretendeu-se caracterizar o tempo de processamento e consumo de memória de cada esquema de divisão de ambiente comparativamente a operações elementares como a geração do grafo de navegação, quantização e localização, conexão de vizinhos, inserção de objetos e número de nós. O segundo momento consistiu em aplicar os algoritmos de procura a cada um dos grafos de navegação gerados por cada esquema de divisão. Neste momento contabilizou-se o processamento computacional, número de iterações, número de nós visitados e expandidos, custo e tamanho do caminho. Para a análise e tratamento dos dados foi utilizado o programa Microsoft Excel Questões e hipóteses de investigação Foram colocadas as seguintes questões de investigação: 1. É possível aplicar e gerir em tempo de execução o esquema de divisão baseado em grelha e em quadtree? 2. Existe alguma diferença em tempo de processamento e memória na gestão do grafo de navegação baseado no esquema de divisão em grelha e em quadtree? 3. De que forma o tempo de processamento e memória são influenciados pela dimensão do ambiente de jogo em cada tipo de representação do ambiente? 38

64 4. De que forma o tempo de processamento e memória são influenciados pelo número de objetos presentes no ambiente de jogo em cada tipo de representação do ambiente? 5. É possível o esquema de divisão baseado em grelha e quadtree suportar múltiplos agentes? 6. O esquema de divisão baseado em grelha e quadtree podem ser aplicados em ambientes dinâmicos? 7. É possível usar o algoritmo Fringe Search no contexto dos vídeo jogos? 8. Existe alguma diferença na procura de caminhos entre o algoritmo A* e o Fringe Search? 9. De que forma o tempo de processamento na procura de caminhos é influenciada pela dimensão do ambiente de jogo? 10. De que forma o tempo de processamento na procura de caminhos é influenciada pelo número de objetos presentes no ambiente de jogo? 11. Existe alguma relação entre o algoritmo A* e Fringe Search e o tipo de representação do ambiente? As seguintes hipóteses foram colocadas ao longo deste projeto: 1. Sim, para ambos os esquemas de divisão do ambiente de jogo é possível aplicalos e gerir em tempo de execução. 2. Sim, o grafo de navegação baseado no esquema de divisão baseado em grelha apresenta um tempo de processamento e consumo de memória superior ao esquema de divisão baseado em quadtree. 3. A dimensão do ambiente influencia diretamente a memória e o tempo de processamento necessário para cada tipo de representação do ambiente. 4. O número de objetos presentes no ambiente de jogo influencia o tempo de processamento e memória no esquema de divisão baseado em quadtree sem contudo influenciar o esquema de divisão baseado em grelha. 5. Sim, é possível o uso de ambos os esquemas de divisão do ambiente de jogo no suporte múltiplos agentes. 6. Sim, é possível o uso de ambos os esquemas de divisão do ambiente de jogo no suporte a ambientes dinâmicos. 7. Sim, é possível o uso do algoritmo Fringe Search no contexto dos vídeo jogos. 39

65 8. Sim, o algoritmo Fringe Search apresenta um tempo de processamento na procura de caminhos inferior e menor número de nós expandidos do que o algoritmo A*. Contudo, apresenta um número superior de nós visitados. 9. A dimensão do ambiente influencia diretamente o tempo de processamento na procura de caminhos em ambos os algoritmos de procura em grafos. 10. O número de objetos presentes no ambiente de jogo influencia diretamente o tempo de processamento na procura de caminhos em ambos os algoritmos de procura em grafos. 11. Os algoritmos de procura em grafos apresentam ambos um tempo de processamento menor na representação do ambiente baseado na quadtree quando comparado com a grelha. 3.2 Material e Métodos Caracterização da amostra No contexto do estudo a amostra consistiu em nove ambientes de jogo. Cada ambiente é caracterizado por duas componentes: dimensão e densidade de objetos contidos no ambiente. A dimensão do ambiente pode variar entre pequena (20 unidades), média (160 unidades) e grande (512 unidades). Ao lidar com dois tipos diferentes de esquemas de divisão houve a necessidade de assegurar que o número máximo de nós gerados e a dimensão mínima de cada célula fossem iguais para cada representação (ver Tabela 5). Dimensão mínima da célula Nº máximo de nós Pequena 2.5 Unidades 64 Média 2.5 Unidades 1024 Grande 2 Unidades Tabela 5 - Tamanho mínimo da célula e número máximo de nós com base no tamanho do ambiente. A categoria densidade de objetos contidos no ambiente de jogo, expressa o número de obstáculos existentes no ambiente. Com vista a gerar o mesmo número de nós ocupados, foi assegurado de que cada objeto ocupe uma célula e que cada célula só contenha um só objeto. Desta forma, para cada esquema de divisão foi assegurado de que cada objeto corresponde a um nó ocupado. A densidade de objetos pode variar 40

66 entre: pouco povoado (25% dos nós ocupados), povoado (30% dos nós ocupados) e muito povoado (35% dos nós ocupados). Pouco povoado (25%) Povoado (30%) Muito povoado (35%) Pequena Média Grande Tabela 6 - Tamanho do ambiente e densidade de objetos no ambiente de jogo. Com base nestas duas categorias cada ambiente foi gerado de forma aleatória, tendo sido colocado dois pontos de passagem em cada ambiente com o objetivo de serem usados na procura de caminho entre esses dois pontos (A e B). A seleção de cada ambiente obedeceu a uma série de critérios de inclusão e exclusão. Critérios de inclusão o tamanho do ambiente corresponde a uma dimensão da categoria dimensão; o número de objetos corresponde a uma densidade da categoria densidade de objetos; cada esquema de divisão divide o ambiente em células de dimensão mínima igual; cada esquema de divisão gera um número máximo de nós igual; cada esquema de divisão apresenta o mesmo número de nós ocupados; cada objeto ocupa apenas uma célula; cada célula é ocupada apenas por um objeto; Critérios de exclusão impossibilidade de navegar do nó A ao nó B e vice-versa; o nó A e/ou o nó B ocupados por um obstáculo; Para a recolha de dados cada elemento da amostra foi submetido a um conjunto de operações, sendo este processo repetido 200 vezes com a excepção da operação de procura de caminhos que foi repetida 500 vezes. A recolha da amostra foi feita num 41

67 único período de tempo, com a duração de 4 dias. Pensamos que o número de ambientes e situações (operações) avaliadas permitiu-nos estudar as questões em estudo Instrumentos Neste subcapítulo abordamos os instrumentos, neste caso as ferramentas usadas na realização do presente estudo. Para além da ferramenta de desenvolvimento de software usada no desenvolvimento da nossa solução, houve a necessidade de recorrer a outros dois tipos de ferramentas: a ferramenta de prova de conceito e a ferramenta de avaliação. Esta decisão justifica-se pela necessidade de provar o conceito aprofundado no Capítulo 4 e de o avaliar. Ferramenta de desenvolvimento de software A ferramenta de desenvolvimento de software tem por objetivo fornecer a tecnologia sobre a qual a nossa solução será desenvolvida. A natureza e os requisitos do nosso estudo para além de implicar o desenvolvimento de um módulo que suporte a nossa solução, implica ainda o desenvolvimento de artefactos que explorem este módulo com o objetivo de o testar e avaliar. Enquanto o desenvolvimento do módulo e do artefacto de avaliação necessita apena de uma linguagem de programação, o artefacto de prova de conceito implica o desenvolvimento de um protótipo funcional de um jogo de vídeo que permita verificar e aperfeiçoar as técnicas discutidas em funcionamento. Começamos por verificar os recursos disponíveis para o desenvolvimento de jogos de vídeo e dos seus módulos: código máquina (assembly), bibliotecas (ex.: OpenGL/DirectX/SDL), Toolkits (ex.: Ogre3D, Crystal Space), Software Development Kit s (SDK s) (ex.: Dark Game SDK) e motores de jogos (game engine) (ex.: Unreal Engine). Biblioteca: define-se por um conjunto de funções que desempenha uma tarefa; Toolkit é uma coleção de classes que fornecem um conjunto de serviços; SDK é uma biblioteca usada para no desenvolvimento do software; Motor de jogo é um programa de computador e/ou conjunto de bibliotecas que disponibiliza um conjunto de funcionalidades que visam facilitar o desenvolvimento de um jogo. As funcionalidades típicas de um motor de jogo são: motor gráfico (renderização gráfica 2D e/ou 3D), motor de física (aplica os princípios da física a modelos 3D e deteção de colisões), animações, som, inteligência artificial, redes, gestão de memória, gestão de ficheiros e linguagem script. O motor gráfico inclui características como a luminosidade, texturas e sombras. 42

68 Para cumprir os objetivos de desenvolvimento descritos e cumprir com os prazos inerentes ao estudo, o recurso escolhido deve assegurar a interoperabilidade entre o módulo e os dois artefactos, e ainda evitar perda de tempo em desenvolvimentos desnecessários aos nossos objetivos procurando assim evitar o reinventar da roda. Dos recursos disponíveis selecionamos como recurso o motor de jogo. Esta escolha deve-se ao facto deste recurso ser uma tecnologia bastante completa, com uma curvatura de aprendizagem e tempo de desenvolvimento rápidos. Para a escolha do motor de jogo mais indicado procedemos à pesquisa e análise dos motores de jogo mais populares na atualidade. O resultado desta pesquisa é descrito brevemente em baixo, mostrando, deste modo, a escolha para o estudo. Software Livre Blender O Blender é um programa de computador de código aberto, criado inicialmente pelo estúdio de animação holandês NeoGeo Studio. Atualmente é desenvolvido pela Blender Foundation para modelagem, animação, texturização, composição, renderização, edição de vídeo e criação de aplicações interativas 3D. É um software multiplataforma estando disponível para os principais sistemas operativos: Microsoft Windows, Linux, Mac OS X. O Blender disponibiliza um motor de jogo conhecido por Blender Game Engine para a criação de aplicações interativas 3D, tais como jogos, apresentações, planeamentos arquitetónicos, entre outros. Este programa fornece ainda um conjunto de ferramentas avançadas de simulação: dinâmica de corpo rígido, dinâmica de corpo macio e dinâmica de fluidos, ferramentas de modelagem baseadas em modificadores, ferramentas de animação de personagens, cenas e imagens, editor de imagem e vídeo com suporte a pós-produção. Como linguagem de script usa o Python. Ilustração 17 - Logotipo do Blender. jmonkey Engine O jmonkey Engine, também conhecido por jme, é um motor de jogo baseado em gráficos API de código aberto sob a licença BSD. A versão mais atual vem integrada 43

69 num SDK. Este motor é escrito em Java e usa como renderizador gráfico o LWJGL (Lightweight Java Game Library) com suporte a OpenGL (Pedro & Nunes, 2009). Ilustração 18 - Logotipo do jmonkey Engine Ogre O Ogre (Object-oriented Graphics Rendering) foi desenvolvido em 2001 sob a licença de software livre (GNU LGPL). Não realidade não é um motor de jogo, mas sim um motor gráfico que possibilita: desenvolvimento de jogos, planeamento arquitetónico, simulações ou qualquer aplicação que necessite de renderização gráfica. O Ogre inserese na categoria de toolkit e é composto por um conjunto de bibliotecas em C++ como um motor de renderização 3D em tempo real. Além da biblioteca principal é ainda disponibilizado um conjunto de plug-ins, ferramentas e add-ons que possibilitam a criação de diferentes aplicações gráficas. É bastante utilizado no aperfeiçoamento de videojogos uma vez que os seus recursos aumentam o desempenho durante a renderização de cenários e objetos tridimensionais. O Ogre suporta diferentes configurações de hardware e é compatível com DirectX e OpenGL (Netto, Machado, Marcos, Pedro, & Nunes, 2006). O Ogre possui ainda uma comunidade ativa e recentemente apresenta suporte para Linux, Windows, Mac OSX, IOS, Windows Phone 8 e Android. Ilustração 19 - Logotipo do Ogre. Panda3D O Panda 3D é um motor de jogo, constituído por conjunto de bibliotecas C++ que usa como linguagem de script o Python para invocar estas bibliotecas, aumentando o nível de abstração durante o desenvolvimento e permitindo assim uma aprendizagem 44

70 rápida. Este motor de jogo é de código aberto sob a licença BSD e lidera o topo de preferências dos utilizadores de motores de jogo de código livre. Esta ferramenta usa o conceito de objetos e nós, com o objetivo de aumentar o desempenho na renderização das cenas. Este conceito permite que os filhos do mesmo nó partilhem os mesmos atributos do pai, como por exemplo iluminação, transparência, entre outros. O Panda 3D disponibiliza efeitos de iluminação, efeito de sombra, motor de física (com deteção de colisões), sistema de partículas, texturas e motor de som (Netto et al., 2006). Este motor permite a visualização do desempenho em tempo real, disponibilizando ainda ferramentas de otimização de desempenho e de debug (Pedro & Nunes, 2009). Por detrás do Panda3D existe uma comunidade pequena, mas ativa. Ilustração 20 - Logotipo do Panda3D. Software comercial Torque Game Engine 3D Torque Game Engine 3D também conhecido por TGE é um motor de jogo 3D criado originalmente pela Dynamic e atualmente desenvolvido pela GarageGames. É o motor de jogo comercial eleito pela maioria dos programadores de jogos, possuindo dois tidos de licenciamento: uma para programadores independentes e outra para programadores profissionais. Destaca-se uma biblioteca de rede para múltiplos jogadores, criação de interfaces e colisões até 256 jogadores. Disponibiliza um editor integrado em tempo de execução e apresenta um conjunto de ferramentas de edição de terreno, sombras, texturização, pintura entre outros. O Torque 3D suporta o carregamento de ficheiros das ferramentas de arte mais conhecidas como: 3ds Max, Maya, Blender. 45

71 A linguagem de programação utilizada é o C++ e como linguagem script o TorqueScript. É multiplataforma com suporte aos sistemas operativos: Microsoft Windows, Mac OS X, Wii, Xbox 360, ios e Linux. Possibilita ainda a publicação do jogo desenvolvido na Web com suporte aos principais explorares de internet. Ilustração 21 - Logotipo do Torque Game Engine. Unreal Development Kit O Unreal Development Kit (UDK) foi criado e desenvolvido pela Epic Games tendo a sua primeira aparição no jogo FPS mundialmente conhecido, o Unreal (1998). Este toolkit foi usado para a criação de alguns dos jogos comerciais de FPS mais conhecidos: Unreal Tournament, Deus Ex, Turok, Tom Clancy s Rainbow Six 3: Raven Shield, Tom Clancy s Rainbow 6: Vegas, America s Army, Red Steel, Gears of War, BioShock, BioShock 2, entre muitos outros. O seu núcleo é escrito em C++, o que possibilita um grau elevado de portabilidade, suportando muitas plataformas: Mac OS X, Linux, PlayStation 2 e 3, Wii U, ios, Xbox 360, Dreamcast, Android e suporta DirectX e Open GL. Ilustração 22 - Logotipo do Unreal Development Kit. Unity 3D O Unity é uma plataforma de desenvolvimento de aplicações interativas 2D e 3D. Esta ferramenta para além de disponibilizar as funcionalidades típicas de um motor 46

72 de jogo, disponibiliza ainda um editor visual, que possibilita visualizar o jogo e criar um jogo completo a partir desse ambiente de desenvolvimento. Este motor tem alcançado alguma notoriedade devido à possibilidade de criar jogos de grande complexidade de uma forma simples e com gastos reduzidos. Outra característica do Unity é a possibilidade de exportar o mesmo jogo para as plataformas mais conhecidas da atualidade, sendo este procedimento na maioria das vezes transparente ao programador. As plataformas suportadas no momento são: Windows, Mac OS X, ios, Android, Navegador Web, Nintendo Wii, Xbox360 e PS3. O motor de jogo do Unity é construído com a linguagem de programação C++, sendo possível usar essa linguagem para criar Plugins. Para a criação de jogos de video, o Unity suporta as seguintes linguagens de programação: C# (framework 3.5), Boo (um dialeto da linguagem Python) e UnityScript (que é considerado uma variante própria de javascript). O Unity 3D possui sete tipos de licenças distintas, cada uma destinada a um tipo de programador ou plataforma. Ilustração 23 - Logotipo do Unity. O desenvolvimento através do Unity 3D é feito através do editor disponibilizado para o efeito. O editor do Unity 3D é composto por um conjunto de janelas, existem 5 janelas principais: Projeto: contem todos os recursos usados na criação do jogo ex.: modelos, prefabs, terrenos, texturas, scripts entre outros; Cenário: onde são posicionados os objetos de jogo (GameObjects), permite visualização do ambiente de jogo e adicionação de recursos através de drag and drop; Jogo: mostra aquilo que o jogador irá ver; Hierarquias: lista todos os GameObjects presentes cenário, nesta janela é possível identificar as dependências entre os objetos; 47

73 Inspetor: permite ajustar as propriedades e adicionar novos componentes aos objetos listados na janela de hierarquias. A criação tradicional de um jogo em Unity 3D consiste resumidamente em construir cenários. A cada cenário são adicionados manualmente recursos da janela projeto ou do próprio Unity 3D. Cada objeto adicionado pode ser visualizado na janela hierarquias, esta janela permite ainda verificar e manipular a dependência entre os objetos. Na janela Inspetor podemos manipular as propriedades dos diversos objetos e adicionar novas componentes (ex.: scripts) a esse objeto. Depois de todos os recursos adicionados e configurados o utilizador pode verificar o resultado final através da janela Jogo. Este processo pode ser descrito como fácil e intuitivo, contudo muito manual. O Unity 3D possibilita ainda adição e manipulação de recursos programaticamente quando necessário. Após o estudo e análise dos diferentes motores de busca disponíveis no mercado, foram escolhidos como opções finais o UDK e o Unity. Ambas as ferramentas são bastante completas e fornecem tudo, ou quase tudo, para o desenvolvimento de um jogo. O UDK é um motor poderoso e flexível com resultados provados. Contudo este é recomendado a utilizadores experientes. Desta forma, a nossa escolha recaiu sobre o Unity 3D pois para além de reunir todos os requisitos necessários para o desenvolvimento da solução, é um motor de jogo poderoso e flexível com uma reduzida curva de aprendizagem que conta com uma vasta comunidade de utilizadores e uma boa coleção de documentação de apoio ao desenvolvimento. Embora o Unity 3D possua uma versão livre que pode ser usada tanto para investigação como para fins comerciais, foi usada uma licença Pro disponibilizada gratuitamente. Outro fator preponderante à escolha apresentada é a possibilidade do desenvolvimento poder ser feito inteiramente em C# e, desta forma, usufruir das características inerentes a esta tecnologia como o modelo de orientação a objetos, uso de interfaces, gestão de memória, entre outros. O C# é uma linguagem de programação usada largamente em escala mundial com o suporte da Microsoft e de uma gigante comunidade de programadores. Outra vantagem é a possibilidade da utilização do ambiente de desenvolvimento integrado (IDE) Microsoft Visual Studio juntamente com o Unity. Este IDE fornece um conjunto valioso de ferramentas como a deteção de erros, intelli-sense, entre outros, e permite ainda um desenvolvimento organizado e dividido em projetos. Foi usada a versão Microsoft Visual Studio 2012, uma vez que é a versão 48

74 mais recente, com suporte à framework 3.5 e disponibilizada gratuitamente pelo portal MSDNAA. Ferramenta de prova de conceito A ferramenta de prova de conceito consiste num protótipo funcional de um jogo de vídeo gerado automaticamente em tempo de execução com o objetivo de permitir observar em ação as diversas técnicas estudadas. Neste subcapítulo serão abordados algumas características desta ferramenta, sendo os detalhes de implementação abordados no subcapítulo Esta ferramenta foi construída sobre o motor de jogo Unity 3D recorrendo a bibliotecas desenvolvidas em C# (framework 3.5). A versão atual do sistema permite gerar automaticamente e em tempo de execução um ambiente de jogo de vídeo (terreno, agentes e obstáculos) com base num conjunto de atributos definidos manualmente antes da execução, através do menu de configuração e/ou informação contida em ficheiros do tipo XML. Cada ficheiro do tipo XML contém a informação de um ambiente de jogo (simulação). Neste ficheiro é possível indicar: o terreno e especificar as suas características (resolução da malha, número de subdivisões, localização, tamanho e amplitude); obstáculos e descrever para cada um o seu tamanho e localização; NPC s e especificar para cada um destes a velocidade máxima de movimentação e rotação e ainda um caminho pré-determinado (conjunto de pontos de passagem). As simulações são geradas automaticamente por geradores, consoante o tipo de simulação, podendo esta ser ou não aleatória tendo por base um conjunto de regras. A inclusão de uma nova simulação implica a adição de um gerador e alteração do menu da interface. O menu de configuração da aplicação permite escolher a simulação que se pretende efetuar através da seleção do ficheiro XML, podendo ser alterada algumas configurações dessa simulação através da interface. Para além disso, é possível definir o tipo de esquema de divisão e o algoritmo de procura que se pretende aplicar, podendo ser especificado algumas opções como o esquema de cores entre outros (ver Ilustração 24). 49

75 Ilustração 24 - Menu de configuração. Embora o menu de configuração já apresente essa opção, a componente Path Smooter ainda não é inteiramente suportada. Ferramenta de avaliação A ferramenta de avaliação consiste numa aplicação de processamento batch, na qual não é exigida a interação do usuário e onde ocorre o processamento de dados contidos em um ou mais ficheiros XML com vista à avaliação da arquitetura descrita no Capítulo 4. Neste subcapítulo serão abordados algumas características desta, ficando os detalhes de implementação reservados para o subcapítulo Esta ferramenta foi construída sobre as bibliotecas desenvolvidas em C# (framework 3.5) e recebe como parâmetro um ficheiro de configuração em que cada entrada do ficheiro representa uma simulação que se pretende avaliar. Cada entrada é constituída por um conjunto de parâmetros em que cada um aponta para um ficheiro XML específico. Os parâmetros atualmente disponíveis são: esquema de divisão (baseado em grelha ou em quadtree), algoritmo de procura em grafos (A* ou Fringe Search), dimensão do terreno (pequena, média ou grande), procedimentos e número de repetições a efetuar dos procedimentos. Os procedimentos são constituídos por um conjunto de operações que são executadas de forma linear, sendo o resultado de cada operação avaliado (tempo de 50

76 processamento e memória) e guardado num ficheiro específico com base na operação e simulação. O sistema atualmente suporta as seguintes operações: inicialização do grafo de navegação; inicialização do algoritmo de procura; adição de objetos durante a inicialização do grafo de navegação (implica apenas uma conexão de vizinhos); adição de objeto (implica uma conexão por de vizinhos por cada objeto adicionado). dimensão do espaço de procura; quantização (conversão de uma posição do ambiente de jogo em nó); localização (conversão de um nó em uma posição do ambiente de jogo); conexão de vizinhos; procura de caminho. Para a geração do ficheiro XML de procedimentos foram construídos dois tipos geradores: um independentemente da ferramenta de prova de conceito e outro que recorre à aplicação de prova de conceito com o objetivo de avaliar os ambientes Procedimentos Num primeiro momento realizou-se uma pesquisa bibliográfica geral sobre o tema dos jogos de vídeo, com o objetivo de aumentar o conhecimento na área e perceber o estado da arte. Devido ao campo dos vídeos jogos ser bastante vasto, o conhecimento inicialmente adquirido foi usado em reuniões de supervisão para debater ideias e colocar/descartar de hipóteses de estudo. Num segundo momento, com o objeto de estudo mais amadurecido procedeu-se a uma nova pesquisa bibliográfica, desta vez mais focada aos objetivos traçados na fase anterior. A revisão bibliográfica dividiu-se principalmente em três campos: representação de espaços físicos do vídeo jogo com vista à navegação, resolução do problema de procura de caminhos e locomoção de agentes artificiais em jogos de vídeo. Realizou-se novamente um conjunto de reuniões onde desta vez procedeu-se ao planeamento e delineamento do estudo. A pesquisa efetuada permitiu perceber o estado da arte nesta área de estudo e ainda entender melhor os desafios que se pretende superar. Foi ainda possível realizar uma pesquisa dos motores de jogo mais atuais e usados no mercado com vista ao desenvolvimento do projeto. Esta fase terminou com a elaboração do relatório preliminar. 51

77 Na fase seguinte procedeu-se ao desenho do sistema com base nos objetivos traçados e nos conhecimentos adquiridos até então. Durante esta fase procedeu-se ainda a pesquisa bibliográfica contínua, de forma a limar arestas do estudo, como por exemplo questões não contempladas até então. Nesta fase ocorreu também a familiarização com tecnologia a ser usada. Embora só na fase seguinte estivesse planeada a implementação do desenho do sistema, também se procedeu a um conjunto de provas de conceito. As provas de conceito foram importantes na medida que permitiram guiar o desenvolvimento do sistema com base em dados reais. Desta forma, foi possível proceder a otimizações, evitar o uso de técnicas mais complexas e estimar prazos de forma mais precisa e realista. Com a implementação acabada foi possível testá-la e avaliá-la de forma geral através da ferramenta prova de conceito. Contudo, só depois do desenvolvimento da ferramenta de avaliação foi possível avaliar, de forma concreta, o sistema. A avaliação do sistema para além de permitir proceder a algumas alterações, com vista ao aumento do desempenho, possibilitou a recolha de dados para o presente estudo. O momento final consistiu na elaboração do relatório final onde foram indicados os resultados dos dados obtidos, e feita uma análise critica e discussão dos mesmos Metodologia estatística Para o tratamento estatístico, dos dados recolhidos foram removidos os 50 melhores e piores resultados. Posteriormente foi calculada a média dos dados recolhidos para cada operação e modo de execução, tendo posteriormente sido feita a comparação dos resultados obtidos. 3.3 Sumário Neste capítulo foi descrito em detalhe a metodologia de investigação usada para alcançar os objetivos propostos. Foi delineado o estudo e o material e métodos usados, tendo sido descrito a amostra alvo as ferramentas e procedimentos usados. 52

78 Capítulo 4 Trabalho realizado 4.1 Análise do problema No desenvolvimento de um projeto é fundamental realizar uma análise antes da conceptualização de qualquer desenho da aplicação. É necessário olhar para os objetivos do estudo (ver Capítulo 1.2 ), para os trabalhos relacionados existentes até então (ver Capítulo 2 e 2.2 ) e compreender os problemas que se pretendem resolver, para depois ser possível conceber um desenho capaz de ser implementado de acordo com os requisitos funcionais especificados. É importante perceber o contexto onde o projeto se insere, tais como as limitações e restrições a que se está sujeito. O problema do pathfinding em jogos de vídeo está relacionado com requisitos: de tempo real e de múltiplos agentes. Estes requisitos, por sua vez, estão limitados aos recursos do sistema computacional, nomeadamente a velocidade de processamento e memória. A natureza finita destes recursos e a noção de que a IA de um jogo de vídeo é apenas uma das diversas componentes de um jogo e que apenas tem uma pequena fatia destes recursos reservada para ela, mostram a importância da utilização e gestão correta destes recursos. Desta forma, a análise do nosso problema deverá ter sempre por base estas premissas. Na análise dos desafios propostos para o projeto é também essencial estudar as alternativas capazes de responder aos requisitos funcionais. O presente estudo tem como problema principal o desenvolvimento de um sistema de navegação baseado em grafos de navegação gerados automaticamente durante o tempo de execução, com o objetivo de suportar a geração on-line de ambientes virtuais. A geração automática de ambientes virtuais afasta a possibilidade do uso de técnicas que usem dados pré processados do ambiente de jogo, como por exemplo o uso 53

79 de grafos de navegação hierárquicos. Isto limita o leque das técnicas possíveis de serem empregues e aumenta o problema de lidar com ambientes de jogo de grande dimensão. Para além do requisito de automatismo e tempo de execução inerentes ao objetivo principal, a complexidade do estudo é agravada com o delineamento dos requisitos primários e secundários (ver Capítulo 1.2 ). Está-se, portanto, perante um problema complexo com implicações nas diversas componentes do sistema de navegação. Para melhor entendimento da problemática recorremos à técnica Divisão e Conquista, analisando cada problema separadamente e o seu impacto nas componentes do sistema de navegação Geração automática e em tempo de execução de grafos A construção de um grafo de navegação é feita através do esquema de divisão. O esquema de divisão é responsável por dividir o espaço físico do ambiente de jogo em nós e conectá-los posteriormente. A geração automática e em tempo de execução de um grafo de navegação baseado num ambiente de jogo inteiramente novo, implicam um processo: que não necessite da intervenção do ser humano; geração rápida o suficiente, de modo a passar despercebida ao utilizador; construção de um grafo de navegação inteiramente novo; Ambientes de jogo com dimensões diferentes O número de nós de um grafo de navegação está associado ao tipo de esquema de divisão usado e ao tamanho do ambiente de jogo. Quanto maior a dimensão do ambiente de jogo, maior o número de nós do grafo necessário para cobrir o ambiente na sua totalidade. Um grande número de nós, para além de ter repercussão na memória do sistema, que necessita de armazenar toda esta informação, por cada procura de caminho efetuada, o sistema vai alocar mais memória e despender mais tempo de processamento na resolução do caminho, uma vez que tem de percorrer um maior número de nós. Os programadores para lidarem com ambientes de jogo muito grandes geralmente recorrem a grafos de navegação hierárquicos, de modo a diminuir os custos durante a procura de caminhos. Esta técnica implica dividir o ambiente em regiões e fazer corresponder cada região a um nó, o qual será ligado aos restantes nós das outras regiões. Cada região tem um grafo de navegação, em que um dos nós corresponde ao nó que representa a região. Para simplificar as procuras, os programadores ainda recorrem 54

80 a tabelas de indexação das regiões. Contudo esta técnica não é possível ser aplicada no presente estudo, uma vez que o processo de identificação das regiões implica um custo de processamento elevado e necessita do envolvimento do ser humano. Esta técnica é aplicada durante a fase de desenho do mapa sendo as tabelas usadas, na procura de caminho, pré-geradas Múltiplos agentes A gestão de múltiplos agentes é um problema complexo e comum a outras áreas de estudo como por exemplo a robótica. Nos vídeo jogos: está limitada aos recursos do próprio sistema; gerida de forma central ou distribuída; ao encargo de uma ou mais componentes do sistema de navegação. A gestão de múltiplos agentes difere de jogo para jogo, consoante o tipo de jogo, tipo de agente e complexidade da IA. A gestão de múltiplos agentes no presente estudo diz respeito ao suporte de múltiplos agentes, e não à resolução da problemática em si, como por exemplo a colisão de NPC s. A finalidade é possibilitar de forma genérica a aplicação das técnicas abordadas a ambientes com múltiplos agentes, disponibilizando os meios e não a forma de o fazer. A resolução da problemática fica então ao encargo do programador consoante as especificações do vídeo jogo, procuramos assim simplificar o objeto de estudo. O suporte de múltiplos agentes deve ter em conta os recursos limitados do sistema, devendo consumir o menor número possível de recursos. É possível responsabilizar uma ou mais componentes pelo suporte a múltiplos agentes, podendo esta responsabilidade estar centralizada ou distribuída. O tipo de esquema de divisão deve gerar um grafo de navegação que forneça mais informação do que simples pontos-chave do ambiente de jogo, caso contrário os agentes irão deslocar-se sempre pelo mesmo trajeto apresentando um comportamento artificial. Esta componente deve ser central a todos os NPC s, com vista a minimizar o consumo de recursos e evitar a atualização e manutenção da congruência de diversos grafos de navegação. A camada responsável pela procura de caminhos pode ser centralizada ou descentralizada. A centralização implica uma instância da camada de procura de caminhos, responsável pela resolução de todos os pedidos de caminhos de todos os NPC s. A descentralização desta camada implica várias instâncias a resolver pedidos de caminho simultaneamente. Trata-se de um trade off entre o número de pedidos a resolver ao mesmo tempo e o número de recursos consumidos por cada instância. 55

81 A complexidade da camada locomoção no suporte de múltiplos agentes está condicionada à distribuição de responsabilidades pelas diversas camadas e centralização, ou não, de camada locomoção Diferentes tipos de unidades Na maioria dos jogos de vídeo em que existe diferentes tipos de unidade, cada tipo possui um grafo de navegação distinto. Esta abordagem permite assim que o caminho retornado seja sempre correto para esse tipo de NPC. Esta abordagem apresenta as seguintes desvantagens: armazenamento em memória de um grafo de navegação, por cada tipo de unidade; em ambiente de jogo dinâmico quando existe uma alteração ao ambiente, todos os grafos de navegação necessitam de ser atualizados; não pode ser aplicada em mapas gerados automaticamente durante o tempo de execução, uma vez que esta informação é incluída durante a fase de desenvolvimento. Outra abordagem possível é incluir, no algoritmo de procura de grafo, heurísticas que verifiquem, por exemplo, o tamanho da unidade e determinem um caminho válido para esta unidade. Esta abordagem tem duas desvantagens: aumento do processamento, devido ao número de heurísticas avaliadas a cada procura realizada; uso de informação pré-processada do ambiente de jogo. A impossibilidade de utilizar estas duas abordagens com base nos requisitos propostos remete-nos para uma terceira hipótese, que consiste na responsabilização da camada locomoção, na validação dos caminhos devolvidos pelo algoritmo de procura e solicitação de novo caminho caso este não seja possível. Contudo, esta abordagem tem a desvantagem de que cada agente irá ter de continuamente validar o caminho devolvido pelo pathfinding, o que consome bastantes recursos no caso de haver muitos agentes Deteção de obstáculos dinâmicos Os agentes que navegam em ambientes dinâmicos, devem conseguir detetar a presença de obstáculos dinâmicos. A deteção de obstáculos dinâmicos consiste na deteção de alterações ao ambiente de jogo, como por exemplo, a adição de uma caixa ao ambiente de jogo que anteriormente não existia. As alterações ao ambiente podem fazer com que, os caminhos determinados anteriormente pelo pathfinding, estejam agora 56

82 inválidos, por exemplo o caminho intersetar a localização onde agora se encontra a caixa. A deteção de obstáculos dinâmicos é normalmente efetuada através de duas abordagens diferentes. A primeira abordagem é semelhante à abordagem descrita para a lidar com diferentes tipos de unidade (ver capítulo ). Nesta abordagem, existe a responsabilização da camada locomoção, pela deteção de alterações ao ambiente de jogo. Ao ser detetado um novo obstáculo a camada deve solicitar a resolução de um novo caminho. A segunda abordagem envolve a modificação do grafo de navegação, de forma a representar corretamente o ambiente de jogo e a invalidação de todos os caminhos determinados até então. A atualização do grafo de navegação está ligada ao tipo de esquema de divisão do ambiente usado. A invalidação de caminhos é necessária, uma vez que ocorre a alteração do grafo de navegação, desta forma é possível invalidar caminhos ainda válidos. Esta aproximação constitui um problema uma vez que todos os agentes em movimento irão solicitar novos caminhos, o que pode sobrecarregar o sistema. 4.2 Desenho da solução Após a análise do problema é então necessário desenhar uma solução possível de ser implementada, que cumpra com todos os requisitos e solucione os problemas identificados anteriormente Sistema de navegação A complexidade da problemática em estudo e o conjunto de requisitos traçados implicam uma solução integrada dos componentes do sistema de navegação como um todo. A análise centrada no problema dá lugar, neste capítulo, ao desenho da solução centrada em cada componente do sistema de navegação. Locomoção A camada locomoção é descentralizada pelos diversos agentes, esta decisão visa endereçar um conjunto de problemas: aumentar a escalabilidade do sistema; suportar ambientes dinâmicos. suportar diferentes tipos de agentes; 57

83 permitir definir pontos-chave no mapa, ex.: ronda de patrulha. O aumento da escalabilidade é alcançando com a independência de cada agente ou tipo de agentes. Embora não faça parte dos objetivos do presente trabalho, será nesta camada que, por exemplo, se pode resolver o problema de colisão de agentes através por exemplo de algoritmos determinísticos. O suporte a ambientes dinâmicos é alcançado através da realização de pedidos frequentes de resolução de caminho, permitindo assim que o agente detete as alterações ocorridas ao grafo de navegação. Desta forma evita-se a adição de heurísticas à camada de procura de caminhos, esta decisão reflete o tradeoff, entre o número de heurísticas avaliadas em cada procura de caminho e o custo de utilização de técnicas como o raycasting. Embora as técnicas, como o raycasting, estejam associadas ao consumo de recursos do sistema, o número de validações de caminho pode ser inferior ao número de caminhos retornados. A validação de caminhos é destinada a dar suporte a diferentes tipos de unidade, e não à deteção de obstáculos dinâmicos. Como cada agente ou tipo de agente possui uma camada de locomoção é possível especificar pontos-chave a esse agente específico ou tipo de agente. Representação do ambiente O esquema de divisão é responsável pela geração do grafo de navegação sendo uma peça fundamental na solução do problema em análise. Deste modo, foi dada especial atenção aos diversos tipos de esquemas de divisão, tendo sido analisado as vantagens e desvantagens de cada abordagem (ver 2.2 ) em comparação com os objetivos em estudo (ver Capítulo 4.1 ). A Tabela 7 sintetiza a análise efetuada. Pontos de passagem Grelha Malha de navegação Espaço de procura Mais pequeno Maior: espaço navegável e não navegável Melhor rácio: nº de nó vs. dimensão do ambiente Geração 100% automática Geração em tempo de execução Não Sim Não Não Sim Não Suporte de Não, a operação de Sim, a operação Não, a operação de ambientes atualização/geração dispendiosa de atualização atualização/geração 58

84 dinâmico em recursos computacionais e de baixo custo. dispendiosa em informação limitada do recursos ambiente de jogo. computacionais. Tabela 7 - Objetivos vs. tipo de esquema de divisão. A análise da tabela mostra, que o objetivo de geração automática e tempo de execução do grafo de navegação, limitam os esquemas divisão ao esquema baseado em grelha. O esquema de divisão baseado em grelha tem a vantagem de poder ser aplicado a ambientes dinâmicos, devido às operações de atualização serem rápidas e de não haver a necessidade de refazer o grafo de navegação. Outra vantagem é que cada nó deste tipo de representação possui informação que pode ser usada no suporte de diferentes tipos de unidade. O esquema de divisão baseado em grelha tem, como principal desvantagem, o grande espaço de pesquisa e o grande fator de ramificação que têm efeitos negativos no consumo de memória e tempo de processamento em cada pesquisa efetuada pelo pathfinding (Anguelov, 2011). Esta desvantagem é crítica relativamente ao requisito de suporte de diferentes tamanhos de ambientes de jogo. Existem algumas técnicas propostas desenvolvidas para aliviar o consumo de recursos e acelerar o pathfinding. Estas técnicas são geralmente categorizadas em três grupos: redução do espaço de procura através da abstração usada, aperfeiçoamento da precisão das heurísticas que guiam a pesquisa (aplicada aos algoritmos de procura) e por último, a deteção de becos sem saída ou métodos de poda de espaço (Harabor, 2011). A maioria das técnicas usadas, na primeira e terceira abordagem, envolvem pré-processamento, desta forma optamos por mitigar o problema do pathfinding pela redução do espaço de procura, usando a abstração quadtree. A quadtree reduz consideravelmente o espaço de procura e, no pior caso, apresenta um espaço de procura igual à grelha regular. Com esta abordagem procuramos diminuir o espaço de procura e aliviar o consumo de recursos do sistema computacional na procura de caminhos. Segundo a análise realizada no capítulo 4.1, a nossa solução recorre a uma camada de representação do ambiente centralizada numa única instância. Embora esta decisão limite a escalabilidade da aplicação, tem por objetivo diminuir a alocação de memória e tempo de processamento na atualização de diversas instância. 59

85 Algoritmos de procura em grafos O requisito de geração automática e em tempo de execução limita a escolha de algoritmos de procura em grafos, que não baseiem o seu algoritmo em dados préprocessados do ambiente de jogo (ex.: Hierarchical Path-Finding (HPA*) (Botea, Martin, Schaeffer, & Tg, 2004), o HAA* (Harabor & Botea, 2008), ou soluções de pathfinding dinâmico como o LPA*, o DHPA* ou SHPA* (Kring, Champandard, & Samarin, 2010) e ao mesmo tempo apresentem um desempenho rápido com baixo consumo de recursos do sistema computacional. Selecionamos dois algoritmos que iremos estudar e comparar: A*, uma vez que se trata de um algoritmo bastante conhecido e utilizado praticamente em todos os vídeo jogos; Fringe Search, que mostrou resultados de processamento mais rápidos e um consumo de memória maior quando comparado com o A* (Björnsson et al., 2005). A primeira escolha baseia-se por ser o algoritmo padrão usado nos vídeos jogos e a segunda escolha justifica-se devido a ser um algoritmo pouco conhecido e estudado, que aponta resultados superiores ao A*. Com vista ao suporte de múltiplos agentes, a nossa solução recorre às potencialidades da tecnologia multithreading existente em algumas plataformas de jogo, desta forma várias instâncias desta camada podem ser criadas e usadas na resolução de caminhos. A solução consiste então em ter várias instâncias a iterar sobre um espaço de procura comum, resultando no aumento do número de pedidos processados com pouco custo de memória. 4.3 Implementação Este capítulo descreve a implementação da solução, tendo em consideração os requisitos técnicos e funcionais identificados e seguindo a especificação da arquitetura descrita anteriormente. A arquitetura foi definida como uma biblioteca e é o núcleo da solução. Este núcleo contém todas as estruturas e algoritmos necessários ao sistema de navegação os quais aprofundamos neste capítulo. Para o desenvolvimento e exploração do sistema de navegação foram desenvolvidas duas ferramentas distintas: ferramenta de prova de conceito e ferramenta de avaliação (ver Ilustração 25). 60

86 Ilustração 25 - Arquitetura subdividida em três módulos distintos. A caracterização de cada uma destas ferramentas é feita no capítulo 3.2.2,neste capítulo são abordados os detalhes de implementação de cada uma Sistema de navegação O sistema de navegação, foi implementado como uma biblioteca usando a tecnologia C# Framework 3.5, versão suportada pela versão mais atual do Unity 3D 4.0.l. A construção da arquitetura como biblioteca permite separar a lógica de negócio (sistema de navegação), das aplicações em si (ferramenta de prova de conceito e ferramenta de avaliação), possibilitando o uso da biblioteca por qualquer aplicação desenvolvida em C# com Framework 3.5, ou superior. Do ponto de vista técnico a implementação do sistema de navegação recorreu ao paradigma da programação orientada a objetos usando os artefactos de abstração, encapsulamento, herança e polimorfismo, sendo promovido a simplificação da implementação e a reutilização de código. O sistema de navegação é composto por 4 módulos: comum: conjunto de variáveis, funções e classes partilhada pelos restantes módulos e por aplicações desenvolvidas que explorem esta biblioteca; locomoção: responsável por gerir agentes. Esta camada interage com a camada de algoritmos de procura para a resolução de caminhos; representação do ambiente: responsável por gerir a representação do ambiente na forma de grafo de navegação; algoritmos de procura: responsável por gerir os algoritmos de procura. Esta camada interage com a camada responsável pela gestão da representação do ambiente; 61

87 Os módulos representação do ambiente e algoritmos de procura são geridos respetivamente por um gerente. Cada gerente é responsável por inicializar e gerir uma ou mais instâncias desse módulo e responder a pedidos. Locomoção A descentralização desta componente implica que cada NPC implemente uma instância da camada de Locomoção, cada instância dispõe de: conjunto de atributos, que podem ser omissos, destinados a um NPC específico ou a um tipo de NPC. Dentro destes atributos é possível definir um caminho prédefinido, constituído por um conjunto de localizações do ambiente de jogo (semelhante aos pontos de passagem); conjunto de métodos, responsável pela gestão da locomoção do agente. Tal como os atributos, estes métodos também podem ser omissos, destinados a um NPC específico ou a um tipo de NPC. É da competência desta camada fazer deslocar corretamente o NPC pelo ambiente de jogo ao longo do caminho pré-definido, e tendo por base um conjunto de atributos. Para a realização desta tarefa, cada NPC envia pedidos de resolução de caminho ao gestor de procura de caminhos. Cada pedido é composto por duas posições: posição inicial (localização do NPC no ambiente de jogo) e posição final (uma localização do caminho pré-definido). Cada pedido será respondido, sendo cada resposta composta por um indicador do resultado da procura e por uma lista de localizações (caminho entre a posição inicial e posição final). A complexidade desta camada difere de jogo para jogo, a implementação realizada destina-se a um comportamento básico, nomeadamente a um comportamento de patrulha. Este comportamento é destinado ao cumprimento dos objetivos e requisitos do estudo, podendo esta implementação ser facilmente estendida para atingir outros fins. Os atributos base desta camada são: atributos físicos do NPC, inerentes à locomoção: Atributo canmove maxspeed Descrição Indicador que assina-la se se o NPC pode movimentar-se ou não. Velocidade máxima em unidades por segundo. rotationspeed Velocidade de rotação em unidades por segundo. minmove Movimento mínimo que o agente pode realizar. Tabela 8 - Lista de atributos físicos de um NPC usados pela camada de locomoção. 62

88 atributos de procura de caminho: Atributo Descrição refreshpathsearchrate Determina com que frequência é realizada uma procura de caminho. cansearch Indicador que assinala se a procura de caminhos pode ser realizada. Tabela 9 - Lista de atributos de procura de caminho de um NPC usados pela camada de locomoção. atributos de comportamentais do NPC: Atributo reachednavpointdistance Descrição Distância do nó ao agente em que se considera que o agente alcançou o nó. slowdowndistancetonavpoint Distancia do nó ao agente em que este irá abrandar ao aproximar-se. Tabela 10 - Lista de atributos comportamentais de um NPC usados pela camada de locomoção. A especificação dos algoritmos por detrás do movimento do NPC, não será descrita, uma vez que saem do âmbito do trabalho. Contudo iremos descrever os métodos responsáveis gestão de pedidos e respostas de resolução de caminho. A implementação desta componente usa duas rotinas como base (pedido de resolução de caminho e decisão do próximo movimento) e um ouvinte de eventos de retorno de resposta a pedidos de resolução de caminho. Devido à complexidade começamos por definir as variáveis auxiliares usadas pelo sistema: Variável system.time lasttimerefreshpath issearching waitingforrepath initialpoint destinypoint Descrição Tempo atual de sistema. O último tempo em que foi realizada uma procura de caminho. Indicador que assinala se o sistema está à procura de caminho. Indicador que assinala se o sistema está à espera de caminho. Ponto 3D com a posição inicial. Ponto 3D com a posição final. 63

89 navpointlist navpointindex pathfinderresponse SearchResult Path pathindex Lista que contem localizações chave do ambiente de jogo (pontos de passagem). Índex do ponto de passagem atual (navpointlist). Estrutura de resposta do gestor de procura de caminhos. Indicador que assinala o resultado da procura realizada pelo algoritmo de procura (valores possíveis: PATH_FOUND, PATH_NOT_FOUND e PATH_INCOMPLITED). Lista de localizações (path) que descreve o caminho entre dois pontos. Índex da localização de destino atual do NPC. nodepathendreached Indicador que assinala se o NPC ao final do caminho. Tabela 11 - Lista de variáveis auxiliares usadas na camada locomoção. O pseudo-código seguinte descreve a rotina de pedido de resolução de caminho do NPC. Depois da inicialização do agente, esta rotina irá estar constantemente em execução: # Descrição 1. O sistema inicia as variáveis auxiliares: Destino Origem navpointindex 0 lasttimerefreshpath issearching waitingforrepath False False 2. O sistema inicia um ciclo infinito O sistema tenta enviar um pedido de procura de caminho: Se o tempo desde a ultima vez que foi realizada uma procura de caminho for maior ou igual à frequência de procura de caminho e se o sistema não se encontra à procura de caminho (system.time lasttimerefreshpath >= refreshpathsearchrate e issearching = false): O sistema procura caminho: O sistema valoriza as seguintes variáveis: 64

90 Destino lasttimerefreshpath issearching initialpoint destinypoint Origem system.time false Posição onde NPC se encontra atualmente no mapa. navpointlist[navpointindex] O sistema envia um pedido de procura de caminho ao gestor com o ponto inicial e o ponto de destino (para mais informação sobre o pedido de procura de caminho ver capítulo ) Caso contrário, o sistema espera até poder enviar um pedido de resolução de caminho: Se o sistema está à espera de resolução de caminho (waitingforrepath = true): O sistema interrompe o ciclo uma vez que já existe uma rotina em execução; Caso contrário: O sistema valoriza a variável waitingforrepath = true e espera x milissegundos até ser tempo de enviar um pedido de procurar caminho, onde: O sistema valoriza a variável waitingforrepath a false e volta a tentar enviar um pedido de procura de caminho (2.1) 2.2 O sistema espera durante o tempo definido pelo atributo refreshpathsearchrate. Tabela 12 - Pseudo-código da rotina de pedido de resolução de caminho da camada locomoção. O pseudo-código descrito em baixo está encapsulado num ouvinte de eventos, e é executado quando uma instância de algoritmo de procura em grafos retorna uma resposta. Este método tem por objetivo atualizar o caminho que o NPC vai realizar: # Descrição 1. Se a resposta do gestor de procura de caminho não estiver vazia (pathfinderresponse = null): O sistema valoriza a variável issearching = false e sai da função; 2. Caso contrário: 65

91 2.1 Se foi encontrado um caminho (pathfinderresponse.path!= null e pathfinderresponse.searchresult = PATH_FOUND): O sistema valoriza a variável pathindex com o valor Caso contrário: O sistema valoriza a variável issearching a false e sai da função; Tabela 13 - Pseudo-código do ouvinte de eventos de resposta de caminhos da camada locomoção. O último trecho de pseudo-código descreve resumidamente a rotina que decide o destino do próximo movimento do NPC # Descrição 1. Se o caminho da resposta do gestor de procura de caminho não estiver vazia (pathfinderresponse.path = null): O sistema retorna a indicação para o agente não se mover; 2 Se o NPC já percorreu o caminho retornado pelo gestor de procura de caminho (pathindex >= pathfinderresponse.path): 2.1 Se o NPC já percorreu todos os pontos de passagem (navpointindex >= navpointlist.length) o sistema indica que o próximo ponto de passagem é o primeiro elemento da lista dos pontos de passagem (movimento de patrulha): navpointindex = 0; Caso contrário, o sistema indica que o próximo ponto de passagem é o elemento seguinte da lista dos pontos de passagem: navpointindex += 1; O sistema valoriza a false as variáveis issearching e nodepathendreached. O sistema retorna a indicação para o agente não se mover; 3 Se a distância do NPC ao ponto de passagem for menor ou igual à distância mínima que um agente tem de estar do nó para este ser considerado como alcançado (reachednavpointdistance): 3.1 Se o agente ainda não chegou ao final do caminho (nodepathendreached = false): nodepathendreached = true 3.2 Se o NPC já percorreu o caminho retornado pelo gestor de procura de caminho 66

92 (pathindex = pathfinderresponse. Length): Se o NPC já percorreu todos os pontos de passagem (navpointindex >= navpointlist) o sistema indica que o próximo ponto de passagem é o primeiro da lista dos pontos de passagem: navpointindex = 0; Caso contrário, o sistema indica que o próximo ponto de passagem é o ponto de passagem seguinte: navpointindex += 1; O sistema valoriza a false as variáveis issearching e nodepathendreached. 3.3 Caso contrário, o NPC chegou a uma localização do caminho retornado pelo gestor de procura de caminho: O sistema valoriza as variáveis: pathindex += 1; nodepathendreached = false; O sistema retorna a indicação para o agente não se mover; 4 O sistema desloca-se para a localização pathfinderresponse.path[pathindex]. Tabela 14 - Pseudo-código da rotina de determinação do próximo movimento do NPC. A frequente procura de caminho permite ao NPC lidar com ambientes de jogo dinâmicos, com um espaço de erro definido pelo atributo refreshpathsearchrate. Este atributo deve, assim ser, valorizado com um valor baixo quando o ambiente sofre alterações frequentes ou no caso de o NPC s deslocar-se a uma velocidade muito elevada (maxspeed). Devido à falta de tempo, não foi possível implementar o sistema de validação de caminhos que fazem parte dos requisitos secundários do estudo. Caso tivesse sido implementada, esta funcionalidade iria ocorrer depois da resposta do gestor de procura de caminhos. Representação do ambiente A implementação da camada de representação do ambiente dividiu-se em duas componentes: gestor e esquema de divisão. Gestor 67

93 O gestor tem como principal objetivo inicializar e gerir o esquema de divisão e ainda disponibilizar o espaço de procura á camada de algoritmos de procura em grafo. Apenas existe uma instância do gestor que implementa um gestor genérico. O gestor genérico descreve um conjunto base de atributos e métodos que todas as implementações do gestor devem suportar. Cada implementação do gestor deve possuir a referência a um esquema de divisão genérico, que tem por objetivo o suporte a diversos tipos de esquema de divisão, embora atualmente o sistema suporte apenas dois tipos (baseado em grelha e baseado em quadtree), é possível no futuro implementar outros esquemas de divisão baseados no esquema de divisão genérico com o mínimo de alterações ao sistema. Esta referência genérica, em tempo de execução, é atribuída a um dos tipos de esquema de divisão suportados pelo sistema. Este atributo tem por objetivo evitar que outras camadas manipulem diretamente o esquema de divisão, ficando essa tarefa ao encargo do gestor. Devendo as demais camadas, recorrer aos métodos disponibilizados pelo gestor. Atualmente o sistema suporta os seguintes métodos: Método Descrição Init Insert InsertAtLoad Inicialização do gestor de grafos de navegação e do grafo de navegação. Insere um objeto no grafo de navegação. Em cada inserção será feita a atualização das conexões (vértices) dos nós vizinhos do nó ou nós onde o objeto foi inserido. Insere um objeto no grafo de navegação, sem atualização das conexões aos nós vizinhos do nó ou nós onde o objeto foi inserido. ConnectNeighbours Atualização das conexões dos nós vizinhos de todos os nós do grafo de navegação. GetNode Traduz uma localização num nó do grafo de navegação. Tabela 15 - Métodos suportados pelo gestor da camada de representação do ambiente. Esquema de divisão O esquema de divisão divide, o espaço do ambiente de jogo, num grafo de navegação. O grafo de navegação pode corresponder inteiramente ao espaço de procura usado pela camada de algoritmos de procura em grafos ou ser necessário algum processo que converta o grafo de navegação no espaço de procura, como acontece no grafo de navegação baseado na quadtree que será abordado mais à frente. 68

94 De seguida, para melhor compreensão, são detalhadas as componentes genéricas da camada de representação do ambiente. O requisito do sistema de navegação, de suportar mais do que um esquema de divisão implica, que todos os esquemas de divisão sejam uma instância de um esquema de divisão genérico. Cada esquema de divisão deve: gerar um espaço de procura linear, nomeadamente um array linear; possuir um conjunto de parâmetros que, guarde a localização e o tamanho do ambiente de jogo; possuir um conjunto de métodos, que suporte os métodos disponibilizados pelo gestor da camada de representação do ambiente (ver Tabela 15). Cada esquema de divisão tem como argumento de inicialização a posição e tamanho do ambiente de jogo, e o tamanho mínimo do nó. O grafo de navegação e o array linear são compostos por nós, embora estes possam ser específicos a cada tipo de esquema de divisão, estes implementam a partir de um nó genérico. O nó genérico deve possuir: Id; conjunto de parâmetros que guarde a localização e o tamanho no nó; custo de navegação no nó (obstáculos e tipo de terreno); array linear, que contem os vizinhos do nó; array linear, que contem os custos da conexão aos vizinhos (relação um para um com a lista de vizinhos). A camada de representação do ambiente suporta atualmente dois esquemas de divisão: baseado em grelha e baseado em quadtree. Baseado em grelha Geração A geração do grafo de navegação, através da divisão do ambiente de jogo pelo esquema de divisão baseado em grelha, consiste na imposição de uma grelha sobre o ambiente de jogo. Com o intuito de simplificar a implementação, atualmente só estão suportados ambientes de jogo com a figura geométrica quadrada, o mesmo se aplica ao tipo célula que compõe a grelha. 69

95 Na inicialização da grelha é determinado a dimensão do espaço de procura (número de células). Uma vez que um dos objetivos de estudo é a comparação entre os diversos esquemas de divisão, é necessário que a aplicação de cada um dos esquemas de divisão ao mesmo ambiente de jogo, origine o mesmo número nós que constitui o espaço de procura. Desta forma, a dimensão do espaço de procura não pode ser simplesmente determinada pela verificação do número de vezes que o ambiente de jogo contém a dimensão mínima da célula indicada por parâmetro. Esta decisão de implementação é justificada pela forma como a quadtree divide o espaço. A quadtree divide o ambiente de jogo em 4 regiões recursivamente, é possível assim, que a dimensão dos nós gerados na profundidade máxima da quadtree, não correspondam ao tamanho mínimo da célula indicado resultando num espaço de procura mais pequeno. æ ç è Tespaço _ procura = Tambiente Equação 2 Tamanho do espaço de procura em grelhas. Tmínimo ö ø 2 Por exemplo, um ambiente de jogo com o tamanho de lado igual a 20 unidades e tamanho mínimo de lado da célula 2 unidades, o esquema de divisão baseado em grelha gera um espaço de procura de 100 nós, enquanto o esquema de divisão baseado em quadtree gera um espaço de procura máximo de 16 nós. Isto acontece uma vez que a quadtree, segundo o exemplo, apresenta uma profundidade máxima de 2 com cada célula a apresentar um tamanho mínimo de 2,5 unidades. Para o esquema de divisão baseado em grelha, gerar um espaço de procura igual ao esquema de divisão baseado em quadtree, é necessário que o tamanho das células da grelha seja igual ao tamanho das células da quadtree na sua profundidade máxima. Para isso, foi implementado um algoritmo semelhante à quadtree. Neste algoritmo o tamanho mínimo indicado é usado como referência para determinar o tamanho mínimo da célula suportado pela quadtree. Desta forma, vamos determinar a profundidade máxima como se estivéssemos a tratar de uma quadtree, através da fórmula: profundidade _ max Log 2 Equação 3 - Profundidade máxima em quadtree. T T ambiente mínimo 70

96 Através da profundidade máxima é possível calcular o tamanho mínimo da célula com a fórmula: T mínimo 2 p T Equação 4 Tamanho mínimo da célula em quadtree. ambiente rofundidade _ max Posteriormente ao cálculo do tamanho mínimo da célula é possível determinar o espaço de procura através da fórmula indicada na Equação 4 substituindo o tamanho mínimo da célula indicada pelo tamanho mínimo da célula determinada pelo algoritmo usado na quadtree. Limiar Ao ser adicionado um objeto à grelha, qualquer célula que intersecte o objeto é considerada como ocupada, não sendo possível ao agente caminhar sobre esta. Espaço de procura O grafo de navegação gerado pelo esquema de divisão baseado em grelha corresponde diretamente ao espaço de procura. A grelha imposta ao ambiente de jogo é armazenada através da abstração de um array linear. Em comparação com a abstração de um array multidimensional, esta abordagem permite baixar o consumo de memória e ainda acelerar o processo de procura. Indexação O esquema de divisão baseado em grelha ao ser imposto no ambiente de jogo vai dividir o ambiente em nós, a cada nó é atribuído um id de forma incremental por linha, a Ilustração 26 exemplifica a atribuição de Id s: Ilustração 26- Exemplo de abstração multidimensional da grelha e atribuição de Id's para cada célula. 71

97 A abstração em grelha usada na Ilustração 26, na realidade não existe, uma vez que a nossa implementação, armazena e manipula o grafo de navegação de forma linear. A abstração em grelha visível na Ilustração 26 na realidade Ilustração Ilustração 27 - Exemplo de abstração linear da grelha e atribuição de Id's para cada célula. É possível manipular através do Id a abstração linear da grelha como se estivéssemos a lidar com a abstração multidimensional da grelha, recorrendo para isso a um conjunto de funções que serão descritas abaixo: I d Equação 5 Id em grelha. Linha ncolunas Coluna C oluna d % n Equação 6 - Obtenção da coluna através do Id. I C olunas C oluna C oordenada_ A X ltura n C olunas Equação 7 - Obtenção da coluna através da coordenada x. Linha Equação 8 - Obtenção da linha através do Id. Id ncolunas 72

98 L inha C oordenada_ Z n L arg ura L inhas Equação 9 - Obtenção da linha através da coordenada z. Vizinhos A determinação de vizinhos é um processo simples, para cada nó o sistema percorre os nós existentes na linha e coluna anterior e posterior onde o nó se encontra e é guardada a referência de cada vizinho num array linear. A Ilustração 28 mostra para o nó identificado pela linha i e coluna j (i, j), as coordenadas por linha e coluna de cada um dos seus vizinhos. A Ilustração 29 mostra a distribuição num array linear dos vizinhos mostrados na Ilustração 28. Ao mesmo tempo que este processo decorre, para cada vizinho encontrado é determinado o custo da ligação (custo de navegação) com base na posição do vizinho face ao nó. O custo de navegação no sentido diagonal superior ao custo de deslocação no sentido vertical ou horizontal. O número de elementos em cada array pode diferir de nó para nó, caso o nó se localize numa das fronteiras do ambiente de jogo. Desta forma um nó pode ter no máximo 8 vizinhos e no mínimo 3 vizinhos. Esta abordagem permite diminuir o consumo de memória e evitar iterações desnecessárias durante a procura de caminho entre dois pontos. Coluna j - 1 j j + 1 i Linha i 1 (i, j) 5 i Ilustração 28 - Determinação de vizinhos do nó (i, j). (i+1, j-1) (i, j-1) (i-1, j-1) (i-1, j) (i-1, j-1) (i, j+1) (i+1, j+1) (i+1, j) Ilustração 29 - Disposição dos vizinhos do nó (i, j) num array linear. 73

99 Quantização/Localização Para determinar o nó que contém uma determinada localização, é necessário determinar o Id do nó, para isso o sistema recorre às funções descritas em baixo. Primeiro vamos determinar a coluna e a linha que essa localização corresponde e com essa informação é determinado o Id do nó. Foi estabelecido que cada nó é representado pelo seu ponto médio, a determinação da localização de um determinado nó, pode ser determinada através da consulta do atributo do nó center, ou através das seguintes funções: C oordenada_ x C oluna( x) T min T 2 min Equação 10 Obtenção da coordenada x. C oordenada_ z L inha( x) T min T 2 min Equação 11 - Obtenção da coordenada z. Baseado em quadtree Geração O grafo de navegação gerado pelo esquema de divisão baseado na quadtree consiste na subdivisão recursiva do espaço em quatro regiões ou quadrantes. A implementação da quadtree é semelhante a tantas outras implementações, para além de implementar o esquema de divisão genérico, é constituída por: uma referência ao nó raiz; um limiar; uma profundidade máxima. Cada nó para além de implementar o nó genérico, é composto por: uma referência (apontador) para o nó pai, no caso do nó raiz, esta referência assume o valor null; 74

100 quatro referências, uma para cada um dos nós filhos (quadrantes: Sudoeste (SO - SW), Sudeste (SE) e Nordeste (NE) e Noroeste (NO ou NW), no caso de não haver nós filhos esta referência assume o valor null (ver Ilustração 9). O contexto de aplicação da quadtree e o requisito do sistema de suportar diversos tipos de algoritmos de procura, implicou a proceder a algumas alterações que são abordados nos seguintes subcapítulos: Profundidade máxima Na maior partes das implementações da quadtree, antes da geração desta é passado por parâmetro a profundidade máxima da quadtree, isto é, o número máximo de vezes que a quadtree pode dividir o espaço ambiente de jogo. O requisito de automatismo do nosso sistema faz com que a profundidade máxima seja determinada durante a geração da quadtree, através da função descrita na Equação 3 usando como referencia o tamanho mínimo que uma célula pode apresentar. Limiar e subdivisão Cada quadtree possui um limiar, que determina quando um determinado nó (quadrante) deve ser subdividido. Por norma, este limiar é determinado por um número máximo de objetos que um nó pode conter. Na maioria das vezes quando esse limiar é alcançado, o quadrante só é subdividido se houver um nó filho que contenha totalmente o objeto adicionado, caso contrário a quadtree não procede a mais subdivisões. Este tipo de implementação não é indicado para ser aplicada aos jogos de vídeo. Uma vez que é necessário uma representação ambiente o mais fiel possível. Na implementação efetuada quando um nó contém ou intersecta um objeto adicionado à quadtree, este nó é subdivido até ser alcançada a profundidade máxima, sendo os nós intersetados pelo objeto, assinalados como ocupados. É possível assim, identificar corretamente a zona ocupada e o espaço livre em que o agente se pode deslocar. Espaço de procura e indexação A geração de um espaço de procura linear, imposta pelos requisitos do sistema, pode ser visto como um problema de representação, nomeadamente a representação linear da quadtree. Uma quadtree linear tem como principal característica, o armazenamento apenas dos nós folha. Isto permite diminuir consideravelmente o espaço, de procura uma vez que os nós não-folha representam o mesmo espaço que os seus nós-filho, podendo assim ser ignorados. Durante a geração da quadtree é inicializado um array linear, com o objetivo de armazenar a referência para os nós folha e de representar o espaço de procura. O tamanho deste array é igual ao número total possível de nós-folha (quando todos os 75

101 nós-folha da quadtree se encontram profundidade máxima), pode ser determinado pela seguinte função: Pr _ max Tespaco _ procurao 4 ofundidade Equação Determinação do espaço de procura numa Quadtree. Geralmente, a quadtree não necessita de ser indexada, uma vez que esta pode ser manipulada e iterada através das referências ao nó pai e aos nós filhos existentes em cada nó. Contudo, a definição da profundidade máxima no início da geração da quadtree, o requisito de representar o espaço de procura de forma linear e o requisito de processamento rápido, abriram o caminho para a implementação da indexação dos nós da quadtree. Desta forma, cada nó da quadtree possui um Id que o identifica. Apesar da implementação da indexação dos nós da quadtree poder ser feita de diversas formas, optou-se por uma solução que permitisse: mapear dados multidimensionais em dados unidimensionais; pesquisa de nós em tempo constante e não dependente do número de elementos existentes na quadtree; referenciar elementos através da linha e coluna em que se encontram (representação em grelha); referenciar diretamente de um nó através do seu id; determinar vizinhos de forma semelhante à determinação de vizinhos no esquema de divisão baseado em grelha. Esta solução recorre àquilo que a Ciência da Computação e Análise Matemática chama de ordem-z, ordem Morton, número de Morton ou sequência de Morton que mapear dados multidimensionais em dados unidimensionais preservando a localização de cada elemento. O número de Morton de um elemento (Id) numa estrutura multidimensional pode ser simplesmente calculado através da intercalação da representação binária das suas coordenadas (z - linha e x - coluna). O processo inverso também é possível uma vez que os bits ímpares da representação binária do Id correspondem à coordenada x e os bits pares correspondem à coordenada z (ver Ilustração 30). 76

102 Ilustração 30 Conversão do número Morton (Id) na coordenada x e z Embora o número de Morton responda ao problema de indexação, existe ainda o problema associado à atribuição do Id a cada um dos nós da quadtree no momento da sua geração. Este problema acontece uma vez que a quadtree é inicializada apenas com o nó raiz, e somente no pior caso se assemelha a uma grelha. Não sendo desta forma possível, obter de forma direta o número da linha e coluna de um determinado nó. A atribuição de um Id (Id(n)) durante a geração de um nó (n) recorre a um conjunto de informações do nó-pai (n-1) e ao código de orientação ( código de orientação( n )). O código de orientação representa o quadrante que o nó ocupa em relação ao nó-pai. Esta relação pode ser verificada através da Tabela 16: Quadrantes Código de orientação Código binário SO 0 00 SE 1 01 NE 2 10 NO 3 11 Tabela 16 - Quadrantes e código de orientação. Ao nó raiz é atribuído o Id 0 e o quadrante SO, sendo os Id s dos restantes nós determinados através da seguinte função: 77

103 I Profundidade_ maxprodundidaden ( ) d ( n) d ( n 1) 4 odigo _ orien( n I ) Equação 13 - Determinação de Id de um nó da quadtree. C Sempre que um nó é gerado este, é adicionado ao espaço de procura na posição correspondente ao seu Id. Através da função da Equação 12 e da Tabela 16 podemos verificar que o id do filho correspondente ao quadrante SO é sempre igual ao Id do pai. Desta forma, a referência do nó-pai no espaço de procura é substituída pela referência do Id do nó filho, obtendo-se desta forma a representação de uma quadtree linear. Vizinhos A determinação dos nós vizinhos para cada nó na quadtree é um processo semelhante ao processo de determinação de vizinhos, descrito para o esquema de divisão baseado em grelha, contudo existe algumas diferenças. O sistema parte do princípio que todos os nós-folhas se encontram na profundidade máxima. Desta forma, é necessário determinar o número de linhas e o número de colunas que o nó ocupa. Com base nessa informação, o sistema vai percorrer a linha e coluna anterior e posterior com o objetivo de determinar os nós vizinhos. Para cada nó correspondente a uma determinada linha e coluna, o sistema verifica se o nó existe, uma vez que o nó pode não estar dividido até à sua profundidade máxima. No caso de este não existir, então o sistema vai determinar o nó-pai desse nó vizinho, e assim sucessivamente, até encontrar o nó que ocupa essa posição. O nó determinado é então adicionado ao array de vizinhos e adicionada uma entrada ao array que contêm o custo da conexão a cada um dos vizinhos. Tal como acontece na implementação da grelha, o número de vizinhos pode diferir de nós para nós e o custo de navegação variar de acordo com a orientação do vizinho ao nó, sendo o custo de navegação na diagonal superior ao custo de deslocação vertical ou horizontal. Quantização/Localização A determinação de um nó que contém uma determinada localização é feita pela determinação do número de Morton através das coordenadas indicadas. Depois do número Morton ser determinado, é verificado se o nó existe, caso não exista o sistema vai determinar o nó-pai desse nó e assim sucessivamente até encontrar o nó que contêm essa localização. 78

104 Tal como a implementação da grelha, a representação do nó numa posição do ambiente de jogo é igual ao ponto médio desse nó. A determinação da localização de um determinado nó, pode ser feita através do atributo do nó center. Algoritmos de procura em grafos Á semelhança da camada de representação do ambiente, a implementação da camada de algoritmos de procura em grafo divide-se em duas componentes: gestor e algoritmos de procura em grafo. Gestor O gestor tem como objetivo principal inicializar e gerir uma ou mais instâncias do algoritmo de procura em grafos. O gestor recebe pedidos de resolução de caminho da camada de locomoção e reencaminha-os. O gestor possui os seguintes atributos: Propriedade Descrição pathfinderthreadpool Referência a um Thread pool que contem threads que executam instâncias do algoritmo de procura em grafos. npathfinders Número de instâncias de algoritmos de procura existentes na thread pool. nrequests Número atual de pedidos a ser tratados. Tabela 17 - Lista de atributos do gestor da camada de algoritmos de procura em grafos. O atributo pathfinderthreadpool referencia uma thread pool. A thread pool apresenta como principais características ser configurável e extensível a outras implementações. É possível configurar o número mínimo e máximo de thread s suportados pela thread pool. A thread pool quando é inicializada, inicializa o número mínimo de thread s definido, este número pode aumentar até ao número máximo definido, a thread pool determina a necessidade de aumentar o número de threads, caso existam pedidos em espera. É possível ainda configurar o modo como o número de threads é aplicado entre: global e por processador. No modo global, o número de threads é atribuído ao sistema como um todo enquanto no modo por processador cada processador do sistema possui um número mínimo e máximo de threads. 79

105 A thread pool possui uma lista genérica de elementos genéricos, sendo a lista extensível a diversas tipos de estrutura de dados e a diversos tipos de elemento. Na implementação atual do sistema de navegação esta lista corresponde a uma fila de tarefas com prioridades, em que cada tarefa corresponde a um pedido de resolução de caminho e está associado a uma prioridade. Esta estrutura de dados irá ordenar os seus elementos pela ordem de chegada e pelo valor da prioridade. Embora atualmente o sistema não suporte inteiramente NPC s de diferentes tipos, esta funcionalidade foi desenvolvida para suportar essa funcionalidade. Os métodos suportados atualmente pelo gestor de algoritmos de procura em grafos são: Método Descrição Init Inicialização do gestor de algoritmos de procura em grafos. FindPath Recebe um pedido de resolução de caminho e adiciona-o à lista de tarefas a ser consumida pelas threads da thread pool. Tabela 18 - Lista de métodos do gestor da camada de algoritmos de procura em grafos. O método Init tem por objetivo inicializar o gestor de algoritmos de procura de grafos. Esta inicialização inclui a inicialização da thread pool. O método FindPath é o método chamado quando a camada de locomoção pretende determinar um caminho entre dois pontos. Este método apresenta um comportamento assíncrono, uma vez que a camada de locomoção de um NPC ao chamar este método não fica bloqueado à espera de uma resposta. O gestor reencaminha o pedido para a fila de tarefas da thread pool onde irá aguardar até ser processado por uma instância do algoritmo de procura em grafo. O comportamento assíncrono entre o pedido e a resposta de resolução de caminho e a existência de várias instâncias do algoritmo de procura em grafo visam o suporte a múltiplos agentes. Tipos de algoritmos de procura em grafos Cada thread da threadpool executa uma instância do algoritmo de procura em grafos. De forma a permitir o suporte a diversos tipos de algoritmos de procura, cada implementação deve obrigatoriamente estender o algoritmo de procura em grafos genérico. O algoritmo de procura em grafos genérico apresenta como principais atributos: 80

106 Propriedade Descrição navigationgraphmanager Referência ao gestor da camada de representação do ambiente. niterations goal Número de iterações realizadas pelo pathfinder no processamento de um pedido de resolução de caminho. Nó de destino. response Estrutura de resposta a ser enviada à camada de locomoção do NPC responsável pelo pedido de resolução de caminho (ver Tabela 22). Tabela 19 - Lista de atributos do algoritmo de procura em grafos genérico. A referência ao gestor da camada de representação do ambiente tem por objetivo disponibilizar o espaço de procura utilizado pelo algoritmo de procura e por outro lado responder a pedidos de localização/quantização de pontos/nós. O algoritmo de procura em grafos genérico disponibiliza ainda um conjunto de métodos que as diversas implementações devem implementar ou usar: Método Init FindPath DoIteration Descrição Inicializa a instância do algoritmo de procura em grafo. Preparação a instância do algoritmo de procura em grafo para uma nova procura de caminho entre dois pontos. Proceder uma iteração do algoritmo de procura em grafos. GetResponse Retorna a resposta à camada de locomoção do NPC responsável pelo pedido de resolução de caminho. Tabela 20 - Lista de métodos do algoritmo de procura em grafos genérico. O método DoIteration procede a uma iteração do algoritmo de procura, desta forma, cada implementação do algoritmo de procura deve estar preparado para ser executado por iteração, invés de calcular o caminho de uma vez só. Este método é chamado repetidamente pela thread até o resultado da iteração ser diferente de não acabado (NOTFINISHED). Esta implementação tem por objetivo suportar o processamento intercalado de pedidos de resolução de caminho, procurando suportar a aplicação de técnicas como o timeslice. Contudo, esta funcionalidade ainda não se encontra inteiramente suportada pelo sistema. 81

107 O método FindPath recebe um pedido de procura de caminho e prepara o algoritmo para uma nova procura de caminho. O pedido consiste numa estrutura composta por: Propriedade Descrição id priority start goal Identificador do pedido. Prioridade do pedido. Ponto 3D que representa a localização do ponto inicial do caminho. Ponto 3D que representa a localização do ponto final do caminho. onpathfinderresponse Referencia ao delegate que contem a referência para um método da camada locomoção do NPC responsável pelo pedido de procura de caminho. Tabela 21 - Lista de atributos da estrutura de pedido de resolução de caminho. Quando o algoritmo de procura termina o processamento de um pedido, o sistema utiliza o atributo onpathfinderresponse para fazer o callback ao NPC responsável pelo pedido. O callback é feito através da chamada ao método descrito na Tabela 13 passando como atributo a estrutura de resposta ao pedido. A estrutura de resposta composta pelos seguintes atributos: Propriedade Descrição id path Identificador da resposta. Array de pontos 3D que representa a solução de caminho entre os dois pontos indicados pela estrutura de pedido de resolução de caminho. searchresult Resultado da procura de caminho Tabela 22 - Lista de atributos da estrutura de resposta de resolução de caminho. O resultado da procura de caminho pode variar entre 2 valores: encontrado (FOUND) e não encontrado (NOTFOUND). Quer a estrutura de pedido, quer a estrutura de resposta podem ser estendidos com objetivo de aumentar o número de funcionalidades ou possibilitar diferentes tipos de implementações. 82

108 Atualmente o sistema de navegação suporta dois tipos de algoritmos de procura em grafo: A* e o Fringe Search. Para cada um destes algoritmos descrevemos as suas principais características e o pseudo-codigo relativos aos dois métodos principais da sua implementação: FindPath e DoIteration. A* A implementação do algoritmo de procura em grafo A* recorre a três estruturas de dados distintas: o conjunto de nós abertos (open) é armazenado numa fila de prioridades. Esta estrutura é responsável por dispor os seus elementos segundo a sua prioridade. Desta forma, o caminho com o menor custo possui a maior prioridade, e é o primeiro da fila a ser selecionado; para armazenar o conjunto de nós fechados (closed) foi usado uma HashSet. Esta estrutura de dados consiste numa coleção de elementos únicos não ordenados, que recorre a uma implementação hash para a identificação dos seus elementos. Esta estrutura foi selecionada uma vez que disponibiliza um conjunto de operações de complexidade O(1). Dentro das operações disponibilizadas, interessa-nos a operação de pertença, a Hashset permitir determinar de forma fácil e rápida se um determinado elemento faz parte do conjunto; a terceira e última estrutura, destina-se a armazenar caminhos (path) entre dois nós. A implementação desta estrutura tem como características ser imutável, uma vez que depois de ser adicionado um elemento a esta estrutura, este não pode ser modificado. Esta característica confere ainda à estrutura a característica de ser threadsafe. Esta estrutura tem como tributos uma lista de nós anteriores (previoussteps), o custo total do caminho, e o ultimo nó adicionado (lasstep). A fila de nós abertos irá guardar diversas instâncias desta estrutura. Método FindPath: # Descrição 1. O sistema valoriza as variáveis: Destino Origem closed {} open open.enqueue(0, new path 83

109 (navgraphmanager.getnode(request.start))) path {} Tabela 23 - Pseudo-código do método FindPath para o algoritmo de procura em grafos A* Método DoIteration: # Descrição 1. O sistema obtém o caminho com o custo mais baixo: path = open.dequeue(); 2. Se o conjunto de nós fechados contém o nó do último passo (if closed contains path.laststep): O método devolve NOTFINISHED. 3. Se o nó no último passo, for igual ao nó de destino (if path.laststep == destination): O método devolve FINISHED. 4 O sistema adiciona o último passo ao conjunto de nós fechados: closed.add(path.laststep) 5. O sistema percorre todos os nós vizinhos do último passo (foreach n in path.laststep.neighbours): 5.1 Se n for possível de caminhar: newpath = path.addstep(n, g(n)) q.enqueue(newpath.totalcost(g(n)) + h(n), newpath) 6 Se não existir mais nó na lista aberta (open.count = 0): O método devolve NOTFOUND. Tabela 24 - Pseudo-código do método DoIteration para o algoritmo de procura em grafos A* O custo do movimento de n (g(n)) é determinado pela soma do custo do caminho do nó path.laststep, o custo de caminhar em n e o custo do caminho entre o nó path.laststep e o nó n. O custo estimado do nó n ao nó destino (h(n)), é calculado através do método Manhattan. Este método destaca-se pela sua rapidez, contudo, não garante o caminho mais curto possível, apresentando apenas uma grande probabilidade disso. 84

110 h Equação 14 Obtenção de h(n). abs( CurrentX T arg etx abs CurrentY T arg etx 10 ( n) ( Fringe Search A implementação do algoritmo de procura em grafo Fringe Search recorre a duas estruturas de dados distintas: a estrutura Fringe que funciona como uma lista duplamente ligada, onde é guarda a informação do nó atual (currentnode) e o nó à cabeça (headnode); Cache array de elementos, em que cada elemento é composto pelo valor g e o nó pai. Método FindPath: # Descrição 1. O sistema inicializa as variáveis auxiliares: Variável Cache C[] Fringe ringe Inicialização new Cache[navGraphManager.searchSpace.Length] Limpa a lista agora e depois : 2. O sistema valoriza as variáveis auxiliares: new Fringe[navGraphManager.searchSpace.Length] Destino C Fringe Origem C.AddCache(navGraphManager.GetNode(request.Start).Id, 0, NULL) Adiciona o nó raiz à lista now: Fringe.insertNode(navGraphManager.GetNode(request.Start)) flimit Valoriza o limiar com o valor do h do nó inicial h(request.start) fmin MaxPossibleValue Tabela 25 - Pseudo-código do método FindPath para o algoritmo de procura em grafos Fringe Search* 85

111 Método DoIteration: # Descrição 1. O sistema valoriza as variáveis: Destino Node Origem Fringe.CurrentNode 2. Se node == null: Se Fringe.Head == Null O método devolve NOTFOUND. Caso contrário: flimit = fmin; O método devolve NOTFINISHED. Caso contrário verifica se o nó goal foi encontrado (node == goal): O método devolve FOUND. 3. O sistema obtém o elemento da cache: Destino cacheelement Origem GetFromCache(node) 4. O sistema determina o valor de f: fvalue = g(cacheelement) + h(nodeid, goal); 5. Se fvalue > flimit: Se fvalue < fmin fmin = fvalue; O sistema obtém o próximo elemento da lista Fringe (Fringe.Next()) flimit = fmin; O método devolve NOTFINISHED. 6. O sistema percorre todos os nós vizinhos do nodeid (foreach n in node.neighbours): 6.1 Se n for possível de caminhar: 86

112 6.2 O sistema determina o g do vizinho: g(n) = g(cacheelement) + n.cost + node.neighboursconectioncost(n); 6.3 O sistema verifica se n há existe em cache (GetFromCache(n)!= null): Se g(n) >= g(getfromcache(n) flimit = fmin; O método devolve NOTFINISHED. 6.4 O sistema adiciona o nó n ao Fringe Fringe.insertNode(n) 6.5 O sistema adiciona o nó n à cache: C.AddCache(n, g(n), node) 7 O sistema atualiza a estrutura Fringe: Remove o elemento corrente (fringe.removecurrentnode()) Atualiza o próximo nó (fringe.nextnode()) 8 flimit = fmin; Tabela 26 - Pseudo-código do método DoIteration para o algoritmo de procura em grafos Fringe Search* Ferramenta de prova de conceito A aplicação de prova de conceito surgiu da necessidade de se ter um modelo prático, que pudesse provar o conceito e a arquitetura estabelecida. Desta forma, foi implementado um projeto em Unity 3D, que através de técnicas de geração processual de conteúdo geram um ambiente de jogo de vídeo, em que os diversos agentes recorrem ao sistema de navegação desenvolvido. O desenvolvimento deste protótipo funcional permitiu, como ferramenta, provar a viabilidade da solução, dos conceitos e as tecnologias envolvidas na elaboração do projeto. A ferramenta desenvolvida suporta a construção automática e a dinâmica de cenários inteiros, em troca da definição de alguns parâmetros. Com vista a este fim e para simplificar a sua implementação, toda a arquitetura da ferramenta assenta na técnica de programação de inversão de controlo. Foi usada uma biblioteca third-party desenvolvida por Sebastiano Mandalà especificamente para o Unity 3D, uma vez que as demais ferramentas para este fim são incompatíveis. Esta técnica possibilita um baixo nível de acoplamento entre os diferentes módulos do sistema. As dependências entre os módulos não são definidas programaticamente, mas sim através da configuração de um container, o qual é responsável por injetar em cada componente as suas dependências. 87

113 Desta forma, os objetos não são criados pelo utilizador, mas sim pelo container de forma lazy (quando necessário). Este aspeto é bastante importante pois permite adiar a criação de objetos até estes serem realmente necessários, minimizando o consumo de memória. Para a criação de objetos o container recorre a fábricas (factories) que são responsáveis pela criação de um tipo de objeto específico. Esta abordagem possibilita que apenas seja necessário adicionar um objeto a cada cenário do Unity 3D, o container. Todos os outros objetos são criados através do container. O tipo de objetos suportados atualmente, são: camada de representação do ambiente; camada de algoritmos de procura em grafos; conjunto entidades (entities). A camada de representação do ambiente no inspetor corresponde ao GameObject do gerente que irá conter como dependência uma instância do grafo de navegação. À semelhança da camada de representação do ambiente, a camada de algoritmos de procura em grafos no inspetor é representada pelo gerente e irá conter como dependência uma instância por cada thread a executar o algoritmo de procura em grafos. Todas as entidades são extensões de uma entidade genérica. Cada tipo de entidade é composta por características únicas e/ou características herdadas de outras entidades e dispõe de um gestor que recorre a fábricas para gerar as suas instâncias. Recorrendo ao paradigma da programação orientada a objetos é possível criar diversos tipos de entidades inteiramente novas ou adicionar comportamentos de entidades já existentes. No inspetor cada tipo de entidade é representada pelo gestor que contêm as suas instâncias. A ferramenta atual suporta as seguintes tipos de entidades: camera: dispositivo que permite ao jogador ver o ambiente de jogo; terrain: Terreno que suportar os diversos objetos do ambiente de jogo. Em cada cenário só existe um e este é gerado inteiramente através de técnicas de geração processual; navpoint: esfera que assina-la uma localização chave no ambiente de jogo; mob: NPC com a capacidade de se movimentar pelo ambiente de jogo. O Mob é composto pela camada de locomoção e um conjunto de NavPoint s; obstacle: volume quadrado que represente um obstáculo que é evitado pelo NPC. 88

114 No início de cada execução o container cria os objetos e as diversas entidades com base em configurações e na informação especificada em ficheiros XML ou informação gerada em tempo de execução pelos geradores. Em cada execução é criado inteiramente um ambiente de jogo de raiz. Ilustração 31 - Simulação de 600 NPC s com esquema de divisão baseado em Grelha e algoritmo de procura A*. Ilustração 32 - Simulação de 2 NPC s com o esquema de divisão baseado em quadtree e algoritmo de procura Fringe Search Ferramenta de avaliação A ferramenta de avaliação foi desenvolvida com o objetivo de avaliar de forma fiável o desempenho e consumo de memória do sistema de navegação desenvolvido. Como requisito desta ferramenta, deve possibilitar a execução de testes automáticos (sem intervenção do ser humano) recebendo como argumento de entrada um ficheiro de configuração e retornando como output o resultado dos testes efetuados. Apesar da ferramenta de prova de conceito permitir observar o consumo de memória e o tempo de resposta do sistema, não se trata de uma avaliação fiável. Por outro lado, a componente gráfica que lhe está associada é desnecessária para a recolha de dados, estando esta associada a um grande consumo de recursos o que influência os resultados obtidos e dificulta a rapidez e replicação dos testes. Tal como acontece na ferramenta de prova de conceito, a execução da ferramenta de avaliação baseia-se em ficheiros de configuração no formato XML. O ficheiro de entrada contêm diversas entradas, cada entrada representa uma situação de 89

115 teste. Uma entrada é composta por diversos parâmetros que correspondem a um ficheiro XML. Parâmetros Descrição Valores possíveis Id Identificação da simulação. - Esquema de divisão Algoritmo de procura em grafos Dimensão do terreno Procedimentos Esquema de divisão a ser aplicado ao ambiente de jogo. Algoritmo de procura em grafos usado para a resolução de caminhos Tamanho do terreno onde será aplicado o esquema de divisão. Lista de procedimentos a aplicar ao ambiente de jogo especificado nos parâmetros anteriores. Baseado em grelha ou em quadtree A* ou Fringe Search Pequena, média ou grande - Número de Número de vezes que os procedimentos serão repetições repetidos Tabela 27 - Parâmetros que compõe uma entrada do ficheiro XML. - A divisão de cada simulação em parâmetros promove a modularização e a reutilização dos ficheiros XML. Os ficheiros de procedimentos são constituídos por diversas entradas, cada entrada corresponde a uma operação que é executada de forma linear sendo registado o tempo de processamento e memória utilizada na sua execução. Atualmente as operações suportadas são: Operação Descrição InitNavigationGraph Inicialização do grafo de navegação. Inicialização do algoritmo de procura. AddObstacleAtLoad Adição de vários obstáculos durante a inicialização do grafo de navegação e no final atualização do grafo de navegação. AddObstacle PrintSearchSpace ToNode ToPoint Adição de um obstáculo e atualização do grafo de navegação. Obtém a dimensão do espaço de procura. Quantização, ocorre a conversão de uma localização do ambiente de jogo num nó do grafo de navegação. Localização, ocorre a conversão de um nó em uma localização do ambiente 90

116 de jogo. ConnectNeighbours FindePath Procede à conexão de vizinhos. Determina o caminho entre dois pontos. FinishTest Finaliza o teste. Tabela 28 - Operações suportadas pela ferramenta de avaliação. Cada ficheiro de procedimento deve possuir no mínimo três procedimentos: InitNavigationGraph, InitNavigationGraph e FinishTest. Para cada procedimento de uma simulação executado é criado um ficheiro de output com o Id da simulação e o processamento. Comparando a implementação da ferramenta de prova de conceito e a ferramenta de avaliação existem três grandes diferenças: não é usada a técnica de programação de inversão de controlo uma vez que a biblioteca usada na ferramenta de prova de conceito é específica para o Unity 3D e o ambiente de execução da ferramenta de avaliação é inteiramente em C#; os objetos e entidades assim como a sua descrição em XML diferem entre ferramentas. Esta opção tem por objetivo poupar memória uma vez que na ferramenta de avaliação não é necessário tantos atributos para descrever os objetos e entidades; a criação dos objetos não recorre a fábricas. Embora estas diferenças tenham obrigado a uma nova implementação da camada business do jogo de vídeo, devido à arquitetura do sistema de navegação ser centrada em objetos tratou-se de uma tarefa relativamente simples. A nível de funcionamento destacam-se duas diferenças entre as duas ferramentas: na ferramenta de avaliação não existe uma camada locomoção, os pedidos realizados à camada de procura em grafos são feitos de forma linear à medida que os procedimentos vão sendo executados existem dois modos de execução. O primeiro modo de execução consiste no uso de apenas uma instância do algoritmo de procura em grafos, existindo apenas a thread principal da ferramenta. O gestor não recorre à threadpool para lançar novas instâncias, sendo as chamadas ao método responsável pela procura de caminho síncronas, lineares e bloqueantes. O segundo modo de execução é semelhante à ferramenta de prova de conceito, em que o gestor recorre à threadpool para 91

117 armazenar e consumir pedidos através de uma ou mais threads. A existência de dois modos de execução tem por objetivo permitir avaliar melhor a arquitetura desenvolvida. A avaliação do tempo de processamento de cada operação é feita através do biblioteca do C# System.Diagnostics que disponibiliza um conjunto de métodos (nomeadamente o Stopwatch) que permitem medir de forma precisa o tempo decorrido. Desta forma, é obtido o tempo antes da chamada à função e depois da chamada à função, sendo o último tempo subtraído pelo primeiro tempo. Para a avaliação da memória usada na execução do método, é obtida a memória total do sistema antes da chamada à função e depois da chamada à função. Sendo a quantidade de memória avaliada depois da chamada à função subtraída à quantidade de memória avaliada antes da chamada à função. Antes da obtenção da memória total do sistema é chamado o método Thread.MemoryBarrier uma vez que a máquina usada em testes dispõe de um sistema multiprocessador e a chamada a este método sincroniza o acesso à memória, fazendo com que o processador não faça reordenamento de instruções. 4.4 Sumário Neste capítulo é descrito o trabalho técnico realizado para alcançar os objetivos propostos. Na primeira secção é feita a análise do problema com vista aos objetivos traçados no capítulo 1.2 e à pesquisa bibliogafia feita no Capítulo 2. Depois da conceptualização dos problemas que este estudo procura resolver, na secção seguinte é descrito o desenho da solução com base nos requisitos e problemas identificados anteriormente. A secção final tem por objetivo especificar a implementação do desenho da solução, nesta secção é detalhado a implementação do sistema de navegação e das duas ferramentas criadas para a explorar. 92

118 Capítulo 5 Resultados Neste capítulo são indicados os resultados da avaliação da arquitetura descrita no capítulo através da ferramenta de avaliação descrita no capítulo segundo os métodos abordados no Capítulo 3. A recolha da amostra foi efetuada no seguinte ambiente: Hardware Processador Memória ram Disco rígido Especificação Intel Core 2 Duo 2.40GHz 4.00 GB RPM Sistema operativo Windows 8 Pro Tabela 29 - Especificação de ambiente de testes. Para a recolha de dados no modo de execução com threadpool, a ferramenta de avaliação foi configurada com o número máximo de 10 threads a serem para aplicadas no modo global. No geral, a recolha da amostra consistiu na avaliação do tempo de processamento e memória alocada de conjunto de operações efetuadas sobre a arquitetura descrita. 93

119 5.1 Apresentação de resultados Inicialização da camada de representação do ambiente Modo de execução sem threadpool Pouco Povoado Ambiente pequeno Ambiente médio Ambiente grande (ms) Grelha Quadtree Grelha Quadtree Grelha Quadtree A* 0,0823 0,0285 6,8530 0, ,7661 0,1265 Fringe Search 0,0825 0,0285 7,3136 0, ,5532 0,1293 Povoado Muito Povoado A* 0,0823 0,0290 6,9181 0, ,8104 0,2900 Fringe Search 0,0833 0,0283 7,0222 0, ,6607 0,2929 A* 0,0825 0,0289 7,1381 0, ,1450 0,2886 Fringe Search 0,0827 0,0295 7,2173 0, ,6877 0,2857 Tabela 30 - Resultados do tempo de processamento na inicialização da camada de representação do ambiente. (ms) Ambiente Pequeno Ambiente médio Ambiente grande Grelha 0,0826 7, ,7705 Quadtree 0,0288 0,0399 0,2355 Tabela 31 - Média do tempo de processamento na inicialização da camada de representação do ambiente: Esquema de divisão Vs. Dimensão do ambiente. Os resultados mostram que: o esquema de divisão baseado em grelha despende mais tempo de processamento na inicialização da camada de representação do ambiente, quando comparado com o esquema de divisão baseado em quadtree; existe uma relação direta entre o tempo de processamento e a dimensão do ambiente de jogo. Esta relação é mais expressiva no esquema de divisão baseado em grelha (ver Ilustração 33). 94

120 Ilustração 33 - Média do tempo de processamento na inicialização da camada de representação do ambiente: Esquema de divisão Vs. Dimensão do ambiente. Pouco Povoado Ambiente pequeno Ambiente médio Ambiente grande (B) Grelha Quadtree Grelha Grelha Quadtree Grelha A* 12976,5 1007, , , ,4 Fringe Search 12972,8 1008, , ,2 Povoado A* 12989,5 960, , ,9 Fringe Search 12980,3 988, , ,6 Muito A* 12984,4 959, , , ,3 Povoado Fringe Search 12982,5 959, , , ,3 Tabela 32 - Resultados do consumo de memória na inicialização da camada de representação do ambiente. (B) Ambiente Pequeno Ambiente médio Ambiente grande Grelha , Quadtree 980, , ,6 Tabela 33 - Média do consumo de memória na inicialização da camada de representação do ambiente: Esquema de divisão Vs. Dimensão do ambiente. Os resultados da alocação de memória na inicialização da camada de representação do ambiente mostram que: o esquema de divisão baseado em grelha apresenta um consumo superior de memória quando comparado com a representação baseada em quadtree; 95

121 existe uma relação direta entre a memória consumida e a dimensão do ambiente de jogo. Esta relação é mais expressiva para o esquema de divisão baseado em grelha (ver Ilustração 34). Ilustração 34 - Gráfico do consumo de memória na inicialização da camada de representação do ambiente: Esquema de divisão Vs. Dimensão do ambiente. Modo de execução com threadpool Tipo de recurso Ambiente pequeno Ambiente médio Ambiente grande Grelha Tempo Proc. (ms) 0, , ,5552 Memória (B) 13319, , ,2 Quadtree Tempo Proc. (ms) 0,0350 0,0455 0,1230 Memória (B) 948, , ,3 Tabela 34 - Resumo dos resultados da inicialização da camada de representação do ambiente no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente. Os dados de execução com threadpool reafirmam as observações dos dados execução sem threadpool. Quanto à comparação os dois tipos de execução observa-se que: a execução com threadpool no geral é ligeiramente mais demorada com a exceção da esquema de divisão do ambiente de jogo baseada na quadtree para o ambiente de jogo de maior dimensão; a execução com threadpool apresenta um maior consumo de memória. 96

122 Não são apresentados dados referentes ao algoritmo de procura em grafos uma vez que esta camada não se encontra inicializada na altura em que esta operação é executada Inicialização da camada de procura de caminhos Modo de execução sem threadpool Pouco Povoado Ambiente pequeno Ambiente médio Ambiente grande (ms) Grelha Quadtree Grelha Quadtree Grelha Quadtree A* 0,0032 0,0045 0,0059 0,0045 0,0078 0,0053 Fringe Search 0,0023 0,0029 0,0037 0,0030 0,0053 0,0044 Povoado A* 0,0032 0,0041 0,0062 0,0047 0,0091 0,0054 Fringe Search 0,0023 0,0028 0,0039 0,0034 0,0053 0,0037 Muito A* 0,0032 0,0039 0,0056 0,0046 0,0091 0,0060 Povoado Fringe Search 0,0023 0,0032 0,0037 0,0031 0,0052 0,0038 Tabela 35 - Resultados do tempo de processamento na inicialização da camada de procura de caminhos. (ms) Ambiente pequeno Ambiente médio Ambiente grande A* 0,0037 0,0052 0,0071 Fringe Search 0,0026 0,0034 0,0046 Tabela 36 - Média do tempo de processamento na inicialização camada de procura de caminhos: Algoritmo de procura em grafos Vs. Dimensão do ambiente. Através da análise dos resultados do tempo de processamento despendido na inicialização da camada de procura de caminhos verificamos que. o algoritmo A* consome mais tempo de processamento quando comparado com o algoritmo Fringe Search. existe uma relação direta entre o tempo de processamento e a dimensão do ambiente de jogo. Esta relação é mais expressiva quando estamos a lidar com o algoritmo A* (ver Ilustração 35). 97

123 Ilustração 35 - Gráfico do tempo de processamento na inicialização da camada do algoritmo de procura em grafos: Algoritmo de procura em grafos Vs. Dimensão do ambiente. Pouco Povoado Ambiente pequeno Ambiente médio Ambiente grande (B) Grelha Quadtree Grelha Quadtree Grelha Quadtree A* 216,0 240,0 216,0 240,0 216,0 240,0 Fringe Search 160,0 184,0 160,0 184,0 160,0 184,0 Povoado A* 216,0 240,0 216,0 240,0 216,0 240,0 Fringe Search 160,0 184,0 160,0 184,0 160,0 184,0 Muito A* 216,0 240,0 216,0 240,0 216,0 240,0 Povoado Fringe Search 160,0 184,0 160,0 184,0 160,0 184,0 Tabela 37 - Resultados do consumo de memória na inicialização da camada de procura de caminhos. (B) Grelha Quadtree A* Fringe Search Tabela 38 - Média os resultados do consumo de memória na inicialização da camada de procura de caminhos. A análise dos dados do consumo de memória na inicialização da camada de procura de caminhos mostra que: o algoritmo de procura A* necessita de alocar mais memória do que o algoritmo Fringe Search. Existe uma relação entre o tipo de esquema de divisão do ambiente e o algoritmo de procura, com o esquema de divisão do ambiente a necessitar de menos memória que a quadtree. 98

124 Não são mostrados resultados relativamente à diferenciação da dimensão do ambiente uma vez que não foram registadas quais quer diferenças. Modo de execução com threadpool Ambiente pequeno Ambiente médio Ambiente grande (ms) Grelha Quadtree Grelha Quadtree Grelha Quadtree Pouco Povoado A* 0,0092 0,0082 0,0099 0,0093 0,0150 0,0107 Fringe Search 0,0080 0,0077 0,0098 0,0098 0,0160 0,0108 Povoado Muito Povoado A* 0,0091 0,0084 0,0111 0,0095 0,0150 0,0113 Fringe Search 0,0090 0,0081 0,0099 0,0107 0,0144 0,0108 A* 0,0097 0,0083 0,0100 0,0095 0,0150 0,0113 Fringe Search 0,0094 0,0081 0,0098 0,0094 0,0145 0,0111 Tabela 39 - Resultados do tempo de processamento na inicialização da camada de procura de caminhos no modo de execução com threadpool. (ms) Ambiente pequeno Ambiente médio Ambiente grande A* 0,0088 0,0099 0,0130 Fringe Search 0,0079 0,0099 0,0129 Tabela 40- Média do tempo de processamento na inicialização da camada de procura de caminhos no modo de execução com threadpool: Algoritmo de procura vs. dimensão do ambiente de jogo. Os resultados do tempo de processamento na inicialização da camada de procura de caminhos são semelhantes ao modo de execução sem threadpool (ver Ilustração 36). Contudo no modo de execução com threadpool observa-se uma diferença de valores menor entre os dois algoritmos. Quando comparado os dois modos de execução verificamos que o modo de execução com threadpool demora mais tempo na inicialização da camada de algoritmo de procura. 99

125 Ilustração 36 - Gráfico do tempo de processamento na inicialização da camada do algoritmo de procura em grafos no modo de execução com threadpool: Algoritmo de procura em grafos Vs. Dimensão do ambiente. Ambiente pequeno Ambiente médio Ambiente grande (B) Grelha Quadtree Grelha Quadtree Grelha Quadtree Pouco Povoado Povoado A* 325,1 407,9 331,1 408,0 425,3 408,0 Fringe Search 395,9 408,0 351,5 408,0 418,6 408,0 A* 325,1 408,0 336,1 408,0 325,1 408,0 Fringe Search 411,8 401,9 330,8 408,0 429,5 408,0 A* 425,1 407,4 335,1 408,0 325,1 408,0 Muito Povoado Fringe Search 398,4 408,0 430,1 408,0 425,1 408,3 Tabela 41 - Resultados do consumo de memória na inicialização da camada de procura de caminhos no modo de execução com threadpool. (B) Grelha Quadtree A* 350,3 407,9 Fringe Search 399,1 407,4 Tabela 42 Média dos resultados do consumo de memória na inicialização da camada de procura de caminhos no modo de execução com threadpool. No que diz respeito à memória consumida na inicialização da camada do algoritmo de procura, à semelhança dos resultados da execução sem threadpool verificou-se a mesma relação entre o tipo de esquema de divisão do ambiente e o 100

126 algoritmo de procura. Contudo, não foi verificado que o algoritmo A* necessite de mais memória em comparação com o algoritmo Fringe Search. Quando comparamos os dois modos de execução verificamos que o modo de execução com threadpool no geral está associado a um maior consumo de memória Adição de objetos antes do início do jogo Modo de execução sem threadpool Ambiente pequeno Ambiente médio Ambiente grande (ms) Grelha Quadtree Grelha Quadtree Grelha Quadtree Pouco Povoado A* 0,0802 1,8767 6, , , ,0915 Fringe Search 0,0817 1,8771 7, , , ,0418 Povoado Muito Povoado A* 0,0850 1,9777 7, , , ,5759 Fringe Search 0,0831 1,9914 7, , , ,3264 A* 0,1129 2,1517 7, , , ,2295 Fringe Search 0,0872 2,1477 8, , , ,6864 Tabela 43 - Resultados do tempo de processamento na adição de objetos antes do início do jogo. (ms) Ambiente pequeno Ambiente médio Ambiente grande Grelha 0,0883 7, ,1138 Quadtree 2, , ,4919 Tabela 44 - Média do consumo do tempo de processamento na adição de objetos antes do início do jogo: Esquema de divisão Vs. Dimensão do ambiente. (ms) Pouco povoado Povoado Muito povoado Grelha 52, , ,6743 Quadtree 895, , ,3903 Tabela 45 - Média do tempo de processamento na adição de objetos antes do início do jogo: Esquema de divisão Vs. Densidade de objetos. A análise do tempo de processamento despendido na adição de objetos antes do início do jogo mostra que: 101

127 o esquema de divisão do ambiente de jogo baseado em quadtree necessita de mais tempo para completar a tarefa de adição de objetos. existe uma relação direta entre o tempo de processamento e a dimensão do ambiente de jogo. Esta relação é mais expressiva para o esquema de divisão baseado em quadtree (ver Ilustração 37). Ilustração 37 Gráfico da média do consumo do tempo de processamento na adição de objetos antes da execução do jogo: Esquema de divisão Vs. Dimensão do ambiente. Modo de execução com threadpool Ambiente pequeno Ambiente médio Ambiente grande (ms) Grelha Quadtree Grelha Quadtree Grelha Quadtree Pouco Povoado A* 0,0935 1, , , , ,6945 Fringe Search 0,0907 1,8932 9, , , ,2258 Povoado Muito Povoado A* 0,0962 2, , , , ,3458 Fringe Search 0,0956 2, , , , ,5282 A* 0,0995 2, , , , ,7437 Fringe Search 0,0992 2, , , , ,1754 Tabela 46 - Resultados do tempo de processamento na adição de objetos antes do início do jogo no modo de execução com threadpool. 102

128 (ms) Ambiente pequeno Ambiente médio Ambiente grande Grelha 0,0883 7, ,1138 Quadtree 2, , ,4919 Tabela 47 - Média do tempo de processamento na adição de objetos antes do início do jogo no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente. (ms) Pouco povoado Povoado Muito povoado Grelha 52, , ,6743 Quadtree 895, , ,3903 Tabela 48- Média do tempo de processamento na adição de objetos antes do início do jogo no modo de execução com threadpool: Esquema de divisão Vs. Densidade de objetos. A execução com threadpool confirma as observações efetuadas com base nos resultados da execução sem threadpool (ver Ilustração 38). Contudo, verifica-se também tempos bastante superiores especialmente à medida que o ambiente de jogo aumenta de dimensão. Ilustração 38 - Gráfico da média do consumo do tempo de processamento na adição de objetos antes da execução do jogo no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente. 103

129 5.1.4 Tamanho do espaço de pesquisa A Tabela 49 mostra o máximo de nós possíveis que cada esquema de divisão pode gerar e o número de objetos a adicionados em cada tipo de ambiente por densidade de objetos (para mais informação consultar capítulo ). (Nº nós) Máximo de nós Pouco povoado (25%) Povoado (30%) Muito povoado (35%) Ambiente pequeno Ambiente Médio Ambiente grande Tabela 49 - Número máximo de nós por dimensão de ambiente e por densidade de objetos Ambiente pequeno Ambiente médio Ambiente grande (Nº nós) Grelha Quadtree Grelha Quadtree Grelha Quadtree Pouco Povoado Povoado Muito Povoado Tabela 50 - Resultados do tamanho do espaço de pesquisa. (Nº nós) Ambiente pequeno Ambiente médio Ambiente grande Grelha Quadtree Tabela 51 Média dos resultados do tamanho do espaço de pesquisa: Esquema de divisão Vs. Dimensão do ambiente. No que diz respeito ao espaço de pesquisa podemos verificar que: o esquema de divisão baseado em grelha gera um número de nós superior ao número de nós da representação do ambiente baseada em quadtree. O número de nós da grelha corresponde a todas as células que a compõem. Como de esperar existe uma relação entre o número de nós e a dimensão do ambiente de jogo (ver Ilustração 39). 104

130 Ilustração 39 - Gráfico da média do tamanho do espaço de procura: Esquema de divisão Vs. Dimensão do ambiente Quantização Modo de execução sem threadpool Pouco Povoado Ambiente pequeno Ambiente médio Ambiente grande (ms) Grelha Quadtree Grelha Quadtree Grelha Quadtree A* 0,0020 0,0087 0,0028 0,0110 0,0050 0,0054 Fringe Search 0,0020 0,0093 0,0027 0,0104 0,0052 0,0073 Povoado Muito Povoado A* 0,0022 0,0085 0,0031 0,0038 0,0066 0,0057 Fringe Search 0,0019 0,0083 0,0028 0,0041 0,0050 0,0059 A* 0,0019 0,0021 0,0024 0,0043 0,0064 0,0071 Fringe Search 0,0020 0,0026 0,0023 0,0035 0,0052 0,0056 Tabela 52 - Resultados do tempo de processamento na quantização. (ms) Ambiente pequeno Ambiente médio Ambiente grande Grelha 0,0020 0,0027 0,0056 Quadtree 0,0066 0,0062 0,0062 Tabela 53 Média dos resultados do tempo de processamento na quantização: Esquema de divisão Vs. Dimensão do ambiente. 105

131 (ms) Pouco povoado Povoado Muito povoado Grelha 52, , ,6743 Quadtree 895, , ,3903 Tabela 54 - Média dos resultados do tempo de processamento na quantização: Esquema de divisão Vs. Densidade de objetos. Os resultados recolhidos mostram que: o esquema de divisão baseado em quadtree despende mais tempo na realização da operação de quantização do que a grelha; verifica-se uma relação direta, entre o esquema de divisão baseado em grelha e a dimensão do ambiente. No esquema de divisão baseado em quadtree, esta relação é inversa, com o tempo de processamento a diminuir com o aumento da dimensão do ambiente de jogo (ver Ilustração 40). a comparação do esquema de divisão baseado em grelha com a densidade de objetos, apresenta valores sensivelmente contantes. No esquema de divisão baseado em quadtree, observa-se uma relação inversa, com o tempo de processamento a diminuir com o aumento da densidade de objetos (ver Ilustração 41). Ilustração 40 - Gráfico da média do tempo de processamento na localização: Esquema de divisão Vs. Dimensão do ambiente. 106

132 Ilustração 41 - Gráfico da média do tempo de processamento na localização: Esquema de divisão Vs. Densidade de objetos. Modo de execução com threadpool Pouco Povoado Ambiente pequeno Ambiente médio Ambiente grande (ms) Grelha Quadtree Grelha Quadtree Grelha Quadtree A* 0,0043 0,0152 0,0049 0,0173 0,0064 0,0067 Fringe Search 0,0038 0,0143 0,0048 0,0176 0,0079 0,0066 Povoado Muito Povoado A* 0,0043 0,0147 0,0062 0,0057 0,0065 0,0070 Fringe Search 0,0043 0,0150 0,0049 0,0068 0,0064 0,0069 A* 0,0046 0,0047 0,0051 0,0057 0,0064 0,0070 Fringe Search 0,0049 0,0046 0,0050 0,0056 0,0065 0,0068 Tabela 55 - Resultados do tempo de processamento na quantização no modo de execução threadpool. (ms) Ambiente pequeno Ambiente médio Ambiente grande Grelha 0,0044 0,0052 0,0067 Quadtree 0,0114 0,0098 0,0068 Tabela 56 Média dos resultados do tempo de processamento na quantização no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente. 107

133 (ms) Pouco povoado Povoado Muito povoado Grelha 0,0054 0,0054 0,0054 Quadtree 0,0130 0,0093 0,0057 Tabela 57 - Média dos resultados do tempo de processamento na quantização no modo de execução com threadpool: Esquema de divisão Vs. Densidade de objetos. Os resultados recolhidos mostram que: o esquema de divisão baseado em quadtree demora mais tempo na realização da operação de localização do que o esquema de divisão baseado em grelha; observa-se uma relação direta entre o esquema de divisão baseado em grelha e a dimensão do ambiente. Em contraste, verifica-se uma relação inversa entre o esquema de divisão baseado em quadtree e a dimensão do ambiente (ver Ilustração 42). o esquema de divisão baseado em grelha quando comparado com a densidade de objetos apresenta valores sensivelmente contantes. No esquema de divisão baseado em quadtree observa-se uma relação inversa, com o tempo de processamento a diminuir com o aumento da densidade de objetos (ver Ilustração 43). A comparação entre os dois modos de execução mostra que o modo de execução com threadpool apresenta resultados superiores. Ilustração 42 - Gráfico da média do tempo de processamento na quantização no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente. 108

134 Ilustração 43 - Gráfico da média do tempo de processamento na quantização no modo de execução com threadpool: Esquema de divisão Vs. Densidade de objetos Localização Modo de execução sem threadpool Ambiente pequeno Ambiente médio Ambiente grande (ms) Grelha Quadtree Grelha Quadtree Grelha Quadtree Pouco Povoado A* 0,0022 0,0029 0,0037 0,0034 0,0045 0,0049 Fringe Search 0,0021 0,0027 0,0031 0,0031 0,0046 0,0064 Povoado A* 0,0025 0,0026 0,0038 0,0042 0,0062 0,0079 Fringe Search 0,0022 0,0024 0,0031 0,0044 0,0045 0,0079 Muito Povoado A* 0,0022 0,0025 0,0030 0,0044 0,0062 0,0090 Fringe Search 0,0022 0,0029 0,0030 0,0033 0,0047 0,0078 Tabela 58 - Resultados do tempo de processamento na localização. 109

135 (ms) Ambiente pequeno Ambiente médio Ambiente grande Grelha 0,0022 0,0033 0,0051 Quadtree 0,0027 0,0038 0,0073 Tabela 59 Média dos resultados do tempo de processamento na localização: Esquema de divisão Vs. Dimensão do ambiente. Os resultados obtidos do tempo de processamento na localização mostram: O esquema de divisão baseado em quadtree despende mais tempo na realização da operação de localização do que a grelha; Existe uma relação entre o esquema de divisão e a dimensão do ambiente (ver Ilustração 44). Ilustração 44 - Gráfico da média do tempo de processamento na localização: Esquema de divisão Vs. Dimensão do ambiente. Modo de execução com threadpool Ambiente pequeno Ambiente médio Ambiente grande (ms) Grelha Quadtree Grelha Quadtree Grelha Quadtree Pouco Povoado Povoado A* 0,0041 0,0042 0,0047 0,0078 0,0092 0,0081 Fringe Search 0,0035 0,0039 0,0045 0,0082 0,0107 0,0071 A* 0,0040 0,0042 0,0059 0,0081 0,0091 0,0093 Fringe Search 0,0040 0,0041 0,0046 0,0093 0,0092 0,0092 Muito A* 0,0045 0,0043 0,0047 0,0080 0,0093 0,

136 Povoado Fringe Search 0,0047 0,0042 0,0046 0,0077 0,0090 0,0080 Tabela 60 - Resultados do tempo de processamento na localização no modo de execução com threadpool. (ms) Ambiente pequeno Ambiente médio Ambiente grande Grelha 0,0041 0,0048 0,0094 Quadtree 0,0042 0,0082 0,0085 Tabela 61 - Média dos resultados do tempo de processamento na localização no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente. No modo de execução com threadpool é verificada a relação entre o esquema de divisão e a dimensão do ambiente as observações, tal como acontece no modo de execução sem threadpool (ver Ilustração 45). Quando comparados os dois tipos de execução verifica-se que o modo de execução com threadpool apresenta um tempo de execução superior. Ilustração 45 - Gráfico da média do tempo de processamento na localização no modo de execução com threadpool: Esquema de divisão Vs. Dimensão do ambiente Procura de caminho Antes da apresentação dos resultados do tempo de execução da operação de procura de caminho inerente a cada modo de execução, iremos caracterizar a procura de caminho realizada em cada situação de teste. 111

137 Ambiente pequeno Ambiente médio Ambiente grande (Nº nós) Grelha Quadtree Grelha Grelha Quadtree Grelha Pouco Povoado Povoado A* 8,0 4,0 89,0 71,0 317,0 257,0 Fringe Search 38,0 16,0 372,0 367,0 1281,0 1246,0 A* 10,0 560,0 75,0 64,0 440,0 408,0 Fringe Search 26,0 29,0 362,0 374,0 1256,0 1327,0 A* 9,0 9,0 152,0 95,0 526,0 286,0 Muito Povoado Fringe Search 20,0 20,0 365,0 406,0 1340,0 1339,0 Tabela 62 - Nº nós visitados na procura de caminho. (Nº nós) Ambiente Pequeno Ambiente médio Ambiente grande Grelha 18,5 235,8 860,0 Quadtree 106,3 229,5 810,5 Tabela 63 - Média dos resultados do nº de nos visitados na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente. (Nº nós) Ambiente Pequeno Ambiente médio Ambiente grande A* 100,0 91,0 372,3 Fringe Search 27,0 374,3 1298,2 Tabela 64 - Média dos resultados do nº de nos visitados na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente. No que diz respeito às diferentes dimensões do ambiente de jogo, a análise da Tabela 63 mostra que o esquema de divisão baseado em grelha apresenta um maior número de nós visitados (ver Ilustração 46). A análise da Tabela 64 indica que o responsável pela maioria das visitas é o algoritmo Fringe Search. Estas duas observações mostram como exceção o ambiente de dimensão pequena (ver Ilustração 47). 112

138 Ilustração 46 - Gráfico da média dos resultados do nº de nos visitados na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente. Ilustração 47 - Gráfico da média dos resultados do nº de nos visitados na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente. (Nº nós) Pouco povoado Povoado Muito povoado A* 124,3 259,5 179,5 Fringe Search 553,3 562,3 581,7 Tabela 65 - Média dos resultados do nº de nos visitados na procura de caminho: Algoritmo de procura Vs. Densidade de objetos. 113

139 No que diz respeito à densidade de objetos a análise da Tabela 65 mostra que: O algoritmo que visita mais nós é o Fringe Search. Verifica-se uma relação direta entre o nº de nós visitados pelo algoritmo de procura Fringe Search e a densidade de objetos (ver Ilustração 48). Ilustração 48 - Gráfico da média dos resultados do nº de nos visitados na procura de caminho: Algoritmo de procura Vs. Densidade de objetos. (Nº nós) Grelha Quadtree A* 180,7 194,9 Fringe Search 562,2 569,3 Tabela 66 - Média dos resultados: Esquema de divisão vs. Algoritmo de procura A Tabela 66 ignora a densidade de objetos e as diferentes dimensões do ambiente de jogo. É possível verificar que o algoritmo Fringe Search apresenta um elevado número de nós expandidos. No que diz respeito ao esquema de divisão, pode verificar-se que a representação em quadtree está associada a um maior número de nós visitados. Ambiente pequeno Ambiente médio Ambiente grande (Nº nós) Grelha Quadtree Grelha Grelha Quadtree Grelha Pouco Povoado A* Fringe Search Povoado A*

140 Fringe Search A* Muito Povoado Fringe Search Tabela 67 - Nº nós expandidos na procura de caminho. (Nº nós) Ambiente Pequeno Ambiente médio Ambiente grande Grelha 48,7 645,8 2450,5 Quadtree 668,0 594,3 2259,5 Tabela 68 - Média dos resultados do nº de nós expandidos na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente. (Nº nós) Ambiente Pequeno Ambiente médio Ambiente grande A* 682,3 606,3 2521,3 Fringe Search 34,0 633,8 2188,7 Tabela 69 - Média dos resultados do nº de nós expandidos na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente. Com base na dimensão do ambiente é possível verificar que o esquema baseado em grelha esta associado a um maior número de nós expandidos (ver Ilustração 49). No que diz respeito ao algoritmo de procura verifica-se que o algoritmo A* é responsável pela maioria dos nós expandidos (ver Ilustração 50). 115

141 Ilustração 49 Gráfico da média dos resultados do nº de nós expandidos na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente. Ilustração 50 - Média dos resultados do nº de nós expandidos na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente. Pouco Povoado Ambiente pequeno Ambiente médio Ambiente grande Quadtree Grelha Grelha Quadtree Grelha Grelha A* Custo Tamanho Fringe Search Custo Tamanho Povoado A* Custo

142 Muito Povoado Fringe Search Tamanho Custo Tamanho A* Custo Tamanho Fringe Custo Search Tamanho Tabela 70 Custo e tamanho do caminho na procura de caminho. Para referência a Tabela 70 mostra os resultados do custo e tamanho do caminho associados à procura de caminho. Modo de execução sem threadpool Pouco Povoado Ambiente pequeno Ambiente médio Ambiente grande (ms) Grelha Quadtree Grelha Quadtree Grelha Quadtree A* 0,0992 0,0468 2,7979 1, , ,0959 Fringe Search 0,0444 0,0222 0,5954 0, , ,7379 Povoado Muito Povoado A* 0,1078 0,0696 1,9745 1, , ,9534 Fringe Search 0,0344 0,0347 0,5857 0, , ,6199 A* 0,0971 0,0975 4,5987 2, , ,5364 Fringe Search 0,0271 0,0279 0,5947 0, , ,4047 Tabela 71 - Resultados do tempo de processamento na procura de caminho. (ms) Ambiente pequeno Ambiente médio Ambiente grande Grelha 0,0683 1, ,2310 Quadtree 0,0498 1, ,0580 Tabela 72 Média dos resultados do tempo de processamento na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente. (ms) Pouco povoado Povoado Muito povoado Grelha 5,5249 6,3218 7,3105 Quadtree 5,3825 7,1489 5,8708 Tabela 73 - Média dos resultados do tempo de procura de caminho: Esquema de divisão Vs. Densidade de objetos. 117

143 A análise dos dados recolhidos mostram que: o esquema de divisão baseado em grelha demora mais tempo na realização da procura de caminho do que o esquema de divisão baseado em quadtree; verifica-se uma relação direta entre o esquema de divisão baseado e a dimensão do ambiente (ver Ilustração 51); observa-se uma relação direta entre o esquema de divisão baseado na grelha e a densidade de objetos (ver Ilustração 52). Ilustração 51- Gráfico da média do tempo de processamento na procura de caminho no modo de execução: Esquema de divisão Vs. Dimensão do ambiente. 118

144 Ilustração 52 - Gráfico da média do tempo de processamento na procura de caminho: Esquema de divisão Vs. Densidade de objetos. (ms) Ambiente pequeno Ambiente médio Ambiente grande A* 0,0863 2, ,0976 Fringe Search 0,0333 0, ,1914 Tabela 74 Média dos resultados do tempo de processamento na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente. (ms) Pouco povoado Povoado Muito povoado A* 6,1694 8,5025 8,0525 Fringe Search 4,7380 4,9683 5,1289 Tabela 75 - Média dos resultados do tempo de procura de caminho: Algoritmo de procura Vs. Densidade de objetos. A análise dos dados do algoritmo de procura que: o algoritmo de procura A* demora mais tempo a resolver o caminho quando comparado com o algoritmo de procura Fringe Search. verifica-se uma relação direta entre os algoritmo de procura e a dimensão do ambiente (ver Ilustração 54); verifica-se uma relação direta entre os algoritmo de procura e a densidade de objetos (ver Ilustração 53); 119

145 Ilustração 54 Gráfico da média dos resultados do tempo de processamento na procura de caminho: Algoritmo de procura Vs. Dimensão do ambiente. Ilustração 53 Gráfico da média dos resultados do tempo de procura de caminho: Algoritmo de procura Vs. Densidade de objetos. 120

146 Modo de execução com threadpool Ambiente pequeno Ambiente médio Ambiente grande (ms) Grelha Quadtree Grelha Quadtree Grelha Quadtree Pouco Povoado A* Fringe Search Povoado Muito Povoado A* Fringe Search A* Fringe Search Tabela 76 - Resultados do tempo de processamento na procura de caminho no modo de execução threadpool. (ms) Ambiente pequeno Ambiente médio Ambiente grande Grelha Quadtree Tabela 77 Média dos resultados do tempo de processamento na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente no modo de execução threadpool. (ms) Pouco povoado Povoado Muito povoado Grelha Quadtree Tabela 78 - Média dos resultados do tempo de procura de caminho: Esquema de divisão Vs. Densidade de objetos no modo de execução com threadpool. A análise dos dados recolhidos com base no esquema de divisão mostra resultados semelhantes aos obtidos no modo de execução sem threadpool. Contudo quando se compara os dois modos, verifica-se que o modo de execução com threadpool consome um tempo de processamento superior (ver Ilustração 51 e Ilustração 52). 121

147 Ilustração 55 - Gráfico da média dos resultados do tempo de processamento na procura de caminho: Esquema de divisão Vs. Dimensão do ambiente no modo de execução com threadpool. Ilustração 56 - Gráfico da média dos resultados do tempo de procura de caminho: Esquema de divisão Vs. Densidade de objetos no modo de execução com threadpool. (ms) Ambiente pequeno Ambiente médio Ambiente grande A* Fringe Search Tabela 79 Média dos resultados do tempo de processamento na procura de caminho no modo de execução com threadpool: Algoritmo de procura Vs. Dimensão do ambiente. 122