Desenvolvimento de Jogos 3d em Java Com A Utilização Do Motor Gráfico

Faculdade Lourenço Filho
Ciência da Computação
Desenvolvimento de Jogos 3D em Java com a Utilização do

Motor Gráfico Irrlicht
por
Daniel Souza Amazonas
____________________
Orientador:
Glaudiney Moreira Mendonça Junior
Fortaleza, 2007
Monografia apresentada ao curso de

Ciência da Computação da Faculdade
Lourenço Filho como requisito parcial
para obtenção do título de Bacharel em
Ciência da Computação.
Orientador:
Glaudiney Moreira Mendonça Junior
Agosto, 2007
Monografia Apresentada ao curso de Bacharel em Ciências da Computação da

Faculdade Lourenço Filho, como parte dos requisitos para a obtenção do grau de
Bacharel em Ciências da Computação.
Composição da Banca Examinadora:
_______________________________________
Prof. MSc. Glaudiney Moreira Mendonça Junior (Orientador)
_______________________________________
Prof. MSc. George Allan Menezes Gomes
_______________________________________
Prof. MSc. Leandro da Silva Taddeo
Aprovada em 24 de agosto de 2007

i
Agradecimentos
A meus pais que me apoiaram sempre, a todos os amigos e colegas do curso de computação,
ao professor e orientador Glaudiney Moreira Mendonça Junior, pela sua paciência na
orientação e idéias que tornaram possível a conclusão desta monografia, e ao George que me
indicou o mesmo. Amigos e colegas, em especial, Erland “Bacon”, Renato “Rato”, Marc
“Fera”, entre outros, pelo apoio, e por duvidarem da conclusão da mesma, pois o maior
incentivo é esse, alguém duvidar.
ii
Resumo
O mercado de jogos está em ascensão no mundo todo, pois cada vez mais estão evoluindo os
hardwares para um melhor desempenho e os softwares para um bom desenvolvimento, logo
se pode dizer que é uma boa área a se explorar, pois existem diversos tipos de plataformas e
gêneros de jogos. No decorrer da monografia, será documentada a história dos jogos, mercado
de jogos, e será exposto como se desenvolvem o mesmo, mostrando o planejamento que junta
os conceitos básicos de jogos e o ciclo de desenvolvimento.
Em seguida, apresenta conceitos de motores gráficos, seu histórico, e quais gêneros de
jogos o utiliza. Citando motores de usos comerciais e livres, detalhando a sua estrutura, e do
que é composta, e alguns processos necessários para o desenvolvimento de um jogo de tiro em
primeira pessoa.
Outro capítulo irá documentar sobre o motor gráfico Irrlicht, motor escolhido, pois
possibilita o desenvolvimento na linguagem Java, conhecida como Jirr. No capítulo serão
apresentadas as funcionalidades do motor.
Para o desenvolvimento de um jogo, serão documentadas algumas etapas do ciclo de
desenvolvimento de um ambiente 3D, utilizando o motor gráfico Jirr, versão Java do Irrlicht.
Ambiente, no qual serão carregados componentes para se assimilar a um jogo de primeira
pessoa. Será mostrada a estrutura do protótipo desenvolvido, apresentando trechos de códigos
e o diagrama de classe projeto.
O projeto proposto permite que se possam desenvolver jogos para desktop utilizando a
linguagem Java.
Palavras-chave: Desenvolvimento de Jogos, Motor Gráfico, Computação Gráfica, Java.

iii
Sumário
Agradecimentos ................................................................................................................. i
Resumo ............................................................................................................................. ii
Lista de Figuras ................................................................................................................ v
Lista de Tabelas .............................................................................................................. vii
1. Introdução ..................................................................................................................... 1
1.1 Motivação ............................................................................................................... 1
1.2 Objetivos................................................................................................................. 2
1.3 Organização do Trabalho........................................................................................ 2
2. Desenvolvimento de Jogos ........................................................................................... 3

2.1 Introdução ............................................................................................................... 3
2.2 Mercado de Jogos ................................................................................................... 5
2.2.1 Mercado Brasileiro .......................................................................................... 6
2.3 Planejamento .......................................................................................................... 7
2.3.1 Conceitos Básicos de Jogos ............................................................................. 7
2.3.2 Ciclo de Desenvolvimento .............................................................................. 9
2.4 Considerações Finais ............................................................................................ 11
3. Motor Gráfico ............................................................................................................. 12

3.1 Introdução ............................................................................................................. 12
3.2 Exemplos de Motores Gráficos ............................................................................ 13
3.3 Estrutura ............................................................................................................... 16
3.4 Jogos de Tiro em Primeira Pessoa ........................................................................ 17
3.4.1 Subsistemas ....................................................................................................... 18
Geração de Dados ................................................................................................... 18
Processamento de Dados ........................................................................................ 20
4. Irrlicht......................................................................................................................... 21
4.1 Introdução ............................................................................................................. 21
4.2 Caracteristicas ....................................................................................................... 23
4.2.1 Plugins ........................................................................................................... 24
4.3 Jirr ........................................................................................................................ 25
4.3.1 Renderização ................................................................................................. 26
4.3.2 Interface Gráfica ............................................................................................ 26
4.3.3 Inserção de Elementos ................................................................................... 27
4.3.4 Tratamento de Eventos .................................................................................. 29
4.3.5 Som ................................................................................................................ 29
iv

5. Desenvolvimento ........................................................................................................ 31
5.1 Introdução ............................................................................................................. 31
5.2 Ciclo de Desenvolvimento ................................................................................... 33
5.3 Classes .................................................................................................................. 34
5.3.1 Criação de Terreno ........................................................................................ 37
5.3.2 Inserção de Imagens ...................................................................................... 38
5.3.3 Colisão ........................................................................................................... 39
5.3.4 Inserção de Modelos ...................................................................................... 39
5.3.5 Tratamento de Eventos .................................................................................. 41
5.3.6 Inserção de Elementos na GUI ...................................................................... 41
6. Conclusões .................................................................................................................. 45
Referências ..................................................................................................................... 47
v
Lista de Figuras
Figura 2.1: Computador analógico e mostrado em um osciloscópio ............................... 3
Figura 2.2: Imagem do jogo de tênis conhecido como PONG ......................................... 4
Figura 2.3: Imagens do jogo Amazônia............................................................................ 4
Figura 2.4: Ordem das etapas para o desenvolvimento de um jogo ............................... 10
Figura 2.5: Diagrama de desenvolvimento de um jogo .................................................. 11
Figura 3.1: Interface do motor Unreal Engine 2 ............................................................ 13
Figura 3.2: Imagem do jogo Neverwinter Nights 2 ........................................................ 15
Figura 3.3: Crysis, jogo que está sendo desenvolvido e utiliza o motor CryEngine2 .... 15
Figura 3.4: Pacific Storm, jogo desenvolvido com o motor OGRE3D .......................... 15
Figura 3.5: Estrutura de um motor gráfico ..................................................................... 16
Figura 3.6: Estrutura básica de um FPS ......................................................................... 18
Figura 3.7: Maplet, um editor de níveis gratuito ............................................................ 19
Figura 3.8: Edição de um modelo MD2 ......................................................................... 19
Figura 4.1: H-Craft Championship, jogo que utiliza o sistema de partículas ................ 21
Figura 4.2: Galact Dream: Rage of War, jogo comercial que utiliza o Irrlicht ............. 21
Figura 4.3: MD2 visto em uma interface gráfica do próprio Irrlicht ............................. 24
Figura 4.4: irrEdit, editor livre bastante completo para o Irrlicht .................................. 25
Figura 4.5: Inicialização do motor em Java.................................................................... 26
Figura 4.6: Configuração de video, e adição de um botão ............................................. 27
Figura 4.7: Carregamento de um cenário Quake 3 ......................................................... 28
Figura 4.8: Mesh carregado pelo Jirr ............................................................................. 29
Figura 4.9: Trecho com exemplos de eventos implementados ....................................... 30
Figura 5.1: Jake versão Java do Quake 2 ....................................................................... 32
Figura 5.2: Etapas realizadas no desenvolvimento do jogo ........................................... 34
Figura 5.3: Diagrama de classe do jogo ......................................................................... 35
Figura 5.4: Criação de um terreno .................................................................................. 37
Figura 5.5: Criação de um skybox .................................................................................. 38
Figura 5.6: Terreno carregado sem o skybox .................................................................. 38
Figura 5.7: Terreno carregado com skybox .................................................................... 38
Figura 5.8: Criação de colisão ........................................................................................ 39
vi
Figura 5.9: Terceira pessoa ............................................................................................. 40

Figura 5.10: Primeira pessoa (FPS) ................................................................................ 40
Figura 5.11: Carregamento de meshes, e suas configurações......................................... 40
Figura 5.12: Métodos necessários para carregar um modelo no ambiente 3D ............... 41
Figura 5.13: Inserção de textos através de componentes da GUI................................... 42
Figura 5.14: Imagem de textos com o uso do recti ........................................................ 42
Figura 5.15: Carregamento de imagens na GUI ............................................................. 42
Figura 5.16: Imagem carregada na interface gráfica, em terceira pessoa ....................... 43
Figura 5.17: Imagem carregada na interface gráfica, em primeira pessoa ..................... 43
Figura 5.18: Imagem com todos os modelos, e componentes carregados ...................... 43
vii
Lista de Tabelas
Tabela 2.1: Vendas de consoles no Japão, onde a primeira coluna representa a primeira
Semana de janeiro, e a segunda, a venda estimada até o fim de 2007 ............................. 6
Tabela 5.1: Comparativo de desempenho do código original e a versão Java ............... 32
Tabela 5.2: Eventos ........................................................................................................ 33
1
Capítulo 1
Introdução
Com a qualidade dos jogos crescendo cada vez mais devido ao desempenho do
hardware das plataformas existentes, é necessário aprender e desenvolver jogos com um nível
de qualidade aceitável para essas plataformas. Pois ultimamente os jogos estão sendo
produzidos por equipes cada vez mais especializadas, dando ênfase as estórias, qualidade
gráfica e efeitos sonoros. Logo, para entrar nesse ramo seleto, a aprendizagem dos processos
de desenvolvimento e da utilização de ferramentas necessárias para a evolução de um projeto,
ou até mesmo, a criação das próprias ferramentas, como motores gráficos proprietários.
1.1 Motivação
Nos últimos anos, as vendas de jogos eletrônicos faturaram mais que toda a indústria
cinematográfica junta (SANTAELLA, 2004). O grande motivo deste crescimento deve-se a
geração de pessoas que cresceram jogando e que ainda continuam a jogar, ensinando seus
filhos a fazerem o mesmo. Os jogos estão cada vez mais reais, simulando todos os efeitos de
físicas: explosões, nuvens, luminosidade etc. através de motores gráficos, e físicas. Para
conseguir realismo, empresas desenvolvem ferramentas, comerciais ou gratuitas a fim de
facilitar o desenvolvimento dos jogos, e diminuir o tempo gasto.
Existem motores voltados para tipos específicos de jogos, como os de ação, estratégia
e simuladores. O Irrlicht é um motor gratuito, onde muitas de suas funcionalidades serão
comentadas, pois através dele é possível o desenvolvimento de jogos comerciais de alto nível
devido aos seus recursos e efeitos disponíveis. Uma grande vantagem existente nesse motor é
a sua flexibilidade em relação às linguagens de programação, pois está disponível em Java,
C++, Phyton, Lua, .NET, entre outras linguagens.
Para quem sempre quis fazer algo no mundo dos jogos, está mais fácil, pois as
ferramentas necessárias estão disponíveis gratuitamente, sendo necessário apenas a
criatividade, um pouco de conhecimento em programação na linguagem desejada e adquirir
experiência com cada desenvolvimento realizado. Com essas facilidades, este trabalho propõe
desenvolver um protótipo de um jogo, comentado as fases do processo de desenvolvimento
realizado.
2
1.2 Objetivos
O objetivo deste trabalho é demonstrar a configuração do ambiente de desenvolvimento para a
utilização do motor gráfico, e sua integração com uma ferramenta de desenvolvimento (IDE -
Integrated Development Environment).
O intuito desta é mostrar o desempenho de outra linguagem diferente da C/C++ em
desenvolvimento de jogos, demonstrando que é possível um desempenho próximo e em um
dos casos até superior. Outro objetivo é comentar e explicar as fases de desenvolvimento de
um jogo em primeira pessoa inserido em um ambiente 3D com a utilização do motor gráfico
Irrlicht, escrito em Java (Jirr), que é um motor orientado a objetos e de rápida aprendizagem.
Logo, esta será a linguagem utilizada para o desenvolvimento do jogo proposto.
1.3 Organização do Trabalho

