DESENVOLVIMENTO DE UM JOGO 3D - jersonseling

UNIVERSIDADE DA REGIÃO DA CAMPANHA
CENTRO DE CIÊNCIAS DA ECONOMIA E INFORMÁTICA
CURSO DE INFORMÁTICA
DESENVOLVIMENTO DE UM JOGO 3D
JERSON DOS SANTOS SELING
Bagé - RS
2009
JERSON DOS SANTOS SELING
DESENVOLVIMENTO DE UM JOGO 3D
Monografia apresentada ao Centro de
Ciências da Economia e Informática, da
Universidade da Região da Campanha
(URCAMP, RS), como requisito parcial para
obtenção do título de Bacharel em
Informática.
Orientador: Abner Guedes
Bagé - RS
2009
JERSON DOS SANTOS SELING
DESENVOLVIMENTO DE UM JOGO 3D
TCC: Trabalho de Conclusão de Curso
Data da Defesa: 16/12/2009
Resultado final: 10
BANCA EXAMINADORA
_____________________
_____________________
_____________________
Profº Carlos Pereira
Profº Cristiano Cachapuz
Profº Márcio Spenst
Bagé - RS
2009
Dedico este trabalho a minha mãe, meu pai e a Deus, sem os quais
eu não teria as oportunidades de chegar aqui.
RESUMO
Este trabalho monográfico busca abordar o processo de desenvolvimento de
um jogo 3D utilizando o engine gráfico OGRE. Além disso, procura mostrar as várias
etapas do desenvolvimento de uma maneira formal e que ainda assim seja possível
de o jogo ser desenvolvido por um único desenvolvedor. Os aspectos mais
importantes desse tipo de aplicação são tratados neste trabalho, como a criação de
personagens em um programa de modelagem 3D, criação de texturas em um
programa de criação de imagens, criação de cenários em programas específicos
para isso e por último a codificação utilizando como linguagem o C++. Um pequeno
jogo (de tiro em terceira pessoa) foi desenvolvido junto a este trabalho e possui os
elementos principais que caracterizam um jogo 3D, como cenário, manipulação de
personagens, inimigos utilizadores de uma forma de inteligência artificial e um
conjunto de regras que definem o objetivo do jogo e a maneira de jogá-lo.
Palavras-chave: jogos 3D, programação gráfica, engines, desenvolvimento formal.
ABSTRACT
This monograph tries to approach the development process of a 3D game using the
OGRE graphic engine. In addition, we seek to demonstrate the various development
stages in a formal way and yet turn possible for the game to be developed by a
single developer. The most important aspects of this application type are discussed
in this work, like the creation of characters in a 3D modeling program, textures
creation in an image creation program, scenario creation within specific programs to
it, and finally the encoding using as data processing language the C++. A little game
(a shooting type on a third person) was developed together with this work and it
presents the main elements that characterize a 3D-game, to wit, scenario, character
manipulation, enemies using some way of artificial intelligence, and a set of rules that
define the game goal and how to play it.
Keywords: 3D games, graphics programming, engines, formal development.
LISTA DE FIGURAS
Figura 1: Higinbotham e o osciloscópio que rodava Tennis for Two......................... 18
Figura 2: Space War! ........................................................................................................ 18
Figura 3: Pong .................................................................................................................... 19
Figura 4: Pitfall ................................................................................................................... 19
Figura 5: Elite ..................................................................................................................... 20
Figura 6: Battlezone .......................................................................................................... 20
Figura 7: Crysis .................................................................................................................. 21
Figura 8: Elementos do projeto do jogo ......................................................................... 26
Figura 9: Storyboards do jogo Portal Runner................................................................ 27
Figura 10: Partes integrantes de um jogo...................................................................... 32
Figura 11: Exemplo de modelo para jogo ...................................................................... 33
Figura 12: Textura e modelo texturizado ....................................................................... 33
Figura 13: Casos de uso do jogo Pac-Man ................................................................... 34
Figura 14: Modelo sem textura (1), modelo com textura (2)....................................... 35
Figura 15: Coordenadas UV em uma superfície 3D .................................................... 36
Figura 16: Texture Map e Light Map............................................................................... 37
Figura 17: Um Cube Map ................................................................................................. 38
Figura 18: Representação de um grafo de cena simples ........................................... 39
Figura 19: Personagem com juntas ................................................................................ 40
Figura 20: Animação de Malha ........................................................................................ 40
Figura 21: Personagem com esqueleto ......................................................................... 41
Figura 22: Biped ................................................................................................................. 41
Figura 23: Tipos de luzes ................................................................................................. 42
Figura 24: Luzes e sombras no engine OGRE ............................................................. 43
Figura 25: Implementação de neblina no engine GLScene........................................ 43
Figura 26: Um Sky Dome ................................................................................................. 44
8
Figura 27: Sky box ............................................................................................................. 44
Figura 28: Heightfield ........................................................................................................ 44
Figura 29: Billboards cobrindo um teapot ...................................................................... 45
Figura 30: Modelo 3D e seu bounding volume cúbico................................................. 46
Figura 31: 3DS Max 8.0 com plugin oFusion instalado ............................................... 48
Figura 32: Adobe Photoshop CS2 .................................................................................. 49
Figura 33: Área de download de animações do site eMotek ...................................... 49
Figura 34: Terragen ........................................................................................................... 49
Figura 35: Funcionamento do engine OGRE ................................................................ 50
Figura 36: Instanciamento da classe da aplicação e sua execução ......................... 51
Figura 37: Ambiente de desenvolvimento ..................................................................... 51
Figura 38: Câmera em terceira pessoa .......................................................................... 52
Figura 39: Interpolação linear .......................................................................................... 52
Figura 40: Projéteis sendo disparados ........................................................................... 53
Figura 41: Explosão de um inimigo................................................................................. 53
Figura 42: Storyboard do jogo Aquarius ........................................................................ 59
Figura 43: Haytron ............................................................................................................. 60
Figura 44: Aquarius ........................................................................................................... 60
Figura 45: Mevelly ............................................................................................................. 60
LISTA DE ABREVIATURAS
2D
2 Dimensions
3D
3 Dimensions
3DS
3D Studio
API
Application Programming Interface
ASAP
As Soon As Possible
BBC
British Broadcasting Corporation
BLP
Blizzard Picture
BMP
Windows Bitmap
BSP
Binary Space Partition
CD
Compact Disk
DDS
Direct Draw Surface
DOS
Disk Operational System
DVD
Digital Video Disk
ESRB
Entertaining Software Rating Board
EUA
Estados Unidos da América
FPS
Frames per Second
FPS
First Person Shooter
GPU
Graphics Processing Unit
IDE
Integrated Development Environment
JPEG
Joint Photography Experts Group
LAN
Local Area Network
LOD
Level of Detail
MD2
Model Quake 2
MFC
Microsoft Foundation Classes
MIT
Massachusetts Institute of Technology
MMORPG
Massive Multiplayer On-Line Roling Player Game
OBJ
Wavefront Object File
ODE
Open Dynamic Engine
OGRE
Object Oriented Graphics Rendering Engine
OIS
Open Input System
OpenGL
Open Graphics Library
PC
Personal Computer
PNG
Portable Network Graphics
PSP
PlayStation Portable
PWC
Price Waterhouse Coopers
QA
Quality Assurance
RPG
Roling Player Game
RTS
Real Time Strategy
SDK
System Development Kit
STL
Standard Template Library
TGA
Truevision Targa
TV
TeleVision
UI
User Interface
UML
Unified Modelling Language
XNA
XNA's Not Acronymed
SUMÁRIO
1 INTRODUÇÃO ...................................................................................................... 12
2 PROBLEMA DE PESQUISA ................................................................................ 14
3 OBJETIVOS E JUSTIFICATIVA........................................................................... 15
3.1 OBJETIVOS ..................................................................................................... 15
3.1.1
Objetivo Geral ........................................................................................... 15
3.1.2
Objetivos Específicos ............................................................................... 15
3.2 JUSTIFICATIVA ............................................................................................... 15
4 PROCEDIMENTOS METODOLÓGICOS ............................................................. 16
5 REVISÃO BIBLIOGRÁFICA................................................................................. 17
5.1 HISTÓRIA DOS JOGOS .................................................................................. 17
5.2 GÊNEROS DE JOGOS ..................................................................................... 21
5.3 TIPOS DE MÍDIAS DOS JOGOS ...................................................................... 23
5.4 O PROCESSO DE DESENVOLVIMENTO........................................................ 24
5.4.1
Projeto........................................................................................................ 26
5.4.2
A equipe de produção .............................................................................. 27
5.4.3
O Desenvolvimento................................................................................... 33
5.4.4
Mapeamento de Texturas ......................................................................... 35
5.4.5
Tópicos Importantes de um Engine Gráfico ........................................... 38
6 CRIAÇÃO DO JOGO AQUARIUS ........................................................................ 47
6.1
6.2
6.3
6.4
6.5
O IDE DE PROGRAMAÇÃO ............................................................................ 48
FERRAMENTAS PARA CRIAÇÃO DE CONTEÚDO ...................................... 48
O PROJETO ..................................................................................................... 50
A PROGRAMAÇÃO ......................................................................................... 50
DIFICULDADES ENCONTRADAS .................................................................. 54
7 CONSIDERAÇÕES FINAIS .................................................................................. 55
8 BIBLIOGRAFIA .................................................................................................... 56
9 ANEXO: PROJETO DO JOGO AQUARIUS ........................................................ 58
9.1
9.2
9.3
9.4
9.5
DESCRIÇÃO DO SISTEMA ............................................................................. 58
ROTEIRO DO JOGO ........................................................................................ 58
STORYBOARD ................................................................................................ 59
ESQUEMA DOS PERSONAGENS .................................................................. 60
DIAGRAMAS UML ........................................................................................... 61
1
INTRODUÇÃO
Este trabalho trata sobre o desenvolvimento de um jogo 3D, mostrando um
método de desenvolvimento e algumas das ferramentas mais utilizadas para isso.
Os jogos 3D são uma tecnologia crescente e em progresso constante,
movimentando dezenas de bilhões de dólares no mercado internacional anualmente
segundo a PWC (SOFTEX, 2005).
O
Brasil
ainda
engatinha
nesse
segmento
com
apenas
algumas
microempresas criadas por empresários jovens com alta qualificação técnica.
Segundo pesquisa da Softex feita em 2003, o faturamento total relacionado ao
desenvolvimento de jogos no Brasil foi de R$ 2,39 milhões, com uma média de R$
341 mil por empresa, já em 2004 o faturamento total saltou para R$ 4,2 milhões.
Na outra ponta dessa evolução tecnológica estão os desenvolvedores
casuais, que programam sem nenhuma intenção comercial. Estes freqüentam ou
mantêm sites renomados no Brasil como o GameDev (www.gamedev.com.br) e o
UniDev (www.unidev.com.br). Tais sites possuem fóruns bem movimentados e
atualizados diariamente, onde seus usuários discutem, tiram dúvidas e aprendem.
Este trabalho busca demonstrar como os jogos 3D são desenvolvidos em
linhas gerais, pois cada jogo, dependendo da plataforma em que rodará e o gênero
ao qual pertence, pode possuir algumas etapas a menos, extras ou alternativas no
desenvolvimento. Para o desenvolvimento serão utilizadas ferramentas freewares,
sharewares, livres para uso não-comercial ou versões trial de softwares
proprietários, demonstrando a possibilidade de se desenvolver um jogo como um
passatempo sem ter gastos excessivos na compra de ferramentas.
13
Serão cobertas as etapas essenciais para o desenvolvimento de um jogo 3D
e ao final estarão em anexo artigos que esclarecem tópicos relacionadas ao tema,
além de documentações do jogo desenvolvido.
O assunto tratado neste trabalho são os jogos eletrônicos, ou pela definição
de Bethke (2003), softwares interativos para entretenimento. Por isso de agora em
diante a referência a termos como “jogos eletrônicos”, “jogos digitais” ou
simplesmente “jogos” significará que são softwares interativos para entretenimento e
não qualquer outra forma de jogo que não essa.
Este trabalho foi estruturado em quatro grandes divisões.
a) A primeira divisão trata sobre as questões introdutórias do trabalho, como
este capítulo, os problemas de pesquisa os objetivos gerais e específicos, a
justificativa que levou o autor a escolher o tema e os procedimentos metodológicos
usados para se desenvolver o trabalho;
b) A segunda divisão trata da revisão bibliográfica. Ela é uma pesquisa que
mostra o estado da técnica tratado pelo trabalho;
c) A terceira divisão trata do desenvolvimento do jogo em si. Desde as
etapas mais iniciais como o projeto, até as mais avançadas como questões
relacionadas a programação do jogo;
d) A quarta divisão é um anexo. Ele é a documentação do jogo desenvolvido
junto a este trabalho monográfico.
2
PROBLEMA DE PESQUISA
Os métodos formais de desenvolvimento de jogos ainda permanecem
restritos a grandes companhias, desenvolvedores casuais, geralmente, não seguem
essas
definições e acabam não
desenvolvimento
de
jogos,
conseguindo finalizar
frustrando-se
e
seus
desestimulando
projetos
os
de
futuros
desenvolvedores a começar a desenvolver jogos 3D. Este trabalho visa demonstrar
sucintamente, esses métodos formais para que o processo de desenvolvimento se
torne uma técnica automatizada e repetível, que possa ser utilizada por um único
desenvolvedor ou uma pequena equipe.
Outro problema comum aos desenvolvedores casuais é que raramente as
fontes de conhecimento ensinam como se criar um jogo completo. Em geral, elas
apenas ensinam como usar uma determinada técnica, ferramenta ou funcionalidade
que pode ser útil em um jogo, mas não ensinam como usar em conjunto essas
várias ferramentas e funcionalidades para criar um jogo inteiro.
Com isso os
desenvolvedores começam a improvisar maneiras de se interligar essas técnicas,
fazendo muitas vezes o que é chamado por alguns autores de “reinventar a roda”.
Logo fica a questão: Como um desenvolvedor ou uma pequena equipe pode
desenvolver um jogo 3D de maneira bem planejada, utilizando as várias tecnologias
disponíveis e gratuitas existentes?
3
3.1
OBJETIVOS E JUSTIFICATIVA
OBJETIVOS
3.1.1 Objetivo Geral
Desenvolver um jogo 3D utilizando um engine gráfico baseado em C++.
3.1.2 Objetivos Específicos
a) Avaliar os engines disponíveis;
b) Definir o engine a ser utilizado com base na relação custo/benefício entre
esforço para desenvolver e a qualidade do resultado obtido;
c) Estudar a metodologia de desenvolvimento do engine escolhido;
d) Desenvolver o projeto do jogo;
e) Programar e testar o funcionamento do jogo.
3.2
JUSTIFICATIVA
A maioria dos usuários de jogos, provavelmente, já pensou pelo menos uma
única vez em como os jogos são criados. Em como o processo de desenvolvimento
pode ser divertido e gratificante. Porém são raros os que satisfazem essa
curiosidade descobrindo como é este processo, isso por não haver uma literatura
que esclareça de forma completa e simples o processo. Este trabalho tem por um de
seus objetivos ser este tipo de literatura, explicando de forma simples as etapas e
processos necessários para se desenvolver um jogo 3D.
4
PROCEDIMENTOS METODOLÓGICOS
Nesta seção, apresenta-se a metodologia que foi adotada no presente
trabalho, bem como as principais etapas que envolvem o método e os
procedimentos a serem utilizados:
a) Avaliar os engines 3D disponíveis com base em suas capacidades,
disponibilidade (open-source, freeware, shareware) e requisitos para se desenvolver
um jogo 3D;
b) Definir o engine a ser utilizado com base na relação custo/benefício entre
esforço para desenvolver e a qualidade do resultado obtido;
c) Estudar a metodologia de desenvolvimento do engine escolhido,
instalando e configurando a IDE de desenvolvimento (engine e compilador);
d) Desenvolver o projeto do jogo, definindo o tema do jogo, formalizar o
roteiro, criar os storyboards e definir o projeto a partir dos diagramas de UML;
e) Desenvolver o conteúdo com o software de modelagem 3D para a criação
dos modelos 3D com base nos storyboards e então programar o jogo. Com este
pronto, parte-se para a fase de testes.
5
REVISÃO BIBLIOGRÁFICA
Os jogos no sentido geral da palavra são formas de entretenimento
praticadas pelas pessoas desde tempos mais remotos. Em sua origem e até hoje a
maioria dos jogos é praticada fisicamente, ou seja, na realidade dos jogadores,
assim são jogos de cartas e esportes. Porém com a criação dos computadores foi
possível o desenvolvimento de realidades virtuais, mundos e regras que existem
apenas nos circuitos lógicos da máquina. Ao longo do tempo essas realidades
virtuais se sofisticaram ao ponto de visualmente assimilar-se a realidade “real”,
graças a tecnologia 3D que permite a representação de volume matematicamente
(TYSON, 2009).
Segundo Huizinga (1938), jogo é uma atividade voluntária exercida dentro
de certos e determinados limites de tempo e espaço, segundo regras livremente
estabelecidas, mas absolutamente obrigatórias, dotado de um fim em si mesmo,
acompanhado de um sentimento de tensão, alegria e de uma consciência de ser
diferente de vida cotidiana.
O filósofo Huizinga em 1938, escreveu seu livro Homo Ludens, no qual
argumenta que o jogo é uma categoria absolutamente primária da vida, tão
essencial quando o raciocínio (Homo Sapiens) e a fabricação de objetos (Homo
Faber), então a denominação Homo Ludens, quer dizer que o elemento lúdico está
na base do surgimento e desenvolvimento da civilização (WIKIPÉDIA, 2009).
5.1
HISTÓRIA DOS JOGOS
Os ancestrais dos jogos eletrônicos atuais foram jogos que utilizavam como
tela de visualização aparelhos conhecidos como osciloscópios, que serviam em um
18
primeiro momento para a representação do ambiente varrido pelas ondas de rádio
nos radares (ver Figura 1). O primeiro desses jogos foi Tennis for Two, criado em
1958 por William Higinbotham (ver Figura 1) (CARVALHO, 2006).
Figura 1: Higinbotham e o osciloscópio que rodava Tennis for Two. Fonte: (CARVALHO, 2006)
Porém o primeiro jogo eletrônico a ter uma representação gráfica mais
parecida com o que temos hoje, ou seja, numa tela normal e não em um
osciloscópio, foi Space War! (ver Figura 2), criado no MIT no início da década de 60
por Steven Russel para rodar em um mainframe, mostrando o potencial gráfico
deste. O monitor deste mainframe era monocromático e exibia além de caracteres,
linhas e pontos. No jogo o usuário controlava uma espaçonave que devia destruir
todas as espaçonaves inimigas e ir passando de nível. (CABRAL, 2005)
Figura 2: Space War! Fonte: (CABRAL, 2005)
Porém até esse momento os jogos eram exclusivos de computadores
militares ou de instituições de ensino superior, pois não havia ainda dispositivos
eletrônicos domésticos capazes de realizar a computação necessária para se rodar
19
um desses jogos. Foi só no final dos anos 60, que a empresa General Instruments
criou o primeiro chip barato, permitindo em 1972 que a empresa Atari lançasse o
primeiro console de videogame do mundo para o público, o Odyssey. Este console
permitia a execução do jogo Pong (ver Figura 3) que era baseado nos osciloscópios.
Nele dois jogadores se enfrentavam, cada um controlando uma raquete que rebatia
uma bolinha ao estilo Tennis for Two (CARVALHO, 2006).
Figura 3: Pong. Fonte: (CARVALHO, 2006)
A partir desse momento começou uma grande disputa entre empresas como
a Atari e suas concorrentes, para que cada uma desenvolvesse um jogo mais
avançado que o de sua concorrente, conseguindo assim mais consumidores. Em
1975 foi lançado o Atari 2600, capaz de executar jogos coloridos com dezesseis
cores diferentes. Entre eles o Pitfall (ver Figura 4) em 1982 (CARVALHO, 2006).
Figura 4: Pitfall. Fonte: (CABRAL, 2005)
Foi nos anos 80, que também começou o desenvolvimento de aplicações 3D
interativas, o primeiro jogo comercializado 3D só foi lançado em 1984 ele era Elite
20
(ver Figura 5) criado por Ian Bell e David Braben para o BBC Microcomputer
(BERGEN, 2004).
Figura 5: Elite. Fonte: (BERGEN, 2004)
Outro jogo 3D lançado nessa época foi Battlezone (ver Figura 6), que
utilizava gráficos coloridos (CARVALHO, 2006).
Figura 6: Battlezone. Fonte: (CARVALHO, 2006)
Desde então, a evolução da tecnologia gráfica 3D só progrediu, chegando
aos dias atuais (ver Figura 7), onde jogos apresentam gráficos quase realistas
(CARVALHO, 2006).
21
Figura 7: Crysis. Fonte: (CARVALHO, 2006)
5.2
GÊNEROS DE JOGOS
Para se criar um jogo deve-se projetá-lo, para isso devem-se conhecer os
diferentes gêneros de jogos que existem para definir em qual desses gêneros o jogo
vai se encaixar.
Segundo Battaiola (2000), os principais gêneros são:
a) Histórias Interativas (RPG) – RPG é o acrônimo para Role Playing Game,
ou jogo de interpretação de papel. Esse tipo de jogo consiste em uma ambientação
contextual (fantasia medieval, horror) e tem por objetivo criar no computador um
ambiente capaz de reproduzir um ambiente real. Exemplos são os títulos Diablo I e
II, Baldur’s Gate I e II, as diversas séries do jogo Ultima, dentre outros. Um nicho
deste tipo de jogo que vem crescendo bastante é o de Massively Multiplayer On-line
Role Playing Game ou MMORPG, aplicativos de RPG que são jogados via Internet,
simultaneamente por milhares de pessoas em todo o mundo, como exemplo deste
temos o World of Warcraft;
b) Estratégia – São jogos que exigem raciocínio, podem ser jogados em
turnos, tais como, os tradicionais jogos de xadrez ou damas como por exemplo os da
série Civilization ou de estratégia em tempo real (RTS) com os jogadores jogando
simutâneamente, como por exemplo, Starcraft, que em geral, apresentam um enredo
envolvendo guerra;
c) Simulação – São jogos que possuem níveis de complexidade variando de
média a alta, em razão da grande quantidade de comandos necessários para jogar.
22
Geralmente, respeitam ou tentam respeitar, de forma fiel, as leis da física. Dentre
estes jogos pode-se citar o Flight Simulator que, apesar de ser orientado para o
treinamento de pilotos, é classificado como jogo; a série Test Drive e os diversos
títulos de jogos de ação em primeira pessoa (simulação de pessoa ou
guerreiro/soldado);
d) Ação – Os jogos de ação podem ser classificados dentre os mais antigos.
Suas características principais são a facilidade de operação, em virtude das poucas
teclas necessárias (geralmente as setas direcionais e uns poucos botões), objetivo
bem definido, história simples e exigência de bons reflexos. Dentre este tipo de jogo
encontram-se os títulos Tomb Raider da Eidos Interactive; Tekken 3 da Namco e
Nemesis da Konami, dentre outros;
e) Adventures (aventuras) – Esse tipo de jogo, muito popular entre os micros
da geração 8 bits, tinha como peculiar a interatividade da sua interface. Inicialmente
o jogador digitava os textos para que as ações pudessem ser interpretadas.
Geralmente, o jogo não possuía gráficos, apenas textos. Em evoluções desse tipo
de jogo a interface já era composta pelas palavras (ações), que poderiam ser
selecionadas com o mouse e executadas com um clique num objeto na tela,
apresentando, assim, gráficos estacionários ou com pouca animação. Esse tipo de
jogo se caracteriza pela exigência de raciocínio lógico e pode ser classificado,
também, como uma história interativa. Como exemplos encontram-se os títulos:
Amazônia da Tilt On-Line (primeiro jogo brasileiro comercializado), Full Throttle, da
Lucas Arts, as séries Space Quest e King’s Quest da Sierra, dentre outros;
f) Infantis – Jogos infantis se caracterizam por sua interface simples e seu
caráter educacional voltado, essencialmente, para as crianças. Este tipo de jogo
pode apresentar características de quaisquer dos jogos citados;
g) Passatempo – São programas simples, com quebra-cabeças rápidos e
sem nenhuma história relacionada, cujo objetivo essencial é atingir uma pontuação
alta. Os jogos de passatempo podem imitar jogos de tabuleiro (damas, xadrez, go,
etc.), de cartas (poker, paciência, sete-e-meio, etc.) ou de qualquer outra forma de
jogo em que o objetivo é simplesmente o entretenimento. Estes jogos têm,
usualmente, interfaces 2D simples;
23
h) Esporte – São programas que simulam esportes populares, como os
jogos de futebol, futebol americano, vôlei, basquete, boxe, basebol, etc. Como o
usuário comanda times inteiros, esses jogos, geralmente, têm interfaces 3D;
i) Educação/Treinamento – Jogos educacionais podem envolver as
características de qualquer um dos jogos anteriores. Por exemplo, um jogo de
aventura pode envolver enigmas relativos a um templo maia ou a um castelo
medieval e, assim, se tornar um jogo educacional sobre história antiga. Um
simulador de vôo pode ser aperfeiçoado para treinar pilotos de avião. O que
diferencia os jogos de educação ou treinamento dos jogos somente para diversão é
que eles levam em conta critérios didáticos e pedagógicos associados aos conceitos
que visam difundir;
j) Advergames – Jogos interativos disponíveis, gratuitamente, em sites
institucionais de empresas, visando promover marcas, produtos e atrair tráfego.
Como os jogos educacionais, também podem envolver as características de
qualquer um dos jogos anteriores. As tecnologias utilizadas nos jogos são acessíveis
à maioria dos usuários e utilizam técnicas de marketing on-line.
5.3
TIPOS DE MÍDIAS DOS JOGOS
Além da definição do gênero o desenvolvedor deve decidir em qual a
plataforma (mídia) o jogo irá rodar. Segundo a SOFTEX (2005) as principais
plataformas são:
a) Consoles – Equipamento digital dotado de um conector para o aparelho
de TV e um encaixe para algum tipo de unidade de armazenamento contendo
programas e/ou dados de um jogo em particular, geralmente, CD, DVD ou BlueRay.
Os consoles mais avançados disponíveis são o PlayStation 3 da Sony; o Xbox 360
da Microsoft e o Nintendo Wii da Nintendo;
b) PC – Computadores domésticos. Os jogos para essa plataforma,
geralmente, são vendidos fisicamente (em CD, DVD ou BlueRay) em grandes redes
varejistas ou obtidos on-line via assinatura e jogados pela Internet utilizando uma
conexão de banda larga;
c) Aparelho celular – Aparelhos de telefonia móvel. Jogos para esta
plataforma são disponibilizados para download pelas próprias operadoras de
24
telefonia ou podem ser adquiridos na internet, o download do jogo pode ser feito
pelo próprio celular ou em um computador e depois transferido para este;
d) Handhelds e consoles portáteis – Estas plataformas possuem telas de
maior tamanho e melhor qualidade que celulares, possibilitando o acesso a jogos de
melhor resolução gráfica. Os principais consoles portáteis são o Game Boy da
Nintendo e o PlayStation Portable (PSP) da Sony;
e) TV Digital – Jogos que podem ser rodados em aparelhos de TV digital
como forma de conteúdo interativo;
f) Multiplataforma – Outra possibilidade é que o jogo seja destinado a mais
de uma plataforma. Assim, poderiam atingir diferentes nichos tecnológicos, tais
como computadores pessoais, celulares, handhelds, Internet, videogames ou
qualquer outro dispositivo.
5.4
O PROCESSO DE DESENVOLVIMENTO
O desenvolvimento de jogos nada mais é do que desenvolvimento de
software. Os jogos são softwares com arte, som e gameplay, assim como softwares
de planejamento finaceiro são softwares especializados em transações e
planejamento financeiro, e sistemas especialistas são softwares com inteligência
artificial. Entretanto, alguns desenvolvedores de jogos se mantêm aparte dos
métodos formais de produção e desenvolvimento de software com a falsa idéia de
que jogos são uma arte, não uma ciência. Os desenvolvedores de jogos precisam
controlar seus métodos de produção para que possam produzir seus jogos de uma
maneira organizada e repetível. Só uma maneira rigorosa pode criar grandes jogos
dentro de um orçamento e em tempo (BETHKE, 2003).
A idéia do jogo é sempre controlada pelo Game Designer, o projetista de
jogo, este não é obrigado a saber programar, modelar objetos 3D ou saber usar
softwares de edição de imagem ou qualquer processo de desenvolvimento,
entretanto ele precisa ser unicamente um visionário, o “deus” do jogo, uma das
tarefas deste profissional é escrever o documento de especificação do projeto do
jogo. Este documento detalha a gameplay, descreve personagens e ajustes
(possivelmente incluindo diagramas e desenhos), inclui descrições e mapas dos
25
níveis a serem explorados no jogo, posições e ações de cada personagem ou classe
de personagem (PEDERSEN, 2003).
Abaixo do projetista está o produtor, o profissional que faz o gerenciamento
do projeto. Ele deve manter a equipe de desenvolvimento produtiva e as linhas de
comunicação abertas. Esta pessoa é um diplomata e um político, a força necessária
para se produzir o jogo. Ele deve manter a equipe de desenvolvimento em sincronia
com a idéia do projetista (PEDERSEN, 2003).
A idéia de um jogo também pode partir de muitas fontes:
a) Um conceito original apresentado por alguém;
b) Uma seqüência para um jogo já existente;
c) Uma adaptação baseada em um personagem de um jogo já existente;
d) Um jogo baseado em um personagem ou história existente (como
personagens de filmes, TV ou quadrinhos);
e) Uma simulação de outros jogos (como jogos de tabuleiro ou de cartas);
f) Uma simulação de um acontecimento do mundo real;
g) Um jogo desenvolvido para aproveitar uma plataforma de jogos específica
(como a Internet ou um sistema de jogos interativo avançado).
Uma vez que a idéia for aceita como viável (por uma empresa ou pelo grupo
de amigos que desenvolverá o jogo) passa-se a etapa de planejamento (TYSON,
2009).
No caso do jogo ser desenvolvido por uma empresa, a aceitação da idéia do
jogo é feita em reuniões para luz verde (green-light meeting), onde desenvolvedores,
produtores e produtores executivos do jogo reúnem-se com os executivos da
empresa para ver se estes aprovam o desenvolvimento do jogo. Para ajudar numa
decisão positiva a equipe de desenvolvedores trabalha na criação de trechos de
software e arte que tentarão provocar uma boa impressão na mente dos executivos.
Isso é chamado comumente de “eye candy” (BETHKE, 2003).
26
5.4.1 Projeto
Quando é dada a luz verde para o desenvolvimento do jogo, uma equipe de
pré-produção é montada. Se o jogo for feito apenas por um entusiasta ou um
pequeno
grupo
sem
pretensões
comerciais,
ainda
assim
as
funções
desempenhadas por estas pessoas terão de ser feitas:
a) Projetista;
b) Produtor;
c) Engenheiro de software / programador;
d) Artista;
e) Roteirista.
Às vezes, a equipe não terá todas essas pessoas (como no caso de um
único desenvolvedor); outras vezes, terá mais de uma pessoa em cada categoria
(TYSON, 2009). O dever dessas pessoas é definir os quatro elementos principais do
projeto de jogo (ver Figura 8): o projeto mestre, o projeto dos níveis e missões, a
mecânica do jogo, a história e os diálogos (BETHKE, 2003).
Figura 8: Elementos do projeto do jogo. Fonte: (BETHKE, 2003)
A primeira coisa que a equipe de pré-produção faz é desenvolver o roteiro
do jogo. O roteiro identifica o tema do jogo, os personagens principais e o plano
geral. Uma parte importante do desenvolvimento do roteiro é saber a natureza do
jogo. Isto significa que o projetista de jogos está envolvido desde o início (TYSON,
2009).
27
Uma vez que o roteiro foi desenvolvido, a equipe cria um conjunto de
storyboards (ver Figura 9). Um storyboard é uma coleção de desenhos imóveis,
palavras e instruções técnicas que descrevem cada cena do jogo.
Figura 9: Storyboards do jogo Portal Runner. Fonte: (TYSON, 2009)
Além de fazer o storyboard do jogo, os projetistas mapearão os diferentes
mundos ou fases dentro do jogo durante a etapa de pré-produção. Os atributos de
cada mundo e os elementos nele contidos são tirados diretamente do roteiro
(TYSON, 2009).
A mecânica do jogo é mais voltada à programação por isso os encarregados
desta função é a equipe de programadores e o engenheiro de software, ela define
como o jogo se comportará (BETHKE, 2003).
A história e os diálogos são definidos por escritores especializados em
jogos. A criação deste tipo de história é totalmente diferente da criação de histórias
de romances ou roteiros de filmes. Um escritor para jogos precisa gastar muito
tempo com o projetista para o direcionamento da história (BETHKE, 2003).
Uma vez que os storyboards e os modelos gerais das fases do jogo estão
completos, o jogo entra na etapa de produção. A equipe de pré-produção se
expande conforme necessário para incluir outros artistas, programadores e
projetistas (TYSON, 2009).
5.4.2 A equipe de produção
A equipe de produção é a equipe de pré-produção expandida. Ela inclui
muitos profissionais das mais diferentes áreas (TYSON, 2009).
28
A seguir segue-se uma lista segundo Bethke (2003) dos profissionais mais
usados nestas equipes, além do projetista e do produtor que já foram explicados:
a) Programadores chefe e diretores técnicos: O programador chefe é
tradicionalmente o programador mais experiente da equipe de programadores. Ele
geralmente toma para si as partes mais desafiadoras do projeto. Alguns jogos
tendem a terem grandes equipes de programadores como os MMRPG Ultima Online
ou EverQuest, ou jogos single-player/multiplayer como Neverwinter Nights com mais
de 25 programadores. Esses projetos com equipes de programadores grandes,
geralmente, possuem um diretor técnico que supervisiona os programadores e
reporta-se diretamente com o produtor. Os diretores técnicos não precisam ter
grande experiência em programação, eles são apenas mais requisitados no
gerenciamento de programadores. Um outro modelo usado é o de se ter chefes
assistentes que são responsáveis por diferentes aspectos da tarefa de programação,
onde cada um cuida de alguns programadores e se reportam ao programador chefe.
Este modelo é usado em empresas como BioWare e Taldren;
b) Programador da mecânica do jogo: Este profissional é o que converte os
documentos de projeto em código. Esta pessoa, geralmente, modela a física do
mundo do jogo, como as armas e as poções funcionam, etc. Estes profissionais são
freqüentemente vistos envolta dos projetistas debatendo o funcionamento das
características do jogo, como o funcionamento de uma arma, por exemplo;
c) Programador 3D: Esta é uma das posições mais respeitadas na indústria
dos jogos. Este profissional deve ter uma forte experiência em aspectos da
matemática como cálculo de vetores e matrizes, trigonometria e álgebra;
d) Programador de inteligência artificial: A demanda por este profissional
varia de jogo para jogo e de gênero para gênero. Steven Polge, atualmente
trabalhando na Epic é um dos maiores programadores de inteligência artificial
conhecidos, criador de códigos como o Bot Reaper. Estes programadores também,
geralmente, programam usando linguagens de script como Lua, Ruby ou Python em
vez da linguagem padrão como o C++;
e) Programador de interface de usuário: Esta é a pessoa encarregada de
desenvolver a interface pela qual o usuário interagirá com o mundo do jogo. Ele é
um expert em bibliotecas de UI;
f) Programador de áudio: Este profissional é o que codifica os efeitos de som
3D, as marcas do sistema de dublagem e os sistemas de música;
29
g) Programador de ferramentas: Companhias de desenvolvimento de jogos
como a ID, revelam gastar mais de 50 por cento dos seus recursos de programação
criando ferramentas. A empresa BioWare tem um departamento de criação de
ferramentas com mais de dez pessoas, que criam ferramentas para todos os jogos
dela. Essas companhias alegam que isso economiza um tempo precioso, o qual
pode ser gasto com o trabalho de projetistas e artistas. Essa economia de tempo é
devida à aceleração do trabalho dos programadores em virtude deste ser
automatizado por estas ferramentas. Dessa forma com o tempo cada companhia cria
seu próprio toolset (conjunto de ferramentas) para obter gráficos na tela, som nos
alto-falantes e que os personagens no jogo tenham um comportamento interessante;
h) Programador do editor de missões/níveis: Encarado também como um
programador de ferramentas, destaca-se apenas quando o jogo lança para o público
o editor de missões ou níveis;
i) Programador de redes: O profissional encarregado de escrever o código
de baixo nível que permitirá o jogo ser jogado por vários jogadores através de uma
LAN ou ao longo da Internet;
j) Diretor de arte: Este é o chefe da equipe de arte, o encarregado de fazer
com que os artistas façam seus trabalhos em tempo. Um diretor de arte geralmente
é um artista com mais experiência na indústria e conhecedor das experiências das
mais diversas pessoas;
l) Artista de conceitos: Este é um artista que vem ganhando notoriedade. No
passado alguns rascunhos eram suficientes para definir a aparência de todos os
personagens e locações. Porém, atualmente, os orçamentos estão de 10 a 20 vezes
maiores do que eram em 1995, os riscos são maiores e a arte errada pode ser fatal
ao projeto. Os desenhos em preto-e-branco de alta qualidade são coloridos (color
comp) para mais tarde serem entregues ao diretor de arte, ao produtor e demais
stakeholders do projeto e estes decidirem se esses desenhos serão colocados no
jogo ou precisarão ser refeitos;
m) Artista 2D/Projetista de interface: O artista 2D é um expert em desenho e
pintura clássico. São eles que pintam fundos de cenários, retratos de personagens e
criam tiles e sprites. Na era dourada do desenvolvimento de jogos, eles usavam o
software Deluxe Paint, hoje usam Photoshop, Illustrator e outros pacotes. Nos jogos
3D este artista, geralmente, também assume o papel de projetista de interface;
30
n) Modelador 3D: O modelador 3D foi o foco das atenções entre 1994 e
1997. Até essa época os artistas com experiência na indústria que existiam eram
invariantemente artistas 2D e esses artistas não tinham os requisitos necessários
para se manipular os pacotes de modelagem 3D. Assim um estranho hibrido de
programador-artista com fascínio por coisas 3D foi requisitado para operar os
modeladores 3D primitivos. Esses artistas também começaram a ser requisitados na
indústria de filmes, e assim as companhias de jogos tinham de pagar caro para
conseguir os disputados modeladores 3D. Assim nesses anos começaram a
aparecer os primeiros operadores de softwares, como as antigas versões do
LightWave. Com o tempo esses pacotes foram ficando mais fáceis de se usar, assim
cursos começaram a ensinar 3D Studio Max e muitas pessoas tiveram a
oportunidade de aprender a usar pacotes de modelagem 3D. Esses profissionais
ainda são altamente respeitados na equipe de desenvolvimento de qualquer jogo,
porém agora eles são mais balanceados com outras partes chaves da arte;
r) Modelador de personagens: Este profissional pertence a uma vertente
especializada de modeladores 3D. Alguns artistas 3D experientes tem mais
facilidade de fazer coisas mecânicas, como espaçonaves, tanques de guerra e
arquitetura, enquanto outros tem a facilidade de fazer os personagens orgânicos. Os
modeladores de personagens com poucos polígonos (low-polys) têm um
entendimento especial de como os detalhes do personagem ganharão vida no
estágio de texturização para economizar ao máximo o seu orçamento de polígonos;
s) Artista de texturas: O artista de texturas, assim como, o artista de
conceitos é um elemento de grande visibilidade na equipe de arte. Como os pacotes
de modelagens 3D são muito sofisticados nos dias atuais é normal ver a fase de
texturização ser de 3 a 4 vezes maior do que a fase de modelagem do personagem.
O artista de textura é capaz de imaginar a “pele” de um objeto em sua mente e criar
um conjunto de texturas para “pintar” a “pele” do modelo 3D;
t) Animador/Estúdio de captura de movimentos: A animação vem em duas
categorias bem distintas: a animação de personagens/animais/monstros e a
animação de objetos em geral. Antenas giratórias, moinhos e radares são bons
exemplos de animações da categoria objetos em geral. Animar um moinho de vento
é uma tarefa mais trivial para um artista do que animar um personagem. Para se
animar personagens são usadas duas técnicas: keyframing e captura de
movimentos (motion capture). Keyframing é o método mais antigo e comum de se
31
animar personagens, tal técnica também é usada na animação de personagens de
desenho animado e monstros que tenham movimentos extremados, movimentos
impossíveis de serem capturados de um ator humano. O processo de animar por
keyframing é bem diferente do de modelar, texturizar e esboçar rascunhos, se um
projeto envolve personagens que precisam ser animados deve-se assegurar que a
equipe tenha animadores competentes para se ter um bom trabalho em tempo, pois
a animação pode ser uma arte lenta. A captura de movimentos é o estado da arte,
atores humanos se movimentam e seus movimentos são capturados. A captura de
movimentos pode ser cara tanto em dinheiro, quanto em tempo ao se tratar os dados
obtidos para que sejam utilizáveis. Este campo vem recebendo grandes
melhoramentos e há poucos estúdios fazendo esse trabalho. Algumas companhias
de desenvolvimento de jogos dividem o trabalho de animação de personagens entre
modeladores e animadores dependendo da natureza da tarefa, já outros estúdios
como a BioWare tem uma equipe de profissionais chamados character riggers para
fazerem isso;
u) Storyboarder: Se o jogo tem filmes ou seqüências de cinemáticas, é
importante que a equipe tenha um profissional na criação de storyboards. Este
artista deve estar apto a projetar e articular cenas em seqüências tanto internas
quanto externas. A maioria dos storyboarders são artistas de conceito, mas não
necessariamente;
v) Dubladores: Vozes em um jogo sempre trazem vida. Compilar vozes age
como um reforço a outros elementos de interatividade ao se ter atores falando por
um personagem. Para se obter boas vozes também é importante se ter um diretor de
dublagem. Um bom diretor de dublagem é capaz de encontrar os atores mais
talentosos, o estúdio de gravação e o engenheiro de som para entregar o áudio no
formato requisitado;
x) Engenheiros de som: São os profissionais responsáveis pela criação dos
sons, em geral, do jogo. Eles fazem coisas como tratamento de sons para a criação
de efeitos como explosões, tiros e músicas.
Estes são só os profissionais envolvidos no desenvolvimento direto do jogo,
ainda existem outros como testers, produtores de linha, produtores executivos,
chefes de QA (quality assurance), advogados, executivos de vendas, etc. A figura 10
32
mostra a partir de uma visão mais ampla as partes integrantes de um jogo (BETHKE,
2003).
Figura 10: Partes integrantes de um jogo. Fonte: (BETHKE, 2003).
33
5.4.3 O Desenvolvimento
Nessa fase os artistas começam a desenvolver os modelos 3D que formarão
o mundo do jogo com base nos storyboards, desenhos de personagens e cenários,
esses modelos podem ser cenários, personagens e outros artefatos. Para o
desenvolvimento desses modelos 3D usa-se softwares como Alias|Wavefront, Maya,
Discreet’s 3D Studio Max, Softimage e LightWave (PEDERSEN, 2003).
Figura 11: Exemplo de modelo para jogo. Fonte primária (2009)
Outros artistas criam as texturas dos modelos 3D, para isso eles usam
softwares como Adobe Photoshop, Jasc Paint Shop Pro, CorelDRAW, Microsoft’s
Paint e Equilibrium DeBabelizer (PEDERSEN, 2003).
Figura 12: Textura e modelo texturizado. Fonte primária (2009)
Já os programadores começam a escrever os códigos de programação com
base nos documentos do projeto, como diagramas UML de casos de uso (ver figura
13).
Para a programação, em geral, usa-se a linguagem C++, um IDE muito
utilizada para ela é o Microsoft Visual C++, que possui versões gratuitas para
estudantes e entusiastas sem pretensões comerciais. Boa parte do código do jogo é
extraído de bibliotecas especiais já prontas (bibliotecas de som, física, rede, gráficos
34
3D), que podem ser reutilizados em diferentes jogos. Uma parte do código é o
engine 3D (a biblioteca de gráficos 3D), uma biblioteca que gera todos os polígonos,
sombras e texturas que o usuário vê (CABRAL, 2003).
Figura 13: Casos de uso do jogo Pac-Man. Fonte: (BETHKE, 2003)
A questão dos engines também é um assunto polêmico entre os
desenvolvedores de jogos, enquanto uns preferem desenvolver além do jogo o
próprio engine, outros preferem usar engines já usados em outros jogos
(desenvolvido por eles, comprados ou livres), alegando que como há repetições de
código, haverá desperdício de tempo e dinheiro. Os desenvolvedores que preferem
desenvolver o engine alegam que criar um engine para cada jogo dá a oportunidade
de diferenciar os jogos, aumentando assim a sua competitividade (SOFTEX, 2005).
Em geral desenvolvedores casuais não desenvolvem o engine 3D, pois o
desenvolvimento desta é consideravelmente mais complexo que o desenvolvimento
do jogo em si. Em vez disto eles adquirem um engine e abstraem os aspectos mais
baixo nível como o desenho de polígonos 3D, criação de sombras e aplicação de
texturas. Existem engines livres na internet que gozam de grande respeito por parte
da comunidade desenvolvedora de jogos, como exemplos pode-se citar OGRE,
IrrLicht (PEDERSEN, 2003) e XNA que é um engine livre da Microsoft para o
desenvolvimento de jogos para PC e XBox, podendo os jogos para PC serem
comercializados livremente (LOBÃO, 2008).
Outra
parte
opcional
desempenhada
pelos
programadores
é
o
desenvolvimento da inteligência artificial, o uso de um engine físico, o uso de uma
API de sons e o uso de alguma técnica de implementação de redes se o jogo tiver a
opção de múltiplos jogadores (PEDERSEN, 2003).
Esses aspectos são opcionais por dependerem muito de jogo para jogo, há
jogos que não necessitam de inteligência artificial, há jogos que não necessitam de
35
uma física real, etc. A questão dos engines físicos é parecida com a dos engines 3D,
mas enquanto uma cuida da exibição dos gráficos 3D, a outra cria as simulações
físicas entre os objetos no mundo 3D, impedindo que uns atravessem outros,
criando gravidade, empuxo, etc. Porém há jogos que utilizam inteligência artificial
para suprimir a física real, ou seja, jogos que não necessitam de todos esses
aspectos, como jogos de ação ou corrida de carros. Existem engines físicos
proprietárias e livres, como proprietários há o Havok, entre os livres estão o ODE,
Newton, Bullet e o PhysX (PEDERSEN, 2003).
Quando todos esses aspectos são unidos no código, cria-se o jogo pronto. A
partir disso, ele deve entrar na fase de testes, onde serão corrigidos prováveis
problemas e feitos alguns aperfeiçoamentos (TYSON, 2009).
Os usuários casuais tendo o concluído o jogo, poderão lançá-lo na internet
para que este sirva como um diploma provando sua capacitação, já os grupos com
interesses comerciais iniciarão a fase de distribuição onde o jogo passará pela sua
classificação etária através de algum órgão do governo (nos EUA o ESRB,
Entertaining Software Rating Board), logo será feita uma campanha de marketing e o
jogo será distribuído no varejo através de algum fabricante que adquiriu a licença
com os desenvolvedores (TYSON, 2009).
5.4.4 Mapeamento de Texturas
Mapeamento de texturas é um método para adicionar detalhes, superfícies
texturizadas ou cores a gráficos ou modelos 3D computacionalmente gerados. A
aplicação dessa técnica foi pioneiramente usada por Edwin Catmull em sua tese de
Ph. D. em 1974 (TEXTURE MAPPING, 2009).
A técnica geralmente é utilizada para atribuir-se imagens de bitmap a objetos
3D.
Figura 14: Modelo sem textura (1), modelo com textura (2). Fonte (TEXTURE MAPPING, 2009)
36
Essas imagens, geralmente, são usadas para colorir-se um objeto (Texture
Mapping), porém pode-se usá-las para criar efeitos especiais como iluminação (Light
Mapping), relevo (Bump e Normal Mapping) e reflexo (Cube e Spherical Mapping),
entre outros (TEXTURE MAPPING, 2009).
Em um objeto 3D comum, cada vértice tem uma coordenada XYZ, já em um
objeto 3D com coordenadas de mapeamento de textura, cada vértice terá além das
coordenadas XYZ, as coordenadas UV ou UVW (UV MAPPING, 2009).
a) UV e UVW Map
As coordenadas UV se referem a uma coordenada cartesiana em uma
imagem de bitmap. Assim como X é a horizontal no espaço 3D, U é a horizontal em
uma imagem plana 2D, ou seja, um bitmap. Da mesma forma que Y é vertical, V
também é (UV MAPPING, 2009).
Figura 15: Coordenadas UV em uma superfície 3D. Fonte (AUTODESK, 2009)
Porém em algumas ocasiões precisa-se usar coordenadas UVW. A maioria
dos modeladores 3D que faz mapeamento de texturas, geralmente usa UVW e não
UV. O W é análogo ao Z, ele é a dimensão da profundidade. Pode-se pensar que
uma dimensão de profundidade em uma textura é inútil, porém isso é um engano, já
que esse valor pode ser usado em texturas 3D, como as texturas procedurais
geradas pelo 3DS Max (UVW MAPPING, 2009).
b) Unwrapping
O termo inglês wrap não tem uma tradução perfeita para o português, mas
em linhas gerais ele significa enrolar, envolver, encobrir e embrulhar. Unwrap é o
37
contrário, ou seja, desembrulhar, descobrir. É isso que se faz quando se deseja
texturizar um objeto 3D.
Quando faz-se uma projeção em um objeto 3D, obtêm-se um mapa de
coordenadas UV ou UVW, esse mapa pode ser transformado em imagem e a partir
desta pode-se desenhar e pintar uma textura.
Normalmente, a aplicação de uma única projeção em todo o modelo não é
suficiente, por isso os programas que possibilitam fazer mapeamento de
coordenadas permitem que se faça a aplicação de projeções em apenas partes do
modelo.
c) Multitexturização
Um objeto 3D pode usar mais de uma textura ao mesmo tempo. Por
exemplo, um objeto pode ter um Light Map para evitar que a iluminação seja
recalculada a cada vez que a cena for renderizada. Outras técnicas de
multitexturização são o Bump Map e o Normal Map, que permitem que se controle
diretamente a orientação das faces do objeto (normals) para propósitos de
iluminação, dando a impressão que a superfície é mais detalhada do que realmente
é, pois estas podem adicionar relevo a um simples polígono. O bump e o normal
mapping se tornaram populares quando video games puderam usá-los no final de
2003 (EBERLY, 2005).
Figura 16: Texture Map e Light Map. Fonte primária (2009)
Outros tipos de técnicas usados em multitexturização são as técnicas para
representar reflexão, como uma alternativa a GPU usar algum algoritmo raytracer
para gerar mapas de reflexão reais, que são extremamente demorados, o que é
inviável já que jogos que precisam que a cena seja renderizada em tempo real
(EBERLY, 2005).
38
As duas técnicas mais usadas para isso são o cube map (também chamado
cubic map) e o spherical map. Eles usam uma imagem que representa um suposto
ambiente ao qual refletirão, não precisando usar o ambiente real para criar o mapa
de reflexão. Por isso é comum ver essas técnicas serem chamadas de Environment
Maps, pois a projeção é estática em relação ao ambiente, ou seja, cada vez que o
objeto se movimenta, a projeção é refeita, dando a ilusão de reflexão (MICROSOFT,
2008).
O cube mapping necessita de 6 imagens para criar um cubo que envolve o
objeto reflexivo como as mostradas na figura abaixo. Há ainda formatos de arquivo
como DDS (DirectDraw Surface) que podem armazenar as 6 imagens em um só
arquivo (MICROSOFT, 2008).
Figura 17: Um Cube Map. Fonte primária (2009)
5.4.5 Tópicos Importantes de um Engine Gráfico
O engine gráfico ou de renderização é o que proporciona funções de
renderização 2D e 3D. Só pode se apoiar em bibliotecas/APIs gráficas como
OpenGL ou DirectX. Define uma camada de abstração entre o hardware/software e
o jogo em si. Além disso, ela se encarrega da visibilidade (BSP e buffers), do
mapeamento, do antialiasing e do gerenciamento das malhas 3D, entre outras
coisas (EBERLY, 2001).
a) Grafo de Cena
O grafo de cena é uma parte muito importante de uma engine. Esta é uma
estrutura de dados muito utilizada em editores gráficos baseados em vetores e em
jogos. Ele se encarrega de ordenar a representação lógica e, também as vezes,
espacial de uma cena gráfica. O grafo é formado de nodos. Cada nodo pode ter
outros nodos filhos, mas um nodo só pode ter um nodo pai. O efeito de algo sobre
39
um pai é visível em todos seus filhos. Assim, uma operação sobre um nodo se
propaga a todos os nodos filhos. Isto permite manipular (escalar/mover/rotar/etc.)
grupos de objetos como se fossem um só. Nos jogos, cada nodo só pode
representar um objeto na cena (FARIAS, 2005).
Figura 18: Representação de um grafo de cena simples. Fonte (FARIAS, 2005)
b) Modelos 3D e Texturas
Os engines gráficos, geralmente, já possuem métodos para o carregamento
de malhas 3D feitas em programas de modelagem 3D. Algumas vezes esses
engines possuem formatos de arquivos próprios para modelos 3D, como o engine
OGRE que possui o formato .MESH, embora também seja possível o uso de
bibliotecas especiais chamadas loaders que carregam um ou mais tipos de formatos
de arquivo, como 3DS, OBJ ou formatos criados pelo próprio desenvolvedor do jogo,
como geralmente é o caso das grandes companhias desenvolvedoras de jogos
(JUNKER, 2006).
Além dos formatos de arquivo de malha, um engine gráfico deve dar suporte
ao carregamento de arquivos imagem, como BMP, JPEG, PNG, TGA e DDS.
Raramente um engine tem um formato de imagem próprio (como o usado pela
Blizzard no jogo Warcraft 3, chamado de BLP, “Blizzard Picture”). Essas imagens
são utilizadas em partes da interface do jogo (menus e fontes) e na texturização de
modelos 3D (FINNEY, 2004).
c) Animação
A animação de modelos 3D é algo fundamental em um jogo. Um engine
gráfico tem como requisito indispensável dar suporte a algum tipo de animação 3D.
Basicamente existem 4 formas de animação 3D (BOUSQUET, 2006).
40
1) A animação procedural é a animação programável, sendo por essa razão
a mais poderosa, ela pode oferecer o resultado desejado pelo programador, porém
com o custo de ser complexa e precisar de muitas linhas de códigos para fazer
movimentos relativamente simples. Com esse tipo de animação é que se
movimentam personagens ao longo de um cenário 3D ou faz-se um personagem
qualquer olhar para algo. Este tipo de animação também pode controlar os outros
três tipos de animação explicados;
2) Modelo 3D com juntas é a forma de se animar mais antiga, sendo
principalmente usada para animar personagens. Foi usada em consoles de video
games antigos como o Nintendo 64 (BOUSQUET, 2006);
Figura 19: Personagem com juntas. Fonte (BOUSQUET, 2006)
3) A animação com base na malha surgiu como uma alternativa a animação
através de juntas. Ela oferece resultados mais suaves, porém difíceis de serem
criados, pois necessitam-se de muitos controladores que são manipulados
manualmente para se animar a malha. O formato de arquivo MD2 usado no jogo
Quake 2 usa esse tipo de animação (BOUSQUET, 2006).
A imagem abaixo mostra um braço e dois manipuladores necessários para
se fazer um simples movimento;
Figura 20: Animação de Malha. Fonte (BOUSQUET, 2006)
41
4) A animação através de esqueleto é a técnica mais moderna, ela oferece
resultados rápidos, podendo estas também, serem animações complexas. Este tipo
de animação também tem a vantagem de ser facilmente procedurável (BOUSQUET,
2006).
Figura 21: Personagem com esqueleto. Fonte (BOUSQUET, 2006)
Neste tipo de animação, uma estrutura esqueletal é colocada dentro do
modelo, este esqueleto é formado por bones (ossos) que quando movimentados
deformam o modelo de acordo. A associação de um modelo a um esqueleto é
chamada skinning.
Uma das ferramentas mais utilizadas para a criação de esqueletos para
personagens é o Character Studio. Esta ferramenta é um plugin do 3DS Max. Ela
permite criar animações de personagens de forma rápida e fácil (BOUSQUET,
2006).
Figura 22: Biped. Fonte (BOUSQUET, 2006)
O Character Studio possui 3 módulos: Biped, Physique e o Crowd. O Biped é
uma estrutura esqueletal humanóide (figura 67) pronta para ser inserida em um
modelo, restando apenas se fazerem pequenos ajustes. O Physique é um modifier
42
que permite que se faça o skinning do Biped em um modelo. O Crowd permite a
animação de grupos de personagens 3D usando um sistema de delegações e
comportamentos (BOUSQUET, 2006).
d) Timer
Os engines gráficos precisam de alguma técnica que permita que se
renderize mais frames ao passar do tempo. É isso que possibilita a criação do
movimento dos objetos 3D. A quantidade de frames renderizada em um segundo é
chamada FPS (Frames Per Second). Um timer é uma classe que informa o tempo
em que um novo frame deve ser renderizado, em geral a técnica mais utilizada para
isso é a ASAP (As Soon As Possible), que renderiza um novo frame após o anterior
terminar de ser renderizado. O timer pode retornar eventos que poderão ser
utilizados pelo desenvolvedor, em geral ele retorna dois eventos, um antes do frame
ser renderizado e outro após (JUNKER, 2006).
e) Luzes, sombras e neblina
Um engine gráfico 3D obrigatoriamente tem em si implementado alguma
técnica que permita a iluminação dos objetos da cena. Em geral são utilizadas Lights
(luzes), objetos que simulam a emissão de luz, afetando a aparência dos demais
objetos a sua volta. A maioria dos engines permite o controle da cor e da intensidade
dessa luz, já outras oferecem vários tipos de luzes, como luzes omnidirecionais
(points ou omnis), cônicas (spots) e direcionais (directionals ou parallels) (EBERLY,
2001).
Figura 23: Tipos de luzes. Fonte (EBERLY, 2001)
Também um engine pode utilizar alguma técnica para a criação de sombras
nos objetos 3D segundo as luzes. Existem vários algoritmos de geração de sombra,
porém os mais comuns são os baseados em texturas e no stencil buffer (JUNKER,
2006).
43
Figura 24: Luzes e sombras no engine OGRE. Fonte primária (2009)
A criação de neblina é uma função nativa das APIs gráficas como OpenGL e
DirectX, por isso é comumente implantada na maioria dos engines gráficos 3D. O
processo de geração de neblina baseia-se na aplicação de filtros durante o processo
de renderização, por esse motivo ela não é manipulada como um objeto 3D que
possa ser movimentado por exemplo (JUNKER, 2006).
Figura 25: Implementação de neblina no engine GLScene. Fonte primária (2009)
f) Céus
O processo de criação de céus para mundos 3D é bem simples e
implementado de forma similar na maioria dos engines gráficos 3D. Basicamente,
existem duas técnicas que podem mudar de nome de engine para engine e também
podem gerar versões modificadas destas (JUNKER, 2006).
1) Sky Dome - Um Sky Dome, geralmente, é uma estrutura arredondada que
possui texturas ou cores ajustáveis para representar o céu (AHEARN, 2006);
44
Figura 26: Um Sky Dome. Fonte (AHEARN, 2006)
2) Sky Box - Um Sky Box é uma estrutura cúbica que possui texturas em
cada uma de suas faces, dando a impressão de um céu (FINNEY, 2004).
Figura 27: Sky box. Fonte (FINNEY, 2004)
g) Terreno
A criação de terrenos com relevo é uma técnica que se baseia na
manipulação dos vértices de um plano 3D (chamado heightfield) seguindo como
referência uma imagem de bitmap em escala de cinzas, chamada de heightmap
(FEIL, 2005).
Figura 28: Heightfield. Fonte (FEIL, 2005)
45
Para a criação do terreno, os pixels brancos significam a maior elevação do
terreno, os pretos, as menores e os cinzas intermediários, as alturas intermediárias
(FEIL, 2005).
h) Partículas e Billboards
Partículas são objetos indispensáveis para a produção de um jogo
visualmente atrativo. Elas são basicamente polígonos de uma só face que são
gerados em grandes quantidades pelo engine para simular uma grande variedade
de fenômenos do mundo real como chuva, fumaça, névoa, água, respingos e fogo.
Elas podem ser usadas para simular qualquer entidade que altera-se como um fluido
ou gás. Até enxames de mosquitos podem ser gerados com partículas (JUNKER,
2006).
Nos jogos, cada polígono de uma face que forma a partícula é texturizado
por uma imagem com canal alpha (mostrado em negro na imagem 75), para
controlar o formato da partícula (JUNKER, 2006).
Figura 29: Billboards cobrindo um teapot. Fonte primária (2009)
Um sistema de partículas é basicamente formado por três entidades:
1) Partículas: As partículas propriamente ditas;
2) Emissor de Partículas: A entidade que possibilita existência das
partículas;
3) Nodo do Emissor de Partículas: O objeto ao qual o emissor de partículas
está anexado.
Partículas em geral são também billboards, ou seja, um polígono de uma só
face e que sempre a mantém alinhada a câmera (JUNKER, 2006).
46
i) Raycasting
Raycasting, ray-query ou picking ray são mecanismos para determinação de
colisão de um raio com um objeto 3D. Os ditos objetos 3D são bounding volumes ou
triângulos, pois é impossível matematicamente determinar se raio colide com um
conjunto de triângulos de forma irregular, ao mesmo tempo. Os bounding volumes
são sólidos geométricos simples que contém em seu interior completamente um
objeto 3D tendo o menor tamanho possível (FARIAS, 2005).
Figura 30: Modelo 3D e seu bounding volume cúbico. Fonte (WIKIPÉDIA, 2009)
Através de fórmulas matemáticas envolvendo a posição de origem do raio,
sua orientação e o bounding volume é possível se determinar o ponto em que o raio
toca o bounding volume e a orientação da normal deste. Apenas pode-se lançar um
raio em um objeto por vez para testar a colisão, não é possível lançar-se um raio
para qualquer lugar e tentar colidi-lo com qualquer objeto. Uma solução para isso é
lançar o mesmo raio várias vezes contra todos os objetos da cena, testando um por
um (FARIAS, 2005).
O raycasting é útil em editores 3D, inteligência artificial e testes de visibilidade.
Quando deseja-se testar se um raio colide com a malha de um objeto 3D e
não seu bounding volume testa-se a colisão do raio com todos os triângulos da
malha, usando um loop. Por esse motivo, quanto mais triângulos tiver a malha, mais
demorado será o teste. Uma técnica de otimização muito usada para isso é testar
primeiro se o raio colide com o bounding volume, se ele colide testa com todos os
triângulos, se ele não colide com o bounding volume, significa que não colide com
nenhum triângulo, logo é desnecessário se fazer o teste (FARIAS, 2005).
6
CRIAÇÃO DO JOGO AQUARIUS
O autor decidiu desenvolver um jogo de tiro em terceira pessoa ambientado
em um universo ficcional baseado no conto literário Aquarius da autoria do mesmo.
Para definir o cenário do jogo foi adaptado um pequeno trecho do conto onde o
personagem Aquarius deve destruir 7 andróides em um terreno desértico.
Para o desenvolvimento do jogo, foram analisados os seguintes engines e
frameworks gráficos:
a) GLScene: biblioteca para Delphi e Lazarus baseada em OpenGL. É uma
biblioteca OpenSource desenvolvida pelo alemão Mike Lischke que tem como
vantagem ser fácil de ser aprendida (GLSCENE, 2009), porém como desvantagem
ela é baseada em uma linguagem pouco usada em jogos (Object Pascal) e o
produto final não satisfaz as expectativas mais exigentes;
b) XNA: um framework para C# baseado em DirectX. Foi desenvolvido pela
Microsoft para alavancar a entrada do C# no mundo das linguagens para jogos. Ele
é livre para o desenvolvimento de jogos para PC e livre para uso não-comercial para
jogos para o console XBox (MICROSOFT, 2009). Como vantagem ele tem o poder
de usar tecnologias bem atuais e ser muito estável, sua desvantagem é requerer
uma placa de vídeo moderna para rodar até os jogos mais simples;
c) OGRE: é um engine desenvolvido pelo britânico Steve Streeting para C++ e que
abstrai a utilização de uma API gráfica, podendo dessa forma utilizar tanto DirectX
quanto OpenGL. É totalmente livre e tem a vantagem de oferecer resultados muito
satisfatórios e rodar em computadores com placas de vídeo modestas (OGRE,
2009). Sua desvantagem é o alto grau de dificuldade para se aprender a usá-lo já
48
que usa uma arquitetura totalmente orientada a objetos, sendo impossível usá-lo de
outra forma.
Com base nessas conclusões o autor decidiu utilizar o engine OGRE, por ele
usar a linguagem C++, que é a mais utilizada na criação dos jogos atualmente no
mercado (SOFTEX, 2005) e por esse engine não requerer uma placa de vídeo de
última geração, pois a placa usada pelo autor foi uma ATI Radeon 9250 (placa
lançada em 2007).
6.1
O IDE DE PROGRAMAÇÃO
Como compilador C++ foi utilizado o Microsoft Visual C++ 2005 Express com
o Microsoft Platform SDK instalado para este suprir as deficiências do Microsoft
Visual C++ 2005 Express que não dispõe dos includes básicos para programação
Windows através de código (windows.h, por exemplo), já que ele é direcionado
apenas para a programação de aplicativos que rodam no console DOS e aplicativos
Windows criados visualmente através do framework MFC (Microsoft Foundation
Classes) (SEDDON, 2005).
Além disso, para poder desenvolver aplicações com o OGRE que usem o
DirectX, deve-se ter instalado também o DirectX SDK.
6.2
FERRAMENTAS PARA CRIAÇÃO DE CONTEÚDO
Para a criação dos modelos 3D foi utilizada uma versão trial do software
Autodesk 3DS Max 8.0 com o plugin oFusion for 3D Studio Max instalado para que
se possa exportar modelos desse software para o formato “.mesh”, utilizado pelo
OGRE.
Figura 31: 3DS Max 8.0 com plugin oFusion instalado. Fonte primária (2009)
49
Para a criação das texturas foi utilizado o software Adobe Photoshop CS2
com os plugins NVidea Normal Map e NVidea DDS Exporter instalados, para que
seja dado ao Photoshop a capacidade de fazer Normal Maps e exportar imagens
para o formato DDS, respectivamente.
Figura 32: Adobe Photoshop CS2. Fonte primária (2009)
As animações dos personagens foram baixadas do site da eMotek, uma
empresa especializada em captura de movimentos para utilização em jogos e que
disponibiliza animações para uso não comercial.
Figura 33: Área de download de animações do site eMotek. Fonte primária (2009)
O terreno e o céu do jogo foram criados no software Terragen, que permite a
criação de heightfields, texturas para terreno e skyboxes.
Figura 34: Terragen. Fonte primária (2009)
50
6.3
O PROJETO
Após a delimitação do universo do jogo através da criação de um documento
de visão geral (ver anexo, item 9.1), é criado o roteiro (ver anexo, item 9.2), que
esclarece a ordem dos acontecimentos da história do jogo. Logo depois foi criado
um storyboard (ver anexo, item 9.3) e desenhos esquemáticos dos personagens (ver
anexo, item 9.4). Com base nesses desenhos foram criados os modelos e as
texturas. A partir do roteiro do jogo também é possível fazer a captura de requisitos e
com estes faz-se o diagrama de casos de uso (ver anexo, item 9.5 subitem a). Este
diagrama tem uma utilidade especial nos modelos dos personagens, pois ele diz
quais são as animações que o personagem pode realizar.
Com o diagrama de casos de uso pronto, foi feito o diagrama de classes (ver
anexo, item 9.5 subitem b) e de sequência (ver anexo, item 9.5 subitem c), a partir
de então iniciou-se a fase de programação.
6.4
A PROGRAMAÇÃO
O engine OGRE utiliza uma arquitetura totalmente orientada a objetos que
vem sendo muito utilizada nos engines modernos. Essa arquitetura pode ser
arranjada de muitas formas, porém a forma mais usada e a forma que é ensinada
nos tutoriais do site da OGRE é criar uma grande classe “aplicação” que é
instanciada e executada através de um único método no método main do código
C++ conforme pode-se ver na figura 35 e 36.
Figura 35: Funcionamento do engine OGRE. Fonte primária (2009)
51
Figura 36: Instanciamento da classe da aplicação e sua execução. Fonte primária (2009)
O método application::go da classe da aplicação dispara uma sequência de
outros métodos que criam objetos que permitem o engine seguir renderizando. Um
desses métodos é o createScene que define uma cena inicial para o universo 3D a
ser mostrado na tela. Outro método importante é o createFrameListener, que cria
uma classe capaz de retornar dois eventos, um antes de um frame ser renderizado
(frameStarted) e um depois que o frame foi renderizado (frameEnded), pela
utilização desses dois eventos é possível fazer-se interações no universo 3D da
cena em tempo real.
O engine OGRE é apenas gráfico, ou seja, ele não manipula sons ou
entradas. Para essas funções devem-se utilizar bibliotecas específicas, como o OIS
que já vem com a OGRE e é uma biblioteca especializada nessa função, podendo
manipular entrada do teclado, mouse e joysticks. O OIS pode retornar eventos
quando uma entrada específica é produzida (tecla pressionada, tecla solta, mouse
movimentado, clique com o mouse, etc.), dando mais poder ao desenvolvedor.
Figura 37: Ambiente de desenvolvimento. Fonte primária (2009)
52
Na classe da aplicação define-se que será usado um heightfield, um skybox e
faz-se a carga do modelo 3D dos personagens. Também são feitos ajustes na
escala dos modelos e no posicionamento da câmera em relação ao personagem.
Figura 38: Câmera em terceira pessoa. Fonte primária (2009)
Seguindo a hierarquia de um grafo de cena, a câmera é posicionada em um
nodo filho ao nodo do personagem. Assim quando o personagem é movimentado a
câmera o seguirá.
Após isso é definida uma posição ao personagem no centro do heightfield. A
altura dele é definida por uma ray query que é atualizado a cada novo frame, assim
o personagem sempre estará em contato com o terreno. Também é definido que o
personagem será movimentado em relação às teclas WASD e as setas direcionais
do teclado, além dele rotacionar segundo a movimentação do mouse, deixando
assim a movimentação do personagem intuitiva.
Com o pressionamento do botão esquerdo do mouse o personagem dispara
“feixes de energia” que atingirão o terreno ou os personagens inimigos. Para fazer o
sistema de movimentação dos projéteis, optou-se por se disparar um ray-query que
difinirá o ponto de partida e o de destino no projétil, então cria-se a malha do projétil
e faz-se este se movimentar entre um ponto e outro através de interpolação linear
conforme a fórmula da figura 39:
Figura 39: Interpolação linear. Fonte primária (2009)
Sendo “Vp” um vetor tridimensional que define a posição atual do projétil; “x0”,
“y0” e “z0” são elementos do vetor “V0” que é o ponto de origem; ”x1”, “y1” e “z1” são
elementos do vetor “V1” que é o ponto de destino. A variável “i” é um número real
entre 0 e 1 que define a relação do ponto atual em relação aos pontos pólos, sendo
53
o valor 0 o pólo de origem e 1 o pólo de destino e os valores intermediários, as
posições do projétil entre esses dois pontos.
Esses projéteis são inseridos em uma lista duplamente encadeada
disponibilizada pela STL chamada list. Através de um loop pode-se percorrer toda
essa lista atualizando a posição de todos os projéteis e testando-se se eles
atingiram algo para que então sejam destruídos.
Figura 40: Projéteis sendo disparados. Fonte primária (2009)
Quando um inimigo é atingido sua animação de morte é ativada e ele
explode. A explosão é um sistema de partículas formado de billboards. Esse sistema
de partículas foi feito utilizando uma ferramenta chamada Particle Accelerator que é
especializada na criação desse tipo de sistema para o engine OGRE. A explosão de
um inimigo pode ser vista na figura 41.
Figura 41: Explosão de um inimigo. Fonte primária (2009)
O jogo usa uma API de som chamada Audiere, que é fácil de ser utilizada em
qualquer aplicação C++, por precisar de pouquíssimas linhas de código para
reproduzir a maioria dos formatos de arquivo de som.
O sistema de inteligência artificial dos inimigos consiste na aproximação
destes do seu alvo (o personagem do jogador no caso) e começar a disparar quando
54
estiver a uma distância de 3 unidades deste. Cada inimigo pode disparar um tiro a
cada 0,5 segundo e possui uma mira com acurácia perfeita que deve acertar o
centro do alvo. Porém os inimigos não podem disparar enquanto andam.
6.5
DIFICULDADES ENCONTRADAS
Uma das maiores dificuldades encontradas foi o modo de programação
utilizado, pois a maioria do processamento deve ser feito em uma fração de 1/60
segundo para o jogo rodar suavemente. Quando esse processamento é demasiado
o jogo começa a sofrer os chamados “lags”, que nada mais são do que atrasos da
atualização dos frames gerados, criando um efeito de câmera lenta ou
congelamento do tempo. Para contornar esse tipo de problema teve-se de, por
exemplo, usar uma lista encadeada para armazenar os projéteis e não um vetor
dinâmico como era a primeira escolha. Isso por que cada vez que um novo elemento
é adicionado a um vetor dinâmico, deve-se alocar uma memória do tamanho do
vetor atual mais a memória para essa uma unidade, o que não é muito demorado se
forem poucos elementos, porém o problema começava a tomar outras proporções
quando cada elemento era uma instância de uma classe e passavam a quantidade
de 100 unidades. Com isso começava-se a ter “lags”. A solução foi utilizar uma lista
encadeada, que é mais difícil de manipular, porém não desperdiçava tanto tempo de
processamento em um simples adicionar de elemento.
Outra grande dificuldade encontrada foi o tempo necessário para se criar os
modelos 3D, mapear os mapas UVW destes, criar-se as texturas, criar-se os
esqueletos, animar, exportar os modelos, criar o cenário, aprender diversas
funcionalidades do engine OGRE, fundamentais para a criação de um jogo e então
programar o jogo carregando os recursos criados (modelos, texturas, animações e
cenário).
7
CONSIDERAÇÕES FINAIS
O uso de técnicas formais no desenvolvimento de um jogo é um fator
fundamental para o sucesso do projeto. Os capítulos anteriores apresentaram de
uma forma resumida as principais etapas no desenvolvimento, embora esse
processo possa variar de jogo para jogo, dependendo da metodologia preferida dos
desenvolvedores.
A não utilização de tais técnicas, geralmente, leva o projeto ao fracasso
deixando os desenvolvedores frustrados. O uso dessas técnicas é importante devida
a natureza de alta complexidade que é o desenvolvimento de um jogo, pois esta
envolve vários ramos da ciência (matemática, programação, física, inteligência
artificial) e da arte ao mesmo tempo (modelagem 3D, pintura, música).
A conclusão do jogo, também mostra que é possível um único desenvolvedor
criar um jogo. É claro, também, que quanto mais membros em uma equipe de
desenvolvimento, mais complexo e rico em detalhes será esse jogo. Segundo o wiki
Lone Developer (2009), um único desenvolvedor deve saber suas limitações e não
extrapolá-las para terminar um projeto, ele deve saber programar espertamente e
não duramente, pois ele também é um exército de um homem só (One-Man Army).
Devendo por esse motivo também ter muita rigidez em suas tarefas, afinal é
apenas ele que projeta, modela, anima, texturiza e programa. Assim, o não
comprimento de uma única etapa no desenvolvimento pode levar ao fracasso do
projeto inteiro.
8
BIBLIOGRAFIA
AHEARN, Luke. 3D Game Textures. Focal Press, Burlington, MA, EUA. 2006.
AUTODESK. 3DS Max Reference Documentation. Autodesk Inc., 2005.
BERGEN, Gino van den. Collision Detection in Interactive 3D Environments.
San Francisco, Morgan Kaufmann Publishers, 2004.
BETHKE, Erik. Game development and production. Texas, Wordware Publishing,
2003.
BOUSQUET, Michele; MCCARTHY, Michael. 3ds Max Animation with Biped.
New Riders, Califórnia, 2006.
CABRAL, A.; ADEODATO, B. & Carvalho, M. Entretenimento digital: Levando a
sério a brincadeira. FINEP, Mimeo, 2003.
EBERLY , David H.. 3D Game Engine Design: A Practical Approach to RealTime Computer Graphics. Morgan Kaufmann, San Francisco, CA, EUA. 2001.
EBERLY, David H. 3D Game Engine Architecture. California, Morgan Kaufmann,
2005.
FARIAS, Thiago Souto Maior Cordeiro de; PESSOA, Saulo Andrade; TEICHRIEB,
Verônica; KELNER, Judith. O Engine Gráfico OGRE. Universidade Federal de
Pernambuco e Escola Politécnica de Pernambuco, Recife, Pernambuco. 2005.
FEIL, John; SCATTERGOOD, Marc. Beginning Game Level Design. Thomson,
Boston, MA, EUA. 2005.
FINNEY, Kenneth C.. 3D Game Programming All in One. Thomson, Boston, MA,
EUA. 2004.
GLSCENE.
GLScene
for
Delphi
Website.
<http://www.glscene.org> Acesso em: 10 Nov. 2009.
2009:
Disponível
em:
57
JUNKER, Gregory. Pro OGRE 3D Programming. Apress, New York, NY, EUA.
2006.
LOBÃO, Alexandre; EVANGELISTA, Bruno; FARIAS, José Antonio Leal de.
Beginning XNA 2.0 Game Programming: From Novice to Professional. New
York, Apress, 2008.
LONE DEVELOPER, Wiki. Lone Developer. 2009: Disponível em:
< http://gpwiki.org/index.php/Lone_developer > Acesso em 10 Jul. 2009.
MICROSOFT. DirectX Documentation For C++. Microsoft Corporation, 2008.
MICROSOFT. XNA Game Studio. 2009: Disponível em:
<http://www.microsoft.com/downloads/details.aspx?FamilyId=7D70D6ED-1EDD4852-9883-9A33C0AD8FEE&displaylang=en#top> Acesso em: 10 Mar. 2009.
NORMAL MAPPING, Wikipedia. Normal Mapping. 2009. Disponível em:
<http://en.wikipedia.org/wiki/Normal_mapping> Acesso em: 19 Set. 2009.
OGRE. Object-Oriented Graphics Rendering Engine Website. 2009: Disponível
em: http://www.ogre3d.org Acesso em: 10 Nov. 2009.
PEDERSEN, Roger E. Game Design Foundations. Texas, Wordware Publishing,
2003.
SEDDON, Chris. OpenGL Game Development. Texas, Wordware Publishing,
2005.
SOFTEX, Observatório Digital. Tecnologias de visualização na indústria de
jogos digitais: potencial econômico e tecnológico para a indústria brasileira
de software. Campinas, Softex, 2005.
TEXTURE MAPPING, Wikipedia. Texture Mapping. 2009. Disponível em:
<http://en.wikipedia.org/wiki/Texture_mapping> Acesso em: 19 Set. 2009.
TYSON, Jeff. Como a 3DO cria videogames; 2009: Disponível em:
<http://eletronicos.hsw.uol.com.br/como-a-3do-cria-videogames.htm> Acesso em:
16 Mar. 2009.
UV
MAPPING,
Wikipedia.
UV
Mapping.
2009.
Disponível
<http://en.wikipedia.org/wiki/UV_mapping> Acesso em: 19 Set. 2009.
em:
UVW MAPPING, Wikipedia. UVW Mapping. 2009. Disponível em:
< http://en.wikipedia.org/wiki/UVW_mapping> Acesso em: 19 Set. 2009.
WIKIPÉDIA. Bounding Volume. 2009. Disponível em: <http://en.wikipedia.org/wiki/
Bounding_volume> Acesso em 29 Jun. 2009.
9
9.1
ANEXO: PROJETO DO JOGO AQUARIUS
DESCRIÇÃO DO SISTEMA
É proposto o desenvolvimento de um jogo 3D de tiro em terceira pessoa,
ambientando em uma realidade fictícia, onde o personagem Aquarius que é o
personagem controlado pelo jogador, deve derrotar sete personagens inimigos,
sendo estes os andróides Haytrons. O personagem do jogador poderá se locomover
livremente pelo cenário e disparar feixes de energia nos inimigos, que se acertarem,
os destruirão. Os inimigos também dispararão contra o personagem do jogador,
ferindo este se acertar e o derrotando depois de um limite de 10 acertos.
9.2
ROTEIRO DO JOGO
a) Personagens:
1) Raiwr Aquarius: Sexo masculino, ruivo, usa um traje negro futurista;
2) Hait Mevelly: Sexo feminino, loira, usa um traje negro e rosa;
3) Andróides Haytrons: Autômatos antropomorfos de 2,5 metros de altura e
longas garras no lugar dos dedos dos pés e mãos;
b) Cenário:
Planeta MBK-34 Nakkin: Planeta desértico com brisa eterna;
c) Cena Única:
Horário: Fim de tarde
59
Aquarius chega ao planeta Nakkin, onde deve derrotar os sete Haytrons
guardiões da frota fantasma para adquirir esta e ajudar a Resistência Rebelde a
fortalecer sua frota que foi dizimada em uma batalha espacial anterior.
Os Haytrons são andróides de uma tecnologia ancestral muito evoluída,
seres autômatos formados de ligas metálico-orgânicas, extremamente flexíveis e
resistentes. Possuem geradores de campos de força que os protegem de agressões
exteriores, além de possuírem um driver de plasma de íons de sódio (razão esta de
seus feixes de energia serem vermelho-alaranjados) que usam para atacar se
necessário. Quando um Haytron é danificado irreversivelmente ele se auto-destrói
numa violenta explosão para proteger sua tecnologia e danificar seus agressores.
Aquarius usa um gerador de campo de força para se proteger e uma
pequena arma com driver de plasma de íons de chumbo.
Aquarius entra em combate com os Haytrons que se mostram implacáveis e
possuidores de uma acurácia perfeita em seus disparos, porém Aquarius vai
derrotando um a um os Haytrons, ao perceber que estes não possuem uma
inteligência muito desenvolvida.
Com os guardiões derrotados Aquarius encontra a frota fantasma e chama
as tropas Rebeldes para que estas levarem-na.
9.3
STORYBOARD
Figura 42: Storyboard do jogo Aquarius. Fonte primária (2009)
60
9.4
ESQUEMA DOS PERSONAGENS
a) Andróides Haytrons
Figura 43: Haytron. Fonte primária (2009)
c) Mevelly
Figura 45: Mevelly. Fonte primária (2009)
b) Aquarius
Figura 44: Aquarius. Fonte primária (2009)
61
9.5
DIAGRAMAS UML
a) Casos de Uso
b) Classes
c) Sequência