ÐÏࡱá > þÿ I 7$ 9$ þÿÿÿ î# ï# ð# ñ# ò# ó# ô# õ# ö# ÷# ø# ù# ú# û# ü# ý# þ# ÿ# $ $ $ $ $ $ $ $ $ $
$ $ $
$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ !$ "$ #$ $$ %$ &$ '$ ($ )$ *$ +$ ,$ -$ .$ /$ 0$ 1$ 2$ 3$ 4$ 5$ 6$ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿì¥Á 5@ ø¿ È bjbjÏ2Ï2 Ëà X X “¿ y ÿÿ ÿÿ ÿÿ ˆ J J J J z z z 4 ®
R… R… R… è :‡ T Ž‰ ô ®
h ú Ž‹ Ž‹ Ž Œ Œ Œ T V L ¢ ( ç é é é é é é $ b R ´ ‚
z 8’ ÔŽ | P 8’ 8’
J J Œ Œ ¸ " ˜ê ˜ê ˜ê 8’ $7 J † Œ R Œ ç ˜ê 8’ ç ˜ê ˜ê ®ê â …þ ¤ Ð 6 X " Áÿ Œ ‚‹ ÐeñjÉ R… \É ˜ )ÿ ³ 4 8 0 h ?ÿ ‚ 6
ôã ( 6
, Áÿ ®
®
J J J J Áÿ J 6
z ¨ Ê 0 ú " ˜ê ‘ 8‘ Ê Ê Ê
®
®
¤w R… ê | ®
®
R… CENTRO UNIVERSITÁRIO FEEVALE
DANIEL COLNAGHI
XNA GAME PROGRAMMING
Novo Hamburgo, 19 de Novembro de 2008.
DANIEL COLNAGHI
XNA GAME PROGRAMMING
Centro Universitário Feevale
Instituto de Ciências Exatas e Tecnológicas
Curso de Ciência da Computação
Trabalho de Conclusão de Curso
Professor Orientador: Ricardo Ferreira de Oliveira
Novo Hamburgo, 19 de Novembro de 2008.
DEDICATÓRIA
Dedico este estudo: aos meus pais, Sandra e Roberto; ao meu irmão,
Roberto Junior; à minha namorada, Daiane.
AGRADECIMENTOS
Agradeço a meu irmão por me ensinar a nunca desistir e por toda a força que me deu no decorrer dos anos, a minha mãe e meu pai pela paciência, apoio e por acreditarem em mim em todas as horas difíceis, a minha namorada por me ajudar sempre que possível e ao meu orientador Ricardo por me mostrar o caminho quando eu não sabia mais por onde seguir.
RESUMO
O desenvolvimento de jogos tem evoluído com o tempo, provocando uma revolução na tecnologia de seu desenvolvimento. Não existem limitações para o ser humano de criar jogos cada vez mais avançados e com recursos que podem chegar bem próximos à realidade. Há dez anos atrás os jogos produzidos eram tão avançados para a época que muitos ficavam se perguntando o que mais poderia vir logo após. Esses jogos possuíam gráficos 3D, inteligência artificial e simulação de física que chegavam a ser chamado de realidade virtual.
Hoje em dia os jogos produzidos já são planejados para os computadores futuros, e questiona-se que máquina será preciso para rodar os jogos, ou até quando será lançada a máquina que rodará o jogo com seus recursos máximos.
O futuro da programação de jogos continuará a ser complexa. Porém a grande mudança é que não haverá mais equipes enormes de desenvolvedores e sim equipes de conteúdo como designers, modeladores 3D, criadores de níveis, criadores de sons entre outros. A razão disso é que a programação de jogos está cada vez mais focada na manipulação do conteúdo.
A proposta do projeto é desenvolver um jogo do gênero arkanoid utilizando o XNA e a metodologia game design document.
Palavras-chave: Programação de jogos, XNA, DirectX, Opengl, game design document.
ABSTRACT
The game development has grow up along the time, making a revolution in this technology. There is no limitation to someone to create games more advanced with resources that can come so close to reality. Ten years ago the games developed were so advanced for that time that many people had been asking themselves what more can come after this. This games had 3D graphics, artificial inteligence and phisic’s simulation who hab been calling by virtul reality.
Nowadays games developed already has been planned to future computers, but even this is questioned what machine it will be need to run games, or till when will be release the machine who run the game with your maximum resources.
The future of game programming will continue to be complex. The great moving is there is no more a huge team of developers, but group with content, as designers, 3D patternmaker, level creators, sounds creators, among others. The reason of this is a game programming each time more concentrate at content's manipulated.
The plan of this project is develop a game like Arkanoid’s type using XNA and game design document metodology.
Keywords: Game programming, XNA, DirectX, OpenGL, Game desing document.
LISTA DE FIGURAS
Figura 1: Core Wars para o console Unix 15
Figura 2: Pong versão do console Atari 16
Figura 3: Tela do jogo Wolfenstein 17
Figura 4: Tela do jogo DOOM 18
Figura 5: XBOX 360 19
Figura 6: Sonic The Hedgehog 23
Figura 7: Tela do jogo Dig Dug 24
Figura 8: Tela do jogo Arkanoid 25
Figura 9: Tela do jogo 1943 26
Figura 10: Tela do jogo Tetris 27
Figura 11: Tela do jogo Super Mario 3 28
Figura 12: Inteligência Artificial do jogo Asteroids 30
Figura 13: Diagrama de Inteligência artificial 31
Figura 14: Diferenças entre os Gráficos 32
Figura 15: Gráfico em três dimensões 33
Figura 16: Colisão em células ou tiles. 34
Figura 17: Colisão usando um vetor 3D 35
Figura 18: Tela do jogo Warcraft 3 usando câmera fixa. 35
Figura 19: Comunicação entre modem 36
Figura 20: Comunicação cliente servidor. 37
Figura 21: Comunicação ponto a ponto. 38
Figura 22: Rascunho de um jogo segundo Perucia(2005). 40
Figura 23: Aparência OpenGL 48
Figura 24: Reunião de linha próxima a Henry Ford 52
Figura 25: Processamento de Dados OpenGL 55
Figura 26: Alta-performance suportada pelo DirectX 62
Figura 27: Biblioteca DirectX 63
Figura 28: Tecnologia de chips digitais 65
Figura 29: Atualizando com COM 66
Figura 30: Composição de um objeto COM 67
Figura 31: DirectX e seus componentes 69
Figura 32: Interface COM 73
Figura 33: I Unknown para criar interface 74
Figura 34: Modelo da aplicação do XNA 78
Figura 35: Classe do jogo criada pelo XNA. 79
Figura 36: Formatos do Content Pipeline 81
Figura 37: Fluxo de conteúdo 82
Figura 38: Versão do XACT 83
Figura 39: Tela do XACT com a estrutura de um novo projeto. 84
Figura 40: Jogo proposto no estilo Arkanoid 85
Figura 41: Diagrama de estados. 89
Figura 42: Fluxo do jogo 90
Figura 43: Diagram de classes 91
Figura 44: Diagrama de seqüência 92
LISTA DE TABELAS
Tabela 1: Síntaxe Comando OpenGL 50
Tabela 2: Tabela de imagens 87
LISTA DE ABREVIATURAS E SIGLAS
IDE: Integrated Development Enviroment
MUD: Multi User Dungeon
RPG: Role Play Game
XNA: Xna´s Not Acronimed
PC: Personal Computer
IBM: International Business Machines
SUMÁRIO
INTRODUÇÃO 13
1 A HISTÓRIA DOS JOGOS 15
1.1 Atari E A História Do Vídeo Game 19
1.2 Gêneros 21
2 ASPECTOS ENVOLVIDOS NA PRODUÇÃO DE JOGO 23
2.1 Estilos De Jogos 23
2.2 Software De Imagem 2d 29
2.3 Software De Modelagem 3d 29
2.4 I.A. 29
2.5 Algoritmos Determinísticos 29
2.6 Inference Engine 30
2.7 Matemática E Física 31
2.8 Gráfico 2d 32
2.9 Gráfico 3d 32
2.10 Teoria Da Colisão 2d E 3d 33
2.11 Multiplayer E Online 36
3 PROJETO DO JOGO 39
3.1 Brainstorm 39
3.2 Rascunhos Do Jogo 40
3.3 Detalhes Do Jogo 41
3.4 Game Design Document 42
4 TECNOLOGIAS DISPONÍVEIS NO MERCADO 44
4.1 Opengl 44
4.1.1 O Que É Opengl? 45
4.1.2 Fundamentos Opengl 46
4.1.3 Modelo Execução 46
4.1.4 Um Pouco Do Código Opengl 47
4.1.5 Sintaxe Do Comando Opengl 49
4.1.6 Opengl Como Uma Máquina Estatal 51
4.1.7 Opengl Rendering Pipeline 51
4.1.7.1 Display Lists 52
4.1.7.2 Evaluators 52
4.1.7.3 Operações Per-Vertex 53
4.1.7.4 Construção Primária 53
4.1.7.5 Operações De Pixel 53
4.1.7.6 Construção De Textura 54
4.1.7.7 Rasterização 54
4.1.8 Operações Básicas Opengl 54
4.2 Cg 55
4.2.1 O Que É Cg? 56
4.2.2 Modelo De Fluxo De Dados Cg 57
4.2.3 Especialização Gpu E Generalização Cpu 58
4.2.4 A Execução Da Análise Racional Para Cg 59
4.2.5 Coexistências Com Linguagens Convencionais 59
4.2.6 Outros Aspectos Do Cg 59
4.2.7 A Execução Limite Em Torno Dos Programas Cg 60
4.3 Directx 61
4.3.1 A Arquitetura Do Directx E O Temido Com 62
4.3.2 O Que É Com? 64
4.3.3 Os Componentes Do Directx. 68
4.3.3.1 Hal: Hardware Abstraction Layer 69
4.3.3.2 Hel: Hardware Emulation Layer 69
4.3.3.3 Directdraw 70
4.3.3.4 Direct3d 70
4.3.3.5 Directsound 70
4.3.3.6 Directsound3d 71
4.3.3.7 Directinput 71
4.3.3.8 Directplay 71
4.3.3.9 Directsetup E Autoplay 72
4.3.4 Interfaciando Com Interfaces 72
4.4 Xna 74
5 TECNOLOGIA XNA CARACTERÍSTICAS 76
5.1 Xna Game Studio Express 77
5.2 Modelo Da Aplicação 77
5.3 Content Pipeline 79
5.4 Xna Audio Creation Tool (Xact) 81
5.5 Projeto De Som 80
6 PROPOSTA DE JOGO 85
6.1 Projeto 85
6.1.1 Breve Descrição do Projeto 86
6.1.1 Breve Descrição do Jogo 86
6.1.1 Documentação do Projeto 86
6.1.4 Documentação do SpacePong 86
6.1.4.1 Imagens utilizadas 86
6.1.4.2 Objetos 86
6.1.4.3 Fases 86
6.1.4.4 Pontuação 86
6.1.4.5 Tela de Ajuda 86
6.1.4.6 Tela de Crédito 86
6.1.4.7 Estrutura do Jogo 86
6.1.4.8 Fluxo do Jogo 86
6.1.4.9 Diagrama de Classes 86
6.1.4.10 Diagrama de Seqüências 86
6.1.4.11 Detalhes do Desenvolvimento 86
6.1.4.12 Teste do Jogo 86
6.1.4.13 Conclusão do Projeto 86
7 CONSIDERAÇÕES FINAIS 94
REFERÊNCIAS 95
INTRODUÇÃO
As ferramentas e métodos de desenvolvimento de jogos têm mudado com o tempo, os efeitos, gráficos e outros recursos que antes não eram possíveis de fazer hoje fazem parte da maioria dos jogos lançados. Cada vez mais os desenvolvedores criam um mundo virtual mais perto do mundo real. Essa afirmação já era prevista por André LaMothe, que sempre acreditou no potencial dos jogos e o rumo que ele tomava com o tempo.
Benjamin Nitshke foi um dos pioneiros no desenvolvimento de jogos em XNA, ele foi privilegiado a testar suas funcionalidades e a nova tecnologia que a Microsoft já vinha desenvolvendo. Inicialmente parecia mais um framework de desenvolvimento de jogos como o DirectX, onde ainda seria preciso uma IDE para desenvolver, isso por que a Microsoft manteve segredo durante um tempo.
Os desenvolvedores de jogos sempre ficaram divididos entre desenvolvimento de jogos de computador e desenvolvimento de jogos de console, para cada um deles era preciso uma nova IDE e uma nova linguagem de programação. Com o XNA é possível desenvolver jogos para computador e para XBOX 360 sem alterar muito o código, inclusive a manipulação de sons agora é feita de um modo separado para não precisar programar para console e computador de dois modos diferentes. Ainda segundo Nitshke, o forte do XNA é o gerenciamento de conteúdo, também conhecido como Content Manager.
Nem por isso o desenvolvimento em cima do DirectX parou, hoje o DirectX está na versão 10 e promete se manter atualizado independentemente das tecnologias paralelas.
Este projeto tem o objetivo de desenvolver um jogo na tecnologia XNA utilizando uma metodologia muito conhecida para documentação do projeto. Essa metodologia conhecida como Game Design Document ajudará a formar o documento com os fluxos, regras, interfaces e descrições detalhadas para o desenvolvimento do jogo.
No capitulo um será abordado a história dos jogos mostrando todo o crescimento em nível de desenvolvimento e entretenimento. Nesse capitulo será citado algumas tecnologias disponíveis na época e suas características básicas.
O capitulo dois aborda os aspectos envolvidos na produção de um jogo como computação gráfica, software de imagem 2d e software de modelagem 3d bem como a teoria de colisão dos jogos em 2d e 3d. Outros aspectos são, inteligência artificial e algoritmos determinísticos que ajudam a deixar o jogo um pouco mais dinâmico.
Visando ilustra a realidade da criação dos jogos, no capitulo três será abordado uma técnica para criar a documentação do jogo e de seu projeto. Técnicas como brainstorm, rascunhos e detalhes do jogo serão utilizados para criar o game design document.
A fim de pesquisa o capítulo quatro se refere às tecnologias mais conhecidas utilizadas para desenvolver um jogo. Nesse capítulo será descrito todas as características básicas das ferramentas de desenvolvimento de jogos citadas no projeto. Tecnologias como Opengl, DirectX, Cg e XNA fazem parte deste capítulo.
O capitulo cinco aborda o XNA para detalhar mais a tecnologia utilizada para desenvolver o projeto. Uma introdução básica a tecnologia é feita a fins de comparação as tecnologias anteriores e que segundo Benjamin Nitshke é o diferencial da ferramenta.
Dedica-se o capitulo seis para descrever o projeto do jogo e todos os aspectos relacionados a ele. Esse capítulo tem toda a descrição do jogo e sua documentação desenvolvida para orientar no desenvolvimento do projeto.
1 A HISTÓRIA DOS JOGOS
Segundo LaMothe (1999), a história dos jogos começou em meados da década de 60, quando surgiram os primeiros mainframes. Um dos jogos mais antigos é o Core Wars (Figura 1), um jogo baseado em texto que rodava em Unix. Com o passar do tempo começaram a surgir jogos com gráficos primitivos e começaram a se espalhar pelos mainframes e mini-computadores.
Figura 1: Core Wars para o console Unix
Fonte: Unix, 1960
A maioria dos jogos era para rede e seguiam alguns estilos como o Multi-User Dungeons (MUDs) e o Star Trek. No entanto estes jogos eram jogados pela minoria e apenas depois do lançamento do Pong a massa popular teve acesso aos jogos. O Pong foi desenvolvido por Nolan Busnell, que investiu na área dos jogos e criou a empresa Atari.
Figura 2: Pong versão do console Atari
Fonte: Atari, 1975
Em meados dos anos 70 surgiram os primeiros computadores pessoais. TRS-80, Apple e o Atari 800 foram os primeiros a invadirem o mercado, antes disso surgiram kits como o Altair 8000 que não era muito fácil de montar. Entre estes três modelos, o Atari 800 era o mais poderoso, o TRS-80 era voltado para negócios e a Apple tinha o melhor marketing.
Os jogos eram escritos em BASIC ou linguagem de máquina pura. Eles não possuíam uma interface gráfica muito avançada e com isso bastava fazer um jogo no estilo Pong com poucas regras para ganhar a atenção do publico da época. Esse fator ajudou a fazer dos primeiros jogos clássicos tornando seus criadores muito conhecidos. Não existiam materiais sobre o assunto, até que alguém publicou um artigo de 50 a 100 paginas, outro artigo apareceu na revista Byte.
Na década de 80 surgiram os primeiros computadores de 16-bits e nessa época os jogos começaram a ter uma aparência boa com mais recursos gráficos. Jogos como Wing Commander e Flight Simulator apareceram no mercado fazendo sucesso com seus gráficos avançados. Nessa época o Amiga 500 e o Atari ST dominavam o mercado como melhores computadores para jogos, entretanto o PC continuava no mercado por ser um computador de baixo custo.
O PC continuou a ganhar popularidade lentamente até a década de 90 quando a IBM PC - compatível chegou à liderança no mercado lançando o Windows 3.0 e ficou conhecido como “o computador de trabalho pessoal”. Era possível jogar, escrever programas e abri-lo para conectar outras placas, diferente do Macintosh da Apple. Esse diferencial atraiu vários hobistas.
Figura 3: Tela do jogo Wolfenstein
Fonte: Gray Matter, 1990
Logo após o lançamento do jogo Wolfenstein (Figura 3) o sucesso foi tão grande que com o avanço dos jogos no ano de 1993 a Id Software lançou DOOM (Figura 4) como uma continuação do sucesso de seu jogo anterior. Ela conseguiu provar que o PC também era uma plataforma de programação de jogos e isso impulsionou mais ainda o avanço do PC. Esse avanço aconteceu tanto com o software como com o hardware. Conforme os jogos e softwares evoluíam, os hardwares começavam a ficar obsoletos e não serviam mais para as próximas tecnologias em desenvolvimento. Esse fator impulsionou o avanço no mundo dos jogos cada vez mais, tornando os jogos mais complexos e reais.
Figura 4: Tela do jogo DOOM
Fonte: id Software, 1993
Segundo Colnaghi (2001), isso fez a Microsoft reavaliar sua posição quanto à programação de jogos, concluindo que era hora de entrar no mercado. Ela entrou no mercado como Microsoft Games e tinha como objetivo criar a solução para todos os problemas do mundo.
Entretanto o Windows 95 não tinha um bom desempenho em vídeo em tempo real e sua capacidade de áudio deixava muito a desejar. Para solucionar este problema a Microsoft lançou o WinG que possuía algumas funções gráficas para desenhar bitmaps na tela.
Logo em seguida a Microsoft começou a desenvolver o DirectX que serviria como uma solução completa para gráficos, sons, dispositivos de entrada(teclado, joysticks e similar), rede e sistema 3D. O DirectX só começou a fazer sucesso a partir da versão 3.0 quando ele se tornou mais estável. E mesmo assim as empresa continuaram a desenvolver jogos usando a plataforma DOS, essa situação só mudou no lançamento do DirectX 5.0.
Atualmente o DirectX está na versão 10 mas só roda no Windows Vista, deixando a maioria dos usuário do Windows XP com a versão 9.0c. Ele é muito usado para desenvolver jogos complexos e de alto desempenho. Entretanto a Microsoft não parou por aí, atualmente a grande novidade é o XNA, uma IDE completa para desenvolvimento de jogos de computador com possibilidade de portabilidade para XBOX 360, o último console lançado pela Microsoft.
Figura 5: XBOX 360
Fonte: Microsoft, 2008
1.1 Atari e a História do Vídeo Game
A história da Atari, segundo Azevedo (2005), começa em 1972 quando seus criadores decidiam entre alguns nomes como Syzygy e Atari. Syzygy era um nome muito difícil de ser pronunciado e já estava registrado para uma companhia que trabalhava com telhados. O nome Atari prevaleceu. Seu significado vem do jogo japonês Go. É o grito que o jogador dá ao encurralar seu inimigo, equivalente ao cheque mate do xadrez. O logo da Atari foi inspirado numa estilização do Monte Fuji e representava toda a solidez que a marca viria a deter no futuro.
Contando com a parceria do colega Al Alcorn, a Atari partiu para a estruturação de seu primeiro produto, chamado de Pong. O jogo foi desenvolvido no quarto do cientista e testado num modelo fliperama. O sucesso foi tanto que o excesso de fichas depositadas causou um problema ao invadir os circuitos. A máquina foi chamada de Computer Space e ganhou o status do primeiro arcade da história dos games. Esse fliperama foi vendido antes da versão doméstica com pouco sucesso e apenas mil e quinhentos equipamentos foram comercializados.
Contudo, a idéia era rodar o Pong em um sistema caseiro por um valor mais popular. Em 1974 a idéia saiu das pranchetas por meio de uma parceria estratégica com a cadeia de lojas Sears. Isso rendeu mais de 150.000 unidades e começou a Pongmania por todo o país.
Durante muito tempo dezenas de empresas lançaram produtos similares ao Atari. A cada novo lançamento melhorias eram feitas para tentar concorrer com as inúmeras marcas. Alguns consoles como o Coleco Telstar e o Fairchild Channel F eram possíveis de programar seu próprio jogo. Foram os primeiros consoles programáveis da história.
Bushnell sai ao mercado com um novo conceito em 1977. A rede de lanchonetes Chuck E. Cheese's, conhecida entre os americanos pelo simpático rato mascote da cadeia, mistura num ambiente futurista e familiar uma casa de fliperamas e uma pizzaria.
Nesse mesmo ano a Atari criou o Video Computer System que revolucionou novamente o mercado dos vídeo games. Foi o primeiro console programável com jogos em cartucho da empresa. Foi para eles que se desenvolveram alguns dos jogos mais famosos da história. Surgiram novas parcerias com as softwares houses nipônicas, como Sega e Konami. A Atari também atuava numa parceria com a Warner Communications.
No lançamento do Video Computer System aconteceram os primeiros desentendimentos entre Bushnell e Steve Ross, presidente da Warner. Esse pode ser entendido como o marco zero da crise que se abateu sobre o setor nos anos que viriam.
A Atari deixou de produzir consoles e focou seus esforços na produção de softwares. A Sega assume de vez sua vocação para criar games em vez de insistir no Dreamcast. Os donos do Sonic apostam que o melhor é criar games para Sony, Nintendo e Microsft em vez de perder dinheiro tentando combatê-los.
1.2 Gêneros
Hoje em dia existem muitos gêneros de jogos, mas não necessariamente é preciso escolher um deles, pode-se fazer uma mixagem de gêneros (LAMOTHE, 1999).
Primeira pessoa: é o jogo em 3D com a visão do personagem, os mais conhecidos são Doom, Quake e Unreal. Tem como objetivo passar a sensação de estar no ambiente do personagem principal.
Esporte: os gráficos variam de 2D e 3D, sua principal característica é a inteligência artificial que vem sendo cada vez mas aprimorada. Normalmente estes jogos permitem que dois jogadores joguem simultaneamente. Um dos jogos mais famosos é o Winning Eleven.
Luta: a visão normalmente é de lado e o jogo é uma mistura de gráficos 2D e 3D. A trilogia do Street Fighter é o exemplo mais conhecido.
Arcade/Tiro/Plataforma: tem como principal característica a simplicidade. São jogos 2D, rápidos, como Pac-Man e Asteroid.
Simulações mecânicas: estilo que passa a sensação de pilotar algum veículo como carro, avião, submarino entre outros. Um dos simuladores que chega mais perto da realidade é o Grant Turismo.
Simulação de ecossistema: tem como objetivo dar poder de Deus ao jogador. Os títulos mais conhecidos são The Sims, Simcity e Black and White.
Estratégia: normalmente o jogador tem que controlar um exército ou uma nação para atingir um objetivo específico. O estilo se divide em dois tipos, em tempo real e por turno, podendo levar horas para terminar uma jogada. Ages of Empire e Deadlock refletem os dois estilos.
Role Play Game: também conhecido como RPG, é um dos estilos que mais atraiu jogador, tanto no modo de jogo sozinho como no modo online. Sua característica é a interação com outros personagens do jogo tornando um jogo não linear. Atualmente a interação online é tanta que permite juntar-se em clãs, realizar missões sozinho ou em grupo, trocar itens, organizar eventos e muito mais. Um exemplo atual é o Silkroad.
Historia interativa: estilo de jogo linear onde o jogador tem que seguir um roteiro. Normalmente decifrando charadas ao decorrer do jogo. Fez muito sucesso quando os recursos gráficos ainda eram básicos. Jogos como Indiana Jones e Leisure Suit Larry seguem esse estilo.
Tabuleiro/Puzzles: jogos de tabuleiros normalmente disputados por mais de um jogador como o Monopoly. Tem como objetivo recriar virtualmente os jogos mais conhecidos de tabuleiro. Algumas vezes sofrendo uma adaptação com recursos extras em 3D e disponibilidade para jogar com outras pessoas pela Internet.
Os jogos podem ser desenvolvidos em duas dimensões (2D) ou em três dimensões (3D). Alguns jogos usam uma mixagem desses estilos, normalmente os jogos em 2D possuem gráficos renderizados em ferramentas de modelagem 3D para parecerem mais agradáveis ao jogador (LAMOTHE, 1999).
2 ASPECTOS ENVOLVIDOS NA PRODUÇÃO DE JOGO
Esse capítulo aborda questões referentes ao desenvolvimento de um jogo assim como seus estilos mais conhecidos.
2.1 Estilos de Jogos
Segundo Feldman (2001), ao passar dos anos o desenvolvimento de jogos no estilo árcade tornou-se um grande negocio e atraiu muitos programadores fieis a esse gênero. A computação gráfica começou a crescer desde então, simplesmente por que um jogo de árcade não vendo no mercado se não possuir um bom design. Feldman mostra como exemplo o Sonic The Hedgehog (Figura 6), provavelmente não seria tão carismático se os gráficos fossem representados como caracteres ASCII. Outro exemplo é o Mortal Kombat, os personagens do jogo não pareceriam tão reais se fossem desenhados a mão em vez de fotos reais.
Figura 6: Sonic The Hedgehog
Fonte: Feldman, 2001
O estilo arcade é bem conhecido pela sua simplicidade gráfica. O jogo pode ter uma tela simples com um nível estático como Pac Man, pode ser divididos em fases ou níveis cada um com uma tela. Uma técnica muito usada é o scrolling ou deslizamento, onde a fase desliza para a direção que o jogador está virado ou andando. Em sua pesquisa Feldman notou cinco tipos de sub gêneros do estilo arcade.
Maze/Chase Games: esse tipo estourou nos anos 80 e com o tempo se mostrou como um exemplo para outros estilos que surgiam. Esse estilo possui uma característica básica, o jogador anda por um labirinto cheio de obstáculos e tem que atingir um determinado objetivo. Na maioria dos jogos o jogador é perseguido por inimigos e tem que completar a missão fugindo ou procurando um meio para eliminá-los. Esses jogos também são conhecidos pela sua simplicidade gráfica. Feldman afirma que são jogos fáceis de se desenvolver e são os favoritos dos desenvolvedores de jogos. Um exemplo muito conhecido é o Dig Dug(Figura 7). Algumas variações desse estilo sofreram adaptações e melhorias como a técnica de deslizamento. Essa técnica é muito utilizada quando o jogo necessita de mais espaço.
Figura 7: Tela do jogo Dig Dug
Fonte: Feldman, 2001
Pong Games: Esse estilo surgiu na década de 70 com a estréia do jogo Pong. O jogo sempre tem uma bola onde um ou mais jogadores rebatem para marcar pontos. Existem muitas variações desse estilo, como o jogo Arkanoid(Figura 7). O diferencial das variações são suas regras diferenciadas como itens de bonus, inimigos, obstaculos e blocos mais resistentes. São jogos simples em regras e gráficos. Normalmente não usam deslizamento de tela e possuem varias fases. Esse estilo lembra bastante os jogos de pinball do fliperama. Uma evolução do jogo Pong é o Arkanoid.
Figura 8: Tela do jogo Arkanoid
Fonte: Taito, 1986
Shooters: Os jogos do tipo shooter, também chamado de shoot-em-up, começaram a aparecer logo depois do primeiro Pong. Eles fizeram muito sucesso nos anos 80 e 90.
Esse estilo possui vários subgêneros muito parecidos. Mesmo assim eles compartilham um tema comum onde existe um agressor e um defensor que tem como objetivo combater seus inimigos durante cada fase do jogo. Normalmente o objetivo é alcançado destruindo todos adversários, diferentes do Maze/Chase Game que o objetivo pode ser concluído evitando seus inimigos.
Em seu subgênero estático o jogador deve combater a ameaça atirando contra o inimigo em uma tela fixa. Já o subgênero scrolling varia entre duas ou quatro direções o que torna o jogo maior e mais sofisticado nos objetos da tela e nas fases. Um exemplo é o jogo 1943 da Capcom(Figura 9).
Normalmente possuem varias regras de jogo tornando seu desenvolvimento um pouco mais difícil e complexo. Isso por que cada jogo impõe a implementação de técnicas diferentes. Eles possuem um design mais detalhado e exigem mais tempo, esforço e habilidade para a criação e desenvolvimento.
Figura 9: Tela do jogo 1943
Fonte: Capcom, 1987
Puzzlers: O gênero puzzler ou quebra cabeça, não fizeram tanto sucesso como o maze/chase game e começaram a fazer parte da industria dos jogos na década de 80, segundo Feldman. Ficou conhecido pelo objetivo de induzir o jogador a pensar sem precisar de reflexos rápidos. Alguns jogos são rápidos e exigem mais reflexos mas a grande maioria não.
Os jogos desse gênero somam diversão com uma ferramenta de aprendizado constante. Segundo Feldman (2001), eles não possuem variações em sub gêneros por serem relativamente simples. Os jogos tem telas fixas e muitos não tem um objetivo maior do que marcar pontos até perder. Algumas variações permitem jogar em dupla para desafiar outros jogadores, ganha quem conseguir resistir mais tempo sem que os blocos preencham a tela.
Segundo Feldman (2001) eles são fáceis de desenvolver e possuem gráficos e detalhes mais simples. O exemplo mais conhecido é o Tetris(Figura 10).
Figura 10: Tela do jogo Tetris
Fonte: Árcade, 2007
Plataformers: Segundo Feldman (2001), os jogos de plataforma apareceram logo cedo com os primeiros jogos de arcade mas só nos anos oitenta começaram a se popularizar. Desde então os jogos de plataforma se tornaram um sinônimo dos jogos de arcade.
Os jogos de plataforma compartilham algo em comum: o jogador manipula o personagem na tela com vários desafios para marcar pontos e atingir determinado objetivo. Sua principal característica é de que todos os jogos possuem plataformas onde o personagem deve se mover, e é por isso que são chamados assim. Este estilo segue a lógica de que se o jogador consegue jogar um jogo de plataforma pode jogar todos.
Assim como os Shoooter, o jogo de plataforma também pode ser estáticos ou dinâmicos(scrooling).
No estilo estático o jogador controla o personagem em uma tela simples onde depois de completar seu objetivo passa para a próxima fase.
Já no estilo scrooling, o mais utilizado é o modo bidirecional, onde o jogador controla a personagem em duas direções, direita e esquerda. Em alguns jogos o jogador pode mover-se para cima e para baixo. Esses jogos são bem mais detalhados e normalmente possuem um mundo e não uma fase(Figura 11).
Figura 11: Tela do jogo Super Mario 3
Fonte: Dynavision, 1990
Feldman explica que nos sub gêneros dos jogos arcade, o estilo plataforma é o mais difícil de criar. Isso porque a tecnologia dos jogos tem se tornado algo tão sofisticado que para os desenvolvedores o jogo fica extremamente complexo e a equipe de arte precisam criar gráficos mais detalhados para tornar o jogo um sucesso.
A qualidade dos gráficos tem se mostrado de certa forma essencial para os jogos e uma boa ferramenta de manipulação de imagem pode aumentar a produtividade e melhorar a qualidade final da arte dos gráficos.
Alguns tipos de ferramentas gráficas que podem ajudar no trabalho de manipulação de imagem e animação são:
Programas de desenho
Utilitário de captura de imagem
Programa para visualizar e converter imagens
Ferramenta de palheta de cores
2.2 Software de Imagem 2d
Atualmente no mercado existem inúmeros softwares de edição de imagens com muitos recursos e efeitos, muitos deles são gratuitos ou até código aberto. Para o desenvolvimento do projeto será usado o Macromedia Fireworks 8 que possui uma versão de demonstração de 30 dias. Outros softwares para edição de imagem são o Photo Shop, Corel Draw, Paint e Paint .NET.
2.3 Software de Modelagem 3d
Softwares de modelagem 3D podem ser extremamente complexos para leigos no assunto e podem custar até 100.000 dólares. Existem versões de demonstração e gratuitas, mas normalmente são bem limitadas. As ferramentas mais conhecidas no mercado são o TrueSpace, Cagliari, 3D Studio Max e Maya. No projeto não será usado nem uma dessas ferramentas
2.4 I.A.
Segundo Colnaghi (2001), a inteligência artificial (I.A.) é um conjunto de algoritmos baseado em lógica, probabilidade e memória a fim de simular a inteligência de um ser humano. A lógica para cada jogo pode variar dependendo da necessidade da inteligência da maquina.
Na prática, a I.A. depende muito do foco, ou seja, objetivo final do cérebro a ser modelado. Para um jogo, se o personagem parecer inteligente, estará suficiente, independente da lógica utilizada. Não existe uma maneira correta de modelar a I.A., se os resultados obtidos são satisfatórios o método escolhido está aprovado (COLNAGHI, 2001).
2.5 Algoritmos Determinísticos
Algoritmos determinísticos são comportamentos predeterminados ou pré-programados. Por exemplo, se olharmos para a I.A. do jogo Asteroids(Figura 12), os asteróides são criados em uma posição qualquer com uma velocidade aleatória. O asteróide possui apenas um objetivo, seguir seu curso predeterminado, e essa e a sua inteligência artificial - simples.
Figura 12: Inteligência Artificial do jogo Asteroids
Fonte: Colnaghi, 2001
2.6 Inference Engine
Segundo Harrison (2003), essa técnica é mais avançada e normalmente é uma solução para a implementação e codificação da inteligência artificial, mas ela é apenas uma parte para a solução.
Ela tem como objetivo criar um diagrama de caso com as ações a serem tomadas dependendo de cada estado da ação. Cada ação é tomada dependendo de seu resultado, como na figura 13.
Figura 13: Diagrama de Inteligência artificial
Fonte: Autor, 2008
2.7 Matemática e Física
Para o desenvolvimento de um jogo é preciso um conhecimento básico em física, até mesmo para um jogo no estilo Pong é necessário aplicar formulas de física. Durante muito tempo estes cálculos de física eram feitos apenas pelo processador da maquina podendo afetar o desempenho do jogo. Até inicio de 2007 os jogos não exigiam tanto recurso de física, até o lançamento de Medal of Honor Airborne. Para conseguir jogar usando seus recursos no máximo, é preciso uma placa de física (AGEIA) além da configuração padrão do jogo.
As placas de física estão começando a aparecer no mercado, abrindo uma nova possibilidade para os jogos, com isso a programação do jogo terá de ser voltada a este novo recurso.
2.8 Gráfico 2d
Um jogo como Pong usa uma estrutura de gráfico 2D, e deve ser tratada com um gráfico cartesiano de duas posições, X e Y. Segundo Stahler (2004), é bom ressaltar que o computador trata o posicionamento das imagens de um modo diferente do gráfico cartesiano, enquanto o Y do computador é acrescentado, para o cartesiano ele é subtraído, entretanto existem formulas matemáticas para transformar um ponto do computador para um ponto no gráfico cartesiano.
Figura 14: Diferenças entre os Gráficos
Fonte: Autor, 2008
O desenvolvimento de um jogo 2D pode ser desenvolvido usando apenas estas duas posições. A maioria dos jogos de console em 2D são desenvolvidos usando apenas este conceito. No caso, o jogo proposto usará o gráfico 2D.
2.9 Gráfico 3d
Um gráfico 3D difere apenas pela sua dimensão Y, que representa a altura do objeto no plano. Este objeto é representado por três coordenadas, X, Y e Z (Figura 15). Infelizmente não existem padrões que dizem que um gráfico 3D deve ter como o eixo Y sendo a altura. Muitas referencias apontam inclusive o eixo Y como sendo a altura e o Z profundidade. Entretanto é tudo uma questão de decisão de qual usar (STAHLER, 2004).
Figura 15: Gráfico em três dimensões
Fonte: Autor, 2008
2.10 Teoria da Colisão 2d E 3d
Alguns jogos em 2D usam este tipo de gráfico para simular um efeito de colisão 3D, conhecidos como jogos isométricos (ANDRÉ LAMOTHE, 1999). Um exemplo de jogo antigo que usa essa tecnologia é o PaperBoy, outro mais recente que fez muito sucesso é o Diablo.
Segundo LaMothe (1999), existem três métodos para aplicar colisão em um jogo.
Jogo baseado em células e totalmente em 2D.
Basicamente deve ser decidido qual será o ângulo de visão do jogo e então desenhar toda a arte no ângulo definido. Entretanto essa técnica depende também de como os desenhos são renderizados na tela, elas devem seguir uma ordem, de baixo para cima, fazendo com que os objetos que estão atrás dos outros continuem atrás(Figura 16).
Figura 16: Colisão em células ou tiles.
Fonte: Colnaghi, 2001
Full screen com colisão 2D ou 3D.
Essa técnica consiste em desenhar um mundo isométrico do tamanho que for desejado e criar uma estrutura secundaria que contenha os dados informando onde no espaço possui colisões. Com essa técnica é possível determinar que os desenhos em 2D ou 3D não precisam ter informação de altura, por mais complexo que eles sejam(Figura 17).
Figura 17: Colisão usando um vetor 3D
Fonte: Colnaghi, 2001
Usando matemática 3D com câmera fixa.
Essa técnica é a mais fácil, pois não é preciso fazer nem uma estrutura extra para armazenar os dados dos objetos, basta usar uma engine 3D e fixar a câmera em um ângulo para fazer o efeito de jogo isométrico. A maioria dos jogos da Sony Playstation I e II usa essa técnica, são em 3D com câmera fixa em 45º(Figura 18).
Figura 18: Tela do jogo Warcraft 3 usando câmera fixa.
Fonte: Blizzard Entertainment, 2002
2.11 Multiplayer e Online
Criar um jogo multiplayer requer muito planejamento na hora de desenvolver o projeto e a forma de comunicação entre os jogadores e o servidor, muitos jogos não dão conta de tantos jogadores e se tornam lentos e praticamente impossíveis de se jogar independente da conexão da maquina do jogador, ou seja o cliente (LAMOTHE, 1999).
Antigamente os jogos eram modem a modem(Figura 19), ou seja, sem um servidor entre os dois jogadores. O primeiro jogo modem a modem foi criado por Dani Bunten Berry e se chama Modem Wars, ele foi lançado para o Commodore 64 na década de 80. O jogo era de estratégia e em tempo real, o que tornou o jogo realmente significante pois até então nem um jogo era em tempo real (BARRON, 2001).
Figura 19: Comunicação entre modem
Fonte: Autor, 2008
Segundo Barron (2001), a comunicação entre as maquinas pode ser feito de outros dois jeitos, cliente servidor e ponto a ponto. No cliente servidor, os dados são enviados para o servidor e retornam um valor ao cliente e vice versa, nesse tipo de comunicação o servidor é sempre dedicado, ou seja, ele só recebe as informações e processa o jogo propriamente dito não necessariamente precisa estar rodando.
A comunicação cliente servidor é utilizada nos jogos de RPG que podem ter mais de cem pessoas conectadas. O servidor consegue executar as tarefas com muito mais performance e suporta muito mais jogadores por não precisar rodar o jogo simultaneamente. A figura 20 exibe uma conexão com um servidor dedicado. Há muitos casos de jogos on-line que precisam de mais de um servidor dedicado para suportar o número excessivo de jogadores.
Figura 20: Comunicação cliente servidor.
Fonte: Autor, 2008
Na comunicação ponto a ponto um cliente simula um Server(Figura 21) e todos clientes se comunicam com ele e entre si seguindo o principio de uma comunicação ponto a ponto. Esse método é muito utilizado em jogos multi jogador quando se tem um número mais reduzido de jogadores.
Figura 21: Comunicação ponto a ponto.
Fonte: Autor, 2008
3 PROJETO DE UM JOGO
Nesse capítulo será abordado uma metodologia para criar e documentar o projeto de um jogo.
Segundo Perucia (2005), o desenvolvimento de um projeto de jogos é muito parecido com outro software qualquer, mas caracteriza-se mais pela sua fase inicial de criação. A criação do jogo segue as principais fases brainstorm, rascunho do jogo, detalhes do jogo que por sua vez resultam no documento final para codificação da idéia. Conhecido como Game Design Document.
Cada fase do processo pode ser repassada até a definição final da idéia. A importância deste documento é tão grande que ao final de seu desenvolvimento, pode ser avaliado se o jogo vai ser um sucesso ou um fracasso.
3.1 Brainstorm
O brainstorm (tempestade de idéias) é a primeira fase de um projeto de jogos. Nessa fase os projetistas devem avaliar todas as sugestões para amadurecer as idéias e não descartar nada que pareça absurdo. Segundo Alexandre Perucia (2005), muitas idéias que pareciam não ter nenhum sentido, no final, acabam virando um sucesso. Um exemplo é o Mario, onde um bombeiro se torna herói em um mundo que tem tartarugas e cogumelos que andam.
Algumas questões que devem ser tratadas nessa fase são: objetivo do jogo, o que o jogador deve fazer, como ele deve fazer, o que torna o jogo divertido, se o jogo terá charadas, etc. Nessa fase as idéias não precisam ser detalhadas. Outro passo é definir o estilo do jogo que será desenvolvido, ou até uma mixagem dele.
O objetivo final do Brainstorm é reunir o máximo de idéias possíveis e diferentes para, futuramente, transformar em algo criativo e facilitar o processo de desenvolvimento de idéias.
Todas as idéias criadas no Brainstorm de um jogo que não são utilizadas podem ser armazenadas para que possam futuramente se transformar em outros jogos.
3.2 Rascunhos do Jogo
A segunda fase consiste em criar protótipos do jogo em papel, desenhar cenas e passagens do jogo para poder simular a jogabilidade (gameplay). Esse tipo de técnica é mais adequado para jogos simples como jogos de tabuleiro e jogos em duas dimensões e ajuda na visualização do projeto final, permitindo fazer alterações sem gerar muito impacto no seu desenvolvimento (PERUCIA, 2005).
Figura 22: Rascunho de um jogo segundo Perucia(2005).
Fonte: Perucia, 2005
O rascunho pode ser desenhado em forma de roteiro como se fosse um filme. Ele ajuda a prever as funcionalidades do jogo não só para o jogador, mas também para o desenvolvedor ou responsável pela documentação técnica do jogo. Ele também torna mais claro as regras do jogo e seu resultado final. O rascunho é uma etapa fundamental para tornar o brainstorm ainda mais criativo e eficiente.
3.3 Detalhes do Jogo
Segundo Perucia (2005), após ter o rascunho do jogo pronto é preciso fazer um detalhamento complexo e escrever tudo a respeito do jogo. Nessa etapa a técnica consiste em realizar perguntas sobre o jogo como:
Em que época se passará o jogo?
Quais são seus inimigos?
Como serão seus ataques?
Qual o objetivo principal do jogo?
Qual será a trilha sonora do jogo?
Qual será o algoritmo de inteligencia artificial usada no jogo?
Qual será a dificuldade do jogo?
Qual será a história do personagem principal do jogo?
Descrever o jogo ou uma cena pode ajudar a formar perguntas mais objetivas Descreva a cena e aquilo que acontece a seguir. Se nada acontecer até que o usuário faça alguma coisa, descrever aquilo que são as opções do usuário e o que acontece como resultado de todas as ações possíveis. É preciso ter em mente que a maioria dos jogos de alguma forma são controladas pelo usuário. O herói não significa automaticamente fazer alguma coisa; o usuário, quando jogar podem fazer com que o herói faça tal-e-um tal ato, o que faria com que o inimigo controlado por computador tomasse atitudes diferenciadas para cada ato.
As perguntas podem ser feitas dependendo do estilo do jogo. Por tanto para cada tipo de jogo as perguntas podem mudar. O objetivo é criar perguntas claras e simples que possam descrever o jogo e fixar a idéa.
Segundo André Lamothe (1997), as charadas podem tornar o jogo mais interessante fazendo do jogo um desafio para que o jogador pense e interaja mais com o ambiente. A idéia é fazer com que o jogo não se torne linear. Atualmente os jogos onlines têm usado muito deste artifício para segurar o jogador por mais tempo e fazendo com que ele retorne com mais freqüência. Para que um jogo que possua apenas o modo de jogar sozinho se torne uma referência, é preciso que tenha muitas charadas e que não seja linear, dando a liberdade no jogador escolher caminhos totalmente diferentes a cada vez que joga. Um bom exemplo é o The Elder Scrolls IV Gates of Oblivion.
É nesta fase que a equipe toda deve ser perguntar se não falta mais nada ou se não deveria ser alterado mais alguma coisa. No decorrer do detalhamento de cada funcionalidade do jogo, a equipe deve levantar a possibilidade de reavaliar alguma pendência e partir do inicio para tornar a idéia mais clara e objetiva. Para isso é possível voltar ao rascunho do jogo ou até mesmo ao brainstorm (PERUCIA, 2005).
3.4 Game Design Document
O game design document tem como objetivo agregar todos os documentos do projeto em um único documento. Essa etapa é muito útil, pois tudo o que foi proposto até o momento pode ser repensado para não ocorrer nem um imprevisto na criação do projeto. Essa fase pode levar muito tempo e tem como objetivo avaliar de forma clara todo o funcionamento do jogo.
Segundo Baldwin (2005), o game design document é um documento de referência. Os membros da equipe de desenvolvimento usam o documento constantemente para encontrar informações específicas para as suas necessidades específicas. O documento pode crescer consideravelmente até o fim do jogo. O objetivo não é tornar o documento um manual de criação com todas etapas detalhadas do jogo. Para isso é preciso organiza-lo de forma que as informações fiquem de fácil acesso e ajudem as equipes relacionadas no projeto. Baldwin salienta que algumas dessas informações podem não aparecer no game design document, e em vez disso aparecer em documentos complementares, como um plano de teste. Isso ajuda a tornar o documento mais organizado e legível.
Uma observação de Baldwin é que um game design document pretende ser um documento vivo. Da mesma forma que um artista muda seu desenho cada vez que pinta, o jogo deve sofrer a mesma alteração conforme o documento. Com isso o documento servirá para que todos da equipe possam acompanhar seu desenvolvimento.
4 TECNOLOGIAS DISPONIVEIS NO MERCADO
Esse capítulo tem como objetivo citar algumas tecnologias muito utilizadas para desenvolver um jogo. Descrevem-se as características de cada tecnologia utilizada no mercado e suas principais vantagens.
4.1 OPENGL
Segundo Wesley, OpenGL é uma biblioteca padrão para manipulação de imagens multi plataforma. A biblioteca foi finalizada em 1992 mas a sua primeira implementação só ocorreu em 1993. Ela era compatível com a biblioteca Iris Graphics Library que foi deenvolvida pela Silicon Graphics. Para estabelecer um padrão, a Silicon Graphics e outras empresas de hardware criaram um padrão que foi chamado de OpenGL.
A evolução do OpenGL é controlado pelo OpenGL Architecture Review Board (ARB), esse grupo foi criado pela Silicon Graphics em 1992. Ele possui regras e um conjunto de normas que são respeitadas para manter o padrão. A sua principal missão é controlar as especificações e manter a conformidade dos testes. O grupo original do ARB era formado por representantes de várias empresas como Microsoft, Intel, Compaq, IBM, entre outras. Atualmente ela é formada por membros das empresas 3Dlabs, Apple, ATI, Dell, IBM, Intel, NVIDIA, SGI e Sun Microsystems.
O OpenGL herdou muitas características da biblioteca Iris GL. A intenção é prover acesso ao harware gráfico mais rápido e no nível mais baixo possível para manter o hardware independente. Ele foi implementado para rodar em vários sistemas operacionais, incluindo Mac, PC e sistemas baseados em UNIX. O OpenGL tem sido apoiado em várias arquiteturas de hardware, das que apóiam pouco às que aceleram praticamente tudo em hardware.
4.1.1 O que é OpenGL?
OpenGL é um software de interface para hardware de gráficos. Esta interface consiste de aproximadamente 250 comandos distintos (cerca de 200 no centro do OpenGL e outras 50 na biblioteca de utilidades do OpenGL) que se usa para especificar os objetos e operações necessárias para produzir interatividade em aplicações tridimensionais.
OpenGL é projetado como uma forma aerodinâmica, interface de hardware independente para ser implementada em muitas plataformas diferentes de hardware. Para completar essas qualidades, nenhum comando para executar tarefas do Windows ou entrada de usuário estar em uso está incluído no OpenGL. Em vez, precisa-se trabalhar através de qualquer controle de sistema Windows o hardware particular que se está usando. Similarmente, OpenGL não providencia comandos de alto nível para descrever modelos de objetos tridimensionais. Muitos comandos forçam a especificar formas relativamente complicadas como automóveis, partes do corpo, aviões ou moléculas. Com o OpenGL aumenta o desejo de modelo por um pequeno grupo de formas geométricas primitivas – pontos, linhas e polígonos.
Uma biblioteca sofisticada que providencia estes traços podem certamente serem construídas no topo do OpenGL. O OpenGL Utility Library (GLU) providencia muito desses traços de modelos, como uma superfície quadrada e curvas e faces NURBS. GLU é uma parte padrão de toda a implementação OpenGL. Também existe um alto nível de ferramentas, como Fahrenheit Scene Graph (FSG), que são construídas sobre o OpenGL, e estão separadamente disponíveis para muitas implementações do OpenGL.
OpenGLs tem a proposta de renderizar dois ou três objetos dimensionais no frame buffer. Estes objetos estão descritos como uma seqüência de vértices (que define objetos geométricos) ou pixels (que define imagens). OpenGL realiza vários passos de processamento de dados do pixel para formar a imagem desejada no buffer.
4.1.2 Fundamentos OpenGL
Desenhos primitivos do OpenGL - pontos, linhas segmentadas ou polígonos - significa vários modos selecionáveis. Podem-se controlar vários módulos simultaneamente, isto é, selecionar um modo não quer dizer que outros modos serão selecionados, embora que muitos modos podem interagir para determinar o que eventualmente termina no buffer. Primitivos são especificados, modos são setados e outras operações do OpenGL são definidas editando comandos na forma de chamada de funções.
Primitivos são definidos por um grupo de um ou mais vértices. Um vértice define um ponto, um ponto final de uma linha, ou a curva de um polígono onde duas extremidades se encontram. Dados (consistindo de vértices coordenados, coloridos, normais, texturas coordenadas e flags extremas) são associados com um vértice e cada vértice e suas associações são processadas independentes, na ordem e do mesmo jeito. A única exceção para esta regra é se o grupo dos vértices precisa ser recordado, então um primitivo particular se ajusta sem uma região especificada; neste caso, vértice de dados pode ser modificados e novos vértices criados. O tipo de recorte depende em qual primitivo o grupo de vértice está representado.
Comandos são sempre processados na ordem em que eles são recebidos, embora possa ter um indeterminado atraso antes que um comando tenha efeito. Isso significa que cada primitivo é desenhado completamente antes que qualquer comando subseqüente tenha efeito. Também significa que os comandos STATE-QUERYING retornam dados que são compatíveis com a execução completa de todos os comandos do OpenGL previamente emitidos.
4.1.3 Modelo Execução
O modelo para interpretação dos comandos OpenGL é o cliente-servidor. Uma aplicação (o cliente) emite comandos, que são interpretados e processados pelo OpenGL (o servidor). O servidor pode ou não operar no mesmo computador como cliente. Neste sentido, OpenGL é uma rede transparente. Um servidor pode suportar vários contextos GL, cada qual é um estado GL encapsulado. Um cliente pode conectar em qualquer um destes contextos. O protocolo de rede requerido pode ser implementado aumentando um protocolo já existente (tal qual o X Windows System) ou usando um protocolo independente. Nenhum comando OpenGL é providenciado para obter informação de usuário.
Os efeitos dos comandos do OpenGL no frame buffer são ultimamente controlados pelo sistema do Windows que aloca os recursos no frame buffer. O sistema Windows determina qual porção do frame buffer o OpenGL pode acessar em qualquer tempo determinado e transfere para o OpenGL como essas porções são estruturadas. Por esta razão, há no OpenGL comandos para configurar o frame buffer ou inicializar o OpenGL. A configuração do frame buffer é feita fora do OpenGL em conjunto com o sistema do Windows; a inicialização do OpenGL toma lugar quando o sistema Windows aloca uma janela para o OpenGL renderizar.
4.1.4 Um Pouco do Código OpenGL
Desde que é possível de fazer muitas coisas com o sistema de gráficos do OpenGL, um programa OpenGL pode ser complicado. Entretanto, a estrutura básica de um programa usual pode ser bem simples: suas tarefas são inicializar certos estados que controlam como o OpenGL renderiza e especificar quais objetos serão renderizados.
A imagem final renderizada consiste de pixels desenhados na tela; um pixel é o menor elemento visível no hardware de display que se pode colocar na tela.
A informação sobre os pixels é organizada na memória dentro dos bitplanes. Um bitplane é uma área da memória que segura um bit de informação para cada pixel na tela; o bit pode indicar quanto vermelho um pixel particular pode ser, por exemplo. Os bitplanes são organizados por eles mesmos dentro de um framebuffer, que segura toda a informação que os displays de gráficos precisam para controlar a cor e a intensidade de todos os pixels na tela.
Abaixo o que o OpenGL pode parecer. Exemplo renderiza um retângulo branco dentro de um fundo preto e seu código relacionado.
Figura 23: Aparência OpenGL
Fonte: Wesley, 2000
A primeira linha da rotina main() inicializa uma janela na tela. A rotina InitializeAWindowPlease() é destinado como um placeholder para rotinas windows-system-specif, que não são geralmente chamadas do OpenGL. As próximas duas linhas são comandos OpenGL que limpam a janela para preto: glClearColor() estabelece qual cor será usado na janela e glClear() atualmente limpa a janela. Uma vez que a cor é setada, a janela é clareada para aquela cor toda vez que o glColor() é chamada. Este clareamento de cor pode ser mudado com outra função glClearColor(). Similarmente, o comando glColor3f() estabelece qual cor será usada para desenhar os objetos – neste caso, a cor é branca. Todos os objetos desenhados depois deste ponto usará esta cor, até ela ser mudada com outra função para mudar a cor.
O próximo comando OpenGL usado no programa glOrtho() especifica o coordinate system que o OpenGL assume enquanto é desenhado a imagem final e como a imagem é mapeada na tela. As próximas chamadas, que são agrupadas por glBegin() e glEnd() definem o objeto a ser desenhado – neste caso um polígono. Os cantos do polígono são definidos pelo comando glVertex3f().
Finalmente, glFlush() assegura que os comandos desenhados estão realmente sendo executados antes e depois guardados num buffer aguardando comandos OpenGL adicionais. O UpdateTheWindowAndCheckForEvents() controla as rotinas placeholder o conteúdo da janela e eventuais processamentos iniciados.
4.1.5 Sintaxe do Comando OpenGL
Comandos OpenGL usam o prefixo gl e a letra inicial de cada palavra em maiúsculo para formar o nome do comando. Semelhantemente, o OpenGL é definido constantemente começando com GL_, usando todas as letras em maiúsculo e usando underline para separar as palavras.
Também percebe-se que algumas letras aparentemente estranhas estão juntas em alguns nomes de comandos (o 3f no glColor3f()). É verdade que a parte Color no comando é suficiente para definir os comandos como aquele que seta as cores. Entretanto, mais do que um comando é definido, então se podem usar diferentes tipos de argumentos. Em particular, a parte 3 do sufixo indica que três argumentos são dados; outra versão do comando Color recebe quatro argumentos. A parte f do sufixo indica que os argumentos são pontos flutuantes. Ter formatos diferentes permite ao OpenGL aceitar os dados do usuário no seu formato de dados.
Alguns comandos OpenGL aceitam tanto quanto oito tipos de dados para seus argumentos. As letras usadas no sufixo para especificar estes tipos de dados para a implementação do ISO C do OpenGL são mostradas na tabela abaixo, juntamente com a definição do OpenGL correspondente.
Tabela 1: Síntaxe Comando OpenGL
SuffixData TypeTypical Corresponding C-Language TypeOpenGL Type Definitionb8-bit integersigned charGLbyte s16-bit integershortGLshort i32-bit integerint or longGLint, GLsizei f32-bit floating-pointfloatGLfloat, GLclampf d64-bit floating-pointdoubleGLdouble, GLclampd ub8-bit unsigned integerunsigned clearGLubyte, GLboolean us16-bit unsigned integerunsigned shortGLushort Ui32-bit unsigned integerunsigned int or unsigned longGLuint, GLenum, GLbitfield Fonte: Wesley, 2000
Estes dois comandos glVertex2i (1, 3) e glVertex2f (1.0, 3.0) são equivalentes, exceto que o primeiro especifica as coordenadas dos vértices como 32-bit integer e a segunda especifica elas como single-precision floating-point numbers.
Alguns comandos OpenGL podem ter uma letra final v indicando que o comando tem um ponto a um vetor (ou array) de valores antes que uma série de argumentos individuais. Muitos comandos têm ambas as versões vetores e não-vetores, mas alguns comandos aceitam apenas argumentos individuais e outros requerem ao menos que alguns argumentos sejam especificados como vetor.
Finalmente, OpenGL define o tipo de GLvoid. Este é o mais freqüentemente usado para os comandos OpenGL que aceitam pontos para arrays de valores.
4.1.6 OpenGL como uma Máquina Estatal
OpenGL é uma máquina estatal. Coloca-se dentro vários estados (ou modos) que depois permanecem em efeito até serem trocados. A cor, por exemplo, é um estado variável. Pode-se setar a cor em branco, vermelho ou qualquer outra cor, e depois cada objeto é desenhado com aquela cor até ela ser mudada. A cor atual é apenas um dos muitos estados variáveis que o OpenGL suporta. Outros controles semelhantes às atuais inspeção e transformação de projeção, linhas e polígonos de exemplo pontilhados, polígonos desenhando modos e a característica dos materiais dos objetos continha sendo desenhado. Muitos estados variáveis referem-se ao modo que estão habilitadas e desabilitadas com o comando glEnable() ou glDisable().
4.1.7 OpenGL Rendering Pipeline
Muitas implementações do OpenGL tem uma semelhante ordem de operações, uma série de estágios de processamento chamado de OpenGL Rendering Pipeline. Esta ordem, não é uma regra estrita de como o OpenGL é implementado mas providencia um guia de confiança para predizer o que o OpenGL irá fazer.
O diagrama a seguir mostra a reunião de linha próxima de Henry Ford , o qual OpenGL pega para processar dados. Dados geométricos (vértices, linhas e polígonos) seguem a parte através da fila de caixas que incluem avaliadores e operações por vértice, enquanto dados de pixel (pixels, imagens e bitmaps) são tratados diferentemente por parte do processo. Ambos os tipos de dados sofrem o mesmo tipo de passo final (rasterização e operação por fragmento) antes do dado de pixel final seja escrito dentro do framebuffer.
Figura 24: Reunião de linha próxima a Henry Ford
Fonte: Wesley, 2000
4.1.7.1 Display Lists
Todos os dados, quer sejam descritos por geometria ou pixels, podem ser salvas num display list para uso atual ou mais tarde. Quando um display list é executado, o dado conservado é enviado do display list somente se ele for enviado pela aplicação imediatamente.
4.1.7.2 Evaluators
Todos os geométricos primitivos são eventualmente descritos por vértices. Curvas paramétricas e superfícies podem ser inicialmente descritas pelos pontos de controle e funções polinomiais chamados basis functions. Evaluators provêem um método para derivar os vértices usados para representar a superfície dos pontos de controle. O método é um mapeamento polinomial, o qual pode produzir superfície normal, texturas coordenadas, cores e valores coordenados espaciais dos pontos de controle.
4.1.7.3 Operações Per-vertex
Para dados de vértice, o próximo são as “operações per-vertex”, que converte vértice em primário. Alguns tipos de dados de vértices são transformadas pelas matrizes 4 x 4 floating-points. Coordenadas espaciais são projetadas de uma posição no mundo 3D para uma posição na tela.
Se as características avançadas estão habilitadas, esse estágio é mais ocupado. Se a texturização está usada, texturas coordenadas podem ser geradas e transformadas aqui. Se a iluminação está habilitada, os cálculos de iluminação são feitos usando o vértice transformado, superfície normal, posição de busca de luz, propriedade do material e outra informação da iluminação para produzir o valor da cor.
4.1.7.4 Construção primária
Recorte, a maior parte da construção primária, é a eliminação de porções geométricas que caem fora num curto espaço, definido por um plano. Pontos de recortes simplesmente passam ou rejeitam vértices. Linhas ou polígonos recortados podem adicionar vértices adicionais dependendo de como a linha ou polígono está recortada.
Em alguns casos, isso é seguido por uma perspectiva divisão, que faz objetos geométricos distantes parecer menores que os objetos pertos.
4.1.7.5 Operações de pixel
Enquanto dados geométricos pegam um caminho através da renderização pipeline do OpenGL, dados de pixel pegam uma rota diferente. Pixels de um array na memória do sistema são primeiro desempacotados a partir de uma variedade de formatos dentro do próprio número de componentes. Depois os dados são escalados, predisposto e processado por um mapa de pixel. O resultado é fechado e depois também escrito dentro da memória de textura ou enviado para o passo da rasterização.
Se os dados de pixel são lidos de um framebuffer, as operações de transferência de pixels são realizadas. Depois estes resultados são empacotados dentro de um formato apropriado e retornam ao array na memória do sistema.
4.1.7.6 Construção de textura
Aplicações OpenGL podem aplicar imagens de texturas para objetos geométricos para fazer eles parecerem mais reais. Se algumas imagens de texturas são usadas, é sensato colocar eles dentro de objetos de texturas que seja mais fácil trocar entre eles.
Algumas implementações OpenGL tem recursos especiais para acelerar a realização das texturas. Elas podem ser especializadas, uma memória de textura de alto desempenho. Se essa memória está liberada, os objetos de textura podem ser priorizados para controlar o uso destes limitados e valiosos recursos.
4.1.7.7 Rasterização
Rasterização é a conversão de ambos geométricos e dados de pixels em fragmentos. Cada fragmento quadrado corresponde a um pixel no framebuffer. Linha e polígono desenhados, largura da linha, tamanho do ponto, modo sombreado e cálculo de cobertura para suportar ANTIALISING são tomadas em consideração como vértices são conectados em linhas ou os interiores do pixel são calculados para um arquivo de polígono.
4.1.8 Operações Básicas OpenGL
A figura apresentada abaixo dá um diagrama abstrato de alto-nível de como o OpenGL processa dados. No diagrama, comandos entram pela esquerda e processam através do que pode ser conceituado como um processamento de pipeline. Alguns comandos especificam objetos geométricos para ser desenhados, e outros controlam como são guiados durante os vários estágios de processamento.
Figura 25: Processamento de Dados OpenGL
Fonte: Wesley, 2000
4.2 Cg
A linguagem Cg foi criada para tornar possível o controle de shapes, aparências e movimentos de objetos usando programação gráfica direto do hardware com o intuito de tornar extremamente rápido o processamento gráfico (RANDIMA, 2003).
O Cg proporciona aos desenvolvedores uma plataforma de programação fácil de usar e ajuda na criação de efeitos especiais em tempo real com qualidade cinematográfica mais rapidamente. Ele também remove a necessidade de programar os efeitos diretamente em linguagem assembly, ou seja, diretamente no hardware.
Cg significa "C para gráfico." A programação C é uma linguagem popular, inventada na década de 1970. Devido à sua popularidade e de design limpo, C desde o início influenciou várias linguagens de programação. Por exemplo, C + + e Java herdaram a sintaxe e estrutura da linguagem C. A linguagem Cg também baseia-se em C.
Cg é diferente de C, C + +, Java, pois é muito especializada. Ninguém jamais escreverá uma planilha ou processador de texto em Cg. Em vez disso, a capacidade do Cg é de controlar programaticamente a forma, aparência, e resolução de objetos utilizando o renderizador gráfico de hardware. De um modo geral, este tipo de linguagem é chamada de shading language (linguagem de sombreamento). Contudo, Cg pode fazer mais do que apenas sombreamento. Por exemplo, os programas podem executar simulação física, composição, nonshading e outras tarefas.
Um programa em Cg é como uma receita para detalhar a forma de um objeto usando programação via hardware gráfico. Com Cg é possivel escrever um programa para fazer uma superfície aparecem acidentada ou para animar um personagem virtual.
4.2.1 O que é Cg?
A linguagem Cg torna possível controlar a forma, a aparência e movimento dos objetos desenhados usando um hardware programável de gráficos. É casar o controle programático destes atributos com a incrível velocidade e capacidade dos processadores de gráficos de hoje. Antigamente não havia praticantes de computação gráfica, fossem artistas ou programadores, havia muito controle sobre a imagem em tempo real que eles geravam.
Cg providencia desenvolvimento com uma completa plataforma de programação que é fácil de usar e permite a rápida criação de efeitos especiais e experiências de qualidade cinematográfica em tempo real em plataformas múltiplas. Providenciando um novo nível de abstração, o Cg remove a necessidade de desenvolvedores programarem diretamente em linguagem assembly, e por meio disso é mais fácil atingir OpenGL, DirectX, Windows, Linux, Macintosh OS X e plataformas de consoles como o Xbox. Cg foi desenvolvido em junta colaboração com Microsoft Corporation e é compatível com ambos OpenGL API e linguagem HLSL da Microsoft para DirectX 9.0.
Cg é a plataforma “C para gráficos”. A linguagem de programação C é uma linguagem popular e geral objetiva inventada na década de 1970. Por causa dessa popularidade e design limpo, C providenciou o básico para muitas linguagens de programação subseqüente. Por exemplo, C++ e Java basearam usa sintaxe e larga estrutura no C. A linguagem Cg baseou ela mesma no C também.
Uma linguagem para Hardware de programação gráfica Cg é diferente de C, C++ e Java porque é muito especializado. Ninguém jamais irá escrever uma planilha ou palavra no Cg. No lugar, Cg atinge a habilidade de programaticamente controlar a forma, a aparência e o movimento dos objetos renderizados usando um hardware gráfico. Geralmente, esse tipo de linguagem é chamado de shading language. Entretanto, Cg pode fazer mais do que apenas graduar. Por exemplo, programas Cg podem realizar simulações físicas, composições e outras tarefas não gradativas.
Pense no programa Cg como uma receita detalhada para como renderizar um objeto usando hardware de gráficos programáveis. Por exemplo, pode-se escrever uma programação Cg para fazer uma superfície áspera ou para animar um caractere virtual.
4.2.2 Modelo de Fluxo de Dados Cg
Em adição ao que tem sido especializado para gráficos, Cg e outras linguagens shading são diferentes das linguagens de programações convencionais porque são baseadas em um fluxo de dados no modelo computacional. Neste tipo de modelo, a computação ocorre em resposta ao fluxo de dados do começo ao fim de uma seqüência de passos de processamento.
Programas Cg operam em vértices e fragmentos (pixels) que são processados quando uma imagem é renderizada. Pense no programa Cg como uma caixa preta a qual vértices ou fragmentos fluem num lado, são de alguma forma transformados, e passam a fluir no outro lado. Entretanto, a caixa não é realmente preta porque se tem que determinar, significa que a programação Cg que se escrevem é exatamente o que acontece dentro.
Sempre que um vértice é processado ou o rasterizer gera um fragmento enquanto renderiza uma cena 3D, o vértice ou fragmento correspondente executa uma programação Cg.
Os computadores pessoais mais recentes – e todos os consoles de jogos recentes – contêm uma unidade de processamento de gráfico (GPU – Graphic Processing Unit) que é dedicado aos gráficos tarefas desta maneira transformando e rasterizando modelos 3D. A programação Cg atualmente é executada dentro do GPU do computador.
4.2.3 Especialização GPU e Generalização CPU
Quer ou não um computador ou console de jogos tenha um GPU, precisa haver uma CPU que rode o sistema operacional e os aplicativos. CPU’s são, por design, de propósito gerais. CPU's executam aplicações escritas em linguagens propósito-geral, como C++ e Java.
Por causa do design especializado das GPU’s, e as tarefas de gráficos são muito mais rápidos, como renderizar cenas 3D, então uma CPU geral deveria ser. Novas GPU’s processam dez milhões de vértices por segundo e rasterizam cem milhões ou até mesmo bilhões de fragmentos por segundo. GPU’s do futuro serão ainda mais rápidas. Isto é completamente rápido que à proporção que uma CPU pode processar um número similar de vértices e fragmentos. Porém, a GPU não consegue executar os mesmos programas arbitrários que uma CPU pode.
A alta-performance natural especializada do GPU é a causa do Cg existir. Linguagens gerais de programação são tão ilimitadas para tarefas especializadas de processamento de vértices e fragmentos. Neste contraste, a linguagem Cg é totalmente dedicada a esta tarefa. Cg também providencia um modelo de execução abstrata igualmente ao modelo de execução abstrata do GPU.
4.2.4 A Execução da Análise Racional para Cg
Para sustentar a ilusão de interatividade, uma aplicação 3D precisa manter uma média de animação de 15 ou mais imagens por segundo. Geralmente se considera 60 ou mais frames por segundo para ser “tempo real”, a média a cada interação com as aplicações parecem ocorrer instantaneamente. Os displays dos computadores podem ter um milhão ou mais de pixels que requerem redesenhar. Para cenas 3D, o GPU tipicamente processa todos os pixels na tela muitas vezes para como os objetos fecham cada um, ou para improvisar a aparência de cada pixel. Isso significa que o tempo real das aplicações 3D pode exigir cem milhões de pixels atualizados por segundo. Juntamente com o processamento de pixel exigido, modelos 3D são compostos de vértices que precisam ser transformadas corretamente antes de serem reunidas dentro de polígonos, linhas e pontos que serão rasterizados dentro dos pixels. Isso pode exigir transformação de dez milhões de vértices por segundo.
Além do mais, esse processamento gráfico acontece juntamente ao considerável valor de esforço requerido da CPU para atualizar a animação para cada imagem. A realidade é que se precisa de CPU e GPU especializado de gráficos orientados capacitados. Ambos são requeridos para renderizar cenas na interatividade proporcional e qualidade padrão que usuários de aplicações 3D e jogos demandam. Isso significa que um desenvolvedor pode escrever uma aplicação 3D ou jogo em C++ e depois usar Cg para utilizar o máximo da força dos gráficos da GPU.
4.2.5 Coexistências com Linguagens Convencionais
De nenhum jeito Cg substitui qualquer linguagem geral existente. Cg é uma linguagem auxiliar, designada especificamente para GPUs. Programas escritos para CPU em linguagens convencionais como C ou C++ podem usar o runtime do Cg para rodar programas Cg para as GPUs executarem. O runtime do Cg é um padrão de grupos de sub-rotinas usadas para rodar, compilar, manipular e configurar programas Cg para execução pelo GPU. Aplicações fornecem programas Cg para instruir GPUs em como executar o programável efeito renderizado que de outra forma não seria possível numa CPU na proporção renderizada que uma GPU é capaz de realizar.
Cg permite um especializado estilo de processamento paralelo. Enquanto a CPU executa uma aplicação convencional, uma aplicação também orquestra o processamento paralelo de vértices e fragmentos no GPU, pelos programas escritos em Cg.
4.2.6 Outros Aspectos do Cg
Cg é uma linguagem de programação “pequena”. Ela torna muito mais simples que uma moderna linguagem geral de programação como C++. Porque Cg especializa transformando vértices e fragmentos, isso não inclui muitas das características complexas requeridas por um software sólido de tarefas de engenharia. Diferente de C++ e Java, Cg não suporta classes e outras características usada em programação orientada ao objeto. A atual implementação do Cg não providencia pontos ou até mesmo alocação de memória. Cg tem absolutamente nenhum suporte para arquivos de operações de entrada/saída. Em geral, estas restrições não são limitações permanentes na linguagem, mas preferivelmente são indicativos de capacidades do mais alto desempenho dos GPUs atuais. Como os avanços da tecnologia permitem uma programabilidade mais geral no GPU, pode se esperar do Cg crescer apropriadamente. Devido ao Cg ser ligado intimamente ao C, futuras atualizações do Cg são aptas para adotar características de linguagens do C e C++.
Cg providencia arrays e estruturas. Também providencia toda a construção flow-control de uma linguagem moderna: loops, condicionais e chamada de funções.
Cg originariamente suportava vetores e matrizes porque esses tipos de dados e as operações matemáticas relacionadas são fundamentais para gráficos e muitos hardwares de gráficos suportam diretamente tipos de dados em vetor. Cg tem uma biblioteca de funções, chamada Standard Library, que é bem apropriado para o tipo de operações requeridas para gráficos.
Programas Cg executam em relativa isolação. Isso significa que o processamento de um particular vértice ou fragmento não tem efeito algum sobre outros vértices ou fragmentos processados no mesmo tempo. Não tem nenhum efeito a execução de um programa Cg. Essa falta de interdependência entre vértices e fragmentos faz os programas Cg extremamente bem apropriados para a execução do hardware pelo alto pipeline e hardware paralelo.
4.2.7 A Execução Limite em torno dos Programas Cg
Quando se escreve um programa numa linguagem designada para uma CPU moderna usando um moderno sistema operacional, se espera mais do que um programa arbitrário mais ou menos, contanto que correto, irá compilar e executar propriamente. Isto é devido as CPU’s, pelo design, executar programas gerais para que em todo o sistema tenha mais do que recursos suficientes.
Entretanto, GPUs são especializados antes de programas gerais, e o grupo característico de GPUs ainda está evoluindo. Nem tudo que se escreve no Cg pode ser compilado para executar em um determinado GPU. Cg inclui o conceito de hardware “perfis”, um do qual será especificado quando compilar um programa Cg. Cada perfil corresponde a uma particular combinação de arquitetura GPU e gráficos API. O programa não somente precisa estar correto como também precisa limitar ele mesmo para as restrições impostas pelo perfil particular usado para compilar o programa Cg.
Como GPUs se desenvolvem, perfis adicionais serão suportados pelo Cg que corresponde a mais capacidade de arquiteturas GPU. No futuro, perfis serão menos importantes como GPUs serão totalmente mais característicos. Mas por enquanto programadores Cg terão necessidade de limitar os programas para assegurar que eles podem compilar e executar nos GPUs existentes. Em geral, perfis futuros serão super grupos de perfis correntes, então os programas escritos para os perfis atuais serão compilados sem mudança usando perfis futuros.
Essa situação soa meio limitada, mas na prática os programas Cg trabalham em dez milhões de GPUs e produzem efeitos renderizados submetidos. Outra razão para limitar o tamanho do programa e SCOPE é que quanto menor e mais eficiente o programa Cg for, mais rápido ele rodará. Gráficos em tempo real são apresentados freqüentemente sobre o balanço do aumento da complexidade da cena, padrão de animações e proteção melhorada. Isso é sempre bom para maximizar a eficiência renderizado através de programação Cg prudente.
As restrições impostas pelos perfis são realmente limitações dos GPUs atuais, não do Cg. A linguagem Cg é poderosa o suficiente para expressar técnicas de proteção que ainda não são possíveis com todo o GPU. Com o tempo, as funcionalidades do GPU irão envolver tão suficiente que os perfis Cg estarão aptos para rodar programas Cg surpreendentemente complexos. Cg é uma linguagem para GPUs presentes e futuros.
4.3 DIRECTX
Segundo McCuskey (2002), a Microsoft criou a primeira versão do DirectX para migrar os desenvolvedores do MS-DOS para o Windows. Antes disso a Microsoft tinha grandes problemas com a limitação e capacidade gráfica e acesso a som diretamente, acarretando muita lentidão para os jogos e alguns aplicativos. E esse foi o objetivo inicial quando a Microsoft criou o DirectX, proporcionar um acesso rápido e direto ao hardware.
Outro beneficio do DirectX é fazer com que qualquer dispositivo de hardware seja acessado indiferente da sua marca ou configuração.
4.3.1 A Arquitetura do DirectX e o Temido COM
GDI (Gradphics Device Interface) é muito lento para criar ação nos jogos em tempo real. Claro, pode-se escrever um jogo de aventura, ou um jogo de cartas, mas é só isso. É por isso que o DirectX foi criado: para dar à programação de PC as ferramentas necessárias para escrever jogos reais e outras aplicações multimídias que concorrem com a performance das aplicações em DOS32.
Figura 26: Alta-performance suportada pelo DirectX
Fonte: LaMothe, 1998
DirectX cumpre o sonho de um baixo nível API que é integrado facilmente com o Windows e o API Windows32. Usando DirectX, pode-se acessar vídeo, áudio, informações de equipamento, e capacidades de rede sem escrever uma linha de GDI ou usando a biblioteca standard do Win32. E se usar o DirectX para trabalhar com qualquer um destes sistemas, não haverá conflitos com o GDI, Windows ou Win32.
Para DirectX funcionar, um número de susbsystems, assim como COM e Win32API precisam se comunicar entre si. Em adição, DirectX tem mais componentes do que simplesmente DirectDraw.
Windows é um compartilhado e cooperativo sistema operacional multi-tarefas, o que significa que todas as aplicações precisam compartilhar tantos recursos quanto o mouse, o display de vídeo, a placa de som, e ficarem ligados. Vídeo Games pela sua natureza quebram esta regra. Um jogo usualmente pega sobre tudo, e por causa da necessidade do jogo por um alto desempenho, tipicamente pode-se rodar um jogo por vez.
DirectX dá um atalho ao hardware sem precisar ir através dos canais normais do Windows. DirectX é uma série de Dynamic Link Libraries (.DLLs), e baixo nível dos equipamentos de drivers que tem a habilidade de controlar todos os aspectos do PC sem muita ajuda do GDI ou da biblioteca standard do Win32. E para criar uma aplicação DirectX, tudo que precisa são os arquivos de leitura, a biblioteca DirectX e as .DLLs na máquina. Então se pode pensar no DirectX como uma biblioteca add-on que tem todas essas capacidades.
Figura 27: Biblioteca DirectX
Fonte: LaMothe, 1998
DLLs são o básico para muito do Windows. Eles permitem as bibliotecas de software rodar na demanda e serem compartilhados por outros aplicativos. Em adição, DLLs podem ser UPGRADED e restauradas sem recompilar ou parar a aplicação que elas usam, assim como .DLLs continuam implementando as funcionalidades das versões anteriores.
Entretanto, DirectX é muito mais que uma biblioteca. É um grupo de padrões e filosofias que outros softwares e hardwares estão seguindo. Neste momento todos os softwares das empresas são escritos nas aplicações DirectX, e todos os hardwares fabricados têm drivers DirectX escritos para seus hardwares. O resultado é uma maçante infra-estrutura que se pode contar de hoje para o futuro.
Para fazer a mágica da tecnologia do DirectX funcionar, Microsoft teve que criar algumas novas técnicas e regras para fazer o DirectX mais robusto. Em outras palavras, um jogo escrito pelo DirectX 1.0 precisa estar apto para rodar em um computador que tenha o DirectX 3.0 ou o DirectX 6.0 instalado. Além disso, a Microsoft sabia que uma tecnologia como o DirectX escaparia das mãos muito facilmente se fosse escrita sem uma grande de precisão e planejamento. O que foi necessário foi um jeito de escrever um software que fosse orientado a objeto, atualizável, capaz de trabalhar com múltiplas linguagens e caixas pretas – como o programador. A resposta para isso chama Component Object Model – COM.
4.3.2 O que é COM?
COM – Component Object Model – é uma tecnologia inventada há alguns anos atrás como nada mais que um depósito de artigos que descreve um conjunto de técnicas de programação para criar componentes de software, muitas como os chips de computadores. O mais legal de usar chips digitais, é que o chip tem uma série de entrada e de produção. Quando se desenha com chips digitais, não precisa se preocupar com o que tem dentro do chip, quer seja SILICON ou pequenos ELVES. Tudo o que precisa se preocupar é em seguir as regras da interface do chip, o funcionamento do chip.
Figura 28: Tecnologia de chips digitais
Fonte: LaMothe, 1998
Além disso, se conectar o OUTPUT de um chip com o outro, e enquanto os INPUTS e OUTPUTS estiverem no formato certo, os chips trabalharam juntos. Esta analogia é a base para componentes de softwares e COM. A idéia do COM é criar componentes de software que são como os chips, ou blocos de Lego, que se pode somente plugar todos juntos. Enquanto eles seguirem as regras, eles funcionarão.
Essa coisa é boa na teoria, mas um software é geralmente confuso.
COM é um conjunto de técnicas e convenções para criar componentes de softwares reutilizáveis que funcionam com qualquer linguagem e tem o sentido dos chips do computador ou dos blocos do Lego. A principal vantagem é que os objetos COM são trocáveis e melhoráveis sem recompilações.
Supõe que uma engenharia de software criou uma aplicação que usa um objeto COM específico. Ela envia a aplicação à diante com o objeto COM (que é usualmente implementada numa DLL) e os usuários rodam a aplicação em suas máquinas e usam-na.
Depois a engenharia de software decide que ela quer adicionar algumas capacidades a mais, mas não quer RECHIP o produto todo. Com COM, ela não precisa RECHIP toda a aplicação. O novo objeto COM com as implementações alteradas é baixado pelo usuário, e imediatamente – a aplicação está pronta. Essa situação é possível porque os objetos COM são rodados dinamicamente pela aplicação do cliente que as usa, então se pode criar uma aplicação que tem um número de objetos e depois repor elas com a mais nova, objetos COM mais atualizados.
Figura 29: Atualizando com COM
Fonte: LaMothe, 1998
Como exatamente se faz um objeto COM? Um objeto COM é exatamente uma classe C++ que contém um número de interfaces. Estas interfaces são puras e virtuais e precisam ser implementados num conteúdo de classes. Cada interface contém funções que os objetos COM suportam, então um objeto COM pode ter uma ou mais interfaces que podem se comunicar e chamar funções diretas.
Figura 30: Composição de um objeto COM
Fonte: LaMothe, 1998
Uma interface pode conter métodos para desenhar objetos, outras interfaces podem conter métodos para fazer sons, e assim por diante. Mas cada interface é uma classe virtual pura que se pode criar somente um template para sua definição.
Existem muitos jeitos de implementar um grupo de interfaces e depois incluir todas num conteúdo de classes, mas a especificação COM dita exatamente como precisa fazer essa implementação e inclusão. Além do mais, as especificações COM explica exatamente como uma aplicação cliente pode se comunicar com um objeto COM, como criar um objeto COM, como destruir um, e assim por diante. Neste caso, as especificações COM explicam todos os detalhes da implementação e tudo que se precisa fazer é criar todas as interfaces e os códigos que vão com elas.
Finalmente, porque os objetos COM são dinamicamente linkáveis, precisa-se usar algo como uma .DLL que contenha eles. Não precisa fazer, mas este método é o caminho mais fácil. Também, porque os objetos COM precisam trabalhar em qualquer linguagem, eles tem uma especificação binária exata, o que significa que se precisa ter certeza que a compilação criou o código binário exato que um compilador padrão Windows C++ faz quando cria uma classe virtual.
Outra versão do COM, chamada DCOM (Distributed COM), é eventualmente mais avançado que o COM e permite usar não somente componentes na própria máquina mas também componentes em outras máquinas sobre uma rede.
4.3.3 Os Componentes do DirectX.
Os vários componentes do DirectX procura dentro de cada aspecto do design do Video game – gráficos, sons, entradas, 3D e rede.
A figura 31 ilustra todos os componentes DirectX e suas relações com o Win32, GDI e o hardware. Note que o GDI e o DirectX estão em diferentes lados: Cada um tem acesso ao outro e ao hardware. Os blocos do DirectX chamam HAL (Hardware Abstraction Layer) e HEL (hardware Emulation Layer) também é muito importante.
Figura 31: DirectX e seus componentes
Fonte: LaMothe, 1998
4.3.3.1 HAL: Hardware Abstraction Layer
O hardware de camadas abstratas (Hardware Abstraction Layer – HAL) é o mais baixo nível de software no DirectX, consistindo de drivers de hardware abastecido pelo produtor para controlar o hardware diretamente. Estas camadas de software dão o máximo de performance porque fala diretamente com o hardware.
4.3.3.2 HEL: Hardware Emulation Layer
O hardware de emulador de camadas (Hardware Emulation Layer – HEL) é desenvolvido no topo do HAL. Em geral, DirectX é designado para levar vantagem do hardware se o hardware está lá, mas o DirectX ainda trabalha se o hardware não está disponível. Por exemplo, supõe-se que se escreva algum código de gráfico, na hipótese de o hardware estar rodando na rotação e escala bitmap suportadas. No hardware que suporta escala e rotação, o código roda em toda a velocidade e usa o hardware, mas se rodar em um hardware que não suporta escala e rotação, então o HEL participa. O HEL emula a funcionalidade do HAL com um software de algoritmos que não se percebe a diferença. Claro que o código roda mais lento porque está sendo emulado, mas roda. Esta é a razão para o HEL. Alguns programadores examinam o hardware, vêem exatamente quão capazes estão, e talvez usem suas próprias rotinas em vez daquelas proporcionadas no DirectX HEL.
4.3.3.3 DirectDraw
DirectDraw é provavelmente o único componente mais importante do DirectX. É permitido acessar o cartão de vídeo, juntamente com s vários hardware de aceleração de capacidade. Além disso, DirectDraw sabe como iniciar todos os modos de vídeo individuais que se possa querer, mesmo em alta resolução e modos True-Color. E DirectDraw tem suporte para sistema de cores, clipping e animação.
4.3.3.4 Direct3D
Este componente do DirectX é o único link entre o programador e o hardware 3D. Direct3D permite usar um padrão API para comunicar e usar qualquer hardware 3D que se pode plugar no computador, de uma forma uniforme. O API é baseado num mecanismo de gráficos criado por uma empresa chamada Rendemorphics (Microsoft comprou o mecanismo), então o API não é de fato novo.
4.3.3.5 DirectSound
DirectSound é uma das grandes coisas na Terra. Escrever drivers de sons para PC é quase impossível. Não pode somente conservar todos os sons num cartão fora, então escrever sons é um trabalho full-time. No passado, muitos programadores de jogos licenciavam seus mecanismos de sons de um terceiro grupo, como John Miles Sound System ou Diamondware Sound Toolkit. E estes mecanismos de sons não eram baratos, mas com o DirectSound esta situação não é mais assim.
DirectSound trabalha com todos os cartões de som. Suporta uma mistura digital pura de múltiplos canais em tempo real. A nova versão do DirectSound suporta música MIDI. Mas MIDI vem morrendo lentamente, agora a digital pura é qualidade em CD e a memória tem se tornado tão barata. Em contramão, novos sintetizadores wave-table e wave-guide estão fazendo um MIDI voltar, então suportar MIDI é satisfatoriamente seguro de compatibilidade.
4.3.3.6 DirectSound3D
DirectSound3d é baseado no DirectSound e é uma implementação do som 3D. A teoria por trás do som 3D é que se pode simular como um objeto real poderia soar em qualquer posição no espaço enquanto se controla a entrada em cada ouvido. Controla-se a entrada trocando a freqüência do som e suas amplitudes, harmonia e cronometragem baseado num modelo matemático de como o som interage com a geometria da cabeça juntamente com como viaja através do espaço.
4.3.3.7 DirectInput
DirectInput foi uma adição muito esperada para o DirectX. Em lançamentos antecipados do DirectX, entrada foi realizada usando Windows e Win32 API. Mas agora, com a versão 3.0, DirectX suporta DirectInput, que permite um programa adquirir dados do teclado, mouse e joystick de uma maneira uniforme. E na versão 5.0, DirectInput suporta serviços Force Feedback – joysticks que vibram.
4.3.3.8 DirectPlay
DirectPlay é provavelmente o menos utilizado de todos os componentes DirectX porque é muito mais difícil de entender do que os outros. DirectPlay é uma rede suportada para jogos. É um grupo um pouco forte de funções e sistemas que permite escrever um código de rede para conexões diretas, locais e internet para jogos sem toda aquela dor de cabeça de usar Winsock ou o próprio código.
Infelizmente, DirectPlay leva mais tempo para aprender do que todos os outros componentes DirectX combinados, mas é bem pior o tempo investido se pretende-se escrever um jogo de rede.
4.3.3.9 DirectSetup e AutoPlay
Estes dois componentes não são de fato objetos do DirectX. DirectSetup é um simples API que se usa para instalar e iniciar o DirectX e o jogo nas máquinas. AutoPlay é o padrão que o Windows suporta para CDs rodarem automaticamente quando eles são colocados nos leitores das máquinas. Microsoft provavelmente quis chamar AutoPlay DirectPlay, mas já foi usado para redes.
4.3.4 Interfaciando com Interfaces
DirectX é implementado como um número de componentes, cada um com um número de interfaces. Para usar i DirectX, precisa-se entender um pouco sobre o que acontece com COM e interfaces – esse entendimento torna o uso do DirectX muito mais fácil nos casos onde tem-se que criar sobrecapas ao redor de todo o DirectX COM.
Um componente consiste de uma ou mais interface. Cada interface é como uma porta de comunicação que precisa ser usada para chamar as funções dentro da interface. Todas as interfaces são derivadas do ROOT interface I Unknow.
GUIDs e IIDs são números especiais que são muito grandes (128 bits) e garantem ser únicos de cada um. Cada objeto COM em existência precisa ter seu próprio GUID ou IID. Em adição, nenhum IID pode ser o mesmo. Então uma vez publicado (distribuído no mundo) um objeto COM com um número de interfaces, cada interface precisa ter seu próprio IID. Estes números são gerados com um programa Microsoft-supplied (com muitos compiladores) chamado GUIDGEN.EXE, que matematicamente garante que nunca irá reproduzir dois GUIDS idênticos. Basicamente, usar GUIDs é um jeito de nomear objetos COM e interfaces unicamente.
Figura 32: Interface COM
Fonte: LaMothe, 1998
I Unknown é a base de classe que todos as interfaces devem derivar. Conseqüentemente, todas as interfaces devem implementar ao menos QueryInterface(), Addref() e Release().
QueryInterface(): Usado para solicitar uma indicação de para a interface de interesse. Precisa passar uma IID interface adiante com uma indicação para assegurar que a interface retorne da função. O único jeito de conseguir acesso para uma interface é através deste método. Isso precisa ser feito uma vez apenas, quando o DirectX não tem a função sobrecapas ou macro para fazer isso sozinho.
Addref (): Reforça o contagem de referência interna do objeto COM. Todos os objetos COM alocam e deslocam eles mesmos através da contagem de referência. Quando um objeto é criado, é desenvolvida uma referência de contagem. Quando a referência de um objeto não é mais necessária, a referência de contagem é diminuída. Deste modo, pelo rastreamento de uma contagem de referência de um objeto podem-se detectar quantos outros objetos estão usando eles. Quando essa contagem for igual a zero, o objeto não está mais em uso e pode ser deletado. Addref() não precisa ser usado nunca, ele é chamado internamente pelos outros objetos COM.
Release (): Diminui a contagem de referência de um objeto COM – um método muito importante que se usa o tempo todo depois que se termina de usar uma interface ou componente.
Abaixo como usar I Unknown para criar algumas interfaces:
Figura 33: I Unknown para criar interface
Fonte: LaMothe, 1998
4.4 XNA
XNA é desenvolvido pela Microsoft e foi iniciado há alguns anos atrás, mas mantido em segredo absoluto. Na GDC (Game Developers Conference – a maior conferência anual de desenvolvedores de jogos) em 2004 a Microsoft anunciou o XNA pela primeira vez. XNA não é simplesmente um framework como o DirectX, ele também contem muitas ferramentas e eventualmente uma customização IDE derivada do visual Studio para facilitar o trabalho do programador. Devido a nenhuma ferramenta ou bits terem sido exibidos até 2006, desenvolvedores de DirectX apenas noticiaram o logo “XNA” no canto de cima direito do DirectX SDK.
Isso significa que a Microsoft trabalhou no framework XNA por um tempo, mas os desenvolvedores não sabiam o que esperar. Poderia ser o sucessor do framework DirectX, mas quando o Direct3D 10 Beta para Windows Vista foi lançado no final de 2005, parecia que o DirectX ainda era o framework de gráficos preferido mesmo para este novo sistema operacional. Depois no começo de 2006 na GDC o Microsoft XNA Build March 2006 CTP foi lançado. XNA Build é uma ferramenta que permite gerenciar complexos processos de build, similar ao Msbuild e ferramentas como Ants, porém mais complexa e poderosa.
Contudo, não é apenas o XNA e sua facilidade de desenvolver que realmente interessam e sim sua portabilidade para o Xbox 360 e sua biblioteca de códigos livres que a Microsoft disponibiliza, sem falar que para disponibilizar seu jogo em Xbox 360, basta se cadastrar no Creators Club e pagar uma taxa anual de U$ 99.
Depois isso foi mantido em segredo por um tempo e somente o pessoal da Microsoft e DirectX MVPs sabiam sobre o próximo XNA Framework e lançamento do XNA Game Studio. O resto do mundo descobriu sobre aquilo na conferência Gamefest em agosto, onde Microsoft anunciou o lançamento do XNA Game Studio Express beta 1 em 30 de agosto de 2006. O primeiro beta somente continha um kit inicial, “Space Wars”, e o XNA não incluiu muitas funcionalidades 3D.
5 Características da Tecnologia XNA
Esse capítulo pretende descrever a tecnologia XNA e suas origens, bem como descrever suas características e vantagens em comparação as outras tecnologias.
XNA Game Studio foi inicialmente centralizado nos iniciantes, hobbyists e estudantes para permitir a eles desenvolver rapidamente seus próprios jogos para as plataformas Windows e XBOX 360. Mas isso não significava que profissionais não pudessem usar o XNA ainda. Uma versão especial do XNA Game Studio Professional foi direcionado para profissionais de jogos no verão de 2007.
Segundo Cawood (2007), para todos os desenvolvedores de XBOX 360, o XNA fez o maior progresso ma programação de jogos no mundo. Antes do XNA era muito complicado e custoso para um estudante, hobista ou desenvolvedor independente de jogos ter acesso a kit de desenvolvimento de console. O XNA possui uma IDE própria para desenvolvimento, o XNA Game Studio Express que é uma extensão do Visual C# Express, as duas ferramentas são gratuitas, ou seja, o usuário tem a possibilidade desenvolver um jogo sem custo algum.
Segundo Klucher (2006) o conteúdo é uma grande parte dos jogos de hoje, e gerenciar o conteúdo em jogos não é fácil, na verdade, é frustrante. Normalmente um dos problemas enfrentados é procurar por um exportador ou a ferramenta certa para apoiar esse exportador. Também é preciso encontrar algumas ferramentas para processar o conteúdo, e utilizar essas ferramentas para criar os dados para o seu jogo. Outro fator é se preocupar com o carregamento dos conteúdos e fazer todo o trabalho necessário para obter o conteúdo exibido corretamente no jogo.
Com o XNA Framework Content Pipeline, o processo é diferente e melhorado. É mais simples de usar, é altamente personalizável e extensível ao que se está fazendo, e isso fornece escolhas ao colocar o jogo em conjunto, tanto nas ferramentas usadas para criar conteúdo quanto no motor usado. Klucher afirma que não é muito empolgante construir infra-estruturas jogo conteúdo quando o que se realmente deseja fazer é concentrar-se no jogo. O XNA Framework ContentContent Pipeline permite fazer isso. Foco no desenvolvimento do jogo.
5.1 XNA Game Studio Express
A janela não parece apenas similar ao Visual C# 2005 Express, realmente é apenas isso. Existem apenas algumas mudanças mínimas para as configurações de um projeto XNA. Existe também uma opção extra em Ferramentas > Opções, que permite selecionar o projeto Xbox 360 e entrar com a chave criptográfica. Adicionalmente, há algumas características novas dentro do IDE, o conteúdo pipeline que permite importar texturas, modelos e sombreamentos muito rápidos para dentro do projeto.
XNA Game Studio Express é atualmente a única IDE disponível para desenvolvimento de jogos com o XNA Framework, mas a Microsoft lançará em breve o XNA Game Studio Pro. Também é bom lembrar que a única linguagem de desenvolvimento é o C#. Porém existe um modo de utilizar o XNA com o Visual Studio 2005, mas não recomendado pela Microsoft.
O XNA Game Studio Express é um add-on do C# Express e é necessário ter o Service Pack 2 do Windows, o .NET Framework 2.0, processador de 1GHz, mais de 512MB de RAM, e o mais importante, uma placa de vídeo com Shader Model 1.1 ou superior.
5.2 Modelo de Aplicação
O FRAMEWORK DO XNA É DIVIDIDO EM TRÊS PARTES ESSENCIAIS.
XNA GRAPHIC ENGINE;
XNA GAME APPLICATION MODEL;
XNA CONTENT PIPELINE;
Figura 34: Modelo da aplicação do XNA
Fonte: Nitschke, 2007
Todas estas DLLs são escritas em C# e podem ser facilmente exploradas usando a ferramenta Reflector (ROEDER disponível em: .). Algumas destas DLLs são apenas chamadas para as DLLs do DirectX para simplificar um pouco a estrutura.
Reflector (ROEDER Disponível em: .). Algumas destas DLLs são apenas chamadas para as DLLs do DirectX para simplificar um pouco a estrutura.
Cada projeto do XNA usa a classe Game que contém todos os componentes necessários. São eles: dispositivo gráfico (graphic device), gerenciador de conteúdo (content manager) e configuração da aplicação (windows settings).
A classe Game contém três métodos essenciais para o projeto, a Microsoft adicionou mais dois métodos (LoadGraphicsContent e UnloadGraphicsContent) na classe Game em sua versão final, que são criados automaticamente, mas não serão abordados por que servem mais para jogos que possuem uma estrutura mais simples.
Figura 35: Classe do jogo criada pelo XNA.
Fonte: Nitschke, 2007
O método Initialize carrega todo o conteúdo do jogo seta todas as configurações iniciais e inicia tudo o que for preciso. Se no caso for usada a modelagem que a Microsoft preparou para o XNA, todo o conteúdo deve ser iniciado no método LoadGraphicsContent.
O método Update atualiza todo o conteúdo que nele estiver. Ele é sempre chamado logo após cada frame. Mas não necessariamente depende desta chamada, o método Update é independente do resto da aplicação.
O método Draw tem como objetivo gerenciar todo o conteúdo gráfico. É neste método que todo o conteúdo gráfico será desenhado e atualizado sempre que for preciso.
A separação destes dois métodos (Update e Draw) não parecem afetar muito o desempenho do jogo no Xbox 360, mas no computador onde o usuário pode minimizar o jogo toda hora e o jogo precisa continuar executando mesmo que o método Draw não seja mais chamado.
5.3 Content Pipeline
O Content Pipeline é usado para compilar, importar e carregar recursos como texturas, shaders, modelos 3D e arquivos de sons. Ele procura e adiciona automaticamente os recursos sem precisar importar e transformar em um arquivo binário.
Ao importar um modelo não é preciso compilar o projeto para verificar se o modelo contém erros ou não, o XNA se encarrega da tarefa.
O Content Pipeline não é apensa uma DLL, ela é formada por cinco sub-divisões, são elas:
Microsoft.Xna.Framework.Content.Pipeline.dll: contém as funções básicas do Content Pipeline.
Microsoft.Xna.Framework.Content.Pipeline.EffectImporter.dll: usado para compilar e importar shaders.
Microsoft.Xna.Framework.Content.Pipeline.FBXImporter.dll: é a maior das DLLs e contém inúmeras funções para importar modelos no formato .fbx e possui funcionalidades como skining e bones, bastante usadas em jogos 3D.
Microsoft.Xna.Framework.Content.Pipeline.TextureImporter.dll: é a DLL responsável por importar todas as texturas 2D. Usando as texturas em formato dds ( formato usado pelo DirectX ) se obtém uma performance ainda melhor, mas também suporta os formatos .png, .jpg, .bmp e .tga.
Microsoft.Xna.Framework.Content.Pipeline.XImporter.dll: usada para importar os modelos 3D no formato .x
Segundo Klucher (2006), com o XNA Framework Content Pipeline, o conteúdo é gerido dentro Visual C# Express. Portanto, da mesma maneira que é possível acrescentar arquivos de código hoje, é possível adicionar o conteúdo também. Isso ajuda a manter as coisas em conjunto e permite-lhe organizar todo o jogo em uma solução.
XNA Framework Content Pipeline é composto por diferentes componentes. Esses componentes são responsáveis para a importação e manipulação de qualquer tipo de conteúdo que esteja relacionado com o Content Pipeline.
Ao adicionar um conteúdo é preciso selecionar um importador. Segundo Klucher o importador é responsável pelos dados e normalização do conteúdo. Isto significa que você não precisa se preocupar com, por exemplo, qual direção o conteúdo está apontando, ou que maneira é instituído o conteúdo na ferramenta de criação. O importador assume os arquivos salvos o seu conteúdo ou exporta a partir de ferramentas para criação e importação dentro do Visual C# Express.
Figura 36: Formatos do Content Pipeline
Fonte: Microsoft, 2008
Segundo Klucher (2006), a maior parte desses importadores são bem conhecidos, e um deles é o Autodesk FBX. FBX é um formato de transporte de arquivo 3D que permite transportar dados em uma cena 3D para muitas outras ferramentas de criação.
Após a importação dos objetos, os dados são alocados no conteúdo chamado DOM. DOM é o termo usado para representar uma coleção de classes ou de um esquema (como um arquivo XML). Isso significa que os dados são representados em um formato conhecido, assim, por exemplo, uma série de vértices ou textura de dados são tratados da mesma maneira não importando de onde ele veio.
Segundo Klucher(2006) um processo é responsável pela tomada de dados a partir do conteúdo DOM. Com isso o conteúdo pode ser usado em tempo de execução. O conteúdo armazenado pelo DOM contém informações especificas para formar todos modelos do jogo em objetos com funções que auxiliamo gerenciamento do jogo.
Os processos são chamados de dentro do conteúdo DOM e este processo trabalha de forma independente do formato do arquivo. Isso por que todo conteúdo é armazenado com um formato igual. O que permitem manipular e gerar novos dados a partir do conteúdo DOM.
Todo o conteúdo referenciado no projeto do jogo, fica disponível e pronto para uso em tempo de execução. Todas as alterações feitas em texturas podem ser substituídas e atualizadas sem precisar construir o projeto novamente.
Segundo Klucher(2006) a ferramenta responsável por fazer todo o caminho de volta é o Content Manager. Que por sua vez converte novamente todo conteúdo para o tipo do objeto em questão(Figura 26).
Figura 37: Fluxo de conteúdo
Fonte: Microsoft, 2008
5.4 XNA Audio Creation Tool (XACT)
Segundo Nitschke (2007), o XACT era uma ferramenta apenas para o XBOX 360 e era preciso ser um desenvolvedor certificado para ter acesso ao XDK( Xbox Development Kit) para usa-lo, sem falar de sua alta complexibilidade. Até mesmo os desenvolvedores de jogos com bastante experiência tinham que estudar bastante para desenvolver em cima do XDK.
Mas tudo isso mudou e a Microsoft resolveu adicionar o XACT dentro do DirectX SDK, tornando uma ferramenta importante para o XNA. Com isso também não é mais necessário a instalação do DirectX SDK para acessar o XACT, pois o XNA instala automaticamente a ferramenta.
Existem outras versões do XACT lançadas antes de outubro de 2006 que podem não funcionar corretamente caso um projeto seja aberto ou convertido para esta versão. No caso, a versão em questão é a 13, outras versões como a 11 e 12 podem não ter suporte a algumas funcionalidades. A versão 13 também é representada pela Content Version 41 no about do XACT, como mostra a figura.
Figura 38: Versão do XACT
Fonte: Autor, 2008
Nitschke explica que no desenvolvimento do jogo usando o XACT, o desenvolvedor não precisa se preocupar muito com algumas propriedades como, volume e formato do som, essa função fica para o especialista na área de som. Inclusive essa é uma nova área que aparece no desenvolvimento de jogos.
5.5 Projeto De Som
Inicialmente o XACT cria um projeto vazio e não contém nem um arquivo de som ou banco de sons disponível. Nitschke aborda a ferramenta da seguinte maneira.
A árvore do projeto que contém a estrutura dos elementos e que não podem ser alterados. Duas categorias padrões, default e musica, que pode ser usado para marcar os arquivos de sons como efeitos ou musicas.
Uma variável global, SpeedOfSound (velocidade do som), que sempre é 343.5 e outras 4 variáveis, Cue Instance, separada em Distance, Doppler Pitch Scalar, Number of cue Instances e Orientation Angle. Todas essas variáveis são importantes para sons 3D.
Um caminho para efeitos globais.
Todo o restante da estrutura é iniciada em branco e deve ser adicionada conforme sua necessidade.
Figura 39: Tela do XACT com a estrutura de um novo projeto.
Fonte: Autor, 2008
6 Proposta de jogo
Este capitulo tem por objetivo descrever o projeto do jogo desenvolvido(Figura 40) utilizando uma das tecnologias abordadas no trabalho. Descreve a modelagem do projeto utilizando a linguagem UML apresentando os diagramas de classe, seqüência e objetos.
Figura 40: Proposta de jogo
Fonte: Autor, 2008
Projeto
Para desenvolver um projeto de jogo é preciso seguir alguns passos citados por Perucia, utilizando o Game Design Document como referencia e guia. Segundo estudo este documento é a base do projeto para toda equipe envolvida.
Breve descrição do projeto
O Space Pong tem como proposta criar um jogo utilizando um dos estilos descrito no trabalho e utilizar a metodologia do game design document para definir os padrões, regras e outras características do projeto.
O estilo escolhido é o Arkanoid, ele herda as características do primeiro jogo que fez sucesso, o Pong. Esse estilo foi escolhido devido a sua simplicidade para desenvolver, jogar e a fácil adaptação das regras do jogo.
Breve descrição do jogo
Segundo Overmans (2006), é importante que primeiro se escreva uma breve descrição do jogo que se pretende implementar. Uma das características desejáveis pode ser o tempo no qual o jogador mantém interesse no jogo. Overmans ressalta que se tratando do primeiro jogo desenvolvido ele deve ser simples. A descrição inicial do jogo foco deste trabalho é como se segue:
O Space Pong é um jogo no estilo Arkanoid onde o jogador deve utilizar o pad para rebater a bola e destruir os blocos. O jogador não pode deixar a bola encostar na parte inferior da tela. Cada vez que os bloco são destruídos a fase recomeça.
Documentação do projeto
De acordo com Overmans (2006) o segundo passo na criação de um jogo é descrever um documento de projeto mais preciso. Neste documento devem constar, os objetos envolvidos no jogo, suas ações e eventos relacionados às ações. Também devem ser descritos os sons, controles e o fluxo do jogo.
Neste documento devem constar as fases do jogo e o fluxo entre cada fase. As regras de pontuação e penalidade devem estar bem descritas e balanceadas, para que o jogo mantenha o interesse do jogador.
Documentação do SpacePong
Para o desenvolvimento do jogo foi criado um documento (Game Design Document) com todas as informações sobre o jogo. Para fazer tal documento foi utilizada a técnica descrita por Overmans. No documento constam informações técnicas, fluxo do jogo, regras do jogo, desenhos e layouts.
Imagens utilizadas
Segundo Overmans, todas as imagens devem constar no game design document. As imagens utilizadas no projeto foram feitas pelo designer Juliano Fagundes. O tema do jogo foi discutido com varias pessoas e foi escolhido o tema espacial. Por padrão foi estabelecido que o formado das imagens seria em png.
De acordo com Feldman (2001) para desenvolver um jogo no estilo 2d, deve-se levar em consideração os gráficos para que o jogador tenha uma boa primeira impressão sobre o jogo. Feldman (2001) também cita a técnica de usar uma cor de fundo padrão para fazer a colisão por pixel, nesse caso a cor rosa, que é muito utilizada para essa técnica.
Tabela de imagens
Imagem que representa as vidas do jogadorBolaBlocos Nave utilizada para rebater o astronautaTabela 2: Tabela das imagns
Fonte: Autor 2000
Objetos
Cada objeto tem uma ou mais ações no jogo. A nave serve para rebater o astronauta contra os blocos e marcar pontos. Os objetos variam de dependentes a independentes. Objeto como a nave depende do jogador para se movimentar, já a bola é um objeto totalmente independente que só reage as alterações do ambiente como colisão.
Os blocos por sua vez são dependentes da reação do usuário com a nave para rebater a bola, e se isso ocorrer ele depende que a bola seja lançada contra o bloco para que alguma ação ocorra.
Fases
As fases são construídas dinamicamente sorteando as cores dos blocos. São seis linhas e oito colunas com blocos. As cores são amarelo, vermelho, verde e azul. Todas as fases são iguais, a única mudança é a disposição das cores nas linhas.
Pontuação
A pontuação é definida pela cor do bloco. A cor vermelha vale cinco pontos, verde dez, amarelo quinze e azul trinta. Ao concluir a fase o jogador recebe um bônus relativo ao tempo levado para concluir a fase.
Tela de ajuda
Na tela de ajuda é possível ver todas as regras, pontuação, descrição do projeto e motivação para desenvolvimento do jogo.
Tela de crédito
Os nomes das pessoas envolvidas no projeto podem ser visualizados na tela de créditos. Alguns comentários sobre o projeto e o jogo são exibidos nessa tela.
Estrutura do jogo
Para melhor desenvolver a aplicação foi criado um fluxo com as ações(Figura 41) de cada objeto e seus comportamentos. Cada objeto no jogo pode tomar uma ação que pode mudar o estado do jogo a qualquer momento.
Figura 41: Diagrama de estados
Fonte: Autor, 2008
Fluxo do jogo
O fluxo do jogo parte do principio que várias ações e eventos são tomados em paralelo, sendo assim o jogo só termina quando uma ação específica for chamada pra encerrar o jogo. Esse fluxo da figura 42 tem como objetivo auxiliar no desenvolvimento do game loop, função principal que controla todos eventos e comportamentos que podem vir do jogador ou de alterações feitas pela maquia.
Figura 42: Fluxo do jogo
Fonte: Autor, 2008
Diagrama de classes
Cada objeto possui sua característica própria para manipulação das regras e comportamentos. Os objetos utilizados são eles: bola, paddle e bloco representados no diagrama de classes(Figura 43).
Figura 43: Diagrama de classes
Fonte: Autor, 2008
A bola é um objeto que está sempre em movimento e só altera seu comportamento quando algum outro objeto ou regra atua sobre ela. O paddle por sua vez muda conforme a ação do jogador. Ele pode mover pela área pré definida e rebater a bola para destruir os blocos. Os blocos são objetos estáticos e que só são alterados quando a bola encosta neles.
Diagrama de seqüências
No diagrama de seqüência é possível ver a ordem em que cada objeto do jogo será criado e inicializado. Isso ajuda na hora de desenhar os objetos na tela e manter uma seqüência (Figura 44) lógica da estrutura.
Figura 44: Diagrama de seqüência
Fonte: Autor, 2008
Detalhes do desenvolvimento
Pela simplicidade do projeto não foi utilizado nem uma técnica mais avançada. Apenas a colisão por pixel foi suficiente para manipular os objetos do jogo.
No desenvolvimento do jogo foi adotado um padrão para as imagens e nomenclatura dos objetos. O código foi comentado para futuramente servir de referencia, aprendizado ou até uma alteração do jogo.
Teste do jogo
O jogo foi disponibilizado para as pessoas que participaram do projeto do jogo e alguns interessados nos fóruns e comunidades de desenvolvimento de jogos em XNA. Para fins de melhorias algumas pessoas responderam um questionário sobre o jogo e seu projeto. Os testes ajudaram a corrigir erros e melhorar o interesse ao jogar. Alguns pontos foram levantados.
1)Fases diferentes ou um editor
2)Sons
3)Objetos de bônus
4)Outras dificuldades
Conclusão do projeto
Após concluir o projeto foi gerada uma versão executável do jogo e distribuída em fóruns e sites do assunto relacionado.
CONCLUSÃO
Tendo por base os dados levantados neste trabalho, foi possível ver todos os processos envolvidos na criação de um projeto de jogo até a escolha de ferramentas para desenvolvimento de cada fase do jogo. Dentro dessa pesquisa foi possível planejar o desenvolvimento do jogo usando as técnicas, documentação, foco para o desenvolvimento e o caminho a seguir para manter uma idéia do inicio ao fim.
O planejamento inicial de um projeto demonstrou sua importância no resultado final, mantendo a qualidade e expectativas do jogo. Através desta pesquisa busquei mostrar os pontos importantes e o quão complexo o projeto de um jogo pode ser.
Também é possível perceber que o desenvolvimento do jogo não depende apenas de uma pessoa e sim de um grupo inteiro que deve estar a par de todas as alterações ou novas propostas de desenvolvimento ao longo do projeto.
Apoiado nisso é possível concluir que muito antes de colocar a mão no código do jogo é preciso documentar e desenvolver a idéia com um grupo de pessoas.
Referências Bibliográficas
AZEVEDO, Eduardo. Desenvolvimento de Jogos 3D e Aplicações em Realidade Virtual. Editora Campus, 2005.
BALDWIN, Mark. Game Design Document Outline. Disponível em: .
BARRON, Todd. Multiplayer Game Programming. Prima Tech, 2001
BUONO, Salvatore A. C# and Game Programming: A beginner´s Guide, A K Peters LTD. 2003.
CAWOOD, Stephen.; MCGEE, Pat. Microsoft XNA Game Studio Creator’s Guide. New York: Osborne. 2007.
COLNAGHI JUNIOR, Roberto. Programação de jogos de computador na plataforma Windows – Teoria e prática. Novo Hamburgo: Trabalho de conclusão. 2001.
FELDMAN, Ari. Designing Arcade Computer Game Graphics, Wordware. 2001.
HARRISON, Lynn T. Introduction to 3D Game Engine Design Using DirectX 9 and C#, Apress. 2003.
KLUCHER, Michael. Program Manager - XNA Game Studio Publicado dia 29 de agosto de 2006. Disponível em: . Acesso em 5 mar. 2008.
LAMOTHE, André. Black Art of 3D Game Programming. California: Waite Group Express, 1995.
LAMOTHE, André. Tricks of the windows game programming gurus – Fundamentals of 2D and 3D game programming, Estados Unidos, Sams, 1999.
MCCUSKEY, Mason. et al. Especial Effects Game Programming with DirectX. Premier Press. 2003.
MICROSOFT XNA DEVELOPER CENTER. Disponível em: . Acesso em 17 set. 2007
MULLIGAN, Jessica. et a. Developing Online Games. New Riders. 2003.
NITSCHKE, Benjamin. Professional XNA Game Programming. Indiana, Wrox. Pazera, Ernest (2001) Isometric Game Programming with DirectX 7.0, Prima Tech, 2007.
PERUCIA, Alexandre Souza. et. al. Desenvolvimento de Jogos Eletrônicos, Porto Alegre: Novatec, 2005.
RANDIMA, Fernando. et. Al. Cg The Cg Tutorial – The Definitive Guide to Programmable Real-Time Graphics, Addison Wesley. 2003.
SLOPER, Tom. Disponivel em: . Acesso em 20 abr. 2008
STAHLER, Wendy. Beginning Math and Physics for Game Programmers, New Riders, 2004.
WESLEY, Addison. OpenGL Programming Guide – The Official Guide to Leraning OpenGL, Version 1.2 / OpenGL Architecture Review Board, Mason Woo, Jackie Neider, Tom Davis, Dave Shreiner -- 3rd ed., Silicon Graphics, 1997.
PAGE
PAGE 2
PAGE 13
PAGE 22
PAGE 38
PAGE 43
PAGE 84
PAGE 95
! 1 : O j l p x ‚ ƒ „ ” ˜ ¬ ƒ … ‰ ‘ š › ¡ ¢ ± ³ ¿ À ñ
üëüëüÙüÕüÕüÑÍÅëü¹üÕüÕüÑü«œ|k|ZkZ| h‰3 hÑ @ˆ
CJ OJ QJ aJ h‰3 h+v @ˆ
CJ OJ QJ aJ h‰3 h=Zc @ˆ
CJ OJ QJ aJ h3Ñ 5@ˆ
CJ OJ QJ aJ h+v 5@ˆ
CJ OJ QJ aJ hÁH @ˆ
CJ OJ QJ aJ h h ;@ˆ
aJ j hÁH UhÑH4 h3Ñ h #h h ;@ˆ
CJ OJ QJ aJ h h @ˆ
CJ OJ QJ aJ hÁH " ! 1 2 3 4 5 6 7 8 9 : O P Q R S T U V W ö ð ð å à å ð Û Û Û Û Û Û Û Û å Ö Û Û Û Û Û Û Û gdÁH gdÁH gdÁH
$dh a$gd @&