Uma Nova Concepção para a Criação de

Jogos Educativos

Esteban Walter Gonzalez Clua1, João Ricardo Bittencourt2

1
ICAD – IGames / VisionLab
Departamento de Informática – PUC – Rio
Rio de Janeiro/RJ
esteban@inf.puc-rio.br
2
Centro de Ciências Naturais e Tecnológicas
UNIFRA - Centro Universitário Franciscano
Santa Maria/RS
jrbitt@unifra.br

Resumo: Este documento apresenta uma discussão sobre a possível utilização de

jogos computadorizados na educação de jovens e está dividido em três partes: 1)
Introdução e motivação, onde se apresentam os principais argumentos sobre a
conveniência de utilizar jogos de computadores no processo de ensino-
aprendizagem; 2) Ferramentas, onde se apresentam resumidamente os processos
necessários para se confeccionar um game 3D, focando especialmente os softwares
e programas necessários para tal e 3) as tendências futuras, onde se apresentam os
caminhos para onde o desenvolvimento de games tende a ir nos próximos anos,
procurando discutir como estes rumos poderão ajudar e melhorar o processo
educacional. Como apêndice ao documento encontra-se um tutorial breve sobre um
engine comercial, que pode ser utilizado para a construção de jogos
computadorizados com fins didáticos.

1. Introdução e motivação
O mercado de jogos para computadores está crescendo de forma rápida, surpreendendo
até os visionários mais otimistas. Enquanto em 2000 o faturamento da indústria mundial
de jogos computadorizados não ultrapassou os US$ 10 bilhões, o ano de 2003 terminou
com um faturamento equivalente a US$ 28,8 bilhões, o que equivale a quase três vezes
a receita gerada pela indústria cinematográfica. Atualmente mais de duzentos títulos são
lançados por ano e apenas nos Estados Unidos mais de 225 milhões de jogos foram
vendidos em 2003 (valor superior ao total de ingressos vendidos pela NBA no mesmo
ano). O investimento que empresas de desenvolvimento estão fazendo também estão
atingindo cifras astronômicas: a Square, por exemplo, gastou mais de US$ 10 milhões
na produção do bem sucedido Final Fantasy XI.
Estas cifras altas apenas retratam o grande interesse e entusiasmo que os games
produzem em diferentes públicos - crianças, adolescentes e adultos jovens. No Brasil, o
número de LAN Houses abertas em apenas dois anos está próximo de 10 mil, sendo que
em alguns bairros das grandes cidades é tão comum encontrar estes estabelecimentos,
como encontrar uma padaria ou uma farmácia. O número de títulos de revistas sobre
games nas bancas de jornal é superior a qualquer outro tema específico, o número de
sites dedicados ao assunto é incontável. Não é para menos: numa pesquisa realizada no
Rio de Janeiro com garotos de classe média e na faixa etária de 10 a 17 anos registrou
que 38% dos garotos (sexo masculino) jogam mais de 20 horas por semana, durante o
ano letivo [CLU 02].
Os jogos educacionais computadorizados são uma das modalidades de CAI
(Computer Assisted Instruction) proposto por Coburn, Kelman, Roberts et al [COB 88]
e são elaborados para divertir os alunos, desta forma aumentando a chance de
aprenderem os conceitos, o conteúdo ou as habilidades embutidas no jogo. Os jogos
educacionais podem ser bastante simples como os de exercícios e práticas, mas podem
ser ambientes de aprendizagem ricos e complexos, denominados por alguns de
micromundos, porque estes fornecem um mundo imaginário para ser explorado pelo
aluno. Para Papert apud Kafai [KAF 95] micromundos são ambientes de aprendizagem
interativos baseados em computador na qual os pré-requisitos estão construídos no
sistema e os aprendizes podem se tornar ativos, construindo sua própria aprendizagem.
Para Amory [AMO 01], os jogos educativos requerem enredos atraentes. Para o
autor é muito importante utilizar os jogos computadorizados no processo educacional
pelo fato dos jogos afetarem a motivação, as funções cognitivas e a curiosidade do
aprendiz, pois estes jogos permitem a experimentação e a exploração do usuário. Um
dos grandes problemas dos jogos educativos é apresentar para o aprendiz uma coleção
de enigmas sem nenhuma ligação, tornando o jogo desinteressante. Por isto é
interessante 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 imerso em micromundos
construtivistas.
Para Kafai [KAF 01], basicamente existem duas abordagens para o
desenvolvimento de jogos com propósitos educacionais. A abordagem instrucional e a
construtivista. A abordagem instrucional consiste da maioria dos jogos voltados para
ensinar. A criança aprende algo enquanto faz uma determinada atividade, pois existe
uma integração do conteúdo que será ensinado com a idéia do jogo. A outra abordagem
é a construtivista, os jogos são usados para aprender. As crianças constroem seus
mundos utilizando ferramentas computacionais, muitas vezes linguagem de
programação, tais como LOGO. Kafai [KAF 95] realizou um projeto com crianças de
10 anos de idade para o desenvolvimento de jogos computadorizados visando o ensino
de frações para alunos que estavam cursando o ensino fundamental. O projeto dos jogos
foi extremamente desafiador para os aprendizes que tiveram que planejar, resolver
problemas, projetar, ensinar e revisar diversos conteúdos sobre frações.
Segundo Jenson & Castel [JEN 02], 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
a imersão onde os usuários queiram estar, explorar e aprender da mesma forma que os
aprendizes fazem nos jogos 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 didáticos 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. Os autores coordenam o projeto Ludus Vitae que consiste de um
ambiente imersivo de jogo on-line focado no personagem com várias áreas e caminhos
que podem ser explorados livremente pelo aluno. Tanto professores quanto aprendizes
colaboram na construção deste mundo. Cria-se a idéia de uma comunidade,
independente das fronteiras curriculares.
Não é necessário muito esforço para se concluir que diante deste contexto, os
games possuem – e seguindo as tendências de mercado, irão possuir muito mais nos
próximos anos – uma forte influência na forma de pensar, no comportamento social,
psicológico e educacional dos jovens. Surgem daí algumas perguntas: esta influência é
positiva? Como educar os jovens dentro desta nova realidade? Os jovens nascidos neste
contexto de expansão das telecomunicações e das tecnologias da informação estão
sendo preparados para uma sociedade futura? De forma pragmática, a escola está apta
para preparar os jovens atuais para exercer sua cidadania e atuarem no mercado de
trabalho em 2021?
1.2 Causas da atratividade dos jogos para computadores
Apesar dos jogos apresentarem vários níveis de conceitos de razoável complexidade,
surge uma pergunta: como usuários com faixas de idade entre 10 e 17 anos conseguem
não só aprender estes conceitos, mas, em especial, se interessar por aprendê-los, quando
muitas vezes não apresentam o mesmo interesse para aprender conceitos de mesmo
nível de complexidade abordados em disciplinas escolares? A resposta pode estar
associada a fatores como atração e desafio. Numa pesquisa realizada por um dos
autores, uma das perguntas feitas foi a seguinte:
- “Porquê você gosta de jogos para computadores?”
A maioria das pessoas respondeu que sentem atração devido ao desafio imposto
pelo mesmo. Uma parcela considerável também respondeu que gosta dos jogos devido à
história e à qualidade gráfica do mesmo.
De fato, um dos principais componentes para que um jogo seja atrativo consiste
no fato de colocar o jogador perante um desafio. Quanto maior for este desafio, maior
será a vontade de ganhar e, portanto, mais atração trará ao jogador. É por isso que jogos
de futebol com times difíceis ou rivais (Brasil x Argentina ou Flamengo x Vasco)
sempre causam mais atração e chamam um público maior do que outras partidas mais
fáceis (Flamengo x Bangu).
Jogos para computadores usualmente fornecem ambientes dotados de interfaces
com alta interatividade e visual sofisticado composto por várias mídias integradas,
podendo assim criar ambientes muito imersivos e, portanto, bastante desafiadores, dado
o realismo imposto. Por exemplo, Metal Gear Solid II ou Resident Evil: Code Veronica.
Além disso, os jogos possuem a possibilidade de contar histórias ricas, com roteiros
originais, por exemplo, Shenmue ou Final Fantasy. Percebeu-se neste trabalho que
desafio e histórias bem contadas são fatores críticos de sucesso no desenvolvimento de
jogos com um forte poder educativo.
Thomas Malone identificou três características que tornam os jogos
computadorizados intrinsecamente motivadores [COB 88]: desafio, fantasia e
curiosidade. Para Greenfield [GRE 88], os jogos computadorizados são atraentes para as
crianças porque estas desenvolveram preferências pelas imagens visuais dinâmicas e
animadas devido à experiência televisiva e devido à interatividade, pois a criança pode
agir no jogo.
Assim diante deste contexto devemos repensar o significado dos “jogos
computadorizados educativos”. Como foi apresentado anteriormente criou-se uma
divisão entre jogos comerciais e jogos educativos. Primeiramente tal denominação já
estabelece um pressuposto que os jogos educativos não podem ser comerciais e vice-
versa. Sabe que o primeiro grupo possui um forte apelo para os jovens, alta qualidade
técnica e um conteúdo de puro entretenimento, enquanto que o segundo tem um fraco
apelo entre os jovens, baixa qualidade e um enfoque altamente conteudista. Battaiola
[BAT 00] e Bates [BAT 01] consideram jogos educativos como uma modalidade de
jogo computadorizado. Nestes jogos existe uma proposta pedagógica explícita, seu
principal objetivo é ensinar algo de uma forma lúdica. Tal modalidade é conhecida
como eduntainment [BAT 00]. Para Rollings & Morris [ROL 04], existem os estilos de
jogos e estes não são categorizados em um único grupo, ou seja, em geral os jogos
apresentam características de diferentes estilos. Um dos estilos propostos por Rolling &
Morris é o estilo educacional, cujo aprendizado é efetuado através da prática. Baseando-
se nesta concepção de Rollings & Morris que permite que os jogos assumam diferentes
estilos pode-se afirmar que os jogos podem ser desenvolvidos com um estilo educativo.
Assim, por exemplo, podem existir jogos de ação, de estratégia, de RPG, de esporte
educativos.
Na Figura 1 estão representados estes conceitos. Independente de um jogo
computadorizado possuir objetivos pedagógicos explícitos os jogos podem ser
considerados educativos pelo fato de desenvolver habilidades cognitivas importantes
para o processo de aprendizagem - resolução de problemas, percepção, criatividade,
raciocínio rápido, entre outras habilidades. Caso o jogo desde seu planejamento tenha
especificado propósitos conteudistas e para ser utilizado dentro do âmbito escolar
denomina-se tal jogo como didático. Se este jogo não possui objetivos pedagógicos
explicítos, foram desenvolvidos enfatizando o entretenimento, denomina-se tais jogos
de entretenimento.

Jogos E du cat i vos

