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
Motor Gráfico Irrlicht
Daniel Souza Amazonas
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
Motor Gráfico Irrlicht
Daniel Souza Amazonas
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
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.
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.
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 3.5 Considerações Finais ... 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
4.4 Considerações Finais ... 30 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
5.4 Considerações Finais ... 44
6. Conclusões ... 45
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.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
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
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.
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.
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
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,
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.
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
65740 31216 18727 17540 6130 1050 724 306 119 28 902411 524928 270938 155303 133404 47806 9361 7156 3076 440 272 146073 1 10 100 1000 10000 100000 1000000 Nin tend o D S Li te Wii PSP Play Stat ion 3 Play Stat ion 2 Xbo x 36 0 Gam e B oy A dvan ce M icro Gam e B oy A dvan ce S P Gam eCub e Nin tend o D S Gam e B oy A dvan ce Consoles Q u an ti d ad es 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.
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 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
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
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.
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.
Figura 2.4: Ordem das etapas para o desenvolvimento de um jogo.
Braimstorming Game Design Document Design Cronograma Level Design Beta Teste Versão Final Demo
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.
Pesquisa
Definição
Criação
Desenvolvimento
Plataforma-Alvo Publico-Alvo Regras do Jogo
Layout do Jogo Arte do Jogo
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
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:
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).
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
Nights 2, mostrando a capacidade gráfica do
motor usado.
Figura 3.3: Crysis, jogo que está sendo desenvolvido e utiliza o motor CryENGINE2.
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.
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: Entrada de Eventos Física Sistema de Partícula Inteligência Artificial Detector de Colisão Renderizaçã o do Vídeo Renderizaçã o do Áudio Imagens Sons NÚCLEO Subsistemas Núcleo
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
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.
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.
Jogo Processamento de Dados
Núcleo do Motor
Geração de Dados Editor de Níveis Editor de Modelos
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).
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.
3.5 Considerações Finais
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.
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 no qual utiliza muito bem o sistema de partículas.
Figura 4.2: Galactic Dream: Rage of War, jogo comercial que utiliza o motor gráfico
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
(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.
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
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.
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
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
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
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.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.
Figura 4.9: Trecho com exemplos de eventos implementados.
4.4 Considerações Finais
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.
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.
Tabela 5.1: Comparativo de desempenho do código original e a versão Java. System Original C Code Jake2-0.9.1
JRE 1.5 jogl Jake2-0.9.2 JRE 1.5 fastjogl Jake2-0.9.3 JRE 1.5 fastjogl Jake2-0.9.4 JRE 1.5 fastjogl/lwjgl AMD Athlon XP 2400 Geforce4 MX Windows 2000 800x600 window 245 fps 172 fps 213 fps 241 fps 260/250 fps AMD Athlon XP 2400 Geforce4 MX Windows 2000 800x600 fullscreen 315 fps Não suportado 225 fps 235 fps 250/282 fps AMD Athlon XP 2400 Geforce4 MX Linux 800x600 window 262 fps 141 fps 212 fps 215 fps 228/240 fps AMD Athlon XP 2400 Geforce4 MX Linux 800x600 fullscreen 56 fps 21 fps 31 fps
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 é
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
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.
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.
Braimstoming
Document Design Level Design
Game Design
Estado no qual se encontra o projeto. Fase de correção.
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