No capítulo 2, será mostrada uma breve historia do vídeo-game, e em seguida o mercado de
trabalho e o ciclo de desenvolvimento de um jogo. O capítulo 3 comentará sobre motores
gráficos, seus subsistemas, e quais gêneros o utilizam. No capítulo 4, algumas funcionalidades
do motor gráfico Irrlicht serão apresentadas, e trechos de códigos da sua versão em Java. O
capítulo 5 apresentará uma estrutura desenvolvida com intuito de se desenvolver um jogo de
tiro em primeira pessoa, comentando trechos de códigos das classes elaboradas. E, por fim, no
capítulo 6, conclusões serão apresentadas.
3
Capítulo 2
Desenvolvimento de Jogos
Esse capítulo irá documentar primeiramente sobre uma breve história dos jogos,
mercado de jogos, e logo depois, como se desenvolve o mesmo, mostrando o planejamento
que engloba os conceitos básicos de jogos e o ciclo de desenvolvimento.
2.1 Introdução
Segundo BATTAIOLA et. al (2004), sobre a história dos jogos, sabe-se que um físico
chamado Willy Higinbotham da Brookhaven National Laboratories dos EUA em 1958 criou
um novo ramo na área da computação, a de desenvolvimento de jogos. Quando ocorriam
visitas em seu laboratório, Willy, preocupado de que as pessoas ficassem desmotivadas pelo
seu trabalho, inventou um jogo de tênis muito simples, sua execução era em um computador
analógico e sua apresentação mostrada em um osciloscópio1, veja na Figura 2.1 esse jogo para
dois jogadores, e na Figura 2.2 as imagens do jogo. Essa idéia foi um sucesso e acabou
incitando a invenção de vários outros jogos, em destaque, os primeiros jogos de galeria (pode
ser uma arma ou um carro) e consoles.
Figura 2.1: Computador analógico e mostrado em um osciloscópio.

1
é essencialmente um voltímetro que, ao invés de usar um mostrador (ponteiro ou display digital) apresenta em
forma de gráfico numa tela a tensão do sinal testado.
4
Figura 2.2: Imagem do jogo de tênis conhecido como PONG.
Um engenheiro eletrônico chamado Nolan Bushnell, depois de um início não tão bem
sucedido de primeiro jogo de galeria, junto com um amigo, criam uma empresa com apenas
um interesse, o desenvolvimento de jogos – a Atari. Inicialmente em 1972, suas atividades
estão voltadas ao famoso jogo Pong. No decorrer de 30 anos, a indústria de jogos acumula
uma grande experiência, onde uma empresa brasileira, a TILT online em 1983, produz seu
primeiro jogo escrito na linguagem Basic para a plataforma de microcomputadores Sinclair
ZX 81, o jogo chama-se Amazônia, que é do gênero adventure. A Figura 2.3 mostra uma
imagem do jogo. Depois esse jogo, teve um grande momento ocioso até o próximo
lançamento, que ocorreu somente nos anos 90. Vários assuntos conjunturais (política de
informática, costumes na área, ausência de investidores) foram os motivos do atraso.
Figura 2.3: Imagens do jogo Amazônia.
Com o desenvolvimento da computação no Brasil, tantos em termos acadêmicos

quanto empresariais, o país adquiriu profissionais muito competentes na área de
desenvolvimento de jogos. Embora esta capacidade, atestada pela qualidade do software,
principalmente para o sistema bancário, não houve aproveitamento da tecnologia conhecida
no desenvolvimento de outros produtos, dentre eles, os jogos de computadores. Depois de 32
anos que Bushnell lutou por um reconhecimento, a invenção de jogos conta com,
5
investimento, capacitação de pessoal e acesso a tecnologia em nações como EUA, Japão e

Coréia, os chefes mundiais na área.
Hoje, as empresas especializadas em desenvolvimento de jogos, no Brasil e no mundo,
trabalham com diferentes áreas do conhecimento, sendo considerada uma das mais
multidisciplinares no campo da computação, pois é um conjunto de idéias, desde a parte de
formação do conceito do jogo, gráficos, sons, entradas, redes, inteligência artificial até
matemática e física. Por ser um campo em que se ramifica, em várias áreas, os profissionais
acabam se especializando em determinados campos e geram uma grande porção de
informação, novas técnicas e procedimentos que são difundidos na indústria de jogos.
2.2 Mercado de Jogos

Segundo SANTAELLA (2004), em 2003, o comércio de jogos obteve uma movimentação de
US$ 28 bilhões em todo o mundo, muito mais do que a indústria de cinema. Desta quantia,
quase US$ 1 bilhão refere-se aos jogos voltados para celulares, sendo que a expectativa é
alcançar um valor estimado de US$ 3 bilhões até 2007, o que influencia o investimento na
criação de jogos voltados para celulares. Ultimamente o comércio de jogos no mundo se
encontra em grande expansão, e está previsto um crescimento no mercado de jogos nas
seguintes áreas:
 Jogos para PC: estava em baixa nos anos anteriores, mas atualmente as pesquisas
mostram que houve um crescimento estendido nos dois primeiros meses de 2007,
tendo movimentado cerca de US$ 203 milhões segundo o instituto de pesquisa NPD
Group, o que representa uma alta de 48% em relação ao ano passado na mesma época.
 Jogos para celular: são os mais importantes representantes dessa categoria de
entretenimento, eles sempre estiveram presentes nos aparelhos, desde os modelos mais
simples que foram os primeiros aos de última geração lançados no mercado. O avanço
dos aparelhos celulares permitiu desenvolverem-se jogos cada vez mais elaborados, e
com mais qualidade, tanto nos gráficos como nos efeitos sonoros, o que abriu as portas
para o surgimento de um mercado importante. Segundo Marcelo Nunes de Carvalho,
diretor de tecnologia da Devworks (DEVWORKS, 2007):
O mercado de jogos vem crescendo muito. O de jogos para celular é o que

mais cresce. Fala-se em crescimento de 7000% até 2006. É um número que beira o
inacreditável, mas é esse número que a indústria considera hoje como sendo a
expectativa de crescimento.
6
 Jogos para consoles: o videogame atual não é apenas uma base de jogos, ele agora é
usado para condensar e ganhar informações para o entretenimento. Com a nova
geração de videogames e suas inovações, teve-se um aumento de suas vendas em
relação aos anos anteriores. Veja na Tabela 2.1 a quantidades de consoles vendidos na
primeira semana de janeiro no Japão, e a previsão das vendas acumuladas até o fim de
2007 (UOL JOGOS, 2007).
Tabela 2.1: Vendas de consoles no Japão, onde a primeira coluna representa a primeira
semana de janeiro, e a segunda, a venda estimada para até o fim de 2007.
Vendas de consoles no Japão
1000000
100000
Quantidades
10000
1000
100
146073
902411
524928
270938
155303
133404
65740
31216
18727
17540
47806
6130
1050
9361
7156
3076
10
724
306
119
440
272
28
1
e
0
ii
P
te
e
DS
ro
n3
n2
36
ub
W
c
PS
eS
Li
ic
an
eC
tio
tio
do
ox
eM
c
DS
dv
an
ta
ta
ten
Xb
A
yS
yS
dv
Ga
c
do
an
oy
a
A
ten
Ni
Pl
Pl
dv
eB
oy
n
A
Ni
eB
m
oy
Ga
m
eB
Ga
m
Ga
Consoles
2.2.1 Mercado brasileiro

Está estimado que o mercado de jogos no Brasil seja de R$ 10 milhões, que são divididos em
nichos, entre eles, destacam-se os middlewares. Eles são de entretenimento puro, uma vez que
é uma ferramenta usada em técnica de desenvolvimento e de manutenção de jogos, e é um
programa que faz a mediação entre outros softwares. Outros conhecidos são os advergames
que se enquadra como jogos de vocação publicitária, e o business games têm como base
simulações de negócios com a finalidade de que o usuário tenha um aprendizado. Os voltados
para educação também estão crescendo.
Segundo FALCO (2005), uma pesquisa realizada pela Abragames, relatou que no
Brasil existem 55 empresas de jogos em plena atividade, e que em média, cada empresa
emprega 15 funcionários. A maior parte dessas empresas está localizada no Paraná, que possui
33% do total, São Paulo com 30% e Rio de Janeiro que concentra 12% das empresas.
7
Grande parte atua no mercado mais tradicional, que são jogos para PC, estimado em
63%. Logo em seguida, vem o de jogos para celulares que estão explorando cada vez mais,
cerca de 22% das companhias atuam nessa área.
2.3 Planejamento
Segundo PERUCIA et. al (2005), as duas ações indicadas antes de se começar o
desenvolvimento de um jogo são pensar e esquematizar, ou seja, planejar. Qualquer
modificação radical do rumo no decorrer da fase de produção do jogo pode ser fatal. O grau
de retrabalho pode ser extremamente alto. Muitos projetos são eliminados devido à esse tipo
de problema. No entanto, quanto mais tempo para a fase de planejamento, será mais cômodo
de ter uma visão concluída do produto, as dificuldades que poderão acontecer e suas soluções.
BITTENCOURT e GIRAFFA (2003) definem que:
No planejamento de jogos e simulações é de vital importância definir e fixar

os objetivos da atividade, a determinação do contexto desejado para a mesma, a
identificação dos recursos utilizáveis para se alcançar os objetivos finais e a
determinação da seqüência de interações.
2.3.1 Conceitos Básicos de Jogos

O filósofo HUIZINGA (1938), definiu jogo como:
Uma atividade voluntária exercida dentro de certos e determinados limites de

tempo e espaço, segundo regras livremente consentidas, mas absolutamente
obrigatórias, dotado de um fim em si mesmo, acompanhado de um sentimento de
tensão e alegria e de uma consciência de ser diferente de vida cotidiana.
Segundo IMPA (2007), existem dois tipos de jogos, os cooperativos e os não-

cooperativos, onde suas diferenças estão no enfoque sobre o jogador. Em jogos não-
cooperativos, o conjunto de ações aceitáveis está diretamente ligado a jogadores individuais,
ou seja, um jogo jogado sozinho. E em jogos cooperativos, o conjunto de ações aceitáveis está
diretamente ligado a grupos de jogadores, que podem estar ligados por uma rede, internet, ou
até mesmo um console com vários jogadores.
A empresa que decidir iniciar o desenvolvimento de um jogo necessita antes de pensar
em qual jogo criar, pensar em termos de negócio, se estará criando algo novo ou apenas mais
um jogo, pois existem jogos que são muito parecidos uns com outros. As empresas de jogos
atuais estão muito bem estruturadas, e seguindo padrões como outras quaisquer, onde têm
8
planejamento, gerenciamento de projetos, produção, marketing, vendas, financeiro etc. Tudo

de forma muito bem organizada para produção de jogos, na qual se tem uma estrutura de
trabalho que permite o cumprimento de metas e o trabalho em equipe.
Para um jogo ser lançado é necessário um grupo bastante qualificado e
multidisciplinar. PERUCIA et. al (2005) define que para a maior parte das empresas que tem
como meta o desenvolvimento de jogos bons e de qualidade, são requeridos cargos específicos
para cada área, a lista abaixo mostra quais são:
 Programadores: que são encarregados de desenvolver o software do jogo, onde são
desenvolvidas técnicas de inteligência artificial, computação gráfica, efeitos sonoros,
interação etc. para programar o jogo.
 Artistas: também fazem parte do quadro efetivo para o desenvolvimento de um jogo.
