Centro Universitrio de Maring Curso Superior de Bacharelado em Sistemas de Informao

JEFERSON MARTINS BRUNO

O Estudo e a Comparao entre Arquiteturas para Desenvolvimento de Entretenimento Digital

Maring 2011

JEFERSON MARTINS BRUNO

O Estudo e a Comparao entre Arquiteturas para Desenvolvimento de Entretenimento Digital

Monografia apresentada ao Curso de Graduao, em Sistemas de Informao, do Centro Universitrio de Maring como requisito parcial para a obteno do ttulo de Bacharel, sob a orientao da professora Aline
Maria Malachini Miotto Amaral

Maring 2011

RESUMO Os objetivos do presente trabalho so divulgaes em ambiente acadmico das metodologias, ferramentas e conceitos para o desenvolvimento de entretenimento digital. Os materiais como livros, tutoriais e artigos sobre desenvolvimento de jogos eletrnicos ou entretenimento digital so dificilmente encontrados no Brasil. Mesmo o mercado de jogos eletrnicos estando em ascenso constante no mundo, h pouco investimento do governo e empresas nesse mercado dentro do Brasil. Foi realizado um estudo nas diversas reas que constituem o desenvolvimento de entretenimento digital, estas reas so: estrutura de desenvolvimento de entretenimento digital, computao grfica, engines, elementos de composio de entretenimento digital e arquitetura de desenvolvimento. Dentro dessas reas so abortados outros fatores que fazem parte do desenvolvimento de jogos eletrnicos. Os critrios utilizados para o desenvolvimento deste trabalho foi identificao dos elementos necessrios para criao de jogos digitais, partindo desde planejamento do projeto dos jogos digitais at definio das ferramentas de desenvolvimento. Os resultados foram metodologias aplicadas no planejamento para criao dos jogos digitais, definio dos elementos que compem a computao grfica, estudo das ferramentas e componentes utilizados pela engine. Foram definidos e estudados os elementos bsicos que fazem parte da composio de um jogo digital, sendo estes: coliso, cmera, iluminao e terreno. As caractersticas, funcionalidades e aplicaes das ferramentas XNA, GlScene e Ogre tambm foram estudas, bem como seu comportamento no desenvolvimento de entretenimento digital. Palavras-chave: XNA, GlScene, Ogre3D, jogos digitais, engine

LISTA DE FIGURAS

FIGURA 1 ATARI E JOGOS DO CONSOLE...................................................................1 FIGURA 2 PLAYSTATION 3, FINAL FANTASY XIII E RESIDENT EVIL 5............2 FIGURA 3 ESTRUTURA DE DESENVOLVIMENTO DE JOGOS (CARNEIRO, 2004)...........................................................................................................................................6 FIGURA 4 RASCUNHO DO OBJETO (ESQUERDA) E IMAGEM 3D DO RASCUNHO (DIREITA) (FESTA, 2010)..............................................................................7 FIGURA 5 FINAL FANTASY VII (ESQUERDA) E FINAL FANTASY X (DIREITA) ...................................................................................................................................................11 FIGURA 6 ILUSTRAES DA COMPOSIO HIERRQUICA DE UM GRAFO DE CENA (LOPES, 2010)......................................................................................................15 FIGURA 7 SCREENSHOT DO JOGO DOOM 3 E A DIVISO DO GRAFO DE CENA (UNIDEV, 2010)..........................................................................................................16 FIGURA 8 SIM CITY 3000................................................................................................17 FIGURA 9 BIT-MAP...........................................................................................................19 FIGURA 10 PLANO CARTESIANO X Y (CASACURTA, 1994)..................................20 FIGURA 11 REPRESENTAO ARAMADA (CASACURTA, 1994).........................21 FIGURA 12 IMAGEM 3D DEMONSTRANDO PRIMITIVAS.....................................22 FIGURA 13 OBJETOS COM SOMBREAMENTO........................................................24 FIGURA 14 IMAGEM RENDERIZADA COM RAYTRACING..................................25 FIGURA 15 TEXTURA DE IMAGEM.............................................................................26 FIGURA 16 IMAGEM TEXTURE MAPS.......................................................................26 FIGURA 17 EXEMPLO DE LEVEL EDITORS PERTENCENTES A DIVERSOS ENGINES.................................................................................................................................28 FIGURA 18 ETAPAS DA ENGINE DE RENDERIZAO..........................................28 FIGURA 19 UTILIZAO DA PROJEO 3D PARA 2D..........................................29 FIGURA 20 RASTERIZAO APLICADA NA CENA................................................30 FIGURA 21 TCNICA BOUNDING-BOX......................................................................31 FIGURA 22 REAO DO OBJETO APS COLISO.................................................31 FIGURA 23 ENGINE DE SOM.........................................................................................32 FIGURA 24 MONTAGEM DE NPC.................................................................................33 FIGURA 25 EXEMPLO DE UMA MQUINA DE ESTADOS.....................................34 FIGURA 26 FUNCIONAMENTO DO BOUNDING-BOX.............................................36 FIGURA 27 COLISO POR PIXEL.................................................................................36 FIGURA 28 IMAGEM DEMONSTRANDO A COLISO DE OBJETOS...................37

FIGURA 29 MODELO SCROLLING (ESQUERDA), TOP VIEW (CENTRO) E SIDE VIEW (DIREITA)...................................................................................................................38 FIGURA 30 - COORDENADAS DA POSIO DA CMERA, E SEUS 7 GRAUS DE LIBERDADE: LOCALIZAO NO ESPAO (X,Y,Z),NGULOS DE ROTAO EM TORNO DE CADA UM DOS EIXOS (SETAS CURVAS) E FOCO. (AZEVEDO, 2003) ...................................................................................................................................................38 FIGURA 31 COUNTER STRIKE......................................................................................39 FIGURA 32 - KINGDOM HEARTS 358/2 DAYS...............................................................39 FIGURA 33 CMERA MOSTRA UMA POSIO FIXA NO JOGO RESIDENT EVIL 3......................................................................................................................................40 FIGURA 34 ILUMINAO LOCAL (ESQUERDA) E ILUMINAO GLOBAL (DIREITA)...............................................................................................................................41 FIGURA 35 LUZ PONTUAL (ESQUERDA), LUZ DIRECIONAL (CENTRO) E LUZ SPOT (DIREITA) (MANSSOUR E COHEN, 2006)............................................................42 FIGURA 36 LUZ AMBIENTAL (ESQUERDA), LUZ DIFUSA (CENTRO) E LUZ ESPECULAR (DIREITA) (MANSSOUR E COHEN, 2006)..............................................42 FIGURA 37 LUZ EMISSIVA.............................................................................................43 FIGURA 38 MAPA DE ALTURA (HEIGHTMAPS)......................................................44 FIGURA 39 SOFTWARES PARA EDIO DE MAPAS DE ALTURA.....................45 FIGURA 40 VISO GERAL DA ARQUITETURA XNA...............................................48 FIGURA 41 VISO DETALHADA DO XNA FRAMEWORK.....................................49 FIGURA 42 START KITS..................................................................................................50 FIGURA 43 FLUXOGRAMA DE UM JOGO (OLIVEIRA, 2011)................................51 FIGURA 44 ESTRUTURA DO XNA E CDIGO FONTE DO PROJETO XNA........52 FIGURA 45 INICIO DA CLASSE GAME1......................................................................54 FIGURA 46 - BALL.BMP......................................................................................................56 FIGURA 47 MICROSOFT VISUAL C# 2008 EXPRESS EDITION.............................57 FIGURA 48 MTODO DE DETECO DE COLISO NO XNA, MODELO BOUDING BOXES (LOBO ET AL., 2010).......................................................................58 FIGURA 49 SPRITE SHEET THREERINGS.PNG (REED, 2009)...............................59 FIGURA 50 CDIGO FONTE DE CAPTURA DE ENTRADA DE DADOS..............60 FIGURA 51 FERRAMENTA DE UDIO XACT............................................................62 FIGURA 52 SISTEMAS DE COORDENADAS DE TRS DIMENSES....................63 FIGURA 53 PALETAS DE COMPONENTE DO GLSCENE........................................66 FIGURA 54 GRFICOS 3D QUE PODEM SER IMPORTADOS NO GLSCENE.....67 FIGURA 55 - ANIMAO POR ESQUELETIZAO DE UM OBJETO VIRTUAL.69 FIGURA 56 - USURIO INDICANDO OBJETO VIRTUAL DISTANTE.....................70

FIGURA 57 GRAFO DE CENA NO GLSCENE.............................................................72 FIGURA 58 OGRE EXECUTANDO NO VISUAL C++ 2008 EXPRESS EDITION...73 FIGURA 59 HIERARQUIA DO SCENENODE (FARIAS ET AL., 2011)....................76 FIGURA 60 VISO DO FRUSTUM.................................................................................77 FIGURA 61 IMAGEM DEMONSTRANDO FSICA REAL COM OGREODE.........79 FIGURA 62 INTERFACES GERADAS PELO CEGUI (CEGUI, 2010).......................81 FIGURA 63 - SKELETAL ANIMATION............................................................................83 FIGURA 64 MORPHING 3D.............................................................................................84 FIGURA 65 DIFERENA ENTRE TEXTURA DO TERRENO, UTILIZANDO DETALHES DE TEXTURA (OGRE, 2011)........................................................................86 FIGURA 66 SKYBOX.........................................................................................................87 FIGURA 67 SKYPLANE....................................................................................................88 FIGURA 68 OS 3 TIPOS DE SOMBRAS DO OGRE: MODULATIVE TEXTURE SHADOWS (ESQUERDA), MODULATIVE STENCIL SHADOWS (CENTRO) E ADDITIVE STENCIL SHADOWS (DIREITA)..................................................................91

LISTA DE TABELAS

TABELA I GNERO DE JOGOS DE COMPUTADOR E CONSOLE COM MAIS UNIDADES VENDIDAS. ........................................................................................................9 TABELA II ESTRUTURA DE DADOS 3D......................................................................21 TABELA III EVOLUO DO XNA.................................................................................47 TABELA IV ARQUIVOS IMPORTADO PELO XNA...................................................53 TABELA V DEFINIES DE FORMATO DE VRTICE NO XNA...........................64 TABELA VI - FORMATO DE MODELOS PARA IMPORTAO EM UMA APLICAO..........................................................................................................................67 TABELA VII PORTABILIDADE DAS ARQUITETURA AVALIADAS PARA OS DIFERENTES SOS.................................................................................................................93 TABELA VIII PORTABILIDADE DAS ARQUITETURA AVALIADA PARA OS DIFERENTES AMBIENTES................................................................................................93 TABELA IX COMPARAO DE DESEMPENHO ENTRE XNA, GLSCENE E OGRE.......................................................................................................................................97 TABELA X EXTENSES DE UDIO SUPORTADAS PELAS ARQUITETURAS DE DESENVOLVIMENTO DE JOGOS..................................................................................100

LISTA DE SIGLAS E ABREVIATURAS

2D 3D API AV BUG CAD CEGUI CG GUI CVS DirectX FPS IA IDE Internet GAME LAN MIT MP3 NPCs ODE Ogre OIS OO OpenGl PC Pixel RPG RAD

Bidimensional Tridimensional Application Programming Interface Ambiente Virtual Falha no software Computer-Aided Design Crazy Eddies GUI System Computao Grfica Graphic User interface Concurrent Version System Interface de Programao de Aplicativos Grficos Frames por segundo Inteligncia Artificial Integrated Development Environment
Interconnected Network

Jogo eletrnico Local Area Network Massachusset Institute of Technology MPEG Audio Stream Layer III Non-Player Characters Open Dynamic Engine Object Orientend Graphic Rendering Engine Object Oriente Input System Orientao a Objetos Open Graphics Library Personal Computer Picture Elements Role-playing Game Rapid Application Development

GAMEPLAY Jogabilidade

SDK SO TEXEL TCP UDP WAN WAV XACT XNA

Software Development Kit Sistema Operacional Texture pixel Transmission Control Protocol User Datagram Protocol Wide Area Network Waveform data Microsoft Cross-Platform Audio Creation Tool XNA's Not Acronymed

SUMRIO

1 INTRODUO......................................................................................................................1 2 ESTRUTURA DE DESENVOLVIMENTO DE ENTRETENIMENTO DIGITAL.......6 3 COMPUTAO GRFICA..............................................................................................18 4 ENGINE (MOTOR GRFICO).........................................................................................27 5 ELEMENTOS DE COMPOSIO DE ENTRENIMENTO DIGITAL........................35 6 ARQUITETURAS DE DESENVOLVIMENTO..............................................................46 6.1.1.1 Jogos..................................................................................................................49 6.1.1.2 Extenses..........................................................................................................50 6.1.1.3 Ncleo...............................................................................................................53 6.1.1.4 Plataforma.........................................................................................................53 6.3.1.1 Root...................................................................................................................75 6.3.1.2 SceneManager...................................................................................................75 6.3.1.3 Entity.................................................................................................................75 6.3.1.4 SceneNode........................................................................................................76 6.3.1.5 Camera e ViewPort...........................................................................................77 6.3.1.6 Framelistener.....................................................................................................77 6.3.3.1 OgreODE..........................................................................................................78 6.3.3.2 OgreNewt..........................................................................................................79 6.3.6.1 Animation State.................................................................................................82 6.3.6.2 Skeletal Animation............................................................................................82 6.3.6.3 Pose Animation.................................................................................................83 6.3.6.4 Morph Animation..............................................................................................83 6.4.6.5 Bleding Animation............................................................................................84 6.3.7.1 Terrain...............................................................................................................85 6.3.7.2 SkyBox..............................................................................................................87 6.3.7.3 SkyDome...........................................................................................................87 6.3.7.4 SkyPlane............................................................................................................88 6.3.7.5 Fog....................................................................................................................89 6.3.7.6 Luzes.................................................................................................................89 6.3.7.7 Sombras.............................................................................................................90 7 COMPARAES ENTRE AS ARQUITETURAS ESTUDADAS.................................93 8 CONSIDERAES FINAIS............................................................................................106 REFERNCIAS....................................................................................................................109 APNDICES..........................................................................................................................113 APNDICE A PROJETO XNA PARA IMPORO DE IMAGEM 2D....................114 APNDICE B JOGO DE MOVIMENTAO DE PERSONAGEM 3D DENTRO DE UM CENARIO DESENVOLVIDO COM GLSCENE .....................................................115 APNDICE C JOGO DE MOVIMENTAO DE PERSONAGEM 3D DENTRO DE UM CENARIO DESENVOLVIDO COM OGRE3D........................................................116

ANEXOS................................................................................................................................117 ANEXO I JOGO DE MOVIMENTAO DE PERSONAGEM 3D DENTRO DE UM CENARIO DESENVOLVIDO COM XNA .......................................................................118 ................................................................................................................................................119

1 INTRODUO

Na dcada de 1950, em plena Guerra Fria, a tecnologia da computao utilizada para gerar simulaes de msseis e prever resultados de uma guerra nuclear, foi utilizada para desenvolver o primeiro jogo eletrnico denominado Tennis for Two criado por William Higinbotham em 1958. O jogo era uma simplificao do tnis e era apresentado em uma tela de osciloscpio (NUNES, 2007). Com o resultado deste pensamento, Steve Russel estudante da MIT (Massachussets Institute of Technology), juntamente com amigos, desenvolveu o jogo space war, o primeiro jogo eletrnico propriamente dito. O jogo tinha duas naves que duelavam entre si, e um sistema de placar para limitar o tempo dos jogadores. Com popularizao de space war muitos jogos do gnero foram desenvolvidos, resultando do desenvolvimento de consoles ou videogames, um dos primeiros consoles desenvolvido foi o Atari, que se tornou um marco na histria dos videogames, possua grande variedade de jogos, conforme ilustrado na Figura 1.

Figura 1 Atari e jogos do console

A dcada de 80, se incio a revoluo dos videogames com as companhias Nintendo e SEGA, criando aparelhos com maior capacidade de processamento de imagens que os aparelhos da Atari. Na dcada seguinte com entrada de novas companhias para o desenvolvimento de console e jogos, dava-se um novo enfoque, os jogos tridimensional (3D) sendo o pice da revoluo multimdia para os consoles. A evoluo dos jogos, assim como da tecnologia no desenvolvimento dos mesmos a partir desta dcada se tornou quase constante, muitas empresas de desenvolvimento de jogos eletrnicos se estabeleceram a partir deste ponto se tornando grandes empresas. No incio do sculo XXI at a atualidade houve outra grande evoluo dos jogos e consoles. Os grficos dos jogos se tornaram quase reais, sendo possvel reproduzir uma cena de Computao Grfica (CG) de alta qualidade com grficos 3D, ilustrados pela Figura 2. Os consoles ganharam novos dispositivos para interao entre o usurio e o jogo, como cmeras, controles sem fio, acesso a Internet entre outros dispositivos.

Figura 2 Playstation 3, Final Fantasy XIII e Resident Evil 5

Sendo assim a indstria de jogos eletrnicos se tornava um dos maiores mercados dessa poca, novas empresas esto se estabelecendo em meio a essa evoluo, cada vez mais existem faculdades e cursos tcnicos oferecendo curso para desenvolvimento de jogos eletrnicos, sendo que o desenvolvedor de entretenimento digital se tornou uma profisso visada por muitos, pois a procura por estes profissionais est cada vez maior. A indstria de jogos no Brasil um mercado relativamente pequeno comparado aos pases como EUA (Estado Unidos da America) e Japo onde existe grande investimento dessa rea. Segundo Lobo et al. (2010) h 560 profissionais trabalhando em 42 empresas no Brasil para criao de jogos eletrnicos, isso representa uma pequena parcela de desenvolvedores.