Jogos de Jogos
E n t r et en i m en t o D i dát i cos
Figura 1: Esquema comparativo dos jogos de entretenimento e jogos
didáticos

Um ponto importante que precisa ser destacado para compreensão desta questão
é a diferenciação entre a mecânica de um jogo e o seu conteúdo e que ambas possuem
caráter educativo. Existem jogos que possuem um conteúdo cuja temática envolvem
aspectos de extrema violência, sexo, entre outras características indesejáveis de serem
abordados em um espaço de aprendizagem, tais como as salas de aula. O jogo Grand
Theft Auto da RockStar Games é um exemplo de jogo cujo protagonista é um criminoso
e as missões oferecidas pelo jogo envolve questões ilegais realizadas no submundo de
uma cidade fictícia. Entretanto este jogo é uma mistura de ação e aventura. O jogo Grim
Fandango da Eletronic Arts também possui estes mesmos estilos, entretanto sua
temática é diferenciada, pois trata de uma fábula que envolve o Dia dos Mortos, um
evento importante culturalmente no México. Se considerarmos este jogo, o Sim City
2000 da Eletronic Arts e o Ages of Empires da Microsoft que foram desenvolvidos sem
uma intenção de educar, também poderiam ser utilizados no escopo escolar pelo fato de
possuírem um conteúdo que pode ser explorado de forma educacional. Andrade,
Zavaleta, Vaz et al [AND 03] consideram que os jogos computadorizados inteligentes
(jogos com uma Inteligência Artificial sofisticada, por exemplo, The Sims) com
objetivos psicopedagógicos bem definidos podem ser usados para desenvolver
habilidades cognitivas, tais como criatividade e visão espacial. O que deve ser
considerado é o conteúdo de um jogo, pois a mecânica dos jogos computadorizados é
implicitamente educativa. No caso da comparação entre Grim Fandango e o Grand
Thief Auto destacam-se os estilos, a mecânica do jogo que permite o desenvolvimento
de habilidades meta-cognitivas, tais como a resolução de problemas. A diferenciação
está na temática. Portanto quando se utiliza o termo jogos computadorizados educativos
referem-se a um jogo que possui explicitamente uma proposta pedagógica, entretanto
não se exclui o caráter educativo de todos os jogos computadorizados mesmo sem um
propósito pedagógico explícito.
Atualmente, os jogos com propósitos didáticos, em geral, são feitos para
crianças e portanto apresentam baixo nível de desafio e muitas cores e desenhos. Hoje,
os jovens e uma pequena parcela do público adulto estão interessados principalmente
em jogos que tenham elementos em 3D e bastante realismo. Desta maneira, os jogos
educativos têm sido vistos com bastante desprezo pelo público jovem. Na pesquisa
realizada [CLU 02], apenas 27% disseram que gostaram de algum jogo educativo que
jogaram. Por outro lado, 68% afirmaram que consideram todos os jogos educativos que
conhecem como sendo ruins.
Segundo a Teem (Teachers Evaluating Educational Multimedia), atualmente a
principal contribuição dos jogos na educação é estimular as pessoas a ganharem
importantes habilidades, como negociação, planejamento, pensamento estratégico e
tomada de decisões. Entretanto, neste trabalho será apresentado uma abordagem mais
objetiva para o processo de ensino-aprendizagem através dos jogos computadorizados.
É importante destacar que esta abordagem não trata-se de nenhuma espécie de
"joguismo", ou seja, uma postura dogmática na qual percebe-se os jogos
computadorizados como a única tecnologia capaz de desenvolver as habilidades
cognitivas dos aprendizes, mas compreende-se os jogos computadorizados como uma
tecnologia educacional enquadrada no contexto cibercultural do século XXI capaz de
auxiliar, junto com demais tecnologias de ensino, e potencializar o processo de
aprendizagem deste aprendiz pós-industrial contextualizado em uma sociedade da
informação e do conhecimento.
1.3 Imersividade: elemento chave para um jogo
Em computação gráfica existem muitos graus de imersividade, seja num cenário 3D ou
não. O conceito de imersividade está relacionado com o grau de interatividade que um
usuário é capaz de ter numa aplicação. Esta interatividade não está apenas relacionada à
capacidade de "andar" num cenário, mas também com a capacidade de interagir com
objetos e outros personagens dentro deste mundo virtual. Outros fatores que permitem
aumentar o grau de imersividade de uma aplicação são o seu foto-realsimo (semelhança
com o mundo real) e estímulos sensoriais, que podem ser dados por joysticks e diversos
dispositivos de entrada (como por exemplo no joystick Dual Shock 2, do Playstation 2,
pode-se o perceber até 128 níveis de pressão no controle, além de ser capaz de fazer
com que o controle vibre de acordo com situações do jogo, como por exemplo quando
um carro passa raspando na parede ou entra no banco de areia da pista).
Num jogo 3D pode-se fazer o usuário “mergulhar” dentro dele, utilizando-se de
um grau de interatividade que se aproxima do mundo real, em alguns aspectos.
Exemplos de jogos assim são aqueles gerados para novos consoles, tais como o X-Box,
o Playstation 2 ou o Game Cube. O Metal Gear Solid III é um exemplo onde guardas
podem até identificar o personagem pela sua sombra e o jogador é capaz de interagir
com praticamente qualquer objeto da cena. Outro exemplo é o jogo The Sims II onde o
jogador deve realizar tarefas do cotidiano interagindo com os objetos de sua casa e as
pessoas à sua volta. O jogo Shenmue que é feito em terceira pessoa com um nível de
ação e imersividade extremamente altos, por exemplo, dentro do jogo é possível ir a
fliperamas, comprar chocolates, telefonar para casa, arrumar emprego, entre outras
ações.
Para Battaiola, Elias, Domingues et al [BAT 02], a motivação é o componente
mais importante para o aprendizado. O sucesso de um jogo é a combinação perfeita de
enredo, interface interativa e o motor do jogo. Tal motivação somente é obtida nos jogos
com propósitos didáticos, se tais permitirem uma maior imersão. Para estes autores a
questão é porque não usar alguns princípios dos jogos computadorizados comerciais
(sem finalidades didáticas explícitas) de grande aceitação pelos jovens para implementar
softwares educacionais, de forma a torná-los mais atrativos?
Desta forma é possível deduzir que os jogos didáticos poderão tornar-se mais
motivadores no momento que deixarem de ser fortemente pedagógicos e agregar em sua
concepção, tecnologias e técnicas de criação oriundas dos jogos de entretenimento, tão
atrativos para os jovens. Assim a Computação Gráfica, a Inteligência Artificial,
Processamento Distribuído, a Interação Homem-Máquina, a elaboração de um roteiro
rico, a composição gráfica e sonora de excelência tornam-se componentes fundamentais
para o incremento da imersividade e das chances de sucesso dos jogos didáticos.
1.4 Uma nova concepção dos jogos didáticos
Atualmente, os jogos educacionais ainda são uma área pouco explorada no mercado da
computação. O principal motivo disto é a dificuldade em se criar um jogo educacional
que seja interessante ao jovem. Até agora, a maioria dos jogos educacionais apenas
atraem aqueles que já tenham um interesse em determinada área e não o público em
geral. Por outro lado, os jogos de entretenimento que atraem o grande público não são
produzidos com o objetivo explícito de fazer o jogador aprender alguma coisa.
O principal problema que se aponta neste trabalho para os jogos educacionais
que se encontram nas prateleiras das lojas consiste no fato de que possuem desafios
fracos e pouco motivadores. Na maioria das vezes estes jogos foram projetados por
educadores e pedagogos, dando uma forte ênfase para aspectos didáticos, não enfocando
aspectos lúdicos. Desta forma estes jogos perdem sua espontaneidade, seu caráter
prazeroso e tornam-se semelhantes as tradicionais aulas com textos didáticos usando
quadro e giz.
 Assim sendo, é importante que os jogos educacionais sejam, antes de mais nada
jogos, ou seja, espontâneos, prazerosos e lúdicos [FOR 00]. O educador deverá, no
processo de design, pensar os momentos adequados para inserir a os aspectos
conteudistas, sem esquecer do prazer em jogar. Entretanto, a equipe de desenvolvimento
e as ferramentas empregadas para tal, devem ser as mesmas que desenvolvem games
comerciais, pois simplesmente pelo fato de um jogo ser utilizado dentro de um escopo
escolar não poderá ser desenvolvido com tecnologias ultrapassadas e inadequadas às
tendências dos jogos de entretenimento cujos jovens estão habituados em seu cotidiano.
A título de exemplo, alunos do curso de games da PUC-Rio estão
desenvolvendo um jogo em que o personagem assume o papel de um garoto que
encontrou, num laboratório de um professor, um relógio capaz de levá-lo a diversos
períodos da história. Neste jogo, Horácio viaja para a época do descobrimento do Brasil
(Figura 2) e se junta à expedição de Pedro Álvares Cabral. No navio, através de diversas
interações com personagens, apresenta-se ao jogador informações de caráter didático,
presentes no conteúdo escolar. Entretanto, ao longo de todo o jogo, os desafios são
iguais aos que se encontram em qualquer jogo de aventura. Desta forma, os aspectos
conteudistas são inseridos no jogo como um pano de fundo (background) e não são
destacados como os elementos principais da trama. A aventura, os desafios e a
resolução de enigmas é que tratam-se dos elementos-chave capazes de motivar os
jogadores a interagirem.

Figura 2 – Imagens do jogo educativo “O Guardião do Tempo” ©.

Outro jogo que pode ser destacado no conceito de jogos didáticos é a Série
Caça-Pistas©. Os jogos desta série abordam temáticas interdisciplinares - linguagem,
matemática, ciências, geografia e lógica inseridas em tramas de aventuras e mistério. O
jogador ao elaborar a estratégia para resolver algum mistério irá encontrar na trama uma
série de desafios relacionados com conteúdos escolares.
Considerando esta nova concepção, não poderia-se deixar de destacar o projeto
Games-to-Teach [GAM 03] desenvolvido no Departamento de Estudos de Mídia
Comparativa do Massachusetts Institute of Technology (MIT) com apoio da Microsoft
Research. O objetivo deste projeto é o desenvolvimento de protótipos conceituais para o
desenvolvimento de entretenimento educacional interativo, sendo que os primeiros
frameworks construídos estão voltados para o ensino da matemática, ciências e
engenharias. Estes jogos ainda não estão implementados, alguns são projetos e outros
são protótipos de desenvolvimento extremamente sofisticados.
 O Hephaestus, o Biohazard e o Revolution são exemplos de protótipos