Eles são responsáveis pelo layout do jogo. Inventam os objetos, texturas, ilustrações,
personagens, animações etc.
 Projetistas de níveis/fases: geralmente esses profissionais são provenientes das mais
variadas áreas. Os projetistas de níveis são aqueles que inventam as fases dos jogos
estruturando seus desafios e surpresas. Dependendo da dimensão da empresa, um
projetista de níveis pode ser responsável exclusivamente pela fase de design ou operar
em todas as etapas, desde a concepção até o desenvolvimento.
 Projetistas de jogos: são considerados os administradores dos projetos e levam o nome
também de Game Designers. Eles são de extrema importância na fase de elaboração
dos projetos, por envolvimento em praticamente todas as áreas da produção de jogos
computadorizados. Eles são responsáveis desde a criação das idéias até a concepção do
jogo e pela preparação do design document, que é um documento bastante detalhado
que contém todas as características e especificações do jogo. Esse profissional possui
uma visão bem ampla de todo o jogo, necessitando manter comunicação constante com
todos do grupo de produção para firmar que o jogo desenvolvido vai estar de acordo
com a proposta do design document.
 Planejador de software (Software Planner): eles dividem o projeto do jogo em um
conjunto de requisitos e avaliam o grau de dificuldade para desenvolver os requisitos
levantados e o tempo necessário.
 Arquiteto-chefe (Lead Architect): seu dever é trabalhar em conjunto com o planejador
de software para juntos elaborarem um conjunto de especificações e módulos, levando
9
em consideração os requisitos técnicos identificados pelo planejador de software.

Logo, a arquitetura geral do projeto é de responsabilidade do arquiteto-chefe.
 Gerente de projeto (Project Manager): sua tarefa é balancear a carga de tarefas gerada
pelo planejador de software e pelo arquiteto-chefe tendo como conseqüência a
elaboração de um planejamento bom e organizado.
 Músicos e sonoplastas: vindos de áreas ligadas a arte e a música, eles compõe as
trilhas sonoras, efeitos especiais e vozes para os jogos.
 Testadores: surgem perto do fim do projeto, são responsáveis de procurarem falhas e
erros conhecidos como bugs nos jogos.
2.3.2 Ciclo de Desenvolvimento

Ao se falar de jogos, uma boa arquitetura de softwares pode trazer grandes vantagens.
PERUCIA et. al (2005) descreve que uma grande vantagem seria a reutilização de módulos
que são comuns em alguns jogos, consequentemente ocorreria não só ganho de tempo, e sim o
de qualidade.
O ciclo de desenvolvimento é dividido em diversas etapas:
 Braimstorming: consiste em reunir toda a equipe para discutir originalidade, inovação
e público-alvo, e também elaborar todo o detalhamento da idéia desde a apresentação
até as especificações técnicas.
 Game Design: onde são descrita todas as características mais importantes do jogo
como: jogabilidade, controles, interfaces, golpes, personagens, inimigos, armas, fases e
tudo sobre o projeto. Em paralelo com essa etapa o document design é elaborado.
 Document Design (DD): é a descrição do jogo. Funciona como um roteiro de cinema,
onde descrevem-se todas as funcionalidades do jogo de modo que todas as áreas
envolvidas possam extrair informações indispensáveis para desenvolverem suas
funções.
 Cronograma: sabendo as etapas de desenvolvimento, é feito um levantamento que
consiste em descrever a ordem em que as tarefas vão ser cumpridas e o tempo
necessário para concretizar cada uma.
 Level Design: é o mapeamento geral de todos os desafios e missões que o jogador
necessita exercer para concluir a fase. É de extrema utilidade, pois é referencia para
que os artistas desenvolvam os cenários e o visual das fases.
10
 Beta: são lançados vários alphas até atingir a versão beta, que possuem todas as fases,
e interatividade do jogo. Junto com essa fase começam os testes.
 Teste: junto com o beta, inicia-se a fase de teste necessária pra detecção dos erros,
mais conhecidos como bugs. E também nessa fase que se coletam opiniões com o
intuito de melhorar o produto.
 Versão Final: versão pronta do jogo com supostos bugs encontrados no decorrer da
fase Beta e de teste corrigidos. Uma versão que já pode ser comercializada.
 Demo: um demo geralmente é distribuído meses antes do lançamento do produto final,
eles são lançados e atualizados constantemente e possuem algumas funcionalidades
para testar a jogabilidade, detectar alguns bugs, criar expectativa entre os jogadores e
oferecer uma pequena amostra que o jogo completo lhe reserva.
Na Figura 2.4, mostra a ordem das etapas, e na Figura 2.5, apresenta em formato de
diagrama o ciclo de desenvolvimento de um jogo, mostrando que é um processo iterativo e
incremental.
Braimstorming
Game Design
Document Design
Cronograma
Level Design
Beta
Teste
Versão Final
Demo
Figura 2.4: Ordem das etapas para o desenvolvimento de um jogo.

11
Pesquisa
Definição
Plataforma-Alvo Publico-Alvo Regras do Jogo
Criação
Layout do Jogo Arte do Jogo
Desenvolvimento
Codificação Teste
Figura 2.5: Diagrama de desenvolvimento de um jogo.
2.4 Considerações Finais

Para o desenvolvimento de jogos, pode-se afirmar que é preciso ter, além do conhecimento de
programação, o conhecimento do que o mercado está interessado. Atualmente o mercado de
celular é o que mais cresce, existindo várias empresas especializadas no desenvolvimento de
jogos para celulares e PDAs.
Uma empresa séria deve seguir todos os passos do ciclo de desenvolvimento, para
garantir um desenvolvimento de alto nível e com grande chance de sucesso e de reuso em
futuras aplicações, garantido assim um desenvolvimento mais rápido.
Para desenvolvimento de jogos, existem motores de jogos, conhecidos também como
motores gráficos, que são ferramentas para facilitar o desenvolvimento, no capitulo a seguir,
alguns motores gráficos serão apresentados.
12
Capítulo 3
Motor Gráfico
Esse capítulo apresenta o surgimento do termo motor gráfico, seu histórico, e que tipo
de jogos o utiliza. Alguns motores de usos comerciais e livres são apresentados, explicando a
sua estrutura, e do que é composta, como sistemas de física, sistemas de partículas, detecção
de colisão, inteligência artificial e renderizadores de vídeo e som. Em seguida apresenta-se o
desenvolvimento de um jogo de tiro em primeira pessoa, e o que é necessário em um motor
gráfico para desenvolvê-lo e, no qual serão especificados seus subsistemas como geração e
processamento de dados.
3.1 Introdução
Segundo WIKIPÉDIA (2007), o termo “game engine”, conhecido também como motor de
jogo, surgiu em meados anos 90 com intuito de juntar jogos 3D com os de primeira pessoa
(FPS, First Person Shooter), o termo se popularizou com a empresa responsável pelos
primeiros jogos desse gênero, a id Software (ID SOFTWARE, 2007), que primeiramente
desenvolveu o Wolfenstein3D, mas só ganhou destaque mesmo com o Doom. Por causa do seu
grande sucesso, a empresa não demorou muito para lançar o Quake. Jogos mais recentes,
como Quake 4 (ID SOFTWARE, 2005) e Unreal Tournament 2003 (EPIC GAMES, 2002),
foram projetados utilizando a mesma idéia, ou seja, utilizando motores gráficos, mas sendo
desenvolvidos separadamente, pois tratava-se de jogos de empresas diferentes.
A contínua evolução dos motores gráficos criou uma separação forte entre
renderização, script, parte artística e desenvolvimento. Isso já é bastante comum, mas até
2003, era típico que uma equipe de desenvolvedores de jogos fizessem tanto o papel artístico
como o de desenvolvimento.
Jogos de terceira pessoa, tradicionalmente os do RPG (Role-Playing Game), já
utilizam seus próprios motores, como RPG Maker (ENTERBRAIN, 2007), mas nada impede
a utilização de motores feitos para os de primeira pessoa. Por exemplo, o RPG Morrowind
(BETHESDA GAME STUDIOS, 2005) e o MMORPG (Massively Multiplayer Online Role-
Playing Game) Dark Age of Camelot (MYTHIC ENTERTAINMENT, 2005) são baseados no
motor NetImmerse (NDL, 2007) e o MMORPG Lineage II (NCSOFT, 2005) é baseado no
motor Unreal Engine 2 (UNREAL TECHNOLOGY, 2007), ambos motores usados
13
inicialmente para jogos de primeira pessoa, veja na Figura 3.1 a interface de criação de fases
desse motor. Motores gráficos são usados por jogos que também foram desenvolvidos
originalmente para consoles. Um exemplo é o motor RenderWare (RENDERWARE FMSS,
2007) que foi usado no jogo Grand Theft Auto.
Figura 3.1: Interface do motor Unreal Engine 2.
Devido à complexidade dos motores gráficos modernos, escrever uma aplicação, que
utiliza estes motores exige que o programador tenha uma certa experiência para poder
aproveitar as funcionalidades disponíveis.
Segundo a WIKIPÉDIA (2007), motor gráfico é uma ferramenta usada para o
desenvolvimento de simulações em tempo real, como os jogos, tanto para videogames ou
computadores. Eles possuem um conjunto de bibliotecas especificas para simplificar o
desenvolvimento do mesmo. O que caracteriza um motor gráfico é um conjunto de
subsistemas como o de renderização, que é usada tanto para gráficos 2D, como para 3D, o
motor de física ou detecção de colisão, e motores de suporte a sons, animação, inteligência
artificial, rede e grafo de cena (scene graph), que é a representação hierárquica de todos os
objetos que compõem um mundo virtual.
3.2 Exemplos de Motores Gráficos

Alguns dos motores gráficos comerciais mais avançados são:
 Earth-4 Engine: motor gráfico usado no jogo Earth 2160. (EARTH 2150, 2007).
14
 Electron Engine: baseado no Aurora Engine, motor gráfico usados em jogos de RPG,
ele foi usado pra o desenvolvimento do jogo Neverwinter Nights 2, veja na Figura 3.2
a capacidade gráfica desse motor. (OBSIDIAN ENTERTAINMENT, 2007).
 Unreal Engine 3: o mais popular motor gráfico para jogos de ação, em sua lista estão
jogos esperados como Tom Clancy's Rainbow Six: Vegas, e Unreal Tournament 3,
ainda sem previsão de lançamento. (UNREAL TECHNOLOGY, 2007).
 Doom 3 Engine: usados nos jogos Doom 3, Quake 4, Prey e Quake Wars. (DOOM 3
ENGINE, 2007).
 CryENGINE2: utilizado em jogos de tiro em primeira pessoa. Sua versão anterior foi
utilizada para o desenvolvimento do jogo Far Cry, e em sua versão mais atual, está
sendo usada para um jogo ainda não lançado, o Crysis, na Figura 3.3, mostra uma
imagem liberada do jogo. (CRYTEK, 2007).
 Source Engine: motor gráfico utilizado no desenvolvimento do jogo Half-Life 2.
(VALVE SOFTWARE, 2007).
 Odyssey Engine: motor desenvolvido pela LucasArts, usado em Star Wars: Knights of
the Old Republic. (BIOWARE, 2007).
Abaixo, alguns motores gráficos livres:
 Axiom Engine: projeto que contem o núcleo do motor OGRE3D. (AXIOM ENGINE,
2007).
 Crystal Space: uma boa estrutura para desenvolvimento de aplicações 3D. (CRYSTAL
SPACE, 2007).
 DarkPlaces: um dos motores livres mais avançados para desenvolvimentos de jogos.
Com a arquitetura baseada no Quake III engine. (DARKPLACES, 2007).
 Game Blender: uma subaplicação do Blender para a criação de jogos. (BLENDER,
2007).
 Irrlicht Engine (IRRLICHT, 2003): plataforma 3D leve com bons gráficos.
 Jirr Engine (JIRR, 2007): versão na linguagem Java do motor Irrlicht.
 OGRE Engine: um dos motores gráficos orientado a objeto mais populares, também
