of 41 /41
UNIVERSIDADE FEDERAL DE SANTA CATARINA DESENVOLVIMENTO DE UM MOTOR PARA JOGOS 2D Ewerton Conceição Florianópolis - Santa Catarina 15 de maio de 2012 UNIVERSIDADE FEDERAL DE SANTA CATARINA

DESENVOLVIMENTO DE UM MOTOR PARA JOGOS 2Dprojetos.inf.ufsc.br/arquivos_projetos/projeto_1180...3D, Torque 3D e RPG Maker. No entanto, nenhum motor é adotado como padrão para desenvolvimento

  • Author
    voliem

  • View
    217

  • Download
    2

Embed Size (px)

Text of DESENVOLVIMENTO DE UM MOTOR PARA JOGOS 2Dprojetos.inf.ufsc.br/arquivos_projetos/projeto_1180...3D,...

  • UNIVERSIDADE FEDERAL DE SANTA CATARINA

    DESENVOLVIMENTO DE UM MOTOR PARA JOGOS 2D

    Ewerton Conceio

    Florianpolis - Santa Catarina

    15 de maio de 2012

    UNIVERSIDADE FEDERAL DE SANTA CATARINA

  • 1

    DEPARTAMENTO DE INFORMTICA E ESTATSTICA

    CURSO DE CINCIAS DA COMPUTAO

    DESENVOLVIMENTO DE UM MOTOR PARA JOGOS 2D

    Ewerton Conceio

    Trabalho de Concluso de Curso apresentado como parte

    dos requisitos para a obteno do grau de Bacharel em

    Cincias da Computao.

    Florianpolis - Santa Catarina

    15 de maio de 2012

    Ewerton Conceio

  • 2

    DESENVOLVIMENTO DE UM MOTOR PARA JOGOS 2D

    Trabalho de Concluso de Curso apresentado como parte dos requisitos para a

    obteno do grau de Bacharel em Cincias da Computao.

    Orientador: Prof. Raul Sidnei Wazlawick

    Banca Examinadora

    Prof. Antnio Carlos Mariani

    Prof. Mauro Roisenberg

  • 3

    Sumrio

    Lista de Figuras

    Lista de Acrnimos

    Resumo

    Abstract

    1 Introduo ........................................................................................................... 9

    1.1 Objetivos ............................................................................................................................... 10

    1.1.1 Objetivo Geral ...................................................................................................................... 10

    1.1.2 Objetivos Especficos ............................................................................................................ 10

    1.2 Metodologia .......................................................................................................................... 10

    1.3 Organizao do Trabalho ...................................................................................................... 11

    2 Fundamentos .................................................................................................... 12

    2.1 Estilos de Jogos ...................................................................................................................... 12

    2.2 Funcionamento Bsico de um Jogo ....................................................................................... 12

    2.3 Organizao das Entidades do Jogo ...................................................................................... 13

    3 Mdulo de Desenho .......................................................................................... 18

    3.1 Posicionando os Objetos no Mapa ........................................................................................ 18

    3.2 Animaes ............................................................................................................................. 19

    4 Mdulo de Fsica ............................................................................................... 22

    4.1 Deteco de Coliso a Posteriori ........................................................................................... 22

    4.2 Deteco de Coliso a Priori .................................................................................................. 23

    4.3 Etapas da deteco de coliso .............................................................................................. 23

    4.3.1 Etapa Ampla .................................................................................................................. 23

    4.3.2 Etapa Especfica ............................................................................................................. 24

    4.4 Coerncia Temporal e Coerncia Espacial ............................................................................ 24

    4.5 Tcnicas de Particionamento do Espao ............................................................................... 25

    4.5.1 Quadtree ....................................................................................................................... 25

    4.6 Implementao da Deteco de Colises no Motor ............................................................. 26

    4.7 Implementao do Tratamento de Colises ......................................................................... 26

    4.8 Implementao da Simulao de Fsica ................................................................................ 27

    5 Mdulo de udio ............................................................................................... 29

    6 Mdulo de Inteligncia Artificial ...................................................................... 31

  • 4

    6.1 Comportamento de Agentes Baseado em Objetivos ............................................................ 31

    6.1.1 Definies ...................................................................................................................... 31

    6.1.2 Uso e Implementao ................................................................................................... 32

    6.2 Lgica Difusa.......................................................................................................................... 35

    6.2.1 Definies ...................................................................................................................... 35

    6.2.2 Uso e Implementao ................................................................................................... 35

    7 Consideraes Finais ....................................................................................... 39

    8 Referncias Bibliogrficas ............................................................................... 40

  • 5

    Lista de Figuras

    Figura 2.1 Hierarquia orientada a objetos ................................................................. 14

    Figura 3.1 Arquivo texto, contendo as posies dos tiles no mapa ........................... 18

    Figura 3.2 Mapa de tiles carregado ........................................................................... 19

    Figura 3.3 Sprite usada para fazer o Bomberman andar .......................................... 19

    Figura 3.4 Principais classes envolvidas em uma animao .................................... 20

    Figura 4.1 Volumes envolventes (Kimmerle, 2005) ................................................... 24

    Figura 4.2 Quadtree com profundidade igual a 2 ...................................................... 25

    Figura 4.3 Componente de fsica .............................................................................. 28

    Figura 5.1 Diagrama de classes do mdulo de sons ................................................. 29

    Figura 6.1Diagrama de classes da tcnica de comportamento de agentes baseados

    em objetivos .............................................................................................................. 33

    Figura 6.2 Grau de desejo de se executar um objetivo ............................................. 36

    Figura 6.3 Quantidade de pontos de vida ................................................................. 36

    Figura 6.4 Distncia a um item .................................................................................. 37

  • 6

    Lista de Acrnimos

    2D Duas dimenses

    3D Trs dimenses

    AABB Axis-aligned Bounding Box

    CPU Central Processing Unit

    DOP Discrete Oriented Polytope

    IA Inteligncia Artificial

    OBB Oriented Bounding Box

    RAM Random Access Memory

    RPG Role-playing Game

    SPU Synergistic Processing Unit

  • 7

    RESUMO

    No desenvolvimento de jogos eletrnicos, interessante reutilizar cdigo-fonte, para que o esforo na criao de novos jogos seja diminudo. Os motores de jogos tm esse propsito. No entanto, no h um motor adotado como padro. Neste trabalho, foi desenvolvido um motor para a famlia de jogos com jogabilidade 2D. Para isso, foram desenvolvidos pequenos jogos, verificando-se partes do cdigo-fonte que possam ser extradas para mdulos do motor e serem reutilizadas. Foram criados mdulos que tratam da parte grfica, deteco de colises, sons e inteligncia artificial. Neste trabalho, so discutidos conceitos envolvendo os mdulos citados anteriormente bem como conceitos bsicos sobre programao de jogos.

  • 8

    ABSTRACT

    In the development of electronic games, it is interesting to reuse source code, so that the effort to create new games is reduced. The game engines have this purpose. However, there is no standard engine. In this work, it was developed an engine for the family of games with 2D gameplay. Thus, it was developed small games, verifying parts of the source code that can be extracted for modules of the engine and reuse. Modules were created that deal with graphics, collision checking, sound and artificial intelligence. In this work, it is discussed concepts involving the modules mentioned above as well as basic concepts of game programming.

  • 9

    1 Introduo

    Simplesmente mentalizando o termo genrico jogo, podemos pensar em

    vrios tipos de jogos, como jogos de cartas, esportes e jogos eletrnicos. Quando

    usado no contexto de jogos eletrnicos, normalmente o termo jogo vem associado a

    mundos 2D ou 3D, contendo um humano, um animal ou um veculo como

    personagem principal sob controle de um jogador (Gregory, 2009).

    Segundo (Sanches, 2009) um jogo um aplicativo multimdia que funciona

    em tempo real, provendo uma resposta da forma mais rpida possvel ao jogador.

    Este tem a impresso que o jogo avana como um filme ou uma cena da vida real,

    apesar de, na prtica, o funcionamento ser diferente.

    O termo motor de jogos comeou a ser usado na dcada de 1990, fazendo

    referncia uma conexo com alguns jogos 3D, como de tiro em primeira pessoa,

    como o conhecido Doom, da empresa id Software. A arquitetura do jogo Doom tinha

    uma separao bem definida entre os componentes principais do software (como

    sistema de renderizao de grficos 3D, sistema de deteco de coliso, sistema de

    udio) e as artes, os mundos, e as regras do jogo (Gregory, 2009).

    O valor dessa separao se tornou evidente quando os desenvolvedores

    notaram que bastaria criar novas armas, cenrios e personagens sem precisar fazer

    grandes modificaes no motor do jogo. Assim, grande parte do cdigo-fonte de um

    jogo poderia ser utilizado novamente em vrios outros, como bibliotecas para vrios

    mdulos, fazendo com que o trabalho dos desenvolvedores de jogos fosse

    diminudo.

    Como durante a criao dos primeiros jogos eletrnicos da histria existiam

    muitas limitaes de hardware, o cdigo-fonte tinha que ser muito bem otimizado.

    No havia separao entre partes do jogo, como parte grfica e parte fsica.

    Hoje em dia, existem vrios motores para jogos. Alguns disponibilizam uma

    biblioteca de classes, outros um editor que permite construir um jogo a partir de uma

    interface grfica, e tambm existem os que disponibilizam as duas formas. Como

    exemplo de motores de jogos, podemos citar: Unreal Engine 3, CryENGINE 3, Unity

    3D, Torque 3D e RPG Maker.

    No entanto, nenhum motor adotado como padro para desenvolvimento de

    jogos. Geralmente, ou escolhido um motor que seja fcil de usar, do ponto de vista

  • 10

    dos desenvolvedores, e que atenda aos requisitos do jogo que se quer fazer ou cria-

    se um novo motor, muitas vezes sendo responsvel por apenas um mdulo do jogo,

    como um mdulo de fsica, por exemplo.

    1.1 Objetivos

    Procurando limitar e tambm nortear o escopo do trabalho, foram definidos

    objetivos para o desenvolvimento do motor. Esses objetivos sero apresentados a

    seguir, de forma geral e especfica.

    1.1.1 Objetivo Geral

    Desenvolver um motor para jogos 2D, contendo uma biblioteca multiplataforma

    desenvolvida em C++ que facilite a criao de jogos.

    1.1.2 Objetivos Especficos

    1. Desenvolver uma biblioteca que deve conter mdulos que tratem da parte

    grfica, de deteco de colises, de sons e de inteligncia artificial;

    2. Comparar tcnicas de deteco de coliso em duas dimenses para

    otimizar o detector de colises;

    3. A biblioteca deve poder ser usada tanto para criar jogos com jogabilidade

    em perspectiva top-down, como para a jogabilidade com rolagem lateral;

    4. Verificar na prtica os desafios envolvidos na criao de um motor de

    jogos.

    1.2 Metodologia

    Cada famlia de jogos tem certos requisitos especficos que, muitas vezes, s

    so descobertos desenvolvendo pequenos prottipos. Alguns requisitos so comuns

    a alguns tipos de jogos, como deteco de coliso e animaes, podendo ser

    diferente a forma como deve ser implementado (coliso em 2D e em 3D, por

    exemplo).

  • 11

    Um problema na criao de motores de jogos tentar fazer o maior motor

    possvel. No artigo Starting out on Game Programming do site Lazy Foo

    Productions, o autor conta que queria fazer uma IA para um jogo da velha que fosse

    imbatvel. Ele a fez de uma forma que pudesse vencer cada armadilha possvel.

    Para isso, ele precisou de quarenta mil linhas de cdigo, sendo que a maioria do

    cdigo foi copiado e colado, gastando um ms do seu tempo. Depois que ele

    descobriu o algoritmo Minimax, viu que poderia ter feito de uma forma melhor e com

    muito menos cdigo.

    Considerando o problema acima, o desenvolvimento do motor foi feito com

    base em prottipos, que so pequenos jogos. Desses jogos, foram retirados os

    requisitos do motor. Partes de cdigo que podem reusadas em outros jogos

    ajudaram a compor os mdulos do motor. O cdigo foi escrito de forma que fosse

    flexvel e sem adicionar coisas desnecessrias, at o momento em que realmente

    seja preciso adicion-las.

    1.3 Organizao do Trabalho

    O captulo 2 fala sobre fundamentos dos jogos. O captulo 3 mostra como foi

    feito o mdulo de desenho e detalha conceitos sobre animaes. O captulo 4 trata

    do mdulo de fsica e explica a deteco de colises. O captulo 5 expe o mdulo

    de udio. O captulo 6 fala sobre o mdulo de IA. O captulo 7 mostra as

    consideraes finais.

  • 12

    2 Fundamentos

    2.1 Estilos de Jogos

    Existem vrios estilos de jogos. De acordo com (Fernandes, 2002), alguns

    deles so:

    Estratgia em tempo real: normalmente so jogos de batalha, em que o

    jogador comanda exrcitos, suprimentos, acampamentos e recursos para

    superar grupos adversrios, como acontece no popular Age of Empires;

    Estratgia baseada em turnos: as batalhas ocorrem em tempos

    espaados para que as aes sejam realizadas, o que nos d tempo para

    pensar, mas no diminui a ao. Tornaram-se populares com o

    surgimento dos RPGs;

    Tiro em primeira pessoa: o jogador controla um personagem, que pode

    ser um soldado, por exemplo, e pode usar diversos tipos de armas para

    matar os inimigos, como no jogo Battlefield;

    Plataformas: conta com rolagem lateral, em que o personagem principal

    passa por fases, podendo encontrar um chefe final em cada fase. Como

    exemplo podemos citar vrios jogos da franquia Super Mario;

    Simulao: so jogos que imitam a realidade, simulando corridas de

    carros, futebol, voo, entre outros;

    RPGs: so jogos que podem conter um ou mais de outros estilos citados

    acima. Sua principal caracterstica est no fato de os personagens

    possurem um nvel, que aumenta conforme vo ganhando experincia.

    Como exemplo, podemos citar jogos da franquia Final Fantasy.

    2.2 Funcionamento Bsico de um Jogo

    Para que um jogador tenha a sensao de que o jogo est fluindo

    naturalmente, o processamento dos comandos do jogador, da lgica do jogo e a

    atualizao da tela tem que ser feitos de forma rpida e sincronizada. Para fazer

    isso, um jogo possui o loop principal, responsvel pela atualizao do jogo, seguindo

    os quatro passos abaixo:

  • 13

    1. Ler entradas do mouse e teclado;

    2. Atualizar os objetos do jogo;

    3. Desenhar a cena a partir dos objetos atualizados;

    4. Voltar para o passo 1 caso o jogo no tenha sido finalizado.

    O jogo atualizado de forma discreta e a velocidade de atualizao dos

    objetos fixa, de acordo com a taxa de quadro por segundo informada. Devido aos

    monitores trabalharem, normalmente, com uma taxa de atualizao de 60 quadros

    por segundo, comum essa taxa ser usada para atualizar um jogo. Se a taxa de

    atualizao for maior que o suportado pelo monitor, alguns quadros sero

    descartados, mesmo tendo feito todo o processamento necessrio para ger-los.

    Por isso, interessante limitar a taxa de atualizao, diminuindo o consumo de CPU

    nos jogos em que se poderia ter uma taxa maior.

    2.3 Organizao das Entidades do Jogo

    Cada jogo possui diferentes tipos de entidades, cada uma responsvel por

    certas tarefas. Normalmente, as entidades so visveis ao jogador, ocupando algum

    lugar no mundo e algumas podem se locomover. Pensando num jogo de aventura,

    podemos imaginar algumas possveis entidades:

    Heri;

    Inimigo;

    Espada;

    Arma de fogo;

    Carro;

    Submarino;

    Barco.

    A forma tradicional de representar as entidades de um jogo como esse fazer

    uma decomposio orientada a objetos das classes necessrias para o

    funcionamento das entidades. Isso geralmente comea com boas intenes, mas

    frequentemente modificado com o progresso de desenvolvimento do jogo,

    principalmente se um motor de jogo usado novamente para criar um jogo diferente

    (West, 2007).

  • 14

    A figura 2.1 mostra uma possvel representao de uma hierarquia orientada

    a objetos do jogo de aventura mostrado anteriormente:

    Figura 2.1 Hierarquia orientada a objetos

    Esse tipo de hierarquia, com uma profunda cadeia de heranas, tende a

    possuir uma classe na raiz e nas folhas as classes representando entidades mais

    concretas, que so, comumente, visveis ao jogador. Num jogo real, a hierarquia

    tende a ser bem mais profunda e complexa, envolvendo animaes, corpos rgidos e

    outros componentes, deixando, muitas vezes, as classes das folhas com muitos

    mtodos que foram herdados e que nunca sero chamados, ou seja, so

    funcionalidades desnecessrias que esto numa determinada classe devido

    profunda cadeia de heranas.

    Mesmo com esse exemplo simples, outro problema pode ser detectado.

    comum, nos jogos, haver uma variao grande dos requisitos, pois ideias de como

    melhorar o jogo podem surgir no meio do desenvolvimento do mesmo. Suponhamos

    que, no exemplo do jogo de aventura apresentado anteriormente, algum teve a

    ideia de criar um veculo anfbio. A hierarquia envolvendo o veculo anfbio pode ser

    vista na figura 2.2, que uma forma clssica de ilustrar um problema da herana

    mltipla, quando uma classe estende a outra duas vezes.

    Profundas hierarquias de heranas tendem a criar problemas de

    desempenho. Eles ocorrem quando for necessrio chamar o construtor de uma

  • 15

    classe derivada, tendo que invocar o construtor das classes bases, o que faz o uso

    de recursos pesados (Flynt; Salem, 2004).

    Figura 2.2 Herana Mltipla.

    Outra abordagem para representar os objetos do jogo uma agregao de

    componentes. Uma forma de fazer isso considerar uma entidade como sendo uma

    soma de componentes. Cada entidade poderia ter como componentes um corpo

    rgido para representar a sua fsica e um componente de animao para cuidar da

    sua representao visual, por exemplo. Esse um modelo simples, porm no o

    mais adequado e pode ser melhorado (Flynt; Salem, 2004).

    Para explicar melhor o modelo de componentes, o passo 2 do loop principal

    ser detalhado agora. Primeiro, consideremos que o jogo possui um conjunto de

    entidades, cada uma com seus componentes. O jogo pode ser atualizado conforme

    o procedimento abaixo, em pseudocdigo:

    Jogo::atualizar(real tempo)

    incio

    1. Para cada e jogo.entidades faa

    a. Para cada c e.componentes

    i. c.atualizar(tempo)

    fim

  • 16

    O procedimento acima bastante simples, mas existe outra forma para usar o

    modelo de componentes e que superior primeira, a atualizao em lotes. Nesse

    modelo, ao invs das entidades atualizarem todos os seus componentes, cada

    conjunto de um dado tipo de componente deve ser atualizado de uma vez s. Uma

    classe gerenciadora pode ser criada para cada tipo de componente para realizar a

    tarefa de atualizao. Considerando que certo jogo possui apenas os componentes

    de fsica e de animao, o passo 2 do loop principal e o mtodo atualizar na classe

    que gerencia os componentes ficariam assim:

    Jogo::atualizar(real tempo)

    incio

    1. gerenteDeFsica.atualizar(tempo)

    2. gerenteDeAnimao.atualizar(tempo)

    fim

    GerenteDeComponentes::atualizar(real tempo)

    Incio

    1. Para cada c componentes

    a. c.atualizar(tempo)

    fim

    A atualizao em lotes traz vrios benefcios. De acordo com (Gregory,

    2009), alguns deles so:

    Mxima coerncia na memria cache: os dados de um subsistema do

    motor so mantidos internamente e podem ser arranjados numa regio

    nica e contgua da memria RAM, o que leva a mxima coerncia

    possvel na memria cache;

    Pipeline eficiente: recursos de hardware especializados podem ser

    usados de forma mais eficiente, ganhando mais uma otimizao. Como

    exemplo, podemos citar o Playstation 3, que possui um conjunto de

    microprocessadores de alta velocidade, chamados de SPUs, cada um

    com sua rea de memria de alta velocidade. Enquanto se processa um

    lote de animaes, a pose de um personagem pode ser calculada e, ao

    mesmo tempo, os dados do prximo personagem so acessados

    diretamente na memria da SPU. Processando cada entidade

    isoladamente no seria atingido esse nvel de paralelismo;

  • 17

    Alguns subsistemas no funcionam adequadamente isolados: uma

    soluo satisfatria para resolver se vrios corpos rgidos esto colidindo

    no pode ser achada, geralmente, se os objetos forem tratados

    isoladamente. As colises entre os objetos devem ser resolvidas em

    grupo, atravs de uma abordagem iterativa ou resolvendo um sistema de

    equaes lineares, por exemplo.

  • 18

    3 Mdulo de Desenho

    O motor de jogos desenvolvido contm um mdulo responsvel por desenhar

    os objetos visveis ao jogador e tambm realizar animaes. Para tornar o mdulo

    de desenho mais completo, foi usada a biblioteca Guichan, que contm

    componentes mais bsicos de desenho como reas de texto, rtulos, botes, entre

    outros.

    3.1 Posicionando os Objetos no Mapa

    Nos jogos 2D, duas formas comuns de jogabilidade so a rolagem lateral e a

    perspectiva top-down. Na primeira, a cmera fica posicionada lateralmente e os

    personagens se movem de um lado para o outro. Na segunda, tambm conhecida

    como birds-eye view, a cmera mostra o jogador e a rea em torno dele vistos de

    cima. Para que se atenda a essas duas formas de jogabilidade, os objetos que

    podem ser desenhados possuem como posio um ponto no mundo.

    Outra forma possvel para representar a posio dos objetos usar um mapa

    de tiles. Segundo (Fernandes, 2001), um tile um desenho pequeno, que se

    caracteriza por ser sequencial consigo mesmo. Assim, colocando-se vrios

    desenhos iguais, lado a lado, formam uma nica imagem, sem cortes. So ideais

    para representar chos, florestas ou elementos estticos de um jogo.

    Figura 3.1 Arquivo texto, contendo as posies dos tiles no mapa

    No prottipo do jogo Bomberman, foi implementado um mapa de tiles. Para

    formar um mapa de tiles, geralmente, usa-se um arquivo que mostra as posies

    dos tiles no mapa (como na figura 3.1). Cada nmero representa um tile, que ser

  • 19

    associado com uma imagem na hora de carregar o mapa. O resultado do

    carregamento de um mapa 15x13 pode ser observado na figura 3.2.

    Figura 3.2 Mapa de tiles carregado

    Por ser mais simples de gerenciar todos os objetos de desenho fazendo com

    que eles tenham uma posio no mapa, o mapa de tiles no foi includo no mdulo

    de desenho.

    3.2 Animaes

    O processo para fazer uma animao em duas dimenses simples. Pode-se

    pegar um conjunto de imagens que determinam certa movimentao e exibi-las,

    sendo que uma nova imagem exibida de acordo com a taxa de quadros por

    segundo.

    Figura 3.3 Sprite usada para fazer o Bomberman andar

    Por se tratar apenas de exibir imagens com certo atraso entre uma e outra

    exibio, esse processo pode ser facilmente automatizado para qualquer animao

    2D. S preciso definir quais so as imagens, a ordem em que sero exibidas e a

    taxa de quadros por segundo.

  • 20

    No jogo Bomberman, para fazer o personagem se movimentar usada uma

    sprite que possui as imagens da movimentao do mesmo (figura 3.3). Sprites so

    as imagens dos objetos do jogo, desenhadas em todos os seus quadros de

    animao (Fernandes, 2002). Quando so mostrados sequencialmente, do uma

    sensao de movimento. Quanto mais quadros tiver uma sprite, mais perfeito fica o

    movimento.

    Figura 3.4 Principais classes envolvidas em uma animao

    O mdulo de desenho armazena um conjunto de vises das entidades do

    jogo. Cada viso pode ter vrios objetos desenhveis associados, mas apenas um

    ser exibido. Um objeto desenhvel representa o desenho uma ao do

    personagem, que pode ser andar, correr, saltar, entre outras. Cada objeto

    desenhvel pode ter um componente associado. Esse componente possui um

    mtodo update, que ser responsvel por atualizar o objeto. No caso das

  • 21

    animaes, h uma classe chamada Animation, que implementa a interface

    Component.

    A classe Animation faz uma animao sempre da esquerda para a direita. No

    entanto, caso um usurio do motor queira fazer a animao de outra maneira ou

    criar outro tipo componente, basta que implemente a interface Component do jeito

    que desejar. O diagrama da figura 3.4 d uma viso geral do mdulo de desenho.

  • 22

    4 Mdulo de Fsica

    O mdulo de fsica foi feito, principalmente, para atender ao objetivo de tratar

    colises entre corpos. Porm, em quase todos os jogos, objetos se movem ou

    realizam alguma ao em que uma simulao de fsica necessria. Assim, foi

    definida uma arquitetura que permite a criao de componentes para simular aes

    de fsica, a qual ser detalhada no final do captulo.

    Cada entidade pode possuir um corpo rgido associado, para tratar das

    aes de fsica e da deteco de coliso. Segundo (Flynt; Salem, 2004), corpos

    rgidos so interessantes de serem usados em jogos porque so perfeitamente

    slidos e no so deformveis. Isso simplifica a matemtica envolvida para simular

    os objetos.

    Aes que ocorrem em um jogo podem, normalmente, ser representadas por

    colises entre dois ou mais corpos. A deteco de colises um fator crtico nos

    jogos, devido a trs grandes problemas: o alto custo computacional, pois quando se

    precisa testar todos os objetos contra todos a complexidade O(n); objetos que

    podem mover-se muito rapidamente, como projteis, por exemplo; e objetos que

    possuem geometria complexa, como personagens (Ferreira; Ferreira, 2009). A

    seguir, sero detalhadas formas de deteco de coliso e mtodos para faz-la de

    forma eficiente.

    4.1 Deteco de Coliso a Posteriori

    A deteco de coliso a posteriori testa se a coliso j ocorreu. A cada passo

    da simulao testado se um objeto tem interseco com outro. Se tiver, h uma

    coliso. um teste discreto, pois testa apenas um momento no tempo.

    Esse teste mais comum, porm menos preciso. Um problema dele pode

    se manifestar quando dados dois corpos, pelo menos um corpo tem uma velocidade

    muito alta e pelo menos um deles seja um corpo pequeno. Dependendo da

    velocidade e do tamanho do corpo, como o teste discreto, pode acontecer de um

    corpo atravessar o outro e o teste vai falhar. A soluo para o problema acima

    usar uma restrio. A velocidade mxima de um objeto multiplicada pelo passo de

  • 23

    tempo de atualizao deve ser menor que o tamanho do menor objeto. Para garantir

    isso, deve-se reduzir a velocidade mxima ou o passo do tempo de atualizao.

    Outro problema dessa tcnica permitir sobreposies dos objetos. Quando

    uma coliso detectada, a posio dos objetos deve ser corrigida. Corrigir a posio

    dos objetos a fim de tornar a simulao real pode ser complicado. Um mtodo

    simples apenas retornar os objetos para as posies que tinham no passo de

    atualizao anterior. Esse mtodo funciona bem se os corpos no tiverem

    velocidade alta e se o intervalo de atualizao no for muito alto. Assim, apesar de

    fisicamente incorreto, o tratamento de coliso imperceptvel ao jogador, pois a

    posio anterior dos corpos vai ser muito prxima da posio atual.

    4.2 Deteco de Coliso a Priori

    Uma tcnica de deteco de coliso a priori prev quando uma coliso vai

    ocorrer. Com uma tcnica a priori, a simulao avanada at o tempo em que a

    coliso vai ocorrer, impedindo que os objetos se sobreponham. Ela mais realista e

    resolve os problemas das tcnicas a posteriori, no entanto tem implementao mais

    complexa e, geralmente, usada em jogos em que no se pode ter uma restrio de

    velocidade ou do passo mximo do tempo de atualizao.

    4.3 Etapas da deteco de coliso

    Normalmente, as tcnicas de deteco de coliso de dividem em duas

    etapas. Numa etapa inicial, os objetos so testados aos pares com um mtodo

    menos preciso, determinando se h uma chance de estarem colidindo. A segunda

    etapa pega os pares da etapa inicial e testa, usando um algoritmo preciso, se h

    coliso. As duas etapas sero detalhadas a seguir.

    4.3.1 Etapa Ampla

    Como foi dito anteriormente, nesta etapa usado um mtodo menos preciso.

    Podem ser usados volumes envolventes para otimizar o teste. A figura 4.1 mostra

    tipos de volumes envolventes. Quanto mais para a direita, mais precisa a

    aproximao, porm os custos de atualizao, de construo e de realizao do

  • 24

    teste de coliso se tornam maiores. Quanto menor a preciso do teste, maior a

    chance dele retornar falsos positivos, porm nos casos em que os volumes

    envolventes dos objetos no colidem nessa etapa no preciso usar o teste com

    preciso mxima. a que est o grande benefcio dessa etapa, que no gastar

    tempo usando um teste totalmente preciso (que computacionalmente caro)

    verificando se h coliso com objetos que esto muito distantes entre si.

    Figura 4.1 Volumes envolventes (Kimmerle, 2005)

    4.3.2 Etapa Especfica

    A etapa especfica recebe os pares candidatos a estarem colidindo obtidos

    na etapa ampla. Nessa etapa, usado um algoritmo preciso para verificar se os

    objetos esto realmente colidindo. Aqui, dependendo da forma do objeto, um teste

    computacionalmente caro pode ser necessrio, mas considerando que o nmero de

    pares testados ser muito menor do que a complexidade O(n), possvel usar o

    teste sem causar um grande impacto negativo na fluncia do jogo.

    4.4 Coerncia Temporal e Coerncia Espacial

    Uma tcnica de deteco de coliso que leve em considerao a coerncia

    espacial vai buscar melhorias de desempenho a partir do princpio de que objetos

    distantes entre si no colidem, logo o nmero de pares de objetos colidindo num

    certo instante de tempo tende a ser menor do que o mximo de colises possveis.

    J a coerncia espacial leva em conta que os objetos se movem relativamente

    pouco entre os perodos de atualizao. Dessa forma, um objeto que est colidindo

    tende a estar colidindo na prxima atualizao e os que no estavam tendem a no

    estar (Rocha, 2010).

  • 25

    4.5 Tcnicas de Particionamento do Espao

    A fim de tirar proveito da coerncia espacial, o espao pode ser particionado

    em vrias clulas. Ele dividido recursivamente para se criar uma estrutura

    hierrquica que minimize a quantidade de testes. Consequentemente, s

    necessrio aplicar o teste de coliso numa mesma clula (Ferreira; Ferreira, 2009).

    Vrias so as formas de particionamento do espao. Entre elas, podemos destacar

    octrees, rvores BSP, kd-tree e rvores esfricas (Gregory, 2009).

    Dividir um espao em quadrantes uma forma de particionar o espao. Num

    mundo 3D, se usaria uma octree, num mundo 2D uma quadtree. Como o escopo

    deste trabalho se limita a ambientes 2D, a tcnica de quadtree ser abordada a

    seguir.

    4.5.1 Quadtree

    O termo quadtree comumente usado para se referir a uma classe de

    estruturas hierrquicas com uma propriedade em comum, que a decomposio

    recursiva do espao (Ferreira; Ferreira, 2009). Elas usam o conceito de estrutura de

    dados em rvore, sendo que cada nodo pode ter at quatro filhos, dependendo da

    implementao. Existem variaes de quadtree em que cada nodo tem exatamente

    quatro filhos, com exceo das folhas da rvore.

    Figura 4.2 Quadtree com profundidade igual a 2

    Uma quadtree divide o espao em quatro partes iguais, recursivamente, at

    que se alcance o tamanho desejado. A figura 4.2 mostra uma quadtree com

    profundidade igual a dois. Os objetos so adicionados no quadrante em que

  • 26

    estiverem contidos. Se um objeto for maior que o menor quadrante da quadtree,

    tenta-se coloc-lo num nodo pai que o contenha. A nica exceo o nodo raiz, em

    que basta que ele tenha interseco com objeto, evitando que o mesmo fique fora

    do espao.

    Alm da coerncia espacial, esta estrutura tambm tira proveito da coerncia

    temporal, pois como os objetos tendem a estar prximos das suas posies atuais

    nas atualizaes seguintes, a atualizao dos objetos na quadtree facilitada,

    bastando perguntar se o objeto est contido no nodo atual. Apenas se ele no

    estiver contido ter de ser removido e colocado em outro nodo, o que uma

    operao custosa, se tiver de ser aplicada em muitos objetos a cada atualizao.

    4.6 Implementao da Deteco de Colises no Motor

    A gerncia da fsica feita pelo gerente de fsica. Ele possui uma instncia

    do mundo e este ltimo contm um espao. O espao est representado na forma

    de uma interface que contm mtodos para adicionar, remover e atualizar corpos

    rgidos e obter os objetos que esto em estado de coliso. Dessa forma, uma

    tcnica a priori ou a posteriori pode ser anexada ao mdulo de fsica, simplesmente

    implementando a interface Space.

    Foram implementados dois espaos, ambos usando-se de tcnicas a

    posteriori: um genrico, que tem de fazer n testes (considerando n o nmero de

    corpos) para saber se os corpos esto colidindo, com a nica melhoria de possuir

    uma etapa ampla e uma especfica; e outro que representa uma quadtree, conforme

    foi descrita na seo 4.5 e considerando cada nodo sempre com quatro filhos, com

    exceo das folhas.

    4.7 Implementao do Tratamento de Colises

    Quando colises ocorrem nos jogos, provvel que algo acontea com as

    entidades envolvidas na coliso. Se um personagem colidiu com uma flecha,

    possivelmente ele deve perder certa quantidade de vida, dependendo do jogo. Se

    um personagem empurrou uma pedra de um penhasco, ela pode receber a fora

    aplicada pelo personagem e, de acordo com sua massa, ganhar certa acelerao e

  • 27

    comear a se mover. Logo, as entidades envolvidas nas colises devem ser

    avisadas para que certas aes sejam tomadas.

    Para fazer isso, o mundo recebe todas as colises calculadas pelo seu

    espao e avisa ao gerente de entidades que uma coliso ocorreu. Foi permitido que

    um corpo rgido no pertencesse a uma entidade, sendo usado apenas no mdulo

    de fsica. O gerente de entidades verifica se os dois corpos rgidos envolvidos numa

    coliso pertencem a uma entidade. Se ambos so parte de entidades, elas so

    avisadas que a coliso ocorreu, atravs do envio de uma mensagem, feito pelo

    gerente de mensagens, e tomam as aes que forem necessrias, inclusive se

    forem apenas aes fsicas, como no caso de empurrar uma pedra, citado

    anteriormente. Se apenas um dos corpos pertencer a uma entidade, a entidade

    avisada sobre com qual corpo ela colidiu. Se ambos os corpos no pertencerem a

    uma entidade, apenas tratada a sobreposio dos corpos, no caso de se fazer uso

    de uma tcnica a posteriori.

    4.8 Implementao da Simulao de Fsica

    Apesar do foco do motor de fsica neste trabalho ser a deteco de colises,

    comum que jogos possuam elementos que se encaixem numa simulao de fsica.

    Para se adequar a essa exigncia dos jogos, foi implementada uma estrutura que

    permite que aes fsicas, como simulao de movimentos dos corpos, fossem

    representadas.

    Foi criada uma classe abstrata a qual representa um componente de fsica

    que pode ser especializado em alguma ao de fsica sobre certo conjunto de

    objetos do jogo. Uma ao fsica que foi predefinida no mdulo de fsica foi um

    movimento.

    H uma classe chamada Movable que estende o componente de fsica e

    possui uma instncia de uma classe que implemente a interface Motion, que

    representa um movimento. No mtodo update da classe Movable, todos os corpos

    rgidos que possuam um mesmo tipo de movimento tero suas posies atualizadas,

    a cada quadro do jogo. A figura 4.3 mostra o diagrama de classes para o

    componente Movable.

  • 28

    Figura 4.3 Componente de fsica

  • 29

    5 Mdulo de udio

    O mdulo de udio foi implementado usando a biblioteca SDL_Mixer. Seu

    uso bastante simples, sendo que o usurio precisa conhecer alguns conceitos

    sobre udio, para que possa saber como passar os parmetros de inicializao. Os

    parmetros so detalhados a seguir:

    Figura 5.1 Diagrama de classes do mdulo de sons

    Frequncia: frequncia de sada das amostras, em Hertz. Segundo a prpria

    documentao da biblioteca, o valor de 22050 Hz adequado para jogos,

    embora se possa querer outro valor, como 44100 Hz, que d a qualidade de

    CD ao som, mas que exige muito mais poder de processamento;

  • 30

    Formato: define a quantidade de bits de sada das amostras de som. So

    permitidos os formatos de 8 bits e 16 bits;

    Canais: define a quantidade de canais da sada de som, sendo que 2 canais

    fazem o som ser estreo e 1 faz o som ser mono;

    Tamanho do buffer: tamanho de cada amostra mixada, em bytes. Deixando

    este valor muito pequeno, o som poder ter cortes. Se for grande demais, o

    som poder ter atrasos. 1024 bytes costuma ser um bom valor quando muitos

    sons precisarem ser mixados;

    Canais de mixagem: define a quantidade de canais usados para a mixagem.

    Quanto mais canais, mais processamento ser preciso para mixar todos os

    sons.

    Para carregar um som basta instanciar um objeto da classe Sound,

    informando o nome do arquivo que contm o som. O gerente de udio vai carregar o

    som, se o mesmo ainda no tiver sido carregado. Isso impede que o mesmo som

    seja carregado vrias vezes. A classe Sound contm mtodos para tocar um som,

    pausar um som, continuar um som, parar um som e tambm definir o volume de um

    som. A figura 6.1 mostra o diagrama de classes do mdulo de som.

  • 31

    6 Mdulo de Inteligncia Artificial

    O projeto da parte de inteligncia artificial de um jogo um ponto delicado.

    Um jogo com uma IA que sempre vence vai deixar o jogador frustrado. Porm, se o

    jogador sempre vencer facilmente, o jogo perder a graa logo. Para (Buckland,

    2005), a IA de um jogo deve entreter o jogador, oferecendo boas batalhas, fazendo

    com que o jogador vena mais vezes do que a mquina e sinta-se poderoso, astuto,

    inteligente e esperto.

    As aes de cada personagem podem ser bem especficas de acordo com

    cada jogo, tornando-se difceis de serem reusadas. Foram isolados, para compor o

    mdulo de IA, duas tcnicas que podem ser usadas para simular a inteligncia de

    um personagem. Uma a de comportamento de agentes baseado em objetivos e

    outra lgica difusa. Ambas as tcnicas sero detalhadas a seguir, bem como suas

    respectivas implementaes no mdulo de IA.

    6.1 Comportamento de Agentes Baseado em Objetivos

    6.1.1 Definies

    No h um consenso na definio do que um agente. (Wooldridge, 2002)

    define um agente como um sistema computacional situado em um ambiente e que

    capaz de realizar aes autnomas nesse ambiente a fim de atingir seus objetivos.

    Outra definio, que muitos pesquisadores de agentes consideram aceitvel,

    conforme (Bradshaw, 1997), diz que um agente uma entidade de software, que

    funciona de forma autnoma e contnua em um determinado ambiente, o qual pode

    conter outros agentes, e que seja capaz de interferir no seu ambiente de uma

    maneira flexvel e inteligente, sem precisar de orientao humana constante.

    O comportamento dos agentes pode ser definido por uma coleo de

    objetivos hierrquicos, que podem ser compostos ou atmicos. Um objetivo atmico

    a representao de uma tarefa, ao, ou comportamento simples, enquanto que

    um objetivo composto representa uma tarefa mais complexa e feito de vrios

    outros objetivos, que por sua vez podem ser compostos ou atmicos, definindo uma

  • 32

    hierarquia aninhada. Alm disso, os objetivos devem ter a capacidade de monitorar

    seu estado e fazer um replanejamento caso falhem (Buckland, 2005).

    Um agente com comportamento dirigido por objetivos tenta imitar o

    comportamento humano, examinando estratgias de alto nvel (objetivos compostos)

    e selecionando a que mais se adequar a certa situao. No caso dos jogos, um

    personagem pode possuir uma srie de objetivos, sendo que ele vai selecionar o

    que for mais desejvel para ele, baseado no estado atual do jogo. Normalmente,

    ser mais desejvel implica em vencer o jogo. O objetivo de alto nvel escolhido ser

    decomposto em outros, que sero satisfeitos um de cada vez. O objetivo pode falhar

    ou pode ser satisfeito e o estado do jogo pode mudar. Tais acontecimentos podem

    fazer o personagem repensar seus objetivos e alterar sua estratgia.

    6.1.2 Uso e Implementao

    A figura 6.1 mostra o diagrama de classes para a tcnica de comportamento

    de agentes baseados em objetivos que foi implementada no mdulo de IA. Um

    objetivo composto pode ser criado especializando a classe CompositeGoal. Criar um

    objetivo atmico feito simplesmente especializando a classe Goal. Cada objetivo

    contm um mtodo abstrato para obter o quo desejvel de ele ser ativado num

    dado momento do jogo. A escolha de qual objetivo ativar feita pela classe Brain.

    Cada entidade que deseja ter seu comportamento dirigido por objetivos deve criar e

    adicionar uma instncia da classe Brain ao gerente de IA, que quando atualizado

    pedir a todos os crebros das entidades para que faam a seleo do melhor

    objetivo a ser perseguido e o execute.

    A forma do clculo do quo desejvel um objetivo ser executado um

    ponto chave na definio dos objetivos. interessante que todos os valores do

    desejo de executar um objetivo estejam padronizados num intervalo, por exemplo,

    de 0 a 1, assim como os valores necessrios para calcular o desejo. Dessa forma a

    comparao entre os valores fica facilitada (Buckland, 2005).

    Um exemplo ser dado para mostrar o funcionamento da escolha dos

    objetivos, considerando um jogo de aventura em que guerreiros lutam entre si para

    ver quem o mais forte. O intervalo de possveis valores para o desejo de se

    executar um objetivo ser [0,1]. Os guerreiros possuem duas armas: uma espada e

    um arco-e-flecha. Eles possuem tambm uma quantidade de pontos de vida e uma

  • 33

    quantidade de flechas. No cenrio, podem surgir itens que aumentam a quantidade

    de pontos de vida ou de flechas. Alguns objetivos possveis para eles seriam:

    Figura 6.1Diagrama de classes da tcnica de comportamento de agentes baseados

    em objetivos

    1. Aumentar pontos de vida: o personagem procura pelo item mais prximo

    que aumente seus pontos de vida, planeja um caminho at ele e o segue;

    2. Atacar um inimigo com a espada: o personagem se dirige ao inimigo e o

    ataca com a espada;

    3. Atacar um inimigo com arco-e-flecha: o personagem se posiciona de

    forma a acertar uma flechada no inimigo e atira a flecha;

    4. Explorar mapa: o personagem escolhe um ponto do mapa, traa um

    caminho at ele o segue;

    5. Fugir: o personagem procura uma rota de fuga e a segue.

  • 34

    Para calcular o quo desejvel do objetivo 1 ser executado, podemos

    pensar que procurar por vida proporcional a quantidade de pontos de vida que o

    personagem possui e inversamente proporcional distncia do item que lhe dar

    mais pontos de vida. A frmula a seguir mostra a relao do desejo de aumentar os

    pontos de vida em funo da quantidade de pontos de vida atual e da distncia do

    personagem ao item:

    A frmula acima funciona porque quanto menos pontos de vida o

    personagem possuir, maior ser o valor do desejo de ir procurar um item que

    aumente sua vida. Para a distncia, podemos limitar um valor como sendo o mximo

    que um personagem ir percorrer para pegar um item. Se a distncia entre um

    personagem e um item for maior ou igual distncia mxima, ento o valor 1 ser

    usado na frmula, o que far o desejo diminuir. Quanto mais prximo de 0 estiver o

    valor da distncia, maior ser o valor do desejo. Tratar a diviso por 0 dependeria

    das regras do jogo. Se basta que um personagem toque em um item para peg-lo, a

    distncia calculada nunca seria 0, pois o personagem j teria pegado o item. No

    entanto, alguns jogos assumem que um comando deve ser dado ao personagem

    para que ele pegue o item, mesmo que ambos ocupem a mesma posio. Nesse

    caso, apenas seria retornado o valor 1, que representa o maior grau de desejo.

    A diviso pode retornar um valor maior que 1. Para que se possam comparar

    os graus de desejo da mesma forma, deve ser feito um procedimento que faa com

    que o valor volte ao intervalo [0,1]. Esse procedimento depende dos valores

    mximos das variveis que representam os pontos de vida e a distncia at um item,

    sendo um cuidado a mais que deve ser tomado ao usar esse mtodo.

    O grau de desejo dos outros objetivos pode ser obtido de forma anloga ao

    que foi feito para se calcular o desejo de ir procurar um item de vida. Para atacar um

    inimigo com a espada, pode-se levar em considerao que o ataque ser feito com o

    personagem muito prximo do inimigo. Logo, quanto menos pontos de vida, mais

    arriscada essa estratgia. Tambm se pode levar em conta a distncia entre os

    dois, pois se ela for muito grande pode no valer a pena ir at o inimigo para atac-

    lo. Um ataque com o arco-e-flecha pode levar em considerao apenas a distncia,

    pois no necessrio se aproximar demais do inimigo e com isso a chance de sofrer

    um ataque e perder pontos de vida menor.

  • 35

    Para o objetivo de explorar o mapa, pode-se atribuir um valor constante e

    baixo. Assim o personagem s vai explorar o mapa quando no tiver que se

    preocupar com outras aes.

    O objetivo de fuga pode ser ativado considerando-se a quantidade de pontos

    de vida e a distncia do item mais prximo que aumente sua vida. Espera-se que o

    objetivo escolhido seja aumentar os pontos de vida, mas pode acontecer de no

    haver um item disponvel ou de ele estar muito longe, o que leva um personagem

    que est prestes a morrer a ter que fugir para que possa ter uma chance de

    sobreviver.

    6.2 Lgica Difusa

    6.2.1 Definies

    Normalmente, quando as pessoas se comunicam costumam usar termos

    lingusticos com algum grau de impreciso. Apesar disso, as pessoas conseguem se

    entender e realizar suas tarefas sem necessitar de uma preciso perfeita e formal.

    Fazer uma mquina entender as variveis lingusticas humanas seria um jeito mais

    natural de se fazer a comunicao entre o homem e a mquina.

    A lgica difusa foi inventada por Lofti Zadeh e permite a um computador

    reagir a regras e termos lingusticos de um jeito similar ao dos humanos. Definies

    como distante, fraco e ligeiramente no so representados por intervalos

    discretos, mas por conjuntos difusos, permitindo que valores sejam atribudos a

    conjuntos considerando seu grau de pertinncia. Esse processo chamado de

    fuzificao. Usando valores difusos, um computador interpreta regras lingusticas e

    produz uma sada que ainda permanece difusa, mas que pode ser defuzificada,

    como normalmente usada nos jogos. Esse processo conhecido como inferncia

    difusa e o mais popular uso da lgica difusa (Buckland, 2005).

    6.2.2 Uso e Implementao

    possvel usar a lgica difusa combinada com o mtodo de comportamento

    de agentes baseados em objetivos. Ela poderia ser usada para implementar o

  • 36

    mtodo getDesirability, nas classes filhas de Goal e CompositeGoal. Como

    determinar o quo desejvel de um objetivo ser executado simplesmente

    baseando-se em atributos do jogo e expresses matemticas no uma tarefa fcil,

    usar a lgica difusa para faz-lo pode ser um jeito mais intuitivo e natural,

    principalmente para desenvolvedores iniciantes, bastando-se apenas que sejam

    definidos os conjuntos difusos e as regras para a inferncia difusa.

    Figura 6.2 Grau de desejo de se executar um objetivo

    Figura 6.3 Quantidade de pontos de vida

    Considerando o exemplo da seo 6.1.2 e o objetivo 1 l definido, ser

    explicado o que seria necessrio definir para calcular o grau de desejo usando lgica

    difusa. Primeiro, devem ser definidas as variveis lingusticas difusas. Para este

    exemplo, precisa-se de uma varivel que represente o grau de desejo de execuo

    do objetivo, uma que represente a quantidade de pontos de vida do personagem e

    outra que represente distncia do personagem ao item mais prximo que aumente

    sua vida.

  • 37

    Figura 6.4 Distncia a um item

    Para a varivel grau de desejo, pode-se ter em mente que ela assume um

    valor no intervalo [0, 100]. Podemos definir trs termos: desejvel, indesejvel, muito

    desejvel. A figura 6.2 ilustra os conjuntos associados aos termos. Para a varivel

    pontos de vida, vamos assumir que um personagem tem, no mximo, 200 pontos

    de vida. Ela pode ser definida com os termos alto, normal e baixo, conforme a

    figura 6.3. A varivel distncia pode ser definida pelos termos perto, mdia e

    longe, como foi feito na figura 6.4.

    As regras que definem o grau de desejo de se executar o objetivo de

    procurar um item de vida so definidas abaixo:

    Se a quantidade de pontos de vida baixa e a distncia at o item de vida

    mais prximo baixa, ento o objetivo muito desejvel;

    Se a quantidade de pontos de vida baixa e a distncia at o item de vida

    mais prximo mdia, ento o objetivo muito desejvel;

    Se a quantidade de pontos de vida baixa e a distncia at o item de vida

    mais prximo longe, ento o objetivo desejvel;

    Se a quantidade de pontos de vida normal e a distncia at o item de

    vida mais prximo baixa, ento o objetivo desejvel;

    Se a quantidade de pontos de vida normal e a distncia at o item de

    vida mais prximo mdia, ento o objetivo indesejvel;

    Se a quantidade de pontos de vida normal e a distncia at o item de

    vida mais prximo longe, ento o objetivo indesejvel;

    Se a quantidade de pontos de vida alta e a distncia at o item de vida

    mais prximo baixa, ento o objetivo muito indesejvel;

  • 38

    Se a quantidade de pontos de vida alta e a distncia at o item de vida

    mais prximo mdia, ento o objetivo indesejvel;

    Se a quantidade de pontos de vida alta e a distncia at o item de vida

    mais prximo longe, ento o objetivo indesejvel;

    Como mtodo de defuzzificao, pode ser usado o mtodo Mdia das

    Mximas, pois tem preciso prxima a do mtodo do Centride, que o mais

    preciso, e tem custo computacional baixo quando comparado ao Centride.

    As regras acima descrevem o grau de desejo de ir procurar um item de vida

    de forma natural, como as pessoas fazem no dia-a-dia, o que torna a lgica difusa

    uma ferramenta poderosa. Os conjuntos podem ser modificados a fim de se ajustar

    o comportamento que se deseja. Por exemplo, o conjunto que define a quantidade

    de pontos de vida como baixa poderia ser esticado para fazer com que um

    personagem fosse mais vezes procurar um item de vida, adquirindo um

    comportamento de se preservar antes de pensar em tomar outras atitudes, como ir

    atacar. Outras variveis tambm poderiam ser exploradas como a fora de ataque

    de uma arma, cabendo ao desenvolvedor escolher quais variveis sero levadas em

    considerao.

  • 39

    7 Consideraes Finais

    Neste trabalho foram apresentados conceitos bsicos de desenvolvimentos

    de jogos. Foram discutidos tpicos sobre grficos, fsica, udio e inteligncia

    artificial.

    Desenvolver um motor para jogos est se mostrou uma tarefa extensa. No

    entanto, desenvolver jogos do zero, sem nenhuma biblioteca para auxiliar

    impraticvel nos dias de hoje considerando a complexidade dos jogos criados

    atualmente.

    Como trabalhos futuros, podem-se criar algumas extenses do motor

    desenvolvido:

    Adaptar os mdulos de fsica de desenho para suportar jogos 3D;

    Criar um mdulo para carregar o jogo totalmente de forma parametrizada,

    sem possuir parmetros embutidos no cdigo;

    Criar um editor de mapas para os jogos.

  • 40

    8 Referncias Bibliogrficas

    Bradshaw, J. M. An introduction to software agents. 1997.

    Buckland, M. Programming Game AI by Example. Wordware Publishing, Inc. 2005.

    Fernandes M. Programao de Jogos com Delphi usando DirectX. Relativa, 2002.

    Fernandes M. Programao de Jogos com Visual Basic usando DirectX. Relativa,

    2001.

    Ferreira, Rodrigo R.; Ferreia, Rafael R. Algoritmos para Deteco de Colises em

    Ambientes Grficos Bidimensionais. 29/01/2009. Disponvel em:

    . Acesso em: 30 jun. 2010.

    Flynt, J.P; Salem, O. Software Engineering for Game Developers. 2004.

    Game Engine. 04/11/2010. Disponvel em:

    . Acesso em: 07 nov. 2010.

    Gregory, J. Game engine architecture. 2009.

    Kimmerle, S. Tutorial: Real-Time Collision Detection for Dynamic Virtual

    Environments. 2005.

    Rocha, R. S. Algoritmos Rpidos de Deteco de Coliso. 2010.

    Sanches, B. C. Funcionamento de um jogo. Disponvel em:

    . Acesso em 07 abr. 2012.

    SDL mixer: Tutorials: Playing a WAV Sound File. Disponvel em:

    . Acesso em: 01 abr. 2012.

    Start out on Game Programming. 28/10/2010. Disponvel em:

    . Acesso em: 25 nov. 2010.

    West, M. Evolve your Hierarchy. 2007. Disponvel em:

    . Acesso em: 08

    abr. 2012.

    Wooldridge, M. An Introduction to multiagents systems. 2002.