desenvolvidos pelo projeto Game-To-Teach [GAM 03]. O Hephaestus é um MMORPG
que permite o projeto de robôs que serão controlados remotamente com o objetivo de
preparar um planeta vulcânico no estilo da Terra para ser habitado pelos humanos. Este
jogo está voltado para alunos do Ensino Médio ou para os primeiros anos de faculdade e
o objetivo educacional do jogo é ensinar mecânica através de uma abordagem
construtivista, através do desenvolvimento dos robôs. Já o Biohazard é um RPG
computadorizado com elementos dos jogos de aventuras cujo jogador interpreta um
jovem médico que deve tratar os pacientes e identificar origem de doenças epidêmicas,
tais como ebola e meningite. Por último, o Revolution é um MMORPG desenvolvido
para o ensino de História para alunos do Ensino Médio ambientado no período da
Guerra Civil Americana. Veja na Figura 3 algumas telas destes protótipos.

Hephaestus Revolution
Figura 3 - Algumas screenshots dos protótipos desenvolvidos pelo
projeto Games-To-Teach

O projeto Games-toTeach fundamenta-se em 11 princípios relacionados abaixo

[GAM 03] e servem de referencial para a elaboração desta nova concepção de jogos
educativos:
1. A mídia de massa, tais como rádio, televisão, livros e cinemas acabam
sendo chamarizes para os aspectos científicos, ou seja, muitos
indivíduos acabam tornando-se pesquisadores devido suas leituras de
ficção científica;
2. A mídia no processo de ensino-aprendizagem. Inspira-se nas séries
televisivas produzidas para apresentar o mundo científico para os
jovens. Ou seja, a mídia sempre preocupou-se na produção de
conteúdo didático de uma forma mais envolvente e motivadora para os
aprendizes;
3. A indústria de jogos computadorizados está madura e consolidando-se
como uma nova forma artística que envolve teatro, psicologia e
arquitetura;
4. Existe o problema dos jogos didáticos enfatizarem fortemente os
aspectos didáticos, sendo que tal modelo acaba reduzindo a motivação
para a aprendizagem. O desafio para os projetos de jogos com
objetivos didáticos é fundir conteúdo educacional com jogabilidade.
Engajando de forma significativa os aprendizes em temáticas, tal
como a matemática, de forma criativa;
 5. A necessidade de projetar jogos didáticos da nova geração que permita
os aprendizes resolverem problemas de forma crítica e criativa. Deve
ser dada a chance aos aprendizes de explorar mundos que contenham
materiais didáticos;
6. Aspecto motivacional. Os jogos computadorizados podem ser
considerados o estado da arte para o desenvolvimento de ambientes de
aprendizagem motivadores.
7. A possibilidade de manipular sistemas complexos. Jogos, tais como,
SimCity permite que o jogador gerencie um cidade tendo que analisar
inúmeras variáveis simultaneamente;
8. Os jogos computadorizados acabaram tornando-se mundos digitais
imersivos, potencializando a imersão através da experimentação
destes mundos. O conhecimento adquirido através destas explorações
poderá ser transferido para outras situações práticas do cotidiano,
devido ao desenvolvimento de habilidades cognitivas através de um
processo de aprendizagem significativa;
9. As comunidades virtuais oriundas dos mundos digitais potencializam
uma rede de intercomunicação entre os indivíduos e potencializam a
fantasia, através da interpretação de personagens que vivem nestes
mundos;
10. O processo de avaliação com jogos computadorizados pode tornar-se
adaptativo através do uso de agentes inteligentes capazes de
observarem o desempenho do jogador e elaborar desafios
personalizados para este;
11. A produção desta nova geração de jogos didáticos requer times
interdisciplinares, criativos e capazes de trabalharem
cooperativamente.
Nesta perspectiva, nacionalmente, destaca-se o Projeto REVOLUTION [BIT
03], cujo objetivo é desenvolver um motor de jogo denominado Druida para o
desenvolvimento de mundos virtuais baseado em RPGs (Role-Playing Games). O
importante é desenvolver tramas divertidas e estimulantes tendo como base cenários
históricos. Uma das possibilidades de exploração desta ferramenta, que encontra-se em
fase de planejamento, é o desenvolvimento de tramas relacionadas com a Revolução
Farroupilha e o folclore gaúcho. Os jogadores irão construir seus personagens típicos
desta época e vivenciar estórias tendo como background à revolução. É importante
destacar que o mais importante é a diversão, o brincar, sendo que os aspectos históricos
não serão didatizados e servirão simplesmente para elaboração do cenário.
Visando melhorar a qualidade dos jogos educativos Clua, Junior & Nabais [CLU
02] sugerem um roteiro que deve ser observado durante o desenvolvimento de jogos
didáticos:
1. Os desafios não devem estar relacionados com o assunto educativo;
2. Os aspectos educativos devem ser apresentados através do contexto, da
ambientação ou de conhecimentos prévios do usuário;
3. Ambientes imersivos e personagens bem elaborados. Lembrando que
imersão implica em envolver o jogador no ambiente [BAT 02]. Além disso,
a imersão não é só gráficos, é engajamento [JEN 02];
4. A ênfase no lúdico. As características pedagógicas devem se adaptar ao
roteiro;
 5. Roteiros ricos, bem elaborados e com alto grau de interação.
Portanto nesta nova concepção considera-se o desenvolvimento de jogos
didáticos da mesma forma que desenvolve-se jogos de entretenimento, desta forma
motivando aprendizes com jogos divertidos e prazerosos.
2. Etapas do processo de elaboração de um jogo
Tendo em vista a conveniência de se utilizar ferramentas padrões do desenvolvimento
de games comerciais para a produção de jogos com objetivos didáticos explícitos, será
apresentado a seguir como consiste este processo, bem como as principais ferramentas
utilizadas para tal fim na indústria já consagrada.
A seguir serão descritas as principais etapas no processo de desenvolvimento de
um jogo de entretenimento tradicional:
2.1 Design Bible
Assim como não faz sentido criar um filme sem antes ter um roteiro bem elaborado,
também é impossível desenvolver um jogo sem antes ter um documento com todas as
suas especificações.
Costuma chamar-se a este documento de Design Bible, que pode ser definido
como uma espécie de manual de instruções para os futuros desenvolvedores do jogo
[ROL 04]. O processo de desenvolvimento não pode começar sem que esta
especificação não esteja pronta. O Design Bible deve conter os seguintes elementos:

- Roteiro: Assemelham-se a roteiros de filmes. Este é um item fundamental para o

processo de criação e será o elemento crucial para demonstrar para os investidores
as potencialidades do produto. É neste item que o jogo deve mostrar seu diferencial
em relação a outros. Chamam-se aos roteiros de jogos de roteiros interativos, pois
diferentemente que os roteiros de filmes, devem ter espaço para interferência do
usuário no desencadeamento da história. Ao elaborar o roteiro deve-se ter em conta
qual o estilo do jogo que se está desenvolvendo, por exemplo, RPG, aventura, entre
outros.

- Game Design: Entende-se por game design a conceituação artística do jogo. Hoje
em dia, dada a complexidade das histórias e dos cenários elaborados, é importante
que esta parte do documento seja escrita por um artista. Dentro deste item deverão
ser expostos quais as principais características dos cenários, esboços de
personagens, descrição das texturas fundamentais, mapas e descrições das fases
(também denominado de level design). O livro [CRA 04] descreve detalhadamente
como é a elaboração deste tópico. Veja Figura 4.

- Game Play: Nesta parte do documento deve descrever-se como será a

jogabilidade. Por jogabilidade entendem-se as regras do jogo e o balanceamento das
regras (game balancing). Nesta descrição deve ficar claro que o jogo é divertido e
irá proporcionar desafios interessantes. Esta parte do documento é muito importante
para guiar os programadores para grande parte da programação, sobretudo na etapa
de scripting (programação).
 Figura 4 – Exemplo da conceituação artística de um personagem e de
um cenário. (extraído do jogo METALmorphosis ©)

- Interface: Pode-se dividir a interface em ingame e outgame. A primeira consiste na

instrumentação disponível durante o jogo e é responsável pela entrada de dados do
jogador para a aplicação. A interface outgame é a forma de apresentar a introdução
do jogo, sua configuração, instruções, etc. Costuma-se dizer que a melhor interface é
aquela que passa desapercebida para o jogador, permitindo que o mesmo possa
focar-se no desenrolar da história e das ações. Veja Figura 5.

Figura 5 – Exemplo do design de uma interface ingame (extraído do

jogo METALmorphosis ©).

Terminada a etapa de conceituação, o desenvolvimento de um game divide-se

em dois caminhos distintos: o de criação artística e o de programação, havendo
entretanto uma grande interseção entre ambas. A criação artística pode ser
compreendida na elaboração dos resources do jogo, ou seja, os elementos que serão
usados para sua montagem: modelos 3D, texturas, terrenos, sons, trilha sonora, entre
outros.
Ao término desta sub-seção é importante destacar que no caso do
desenvolvimento de um jogo didático a preocupação com aspectos de ensino-
aprendizagem e com a definição do conteúdo inicia-se no Design Bible. É fundamental
nesta etapa criar a equipe interdisciplinar formada por profissionais de informática,
pedagogos, artistas e educadores especialistas no domínio do jogo. O processo de
desenvolvimento deve seguir os mesmos passos descritos anteriormente, da mesma
forma que um jogo de entretenimento é criado.
2.1 Modelagem 3D
A equipe de modelagem 3D será responsável por criar os objetos geométricos das fases.
A geometria de um jogo pode ser dividida em dois tipos: modelagem estrutural e
modelagem de elementos dinâmicos. Esta diferenciação existe pelo fato de que os
modelos estruturais, por não sofrerem alteração de posição, sofrerão um pré-
processamento, de maneira a otimizar o processo de renderização, como será
apresentado na seção 3. A modelagem estrutural consistirá basicamente na criação do
cenário em si, o terreno e alguns outros elementos estáticos.
Para esta etapa os principais softwares utilizados são o Discreet 3DS MAX [DIS
04], MAYA [ALI 04], Avid Softimage [SOF 04] (veja Figura 6) e Ligthwave [NEW 04].
Outro modelador 3D que pode ser utilizado, apesar de sua complexidade de uso é o
Blender 3D [BLE 04]. Alguns recursos que estes programas oferecem, tornando-os
ótimos para este processo são:
- Ferramentas de modelagem baseadas em polígonos: Toda a modelagem deverá
ser feita por polígonos. Assim sendo, é importante que haja uma fácil e intuitiva
forma de manipulá-los.

- Ferramentas intuitivas para texturização: Grande parte da riqueza de uma

modelagem está na boa aplicação de texturas sobre os modelos. É comum, por
exemplo, ter que aplicar um mapeamento de texturas para polígonos individuais;

- Boas ferramentas para otimização de polígonos: É comum, durante o processo

de modelagem, criar objetos com mais polígonos do que se pode suportar no
jogo. Assim sendo, é importante que um pacote de modelagem forneça recursos
para reduzir o número de polígonos de objetos, minimizando a sua perda de
qualidade.

- Boa interface de visualização: Para o artista é importante que na medida que