chamado de OGRE3D. Na Figura 3.4, podemos ver a qualidade gráfica de um jogo que
usa esse motor. (OGRE3D, 2007).
 Panda3D Engine: motor para desenvolvimento rápido, feito na linguagem Python.
(PANDA3D, 2007).
 ProQuake: uma modificação do motor Quake engine. (PROQUAKE, 2007).
15
Esses motores fornecem um pacote de ferramentas visuais que agiliza o processo de

desenvolvimento de um ambiente 3D, em adição à componentes de softwares reusáveis. Essas
ferramentas visuais são comumente equipadas em uma IDE (Integrated Development
Environment) ou RAD (Rapid Application Development), que serve para simplificar o
desenvolvimento de jogos. Esses motores são também chamados de “game middleware” por
fornecerem um programa flexível e reutilizável com todas as funcionalidades necessárias para
se criar um jogo, no intuito de reduzir os custos, complexidade, e todos os outros fatores
críticos para a indústria de jogos.
Alguns motores gráficos só fornecem capacidades de renderização 3D em tempo real
dentro das funcionalidades requeridas pelos jogos, pois quanto mais detalhes, menor é seu
desempenho de renderização (processo pelo qual se pode obter imagens digitais).
Figura 3.2: Imagem do jogo Neverwinter Figura 3.3: Crysis, jogo que está sendo
Nights 2, mostrando a capacidade gráfica do desenvolvido e utiliza o motor CryENGINE2.
motor usado.
Figura 3.4: Pacific Storm, jogo desenvolvido com o motor OGRE3D.

16
3.3 Estrutura
Uma característica comum dos motores gráficos é a sua complexidade, sendo mais difícil de
aprender sua utilização em relação a outras aplicações. Segundo HODOROWICZ (2001),
existem vários subsistemas no motor gráfico como inteligência artificial, física, animação,
colisão, renderização, sons, etc. que devem operar em um motor gráfico.
O comportamento de um motor gráfico pode ser visto na Figura 3.5, nela são
mostrados todos os subsistemas de um motor.
Física Sistema de
Partícula
Entrada de
Eventos NÚCLEO
Detector de Inteligência
Colisão Artificial
Renderizaçã Renderizaçã
o do Vídeo o do Áudio
Subsistemas
Núcleo
Imagens Sons
Figura 3.5: Estrutura de um motor gráfico (GAMASUTRA, 2005).
Nessa estrutura, pode-se dizer que a entrada de eventos indica um dos três estados
possíveis para um botão (apertado, liberado ou mantida continuamente apertado), onde a ação
é decidida pelos desenvolvedores do jogo em resposta aos eventos apropriados. Na segunda
camada temos o núcleo que é o componente principal de um motor, e ele está relacionado
diretamente com todos os subsistemas Ele é responsável pela gerencia do motor em alto nível.
Segundo MAIA (2005), os subsistemas são componentes que garantem as principais
funcionalidades do motor, cada um deles é responsável por um aspecto especifico da
aplicação, bem como pela gerência desse aspecto em tempo de execução. Existem diversos
subsistemas, mas alguns deles são bastante importantes, abaixo serão listados alguns desses
subsistemas:
17
 Física: tenta simular uma física real, que engloba a gravidade, resistência, elasticidade,
fricção, entre outros, mas todos esses elementos podem ser completamente
manipulados pelo desenvolvedor. Ele calcula o movimento, rotação e resposta de
colisão de corpos rígidos aplicando física realista neles. Alguns motores suportam a
física de corpos não-rígidos, como fluídos.
 Sistema de Partícula: é um gerador de efeitos especiais que cria uma grande
quantidade de minúsculas partículas para resultados como explosão, fogo e fumaça.
Com uma boa elaboração dos efeitos de partículas, eles aparentam serem melhores que
animações pré-renderizadas por isso, grande parte dos jogos mais recentes estão
usando o sistema de partículas.
 Detector de Colisão: é encarregado de determinar interseções e a situação do contato
entre modelos tridimensionais, garantido precisamente o local da colisão, pois ele
detecta em qual polígono2 haverá o mesmo.
 Inteligência Artificial: é responsável pelo comportamento dos personagens controlados
pelo motor, a fim de se comportar diferente em cada situação existente no jogo, como
resolver problemas.
 Renderização do Vídeo: é responsável pela geração da resposta visual interativa. Ele é
um processo de geração de imagem a partir de um modelo, que é uma descrição
tridimensional de um objeto.
 Renderização do Áudio: encarregado pela geração de estímulos auditivos, sendo capaz
de reproduzir os efeitos sonoros do ambiente.
3.4 Jogos de Tiro em Primeira Pessoa

Segundo KHATUA e AGRAWAL (2005), o motor gráfico é o núcleo de um jogo. Ele
consiste de várias rotinas e serviços usados em cada jogo e fornece uma plataforma robusta,
usando-se em grande escala e diminuindo o tempo de desenvolvimento. As indústrias dos
jogos preferem utilizar motores voltados a jogos de tiro em primeira pessoa (FPS), pois existe
uma grande demanda no mercado de jogos para essa categoria, jogos como Quake 4 (ID
SOFTWARE, 2005), Half-Life 2 (VALVE, 2004), Battlefield 2142 (EA, 2007) e F.E.A.R.
(VU GAMES, 2005). Diferente de outros estilos de jogos como Role-Playing-Games (RPG) e
Real-Time-Strategy (RTS), que além de possuírem bons gráficos, tem como ênfase a uma
história bem elaborada que procura cativar o jogador, os jogos de FPS envolvem e fornecem
2
É uma figura plana formada por três ou mais segmentos de reta que se intersectam dois a dois.
18
ao usuário uma renderização bem realista no quesito física, efeitos especiais que são bastante
trabalhadas. Devido a essa razão, todos os avanços em qualidade visual e de física, são feitos
em jogos de FPS. Motores Gráficos modernos são aplicações que evoluíram gradualmente na
melhoria de seus subsistemas e hoje possui uma estrutura bastante complexa, voltada para a
diversão do jogador.
3.4.1 Subsistemas
Segundo KHATUA e AGRAWAL (2005), um motor gráfico com a finalidade de criar jogos
FPS necessita de dois subsistemas que são a geração e o processamento dos dados. Veja na
figura 3.6 a estrutura necessária para a criação de um jogo em primeira pessoa.
Processamento de Geração de Dados

Jogo Dados
Núcleo do Motor Editor de Níveis
Editor de Modelos
Dados do Jogo
Figura 3.6: Estrutura básica de um FPS.
Geração de Dados
KHATUA e AGRAWAL (2005) diz que é o subsistema responsável pela geração dos dados
denominado como “game-data”, que constitui a geometria dos níveis, modelos de jogadores e
inimigos, objetos estáticos que servem para povoar o mundo virtual e seus atributos.
O game-data é classificado em duas partes:
 Mundo estático (static world): é uma geometria estática, em grande escala, do mundo
virtual e alguns de seus componentes como paredes, andares, escadas, terrenos, etc.
Tudo é feito através do mesh, que são vários polígonos contínuos com sua determinada
textura, e muitas fontes de luz, que são processados com muita eficácia. O mundo
virtual é criado com um editor de nível que possui certas facilidades, como arrasta e
solta, dando a possibilidade uma construção rápida. O mesh é elaborado com adição ou
subtração de objetos primitivos como caixa, cilindro, cone, esfera e escadas, e
adicionando entidades como luzes e plataformas. Na Figura 3.7, podemos ver a
interface de um editor de níveis.
19
 Entidades móveis (objetos, jogadores, monstros, portas, plataformas, energia, munição,

armadura, etc.): é responsável por tudo que se move como inimigos, objetos, etc. O
editor de modelos importa modelos bastante populares, como os formatos MD2
(QUAKE 2, 1997) e MD3 (QUAKE 3, 1999), onde define atributos e comportamentos
específicos do motor. Os meshes dos modelos têm em média de 100 a 400 polígonos,
com uma única textura (skin), que é aplicada sobre eles. Na Figura 3.8 mostra a edição
de um modelo MD2.
Figura 3.7: Maplet, um editor de níveis gratuito (BLITZBASIC, 2007).
Figura 3.8: Edição de um modelo MD2.

20
Processamento dos Dados

Segundo KHATUA e AGRAWAL (2005), o processamento dos dados é responsável por
carregar e renderizar o game-data e também por controlar os subsistemas de som e tempo. Ele
fornece o controle das rotinas matemáticas (vetores, planos, matriz, etc.), gerenciamento de
memória, carregamento de arquivos, etc. Também pertence a esse subsistema o renderizador
3D.
Renderizador 3D é um processo automático que converte modelos 3D em imagens 2D
para ser exibido em uma tela, dependendo do usuário, pode ser inseridos efeitos que possam
deixar as imagens mais ou menos realistas.
O núcleo está diretamente relacionado com o processamento de dados, onde contêm
rotinas específicas para inicialização, controle da câmera, manipulação de vetores
matemáticos, renderização geométrica dos níveis, remoção de superfícies escondidas, texturas,
etc., também ele é fundamental para a conexão das entradas do usuário com suas ações no
jogo.

Motores gráficos são ferramentas voltadas para o desenvolvimento de jogos, e podem ser
divididos em duas partes, o núcleo e os subsistemas. O núcleo é o mais importante, pois ele
controla todos os subsistemas.
Os subsistemas são divididos por funcionalidades, como simulação física, inteligência
artificial, sistema de partículas, detector de colisões, renderizadores de áudio e vídeo. Um
motor gráfico necessário pra o desenvolvimento de um FPS, seria composto pela geração de
dados, que é responsável pela criação do game-data, no qual é dividido em duas partes, o
mundo estático e o móvel, e pelo processamento de dados, pois todos os modelos do game-
data são renderizados por ele.
Com a estrutura detalhada de um motor gráfico voltado para jogos de tiro em primeira
pessoa, a criação de um novo jogo teria como foco a criação de um mundo usando um editor
de níveis, e no desenvolvimento de modelos programando-os através de um editor. O motor
possui suporte à simulação física com a detecção de colisões, a gravidade, e a capacidade de
criar efeitos especiais de sistema de partículas, o necessário pra um simples desenvolvimento
FPS. Para este trabalho, será utilizado o motor gráfico não comercial Irrlicht. Este motor será
apresentado no capítulo seguinte.
21
Capítulo 4
Irrlicht
O Irrlicht é um motor de jogos completo, bastante rápido e fácil de aprender, mas por
enquanto não há muitos projetos comerciais que o utilize. Esse motor foi escolhido para
possibilitar o desenvolvimento na linguagem Java. Sua versão para Java é conhecido como
Jirr. Este motor está disponível para outras linguagens como Python, Lua, Basic, Ruby, Perl e
C#. No decorrer do capítulo serão apresentadas as funcionalidades do motor, alguns plugins e
trechos de códigos na linguagem Java (Jirr) como carregamento de meshs, eventos, áudio
através do IrrKlang, ou seja, suas principais funcionalidades.
4.1 Introdução
O motor gráfico Irrlicht é um motor orientado a objetos escrito em C++. Ele é um projeto de
código aberto com objetivo de ter um desempenho avançado e elevado. O Irrlicht pode ser
usado para desenvolvimento de jogos 2D ou 3D, ou para aplicações gráficas de aplicação
geral. A Figura 4.1 mostra a imagem de um projeto livre com alta qualidade gráfica usando
muitos dos recursos disponíveis no motor, e a Figura 4.2 mostra a imagem de um projeto
comercial desenvolvido pela Evolution Vault.
Figura 4.1: H-Craft Championship, jogo livre Figura 4.2: Galactic Dream: Rage of War,
no qual utiliza muito bem o sistema de jogo comercial que utiliza o motor gráfico
partículas. Irrlicht.
Ele é mais voltado para desenvolvimento de jogos, pois já possui a parte física do
motor implementada, onde existem vários métodos que lidam com detecção de colisão, mas
existem motores físicos livres que funcionam em paralelo com ele, que é o caso do Newton
22
(NEWTON, 2007) em C++, JNewton (JNEWTON, 2007) e o JOODE (JOODE, 2007) escrito
em Java. Alguns motores necessitam de um motor de física além do próprio motor gráfico,
eles podem ser livres ou comerciais. O Irrlicht vem com uma documentação excelente, e
integra todas as características das versões anteriores, que são:
 Sombras dinâmicas: sombras que podem variar dependendo da intensidade e direção
