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.