um objeto seja construído, possa-se acompanhar, em tempo real, como o mesmo
será visto no jogo.
 Figura 6 – As interfaces “what you see is what you play” permite que o
artista possa ver em tempo real, na interface do software de
modelagem, como seus modelos ficarão na renderização final do jogo.
Imagens extraídas do Avid Softimage XSI ®.

Neste processo, uma virtude importante que os artistas devem ter é a de serem
capazes de modelar objetos com o menor número de polígonos possível (Figura 7).
Otimizando-se a modelagem, será possível que o cenário possa ser mais extenso e que
mais objetos possam ser inseridos no mesmo.

Figura 7 – Um mesmo modelo está representado em duas resoluções

diferentes de polígonos. Perceba-se que o resultado final é bastante
semelhante, embora o avião da direita possua 15 vezes mais polígonos
que o da esquerda.
2.2 Terrenos
Os terrenos também são conhecidos como heigh maps e consistem em imagens com
diversas tonalidades de cinzas. Os pixels escuros corresponderão a áreas baixas do
terreno e os claros a partes mais altas. Assim sendo, elaborar um terreno resume-se a
criar um mapa de altura adequado para o cenário. Este mapa de altura pode ser pintado
manualmente, usando algum software de edição de imagem. Entretanto, para relevos
mais complexos existem inúmeras ferramentas capazes de gerar mapas mais detalhados,
bem como editá-los de forma mais intuitiva. Além de gerar os mapas de altura, estes
softwares são capazes de gerar suas texturas correspondentes. Algumas das ferramentas
mais utilizadas são o Corel Bryce [COR 04], VueD’Espirit [EON 04], Terragen [TER
04] e Mojo Word Generator [PAN 04]. Veja Figura 8.

Corel Bryce Terragen

VueD’Espirit Mojo Word Generator

Figura 8 – Softwares utilizados para criar height maps e suas
correspondentes texturas.

Posteriormente, estes mapas de altura serão projetados sobre malhas regulares de

polígonos (Figura 9). Dependendo do engine, isto será feito na ferramenta de
modelagem 3D ou no editor específico do engine.

Figura 9 – Um mapa de altura é aplicado sobre uma malha de

polígonos regulares, formando um terreno 3D. Este processo pode ser
efetuado no engine ou no software de modelagem 3D.
2.3 Engines
É importante se destacar algumas definições e diferenciações entre as inúmeras
ferramentas existentes para o desenvolvimento de jogos computadorizados. Existem
muitas contradições e definições errôneas dos termos utilizados na literatura da área,
tais como biblioteca (library), toolkit, game engine e framework.
Uma biblioteca é um conjunto de rotinas gravadas em um arquivo onde cada
uma destas possui um nome e uma funcionalidade específica. Para o programador basta
referenciar tais funções, sem precisar que estas sejam reescritas todas as vezes que
forem necessárias. Estas bibliotecas podem comportar uma série de funcionalidades
específicas para um domínio, por exemplo, jogos computadorizados. Tais rotinas não
são orientadas a atividades, mas a funcionalidades. No caso de uma biblioteca para
jogos esta pode oferecer funcionalidades para manipulação de imagens, arquivos,
reprodução sonora, criação de imagens e/ou algoritmos de Inteligência Artificial. Como
exemplos de biblioteca é possível citar a OpenGL e a SDL.
Gamma, Helm, Johnson et al [GAM 95] definem os toolkits como um conjunto
de classes relacionadas e reutilizáveis, projetadas para fornecer uma funcionalidade útil
e de propósito geral, como por exemplo, um conjunto de classes para listas, pilhas e
filas. Para estes autores os toolkits são equivalentes em orientação a objetos às
bibliotecas de sub-rotinas. Destacando que os toolkits não impõem um projeto
específico à aplicação que está sendo desenvolvida. Ou seja, simplesmente provêm
recursos que poderão ser reutilizados em inúmeras aplicações. O DirectX pode ser
considerado um toolkit.
Quanto o engine, primeiramente é importante efetuar uma analogia. Considera-
se um motor de um carro. Este é responsável por fazer o automóvel movimentar-se. 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.
Dentro do conceito de Engenharia de Software, é a parte do projeto que executa certas
funcionalidades para um programa, por exemplo, um motor de busca na web semelhante
ao Google. Conforme FOLDOC [FOL 04], dicionário online de computação mantido
pelo Departamento de Computação do Imperial College London, um engine é um
componente de software capaz de executar um processamento que resulta em uma
determinada saída, precisando obrigatoriamente de um front end que irá fornecer as
informações de entrada e/ou exibir as informações de saída. No caso do Google, este
simplesmente recebe uma coleção de palavras chaves, efetua um algoritmo de busca e
apresenta para o usuário uma listagem de sites que contêm as palavras procuradas.
Neste caso o front end é o navegador Web que coleta as palavras e apresenta os
resultados. No servidor encontra-se um componente de software capaz de efetuar a
busca. Tal componente denomina-se motor (engine).
Dentro da área de jogos, um engine se encarregará por comunicar-se com o
hardware gráfico, irá mandar os modelos para serem renderizados, cuidará da entrada de
dados do jogador, tratará de todos os cálculos matemáticos e outras operações 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. Em todos os casos, estas
definições convergem em algumas características:
- Permitir que o desenvolvedor possa criar diversos jogos diferentes, usando um
mesmo engine. É comum, entretanto, que os engines sejam catalogados de
acordo com os tipos de jogos para os quais eles foram concebidos [EBE 00].
- Poder reaproveitar com facilidade o código desenvolvido em algum momento.
- 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.

Para Lewis & Jacobson [LEW 02], os engines referem-se a uma coleção de
módulos de simulação que não especifica diretamente o comportamento ou o ambiente
do jogo. Incluem módulos para capturar eventos de entrada, gerar saídas (renderizar
gráficos 3D, desenhar gráficos 2D e reproduzir sons) e a dinâmica dos mundos dos
jogos.
Para Domingues [DOM 03], os engines são fundamentais no desenvolvimento
de um jogo, pois são responsáveis pelo controle e processamento básico de todas as
mídias envolvidas. Além disso, abstrai a complexidade do desenvolvimento de jogos,
pois os desenvolvedores não precisam concentrar-se na codificação, somente na lógica e
nos aspectos multimídia. Para Madeira [MAD 01], um motor de jogo é “o seu sistema
de controle, o mecanismo que controla a reação do jogo em função das ações dos
usuários”. Devido sua arquitetura modular permite que diversos jogos sejam
desenvolvidos reaproveitando estes módulos.
Um engine pode ter sido projetado usando um conjunto de bibliotecas e/ou
toolkits, esta tecnologia oferece uma mecânica de execução completa. No caso dos
jogos torna-se difícil de personalizá-lo para suportar diferentes gêneros, em geral,
permitem construir um único tipo de jogo, devido sua alta especialização. Um exemplo
de engine é o motor do Quake da id Software. A partir deste motor é possível projetar
diferentes jogos de ação em primeira pessoa.
Desenvolver um engine é uma área complexa e repleta de desafios. Entretanto, o
objetivo deste documento não é ensinar a implementar um engine, mas sim entendê-los
e saber utilizá-los.
Normalmente, um engine é composto por diversas ferramentas, cada uma
responsável por alguma etapa do processo de criação de um jogo. Os componentes mais
comuns [ZER 04] de se encontrar em engines são os seguintes:
- Engine Core: Consiste no “coração do engine”. Este será um programa que
executará a aplicação do jogo, manipulará a fase e os objetos, renderizará as
cenas, entre outras operações. Fazendo-se uma analogia rudimentar, pode-se
dizer que o engine core é o sistema operacional do jogo.

- Engine SDK: É o código fonte do engine core. Através dele pode-se alterar o
funcionamento do engine. Normalmente este componente é o mais protegido e
para conseguí-lo, no caso de engines comerciais, será necessário comprar o
 pacote mais caro que a empresa oferece. É possível criar jogos sem o SDK de
um engine, entretanto, os tipos de aplicações possíveis de serem desenvolvidos
serão muito mais restritos.

- Level Editors: Através deste componente será possível unificar modelagens

feitas em diversos programas, associá-los à programação e inserir códigos em
scripts. Em muitos casos, dentro destes editores é possível também criar
modelos 3D. Veja Figura 10.

Figura 10 – Exemplo de level editors pertencentes a diversos engines

comerciais.

- Conversores / Exportadores: Os resources serão normalmente feitos em

diversos softwares comerciais, como se apresentou anteriormente. Mais ainda:
numa equipe de desenvolvimento grande cada artista poderá criar os elementos
no programa de sua preferência. Assim sendo, os engines deverão fornecer
instrumentos para importar estes modelos para o formato específico do engine.
Estes conversores poderão ser plugins instalados nos programas de modelagem
3D ou podem estar incluídos no level editor.

- Builders: Como será discutido mais adiante, de forma a otimizar o

processamento do jogo, serão feitos alguns pré-processamentos sobre os objetos
(tais como o BSP, lightmaps, portais, PVS). Desta maneira, um engine fornecerá
as ferramentas para realizar estes pré-processamentos. É comum que estejam
dentro do level editor.

- Linguagens Script: Grande parte do desenvolvimento da lógica do jogo e da

Inteligência Artificial de elementos dinâmicos será implementada sobre scripts e
não diretamente sobre o engine core. Assim, cada engine possuirá sua
linguagem de programação script, sendo comum usar linguagens comuns, tais
como JavaScript, Python e LUA.

Pode-se dizer que um engine é composto por diversos “sub-engines”, sendo cada
um responsável por tratar um tipo de problema envolvido em jogos. Os principais
componentes são:
2.3.1 Engine de renderização (ou engine 3D)
O engine 3D será responsável basicamente pelo pipeline gráfico, que é o processo de
gerar imagens 2D partindo de modelos 3D (Figura 11). Este processo é dividido em
diversas etapas [LAM 03], sendo as mais importantes:
- Transformações 3D: Nesta etapa aplica-se o movimento aos modelos 3D. Este
movimento consiste no seguinte: a cada passo do jogo uma matriz irá
acumulando o resultado de todos os movimentos que o objeto sofreu ao longo de
seu histórico. Antes de visualizar a cena, será aplicada esta matriz sobre cada
vértice que o compõem, posicionando-o no local que lhe corresponde naquele
instante;

- Projeção 3D ◊ 2D: Os vértices que compõem o objeto são coordenadas 3D,

porém a imagem do modelo deverá ser desenhada numa superfície
bidimensional (tela do computador). Nesta etapa, os vértices do modelo serão
projetados sobre o plano de projeção da câmera. É comum encontrar esta etapa
do pipeline junto com a etapa de transformações 3D, pois em última instância
realizar esta projeção consiste numa aplicação de matriz de transformação
também.

Figura 11 – Etapas mais importantes do pipeline gráfico.

- Culling: Existem inúmeras formas de otimizar o processamento gráfico de um