Sendo no Brasil o desenvolvimento de jogos voltado mais para os computadores do que para console, pelo fato de ser caro o desenvolvimento e distribuio de jogos para console: o valor gasto para criao de um jogo de Playstation 3 equivalente ao valor gasto em uma produo cinematogrfica. Entretanto a indstria de jogos no Brasil vem se expandindo, assim se tornado uma rea promissora para se trabalhar, pois segundo a Abragames (2008) a indstria software de entretenimento digital teve um crescimento de 28% entre 2006 e 2007, e a projeo do crescimento entre 2007 e 2008 chegaram a 31%. Sabe-se que o desenvolvimento de um jogo no s leva como atividade a programao, mais outras tarefas como roteiro, tratamento de som e imagens, dinmica do jogo e outras demais atividades. Nesse meio carece de diversas reas a se especializar, pois os jogos tambm so produtos comercializados, um jogo direcionado a certo pblico em certo tempo e gasto valores significativo. Jogos so planejados e gerenciados por uma equipe ou uma pessoa. Esta pesquisa est voltada para as arquiteturas de desenvolvimento em especial a ferramenta da Microsoft o XNA (XNA's Not Acronymed). Segundo Lima (2010) o XNA a nova arquitetura desenvolvida pela Microsoft para auxiliar os desenvolvedores no processo de criao de jogos tanto para Windows quanto Xbox 360 e Zune. O XNA possui uma API (Application Programming Interface) para criao de jogos 3D assim como jogos Bidimensional (2D), alm de permitir a manipulao de som e entrada de dados como teclado, mouse e joystick. Ele nos permite desenvolver jogos com uma grande agilidade e rapidez.

1.1 MOTIVAO

A motivao que leva o desenvolvimento desse trabalho a divulgao em ambiente acadmico das metodologias, ferramentas e conceitos para o desenvolvimento de entretenimento digital. Livros, tutoriais e artigos sobre desenvolvimento de entretenimento digital, so dificilmente encontrados na lngua portuguesa. Por este motivo a divulgao do desenvolvimento de entretenimento digital se torna difcil, pois a maior parte do material

sobre este assunto se encontra redigida em ingls, sendo assim, o desenvolvedor deve possuir conhecimento sobre a lngua inglesa. No Brasil ainda h uma divulgao sobre o assunto, atravs de fruns, comunidades, sites e universidades, como exemplo pode-se citar o portal UniDev (www.unidev.com.br), tendo como objetivo reunir pessoas e informaes ligadas ao desenvolvimento de jogos, dentro deste portal o usurio encontra notcias, tutorias, links, artigos e toda informao necessrio para que as pessoas interessadas conheam o desenvolvimento de jogos eletrnicos, sendo que este portal reuni informaes de vrios linguagens de programao e ferramentas para o desenvolvimento de jogos. Atualmente o Brasil se encontra como um pas promissor para a rea de entretenimento digital, o segundo dados da Abragames houve um crescimento considervel nessa rea entre o ano de 2006 a 2008.

1.2 OBJETIVOS

O desenvolvimento de entretenimento digital sempre foi uma atividade demorada pelo fato de se programar para o hardware, sendo executada somente por profissionais ou quem tinha um conhecimento avanado nessa rea. Hoje existem vrias ferramentas que fazem essa parte de integrao com o hardware, assim o desenvolvedor de jogos utiliza as placas de vdeos, som, entrada de comandos (input) e sada dos comandos (output) com maior facilidade no desenvolvimento de jogos eletrnicos. Nesse trabalho sero estudadas diferentes reas que constituem o desenvolvimento de entretenimento digital, estas reas so: planejamento e gerenciamento de jogos, elementos do jogo digital, computao grfica, jogos no ambiente cultural, engine e arquitetura de desenvolvimento. Dentro dessas reas sero abordados outros conceitos que fazem parte do desenvolvimento dos jogos. E por fim, compreender a estrutura da arquitetura XNA e quais suas vantagens ou desvantagens sobre as arquiteturas Ogre3D e GlScene.

1.3 ORGANIZAO DA MONOGRAFIA

Este trabalho composto por 7 captulos a partir dessa introduo, cuja estrutura encontra-se segmentada da seguinte maneira: o captulo 2 mostra estrutura de desenvolvimento de entretenimento digital, apresentando o planejamento e o gerenciamento da estrutura de desenvolvimento de jogo. O captulo 3 descreve o que computao grfica, a soluo e a demonstrao prtica. No captulo 4 mostra e descreve o que engine, descrevendo sua funcionalidade. O captulo 5 descreve os elementos que compem os jogos eletrnicos. O captulo 6 apresentar as arquiteturas de desenvolvimento de entretenimento digital. O captulo 7 descrever a comparao entre arquitetura de desenvolvimento descritas do captulo 6. O captulo 8 tm-se a concluso obtida no trabalho desenvolvido. E por fim, so apresentadas as referncias que foram abordadas neste trabalho.

2 ESTRUTURA DE DESENVOLVIMENTO DE ENTRETENIMENTO DIGITAL

O planejamento e gerenciamento do desenvolvimento de jogos eletrnicos uma parte importante para garantir o sucesso do jogo no mercado, pois uma vez que nessa etapa so definidos os principais pontos a serem seguidos nas fases seguintes. A Figura 3 mostra a estrutura de desenvolvimento de jogos, segundo Carneiro (2004) o Game Design seria a etapa onde o jogo seria criado juntamente com a sua estria, os personagens, o mundo onde passa a enredo do jogo e a interao entre personagens, com outros personagens e com o mundo.

Figura 3 Estrutura de desenvolvimento de jogos (CARNEIRO, 2004)

O Rascunho dos Objetos e Cenrios seriam os rascunhos em papis de objetos, cenrios, personagens e entre outros, para auxiliar os modeladores na hora da modelagem (Figura 4).

Figura 4 Rascunho do objeto (esquerda) e imagem 3D do rascunho (direita) (FESTA, 2010)

Na Modelagem, os modeladores e pessoas responsveis pelas texturas criam os modelos e as texturas que sero utilizadas no jogo. Na Engenharia de Software feita a modelagem do sistema, na maioria dos casos essa modelagem no feita por completo antes da implementao, sendo contrria, a modelagem do sistema desenvolvida juntamente com as outras fases. E na Programao o jogo desenvolvido. Aqui feita lgica do jogo, so inserido os elementos de Inteligncia Artificial (IA), udio, jogabilidade entre outros elementos. Esse captulo tem como objetivo demonstrar a estrutura de desenvolvimento de jogos eletrnicos, no se entrar em detalhes nas fases, aspectos ou elementos do desenvolvimento de jogos eletrnicos.

2.1 TIPOS DE GAMERS E JOGOS

Antes de se desenvolver um jogo eletrnico deve se levar em considerao vrios fatores, os primeiros fatores que devem ser considerado antes da engenharia saber qual o pblico alvo que se deseja atingir, segundo Lobo et al. (2010) essa escolha ir definir a direo de todo o esforo de criao do jogo, desde a escolha da idia at o nvel de detalhamento que se espera nas fases. O pblico-alvo dividido em seis categorias (LOBO et al., 2010): Heavy Gamers (jogadores frequentes): jogam constantemente. Avid Console Gamers (jogadores de console vidos): compram principalmente jogos de consoles. Mass Market Gamers (jogadores de jogos da moda): usualmente s compram jogos que esto na moda. Prefer Portable Gamers (jogadores que preferem portteis): usualmente jogam em dispositivos portveis. Secondary Gamers (jogadores secundrios): jogam jogos comprados por outros (amigos e familiares). Infrequent Gamers (jogadores no frequentes): s jogam eventualmente para se distrarem. Utilizando-se das categorias que se encontra nos limites, tm-se uma idia do nvel de planejamento que se deve impor a cada tipo de jogos conforme o pblico-alvo que se deseja atingir. Infrequent Gamers: jogos para essa categoria devem ser fceis de jogar, constitudo de pouca histria ou nenhuma, o fundo deve oferecer nveis desafiadores, porm de curta durao. Jogos para esse nvel no necessitam de grficos detalhados, nem msica ou efeitos sonoros de alta qualidade. Heavy Gamers: esses jogos so ao contrrio dos jogos desenvolvidos para a categoria infrequent gamers. Nesse caso os jogos tm que possuir um enredo elaborado, grficos detalhados, efeitos sonoros e trilha de msicas de alta qualidade, pois o usurio tem que se sentir dentro do prprio jogo. Depois de se escolher o pblico alvo tambm deve se escolher que tipo de jogo e a plataforma que se deseja desenvolver. Segundo Morais (2010), jogos so subdivididos em

diversos tipos, cada um com seu aspecto especfico que influncia cada jogador. A Tabela I mostra os tipos de jogos existentes no mercado e o porcentual de jogos vendidos.

Tabela I Gnero de jogos de computador e console com mais unidades vendidas.

Computador 30.8% 19.8% 14.4% 12.4% 5.8% 4.7% 3.7% 8.4%

Console 9.3% 8.7% 7.8% 30.1% 17.3% 11.1% 4.7% 11%

Gnero Estratgia Crianas e entretenimento familiar Tiro RPG (role player games) Aventura Ao Esportes Corridas Luta Outros

Fonte: Dados fornecidos pelo NPD Group.

Um detalhe importante na Tabela I que os gneros mais vendidos para computadores so razoavelmente diferentes dos mais vendidos para console.

2.2 GAME DESIGN (PROJETISTA)

O game design o papel de extrema importncia no desenvolvimento de jogos. Este profissional est presente na grande maioria da equipes, o game design est presente em todas as fases do desenvolvimento, pois ele responsvel por diversas funes: imaginar o jogo, redigir a documentao de projeto, desenhar as interfaces de usurio, definir objetivos da lgica do jogo, desenvolver a estria e o dilogo, descrever os elementos que criam o game, participar do processo de refinamento, teste e integrao das partes do software e transmitir informao as equipes de desenvolvimento do game.

10

Segundo Carneiro (2004), o game design uma das reas que so responsveis pelo sucesso ou no do jogo. Jogos que o game design no tiver a devida ateno ou preocupao, provavelmente no faro sucesso no mercado. Pois o detalhamento dos grficos, enredo, jogabilidade (gameplay), nvel estratgia e outros elementos cujo game design responsvel por elaborar, estes elementos garantem uma alta porcentagem de que o jogo far sucesso. O game design tm que possuir certas qualidades que o destaquem na sua profisso, sendo elas habilidade de escrita, conhecimentos gerais, conhecer e dominar uma grande variedade de games e tecnologias, dedicao ao trabalho, trabalhar em equipe, conhecimento tcnico na rea de programao e conhecer o mercado que se est trabalhando.

2.3 CONCEITUAO

Antes do processo de desenvolvimento, a idia do que se deseja desenvolver deve ser colocado em pauta, um exemplo como ser o jogo, qual ser objetivo do jogador, quais sero os desafios. Nesta etapa tm-se uma idia vaga do que se deseja desenvolver, pois no necessariamente aquilo que o jogo se tornar no final, porque pode haver mudanas do decorrer do desenvolvimento para melhorias no jogo, por mais que a idia inicial seja boa, na prtica no seria assim, portanto, o processo onde as idias comeam a serem pensadas (MORAIS, 2010). O conceito de idia do jogo bastante abstrato, pois podem vir de diversas fontes ou lugares: so baseados em jogos existentes, lendas, histrias reais, filmes, livros, programas de televiso, esportes ou das estrias criadas na mente humana, o que mais normal de se ver nos jogos eletrnicos. Mundos imaginrios criados a partir da mente do game design, muitas estria de games so desenvolvida nesse ponto de vista onde o game design imagina personagens, mundos, objetos, o enredo e tudo o que ele pode extrair de sua mente e misturar com a realidade se possvel. Segundo Carneiro (2004) muitas idias de jogos vm dos sonhos. No dos sonhos que acontecem quando se est dormindo, mas sim daqueles que acontecem em momentos de divagao. Uma demonstrao de game que se tornou uma grande franquia e foi desenvolvido a partir da imaginao de Hironobu Sakaguchi, e a srie de jogo eletrnico FINAL FANTASY que possui enredos diferentes conforme uma nova edio sai no mercado, apesar dos enredos

11

no possurem conexes entre os ttulos da srie, muitos elementos so reutilizveis, como o sistema e batalhas, gameplay, alguns personagens e entre outros elementos (Figura 5).

Figura 5 Final Fantasy VII (esquerda) e Final Fantasy X (direita)

No processo de escolha da idia do jogo, deve-se levar em conta tambm que, se for um jogo comercial, a idia dele no deve agradar apenas um jogador. Ela deve agradar a maior faixa de jogadores possveis. O principal propsito de um jogo prover entretenimento para outras pessoas (CARNEIRO, 2004). O jogo desenvolvido no universo virtual tambm possui regras. Segundo Carneiro (2004) so essas regras que definem as aes e movimentos que os jogadores podem e o que eles no podem fazer no decorrer do jogo. As regras tambm definiro as condies para que o jogador consiga a vitria no game.

2.4 IMERSO

A imerso o ato de imergir, aprofundar, entrar e envolver. Esse um dos pontos que faz o jogo desenvolvido um sucesso. O ato de imergir faz com que o jogador se sinta parte do mundo fantasioso criado pelo jogo. Segundo Morais (2010) quando maior a iluso de realismo gerada do jogo em relao ao jogador, maior a sensao de interao e mais ele estar interessando em avanar e conseguir alcanar seus objetivos, e tudo isso um importante fator que deve ser alcanado na etapa de game design. O mundo inserido nos jogos eletrnicos deve passar a sensao de ser harmnico, isto , um sentimento de que todas as partes do jogo pertencem a um nico contexto. Segundo Carneiro (2004) harmonia

12

essencial num mundo de um bom jogo. A cada deciso tomada referente ao game design, deve ser perguntado se aquela idia pertence ao contexto do mundo, se harmonia no ser quebrada. Essa imerso no leva s inconsiderao os cenrios e mundos desenvolvidos mais tambm pelas estrias chamativas e obscuras, escondendo muitos secretos a qual o jogador ao decorrer do jogo desvendar. Alm de envolver ambiente e estrias, tambm envolve os personagens que devem fazer com que os jogadores se sintam a vontade com eles. Estes personagens podem assumir diversos esteretipos, estes so heris, mentores, aliados, guardies, alto suficiente, malandros e viles cada um desses tem sua participao do enredo de certos tipos de jogos eletrnicos. Esses elementos de jogos eletrnicos levam a uma maior interao entre o jogador e jogo, captando os sentidos e sentimentos do jogador e o atrado por longos perodos de tempo. Esse mundo bem planejado, atraente e deslumbrante em grficos e interao o que faz os jogos se tornarem sries de sucesso no mercado de games.

2.5 IMPLEMENTAO

A implementao um processo que est presente no desenvolvimento de qualquer tipo de software, sendo assim, este processo tambm faz parte do desenvolvimento dos jogos eletrnicos. Por questo de organizao este processo ser explicado em trs partes sendo: programao ou codificao, teste e manuteno. A programao do jogo acompanha o desenvolvimento desde o incio, mesmo ainda o jogo no possuindo grficos definidos ou estria completa, pode ser adiantado muita coisas que viro a ser necessrias no futuro do desenvolvimento. Um jogo pode ser programado em qualquer linguagem de programao, apesar de que, na maioria das vezes os jogos eletrnicos so feitos com a linguagem C/C++. Em conjunto da linguagem de programao, deve ser utilizada uma API que trabalha com grficos, como DirectX e OpenGL. Para suporte linguagem e API, utilizam-se os motores de jogo ou Game Engines, que geralmente j possuem funes ou mdulos prprios para o desenvolvimento de games, tais como clculo de coliso, fsica de um ambiente, tratamento de sons e vdeos, e que fornece toda a base para o incio do desenvolvimento (MORAIS, 2010).

13

O processo de codificao de um jogo exige grande conhecimento e capacidade tcnica por parte do programador. A programao de games no um processo automatizvel. Os algoritmos geralmente so complexos com grandes desafios, sempre havendo necessidades de otimizao de rotinas complexas e utilizao de linguagens de baixo nvel de abstrao comum. Alm disso, o uso de novas tcnicas e tecnologias constante do desenvolvimento de jogos eletrnicos, tornando o desenvolvimento um verdadeiro laboratrio, onde os programadores frequentemente so obrigados a abandonar boa parte de seu trabalho por no alcanar os resultados desejveis (JUNIOR, NASSU e JONACK, 2002). O processo de teste de jogos eletrnicos no apenas para encontrarem falhas, mas tambm para a jogabilidade e aceitao do jogo por parte dos usurios. Por este motivo, os testes geralmente so distribudos por todas as fases de desenvolvimento. O teste de funcionalidade e bugfix tm por objetivo as caractersticas das abordagens clssicas da Engenharia de Software. E no playtest os programadores analisam a aceitao do game e a reao dos jogadores (JUNIOR, NASSU e JONACK, 2002). extremamente frustrante para cada jogador ter quantidade de horas perdidas em um jogo devido a um problema de bug (falha) no software, neste ponto se aplica a manuteno, o reparo desses bug para melhor funcionalidade do jogo. No caso dos games desenvolvidos para console, no existe muita facilidade para atualizaes. Mas felizmente essa plataforma dificilmente apresenta problemas de compatibilidade e possui uma boa e extensiva fase de teste, geralmente o suficiente para evitar frustrao do lanamento de um jogo com problema. Que no caso dos jogos para PC (Personal Computer) so exatamente ao contrrio pelo fato de se desenvolver para diversas configuraes de mquinas existentes, nesse caso o lanamento de atualizaes uma boa soluo, mas nem sempre ela eficaz. Para avaliao pelo cliente, as empresas de jogos disponibilizam uma verso demo do jogo desenvolvido, este demo uma pequena frao do jogo, que no caso seja uma nica fase ou misso, normalmente sempre so os primeiros desafios a serem encontrado no jogo. Na indstria de games os demos so lanados geralmente alguns meses antes do lanamento do produto completo, para criar expectativas entre os jogadores.

2.6 GRAFO DE CENA

14

O avano do poder computacional faz com que as cenas grficas se tornem cada vez mais complexas e mais realistas, e possam ser geradas e visualizadas em tempo real com o simples uso de computadores. Essa complexidade tambm se aplica ao desenvolvimento da cena, que precisa especificar e modelar vrias caractersticas. Isso implica na exigncia de estrutura de dados, tcnica para os elementos da cena e mostrar a informao na tela de forma rpida e eficiente (POZZER, 2007). Para essa utilidade se aplica os grafos de cena, que so ferramentas conceituais para a representao do Ambiente Virtual (AV) nas aplicaes de CG. Um AV uma representao de diversos aspectos do mundo real ou abstrato. Os aspectos considerados em uma aplicao de CG so: disposies dos objetos, formas, textura de superfcies, iluminao, entre outros. Cada um desses aspectos deve ser inserido em um grafo de cena para representar o ambiente virtual. O grafo de cena formado, portanto, por ns conectados por retas. Cada n possui um conjunto de atributos que podem, ou no, influenciar seus ns conectados, e esses ns so ligados de maneira hierrquica, sendo que cada filho somente possuir um pai e no forma ciclo entre os ns, como ilustra a Figura 6 (LOPES, 2010).

15

Figura 6 Ilustraes da composio hierrquica de um grafo de cena (LOPES, 2010)

Algo importante ao construir um grafo de cena onde se envolve um cenrio separar em no mnimo dois subgrafos: o primeiro, o subgrafo de contexto, conter os objetos que fazem parte da cena virtual (geometrias, luzes, cenrios, entre outros) e o outro o subgrafo de visualizao, que possuir todos os objetos necessrios para criar, posicionar, direcionar e movimentar a cmera virtual, pois mesmo que se tenha criado o cenrio, sem a cmera o AV criado no poder ser visualizado, ilustrado na Figura 7. Essa diviso ocorre pelo fato de que preciso separar os objetos responsveis pela cmera dos que esto em cena, pois caso contrrio, sempre ao movimentar a cmera, os objetos do cenrio iro se mover junto com ela (UNIDEV, 2010).

16

Figura 7 Screenshot do jogo Doom 3 e a diviso do grafo de cena (UNIDEV, 2010)

2.7 JOGOS NO AMBIENTE CULTURAL

Uma grande parte dos jogos eletrnicos no traz grandes benefcios em nvel educacional e a seus usurios, uma vez que a indstrias capitalistas no pensam em que beneficio isso trar a seu usurio mais sim quanto aquilo vai render para ela. Segundo Setzer (2001) os jogos eletrnicos prejudicam o comportamento dos indivduos a que se submete a sua diverso prazerosa. No entanto, pode-se observar a existncia de jogos com o potencial de ensinar e educar os seus usurios, no caso os jogos eletrnicos educacionais que tem por objetivo promover o conhecimento entre o jogador e o jogo, onde o jogo trs desafio a seu jogador em forma de quebra-cabea, simulao, RPG entre outros. A indstria de jogos educacionais tem um alto potencial para desenvolver grandes obras no mundo dos jogos. Pode-se exemplificar o caso dos simuladores, onde existe uma srie conhecida como SIM CITY (Figura 8), um jogo onde o usurio, se transforma no prefeito de uma cidade e tem por controlar o desenvolvimento e as atividades da cidade, tem que gerenciar como a cidade deve se desenvolver e administrar os problemas que o crescimento da cidade ocasiona. Esse jogo demonstra a interao que o usurio deve ter com os problemas que a sua cidade pode causar ao meio ambiente e as pessoas que nela vivem.

17

Figura 8 Sim City 3000

Apesar de muito estudado pela psicologia devido aos seus efeitos sobre as pessoas, principalmente crianas, o jogo eletrnico como objeto cultural ainda pouco analisado. O semioticista tcheco Ivan Bystrina coloca os jogos e sonhos como itens fundamentais no universo da cultura. Entre os seres humanos o jogo no se limita apenas infncia; ao contrrio, o ser humano aprecia o jogo e as brincadeiras at o fim de sua vida, at a morte. Os jogos tm finalidade de nos ajudar na adaptao realidade, alm de facilitar sobremaneira o aprendizado, o comportamento cognitivo (ABREU, 2003). Os jogos eletrnicos podem ter como objetivo transmitir a cultura e conhecimento para seus jogadores, atravs das aes que o jogador devera executar no mundo virtual impostas pelo jogo. Sendo assim o jogador dever adquirir os conhecimentos transmitidos por aquela ao do jogo, para utilizaes posteriores nos demais desafios que o prprio jogo o submeter. Dessa maneira o jogador ter essas informaes retidas em sua mente, podendo utiliz-la para sua vida real.

18

3 COMPUTAO GRFICA

A CG a disciplina que trata das tcnicas e dos mtodos computacionais, que convertem dados para dispositivos grficos e vice-versa (VIANNA, 2010). A CG possui infinitas aplicaes para diversas reas, desde a prpria informtica, ao produzir interfaces grficas para software, Sistemas operacionais e Internet, exemplos sistemas de CAD (Computer-Aided Design) onde possuem demonstrao do cenrio ou objeto em 3D, at a utilizao em filmes com animaes grficas, tambm so aplicadas em diversas outras reas que se utilizam da computao para solues de problemas como medicina, arquitetura, engenharia e entre outras reas. Uma das reas que este trabalho ir descrever ser a utilizao da CG em jogos eletrnicos. O avano da CG afeta diretamente a indstria de jogos eletrnicos, um exemplo a comparao entre os videogames da primeira gerao com os modelos atuais, tecnologia empregada no desenvolvimento e potncia para gerao de grficos dos consoles da primeira gerao so muito inferiores aos modelos atuais de console. Conforme a tecnologia foi avanando a CG tambm foi se desenvolvendo, pois se sabe que a tecnologia que limitava a evoluo da CG.

3.1 IMAGEM

Uma imagem composta por um conjunto de pontos, estes pontos so denominados Pixels (Picture Elements). Estes pixels esto sendo exibidos na tela do computador formando uma matriz de pontos que denominada de Bit-Map. Este Bit-Map um conjunto desses elementos onde cada elemento possui uma informao referente cor associada aquele ponto especfico. Uma determinada imagem possuir tambm uma resoluo associada a ela, que o nmero de elementos que esta imagem possui na horizontal e na vertical. Cada elemento da imagem possuir uma localizao, que definida pela suas coordenadas no eixo X e Y.

19

Portanto, uma imagem uma matriz de pontos ou pixels, com uma determinada resoluo horizontal (eixo X) e vertical (eixo Y), onde para cada ponto desta matriz temos uma cor associada (CASACURTA et al., 1994).

Figura 9 Bit-Map.

3.1.1 Pixel

Pixel o menor ponto que forma uma imagem digital, sendo que o conjunto de milhares de pixels forma a imagem inteira. Num monitor colorido cada Pixel composto por um conjunto de 3 pontos: verde, vermelho e azul. Nos melhores monitores cada um destes pontos capaz de exibir 256 tonalidades diferentes e combinando tonalidades dos trs pontos ento possvel exibir pouco mais de 16.7 milhes de cores diferentes.

20

3.1.2 Bidimensional

Os modelos 2D so descritos atravs do plano cartesiano X e Y, onde cada ponto do modelo representado por um par de coordenadas. Nos modelos de duas dimenses as entidades bsicas so o ponto, reta e curva (CASACURTA, 1994).

Figura 10 Plano cartesiano X Y (CASACURTA, 1994)

3.2 GRFICO

So representaes visuais em uma superfcie, geralmente usados para se mostrar uma cena, grficos podem ser bidimensionais ou tridimensionais.

3.2.1 Tridimensional

Os modelos 3D so descritos atravs de suas coordenadas espaciais, ou seja, coordenadas X, Y e Z. Nos modelos de trs dimenses alm das entidades ponto e aresta surge entidade face, que uma sequncia ordenada de pontos e arestas. Um exemplo simples a demonstrao de um cubo. Nesta definio do cubo, iremos primeiramente represent-lo apenas pelos vrtices que compem as suas extremidades.

21

Figura 11 Representao aramada (CASACURTA, 1994)

A figura acima representa um cubo tridimensional, onde a tabela fornece as coordenadas de cada vrtice do cubo. Esta representao denominada de aramada, pois no temos o conceito de faces. A descrio final do cubo ser dada em funo apenas de seus vrtices e das arestas que unem um vrtice ao outro. Uma descrio mais completa deveria indicar: os vrtices, as arestas que unem os vrtices, e as faces que so compostas por um conjunto de arestas. A Tabela II apresenta as duas descries para o exemplo dado na Figura 11 (CASACURTA, 1994).
Tabela II Estrutura de dados 3D

3.2.2 Primitivas

Uma primitiva 3D uma coleo de vrtices que formam uma nica entidade 3D. Grficos so criados a partir de pontos, linhas ou tringulos. Esses elementos bsicos so referidos como objetos primitivos.

22

Figuras complexas so construdas com uma serie de pontos, linhas, ou tringulos. Um modelo 3D esttico basicamente feito de um arquivo contendo informaes de vrtices que incluem posio X, Y, Z, cor, coordenadas da imagem, e possivelmente outros dados.

Figura 12 Imagem 3D demonstrando primitivas

3.3 RENDERIZAO

Renderizao o processo pelo qual pode-se obter o produto final de um processamento digital qualquer. Este processo aplica-se essencialmente em programas de modelagem 2D e 3D. A renderizao muito aplicada para objetos 3D, fazendo a converso de um 3D para uma representao em 2D, seja para obter uma imagem esttica, seja para obter imagens fotorealstica em vdeo. Para renderizar uma cena necessrio, entre varias coisas, definir um tipo de textura para os objetos existentes, sua cor, transparncia e reflexo, localizar um ou mais pontos de iluminao e um ponto de vista sob o qual os objetos sero visualizados. Ao renderizar, o programa calcula a perspectiva do plano, as sombras e a luz dos objetos. Tambm a possibilidade dos objetos serem representados como um denso conjunto de pontos que possuem tanto informao da sua geometria, como do material que determina a

23

aparncia do mesmo. Utilizando mtodos tradicionais de renderizao, necessrio obter um conjunto de dados que forma uma superfcie, independente de sua representao, para depois projetar estes pontos em uma imagem em 2D (IGNCIO, 2003).

3.3.1 Projeo 3D

Da mesma maneira que um desenhista, quando quer representar no papel a imagem de um objeto 3D, no computador tambm preciso gerar uma projeo do objeto que se deseja exibir. Uma projeo 3D nada mais do que uma representao bidimensional de um objeto 3D. Existem vrias tcnicas e tipos de projeo, cada uma delas adequada a um tipo de aplicao. Uma delas projeo em perspectiva, essa possui a capacidade de simular a projeo feita pelo olho humano, quando este capta a imagem de um objeto (TEIXEIRA, TEICHRIEB e KELNER, 2010).

3.3.2 Sombreamento

Este efeito til na determinao da posio de um objeto em relao a um piso colocado abaixo deste, ou na definio relativa entre objetos. Em CG, a manipulao da luz tem um papel fundamental na atribuio de realismo da cena. Os efeitos da luz sobre as superfcies e seus materiais, o obscurecimento em funo de sua posio, orientao e caractersticas luz so, portanto, peas-chave. A CG refere-se frequentemente s regras da fsica tica e fsica das radiaes para explicar a interao da luz nos objetos. No entanto, a falta de modelos complexos e abrangentes levam os programadores a simplificaes do processo computacional. As tcnicas antigas de sombreamento so, modelo Gouraud e modelo Phong, e as novas tcnicas de iluminao global so ray tracing e radiosidade (AZEVEDO, 2003).

24

Figura 13 Objetos com sombreamento

3.3.3 Ray Tracing

Raytracing a tcnica de renderizao de uma cena que calcula a imagem desta cena simulando a forma como os raios de luz percorrem o seu caminho no mundo real. No mundo real, os raios de luz so emitidos a partir de uma fonte de luz, de acordo com as caractersticas desta fonte de luz ser iluminado os objetos da cena. A luz ento refletida por estes objetos podendo ainda passar atravs de objetos transparentes e semitransparentes. Esta luz refletida ento atinge os olhos do observador ou a lente de uma cmera. Como a grande parte dos raios de luz nunca atinge um observador, programar uma simulao exatamente desta forma impraticvel em termos da quantidade de processamento que desperdiado. Assim sendo, o algoritmo ray tracing limita-se a inverter o sentido do trajeto dos raios de luz, passando agora o observador a ser a fonte, e desta forma apenas sero processados os raios que efetivamente so vistos pelo observador.

25

Figura 14 Imagem renderizada com raytracing

3.3.4 Textura

A textura descreve algumas das propriedades da superfcie de um objeto, como rugosidade e padronagem. Em princpio, possvel modelar esses detalhes com o acrscimo de detalhes na geometria da superfcie ou usando materiais de propriedades ticas distintas. Mais dessa forma o processamento ficaria muito complexo, de modo que, na prtica esses efeitos so modelados com o uso de mapas de textura (AZEVEDO, 2003). A idia bsica reproduzir sobre a superfcie do objeto as propriedades de alguma funo ou mapeamento bidimensional, conforme ilustra Figura 15. Os mapas de textura so tcnicas utilizadas para gerar uma imagem que atribua cor, iluminao, reflexo e sombreamento, sobre um objeto, que seria a exibio de uma imagem sobre o exterior do objeto, uma dessas tcnicas o Texture Map.

26

Figura 15 Textura de imagem.

3.3.5 Texture Map

Texture map foi tradicionalmente usado para adicionar realismo nas imagens geradas por computador. Em sua forma bsica, o mapa de textura aplica uma imagem, ou seja, uma textura sobre um objeto na cena. Por ser muito til e simples, passou a ser considerado como padro para as interfaces de softwares e hardwares grficos. Os mapas de texturas podem ser usados em cenas complexas com um baixo custo de processamento. Quando mapeamos uma textura em um objeto, a cor do objeto em cada pixel modificada pela cor correspondente na textura (AZEVEDO, 2003).

Figura 16 Imagem Texture Maps

27

4 ENGINE (MOTOR GRFICO)

Pelo conceito de engenharia de software trata-se da parte do projeto que executa certas funcionalidades para um programa. Dentro da rea de jogos, um engine se encarregar por entender-se com o hardware grfico, ir controlar os modelos para serem renderizados, tratar das entradas de dados do jogador, tratar de todo o processamento de baixo nvel e outras coisas que o desenvolvedor de jogos normalmente no deseja fazer ou no tem tempo para se preocupar (CLUA e BITTENCOURT, 2005). Uma engine normalmente composta por diversas ferramentas, cada qual responsvel por alguma etapa no processo de criao de um jogo. Segundo Clua e BITTENCOURT, (2005) os componentes mais comuns de se encontrar em engines so os seguintes: Engine Core: este ser um programa que executar a aplicao do jogo, manipular a fase e os objetos, renderizar as cenas, entre outros. Ele a parte principal da engine. Engine SDK: o cdigo fonte do engine core. Atravs dele pode-se alterar o funcionamento do engine. possvel criar jogos sem o SDK de um engine, entretanto, os tipos de aplicaes possveis de serem desenvolvidos sero restritos. Level Editors: atravs deste componente ser possvel unificar modelagens feitas em diversos programas, associ-los programao, inserir cdigos em scripts, entre outros. Veja Figura 17. Conversores/Exportadores: normalmente so plug-ins instalados nos programas de modelagem 3D ou podem estar includos no level editor, tem como funcionalidade importar ou converter os modelos gerados por um level editor ou programa de modelagem 3D especfico para outros editores 3D. Builders: serve para algumas operaes de pr-processamento sobre os objetos. Assim uma engine fornecer as ferramentas para realizar estes prprocessamentos. Normalmente o builder j vem includa no level editor. Linguagens Script: a maior parte do desenvolvimento da lgica do jogo e da IA dos elementos dinmicos desenvolvida sobre scripts e no diretamente sobre o engine core.

28

Figura 17 Exemplo de level editors pertencentes a diversos engines

Pode-se afirmar que um engine na realidade composto por diversas outras engines, sendo cada um responsvel por tratar um tipo de problema referente aos jogos. Os principais componentes so de renderizao, de fsica, de som e de IA (CLUA e BITTENCOURT, 2005).

4.1 ENGINE DE RENDERIZAO

Figura 18 Etapas da engine de renderizao

O engine de renderizao basicamente responsvel, pelo processo de gerar imagens 2D utilizando modelos 3D. Veja a Figura 18. Segundo Clua e Bittencourt, (2005) o processo renderizao dividido em diversas etapas, sendo as mais importantes: Transformaes 3D: nesta etapa aplica-se a movimentao dos modelos 3D. Esta movimentao consiste no seguinte: a cada passo do jogo uma matriz ir armazenado o resultado de todos os movimentos que o objeto sofreu ao longo de

29

sua ao. Antes de visualizar a cena, ser aplicada esta matriz sobre cada vrtice que o compem o objeto, a posicionando-o no local que lhe corresponde naquele instante. Projeo 3D para 2D: os vrtices que compem o objeto so coordenadas 3D, porm a imagem do modelo dever ser desenhada numa superfcie 2D. Nesta etapa, os vrtices do modelo sero projetados sobre o plano de projeo da cmera.

Figura 19 Utilizao da Projeo 3D para 2D

Culling: a funo da tcnica de culling saber escolher os polgonos adequadamente, de forma que numa determinada situaes estejam presentes somente os polgonos que importam para a visualizao a partir de um ponto em que a cmera se encontra. Sendo um recurso para otimizao do processamento grfico de um jogo.

Clipping: ao projetar um polgono no plano de projeo da cmera, alguns polgonos sero projetados totalmente na rea da tela e outros sero projetados parcialmente, ou seja, somente uma parte dele estar na tela de projeo. O clipping e utilizando em cima desses polgonos parcialmente projeto, ele recortar todos esses polgonos, ou seja, criar novas arestas e vrtices.

Rasterizao: a ltima etapa do processo de renderizao consiste em preencher os polgonos adequadamente, aplicando o material com o qual esto definidos, ou seja, dessa etapa se aplica a iluminao e textura sobre o objeto representado. Este processo pode ser feito atravs de um clculo de iluminao para cada um

30

dos pixels (per pixels) do interior dos polgonos ou para cada vrtice (per vertex) visvel na malha, sendo que malha uma coleo de polgonos que definem um objeto 3D.

Figura 20 Rasterizao aplicada na cena

4.2 ENGINE DE FSICA

um modelo de engine que simula o funcionamento de algumas leis da fsica sobre o mundo virtual criado, usando variveis como massa, velocidade, frico e resistncia ar, fazendo o possvel para simular as mesma condies impostas no mundo real. Assim a uma delimitao sobre um objeto, no caso ao andar dentro de um labirinto e bater numa parede o jogador no poder atravess-la; ao dar um pulo, o jogador ir colidir com o cho e no deve continuar caindo para sempre, entre outras aes que ser empregada a fsica para assemelhar o mundo virtual ao mundo real (CLUA e BITTENCOURT, 2005). Segundo Clua e Bittencourt, (2005) os clculos de fsica bsicos num jogo so: Coliso: os objetos 3D devem se colidir um com os outros e retornarem uma ao fsica. Essa coliso no trivial de ser realizada para um mundo virtual como para o mundo real, j que em ltima instncia corresponderia em verificar se cada um dos polgonos de um determinado objeto possui interseo com cada um dos polgonos do restante da cena. Para isso so utilizadas algumas tcnicas como o bouding-box, que consiste em englobar cada objeto por uma caixa e calcular a coliso para a caixa e no para a malha completa do objeto (Figura 21).

31

Figura 21 Tcnica bounding-box

Resultante de foras: os objetos no mundo real se movimentam devido aplicao de diversas foras sobre o mesmo. Num ambiente virtual necessrio simular a aplicao dessas foras sobre os objetos, calculando a resultante a cada instante para verificar como ser seu movimento.

Figura 22 Reao do objeto aps coliso

32

4.3 ENGINE DE SOM

Este componente do engine permitir o controle sobre os arquivos de som da biblioteca de recursos do jogo. Normalmente utilizar alguma API adequada para manipular os arquivos de som, tal como DirectSound ou OpenAL. Alm de permitir abrir e tocar estes arquivos, os engines de som permitem um controle de som posicional, permitindo que objetos emitam sons conforme suas aes em cena e seu posicionamento em relao ao cenrio (CLUA e BITTENCOURT, 2005). Tambm possui outras funes como a diviso entre os canais de sada, o gerenciamento de volume, a criao de vozes virtuais e entre outras funes, para aprimorar o udio dos jogos. Como ilustra a Figura 23.

Figura 23 Engine de som

4.4 ENGINE DE INTELIGNCIA ARTIFICIAL

Entende-se por IA para jogos, os programas que controlam o comportamento dos personagens no controlados por jogadores, tipicamente conhecido como NPCs (Non-Player Characters). Em grande parte dos casos, o comportamento dos NPCs implementado atravs de mquinas de estados. O algoritmo utilizado na mquina de estados procura resolver

33

problemas selecionando um estado entre os diversos possveis, em que o objeto pode se encontrar, esses estados so implementados nos NPCs como mtodos que fazem parte de uma classe (Figura 24). A transio de um estado para outro est diretamente ligada a algum evento do jogo (CLUA e BITTENCOURT, 2005).

Figura 24 Montagem de NPC

Desta maneira, a IA de um NPC basicamente baseado em estados que o mesmo pode se encontrar. Este personagem devera fazer monitoramentos constantes sobre os eventos que possam causas alguma mudana em seu estado (CLUA e BITTENCOURT, 2005). No caso um exemplo em jogos, seria um NPC em estado de espera, onde ele no se movimenta, o jogador se aproxima dele a uma distncia de 30 m, ento o NPC passar do estado de espera para o estado de perseguio, no momento que o NPC alcanar uma distncia de 2m do jogador, ele trocar de estado de perseguio para o estado de ataque. Veja a Figura 25. Tambm a outras tcnicas de IA que podem ser empregadas a jogos eletrnicos, como Pathfinding, Redes de Neurais Artificiais e Algoritmos Genticos.

34

Figura 25 Exemplo de uma mquina de estados

4.5 ENGINE DE REDE

Com o crescimento da popularidade dos jogos online e jogos em rede LAN (Local Area Network) foram desenvolvidas ferramentas para o controle deste recurso em jogos eletrnicos. A engine de rede implementa muito dos recursos utilizado em redes de computadores, sendo utilizado tanto no uso de uma WAN (Wide Area Network) como a Internet ou em redes LAN. Segundo Silva (2009), Uma engine de rede possui uma arquitetura de comunicao ou mais de uma, que podem ser: cliente/servidor, ponto a ponto e servidor mestre. Assim como sua comunicao pode ocorrer atravs dos protocolos de comunicao TCP (Transmission Control Protocol) e UDP (User Datagram Protocol). Os principais recursos destas engine so: sistema de replicao de objetos, conexo segura, autopatcher, chamada de procedimentos, comunicao de voz e NAT Punchthrough (SILVA, 2009).

35

5 ELEMENTOS DE COMPOSIO DE ENTRENIMENTO DIGITAL

Deste capitulo ser abortado os elementos bsicos que compem um jogo eletrnico, alguns pontos abortados nesse captulo j foram previamente citados em captulos anteriores.

5.1 COLISO

A coliso um dos elementos de extrema importncia para jogos eletrnicos, sendo 2D ou 3D, pois sabe-se que os jogos eletrnicos simulam a maioria das caractersticas do mundo real, mesmo sendo jogos fantasiosos seus limites so definidos por aspectos reais, sendo assim leva-se em considerao a impenetrabilidade, isto , a propriedade da matria que consiste na impossibilidade de dois corpos ocuparem no mesmo tempo o mesmo lugar no espao. Segundo Lobo et al. (2010), pode-se dizer que fazer com que um objeto rebata nas bordas da janela uma forma simples de deteco de coliso. Certamente a deteco de coliso entre objetos 2D ou 3D se torna muito mais complexa, quando aplicamos as leis da fsica do mundo real no mundo virtual, pois necessrio aplicar vrios clculos matemticos para definir a reao do objeto aps a coliso. Segundo Lobo et al. (2010), se voc pesquisar algoritmo de deteco de coliso em alguma pgina de busca na internet, encontrar milhares de pginas, apresentando uma srie de diferentes algoritmos para detectar colises entre objetos em sistemas 2D e 3D. Um algoritmo simples de deteco de coliso o Bounding-Box (j citado anteriormente no captulo 4) que consiste em criar uma caixa envolta do objeto para detectar se houve coliso com outra caixa ou com os limites do cenrio. Uma forma simples de implementar o teste de coliso entre caixas de dois objetos simplesmente conferir se a posio x,y do canto superior esquerdo da primeira caixa esta dentro da caixa do segundo objeto, em outra palavras, pega-se a posio x inicial da primeira caixa e soma mais a sua largura, fazendo o mesmo com y, pega-se y inicial da primeira caixa e soma mais a altura, assim se a segunda caixa entrar nesse intervalo da primeira existe uma coliso entre os objetos (Figura 26).

36

Figura 26 Funcionamento do Bounding-Box

Outra tcnica de coliso a coliso por pixel. Este tipo de coliso a mais precisa para ser utilizada em ambientes 2D, porm sendo mais complexa pois a coliso feita a partir dos pixels no transparente de uma imagem. Ento, quando um pixel transparente significa que no teve coliso (Figura 27).

Figura 27 Coliso por Pixel

Na coliso de objetos 3D, h dois mtodos conhecidos, sendo um deles coliso por box, similar ao Bounding-Box e a coliso por polgono, onde aps saber qual a regio no espao que os objetos se intercede, verifica-se se algum dos polgonos de um deles (pertencente regio) colidi com um polgono do outro objeto (tambm pertencente regio).

37

Figura 28 Imagem demonstrando a coliso de objetos

5.2 CMERA

A cmera nos jogos eletrnicos representa a viso do jogador. O modelo de visualizao da cmera se diferencia nos jogos 2D para os jogos 3D, pelos fatores de movimentao da cmera em modelos 3D, que no caso da maioria dos jogos 2D no possui. Alguns dos modelos de cmera para jogos 2D so o Scrolling, Top View e o Side View. O modelo Scrolling permite o jogador visualizar uma pequena parte da dimenso total da cena, assim a imagem projetada superior a abertura da cmera, sendo que conforme a movimentao do personagem pela cena a cmera se movimenta para outra parte da imagem que esta fora do limite de visualizao da cmera. Outro modelo de cmera 2D o Top View, aqui a cmera se posicionada sob a cena, sem nenhuma inclinao, este modelo pode ser utilizado junto com o modelo Scrolling, onde h necessidade de um deslizamento da cmera sobre o cenrio, a utilizao desse dois modelos juntos ocorre com maior frequncia em jogos de naves, enquanto o modelo Top View e bastante utilizado para jogos de tabuleiros onde no h movimentao de cmera.Tambm possui o modelo de cmera Side View onde a cmera se posiciona ao lado do personagem, na maioria dos jogos ocorre Scrolling da tela, jogos famosos utilizam este modelo de visualizao um exemplo a destacar e o jogo Super Mario Bros da fabricante Nintendo. A Figura 28 ilustra os modelos de cmeras 2D.

38

Figura 29 Modelo Scrolling (esquerda), Top View (centro) e Side View (direita)

Os modelos de cmeras para visualizao de jogos 3D se diferem dos modelos aplicados sobre os jogos 2D, por causa da diferena na movimentao da cmera em diversos ngulos no modelos 3D, sendo que o jogador pode rotacional e movimentar a cmera dos trs eixos x, y, z que no caso dos jogos 2D so apenas os dois eixos x, y. Como ilustrado na Figura 29.

Figura 30 - Coordenadas da posio da cmera, e seus 7 graus de liberdade: localizao no espao (x,y,z),ngulos de rotao em torno de cada um dos eixos (setas curvas) e foco. (AZEVEDO, 2003)

Alguns dos modelos de cmera 3D so as cmeras cinematogrficas, cmera em primeira e cmera em terceira pessoa. O modelo de cmera em primeira pessoa bastante utilizado para jogos de tiro, os famosos FPS (First Person Shooter), onde o objetivo da cmera dar a sensao de imerso para o jogador. A cmera fica localizada na cabea do

39

personagem, dando a impresso de que o jogador visualiza exatamente o que o personagem visualiza. O jogador tem um sentido que ele realmente est dentro do jogo (SUGUISAKI, 2007). A Figura 31 ilustra uma cena do jogo Counter Strike.

Figura 31 Counter Strike

As cmeras em terceira pessoa so cmeras que seguem o personagem por trs, comum estas cmeras estar flutuando acima da cabea do personagem, a certa distncia do mesmo para uma visualizao dele dentro da cena. Um dos fatores interessante sobre esta cmera que ela no fixa e oferece vrios ngulos para visualizao do personagem e cenrio. Como ilustra a Figura 32.

Figura 32 - kingdom hearts 358/2 days

40

Segundo Suguisaki, (2007) modelo de cmera cinematogrfica no realizado apena por uma cmera, mas um conjunto de cmeras virtuais. Estas cmeras observam a ao e procuram sempre dar o melhor ngulo da cena, para aumentar a iterao com o jogo. Estas cmeras podem ser fixas, flutuantes e acompanhar o personagem, as cenas so apresentadas ao jogador como se estivessem sendo filmadas, procurando enriquecer o jogo com tomadas de posies, para aumentar o grau de imerso do jogo. A Figura 33 ilustra uma cena do jogo Resident Evil 3, onde a cmera fixa do cenrio.

Figura 33 Cmera mostra uma posio fixa no jogo Resident Evil 3

5.3 ILUMINAO

A iluminao uma tcnica importante em objetos grficos criados atravs do computador. Sem iluminao os objetos tendem a no apresentar caractersticas realistas. O ponto principal da iluminao consiste em simular como os objetos refletem as luzes. H dois fenmenos com maior importncia na gerao de imagens. A interao da luz entre as bordas dos objetos e como a luz absorvida ou espalhada dentro do material. Tcnicas de iluminao podem ser classificadas entre dois grandes grupos. Tcnicas de iluminao global so as tcnicas que consideram todos os feixes de luz emitidos por fontes de luz indiretas.

41

Tcnicas de iluminao local, que levam em conta apenas a fonte de luz e sua incidncia no objeto a ser iluminado.

Algoritmos de iluminao global levam em conta a incidncia dos raios provenientes das fontes de luz assim como a influncia dos raios refletidos por outros objetos na cena. A energia proveniente de uma fonte de luz ao atingir a borda de um objeto absorvida ou refletida. A energia refletida influencia ento nos demais objetos na sala. Tcnicas de iluminao local levam em conta somente a interao dos objetos com as fontes de luz e normalmente so modelos empricos que no levam em conta a lei de conservao de energia (ALBUQUERQUE, 2005).

Figura 34 Iluminao Local (esquerda) e Iluminao Global (direita)

Para a iluminao de um ambiente ou objeto em cena necessita-se das fontes de luz, que so os pontos de iluminao dentro de uma cena. Para uma compreenso melhor das fontes de luz, descreveremos sua natureza e interao com os objetos (MANSSOUR e COHEN, 2006). Fonte de luz Pontual aquela cujos raios de luz emanam igualmente em todas as direes a partir de um nico ponto no espao. Esse tipo de fonte de luz comparvel a uma lmpada. Fonte de luz Direcional aquela cujos raios de luz vm sempre de uma nica direo. Fonte de luz Spot na verdade uma combinao de uma luz pontual com um componente direcional: os raios de luz so emitidos na forma de um cone, apontado para uma direo nica.

42

A Figura 35 ilustra a direo dos feixes de luz das fontes luminosas citado anteriormente.

Figura 35 Luz Pontual (esquerda), Luz Direcional (centro) e Luz Spot (direita) (MANSSOUR e COHEN,

2006) As interaes entre as fontes de luz e as superfcies do objeto so descritas atravs dos modelos de reflexo. Em um modelo desse tipo, consideram-se as propriedades da superfcie e a natureza da fonte de luz (MANSSOUR e COHEN, 2006). Figura 36 ilustra os tipos de modelo de reflexo de luz.

Figura 36 Luz Ambiental (esquerda), Luz Difusa (centro) e Luz Especular (direita) (MANSSOUR e COHEN, 2006)

5.3.1 Difusa

A Luz Difusa a luz que vem de uma direo, ou seja, de uma determinada fonte de luz que se encontra na cena. Uma vez que esta luz incida em uma superfcie, difundida

43

igualmente em todas as direes, assim a superfcie aparece igualmente luminosa, no importando de onde visualizada. Qualquer luz vinda de uma posio particular ou direo tem provavelmente uma componente difusa.

5.3.2 Emissiva

A Luz Emissiva simula a luz que se origina do prprio objeto; a cor emissiva de uma superfcie adiciona intensidade ao objeto, mas no afetada por qualquer fonte de luz; ela tambm no introduz luz adicional da cena. A Figura 37 demonstra uma fonte de luz emissiva, ela representa a luz emitida diretamente por um polgono. Luz emissiva

Figura 37 Luz Emissiva

5.4 TERRAIN

O terreno representa o cenrio onde o personagem esta inserido, este cenrio possui uma paisagem constituda por montanhas, colinas, gramados, rvores e outros aspectos que a deixam mais realista possvel.

44

Para criao de terrenos 3D se utiliza o mapa de altura ( heightmaps), que consiste em um imagens 2D com diversas tonalidades de cinza. Os pixels mais escuros da imagem equivalem s reas baixas do terreno, enquanto os pixels claros as partes alta (CLUA e BITTENCOURT, 2005). A Figura 38 mostra um exemplo de mapa de altura.

Figura 38 Mapa de altura (heightmaps)

Os mapas de altura podem ser pintados manualmente ou atravs de software de edio de imagem, entretanto para relevos mais detalhados existem inmeras ferramentas que podem ger-los e edit-los de forma simples. Alm de gerar os mapas de altura, estes softwares podem aplicar textura sobre os mapas criados. Figura 39 apresenta alguns dos editores de mapas existentes.

45

Mojo Word

Core Bryce

Carrara

Terragen Figura 39 Softwares para edio de mapas de altura

46

6 ARQUITETURAS DE DESENVOLVIMENTO

Neste capitulo so abortados as arquitetura para desenvolvimento de jogos eletrnicos. Atualmente existem vrias arquiteturas sendo estas proprietrias ou gratuitas. Algumas tambm funcionam em diferentes Sistemas Operacionais (SO) sendo Windows, Mac Os e Linux, e suas aplicaes podem ser executadas em diferentes plataformas como consoles, navegadores, SO e dispositivos moveis. Algumas das arquiteturas conhecidas: Ogre3D (C++), GlScene (Delphi), jMonkey (Java), Blender (Python), Unity3D (Boo) e XNA (C#).

6.1 XNA

O XNA um framework gratuito para desenvolvimento de jogos digitais produzido pela Microsoft, sendo seu cdigo baseando no .Net Framework, utiliza como linguagem de programao C# e um conjunto de bibliotecas para desenvolvimento, suas aplicaes executam nas seguintes plataformas Windows, Xbox 360, Zune e Windows Phone 7. Atualmente o XNA esta na verso 4.0, a primeira verso do framework foi lanada por volta de novembro de 2006, mesmo no sendo popular nas comunidades de desenvolvimento o framework j ajudava bastante os programadores no desenvolvimento de jogos para Windows sem a necessidade de conhecimento sobre DirectX (Interface de Programao de Aplicativos Grficos) (GOMES e SILVA, 2011). A Tabela III mostra a evoluo do XNA e suas funcionalidades adquiridas em cada verso.

47 Tabela III Evoluo do XNA

Ano XNA 1.0 2006

Verso e funcionalidades do XNA - Desenvolvimento para Xbox 360 - Arquitetura simples para criao de jogos XNA 2.0

2007

- Multiplayer - Adotado em 700 universidades americanas - 4 contratos XBLA (Xbox Live Arcade) na competio Dream Build Play XNA 3.0

2008

- Jogos da comunidade no Xbox LIVE - Desenvolvimento de jogos para Zune - Suporte ao Xbox LIVE Arcade XNA 3.1

2009

- API de suporte para reproduo de vdeos - Suporte ao avatar do Xbox 360 XNA 4.0 - Desenvolvimento para Windows Phone 7

2010

Segundo Lobo et al. (2010), o grande segredo por trs do XNA a sua facilidade, este framework extremamente simples em comparao com outras bibliotecas de programao de jogos para console e Windows, isso devido abstrao que oferece nos detalhes de controle de grficos, udio, dispositivos de entrada e outros recursos, detalhes estes que esto sempre presente nas demais bibliotecas. O XNA facilita a manipulao dos recursos, o que antes deveria ser programado com vrias linhas de cdigos complexos, passa a ser realizado com apenas uma linha de cdigo, sendo assim carregar um arquivo de imagem no trs preocupao ao desenvolvedor em saber qual a extenso ou como ser tratado esse arquivo. A Figura 40 apresenta uma viso geral da arquitetura XNA.

48

Figura 40 Viso geral da arquitetura XNA

O XNA utiliza como ambiente de desenvolvimento o XNA Game Studio (ferramenta gratuita desenvolvida pela Microsoft) ou Visual Studio (ferramenta paga da Microsoft) para o desenvolvimento de jogos eletrnicos para as plataformas citadas anteriormente, sendo assim, j facilita conseguir um alto grau de compatibilidade. Tambm se pode observar na Figura 39 que h diferenas nas camadas inferiores da arquitetura, pois enquanto a verso Windows dos jogos excuta sobre a .Net Framework, a verses para Xbox 360 e Zune utilizam-se de uma verso compactada deste Framework (LOBO et al., 2010).

6.1.1 Viso detalha do XNA

O XNA Framework se divide em vrias camadas, cada uma com seus componentes, responsveis por atividades especficas. A Figura 41 apresenta uma viso mais detalha do XNA Framework, mostrando quais componentes so oferecidas pela biblioteca, quais se podem encontrar em comunidades de desenvolvedores de jogos e quais so desenvolvidos pelo programador do jogo.

49

Figura 41 Viso detalhada do XNA Framework

6.1.1.1 Jogos

Na camada de jogos, o desenvolvedor responsvel por escrever as linhas de cdigo do jogo e tambm por todo o seu contedo, sendo desde sons at texturas e modelos 3D, os quais so importados de outras aplicaes atravs da IDE (Ambiente Integrado de Desenvolvimento). Tambm na camada de jogos se encontra os Starter Kits que so mini-jogos e aplicaes prontas para o desenvolvedor utilizar. Nessa camada ainda se encontra os componentes, que so cdigos criados por terceiros, mas que podem ser includos nos jogos at mesmo para minimizar o processo de codificao. A Figura 42 mostra um conjunto de Start Kits.

50

Figura 42 Start Kits

6.1.1.2 Extenses

A camada extenses faz com que o XNA se torne uma ferramenta prtica para o desenvolvimento de games e aplicaes utilizando DirectX. Nessa camada encontram-se dois importantes componentes: o Modelo de Aplicao e o Content Pipeline. Juntos, eles so os principais responsveis por facilitar o trabalho dos desenvolvedores (OLIVEIRA, 2011). O Modelo de Aplicao o responsvel pela criao e gerenciamento de janelas do jogo, sendo ele que executa a inicializao do DirectX. Ele tambm responsvel pelo gerenciamento do loop da execuo do jogo. Segundo Lobo (2010), todo jogo segue uma lgica especifica: preparar o todo o contedo inicial do jogo; executar o lao de repetio central do jogo (loop), at que o objetivo do jogo seja alcanado e de fim ao jogo, depois libera o contedo carregado pelo jogo.

51

A Figura 43 exemplifica o processo de loop, mostrando um fluxograma de um jogo simples.

Figura 43 Fluxograma de um jogo (OLIVEIRA, 2011)

Sobre Modelo de Aplicao, quando criado um novo projeto de jogo no XNA, ele j prov as primeiras linhas de cdigo, com comentrios em ingls que nos ajuda entender a lgica da estrutura de nosso jogo (OLIVEIRA, 2011). A Figura 44 ilustra a arquitetura de um programa XNA e o cdigo fonte que apresentado quando se cria um novo projeto XNA.

52

Figura 44 Estrutura do XNA e cdigo fonte do projeto XNA

O Content Pipeline o componente que fornece as ferramentas para processar todo o contedo do jogo. Ele ficar responsvel por tratar as texturas, modelos 3D, imagens, definies de sons e outros recursos, sendo ainda responsvel por aperfeioar todos os contedos importados para o jogo. Ele tambm se responsabiliza por importar diversos tipos de contedos e export-los para arquivos binrios que sero utilizados no jogo (OLIVEIRA, 2011). A Tabela IV mostra os tipos de arquivos que o XNA importa.

53 Tabela IV arquivos importado pelo XNA.

Modelos 3D .FBX .X

Modelos 2D .BMP .DDS .DIB .HDR .JPG .PFM .PNG .PPM .TGA

Material (shaders) .FX

udio .XAP .WAV .WMA .MP3

6.1.1.3 Ncleo

a principal camada do XNA Framework, os seus componentes fornecem recursos para as mais diversas funes do jogo. As funes fornecidas por esta camada so: Graphics: comandos para desenhar os objetos 3D e 2D; Audio: tocar arquivos de sons fornecidos pelo XACT; Input: funes para verificao de controles; Math: auxilio matemtico para clculos com matrizes, aproximaes e funes grficas; Storage: manipulaes de arquivos em PC ou Xbox; Network: oferecendo mtodos simples para conexo de Xbox 360 e PC, nas LAN ou diretamente no Xbox LIVE!.

6.1.1.4 Plataforma

Esta camada do XNA Framework aquela sobre quais todos os demais componentes apresentado anteriormente esto baseados. Esta camada que faz a ligao entre o cdigo fonte e as funcionalidades desenvolvidas pelo programador ao hardware da mquina. Ela possui quatro componentes que so: Direct3D: controla os Grficos 3D; XACT: controla o udio e possibilita a criao de sons; XINPUT: suporte aos dispositivos de entrada (Teclado, Mouse e outros);

54

XContent: suporte a contedo de imagens, vdeos, sprites.

6.1.2 Estrutura do XNA

Segundo Lobo et al. (2010), antes do XNA, a estrutura de um jogo precisava ser codificada, de forma que precisavam se preocupar com os detalhes que no esto relacionados diretamente com o jogo. No caso do XNA esta complexidade ocultada, quando se cria um projeto XNA, so criados arquivos que j incluem os mtodos e cdigos necessrios para o funcionamento de um jogo (Figura 44). A utilidade dos mtodos criados pelo XNA na classe Game1, nome padro que o XNA atribui a classe, so: Game1(): construtor da classe, inicia os arquivos em geral. Initialize(): inicializao do jogo. LoadContent(): carregar os recursos grficos e de som. Run(): inicia o game loop. Update(): ler entrada de dados do usurio, fazer clculos, testar critrios de fim de jogo, executado a cada loop do jogo. Draw(): onde se colocam as rotinas de desenho do jogo, executado a cada loop do jogo. UnloadContent(): libera recursos do jogo.

Figura 45 Inicio da classe Game1.

55

A Figura 45 mostra o inicio da classe Game1, esta classe comea com a criao do objeto GraphicsDeviceManager e SpriteBatch. O GraphicsDeviceManager uma referncia ao gerenciador de dispositivos grficos, tambm conhecido somente como device, atravs deste que possvel acesso s funes da placa grfica do computador. O SpriteBatch tem como utilidade desenhar texto e imagens 2D (LOBO et al., 2010). A inicializao no XNA realizada incluindo-se cdigos nos mtodos Initialize() e LoadContent(). O mtodo Initialize() chamado uma nica vez no jogo, quando se executa do mtodo Run(), logo antes do lao de repetio do jogo se inicializar. Este local correto para incluir as rotinas de inicializao de elementos no grficos, como o contedo de udio para ser tocado. O mtodo LoadContent() o local certo para incluir as rotinas de carregamento dos grficos, pois este mtodo ser chamado toda vez que houver uma alterao no device que obrigue a uma carga, ou recarga, dos grficos (LOBO et al., 2010). O mtodo UnloadContent() onde deve-se colocar todas as rotinas de liberao de dos elementos grficos. Toda rotina que se inclua para carregar os grficos no mtodo LoadContent(), deve-se incluir sua contrapartida, liberando o contedo grfico no mtodo UnloadContent(). A classe Game do XNA oferece dois mtodos de sobrecarregveis que sero chamados automaticamente pelo game loop interno do XNA, sendo eles Update(), onde se deve incluir as rotinas de clculos, e Draw(), onde se devem incluir os desenhos dos componentes do jogo.

6.1.3 Grficos 2D

No XNA a responsabilidade por representar um grfico 2D atribuda a classe Texture2D. Esta classe possui diversas propriedades e mtodos para trabalhar com texturas. A imagem armazenada como um conjunto 2D de texels (texture pixel), tambm denominado Sprite, os texels so a menor unidade que pode ser armazenada na placa grfica e incluem valores para cor e transparncia.

56

Sprite uma imagem 2D que pode ser manipulada de forma independente do resto do jogo. As imagens 2D so desenhadas pelo computador em forma de retngulo, usualmente as sprite tem parte transparentes para no apresenta a forma de um desenho retangular (LOBO et al., 2010).
... protected override void LoadContent() { textura = Content.Load<Texture2D>("ball"); posicao = new Vector2(0f, 0f); spriteBatch = new SpriteBatch(GraphicsDevice); } ...

APNDICE A O APNDICE A ilustra a cdigo fonte de um projeto para desenhar uma imagem 2D na tela, sendo uma imagem esttica. Na primeira linha do cdigo fonte apresentado acima, utiliza-se o gerenciador de contedo para importar uma textura a partir na imagem includa do projeto, ball. Quanto se cria uma varivel do tipo SpriteBatch, vale destacar que precisa-se informar o dispositivo grfico como parmetro. A Figura 46 mostra o arquivo importado na primeira linha de comando.

Figura 46 - ball.bmp

Para a utilizao dos arquivos nos projetos XNA, eles devem ser includos na pasta Content do projeto, o arquivo referenciado no cdigo fonte atravs do nome que atribudo na propriedade Asset Name, a Figura 47 demonstra essa configuraes necessrias na IDE.

57

Figura 47 Microsoft Visual C# 2008 Express Edition

O ltimo mtodo da classe do jogo o mtodo Draw() onde ser desenhada a textura inicializada no mtodo Initialize(). O objeto usando para desenhar a imagem e o SpriteBatch, j citado anteriormente, o mtodo Draw() do SpriteBatch que imprimi a imagem em tela, este mtodo inserido dentro de um bloco que se inicia com uma chamada ao mtodo Begin() do SpriteBatch e fechado com o mtodo End(), como apresentado no trecho de cdigo a seguir.
... protected override void Draw(GameTime gameTime) { GraphicsDevice.Clear(Color.CornflowerBlue); spriteBatch.Begin(); spriteBatch.Draw(textura, posicao, Color.White); spriteBatch.End(); base.Draw(gameTime); }

APNDICE A

58

6.1.4 Fsica

Segundo Lobo et al. (2010) pode-se dizer que fazer uma sprite rebata nos limites na tela j uma forma simples de deteco de coliso. Um algoritmo simples de se implementar para teste de coliso o bounding boxes, j citado anteriormente nos captulos 4 e 5, que consiste colocar a imagem dentro de uma quadrado e analisar se alguma outra imagem atravessa o limite estabelecido do quadrado, tendo assim uma coliso.
public bool Collides(clsSprite outraSprite) { // confere se as duas caixas se colidiram if (this.posicao.X + this.tamanho.X > outraSprite.posicao.X && this.posicao.X < outraSprite.posicao.X + outraSprite.tamanho.X && this.posicao.Y + this.tamanho.Y > outraSprite.posicao.Y && this.posicao.Y < outraSprite.posicao.Y + outraSprite.tamanho.Y) return true; else return false; } Figura 48 Mtodo de deteco de coliso no XNA, modelo Bouding Boxes (LOBO et al., 2010)

6.1.5 Animao

As animaes 2D so compostas por um conjunto de imagens autnomas, organizadas seqencialmente, quando essas imagens so alternadas em um pequeno ciclo de tempo causa a iluso de uma animao, o nome dado a esse efeito flip box. Normalmente as animaes sprite so dispostas em uma nica folha, sendo retiradas as imagens individualmente da folha e desenhadas na tela em uma ordem especifica. Estas folhas so conhecidas como Sprite Sheet (REED, 2009).

59

Figura 49 Sprite Sheet threerings.png (REED, 2009)

Animao 3D representa a movimentao dos objetos ou corpos em 3D, no caso o personagem, para atribuir movimento ao personagem existe um mtodo chamado animao esqueletal. Neste processo e construdo um esqueleto para o modelo onde se liga cada vrtice da malha do modelo a um osso do esqueleto. O content pipeline do XNA no oferece suporte a animao esqueletal, sendo necessrio estender a content pipeline, adicionando suporte a animao esqueletal. Segundo Lobo et al. (2010), o content pipeline suporta parcialmente a animao esquelal, sendo que possvel importar dados de animao de arquivos .X e .FBX, mas no so processados todos os dados que so importados.

60

6.1.6 Controle (Input)

O XNA utiliza classes Keyboard, KeyboardState, Mouse e GamePad para capturar os dados de entrada, no caso os dispositivos padres que o XNA trabalha so keyboard (teclados), mouse e GamePad (controle do Xbox 360). Com poucas linhas de cdigo pode-se implementar a funcionalidade do controle sobre a sprite. A Figura 50 mostra o cdigo fonte de captura das entradas do keyboard, mouse e GamePad.

...
//Capturar entrada do GamePad if (GamePad.GetState(PlayerIndex.One).DPad.Up == ButtonState.Pressed) posicao += new Vector2(0, -5); if (GamePad.GetState(PlayerIndex.One).DPad.Down == ButtonState.Pressed) posicao += new Vector2(0, 5); if (GamePad.GetState(PlayerIndex.One).DPad.Left == ButtonState.Pressed) posicao += new Vector2(-5, 0); if (GamePad.GetState(PlayerIndex.One).DPad.Right == ButtonState.Pressed) posicao += new Vector2(5, 0); //Capturar entrada do Teclado KeyboardState keyboardState = Keyboard.GetState(); if (keyboardState.IsKeyDown(Keys.Up)) posicao += new Vector2(0, -5); if (keyboardState.IsKeyDown(Keys.Down)) posicao += new Vector2(0, 5); if (keyboardState.IsKeyDown(Keys.Left)) posicao += new Vector2(-5 , 0); if (keyboardState.IsKeyDown(Keys.Right)) posicao += new Vector2(5, 0); //Capturar entrada do Mouse if (Mouse.GetState().LeftButton == ButtonState.Pressed) { if (posicao.X < Mouse.GetState().X) posicao += new Vector2(5, 0); if (posicao.X > Mouse.GetState().X) posicao += new Vector2(-5, 0); if (posicao.Y < Mouse.GetState().Y) posicao += new Vector2(0, 5); if (posicao.Y > Mouse.GetState().Y) posicao += new Vector2(0, -5); }

...
Figura 50 Cdigo fonte de captura de entrada de dados

61

6.1.7 udio

O XNA se utiliza da mesma estrutura bsica para gerenciar grficos e sons. Para o XNA, som apenas um contedo adicional para o jogo. No XNA h duas formas de se trabalhar com sons: adicionando os arquivos de udio diretamente no cdigo do jogo ou atravs de um arquivo de projeto gerado pelo XACT (Microsoft Cross-Platform Audio Creation Tool) (LOBO et al., 2010). Para tocar os arquivos de udio diretamente o XNA se utiliza na classe Song para arquivos de msica, sendo suportados arquivos do tipo MP3 e WMA, e para tocar arquivos de efeitos sonoros ele utiliza as classes SoundEffect e SoundEffectInstance, sendo suportado arquivos do tipo WAV. A importao dos arquivos de udio bastante semelhante importao dos arquivos de imagens 2D. O XNA tambm possui uma classe chamada MediaPlayer, que utilizada para tocar a msica repetidas vezes, sem a necessidade de estar chamando um mtodo a todo momento que a msica parar de tocar. Segundo Lobo et al. (2010) a classe MediaPlayer bastante poderosa, oferece diversas funcionalidade e acesso a informaes sobre lbuns e msicas tocadas pelo programa Media Player, da Microsoft. O segundo mtodo para tocar arquivos de udio no XNA utilizar o XACT que uma ferramenta profissional para incluso de arquivos de udio em jogos, sendo utilizado por grandes empresas de desenvolvimento de jogos para o Xbox 360. A grande vantagem de se utilizar XACT para inserir contedo de udio em um jogo, est no poder que a ferramenta oferece para o responsvel pela criao das msicas e efeitos sonoros. Com esta ferramenta pode se configurar previamente diversos detalhes do uso do som no jogo. Basicamente esta ferramenta usada para criar bancos de som, que so compilados em um arquivo XAP, que por sua vez em importado para o projeto do jogo atravs do gerenciador de contedo (LOBO et al., 2010). A Figura 51 mostra tela da ferramenta de udio XACT.

62

Figura 51 Ferramenta de udio XACT

Para o gerenciamento de udio utilizando o arquivo desenvolvido no XACT, o XNA se utiliza de algumas classes, sendo essas a AudioEngine, WaveBank e SoundBank. A classe AudioEngine a referncia do projeto de udio pra os servios de udio do PC e Xbox 360, ela utilizada principalmente para ajustar algumas configuraes gerais, alm de servir como parmetro para instanciar as demais classes. A classe WaveBank uma coleo de arquivo WAV. A classe SoundBank uma coleo de efeitos sonoros. Esses efeitos sonoros que so tratados no projeto do XACT, sendo alterados diversos detalhes no som, para serem aplicados no jogo. Tambm existe a classe Cue que oferece uma srie de mtodos e propriedades para que possibilite o melhor controle sobre a execuo do som (LOBO et al., 2010).

63

6.1.8 Grfico 3D

Quando se trata com sistemas de coordenadas cartesianos de trs dimenses, h dois tipos possveis de sistemas: sistemas de mo esquerda (left-handed) e sistemas de mo direita (right-handed). Estes nomes se referem posio do eixo z em relao aos eixos X e Y. A Figura 52 ilustra os dois sistemas de coordenadas cartesianos de trs dimenses.

Figura 52 Sistemas de coordenadas de trs dimenses

O XNA trabalha por padro com o sistema de coordenadas de mo direita, sendo que quando atribudos valores negativos para Z tornam um objeto visvel, e quanto mais negativo o valor de X deste objeto, mais distante se encontrar e menor aparecer na tela (LOBO et al., 2010). O XNA se utiliza de dois tipos de projees assim como a maioria das bibliotecas de programao de jogos, sendo elas Projeo de Perspectiva, citadas anteriormente no captulo 5, e Projeo Ortogonal, desta projeo os objetos no reduzem de tamanho quando o jogador se afasta dele. A parte mais bsica de uma imagem 3D o vrtice. Matematicamente vrtices so apenas coordenadas 3D, mas no XNA elas podem incluir informaes adicionais, como cor, textura entre outras, isso depende do formato do vrtice (LOBO et al., 2010). A Tabela V apresenta as definies de vrtices oferecidas pelo XNA.

64 Tabela V Definies de formato de vrtice no XNA.

Formato VertexPositionColor VertexPositionTexture

Descrio Define um vrtice com posio e cor para desenho Define um vrtice com posio e coordenadas de textura, que definem como mapear uma dada textura sobre aquele vrtice, sendo (0,0) o canto superior esquerdo da textura e (1,1) o

canto inferior direito VertexPositionColorTexture Define um vrtice com posio, cor e coordenadas de textura VertexPositionNormalTexture Define um vrtice com posio, coordenadas de textura e vetor normal
Fonte: Lobo

et al., 2010.

A classe que a referncia para placa grfica possui um mtodo chamado DrawPrimitives(), que utilizado para desenhar o contedo do conjunto de vrtices conforme a primitiva de desenho definida pelo desenvolvedor atravs da classe PrimitiveType. Tambm existe classe chamada BaseEffect, est classe oferece propriedades e mtodos que permitam o desenvolvedor definir diretamente os detalhes necessrios para desenhar uma cena 3D. Alguns das propriedades que essa classe possui so (LOBO et al., 2010): View: a matriz de viso, que define a direo e posio da cmera. Project: a matriz de projeo que utilizada nos mapeamento de coordenadas 3D. Word: a matriz do mundo. LightingEnable: cena desenhada com uma luz bsica. EnableDefaultLighing: define uma luz branca e direcional. AmbientLightColor: define a cor da luz ambiente. FogColor, FogStart e FogEnd: define uma neblina pra a cena.

Para as bibliotecas de desenvolvimento de jogos, tambm possvel importar objetos 3D criados por outros programas, esse objetos so conhecidos como modelo 3D, ou simplesmente modelo. A definio de modelo uma hierarquia de malhas que podem ser desenhas independentemente, sendo malha uma coleo de vrtices interconectados, junto com informaes de desenho. O XNA oferece algumas classe para manipulao de modelos e malhas, sendo elas Model e ModelMesh.

65

No existe nenhuma classe no XNA que trabalha diretamente com a cmera, mas ele oferece varias propriedades e mtodos que ajudam o programador a desenvolver sua prpria classe de gerenciamento dos tipos de cmeras existentes para visualizao de jogos 3D.

6.1.9 Cenrio

Assim como o XNA no possui uma classe que trabalha diretamente com a cmera, ele tambm no possui nenhuma classe que trata diretamente do terreno, sendo assim, o desenvolvedor pode programar a sua prpria classe que gerencia o terreno, utilizando os diversos modelos para criao de terreno, o desenvolvimento das classes necessrias para o gerenciamento do terreno no se torna difcil com as classes, mtodos e propriedades disponibilizadas pelo XNA. O modelo mais comum para criao de terreno o mapa de altura, citado anteriormente no captulo 5, onde se utiliza uma imagem 2D para a criao do cenrio 3D.

6.1.10 Grafo de Cena

O XNA no oferece uma classe de suporte ao grafo de cena, sendo ele basicamente a associao entre os objetos, em que o n principal incorpora o demais ns que so as representaes de classes. O desenvolvedor pode criar sua classe de suporte ao grafo cena, e fazer com que as demais classes utilizadas pelo jogo a implemente.

6.2 GLSCENE

66

GLScene uma biblioteca 3D para Delphi baseada em OpenGL (Open Graphics Library), e desenvolvida por Mike Lischke e Eric Grange. Atualmente est na verso 1.1 CVS (Concurrent Version System). Essa ferramenta tem componentes visuais que permitem a descrio de objetos e renderizao de cenas em 3D. GLScene no uma simplificao da OpenGL, nem uma biblioteca de utilitrios, mas uma abstrao em alto nvel, orientada a objetos, que utiliza conjuntos de classes para criar ambientes genricos 3D, aliados tecnologia RAD (Rapid Application Development). A GLScene uma ferramenta que permite construir cenas em 3D sem que haja a necessidade de aprender a codificao OpenGl ou utilizar as classes OpenGl para o desenvolvimento, pois dispe de componentes que englobam as caractersticas de um Grafo de Cena, citado anteriormente no captulo 2. A GlScene uma biblioteca Open-Source, licenciada pela Mozilla Public License. Seu cdigo fonte fornecido a qualquer indivduo que queira colaborar para o aperfeioamento da ferramenta em futuras verses (RIEDER e BRANCHER, 2002). Encontram-se, atualmente, as verses disponveis desse componente para as ferramentas de programao: Borland C++ Builder 5 e 6; Delphi 6 e 7; e Lazarus (Verso Freeware Delphi) (LISCHKE e GRANGE, 2011). A Figura 53 ilustra as paletas de componentes da verso 1.1 do GlScene.

Figura 53 Paletas de componente do GlScene

6.2.1 Cenrio

67

Um cenrio na GLScene definido por uma estrutura hierrquica de objetos que fazem parte do AV. Estes so adicionados cena pela prpria ferramenta, conforme a escolha do programador, optando por formas pr-definidas (prontas), estruturais (desenvolvidas em outros aplicativos) ou procedurais (desenvolvidas pelo programador utilizando a GLScene). Existe ainda a possibilidade de rotacionar e dar movimento aos objetos, sejam eles em uma, duas ou trs dimenses. Fundos de cena, luzes, cmeras, efeitos especiais, animao de objetos estticos por meio de outras formas e importao de arquivos no formato 3D Studio e Quake Models (Figura 54) como referncias para Avatares ou objetos estticos presentes em um AV com clculo vetorial automtico e preciso e a importao de texturas, tambm so suportados e apresentam bons rendimentos na renderizao (LISCHKE e GRANGE, 2011).

Figura 54 Grficos 3D que podem ser importados no GlScene

Tipos de arquivos suportados para importao no GlScene so ilustrados na tabela seguinte (Tabela VI):
Tabela VI - Formato de modelos para importao em uma aplicao.

Aplicativo 3d Studio Quake 2 Models Quake 3 Models Wave Front Object Half Life Models Normal Mapper File GNU Triangulated Surface Ghoul2 FSRad
Fonte: glscene.org

Formato 3DS MD2 MD3 OBJ SMD NMF GTS GL2 OCT

O componente GLScene da paleta de ferramentas GLScene utilizado para o gerenciamento da cena, sendo responsvel pelo gerenciamento de diversos outros

68

componentes. O componente TGLFreeForm utilizado para importao de objetos 3D, sendo esse tipo de objeto representao de qualquer forma importada para a cena. O GlScene tambm trabalha com objetos 2D, utilizando o componente TGLSprite que a representao de um sprite, que so formas 2D inseridas num mundo 3D, sendo caracterizado por sempre mostrar a mesma face para a cmera, podendo girar nos 3 eixos se necessrio.

6.2.2 Materiais

Podem-se personalizar materiais disponveis pela ferramenta e adicion-los a essa biblioteca. A aplicao de materiais, com efeitos de iluminao difusa, especular (citados no captulo 5), contraste, brilho e matizao, conferindo maior realce aos componentes do programa e aproximando-os da realidade. O GlScene se utiliza do componente TGLMaterialLibrary da paleta GLScene, para personalizar os materiais encontrados em cena. O GLScene tambm possui os shaders, componentes que adicionam certos efeitos visuais nos materiais.

6.2.3 Estrutura

Uma das grandes vantagens da GLScene a habilitao automtica de driver OpenGl (caso exista). Alm disso, podem-se ajustar diversas cmeras em um nico cenrio, permitindo diferentes visualizaes em diversos ngulos, bem como proporcionar efeitos de neblina e sombra, reflexo de objetos (espelhos) e suporte para tela cheia.

6.2.4 Animao

69

Atribuir movimentao aos objetos requer cadncia dos mesmos (Figura 55). A biblioteca fornece a cadncia de maneira automtica, com propagao de eventos progressivos ao tempo, manipulao de comportamentos dos objetos e aplicao de fsica dinmica: inrcia, acelerao, frenagem e fora. Pode-se tambm interpolar frames e permitir metamorfoses. Os componentes responsveis pelo gerenciamento das animaes so: o TGLActor, sendo este responsvel pela importao das animaes 3D e o GLAnimatedSprite utilizado para importao de animaes 2D.

Figura 55 - Animao por esqueletizao de um objeto virtual

6.2.5 Interface

A interface dispe de funes para seleo de objetos que ajudam na movimentao das cmeras e na translao de objetos. A interface de aplicao tambm auxilia na converso entre telas e coordenadas de mundos virtuais, utilizando a tcnica raycasting (Figura 56) utilizada para seleo de objetos virtuais distantes do usurio (PINHO, BOWMAN e FREITAS, 2002). O componente GLGuiLayout permite a criao de interfaces para o usurio interagir com o programa. Essas interfaces so bem semelhantes as do Windows. Este componente possui propriedades que definem a aparncia da interface.

70

Figura 56 - Usurio indicando objeto virtual distante.

6.2.6 udio

A biblioteca pode receber a habilitao de som 3D em movimentos, objetos e na prpria cena, com atualizao automtica de posicionamento, orientao e velocidade de entrada e sada de som. O componente TGLSoundLibrary utilizado para armazenar os arquivos de udio como efeitos sonoros e trilhas de msica para ser utilizado por outros componentes que so: TGLSMFMOD, TGLSMBASS, TGLSMWaveOut e o TGLSMOpenAL estes so

usados para o gerenciamento do udio.

Os tipos de som 3D suportados so: WAV MP3 Formatos anteriormente citados. OGG MP2 RAW Formatos seqenciais: MIDI, MOD, IT, S3M e XM

Os tipos de som 2D suportados so:

71

6.2.7 Controle (Input)

O GlScene utiliza como dispositivos de entrada o mouse e keyboard. Para captura dos dados de entrada pelo mouse o GlScene oferece dois mtodos: a utilizao dos eventos da view como OnMouseMove, OnClick e outros eventos relacionados ao mouse ou utilizao dos componentes TGLNavigator e TGLUserInterface que fornecem uma movimentao da cmera em torno do objeto selecionado pelo desenvolvedor. Para captura dos dados do keyboard o GlScene oferece um recurso atravs de linhas de cdigo, sendo este a Uses Keyboard que oferece o mtodo isKeyDown() para capturar a teclas pressionadas pelo jogador, este mtodo necessita ser verificado constantemente, para isso usa-se o componente TGLCadencer que fornece um funcionamento de loop para o jogo, sendo assim os cdigos de captura dos dados escrito dentro do nico evento do TGLCadencer e a cada frame estes cdigos so executados para saber se houve alguma ao por parte do jogador.

6.2.8 Utilitrios

O utilitrios so componentes utilizados para auxiliar os demais componentes do GlScene, tendo como funes: otimizao de funes geomtricas (vetores, matrizes e quaternrios), componente para a salvar tela, relgio assncrono, determinao da velocidade de quadros por segundo e suporte para joystick. Os utilitrios se encontra na paleta GLScene Utils da biblioteca GlScene.

6.2.9 Grafo de Cena

O grafo de cena apresentado pelo GlScene atravs de um componente visual chamado GLScene, este abre uma pequena janela mostrando todos os objetos utilizado na

72

aplicao, o sistema de apresentao dos objetos nessa janela uma treeview, onde cada objeto que se encontra dentro de outro objeto pertencente a ele, assim como exibido do captulo 2. A Figura 57 ilustra a janela de grafo de cenas do GLScene.

Figura 57 Grafo de Cena no GlScene

6.3 OGRE 3D

Ogre (Object Oriented Graphic Rendering Engine) uma engine grfica 3D flexvel, escrita em C++, OO (Orientado a Objetos), multiplataforma e de cdigo aberto. Existem verses da Ogre para outras demais linguagens como Python, Java e Microsoft .Net. O Ogre cuida apenas da parte grfica com relao ao ambiente 3D. Fsica, rede, interface, som e outros componentes do jogo devem ser adicionados atravs de outras bibliotecas que possuem compatibilidade com o Ogre. Algumas das bibliotecas desenvolvidas para auxiliar o Ogre com o desenvolvimento dos jogos foram: OIS (Object Oriente Input System) biblioteca para dispositivos de entrada como teclado, mouse e joystick. CECUI (Crazy Eddies GUI System) biblioteca para desenvolver interface de usurio.

73

ODE (Open Dynamic Engine) biblioteca para trabalhar com a fsica de ambiente e objeto.

Com o conjunto de biblioteca do Ogre possvel desenvolvimento de jogos, visualizao de arquiteturas, simulaes ou qualquer aplicao que necessite de uma soluo para renderizao 3D. Muito utilizado para o aperfeioamento de jogos digitais, o Ogre3D possui caractersticas que facilita a execuo de uma aplicao grfica, j que oferece recursos que aumentam o desempenho durante a renderizao de cenrios e objetos 3D. (NUNES, 2009). O Ogre pode ser utilizado por varias ferramentas de desenvolvimentos, sendo o Code::Blocks, DevC++, Eclipse, Netbeans, KDevelop e Visual C++ Express Edition da Microsoft.

Figura 58 Ogre executando no Visual C++ 2008 Express Edition

Os sistemas operacionais que o Ogre pode ser utilizando so Linux, Windows e Mac OS X, sendo este ltimo no suportado oficialmente, mas realizando a compilao do Ogre possvel ser utilizada. Tambm possvel a escolha entre os dois renderizadores principais do mercado, o OpenGl e o DirectX (REDIEL, 2007). Com relao instalao desta engine de jogo, no um procedimento fcil devido ao fato de no s ser necessrio instalar o motor do jogo propriamente dito, mas tambm

74

outros componentes auxiliares. Existem vrias maneiras para poder utilizar o Ogre. Uma opo seria fazer o download do SDK (Software Develoment Kit) pr-construdos. Nesta opo no necessria construir cdigo fonte para utilizao do Ogre, sendo j existente bibliotecas e arquivos de cabealhos prontos, juntamente com todos os programas de demonstrao que podem ser utilizado pelo desenvolvedor em suas aplicaes. Outra opo o download do cdigo fonte, onde se pode aprender como o Ogre funciona internamente, mudar suas configuraes de compilao, melhorar o funcionamento da biblioteca e at contribuir com pacthes (pacotes de atualizao). Est opo requer mais trabalho do desenvolvedor para ser utilizada. Como ltima opo tem-se o SVN (Subversion) esta a ltima palavra em flexibilidade para poder obter o cdigo fonte de uma forma direta do repositrio de cdigo fonte, sendo a principal vantagem a obteno de correes de bugs e de novos recursos (NUNES, 2009).

6.3.1 Classes

Sendo o Ogre OO, ele utiliza classes para a abstrao dos objetos necessrios no desenvolvimento. A arquitetura adotada pelo Ogre se utiliza dos vrios padres de projeto, que a torna simples e fcil de usar. Vrios conceitos e padres so introduzidos pela arquitetura sendo os principais: Root, SceneManager, Entity, SceneNode, Camera e FrameListener.

75

6.3.1.1 Root

A classe Root o ponto de partida do Ogre. Ela deve ser instanciada antes de qualquer outro elemento, pois responsvel por dar origem a todo o sistema e administrar o acesso ao mesmo. Desta forma, ela tambm deve ser a ultima a ser destruda, pois seu trmino significa fim do uso da biblioteca (FARIAS et al., 2011). Ao criar uma instncia da classe Root o construtor recebe trs parmetros, sendo o pluginFile: indicando um arquivo de configurao, este arquivo aponta onde se localiza os plugins do Ogre; configFile: aponta o arquivo de configurao da janela de configurao de renderizao; logFile: aponta para o arquivo de log a ser usado pelo Ogre.

6.3.1.2 SceneManager

A classe SceneManager armazena e manipula todo o contedo da cena que ser renderizado pela engine. Sendo ela tambm responsvel por aplicar algoritmos para otimizar a exibio da cena, criar e controlar todas as cmeras, os objetos mveis (Entities), as luzes, as malhas e as partes estticas da cena (FARIAS et al., 2011). Existem diversos tipos de SceneManagers: ST_EXTERIOR_CLOSE: para ambientes abertos no extensos. ST_EXTERIOR_FAR: para ambientes abertos extensos. ST_EXTERIOR_REAL_FAR: para ambientes muito extensos. ST_INTERIOR: para ambientes pequenos e fechados.

6.3.1.3 Entity

A Entity uma instncia de um objeto mvel na cena, sendo qualquer o objeto que vem a ser representado por uma malha. Por exemplo, personagens, carros, avies ou objetos

76

pequenos que tem mobilidade na cena. Alguns elementos que podem parecer Entity, mas no so como luzes, cmeras e partculas estes so uma espcie de SceneNode. Uma Entity criado utilizando a funo createEntity() do SceneManager, em que ela recebe dois parmetros, sendo o primeiro o nome da entity e o segundo o nome da malha a ser utilizado. O formado de malha utilizado pelo Ogre o .mesh, que pode ser convertido por diversas ferramentas para utilizao no Ogre.

6.3.1.4 SceneNode

O SceneNode utilizado para guardar as informaes dos objetos anexados a ele, como entity, luzes, cmeras e objetos mveis. Sendo que atravs do SceneNode se manipula a posio, orientao e escala dos objetos anexados a ele. Toda Entity, para se torna visvel, deve-se estar anexada a um SceneNode, que deve fazer parte da estrutura hierrquica que compem a cena. Segundo Farias et al. (2011) pode-se utilizar o SceneNode para aplicar transformaes espaciais s entities anexadas. Estas transformaes so aplicadas hierarquicamente a todos os ns descendentes, ilustrado pela Figura 59.

Figura 59 Hierarquia do SceneNode (FARIAS et al., 2011)

77

6.3.1.5 Camera e ViewPort

A classe Camera representa um ponto de vista da cena, referenciada por um n com propriedades de Frustum. A cmera Frustum a apresentado como uma pirmide de visualizao, onde a cmera se encontra no topo. O Frustum possui atributos como campo de vista (ngulo aberto), aspecto (relao entre largura e altura) e os planos que delimitam o volume de visualizao (near plane e far plane) (Figura 60).

Figura 60 viso do Frustum

O ViewPort a rea da janela em que a cmera associada ao viewport (janela de visualizao) ir renderizar suas imagens.

6.3.1.6 Framelistener

A classe FrameListener responsvel pelo loop do Ogre. Ela possui trs mtodos: frameStarted() que chamado antes da renderizao do frame na janela , frameEnded() que chamado aps a renderizao e o frameRenderingQueued() que chamado aps os comando de rendeizao serem emitidos, mas antes da renderizao do frame na janela. O cdigo do projeto pode ser colocado todo dentro de um deles ou distribudos entre os eles.

78

6.3.2 Controle (Input)

O OIS uma biblioteca desenvolvida em C++, totalmente orientada a objeto, multiplataforma que prove uma simples soluo para os diferentes tipos de dispositivos de entrada como: teclado, mouse e joystick. O Ogre por padro j vem com a OIS, mas no h obrigatoriedade de escolher est biblioteca para o gerenciamento dos dispositivos de entrada, podendo o desenvolvedor escolher qualquer outra biblioteca que se integre com o Ogre. O OIS fornece as classes KeyListener, MouseListener e JoyStickListener, sendo estas responsvel por realiza o trabalho de escutar os dispositivos e realizar uma chamada de callback s classes nelas registradas (REDIEL, 2007).

6.3.3 Fsica

Conectores de bibliotecas fsicas so implementados pelo padro de projeto Adpater, que servem para preencher a lacuna entre as bibliotecas fsicas e o Ogre. Na maior parte, a biblioteca fsica conduz a transformao do objeto e atualiza a associao da instncia de Entity com base no retorno da coliso no mundo fsico (JUNKER, 2006). Algumas das bibliotecas fsicas que oferecem integrao com o Ogre so OgreODE e o OgreNewton.

6.3.3.1 OgreODE

ODE uma biblioteca de cdigo aberto, sendo de alto desempenho para simulao dinmica de corpos rgido. Ela estvel, madura e independente de plataforma, podendo ser utilizada com linguagem C ou C++.Possui um conjunto de tipos avanados e integra deteco de coliso com atrito. ODE til para simular veculos, objetos em AV e criaturas virtuais.

79

Sendo esta biblioteca que programa os clculos de fsica reais para o desenvolvedor. Seu autor original Russel Smith.

Figura 61 Imagem demonstrando fsica real com OgreODE

6.3.3.2 OgreNewt

A OgreNewt outra biblioteca de fsica gratuita para uso no comercial, seu SDK est ativo e em desenvolvimento. OgreNewt o conector desenvolvido para adaptar Newton ao Ogre (JUNKER, 2006). Newton possui soluo integrada para simulao em tempo real. A API tambm fornece gerenciamento de cena, deteco de coliso e comportamento dinmico, sendo ainda pequena e rpida.

6.3.4 udio

Segundo Riedel (2007), a OpenAL (Open Audio Library) uma API de udio 3D multi-plataforma, apropriada para jogos e outras aplicaes que necessitam de udio. A OpenAL licenciada atravs da LGPL (Lesser General Public License), foi desenvolvida

80

originalmente pela empresa Loki Software com o objetivos de facilitar a portabilidade dos jogos criador em Windows para o plataforma operacional Linux. Atualmente o projeto da biblioteca pertence Creative Techonogy. As funcionalidades desta biblioteca esto baseadas em trs conceitos: source objects (objeto que emite som), audio buffers (som emitido pelo objeto) e listener (ouvinte). O source object contm a referncia de um audio buffer alm dos atributos como velocidade, posio, direo e intensidade. O listener determinado atravs dos atributos velocidade, posio e direo. A biblioteca capaz de criar efeitos de atenuao e efeito Doppler. A OgreAL a biblioteca utilizada como conector de udio para integrao da API OpenAL ao Ogre.

6.3.5 Interface

Para o desenvolvimento de jogos digitais, alm de toda estrutura grfica, fsica e de udio, necessrio o desenvolvimento da parte de interface com o usurio, sendo tambm conhecida como GUI (Graphic User interface). Estas interfaces oferecem a criao de janelas, botes, caixas de textos e entre outros recursos necessrios para interao com o usurio. Sendo o Ogre uma engine grfica, ele no fornece nenhum tipo de suporte a GUI, sendo assim, responsabilidade do desenvolvedor programar esta parte. Para no ter a necessidade de programar as interfaces do incio, a biblioteca CEGUI fornece a estrutura para o desenvolvimento das GUI, liberando o desenvolvedor deste trabalho. A CEGUI uma biblioteca livre que providncia janelas e GUI para as API e motores grficos em que estas funcionalidades esto ausentes ou possuem grave falta. A biblioteca orientada a objeto, desenvolvida em C++, sendo orientada para os desenvolvedores de jogos digitais gastarem seu tempo com o desenvolvimento de jogos e no construindo subsistemas GUI (CEGUI, 2011).

81

Figura 62 Interfaces geradas pelo CEGUI (CEGUI, 2010)

Segundo Riedel (2007), a vantagem de se utilizar o CEGUI pela facilidade dele ser implementado na aplicao, necessitando de poucas linhas de cdigo para coloc-lo em funcionamento. Sendo suas telas baseadas em arquivo XML, deve-se apenas indicar o arquivo a ser carregado, que a interface estar carregada, podendo ser exibida no momento que o desenvolvedor desejar. Tambm possvel criar componentes em tempo de execuo, atendendo a qualquer tipo de necessidade para configurao da interface.

6.3.6 Animao

O Ogre trabalha com vrios tipos de animao sendo elas Skeletal Animation, Pose Animation, Morph Animation e Blending Animation.

82

6.3.6.1 Animation State

A principal interao entre o aplicativo e animao em Ogre atribuda atravs da classe AnimationState. Na ferramenta de modelagem, pode-se definir mltiplas animaes de esqueleto ou malha em um timeline. Como parte do processo de exportao, diferentes parte de uma timeline em um objeto de animao pode receber nomes, no cdigo fonte do projeto esses nomes servem para retornar diferentes animaes dentro de uma Entity. O objeto retornado um AnimationState que permite acesso as seguintes propriedades da animao (JUNKER, 2006): Lenght: obtm o comprimento. Current position: obtm ou grava a posio atual. Animation name: obtm o nome da animao. Looping: obtm ou grava se animao repetir quando chegar ao final do segmento. Enabled: obtm ou grava se animao est ativada. Weight: obtm ou grava a quantidade de influncia que animao tem quando misturadas com outras.

6.3.6.2 Skeletal Animation

A Skeletal Animation o tipo mais comum usado em animao de corpos dinmicos. Com esta animao os vrtices em uma malha so vinculados a ossos que compem o esqueleto. Em comparao com o corpo humano a animao do corpo criado pelo computador no possui realmente estes ossos, eles so representados por um desencarnado onde se define a posio do osso, orientao e escala (Figura 63). O esqueleto e definido por uma cadeia hierrquica. Onde cada osso possuir um antecessor e possivelmente um sucesso, no sendo necessrio que o osso possua um sucesso, pois ele pode ser o ultimo osso. Normalmente, todos os ossos de um esqueleto tero um antecessor, exceto um, que a raiz de esqueleto.

83

Figura 63 - Skeletal Animation

6.3.6.3 Pose Animation

Pose refere-se ao fato de que diversas imagens de um modelo de animao so armazenas nas trilhas de animao. Essas imagens podem ser misturadas para criar uma animao mais complexa do que a utilizao delas separadamente (JUNKER, 2006)..

6.3.6.4 Morph Animation

Morphing uma tcnica utilizada para transformar a forma de um objeto 3D (Figura 64). Morph Animation utiliza-se de diferentes modelos, para transformao de um objeto fisicamente em outro. O animador deve selecionar pontos em comum entre os dois objetos para transformao. Como exemplo, um rosto tem-se os seguintes pontos olhos, orelhas, cabelos, nariz entre outros detalhes. O animador deve prestar ateno ao definir os pontos de transformao entre os objetos, sendo que espaos em branco e sombras tambm devem ser observados (SILVA, 2009).

84

Figura 64 Morphing 3D

6.4.6.5 Bleding Animation

Bleding Animation utilizada para sincronizar os intervalos entre diferentes animaes. Por exemplo: o personagem est executando a ao de correr, em seguida ele precisa parar; a troca de ao brusca mostraria uma imagem do personagem correndo e depois ele parado, nesse caso no haveria movimentao realista. O Bleding Animation misturar esses dois quadros, assim elimina gradualmente a ao de correr e entra-se na ao de parado, atribuindo maior realidade ao movimento do personagem.

6.3.7 Cenrio

Segundo Riedel (2007), o cenrio um conjunto de informaes, como malhas que compem os objeto e terreno, os personagens, luzes, cmeras e outros elementos da cena 3D. Para que possa ser criado, dever-ser todo modelado em um software modelagem 3D, sendo depois exporta em uma linguagem de script.

85

O Ogre oferece alguns recursos para implementao do cenrio como luzes, sombras, terrain, Sky Box, Sky Dome, Sky Plane e Fog.

6.3.7.1 Terrain

A importao de um terreno em uma cena feita atravs do mtodo chamado heightmap, citado anteriormente no captulo 5, este mtodo se utiliza de uma imagem em escala de cinza em que cada pixel representa um valor de altura, sendo 0 o nvel do solo e 255 o ponto mais alto do terreno. Para insero do terreno no ambiente 3D do Ogre, se utiliza o mtodo SetWorldGeometry() da classe SceneManager, este mtodo recebe como parmetro um arquivo de script que possui as configuraes do terreno. Este arquivo encontra-se junto com a biblioteca do Ogre, o nome do arquivo terrain.cfg. O terreno texturizado com uma imagem esticada sobre ele. Essas texturas so tipicamente marrom para montanhas, verde, branco ou cinza para terra, grama neve ou pedra. As imagens aplicadas para texturizao normalmente so menores do que o terreno a ser coberto, causando o aparecimento de borres quando visto de perto. Para ajudar com este problema, se utiliza um detalhe de textura, que uma imagem misturada com a textura do terreno, quando o terreno o visualizado de perto (OGRE, 2011). A Figura 65 demonstra uma comparao entre dois terrenos, sendo um aplicado o detalhe de textura.

86

Figura 65 Diferena entre textura do terreno, utilizando detalhes de textura (OGRE, 2011)

Os parmetros bsicos de configurao do script so: WorldTexture: define a imagem que ser utilizada como textura. DetailTexture: define a imagem utilizada no detalhe de textura. DetailTile: especifica o numero de vezes que a DetailTexture ser repetida em cada tile do terreno. Tile uma diviso do terreno 3D, faz referencia a diviso de um terreno por metro quadrados. PageSource: define a fonte do heightmap. Heightmap.image: define o arquivo de imagem que ser utilizado para desenhar o terreno. PageSize: especifica o tamanho dos vrtices do terreno. O PageSize deve possuir o mesmo valor que a dimenso de um dos lados da imagem utilizada no Heightmap.image. TileSize: determina a quantidade de divises que o terreno ter em suas dimenses. MaxPixelError: define o quantidade de erros permitidos na gerao do terreno. PageWorldX e PageWorldZ: define a dimenses do terreno dentro das coordenadas do mundo. MaxHeight: define a altura mxima do terreno.

87

6.3.7.2 SkyBox

O SkyBox basicamente um grande cubo que engloba todo o ambiente 3D. Serve tambm para adicionar um fundo ao ambiente (Figura 66).

Figura 66 SkyBox

Para criar o SkyBox se utiliza o mtodo setSkyBox() da classe SceneManager, o mtodo possui quatro parmetros para serem preenchidos, o primeiro parmetro recebe um valor booleano que indica se o SkyBox est habilitado ou desabilitado, o segundo parmetro qual o material que dever ser utilizado como SkyBox, o terceiro indica a distncia da cmera do SkyBox e o quarto informa se o SkyBox ser desenhado antes da cena ou depois, este parmetro recebe um valor booleano.

6.3.7.3 SkyDome

O SkyDome uma esfera que cobre todo o ambiente 3D, ele semelhante ao SkyBox, a diferena que sua textura aplicada de forma que aparenta ser uma esfera. Este tipo de cu no possui a texturizao da base, logo, sendo necessria a utilizao de um terreno. A

88

implementao do SkyDome e feita atravs do mtodo setSkyDome() da classe SceneManager, este mtodo possui seis parmetros, sendo que o dois primeiros e os dois ltimos so os mesmo do mtodo setSkyBox(), o terceiro parmetro define o valor de curvatura da textura e o quarto informa quantas vezes a textura poder ser repetida no SkyDome (RIEDEL, 2007).

6.3.7.4 SkyPlane

O SkyPlane se difere dos outros cus, devido ao fato dele se comportar como uma superfcie plana, sendo apenas um plano colocado acima do ambiente 3D. Em sua criao envolve a utilizao de uma superfcie plana onde o SkyPlane ser aplicado, com o mtodo setSkyPlane() da classe SceneManager, este mtodo recebe o seguintes parmetros, o primeiro define se est habilitado, o segundo define o plano a ser usado, o terceiro define a textura, o quarto especifica a dimenso do SkyPlane, o quinto define a quantidade de vezes que a textura ser aplicada e o sexto informa se o SkyPlane ser desenhado antes ou depois da cena.

Figura 67 SkyPlane

Observa-se que na Figura 67 o SkyPlane no preenche todo o horizonte, ficando um espao negro no cenrio. Para corrigir este problema pode-se adicionar uma curvatura ao SkyPlane, para isso ser adicionado mais trs parmetros ao mtodo setSkyPlane(), sendo que

89

o stimo parmetro define a curvatura do plano e o oitavo e nono define a quantidade de segmentos do cu nos eixo X e Y respectivamente.

6.3.7.5 Fog

A neblina (fog) recurso que ajuda a compor uma ambiente 3D. Podendo ser utilizada para criar uma cena de suspense, esconder objetos e limites do cenrio e tambm ocultar a baixa qualidade da renderizao do ambiente 3D. Segundo Ogre (2011), a neblina no uma entidade que ocupa um espao vazio no cenrio. Em vez disso a neblina basicamente um filtro aplicado em qualquer objeto que o usurio esteja visualizando. O Ogre possui dois tipos de fog: Linear: cria uma neblina em um intervalo de espao em relao cmera. Exponential: cria uma neblina onde sua densidade aumentada conforme cmera se distncia da mesma. A neblina criada atravs do mtodo setFog(), este mtodo recebe cinco parmetros, sendo que o primeiro parmetro define o tipo de fog, o segundo informa a cor da fog, o terceiro especfico para o tipo Exponential, o quarto e quinto parmetro definem os intervalos onde a neblina se torna mais densa.

6.3.7.6 Luzes

As luzes so criadas com o propsito de iluminar o cenrio do jogo. Segundo Riedel (2007), a luz no uma entidade, no possuindo uma representao visual, pois somente possvel sua visualizao quanto ilumina uma entidade. O resultado final a combinao com as propriedades da luz e as propriedades do material do objeto que ir refleti-la. O Ogre possibilita a utilizao de 3 tipos de iluminao sendo elas: Point: cria uma luz que ilumina em todas as direes.

90

Spotlight: cria uma luz que funciona com uma lanterna. Esta luz ser representada como um cone sendo o topo o inicia na luz e a base o final, iluminando todo o ambiente que se encontra dentro do cone. Na base a luz se encontra mais intensa no centro e conforme se afasta do centro sua intensidade diminui.

Directional: cria uma luz distante, que a partir de uma direo, ilumina uma grande rea, se assemelhando a luz do sol ou da lua.

Uma luz criada utilizando o mtodo createLight() da classe SceneManager, recebe uma string com parmetro que seu nome de identificao. Se utiliza tambm o mtodo setType() que define o tipo de luz a ser crida. Duas das propriedades mais importante de uma luz a ser definida sua cor especular e difuso, que define o nvel de reflexo da luz.

6.3.7.7 Sombras

As sombras so elementos importantes que aumentam o realismo em um ambiente 3D e ajudam o jogador a compreender a relao espacial entre os objetos. O lado negativo de se utilizar sombras que elas necessitam de grande parte do processamento grfico do PC, sendo que se o computador no possuir placas ou adaptadores de vdeo ao executar um jogo que se utiliza de tcnicas avanadas de sombreamento podem ocasiona travamentos constantes no PC. O Ogre suporta basicamente 3 tipos de sombras: Modulative Texture Shadows: e mais simples das 3 sombras, as sombras criadas no possui um nvel alto de detalhamento, sendo elas um pouco distorcidas. Modulative Stencil Shadows: esta sombra equilibrada entre qualidade visual e gasto de processamento, as sombras criadas possuem uma tima definio nos detalhes e no prejudicam o processamento do PC. Additive Stencil Shadows: em nvel de detalhes est a melhor entre as 3 citadas, seu lado negativo que necessita de um maior gasto de processamento pois a criao das sombras verificada para cada luz da cena separadamente.

91

Figura 68 Os 3 tipos de sombras do Ogre: Modulative Texture Shadows (esquerda), Modulative Stencil Shadows (centro) e Additive Stencil Shadows (direita)

6.3.8 Grafo de Cena

O Ogre utiliza a classe SceneNode para representar um n, sendo que para cada n se vincula uma entidade ou objeto utilizando o mtodo attachObject() . Para utilizao do grafo de cena h necessidade definir um n raiz, sendo este o primeiro do n da hierarquia do grafo, no caso do Ogre o n raiz gerado automaticamente, para pegar a instncia dele se utiliza o mtodo getRootSceneNode() da classe SceneManager, com a instncia do n raiz se utiliza o mtodo createChildSceneNode() para criar o n filho, sendo que cada n pode utilizar este mtodo para gerar seus ns filhos.

6.4 OPENGL

OpenGl definida como uma geradora de interface para hardwares grficos. Mas, na verdade, OpenGl uma biblioteca de rotinas grficas e de modelagem, 2D e 3D, extremamente portvel e rpida. Seus recursos permitem ao usurio criar objetos grficos de alta qualidade, com vrios recursos avanados de animao, tratamento de imagens e texturas. A biblioteca OpenGl foi introduzida em 1992 pela Silicon Graphics, no intuito de conceber uma API, independente de dispositivos de exibio. Com isso, estabeleceu-se uma ponte entre o processo de modelagem geomtrica de objetos (situados em um nvel de abstrao mais elevado) e as rotinas de exibio e de processamento de imagens implementadas em dispositivos (hardware) e SO especficos, tornando as funes OpenGl portveis para qualquer SO.

92

Diante das funcionalidades providas pelo OpenGl, tal biblioteca tem se tornado um padro amplamente adotado na indstria de desenvolvimento de aplicaes. Desenvolvedores de jogos, e de aplicaes cientficas e comerciais tm utilizado OpenGl como ferramenta de apresentao de recursos visuais, principalmente com a adoo desse padro por parte dos fabricantes de placas de vdeo destinadas aos consumidores domsticos.

93

7 COMPARAES ENTRE AS ARQUITETURAS ESTUDADAS

Neste captulo so abortados as comparaes entre as arquiteturas XNA, GlScene e Ogre3D. Para estudo de comparao foram desenvolvidas pequenas aplicaes e pesquisado as funcionalidades que compem as arquiteturas de desenvolvimento de entretenimento digital. Alguns dos projetos citados nesse captulo, no so nativos das arquiteturas de desenvolvimento, foram desenvolvidos atravs de comunidades ou de empresas parceiras.

7.1 PORTABILIDADE

A Tabela VII apresenta a portabilidade das arquiteturas de desenvolvimento de jogos avaliadas para os diferentes tipos de SOs.
Tabela VII Portabilidade das Arquitetura avaliadas para os diferentes SOs.

SO Windows Linux Mac OS Windows Phone 7 Android IPhone

XNA Sim No Sim Sim Sim Sim

GlScene Sim Sim No No No No

Ogre 3D Sim Sim Sim No Sim Sim

A Tabela VIII apresenta a portabilidade das arquiteturas de desenvolvimento de jogos avaliadas para os diferentes tipos de ambientes.
Tabela VIII Portabilidade das Arquitetura avaliada para os diferentes ambientes.

Dispositivos Celulares Consoles Web Computadores

7.1.1 XNA

XNA Sim Sim Sim Sim

GlScene No No No Sim

Ogre 3D Sim No Sim Sim

94

O XNA possui uma portabilidade nativa em suas aplicaes, sendo portvel para o dispositivo mvel Zune, para o console Xbox 360 e para Windows Phone 7 com a nova verso do framework o XNA 4.0. O aplicativos desenvolvidos no XNA podem ser portveis para a web, IPhone e Android, atravs de projetos desenvolvidos pela comunidade e empresas. No caso a portabilidade para web possvel atravs do API SilverSprite, desenvolvido por Bill Reis e mantido por Jos Antonio Farias e Kevin Wolf, esta API utiliza o projeto do jogo desenvolvido em XNA para ser incorporado em uma aplicao SilverLight, sendo possvel somente portar jogos 2D. O projeto MonoTouch permite criar aplicaes em C# e .Net que sejam executadas nos dispositivos IPhone, IPad e IPod Touch, aproveitando as APIs do IPhone e reutilizao do cdigo e bibliotecas que foram construdas para o .Net, sendo necessrio o sistema operacional MAC e o SDK (Software Development Kit) do IPhone para desenvolvimento das aplicaes (XAMARIM, 2011). Assim como o projeto MonoTouch, tambm existe o projeto MonoDroid desenvolvido pela Xamarim, este projeto permite a criao de aplicaes em C# e .Net para o SO Android. O framework XNA no portvel para o SO Linux.

7.1.2 GlScene

Os jogos desenvolvidos pela arquitetura GlScene se limita a executar somente em computadores. A biblioteca GlScene portvel tanto para os SOs Windows e Linux, no caso no Linux se utiliza a IDE Lazarus para o desenvolvimento dos jogos.

7.1.3 Ogre3D

95

Um dos conceitos empregado no desenvolvimento do Ogre foi portabilidade da biblioteca, sendo ela portvel para os SOs Windows, Linux e MAC OS X. Um ponto que diferencia o Ogre das demais arquiteturas estudadas a portabilidade da linguagem de programao, sendo que o XNA se utiliza somente da linguagem C# e o GlScene da Pascal para desenvolvimento de jogos, o Ogre encontrado em diferentes linguagens de programao sendo elas Python, Java e .Net. Os jogos desenvolvidos com as APIs Python-ogre (Python), Mogre (.Net) ou Ogre4J (Java) que so as extenses do Ogre para outras linguagens, so portveis para a web (OGRE3D, 2011). Aplicaes do Ogre so portveis para o IPhone e dispositivos moveis que utilizam o SO Android, atravs das bibliotecas OgreIPhone e OgreAndroind.

7.2 CODIFICAO

7.2.1 XNA

A estrutura do XNA para o desenvolvimento de jogos eletrnicos bem definida, a classe de execuo principal que a classe que mantm o loop de execuo do jogo, possui os mtodos definidos visando estrutura de execuo de jogos digitais, sendo divididas em: inicializao do jogo, carregamento dos arquivos utilizados, atualizao das condies do jogo, desenho das imagens na tela e finalizao do jogo. O XNA tambm possui diversas classes a serem utilizadas do desenvolvimento de jogos, sendo esta classe para o tratamento de grficos, udio, controles, funes matemticas e conexes de rede. Muitas das classes de gerenciamento de elementos como sombra, terreno, luz ou cmera no existem no XNA, sendo necessrio o desenvolvimento destas classes.
7.2.2 GlScene

96

Ao contrario das outras arquiteturas o GlScene uma biblioteca que se utiliza dos componentes visuais para o desenvolvimento de jogos digitais. A uma grande facilidade para se desenvolver no GlScene por uso dos componentes visuais, tambm h facilidade na manipulao dos componentes atravs do cdigo fonte, sendo que os estes so objetos de classe predefinidos com propriedades e eventos, podendo ser configura atravs de modo visuais ou cdigo fonte. Em questo de codificao comparando o GlScene com as demais arquiteturas avaliadas, levando em considerao a quantidade de linhas de cdigo escrita pelo programador, O GlScene leva significativa vantagem sobre as demais.

7.2.3 Ogre3D

Sendo o Ogre desenvolvido na linguagem C++ e possuindo uma estrutura fortemente OO, o desenvolvedor precisa possuir certo nvel de conhecimento sobre OO e outros conceitos que envolvem a mesma. Assim como o XNA oferece uma estrutura de classe para o desenvolvedor programar, o Ogre possui este mesmo conceito, mas a diferena que a estrutura oferecida pelo Ogre e muito mais complexa e flexvel que a do XNA. O Ogre oferece conjunto de classes, sendo cada uma delas responsvel por funcionalidades especificas para execuo do jogo, estas classes podem ser herdadas e implementadas em outras classes definidas pelo desenvolvedor, conforme-lhe convm necessidade. O Ogre tambm se utiliza de vrios Design Pattern, conceitos e abstraes que facilitam o desenvolvimento do projeto de um jogo digital. Um dos pontos importante no Ogre so as abstraes de elementos necessrios ao jogo, sendo que para cada elemento ele oferece uma classe ou mtodo que a defina e a gerencie. Outro ponto a ser destacado fato que o Ogre no se responsabiliza por todas as funcionalidades necessrias para o desenvolvimento de jogos, j que sua funo somente o gerenciamento do ambiente grfico, assim h necessidade de instalar outras bibliotecas que se responsabilizem por estes recursos, ficando a cargo do desenvolvedor escolher a biblioteca que melhor atenta suas necessidades.

97

7.3 DESEMPENHO

Para estudo de comparao do desempenho das arquiteturas apresentadas, foram desenvolvidos prottipos de movimentao de personagem 3D dentro de um terreno. As aplicaes desenvolvidas para esta avaliao encontram-se apresentadas nos APNDICE B, APNDICE C e ANEXO I (LOBO et al., 2010). As configuraes do computador usado para executar as aplicaes so: Notebook HP pavillion dv6500 com processador Core 2 Duo T7100 1.8 GHz, 2 GB de memria DDR2, placa de vdeo GeForce 8400M GS de 256MB e SO Windows Seven Professional 64 bits. Para medir o desempenho das aplicaes foram avaliados os seguintes pontos: memria consumida, processamento utilizado em porcentagem, qualidade do grfico 3D, FPS (frames por segundo) e velocidade da inicializao da aplicao medida em segundos. A Tabela IX mostra os dados extrados das aplicaes desenvolvidas em cada arquitetura.
Tabela IX Comparao de desempenho entre XNA, GlScene e Ogre

Memria Processamento (%) Qualidade do Grfico 3D

XNA 72 MB 19 Polgonos detalhados, boa qualidade de texturizao 62 20 segundos

GlScene 38 MB 70 Baixo uso dos polgonos, baixa qualidade de texturizao 80 10 segundos

Ogre3D 48 MB 53 Polgonos detalhados, boa qualidade de texturizao 30 45 segundos

FPS Velocidade de inicializao (seg)

98

7.3.1 XNA

O XNA apresenta um maior consumo de memria que as demais arquiteturas, porm seu custo de processamento o menor. A qualidade grfica apresentada pelo XNA bem detalhada em sua textura e seus grficos 3D apresentam polgonos arredondados, isso expressa uma grande quantidade de polgonos sendo usado para renderizao das imagens. Sua taxa de 62 FPS, que a mdia para os jogos de tiro em primeira pessoa.

7.3.2 GlScene

O GlScene apresenta o menor consumo de memria entre as arquiteturas, porm seu custo de processamento o maior, chegando a gasta 80% do processador. A qualidade grfica mais baixa das arquiteturas avaliadas sendo que sua texturizao no apresenta boa qualidade e os grficos 3D apresentam uma forma quadrangulada, mostrando o baixo uso de polgonos. Sua taxa de 80 FPS, sendo boa para jogos que apresenta vrios objetos dinmicos em tela. Sua velocidade de inicializao mais rpida, sendo executado em 10 segundos.

7.3.3 Ogre3D

O Ogre apresenta um consumo de memria de 48 MB por uso da aplicao, tambm o consumo do processado de 53%, sendo esta arquitetura de consumo mdio entre as avaliadas. A qualidade grfica da aplicao desenvolvida na Ogre se assemelha a no XNA, mas seu diferencial que na Ogre est qualidade pode ser mais bem tratada ou reduzida conforme o recurso do dispositivo que est executando a aplicao. Sua taxa de 30 FPS, sendo a mdia para jogos que no necessitam de muita movimentao. Sua velocidade de inicializao maior das arquiteturas avaliadas, por causa do uso de diferentes bibliotecas que o compem.

99

7.4 GRFICO 2D E 3D

7.4.1 XNA

O XNA possui um simples mecanismo de manipulao dos objetos 2D, oferecendo varias classes que auxiliam no desenvolvimento dos jogos 2D, tambm sua Content Pipeline facilita o armazenamento e busca dos objetos, o que o torna uma grande vantagem para o desenvolvedor Em relao aos grficos 3D o XNA tambm oferece classes que ajudam o desenvolvedor no tratamento e manipulao dos objetos, porm a arquitetura no oferece classe de gerenciamento dos recursos necessrios para o jogo, ficando a cargo do desenvolvedor criar sua prpria API de gerenciamento destes recursos. O XNA somente importa modelos 3D nas extenses .X e .FBX, sendo necessrio converter outros extenses para as suportadas pelo XNA.

7.4.2 GlScene

O GlScene oferece alguns recursos para trabalhar com grficos 2D, apesar de no oferecer tantos recurso para tratamento da imagem como XNA. Pode-se utilizar o grfico 2D como uma imagem esttica ou criar uma animao utilizando mtodo de sprite sheet, o ponto positivo no GlScene sobre imagens 2D que o desenvolvedor pode utiliz-las para animaes de efeitos ou criar um jogo 2D com efeitos de profundidade. Em relao aos grficos 3D, o GlScene foi desenvolvido para atender todos os recursos necessrios para tratamento e gerenciamento das objetos apresentados em cena. O GlScene importa diferentes extenses de modelos 3D, sendo a arquitetura que mais se diversifica na importao dos modelos, as extenses importadas pelo GlScene foram citadas no captulo 6.

100

7.4.3 Ogre3D

O Ogre no melhor arquitetura para se desenvolver jogos 2D, pois muito dos recursos que ele oferece no so aproveitados para essa estrutura de jogos, j que o Ogre foi desenvolvido para trabalhar com grficos 3D. Apesar de no ser uma arquitetura desenvolvida para jogos 2D ele oferece recursos para trabalhar com este tipo de grfico, sendo que h necessidades de criar interface para usurio se interagem ou utiliza este grficos 2D como parte do cenrio. Uma das bibliotecas para se trabalhar com grficos 2D no Ogre a CEGUI, citada anteriormente no captulo 6. Em relao aos grficos 3D, o Ogre apresenta praticamente os mesmos recursos que o GlScene, sendo uma diferena entre as duas arquiteturas a qualidade grfica apresentada pela aplicao desenvolvida no Ogre e a disponibilizao de recursos a mais para tratamento dos objetos 3D, sendo que nestes pontos o GlScene no possui tanto avano. O Ogre somente importa modelos 3D na extenso .mesh, sendo necessrio converter outras extenses para a suportada pelo Ogre.

7.5 UDIO

A Tabela X apresenta as extenses de udio suportadas pelas arquiteturas de desenvolvimento de jogos avaliadas.
Tabela X Extenses de udio suportadas pelas arquiteturas de desenvolvimento de jogos

Extenses de udio .WAV .MP3 .WMA .OGG MP2 RAW .MIDI .MOD

XNA Sim Sim Sim No No No No No

GlScene Sim Sim No Sim Sim Sim Sim Sim

Ogre3D Sim Sim No Sim No No No Sim

101

7.5.1 XNA

O XNA oferece dois mtodos para se trabalhar com o udio, o XACT ou as classes de som da prpria arquitetura, citados anteriormente no captulo 6. O ponto positivo por se trabalhar com o XACT que no h necessidade de ferramentas adicionais para tratar os arquivos de udio, tambm todos os arquivos necessrio para reproduo das trilhas de udio do jogo so armazenados em um nico componentes. O XNA tambm oferece as classes da arquitetura para gerenciar o udio sendo elas divididas em classes de efeitos sonoros e msicas, sendo assim, ela oferece um melhor gerenciamento do udio conforme a necessidade do desenvolvedor. O XNA possui recursos para reproduo de efeitos sonoros e msicas, com udio 3D. Entre as arquiteturas avaliadas o XNA o que oferece mais recursos para se trabalhar com o udio, porm ele o que menos aceita formatos diferentes de udio, sendo somente as extenses MP3 e WAV.

7.5.2 GlScene

A utilizao de udio no GlScene se torna uma tarefa fcil por causa da estrutura visual da arquitetura, sendo que em cada objeto presente em cena pode se atribuir efeitos sonoros a serem utilizados em uma ao. O ponto positivo do GlScene em relao ao udio que o desenvolvedor pode escolher entre trs APIs de udio a serem utilizada, sendo elas: FMOD, Bass e a OpenAL. O GlScene tambm aceita diferentes tipos de extenso de udio, sendo a arquitetura entre as avaliadas que mais se diversifica nas extenses reproduzidas.

102

7.5.3 Ogre3D

A utilizao de udio no Ogre uma tarefa difcil, no pelo fato de como se usar as classes de udio, mas pela instalao da biblioteca, sendo que o Ogre nativamente no possui suporte a udio. O Ogre se utiliza de APIs de udio externas para oferecer suporte aos arquivos de sons a serem utilizado durante o jogo. A principal API utiliza no Ogre a OpenAL, citada anteriormente no captulo 6. Para integrao da arquitetura Ogre com a API de udio, se utiliza bibliotecas de udio, sendo elas: OgreAL ou OgreOggSound, cada biblioteca possui caracterstica prprias, podendo oferecer recursos e gerenciamento diferenciados uma da outra. Tambm possvel a utilizao de outras APIs de udio, ficando a cargo de o desenvolvedor escolher qual melhor API que atenta suas necessidades no projeto de um jogo digital. Assim como GlScene que possvel vincular o efeito sonoro ao objeto em cena, o Ogre possui este mesmo recurso.

7.6 CMERA

7.6.1 XNA

O XNA no possui nativamente uma classe de gerenciamento de cmera, podendo ficar a cargo de o desenvolvedor implementar este recurso ou escolher uma biblioteca desenvolvida pela comunidade XNA ou por grupos independentes que implementam este mesmo recurso.

103

7.6.2 GlScene

O GlScene possui um objeto chamado GLCamera do componente TGLScene, sendo este responsvel pelo gerenciamento da cmera dentro de uma cena, atravs deste objeto configurado a movimentao, rotao, translao e escala de uma cmera. Tambm possvel a existncia de mais de um GLCamera dentro de uma cena, possibilitando a utilizao de mltiplas cmeras. A cmera pode ser configurada atravs dos componentes visuais para seguir um objeto alvo, sendo assim, ela se movimentar em relao ao objeto determinado pelo desenvolvedor, no havendo necessidade de escrever diversas linhas de cdigo para est funo.

7.6.3 Ogre3D

O Ogre possui uma classe para gerenciamento da cmera chamada Camera, sendo esta criada atravs da classe SceneManager utilizando o mtodo createCamera(). A classe Camera responsvel por qualquer configurao que envolva a visualizao de uma cena, sendo assim, nela que se configura a movimentao, rotao, translao e escala da cmera, tambm esta classe onde se configura a distncia mnima ou mxima que um objeto deve se encontra da cmera para ser visualizado. O Ogre tambm possui outras classes que oferecem suporte a cmera, sendo em relao ao grafo de cena para vincular a cmera a um objeto ou em relao a outros tipos de cmeras necessrias para os jogos.

104

7.7 TERRENO

7.7.1 XNA

O XNA no possui nativamente uma classe de gerenciamento de terreno, podendo ficar a cargo de o desenvolvedor implementar este recurso ou escolher uma biblioteca desenvolvida pela comunidade XNA ou grupos independentes que implementam este mesmo recurso.

7.7.2 GlScene

GlScene

trabalha

com

terreno

atravs

de

um

objeto

chamado

TGLTerrainRenderer do componente TGLScene, ele utiliza a mtodo de mapa de altura, citado no captulo 5, para criao dos terrenos, tambm e necessrio o componente TGLBitmapHDS, sendo este que armazena a imagem 2D usada no mtodo de mapa de altura. O GlScene oferece a utilizao de mltiplas textura sobre o terreno, atribuindo um efeito mais realista sobre o cenrio. Pela utilizao dos componentes visuais, a tarefa de criao e configurao do terreno se torna uma atividade relativamente fcil para o desenvolvedor.

7.7.3 Ogre3D

Assim como GlScene, o Ogre tambm possui uma classe para criao de terreno sendo ela chamada TerrainSceneManager, esta classe e criada atravs do mtodo setWorlGeometry(), citada anteriormente no captulo 6. Um dos pontos positivos em relao criao de terreno na arquitetura Ogre as configuraes para gerao do terreno, sendo esta mantida dentro de um arquivo script fora

105

do cdigo fonte do jogo, facilitando alteraes das configuraes do terreno sem a necessidade de alterar o cdigo fonte.

106

8 CONSIDERAES FINAIS

O desenvolvimento de um jogo digital requer uma srie de conhecimentos em diversas reas, habilidades e ferramentas que auxiliam nas atividades de desenvolvimento de jogos digitais. Dificilmente uma nica pessoa possui conhecimento ou habilidade para desenvolver um jogo sozinho, sendo que a maior parte dos jogos de sucesso desenvolvida por mdias ou grandes equipes, onde cada desenvolvedor possui habilidades especificas em determinadas reas. Nesse trabalho foram avaliadas trs arquiteturas para o desenvolvimento de jogos digitais sendo elas: XNA, GlScene, Ogre3D e apresentado as vantagens e desvantagens das arquitetura, sendo utilizado os seguintes aspectos para avaliao: portabilidade, codificao, desempenho, utilizao dos grficos 2D e 3D, udio, cmera e terreno. Em determinados aspectos o XNA apresenta vantagens significativas para o desenvolvimento de jogos digitais, assim como em outros aspectos possui desvantagens em relao s demais arquiteturas avaliadas. Os aspectos vantajosos apresentados pelo XNA se encontram em sua portabilidade, desempenho, grficos 2D e udio. A portabilidade do XNA um dos pontos mais importantes dessa arquitetura, sendo que, suas aplicaes portveis para grande parte dos SOs e em muitos dos dispositivos que aceitam jogos, como apresentado nas tabelas VII e VIII do captulo anterior. O Ogre apresenta semelhante portabilidade no sendo apenas portvel para os consoles. Em relao ao desempenho o XNA apresenta a quantidade mdia de FPS, com boas qualidades grficas e consumo computacional moderado, ao contrario das outras arquiteturas que apresentam uma maior taxa de FPS com baixas qualidades grficas, no caso do GlScene ou uma baixa taxa de FPS com consumo computacional moderado, no caso do Ogre. O XNA trabalha relativamente bem com os grficos 2D, oferecendo recursos simples para armazenar, buscar, desenhar e remover os elementos grficos. Ele tambm utiliza baixo recursos computacionais para execuo dos jogos, ao contrario das arquiteturas Ogre e GlScene pois so desenvolvidas para trabalhar com grficos 3D. No aspecto referente ao udio o XNA, a arquitetura que menos aceita diferentes formatos de udio, como apresentado na tabela X do captulo anterior. Porm, a arquitetura

107

que mais oferece diferentes tipos de classes para o tratamento, gerenciamento, e reproduo dos arquivos sonoros. Os aspectos que o XNA no apresenta significativa vantagens em relao s demais arquiteturas avaliadas so: codificao, grficos 3D, cmera e terreno. Apesar da estrutura de desenvolvimento do XNA ser relativamente bem definida, ele no possui nenhuma classe de gerenciamento dos componentes necessrio para o desenvolvimento de jogos digitais, exemplificando o XNA no possui classes que criam e gerenciam os elementos dos jogos como: iluminao, cmera, coliso, terreno ou grafo de cena, ficando a cargo do desenvolvedor a implementao dessas classes ou a escolha de uma biblioteca desenvolvida por terceiros. Os aspectos vantajosos do GlScene so em relao codificao e a cmera. Na codificao o GlScene se destaca devido aos seus componentes visuais, os quais facilitam o desenvolvimento de jogos, sendo que este componentes so facilmente manipulados atravs de linhas de cdigo fonte, pois eles so objetos de classes predefinidos com propriedades e eventos. Em relao cmera, o GlScene facilita a manipulao deste componente devido ao seu ambiente visual. Ele tambm oferece diversas propriedades sendo elas: escala, rotao, translao e a possibilidade da cmera seguir um objeto determinado pelo desenvolvedor, deste jeito a cmera se movimenta em relao ao objeto. As configuraes da cmera podem ser realizadas atravs do modo visual ou por cdigo fonte. Os aspectos vantajosos do Ogre so em relao ao grfico 3D e o terreno. O Ogre uma arquitetura desenvolvida para trabalhar com grficos 3D. Ele apresenta praticamente os mesmos recursos que a arquitetura GlScene. Suas vantagens so em relao alta qualidade grfica apresentada por ela e por oferecer diversos recursos para tratamento de objetos 3D, sendo em relao movimentao, transformao, fsica ou qualidade grfica. Em relao ao terreno, o Ogre oferece mecanismos que facilitam sua criao e modificao, sendo que para gerar o terreno a arquitetura se utiliza de um arquivo de script contendo todas as informaes necessrias sobre a estrutura do terreno, sendo assim, qualquer modificao necessria a estrutura do terreno no necessita de alteraes no cdigo fonte, sendo necessrio somente alterar as configuraes dentro do arquivo de script. No existe uma arquitetura de desenvolvimento de jogos digitais que seja a melhor entre todas as arquiteturas, mas sim, aquela que melhor atenda as necessidades do projeto de

108

desenvolvimento certo tipo de jogo. Deste ponto, fica a cargo do game design avaliar qual a melhor arquitetura para o projeto em desenvolvimento e verificar quais os pontos fortes e fracos desta arquitetura.

8.1 TRABALHOS FUTUROS

Nesse trabalho o objetivo foi compreender o desenvolvimento de jogos digitais e os elementos que o compe, assim tambm como o funcionamento das arquiteturas de desenvolvimento de jogos digitais, no ocorrendo efetivamente o desenvolvimento de um jogo por completo. Uma das possibilidades para trabalhos futuros o desenvolvimento de jogos educacionais utilizando umas das arquiteturas avaliadas anteriormente, que auxiliem o professores no ensino educacional de determinadas matrias, sendo aquelas matrias onde os alunos possuem o maior grau de dificuldade de assimilao da informao. Outra possibilidade no desenvolvimento de jogos nas reas de reabilitao e fisioterapia, pois com o novo dispositivo de reconhecimento corporal, o Kinect, desenvolvido pela Microsoft para o Xbox 360, o jogador ter uma maior interao com o jogo, pois necessita dos movimentos do corpo para se interagir com o jogo, fazendo com que o corpo do jogador se transforme em um verdadeiro joystick.

109

REFERNCIAS

ABRAGAMES. A indstria brasileira de jogos eletrnicos: Um mapeamento do crescimento do setor nos ltimos 4 anos. Disponvel em: <http://www.abragames.org/docs/AbragamesPesquisa2008.pdf>. Acesso em: 9 mar 2010. ABREU, Andre de. VIDEOGAME: UM BEM OU UM MAL? Um breve panorama da influncia dos jogos eletrnicos na cultura individual e coletiva. 2003. Disponvel em: <http://andredeabreu.com.br/docs/videogames_bem_ou_mal.pdf>. Acesso em: 18 maio 2010. ALBUQUERQUE, Marco Tlio C. F. REVOLUTION ENGINE: Arquitetura de um Motor 3D para Jogos. 2005. p. 68. Monografia (Cincia da Computao) - Centro de Informtica Universidade Federal de Pernambuco, Recife, Pernambuco. AZEVEDO, Eduardo. Teoria da Computao Grfica. So Paulo: Editora Campus Ltda., 2003. 362 p. CARNEIRO, Mairlo Hideyoshi Guibo. Desenvolvimento de jogos de Computador. 2004. p. 117. Monografia (Cincia da Computao) Departamento de Matemtica e Computao Universidade Federal de Itajub, Itajub, Minas Gerais. Disponvel em: <http://www.programadoresdejogos.com/trab_academicos/marlo_luiz.pdf>. Acesso em: 21 abril 2010. CASACURTA, Alexandre; OSRIO, Fernando; FIGUEROA, Franz; MUSSE, Soraia Raupp. Computao Grfica: Introduo. 1998. (Informtica) Centro de Cincias Exatas e Tecnolgicas Universidade do Vales do Rio dos Sinos, Rio Grande do Sul. 1998. CEGUI. Tutorials CEGUI WIKI. Disponvel em:

<http://www.cegui.org.uk/wiki/index.php/Main_Page>. Acesso em: 13 Junho 2011. CLUA, Esteban Walter Gonzalez; BITTENCOURT, Joo Ricardo. Desenvolvimento de Jogos 3D: Concepo, Design e Programao. Anais da XXIV Jornada de Atualizao em Informtica do Congresso da Sociedade Brasileira de Computao, pp. 1313-1356. So Leopoldo, 2005. FARIAS, Thiago Souto Maior Cordeiro de; PESSOA, Saulo Andrade; TEICHRIEB, Veronica; KELNER, Judith. O Engine Grfica Ogre3D. In: V BRAZILIAN SYMPOSIUM ON COMPUTER GAMES AND DIGITAL ENTERTAINAMENT, 5., 2006, Recife. COMPUTING AND ART&DESIGN TUTORIALS. Recife: UFPE, Escola Politcnica de Pernabunco, 2006. FESTA, Marco Antonio. Andador # 1. Disponvel em: <http://marcoantoniofesta.wordpress.com/2010/02/26/andador-1/>. Acesso em: 24 nov 2010

110

GOMES, Hewerson; SILVA, Marcos Alberto Lopes da. XNA Framework para desenvolvimento de jogos. Sistemas de Informao Centro Universitrio do Tringulo. Uberlndia, Minas Gerais. GUIMARES, Marcelo de Paiva; GNECCO, Bruno Barbieri; DAMAZIO, Rodrigo. Realidade Virtual e Aumentada: Conceitos, Projeto e Aplicaes. Kirner & Siscoutto. cp. 6, pg 108 -128. 2007. Petrpolis RJ IGNCIO, Ubirat Azevedo. Uma proposta de Amostragem Adaptativa para Computao Grfica Baseada em Pontos. 2003. p. 49. Monografia (Bacharel em Cincia da Computao) - Universidade Do Vale Do Rio Dos Sinos, So Leopoldo, Rio Grande do Sul. JUNIOR, Ademar de Souza Reis; NASSU, Bogdan T.; JONACK, Marco Antonio. Um Estudo Sobre os Processos de Desenvolvimento de Jogos Eletrnicos (Games). 2002. Disponvel em: <www.ademar.org/texts/processo-desenv-games.pdf>. Acesso em: 21 abril 2010. JUNKER, Gregory. Pro OGRE3D Programming. Estados Unidos: Apress, 2006. 288 p. LIMA, Luciano. Microsoft XNA. 2009. Disponvel em: <http://www.lucianolima.com.br/xna/Introducao_ao_XNA_Parte_1.pdf>. Acesso em: 7 mar 2010. LISCHKE, Mike; GRANGE, Eric. GLScene: OpenGL Library for Delphi. Disponvel em: <http://www.glscene.org>. Acesso em: 24 maio 2011. LOBO, Alexandre Santos; EVANGELISTA, Bruno Pereira; FARIAS, Jos Antonio Leal; OLIVEIRA, Patryck Pabllo Borges. XNA 3.0 para desenvolvimento de jogos no Windows, Zune e Xbox 360. Rio de Janeiro: Brasport, 2010. 431 p. LOPES, Luiz Fernando Braga. ARQUITETURA PARA O DESENVOLVIMENTO DE AMBIENTES VIRTUAIS ADAPTATIVOS APLICADA AO ENSINO DE FSICA. 2010. p. 100. Tese (Doutorado em Engenharia Eltrica) - Universidade Federal de Uberlndia, Uberlndia, Minas Gerais. MANSSOUR, Isabel Harb; COHEN, Marcelo. Introduo Computao Grfica. Tutorial aceito para apresentao no SIBGRAPI 2006 e publicao na Revista de Informtica Terica e Aplicada, Porto Alegre, v. 13, n. 2, p. 43-67, 2006. MORAIS, Felipe Castanheira. Desenvolvimento de jogos Eletrnicos. Disponvel em: <http://revistas.unibh.br/dcet/include/getdoc.php?id=102&article=39&mode=pdf>. Acesso em: 21 abril 2010. NUNES, Maira Rita Begalli. Social Impact Games: uma nova possibilidade de comunicao. 2007. Disponvel em: <http://www.bocc.ubi.pt/pag/nunes-maira-social-impact-games.pdf>. Acesso em: 14 maio 2010.

111

NUNES, Lus. Motores para Desenvolvimento de Jogos Digitais. Relatrio da Disciplina de Projeto (Engenharia da Informtica) Instituto Politcnico de Bragana, Bragana, So Paulo. 2009. OGRE3D. Ogre wiki Support and community documents for Ogre3D. Disponvel em: <http://www.ogre3d.org/tikiwiki/>. Acesso em: 13 Junho 2011. OLIVEIRA, Srgio. GameDev #6: Conhecendo o XNA Mergulhando nas suas Camadas. Disponvel em: <http://www.nintendoblast.com.br/2009/12/gamedev-6-conhecendo-o-xnamergulhando.html>. Acesso em: 8 maio 2011. POZZER, Cesar Tadeu. Grafo de Cena. Disponvel em: <http://wwwusr.inf.ufsm.br/~pozzer/disciplinas/cga_2_grafo_cena.pdf>. Acesso em: 08 maio 2010. PINHO, M. S., BOWMAN, D. A., and FREITAS, C. M. Cooperative object manipulation in immersive virtual environments: framework and techniques. In: Proceedings of the ACM Symposium on Virtual Reality Software and Technology (Hong Kong, China, November 11 13, 2002). VRST '02. ACM, New York, NY, 171-178. REED, Aaron. Learning XNA 3.0. Sebastopol: OReilly, 2008. 508 p. RIEDEL, Rafael. Desenvolvimento de jogos: Uma abortagem prtica ao Ogre3D e seus subsistemas. 2007. p. 127. Monografia (Cincia da Computao) - Universidade FUMEC, Belo Horizonte, Minas Gerais. RIEDER, Rafael; BRANCHER, Jacques Dulio. Development of a micro world for the education of the Fundamental Mathematics, using OpenGL and Delphi. In: X Congreso Iberoamericano de Educacin Superior en Computacin - CIESC, 2002, Montevideu, 2002. SETZER, Valdemar W. Os Meios eletrnicos e a Educao: televises, jogos eletrnicos e computadores. In: ______. Meios eletrnicos e educao: uma viso alternativa. So Paulo: Escrituras e Distribuidoras de Livros Ldta, 2001. cap. 1, p. 15-19. SILVA, Vincius Cordeiro. RECURSOS OFERECIDOS POR ENGINES PARA DESENVOLVIMENTO DE JOGOS 3D. 2009. p. 120. Monografia (Cincia da Computao) Instituto de Cincias Exatas e Geocincias - Universidade de Passo Fundo, Passo Fundo, Rio Grande do Sul. SUGUISAKI, Gilmar. Modelagem de Elementos Dinmicos para Jogos 3D. 2007. p. 80. Monografia (Cincia da Computao) - Universidade Estadual de Londrina, Londrina, Paran. TEIXEIRA, Joo Marcelo Xavier Natrio; TEICHRIEB, Vernica; KELNER, Judith. Hardwire: uma soluo de renderizao para realidade aumentada embarcada. Disponvel

112

em:<https://150.161.192.17/svn/repositorioGPRT/2006/Public/WRA/JoaoMarceloTeixeira_h ardwire.pdf>. Acesso em: 14 maio 2010. UNIDEV. Desenvolvimento de jogos com Java + Java3D. Disponvel em: <http://udco.unidev.com.br/>. Acesso em: 14 mar 2010. VIANNA, Arlindo Cardarett. Computao Grfica. Disponvel em: <http://www.inf.ufes.br/~thomas/graphics/www/apostilas/CIV2801AcvCompGraf.pdf>. Acesso em: 14 maio 2010. Visualizao Realstica em 3D, z-Buffering e Raytracing. Disponvel em: <http://www.inf.ufsc.br/~awangenh/CG/raytracing/index.html>. Acesso em: 14 maio 2010. XAMARIN. Projeto MonoTouch. Disponvel em: <http://ios.xamarin.com>. Acesso em: 30 set 2011.

113

APNDICES

114

APNDICE A PROJETO XNA PARA IMPORO DE IMAGEM 2D

using using using using using using using using using using using using System; System.Collections.Generic; System.Linq; Microsoft.Xna.Framework; Microsoft.Xna.Framework.Audio; Microsoft.Xna.Framework.Content; Microsoft.Xna.Framework.GamerServices; Microsoft.Xna.Framework.Graphics; Microsoft.Xna.Framework.Input; Microsoft.Xna.Framework.Media; Microsoft.Xna.Framework.Net; Microsoft.Xna.Framework.Storage;

namespace WindowsGame1 { public class Game1 : Microsoft.Xna.Framework.Game { GraphicsDeviceManager graphics; SpriteBatch spriteBatch; Texture2D textura; Vector2 posicao; public Game1() { graphics = new GraphicsDeviceManager(this); Content.RootDirectory = "Content"; } protected override void Initialize() { base.Initialize(); } protected override void LoadContent() { textura = Content.Load<Texture2D>("ball"); posicao = new Vector2(0f, 0f); spriteBatch = new SpriteBatch(GraphicsDevice); } protected override void UnloadContent() { textura.Dispose(); spriteBatch.Dispose(); } protected override void Update(GameTime gameTime) { base.Update(gameTime); } protected override void Draw(GameTime gameTime) { GraphicsDevice.Clear(Color.CornflowerBlue); spriteBatch.Begin(); spriteBatch.Draw(textura, posicao, Color.White); spriteBatch.End(); base.Draw(gameTime); } } }

115

APNDICE B JOGO DE MOVIMENTAO DE PERSONAGEM 3D DENTRO DE UM CENARIO DESENVOLVIDO COM GLSCENE

Este apndice se encontra em uma mdia digital (CD-ROM).

116

APNDICE C JOGO DE MOVIMENTAO DE PERSONAGEM 3D DENTRO DE UM CENARIO DESENVOLVIDO COM OGRE3D

Este apndice se encontra em uma mdia digital (CD-ROM).

117

ANEXOS

118

ANEXO I JOGO DE MOVIMENTAO DE PERSONAGEM 3D DENTRO DE UM CENARIO DESENVOLVIDO COM XNA

Este anexo se encontra em uma mdia digital (CD-ROM).

119

REGISTRO DE DEFESA
Monografia de TCC apresentada nesta data Banca Examinadora abaixo indicada:

____________________________ Professor Orientador ___________________________ Convidado

________________________ Assinatura _______________________ Assinatura

__________________________ Convidado

________________________ Assinatura