da luz, e suas projeções podem mudar conforme o terreno.
 Sistemas de partículas: responsáveis pelos efeitos especiais, como fogo, nuvens,
explosões, etc.
 Animação de objetos: movimentação e orientação de objetos.
 Detecção de colisão: determina precisamente em qual polígono houve a colisão.
Dependendo da regra do jogo, podem ocorrer inúmeros eventos.
O Irrlicht é multiplataforma, podendo funcionar atualmente em Windows, Linux e
Mac, tornando-o um motor com uma ótima portabilidade. Ele é conhecido por ter uma boa
velocidade, inúmeras funcionalidades e possuir uma curva de aprendizagem mínima. Como é
uma ferramenta de código aberto, ele é distribuído gratuitamente sob os termos de autorização
zlib/libpng, podendo ser utilizado livremente, até mesmo em projetos comerciais. Em caso de
modificações, a licença alerta para as seguintes restrições:
1. A origem deste programa de computador não pode ser apresentada de forma

errônea; você não pode reivindicar ter escrito o programa de computador original.
Se você usar esse programa de computador em um produto, um reconhecimento de
créditos na documentação do produto seria apreciada, mas não é exigida.
2. Versões alteradas do código-fonte devem estar marcadas como tais, e não podem
ser apresentadas forma errônea, como sendo o programa de computador original.
3. Este aviso não pode ser alterado ou removido de qualquer distribuição de código
fonte. (ZLIB/LIBPNG, 2006).
Segundo GEBHARDT (2003), chefe do projeto Irrlicht, a RABCAT Computer

Graphics (RABCAT, 2007) desenvolveu um motor gráfico utilizando-o, chamado de
RABCAT engine (RABCAT ENGINE, 2007). Essa empresa já desenvolve games para
consoles de ultima geração como o PlayStation 3 (PS3), XBOX360 e XBOX. Futuramente ela
poderá utilizar esse motor para novos jogos.
23
4.2 Características
Em sua configuração básica (default), esse motor possui suporte a vários formatos de mesh e
imagens sem a necessidade de plugins, entretanto, para agilizar o desenvolvimento de jogos, o
Irrlicht possui alguns AddOns, que são aplicativos com a finalidade de facilitar a criação de
objetos, movimentos, sons, e a leitura de alguns arquivos específicos, entre outros. Algumas
características presentes em todas as versões do Irrlicht já foram citadas, e conforme o site
oficial, as principais são: (IRRLICHT, 2007).
 Alto desempenho em tempo real na renderização 3D, usando renderizadores como
Direct3D e OpenGL.
 Plataforma independente. Funciona em Windows95, 98, NT, 2000, XP, Linux e
MacOS.
 Biblioteca interna que permite trabalhar com pixel shader 1.1 (manipula pixels, para
aplicar efeitos em uma imagem, como realismo, rastro de colisão, sombras, e efeitos
explosivos) e vertex shader 3.0 (trabalha no esqueleto de vértices do modelo 3D e com
isso alcança melhores animações do que seria possível sem ele).
 Renderização das cenas de modo hierárquico.
 Rápida e fácil detecção de colisão e de resposta.
 Leitura direta de arquivos compactados no formato zip (formato de compactação de
arquivos).
 Vários efeitos especiais através dos sistemas de partículas, como realismo nas
superfícies da água, iluminação dinâmica, sombras dinâmicas, transparência de
objetos, mapeamento das luzes, partículas customizáveis de neve, fumaça, fogo, entre
outras, mapeamento esférico, animação de texturas e fog (efeito de fumaça, nuvem).
 Suporta texturas nos seguintes formatos: Adobe Photoshop (.psd), formato JPEG
(.jpg), Portable Network Graphics (.png), Truevision Targa (.tga), Windows Bitmap
(.bmp), e Zsoft Paintbrush (.pcx).
 Suporta meshes nos seguintes formatos: 3D Studio meshes (.3ds), B3D files (.b3d),
Alias Wavefront Maya (.obj), Cartography shop 4 (.csm), COLLADA (.xml, .dae),
DeleD (.dmf), FSRad oct (.oct), Irrlicht scenes (.irr), Microsoft DirectX (.x) (binário e
texto), Milkshape (.ms3d), My3DTools 3 (.my3D), OGRE meshes (.mesh), Pulsar
LMTools (.lmts), Quake 3 levels (.bsp), Quake 2 models (.md2). Na Figura 4.3, mostra
-se a leitura de um arquivo *.md2.
24
 Efeitos sonoros 2D e 3D com o irrKlang (motor gratuito de sons 3D). O irrKlang

também é considerado um plugin, mas ele foi integrado nas versões mais recentes do
motor.
Figura 4.3: Md2 visto em uma interface gráfica do próprio Irrlicht.
4.2.1 Plugins
Com a finalidade de agilizar e adicionar funcionalidades, o Irrlicht tem vários plugins ou
AddOns. Um plugin pode ler e escrever um arquivo específico e, para os arquivos com a
extensão .irr, foi criada a ferramenta gráfica irrEdit, que é usado para desenvolver alguns
sistemas de partículas, visualização de meshes, e editção de níveis. A Figura 4.4 apresenta a
interface desse editor.
25
Figura 4.4: irrEdit, editor livre, bastante completo para o Irrlicht.
Alem desse editor, existem vários outros plugins, com diversas funcionalidades.
 irrKlang: biblioteca livre para sons 2D e 3D, e possui uma interface similar ao do
Irrlicht.
 DeleD DMF Loader: carrega arquivos do tipo .dmf para o Irrlicht. DeleD é um editor
gráfico com diversas facilidades em edição de níveis, possui versão livre e comercial.
 ICE - Irrlicht Common Engine Framework: proporciona a criação do esqueleto do
projeto, resultando em uma produção rápida de um jogo.
 My3D: ferramenta feita para exportar o mapeamento das luzes de uma cena para outras
extensões 3D (3DSMAX5, 3DSMAX6, 3DSMAX7 e Giles) diretamente no Irrlicht.
 Zenprogramming: primeiro renderizador não oficial de terrenos para o Irrlicht.
 IrrWizard: criação de um projeto Irrlicht através de um wizard, que é um assistente de
interface gráfica e de uso simplificado para realização de tarefas, dividido em passos.
4.3 Jirr
Jirr é a ligação da linguagem Java com o motor gráfico Irrlicht, herdando todas as
características e funcionalidades. A sua versão mais atual é a 1.3, nela já vem integrado o
jirrKlang, versão Java do irrKlang, plugin responsável por sons 2D e 3D.
26
Para o funcionamento do Jirr na plataforma Windows, é necessário configurar

variáveis de ambiente com o caminho dos arquivos D3DX81ab.dll, necessário para
renderização, irrKlang.dll, responsável para efeitos sonoros, e irrlicht_wrap.dll, que é uma
biblioteca chamada em todas as aplicações Jirr. Além disso, também é necessário a inclusão
de dois pacotes no projeto Java: jirr13.jar e jirrklang.jar.
Na Figura 4.5 é mostrado a inicialização do Jirr em Java.
Figura 4.5: Inicialização do motor em Java.
4.3.1 Renderização
A renderização no Jirr pode ser realizada através do Direct3D9.0, Direct3D8.1 (DIRECT3D,
2007), OpenGL1.2 (OPENGL, 2007), por Software, ou também pode-se optar por não utilizar
renderizador, onde não é feito nenhum desenho, útil para as aplicação que não precisa de
visualização.
Após a inicialização, é necessária a escolha de qual renderizador utilizar. Isso é feito
através da classe E_DRIVER_TYPE e nela pode-se configurar: a resolução do vídeo, quantos
bits de cores utilizar, se utilizará tela cheia ou não, além de determinar se haverá eventos ou
não.
4.3.2 Interface Gráfica

Com o vídeo configurado, a classe da interface gráfica IGUIEnvironment é utilizada conforme
a necessidade, podendo colocar textos, fontes, componentes como botão, combobox, checkbox
27
e listbox, objetos, bordas, imagens, entre outras opções disponíveis. A Figura 4.6 demonstra
como utilizar um renderizador, configurar o vídeo, e adicionar um botão na interface gráfica.
Figura 4.6: Configuração de vídeo, e adição de um botão.
4.3.3 Inserção de Elementos

Para adicionar elementos que irão compor a cena é preciso utilizar a classe ISceneManager.
Esta classe pode carregar meshes animados, objetos, câmeras, terrenos, textos, luzes, sistemas
de partículas, caixas, esferas, cubos, mapeamento de teclas, superfícies de água, criar colisões,
cria animações com todos os tipos de objetos carregados, desenhar todas as cenas, entre outras
opções.
A posição dos elementos no mundo virtual é definida pela classe vector3df que estende
a classe Object. Nela configuram-se X, Y e Z que são valores do plano cartesiano 3D.
As cores do ambiente são definidas através do renderizador escolhido, e ao chamar o
método beginScene, pode-se configurar o backBuffer, que é uma tela virtual na memória onde
se desenha todo o cenário para depois ser enviado para o vídeo, o zBuffer, que consiste em
mostrar apenas o pixels mais perto da tela, e as cores, através da classe SColor. Esta ultima
classe utiliza-se quatro campos, o primeiro responsável pela transparência, e os outros pela
28
intensidade do vermelho, verde e azul, conhecidos como RGB, todos podendo variar de 0 a
255.
Para carregar um mesh, que são modelos, terrenos, ou cenários, é necessário o uso de
duas classes: IAnimatedMesh e IAnimatedMeshSceneNode. Elas recebem um objeto do tipo
ISceneManager que tem como objetivo carregar um mesh. É possível carregar modelos do
Quake2 (extensão .md2), cenários do Quake3 (extensão .bsp), entre outros.
Um modelo animado md2 costuma ser dividido em dois meshes, um dedicado para o
modelo em si, e outro dedicado para algum objeto que ele carrega: ou modelos que são
divididos em membros superiores e inferiores. Sendo assim é necessário o carregamento dos
dois meshes na mesma coordenada do plano cartesiano, e a inicialização ao mesmo tempo de
ambos, para que se tenha um modelo completo com animações sincronizadas.
Nos cenários do Quake3, é necessário o uso de um método para abrir o arquivo devido
ao seu formato compactado, (do tipo .pk3). Após aberto, é possível utilizar de seus arquivos
de textura e de mesh (no formato .bsp). A Figura 4.7 apresenta o carregamento de um cenário,
e a Figura 4.8 apresenta a visualização do mesmo.
Figura 4.7: Carregamento de um cenário Quake3.

29
Figura 4.8: Mesh carregado pelo Jirr.
4.3.4 Tratamento de Eventos

Na classe em que há os eventos, é necessária a extensão da classe IEventReceiver, responsável
por receber e executar os eventos através do método booleano OnEvent. Cada evento das
teclas deve ser tratado individualmente, o que pode ser feito com uma estrutura de seleção
múltipla (switch/case em Java).
4.3.5 Som
A inserção de sons é feita através do dispositivo irrKlang. A Figura 4.9 mostra o
desenvolvimento de eventos e a utilização de efeitos sonoros.
30
Figura 4.9: Trecho com exemplos de eventos implementados.