jogo. Uma destas consiste nos métodos de culling (Cull em inglês significa
"refugo, escolher, selecionar de dentro de um grupo"). Assim, o que as técnicas
de culling terão de fazer é saber escolher polígonos adequadamente, de forma
que numa determinada situação, estejam presentes apenas aqueles que realmente
importam para a visualização a partir do ponto em que a câmera se encontra.
Pode-se pensar também da seguinte forma: quais dos polígonos de uma cena
deverão ser enviados para o pipeline da placa gráfica? Obviamente não se deseja
enviar algum que não terá nenhuma influência na visualização, mas até que
ponto é simples realizar esta escolha, de forma rápida. Existem muitos
algoritmos que farão este tipo de escolha. Em muitos casos a eficiência deste
procedimento estará atrelada ao tipo de agrupamento e ordem de polígonos (um
terreno possui uma distribuição de polígonos completamente diferente de que
um personagem ou do que um labirinto). O culling pode ser feito em qualquer
estágio do pipeline gráfico. Entretanto, pode-se pensar que quanto antes se
conseguir livrar dos polígonos que não interessam, melhor, pois coloquialmente
pode-se dizer que "ninguém gosta de andar com um elefante branco nas costas
de graça". Vale a pena ressaltar que um método de culling não anula outro:
podem-se ter os efeitos somados em muitos casos.
 - Clipping: Ao projetar polígonos sobre o plano de projeção da câmera, alguns
polígonos cairão totalmente dentro da área da tela e outros cairão parcialmente
dentro, ou seja, apenas uma parte do polígono estará na tela de projeção. Para
estes polígonos é necessário realizar o clipping (recorte), que consiste em criar
novas arestas e vértices.

- Rasterização (iluminação e texturização): Finalmente, a última etapa do

processo de renderização consiste em preencher os polígonos adequadamente,
aplicando o material com o qual estão definidos. Inicialmente poderia-se pensar
em fazer este processo através de um cálculo de iluminação para cada um dos
pixels (per pixel) do interior de um polígono. Entretanto isto seria
demasiadamente caro em termos computacionais. Para viabilizar este processo
realiza-se uma interpolação (rasterização) entre a cor de cada um dos vértices
que compõem o polígono. Desta forma, o cálculo de iluminação é feito apenas
para cada vértice (per vertex) visível da malha. Esta rasterização também
poderia demandar bastante tempo de processamento, pois apesar de ser algo
simples de ser feito, existem pixels numa tela. Entretanto, este processo é
realizado por um hardware específico para esta tarefa, que é a placa gráfica, ou
GPU – Graphic Processor Unit.

Existe uma série de efeitos de iluminação (blur, bump-mapping, especularidade)

que não podem ser aplicados realizando-se uma rasterização como foi explicada
anteriormente. Isto porque para estes efeitos é necessário realizar um cálculo de
iluminação per pixel e não per vertex. Para solucionar este tipo de problema, as placas
gráficas mais modernas possuem a capacidade de suportar pixel shaders (Figura 12),
que são pequenos programas que são executados para cada pixel que será plotado na
tela. Para maiores informações sobre esta tecnologia, ver [STL 04].

Figura 12 – Imagens geradas em tempo real utilizando pixel shaders.

Apesar de ser enfatizado a engine 3D, pois atualmente a grande maioria dos
jogos de entretenimento utilizam esta tecnologia e o maior interesse dos jovens é por
este tipo de jogo é importante destacar que podem ser desenvolvidos jogos com gráficos
bidimensionais (2D). A escolha por um determinado modo de visualização (3D/2D)
dependerá do estilo de jogo que está sendo desenvolvido e a plataforma de execução.
Um jogo de ação como o Counter Strike não poderia utilizar um visualizador 2D pelo
fato de sua jogabilidade. Entretanto muitos jogos criados para telefones celulares, que
comumente possuem poucos recursos de hardware, estão adotando a tecnologia 2D.
Por tratar-se de jogos desenvolvidos para o âmbito escolar deve-se considerar
que muitas escolas, principalmente as instituições públicas, possuem máquinas com
configurações antigas e executando GNU/Linux. Logo, jogos 3D que utilizam
tecnologias muito avançadas poderão não executar sob estes hardwares antigos.
Certamente que tais limitações é que tornam mais desafiador a criação de jogos
computadorizados capazes de executarem sob este contexto, de forma atrativa e usando
tecnologias semelhantes as usadas em jogos de entretenimento.
2.3.2 Engine de Física
Grande parte da interatividade de um jogo se deve ao funcionamento das leis da física
(ou ao menos a uma parte delas...) sobre o mundo virtual criado. Assim, ao andar sobre
um labirinto e bater numa parede o jogador não pode atravessá-la; ao dar um pulo, o
jogador deve colidir com o chão e não continuar caindo para sempre; ao acelerar um
carro, sua velocidade deverá ir crescendo gradualmente e não abruptamente.
Os cálculos de física básicos num jogo são:
- Colisão: Objetos 3D devem colidir com outros. Esta colisão não é tão trivial de ser
realizada para um mundo virtual como o é para o mundo real, já que em última
instância corresponderia em verificar se cada um dos polígonos de um determinado
objeto possui interseção com cada um dos polígonos do restante da cena. Existem
inúmeras formas de otimizar estes cálculos (ver [EBE 03]), sendo a mais comum a
técnica de bounding-boxes, que consiste em englobar cada objeto por uma caixa e
calcular a colisão para a caixa e não para a malha completa do objeto.

- Resultante de forças: Os objetos se movimentam num mundo real devido a

aplicação de diversas forças sobre o mesmo. Num ambiente virtual será necessário
simular a aplicação de forças de diversas naturezas sobre os objetos, calculando a
resultante a cada instante para verificar como será o seu movimento. Para mais
detalhes, ver [BER 03].

2.3.3 Engine de Som

Este componente do engine permitirá o controle sobre os arquivos de som da biblioteca
de recursos do jogo. Normalmente utilizará alguma API adequada para manipular este
tipo de arquivos, tal como o DirectSound ou o OpenAL. Além de permitir abrir e tocar
estes arquivos, os engines de som permitirão um controle de som posicional, permitindo
que objetos da cena emitam sons e estes se comportem conforme o posicionamento do
objeto na cena.
2.3.4 Engine de Inteligência Artificial
Entende-se por Inteligência Artificial para jogos, os programas que descreverão o
comportamento de entidades não controladas pelo jogador, tipicamente os NPC (Non-
Player Characters).
Tipicamente o comportamento inteligente destas entidades é desenvolvido
através de máquinas de estados. Os algoritmos de máquinas de estados procuram
resolver problemas formalizando diversos possíveis estados em que um elemento pode
se encontrar (no caso de uma televisão, por exemplo, poderia-se ter estes estados:
Desligada, Acesa e Stand-by). A transição de um estado para outro estará atrelado a
algum evento que dispare esta mudança (no exemplo anterior, ao apertar a tecla <on> a
TV muda do estado de desligada para Stand-by).
 Desta maneira, a inteligência de um personagem de um jogo pode ser descrita
por diversos estados em que o mesmo pode se encontrar (no caso de um jogo de ação,
poderíamos descrever estes estados como espera, perseguição, ataque, fuga, morte, por
exemplo). Este personagem deverá fazer um monitoramento constante sobre
acontecimentos que possam disparar a mudança de um estado para outro. Usando o
exemplo de um jogo de ação, suponha-se que o fato do jogador aproximar-se mais do
que 30m do NPC faça com que o mesmo passe do estado de espera para o estado de
perseguição. Veja Figura 13.

Figura 13 – Exemplo de uma máquina de estados típica para um jogo

de ação.
Conforme foi apresentado no início deste trabalho, os jovens preferem jogos
computadorizados que ofereçam grandes desafios. Um roteiro bem elaborado e uma
excelente modelagem 3D serão sacrificados caso não sejam desenvolvidos NPCs com
comportamentos sofisticados. Uma das principais causas de desinteresse por um jogo é
o fato dos oponentes se comportarem de forma incoerente e/ou muito simplificada
eliminando o desafio do jogo.
Apesar da grande maioria dos jogos utilizar scripts e máquinas de estados para
configurar o comportamento inteligente dos NPCs, outras técnicas de Inteligência
Artificial podem ser utilizadas, tais como Redes Neurais Artificiais, Redes Bayesianas,
Algoritmos Genéticos e Lógica Difusa. Adotar técnicas de Aprendizado de Máquinas
podem ser efetivamente consumidoras de maior poder de processamento do dispositivo,
entretanto podem ser utilizadas para modelar comportamento adaptativo das entidades
computacionais.
Um SDK bastante conhecido trata-se do DirectIA (Direct Intelligent Adaptation)
[DIR 04], que oferece um conjunto de ferramentas para projetar e implementar as
necessidades de inteligência artificial para qualquer aplicação, inclusive jogos. Usando
o DirectIA é possível criar agentes inteligentes com a capacidade de adaptação. É
possível utilizar um sistema de regras de predição, máquinas de estado e máquinas
difusas para efetuar o processo de inferência destes agentes. Outro SDK de Inteligência
Artificial trata-se do Renderware A.I [REN 04] que oferece uma série de
comportamentos pré-estabelecidos que podem ser usados na definição de scripts usando
uma linguagem like C ou LUA.
2.4 Engines – Qual usar?
Existe uma grande quantidade de engines. Em [DEV 04] há uma excelente lista de
referências sobre os principais e mais completos. Como escolher o engine adequado
para desenvolver um jogo? Existem diversos fatores que se devem ser considerados:
- Orçamento disponível: Existem engines que custam U$ 100,00 e outros que
ultrapassam U$ 1 milhão. Os mais dispendiosos, além de possuírem todo tipo de
recurso que um engine é capaz de ter, normalmente são programas que possuem
uma excelente equipe de apoio, que irá acompanhar a empresa desenvolvedora do
início ao fim da sua produção. Este acompanhamento consistirá em desenvolver
plugins específicos, adaptar funcionalidades do engine para as necessidades
específicas e até dar treinamento para os programadores.
- Tipo de jogo a ser desenvolvido: Apesar de existirem engines que são capazes de
construir tipos bastante diferentes de jogos, a maioria terá uma série de
características que favorecem para o desenvolvimento de um tipo específico de jogo,
por exemplo, engine para criação de RPGs, jogos de ação, corrida, entre outros.

- Milestones: O tempo que se possui para produzir um jogo influencia muito na

escolha do engine. Alguns engines permitem que um jogo seja feito em poucos dias,
mas implicará numa série de soluções padrões, que o tornam semelhante a muitos
outros jogos produzidos com aquele mesmo engine.

