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 ducat ivos

Jogos de E nt r et eniment o

Jogos D idát icos

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

S AL

E xt ens ões

S is t ema Oper acional

JVM

AMP H I B I AN

S AL

E xt ens ões

S is t ema Oper acional

JVM

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