O Irrlicht tem a capacidade e as funcionalidades que vários motores comerciais possuem.
Segundo GEBHARDT (2003) do site oficial do motor, existem patchs para leitura de modelos
modernos utilizados em jogos como Quake 4, e Doom 3. Com essa possibilidade, pode-se
utilizá-lo para desenvolvimento de jogos com alto nível de qualidade, o que já é possível
utilizando-se os modelos carregados por padrão.
Levando em consideração que esse motor gráfico é livre e com bastante
funcionalidades, ótimo desempenho e de rápida aprendizagem, e que possui versões em
muitas linguagens, ele será utilizado no próximo capitulo para o desenvolvimento de um jogo
BETA em FPS, no qual haverá um mundo virtual com tratamento de algumas colisões, efeitos
de tiros, e a manipulação de um modelo que irá interagir nesse mundo. Esse capitulo
descreverá o ciclo de desenvolvimento do jogo.
31
Capítulo 5
Desenvolvimento
Neste capítulo, documentam-se algumas etapas do ciclo de desenvolvimento de um

ambiente 3D, utilizando o motor gráfico Jirr, versão Java do Irrlicht. Neste ambiente, são
colocados modelos do jogo Quake 2, com o intuito deste ambiente tornar-se um jogo em
primeira pessoa (FPS). Será mostrada a estrutura do protótipo desenvolvido, apresentando
trechos de códigos e o diagrama de classe do projeto.
5.1 Introdução
A linguagem Java, tem uma má reputação para desenvolvimento de jogos desktop. Muitos
desenvolvedores têm costume de usar outras linguagens, como C/C++ e Assembly, para o
aumento de desempenho.
Segundo “boaglio”, o moderador do fórum GUJ (SILVEIRA et. al), em uma palestra
sobre jogos em Java do Sun Tech Days de 2005 um palestrante disse que “antigamente o
programador colocava a culpa no processador pra justificar a lentidão do jogo, hoje ele
culpa a linguagem”. Pode-se dizer que existe um grande paradigma no quesito desempenho,
pois muitos desenvolvedores, por ter uma idéia formada sobre Java não arriscariam
desenvolver jogos utilizando esta linguagem. Uma outra dificuldade em utilizar essa
linguagem é a programação em 3D, mas o aparecimento de motores gráficos para essa
plataforma resolve este problema e possibilita o desenvolvimento de jogos utilizando Java.
Em alguns casos, pode-se dizer que a linguagem Java possui desempenho igual, ou até
superior que jogos feitos em C/C++. Segundo ZICKNER (2004) et al., o Jake, projeto no qual
migrou toda a plataforma do Quake 2 para Java, está como prova. Foi usado o jogl e o
fastjogl, que são bibliotecas OpenGL para o Java. A Tabela 5.1 possui um comparativo de
performance do código original e as versões lançadas em Java e a Figura 5.1 mostra o jogo em
execução.
32
Tabela 5.1: Comparativo de desempenho do código original e a versão Java.

System Original C Code Jake2-0.9.1 Jake2-0.9.2 Jake2-0.9.3 Jake2-0.9.4
JRE 1.5 jogl JRE 1.5 fastjogl JRE 1.5 fastjogl JRE 1.5 fastjogl/lwjgl
AMD Athlon XP 2400
Geforce4 MX
245 fps 172 fps 213 fps 241 fps 260/250 fps
Windows 2000
800x600 window
AMD Athlon XP 2400
Geforce4 MX Não
315 fps 225 fps 235 fps 250/282 fps
Windows 2000 suportado
800x600 fullscreen
AMD Athlon XP 2400
Geforce4 MX
262 fps 141 fps 212 fps 215 fps 228/240 fps
Linux
800x600 window
AMD Athlon XP 2400
Geforce4 MX
56 fps 21 fps 31 fps
Linux
800x600 fullscreen
Figura 5.1: Jake versão Java do Quake 2.
Para o desenvolvimento de um jogo, é preciso utilizar o conceito de ciclo de

desenvolvimento. Nesse ciclo é relatado todo o processo de desenvolvimento de um jogo, e é
33
dividido por etapas como: Braimstorming, Game Design, Document Design, Level Design,
entre outras. Este projeto não desenvolveu todas as etapas, sendo apresentadas somente
aquelas que foram realizadas. O projeto foi desenvolvido na linguagem Java, com a integração
do motor gráfico Jirr, o ambiente de programação usado foi o NetBeans 5.5, e o
desenvolvimento do diagrama de classes foi realizado com UML Visual Paradigm, além de
utilizar algumas ferramentas de edição de imagem.
5.2 Ciclo de desenvolvimento

Para o desenvolvimento de um jogo é necessária uma equipe, onde cada um tem uma área a
atuar, como modelagem, editoração de imagem e sons, programação, entre outros. As etapas
realizadas serão descritas a seguir.
No Braimstorming, que é fase na qual acontece a discusão do tipo e de como vai ser
desenvolvido o jogo, decidiu-se que o projeto será um jogo de tipo em FPS, e que todos os
modelos utilizados serão do jogo Quake 2, pois estão disponíveis gratuitamente na internet. O
jogo é composto de apenas uma fase no estilo deathmatch, que é um cenário aberto, sem
labirintos, sendo mais fácil a localização de um adversário, garantindo assim mais ação no
jogo. Essa fase possui três missões, com objetivos similares, que é eliminar inimigos distintos.
No Game Design, responsável pelas características do jogo como jogabilidade, tipos de
ataque, controles, etc., foi definido que esse jogo possui apenas um personagem controlável
que possui somente uma arma, e que seus movimentos são compostos por andar, abaixar,
atirar, pular, e fazer rolamento. Esses controles matem-se iguais a maioria dos jogos de
primeira pessoa. A Tabela 5.2 mostra os eventos de cada tecla utilizada no jogo.
Tabela 5.2: Eventos.

Teclas Eventos
Botão esquerdo do mouse Atirar
Botão direito do mouse Pular
Setas Direção do personagem
Mouse Controle do olhar e mira
No Document Design, responsável pela descrição jogo além da idéia citada na fase de
Braimstorming, foi feita uma pequena descrição do jogo, essa definição não é muito
elaborada, pois se trata de um jogo simples e de estudo de possibilidades. O jogo ele consiste
de um personagem que se movimenta em um cenário em busca de seus inimigos. Possui três
34
missões no total, onde, cada uma delas consiste em derrotar um grupo de inimigos. A primeira
é derrotar um grupo de três inimigos, as demais, apenas um.
Level Design consiste em determinar o desafio do jogo, como o jogador irá vencer ele.
No jogo elaborado, após o jogador concluir as missões, ele será vitorioso.
O jogo está em fase de detecção de bugs, ou seja, em fase de correção, mas ainda não é
o Beta, pois falta algumas funcionalidades pra que ele chegue a essa etapa. Funcionalidades
como colisão com o inimigo, colisão do projétil com o inimigo, e alguns mapeamentos das
teclas funcionais do jogo estão pendentes. Este exemplo é voltada para o aprendizado da
utilização do motor gráfico e suas funcionalidades, mostrando como é possível o
desenvolvimento de jogos de alto nível e comerciais com a linguagem Java.
As etapas do ciclo de desenvolvimento que não foram executadas são: cronograma,
demo, Beta, teste e versão final. A Figura 5.2 demonstra as etapas realizadas neste projeto.
Braimstoming Game Design
Document Design Level Design
Estado no qual se encontra

o projeto. Fase de correção.
Figura 5.2: Etapas realizadas no desenvolvimento do jogo.
5.3 Classes
Para uma melhor organização dos arquivos do projeto, dividiu-se as classes (armazenados na
pasta src) dos arquivos de mídia (Armazenados em media). Os arquivos de mídia
compreendem os modelos, os componentes, as imagens e os sons.
Para o desenvolvimento do jogo foram desenvolvidas oito classes. Elas serão
mostradas através de um diagrama de classe para um melhor entendimento, em seguida
comentando seus métodos e as suas funcionalidades, e o motivo delas existirem. A
representação do jogo em diagrama de classe está na Figura 5.3, onde é possível ver o
relacionamento do mesmo.
35
Figura 5.3: Diagrama de classe do jogo.
A estrutura do jogo é simples, existindo uma classe que determina qual renderizador
usar e uma que controla todos os componentes e modelos inseridos no jogo.
A classe Principal, é responsável em chamar as opções existentes de renderizadores na
classe OpcaoRenderizador, onde essa faz chamadas dos eventos da classe GameEventos e da
estrutura do jogo, a EstruturaGame, nessa é montada o jogo, pois carrega os modelos do
personagem principal que está na classe ModelosGame e dos inimigos na InimigosGame, o
36
mapa em GameMapas e os componentes em ComponentesGame. O jogo é composto pelas

seguintes classes:
 Principal: carrega as bibliotecas do motor gráfico e de som. Onde inicia o som do
jogo. Instancia-se um objeto do tipo OpcaoRenderizador, responsável pelas opções de
renderização.
 OpcaoRenderizador: nela tem uma instanciação de um objeto da classe GameEventos,
responsável pelo mapeamento das teclas. Ela utiliza recursos da biblioteca swing
(existente no Java) para criar botões com as opções de renderizadores, que são:
Direct3D 9, Direct3D 8, OpenGL 1.2/1.3, Software Renderer e Null Device. O
Software Renderer é uma alternativa para se usar um renderizador compatível com
quase todas as placas, e o Null Device, quando não se quer usar renderizador. Após a
escolha do dispositivo, monta-se uma interface gráfica para o jogo.
 GameEventos: classe que trata o mapeamento das teclas, ela utiliza métodos estáticos
da classe ModelosGame, pois cada tecla pressionada ativa uma animação diferente do
modelo.
 ModelosGame: nela são desenvolvidos todos os estados do modelo, através de
métodos estáticos, que controlam animações como, andar, abaixar, abaixar e andar,
atirar, pular e padrão (default) que é um método chamado quando não ocorre nenhum
evento pela classe GameEventos. Além dos estados possíveis do modelo, ela possui
um método estático responsável pelo desenho do rosto do personagem na tela.
 EstruturaGame: configura a interface gráfica do jogo e das cenas, onde foram
adicionados textos e imagens. Nela é chamada métodos estáticos das classes
GameMapas, ModelosGame, InimigosGame e ComponentesGame, responsáveis por
montar o jogo.
 GameMapas: representa o terreno utilizado com sua escala e seu nivel mais alto e mais
baixo, resultando em um efeito de montanhas. São carregadas três tipos de textura,
uma textura global para o terreno, e as outras duas responsáveis pelos detalhes do
mesmo, utilizando efeitos sobre eles.
 ComponentesGame: classe responsável por inserir desenhos que representam a energia
e a munição do personagem do jogo.
 InimigosGame: utiliza modelos *.md2 para se adicionar no mapa, esses modelos
possuem uma escala de dez vezes o tamanho do personagem controlado, pois é mais
37
fácil a sua localização no terreno. Nessa classe também possui um método estático
responsável pelos rostos dos inimigos.
Com as funcionalidades das classes documentadas serão expostas algumas
funcionalidades para uma melhor compreensão. Serão mostradas: a criação de um terreno,
inserção de textos e imagens, o posicionamento da câmera, e o funcionamento da colisão com
o terreno (único efeito de física desenvolvido), pois convencionalmente usam-se motores de
física próprios para essa funcionalidade, como o JNewton.
5.3.1 Criação de Terreno

Depois de se carregar a interface gráfica do motor gráfico, que é configurada com a
instanciação de um objeto do tipo IGUIEnvironment, o ambiente virtual deve ser especificado.
Existem duas maneiras de se criar um terreno: utilizar uma estrutura já existente comumente
utilizada em jogos como Quake 3, ou criar um terreno. Para esse ambiente simples, será
utilizada a geração de um terreno por ser mais fácil de trabalhar do que uma estrutura feita,
uma vez que seria necessária a criação de um terreno com as dimensões e deformidades exatas
para que os dois se complementassem perfeitamente. A Figura 5.4 apresenta o código-fonte da
criação de um terreno.
Figura 5.4: Criação de um terreno.
Para criar o terreno, é necessária a instanciação de um objeto do tipo