- Plataforma: Um jogo pode ser desenvolvido para diversas plataformas, tais como
Windows, GNU/Linux, XBOX, GameCube, Playstation, MacOS, PalmOS, WinCE,
PalmOS, SymbianOS entre outros. É fundamental que o engine escolhido suporte a
plataforma para a qual se está desenvolvendo. Os engines mais caros normalmente
são capazes de produzir jogos para diversas plataformas.

- Documentação oferecida: O desenvolvedor de jogos deverá, antes de adotar um

engine, verificar como é a documentação do mesmo. Sem uma documentação
eficiente, dificilmente o programador será capaz de utilizar adequadamente os
recursos oferecidos pelo engine.

- Ferramentas disponíveis: Cada engine possuirá conversores e exportadores, que

permitirão que sejam utilizados outros programas para programar seu SDK ou para
modelar os objetos 3D. É fundamental que o desenvolvedor analise quais as
ferramentas com as quais se pode produzir os para o engine em questão (se a equipe
de modeladores conhece apenas o MAYA, é conveniente que o engine a ser adotado
suporte o MAYA para os modelos 3D).

2.5 Amphibian - Jogos Multiplataformas Livres

O Amphibian [BIT 04] trata-se de um framework distribuído livremente sob a licença
GNU GPL que permite o desenvolvimento de engines multiplataformas. A linguagem
de programação escolhida para seu desenvolvimento é Java. Entretanto as APIs desta
linguagem possuem algumas diferenciações tornando alguns códigos não totalmente
portáveis. O Amphibian não trata-se de um engine, mas de um framework que descreve
uma infra-estrutura genérica e abstrata, comum em diferentes motores. Desta forma
necessitou-se projetar uma camada de abstração que tornasse o Amphibian
independente de qualquer máquina virtual Java. A arquitetura de camadas do
Amphibian pode ser vista na Figura 14.

AMP H I B I AN
E x t en s ões

S AL
JVM

S i s t em a Oper aci on al

Figura 14: Arquitetura de Execução Completa do Amphibian.

Esta arquitetura possui uma camada referente ao sistema operacional. Sob esta,
executa-se uma JVM que fornece uma abstração referente à plataforma de execução.
Sob esta camada está a SAL – System Abstraction Layer. Consiste exatamente da
camada de abstração referente às máquinas virtuais. Considerou-se esta camada externa
ao Amphibian pelo fato de fornecer componentes básicos comuns para diferentes
aplicações até mesmo externas ao contexto dos jogos computadorizados. Ou seja,
diferentes aplicações podem utilizar esta camada, desta forma tornando-se
independentes de máquinas virtuais. As extensões da SAL podem utilizar uma máquina
virtual específica ou utilizar métodos nativos e executarem diretamente sob um sistema
operacional, desta forma perdendo a portabilidade, mas sem comprometer a
compatibilidade com as camadas superiores
A última camada trata-se das extensões criadas basicamente a partir das
abstrações de cada uma das camadas básicas e especifica a relação destas extensões com
as camadas da arquitetura de execução. Fayad, Schimidt & Johnson [FAY 99] afirmam
que os frameworks são projetos de software com pontos de personalização (hot spots).
Quando uma aplicação é criada a partir de um framework adota-se um fluxo de controle
padrão e as especificidades da aplicação serão atendidas através da construção de
extensões para serem utilizadas nestes pontos de personalização. Portanto, existem
extensões criadas a partir dos hot spots do Amphibian e da SAL. Tais extensões podem
usar componentes oferecidos pela camada JVM e pelo sistema operacional, entretanto à
medida que uma extensão utiliza um componente das camadas mais inferiores perde-se
sua portabilidade. Ou seja, se for criada uma extensão para o Amphibian usando
somente tal camada, esta extensão será reutilizável para qualquer SAL, JVM e sistema
operacional. Entretanto se tal extensão utilizar um componente do sistema operacional o
uso desta ficará restrito a esta plataforma. Mesmo considerando a possibilidade de
perder portabilidade adotar tal arquitetura permite que a estrutura do framework em
geral seja mais flexível, desta forma melhor atendendo os requisitos do projeto de um
jogo. Assim é possível utilizar bibliotecas externas e/ou dependentes de sistema
operacional inclusive tecnologias bastante difundidas no desenvolvimento de jogos, tais
como OpenGL, SDL e DirectX. Em resumo o desenvolvedor de um motor de jogo pode
optar pelo nível de portabilidade de suas extensões.
Destaca-se que o Amphibian foi desenvolvido para permitir o avanço técnico-
científico, principalmente no cenário brasileiro, do desenvolvimento de jogos
computadorizados, seja no âmbito acadêmico ou no âmbito comercial beneficiando
principalmente a indústria na produção de jogos para computadores pessoais e
dispositivos móveis. Espera-se construir motores de jogos para serem utilizados na área
de Informática na Educação. Acredita-se que pelo fato de desenvolver um framework
para construir motores de jogos multiplataforma e que seja livremente distribuído, os
jogos computadorizados passem a ser mais utilizados nas escolas, principalmente nas
instituições públicas que utilizam outros sistemas operacionais diferentes da plataforma
Microsoft Windows.
Os principais requisitos que o Amphibian pretende atender estão listados abaixo:
- Um motor de jogo em geral, deve ser executável na plataforma de
computadores pessoais (Windows, Linux e MacOS), móveis
(PalmOS e Windows CE), celulares (Symbian OS) e motores
integrados com tecnologia Web (servlets e applets);
- Além destas plataformas e sistemas citados anteriormente o
Amphibian deve ser extensível, ou seja, ser adaptável para uma nova
plataforma que não esteja prevista no item anterior;
- Independente do dispositivo de visualização, ou seja, uma aplicação
pode ser visualizada com gráficos bidimensionais (vista superior ou
isométrica) ou gráficos tridimensionais em qualquer dispositivo, seja
este um monitor ou um display de um handheld ou telefone celular;
- Independente do mecanismo de persistência. Neste contexto a
persistência trata da configuração do motor de jogo, da descrição do
jogo e dos objetos que são utilizados. Portanto as questões referentes
a salvar e recuperar uma sessão de jogo estão incluídas neste tópico;
- A persistência dos dados pode ocorrer no módulo cliente ou em
servidor remoto. Independente do local de armazenamento, a forma
de persistência dos objetos deve ser flexível. Isto implica em persistir
os dados usando um gerenciador de banco de dados, XML, arquivos
de textos, formatos proprietários, PDB (Palm Database) ou um outro
formato de armazenamento qualquer;
- Oferecer alta modularidade. Deve permitir trocar os componentes do
motor afetando o mínimo possível outros componentes,
principalmente os que se referem aos componentes da lógica da
aplicação;
- Distribuído sob os termos da licença LGPL;
- Uma solução com baixo custo (valor monetário) para ser ofertada
para comunidade.
 O processo de criação de um jogo computadorizado utilizando o Amphibian
pode ser descrito em seis passos principais:
1. Criação de um domínio de jogo. Consiste na implementação das classes
referente a lógica do jogo. Por exemplo, se estivéssemos desenvolvendo um
jogo de xadrez, as classes de domínio tratariam das regras e dos
componentes (peças) deste jogo. Para criação destas classes são utilizados
somente os pacotes do Amphibian e da SAL para garantir a portabilidade;
2. Desenvolvimento de classes de adaptação para o Amphibian. Possivelmente
algumas classes de ligação precisam ser desenvolvidas, por exemplo,
tratamento de eventos produzidos pelo teclado ou pelo mouse. Quando estes
eventos ocorrem, estes deverão ser capturados pelo Amphibian e
posteriormente irão interelacionar-se com objetos referentes ao domínio de
jogo;
3. Opcionalmente poderão ser criados alguns componentes específicos, por
exemplo, uma nova forma de visualização. Tais customizações tratam-se de
plugins;
4. Configurações da especificação do motor para cada plataforma utilizando o
como padrão o formato XML. Cada componente do engine que será usado é
definido em um arquivo XML. No momento de inicialização do jogo, tais
componentes são criados e configura-se o motor para executar determinado
jogo. Percebe-se que o engine no Amphibian não é estático, ou seja, com
componentes definidos em tempo de compilação. O engine criado com o
Amphibian utiliza-se de dynamic binding para criar seus componentes em
tempo de execução desta forma aumentando a flexibilidade do framework;
5. Definição dos descritivos dos jogos que poderão ser criados para executarem
sob este novo motor. Cada jogo que será interpretado pelo motor também é
definido usando um arquivo XML;
6. Criação dos recursos audiovisuais. Cada título para cada plataforma requer a
criação das imagens, sprites, sons, scripts, entre outros recursos que serão
utilizados no jogo.
Os quatro primeiros passos permitem desenvolver um motor de jogo. Diversos
títulos de jogos podem ser desenvolvidos para este motor repetindo os dois últimos
passos da seqüência, ou seja, definindo diferentes descritivos e recursos audiovisuais.
Nas Figuras 15 e 16 são apresentadas algumas telas dos testes iniciais que foram
efetuados usando o Amphibian. Tais aplicações não são extremamente arrojadas.
Entretanto estas não ilustram a sofisticação dos jogos computadorizados que foram
desenvolvidos, mas sim as potencialidades da arquitetura do framework que dado um
conjunto de componentes com alta abstração e um mesmo arquivo de especificação
XML é possível configurar um jogo para executar em diferentes dispositivos.
 Figura 15: Screenshots do Quadrados Coloridos em Multiplataformas
(Tela Janela).

Figura 16: Screenshots do Snake Executando em Multiplataformas.

Um dos pontos que precisa ser destacado no Amphibian, que muitas vezes é
incompreendido pela comunidade, é a facilidade de reusar componentes de software em
diferentes dispositivos com diferentes sistemas operacionais simplesmente definindo um
arquivo formatado no padrão XML. Pelo fato do Amphibian ser um projeto novo,
nenhum jogo arrojado ainda foi desenvolvido. O que pretende ser destacado neste
trabalho que o Amphibian trata-se de uma tecnologia livre e gratuita que permite a
customização de diferentes motores de jogos executáveis em diferentes plataformas.
Certamente tal característica torna-se significativa quando considera-se o âmbito
escolar, que conforme foi dito anteriormente possui algumas limitações quanto à infra-
estrutura tecnológica. E se considerarmos o contexto de muitas instituições de ensino
brasileiras, estas possuem como sistema operacional padrão de seus laboratórios o
sistema operacional GNU/Linux, como é o caso do estado do Rio Grande do Sul. Desta
forma os jogos computadorizados devem ser compatíveis com diferentes plataformas.
Apesar dos visualizadores 3D não estarem implementados, tal funcionalidade
poderá ser implementada para o Amphibian, pois o framework generaliza os elementos
de visualização permitindo a personalização. Esta extensão poderá ser feita através da
criação de um plugin acessando, por exemplo, a biblioteca OpenGL e associando-se este
plugin ao engine no momento de sua configuração (definindo isto no arquivo XML).
Além das plataformas citadas anteriormente, atualmente o Amphibian está sendo
portado para o J2ME adotando o MIDP 2.0 por Ricardo de Moura Fonseca no Centro
Federal de Educação Tecnológica do Paraná (CEFET), na cidade de Ponta Grossa. Este
trabalho encontra-se em fase de finalização. A Figura 17 ilustra os primeiros resultados
obtidos.

