Universidade Presbiteriana Mackenzie
REALIDADE MISTURADA APLICADA À JOGOS DIGITAIS: DESENVOLVIMENTO
DE UM JOGO COM REALIDADE MISTURADA EM COMEMORAÇÃO AOS 140
ANOS DE MACKENZIE
Dennis José da Silva (IC) e Ismar Frango Silveira (Orientador)
Apoio: PIVIC Mackenzie
Resumo
Com a criação de dispositivos imersivos para jogos digitais como Microsoft Kinect, Sony Playstation
Move e Nintendo Wii e o sucessos dos mesmos em ambiente comercial é proposto o
desenvolvimento de um jogo com características de realidade misturada para proporcionar uma
sensação de maior imersão ao jogador. O jogo terá como tema a historia da Universidade Mackenzie
e será ambientado na mesma, o jogador deverá realizar ações em dois ambientes o de realidade
virtual e o de realidade aumentada, para o seu desenvolvimento é proposto uma integração entre
uma game engine e uma API de realidade aumentada de uso geral que possa ser reutilizada para
desenvolvimento de outros jogos com as mesmas características, utilizado uma abordagem top-down
iniciando com a criação de documentos de game design e level design, captura de requisitos e
diagramas de UML foi proposta um mecânica de funcionamento para essa integração assim como a
implementação de um dos módulos integrando a game engine Microsoft XNA e a API de realidade
aumentada ARToolkit para isso foi necessário ultrapassar alguns obstáculos como a comunicação
entre as linguagens de programação C# utilizada no XNA e C/C++ utilizada na ARToolkit, mas com a
utilização da linguagem CLI C++ da Microsoft e do padrão de projeto adapter foi possível realizar
essa comunicação.
Palavras-chaves: Realidade misturada, game engine, Integração de tecnologias
Abstract
With the creation of immersive devices to digital games as Microsoft Kinect, Sony Playstation Move
and Nintendo Wii and the success of theirs at commercial environment is proposed the development
of a game with mixed reality characteristics to provide a greater sense of immersion to the player. The
game will have Mackenzie University story as its theme and scenario too, the player will take action in
two environments, the virtual reality environment and augmented reality environment, to its
development is proposed a integration system between a game engine and a augmented reality API
for a general use that can to be reused in another game with the same characteristics development.
Using a top-down approach started with a game design and level design documents, requirements
capture and UML diagrams was proposed operating mechanism to this integrate system and
implementation of one of the modules integrating the Microsoft XNA game engine and ARToolkit
augmented reality API, for this was necessary pass obstacles as the communicate between the
programming languages C# used in Microsoft XNA and C/C++ used in ARToolkit API but with
Microsoft CLI-C++ programming language use and the adapter design pattern use was possible made
this communication.
Key-words: Mixed reality, game engine and technologies integration
1
VII Jornada de Iniciação Científica - 2011
INTRODUÇÃO
A área de jogos digitais está se dedicando cada vez mais ao desenvolvimento de
dispositivos com interação não convencional isso pode ser notado por meio dos
investimentos de empresas e nos produtos gerados por esses investimentos como PSMove
(SONY, 2011), Nintendo Wii (NINTENDO WII, 2011) e Microsoft Kinect (MICROSOFT, 2011)
apresentados na figura 1. Todos esses dispositivos tem como característica a imersão não
prendendo o jogador ao pressionar de botões, mas também permitindo que o jogador
interagir com o seu próprio corpo realizando movimentos de acordo com o jogo. O Microsoft
Kinect permite ainda que o jogador jogue sem controle realizando apenas movimentos com
o seu corpo.
Figura 1: Da esquerda para direita: Controle Nintendo Wii, Controle Sony Playstation Move, Microsoft Kinect
Os campos de realidade virtual e aumentada são áreas que estudam interfaces
tridimensionais em tempo real, a realidade misturada é a área que estuda aplicações com
características de realidade virtual e aumentada simultaneamente (KIRNER, 2008). Com
esses conceitos é proposto o desenvolvimento de um jogo com essas características em
busca de uma maior imersão e proporcionar ao jogador uma nova maneira de interagir. Para
suprir essas características o jogo terá dois modos intercambiáveis durante o gameplay, o
modo realidade virtual onde o jogador terá que interagir com dispositivos tradicionais como
teclado, mouse e controle e terá que explorar o cenário para encontrar itens secretos e
desafios e o modo realidade aumentada onde o jogador terá que interagir com marcadores
de realidade aumentada para resolver puzzles e progredir no jogo.
Para o desenvolvimento do jogo é proposto o desenvolvimento de uma camada de software
entre uma game engine e uma API de realidade aumentada para que seja possível integrar
recursos de uma game engine como efeitos de física, manipulação de modelos 3D, HUD,
efeitos sonoros, entre outros a aplicativos de realidade aumentada, essa integração tem
como objetivo facilitar o desenvolvimento de aplicativos e jogos com essas características.
2
Universidade Presbiteriana Mackenzie
REFERENCIAL TEORICO
Desde a invenção do ENIAC a necessidade de interfaces intuitivas e fáceis de aprender é
uma preocupação dos teóricos de interface-humano computador. A realidade virtual estuda
e desenvolve interfaces interativas e tridimensionais criadas em computador que funcionam
em tempo real (KIRNER, 2008), diferentemente da realidade aumentada que mistura
ambientes reais e virtuais, geralmente usasse marcadores que são sobrepostos por
modelos 3D (figura 2). A realidade misturada estuda aplicações com características de
realidade virtual e aumentada (REIMANN, 2005).
Figura 2: Jogo Eye of Judgment para Sony Playstation 3 que tem características de realidade
aumentada com marcadores nas cartas. Imagem retirada do site eyeofjugment (2011) .
Aplicações com realidade misturada vêm sendo estudadas e aplicadas em diversas áreas
como fotometria (TAKEMURA, 2006), psicologia (NILSSON e JOHANSSON, 2005),
arqueologia (ISHAK e FEINER, 2004), educação (STAPLETON e HUGHES, 2005),
arquitetura (KAKUTA, 2005), entre outras.
As aplicações mais comuns em realidade virtual são aquelas em que o usuário interage com
mundos virtuais manipulando objetos virtuais e navegando no ambiente por meio de
dispositivos de entrada como mouse, teclado, joystick, trackers entre outros. Jogos digitais e
mundos virtuais na web são exemplos de aplicações. Ferramentas como VRML (W3C,
1995) e X3D (WEB3D, 2011) são muito utilizadas para o desenvolvimento dessas
aplicações em ambiente web já que podem ser lidas e interpretadas pelo navegador apenas
com a instalação de plug-ins, em jogos digitais normalmente são utilizadas game engines
que facilitam a inserção de interação com modelos tridimensionais normalmente modelados
3
VII Jornada de Iniciação Científica - 2011
em ferramentas como Blender (BLENDER, 2011), 3D Studio Max e Maya (AUTODESK,
2011).
As ferramentas mais comuns em realidade aumentada são ARToolkit e Flartoolkit (KIRNER,
2008), ambas são APIs que possuem algoritmos para manipulação de marcadores e
orientação de modelos sobre esses marcadores. ARToolkit é uma API desenvolvida em
linguagem C e possuem licença livre para uso acadêmico, o Flartoolkit é desenvolvido em
Flash e é mais utilizado em aplicações para internet.
Pela a abordagem adotada foi importante o desenvolvimento de dois documentos referentes
à área de jogos digitais, o GDD (Game Design Document) e o LDD (Level Design
Document) os mesmos são usadas para descrever e delimitar o jogo com intuito de auxiliar
e guiar a equipe de desenvolvimento (ROUSE, 2005).
Em um GDD são descritos a historia, mecânica, itens, personagens, entre outros elementos
do jogo, por meio de um GDD a equipe de desenvolvimento pode criar e modelar os
personagens de acordo com sua personalidade e aparência descritas no documento com a
historia documentada é possível desenvolver o ambiente de acordo com o clima que o
designer projetou, a equipe de programação é capaz de projetar e desenvolver a estrutura
interna que usará no jogo a partir da descrição dos itens e mecânica. Apesar de o GDD ser
um documento na há uma padronização em seu desenvolvimento, ao contrario do que
ocorre na indústria cinematográfica com o roteiro, apesar disso, os grandes estúdios de
desenvolvimento seguem padrões internos (ROUSE, 2005).
O LDD é o documento responsável por descrever o cenário, ou seja, o local onde ocorrera o
jogo, normalmente o documento de level design possui uma ilustração do cenário que será
usado pela equipe de designs e artistas como guia em suas criações e pela equipe de
programadores para o desenvolvimento da interação do cenário já que a mesma deve ser
descrita no documento (figura 3).
4
Universidade Presbiteriana Mackenzie
Figura 3: Exemplo de um esboço de um LDD, normalmente feito nas fases iniciais da documentação.
Figura retirada de Byrne (2005).
A tarefa de um designer de level se concentra em desenvolver um cenário atrativo ao
jogador impondo barreiras e desafios como puzzles, inimigos e labirintos, entre outros. O
posicionamento de objetos e a interação do jogador com eles é uma das tarefas deste
profissional assim como o desenvolvimento de um cenário que represente o clima do jogo
(ROUSE, 2005).
Em conjunto esses dois documentos são importantes para que a equipe desenvolvimento
trabalhe com linhas guias e focadas em um objetivo, todos trabalhando para criação de um
jogo que tenha características únicas em todos os aspectos assim como a engenharia de
software atua no desenvolvimento de software (ROUSE, 2005).
Com o desenvolvimento da documentação do jogo é necessário escolher as ferramentas e
tecnologia para enfim iniciar a criação do game. Desde a criação Spacewars em 1961
(JEFFREY, 2007) a indústria de jogos eletrônicos vem crescendo rapidamente até mesmo
ultrapassou a indústria cinematográfica em algumas medições (ENTERTAINEMENT
SOFTWARE RATING BOARD, 2009), com esse crescimento nota-se um aumento na
complexidade no gameplay e no desenvolvimento de jogos, para agilizar e facilitar o
desenvolvimento de jogos é importante que uma empresa adote a utilização de uma game
engine (ANDERSON, 2008).
5
VII Jornada de Iniciação Científica - 2011
Uma game engine é um conjunto de módulos que modela as funcionalidades básicas
comuns aos games independente do tipo e estilo (LEWIS, 2002). Esses módulos são
responsáveis pelas funcionalidades de input (entrada de dados), geralmente realizados por
meio de teclado, mouse e joystick e output (exibição de gráficos no display, som, vibração
no controle), existem game engines que suportam efeitos de física também como Unreal
Game Engine (EPIC GAMES, 2011) e Unity (UNITY, 2011). As funcionalidades de uma
game engine estão entre manipulação de grafo de cena, renderização, posicionamento de
objetos no cenário, controle de mecânica, manipulação de animação, controle de
iluminação, GUI (Graphical User Interface, são imagens em 2D geralmente exibindo
informações sobre o jogo como vidas restantes, fase atual, item selecionado, entre outros),
essas tarefas são realizadas por meio da comunicação da game engine com uma API de
baixo nível (LEWIS, 2002).
Uma das games engines que tem se destacado entre os desenvolvedores indies
(desenvolvedores que não trabalham para grandes corporações) é a Microsoft XNA. Dentre
suas vantagens estão o desenvolvimento para multiplataforma (Windows phone 7, Xbox,
computadores) com reuso de código, é gratuita, tem suporte da Microsoft, possibilita
trabalhar coma Microsoft Live e comercializar os jogos por meio da mesma. Com a versão
4.0 do C# ainda é possível trabalhar em seu ambiente multithreading possibilitando o
aumento de desempenho com o processamento paralelo (MICROSOFT, 2011).
XNA é uma game engine desenvolvida sobre o Microsoft Directx (biblioteca com
diversas funções de desenho 2D e 3D além de utilitários para som, input e output, entre
outras), criando assim uma interface mais amigável entre o desenvolvedor e a game engine
disponibilizando um conjunto de classes, padrões e estruturas que facilitam o
desenvolvimento do game utilizando ferramentas de orientação a objetos disponibilizados
pela linguagem C# e a IDE Microsoft Visual Studio que possuí diversas ferramentas para o
desenvolvimento como debbugers e Intelisense. O XNA pode ser dividido em diversos
módulos e quatro camadas que se comunicação entre si e disponibilizam um conjunto de
classes no formato de um framework para o desenvolvedor em sua camada mais alta (figura
4):
•
Game: Foco no desenvolvimento do conteúdo do jogo é nesta camada que o
desenvolvedor trabalha;
•
Extended Framework: Nesta camada ocorre uma abstração do núcleo do XNA
onde são definidas as classes que serão utilizadas pela camada game;
•
Core Framework: Abstrai as funcionalidades das bibliotecas de baixo nível da
camada de plataforma;
•
Plataforma: Bibliotecas de baixo nível.
6
Universidade Presbiteriana Mackenzie
Figura 4: Estrutura da game engine Microsoft XNA, imagem feita por Lobão (2008)
Em jogos modernos uma game engine não é suficiente para manter a qualidade exigida pelo
mercado para isso é necessário engines adicionais para controle de física, inteligência
artificial e outras especialidades, essas engines não são inclusas em diversas engines como
Ogre e XNA, sendo necessário a integração de engines externas para realização destas
tarefa (figura 5).
Figura 5: Estrutura de game engine que não possui engine de física e inteligência artificial embutidas ao seu
núcleo. Adaptado de Jeffrey (2007)
Havok (HAVOK, 2011) e Physx (NVIDIA, 2011) são duas engines de físicas comerciais e
concorrentes e possuem diversos títulos de sucesso no mercado produzidos com suas
tecnologias, Newton Game Dynamics (NEWTON GAME DYNAMICS, 2011) é uma engine
7
VII Jornada de Iniciação Científica - 2011
de física open source e pode ser baixado da internet gratuitamente, todas essas engines
podem ser integradas com game engines para a produção de jogos mais elaborados, ainda
não existe uma engine para inteligência artificial de uso geral como as de física,
normalmente esse modulo do game é implementado pelo próprio desenvolvedor dentro de
uma game engine, exceto a game engine Unreal (EPIC GAMES, 2011) que possui o
sistema Kismet para o controle deste modulo.
METODO
Para o projeto optou-se pelo uso de uma metodologia top-down, ou seja, inicialmente não foi
decidido qual tecnologia utilizar, mas como o jogo deveria estar no final e para isso foi criado
os documentos de game design e level design, resumidamente o jogo proposto se baseia na
historia de José um garoto do Colégio Mackenzie com uma grande imaginação, certo dia
sua professora de historia resolve fazer um passeio no Edifício Mackenzie o primeiro edifício
da faculdade em Higienópolis quando José começa a imaginar como seria viver naquela
época, a partir dai o jogador assume o papel de José que deverá encontra uma relíquia para
cada faculdade para que possa sair do mundo de sua imaginação. O jogo se baseia em uma
mecânica simples de jogos em terceira-pessoa onde a câmera irá acompanhar o
personagem sobrevoando-o, o jogador poderá explorar o cenário e encontrar itens secretos
e os desafios que serão recompensados por uma relíquia de faculdade, o jogo terá dois
modos, o modo em que o jogador explora o cenário em busca de desafios e itens, será
chamado de modo explorador e representara a interação por meio de realidade virtual, o
modo em que o jogador deverá resolver um puzzle ou desafio será chamado de modo
desafio e jogador irá interagir por meio de marcadores de realidade aumentada.
No documento de level design foi proposto dois desafios para o modo de realidade
aumentada, o primeiro é composto por um labirinto virtual que será projetado em cima de
um marcador de realidade aumentada e o objetivo do jogador será levar uma pequena
esfera do ponto inicial até o ponto final passando-a por várias paredes, o jogador deverá
movimentar o marcado para que a esfera se movimente respeitando leis de física (figura 6).
Figura 6: Imagem utilizada no LDD para o primeiro desafio
8
Universidade Presbiteriana Mackenzie
No segundo nível o jogador terá um tabuleiro com marcadores de realidade aumentada
projetando pedaços de encanamento não conectados e vários marcadores moveis que
representaram pedaços deste encanamento e o objetivo do jogador será posicionar com a
orientação certa essas peças moveis para que todo o encanamento seja conectado antes do
cronometro terminar sua contagem (figura 7).
Figura 7: Esboço do segundo desafio.
Com o desenvolvimento da ideia geral do jogo e de sua documentação foi estudado as
tecnologias que poderiam ajudar a implementá-lo. Inicialmente foi escolhido a game engine
Unity para o desenvolvimento do jogo, por que ela é uma engine que possibilita a
prototipação e implementação do jogo com facilidade e agilidade também pelo
conhecimento técnico adquiridos, mas após uma analise em sua documentação na web
constatou-se que ela não tem suporte a desenvolvimento de plug-ins com a linguagem
C/C++ em sua versão indie (UNITY, 2011), requisito necessário para a integração da engine
com a ARToolkit (API de realidade aumentada escolhida para a integração), então foi
optado em integrar a linguagem C# (suportada pela Unity) com as linguagens C/C++ por
meio de uma dll (dynamics link library), foi verificado que essa integração era possível por
meio de uma extensão da linguagem C++ da Microsoft chama de CLI (Commom Language
Infrastruture) C++, essa extensão quando compilada gera bytecodes para linguagem C#.
Porém não foi possível realizar essa integração na Unity por que seu compilador e
interpretador da linguagem C# não é o mesmo utilizado pela Microsoft, a Unity usa o
9
VII Jornada de Iniciação Científica - 2011
compilador Mono que possibilita o desenvolvimento de aplicativos em C# para
multiplataformas.
Tendo em vista essas adversidades foi alterada a game engine utilizada no projeto para a
Microsoft XNA, por que possui vários recursos, é gratuita e suportar desenvolvimento para
multiplaformas da Microsoft como Xbox, Windows Phone e computadores com sistema
operacional Windows, a utilização da linguagem C# com o compilador .Net framework
também foi um diferencial. Definido a tecnologia e os recursos disponíveis existiam duas
importantes tarefas a serem realizadas, o desenvolvimento dos assets do jogo, ou seja, os
modelos 3D, som, cenário, entre outros, ou desenvolver essa camada de software para a
integração das duas tecnologias. Na primeira situação seria necessário primeiramente
desenvolver habilidades técnicas em alguma ferramenta de modelagem 3D como Blender,
3D Studio Max ou Maya, planejar os elementos do jogo e cria-los, na segunda situação seria
necessário o planejamento e a documentação necessárias para o desenvolvimento de um
software reutilizável e modular e depois implementa-lo.
Como seria necessário o desenvolvimento da camada de integração para definir o que seria
possível ou não implementar e conhecer os limites desta aplicação optou-se por
implementá-la primeiro. O trabalhou iniciou-se por uma definição de alto nível separando as
partes que seriam integradas para o desenvolvimento do software, essa definição foi
formalizada por um diagrama de componentes (figura 8).
Figura 8: Diagrama de componentes proposta para a camada de integração entre a game engine XNA e a API
ARToolkit
Cada modulo será responsável pela integração de um conjunto de funcionalidades
especificas e os mesmos serão independentes entre si, e o modulo principal que integrará
todos eles (Integration Layer) será dependente de todos e o mesmo disponibilizara uma
interface ao XNA e utilizara a interface da ARToolkit, as responsabilidades dos módulos
foram dividas da seguinte maneira:
10
Universidade Presbiteriana Mackenzie
•
AR Resource Manager: Será responsável por manipular recurso relacionados a
realidade aumentada como marcadores e configuração de câmera;
•
Transformation Adapter: Será responsável por realizar adaptações entre os tipo
de transformações (rotação, translação, escala, definição de câmera, entre outras)
das duas tecnologias.
•
3D Models Adapter: Será responsável por realizar adaptações do modelos
carregados no XNA e sua representação na ARToolkit
•
Integration Layer: Será responsável pela comunicação entre o XNA e a
ARToolkit por meio dos componentes definidos acima.
Concluído o diagrama de componentes foi definido que o componente Transformation
Adapter seria o primeiro a ser implementado, esse processo iniciou-se pela documentação
das classes por meio de um diagrama de classes (figura 9).
Figura 9: Diagrama de classes do componente Transformation Adapter.
Essa estrutura de classes tem como objetivo fazer uma adaptação da classe Matrix do XNA
para a representação de matriz utilizada em OpenGL (biblioteca gráfica utilizada na
ARToolkit), para isso foi utilizado o design pattern Adapter (GAMMA, HELM, et al., 2003)
com uma adaptação, como a classe MatrixAdapter não conseguia manipular um tipo de
dado complexo do C# por ser uma classe em C++ foi necessário a inserção da classe
MAREMatrix em C# para conversão da classe Matrix em um tipo manipulável em C++.
Com o desenvolvimento da estrutura e a definição das classes foi possível a implementação
deste componente, utilizando Microsoft Visual Studio foi desenvolvida duas dlls uma C# para
classe MAREMatrix que foi utilizada pela dll TransformationMatrix para realizar a adaptação.
Para fim de testes foi desenvolvido um aplicativo em XNA que envia uma Matrix para a
11
VII Jornada de Iniciação Científica - 2011
adaptação e um aplicativo em C++ recebia essa matriz adaptada e a imprimia em um
arquivo.
RESULTADOS E DISCUSSÃO
Após o desenvolvimento da documentação do jogo (game design document e level design
document) é proposto um modelo para o desenvolvimento da camada de integração que
pode ser reutilizado em outros projetos ou na integração de outras game engines ou outras
ferramentas de realidade aumentada. O modelo propõe o desenvolvimento de uma camada
que realize a comunicação de uma game engine com uma API de realidade aumenta
dividindo as responsabilidades, a API de realidade aumenta seria responsável por fornecer
as informações de onde está o marcador e de sua orientação em relação à câmera, também
teria que desenhar o modelo no marcador e das configurações na câmera, a game engine
seria responsável por manipular os dados recebidos da interação do jogador e responder
essas ações no objeto por meio de transformações, também seria de responsabilidade da
game engine a integração com outras ferramentas como uma engine de física e a
manipulação de recursos externos como carregamento de áudio e de modelos 3D.
O desafio do labirinto proposto no game design atuará da seguinte maneira no modelo:
•
A API de realidade aumentada informaria o posicionamento e orientação dos
marcadores para a camada de integração;
•
A camada de integração adaptaria os dados enviados pela API de realidade
aumentada para um formato conhecido pela game engine;
•
A game engine carregaria o modelo 3D do labirinto e da esfera em memoria, e com
as informações dos marcadores processaria as novas posições e orientações dos
modelos e as enviaria para camada de integração.
•
A camada de integração adaptaria o modelo 3D e suas informações de posição e
orientação para um formato conhecido na API de realidade aumentada;
•
A API de realidade aumentada desenharia a imagem no marcador;
•
O processo se repete até o fim do jogo definido pela game engine;
Também foi proposta uma arquitetura para o desenvolvimento deste modelo utilizando a
game engine XNA e a API de realidade aumentada ARToolkit essa arquitetura baseada em
componentes (descrita na seção métodos), cada componente é responsável por ações de
comunicação entre as tecnologias. Por meio deste componente foi possível o
desenvolvimento de classes que possibilitam a criação da comunicação entre o XNA e a
ARToolkit, para isso foi necessário integrar duas linguagens de programação diferentes C e
C# realizada por meio da linguagem CLI C++, por meio destas tecnologias foi possível
desenvolver uma pequena aplicação de teste que permitia trocar de uma ambiente para o
12
Universidade Presbiteriana Mackenzie
outro, ou seja, dentro de um jogo feito em XNA foi possível ativar uma aplicação de
realidade aumenta, essa aplicação abria uma janela em azul (aplicação padrão do XNA) que
executa as funções gráficas e processamentos necessários em background e aguardava
que o usuário apertasse a tecla Enter e então disparava um evento na aplicação que
executa uma função dentro de uma dll CLI-C++ que executava uma aplicação utilizando
funções da ARToolkit.
CONCLUSÃO
É possível facilitar o desenvolvimento de jogos que utilizam realidade misturada e
aumentada por meio de uma integração de uma game engine com uma API de realidade
aumentada, por meio desta integração é possível desenvolver jogos com realidade
aumentada mais interativa e com mais recursos, por que as game engines possuem
diversos recursos para manipulação de objetos 3D, inserção de física e criação de
interação.
Como projetos futuros é pretendido o desenvolvimento dos demais componentes da
arquitetura proposta para a integração do XNA e da ARToolkit, e o desenvolvimento do jogo
proposto inicialmente, e a avaliação do desenvolvimento de um jogo por meio do modelo
proposto.
REFERENCIAS
ANDERSON, E. F. The Case for Research in Game Engine Architecture. ACM, 2008. 228231.
AUTODESK. Autodesk - 3D Design and Engineering Software for Architecture,
Manufacturing and Entertainment, 2011. Disponivel em: <http://usa.autodesk.com/>.
Acesso em: mar. 2011.
BLENDER. Blender org, 2011. Disponivel em: <http://www.blender.org/>. Acesso em: abr.
2011.
BYRNE. Game level design. [S.l.]: Charles River Media, 2005.
ENTERTAINEMENT SOFTWARE RATING BOARD. Video Game Industry Statistics. ESRB,
2009. Disponivel em: <http://www.esrb.org/about/video-game-industry-statistics.jsp>. Acesso
em: abr. 2011.
EPIC
GAMES.
Site
oficial
da
game
engine
Unreal,
2011.
Disponivel
em:
<http://www.unrealengine.com/>. Acesso em: abr. 2011.
EYEOFJUDGMENT. Site oficial do jogo Eye of judgment, 2011. Disponivel em:
<http://www.eyeofjudgment.com/>. Acesso em: abr. 2011.
13
VII Jornada de Iniciação Científica - 2011
GAMMA, E. et al. Desing Patterns Elements of Object-Oriented Software. [S.l.]: AddisonWesley, 2003.
HAVOK. Site oficial da Havok, 2011. Disponivel em: <http://www.havok.com/>. Acesso em:
ago. 2011.
ISHAK, E.; FEINER, S. Collaborative Mixed Reality Visualization of an. ACM, 2004.
JEFFREY, F. Down the Hyper-Spatial Tube: Spacewar and the Birth of Digital Game Culture.
Gamasutra, 2007. Disponivel em: <http://www.gamasutra.com>. Acesso em: mar. 2011.
KAKUTA, T. Shading and Shadowing of Architecture in Mixed Reality. ACM, 2005. 0-1.
KIRNER, C. Fundamentos de realidade virtual e aumentada. In: SISCOUTTO Realidade
virtual e aumentada: Uma abordagem Tecnológica. [S.l.]: SBC, 2008. p. 1-20.
LEWIS, J. J. M. Game engine in scientific research. ACM, 2002.
LOBÃO,
A.
Links
para
Jogos
-
Alexandre
Lobão,
2008.
Disponivel
em:
<http://www.alexandrelobao.com>. Acesso em: mar. 2011.
MICROSOFT. Site oficial do console XBox com Kinect, 2011. Disponivel em:
<http://www.xbox.com/en-US/Press/archive/2011/0308-Ten-Million-Kinects.>.
Acesso
em:
Julho 2011.
MICROSOFT. Site oficial da Microsoft para desenvolvedores Windows e Xbox, 2011.
Disponivel em: <http://create.msdn.com/en-US/>. Acesso em: abr. 2011.
NEWTON GAME DYNAMICS. Site oficial da engine de física Newton, 2011. Disponivel
em: <http://newtondynamics.com/forum/newton.php>. Acesso em: ago. 2011.
NILSSON, S.; JOHANSSON, B. A Cognitive Systems Engineering Perspective on the. ACM,
2005. 154-161.
NINTENDO WII. Site oficial do console Nintendo Wii, 2011. Disponivel em:
<http://www.nintendo.com/wii>. Acesso em: Julho 2011.
NVIDIA.
Site
oficial
do
produto
PhysX
da
Nvidia,
2011.
Disponivel
em:
Disponivel
em:
<http://www.nvidia.com/object/physx_new.html>. Acesso em: ago. 2011.
REIMANN, C. Adaptive mixed reality game. ACM, 2005. 302-305.
ROUSE, R. Game design: theory and practice. [S.l.]: Wordware, 2005.
SONY.
Site
oficial
do
console
Sony
Plastation,
2011.
<http://us.playstation.com/ps3/playstation-move/>. Acesso em: Julho 2011.
14
Universidade Presbiteriana Mackenzie
STAPLETON, C.; HUGHES, C. E. C.; HUGHES, C. E. The Art of Nurturing Citizen Scientists
through. ACM, 2005.
TAKEMURA, M. Photometric Inconsistency on a Mixed-Reality Face. ACM, 2006. 129-138.
UNITY. Site oficial da game engine Unity, 2011. Disponivel em: <http://unity3d.com/>.
Acesso em: mar. 2011.
W3C.
VRML
Virtual
Reality
Modeling
Language,
1995.
Disponivel
em:
<http://www.w3.org/MarkUp/VRML/>. Acesso em: abr. 2011.
WEB3D.
X3D
and
Related
Speci,
2011.
Disponivel
em:
<http://www.web3d.org/x3d/specifications/>. Acesso em: abr. 2011.
Contato: [email protected] e [email protected]
15