ITerrainSceneNode, que no exemplo do código chama-se terrain. Pode-se adicionar texturas
através do método de um objeto do tipo ISceneManager, chamado no código de smgr. Ao
decidir a escala é necessário definir um vector3df para o tipo float, ou vector3di para o tipo
inteiro, com três valores X, Y e Z representando as escalas para as três direções. Com método
setMaterialFlag(), pode-se determinar alguns efeitos sobre o terreno: o EMF_LIGHTING
38
como padrão está ativado, ao desativa-lo, a textura do terreno fica com uma melhor
iluminação. Existem vários efeitos como EMF_ANISOTROPIC_FILTER,
EMF_BACK_FACE_CULLING, EMF_BILINEAR_FILTER, EMF_FOG_ENABLE,
EMF_GOURAUD_SHADING, entre outros. Foi determinado mais dois tipos de texturas que
sobrepõem a aplicada sobre o terreno, ocasionando um efeito muito mais detalhado sobre a
superfície, para selecionar as texturas usa-se o método setMaterialTexture().
5.3.2 Inserção de Imagens

Para inserir texturas que simulam o plano exterior do terreno é necessário usar o método
addSkyBoxSceneNode(), que pertence ao objeto smgr, nele pode-se adicionar seis texturas,
uma para cada face de um cubo, chamado de skyBox, representando o exterior. A Figura 5.5
define um skyBox, a Figura 5.6 mostra apenas o terreno carregado e a Figura 5.7 um terreno
com skyBox.
Figura 5.5: Criação de um skyBox.
Figura 5.6: Terreno carregado sem o skybox. Figura 5.7: Terreno carregado com skyBox.
39
5.3.3 Colisão
Com o terreno gerado e texturizado, deve-se criar a colisão da câmera com o terreno através
de uma instanciação de um objeto do tipo ITriangleSelector, e configurar o objeto terrain pelo
método setTriangleSelector(). Depois é necessário um objeto do tipo ISceneNodeAnimator
para definir o que vai colidir, no caso a câmera e o terreno. A Figura 5.8, mostra como é feito
esse procedimento.
Figura 5.8: Criação de colisão.
5.3.4 Inserção de modelos

Após configurar as colisões, é determinado o local onde o modelo controlado será
posicionado. Pode ser em frente à câmera, dando uma característica de um jogo de terceira
pessoa, ou muito próximo a câmera, tornando-se um jogo de primeira pessoa. O modelo é
composto por dois arquivos de meshes, seu corpo e sua arma. Ambos têm que estar com a
mesma escala, rotação e posicionamento no mundo virtual. Para adicionar o modelo, é
necessário pegar a posição da câmera, pois a partir dela que será introduzido o personagem do
jogo, acompanhando todos os movimentos realizados pela câmera. Será necessária a utilização
de duas classes para montar o modelo: IAnimatedMesh e IAnimatedMeshSceneNode. A
primeira classe serve para carregar um modelo e a segunda, para definir texturas, posições,
escalas e rotações. A definição da animação do modelo é feita pelo método
setMD2Animation(), onde se determina todos os movimentos possíveis. Na Figura 5.9 e 5.10,
são mostrados os modelos carregados em terceira e primeira pessoa respectivamente, e a
Figura 5.11 apresenta a carga e a definição do tipo de animação do modelo.
40
Figura 5.9: Terceira pessoa. Figura 5.10: Primeira pessoa (FPS).
Figura 5.11: Carregamento de meshes, e suas configurações.
O carregamento dos inimigos é o mesmo processo do modelo controlado, mas ele será
posicionado em relação ao plano, e não em relação à câmera. Para configurar, basta de deixar
41
de chamar o método setParent(). A Figura 5.12 mostra os métodos que devem ser chamados
para a configuração do modelo dos inimigos.
Figura 5.12: Métodos necessários para carregar um modelo no ambiente 3D.
5.3.5 Tratamento de Eventos

Para configurar os eventos, com suas respectivas animações, é necessário criar métodos que
representam cada um deles. Nesses outros métodos, é preciso definir somente a animação pois
sua configuração inicial de escala, posicionamento, rotação, texturas e modelos, serão
mantidas. Os tipos básicos de uma animação são:
 Parado: setMD2Animation(EMD2_ANIMATION_TYPE.EMAT_STAND);
 Correr: setMD2Animation(EMD2_ANIMATION_TYPE.EMAT_RUN);
 Abaixado:setMD2Animation(EMD2_ANIMATION_TYPE.EMAT_CROUCH_STAND);
 Pulo: setMD2Animation(EMD2_ANIMATION_TYPE.EMAT_JUMP);
 Ataque: setMD2Animation(EMD2_ANIMATION_TYPE.EMAT_ATTACK);
Os eventos são configurados através de uma classe que estende IEventReceiver. Por
meio dessa classe, podem-se configurar os eventos das teclas e do mouse. A Figura 4.9 mostra
um exemplo com mapeamento de duas teclas.
5.3.6 Inserção de elementos na GUI

As adições de textos podem ser realizadas através de componentes da interface gráfica ou por
imagens. Para modificar de fontes, é necessário o uso de imagens, pois na versão em Java do
motor gráfico, diferente do C++, ainda não foi incluído nenhum recurso para o uso das fontes
TrueType Font.
No jogo, para adição de textos, foram usados os dois tipos, componentes da GUI e
imagens. Foi criado um objeto do tipo recti que representa um retângulo, e nele adicionado
textos. Em seguida esse componente foi inserido na GUI pela classe IGUIStaticText, nela é
necessário o objeto do tipo recti, e um texto do tipo String. A Figura 5.13 mostra o seu
desenvolvimento e a Figura 5.14, o seu resultado.
42
Figura 5.13: Inserção de textos através de componentes da GUI.
Figura 5.14: Imagem de textos com uso do recti.
E para o carregamento de imagens na GUI, é necessário o uso do método addImage(),

no objeto da classe IGUIEnvironment, como mostra a Figura 5.15. Esse é o procedimento
usado em todas as imagens e textos em formatos de imagens. Para o personagem controlado
pelo usuário e os inimigos, foram adicionadas as imagens de seus rostos, textos relacionados
com energia e munição. Todas as imagens foram salvas com transparências (formato PNG),
conseguindo um efeito mais sofisticado. A Figura 5.16 e 5.17 exibem o carregamento de todas
as imagens na GUI, em terceira e primeira pessoa respectivamente, oferecendo uma
perspectiva mais adequada para jogos de ação.
Tabela 5.15: Carregamento de imagens na GUI.

43
Figura 5.16: Imagem carregada na interface Figura 5.17: Imagem carregada na interface
gráfica, em terceira pessoa. gráfica, em primeira pessoa (FPS).
A Figura 5.18 apresenta como fica o ambiente com todos os inimigos e componentes
carregados.
Figura 5.18: Imagem com todos os modelos, e componentes carregados.

44

Esse capítulo demonstrou o que é necessário para o desenvolvimento de um ambiente 3D,
usando um motor gráfico, voltado pra o desenvolvimento. Foi configurado o terreno, a
movimentação da câmera, e a execução de algumas animações do modelo. São os primeiros
passos para o desenvolvimento de um jogo, mas é imprescindível também o uso de um motor
de física, uma vez que, com ele, são possíveis efeitos muito mais realistas.
Pode-se dizer também que a linguagem Java, além de seu foco para dispositivos
móveis, está começando a alcançar o desenvolvimentos de jogos 3D para desktop.
45
Capítulo 6
Conclusões
Para se desenvolver um jogo é necessário também ter conhecimento do que o mercado está
interessado. Segundo a BBC BRASIL (2007), com a evolução da banda larga, os jogos on-line
do gênero MMORPG estão entre a preferência do mercado, jogos como: World Of Warcraft,
Lineage 2 e Star Wars Galaxies. Jogos no qual são cobradas mensalidades para se jogar
estimam-se que no mercado americano de assinaturas chegou ao valor de US$576 milhões
enquanto a Europa conseguiu um valor no mercado de US$299 milhões.
Para entender como se comporta um motor gráfico, foi feita uma pequena análise sobre
sua arquitetura, a fim de compreender melhor toda a sua estrutura junto com seus subsistemas.
Subsistemas como: simulação física, inteligência artificial, sistema de partículas, detector de
colisões, renderizadores de áudio e vídeo, foi possível começar a desenvolver um jogo
utilizando essa tecnologia.
A utilização do Irrlicht foi crucial, pois possui um ótimo desempenho e é de rápida
aprendizagem. Com ele é possível a criação de jogos de alto nível de qualidade. Com a
utilização de motores gráficos e de física é possível criar jogos realistas, e com uma grande
chance de sucesso se for feito todos os ciclos de desenvolvimento, onde exige a participação
de uma equipe para a criação de um jogo grande e de qualidade. Para os interessados em
desenvolvimento de jogos, é aconselhado que se junte um grupo, onde cada um terá sua
função, e que estejam relacionadas com as tarefas que devam ser executadas.
A integração do Irrlicht e Java resultou na geração de um terreno, movimentação de
câmeras, carregamento de modelos, e a execução de animações do mesmo. Espera-se que
brevemente a linguagem Java esteja voltada para jogos, não apenas em dispositivos móveis,
mas sim para jogos desktop.
Essa integração não tem todas as funcionalidades em relação a patchs existentes ao
Irrlicht, no qual ajudam a utilizar fontes true types, carregar outros tipos de meshes, como
MD3, e até um wizard, no qual ajuda a criar um game em FPS. Isso foi uma pequena
dificuldade pra quem está aprendendo a utilizar o motor, pois foi necessária a criação de uma
estrutura própria, salvar fontes como imagens e utiliza-los como componentes, e carregar
meshes um pouco antigo, como os do Quake 2.
46
A utilização dessa linguagem para o desenvolvimento proposto, foi o inicio do

rompimento do receio com a mesma, uma vez que os computadores atuais estão com uma
performance bastante elevada, garantido um bom desempenho mesmo com aplicações 3D.
Existe a possibilidade de concluir um jogo, ou até mesmo esse protótipo utilizando
essa tecnologia, e futuramente poderá ser feito um comparativo direto entre as versões C/C++
e Java, relatando o desempenho de cada um.
47
Referências
AXIOM ENGINE. (2007). Axiom Engine. Disponível em

http://axiomengine.sourceforge.net/wiki/index.php/Main_Page Visitado em 20/06/2007.
BATTAIOLA, André Luiz; RIBAS, Viviane Gaspar; MONTENEGRO, Bruna Cozer;
ANDRADE, Joana Fernandes de; KIRA, Gustavo. (2004). O papel do designer no
desenvolvimento de jogos de computadores. Disponível em
http://www.universia.com.br/materia/materia.jsp?id=5941. Visitado em 02/05/2007.
BBC BRASIL. (2007). Mercado de jogos online chegou a US$ 1 bi em 2006, diz estudo.
Disponível em
http://www.bbc.co.uk/portuguese/reporterbbc/story/2007/03/070321_mundovirtualmercad
ofn.shtml. Visitado 26/06/2007.
BETHESDA GAME STUDIOS. (2007). Bethesda Game Studios. Disponível em
http://www.bethsoft.com/ Visitado em 28/06/2007.
BIOWARE. (2007). BioWare. Disponível em http://www.bioware.com/ Visitado em
22/06/2007.
BITTENCOURT, João Ricardo; GIRAFFA, Lucia Maria. (2003). Modelando Ambientes de
Aprendizagem Virtuais utilizando Role-Playing Games. Dissertação de mestrado,
Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS), Porto Alegre, p. 2.
BLENDER. (2007). Game Engine with 2.25 physics. Disponínel em
http://www.blender.org/development/release-logs/blender-233/game-engine-with-225-
physics/ Visistado em 25/06/2007.
BLITZBASIC. (2007). Maplet. Disponível em
http://www.blitzbasic.com/Products/maplet.php Visitado em 17/06/2007.
CRYTEK. (2007). Crytek CryEngine2. Disponível em
http://www.crytek.com/technology/cryengine-2/specifications.html Visitado em
23/06/2007.
CRYSTAL SPACE. (2007). Crystal Space. Disponível em
http://www.crystalspace3d.org/main/Main_Page Visitado em 19/06/2007.
DARKPLACES. (2007). LordHavoc’s DarkPlaces. Disponível em
http://icculus.org/twilight/darkplaces/ Visitado em 18/06/2007.
48
DEVWORKS. (2007). Devworks Game Technology. Disponível em