Figura 17: Screenshot dos Quadrados Coloridos executando sob

J2ME/MIDP 2.0

Além disso, está sendo implementado um plugin para o Amphibian que permite
o uso da linguagem LUA para definição de eventos, facilitando o uso do framework por
programadores inexperientes ou que desconheçam a linguagem Java.

3. O Futuro Próximo
Cada vez mais os jogos tem ganhado a característica de serem on-line, ou seja, de
permitir que vários usuários participem de um mesmo jogo, simultaneamente. Nestes
tipos de jogos constroem-se o que se denomina de mundos persistentes. Entende-se por
mundos persistentes mundos virtuais em que há uma certa independência de um jogador
específico para que as coisas aconteçam. Além disso, possuem a característica de
evoluírem durante o transcorrer do tempo. É comum que, utilizando a tecnologia de
jogos massivos – nome dado aos jogos que permitem milhares de jogadores ao mesmo
tempo - se desenvolvam jogos no estilo de RPG (Star Wars Galaxy, Lineage II,
Prinston Tale, Erinia, Conqueronline, Planshift, entre outros).
Este estilo de jogos tem grande capacidade de transmitir conteúdo para os seus
jogadores. Neste caso, pode ser transmitido um conhecimento a partir de pessoas reais,
que tomam parte do jogo através de avatares. Através de interações, os avatares podem
transmitir informações de interesse educacional. Abordando estes
Muitos pesquisadores pensam que este tipo de jogo pode funcionar como um
instrumento de educação à distância. De fato, algumas escolas americanas estão
implantando diversos jogos com esta finalidade, ainda em cunho experimental. É o caso
da pesquisa desenvolvida por Goodson-Espy, Espy & Cifarelli [GOO 02] que consistiu
do uso de um 3D MMORPG na Internet usado para ensinar matemática para alunos da
escola média. Os testes feitos pela pesquisadora indicaram que os alunos tiverem grande
facilidade para desenvolver os testes de avaliação pelo fato de terem interagindo com
conceitos matemáticos no mundo virtual.
Além destas tecnologias é importante destacar a computação móvel e a TV
digital como tecnologias emergentes que certamente irão apoiar o processo de
teleducação. É o conceito de umbiqüidade computacional, ou seja, a informação em
todos os lugares independente de dispositivos. O m-learning já é uma modalidade de
ambientes virtuais de aprendizagem móvel baseados em telefonia celular e handhelds.
Certamente que os jogos computadorizados também possui seu espaço neste contexto,
podendo perfeitamente serem desenvolvidos jogos com fins didáticos e lúdicos para
executarem sob estas plataformas facilitando a mobilidade e a integração destes
dispositivos em salas de aulas.
A TV digital também pode ser considerada neste contexto como uma nova
tecnologia que poderá potencializar o processo de inclusão digital. E com uso desta
tecnologia cresce as potencialidades de utilização de jogos computadorizados
executando diretamente sob um aparelho TV permitindo aos jogadores a mesma
interação oferecida pelos computadores pessoais.
Ao término do presente trabalho destaca-se a importância da difusão dos jogos
computadorizados como ferramentas tecnológicas educativas independente dos seus
objetivos didáticos explícitos. Certamente os nossos jovens deverão ser preparados para
uma realidade bastante diferenciada do século passado, cuja informação, o
conhecimento é mais étereo e está mais presente em seu cotidiano. Perceebe-se a
necessidade de formar sujeitos criativos, autônomos e capazes de resolver problemas,
características fundamentais para era pós-industrial. Assim não pode-se enfocar o
processo de desenvolvimento de jogos com fins didáticos da mesma forma que estes
eram projetados no final do século passado. O contexto cultural é diferenciado logo
necessita-se de ferramentas adaptadas a esta nova contextualização. Acredita-se que no
presente trabalho não esgotou-se todas as possibilidades de discussões sobre esta
temática, mas no mínimo sirva como um referencial inicial para o desenvolvimento de
novos jogos computadorizados, de uma nova geração, para serem usados no âmbito
escolar.
Referências Bibliográficas
[ALI 04] Alias. Disponível em <http://www.aliaswavefront.com>. Acesso em 10 out.
2004.
[AMO 01] Amory, Alan. Building an Educational Adventure Game: Theory, Design
and Lessons In: Journal of Interactive Learning Research. 2001, v.12 num. 23. pp.
249-263.
[AND 03] Andrade, Leila; Zavaleta, Jorge; Vaz, Francine; et al. Jogos Inteligentes são
Educacionais? In: XIV Simpósio Brasileiro de Informática na Educação. Rio de
Janeiro: SBC, 2003, pp. 699-707.
[BAT 00] Battaiola, André 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ática. Curitiba:SBC, Julho/2000, v. 2. pp. 83-122.
[BAT 01] Bates, Bob. Game Design – The Art & Business of Creating Games.
Roseville: Prima Tech, 2001, 300 p.
[BAT 02] Battaiola, André L.; Elias, Nassim C.; Domingues, Rodrigo 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. São
Leopoldo: SBC, 2002, pp. 282-290.
[BER 03] Bergen, Gino Van Den. Collision Detection in Interactive 3D Environments
(Morgan Kaufmann Series in Interactive 3D Technology). Morgan Kaufmann.
October 2003.
[BIT 03] Bittencourt, João R.; Giraffa, Lucia M. Modelando Ambientes de
Aprendizagem Virtuais utilizando Role-Playing Games In: XIV Simpósio Brasileiro
de Informática na Educação. Rio de Janeiro: SBC, 2003. pp. 718-727.
[BIT 04] Bittencourt, João R. Um Framework para Criação de Jogos Computadorizados
Multiplataforma. Porto Alegre: PPGCC/PUCRS, 2004, 199 p. (Dissertação de
Mestrado)
[BLE 04] Blender. Disponível em: <http;//www.blender.bl> Acesso em 10 out. 2004
[CLU 02] Clua, Esteban W. G.; Junior, Carlo L. de L.; Nabais, Rodrigo J. de M.
Importância e Impacto dos Jogos Educativos na Sociedade. In: I Workshop
Brasileiro de Jogos e Entretenimento Digital. Proceedings. SBC: Fortaleza, 2002,
[Meio digital].
[COB 88] Coburn, Peter; Kelman, Peter; Roberts, Nancy et al. Informática na educação.
Rio de Janeiro; LTC, 1988. 298 p.
[COR 04] Corel Bryce. Disponível em: <http;//www.corel.com/bryce> Acesso em: 10
out. 2004.
[CRA 04] Crawford, Chris. Chris Crawford on Game Design. New Riders Publishers,
2004.
[DEV 04] DevMasters. Disponível em; <http://www.devmasters.net/engine> Acesso
em: 10 out. 2004.
[DIR 04] DirectIA. Disponível em <http://www.directia.com> Acesso em: 10 out. 2004.
[DIS 04] Discreet. Disponível em: <http://www.discreet.com/products/> Acesso em: 25
jan. 2004.
[DOM 03] Domingues, Rodrigo G. Projeto de um framework para auxilio no
desenvolvimento de aplicações com gráficos 3D e animação. São Carlos, UFSCAR,
2003, 196 p. (Dissertação de Mestrado)
[EBE 00] Eberly David H., 3D Game Engine Design : A Practical Approach to Real-
Time Computer Graphics. Morgan Kaufmann, September, 2000.
[EBE 03] Eberly David H. Game Physics (Interactive 3d Technology Series). Morgan
Kaufmann; Bk&CD-Rom edition. December, 2003.
[EON 04] E-On Software. Disponível em: <http://www.e-onsoftware.com> Acesso em:
10 out. 2004.
[FAY 99] Fayad, Mohamed E.; Schmidt, Douglas C.; Johnson, Ralph E. Building
Application Frameworks: Object-oriented Foundations of Framework Design. New
York: John Wiley & Sons, 1999, 664 p.
[FOL 04] FOLDOC - Free On-line Dictionary of Computing. Disponível em:
<http://wombat.doc.ic.ac.uk/foldoc/index.html>. Acesso em: 11 out. 2004.
[FOR 00] Fortuna, Tânia R. Sala de aula é lugar de brincar? In: Xavier, Maria L.F.;
DALLA ZEN, Maria I.H. (Org). Planejamento: Análises menos convencionais.
Porto Alegre: Mediação, 2000, 147-164p.
[GAM 03] Games to Teach Project. Desenvolvido pelo MIT. Disponível em:
<http://cms.mit.edu/games/education/> Acesso em: 28 dez. 2003.
[GAM 95] Gamma, Erich; Helm, Richar; Johnson, Ralph; et al. Design Patterns:
Elements of Reusable Object-oriented Software. Boston: Addison-Wesley, 1995,
395 p.
[GOO 02] Goodson-Espy, Tracy.; Espy, Samuel.; Cifarelli, Victor Warrick’s Secrets:
Teaching Middle School Mathematics through an Internet based 3D Massively
Multiplayer Role Playing Game In: Society for Information Technology and
Teacher Education International Conference. 2002, num. 1, 1080-1084p.
[GRE 88] Greenfield, Patrícia M. O Desenvolvimento do Raciocínio na Era da
Eletrônica – Os Efeitos da TV, Computadores e Videogames. São Paulo: Summu,
1988. 162 p.
[JEN 02] Jenson, Jennifer; Castel, Suzanne. 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> Acesso
em: 04 set. 2004.
[KAF 01] Kafai, Yasmin 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. Chicago: Cultural Policy Center -
University of Chicago, 2001. Disponível em:
<http://culturalpolicy.uchicago.edu/conf2001/papers/kafai.html>. Acesso em: 04 set.
2004.
[KAF 95] Kafai, Yasmin B. Minds in Play – Computer Game Design as a Context for
Children’s Learning. Hillsdale: Lawrence Erlbaum, 1995, 339 p.
[LAM 03] LaMothe, André. Tricks of the 3D Game Programming Gurus-Advanced 3D
Graphics and Rasterization, Pearson Education, June 2003.
[LEW 02] Lewis, Michael; Jacobson, Jeffrey. Game Engines in Scientific Research In:
Communication of the ACM. Jan. 2002, vol. 45, n. 1, 27-31p.
[MAD 01] Madeira, André G. Forge V8: Um Framework para o Desenvolvimento de
Jogos de Computador e Aplicações Multimídia. Recife, UFPE, 2001, 99 p.
(Dissertação de Mestrado)
[NEW 04] Newtek. Disponível em: <http;//www.newtek.com> Acesso em: 10 out.
2004.
[PAN 04] Pandromeda. Disponível em: <http://www.pandromeda.com> Acesso em: 10
out. 2004.
[REN 04] Renderware A.I. Disponível em: < http://www.renderware.com/ai.asp>
Acesso em: 10 out. 2004.
[ROL 04] Rollings, Andrew and Morris, Dave. Game Architecture and Design: A New
Edition. New Riders Publishers, 2004.
[ROL 04] Rollings, Andrew and Morris, Dave. Game Architecture and Design: A New
Edition. New Riders Publishers, 2004.
[SOF 04] Softimage. Disponível em: <http://www.softimage.com/xsi> Acesso em 10
out. 2004.
[STL 04] St-Laurent, Sebastien. Shaders for Game Programmers and Artists. Muska &
Lipman/Premier-Trade; 1st edition.May, 2004.
[TER 04] Terragen. Disponível em: <http://www.planetside.co.uk/terragen/> Acesso
em: 10 out. 2004.
[ZER 04] Zerbst, Stefan and Düvel, Oliver. 3D Game Engine Programming. Thomson
Course Technology, Premier press, 2004.
Apêndice I – Introdução ao 3D Game Studio
1. Introdução
O 3D Game Studio é um engine de alto nível de abstração, isto é, possibilita que o
desenvolvimento de um game seja realizado sem a necessidade de grandes
conhecimentos de programação ou conhecimento de algoritmos específicos. Por um
lado a produção se torna simples e rápida, mas por outro lado as possibilidades são
limitadas e o padrão gráfico dos jogos terão ligeira semelhança entre si.

