U F PA
UNIVERSIDADE FEDERAL DO PARÁ
JOGO DA CABANAGEM: PROJETO E IMPLEMENTAÇÃO.
FELIPE VAZ DOS REIS
INSTITUTO DE TECNOLOGIA
UNIVERSIDADE FEDERAL DO PARÁ
BELÉM – PARÁ
2009
i
UNIVERSIDADE FEDERAL DO PARÁ
INSTITUTO DE TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
FELIPE VAZ DOS REIS
JOGO DA CABANAGEM: PROJETO E IMPLEMENTAÇÃO
TRABALHO
SUBMETIDO
AO
COLEGIADO DO PROGRAMA
DE
PÓS-GRADUAÇÃO
EM
ENGENHARIA ELÉTRICA PARA
OBTENÇÃO
MESTRE
ELÉTRICA.
Belém – PA
2009
DO
EM
GRAU
DE
ENGENHEIRA
ii
JOGO DA CABANAGEM: PROJETO E IMPLEMENTAÇÃO.
Este Trabalho foi julgado em ___/___/_____ adequado para obtenção de
mestre em Engenheira Elétrica, e aprovado na sua forma final pela banca
examinadora que atribuiu o conceito ________________________.
_____________________________________
Prof. Dr. Manoel Ribeiro Filho
ORIENTADOR
_____________________________________
Prof. Dr. Roberto Célio Limão de Oliveira.
CO-ORIENTADOR
_____________________________________
Prof. Dr. Carlos Renato Lisboa Francês
MEMBRO DA BANCA EXAMINADORA
_____________________________________
Prof. Dr. Eloi Luis Favero
MEMBRO DA BANCA EXAMINADORA
_____________________________________
Prof. Dr. Bianchi Serique Meiguins
MEMBRO DA BANCA EXAMINADORA
_____________________________________
Prof. Dr. Marcus Vinicius A. Nunes
COORDENADOR DO PROGRAMA DE PÓSGRADUAÇÃO EM ENGEHARIA ELÉTRICA
Belém – PA
2009
iii
“Pedi e se vos dará. Buscai e achareis.
Batei e vos será aberta. Porque todo
aquele
que
pedir,
recebe.
Quem
busca, acha. A quem bate, abrir-se-á”.
Mt 7, 7- 8
iv
AGRADECIMENTOS
Primeiramente, quero agradecer a Deus por todas as conquistas da
minha vida. A minha esposa Solange, por todo amor, carinho, compreensão e
amizade que me proporciona. Aos meus pais, por todo carinho, compreensão,
educação e amizade que me foram dados.
A todos os professores que, de uma forma ou outra, contribuíram para
minha formação acadêmica.
A todos os meus amigos e colegas da Universidade Federal do Pará e
em especial do LaRV (Laboratório de Realidade Virtual) que contribuíram direta
ou indiretamente para o êxito deste trabalho.
Felipe Vaz dos Reis
v
RESUMO
Esta dissertação descreve o desenvolvimento de um motor de jogo para
uso educacional, construído usando ferramentas livres. Motor de jogo é um
conjunto de bibliotecas e/ou programas que oferecem funcionalidades para o
desenvolvimento de jogos eletrônicos. Motor de jogo é a parte principal de um
jogo eletrônico, pois oferece os mecanismos para funcionamento de um jogo. O
motor de jogo proposto neste trabalho é um motor de jogo puramente 3D que
oferece recursos de simulação física, simulação sonora 3D, detecção de
colisão, inteligência computacional e scripting usando a linguagem de
programação lua. O motor foi todo desenvolvido usando ferramentas livres e
utilizando a linguagem de programação C++. O objetivo deste motor é oferecer
recursos e facilitar o desenvolvimento de jogos educativos. Como estudo de
caso foi implementado um jogo educativo sobre a Revolução da Cabanagem.
É descrito nesta dissertação um estudo sobre jogos eletrônicos e
motores de jogos. Também é descrito o motor de jogo desenvolvido, mostrando
a sua estrutura e funcionamento e no final mostras as conclusões sobre o
desenvolvimento do motor e sobre os trabalhos futuros.
vi
ABSTRACT
This thesis describes the development of a game engine for educational
use, built using free tools. Game engine is a set of libraries and / or software
that provide functionality for the development of electronic games. Game engine
is the main part of an electronic game, it offers mechanisms for the operation of
a game. The game engine proposed in this paper is a purely 3D game engine
that offers resources for physical simulation, 3D sound simulation, collision
detection, computational intelligence and scripting programming language,
using the moon. The engine was developed using all available tools and using
the programming language C + +. The objective of this engine is to provide
resources and facilitate the development of educational games. As a case study
was implemented an educational game on the Revolution of Cabanagem.
It is described in this thesis a study on electronic games and game engines.
Also described is the engine of the game developed, showing its structure and
operation, and at the end shows the findings on the development of the engine
and on future work.
vii
viii
SUMÁRIO
CAPÍTULO 1 – INTRODUÇÃO......................................................................................................... 14
CAPÍTULO 2 – JOGOS ELETRÔNICOS.......................................................................................... 18
2.1
BREVE HISTORICO ........................................................................................................ 18
2.2
DEFINIÇÃO...................................................................................................................... 21
2.3
GÊNEROS OU TIPOS DE JOGOS ELETRONICOS ....................................................... 22
2.3.1
Ação ........................................................................................................................................ 22
2.3.2
Aventura ................................................................................................................................ 23
2.3.3
Estratégia .............................................................................................................................. 24
2.3.4
RPG ......................................................................................................................................... 24
2.3.5
Esporte ................................................................................................................................... 25
2.3.6
Simulação .............................................................................................................................. 26
2.3.7
Quebra-Cabeça ................................................................................................................... 26
2.3.8
Passatempo ........................................................................................................................... 27
2.3.9
Educacional .......................................................................................................................... 28
2.4
JOGOS EDUCACIONAIS ................................................................................................ 28
2.4.1
Exemplos de Jogos Educacionais .................................................................................. 31
2.4.1 Triade .................................................................................................................................. 30
2.4.2 Games-To-Teach .............................................................................................................. 31
2.4.3 Laguna
2.4.4
2.5
– Aprendendo sobre a guerra do Paraguai com jogo educativo ....... 32
Jogo educativo sobre a Revolução da Cabanagem – Fase Pré-Revolucionária
CONSIDERAÇÕES FINAIS ..............................................................................................34
CAPÍTULO 3 – MOTOR DE JOGO .................................................................................................. 35
3.1
BREVE HISTORICO ........................................................................................................ 35
3.2
DEFINIÇÃO...................................................................................................................... 36
3.2.1
Módulo gráfico ......................................................................................................................... 37
3.2.2
Módulo de física ...................................................................................................................... 38
3.2.3
Módulo de interface com usuario ............................................................................................. 38
3.2.4
Módulo de som ......................................................................................................................... 38
3.2.5
Módulo de Inteligência Computacional ................................................................................... 38
3.2.6
Módulo de rede......................................................................................................................... 39
3.3
ESTRUTURA ................................................................................................................... 39
3.4
TRABALHOS RELACIONADOS...................................................................................... 42
3.4.1
enJine – Um motor de jogos educacionais em java.................................................................. 42
33
ix
3.4.2
J3DTOOL – Um motor para desenvolvimento de jogos educacionais em Java3D.................. 42
3.4.3
STEAMie................................................................................................................................... 43
3.4.4
SAGE – A simple academic game engine ................................................................................. 44
3.4.5
Alice.......................................................................................................................................... 45
3.4.5
Comparativo entre os motores.................................................................................................. 46
3.5
CONSIDERAÇÕES FINAIS ..............................................................................................46
CAPÍTULO 4 – MOTOR PROPOSTO ............................................................................................. 47
4.1
CARACTERISTICAS ....................................................................................................... 47
4.2
ARQUITETURA ............................................................................................................... 49
4.3
FRAMEWORK ..................................................................................................................50
4.4
GERENCIADORES ......................................................................................................... 53
4.5
INTERFACES .................................................................................................................. 55
4.6
SISTEMAS ....................................................................................................................... 55
4.6.1
Sistema de Renderização Gráfica e Interface Gráfica ............................................................ 56
4.6.2
Sistema de Física ...................................................................................................................... 56
4.6.3
Sistema de Intligencia Computacional ..................................................................................... 59
4.6.4
Sistema de Som ......................................................................................................................... 68
4.6.5
Sistema de Interface com usuario............................................................................................. 73
4.7
FUNCIONAMENTO DO MOTOR ...............................................................................................
73
4.7.1
Instanciação do conteudo ......................................................................................................... 73
4.7.2
Inicialização do motor e sistemas............................................................................................. 73
4.7.3
Atualização do motor e sistemas .............................................................................................. 73
4.8
CONSIDERAÇÕES FINAIS ..............................................................................................74
CAPÍTULO 5 – CONCLUSÕES........................................................................................................ 75
REFERÊNCIAS BIBLIOGRÁFICAS................................................................................................. 77
APENDICE A – ESTUDO DE CASO................................................................................................ 86
APENDICE B - DIAGRAMA DE CLASSES DO NÚCLEO DO MOTOR ....................................... 119
APENDICE C - DIAGRAMA DE CLASSES DO SISTEMA FUZZY ............................................... 120
APENDICE D - CÓDIGO FONTE EXEMPLO DO USO DO MOTOR PROPOSTO....................... 121
x
LISTA DE FIGURAS
Figura 2.1 – Space War. ....................................................................................... 17
Figura 2.2 – Tênis para dois.................................................................................. 18
Figura 2.3 – Computer Space. .............................................................................. 18
Figura 2.4 – Magnavox Odyssey........................................................................... 19
Figura 2.5 – Wolfstein 3D.. .................................................................................... 20
Figura 2.6 – Doom III............................................................................................. 22
Figura 2.7 – The Legendo of Zelda ....................................................................... 22
Figura 2.8 – Age of Empire III................................................................................ 23
Figura 2.9 – Final Fantasy 13................................................................................ 24
Figura 2.10 – Winning Eleven 7. ........................................................................... 24
Figura 2.11 – Flight Simulator 2008. ..................................................................... 25
Figura 2.12 – Tetris ............................................................................................... 26
Figura 2.13 – The Sims 3. ..................................................................................... 27
Figura 2.14 – Jogo Brain Age................................................................................ 27
Figura 2.15 – Triade - Jogo educativo sobre a Revolução FrancesI. .................... 30
Figura 2.16 – Jogo Revolution – Jogo sobre a guerra civil americanI. .................. 31
Figura 2.17 – Imagens dos cenários da vila (a) e de uma das tribos (b)............... 32
Figura 2.18 – Jogo educativo sobre a revolução da cabanagem – Fase PréRevolucionária....................................................................................................... 33
Figura 3.1 – Diagrama de um motor de jogo modular genérico. ........................... 40
Figura 3.2 – Telas de jogos desenvolvidos com o motor enJine. .......................... 42
Figura 3.3 – Jogo AITEM desenvolvido usando o motor J3DTOOL...................... 43
Figura 3.4 – Image do jogo FORCE AND MOMENTUM. ...................................... 44
Figura 3.5 – Ned’s Turkey Farm............................................................................ 44
Figura 3.6 – Alice editor. ....................................................................................... 45
Figura 4.1 – Arquitetura do motor.......................................................................... 48
Figura 4.2 – GameObject. ..................................................................................... 50
Figura 4.3 – SceneObject do tipo Mesh. ............................................................... 50
Figura 4.4 – Scene Object do tipo Luz.. ................................................................ 51
Figura 4.5 – Scene Object do tipo Terreno............................................................ 51
Figura 4.6 – Diagrama de Classes do Sistema de Física..................................53
Figura 4.7 – Sistema de Inteligência Computacional.. .......................................... 58
Figura 4.8 – Diagrama de Classes do sistema de inteligência computacional...... 59
xi
Figura 4.9 – IAObject. ........................................................................................... 60
Figura 4.10 – Diagrama de Interação que mostra o ciclo de processamento
realizado por um
IAObject................................................................................................................. 61
Figura 4.12 – Raio do Sensor de Visão................................................................. 62
Figura 4.13 – Cabanos com os seus sensores do tipo EyeSensor.. ..................... 62
Figura 4.14 – Relacionamento dos tipos de Behaviour. ........................................ 63
Figura 4.15 – Diagrama de classe do Módulo que implementa a maquina de
estados finitos.. ..................................................................................................... 64
Figura 4.16 – Diagrama de Classes do Módulo que implementa Sistema Fuzzy.. 65
Figura 4.17 – Comparativo entre Som Estéreo e Som 3D: em (a) e (b) o som
estéreo permanece constante independente da movimentação do usuário; em
(c) e (d) o ponto de recepção do som é influenciado pelos movimentos do
personagem e componentes do
cenário. ................................................................................................................. 68
Figura 4.18 – Diagrama de Classes do Sistema de som. ..................................... 69
Figura I.1 – Gerenciador de Estado. ..................................................................... 75
Figura I.2 – Estado de Jogo.. ................................................................................ 75
Figura I.3 – Diagrama de estados do jogo. ........................................................... 76
Figura I.4 - Fluxo do game loop............................................................................. 78
Figura I.5 - Menu Principal.. .................................................................................. 79
Figura I.6 - Escolha das Missões.. ........................................................................ 80
Figura I.7 - Vídeo Introdutório da Missão... ........................................................... 81
Figura I.8 - Inventário da Missão... ........................................................................ 81
Figura I.9 - Cenário da Missão... ........................................................................... 82
Figura I.10 - Personagens da Missão: Cabano, escravo, lenhador e um
soldado.................................................................................................................. 82
Figura I.11 - Inicio da Missão... ............................................................................. 83
Figura I.12 - Personagem próximo ao objetivo...................................................... 84
Figura I.13 - Fim da Missão Belém 1820 – 183I.................................................... 84
Figura I.14 - Tela introdutória da Missão Fundar o jornal “O Paraense”... ............ 85
Figura I.15 - Inventário da Missão... ...................................................................... 86
Figura I.16 - Cenário da Missão... ......................................................................... 86
Figura I.17 - Personagens da Missão: Felipe Patroni, Batista Campos, soldado
e um
cabano................................................................................................................... 87
xii
Figura I.18 - Inicio da Missão.... ............................................................................ 88
Figura I.19 - Personagem próximo ao objetivo...................................................... 88
Figura I.20 - Felipe Patroni capturado por um soldado.. ....................................... 89
Figura I.21 - Fim da Missão Jornal O Paraense... ................................................. 89
Figura I.22 - Tela introdutória da Missão............................................................... 90
Figura I.23 - Inventário da Missão... ...................................................................... 90
Figura I.24 - Cenário da Missão. ........................................................................... 91
Figura I.25 - Personagens da Missão: Batista Campos e um soldado.... .............. 91
Figura I.26 - Inicio da Missão Batista Campos.... .................................................. 92
Figura I.27 - Personagem Batista Campos remando num bote............................. 93
Figura I.28 - Personagem Batista Campos sendo morto por um soldado.... ......... 93
Figura I.29 - Fim da Missão................................................................................... 94
Figura I.30 - Vídeo Introdutório da Missão.... ........................................................ 94
Figura I.31 - Inventário da Missão do Acará.......................................................... 95
Figura I.32 - Personagens da Missão: Cabano, Escravo, Lenhador, Fèlix
Malcher e
Francisco Vinagre. ................................................................................................ 96
Figura I.33 - Personagem Félix Malcher e a interface........................................... 96
Figura I.34 - Viagem entre as fazendas.... ............................................................ 97
Figura I.35 - Inventário da Missão. ........................................................................ 98
Figura I.36 - Personagens da Missão: Cabano, Escravo, Lenhador, Soldado,
Comandante,
Francisco Vinagre e Angelim................................................................................. 98
Figura I.37 - Angelim e vários cabanos indo atacar o quartel. .............................. 99
Figura I.38 - Vídeo sobre o ataque no Acará....................................................... 100
Figura I.39 - Vídeo introdutório da Missão.. ........................................................ 101
Figura I.40 - Inventário da Missão. ...................................................................... 101
Figura I.41 - Cenário da Missão.. ........................................................................ 102
Figura I.42 - Personagens da Missão.................................................................. 102
Figura I.43 - Começo da missão... ...................................................................... 103
Figura I.44 - Cabanos aguardando pelo Angelim... ............................................. 104
Figura I.45 - Morte do presidente português. ...................................................... 104
xiii
14
CAPÍTULO 1 – INTRODUÇÃO
Motor de jogo é o componente principal de um jogo eletrônico. O motor é
responsável pelo funcionamento interno do jogo, abstraindo a complexidade de
seu funcionamento, oferecendo funcionalidades para um bom desempenho de
um jogo.
Motores de jogos é um conjunto de bibliotecas e/ou programas que
fornecem funcionalidades para o desenvolvimento de jogos eletrônicos. Ele
permite que vários jogos possam ser criados com o uso de um mesmo motor
de jogo e alguns ainda permitem o uso de ferramentas que auxiliam na
produção de conteúdos de um jogo, tais como um editor de cenários,
modeladores, exportadores de formatos 3D, entre outros.
Para a produção de um jogo é necessário o uso de um motor de jogo,
pois facilita o desenvolvimento, permitindo que o programador não precise
saber os detalhes de implementação, mas apenas das funcionalidades
fornecidas pelo motor.
Contudo, utilizar um motor de jogo requer certo investimento financeiro,
pois dependendo de seus recursos oferecidos, alguns motores possuem
preços bastante altos, o que inviabiliza o projeto de jogos eletrônicos
educacionais.
Atualmente, existem alguns motores de jogos livres para uso
educacional, contudo esses motores possuem varias limitação tanto em termos
computacionais quanto em conteúdo. Por exemplo, podemos citar os motores
enJine[37], J3DTOOL[33], SAGE[55], STEAMie[41] e Alice[1].
enJine é um motor de jogo desenvolvido usando a API Java3D, que
oferece os recursos de som estéreo 2D, detecção de colisão, sistema de
colisão e sistema de animação. Contudo, não oferece recursos de som 3D,
simulação física e sistema de inteligência computacional.
J3DTOOL é um motor também desenvolvido usando a API Java3D com
recursos mais limitados que o motor Enjine, oferecendo apenas os recursos de
animação e som 2D.
15
SAGE é um motor de jogo desenvolvido usando a API DirectX,
oferecendo um sistema de animação, sistema de som estéreo 2D. Além de
suas
limitações,
o
motor
foi
desenvolvido
para
o
aprendizado
de
desenvolvimento de jogos, ou seja, o objetivo deste motor é o aprendizado
sobre o desenvolvimento de jogos.
Alice é um motor de jogo desenvolvido usando a API Java3D, que
possui os mesmos propósitos que o motor SAGE. Alice possui um editor no
qual o aluno poderá construir o ambiente do jogo/simulação, aplicando os
conceitos de linguagem de programação.
STEAMie é um motor de jogo desenvolvido usando a API DirectX,
oferecendo vários recursos, tais como: sistema de som estéreo, sistema de
animação, sistema de física e detecção de colisão, sistema de interface gráfica
entre outros. Esse motor é o mais completo do que todos os outros motores,
contudo não oferece um sistema de inteligência computacional.
Esses motores citados anteriormente não possuem todos os recursos
necessários para o desenvolvimento de jogos, de forma que para desenvolver
um jogo mais elaborado usando estes motores é necessária uma codificação
sobre o código fonte deste e/ou também um estudo sobre uma biblioteca que
forneça os recursos necessários.
O objetivo deste trabalho é a proposta de um motor de jogo que permita
o desenvolvimento de jogos eletrônicos com mais recursos computacionais que
os motores citados anteriormente, tais como o uso de um sistema de
renderização gráfica 3D, que suporte Shaders, CG, sistema de partículas,
etc.Um sistema de física realística com detecção de colisão e sistema de
movimentação de personagens. Um sistema de som 2D e 3D estéreo. Um
sistema de inteligência computacional através do uso de scripts, máquinas de
estados finitos e sistema Fuzzy. De forma que possam ser desenvolvidos jogos
eletrônicos
com
mais
qualidade
técnica
e
também
facilitando
o
desenvolvimento de aplicações/jogos que possam utilizar o motor.
Como estudo de caso foi desenvolvido um jogo educacional sobre a
Revolução da Cabanagem, que é um jogo que mescla os estilos de aventura,
ação, estratégia e educacional e tem como o objetivo mostrar ao jogador
16
através do uso do jogo a história da Revolução Cabana, através do controle e
diálogos dos personagens que foram importantes para o movimento, do enredo
que foi baseado nos acontecimentos históricos e das informações que são
mostradas ao jogador.
O motor foi desenvolvido usando as características de orientação a
objetos, totalmente implementado usando a linguagem de programação C++ e
com uma arquitetura flexível e modular, permitindo a expansão de suas
funcionalidades.
O motor utiliza diversas bibliotecas e APIs, tais como o Ogre3D[25] para
a renderização gráfica 3D, NVidia PhysX[45] para a colisão de objetos e
simulação física, FMOD[18] e OpenAL[43] para a simulação sonora, CEGUI[8]
para a interface com usuário, a biblioteca OIS[42] para o controle da interface
de entrada e saída com o usuário, utilização de scripts na linguagem Lua[32]
para a configuração do comportamento dos personagens e opcionalmente
possibilita a codificação do jogo/aplicação.
O motor de jogo desenvolvido é uma parte do projeto sobre a construção
de um Jogo Eletrônico Lúdico Educacional de Estratégia a Revolta da
Cabanagem que foi financiado pela CHAMADA PÚBLICA: MCT/FINEP/MEC Jogos Eletrônicos Educacionais 02/2006.
Esta
dissertação
está
dividida
em
fundamentação
teórica,
desenvolvimento e conclusões.
No capítulo 2 é apresentada uma fundamentação teórica sobre jogos
eletrônicos. É mostrado neste capítulo um breve histórico, definições e jogos
tipos ou gêneros de jogos eletrônicos. Por último, mostra um estudo sobre
jogos eletrônicos educativos, mostrando algumas considerações e uns
exemplos de jogos educativos.
No capítulo 3 é apresentado um estudo sobre motores de jogos. São
mostrados neste capítulo um breve histórico, a definição e a estrutura de
motores de jogos. Por último, são mostrados os trabalhos relacionados.
No capítulo 4 é apresentado o motor de jogo proposto. São mostradas
neste capítulo as características do motor desenvolvido, a arquitetura proposta.
17
O capítulo mostra os componentes que fazem parte do motor e no final mostra
as etapas de funcionamento do motor.
No capítulo 6 são apresentadas as conclusões finais sobre o presente
trabalho e sobre os estudos e pesquisas realizadas.
No apêndice A é apresentado o estudo de caso, que é o jogo eletrônico
educacional sobre a revolução da cabanagem. É mostrado neste apêndice o
processo de implementação, a estrutura do jogo e o jogo.
No apêndice B é mostrado o diagrama de classes do núcleo do motor
desenvolvido.
No apêndice C é mostrado o diagrama de classes do sistema fuzzy
desenvolvido para o subsistema de inteligência computacional.
No apêndice D é mostrado um código fonte exemplo do motor
desenvolvido.
18
CAPÍTULO 2 – JOGOS ELETRÔNICOS
Neste capítulo será mostrado um estudo sobre jogos eletrônicos
mostrando um breve histórico, definição e tipos de jogos eletrônicos. Por fim é
mostrado um breve estudo sobre jogos educativos.
2.1. BREVE HISTÓRICO
A história dos jogos pode ser dividida em: antes da década de 70,
décadas de 70, 80, 90 e 2000, e através das diferentes tecnologias utilizadas
em diferentes épocas.
Antes da década de 70, algumas empresas e pessoas já começavam a
dar os primeiros passos na criação de jogos. Uma das principais empresas da
indústria, a Nintendo, começou como uma empresa que fabricava cartas de
baralho. Segundo a linha de tempo encontrada em [27] esse é o primeiro
marco da história dos jogos eletrônicos (pelo fato que a Nintendo hoje está no
mercado de jogos eletrônicos). Ainda, desde o início do século XX, [27] e [15]
consideram máquinas como a Gottlieb Baffle Ball os precursores das máquinas
de pinball, que hoje em dia são máquinas de jogos eletrônicos.
O primeiro jogo eletrônico interativo criado na história foi o Spacewar,
mostrado na Figura 2.1, um jogo onde duas pessoas controlavam dois tipos
diferentes de espaço-nave que deveriam combater entre si. Esse jogo foi
programado por um estudante do MIT, Steve Russell, em um computador PDP1 em 1961 [15].
Figura 2.1 Space War
19
Existem alguns historiadores, porém, que argumentam que o primeiro
jogo eletrônico foi o “Tênis para dois” que foi criado por Willy Higinbotham,
mostrado na Figura 2.2, um cientista do Brookhaven National Laboratory.
Higinbotham programou, em 1958, um osciloscópio onde era possível jogar
uma partida de tênis interativa [27].
Figura 2.2 Tênis para dois
Em 1970, Nolan Bushnell começou a trabalhar em uma versão fliperama do
jogo Spacewar, chamada Computer Space, mostrado na Figura 2.3. No ano
seguinte, a empresa Nutting Associates comprou o jogo de Bushnell, colocando
no mercado a primeira máquina de fliperama da história.
Figura 2.3 Computer Space
Em 1972, Bushnell abre sua própria empresa, a Atari, famosa pelo jogo Pong
(criado pelo engenheiro Al Alcorn). Até o fim da dessa década, muitas
empresas entraram no mercado de jogos, como Taito, Midway e Capcom, além
da Magnavox lançar em 1972 o computador Odyssey, mostrado na Figura 2.4
[27].
20
Figura 2.4 Magnavox Odyssey
Seguindo a linha de tempo dos jogos em [27], nos anos 80 as máquinas
de fliperama estavam em seu auge, com muitos jogos sendo lançados (Donkey
Kong, Tron e Q*Bert são alguns exemplos) ao mesmo tempo em que surgiram
os primeiros videogames 8-bit: Famicom, da Nintendo e Master System, da
SEGA (Service Games).
Na área de jogos para computador, houve também um grande
lançamento de jogos e criação de empresas, sendo a On-Line Systems (atual
Sierra Online) uma das pioneiras no setor de jogos para computador [15].
Em março de 1986, Chris Crawford [11] reuniu alguns amigos
desenvolvedores em sua casa para a primeira Computer Game Developers
Conference (atual GDC), onde discutiram assuntos sobre game design e
negócios.
A década de 90 foi marcada pelo lançamento e batalhas de videogames
de 16-bit (Sega Genesis e Super Famicom, da Nintendo), de 32-bit (PlayStation
da Sony e Sega Saturn) e o lançamento de videogames como 3DO da
Panasonic e Nintendo64 da Nintendo (esse de 64-bit) [27].
Um grande marco para a história de jogos para computador foi o
lançamento do jogo Wolfstein 3D pela id Software em 1991, mostrado na
Figura 2.5, o primeiro jogo de tiro em primeira pessoa, atualmente um dos
gêneros de jogos mais famosos entre os jogadores [30].
21
Figura 2.5 Wolfstein 3D.
No final da década de 90 para 2000, Sony e Nintendo divulgaram seus
novos videogames de 128-bit (PlayStation 2 e GameCube, respectivamente),
enquanto a Microsoft também entrou para esse segmento. Atualmente, a
atenção da mídia e dos jogadores está voltada aos jogos online multiplayer
massivos (centenas a milhares de pessoas jogando ao mesmo tempo num
mundo virtual via internet) e aos videogames portáteis Sony PSP e Nintendo
DS (esse inovando com duas telas, sendo uma delas sensíveis ao toque, como
em PDA’s).
2.2 DEFINIÇÃO
Um Jogo eletrônico pode ser definido como um sistema composto de
três partes básicas: enredo, motor e interface interativa. O sucesso de um
jogo está associado à combinação perfeita destes componentes. [4].
O enredo define o tema, a trama, o(s) objetivo(s) do jogo, o qual através
de uma série de passos o usuário deve se esforçar para atingir. A definição da
trama não envolve só criatividade e pesquisa sobre o assunto, mas também a
interação com pedagogos, psicólogos e especialistas no assunto a ser
enfocado pelo jogo.
A interface interativa controla a comunicação entre o motor e o usuário,
reportando graficamente um novo estado do jogo. O desenvolvimento da
interface envolve aspectos artísticos, cognitivos e técnicos. O valor artístico de
uma interface está na capacidade que ela tem de valorizar a apresentação do
jogo, atraindo usuários e aumentando a sua satisfação ao jogar. O aspecto
cognitivo está relacionado à correta interpretação da informação gráfica pelo
22
usuário. Note-se que em termos de jogos educacionais, a interface deverá
obedecer a critérios pedagógicos. O aspecto técnico envolve desempenho,
portabilidade e a complexidade dos elementos gráficos.
O motor do jogo é o seu sistema de controle, o mecanismo que controla
a reação do jogo em função de uma ação do usuário. A implementação do
motor envolve diversos aspectos computacionais, tais como, a escolha
apropriada da linguagem de programação em função de sua facilidade de uso
e portabilidade, o desenvolvimento de algoritmos específicos, o tipo de
interface com o usuário, etc.
2.3 GÊNEROS OU TIPOS DE JOGOS
Do fato que as pessoas são diferentes entre si, cada uma com seus
gostos e opiniões, os jogos possuem a capacidade de envolver os mais
diversos tipos de jogadores por serem diversificados em suas classes. Em
continuidade, caracterizar um jogo como um conjunto de estilos é mais
apropriado do que determiná-lo em uma só categoria. Ou seja, um jogo pode
ser mais estratégico que o outro, além de permitir que um jogo seja de vários
estilos diferentes.
Os estilos propostos por [52], [44] e [54] podem ser caracterizados da
seguinte forma:
2.3.1 Ação: Representam uma grande faixa de estilos de jogos, podendo estes
tanto ser encontrados com gráficos 3D, quanto com gráficos 2D. Geralmente
eles são divididos em dois subgêneros: aqueles em que se atira e aqueles em
que não se atira. As principais habilidades que este tipo de jogo explora no
jogador são o tempo de reação e a coordenação entre a visão e as mãos do
jogador em situações de pressão. Fazem parte desse gênero jogos de luta,
como Street Fighter, jogos de tiro, como DOOM III mostrado na Figura 2.6,
jogos tipo labirinto, como Pac-Man, Mario, dentre outros tipos de jogos;
23
Figura 2.6 Doom III.
2.3.2 Aventura: ao contrário dos demais gêneros, um jogo de aventura não é
uma simulação ou uma competição. Ele é uma estória interativa sobre um
determinado personagem que é controlado pelo jogador. Apesar do gênero ter
sido alterado muito no decorrer dos anos, existem certas qualidades que
caracterizam esse gênero: exploração, coleção ou manipulação de objetos,
solução de quebra-cabeças e a ênfase reduzida quanto ao combate ou aos
elementos de ação. Podemos citar jogos como The Legend of Zelda mostrado
na Figura 2.7, Grim Fandango, Gabriel Knight etc. como do gênero;
Figura 2.7. The Legendo of Zelda
24
2.3.3 Estratégia: jogos baseados nos jogos de tabuleiro. A grande maioria dos
jogos deste gênero é lançada para PC, por sua grande capacidade de iteração
entre usuário e jogo. Dividem-se em duas formas principais: baseado em
turnos e em tempo real. Dentro desse gênero destacam-se títulos como Age of
Empire, Civilization, Warcraft, Outlive, dentre outros. Na Figura 2.8, pode ser
vista uma imagem do jogo Age of Empire III;
Figura 2.8 Age of Empire III.
2.3.4 RPG: assim como os jogos de estratégia, os RPGs formam um gênero de
jogo que também foi derivado dos jogos de papel e caneta. Geralmente os
RPGs possuem duas características que os distinguem dos demais gêneros:
•
Personagens de jogo configuráveis, que melhoram no decorrer do
jogo, com o aumento da experiência;
•
Estórias muito bem definidas e que desenvolvem no decorrer do
jogo.
A parte da estória é uma parte muito singular desse gênero. Nela, o
jogador interage, de maneira que ele acaba se tornando uma parte muito real
da mesma. Fazem parte desse gênero jogos do estilo Final Fantasy 13
mostrado na Figura 2.9, Dragon Quest, Diablo, Erinia, dentre outros;
25
Figura 2.9 Final Fantasy 13.
2.3.5 ESPORTE ao contrário dos outros gêneros, onde o mundo em que a
estória se desenvolve é pouco conhecido pelos jogadores, nos jogos esportivos
o mundo é bastante conhecido. Por exemplo, muitas pessoas conhecem como
é o futebol profissional e as suas regras. Entretanto, isso não quer dizer que os
jogos desse gênero são extremamente realistas. Fazem parte deste gênero
jogos como Winning Eleven 7, NHL 2008, etc. Na Figura 2.10 mostra o jogo
Winning eleven 7.
Figura 2.10 Winning Eleven 7.
26
2.3.6 Simulação: trata-se de manipular e experimentar um modelo matemático
que pretende reproduzir alguma situação ou artefato real. Através da
experimentação o jogador vai aperfeiçoando suas ações de forma a dominar o
modelo simulado. Os jogadores que irão jogar este tipo de jogo querem ter a
experiência mais próxima possível de qual seria a sensação na realidade.
Jogos como Grand Turism Prologe, Flight Simulator 2008 mostrado na Figura
2.11, dentre outros, fazem parte desse gênero.
Figura 2.11 Flight Simulator 2008.
2.3.7 Quebra-cabeça: também denominado de puzzle, tratam-se de problemas
que precisam ser resolvidos com raciocínio lógico-matemático, principalmente
o raciocínio dedutivo. Charles Blaster e Tetris são exemplos de quebra-cabeça.
A Figura 2.12 mostra o jogo Tetris.
27
Figura 2.12 Tetris
2.3.8 Passatempo: não envolvem condições de vitória ou derrota e não
possuem um objetivo pré-determinado. Predomina as ações livres sob o
artefato computacional. O jogo The Sims é um exemplo de jogo de
passatempo. A Figura 2.13 mostra o jogo The Sims 3;
Figura 2.13 The Sims 3.
28
2.3.9 Educacional: um jogo educacional pode 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 antigI. 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. Um exemplo de jogos educacional é o jogo Brain Age: Train
Your Brain in Minutes a Day!( Idade Mental! Treine seu cérebro em minutos por
dia! ) mostrado na Figura 2.14, lançado para o videogame Nintendo DS que foi
um sucesso entre os adultos, atraídos por pequenos jogos de raciocínio e
memorização.
Figura 2.14 Jogo Brain Age.
É preciso dizer que apesar de terem sido citados exemplos de jogos
digitais em cada estilo não significam que os jogos são de uma única classe.
Um jogo como Zelda que enfatiza a aventura possui a combinação de estilos
de ação e quebra cabeça.
2.4 JOGOS EDUCACIONAIS
Os jogos são vistos como uma forma de estimular aprendizagens,
ambientes colaborativos, exploração e manipulação ativa da informação,
29
criatividade e capacidade de resolução de problemas, comunicação, tomada de
decisões,
capacidade
de
planificação
e
pensamento
estratégico.
As
experiências vividas nas situações de jogo afetam as expectativas dos
aprendizes sobre as atividades de aprendizagem, sendo que estes preferem
tarefas ativas, rápidas, de caráter exploratório e informação disponibilizada em
vários suportes em paralelo [28].
Os
jogos
educativos
concentram-se
especificamente
em
áreas
pedagógicas e são utilizados como forma de aprendizagem e desenvolvimento
de conteúdos e competências. A qualidade, usabilidade e adequação varia de
jogo a jogo. A gama de produtos disponíveis de jogos educativos vai de jogos
de treino/memorização (drill and practice) a ambientes virtuais interativos. As
deficiências comuns apontadas a estes jogos estão na inadequação dos
conteúdos pedagógicos, mal projetados, baixa qualidade gráfica, pouca
usabilidade, atividades limitadas e que estimulam apenas a repetição.
Apontam-se também dificuldades técnicas, de adequação ao conteúdo, de
adaptação ao contexto das aulas. Em parte, estas deficiências são devidas ao
contexto de desenvolvimento destes jogos. Os profissionais e as instituições
que os produzem não conseguem atingir os elevados valores de produção que
são normais na indústria dos jogos, devido à falta de investimentos em projetos
de cunho educacional.
Segundo Amory [2], os jogos educativos devem possuir enredos
atraentes, ligação adequada do enredo do jogo com o conteúdo a ser ensinado
e acrescentar nestes jogos princípios narrativos que estabeleçam início, meio e
fim. Por último, Amory acredita que os jogos computadorizados educativos
disponibilizam uma forma onde o aprendiz pode estar envolvido em ambientes
construtivistas, onde o aprendiz constrói o conhecimento sobre o assunto a ser
ensinado jogando o jogo.
Segundo Jenson & Castel [24], a meta principal do educador é engajar
os aprendizes como agentes e arquitetos de sua própria educação. O maior
desafio dos jogos com propósitos educacionais é oferecer para o aprendiz um
ambiente que propicie o envolvimento, onde os usuários queiram estar,
explorar e aprender da mesma forma que os aprendizes fazem nos jogos
30
computadorizados comerciais. Estes autores também concordam com a
premissa que os jogos comerciais são extremamente atraentes para as
crianças e jovens, com alta qualidade técnica. Mas infelizmente são
considerados pela sociedade como jogos sem valor educacional que
consideram o jogador como um mero comprador. Já os jogos educativos em
geral não são atrativos, pois não criam uma sensação de imersão, trata o
jogador como um estudante, pois possui uma forte abordagem educacional. Os
jogos educacionais devem seguir a rota do sucesso dos chamados jogos
comerciais pelo fato que estes permitem uma maior imersão, uma exploração
do espaço e permite que o aprendiz interprete um personagem e explore um
mundo virtual.
Para Rieder [51], jogos educativos são atividades lúdicas que possuem
objetivos pedagógicos voltados para o desenvolvimento do raciocínio e
aprendizado do jovem. O principal objetivo de um jogo educativo deve ser o
entretenimento aliado à apresentação de novos conhecimentos (ou o reforço
daqueles já descobertos). Ainda, deve explorar por completo o processo de
ensino e aprendizagem, proporcionando ao estudante interesse e motivação,
afim de que ele possa aprender de forma divertida, assimilando fatos e
resolvendo problemas no decorrer do jogo.
Existem também jogos que são desenvolvidos como primordialmente
lúdicos, mas com um potencial educacional, há muitos exemplos de produtos
que se adéquam aos objetivos educacionais. Os jogos de aventura, estratégia
e simulação são apontados como um grande potencial educativo, ao
permitirem que os alunos controlem ambientes virtuais que os obrigam a
desenvolver competências de resolução de problemas, tomada de decisões e
pesquisa de informação relevante. Os motores gráficos e tecnologias
interativas presentes nos jogos de computador são por vezes adaptados a
jogos educativos, como por exemplo, os motores Doom Engine e Neverwinter
Nights Engine [49][40][63][39].
O emergente campo dos mundos virtuais e MMORPGs (Massive MultiUser Online Role Playing Games) está a ser explorado por educadores que
31
desenvolvem pontos de encontro, aulas e recursos virtuais de exploração livre
[21][56].
2.4.1 Exemplos de jogos educacionais
Nesta seção serão mostrados alguns exemplos de jogos educacionais.
2.4.1.1 Tríade
Neste trabalho é apresentado o projeto de um jogo eletrônico voltado
para o ensino-aprendizagem sobre a Revolução Francesa. O titulo do jogo
chamado de TRIADE trata-se de “Igualdade, Fraternidade e Liberdade”, um
jogo com estilo RPG single-player que leva o jogador para a França do século
18, na pele de Jeane de Vallois, filha do nobre aristocrata Henry de Vallois e
integrante do movimento pré-revolucionário [57]. O jogo foi desenvolvido
usando o motor de jogo Torque Engine, um motor de jogo comercial para
desenvolvimento de jogos com estilo de ação. A Figura 2.15 mostra uma
imagem do jogo mostrando a personagem Jeane de Vallois.
Figura 2.15 Triade - Jogo educativo sobre a Revolução Francesa.
2.4.1.2 Games-To-Teach
Pode-se
citar
o
projeto
Games-To-Teach
[19]
conduzido
pelo
Massachusetts Institute Technology que propõe uma série de novos estilos de
32
jogos voltados para uma nova geração de aprendizes. Na Figura 2.16 são
mostrados dois screenshots do jogo Revolution que aborda a história da
Guerra Civil Americana na forma de um MMORPG (Massive Multiplayer Online
Role-Playing Games). O jogo foi desenvolvido usando o motor de jogo
Neverwinter Nights Engine, um motor de jogo comercial para desenvolvimento
de jogos do tipo RPG.
Figura 2.16 Jogo Revolution – Jogo sobre a guerra civil americana.
2.4.1.3 Laguna – Aprendendo sobre a Guerra do Paraguai com jogo
educativo
Neste trabalho [37] é descrito o jogo Laguna, que narra os
acontecimentos da retirada da Laguna, episódio da Guerra do Paraguai, que foi
desenvolvido baseado nas premissas do construcionismo e com utilização de
ferramentas de software livre. O objetivo do jogo é auxiliar no processo de
ensino e aprendizagem de temas relacionados à História do Brasil, de uma
forma atraente e divertida. O jogo foi implementado usando o motor de jogo
Blender Engine, que é um motor de jogo gratuito disponibilizado para a criação
de jogos. A Figura 2.17 mostra imagens de dois cenários do jogo: cenários da
vila e de uma das tribos.
33
Figura 2.17. Imagens dos cenários da vila (a) e de uma das tribos (b).
2.4.1.4 Jogo educativo sobre a Revolução da Cabanagem – Fase PréRevolucionária
Neste trabalho [48] é mostrada a primeira etapa do jogo educativo sobre
a revolução da cabanagem chamado de fase Pré-Revolucionária. Essa etapa
se divide em três sub-etapas: “Belém do Pará (1820-1835)”, “Felipe Patroni” e
“Batista Campos”. Na sub-etapa de Belém do Pará, o usuário terá que controlar
um personagem que percorrerá a cidade na época da revolução, com o
objetivo de conhecer alguns prédios e locais importantes no contexto histórico
da Cabanagem. As outras sub-etapas descreverão a participação de dois
personagens marcantes na fase preparatória da revolução, Felipe Patroni e
Batista Campos. Esta etapa foi desenvolvida usando o motor proposto no
capítulo 4 desta dissertação. A Figura 2.18 mostra o cenário da fase PréRevolucionária e um cabano.
34
Figura 2.18 Jogo educativo sobre a revolução da cabanagem – Fase Pré-Revolucionária.
2.5 CONSIDERAÇÕES FINAIS
Neste capítulo foi mostrado um breve estudo sobre jogos eletrônicos,
mostrando o histórico, o conceito e tipos de jogos existentes.
Também é mostrada uma breve discussão sobre jogos educativos
mostrando as características destes jogos e dos benefícios do uso dos jogos
educativos como ferramenta de ensino-aprendizado.
Neste capítulo foram abordados os conceitos sobre jogos eletrônicos. No
próximo capítulo será mostrado um estudo sobre motor de jogo, o componente
principal de um jogo eletrônico.
35
CAPÍTULO 3 – MOTOR DE JOGO
Neste capítulo será mostrado um estudo feito sobre motores de jogos ou
game engine, mostrando um breve histórico, definição e a estrutura de motores
de jogos. Por último, são mostrados os trabalhos relacionados.
3.1 BREVE HISTORICO
O termo "game engine" surgiu em meados da década de 1990,
especialmente com o surgimento de jogos de tiro em primeira pessoI. Tal foi à
popularidade da Id Software com os jogos Quake e DOOM que em vez de
começar a desenvolver jogos a partir do "zero", outros desenvolvedores
modificaram o núcleo desses jogos e construíram outros jogos com nova
aparência, caracteres, armas e níveis(levels), como por exemplo o jogo Quake
Soccer, que é um jogo de futebol que foi criado usando o núcleo do Quake. Ou
seja, os programadores modificaram o núcleo dos jogos Quake e DOOM para
que se adequassem aos seus próprios conteúdos [12][60].
Com isso, surgiram dois conceitos: motor de jogo (game engine) e
conteúdo de jogo (game content). Fazendo uma analogia a um carro, game
engine representa o motor do carro e o game content representa todo o resto
tais como: banco, volante, CD - player, pára-choque, rodas, etc.
Depois disso, jogos como Quake III Arena e Unreal da Epic Games em
1998 foram concebidos com esta perspectiva em mente, com o motor e o
conteúdo sendo desenvolvido separadamente.
O estilo de jogos de tiro em primeira pessoa FPS continua sendo o estilo
mais predominante nos motores de jogos, mas agora eles estão também sendo
estão sendo utilizados em outros estilos e também sendo projetados para ser
usados para a criação de diversos estilos em um único motor. Por exemplo, o
RPG Morrowind e o MMORPG Dark Age of Camelot são baseados no motor
Gamebryo Engine que é um motor para jogos MMORPG, e o MMORPG
Lineage II é baseado no Unreal Engine.
36
Embora o termo fosse utilizado pela primeira vez na década de 1990,
existem alguns sistemas anteriores, na década de 1980 que são igualmente
considerados como motores de jogos, tais como os sistemas AGI e SCI da
SIERRA, o sistema SCUMM da LucasArts e o motor FreeScape da Incentivo
Software's. No entanto, ao contrário de motores de jogos mais modernos, estes
motores de jogo nunca foram utilizados em qualquer produtos de terceiros
(exceto o sistema SCUMM que foi licenciado para ser utilizado pela
Humongous Entertainment).
3.2 DEFINIÇÃO
Um motor de um carro é responsável por fazê-lo andar. Ao dar a ignição
do veículo, o motorista coloca o motor em funcionamento e começa a mover-se
com ele, sem precisar saber como funciona todo o processo mecânico. A
transferência do movimento dos eixos para as rodas, a sincronização das
explosões dos pistões, a injeção de combustível na câmara de combustão,
tudo fica a cargo do motor. Um engine para jogos basicamente segue o mesmo
princípio de funcionamento. Dentro do conceito de engenharia de software
trata-se da parte do projeto que executa certas funcionalidades para um
programa. Dentro da área de jogos, um engine se encarregará por entender-se
com o hardware gráfico, irá controlar os modelos para serem renderizados,
tratará da simulação física e sonora, tratará das entradas de dados do jogador,
tratará de todo o processamento de baixo nível e outras coisas que o
desenvolvedor de jogos normalmente não deseja fazer ou não tem tempo para
se preocupar. Existem inúmeras definições para um engine. Entretanto, estas
definições convergem em algumas características:
– Permitir que o desenvolvedor possa criar diversos jogos diferentes,
usando um mesmo motor de jogo. É comum, entretanto, que os motores sejam
catalogados de acordo com os tipos de jogos para os quais eles foram
concebidos [16];
– Poder reaproveitar com facilidade o código desenvolvido em projetos
anteriores;
37
– Abstrair a manipulação de API’s (embora, em muitos casos, o
desenvolvedor irá usar as próprias API’s dentro do ambiente do engine, para
implementar funcionalidades específicas);
– Possibilitar uma fácil integração entre código e modelagem 3D. Para
esta finalidade é comum que os engines apresentem editores de cenas.
Segundo Lewis [31], o conceito de motor surgiu devido à necessidade de
reduzir o tempo de desenvolvimento e custos na indústria de jogos, tendo em
vista que a cada novo projeto não havia reaproveitamento de recursos
utilizados em jogos anteriores, ou seja, recriavam-se tudo a partir do zero.
Segundo Stang [61], um motor de jogo pode ser definido como um
conjunto de módulos que desempenham tarefas especifica e necessárias ao
desenvolvimento de um jogo. Segundo Bernades et all [5], alguns dos módulos
comumente encontrados em motores de jogos são:
•
Módulo gráfico para renderização 2D e 3D;
•
Módulo de física;
•
Módulo de reconhecimento de dispositivos;
•
Módulo de som;
•
Módulo de inteligência computacional;
•
Módulo de rede.
Nas seções subseqüentes, serão brevemente definidas as funções
básicas de cada um destes módulos.
3.2.1 Módulo gráfico
O Módulo gráfico ou renderizador gráfico é um dos componentes mais
complexos de um motor, pois tem a responsabilidade de desenhar, com
velocidade suficiente, os componentes visuais da aplicação formados por
objetos 2D e 3D (estáticos ou dinâmicos).
38
Para que um bom desempenho seja obtido, o módulo gráfico geralmente
utiliza diversas técnicas de otimização, que incluem diminuir o detalhamento
dos objetos à medida que sua distância aumenta em relação ao observador
(Level Of Detail) e não desenhar polígonos ocultos ou objetos que estejam fora
do volume de visualização (Culling).
Em ambientes formados por modelos complexos estas técnicas são
importantes para garantir um desempenho aceitável, pois quanto mais
polígonos tiverem que ser desenhados, mais lenta será a etapa de
renderização. Além disso, existem casos em que o renderizador necessita
ordenar os objetos a serem desenhados para que seja possível criar alguns
efeitos como sombras e objetos transparentes.
3.2.2 Módulo de física
O sistema de física tem por objetivo identificar se entidades virtuais
estão em colisão, simular corpos rígidos, deformáveis e movimentos com
aceleração, resistência e gravidade, que são fatores essenciais para que o
realismo seja mantido.
3.2.3 Módulo de reconhecimento de dispositivos
O Módulo responsável pelo reconhecimento de dispositivos tem a tarefa
de monitorar e captar dados e eventos disparados pelos equipamentos
utilizados pelo usuário para interagir com a aplicação, como mouse, teclado e
joystick.
3.2.4 Módulo de som
A renderização sonora é importante para determinar parâmetros como
atenuação, volume e freqüência de um som com base na posição e orientação
do usuário no ambiente virtual.
3.2.5 Módulo de inteligência computacional
O Módulo de inteligência computacional deve oferecer mecanismos para
que o desenvolvedor possa atribuir comportamentos a entidades controladas
39
pela aplicação. Um dos algoritmos freqüentemente é o "A Star" que considera
diversos fatores para determinar o caminho de menor custo entre dois pontos
[29]. Atualmente grande parte dos motores oferece também suporte a script
com o qual é possível descrever o comportamento de uma entidade sem a
necessidade de recompilar a aplicação.
3.2.6 Módulo de rede
O Módulo de rede deve oferecer recursos para que seja possível realizar
a comunicação entre computadores que participam de uma mesma simulação
simultaneamente. Através deste Módulo é possível manter a consistência do
mundo virtual utilizado em aplicações colaborativas.
Como é possível observar, os módulos que compõem um motor não têm
por objetivo especificar como deve ser o ambiente do jogo, ou mesmo a lógica
que será empregada no jogo. Essa característica permite que diferentes jogos
possam ser implementados com base em um mesmo motor, onde cada
aplicação poderá utilizar alguns, ou todos os módulos oferecidos por um motor.
Uma observação muito importante é que motores de jogos devem ser
distinguidos de motores gráficos que vêm apenas com capacidades de
renderização gráfica e também devem ser distinguidos dos Software Developer
Kits (SDKs), que ajudam no desenvolvimento de jogos. Enquanto que o
primeiro normalmente tem limitações quanto ao que e como as coisas podem
ser incluídas em um jogo, este último é muito mais flexível, mas com um foco
mais restrito. Por exemplo, Gamebryo é um motor de renderização proprietário
muito flexível, mas não tem capacidade física ou colisão, ao contrário do Havok
que é apenas um motor de física.
3.3 ESTRUTURA
Um motor de jogo é um software que compõe o núcleo de um jogo
eletrônico. Ele manipula a renderização gráfica (2D ou 3D), física, som,
inteligência computacional, colisão, e outros aspectos de mecanismo do jogo. A
Figura 3.1 ilustra os componentes de um motor de jogo genérico proposto por
[31].
40
Figura 3.1. Diagrama de um motor de jogo modular genérico [56].
O mundo virtual (1) é o cenário, ou nível, no qual o jogador interage com
o jogo. O cenário é o ambiente virtual de um jogo e é composto por um ou
vários mapas, objetos, luzes, partículas, etc. Os níveis também podem ser
criados pelos usuários e facilmente importados para o jogo através do uso de
editores que alguns motores disponibilizam para o usuário.
O script (2) representa o código fonte do jogo no qual contém a lógica do
jogo. A lógica do jogo corresponde às regras e sobre o funcionamento do jogo.
Scripting é uma forma de linguagem de programação em alto nível que permite
ao usuário personalizar ainda mais o jogo, adicionando novos comportamentos
de atores, animações, reações físicas, etc.
O motor de jogo (3) coordena a renderização gráfica, a física, colisão de
objetos, som, interface gráfica e outros elementos, a fim de fornecer as
funcionalidades para o funcionamento do jogo. Um motor é basicamente divido
em núcleo e subsistemas.
O núcleo é responsável em registrar, identificar, iniciar e coordenar o
funcionamento de todos os módulos e subsistemas que compõem o motor.
41
Assim, o núcleo caracteriza-se por oferecer uma série de serviços comumente
utilizados pelos subsistemas, além de estabelecer as políticas aplicadas ao
carregamento de mídias; ao gerenciamento de memória; ao tratamento das
particularidades da plataforma corrente; ao escalonamento das tarefas
executadas pelo motor; ao sistema de eventos, que trata a interação do usuário
com os dispositivos de entrada; à manutenção do registro de atividades e erros
do motor (log).
Um subsistema representa um módulo específico do motor que é
utilizado pelo jogo para a implementação de um conjunto de funcionalidades.
Assim, um determinado subsistema é caracterizado pelo domínio de problemas
para o qual é destinado e pelas tarefas que desempenha como módulo do
motor, além das tecnologias que utiliza para desempenhar essas tarefas. O
subsistema de renderização em tempo-real, por exemplo, caracteriza-se por
sintetizar imagens a uma taxa de exibição interativa com base numa cena
tridimensional e, dentre as tarefas que desempenha, estão: a determinação da
visibilidade dos objetos na cena, a geração texturas e a especificação sistemas
de coordenadas através de matrizes. Para tanto, é necessário que esse
subsistema se atenha a tecnologias específicas, como técnicas para a
eliminação de faces ocultas e renderização em baixo nível através de uma API
3D. Dessa maneira, cada subsistema é responsável por um aspecto específico
da aplicação, bem como pela gerência desse aspecto em tempo de execução.
Como componentes de software, os subsistemas são capazes de encapsular a
complexidade de utilização de técnicas e subsistemas de baixo nível externos
ao motor.
Em alguns jogos, a rede está prevista (5) no qual permite uma
experiência de jogos multiusuários. As API’s fornecem funcionalidades básicas
sobre os dispositivos que representam, como por exemplo, a API OpenGL que
contem um conjunto de funcionalidades para a criação de ambientes gráficos.
Todo este software interage com o sistema operacional do usuário (6).
42
3.4 TRABALHOS RELACIONADOS.
Motores de jogos educacionais são motores que são desenvolvidos para
permitir o desenvolvimento de jogos utilizando as funcionalidades deste. Nesta
seção serão apresentados alguns motores educacionais desenvolvidos.
3.4.1 enJine – Um motor de jogos educacionais em Java
O motor enJine [38] visa oferecer um motor de jogo destinado ao
aprendizado de computação gráfica e de programação de jogos. É um dos
poucos motores para a plataforma JAVA / JAVA 3D, sendo que sua estrutura
clara, simples e consistente, que facilitam o aprendizado e uso, o tornam
diferenciado
em
aplicações
didáticas.
No
momento
encontra-se
em
desenvolvimento uma interface de programação que permitirá que o pacote
seja utilizado pro professores e outros profissionais que não possuam
conhecimento de programação. A Figura 3.2 apresenta algumas telas de jogos,
baseados no enJine, desenvolvidos por alunos.
Figura 3.2 Telas de jogos desenvolvidos com o motor enJine.
3.4.2 J3DTOOL – Um motor para o desenvolvimento de jogos
educacionais em Java3D
J3DTOOL[33] é um motor destinado ao desenvolvimento de jogos
educacionais em três dimensões. O motor é baseado na API gráfica Java 3D e
43
constituído de classes que abstraem para um nível mais alto as funcionados da
API Java 3D. O motor oferece recurso de criação de ambientes do tipo sala de
aula e a manipulação de objetos 3D feitos em VRML. O motor também oferece
recursos para animação, tratamento de colisão e captura de eventos do teclado
e joystick. A Figura 3.3 mostra um jogo educacional chamado “AITEM” que foi
desenvolvido usando o motor J3DTOOL. O jogo foi desenvolvido para auxiliar
no aprendizado dos conteúdos de matemática do ensino fundamental.
Figura 3.3. Jogo “AITEM” desenvolvido usando o motor J3DTOOL.
3.4.3 STEAMie
STEAMie[41] é um motor de jogos educacionais usado para criar
avançados, realísticos e envolventes ambientes de aprendizado virtuais.
STEAMie foi desenvolvido usando a linguagem de programação C++ e é
baseado na API gráfica OpenGL 2.1. Além de recurso gráficos, o motor oferece
sistema de interface gráfica baseado na API GuiChan para a criação das
interfaces. Também oferece um sistema de animação, um sistema de colisão e
física baseado na API ODE e provém recurso de rede. Vários jogos foram
desenvolvidos usando o motor. A Figura 3.4 mostra uma imagem do jogo
“Force and Momentum” que foi desenvolvido para ensinar sobre os conceitos e
uso de forças e momentos.
44
Figura 3.4. Image do jogo FORCE AND MOMENTUM.
3.4.4 SAGE – Simple Academic Game Engine
Sage[56] é um motor de jogos educacionais simples para o ensino de
programação de jogos. Sage foi projetado para possuir uma arquitetura
modular, para que os alunos possam desenvolver seus próprios módulos e
adicionarem ao motor. O motor foi totalmente escrito usando a linguagem C++
e desenvolvido usando a API DirectX. O motor possui vários demos no quais
os alunos podem observar o funcionamento de um jogo e também podem
melhorar esses demos. A Figura 3.5 mostra uma imagem do demo “Ned’s
Turkey Farm” desenvolvido usando o motor SAGE.
Figura 3.5 Ned’s Turkey Farm.
45
3.4.5 Alice
Alice [1] é um ambiente de programação 3D inovador que facilita a
criação de uma animação para contar uma história, jogar um jogo interativo, ou
um vídeo para compartilhar na web. Alice é uma ferramenta disponível
gratuitamente para o ensino de programação orientada para objeto. Ela permite
que os estudantes aprendam conceitos de programação fundamentais no
contexto da criação de filmes animados e na criação de simples jogos
eletrônicos.
No editor disponibilizado, os estudantes arrastam e soltam os itens
disponibilizados na interface gráfica para criar um programa. As instruções para
o funcionamento são descritas através de conceitos de programação orientada
a objetos de linguagem de programação, tais como Java, C + +, C #. Alice
permite aos estudantes ver imediatamente como sua animação é executada, o
que lhes permite compreender facilmente o relacionamento entre os conceitos
de programação e o comportamento dos objetos em sua animação.
Manipulando os objetos em seu mundo virtual, os alunos ganham experiência
com todas as construções de programação ensinadas tipicamente em um
curso introdutório de programação. A Figura 3.6 mostra o editor disponibilizado
por Alice [1].
Figura 2.1. Alice editor
46
3.4.6 Comparativo entre os motores
Nesta subseção será mostrado um comparativo sobre os motores das
subseções anteriores, na tabela 1 mostra uma tabela comparativa dos recursos
computacionais de cada motor.
Motor/
API
Sistema de
Características
gráfica
Animação
Som
Física
Rede
Inteligência
Colisão
Script
Editor
Computacional
EnJine
Java3D
Sim
2D
-
-
-
sim
-
-
J3DTOOL
Java3D
Sim
2D
-
-
-
sim
-
-
SAGE
DirectX
Sim
2D
-
-
-
Sim
-
-
STEAMie
DirectX
Sim
3D
ODE
Sim
-
Sim
-
-
Alice
Java3D
Sim
2D
-
-
-
-
Sim
Sim
Tabela 1. Tabela comparativa dos recursos computacionais de cada motor.
Pode-se observar da tabela 1 que nenhum dos motores possui módulo
de inteligência computacional e apenas o motor STEAMie possui módulo de
física, módulo de rede e som 3D.
3.5 CONSIDERAÇÕES FINAIS
Neste capítulo foi mostrado um breve estudo sobre motores de jogos,
mostrando um breve histórico, o conceito e a estrutura de um motor de jogo.
Foi visto também os trabalhos relacionados e também um comparativo
dos motores de jogos educacionais existentes.
Como se pode observar na tabela 1, que os motores de jogos
educacionais são muito limitados em termos computacionais.
No próximo capítulo será mostrado um motor de jogo que supre as
deficiências destes motores, sendo um motor que possui vários recursos
computacionais não existentes nos motores citados e possui uma arquitetura
flexível
e
modular,
funcionalidades.
dessa
forma
permitindo
a
expansão
de
suas
47
CAPÍTULO 4 – MOTOR PROPOSTO
Neste capítulo será discutido sobre o motor de jogo educacional
proposto. Também neste capítulo serão detalhados aspectos de sua estrutura
e de seu funcionamento.
4.1 CARACTERÍSTICAS
O motor proposto foi concebido para agilizar o projeto e implementação
de jogos educacionais. Para alcançar este objetivo, desenvolveu-se a
arquitetura do motor com base no conceito de orientação a objetos. Segundo
Deitel [14], a programação orientada a objetos leva vantagem sobre a
codificação procedural pelo fato que as pessoas vivem em um mundo orientado
a objetos e sendo assim os programadores podem desenvolver seus jogos da
mesma forma que percebem o ambiente ao seu redor.
O motor foi totalmente implementado usando a linguagem C++ e possui
uma arquitetura modular e flexível possibilitando a expansão de suas
funcionalidades.
Em termos de recursos gráficos, o motor proposto utiliza as
funcionalidades do motor gráfico Ogre3D, que é um motor gráfico desenvolvido
em C++ muito utilizado na produção de jogos. O motor oferece mecanismos
para o carregamento de modelos animados e estáticos, no formato “.mesh” que
é formato suportado pelo o motor gráfico Ogre3D. Através do uso de plugins do
motor gráfico Ogre3D o motor proposto utiliza as funcionalidades do sistema de
interface gráfica CeGUI e do sistema de interface de entrada e saída com
usuário OIS.
Outra característica importante, é que o próprio motor se encarrega de
tarefas como alocação e liberação de memória e o gerenciamento de recursos
no sentido de evitar que um mesmo arquivo contendo uma imagem, modelo 3D
ou som seja carregado mais de uma vez.
48
Em termos de simulação física, o motor utiliza recursos da API de física
NVidia PhysX[45], um dos melhores motores de física existentes e muito usado
em jogos. O NVIDIA PhysX é um poderoso mecanismo de física, que permite o
uso de elementos físicos em tempo real nos mais modernos jogos para PC e
para console.
O motor utiliza as funcionalidades da APIs Fmod[18] e OpenAL[43] para
a simulação sonora. Dessa forma, o motor oferece funções de alto nível para a
renderização de sons 2D e 3D. Para os sons tridimensionais é possível
configurar atributos como posição, direção e velocidade sendo que o resultado
final é influenciado pela posição de uma entidade denominada "ouvinte" que
pode representar, por exemplo, a posição da câmera em um determinado
momento. O sistema de som suporta variados formatos de arquivo de som tais
como:.mp3, .wav, .ogg;
O motor disponibiliza um sistema de inteligência computacional baseado
em objeto de inteligência. Um objeto de inteligência é um objeto genérico que
contém propriedades de inteligência, ou seja, um objeto de inteligência é capaz
de capturar estímulos do ambiente virtual, processar esses estímulos, tomar
uma decisão e executar uma ação. O sistema possui um sistema de
movimentação que oferece funções para a busca do menor e melhor caminho.
O sistema possui recurso de tomada de decisão baseado em máquina de
estados finitos e sistema Fuzzy. O sistema também permite o uso de script na
linguagem lua para customizar o comportamento de um IAObject de acordo
com a necessidade do desenvolvedor.
O motor também permite o uso de suas funcionalidades através de script
lua. O motor possui um interpretador de comandos da linguagem lua integrado,
permitindo a construção de jogos usando apenas a linguagem de script luI.
O motor também disponibiliza a criação de animações 3D em tempo real
e a reprodução de vídeos no formato .ogg.
49
4.2 ARQUITETURA
A arquitetura do motor foi projetada de acordo com o princípio de
encapsulamento do paradigma de orientação a objetos (OO), de maneira que
cada subsistema disponibilizado pelo motor fosse definido por meio de uma
interface abstrata. Essa interface é única e, portanto, independente da
implementação do módulo ou da tecnologia associada ao mesmo. Essa forma
de padronizar o acesso às funcionalidades de cada serviço, oferecendo ao
usuário a conveniência de conhecer e usar apenas as interfaces padrões, torna
o sistema independente de tecnologias específicas.
A engine foi projetada para possuir uma arquitetura que permita a
flexibilidade e a reusabilidade de seus componentes, permitindo a expansão de
suas funcionalidades. A Figura 4.1 contém um diagrama que mostra a
arquitetura do motor. Esse diagrama mostra também como os diferentes
sistemas são conectados com o núcleo do motor. Todas as comunicações
entre o núcleo do motor e os sistemas são feitos através de uma interface
comum.
Figura 4.1. Arquitetura do motor.
50
O motor é divido em duas partes: núcleo e sistemas. O núcleo é divido
em duas partes distintas: framework e gerenciadores. O framework contém os
elementos que serão utilizados na aplicação/jogo e são gerenciados pelos
gerenciadores. Os gerenciadores são singletons que são responsáveis por
gerenciar elementos contidos no framework ou gerenciar partes especificas do
motor. No apêndice B é mostrado o diagrama de classes do núcleo do motor.
As interfaces são os meios de comunicação entre o motor e os
subsistemas e entre os subsistemas. Todos os subsistemas possuem uma
interface de comunicação com o exterior, de tal forma que para o núcleo ou
outro subsistema possa se comunicar é necessário implementar essa interface.
Um subsistema é tratado como uma entidade separada do núcleo. Essa
modularidade
permite
que
os
sistemas
possam
ser
carregados
ou
descarregados conforme seja necessário pelo motor.
4.3 FRAMEWORK
Um framework consiste num conjunto de classes que colaboram para
realizar uma responsabilidade para um domínio de um sistema [14]. O
framework é composto de elementos que serão instanciados e manipulados
pela aplicação/jogo que utilizará o motor. Todos os elementos do framework
são gerenciados por gerenciadores específicos. Os principais elementos que
constituem o framework são:
GameObject
GameScene
SceneObject
GameActor
4.3.1 GameObject: Esta classe é um classe abstrata que representa um objeto
genérico do jogo. Todo e qualquer elemento a ser criado usando o motor deve
51
derivar da classe GameObject. A Figura 4.2 mostra a estrutura de um
GameObject.
Figura 4.2 GameObject
4.3.2 SceneObject: Esta classe é uma especialização da classe GameObject
no qual representa um objeto que faz parte de uma cena de jogo. Há
basicamente três tipos de objetos de cena: MESH, LUZ e TERRENO. Um
SceneObject do tipo MESH possui propriedades gráficas, de física e de som,
ou seja, esse objeto pode possui um modelo associado, um corpo rígido e
emitir um som. A Figura 4.3 mostra a estrutura no formato em xml de um objeto
de cena do tipo MESH que contém as propriedades gráfica, física e de som.
52
Figura 4.3 SceneObject do tipo Mesh.
Um SceneObject do tipo luz representa uma luz que pode ser do tipo:
pontual, direcional e spotlight. A Figura 4.4 mostra a estrutura de um
SceneObject do tipo luz.
<xml>
<SceneObject name="luz1" TYPE=LUZ>
<property>
<tipo>"Pontual"<tipo>
<diffusecolor>"1.0 1.0 1.0"<diffusecolor>
<specularcolor>"0.0 0.0 0.0"<specularcolor>
<atenuacao>"10"<atenuacao>
<limite_atenuacao>500<limite_atenuacao>
<posicao>"50 30 20"<posicao>
<direcao>" 5 5 0"<direcao>
<distancia_visivel>"1000.0"<distancia_visivel>
<potencia>"2.0"<potencia>
</property>
</SceneObject>
</xml>
Figura 4.4 Scene Object do tipo Luz.
Um SceneObject do tipo terreno representa um terreno do tipo
heightmap ou mapa de altura. A Figura 4.5 mostra a estrutura de um
SceneObject do tipo terreno.
<xml>
<SceneObject name="chao" TYPE=TERRENO>
<property>
<graphics>
<arquivo_conFiguracao>"terreno.cfg"</arquivo_conFiguracao>
</graphics>
<physics>
<mapa_de_altura>"terreno.png"</mapa_de_altura>
</physic>
</property>
</SceneObject>
</xml>
Figura 4.5 Scene Object do tipo Terreno.
53
4.3.3 GameScene: Esta classe representa a cena do jogo. A cena do jogo é
responsável por gerenciar todos os objetos de cenas. A cena do jogo é
responsável pela criação, atualização e destruição dos objetos da cena.
4.3.4 GameActor: Esta classe é uma classe abstrata que representa um
personagem que pode ser controlado pelo jogador ou pelo sistema de
inteligência computacional. Os GameActor são gerenciados pelo gerenciador
GameActorManager. Há basicamente dois tipos de GameActors: Actor e IActor.
4.3.4.1 Actor: é uma classe que é uma especialização da classe GameActor
no qual representa o personagem que vai ser controlado pelo jogador. O
controle do Actor é feito pelo GameActorController.
4.3.4.2 IActor: é uma classe que é uma especialização da classe GameActor,
no qual representa o personagem que vai ser controlado pelo sistema de
inteligência computacional. A principal diferença entre o Actor e IActor são que
o IActor incorpora as funcionalidades de um objeto de inteligência
computacional.
4.4 OS GERENCIADORES
Os gerenciadores fornecem funcionalidades gerenciais ao motor e são
implementados como singletons, ou seja, só é feita uma instancia para cada
tipo de gerenciador. Os gerenciadores são singletons porque a duplicação de
seus recursos pode causar redundância, dessa forma afetando o desempenho.
Os principais gerenciadores são:
•
GameManager
•
GameActorManager
•
GameEnvironmentManager
•
XMLManager
•
GameLogManager
54
•
ScriptManager
•
MovieManager
•
AnimationManager
4.4.1 GameManager: Esta classe representa o gerenciador principal do motor,
no qual é responsável pelo funcionamento do motor, pela gerência dos demais
gerenciadores e pela gerência dos subsistemas. O gerenciador é responsável
pela inicialização e atualização do motor e dos subsistemas.
4.4.2 GameActorManager: Esta classe representa o gerenciador de atores do
jogo. Este gerenciador é responsável pela criação, atualização e a destruição
de todos os GameActors.
4.4.3 GameEnvironmentManager: Esta classe representa o gerenciador de
ambiente no qual fornece as informações sobre a cena e sobre o
funcionamento do motor e dos sistemas.
4.4.4 XMLManager: Esta classe representa o gerenciador de leitura de
arquivos nos formatos .xml. O gerenciador é responsável pela leitura e pela
interpretação desses arquivos e fornecendo essas informações aos elementos
do framework ou aos gerenciadores.
4.4.5 GameLogManager: Esta classe representa o gerenciador que registra os
log de todas as operações que acontecem no motor. Através deste log é
possível registrar o processamento das operações que acontecem no motor e
nos sistemas, além de permitir a identificação de erros.
4.4.6 ScriptManager: Esta classe representa o gerenciador de script. Este
gerenciador é responsável por fornecer os métodos que promovem o uso de
script para a utilização do motor.
4.4.7 MovieManager: Esta classe representa o gerenciado de vídeos. Este
gerenciador é responsável por gerenciar a reprodução de vídeos.
55
4.4.8 AnimationManager: Esta classe representa o gerenciador de animações
3D em tempo real. O gerenciador é responsável pela execução de animações
3D.
4.5 INTERFACES
As interfaces são as formas como o framework e os gerenciadores se
comunicar com os sistemas. O framework e os gerenciadores residem no
interior do motor e, portanto, o framework tem acesso direto aos gerenciadores.
Os sistemas, no entanto, residem fora do motor e possuem diferentes
funcionalidades, tornando-se necessário dispor de um método comum de
acesso aos mesmos.
As interfaces estabelecem um conjunto de funcionalidade que precisam
ser implementados a fim de ter um método comum de acesso. Isto torna
desnecessárias para o framework saber os detalhes sobre um determinado
sistema.
Os sistemas precisam implementar as interfaces para que o framework
possa acessar aos seus componentes. Um sistema tem três componentes que
devem ser implementados usando as seguintes interfaces:
• Interface de sistema: Fornece métodos para criar e destruir cenas.
• Interface de cena. Fornecer métodos de criação e destruição de
objetos.
• Interface de objetos. Fornece informação sobre o respectivo objeto do
sistema.
4.6 SISTEMAS
Nesta seção serão mostrados todos os sistemas que fazem parte do
motor de jogo proposto.
56
4.6.1 Sistema de Renderização Gráfica e Interface Gráfica
O sistema de renderização gráfica do motor Proposto é motor gráfico
Ogre3D[25]. Ogre3D é um motor gráfico desenvolvido em C++, orientado a
objetos, de código fonte aberto, muito usado no desenvolvimento de jogos.
Uma das vantagens em utilizar o Ogre3D é seu suporte as várias placas
gráficas existentes atualmente, desde as mais obsoletas até as mais
sofisticadas.
Para tanto, o Ogre3D oferece funções especificas para que o
desenvolvedor possa verificar a configuração do hardware da máquina em que
a aplicação esta sendo executada e com base nestas informações utilizar os
recursos apropriados.
Os recursos gráficos do Ogre3D incluem sistemas de partículas,
sombreamento por vértice, multi-textura, modelos estáticos e animados,
técnicas para simulação de grama e pelos, skybox, skydome, criação de
terrenos baseados em mapas de altura, iluminação e BSP (Binary Space
Partitioning), suporte a CG, Shaders, sistema de animação por esqueleto,
Blending e IK( Inverse Kinematic), efeitos especiais, etc.
O motor Proposto utiliza diversas funcionalidades do motor gráfico
Ogre3D além das propriedades gráfica tais como gerência de memória,
gerência de recursos e do uso da interface gráfica CeGUI[8] através de plugins
para o sistema de interface gráfica do motor proposto. Para mais detalhes
sobre as características do Ogre3D e CeGUI consultar as referências [25][8].
4.6.2 Sistema de Física
O sistema de física desenvolvido é responsável por criar uma abstração
em alto nível da API de física NVidia PhysX[45]. O sistema encapsula os
funcionamentos internos da API criando uma abstração de forma que quando o
jogo/aplicação for utilizar o sistema não é necessário o funcionamento da API,
mas apenas do funcionamento do sistema de física em questão. Dessa forma
57
torna o uso do sistema independente da tecnologia que é usada. O sistema de
física possui a estrutura mostrada na Figura 4.6:
Figura 4.6. Diagrama de Classes do Sistema de Física.
O sistema de física é composto basicamente dos seguintes elementos:
PhysicsFacade: Esta classe representa uma fachada do sistema de física com
o mundo exterior. Esta classe implementa o padrão de projeto facade. É
responsável por disponibilizar os serviços do sistema de física ao mundo
exterior.
PhysicsManager: Esta classe é o gerenciador de todo o sistema de física e de
todos os seus elementos. É responsável pela criação, atualização e destruição
da cena físicI.
PhysicsScene: Esta classe representa a cena física. É responsável por
gerenciar todos os PhysicsObjects. Ela também é responsável por inicializar e
produzir a simulação física. A classe PhysicsScene apresenta os seguintes
atributos:
Configuração da gravidade;
Configuração dos materiais de contatos entre PhysicsObjects;
Configuração do contato dos PhysicsObjects.
58
PhysicsObject: Esta classe representa um objeto com propriedades físicas.
Um PhysicsObjeto pose ser de vários tipos que dependem da sua forma de
representação no mundo físico. Os tipos são estes:
Capsule: Representa um corpo rígido na forma de uma cápsula;
CompoundShape: Representa um corpo rígido que é composto de
varias tipos de formas;
Convex: Representa um corpo rígido na forma de um sólido convexo;
Cube: Representa um corpo rígido na forma de um cubo;
Ground: Representa um corpo rígido na forma de uma carcaça de um
carro;
Sphere: Representa um corpo rígido na forma de uma esfera;
Trianglemesh: Representa um corpo rígido na forma de um modelo 3D;
Terrain: Representa um corpo rígido na forma de um terreno;
Wheel: Representa um corpo rígido na forma de uma rodI.
PhysicsFactoryObject: Esta classe é um construtor de PhysicsObjects. Esta
classe implementa o padrão de projetos AbstractFactory e no qual todas as
criações dos PhysicsObjects são realizado por esta classe.
PhysicsMaterial: Esta classe representa um material que é utilizado para a
configuração do contato entre PhysicsObject. Um material possui as
propriedades de fricção, atrito, etc.
PhysicsContact: Esta classe é uma classe abstrata que serve para notificar
todos os contatos entre os PhysicsObjects e PhysicsActor. Para que seja feito
a notificação entre PhysicsObjects é necessário a criação de uma classe que
estenda da classe PhysicsContact.
PhysicsActor: Esta classe é uma classe a representação física de um
personagem.
59
PhysicsJoint: Esta classe representa um junta que pode ser feita entre
PhysicsObjects.
4.6.3 Sistema de Inteligência computacional
O sistema de inteligência computacional desenvolvido é baseado no
conceito de objeto de inteligência IAObject. Um IAObject é um objeto genérico
que contém propriedades de inteligência, ou seja, um IAObject é capaz de
capturar estímulos do ambiente virtual, processar esses estímulos, tomar uma
decisão e executar uma ação. O sistema possui um sistema de movimentação
que oferece funções para a busca do menor e melhor caminho.
O sistema também possui um sistema de tomada de decisão através do
uso de script, uso de máquina de estados finitos e por um sistema Fuzzy.
O sistema foi projetado sobre a estrutura de um sistema de inteligência
computacional proposto por [36] em três componentes: componente de
animação, componentes de movimentação e componentes de comportamento
ou tomada de decisão, conforme mostra a Figura 4.7.
Comportamento
Movimentação
Animação
Figura 4.7 Sistema de Inteligência Computacional.
Componente de Animação: O componente de animação é responsável por
executar as animações de um IAObject. As ações do componente são
basicamente: Seleção da Animação e parametrização da Animação. As tarefas
deste componente são executadas pelo sistema de animação da API gráfica
Ogre3D.
Componente de Movimentação: O componente de movimentação é
responsável por fornecer os mecanismos para a movimentação de um
IAObject. A principal ação do componente é algoritmo de pathfind[29].
60
Componentes de Comportamento: Os componentes de comportamento são
responsáveis pela tomada de decisão de um IAObject. A principal ação de um
componente de comportamento é a execução de ações a serem tomadas pelos
IAObject.
4.6.3.1 Estrutura do Sistema
O sistema de inteligência computacional possui elementos que
implementam os componentes descritos anteriormente. A Figura 4.8 mostra o
diagrama de classes do sistema computacional desenvolvido.
Figura 4.8 Diagrama de Classes do sistema de inteligência computacional.
O sistema de inteligência computacional é composto basicamente pelos
seguintes elementos:
IAFacade : Esta classe representa uma fachada do sistema de inteligência
computacional com o mundo exterior. Ela implementa o padrão de projeto
façade.
IAManager: Esta classe é responsável por gerenciar todo o sistema de
inteligência computacional. É responsável também pela criação, atualização e
destruição da cena de inteligência computacional.
61
IAScene: Esta classe representa a cena de inteligência computacional. É
responsável pela criação de todos os elementos da cena de inteligência
computacional.
IAObject: Esta classe
representa uma objeto que possui inteligência. Ele
possui a capacidade de absorver estímulos do ambiente através de sensores,
processar estes estímulos, realizar calculo de comportamento através destes
estímulos e tomar uma decisão através do tipo de comportamento associado a
este objeto. A Figura 4.9 mostra a estrutura de um IAObject.
Figura 4.9 IAObject
Os
principais
métodos
de
um
IAObject
são
captureStimulus(),
processStimulus(), processBehaviour() e processIA().
•
captureStimulus(): Este método é responsável por capturar os
estímulos do ambiente através dos sensores adicionados ao
IAObject. Os sensores informarão ao IAObject se foram
detectados outros IAObjects.
•
processStimulus(): Este método é responsável pelo tratamento
dos estímulos capturados do ambiente. O IAObject irá processar
todos os seus estímulos e irá criar um objeto do tipo Stimulus.
62
•
processBehaviour():
Este
método
é
responsável
pelo
processamento do comportamento do IAObject. O objeto do tipo
Stimulus gerado no método processStimulus() é passado ao
objeto do tipo Behaviour para processamento do estimulo e para
determinar quais ações serão executadas pelo IAObject.
•
processIA(): Este método é responsável pela execução das
ações que foram fornecidas pelo objeto do tipo Behaviour. As
ações são fornecidas ao ActionScheduler para o escalonamento
da execução das ações.
A seqüência das interações entre as classes para o processamento da
inteligência computacional de um IAObject é mostrado na Figura 4.10.
Figura 4.10. Diagrama de Interação que mostra o ciclo de processamento realizado por
um IAObject.
Stimulus: Este classe é uma classe abstrata que representa um estimulo que
será executado por um Behaviour para a tomada da decisão. Um estimulo
representa o objeto de entrada para um Behaviour, para que seja produzidas
ações, estas que serão executadas pelo IAObject.
63
IASensor : Esta classe é uma classe abstrata que representa um sensor, que
capta estímulos do ambiente.
EyeSensor : é uma especialização da classe IASensor no qual ele capta os
IAObjects através de um raio de visão pré-definido. O raio de visão é formado
pelo ângulo do vetor normal do IAObject e o vetor projetado pelo ângulo que é
passado como parâmetro ao EyeSensor, conforme mostra a Figura 4.11.
Figura 4.11. Raio do Sensor de Visão.
Um exemplo do uso dos EyeSensor no jogo da cabanagem é mostrado na
Figura 4.12, onde mostra os cabanos e os raios de seus sensores EyeSensor.
Cada cabano possui 10 sensores para a detecção dos estímulos.
Figura 4.12 Cabanos com os seus sensores do tipo EyeSensor.
64
Behaviour: Esta classe é uma classe abstrata que representa um
comportamento. Um comportamento é um conjunto de regras ou uma
inferência que define quais as ações vão ser tomadas através dos estímulos
capturados, ou seja, é responsável pela tomada de decisão do IAObject. A
classe Behaviour representa a tomada de decisão de um IAObject. Existem
basicamente três tipos de Behaviour no sistema de inteligência computacional
desenvolvido: ScriptBehaviour, FSMBehaviour e FuzzyBehaviour. Todos essas
classes devem implementar o método process(Stimulus). A Figura 4.13 mostra
o relacionamento dos behaviours.
Figura 4.13 Estrutura dos tipos de Behaviour.
ScriptBehaviour: Esta classe é uma especialização da classe Behaviour no
qual o comportamento é definido através do código descrito em um arquivo de
script na linguagem luI. Um exemplo de criação e configuração do
comportamento ao IAObject usando o ScritpBehaviour é mostrado abaixo:
// criação do comportamento
ScriptBehaviour *scriptBehaviour = new ScriptBehaviour();
// definição do arquivo
scriptBehaviour->setScript(“soldado.lua”);
// configurando o comportamento ao IAObject
mIActor->setBehaviour(scriptBehaviour);
FSMBehaviour: Esta classe é uma especialização da classe Behaviour no
qual o comportamento é definido através do uso de uma máquina de estados
65
finitos. A Figura 4.14 mostra o diagrama de classes do módulo que implementa
a máquina de estado.
Figura 4.14 Diagrama de classe do módulo que implementa a máquina de estados finitos.
Um exemplo de criação e configuração do comportamento ao IAObject é
usando o FSMBehaviour é mostrado abaixo:
// definição da maquina de estado
FSMMachine m_machine = new FSMMachine();
m_machine->AddState(new AttackState(this));
m_machine->AddState(new EvadeState(this));
IdleState * Nada = new IdleState(this);
m_machine->AddState(Nada);
m_machine->SetDefaultState(Nada);
m_machine->Reset();
// criação do FSMBehaviour
Behaviour *mBehaviour = new FsmBehaviour();
mBehaviour->setFSMMachine(m_machine);
// conFigurando o comportamento ao avatar
mIActor->setBehaviour(mBehaviour);
FuzzyBehaviour: Esta classe é uma especialização da classe Behaviour no
qual o comportamento é definido através do uso de um sistema fuzzy. A Figura
4.15 mostra o diagrama de classes do módulo que implementa o sistema fuzzy.
No apêndice C é detalhado o diagrama de classes do sistema fuzzy.
66
Figura 4.15 Diagrama de Classes do Módulo que implementa Sistema Fuzzy
Um exemplo de criação e configuração do comportamento para um
IAObject é mostrado abaixo:
// definição do sistema fuzzy
FuzzyModule fm;
FuzzyVariable& DistToTarget = fm.CreateFLV("Distancia");
FzSet Perto = DistToTarget.AddLeftShoulderSet("Perto",0,25,150);
FzSet Media = DistToTarget.AddTriangularSet("Media",25,50,300);
FzSet Longe = DistToTarget.AddRightShoulderSet("Longe",150,300,500);
FuzzyVariable& Saude = fm.CreateFLV("Saude");
FzSet Saude_Baixa = Saude.AddLeftShoulderSet("Baixa",0,25,50);
FzSet Saude_Media = Saude.AddTriangularSet("Media",25,50,75);
FzSet Saude_Alta= Saude.AddRightShoulderSet("Alta",50,75,100);
FuzzyVariable& Acao = fm.CreateFLV("Acao");
FzSet Nada = Acao.AddSingletonSet("Nada",25,25,25);
FzSet Atacar = Acao.AddSingletonSet("Atacar",50, 50, 50);
FzSet Fugir = Acao.AddSingletonSet("Fugir",75, 75, 75);
// conFiguração das regras
fm.AddRule(FzAND(Perto,
fm.AddRule(FzAND(Perto,
fm.AddRule(FzAND(Perto,
fm.AddRule(FzAND(Media,
Saude_Alta), Nada);
Saude_Media), Nada);
Saude_Baixa), Nada);
Saude_Alta), Fugir);
fm.AddRule(FzAND(Media, Saude_Media), Fugir);
67
fm.AddRule(FzAND(Media,
fm.AddRule(FzAND(Longe,
fm.AddRule(FzAND(Longe,
fm.AddRule(FzAND(Longe,
Saude_Baixa), Atacar);
Saude_Alta), Atacar);
Saude_Media), Atacar);
Saude_Baixa), Nada);
// criação do FuzzyBehaviour
Behaviour *mBehaviour = new FuzzyBehaviour();
mBehaviour->setFuzzyModule(fm);
// conFigurando o comportamento ao avatar
mIActor->setBehaviour(mBehaviour);
Waypoint: Um Waypoint é um determinado lugar em um mapa que possui uma
coordenada e uma descrição. O Waypoint representa um local onde as
entidades irão se locomover e são a referencia de algumas locais no ambiente
no jogo. Existem três tipos de Waypoints diferentes:
Map Goal Waypoint: Representa um local que é um objetivo do jogo.
Normal Waypoint: Representa um local qualquer.
Portal Waypoint: é um Waypoint especifico que serve para conectar
dois WaypointSectors.
WaypointSector: Um WaypointSector é uma determinada região em um mapa
que possui uma coordenada, uma dimensão e uma descrição. Um
WaypointSector pode conter nenhum, um ou vários WaypointPortals. Existem
dois tipos de WaypointsSectors:
Map Goal WayPointSector: Representa uma região que corresponde
um objetivo do jogo.
NormalWayPointSector: Representa uma região qualquer.
Pather: Esta classe é responsável pelos cálculos de movimentação e na
escolha do melhor caminho entre os Waypoints e WaypoinsSectors. Os
cálculos envolvem o algoritmo A* e análise do terreno.
WaypointMap: Esta classe representa um mapa no ambiente do jogo e é
composto por Waypoints e WaypointSector. WaypointMap é um singleton que
68
contém as informações sobre todos os Waypoints e WaypointsSectors. Ele
também é responsável por acionar a classe Pather para a realização dos
algoritmos de melhor caminho.
Action: Esta classe representa uma ação. Esta ação é a ação que um IAObject
poderá realizar, como por exemplo, a ação moveToWaypoint representa a ação
de mover o IAObject para o Waypoint especificado. A execução de uma ação
envolve a movimentação do IAObject e a execução de uma animação.
ActionScheduler: Esta classe representa um escalonador de ação. Ele é
responsável por gerenciar as ações a serem executadas pelo IAObject.
4.6.4 Sistema de Som.
O sistema de som foi desenvolvido sobre o Fmod[18] e tem a função de
coordenar o carregamento e renderização de sons 2D e 3D. Este sistema
mantém uma lista de todos os sons já carregados pela aplicação para evitar
que um mesmo recurso seja replicado. Além disso, para sons tridimensionais é
possível configurar vários parâmetros como volume, orientação, posição, área
de influencia e atenuação.
No motor proposto a utilização de sons 2D serve basicamente para criar
músicas de fundo ou efeitos aplicados a componentes de interface como por
exemplo o clique de um botão.
Já os sons tridimensionais são utilizados para criar representações
sonoras de objetos 3D estáticos ou em movimento contidos no mundo virtual.
Para que o sistema de som possa renderizar sons tridimensionais, o
sistema trabalha com dois elementos: o emissor e o ouvinte. É com base em
parâmetros como posição, orientação e distância entre emissor e ouvinte, e
outras fontes sonoras próximas que será determinado o resultado final de um
efeito sonoro.
Através do chamado som virtual, o participante pode perceber
características do objeto emissor como distância, localização, tipo de objeto, e
tamanho do ambiente.
69
No contexto de jogos é importante não confundir som estéreo com som
3D. A diferença é que o som 3D sofre modificações dependendo da
posição/orientação do personagem no mundo virtual em relação ao ponto de
emissão do som. Além disso, sons tridimensionais são influenciados pelos
elementos que compõem a cena como paredes e outros objetos que também
emitem som.
O som estéreo não é influenciado por tais atributos e permanece com
intensidade constante da posição/orientação do participante. A Figura 4.16
apresenta um comparativo entre som estéreo e 3D.
A utilização de som estéreo é geralmente empregada para a reprodução
de uma trilha sonora ou mesmo para representar eventos de componentes de
interface enquanto que os sons 3D são aplicados aos elementos virtuais do
cenário para dar mais fidelidade ao ambiente.
Figura 4.16: Comparativo entre Som Estéreo e Som 3D: em (a) e (b) o som estéreo
permanece constante independente da movimentação do usuário; em (c) e (d) o ponto de
recepção do som é influenciado pelos movimentos do personagem e componentes do
cenário [7].
É estipulado também que para cada cena existe apenas um ouvinte
geralmente representando o usuário e diversos sons, e que suas posições
devem ser atualizadas a cada quadro.
O sistema de som é estruturado conforme mostra o diagrama de classes
na Figura 4.17.
70
Figura 4.17 Diagrama de Classes do Sistema de som
O sistema de som é composto pelos seguintes elementos:
SoundObject - Este elemento é responsável pela a emissão de sons. Existem
8 tipos de emissores de sons, divididos em 2 categorias: SOUND e STREAM.
SOUND:
•
2D_SOUND( emissor de som em duas dimensões sem loop ),
•
2D_SOUND_LOOPED( emissor de som em duas dimensões com
loop ),
•
3D_SOUND( emissor de som em três dimensões sem loop ),
•
3D_SOUND_LOOPED( emissor de som em três dimensões com
loop );
STREAM:
•
2D_STREAM( emissor de um stream em duas dimensões sem
loop ),
•
2D_STREAM_LOOPED( emissor de um stream em duas
dimensões com loop ),
•
3D_STREAM ( emissor de um stream em três dimensões sem
loop ),
•
3D_STREAM_LOOPED(
dimensões com loop ).
emissor
de
um
stream
em
três
71
Um SoundObject do tipo SOUND carrega todo o arquivo na memória
para depois ser reproduzido e permanece na memória até a sua liberação, já o
SoundObject do tipo STREAM é carregado no mesmo tempo de reprodução e
não permanece na memória. A utilização de SoundObjects do tipo SOUND é
recomendado para arquivos pequenos e precisam ser reproduzidos inúmeras
vezes. A utilização de sons do tipo STREAM é recomendada para arquivos
grandes ou que são reproduzidos poucas vezes. Um SoundObject possui os
seguintes atributos:
Vetor posição no espaço global de coordenadas;
Vetor velocidade no espaço global de coordenadas;
Ganho, um fator escalar que multiplica a amplitude dos sons
reproduzidos a partir dessa fonte sonora;
Valores mínimo e máximo para o ganho efetivo, que é obtido através
dos cálculos de atenuação sonora;
Distância máxima e distância de referência, que são utilizadas no
modelo de atenuação baseado no inverso da distância;
Rolloff, usado para exagerar ou diminuir o efeito da atenuação sonora
quando o modelo de atenuação baseado no inverso da distância é
utilizado;
Valor Booleano indicando se essa fonte sonora está reproduzindo sons
de maneira cíclica;
Pitch, que especifica um deslocamento tonal nos sons reproduzidos;
Vetor direção no espaço global de coordenadas, indicando a direção que
o som é emitido por essa fonte sonora;
Ângulos mínimo e máximo (em graus), que, respectivamente, definem o
cone interno e o cone externo, usados para o cálculo de atenuação
baseado na direção de emissão do som em relação ao ouvinte;
Fator multiplicativo do ganho fora do cone externo, usado no cálculo de
atenuação baseado na direção de emissão do som em relação ao
ouvinte; e
Conjunto de propriedades EAX, descrevendo efeitos, como obstrução e
oclusão, que são aplicados apenas quando forem suportados pela
plataforma de execução.
72
SoundObjectFactory: Esta classe é um construtor de SoundObject. Esta
classe implementa o padrão de projetos AbstractFactory no qual todas as
criações dos SoundObjects são realizado por esta classe.
SoundScene: Esta classe representa uma cena do sistema de áudio. A cena é
responsável pela criação, atualização e destruição dos SoundObjects e a
criação e atualização do SoundListener.
SoundListener: Este elemento é responsável por “escutar” ou perceber os
sons emitidos de todas as fontes sonoras, geralmente é acoplado a câmera.
Vetor posição no espaço global de coordenadas;
Vetor velocidade no espaço global de coordenadas;
Vetores foco e up no espaço global de coordenadas, descrevendo a
orientação do ouvinte;
Ganho, que afeta o volume dos sons percebidos pelo ouvinte; e
Conjunto de propriedades EAX descrevendo fatores de reverberação,
que são modificados apenas quando a plataforma de execução possui
suporte a esse tipo de efeito sonoro.
SoundManager – Esta classe é o gerenciador de todo o sistema de som. Ele é
responsável pela configuração de todo o sistema e pela produção de todo os
efeitos sonoros além da atualização de todo o sistema. Também é responsável
por criar, excluir, interagir e atualizar todos os componentes do subsistema.
Frequência para mixagem da saída, descrita em HZ;
Escala utilizada para ajustar a unidade de distância usada para
descrever as velocidades do ouvinte e das fontes sonoras aos cálculos
de efeito Doppler;
Fator de escala usado para exagerar ou diminuir a intensidade com que
o efeito Doppler é percebido pelo ouvinte;
Modelo de atenuação sonora; e
Uma instância de SoundListener que encapsula o ouvinte da simulação.
73
SoundFacade : Esta classe representa uma fachada do sistema de som com o
mundo exterior. Ela implementa o padrão de projeto facade.
4.6.5 Sistema de Interface com usuário.
O sistema de interface com usuário é um sistema simples baseado na
API OIS [42], que só possui um elemento que é o gerenciador de interface de
entrada do usuário.
O gerenciador é responsável por configurar os dispositivos de entrada
como teclado, mouse e joystick. Também é responsável por capturar os
eventos destes dispositivos e pela a atualização de todo o sistema.
4.7. FUNCIONAMENTO DO MOTOR
O funcionamento do motor pode ser dividido em três etapas:
Carregamento do conteúdo, Inicialização do motor e dos subsistemas e
atualização do motor e dos subsistemas;
4.7.1 Instanciação do conteúdo: Nesta etapa acontece a instanciação do
conteúdo, ou seja, os arquivos são mapeados na memória, para então serem
carregados.
4.7.2 Inicialização do motor: Nesta etapa acontece a inicialização do motor,
ou seja, nesta etapa os gerenciadores são inicializados e os subsistemas
também são inicializados.
4.7.3 Atualização do motor e sistemas: Esta etapa deve acontecer dentro do
game loop, onde serão atualizados os gerenciadores e os sistemas. Esta etapa
deve ser implementada pelo jogo/aplicação que utilizará o motor.
É importante salientar que a aplicação/jogo que utilizará o motor deverá
seguir todas essas etapas para o perfeito e completo funcionamento do motor.
74
No apêndice D está descrito um código exemplo de utilização do motor.
4.8 CONSIDERAÇÕES FINAIS
Neste capítulo foi mostrado o motor de jogo desenvolvido, mostrando as
suas características, a arquitetura, os componentes e o funcionamento do
motor.
No apêndice A, para testar e comprovar o funcionamento do motor será
mostrado um estudo de caso sobre um jogo desenvolvido usando o motor.
75
CAPÍTULO 5 – CONCLUSÕES
Neste capítulo será mostrado às conclusões sobre o trabalho proposto.
5.1 Contribuições do trabalho
Este trabalho mostrou o desenvolvimento de um motor de jogo
educacional. O motor possui vários recursos não existentes nos motores de
jogos educacionais atuais, de forma que jogos educativos mais elaborados e
sofisticados possam ser desenvolvidos utilizando este motor desenvolvido.
Com o uso do motor vários jogos podem ser desenvolvidos, pois o motor
possui uma arquitetura genérica, flexível e expansível, de modo que pode ser
adequado para qualquer tipo de projeto de jogos.
Além do que o motor utiliza as mesmas tecnologias dos jogos
comerciais, possibilitando que até mesmos jogos educativos possam ser
criados com as mesmas características do que os jogos comerciais.
5.2 Dificuldades Encontradas
Existem várias dificuldades encontradas durante o desenvolvimento do
motor, podem-se citar as principais:
•
Falta de boas literaturas que tratam de forma prática o
desenvolvimento de jogos. Existem várias literaturas, porém muito conceitual e
não mostra de fato como se devem desenvolver jogos;
•
Dificuldade de integração das tecnologias. Integrar as tecnologias
foi um fator crucial, pois cada API funciona de uma forma diferente, de forma
que foi necessária uma adaptação de cada API para possam ser integradas no
motor;
•
Muitas das APIs utilizadas estavam em desenvolvimento. O motor
gráfico Ogre3D ainda está em desenvolvimento e muitos bugs foram
encontrados;
•
Difícil adaptação das API’s para outros sistemas operacionais, tais
como o Linux;
76
5.3Trabalhos Futuros
Como trabalhos futuros pretendem-se a adição de Módulo de rede,
permitindo a jogabilidade multiusuário.
Também como trabalhos futuros pretendem-se a criação de um editor de
cenários para facilitar a construção e a configuração de cenários.
Pretende-se a melhoria do sistema de inteligência computacional com a
adição de novos algoritmos de tomada de decisão, a criação de algoritmos de
Tactics AI, ou seja, inteligência computacional tática.
Também se pretende a otimização e a refatoração de todo o código
fonte.
5.4 Considerações finais
Todo o processo de produção do motor levou em média 15 meses,
considerando o tempo de projeto, codificação e testes. Vários protótipos foram
desenvolvidos para testar as funcionalidades de cada subsistema incorporado
ao motor.
O subsistema de inteligência computacional foi o mais demorado, não foi
utilizada nenhuma biblioteca ou API. O subsistema foi criado a partir de vários
estudos sobre inteligência computacional em jogo.
O código fonte do motor possui aproximadamente 30 mil linhas de
código fonte.
Foram feitas várias publicações feitas sobre o trabalho em congressos:
•
Uma publicação no Simpósio Brasileiro de Jogos eletrônicos e
Entretenimento Digital – SBGAMES – 2008;
•
Uma publicação no Workshop de Informática na Escola – WIE –SBC –
2008;
•
Duas publicações no Simpósio de Realidade Virtual e Aumentada – SVR
– 2007;
•
Uma publicação no IV Seminário de Jogos Eletrônicos, Educação e
Comunicação – construindo novas trilhas.
77
REFERENCIAS BIBLIOGRAFICAS:
[1] Alice, disponível em http://www.alice.org/, acessado em 20 de abril de 2009.
[2] AMORY, I., Building an Educational Adventure Game: Theory, Design
and Lessons In: Journal of Interactive Learning Research v.12 num. 23. Pags.
249-263. 2001.
[3] BATTAIOLA, A L.; NASSIM, E. C.; DOMINGUES, R. G. et al
Desenvolvimento de um Software Educacional com Base em Conceitos
de Jogos de Computador, In: XIII Simpósio Brasileiro de Informática na
Educação. 2002.
[4] BATTAIOLA, I. L., Jogos por Computador – Histórico, Relevância
Tecnológica e Mercadológica, Tendências e Técnicas de Implementação
In: XIX Jornada de Atualização em InformáticI. Curitiba: SBC, Julho/2000, v. 2.
pp. 83-122.
[5] BERNARDES, J. L., BIANCHINI, R., CUZZIOL, M., JACOBER, E.,
NAKAMURA, R. e TORI, R. Realidade Virtual: Conceitos e Tendências,
capítulo Jogos Eletrônicos e Realidade Virtual, págs. 159-176. 2004.
[6] BITTENCOURT J. R.; FIGUEIREDO, C. Z., Jogos Computadorizados
para
Aprendizagem
Matemática
no
Ensino
Fundamental.
Novas
Tecnologias na Educação, Porto Alegre, v. 3, n. 1, p. 4-5, Maio, 200I.
[7] BURDEA, G. C.; COIFFET, P. Virtual Reality Technology. WileyInterscience, Second Edition, 2003.
[8] CeGUI, disponível em http://www.cegui.org.uk/wiki/index.php/Main_Page,
acessado em 20 de abril de 2009.
78
[9] CIPRIANI, O. N.; MONSERRAT J. N.; DE SOUZA I. M. S., Construindo um
Jogo Para Uso na Educação Matemática, No Simpósio Brasileiro de Jogos
para Computador e Entretenimento Digital. Porto Alegre: Sociedade Brasileira
de Computação, 2007.
[10] CLUA, E. W. G.; BITTENCOURT J.R., Mini-curso: Uma Nova
Concepção para a Criação de Jogos Educativos. No Simpósio Brasileiro de
Informática na Educação, 2006.
[11] CRAWFORD, C. Chris Crawford on Game Design. New Riders. 2003.
[12]
DALMAU,
D. S.,
Core
Techniques
and
Algorithms
in
Game
Programming, New Riders Publishing, 2003.
[13] DAMASCENEO R. R.; REIS F. V.; RIBEIRO F. M., SILVA F. C., SOUSA M.
S., Jogo Educativo com Tema Histórico: A Revolução da Cabanagem, No
Simpósio Brasileiro de Jogos para Computador e Entretenimento Digital. Porto
Alegre: Sociedade Brasileira de Computação, 2008.
[14] DEITEL, H. M.; DEITEL, P. J., C++ como programar. Bookman, 200I.
[15] DEMARIA, R.; WILSON, J. L. High Score! The Illustrated History of
Electronic Games, 2nd edition. McGraw- Hill/Osborne. 2004.
[16] EBERLY, D. H., 3D Game Engine Design: A Practical Approach to
Real-Time Computer Graphics. Morgan Kaufmann, September, 2000.
[17] FINNEY, K. C., 3D game programming, all in one. Thomson Course
Technology. 2004.
[18] FMOD, disponível em http://www.fmod.org/, acessado em 20 de abril de
2009.
79
[19]
GAMES
TO
TEACH
PROJECT.
Disponível
em:
http://www.educationarcade.org/gtt/revolution/index.html, acessado em 20 de
abril de 2009.
[20] GEROSA, L. M.; CURY, D., Uma Abordagem Construcionista no Uso
de Jogos Eletrônicos na Educação, No Simpósio Brasileiro de Jogos para
Computador e Entretenimento Digital. Porto Alegre: Sociedade Brasileira de
Computação, 2007.
[21] GOMES, T. S. L.; CARVALHO, I. I. I., Jogos Como Ferramenta
Educativa: de que forma os jogos online podem trazer importantes
contribuições para a aprendizagem. ZON DIGITAL GAMES 2008, disponivel
em www.lasics.uminho.pt/ojs/index.php/zongames08, acessado em 20 de abril
de 2009.
[22] GRANDO, I.; TAROUCO, L., O Uso de Jogos Educacionais do Tipo
RPG na Educação. Novas Tecnologias na Educação, Porto Alegre, v. 3, n. 1,
Maio 200I.
[23] HARRISON, L. T., Introduction to 3D game engine design using directx
9 and C#, Springer-Verlag. 2003.
[24] JENSON, J.; CASTEL S., Serious Play: Challenges of Educational
Game Design In: American Research Association Annual Meeting in New
Orleans.
Louisiana:
AERA,
2002.
Disponível
em:
<http://edtech.connect.msu.edu/Searchaera2002/viewproposaltext.asp?propID=
5573> acessado em 20 de abril de 2009.
[25] JUNKER, G., Pro Ogre 3D Programming, Apress, 2006.
[26] KAFAI, Y. B., The Educational Potential of Electronic Games: From
Games-To-Teach to Games-To-Learn In: Playing by the Rules – The Cultural
Policy
Challenges
of
Video
Games
Conference,
disponivel
em
80
http://www.savie.ca/SAGE/Articles/1232-KAFAi-2001.pdf,
acessado
em
acessado em 20 de abril de 2009.
[27] KENT, S. L. The Ultimate History of Video Games: From Pong to
Pokémon and Beyond – The Story Behind the Craze that Touched Our
Lives and Changed the World. Three River Press. 2001.
[28] KIRRIEMUIR, J.; MCFARLANE, I., Literature Review in Games and
Learning.
Disponível
em:
http://www.futurelab.org.uk/resources/documents/lit_reviews/Games_Review.pd
f, acessado em 20 de abril de 2009.
[29] KUMAR, P., BOTTACI, L., MEHDI, Q., GOUGH, N. e S., N. Eficient
pathfinding for 2d games. in Proceedings of CGAIDE, 2004.
[30] KUSHNER, D. Masters of Doom: How Two Guys Created an Empire
and Transformed Pop Culture. Random House. 2003.
[31] LEWIS, M.; JACOBSON, J., Game engines in scientic research introduction. Communications of the ACM, 45(1): 27-31, 2002.
[32] LUA, disponível em: http://www.lua.org, acessado em 20 de abril de 2009.
[33] MALFATTI, S. M.; BRANCHER, J. D. ; DIHL, L. L., J3DTOOL - Um Motor
para o Desenvolvimento de Jogos Educacionais em Java3D. In: TALLER
INTERNACIONAL DE SOFTWARE EDUCATIVO - TISE, Santiago, 2004.
[34]
Managing
Game
States
in
C++,
disponível
em
http://gamedevgeek.com/tutorials/managing-game-states-in-c/, acessado em 20
de abril de 2009.
[35] MAZZORANI I. C.; SPAGNOLI l.; MARCZACK D. S.; GIRAFFA, M. O
desenvolvimento
do
jogo
educacional
TCHÊ,
disponível
em
81
http://www.sbc.org.br/reic/edicoes/2002e1/cientificos/ODesenvolvimentodoJogo
EducacionalTCHE.pdf
[36] MILLIGTON, I., Computacional Intelligence for games, Morgan
Kaufmann, 2006.
[37] MULLER, R. M.; CAVALCANTE, G. D.; DOS SANTOS L. I. dos Santos.
Laguna – Aprendendo sobre a Guerra do Paraguai com jogo educativo.
XIII Workshop de Informática na EscolI. 2006.
[38] NAKAMURA, R.; BERNADES, J.; TORI, R., enJine: Architecture and
application of an open-source didactic game engine. In Digital Proceedings
of the V Brazilian Symposium on Computer Games and Digital Entertainment,
pages 1–7, 2006.
[39] NAKAMURA, R. et al. A practical study on the usage of a commercial
game engine for the development of educational games. In: Proceedings of
the II Workshop de Jogos e Entretenimento Digital. Salvador: SBC, 2003.
[40] NEVES, F. Mod-games in training and education. Nos anais SBGAMES
2005 – Simpósio Brasileiro de Jogos para Computador e Entretenimento
Digital. Porto Alegre: Sociedade Brasileira de Computação. 200I.
[41] NYKL, S.; MOURNING, C.; LEITCH M.; CHELBERG, D.; FRANKLIN T.;
LIU C., An Overview of the STEAMiE Educational Game Engine. Disponivel
em:
http://vital.cs.ohiou.edu/steamwebsite/downloads/steamieFITOct08.pdf,
acessado em 20 de abril de 2009.
[42] OIS, disponível em http://www.wreckedgames.com/, acessado em 20 de
abril de 2009.
82
[43]
OpenAL,
disponível
em
http://connect.creativelabs.com/openal/default.aspx, acessado em 20 de abril
de 2009.
[44] PEDERSEN, R. E., Game Design Foundations. Wordware Game and
Graphics Library. 2003.
[45] PHYSX, disponível em http://br.nvidiI.com/object/nvidia_physx_br.html,
acessado em 20 de abril de 2009.
[46] PRIKLADNICKI R.; WANGENHEIM C. G., O Uso de Jogos Educacionais
para o Ensino de Gerência de Projetos de Software. No Fórum em
Educação de Engenharia de Software – FEES, 2008.
[47]
RAIOL,
D.
I.,
Motins
Políticos,
ou
História
dos
Principais
Acontecimentos Políticos da Província do Pará desde o Ano de 1821 até
1835, Editora da UFPA, 1970.
[48] REIS, F.; DAMASCENO, R.; SILVA, F.; RIBEIRO, M.. Jogo educativo
sobre a Revolução da Cabanagem – Fase Pré-Revolucionária; nos Anais
do XXVIII Congresso da SBC – WIE – Workshop sobre Informática na Escola,
Págs 156 – 16I. 2008.
[49] RIBEIRO, L. O. M.; TIMM M. I.; ZARO, M. I., Modificações em jogos
digitais e seu uso potencial como tecnologia educacional para o ensino
de
engenhariI.
Novas
Tecnologias
na
Educação.
Disponível
em:
http://www.cinted.ufrgs.br/renote/jul2006/artigosrenote/a36_21203.pdf,
acessado em 20 de abril de 2009.
[50] RIBEIRO, M.; BARATA, P.; NASCIMENTO, M.; SILVA, F.; Ambiente
Virtual Na Região do Rio Acará do Século XIX; in X Symposium of Virtual
and Augmented Reality, pags 396-399. 2008.
83
[51] RIEDER, R.; ZANELATTO, E.; BRANCHER, J. D. Observação e Análise
da Aplicação de Jogos Educacionais Bidimensionais em um Ambiente
Aberto. INFOCOMP – Journal of Computer Science, v. 4, n. 2, p. 63-71, jun.
200I.
[52] ROLLINS, I.; MORRIS D., "Game Architecture and Design", Coriolis Ed,
2000.
[53] ROSA, N. dos Santos; RAPKIEWICZ, C. E., Ensinando princípios
básicos de programação utilizando jogos educativos em um programa de
inclusão digital, No Simpósio Brasileiro de Jogos para Computador e
Entretenimento Digital. Porto Alegre: Sociedade Brasileira de Computação,
2007.
[54]
DAMASCENO,
R.
UTILIZANDO
TÉCNICAS
LIVRES
PARA
CONSTRUÇÃO DE JOGOS ELETRÔNICOS DIGITAIS: VERSÃO BETA DA
REVOLTA DA CABANAGEM. Trabalho de Conclusão de Curso - Universidade
Federal do Pará. 2006.
[55] ROVERE, I. S.; ZAGO, G. S., Uma Proposta do Uso do Second Life
como Ferramenta Educacional, XXX Congresso Brasileiro de Ciências da
Comunicação – Santos – 29 de agosto a 2 de setembro de 2007;
[56] SAGE, disponível em http://larc.unt.edu/sage/, acessado em 20 de abril de
2009.
[57] SANTANA, C.; SENA, G.; MOURA J.; ALVES, L. , Tríade: delineando o
processo de construção de um roteiro de um jogo eletrônico, no Simpósio
Brasileiro de Jogos para Computador e Entretenimento Digital, 2007.
[58] SAVI, R., Jogos digitais educacionais: benefícios e desafios. Novas
Tecnologias na Educação, Porto Alegre, v. 3, n. 1, Maio 200I.
84
[59] SEBBEN N.; GUEDES I. L., Desenvolvimento de Jogos para a Terceira
Idade, No Simpósio Brasileiro de Jogos para Computador e Entretenimento
Digital. Porto Alegre: Sociedade Brasileira de Computação, 2007.
[60]
SIMPSON,
J.,
Game
Engine
Anatomy
101,
disponível
em
http://www.extremetech.com/article2/0,2845,594,00.asp, acessado em 20 de
abril de 2009.
[61] STANG, B., Game engines: Features and possibilities. Technical
report, Institute of Informatics and Mathematical Modeling at The Technical
University of Denmark, 2003.
[62] TAROUCO, L. M. R.; ROLAND, L. C.; MASCARENAS M. J. F.;
PEDROSOS,
M.
L.,
Jogos
educacionais,
disponível
em
http://www.cinted.ufrgs.br/renote/mar2004/artigos/30-jogoseducacioanis.pdf
[63] TAVARES, R.; NEVES, F. Tutorial – Introdução ao Game Design
através da modificação de Half-Life. In: workshop brasileiro de artes e design
em jogos de computador e entretenimento digital, 2005, São Paulo. Anais
SBGAMES 2005 – Simpósio Brasileiro de Jogos para Computador e
Entretenimento Digital. Porto Alegre: Sociedade Brasileira de Computação.
2007.
[64] TIMM, M. I.; RIBEIRO, L. O. M.; LANDO, V.R.; AZEVEDO, I. M. P.; VIEIRA
E., Game educacional: desafios da integração de elementos ficcionais,
tecnológicos, cognitivos e de conteúdo. Simpósio Brasileiro de Jogos para
Computador e Entretenimento Digital. Porto Alegre: Sociedade Brasileira de
Computação, 2008.
[65] TOBALDINI, M. I.; MARTINELLI M.; BRANCHER, J. D., Arquiteturas
Históricas
no
Ambiente
de
um
Jogo
de
RPG
Educacional
Computadorizado, No Simpósio Brasileiro de Jogos para Computador e
85
Entretenimento Digital. Porto Alegre: Sociedade Brasileira de Computação,
2006.
86
I - APÊNDICE A: ESTUDO DE CASO
Neste apêndice será mostrado um estudo de caso de utilização do motor
de jogo desenvolvido. O estudo de caso é jogo da Cabanagem.
Jogo da Cabanagem é um jogo educacional construído para ensinar a
história da cabanagem. O jogo da cabanagem é um jogo educativo puramente
3D que reuni os estilos de aventura, estratégia e ação, que permite ao usuário
vivenciar a história da cabanagem desde o começo até o seu final. O jogo foi
implementado usando o motor de jogo proposto, descrito no capítulo 4.
O enredo do jogo está dividido em três partes de acordo com os
acontecimentos ocorridos na revolução:
1º Etapa: Período pré-revolucionário (1821 a 1823) que abrage as
missões conhecer Belém, fundar jornal O Paraense e Batista Campos.
2 º Etapa: Explosão do Conflito Armado (outubro de 1834) que abrange
as missões do acará.
3 º Etapa: Tomada do Poder ( 7 de janeiro de 1835) que abrange a
missão da tomada do poder em Belém.
I.1 HISTORIA DA REVOLUÇÃO DA CABANAGEM
A origem do movimento cabano é fundamentada na pregação do Frei
Luiz Zagalo sobre liberdade. Sendo expulso do Pará em 1817. No entanto,
deixou sementes em Felipe Alberto Patroni (1748-1866) e em João Batista
Gonçalves Campos (1782- 1834).
Felipe Patroni nasceu em uma cidade do Pará, chamada Acará [34]. Ele
cursava direito em Lisboa, e mesmo antes de terminar o curso, retorna ao
estado e passa a lutar diplomaticamente para que Portugal reconhecesse a
independência do Pará.
Ele realizou pronunciamentos, discursos e fundou o primeiro jornal do
Pará, para criticar Portugal, o qual poderia conceder a independência, mas não
o poder. Felipe tem sua imprensa perseguida e é preso. Quando solto, não
87
participa mais da causa paraense. Saindo do Pará, terminou o curso de direito
e por fim morreu no ano de 1866.
Batista Campos continuou com as publicações do jornal fundado por
Felipe Patroni. Ele também foi perseguido pelos portugueses, e por isto, o
movimento se intensificou e passou a ser marcado pela violência. Em 1834 ele
morre por não ter o devido cuidado médico a uma infecção de um ferimento,
isso por estar foragido no interior do estado do Pará. Batista Campos era o
principal líder dos cabanos, que invadiram Belém e tomaram o poder uma
semana após a sua morte. A luta revolucionária estava explodindo entre uma
vertente dominante, política e economicamente, e outra explorada e dominada.
Na vertente dominante estava o grupo português e filo-português. Na
vertente explorada e dominada estavam os liberais brasileiros, pequenos
proprietários, lavradores e pescadores.
A origem do nome do movimento deve-se a presença maciça dos
homens que moravam em cabanas, “homens das cabanas”.
A parte da história da cabanagem ensinada na primeira etapa concentrase em conhecer a cidade de Belém, no período do movimento, e nos
personagens Felipe Patroni e Batista Campos.
A parte da história da cabanagem ensinada na segunda etapa é sobre
os acontecimentos na região do acará que foi caracterizada como a explosão
do conflito armado.
A parte da história da cabanagem ensinada na terceira etapa é sobre os
acontecimentos da tomada do poder pelos cabanos.
I.2 ESTRUTURA DO JOGO
O jogo está estruturado em estados chamados de GameState[26], onde
cada estado representa uma situação no jogo, por exemplo o MainMenuState
representa o estado do menu principal do jogo. Os estados são gerenciados
pelo gerenciador GameStateManager. GameStateManager não é somente
responsável por gerenciar os estados, mas também da execução do game loop
e a atualização do jogo, do motor e dos subsistemas.
88
A aplicação do jogo cria uma instância de GameStateManager e deixa
que o gerenciador controle a execução do jogo.
I.2.1 Gerenciador de estados de jogo
Gerenciador de estados é gerenciador principal do jogo, no qual é
responsável pela execução do jogo, pela execução e atualização do estado
atual assim como da transição entre os estados. A Figura I.1 mostra a estrutura
do gerenciador de estado.
Figura I.1 Gerenciador de Estado.
I.2.1 Estado de jogo
Um estado de jogo corresponde a um momento especifico do jogo como,
por exemplo, o MainMenuState que corresponde ao estado de menu principal,
ou seja é a tela principal do jogo, que permite o jogador começar o jogo ou sair.
A Figura I.2 mostra a estrutura de um estado.
89
Figura I.2 Estado de Jogo.
Um estado é composto basicamente de três métodos principais: enter(),
exit(), pause(), update(unsigned log time).
• Enter(): Este método é o método executado quando o gerenciador
executa um estado. Neste método são inseridos todos os códigos de
criação da cena de um estado.
• Exit(): Este método é executado quando o gerenciador deixa de
executar este estado para executar outro estado ou finalizar o jogo.
Neste método é inserido todo o código de exclusão da cena, para a
liberação de memória.
• Pause (): Este método é executado quando o estado é pausado.
• Update(unsigned long): Este método é o método de atualização do
estado. Neste método é inserido todo o código que precisa ser
atualizado.
I.2.3 Diagrama de Estados
Um diagrama de estado mostra os possíveis estados de um objeto e as
transações responsáveis pelas suas mudanças de estado. A Figura I.3 mostra
o diagrama de estado do jogo, mostrando as transições de estados.
90
Figura I.3 Diagrama de estados do jogo.
IntroState: representa o estado introdutório do jogo, onde é mostrado uma tela
de apresentação mostrando o logo do jogo e dos produtores do jogo.
MainMenuState: Representa o estado de menu principal do jogo, nele o
jogador pode começar e sair do jogo, também pode acessar os extras do jogo.
LevelState: Representa o estado de escolha de missões, nele o jogador
poderá escolha qual missão deseja jogar.
LoadingState: Representa o estado que antecede as missões no qual é
exibido ao jogado informações sobre a fase escolhida.
EndingState: Representa o estado de final de missões, no qual apresenta
informações sobre a missão concluída.
ExtraState: Representa o estado de extras, no qual apresenta as informações
extras do jogo
CreditState: Representa o estado de créditos, no qual apresenta as
informações de crédito do jogo.
91
Mission1State,
Mission2State,
Mission3State,
AcaraState,
AcaraBatalhaState e Mission5State: Cada um desses estados representam
uma fase do jogo.
I.3 FUNCIONAMENTO DO JOGO
O funcionamento do jogo é dividido em duas etapas: Inicialização do jogo e
a execução do game loop.
I.3.1 Inicialização do jogo
A inicialização do jogo consiste nas seguintes subetapas:
1.
Criação e inicialização do gerenciador de estados: Nesta
subetapa são criados e inicializados o gerenciador de estados e os estados.
2.
Inicialização do motor: Esta subetapa está descrita na seção 4.2.
3.
Começa o primeiro estado: Depois do gerenciador inicializado, os
estados inicializados e o motor também inicializados, o gerenciador executa o
primeiro estado, no caso é o IntroState.
I.3.2 Game Loop
Após da etapa anterior é então executado o game loop. O game loop é
responsável pela atualização do jogo, do gerenciador de estados e dos
sistemas. A Figura I.4 mostra o fluxo de execução do game loop.
92
Figura I.4 Fluxo do game loop.
I.4 JOGO DA CABANAGEM
O jogo da cabanagem pode ser divido em três momentos principais:
menu principal, escolha das missões e as missões.
I.4.1 Menu
O menu principal é o primeiro contato do jogador com o ambiente do
jogo, podendo começar uma campanha, visualizar os créditos e extras e sair do
jogo. A Figura I.5 mostra o menu principal do jogo.
93
Figura I.5 Menu Principal.
I.4.2 Escolha das missões
A tela de escolha de missão é acessada quando o jogador começa uma
campanha. Na tela é disponível ao jogador a escolha da missão a ser jogada
assim como a dificuldade inerente aquela missão escolhida. Também são
mostradas ao jogador informações textuais e um mapa do local da missão. A
Figura I.6 mostra a tela de escolha de missões.
Figura I.6 Escolha das Missões.
94
I.4.3 Missões
Cada missão escolhida é divida em 3 partes: introdução, missão e fim. A
introdução é responsável por contextualizar o jogador sobre a missão escolhida
mostrando informações sobre os acontecimentos que envolvem a missão. A
missão corresponde à parte que é jogável, onde o jogador irá cumprir os
objetivos da missão. Por último, o fim que mostra as informações sobre o final
da missão concluída e sobre os acontecimentos inerentes aquela missão.
I.4.3.1 Missão #1: Fase Conhecer Belém
A missão começa com um vídeo introdutório mostrando informações
sobre o personagem Felipe Patroni e sobre a cidade de Belém do Grão Pará,
como mostra a Figura I.7.
Figura I.7 Vídeo Introdutório da Missão.
a) Objetivo: O objetivo desta missão é como o nome sugere e conhecer a
cidade de Belém no período de 1820 á 1830. Para isso o jogador controlará o
personagem Felipe Patroni no qual irá visitar seis lugares importantes da
cidade de Belém que são os quartéis, o forte São Pedro Nolasco, Arsenal de
Guerra, Hospital a Igreja da Sé e o Forte do Castelo. Todos os objetivos estão
descritos no inventário da missão mostrado na Figura I.8.
95
Figura I.8 Inventário da Missão.
b) Cenário: O cenário da missão é cidade de Belém no ano de 1820 e é
constituído de prédios, igrejas, pelourinho, forte do Castelo e São Pedro
Nolasco, e o palácio do governo. O cenário também contém uma música
ambiente. A Figura I.9 mostra o cenário da missão.
Figura I.9 Cenário da Missão.
c) Personagens: Além do personagem Felipe Patroni controlado pelo jogador,
há outros personagens pela cidade. Estes são alguns cabanos, escravos,
96
lenhadores e soldados que ficam passeando pela cidade, além dos cabanos
que ficam na frente dos locais dos objetivos. Os personagens da missão são
mostrados na Figura I.10.
Figura I.10 Personagens da Missão: Cabano, escravo, lenhador e um soldado.
d) Desafio: Nesta missão não há desafio, pois a missão é apenas para
conhecer o ambiente virtual e para aprender sobre os movimentos básicos do
controle do personagem.
e) Inicio da Missão: A missão começa com o personagem no lugar chamado
de Pelourinho, e a partir daí pode começar a aventura de conhecer os locais
determinados. O jogador pode utilizar um minimap localizado na parte superior
direita da tela para se guiar no ambiente e além do mapa da cidade também
disponibilizado. A Figura I.11 mostra o começo da missão no qual é mostrado
personagem Felipe Patroni e também pode se observar o minimap localizado
no canto superior direito.
97
Figura I.11. Inicio da Missão.
f) Durante a Missão: O jogador pode navegar livremente no ambiente do jogo
e quando o personagem se aproxima do local a ser visitado é mostrada uma
mensagem informativa conforme mostra a Figura I.12.
Figura I.12. Personagem próximo ao objetivo.
g) Condição de Derrota: Nesta missão não há condição de derrota, pois a
missão é apenas para o jogador aprender a controlar o personagem e para
conhecer sobre o ambiente virtual.
98
h) Fim da Missão: O fim da missão é atingido quando todos os objetivos são
conquistados. Ao concluir a missão é mostrada uma tela informativa sobre a
missão concluída conforme mostra a Figura I.13.
Figura I.13. Fim da Missão Belém 1820 – 183I.
Missão #2: Fundar o Jornal “O Paraense”
A missão começa com uma tela introdutória mostrando informações
sobre o personagem Felipe Patroni e da imprensa local, como mostra a Figura
I.14.
Figura I.14. Tela introdutória da Missão Fundar o jornal “O Paraense”.
99
a) Objetivo: O objetivo desta missão é contar a história do personagem Felipe
Patroni, um dos principais personagens da revolução cabana, e sobre a origem
da imprensa paraense. A missão tem quatro objetivos que são: obter a
máquina tipográfica, obter tinta e papel, fundar o jornal “O Paraense” e entregar
a primeira versão do jornal ao personagem Batista Campos. A Figura I.15
mostra o inventario da missão.
Figura I.1I. Inventário da Missão.
b) Cenário: O cenário da missão é cidade de Belém no ano de 1820 é
constituído de prédios, igrejas, pelourinho, forte do Castelo e São Pedro
Nolasco, e o palácio do governo. O cenário também contém uma música
ambiente. A Figura I.16 mostra o cenário da missão.
100
Figura I.16. Cenário da Missão.
c) Personagens: Os personagens que fazem parte desta missão são o Felipe
Patroni, o herói, os soldados do governo português, que irão perseguir Felipe
Patroni, Batista Campos além dos cabanos que ficam na frente dos locais dos
objetivos. Os personagens da missão são mostrados na Figura I.17.
Figura I.17 Personagens da Missão: Felipe Patroni, Batista Campos, soldado e um
cabano.
d) Desafio: O desafio desta missão está em concluir os objetivos sem ser
capturado pelos soldados do governo português.
101
e) Inicio da Missão: A missão começa com o personagem localizado no forte
do castelo e a partir daí pode começar a aventura de ir até os locais
determinados. O jogador pode utilizar um minimap localizado na parte superior
direita da tela para se guiar no ambiente e além do mapa da cidade também
disponibilizado. A Figura I.18 mostra o começo da missão no qual é
personagem o Felipe Patroni e também pode se observar o minimap localizado
no canto superior direito.
Figura I.18. Inicio da Missão.
f) Durante a Missão: O jogador pode navegar livremente no ambiente do jogo
e quando o personagem se aproxima do local a ser visitado é mostrada uma
mensagem informativa conforme mostra a Figura I.19.
102
Figura I.19. Personagem próximo ao objetivo.
g) Condição de Derrota: A condição de derrota da missão é permitir que o
personagem seja capturado pelos soldados do império. A Figura I.20 mostra o
personagem Felipe Patroni sendo capturado por um soldado português.
Figura I.20 Felipe Patroni capturado por um soldado.
h) Fim da Missão: O fim da missão é atingido quando todos os objetivos são
conquistados. Ao concluir a missão é mostrada uma tela informativa sobre a
missão concluída conforme mostra a Figura I.21.
103
Figura I.21 Fim da Missão Jornal O Paraense.
Missão #3: Batista Campos
A missão começa com uma tela introdutória mostrando informações
sobre o personagem Batista Campos, como mostra a Figura I.22.
.
Figura I.22. Tela introdutória da Missão.
a) Objetivo: O objetivo desta missão está em conduzir o personagem Batista
Campos para próximo das margens do rio Guamá, para que o personagem
possa pegar um barco, para fugir da perseguição do governo Português, para o
104
interior. A Figura I.23 mostra o inventario da missão com o objetivo a ser
executado.
Figura I.23. Inventário da Missão.
b) Cenário: O cenário da missão é cidade de Belém no ano de 1820 é
constituído de prédios, igrejas, pelourinho, forte do Castelo e São Pedro
Nolasco, e o palácio do governo. O cenário também contém uma música
ambiente. A Figura I.24 mostra o cenário da missão.
Figura I.24 Cenário da Missão.
105
c) Personagens: Os personagens que fazem parte desta missão são o Batista
Campos e os soldados do governo português, que irão perseguir Batista
Campos. Os personagens da missão são mostrados na Figura I.2I.
Figura I.25 Personagens da Missão: Batista Campos e um soldado.
d) Desafio: O desafio desta missão está na perseguição mais agressiva dos
soldados ao personagem Batista Campos, podendo até matarem o
personagem.
e) Inicio da Missão: A missão se inicia no local onde finalizou a missão
anterior e a partir daí pode começa a aventura de chegar até as margens do rio
Guamá sem ser morto pelos soldados que estão procurando por Batista
Campos. O jogador pode utilizar um minimap localizado na parte superior
direita da tela para se guiar no ambiente e além do mapa da cidade também
disponibilizado. A Figura I.26 mostra o começo da missão no qual é mostrado o
personagem Batista Campos e também pode se observar o minimap localizado
no canto superior direito.
106
Figura I.26. Inicio da Missão Batista Campos.
f) Durante a Missão: O jogador pode navegar livremente no ambiente do jogo
e quando o personagem se aproxima do local do objetivo é mostrada uma
animação mostrando o personagem pegando um bote nas margens do rio e
remando pelo rio Guamá conforme mostra a Figura I.27.
Figura I.27. Personagem Batista Campos remando num bote.
g) Condição de Derrota: A condição de derrota da missão está em permitir
que os soldados matem o personagem Batista Campos. A Figura I.28 mostra
um soldado matando o personagem Batista Campos.
107
Figura I.28 Personagem Batista Campos sendo morto por um soldado.
h) Fim da Missão: O fim da missão é atingido quando o objetivo da missão é
conquistado. Ao concluir a missão é mostrada uma tela informativa sobre a
missão concluída conforme mostra a Figura I.29.
Figura I.29. Fim da Missão.
I.4.4 Missão #4: Acará
A missão começa com um vídeo introdutório mostrando informações
sobre os acontecimentos de perseguição do império ao Batista Campos e
108
sobre o império Português no Brasil. A Figura I.30 mostra uma imagem do
vídeo introdutório.
Figura I.30 Vídeo Introdutório da Missão do Acará.
a) Objetivo: O objetivo desta missão é vender os recursos para conseguir a
capacidade de atacar as tropas do império. O jogador controlará o personagem
Félix Malcher ou Francisco Vinagre que irão comandar os cabanos, escravos,
lenhadores para a obtenção dos recursos. A Figura I.31 mostra o inventário da
missão contendo o objetivo da missão e os comandos do jogo.
Figura I.31 Inventário da Missão do Acará.
109
b) Cenário: A missão acontece em dois cenários: Na fazenda Acará-Açu e no
Sítio Santa Cruz. A fazenda Acará-Açu é a fazenda do personagem Felix
Malcher e ela possui uma senzala, casa grande, igreja e áreas de coletas dos
recursos: cana, madeira, peixe. O Sitio Santa Cruz é sitio do Francisco Vinagre
e tem uma plantação de mandioca e uma casa de moinho para fazer farinha.
c) Personagens: Os personagens que fazem partes desta missão são os
cabanos, escravos, lenhadores, Felix Malcher e Francisco Vinagre. Os
personagens da missão são mostrados na Figura I.32.
Figura I.32 Personagens da Missão: Cabano, Escravo, Lenhador, Fèlix Malcher e
Francisco Vinagre.
d) Desafio: Nesta missão, o desafio está em obter todos os recursos dentro de
um intervalo de tempo determinado pelo nível de dificuldade da missão.
e) Inicio da Missão: A missão inicia na fazenda Acará-Açu, no qual o jogador
irá controlar o personagem Félix Malcher e a partir daí o jogador pode começar
a comandar os cabanos, escravos e lenhadores para a obtenção dos recursos.
A Figura I.33 mostra o personagem Malcher e a interface da missão.
110
Figura I.33 Personagem Félix Malcher e a interface.
f) Durante a Missão: Durante a missão o jogador poderá visualizar a
quantidade de recurso obtido e o tempo que falta para a tropa portuguesa
chegar a fazenda. O jogador poderá alternar o controle das duas fazendas ao
longo do jogo através das teclas F9 ou F10. Ao acionar a tecla F9 ou F10
acontece uma animação de uma viagem de uma fazenda a outra ao longo do
rio Acará, mostrado na Figura I.34.
Figura I.34 Viagem entre as fazendas.
111
h) Condição de derrota: A condição de derrota está quando expira o tempo de
obtenção de recursos e não foram obtidos recursos suficientes.
g) Fim da Missão: O fim da missão ocorre quando os recursos necessários
foram obtidos e então o jogador deverá chamar o Angelim para começar o
ataque.
I.4.5 Missão #5: Batalha no Acará
A missão inicia logo após o fim da missão anterior do Acará.
a) Objetivo: A missão tem como objetivo principal a morte do soldado
comandante do império José Maria Nabuco de Araujo. Para isso o jogador irá
controlar o personagem Angelim que é auxiliado pelo personagem Francisco
Vinagre. A Figura I.35 mostra o inventário da missão contendo o objetivo da
missão e os comandos do jogo.
Figura I.35 Inventário da Missão
b) Cenário: A missão acontece na fazenda Vila Nova no qual é constituída de
uma pequena casa onde está a tropa portuguesa e umas plantações.
112
c) Personagens: Os personagens que fazem partes desta missão são:
Angelim,
Francisco
vinagre,
cabanos,
escravos,
lenhadores,
soldados
portugueses e o comandante Nabuco de Araújo. Os personagens da missão
estão mostrados na Figura I.36.
Figura I.36 Personagens da Missão: Cabano, Escravo, Lenhador, Soldado, Comandante,
Francisco Vinagre e Angelim.
d) Desafio: O desafio desta missão está em derrotar com todos os soldados do
império sem deixar o personagem Angelim morrer.
e) Inicio da Missão: A missão começa mostrando uma tecla das escolhas das
equipes de cabanos, escravos e lenhadores, para começar o ataque ao
pequeno quartel dos soldados do império. A Figura I.34 mostra a tela de
escolha das equipes.
f) Durante a Missão: Após a escolha das equipes o ataque pode ser iniciado.
O jogador poderá enviar de dois em dois de cada equipe para atacar o quartel
usando as teclas 1,2 ou 3, cada tecla é responsável por enviar dois cabanos de
uma equipe, contudo para poder chamar novamente mais dois é necessário
aguarda um intervalo de tempo determinado. A Figura I.37 mostra uma imagem
do personagem Angelim armado com uma arma tipo bacamarte e vários
cabanos indo atacar o quartel. Também é mostrada uma tela na parte inferior
mostrando qual a equipe dos cabanos escolhidos e o tempo para mandar
novamente mais dois cabanos atacarem.
113
Figura I.37 Angelim e vários cabanos indo atacar o quartel.
h) Condição de derrota: A condição de derrota desta missão está em permitir
a morte do personagem Angelim.
g) Fim da Missão: O A missão finaliza quando o comandante Nabuco de
Araújo morre pelo personagem Angelim. Logo após a morte é mostrado um
vídeo mostrando informações sobre o ataque no acará. A Figura I.38 mostra
uma imagem deste vídeo.
Figura I.38. Vídeo sobre o ataque no Acará.
114
Missão #6: Batalha em Belém
A missão começa com um vídeo introdutório sobre os acontecimentos
sobre o final da batalha no acará, mostrado na Figura I.39 e uma tela
introdutória mostrando informações sobre a batalha em Belém.
Figura I.39. Vídeo introdutório da Missão.
a) Objetivo: O objetivo desta missão é conquistar os diversos locais da cidade
de Belém para conseguir tomar o poder do império no Brasil. Os locais a serem
conquistados são: Quartéis, Arsenal de Guerra, Forte do Castelo e Palácio do
governo. A Figura I.40 mostra o inventario da missão com o objetivo a ser
executado.
115
Figura I.40. Inventário da Missão.
b) Cenário: O cenário da missão é cidade de Belém no ano de 1835 e é
constituído de prédios, igrejas, pelourinho, forte do Castelo e São Pedro
Nolasco, e o palácio do governo. O cenário também contém uma música
ambiente. A Figura I.41 mostra o cenário da missão.
Figura I.41 Cenário da Missão.
c) Personagens: Os personagens que fazem parte desta missão são: Angelim,
Francisco Vinagre, cabanos, escravos, lenhadores, soldados do império e o
116
governador Malhado. Os personagens da missão são mostrados na Figura
I.42.
Figura I.42 Personagens da Missão: Cabano, Escravo, Lenhador, Soldado, Francisco
Vinagre, Angelim e o Malhado.
d) Desafio: Nesta missão o desafio está em conquistar todos os quatro locais
de ataque matando todos os soldados e no final matar o governador Lobo de
Souza (malhado).
e) Inicio da Missão: A missão se inicia numa região afastada do centro da
cidade próximo ao Mosteiro São José Liberto, onde o jogador controla o
personagem Angelim armado com uma arma do tipo bacamarte que controla
outros cabanos para o ataque. O jogador pode utilizar um minimap localizado
na parte superior direita da tela para se guiar no ambiente e além do mapa da
cidade que também é disponibilizado. A Figura I.43 mostra o começo da
missão onde mostra o personagem Angelim e alguns cabanos, também pode
se observar o minimap localizado no canto superior direito.
117
Figura I.43 Começo da missão.
f) Durante a Missão: O jogador controla o personagem Angelim que pode
navegar livremente no ambiente do jogo. Há outros cabanos ajudando o
Angelim a conquistar os locais, contudo estes ficam aguardando o Angelim
chegar próximo ao local a ser atacado para que estes o ajudem. A Figura I.44
mostra essa situação, onde os cabanos esperam por Angelim para atacar o
quartel.
Figura I.44 Cabanos aguardando pelo Angelim.
g) Condição de Derrota: A condição de derrota está em permitir que o
personagem Angelim morra.
118
h) Fim da Missão: A missão finaliza quando o governador Malhado é morto
pelos cabanos subindo as escadarias do palácio do governo. A Figura I.45
mostra a animação da morte governador Lobo de Souza.
Figura I.45 Morte do governador Lobo de Souza.
119
II - Apêndice B: Diagrama de Classes do Núcleo do Motor.
120
III - Apêndice C: Diagrama de Classes do sistema fuzzy.
121
IV - Apêndice D: Código fonte exemplo do uso do motor
proposto.
#include "Mission1State.h"
namespace JogoCabanagem
{
Mission1State* MissionState::mMission1State;
void Mission1State::enter( void )
{
GameEnvManager::getSingletonPtr()->setLevel(1);
mGraphicManager
mGraphicWindow
mOverlayMgr
mGraphicsScene
"TerrainSceneManager" );
mCamera
mViewport
GameScene *mGameScene
>createScene(mGraphicsScene);
= Root::getSingletonPtr();
= mGraphicManager->getAutoCreatedWindow();
= OverlayManager::getSingletonPtr();
= mGraphicManager->getSceneManager(
= mGraphicsScene->createCamera( "Mission1Camera" );
= mGraphicWindow->addViewport( mCamera );
= GameManager::getSingletonPtr()-
mGraphicsScene->setSkyBox(true, "Jogo/CloudyNoonSkyBox");
mGraphicsScene->setAmbientLight(ColourValue(0.6, 0.6, 0.6));
ColourValue fadeColour(0.93, 0.86, 0.76);
mGraphicsScene->setFog( FOG_LINEAR, fadeColour, .01, 4000, 7000);
mViewport->setBackgroundColour(fadeColour);
mPhyMgr = PhysicsManager::getSingletonPtr();
mPhyMgr->initialize(mGraphicsScene);
mSoundMgr = SoundManager::getSingletonPtr();
mSoundMgr->initialize(mGraphicsScene);
PhysicScene *mPhysicScene = mPhyMgr->createScene("CenaFisica","gravity: yes, floor:
yes");
mGameScene->LoadSceneFromXML("fasetour.xml");
mActorManager = JogoCabanagem::ActorManager::getSingletonPtr();
mActorManager->addActor("TTTT","felipepatroni.xml");
mActorManager->getActor("TTTT")->setFriendlyGroup("CABANO");
mActorManager->getActor("TTTT")->setEnemyGroup("PORTUGUESES");
GameCameraController camera_actor = new GameCameraController(mActorManager>getActor("TTTT"));
mActorController = new
JogoCabanagem::ActorController(mGraphicsScene,mActorManager>getActor("TTTT"),camera_actor);
setupWaypoints();
setupAI();
minimap = new JogoCabanagem::MiniMap();
minimap->show();
}