http://www.devworks.com.br/principal/site.asp?val=0 Visitado em 26/06/2007.
DIRECT3D. (2007). DirectX. Disponível em
http://www.microsoft.com/downloads/details.aspx?familyid=9216652f-51e0-402e-b7b5-
feb68d00f298&displaylang=en Visitado em 15/06/2007.
DOOM 3 ENGINE. (2007). Id Software. Disponível em
http://www.idsoftware.com/business/idtech4/ Visitado em 21/06/2007.
EA. (2007). Eletronic Arts. Disponível em http://www.ea.com/home.jsp Visitado em
12/06/2007.
EARTH 2150. (2007). Earth 2160. Disponível em
http://www.earth2150.cn/Earth2160/doc/engine.htm Visitado em 20/06/2007.
ENTERBRAIN. (2007). Enterbrain. Disponível em http://www.enterbrain.co.jp/index.html
Visitado em 25/06/2007.
EPIC GAMES. (2007). Epic Games. Disponível em http://www.epicgames.com/ Visitado em
24/06/2007.
FALCO, Alessandra de. (2004). Desenvolvedoras de jogos de olho na mobilidade. Disponível
em http://webinsider.uol.com.br/index.php/2004/10/02/desenvolvedoras-de-jogos-de-olho-
na-mobilidade/. Visitado em 06/05/2007.
GAMASUTRA. (2005). Threading 3D Game Engine Basics. Disponível em
http://www.gamasutra.com/features/20051117/gabb_01.shtml Visitado em 15/06/2007.
GEBHARDT, Nikolaus; Alten, Thomas; Stehno, Christian; Davison, Gareth; Celis, Alvaro F.;
Goewert John; Jam. (2003). Projects Using Irrlicht. Disponível em
http://irrlicht.sourceforge.net/screenshots-projects.html. Visitado em 21/05/2007.
HODOROWICZ, Luke. (2001). Elements of Game Engine. Disponível em
http://www.flipcode.com/tutorials/tut_el_engine.shtml Visitado em 19/06/2007.
HUIZINGA, Johan H. (1938). Homo Ludens - A Study of the Play-Element in Culture.
Routledge.
ID SOFTWARE. (2007). Id Software. Disponível em http://www.idsoftware.com/ Visitado
em 26/06/2007.
IMPA, Instituto Nacional de Matemática Pura e Aplicada. (2007). Teoria dos Jogos Não
Cooperativos. Disponível em http://webold.impa.br/Disciplinas/Ementas/9.3.30.html.
49
IRRLICHT. (2003). Irrlicht - Lightning Fast Realtime 3D Engine. Disponível em

http://irrlicht.sourceforge.net/index.html. Visitado em 18/05/2007.
JIRR. (2007). Jirr - Fast 3D for Java. Disponível em http://jirr.sourceforge.net/. Visitado em
17/05/2007.
JNEWTON. (2007). JNewton Newton Dynamics Physics library. Disponível em
https://sourceforge.net/projects/jnewton Visitado em 20/06/2007.
JOODE. (2007). JOODE. Disponível em http://joode.sourceforge.net/ Visitado em
12/06/2007.
KHATUA, Kaushik; AGRAWAL, Anupam. (2005). Development of a Game Engine for FPS
games. Indian Institute of Information Technology, Deoghat, Jhalwa, Allahabad-211011,
India.
MAIA, José Gilvan Rodrigues (2004). CRAbGE – Uma Arquitetura para Motores Gráficos
Flexíveis, Expansíveis e Portáteis. Dissertação de mestrado, Universidade Federal do
Ceará (UFC), Fortaleza, p. 42-46.
MYTHIC ENTERTAINMENT. (2007). Mythic Entertainment. Disponível em
http://www.mythicentertainment.com/ Visitado em 29/06/2007.
NCSOFT. (2007). NCsoft. Disponível em http://www.ncsoft.com/ Visitado em 22/06/2007.
NDL. (2007). NetImmerse Emergent Game Technologies. Disponível em http://www.ndl.com/
NEWTON. (2007). Newton Game Dynamics. Disponível em
http://www.newtondynamics.com/ Visitado em 16/06/2007.
OBSIDIAN ENTERTAINMENT. (2007). Obsidian Entertainment. Disponível em
http://www.obsidianent.com/ Visitado em 21/06/2007.
OGRE3D. (2007). OGRE3D Open Source Graphics Engine. Disponível em
http://www.ogre3d.org/ Visitado em 14/06/2007.
OPENGL. (2007). OpenGL - The Industry's Foundation for High Performance Graphics.
Disponível em http://www.opengl.org/ Visitado em 12/06/2007.
PANDA3D. (2007). Panda3D – Free 3D Engine. Disponível em http://panda3d.etc.cmu.edu/
PERUCIA, Alexandre S.; Antônio Córdova de B.; Guilherme Lage B.; Roberto Ribeiro C.
Menezes. (2005). Desenvolvimento de Jogos Eletrônicos. NOVATEC, São Paulo, p. 25-
29.
50
PROQUAKE. (2007). ProQuake. Disponível em http://proquake.planetquake.gamespy.com/

QUAKE 2. (1997). Quake II. Disponível em
http://www.idsoftware.com/games/quake/quake2/ Visitado em 14/06/2007.
QUAKE 3. (1999). Quake III. Disponível em
http://www.idsoftware.com/games/quake/quake3-arena/ Visitado em 14/06/2007.
RABCAT. (2007). RABCAT Computer Graphics GmbH - Graphic outsourcing solutions for
the gaming industry. Disponível em http://www.rabcat.com/ Visitado em 06/06/2007.
RABCAT ENGINE. (2007). RABCAT ENGINE. Disponível em
http://www.rabcat.com/sites_eng/development_engine.htm Visitado em 01/06/2007.
RENDERWARE FMSS. (2007). Renderware FMSS. Disponível em
http://www.renderware.com/ Visitado em 20/06/2007.
SANTAELLA, Lucia. (2004). Games e Comunidades Virtuais. Disponível em
http://csgames.incubadora.fapesp.br/portal/publica/comu. Visitando em 20/05/2007.
SILVEIRA, Paulo; Mota, Samuel; Villela, Carlos; Umlauf, Sérgio; Urubatam, Rodrigo; Steil,
Rafael. (2002). Desenvolvedores do GUJ – Grupo de Usuário Java. Vale a pena usar Java
para criar jogos?. Disponível em http://www.guj.com.br/posts/list/51058.java. Visitado
em 20/06/2007.
UNREAL TECHNOLOGY. (2007). Unreal Technology. Disponível em
http://www.unrealtechnology.com/html/technology/ue2.shtml e
http://www.unrealtechnology.com/html/technology/ue30.shtml Visitado em 20/06/2007.
UOL JOGOS. (2007). Venda de consoles cai em ranking semanal japonês. Disponível em
http://jogos.uol.com.br/ultnot/multi/ult530u4707.jhtm Visitado em 25/06/2007.
VALVE SOFTWARE. (2007). Source Engine. Disponível em
http://www.valvesoftware.com/sourcelicense/enginefeatures.htm e
http://www.valvesoftware.com/ Visitado em 21/06/2007.
VU GAMES. (2005). Sierra. Disponível em http://www.sierra.com/en/home.html Visitado em
16/06/2007.
WIKIPÉDIA. (2007). Motor de Jogo. Disponível em
http://pt.wikipedia.org/wiki/Motor_de_jogo e http://en.wikipedia.org/wiki/Game_engine
ZICKNER, Holger; Weisse, Carsten; Stoeckel, Rene. (2004). Bytonic Software – Jake.
Disponível em http://bytonic.de/html/jake2.html. Visitado em 20/06/2007.
51
ZLIB/LIBPNG. (2006). Licença ZLIB/LIBPNG. Disponível em

http://www.opensource.org/licenses/zlib-license.php Visitado em 08/06/2007.

Desenvolvimento de Jogos 3d em Java Com A Utilização Do Motor Gráfico

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Desenvolvimento de Jogos 3d em Java Com A Utilização Do Motor Gráfico

Uploaded by

Copyright:

Available Formats

Faculdade Lourenço Filho

Desenvolvimento de Jogos 3D em Java com a Utilização do

Daniel Souza Amazonas

Daniel Souza Amazonas

Monografia apresentada ao curso de

Daniel Souza Amazonas

Monografia Apresentada ao curso de Bacharel em Ciências da Computação da

Composição da Banca Examinadora:

Aprovada em 24 de agosto de 2007

Palavras-chave: Desenvolvimento de Jogos, Motor Gráfico, Computação Gráfica, Java.

2. Desenvolvimento de Jogos ........................................................................................... 3

3. Motor Gráfico ............................................................................................................. 12

4.4 Considerações Finais ............................................................................................ 30

Figura 5.9: Terceira pessoa ............................................................................................. 40

1.3 Organização do Trabalho

Figura 2.1: Computador analógico e mostrado em um osciloscópio.

Figura 2.2: Imagem do jogo de tênis conhecido como PONG.

Figura 2.3: Imagens do jogo Amazônia.

Com o desenvolvimento da computação no Brasil, tantos em termos acadêmicos

investimento, capacitação de pessoal e acesso a tecnologia em nações como EUA, Japão e

2.2 Mercado de Jogos

O mercado de jogos vem crescendo muito. O de jogos para celular é o que

2.2.1 Mercado brasileiro

No planejamento de jogos e simulações é de vital importância definir e fixar

2.3.1 Conceitos Básicos de Jogos

Uma atividade voluntária exercida dentro de certos e determinados limites de

Segundo IMPA (2007), existem dois tipos de jogos, os cooperativos e os não-

planejamento, gerenciamento de projetos, produção, marketing, vendas, financeiro etc. Tudo

em consideração os requisitos técnicos identificados pelo planejador de software.

2.3.2 Ciclo de Desenvolvimento

Figura 2.4: Ordem das etapas para o desenvolvimento de um jogo.

Figura 2.5: Diagrama de desenvolvimento de um jogo.

2.4 Considerações Finais

Figura 3.1: Interface do motor Unreal Engine 2.

3.2 Exemplos de Motores Gráficos

Esses motores fornecem um pacote de ferramentas visuais que agiliza o processo de

Figura 3.4: Pacific Storm, jogo desenvolvido com o motor OGRE3D.

Figura 3.5: Estrutura de um motor gráfico (GAMASUTRA, 2005).

3.4 Jogos de Tiro em Primeira Pessoa

Processamento de Geração de Dados

Figura 3.6: Estrutura básica de um FPS.

 Entidades móveis (objetos, jogadores, monstros, portas, plataformas, energia, munição,

Figura 3.7: Maplet, um editor de níveis gratuito (BLITZBASIC, 2007).

Figura 3.8: Edição de um modelo MD2.

Processamento dos Dados

3.5 Considerações Finais

1. A origem deste programa de computador não pode ser apresentada de forma

Segundo GEBHARDT (2003), chefe do projeto Irrlicht, a RABCAT Computer

 Efeitos sonoros 2D e 3D com o irrKlang (motor gratuito de sons 3D). O irrKlang

Figura 4.3: Md2 visto em uma interface gráfica do próprio Irrlicht.

Figura 4.4: irrEdit, editor livre, bastante completo para o Irrlicht.

Para o funcionamento do Jirr na plataforma Windows, é necessário configurar

Figura 4.5: Inicialização do motor em Java.

4.3.2 Interface Gráfica

Figura 4.6: Configuração de vídeo, e adição de um botão.

4.3.3 Inserção de Elementos

Figura 4.7: Carregamento de um cenário Quake3.

Figura 4.8: Mesh carregado pelo Jirr.

4.3.4 Tratamento de Eventos

Figura 4.9: Trecho com exemplos de eventos implementados.

4.4 Considerações Finais

Neste capítulo, documentam-se algumas etapas do ciclo de desenvolvimento de um

Tabela 5.1: Comparativo de desempenho do código original e a versão Java.