Universidade de Brasília
Instituto de Ciências Exatas Departamento de Ciência da Computação
Bonsai: um editor de programação gráfica para o motor de jogos Unity 3D
Anderson Campos Cardoso
Monografia apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação
Orientadora
Prof.a Dr.a Carla Denise Castanho
Coorientador
Prof. Dr. Rodrigo Bonifácio de Almeida
Brasília
2013
Universidade de Brasília — UnB Instituto de Ciências Exatas
Departamento de Ciência da Computação Bacharelado em Ciência da Computação
Coordenadora: Prof.a Dr.a Maristela Terto de Holanda
Banca examinadora composta por:
Prof.a Dr.a Carla Denise Castanho (Orientadora) — CIC/UnB Prof. Dr. Rodrigo Bonifácio de Almeida — CIC/UnB
Prof. Dr. Guilherme Novaes Ramos — CIC/UnB Prof.a Dr.a Fernanda Lima — CIC/UnB
CIP — Catalogação Internacional na Publicação
Cardoso, Anderson Campos.
Bonsai: um editor de programação gráfica para o motor de jogos Unity 3D / Anderson Campos Cardoso. Brasília : UnB, 2013.
127 p. : il. ; 29,5 cm.
Monografia (Graduação) — Universidade de Brasília, Brasília, 2013.
1. jogos , 2. desenvolvimento, 3. programação gráfica, 4. Unity 3D CDU 004.4
Endereço: Universidade de Brasília
Campus Universitário Darcy Ribeiro — Asa Norte CEP 70910-900
Brasília–DF — Brasil
Universidade de Brasília
Instituto de Ciências Exatas Departamento de Ciência da Computação
Bonsai: um editor de programação gráfica para o motor de jogos Unity 3D
Anderson Campos Cardoso
Monografia apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação
Prof.a Dr.a Carla Denise Castanho (Orientadora) CIC/UnB
Prof. Dr. Rodrigo Bonifácio de Almeida Prof. Dr. Guilherme Novaes Ramos
CIC/UnB CIC/UnB
Prof.a Dr.a Fernanda Lima CIC/UnB
Prof.a Dr.a Maristela Terto de Holanda
Coordenadora do Bacharelado em Ciência da Computação
Brasília, 09 de março de 2013
Agradecimentos
Em primeiro lugar, agradeço aos meus orientadores, professores Carla Denise Castanho e Rodrigo Bonifácio de Almeida, que tantas vezes mostraram seu apoio e auxiliaram na superação de desafios. Também agradeço aos professores Guilherme Novaes Ramos e Fernanda Lima pelos valiosos comentários e sugestões, e por terem aceito o convite para participarem da banca de avaliação deste trabalho.
Agradeço aos meus pais, Lisérgio e Sthela, por sempre terem acreditado em mim, e propiciado um ambiente onde eu pudesse alcançar meus objetivos. Agradeço ao meu avô materno, Gerisvander, pelo apoio durante toda esta jornada e por ter possibilitado que este momento se concretizasse.
Quero também agradecer à minha esposa Viviane, por me apoiar de inúmeras formas e estar sempre presente quando preciso. Agradeço ao meu filho Derick, pelos maravilhosos momentos de lazer e por me lembrar, todos os dias, o porquê de estar aqui.
Agradeço aos meus amigos de curso por estarem juntos durante toda a graduação, sempre ajudando-se uns aos outros, e por compartilhar momentos inesquecíveis de estudo, desespero e, claro, diversão.
Abstract
As pessoas estão cada vez mais imersas no mundo virtual dos jogos eletrônicos. Celu- lares, tablets, computadores, televisores são alguns exemplos de dispositivos que compor- tam esta mídia. Lojas de distribuição digital (como Apple Store,Google Play,Steam, etc) permitem que jogos eletrônicos possam ser facilmente comercializados em todo mundo.
Além disto, existem inúmeras ferramentas gratuitas, ou de baixo custo, para desenvolvi- mento de games. Este cenário fomenta um crescente número de novas empresas, e pe- quenos grupos, na indústria de jogos eletrônicos. Entretanto, o desenvolvimento de jogos eletrônicos não é uma tarefa trivial, exige-se um forte conhecimento técnico na área de computação.
Neste contexto, esta monografia apresenta o software Bonsai, um plugin de progra- mação gráfica para o motor de jogos eletrônicos Unity 3D que dispensa a necessidade de conhecimento de programação. O objetivo é possibilitar a rápida produção de jogos, principalmente por grupos que não possuem uma equipe de programação, de uma maneira simples e intuitiva, através da criação e determinação de comportamentos de objetos via interface gráfica. O Bonsai fornece uma abstração do código específico do jogo em forma de árvore, que permite configuração em tempo de execução, visualização dos passos de execução, criação de novas estruturas via programação e reutilização de comportamentos em outros objetos e projetos.
Palavras-chave: jogos , desenvolvimento, programação gráfica, Unity 3D
Abstract
People are increasingly immersed in the virtual world of video games. Cell phones, tablets, computers, televisions are examples of devices that enable this media. Digital distribution stores (like Apple Store, Google Play, Steam, etc) allow electronic games to be easily marketed worldwide. Moreover, there are numerous free, or low cost, tools for game development. This setting fosters a growing number of new companies and small groups in the game industry. However, game development is not a trivial task, it requires a strong expertise in the field of computing.
In this context, this work presents the Bonsai tool, a visual programming plugin for the Unity 3D game engine which does not require programming skills. The main goal is to enable rapid production of games, especially by groups that do not have a programming team, in a simple and intuitive way, by creating and determining object’s behaviour with a graphical user interface. Bonsai provides an abstraction of the game’s specific code as a tree structure, which enables run-time configuration, visualization of execution’s steps, programmatically creating new structures and reuse of behaviors in others objects and projects.
Keywords: games, development, visual programming, Unity 3D
Sumário
1 Introdução 1
1.1 Problema . . . 2
1.2 Hipótese . . . 2
1.3 Objetivo . . . 2
1.4 Metodologia . . . 3
1.5 Organização do Documento . . . 3
2 Trabalhos Correlatos 4 2.1 Antares Universe . . . 4
2.2 UScript . . . 6
2.3 Playmaker . . . 9
2.4 NoCode eNoCode-FSM . . . 12
3 Revisão Teórica 15 3.1 Agentes Racionais. . . 15
3.1.1 Agente Reativo Simples . . . 15
3.1.2 Agente Reativo Baseado em Modelo de Ambiente . . . 16
3.1.3 Agentes Reativos e Jogos Eletrônicos . . . 16
3.2 Principais Metodologias para Tomada de Decisão . . . 17
3.2.1 Máquina de Estados . . . 17
3.2.2 Árvore de Comportamento . . . 18
3.3 Unity 3D . . . 23
3.3.1 Objetos de Jogo e Componentes . . . 23
3.3.2 Interface Principal . . . 23
3.3.3 Prefab . . . 24
3.3.4 Construção de um Jogo na Unity 3D . . . 24
4 Bonsai 26 4.1 Visão Geral . . . 26
4.2 Componente Bonsai. . . 27
4.3 Behaviours ou Nós . . . 27
4.3.1 FunctionBehaviour ou Funções . . . 28
4.3.2 BoxBehaviour ou Variáveis . . . 28
4.3.3 PrefabTask . . . 29
4.4 Global Bonsai . . . 29
4.5 Interface . . . 29
4.5.1 Menu Principal . . . 29
4.5.2 Janela Bonsai . . . 30
4.5.3 Janela de Adição de Nós . . . 32
4.5.4 Inspector View . . . 33
4.5.5 Janela Create Behaviour . . . 34
4.5.6 Janela de Preferências . . . 35
4.6 Relação com Linguagem de Programação . . . 35
4.6.1 Condição . . . 36
4.6.2 Composição . . . 36
4.6.3 Atribuição . . . 38
4.6.4 Não-determinismo. . . 38
4.6.5 Iteração . . . 38
4.7 Implementação . . . 39
4.7.1 Editor . . . 40
4.7.2 Runtime . . . 40
5 Aplicações do Bonsai 44 5.1 Controlador em Terceira Pessoa . . . 44
5.1.1 Construindo a Cena . . . 44
5.1.2 Árvore de Comportamento . . . 44
5.2 Eventos de Colisão (Triggers) . . . 47
5.2.1 Construindo a Cena . . . 47
5.2.2 Árvore do Comportamento dos Eventos de Colisão . . . 48
5.3 Controlador de Inimigo . . . 49
5.3.1 Construindo a Cena . . . 49
5.3.2 Árvore de Comportamento do Inimigo . . . 49
6 Conclusão 52 6.1 Trabalhos Futuros. . . 52
Referências 54
Lista de Figuras
2.1 Bloco lógico Get Component doAntares Universe. . . 5
2.2 Editor da ferramenta Antares Universe com um grafo para rotacionar um objeto a cada atualização de quadro. . . 5
2.3 Encaixes do nó Spawn Prefab do editor uScript. . . 7
2.4 Exemplos dos três tipos de nós (evento, ação e variável) existentes nos grafos do editor do uScript. . . 8
2.5 Interface do uScript com um grafo para rotacionar um objeto a cada atu- alização de quadro. . . 9
2.6 Máquina de estados no editorPlaymaker que modela o comportamento de um interruptor. . . 10
2.7 Interface do Playmaker com uma máquina de estados para rotacionar um objeto a cada atualização de quadro. . . 10
2.8 FerramentaNoCode com três instruções em sua janela. . . 13
2.9 Um componente NCLogic com três variáveis na Inspector View. . . 13
2.10 FerramentaNoCode-FSM com três instruções em sua janela. . . 14
3.1 Exemplo de uma máquina de estados finitos de um agente robô que coleta recursos. . . 18
3.2 Exemplo de uma máquina de estados finitos de um agente robô que coleta recursos e precisa recarregar sua bateria para manter o funcionamento. . . 19
3.3 Tarefa de combinação do tipo sequência de uma árvore de comportamento. 20 3.4 Tarefa de combinação do tipo seleção de uma árvore de comportamento. . 21
3.5 Exemplo de uma árvore de comportamento. . . 21
3.6 Exemplo de uma árvore de comportamento com um nó decorador. . . 22
3.7 Instrução if. . . 22
3.8 Janela principal do motor de jogos Unity 3D . . . 24
4.1 Nós Update,OnTriggerEnter e Restart, do tipo FunctionBehaviour . . . . 28
4.2 Menu principal do plugin Bonsai. . . 30
4.3 Janela principal da ferramenta Bonsai. . . 31
4.4 Janela principal da ferramenta Bonsai durante a execução. . . 31
4.5 Janela para adição de nós na árvore . . . 32
4.6 A Inspector View é utilizada para mostrar detalhes sobre o behaviour sele- cionado . . . 33
4.7 JanelaCreate Behaviour com a propriedadeisPlaying da classeAnimation selecionada. . . 34
4.8 Janela de Preferências do plugin Bonsai. . . 35
4.9 Hierarcchy View e Janela Principal modificadas pelas opções de preferências 35
4.10 Comportamento if-else. . . 36
4.11 Comportamento if-elseif. . . 37
4.12 Nó Folder, composição sequencial de árvores de comportamento . . . 37
4.13 Operação de atribuição noplugin Bonsai . . . 38
4.14 Exemplo de não-determinismo noplugin Bonsai . . . 39
4.15 Repetição com condição no Bonsai. . . 39
4.16 Diagrama de classes do módulo de Runtime e de parte do motor Unity 3D. 41 4.17 Diagrama de classes contendo a hierarquia de nós da ferramenta Bonsai. . 42
5.1 Configuração inicial da cena com um plano, uma cápsula, uma câmera e uma luz direcional. . . 45
5.2 Árvore de comportamento de um controlador em terceira pessoa que não altera a velocidade de movimento do personagem. . . 46
5.3 Árvore de comportamento de um controlador em terceira pessoa.. . . 47
5.4 Comportamento para rotacionar a câmera em direção à personagem.. . . . 47
5.5 Cena composta por um plano, a personagem uma luz, uma câmera e um alarme.. . . 48
5.6 Comportamento para ativar e desativar o objeto alarme. . . 49
5.7 Árvore de comportamento com o comportamento do inimigo com parte da estrutura condicional. . . 50
5.8 Comportamento de seguir o objeto Player e mostrar uma mensagem de ataque. . . 51
Capítulo 1 Introdução
Em 1958 William Alfred Higinbotham desenvolveu um programa chamadoTennis for Two para um computador analógico [22]. Tennis for Twopossibilitava que duas pessoas se confrontassem em um jogo de tênis em duas dimensões. O curioso programa que misturava interação com entretenimento deu início a uma das mídias mais populares atualmente, os jogos eletrônicos. Existem diversos jogos eletrônicos disponíveis para celulares, computa- dores e consoles, com as mais diversas finalidade, tais como, entretenimento, educação, treinamento e reabilitação [15, 16, 24].
A indústria de jogos eletrônicos sofreu um enorme crescimento nas últimas décadas, e desde 2007, seu faturamento anual ultrapassou o da indústria cinematográfica [27].
Antes da década de 90 apenas um pequeno grupo de programadores, ou um único programador, participavam de todo o processo de desenvolvimento de um jogo eletrônico.
Estes programadores desenvolviam, geralmente a partir do zero, todo o código e a arte do jogo [1, 23]. Fatores como a competição no setor, a pressão por produtividade e a contínua expansão da indústria de jogos, aumentaram a demanda tanto por profissionais especializados como por novas técnicas de desenvolvimento e produção de jogos [23].
Nos anos 90, motores de jogos (ou Engines), como o Voxel, Ultima Underworld e Doom Engine [18], tornaram-se populares no contexto de desenvolvimento de jogos, pois criavam uma abstração da arquitetura dehardware. Isto facilitava a programação dos jogos, porque permitia que o mesmo motor fosse utilizado para a criação de diferentes jogos em diferentes plataformas.
A arquitetura da maioria dos jogos eletrônicos atuais pode ser dividida em três partes:
motor de jogo (ouengine), lógica do jogo e arte do jogo. O motor de jogo é responsável por fornecer um ambiente onde a lógica do jogo irá funcionar. Ele possui funções básicas para renderização, áudio, matemática, mecânica, etc. A lógica do jogo, também denominado de código específico, é responsável por definir as regras e comportamentos de seus objetos, e corresponde a scripts, bytecodes ou DLLs (Dynamic-Linked Library). A arte do jogo são arquivos de texturas, mapas, modelos 3D e áudio, etc [17].
O motor de jogo é um sistema de software que fornece um conjunto de programas e ferramentas para simplificar e abstrair o processo de desenvolvimento de um jogo. Dentre os motores de jogos atualmente disponíveis no mercado, destacam-se: a CryEngine 3 [6]
pela qualidade gráfica, a Unreal Development Kit [31], também conhecida como UDK, por possuir um editor completo que não necessita de outras ferramentas para a confecção
de games e a Unity 3D [30] pela sua grande popularidade no desenvolvimento de jogos eletrônicos.
Apesar de um motor de jogo fornecer funções básicas para agilizar o desenvolvimento de jogos, toda a lógica do jogo ainda deve ser programada. Geralmente este código especí- fico do jogo é desenvolvido através de uma linguagem descript. A tarefa de se programar um jogo eletrônico, mesmo utilizando um motor de jogo, é complexa e desafiadora. Exige- se uma base sólida de programação e envolve diferentes áreas da ciência da computação como: inteligência artificial, análise de algoritmos e etc [23].
Alguns motores de jogos facilitam o desenvolvimento da lógica do jogo permitindo que esta seja programada através de uma ferramenta visual. A CryEngine 3 e a Un- real Development Kit possuem, respectivamente, os editores Flowchart e Kismet para desenvolvimento do código específico do jogo de forma visual. A Unity 3D não possui um editor nativo para tal facilidade, mas existem plugins (módulos que estendem a funcio- nalidade padrão do editor) proprietários, tais como, Antares Universe [2], uScript [28] e Playmaker [8], que estendem o editor e fornecem tal funcionalidade [2, 6, 8, 28, 31]
Uma categoria diferente de motores de jogos são os voltados para o público não pro- gramador. Estas ferramentas se distinguem das anteriores mencionadas pois desde sua concepção levam em consideração o suporte à construção da lógica do jogo de forma vi- sual. Este é o caso das ferramentasGame Maker [9],Multimedia Fusion [29],Kodu [20] e Gameka [5]. A maioria suporta somente a construção da lógica do jogo de forma visual, ou seja, não possuem suporte a programação.
1.1 Problema
Observou-se nos estudos que dentre as metodologias para modelagem de comporta- mento presentes nas ferramentas de programação gráfica disponíveis para a engine Unity 3D (como a Antares Universe, uScript, Playmaker), não existe uma que mantenha uma visualização de fácil compreensão a medida que se evolui a lógica. Também observou-se, que dentre as ferramentas estudadas não existe uma que possibilite a edição total da lógica em tempo de execução, seja de fácil manutenção para lógicas complexas e tenha um fluxo de trabalho similar as demais tarefas do motor Unity 3D.
1.2 Hipótese
A lógica específica de um jogo eletrônico é melhor visualizada, confeccionada e evo- luída, por não programadores, através de um modelo, com interface gráfica, que forneça uma abstração para linguagens de programação de alto nível. Isto é, o modelo deve abs- trair detalhes específicos da implementação e da linguagem de programação utilizada, ao mesmo tempo que fornece um conjunto de simples regras que possibilite a construção de semânticas similares às presentes em tais linguagens.
1.3 Objetivo
Neste contexto, o objetivo deste trabalho é o desenvolvimento de uma abstração visual para linguagens de programação, denominado Bonsai, no âmbito de desenvolvimento de
jogos eletrônicos. Mais precisamente o Bonsai é um plugin para o motor de jogos Unity 3D que se encaixa na categoria de editor de programação gráfico. O Bonsai não requer conhecimentos sobre codificação de programas e fornece uma visualização gráfica da lógica do código específico de um jogo eletrônico. Seu fluxo de trabalho é similar às demais tarefas presentes no motor Unity 3D, e se assemelha a organizar uma estrutura de diretórios em sistemas operacionais modernos.
1.4 Metodologia
A metodologia proposta para trabalho é dividida em uma sequência de etapas. Inici- almente é feito um levantamento bibliográfico de trabalhos correlatos, onde é verificado o estado da arte em termos de metodologias para modelagem de comportamento de agen- tes reativos. Então, com base nas informações coletadas, serão identificados eventuais problemas e deficiências destes trabalhos. A partir destes resultados serão desenvolvidos mecanismos e alterações, em uma solução proposta, que permitam mitigar estas deficiên- cias. Também será desenvolvido um software que permite pôr em prática esta solução.
1.5 Organização do Documento
O restante desta monografia está organizado da seguinte forma. No Capítulo 2 são descritos alguns trabalhos relacionados com o objeto desta monografia. O Capítulo 3 contém conceitos e metodologias que serviram como base para as decisões de design no desenvolvimento do Bonsai. As características, funcionalidades e implementação do soft- ware desenvolvido são descritos no Capítulo4. No Capítulo5, oplugin Bonsai é utilizado para desenvolver a lógica de alguns cenários presentes no desenvolvimento de jogos eletrô- nicos. Por fim, no Capítulo6, são relatados os resultados do trabalho e expostas algumas conclusões e propostas de trabalhos futuros.
Capítulo 2
Trabalhos Correlatos
Este capítulo tem por objetivo oferecer ao leitor a oportunidade de conhecer outros projetos relacionados a este trabalho. As Seções 2.1,2.2 e2.3 apresentam as ferramentas Antares Universe, uScript e PlayMaker respectivamente. Estas ferramentas são plugins de programação visual para a ferramenta Unity 3D.
2.1 Antares Universe
Antares Universe [2] é um editor visual para programação de jogos naUnity 3D. Neste editor, a lógica do jogo é construída em forma de grafos onde os nós representam ações, eventos e variáveis, enquanto as arestas definem a ordem de execução dos nós.
Neste editor os nós são chamados de blocos lógicos, cada bloco pode possuir gatilhos e variáveis de entrada ou saída. Os gatilhos são utilizados para definir a ordem de execução dos blocos lógicos. Ao terminar sua execução o bloco envia um sinal para que todos os blocos lógicos conectados ao seu gatilho de saída iniciem sua execução. Os gatilhos são representados por setas que apontam para a direita. As setas à esquerda do bloco representam gatilhos de entrada e as setas à direita gatilhos de saída. Alguns blocos lógicos não possuem gatilhos de entrada, estes iniciam sua execução quando um determinado evento ocorre.
As variáveis são geralmente representadas por círculos, que são cinzas quando um valor já foi atribuído à variável e vermelhos caso contrário. As variáveis de entrada se localizam na parte de cima do bloco lógico e as variáveis de saída abaixo. Na Figura 2.1 tem-se o bloco Get Component, que possui um gatilho de entrada, três de saída, uma variável de entrada e três variáveis de saída, como exemplo.
Na Figura 2.2 é apresentado o editor da ferramenta Antares Universe com um grafo para rotacionar um objeto a cada atualização de quadro. O grafo possui três nós e duas arestas. O nó mais acima é o Transform que representa uma variável, neste caso o componente Transform do objeto que irá rotacionar. O nó mais abaixo é o Rotate, que tem como função atualizar o componente Transform do objeto de forma que este seja rotacionado. Por último temos o nó Update que está ligado ao nó Rotate e é responsável por ativá-lo a cada atualização de quadro.
A janela de edição doAntares Universe pode ser dividida em quatro partes:
1. Área de trabalho: região onde o grafo é confeccionado.
Figura 2.1: Bloco lógico Get Component doAntares Universe.
Figura 2.2: Editor da ferramenta Antares Universe com um grafo para rotacionar um objeto a cada atualização de quadro.
2. Caixa de ferramentas: nesta parte da interface encontram-se os blocos lógicos disponíveis para desenvolvimento do grafo. Os blocos lógicos estão organizados por funcionalidade, ao se clicar no botão do bloco este ficará disponível para uso na área de trabalho. Também é possível pesquisar por um bloco através do nome.
3. Inspecionador: informa detalhes sobre o bloco selecionado na área de trabalho.
Esta região da interface possui quatro partes:
(a) parâmetros de entrada;
(b) parâmetros de saída;
(c) área de conversão de bloco;
(d) descrição;
4. Painel de Instrumentos: possui menus para interação com o grafo, através dos quais é possível salvar, carregar ou renomear um grafo, além de ajustar configurações globais da janela.
u s i n g U n i t y E n g i n e ;
u s i n g A n t a r e s . V i z i o . Runtime ;
[ V i s u a l L o g i c B l o c k ("Sum o f F l o a t s B l o c k ", " Smart B l o c k s ") ] p u b l i c c l a s s MySinBlock : L o g i c B l o c k
{
[ Parameter ( V a r i a b l e T y p e . In , t y p e o f (f l o a t) ) ] p u b l i c V a r i a b l e a ;
[ Parameter ( V a r i a b l e T y p e . In , t y p e o f (f l o a t) ) ] p u b l i c V a r i a b l e b ;
[ Parameter ( V a r i a b l e T y p e . Out , t y p e o f (f l o a t ) ) ] p u b l i c V a r i a b l e aPlusB ;
p u b l i c o v e r r i d e v o i d O n I n i t i a l i z e D e f a u l t D a t a ( ) {
R e g i s t e r O u t p u t T r i g g e r (" E x i t ") ; }
[ E n t r y T r i g g e r ] p u b l i c v o i d I n ( ) {
aPlusB . Value = (f l o a t) a . Value + (f l o a t) b . Value ; A c t i v a t e T r i g g e r (" E x i t ") ;
} }
Código Fonte 2.1: Ação personalizada do editorAntares Universe.
O Antares Universe possibilita, via programação, a criação de novos blocos persona- lizados. Para isto, estende-se a classe LogicBloc e implementam-se as variáveis e gatilhos.
O Código Fonte 2.1 é um bloco que calcula a soma de dois números. Este bloco possui duas variáveis de entrada (a e b) do tipofloat e uma variável de saída (aPlusB), também do tipo float. O métodoOnInitializeDefaultData é chamado quando o bloco é instanciado e registra um gatilho de saída, neste caso, Exit. O método In é um gatilho de entrada pois possui o atributo EntryTrigger, este método é executado sempre que o gatilho de entrada é ativado. O método In calcula a soma das duas variáveis de entrada e armazena o resultado na variável aPlusB, logo após ativa o gatilho de saída Exit.
2.2 UScript
O uScript [28] é uma ferramenta de programação visual para a Unity 3D inspirada no Kismet da UDK [31]. No uScript, a lógica do jogo é representada por grafos e assim como no Antares, os nós dos grafos representam eventos, ações e variáveis, e as arestas representam a ordem de execução dos nós ou atribuem referências a variáveis. Ao se salvar um grafo a ferramenta gera três arquivos: um binário que contém informações sobre a
apresentação visual do grafo e dois outros scripts na linguagem C#. Um dos scripts é um componente e o outro contém toda a lógica presente no grafo. O componente deve ser anexado a algum objeto de jogo na cena, sua função é criar uma instância do script que contém a lógica do grafo.
Neste editor os nós podem se ligar através de encaixes, que podem ser de entrada/saída ou de variáveis de entrada/saída. Os encaixes de entrada/saída são representados por círculos de cor preta, os de entrada ficam à esquerda do nó, e os de saída à direita. Esses encaixes definem a ordem de execução dos nós. Ao terminar a sua execução um nó envia um sinal para que todos os nós conectados em seu encaixe de saída iniciem sua execução.
Os encaixes de variáveis de entrada são representados por círculos e os de variáveis de saída por setas, a cor do encaixe indica o tipo da variável.
Na Figura 2.3 tem-se o nó Spawn Prefab que instancia um objeto na cena. Este nó possui um encaixe de entrada, dois encaixes de saída, três encaixes de variáveis de entrada e um encaixe de variável de saída.
Figura 2.3: Encaixes do nó Spawn Prefab do editor uScript.
A Figura 2.4 apresenta um exemplo dos três tipos de nós existentes no uscript, da esquerda para a direita tem-se:
• Evento: possui a borda na cor alaranjada, não possui encaixe de entrada e é execu- tado quando um determinado evento ocorre.
• Ação: possui a borda na cor cinza e pelo menos um encaixe de entrada.
• Variável: não possi encaixes e pode ser ligado a encaixes de variáveis de entrada ou saída do mesmo tipo.
O grafo presente na Figura2.5 rotaciona um objeto a cada atualização de quadro. O nóGlobal Update aciona a execução do nó Rotate a cada atualização de quadro. ORotate é responsável por rotacionar o Game Object, referenciado pelo nó mais abaixo, cada vez que entra em execução.
A interface do uScript pode ser dividida em cinco partes, conforme indicado pela numeração em vermelho na Figura 2.5 [28]:
1. Painel de paletas de nós: nesta parte encontra-se uma lista de nós a serem utilizados no painel de tela. Os nós aparecem neste painel como botões, clicando-se
Figura 2.4: Exemplos dos três tipos de nós (evento, ação e variável) existentes nos grafos do editor do uScript.
em um destes botões cria-se um nó, correspondente a este botão, no centro do painel tela.
2. Painel de tela: a tela é a região onde os nós são inseridos e conectados para se formar um grafo lógico.
3. Painel de propriedades: este painel mostra todas as propriedades do nó selecio- nado na tela. É possível editar os valores de uma propriedade ou esconder/mostrar um encaixe de variável.
4. Painel de referência: contém informações textuais sobre o nó selecionado na tela.
Também possui botões para a documentação on-line e o arquivo correspondente ao código fonte do nó.
5. Painel uScript: este painel mostra todos os grafos criados no projeto. Também possui informações sobre os grafos, como por exemplo, qual grafo está carregado, qual não está salvo, etc.
Estendendo-se a classe uScriptLogic ou a classe uScriptEvent é possível criar novos nós de ações ou eventos respectivamente. O Código Fonte 2.2 mostra um nó de ação personalizado que possui duas variáveis de entrada (a e b) e uma de saída (aPlusB), todas do tipo float. O método In é apresentado na tela como um encaixe de entrada, e o método Out é representado como um encaixe de saída. Ao receber o sinal de entrada, o método In é executado e realiza a soma dos números.
Figura 2.5: Interface do uScript com um grafo para rotacionar um objeto a cada atuali- zação de quadro.
u s i n g U n i t y E n g i n e ;
[ NodePath (" A c t i o n s /Math") ]
p u b l i c c l a s s MySumAction : u S c r i p t L o g i c {
p u b l i c b o o l Out { g e t { r e t u r n t r u e; } }
p u b l i c v o i d I n ( f l o a t a , f l o a t b , o ut f l o a t aPlusB ) {
aPlusB = a + b ; }
}
Código Fonte 2.2: Código de uma ação personalizida no editor uScript.
2.3 Playmaker
O Playmaker [8] é uma extensão ao editor da Unity3D que possibilita o desenvolvi- mento de máquinas de estados finitos de forma visual. Através deste editor é possível criar estados, definir ações para estes estados, e determinar as transições entre os estados. Mu- danças de estados são desencadeadas por eventos. Existem alguns eventos pré-definidos que estão relacionados com eventos do motor Unity 3D como, por exemplo, os eventos de clique de mouse. O Playmaker também possibilita a criação de eventos personalizados que podem ser disparados através de ações.
A Figura 2.6 ilustra um exemplo de uma máquina de estados no editor Playmaker.
Esta máquina de estados possui dois estados, On e Off, e três transições desencadeadas pelos eventos Start, Mouse Down e Mouse Up. Quando a máquina de estados se torna
Figura 2.6: Máquina de estados no editor Playmaker que modela o comportamento de um interruptor.
ativa o eventoStart é disparado e torna o estado Off ativo. Ao se tornar ativo um estado executa todas as suas ações, na ordem em que foram definidas. O evento Mouse Down e Mouse Up são disparados, respectivamente, pelo sistema quando o usuário pressiona algum botão do mouse e quando solta algum botão do mouse que esteja pressionado.
Assim a transição do estado Off para o estado On ocorre quando o usuário pressiona algum botão do mouse, e do estado On para o Off quando o usuário solta algum botão do mouse.
Figura 2.7: Interface do Playmaker com uma máquina de estados para rotacionar um objeto a cada atualização de quadro.
A Figura 2.7 é uma máquina de estados com um evento Start e um único estado chamado de State 1. O estado State 1 possui uma única ação (Rotate) responsável por rotacionar o objeto. O evento Start torna o estado State 1 ativo e inicia a execução da ação Rotate.
A janela principal do Playmaker pode ser dividida em duas partes, conforme indica as numeração em vermelho na Figura 2.7 e a respectiva descrição abaixo:
1. Editor de grafo: nesta região é possível adicionar novos estados, determinar as transições, entre os estados, e os eventos que as desencadeiam.
2. Inspecionador: através deste painel é possível editar propriedades da máquina de estados finito e também de seus estados. Este painel possui as abas:
(a) FSM: nesta aba é possível editar propriedades da máquina de estados finitos.
(b) State: contém as propriedades das ações do estado selecionado no editor de grafo, possibilita a alteração, inclusão, remoção e mudança de ordem das ações.
(c) Event: aba para criação de eventos personalizados.
(d) Variables: possibilita a criação de variáveis que podem ser utilizadas para troca de informações entre as ações dos estados.
OPlaymaker possibilita a programação de novos tipos de ações, que são desenvolvidas estendendo-se a classe FsmStateAction e implementando-se os métodos Reset, OnEnter e/ouOnUpdate. O métodoReset é utilizado para inicializar as variáveis da ação, o método OnEnter é acionado quando a ação deve ser executada e o método OnUpdate é chamado a cada atualização de quadro, enquanto o estado estiver ativo.
O Código Fonte 2.3 mostra uma ação personalizada que soma dois números do tipo float. A ação possui duas variáveis de entrada do tipo FsmFloat, este tipo é utilizado pelo Playmaker para armazenar variáveis do tipo float. O método Reset é utilizado para inicializar as variáveis do objeto e o método OnEnter realiza a soma dos números.
u s i n g U n i t y E n g i n e ;
u s i n g System . C o l l e c t i o n s ;
namespace HutongGames . PlayMaker . A c t i o n s {
[ A c t i o n C a t e g o r y ( A c t i o n C a t e g o r y . Math ) ] [ T o o l t i p ("Sums one F l o a t by a n o t h e r . ") ] p u b l i c c l a s s MySumAction : F smS tate Ac tion {
[ UIHint ( UIHint . V a r i a b l e ) ] p u b l i c FsmFloat f l o a t V a r i a b l e ; p u b l i c FsmFloat sumBy ;
p u b l i c o v e r r i d e v o i d R e s e t ( ) {
f l o a t V a r i a b l e = n u l l ; sumBy = n u l l ;
}
p u b l i c o v e r r i d e v o i d OnEnter ( ) {
f l o a t V a r i a b l e . Value += sumBy . Value ; F i n i s h ( ) ;
} } }
Código Fonte 2.3: Ação personalizida do plugin Playmaker.
2.4 NoCode e NoCode-FSM
Dois outros plugins de programação gráfica para a Unity 3D precederam o desenvol- vimento do Bonsai: NoCode e NoCode-FSM. O NoCode, Figura 2.8, possui inspiração na ferramenta Kodu [20]. A lógica é construída através de instruções que possuem um conjunto de condições e ações. Durante a execução, cada instrução avalia seu conjunto de condições para decidir se executa, ou não, seu conjunto de ações. A execução de uma instrução é condicionada a um evento, que é indicado no primeiro atributo da instru- ção. Por exemplo, a primeira instrução da Figura 2.8 ocorre no evento Start, padrão do motor Unity 3D e correspondente à eventos como início de jogo, atualização de quadro, atualização da física, etc.
As instruções são armazenadas em um componente chamado deNCLogic, que possui toda a informação necessária para a execução da lógica específica. Além das instruções, o componente NCLogic também armazena variáveis, que são utilizadas pelas condições e ações. A Figura 2.9 corresponde à visualização de um componente NCLogic na janela de componentes, ou Inspector View, da Unity 3D. Este componente possui três variáveis:
speed, target e direction, que armazenam valores do tipo float, GameObject e Vector3 respectivamente. Nesta mesma janela é possível incluir novas variáveis e editar atributos (como nome, cor , símbolo, etc) das variáveis já criadas.
NoCode-FSM, Figura2.10, é uma evolução daNoCode, que se baseia em máquinas de estados finitos, em que cada estado corresponde a um conjunto de instruções como os da
Figura 2.8: Ferramenta NoCode com três instruções em sua janela.
Figura 2.9: Um componente NCLogic com três variáveis na Inspector View.
ferramenta NoCode. O componente NCLogic desteplugin armazena, além das instruções e variáveis, uma máquina de estados finitos (com seus estados e transições).
Os doisplugins,NoCode eNoCode-FSM, permitem que o conjunto de ações e condições possam ser estendidos via programação. Os nós de ação possuem como classe base a classe NCActionBaseNode, os nós do tipo condição herdam da classeNCConditionBaseNode. A classe NCActionBaseNode possui o método virtual Do, que é invocado quando a ação é executada. A classeNCConditionBaseNode possui o método virtualTest, que retorna um valor booleano para validação da condição.
O Código Fonte2.4mostra uma ação personalizada, denominadaFloatAdd, dosplugins NoCode e NoCode-FSM. Esta ação possui três variáveis, que armazenam valores do tipo float, como atributo. Em sua execução, método Do, a variável aPlusB recebe a soma das variáveis a eb.
Figura 2.10: Ferramenta NoCode-FSM com três instruções em sua janela.
u s i n g U n i t y E n g i n e ; u s i n g NoCode . Nodes ; [ I n f o (" FloatAdd ",
i c o n P a t h=" A s s e t s /NoCode/ E d i t o r / Images / E d i t F l o a t . png ", d e s c r i p t i o n = " s t o r e = a + b") ]
p u b l i c c l a s s FloatAdd : NCActionBaseNode {
p u b l i c V a r i a b l e F l o a t a ; p u b l i c V a r i a b l e F l o a t b ; [ R e q u i r e V a r i a b l e ]
[ N C V a r i a b l e I n f o ( S l o t P o s i t i o n . Corner4 ) ] p u b l i c V a r i a b l e F l o a t aPlusB ;
p u b l i c o v e r r i d e v o i d Do ( ) {
aPlusB . Value = a . Value + b . Value ; }
}
Código Fonte 2.4: Código de uma ação personalizida dosplugins NoCode eNoCode-FSM.
Apesar de simples, a ferramenta NoCode possui pouca expressividade, não possui estruturas de repetição, blocos de instrução e outras estruturas. Embora seja fácil re- presentar a lógica em forma de máquina de estados, a ferramenta NoCode-FSM, possui alguns problemas, além dos inerentes à máquina de estados finitos: representar estrutu- ras condicionais complexas (if-elseif ou switch) ou estruturas de repetição é uma tarefa difícil.
Capítulo 3
Revisão Teórica
Nesse capítulo é feita uma revisão teórica sobre os conceitos envolvidos na construção doplugin Bonsai. A Seção3.1contém informações sobre os principais agentes inteligentes utilizados em jogos eletrônicos. Durante a Seção 3.2 é apresentada uma comparação entre as metodologias de tomada de decisão para comportamento de agentes reativos.
Esta comparação é fundamental para compreender as decisões de projeto presentes no desenvolvimento da Bonsai. Na Seção 3.3 tem-se uma breve introdução ao motor de jogos eletrônicos Unity 3D, seu fluxo de trabalho e os conceitos envolvidos no processo de desenvolvimento de um jogo eletrônico nesta engine.
3.1 Agentes Racionais
Russel e Norvig [25] descrevem um agente como tudo o que pode ser considerado capaz de perceber seu ambiente por meio de sensores e agir sobre este ambiente através de atuadores. Uma definição mais recente é apresentada em [7]: "Um agente é uma entidade autônoma capaz de interagir com o ambiente e outros agentes". Assim, um ser humano no ambiente a sua volta pode ser considerado um agente, uma vez que é uma entidade que toma decisões por conta própria, possui sensores (ouvidos, olhos e outros órgãos) e atuadores (braço, corpo, etc) que agem sobre o mesmo ambiente ou outros seres humanos (agentes).
Não existe um consenso quanto a definição de agente [3], porém as idéias de autonomia e interação com o ambiente norteiam este conceito. No contexto deste trabalho entende-se por agente algo que possui autonomia e interage com o ambiente.
Um agente é considerado racional quando é capaz de tomar a melhor decisão possível com as informações que possui. Para isto deve-se estabelecer uma medida de desempenho.
Esta medida deve classificar a ação escolhida pelo agente em contrapartida com o estímulo recebido. Pode-se entender um agente racional como aquele que escolhe a ação que tenta maximizar o desempenho a partir de seu conhecimento [25].
3.1.1 Agente Reativo Simples
O tipo mais simples de agente é o reativo simples. Este agente escolhe qual ação executar baseando-se apenas nas informações disponibilizadas por seus sensores naquele
momento. Esses agentes possuem um modelo simples porém limitado. Tais agentes decidem levando em consideração apenas a percepção atual [25].
Em jogos eletrônicos diversas entidades podem ser modeladas como agentes reativos simples e gerar agentes racionais. Considere a seguinte situação em um jogo: o personagem do jogador deve pressionar um botão para abrir uma porta e prosseguir no jogo. A ação (abrir uma porta) do botão depende unicamente de um estímulo do personagem.
O comportamento do botão descrito anteriormente pode ser generalizado para o se- guinte: dada uma condição execute uma ação. Este tipo de comportamento é comumente encontrado em diversas entidades de jogos eletrônicos.
3.1.2 Agente Reativo Baseado em Modelo de Ambiente
Os agentes reativos baseados em modelo possuem a capacidade de manter um estado interno parcial do ambiente. Este estado interno deve influenciar na tomada de decisão do agente. Conforme o agente baseado em modelo recebe estímulos do ambiente seu estado interno é atualizado. Deste forma, ao longo do tempo o estado interno do agente é modificado.
Este mecanismo faz com que o agente decida levando em consideração o seu histórico de estímulos, diferente do agente reativo simples que considera apenas a situação atual.
Entretanto, para ter um bom resultado o agente precisa ter algum conhecimento de como é o seu ambiente, saber como seu ambiente funciona e com base na memória estimar a si- tuação atual. Este conhecimento se encontra codificado no sistema que atualiza os estados internos dos agentes. A idéia é que este tipo de agente possa manter uma representação, mesmo que simbólica, de como é o seu ambiente. Esta representação é conhecida como modelo do mundo [25].
Agora, considere a seguinte situação em um jogo eletrônico: o personagem do jogador deve pressionar um botão duas vezes para abrir uma porta e prosseguir no jogo. Nesta situação, a ação (abrir a porta) do botão depende de dois estímulos que ocorrem em ocasiões diferentes. Logo, o comportamento deste botão não pode levar em consideração apenas os estímulos em um dado instante. A informação de que o botão foi pressionado na primeira vez deve ser armazenada no tempo, para se ter conhecimento quando o botão for pressionado novamente. Assim, o botão precisa atualizar o seu estado interno no tempo para poder decidir se ao ser pressionado deve, ou não, abrir a porta.
3.1.3 Agentes Reativos e Jogos Eletrônicos
Existem diversos outros tipos de agentes, dentre eles os agentes baseados em objetivos, agentes baseados na utilidade e com aprendizagem [25]. Alguns agentes possuem a capa- cidade de armazenar informações internamente, ou todos estímulos recebidos, e utilizar tais dados para decidir sobre a ação a ser tomada.
Uma importante diferença entre a robótica e os jogos eletrônicos é que neste último o ambiente do agente é o próprio mundo do jogo [10]. Isto implica que toda a informação do ambiente pode ser disponibilizada para os agentes. Outro importante fato é que os sensores dos agentes em jogos eletrônicos baseiam-se em símbolos e não em sensores reais (que podem conter erro) [10]. Por estes fatores os agentes reativos são frequentemente utilizados em jogos eletrônicos.
3.2 Principais Metodologias para Tomada de Decisão
O comportamento de tomada de decisão pode ser modelado através de diversas repre- sentações, entre elas temos as máquinas de estados finitos, máquinas de estados hierárqui- cas, árvore de comportamento, etc. Basicamente estas representações tentam responder à mesma pergunta, ou seja, como mapear um conjunto de entradas para um conjunto de ações?
Nem sempre esta lógica é trivial, existem comportamentos complexos com centenas de entradas, condições e ações. O modelo deve se responsabilizar por tratar todas estas informações e ainda possuir escalabilidade ao mesmo tempo que se mantém inteligível para os seres humanos. Durante esta seção são apresentados diversas representações para modelar o comportamento de tomada de decisão, suas vantagens e desvantagens.
3.2.1 Máquina de Estados
Máquinas de estados são comumente utilizadas para descrever comportamentos. A vantagem de uma máquina de estados está na simplicidade. Uma máquina de estados é composta por apenas dois componentes [21]:
• Estado: Caracteriza-se por uma sequência de ações.
• Transição: Corresponde a um caminho de um estado para outro. Uma transição relaciona um evento com dois estados, informa qual será a mudança de estado caso uma determinada condição seja verdadeira.
Uma máquina de estado nada mais é do que um conjunto de estados e um conjunto de transições entre estes estados. Em um dado instante somente um estado pode estar em execução, a mudança de estado ocorre quando uma determinado condição é satisfeita.
Máquina de Estados Finitos
Máquinas de estados finitos (FSM - Finite State Machine) são máquinas de estados que possuem um conjunto finito de estados. FSM é a técnica mais comum para modelagem de comportamento de tomada de decisão em jogos eletrônicos [21]. Apesar do conceito simples, estas máquinas podem ter milhares de estados, o que prejudica sua escalabilidade e visualização gráfica.
A Figura 3.1 mostra uma máquina de estados que modela o comportamento de um agente robô que tem a função de coletar recursos e trazê-los à base. A máquina de estados contém os seguintes estados: Procurando,Extraindo eEntregando. As transições entre os estados são desencadeadas pelos eventos: Coleta Recursos, Entrega Recursos e Encontra Recursos.
Em comportamentos complexos, frequentemente têm-se a necessidade de duplicação de estados [21]. O aumento do número de estados ocorre quando se deseja representar agentes orientados a objetivos. Para representar tais agentes define-se um objetivo como um conjunto de estados. Porém, quando um outro objetivo possui alguns estados semelhantes, é necessário duplicar estes estados no novo objetivo. Isto é necessário para que em uma transição de estados o objetivo atual seja mantido.
Procurando
Entregando Coleta Recursos Extraindo
Entrega Recursos Encontra Recursos
Figura 3.1: Exemplo de uma máquina de estados finitos de um agente robô que coleta recursos.
No exemplo do agente robô que coleta recursos, caso este também necessite recarregar sua bateria quando esta estiver fraca, é necessário criar um novo estado, denominado Recarregando, na FSM. Este estado deve ser prioridade para o agente, uma vez que sem bateria o agente não pode exercer a função de coletar recursos. Desta forma os três outros estados (Procurando, Entregando e Extraindo) devem conter transições para um estado onde a bateria deve ser recarregada. Porém, ao se carregar a bateria o agente deve retornar para o estado anterior ao estado Recarregando, para que a função de coletar recursos continue de um estado válido. Nesta situação é preciso criar um estado Recarregando para cada estado relacionado com a função de coletar recursos. A Figura 3.2 representa a máquina de estados finitas deste agente.
Máquina de Estados Finitos Hierárquica
Ao invés de modelar todo o comportamento em uma única máquina de estados, em uma máquina de estados finitos hierárquica (HFSM - Hierarchical Finite State Ma- chine), o comportamento é dividido em vários sub-comportamentos. Cada um destes sub-comportamentos corresponde a uma FSM, e estas máquinas também são ligadas en- tre si por transições. Em um dado instante somente uma destas máquinas pode estar em execução.
A vantagem da HFSM em relação à uma FSM é uma melhor modularidade. Isto au- menta o reaproveitamento de partes de uma máquina em outra, e facilita a representação de comportamentos mais complexos [21]. Porém, as HFSMs sofrem do mesmo problema que as FSMs, o aumento da complexidade do comportamento impacta em um aumento no número de transições, estados e FSMs; dificultando a sua manutenção, atualização e visualização [10]. Representar objetivos ainda é uma tarefa difícil para estas máquinas.
3.2.2 Árvore de Comportamento
Árvore de comportamento (BT - Behaviour Tree) é uma metodologia para projetar comportamentos de sistemas autônomos [13]. Esta metodologia reúne diversas técnicas de inteligência artificial: HFSM, scheduling, execução de ações e planejamento [21].
Procurando
Entregando Extraindo
Recarregando (Procurando)
Recarregando (Extraindo) Recarregando (Retornando)
Coleta Recursos
Entrega Recursos Encontra Recursos Bateria Fraca Bateria Recarregada
Bateria Fraca Bateria Recarregada Bateria Fraca Bateria Recarregada
Figura 3.2: Exemplo de uma máquina de estados finitos de um agente robô que coleta recursos e precisa recarregar sua bateria para manter o funcionamento.
A proposta da BT é representar o comportamento em uma estrutura de árvore, de modo que cada sub-árvore corresponda a um sub-comportamento. Estas sub-árvores são chamados de tarefas.
A BT se assemelha à uma HFSM, entretanto, ao contrário de um estado, o bloco principal é uma tarefa [21]. Uma importante diferença entre uma HFSM e uma árvore de comportamento, é que nesta última a própria estrutura define a prioridade de execução das tarefas (seu bloco principal). Facilitando a modelagem de comportamentos que possuem objetivo, um dos problemas presentes nas HFSMs.
Execução
A execução da árvore de comportamento ocorre com busca em profundidade iniciando- se pela raiz. A primeira folha encontrada será executada, o valor retornado de sua execução será repassado para seu pai. O pai processa esta informação e, dependendo de sua lógica de tomada de decisão, ou seus demais filhos são processados ou a execução nesta sub- árvore é interrompida e a árvore continua a ser processada com busca em profundidade na próxima sub-àrvore.
Ações ou Condições (Folhas)
As folhas de uma BT podem ser de dois tipos: ação ou condição. As folhas represen- tam a interface de comunicação com o ambiente. As condições lêem informações sobre o estado do ambiente e executam validações, as ações modificam o ambiente [4]. As ações ou condições podem ser complexas ou simples, isto é, uma condição pode corres- ponder a identificar se um inimigo está no campo de visão ou pode ser simplesmente uma comparação entre os valores de duas variáveis.
Tarefas de Combinação (Ramos)
Enquanto as folhas possuem condições e ações, os ramos (denominados de tarefa de combinação) contém a lógica de tomada de decisão. Os ramos controlam quais filhos (condições, ações e outros ramos) serão executados.
No término da execução tanto os ramos quanto as folhas retornam um valor ao seu pai, este valor indica se o nó ou seus sub-nós, no caso dos ramos, foram executados. Diversas implementações de árvores também retornam outras informações sobre sua execução, como por exemplo se houve algum erro. A escolha dos ramos é realizada levando-se em conta o valor retornado por seus filhos.
Existem vários tipos de ramos, e cada um possui uma lógica diferente para tomada de decisão. Os tipos mais comuns de tarefa de combinação são a seleção e a sequência.
A “sequência” retorna o valorverdadeiro quando todos os seus filhos também retornam o valor verdadeiro. Esta tarefa de combinação executa os seus filhos em ordem, e caso um deles retorne o valor falso a “sequência” interrompe a execução e retorna o valorfalso.
A árvore na Figura 3.3 representa o comportamento de luta de uma entidade em um jogo eletrônico. As folhas de cor alaranjada são condições e as de cor cinza ações. O ramo
“Lutar” é do tipo sequência e portanto só retornará o valor verdadeiro se todas as suas folhas (“Encontrou Inimigo?”,“Inimigo na mira” e “Atacar inimigo”) também retornarem o valor verdadeiro.
Após a raiz, a condição “Encontrou Inimigo?” é executada na árvore da Figura 3.3.
Se esta condição for verdadeira o próximo nó a ser executado é a condição “Inimigo na mira?”. Se a condição “Inimigo na mira?” for falsa a execução dos filhos de “Lutar” é interrompida e o valorfalso é retornado por este último nó. A ação “Atacar” é executada se o retorno de “Inimigo na mira?” também for verdadeiro.
Lutar
Encontrou
inimigo? Inimigo
na mira? Atacar inimigo
Figura 3.3: Tarefa de combinação do tipo sequência de uma árvore de comportamento.
A “seleção” retorna o valorverdadeiro se pelo menos um de seus filhos também retor- nar o valor verdadeiro. Caso um de seus filhos retorne o valor verdadeiro a execução é interrompida e o valor verdadeiro é retornado para seu o pai. Se a execução chegar ao final e nenhum valor verdadeiro for retornado pelos seus filhos, a “seleção” retorna o valor falso.
A árvore na Figura 3.4 representa o comportamento de descanso de um agente. Este comportamento possui uma tarefa de combinação do tipo seleção (“Descansar”) e três ações (“Deitar”, “Sentar”, “Se escorar”). O primeiro nó a ser executado na árvore 3.4 é a ação “Deitar”. Caso esta ação retorneverdadeiro a execução dos filhos da tarefa de seleção de “Descansar” é interrompida e o valor verdadeiro é retornado ao pai deste último nó.
Caso o valor retornado por “Deitar” seja falso, o próximo filho (“Sentar”) será executado.
Se todos os filhos de “Descansar” retornarem o valor falso então este último também retornará o valor falso.
Descansar
Deitar Sentar Se escorar
Figura 3.4: Tarefa de combinação do tipo seleção de uma árvore de comportamento.
A árvore na Figura 3.5 possui mais tarefas que as anteriores e representa o compor- tamento de patrulhar de um agente. A raiz desta árvore é um nó de seleção, assim, ou o agente executa a tarefa “Atacar” ou a tarefa “Procurar inimigo”. A tarefa "Ata- car"corresponde a mesma árvore apresentada na Figura3.3. A possibilidade de reutilizar tarefas em outras árvores é uma das vantagens da árvore de comportamento [13].
Patrulhar
Lutar Procurar
inimigo
Encontrou
inimigo? Inimigo
na mira? Atacar Inimigo
Investigar
Mover
Esta
claro? Olhar em volta
Figura 3.5: Exemplo de uma árvore de comportamento.
Decoradores (Ramos com um único filho)
O decorador é um tipo especial de tarefa de combinação que possui apenas um único filho. A função desta tarefa é adicionar um comportamento diferente a seu filho, modi- ficando a execução desta sub-árvore. Geralmente estes decoradores modificam o retorno de um nó ou definem, utilizando algum parâmetro dinâmico, quando executar seus filhos.
Tais tarefas são inspiradas no padrão de projeto de mesmo nome [4, 21].
Em um exemplo mais complexo, a árvore na Figura3.6também representa o compor- tamento de descansar de um agente. Porém, um nó decorador, denominado “Apenas 2 Vezes”, é inserido para adicionar um limite ao número de vezes que a ação “Deitar” pode ser executada.
Descansar
Deitar
Sentar Se escorar Apenas
2 vezes
Figura 3.6: Exemplo de uma árvore de comportamento com um nó decorador.
Relação com Linguagem de Programação
As árvores de comportamento possuem uma estreita relação com as linguagens de pro- gramação [21, 25]. Por exemplo, na Figura 3.7 é mostrado como construir uma condição, similar à instrução if de linguagens de programação, em uma árvore de comportamento.
Utiliza-se uma tarefa de combinação do tipo seleção e duas sub-árvoresP eb. A sub-árvore P será executada somente se a sub-árvoreb retornar o valor verdadeiro.
If
b P
Figura 3.7: Instrução if.
Árvore de Comportamento em Jogos Eletrônicos
Halo 2 [14], lançado em 2004, foi um dos primeiros jogos a utilizar árvores de compor- tamento para modelar o comportamento dos agentes. Este modelo foi implementado no jogoHalo 2 para satisfazer alguns requisitos de projeto, como: escalabilidade, trânsparên- cia, coerência e facilidade de trabalho [14]. A árvore de comportamento possibilitou que
os designers, sem conhecimentos sobre programação, pudessem desenvolver a lógica de tomada de decisão dos inimigos e NPC’s1. Desde então, as BT’s tornaram-se um modelo popular para criação de inteligência artificial de personagens em jogos eletrônicos. Em 2011 o jogo Spore utilizou uma versão modificada das BTs presente em Halo para criar um sistema de inteligência artificial para milhares de criaturas virtuais [11].
3.3 Unity 3D
A Unity 3D é um motor para jogos eletrônicos com foco na usabilidade e desenvolvi- mento para múltiplas plataformas [30]. Seu principal público alvo são pequenas empresas e desenvolvedores independentes de jogos eletrônicos. Apesar de estar disponível desde 2005 a Unity 3D só começou a se tornar popular ao disponibilizar uma versão gratuita e um editor para o sistema operacional Windows. Segundo a pesquisa da revista Game Developer, realizada entre desenvolvedores de jogos para plataformas móveis e sociais, 53.1% deles utilizam o motor Unity 3D [19].
3.3.1 Objetos de Jogo e Componentes
Neste motor os jogos são desenvolvidos em uma arquitetura baseada em entidade com- ponente, em que todo o jogo é formado por um único tipo de entidade chamada de objeto de jogo. Os objetos de jogo são containers para componentes. Um componente adici- ona uma determinada funcionalidade a um objeto de jogo. Por exemplo, o componente Rigidbody adiciona características de corpo rígido (massa, gravidade, etc) ao objeto, o componenteMeshRendering desenha o objeto na cena. Desta forma, o que diferencia um personagem de um veículo ou de uma parede é o conjunto de componentes adicionado neste objeto de jogo.
3.3.2 Interface Principal
A Figura 3.8 apresenta a janela principal da ferramenta Unity 3D. Esta janela se subdivide em regiões:
• Project View: contém todos os recursos (também chamados de assets) a serem uti- lizados na construção do jogo. Exemplos deassets são: arquivos de áudio, texturas, scripts, prefabs, etc. A project view corresponde a arquivos e pastas do projeto no sistema do usuário.
• Hierarchy View: contém todos os objetos de jogo utilizados na cena.
• Scene View: está intimamente relacionada com ahierarchy view. Os objetos de jogo dahierarchy viewsão selecionados e manipulados nascenede modo a transformarem- se no cenário do jogo.
• Game View: representa como será o seu jogo após publicado. É desenhada a partir das câmeras de seu jogo.
1NPC, ou Non Player Character, é um tipo de personagem em jogos eletrônicos que não pode ser controlado pelo jogador.
• Inspector View: mostra informações detalhadas sobre um objeto de jogo e seus componentes.
• Barra de Ferramentas: contém botões e comandos para se manipular/criar objetos de jogo e adicionar ou remover componentes.
Figura 3.8: Janela principal do motor de jogos Unity 3D
3.3.3 Prefab
O prefab é um asset modelo para criação de objetos de jogo. Isto é, corresponde a um objeto de jogo pré-configurado pelo usuário (com componentes, etc) a ser utilizado na confecção da cena. Os prefabs são construídos pelo usuário conforme sua necessidade e se encontram na project view como os demais recursos de jogo.
3.3.4 Construção de um Jogo na Unity 3D
No motor Unity 3D, um jogo corresponde a um conjunto de cenas. Uma cena pode corresponder à uma fase do jogo ou uma tela de menu, por exemplo. Somente uma cena pode ser construída por vez. A cena é um asset composto por um conjunto de objetos de jogo, os objetos de jogo da cena em edição no momento são apresentados nas regiões hierarchy escene view.
A construção de um jogo na Unity 3D consiste em criar uma cena, acrescentar os objetos de jogo desejados e adicionar comportamento/função aos objetos através de com- ponentes. Os comportamentos ou funções adicionados correspondem a lógica específica
do jogo. A engine já contém diversos componentes que podem ser utilizados, mas não é o suficiente para se construir qualquer tipo de jogo. A lógica específica do jogo é ba- sicamente desenvolvida através da construção de novos componentes, que consistem em scripts, nas linguagens Boo, UnityScript ou C#. Estes scripts, obrigatoriamente devem herdar da classe abstrata MonoBehaviour.
O fluxo de trabalho na Unity 3D consiste em operações de arrastar e soltar com o mouse. Por exemplo, para adicionar uma textura (naproject view) em um objeto de jogo na cena, basta arrastar a textura para cima do objeto de jogo na hierachy ouscene view.
O mesmo mecanismo pode ser utilizado para adicionar um componente criado através de um script ou para adicionar um objeto de jogo baseado em um prefab na cena.
Capítulo 4 Bonsai
Os motores de jogos conquistaram um importante espaço no processo de desenvolvi- mento de jogos eletrônicos de modo que, atualmente com uma mesma engine são cons- truídos diversos jogos diferentes em um menor intervalo de tempo. Analisando superfici- almente, o que diferencia um jogo de outro são seus modelos, texturas, arquivos de áudio, scripts e como o motor é configurado para trabalhar com estes objetos.
Apesar dos motores de jogos agilizarem o processo de criação de jogos eletrônicos, todos os recursos (ou assets), incluindo o código específico do jogo, ainda devem ser desenvolvidos. O desenvolvimento do código específico requer conhecimentos sólidos em codificação de programas, e muitas vezes abrangem áreas da ciência da computação como inteligência artificial, análise de algoritmos, etc. O foco deste trabalho é o desenvolvimento de um plugin, denominado Bonsai, que tem como objetivo facilitar e agilizar o processo de desenvolvimento da lógica específica de jogos eletrônicos no motor Unity 3D.
Na Seção 4.1 tem-se uma visão geral sobre o plugin, as Seções 4.2, 4.3 e 4.4 pos- suem detalhes de projeto da Bonsai. A interface do plugin é apresentada na Seção 4.5.
A Seção 4.6 mostra a correlação semântica que a Bonsai possui com as linguagens de programação de alto nível. Por fim, a Seção 4.7 apresenta a implementação do plugin.
4.1 Visão Geral
A Bonsai é um plugin para o motor de jogos Unity 3D que se enquadra na categoria devisual scripting, isto é, possibilita o desenvolvimento da lógica do jogo de forma visual, sem necessidade de codificação de programas. Existem diversas outras ferramentas para este fim, porém observa-se que a visualização e semântica destas ferramentas são prejudi- cadas dependendo do tipo de comportamento e/ou da metodologia de tomada de decisão adotada.
Dentre as metodologias presentes na Seção3.2, a árvore de comportamento se destaca por sua relação com linguagens de programação e modularização de comportamentos em sub-árvores. A relação com linguagens de programação é interessante do ponto de vista semântico, uma vez que possibilita a construção de estruturas com mesma semântica que instruções presentes em linguagens de programação. A modularização do comportamento em sub-árvores, por sua vez, facilita a visualização de comportamentos complexos.
O desenvolvimento da Bonsai é inspirado na relação semântica entre as árvores de comportamento e as linguagens de programação. O conceito base do plugin é o desen-
volvimento de uma abstração de linguagens de programação. A lógica é confeccionada sem necessidade de codificar programas, permitindo que não-programadores (como game designers, por exemplo) possam utilizá-la, sem que se perca a expressividade presente nas linguagens de programação.
A Bonsai fornece uma abstração visual para linguagens de programação de alto nível.
O fluxo de trabalho, do ponto de vista do usuário, é similar à tarefa de organizar uma estrutura de diretórios em sistemas operacionais modernos. A lógica do jogo é construída com simples ações como navegar por menus e arrastar objetos.
4.2 Componente Bonsai
No plugin Bonsai a lógica de um objeto de jogo é representada por uma árvore de comportamento. As árvores de comportamento são associadas a objetos de jogo através do componente Bonsai, cuja principal função é armazenar e executar uma árvore de comportamento.
O componente Bonsai corresponde a um script desenvolvido na linguagem C# que herda diretamente do componente MonoBehaviour. Os principais atributos do compo- nente Bonsai são:
• Name: nome do componente.
• Root: referência para a raiz da árvore de comportamento.
• CurrentFunction: indica qual o tipo de evento originou a execução da árvore.
Um componente Bonsai só pode armarzenar uma única árvore de comportamento por vez. Entretanto, um mesmo objeto de jogo pode possuir mais de um componente Bonsai e, consequentemente, mais de uma árvore de comportamento.
4.3 Behaviours ou Nós
Cada árvore adiciona um comportamento ou função a um objeto de jogo. Uma árvore de comportamento é formada por nós, também chamados de behaviours. Cada nó é independente e possui uma função específica. Estes nós são combinados através de uma relação de pai e filho para formar uma árvore.
Umbehaviour corresponde a umscript que herda da classeBonsaiBehaviour. Existem diversos tipos de behaviours, sendo os principais: CompositeBehaviour,DecoratorBehavi- our, FunctionBehaviour, BoxBehaviour e PrefabTask. As classes CompositeBehaviour e DecoratorBehaviour não possuem um comportamento definido, estes tipos apenas adici- onam, respectivamente, as funcionalidades de nós do tipo tarefa de combinação e decora- dores.
Apesar das árvores de comportamento possuírem estruturas com mesma semântica que estruturas de condição e repetição presentes em linguagens de programação, elas não possuem um mecanismo que se assemelhe, semanticamente, as funções ou variáveis de linguagens de programação. Os nós do tipo FunctionBehaviour e BoxBehaviour são ex- tensões à árvore de comportamento que adicionam funcionalidades semelhantes às funções e variáveis, respectivamente, de linguagens de programação.
4.3.1 FunctionBehaviour ou Funções
Na Bonsai, a execução da árvore é associada a um evento. Este evento pode corres- ponder a um evento nativo do motor (atualização de quadro, detecção de colisão, etc) ou iniciado por um outro nó da árvore. Um nó do tipo decorador identifica este evento em execução para decidir se continua ou não a execução de seus filhos. Os nós que pos- suem tal tarefa pertencem a uma classe especial chamada de FunctionBehaviour. Estes nós agrupam um conjunto de nós em uma sub-árvore. Este comportamento é similar aos de funções em linguagens de programação, estas por sua vez agrupam um conjunto de instruções em blocos.
A Figura 4.1 mostra três nós do tipo FunctionBehaviour: Update, OnTriggerEnter e Restart. Os nós Update e OnTriggerEnter estão relacionados com eventos do compo- nente MonoBehaviour. O nó Restart é uma função customizável relacionada a um evento disparado por um outro nó.
Figura 4.1: Nós Update, OnTriggerEnter e Restart, do tipo FunctionBehaviour
4.3.2 BoxBehaviour ou Variáveis
As árvores de comportamento não possuem um mecanismo explícito de comunicação entre seus nós, ou seja, isto geralmente é feito através de relações diretas, gerando aco- plamento e dificultando o reuso de nós. Uma solução para este problema é o uso de uma abstração do tipoblackboard [21]. Entretanto, apesar desta abstração centralizar as variá- veis e não gerar acoplamento entre os nós, dificulta o desenvolvimento de um mecanismo para definir o escopo de uma variável.
A Bonsai possui uma classe de nós decoradores do tipoBoxBehaviour, também deno- minados de box. Estes nós não possuem código de execução, sua função é armazenar uma determinada informação. Somente os filhos destes nós podem ter acesso (ler ou escrever) aos seus dados. Possibilitando um mecanismo que define um escopo para estes nós.
A Bonsai contém nove tipos básicos de BoxBehaviour: BoolBox, FloatBox, Game- ObjectBox, IntBox, ObjectBox, QuaternionBox, RectBox, StringBox e Vector3Box. Estes tipos básicos armazenam respectivamente os valores: booleanos, ponto flutuante, referên- cias a objetos de jogo, inteiros, objetos (texturas, arquivos de música, etc), quaternion,