Figura A1.1 – Alguns níveis de jogos feitos no 3D Game Studio

O Engine é composto basicamente por 2 módulos:

- Model Editor, responsável sobretudo pela criação e animação de modelos
dinâmicos e de terrenos;
- Level Editor, para elaborar uma fase por completo.
Para se criar um jogo no Game Studio é necessário, além de conhecer estas duas
ferramentas, conhecer também a linguagem script (WDL), que permite criar a lógica do
jogo e comportamento inteligente de alguns elementos.
2. Level Editor
O Level Editor é o principal módulo do Game Studio. É nele que serão inseridos os
elementos estáticos, os dinâmicos, terrenos, luzes, sprites e cameras. Também é nele
que se fará a associação de programas feitos em WDL com os modelos 3D. Além de
tudo isto, é neste módulo que será gerada a BSP, os Light maps, PVS e demais
componentes que permitirão que o jogo seja executado.
Na Figura A2.2 pode-se ver que a tela do Level Editor está dividida em 3 partes:

Figura A1.2 – Level editor do 3D Game Studio

– Área de trabalho: Esta região permite ver a geometria da cena. Estas visões podem
ser ortogonais (sem deformação perspectiva) ou perspectivas, dadas pela visão de
camera. Normalmente se operará com a visão ortogonal de topo, lado e frente e com
a visão perspectiva da camera 3D. Para inserir uma nova vista, basta clicar no menu
view◊ Add View. Para a visão de camera pode-se optar pelo modo de visualização:
View ◊ Wire Frame permite ver a modelagem em formato de arestas e vértices,
View◊ Solid permite ver a modelagem com os polígonos preenchidos e View ◊
Textured permite ver a modelagem com as texturas aplicadas. Normalmente este
último modo é o mais conveniente de se usar, pois permitirá que se tenha uma idéia
mais próxima do resultado final. Com o botão da direita do mouse pode realizar-se a
operação de PAN, que consiste em mover a área que se esta mostrando na região. A
operação de PAN ocorre simultanemante em todas as vistas ortogonais, mas
separadamente na visão de camera. Para se realizar um ZOOM sobre uma região,
pode-se usar o mouse wheel ou clicar no ícone de lupa. Sobre a visão de camera é
possível também realizar uma operação de ORBIT, que consiste em girar a camera
ao redor de seu alvo. Isto pode ser feito através do ícone de um olho verde com uma
flecha em formato de arco.

– Área de Projeto: Nesta seção manipula-se os diversos recursos que se encontram

presentes no cenário. Object refere-se a todos os objetos presentes no cenário, Views
relaciona todas as vistas armazenadas (isto é feito clicando-se na pasta com o botão
direito do mouse e escolhendo a opção Add View Settings, que gravará as
configurações das vistas num item mostrado dentro desta pasta), Texture indica
todas as bibliotecas de texturas disponíveis, bem como as imagens de cada
biblioteca e Resources indica todos os elementos que estão sendo usados, tais como
 sons, scripts e mapas. Ao dar um double-click sobre um dos recursos, será aberto o
arquivo pelo programa associado ao seu tipo.

– Menu e Toolbar: Nesta área se encotram as funcionalidades e comandos do Level

Editor.

2.1 Modos de Manipulação

Apenas um modo de manipulação pode estar acionado de cada vez. Estes modos podem
ser:
- Selecionar (botão com um dedo): permitirá selecionar um determinado objeto
ou grupo. Para selecionar basta clicar sobre o objeto ou traçar um retângulo com
o mouse, fazendo com que todos os objetos que estejam dentro sejam
selecionados. Um objeto selecionado aparecerá em vermelho, enquanto os não
selecionados aparecem em branco.
- Mover (botão com uma flecha sobre um cubo): Permitirá mover um
determinado objeto ou grupo livremente.
- Rotacionar (botão com um arco sobre um cubo): Permitirá rotacionar um
determinado objeto sobre o eixo perpendicular a vista em que se realiza a
operação;
- Escalar (botão com setas em cruz sobre um cubo): Irá alterar a escala de um
objeto. Ao mover o mouse horizontalmente a escala será feita na direção
horizontal da vista e ao mover verticalmente a escala será feita na direção
vertical. Para que a escala seja igual nas duas direções, basta mover o mouse
apertando a tecla ctrl.
As transformações podem ser feitas com maior ou menor precisão através do
snap. O snap consiste em realizar incrementos pré-estabelecidos nas transformações. O
valor do Snap é estipulado no pequeno slider que se encontra na área de botões do Tool
bar. Caso o valor seja correspondente a 1 as transformações serão contínuas.
2.2 Texturas
As texturas são organizadas em bibliotecas, chamadas de WADS, que podem ser
manipuladas através do comando Textures◊ Wad Manager. Para se criar uma nova
biblioteca, usa-se o comando Add Wad. A biblioteca construída não possuirá nenhuma
textura associada, enquanto o usuário não as inserir. Para inserir texturas deve-se clicar
com o botão direito sobre o espaço correspondente à biblioteca, na área de projeto e
escolher o comando Add Texture. Pode-se também criar uma biblioteca que contenha
todas as imagens que estão presentes no projeto corrente. Para tanto deve-se escolher o
comando Build Wad no Wad Manager. Para carregar uma biblioteca de texturas para
dentro de um determinado projeto se deve usar o comando Add Wad estando dentro do
Wad Manager. Ao realizar isto aparecerá a lista de todas as texturas existentes nesta
biblioteca no campo Textures, da área de projetos.
Pode-se criar uma lista com as texturas mais usadas num projeto, sendo que
estas texturas podem ou não estar em WADs diferentes. Para isto deve-se usar o
comando Textures ◊ Texture Bookmarks.
Para associar uma textura a um determinado objeto, basta selecionar o objeto e
em seguida dar um double click sobre a textura desejada, na área de projeto. Ao realizar
isto, todos os polígonos do objeto receberão esta textura. A textura pode ser manipulada
através do painel de propriedades do objeto em questão (Figura A1.3), tendo em conta
que o controle será individual para cada polígono que compõe o objeto. Para escolher o
polígono deve-se clicar sobre as setas que estão no canto superior direito da janela. O
polígono selecionado irá aparecer em amarelo.

Figura A1.3 – Painel de propriedades de um objeto

Uma das opções do painel de propriedades se refere justamente à forma como a

textura está aplicada (opção surface). O parâmetro offset permite mover a textura sobre
os polígonos, scale permite alterar a escala da textura em relação ao objeto e angle
permite girar a textura sobre os polígonos.
Pode-se aplicar uma textura também apenas para um elemento de um grupo ou
apenas para uma das paredes de um bloco. Para tanto deve-se selecionar o elemento ou
a parede. Isto é feito selecionando-se o grupo ao qual pertence e depois usar o comando
Scope Down (botão com um grupo de cubos e uma seta para baixo) que irá descendo
aos níveis mais baixos da hierarquia. Para voltar ao objeto original, usa-se o comando
Scope Up.
2.3 Construindo Salas
As salas serão normalmente feitas através de objetos primitivos, ou blocos (cubos,
cilindros, pirâmides, etc). Para criar um objeto primitivo usa-se o comando Object◊
Add Primitive ou Object ◊ Add Cube. Note-se que os objetos primitivos serão sempre
representados por polígonos e deve-se escolher o grau de refinamento dos mesmos. É
importante que se escolha sempre o menor número de polígonos possíveis, de forma a
otimizar a cena.
Uma vez criado o objeto que servirá de sala, deve-se usar o comando Edit ◊
Hollow Block para que cada polígono se torne uma parede (composta por 6 polígonos).
Isto permitirá que uma parede possa ser vista dos dois lados, sem a necessidade de que o
engine crie um estado de normais duplas para cada polígono.
 Como na maioria das vezes as salas serão originadas por cubos, já existe um
comando capaz de criar salas prontas, ou seja, com o Hollow Block já aplicado. (Object
◊ Add Hollow Cube)
Para acessar às propriedades de uma determinada primitiva, basta clicar com o
botão direito sobre o mesmo e optar por properties. As propriedades que um bloco pode
receber são:
- Passable: O bloco não terá colisão com os elementos dinâmicos do jogo. (Por
exemplo, água de uma piscina);
- Invisible: O bloco não será visualizado no jogo, mas poderá ter colisão com os
outros elementos.
- Texture Lock: A textura permanecerá imóvel quando o objeto sofrer
transformações espaciais.
Após ajustar o tamanho e a posição do bloco que servirá de sala, muito
provavelmente se desejará criar buracos que sirvam de passagem de uma sala para
outra. Para isto, deve-se utilizar um objeto auxiliar, que poderá ser qualquer uma das
primitivas disponíveis. Este objeto deverá ser colocado de tal forma que contenha
dentro dele toda a parte da geometria de outros objetos que serão removidos (ver Figura
A1.4). Após posicioná-lo adequadamente, deve-se manter este objeto auxiliar
selecionado e utilizar o comando Edit ◊ CSG Subtract. Feito isto, o objeto auxiliar
ainda estará presente, mas todas as partes das geometrias que estiverem contidas em seu
interior terão desaparecidos. Para completar a operação deve-se apagar ou mover o
objeto auxiliar. Esta operação apenas funciona com os objetos estáticos, ou seja, os
blocos e os objetos pré-fabricados. Não terá nenhum efeito com os objetos dinâmicos,
tais como sprites e terrenos.

Figura A1.4 – Operação de subtração