FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Jogos 3D em tempo real para iPhone /iPad baseados em sensores

Rui Tiago de Cruz Barros

Mestrado Integrado em Engenharia Informática e Computação

Orientador: Rui Pedro Amaral Rodrigues (Professor Auxiliar)

15 de Fevereiro de 2011

Jogos 3D em tempo real para iPhone / iPad baseados emsensores

Rui Tiago de Cruz Barros

Mestrado Integrado em Engenharia Informática e Computação

Aprovado em provas públicas pelo júri:

Presidente: António Fernando Vasconcelos Cunha Castro Coelho (Professor Auxiliar)

Vogal Externo: Frutuoso Gomes Mendes da Silva (Professor Auxiliar)

Orientador: Rui Pedro Amaral Rodrigues (Professor Auxiliar)

15 de Fevereiro de 2011

Resumo

O desenvolvimento de jogos e conteúdos multimédia está cada vez mais associadoà utilização de sensores. O principal objectivo é proporcionar aos seus utilizadores ex-periências mais naturais e divertidas. Ao mesmo tempo, o aparecimento de dispositivosmóveis mais capazes, como telemóveis e tablets, abrem a porta à criação de aplicações 3Dbastante apelativas e com grande potencial de crescimento. É a junção destas duas com-ponentes que dá origem a esta dissertação. A criação de jogos 3D em dispositivos móveis,fortemente orientados para a interactividade, é uma oportunidade de chegar a um públicoalvo mais alargado. No entanto, esta expansão levanta novos problemas. É agora maisdifícil abranger todos os sistemas operativos e sensores disponíveis, obrigando, quasesempre, a escrever código específico para cada situação. A solução consiste em encontrarou desenvolver alternativas multi-plataforma para o motor gráfico 3D e para a camada deinput da aplicação.

i

ii

Abstract

The development of games and multimedia contents is more and more associated tothe use of sensors. The first aim is to offer funnier and more natural experiences toits users. At the same time, the discovery of more modern and more efficient mobilegadgets, like mobile phones and tablets , leads us to the creation of 3D applications quietappealing and with a great potential of increasing. This thesis is based on the union ofthese two components. The creation of 3D games for mobile gadgets, strongly directed tothe interactivity is an opportunity to reach a wider public target. However, this spreadingbrings us some new problems. Now, it’s more difficult to enlarge all the operative systemsand available sensors, which forces us to write a specific code for each situation. Thesolution consists of finding or developing multi-platform alternatives for the 3D graphicengine and for the input application layer.

iii

iv

Conteúdo

1 Introdução 11.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Motivação e Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Estado da Arte 52.1 Motores Gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Unity3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 OGRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Irrlicht Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.4 ShiVa3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.5 Análise comparativa . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Jogos com utilização de sensores . . . . . . . . . . . . . . . . . . 152.2.2 Exemplos de dispositivos com sensores complexos . . . . . . . . 172.2.3 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Framework para abstracção de sensores 213.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.1 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.2 Blocos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.3 Acções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.4 Mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.5 Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4.1 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4.2 Classes principais . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4.3 Dependências . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Testes e resultados 354.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Ambiente de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

v

CONTEÚDO

4.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.5 Casos de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.6 Considerações sobre o Unity3D . . . . . . . . . . . . . . . . . . . . . . 39

5 Conclusões e Trabalho Futuro 415.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Referências 43

vi

Lista de Figuras

2.1 Editor 3D do Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Pequeno exemplo desenvolvido em OGRE 3D . . . . . . . . . . . . . . . 102.3 Editor 3D do Irrlicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Editor 3D do Shiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Labyrinth 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6 Doodle Jump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Cut the rope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.8 WiiSports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.9 Esquema representativo do funcionamento do Kinect . . . . . . . . . . . 192.10 Equipamento necessário para a utilzação do PlayStationMove . . . . . . . 20

3.1 Visão geral da arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Hierarquia de acções . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Possível estrutura da árvore de acções . . . . . . . . . . . . . . . . . . . 253.4 Mensagems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5 Demonstração de IConnection . . . . . . . . . . . . . . . . . . . . . . . 303.6 Utilização de threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Medição da latência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2 Resultado dos testes de latência para diferentes dispositivos (em micro-

segundos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

vii

LISTA DE FIGURAS

viii

Lista de Tabelas

2.1 Comparação entre os vários motores . . . . . . . . . . . . . . . . . . . . 14

ix

LISTA DE TABELAS

x

Abreviaturas e Símbolos

3D 3 DimensõesAPI Application Programming InterfaceCPU Central Processing UnitiOS Sistema operativo criado pela Apple para dispositivos móveisOGRE Object-Oriented Graphics Rendering EnginePSP PlayStation PortableWYSIWYG What You See Is What You Get

xi

ABREVIATURAS E SÍMBOLOS

xii

Capítulo 1

Introdução

Desde o seu aparecimento que os jogos têm vindo a marcar uma forte presença nasociedade actual e vieram transformar a forma como os conteúdos multimédia são apre-sentados ao público. São, cada vez mais, um veículo importante na comunicação deconceitos e dinamização de marcas pois permitem aproximar e cativar potenciais alvos denegócio, sejam eles jogadores ou empresas. À medida que o hardware evoluiu, também osjogos acompanharam esse progresso tirando partido das capacidades dos processadores eplacas gráficas que foram surgindo. O 3D emergiu, trazendo consigo novos ambientes eexperiências ao utilizador final.

Mais recentemente, os telemóveis passaram de simples ferramentas do quotidiano paraverdadeiras plataformas de entretenimento, disponibilizando todo o tipo de jogos e con-teúdos multimédia. A par deste crescimento verifica-se uma tendência dos fabricantesde dispositivos móveis criarem aparelhos com elevado poder de processamento e de osequiparem com vários tipos de sensores, abrindo novas oportunidades de interacção comas aplicações desenvolvidas. Estão assim reunidas boas condições para a produção deconteúdos 3D interactivos direccionados para os tablets e telemóveis.

O estudo que aqui se apresenta foi realizado na Gema Interactive Media , uma em-presa do Porto vocacionada para o desenvolvimento de soluções interactivas. A investi-gação destes temas visa responder às necessidades sentidas no dia-a-dia desta empresae que decorrem das constantes mudanças registadas no mercado tecnológico. O ramodas aplicações móveis está em forte crescimento exigindo uma actuação eficaz, capaz desatisfazer as expectativas dos clientes da Gema Interactive Media , quer pela sua abran-gência, quer pela qualidade das experiências proporcionadas. É neste contexto que surgeesta dissertação.

1

Introdução

1.1 Contexto

Hoje em dia é muito comum recorrer a aplicações multimédia para promover even-tos, conceitos e produtos, tais como mapas interactivos e superfícies multi-toque. Sãoaplicações que pretendem causar um impacto imediato e captar rapidamente a atençãodos utilizadores. É por isso importante garantir que despertam a curiosidade do maiornúmero de pessoas e que, uma vez conquistada, se traduza numa experiência divertida.Muitas destas soluções interactivas são multi-jogador, criando experiências partilhadaspor várias pessoas em simultâneo. Os computadores desktop têm vindo a desempenharum papel fundamental neste tipo de iniciativas já que é neles que este tipo de aplicaçõessão executadas. Por serem máquinas com enorme capacidade de processamento e arma-zenamento, são quase sempre peças indispensáveis para soluções interactivas. O recenteaparecimento de dispositivos portáteis, como são os tablets, veio alimentar as expectati-vas que os utilizadores depositam neste tipo de iniciativas. Ao contrários dos anteriores,estes dispositivos não obrigam a uma solução fixa num determinado espaço. Pelas suascaracterísticas, é possível, por exemplo, dispersar uma solução interactiva por diferenteslocais continuando a ser multi-utilizador.

As novas plataformas móveis apresentam-se como óptimas oportunidades para a cria-ção de jogos 3D muito semelhantes aos já existentes, mas com novas formas de interacção.Os sensores que geralmente equipam os tablets e telemóveis são mais um factor diferen-ciador quando comparados com os computadores convencionais. Começa a ser possíveldeixar de lado os antigos ratos e teclados, substituídos pelos acelerómetros, giroscópios eecrãs multi-toque.

1.2 Problema

Uma das componentes mais importantes no desenvolvimento de aplicações interacti-vas, e em particular de jogos, é a camada de interacção. Nos primeiros tempos dos víde-ojogos, essa camada reduzia-se em muitos casos à simples identificação de quais eram osbotões ou teclas pressionadas num dado momento. A pouca variedade de métodos de en-trada tornava o desafio de ler as intenções directas do jogador num tarefa simples e trivial.Com a evolução da tecnologia e, paralelamente, da melhoria da usabilidade das interfacede utilizador, os novos métodos de interacção são bastantes mais naturais e, consequen-temente, mais intuitivos para o utilizador final. Apesar das grandes vantagens que estaevolução reúne, levanta, também, inúmeros desafios. É agora mais difícil conseguir lidarcom todos os dispositivos, a complexidade dos dados e estados que geram, e as respec-tivas acções que deles resultam. Nos dias que correm, é preciso reconhecer gestos, some imagens, bem como processar informação oriunda de muitos outros tipos de sensores.É para dar resposta a esta necessidade de maior interactividade em dispositivos móveis

2

Introdução

que surge esta dissertação. Para que seja possível criar novas soluções, mais dinâmicas eamigáveis, com conteúdos suficientemente apelativos para todos os utilizadores.

O trabalho a ser desenvolvido pode ser dividido em duas partes. A primeira parteconsiste em estudar a viabilidade da utilização de um motor gráfico 3D em dispositivosmóveis. Os computadores são máquinas bem mais capazes que este tipo de aparelhoso que significa que podem existir diferenças entre características de motores para PC eas características de motores para dispositivos móveis. É objectivo desta primeira parteidentificar o motor com melhor compromisso entre desempenho e funcionalidades quepermita desenvolver simultaneamente aplicações para desktop e móveis.

A segunda parte tem como principal objectivo implementar uma framework multi-plataforma que transforme em acções o input que é recebido pelos dispositivos de entrada,sejam eles sensores, rato, teclado, joystick , etc. A vantagem que se pretende retirar destaframework é a abstracção do método de entrada de um jogo ou aplicação e que permita,de uma forma transparente, desenvolver o código orientado às acções, sem a preocupaçãode conhecer os diferentes dispositivos de entrada.

1.3 Motivação e Objectivos

Espera-se que a aplicação dos resultados da investigação permita acelerar o desen-volvimento de jogos multi-plataforma que explorem diferentes tipos de sensores. Sendopossível abstrair o tipo de dispositivos de entrada, é possível direccionar esforços paramelhorar a qualidade e as funcionalidades de cada jogo. As empresas e programadoresficam assim livres de trabalho que, embora obrigatório, não acrescenta valor aos seusconteúdos. É com o propósito de colmatar esta falha que se dá início a esta dissertação.Os objectivos passam por conhecer quais as vantagens e limitações do motor gráfico paradispositivos móveis, e ter uma solução que permita aos programadores da Gema Interac-tive Media utilizarem os sensores de qualquer aparelho de forma transparente, sem sernecessário implementar código para o efeito.

1.4 Estrutura do documento

No segundo capítulo é feita uma análise do estado da arte dos temas definidos ante-riormente. São apresentadas as actuais alternativas que de alguma maneira satisfazem osobjectivos propostos ou parte deles. É feita uma avaliação de cada uma dessas alternativaspara uma reflexão sobre a sua aplicabilidade no trabalho desenvolvido.

Já no terceiro capítulo, está documentada com mais detalhe a framework que resultadeste estudo. Inclui a definição dos requisitos que devem ser cumpridos, a arquitectura dasolução e discussão sobre a sua implementação.

3

Introdução

O quarto capítulo é dedicado aos testes aplicados à framework. São apresentados osrespectivos resultados e feita uma análise dos mesmos. É também possível encontrar nestecapítulo algumas considerações relevantes relativamente ao motor gráfico escolhido.

Por último, vem o capítulo cinco, onde se reúnem as principais conclusões retiradasao longo da criação deste documento e de todo o trabalho a ele associado. São sugeridosalguns melhoramentos bem como referidas algumas expectativas de trabalho futuro.

4

Capítulo 2

Estado da Arte

Neste capítulo é feito um estudo sobre as actuais tecnologias que estão relacionadascom os objectivos desta dissertação. Os resultados desse estudo sustentam o trabalho de-senvolvido no âmbito desta dissertação. Como já foi referido, esta dissertação pode serdividida em duas componentes distintas. Para cada uma dessas componentes é necessá-rio conhecer quais as ferramentas que já existem e avaliar a sua eficácia no contexto emque se inserem. A segunda componente da dissertação envolve a criação de uma plata-forma de abstracção de sensores, e requer um estudo mais orientado a tecnologias menosestabelecidas, no sentido de identificar novos caminhos a explorar.

2.1 Motores Gráficos

Hoje em dia existem várias e diferentes plataformas de desenvolvimento de softwareque têm vindo a ganhar mercado e que estão cada vez mais presentes em diversos tiposde computadores e dispositivos. Os motores gráficos têm acompanhado esta tendênciatentando garantir a compatibilidade com o maior número de sistemas operativos. Istopermite a empresas e programadores chegar a um maior número de utilizadores sem a ne-cessidade de criar conteúdos de raiz para cada plataforma. É por isso importante a análisedos vários motores gráficos tendo em conta as suas funcionalidades e desempenho. Du-rante a pesquisa de alternativas foi feita uma pré-selecção de quatro motores consideradosmais adequados para os objectivos definidos. Cada um desses motores foi avaliado combase no seguinte conjunto de critérios:

• Multiplataforma: Sendo um dos objectivos da dissertação estudar a portabilidadede jogos 3D desktop para dispositivos móveis, é importante cobrir o maior númerode sistemas operativos.

5

Estado da Arte

• Compatibilidade com o Objective-C: O motor gráfico escolhido deverá ter a capa-cidade de ser integrado na linguagem nativa do iOS , o Objective-C. Nos casos dosmotores gráficos desenvolvidos em C ou C++, e uma vez que essas linguagens sãosubconjuntos do Objective-C, essa compatibilidade estará desde logo garantida.

• Sistemas de rendering: A possibilidade de escolher entre vários subsistemas derendering, como o OpenGL e DirectX, é uma mais valia que deve ser tida em contana avaliação das diferentes alternativas.

• Outros subsistemas de jogo: A inclusão de outros subsistemas de jogo, como físicae audio, é um critério de menor importância relativamente aos restantes mas quedeve estar presente no processo de decisão. Apesar de não ser obrigatório a inclusãode tais subsistema, é fundamental que existam pelo menos alternativas compatíveis.

• Compatibilidade software de modelação: Um jogo 3D é composto por vários ar-tefactos de entre os quais se destacam os modelos 3D (criados em software própriopara o efeito). A quantidade de formatos que podem ser importados pelo motor grá-fico é mais uma componente na apreciação global. A compatibilidade com softwarede modelação é um ponto a ter em conta pois permite agilizar o desenvolvimentode aplicações no contexto da Gema Interactive Media. Actualmente, os programasmais usados são o 3D Studio Max e o Cinema 4D. Ambos têm a possibilidade de ex-portar os respectivos modelos para o formato FBX. Este formato é bastante utilizadoe muito flexível. Nele podem estar embutidos, para além da geometria do modelo,as respectivas texturas e animações. O Unity3D lida bastante bem com vários for-matos, incluindo .3ds e .c4d. Permite, inclusivé, editar directamente o modelo nosoftware de modelação e ver as alterações automaticamente dentro do Unity3D.

• Documentação disponível: Só é possível tirar o máximo partido de um motor grá-fico quando existe boa documentação.

• Preço: Por último, o valor a pagar pelo software é um critério importante na escolhado motor gráfico.

É com base nestes parâmetros que será determinado o valor de cada uma das alterna-tivas pré-seleccionadas. Depois de realizada essa avaliação, é tomada a decisão de qualdelas está melhor preparada para o trabalho que se pretende realizar.

2.1.1 Unity3D

O Unity3D é uma ferramenta muito completa para o desenvolvimento de jogos 3D eque foi desenhada para a criação de gráficos de alta qualidade. O seu desenvolvimentocomeçou em 2001 pela Unity Technologies e desde então várias versões foram surgindo no

6

Estado da Arte

mercado. Ao longo do tempo foi ganhando reconhecimento que resultou na obtenção devários prémios internacionais, de entre os quais, no contexto desta dissertação, se destacao “Best Use of Mac OS X Graphics - Apple WWDC 2006” [Uni11d].

Distingue-se dos restantes sistemas descritos neste documento por incluir um vastoconjunto de funcionalidades muito além de um simples motor gráfico. De facto, o Unity3Dé um espaço de desenvolvimento que integra todas as ferramentas necessárias para a im-plementação de um jogo 3D com gráficos de elevada qualidade[Uni11c]. A partir do edi-tor integrado, é possível criar todos os cenários e posicionar os objectos que vão povoar omundo dentro da aplicação. Isto permite ter um feedback imediato e uma representaçãoexacta do que será visto em runtime.

O Unity3D disponibiliza uma série de motores que visam acelerar o desenvolvimentode jogos em três dimensões. Um dos mais importantes é o motor de física PhysX que,sem grande esforço adicional, faz com que todos os objectos de um cenário reajam às leisda física. Inclui também um motor de audio capaz de reproduzir sons em 3D e váriosmétodos para a criação de aplicações multi-jogador [Uni11f, Uni11a].

Figura 2.1: Editor 3D do Unity

Uma das principais características que o diferenciam da maior parte dos motores é apossibilidade de desenvolvimento para múltiplas plataformas e dispositivos. É até pos-sível criar um jogo para a Web com características e desempenho tipicamente esperadosapenas em ambientes desktop. Um exemplo está disponível em [Uni11b], sob a formade um jogo que em fullscreen facilmente se confunde com uma aplicação nativa a serexecutada directamente pelo sistema operativo. A possibilidade de exportar o jogos 3Dcriados para diferentes targets faz parte do tema desta dissertação e, no caso da web, uma

7

Estado da Arte

mais valia para a Gema Interactive Media, a empresa onde foi desenvolvido o projecto.O Unity3D cumpre com distinção esse requisito já que permite o desenvolvimento paradiferentes plataformas, tais como Windows, Mac OSX, iOS e Android [Uni11g].

A versão base do Unity3D é gratuita mas não inclui algumas funcionalidades presentesna versão profissional. As mais marcantes são [Uni11e]:

• Video playback e Streaming: É de grande interesse ter a possibilidade de integrarvídeo com os jogos 3D para apresentação de diversos tipos de conteúdos previa-mente produzidos em software de edição de vídeo.

• Splash screen predefinido: Só na versão profissional é possível retirar ou persona-lizar a janela que é apresentada no início da aplicação.

• Optimização do tamanho da aplicação: Esta optimização consiste em retirar par-tes do motor que não estão a ser usadas diminuindo assim o tamanho do projecto.Esta funcionalidade só é aplicável à versão iOS.

• Efeitos Render-to-texture: A capacidade de utilizar render-to-texture significa queé possível criar uma textura dinâmica. Ou seja, é possível criar uma textura a partirda imagem captada por uma câmara e ainda permite a criação de água com reflexõese refracções em tempo real.

• Occlusion Culling: Está descrito no site do Unity3D , e na definição standard deocclusion culling, como uma solução incorporada no motor que evita o renderingde objectos invisíveis à câmara, mesmo que estejam dentro da área definida pelofrustum diferenciando-se assim do Frustum Culling.

• Sombras em tempo real: Embora não estando disponíveis para os sistemas iOSe Android, a utilização de sombras em computadores Windows e Mac é um factorimportante para o realismo de uma cena.

• Profiler: É uma ferramenta indispensável na optimização de um jogo. Permitemonitorar vários aspectos relativos à utilização do CPU, memória e rendering.

• Restrições de licenciamento: A versão gratuita não pode ser licenciada por empre-sas com volume de negócios superior a US$100 000 no seu último ano fiscal.

Só é possível tirar partido destas funcionalidades mediante a compra de uma licençaprofissional e que, no início de Fevereiro de 2012, podia custar até US$5.000.

Para concluir, resta dizer que o Unity3D apresenta-se como uma alternativa de pesona escolha de um motor gráfico, não só pela portabilidade que o caracteriza, mas tambémpor todas as facilidades que oferece na criação e implementação de conteúdos 3D.

8

Estado da Arte

2.1.2 OGRE

O acrónimo OGRE significa Object-Oriented Graphics Rendering Engine e, tal comoo nome indica, trata-se exclusivamente de um motor gráfico. Não tem, portanto, outrossubsistemas tais como motor de física e de audio. O projecto nasceu em 1999 pela mão deSteve Streeting mas só dois anos mais tarde, em 2001, surgiram os primeiros resultadosque permitiram ao OGRE afirmar-se como uma alternativa aos restantes motores gráficos[Wik11]. Desde o seu aparecimento foram produzidas várias alterações e lançadas versõescom melhoramentos e novas funcionalidades. Até à data, a versão estável do OGRE é a1.7.2 estando a 1.8 a ser preparada e já disponível para download.

É importante referir que o OGRE é apenas e só um motor gráfico. Com referido an-teriormente, não inclui, na sua base, outros sistemas quase sempre presentes em softwarede desenvolvimento 3D, como motores de física, audio, rede, etc. Existem no entantovários suplementos que podem ser usados para ultrapassar essas necessidades mas queoficialmente não fazem parte do motor original. Pode pensar-se que a não inclusão des-ses subsistemas é um ponto fraco do OGRE, o que não é necessariamente verdade. Porser exclusivamente um motor de rendering não impõe quaisquer restrições à escolha demotores externos. Esta flexibilidade é um factor a ter em conta para esta dissertação, poisa disponibilidade do hardware nos vários dispositivos pode exigir soluções adaptadas acada caso.

Desenvolvido na totalidade em C++, o OGRE consegue chegar às plataformas maisimportantes, o Windows, Mac OS X e Linux. Tem também vários templates com projectospara os IDE mais conhecidos, como, por exemplo, o Visual Studio.NET e o Xcode. Estasduas características são bastante úteis porque não restringem o programador a um ambi-ente de desenvolvimento e garantem que os resultados são iguais independentemente daplataforma à qual se destina o produto final.

A versão 1.7 trouxe uma novidade e que representa um avanço para os que desenvol-vem nesta tecnologia: a possibilidade de compilar os seus jogos para dispositivos com oiOS , nomeadamente, o iPhone , iPad e iPod . Também está a ser desenvolvido, emboranão oficialmente, o suporte para o sistema operativo Android. Este avanço coloca o OGREcomo uma hipótese que deve ser explorada no âmbito desta dissertação.

Além de ser um motor livre e open-source, conta com uma comunidade online ondeé possível obter muitos exemplos demonstrativos das capacidades deste motor. É fácilencontrar vários livros e e-books dedicados ao OGRE e que dão uma explicação detalhadasobre a sua arquitectura e funcionamento.

Já foi referida anteriormente a independência conseguida pelo OGRE relativamentea motores externos. Na verdade, essa flexibilidade está presente em toda a sua estruturae permite personalizar vários subsistemas como o gestor do grafo de cena OctreeScene-Manager. Isto só é possível devido à arquitectura do OGRE, fortemente orientada para a

9

Estado da Arte

Figura 2.2: Pequeno exemplo desenvolvido em OGRE 3D

utilização de plugins. Esses plugins são blocos de código pré-compilados que podem seranexados em runtime para desempenhar tarefas específicas e controlar diferentes aspectosdo motor gráfico.

2.1.3 Irrlicht Engine

O Irrlicht Engine é mais uma alternativa para a escolha de um motor gráfico. Come-çou a ser desenvolvido por Nikolaus Gebhardt em 2003 mas já conta com uma equipaconstituída por vários programadores. Tal como no caso do OGRE, é apenas um motorgráfico tratando exclusivamente do rendering de uma cena. Sem física, audio e outroscomponentes tão esperados em conteúdos 3D. É importante referir que contém na suabase um sistema básico para detecção de colisões e mouse picking, mas o seu uso é desa-conselhado por não ter as características de um motor próprio para o efeito. O Irrlicht foiusado em vários projectos comercias, tais como o Lex Venture e o H-Craft Championship,bem como muitos outros livres ou open-source.

Suporta seis subsistemas de rendering, como o DirectX e o OpenGL, dos quais doissão por software de forma a garantir que é sempre possível mostrar algum conteúdo,mesmo quando os mais importantes não estão disponíveis. Por esta razão, e aliada aofacto de ser implementado em C++, o Irrlicht pode ser usado em múltiplas plataformas,

10

Estado da Arte

tal como os seus concorrentes. Recentemente foi adaptado para correr no iPhone havendojá exemplos no site oficial e inclusivé na AppStore.

As funcionalidades presentes neste motor aproximam-no mais do OGRE do que dosrestantes. No entanto, a arquitectura do Irrlicht, ao contrário da arquitectura do OGRE, éfrequentemente descrita como pouco flexível e de difícil estensão. Não é fácil reunir argu-mentos para justificar esta afirmação pois todas as opiniões encontradas na internet vêmde fóruns e páginas pessoais. Embora não tendo dados concretos, verifica-se uma tendên-cia em classificar o OGRE como um sistema mais maduro e bem desenhado relativamenteao Irrlicht Engine.

Figura 2.3: Editor 3D do Irrlicht

2.1.4 ShiVa3D

Em 2003, Philip Belhassen e Nicolas Peri deram início à Stonetrip, a empresa francesaresponsável pelo desenvolvimento do ShiVa3D, um motor de jogo capaz de criar todoo tipo de aplicações multimédia em três dimensões. O objectivo principal de Philip eNicolas consistia na criação de uma solução completa para a implementação de vídeosjogos multi-plataforma. É com este intuito que dão início ao seu projecto que já contacom mais de oito mil aplicações e trezentos jogos.

11

Estado da Arte

Figura 2.4: Editor 3D do Shiva

O ShiVa3D é mais do que um motor gráfico. Tal como já foi referido, trata-se de ummotor de jogo que coloca à disposição sistemas de partículas, física, audio, entre outrasfuncionalidades. Consiste num pacote de seis ferramentas das quais se destacam duas:

• ShiVa Editor: É o editor do mundo e onde estão concentradas todas as funcionali-dades para o desenvolvimento da aplicação, desde materiais, animação e programa-ção da lógica do jogo.

• ShiVa Authoring Tool: É aqui que, uma vez criado, o jogo é exportado para asdiversas plataformas à escolha.

O conjunto de plataformas que são suportadas pelo ShiVa3D é bastante abrangente.Para além de chegar às mais importantes, como o Windows, Mac OSX e Linux, chegatambém ao iPhone , iPad , Android e Palm . Além destas, estão prometidas para breveno seu site oficial as plataformas Wii, PSP e PS3. Um facto que merece especial destaquenesta aplicação é a enorme simplicidade de exportação para o iPhone .

Apesar destas vantagens, o ShiVa3D impõe restrições ao ambiente de desenvolvi-mento. Essas restrições advêm do facto do ShiVa Editor estar disponível apenas parao Windows, o que significa que a criação de jogos para o iOS obriga o licenciamento dedois sistemas operativos, o Microsoft Windows e o Mac OSX.

O pacote completo de aplicações Shiva3D pode ser descarregado gratuitamente e portempo ilimitado desde que seja utilizado exclusivamente para aprendizagem. Para levantarestas restrições é necessário obter uma licença que varia entre os 169Ce os 1499C.

12

Estado da Arte

2.1.5 Análise comparativa

Depois de identificados os motores gráficos que reúnem os principais requisitos destadissertação, é tempo de os avaliar segundo os critérios já definidos e enunciados no iníciodeste capítulo. O resultado dessa avaliação tem como objectivo comparar cada uma dasalternativas e identificar a mais adequada para o trabalho aqui apresentado.

Com base na tabela anterior, é fácil concluir que o Unity3D é o motor que melhorse encaixa no âmbito desta dissertação. Quer pelas suas funcionalidades, quer pela suaportabilidade. Tem no entanto duas desvantagens importantes: não é possível exportar osjogos para Linux e o seu preço é significativamente maior que o das restantes alternativas.Estando o tema desta tese direccionado para os dispositivos móveis e havendo disponibi-lidade por parte da Gema Interactive Media em adquirir o Unity3D , as principais razõesque justificam a escolha são:

• Editor gráfico: O editor WYSIWYG facilita a configuração das propriedades dosobjectos e ajuda a criar cenas com mais realismo.

• Várias plataformas: É o motor que abrange o maior número de plataformas.

• Suporte profissional: O suporte especializado que é garantido pelos profissionaisdo Unity3D é uma segurança adicional.

Portar jogos desktop para dispositivos móveis apresenta vários desafios uma vez queesses dispositivos são máquinas com menor desempenho que os computadores desktop.Apesar disso, e ao contrário dos computadores tradicionais, proporcionam novas oportu-nidades de interacção com base em vários tipos de sensores, dando início à segunda partedesta dissertação.

2.2 Sensores

A proliferação dos meios tecnológicos registada nos últimos anos tem transformadoprofundamente o mundo em que vivemos. Desde ferramentas que nos ajudam a desem-penhar tarefas do quotidiano a simples objectos de entertenimento, é difícil, ou mesmoimpossível, encontrarmos uma área de actividade que não faça uso das mais recentes tec-nologias.

É cada vez mais fácil encontrar diversos tipos de sensores em diversos tipos de dis-positivos como, por exemplo, giroscópios, acelerómetros e multi-toque. Esta evoluçãotrouxe consigo novas oportunidades de interacção com os jogos e aplicações, resultandoem experiências mais ricas, mais próximas da realidade e mais fáceis de usar para o utili-zador final.

13

Estado da Arte

Tabela 2.1: Comparação entre os vários motores

Critérios Unity3D OGRE Irrlicht Engine ShiVa3DPlataformasLinux - sim sim simMac OSX sim sim sim simWindows sim sim sim simiOS sim sim sim simAndroid sim - - simPalm - - - simPlaystation 3 sim - - -PSP sim - - -Xbox 360 sim - - -Wii sim - - simWeb sim - - simObjective-C(a) sim sim sim simRenderingOpenGL sim sim sim simOpenGLES sim sim sim simSoftware Rendering - - sim -MotoresFísica sim - - simÁudio sim - - simRede sim - - simModelos 3D(b)3D Studio Max sim sim sim simBlend sim sim sim simCOLLADA sim sim sim simMaya sim sim sim simDocumentação Completa Completa Completa RazoávelPreço 3 300C(c) 0C 0C 1 499C

(a) Possível através do uso de plugins.(b) Podem ser necessários plugins para exportação para outros formatos legíveis pelos motores.(c) O preço inclui apenas as licenças para Mac OSX, Windows, Android e iOS . Para as restantesplataformas é necessário entrar em contacto com a Unity Technologies.

14

Estado da Arte

Dentro deste contexto nasce um novo desafio para as empresas e programadores: con-seguir adaptar os seus jogos e conteúdos interactivos à vasta gama de sensores existen-tes. A reprogramação de jogos para contemplar cada sensor é uma medida a evitar, poisimplica a perda de tempo que poderia ser gasto em melhorar a sua qualidade e funcio-nalidades. E tendo em conta o elevado número de sensores disponíveis, escrever códigoespecífico para cada situação pode simplesmente não ser viável.

É este problema que a segunda parte desta dissertação pretende resolver. O principalobjectivo consiste em desenvolver uma framework que seja multiplataforma e que trans-forme em acções os valores lidos pelos sensores. Desta maneira a lógica de um jogopode estar orientada às acções do jogador, sem a preocupação de conhecer o estado de umcontrolador num determinador instante de tempo. Espera-se que em virtude desta novaabordagem seja possível escolher qual o dispositivo de entrada (rato, teclado, joystick ,etc) sem alterar uma única linha de código.

2.2.1 Jogos com utilização de sensores

Com o aparecimento de dispositivos com vários sensores incorporados, as lojas virtu-ais de jogos foram aumentando a sua oferta. Em muitos deles verifica-se que recorrem aossensores para gerar acções. A seguinte lista de jogos consiste num conjunto de exemplosque usam esta nova forma de interacção.

2.2.1.1 Labyrinth 2

O Labyrinth 2 é uma aplicação móvel que consiste em percorrer um labirinto comuma esfera. Durante o caminho, existe uma série de obstáculos, como paredes e buracos,que dificultam a tarefa do jogador. O principal destaque deste jogo vai para a forma comoo utilizador interage com o labirinto. Inclinando o dispositivo influencia o trajectória dabola, simulando a força da gravidade.

2.2.1.2 Doodle Jump

O Doodle Jump é um jogo de plataformas para dispositivos móveis. A diferença rela-tivamente aos jogos tradicionais de plataformas é que o controlo também é feito atravésdo giroscópio. A inclinação do aparelho é que determina a velocidade horizontal do per-sonagem. Ao longo do jogo existe um conjunto de bónus e armadilhas que tornam o jogomais emocionante.

2.2.1.3 Cut the rope

Bastante conhecido na AppStore, o Cut The Rope é um jogo de estratégia que desafia ojogador a levar uma bola ao ponto de destino, onde está um sapo preparado para a comer.

15

Estado da Arte

Figura 2.5: Labyrinth 2

Figura 2.6: Doodle Jump

16

Estado da Arte

Neste caso, a interacção é feita através do toque e muito intuitiva. O dedo do participantetem a propriedade de conseguir cortar uma série de cordas. Fazendo um gesto de corte, épossível desfazer várias cordas que culminam no comprimento dos objectivos.

Figura 2.7: Cut the rope

2.2.1.4 WiiSports

Não sendo apenas um jogo, mas um conjunto de jogos, destaque-se principalmentepela forma de interacção. Em cada um desses jogos, cada um deles com diferentes ob-jectivos, é necessário que os participantes realizem uma série de gestos que simulem arealidade. O WiiSports é um bom exemplo de reconhecimento gestual através do uso degiroscópios.

2.2.2 Exemplos de dispositivos com sensores complexos

Nos últimos anos tem surgido uma novidade nos vídeos jogos que alterou significativa-mente a forma como os utilizadores interagem com os jogos. Ao contrário do tradicionalcomando composto por teclas direccionais e vários botões, é agora possível desempenharacções através de gestos. Os pontos seguintes são alguns exemplos desse tipo de soluções.

17

Estado da Arte

Figura 2.8: WiiSports

2.2.2.1 Kinect

O Kinect é um produto desenvolvido pela Microsoft para a Xbox 360 e apresenta vá-rios aspectos interessantes no que diz respeito a abstracção de acções. Baseia-se unica-mente numa câmara que capta os movimentos do jogador, permitindo que este controle einteraja com o ambiente. As acções são transmitidas através de gestos corporais e coman-dos de voz, o que oferece grande liberdade aos seus utilizadores. Com esta tecnologiaabandonam-se as tradicionais formas de interacção como comandos e joysticks.

Apesar de não ser uma solução genérica para abstracção de acções, já que interpretaapenas gestos e voz, é uma referência neste tipo de projectos. Começam a surgir biblio-tecas, como o OpenKinect, criadas com o objectivo de comunicar com o sistema Kinect eque podem revelar-se bastante úteis no decurso do trabalho futuro.

2.2.2.2 PlaystationMove

A tecnologia PlayStation Move, apresentada em 2 de Junho de 2009, é uma plataformade controlo sensível ao movimento. Criada pela Sony Computer Entertainment, tem ummodo de utilização semelhante ao concorrente Wii Remote, embora ofereça uma precisãobastante maior. A plataforma consiste numa câmara PlayStation Eye e um ou mais (até 4)comandos PlayStation Motion Controller que, em conjunto, conseguem determinar quala posição do jogador e detectar diferentes gestos ao longo do tempo.

A utilização da câmara é necessária para determinar a posição do comando. Duranteesse processo cada um dos comandos faz brilhar a esfera com uma cor distinta de todas as

18

Estado da Arte

Figura 2.9: Esquema representativo do funcionamento do Kinect

outras. O sistema PlayStation Move é também um bom exemplo de abstracção de acçõesporque as operações no jogos são executadas através de gestos e movimentos do MotionController. Tal como no caso do Kinect, não é uma solução genérica porque baseia-seexclusivamente na utilização dos comandos para interpretar acções.

2.2.3 Análise

Durante a pesquisa sobre o tema não encontrei nenhuma framework que estivessealinhada com os principais requisitos que foram propostos. Existem no entanto inúmerasbibliotecas que abstraem vários sensores permitindo ao programador escrever código nãoespecífico de uma plataforma em particular. Essas bibliotecas disponibilizam sob a formade uma API um conjunto de classes e métodos que permitem conhecer o estado de cadadispositivo ao longo do tempo. Esta abordagem não é diferente da que já é seguida naGema Interactive Media uma vez que continua a depender de código específico de cadacontrolador. O trabalho que se propõe é justamente desenvolver uma framework que estejade acordo com os requisitos já mencionados no início do capítulo.

2.3 Conclusão

Para introduzir o estado da arte foram definidos os critérios a serem usados para ava-liar as alternativas que de alguma forma se enquadram com o tema desta dissertação. De

19

Estado da Arte

Figura 2.10: Equipamento necessário para a utilzação do PlayStationMove

seguida foram apresentadas essas alternativas e identificadas as suas principais caracte-rísticas. A escolha do motor Unity3D resulta da análise dos prós e contras de cada plata-forma. O trabalho desenvolvido ao longo do próximo capítulo é apoiado por este motorde jogo, já que permite a junção das duas componentes desta dissertação nos dispositivoscom sistema operativo iOS. Conclui-se, também, que é mais proveitoso implementar umaframework de abstracção de sensores ao invés de utilizar uma já existente.

20

Capítulo 3

Framework para abstracção de sensores

No presente capítulo é abordado o trabalho desenvolvido após a análise do estado daarte, descrevendo em detalhe as suas aplicações práticas.

3.1 Introdução

Como já foi referido, o objectivo da segunda componente da dissertação é criar umaAPI que sirva de interface entre qualquer tipo de sensor e o input de um programa decomputador, libertando-o da dependência do teclado e do rato. O resultado obtido pre-tende dinamizar os métodos de input e tornar mais simples a adaptação de jogos aos novosdispositivos e sensores que venham a aparecer no mercado.

3.2 Requisitos

Para reunir os requisitos da framework é necessário pensar em que situações esta émais frequentemente utilizada. Essa decisão influencia de forma significativa as vantagensque o sistema pretende oferecer e se será capaz de ultrapassar as dificuldades específicasde uma determinada área. Estando esta dissertação ligada ao desenvolvimento de jogosem dispositivos móveis, é natural que os requisitos tenham sido pensados especificamentepara esse propósito. São eles:

• Personalização XML: Deve ser possível alterar o comportamento do sistema atra-vés de um ficheiro XML e sem ser necessário recompilar a aplicação.

• Extensível: Nos casos em que é necessário adicionar novos dispositivos de entradaque ainda não estejam contemplados, é importante garantir que existe uma formafácil de os integrar no sistema.

21

Framework para abstracção de sensores

• Sistema de plugins: A framework deve implementar um sistema de plugins. Aprincipal vantagem é a possibilidade de inclusão, através do XML, de novos dis-positivos, filtros ou outras unidades de processamento de sinais. No iOS tal não épossível porque, até à data, a Apple não autoriza a utilização de dynamic libraries.

• Desempenho: O desempenho da framework tem obrigatoriamente de ser suficien-temente aceitável para não arruinar o resto da aplicação. Os jogos são um tipo deaplicação em que se verifica uma intensiva utilização dos recursos disponíveis, querem processamento, quer em memória. É um requisito fundamental porque se forignorado, pode tornar o sistema inutilizável em situações reais.

• Multiplataforma: Espera-se que esta framework consiga chegar ao maior númerode dispositivos e sistemas operativos. É necessário algum cuidado no que diz res-peito à escolha de bibliotecas externas para que essas dependências não criem fac-tores de exclusão. A linguagem escolhida é C++ por ter grande abrangência.

3.3 Arquitectura

A arquitectura da framework , representada na figura, pode ser descrita como umconjunto de passos a serem executados dentro de um diagrama. O input esperado sãoos estados ou valores lidos dos dispositivos de entrada, que depois darão origem às ac-ções entretanto geradas pelos blocos. O desenho da arquitectura foi pensado de formaa garantir que fosse possível abranger o maior número de dispositivos e configurações.A principal vantagem desta implementação é a capacidade de manipular a estrutura deblocos, alterando o output de acções gerados pela framework . Na próximo ponto serãoanalisados os detalhes da implementação.

3.3.1 Diagrama

O diagrama é a estrutura principal que alberga todos os componentes que irão proces-sar os sinais dos dispositivos de entrada. O seu propósito é garantir que todos os blocossão processados pela ordem correcta. É através do diagrama que se criam as ligações en-tre os blocos. No final, são essas ligações que irão determinar em que iteração cada blocodeve ser executado.

3.3.2 Blocos

Os blocos são os componentes que integram um diagrama e, em conjunto, produzemas acções que vão sendo identificadas. Na sua forma mais simples limitam-se a ler dadosdos blocos anteriores e, de seguida, a emitir dados para os blocos seguintes. Durante estepercurso, e com base nos valores trocados entre eles, é que podem surgir as acção que vão

22

Framework para abstracção de sensores

Figura 3.1: Visão geral da arquitectura

servir de output da framework . Os blocos não são executados todos ao mesmo tempo. Aordem de execução é ditada pelo esquema de ligações.

A cada um dos blocos é associada uma iteração. Ou seja, a cada iteração, existe umconjunto de blocos a serem executados. O método utilizado para construir o mapa deassociações é bastante simples. Os passos são os seguintes:

• Blocos sem ligações de entrada são colocados na 1ª iteração.

• Se um bloco está na iteração i, então os blocos acessíveis através das ligações desaída estão na iteração i + 1.

Qualquer mudança aplicada à estrutura do diagrama exige que este algoritmo volte aser aplicado. O objectivo é que as associações bloco / iteração reflictam o novo estado dodiagrama.

Dentro de cada iteração os blocos são executados sem uma ordem definida e, pordefeito, sequencialmente. Isto significa que um bloco só começará o seu processamentodepois de todos os anteriores terminarem os seus. Isto levanta o problema de reduzir autilidade da framework . Blocos que gastem demasiado tempo a interpretar sinais, algobastante comum em situações deste género, vão atrasar o trabalho dos restantes quando,talvez, nem era preciso. Por essa razão, e se assim o pretenderem, os blocos podemexecutar o seu processamento em paralelo, utilizando threads.

23

Framework para abstracção de sensores

3.3.3 Acções

As acções são o único output da framework e o resultado de todo o processamentoprévio desencadeado pelos blocos no diagrama.

Existem dois tipos de acções: as simples e compostas. As simples são indivisíveis eforam geradas unicamente a partir dos sinais de entrada. As compostas, por outro lado,são todas aquelas que têm por base outras acções, sejam elas simples ou compostas.

Um exemplo bastante demonstrativo destes dois conceitos pode ser encontrado emaplicações multi-toque. No contexto desta eventual aplicação, é possível classificar umtoque na superfície como uma acção simples. No entanto, a acção de zoom, realizadacom dois dedos é classificada como uma acção composta, pois, na sua origem, estão duasacções simples. Na prática, a diferença mais marcante entre as duas é que no caso dasacções compostas existe uma LinkedList<Action *> com todas as acções que serviramde base para a sua criação. As classes seguintes servem justamente para representar estasituação:

Figura 3.2: Hierarquia de acções

Segundo este modelo é fácil perceber que é possível ignorar se a acção é simples oucomposta, uma vez que ambas são do tipo IAction. Esta abstracção permite ao progra-mador orientar o seu código aos acontecimentos e, quando necessário, obter informaçõesmais detalhadas sobre os mesmos.

Cada instância de IAction tem uma propriedade que identifica o tipo de acção, como,por exemplo, Jump. Esta propriedade, uma string, vai determinar quais os IActionListe-ners que serão notificados quando ocorrer uma acção deste tipo.

A utilização de uma árvore para organizar as acções nasce com um único propósito:criar uma hierarquia de tipos, dotando a framework de maior flexibilidade. O exemploseguinte mostra uma possível estrutura:

24

Framework para abstracção de sensores

Figura 3.3: Possível estrutura da árvore de acções

25

Framework para abstracção de sensores

O que isto significa é que a acção do tipo Jump é também do tipo Translate e, con-sequentemente, do tipo RootAction. De notar que todas as acções, sem excepção, sãoobrigatoriamente do tipo RootAction. Esta estrutura permite, por exemplo, que um IActi-onListener fica à espera de acções do tipo Translate, sendo notificado sempre que ocorrerum Jump, Left ou Right.

3.3.4 Mensagens

Os blocos, como entidades independentes que são, não têm conhecimento da estru-tura que os rodeia. Este facto implica que sejam desenvolvidos para enfrentarem e fun-cionarem em situações potencialmente desconhecidas. Não sabendo quais os vizinhospresentes no diagrama, levanta-se um problema que precisa de ser resolvido, sob pena delimitar a flexibilidade da framework : Como comunicar entre blocos independentementeda configuração do diagrama? É neste contexto que surgem as mensagens.

As mensagens são mecanismos de controlo que permitem alterar o funcionamento deum diagrama a qualquer instante. Viajam sob a forma de eventos que podem ser difun-didos a todos os blocos, ou parte deles, para que sejam notificados de acontecimentosimportantes. Por exemplo, imagine-se que numa determinada configuração, um dos com-ponentes do diagrama pretende reinicializar e descartar todas as acções candidatas a ac-ções complexas. Segundo o protocolo (ver mais abaixo), o bloco deve enviar a mensagemForget, que serve justamente para esse propósito. Não sendo possível forçar que todosos blocos esqueçam, de facto, as suas possíveis acções compostas, é da responsabilidadedos mesmos que implementem o protocolo e, quando sinalizados, executem a respectivaordem. Não o fazer significa que o bloco não está de acordo com o protocolo e a suainclusão pode resultar no mau funcionamento do sistema.

É importante verificar que o sistema de mensagens não segue o padrão Publish / Subs-cribe. Nem faria sentido que o seguisse porque as mensagens, na sua maioria, devemchegar a todos os destinatários. Recorrendo novamente ao exemplo anterior, a mensagemForget não poderia ficar por entregar.

3.3.5 Protocolo

A introdução das mensagens trouxe uma necessidade de uniformizar os acontecimen-tos e pedidos mais comuns. Um protocolo desconhecido não tem valor uma vez que osprogramadores dos blocos não sabem que mensagens podem esperar, e, naturalmente,não reagirão em conformidade. A definição de um protocolo apresenta-se como umaalternativa viável para tornar públicos quais os acontecimentos chave da framework .

Pela importância demonstrada na parágrafo anterior, é altamente recomendado quetodos os blocos sejam desenvolvidos em concordância com o sistema de mensagens.

Actualmente estão definidas cinco mensagens:

26

Framework para abstracção de sensores

Figura 3.4: Mensagems

27

Framework para abstracção de sensores

• Clear - esta mensagem tem como principal objectivo apagar descartar todas as ac-ções, simples ou compostas, de todos os blocos;

• Forget - a mensagem Forget avisa os destinatários que devem esquecer o contextoem memória que servirá de base para gerar acções complexas;

• StopActions - os blocos que receberem esta mensagem devem parar de emitir ac-ções;

• StartActions - reactiva novamente a emissão de acções;

• Message - mensagem genérica que pode transportar dados. Serve essencialmentepara criar um canal de comunicação entre um ou mais blocos;

Um aspecto negativo relativamente à adopção de um protocolo é a possibilidade deserem acrescentadas mensagens em novas versões da framework , correndo o risco dosblocos mais antigos, entretanto obsoletos, serem incompatíveis com as novas versões.

3.4 Implementação

A linguagem de desenvolvimento escolhida foi o C++. As razões que justificam estaopção são:

• Multiplataforma: É a linguagem de programação mais compatível entre todos ossistemas operativos, especialmente em dispositivos móveis (Android e iOS).

• Compatível com o Unity3D : Uma vez que o Unity3D foi o motor gráfico escolhido,seria benéfico experimentar a framework num jogo desenvolvido nesta plataforma.Como já foi referido, a utilização de plugins no Unity3D só é possível se estes foremimplementados em C, C++ ou Objective-C.

3.4.1 Tecnologias

A implementação da arquitectura apresentada no capítulo anterior foi conseguida atra-vés de um conjunto de tecnologias que melhor se apresentavam para a conclusão do traba-lho proposto. Embora existam outras alternativas, bastante interessantes para o projectoem causa, as que foram utilizadas são descritas de seguida:

• Xcode: A framework foi criada utilizando o Xcode, da Apple. Esta ferramenta,muito direccionada para o desenvolvimento de aplicações iOS e MacOSX, está dis-ponível gratuitamente para download a todos os membros do programa de desen-volvimento da Apple. Uma vez que a Gema Interactive Media está já inscrita nessemesmo programa, o uso desta aplicação não acarreta custos adicionais.

28

Framework para abstracção de sensores

• Linguagem C++: A linguagem escolhida foi o C++. Esta linguagem é suportadapor quase todos os sistemas operativos actuais, razão que faz do C++ muito versátil.Desta forma, um dos principais requisitos, ser multiplataforma, fica assegurado.Acresce ainda o facto de fazer parte do Objective-C, linguagem nativa do iOS .

3.4.2 Classes principais

3.4.2.1 InputSystemRoot

Toda a framework está contida na class InputSystemRoot. É através dela que se podeconfigurar todo o sistema e onde todas as funcionalidades são acessíveis. É expectávelque várias camadas de uma aplicação necessitem de aceder à framework , quer para re-gistar IActionListeners, quer para inserir qualquer tipo de input. É importante referir queexiste apenas uma única instância de InputSystemRoot, o que significa que a referênciapara tal objecto teria de ser passada para os níveis mais baixos de toda a arquitectura. Anatureza desta situação enquadra-se no singleton pattern, um modelo de desenvolvimentoque contempla uma única instância de uma class e que ao mesmo tempo é global e aces-sível em qualquer parte da aplicação. A desvantagem que advém deste modelo, por vezesconsiderados como anti-pattern, é que cria uma certa dependência à framework já quefica mesclada com grande parte do projecto. A vantagem, por outro lado, é que facilita asua utilização, tornando mais confortável a abstracção de sensores.

3.4.2.2 Diagram

Como foi referido no ponto anterior, a globalidade da framework está encapsuladadentro da class InputSystemRoot. Esta class contém um membro, do tipo Diagram, queé o motor responsável pela geração de ciclos completos, desde a entrada de input, até aooutput, ou seja, as acções.

3.4.2.3 DiagramConnection

Uma vez dentro do diagrama, os blocos só realizam trabalho útil se estiverem ligadosuns aos outros. Essas ligações têm um propósito simples: criar uma estrutura partilhadapor ambos os blocos onde o emissor adiciona um valor que estará imediatamente dispo-nível no receptor na iteração seguinte. A figura 3.5 mostra precisamente essa situação.A estrutura de dados que mais se adequada a esta ligação é uma queue. Por isso, quandoum bloco emite um valor por um dos seus canais de saída, está a adicionar esse mesmovalor ao fim da fila em DiagramConnection. O bloco seguinte, o receptor, retira, casoexistam dados disponíveis, o elemento que se encontra na cabeça da fila. Desta forma,garante-se que a ordem pela qual os valores foram enviados é igual à ordem em que vãoser recebidos.

29

Framework para abstracção de sensores

Figura 3.5: Demonstração de IConnection

3.4.2.4 IConnectionData

Durante um ciclo, os blocos podem gerar informação que será transmitida através dosseus canais de saída. Essa informação tem de ser suficientemente genérica para represen-tar qualquer tipo de dados, sejam eles primitivos ou instâncias de classes. Numa primeiraaproximação. Como já foi referido em cima, uma ligação entre dois blocos pode ser vistocomo uma fila. Assim sendo, sempre que um bloco envia um pacote para outro, está, nofundo, a adicioná-lo à cauda da fila do bloco seguinte. Como as filas são uma estruturade dados de um só tipo, isto é, todos os items tem de ser do mesmo tipo, levanta-se umaquestão. Se a ligação entre blocos só pode transmitir um tipo de dados, como fazer paraenviar diferentes valores e objectos? Existem linguagens em que qualquer variável é umainstância de um tipo geral e que abrange todas as classes do sistema. O Objective-C éuma dessas linguagens, isto é, qualquer objecto é filho de NSObject. Se esta situação severificasse no C++, bastaria generalizar o tipo de dados a serem trocados como sendoNSObjects. No entanto, essa não é uma possibilidade real pois, como sabemos, os tiposprimitivos, como int ou float, não são sequer objectos. A solução para este problema con-siste em criar uma interface IConnectionData que, se implementada, torna as instânciasdessa class passíveis de serem transmitidas entre blocos. Esta interface não contém méto-dos, servindo exclusivamente para abstrair o tipo de dados que são enviados ou recebidos.Desta forma, é possível criar classes para cada tipo de dados primitivos e que guardarãoo seu respectivo valor.

3.4.2.5 Árvore de acções

As classes que implementem a interface IActionListener são classes que podem sernotificadas que uma acção de um determinado tipo foi desencadeada. Este modelo, co-nhecido como Publish / Subscribe pattern, faz a ponte entre a framework e a aplicaçãoque se está a desenvolver. A estrutura em árvore que representa o conjunto de acçõesdisponíveis, e a forma como se relacionam, foi escolhida com base em dois pontos funda-mentais. Por um lado, permite que seja possível ficar à espera de um tipo mais genéricode acção. Recorrendo ao exemplo da figura 3.3, um IActionListener pode aguardar queocorra a TranslateAction, que por sua vez será desencadeada sempre que JumpAction,LeftAction ou RightAction for detectada. Por outro lado, é fácil determinar os nós pai de

30

Framework para abstracção de sensores

uma determinada acção. Basta percorrer a árvore ascendentemente para retirar a lista dasacção mais genéricas de uma determinada acção.

Esta alternativa permite olhar para as acções como uma estrutura organizada e fle-xível. Em vez de estarem isoladas umas das outras, armazenadas, por exemplo, numaLinkedList, passam a estar categorizadas conforme o tipo a que pertencem.

Pelas razões expostas, também seria admissível pensar na estrutura das acções comoum grafo mais genérico, ao invés de uma árvore (um caso particular de grafo). Nessasituação, as acções não teriam pais nem filhos mas antes vizinhos. A razão pela qual nãofoi escolhida esta opção é que torna demasiado complexa a tarefa de determinar de quetipos mais abrangentes é uma dada acção. Recorde-se que, no caso de uma árvore, bastapercorrer os nós pai até ao nó raiz para se conhecerem os tipos anteriormente referidos.

3.4.2.6 Threads

Os dispositivos de entrada têm diferentes necessidades de processamento. A naturezade cada um deles influencia significativamente o tempo que demoram a interpretar acções.Por exemplo, um comando constituído apenas por botões tem, tipicamente, um delaybastante mais curto que uma câmara / entrada de vídeo. Se o diagrama não for capaz deexecutar os blocos com multiprocessamento, então a latência da framework nunca seráinferior à soma do tempo de processamento de todos os blocos. Pelas razões apresentadasanteriormente, nomeadamente pela rapidez exigida à solução, é imperativo que os blocos,se assim o exigirem, possam ser executados em threads diferentes. Por forma a evitar oprotelamento de um ciclo que aguarda o final de uma tarefa de um bloco, foi introduzida apossibilidade de cada IDiagramBlock pedir à framework que seja executado numa threaddiferente. Para esta funcionalidade havia duas maneiras de a implementar:

• Criação de threads serem criadas por cada bloco, ficando à sua responsabilidade asua correcta utilização e remoção.

• Inclusão de threads na framework . Basta que os blocos que necessitem de proces-samento em paralelo o sinalizem devidamente.

A opção escolhida foi a segunda hipótese, baseando-se essencialmente em dois mo-tivos. A primeira razão é que torna a tarefa do programador significativamente menoscomplexa. Deixa de ser necessário conhecimentos específicos sobre threads e reduz aprobabilidade de má gestão de recursos. Por outro lado, permite activar o modo multipro-cessamento de um bloco desenvolvido por terceiros, o que pode eventualmente resultarnuma melhoria de desempenho da globalidade do sistema.

31

Framework para abstracção de sensores

Figura 3.6: Utilização de threads

3.4.2.7 XML

A capacidade de ler diagramas em XML é um requisito fundamental da frameworkpois permite alterar o comportamento de uma aplicação sem necessitar de recompilação1.O conteúdo XML pretende ser uma representação fiel de um diagrama. É assim possívelserializar e deserializar uma instância de Diagram.

Exemplo de um possível ficheiro de entrada XML:

<?xml v e r s i o n = " 1 . 0 " e n c o d i n g =" u t f −8"?>< i n p u t s y s t e m >

< b locks >

<block ><name> touch </ name>< type > V i r t u a l J o y s t i c k B l o c k </ type >< c o n n e c t i o n s >

< c o n n e c t i o n o u t p u t C h a n n e l ="0"blockName =" i n v e r t "i n p u t C h a n n e l ="0" / >

< c o n n e c t i o n o u t p u t C h a n n e l ="1"blockName =" i n v e r t "i n p u t C h a n n e l ="1" / >

</ c o n n e c t i o n s ><params >

1Na verdade, existem algumas situações em que tal não é possível, tal como explicado no capítulo 5.

32

Framework para abstracção de sensores

< j o y s t i c k c e n t e r X ="10" c e n t e r Y ="20" r a d i u s ="30" / ></ params >

</ b lock >

<block ><name> i n v e r t < / name>< type > I n v e r t A x i s B l o c k < / type >

</ b lock >

</ b locks >

</ i n p u t s y s t e m >

Este exemplo representa um Diagram que contém apenas dois blocos. O primeiro,conhecido pelo nome touch, tem duas ligações de saída e ambas para o bloco invert.Os nomes utilizados no conteúdo XML não têm qualquer restrição e servem apenas parareferenciar blocos, sendo a propriedade <type> que indica a que class pertence. É aindapossível passar alguns parâmetros que podem ser acedidos a qualquer momento dentro daclass Block. A lista de <connection>, tal como o nome indica, contém a lista de ligaçõesde saída, e, para cada uma delas, a que bloco deve ser ligada.

3.4.3 Dependências

Para facilitar e acelerar a utilização da framework , é possível ler a configuração de umdiagrama a partir de um ficheiro XML. Com excepção de algumas situações, referidas nocapítulo de 5 Conclusões e trabalho futuro, é assim possível alterar o comportamento dosistema sem voltar a compilar toda a aplicação. Para o processamento de um documentoXML, foi utilizada a biblioteca libxml2, compatível com todos os ambientes de testeslistados no capítulo 5.

33

Framework para abstracção de sensores

34

Capítulo 4

Testes e resultados

Depois da utilização do Unity3D e a implementação da framework , é tempo de des-crever os testes a que foram sujeitos e os respectivos resultados. É justamente esse oobjectivo deste capítulo.

4.1 Introdução

Na apresentação da framework , foi referido que um dos seus objectivos principaisé ter uma baixa latência, tanto imperceptível quanto possível. Não é aceitável que estaabordagem introduza um atraso suficientemente grande ao ponto de não ser desprezávelaquando da implementação de um jogo. Para além de uma resposta rápida da framework, é igualmente importante que o consumo de memória mantenha níveis compatíveis comum ambiente de desenvolvimento 3D. Neste sentido, a framework criada foi sujeita a umabateria de testes para medir os tempos de resposta e a quantidade de memória utilizadaem diferentes situações.

4.2 Ambiente de testes

Os testes foram realizados em alguns dos ambientes mais relevantes do ponto de vistadesta dissertação. Uma vez que a única licença disponível no Unity3D é válida apenaspara dispositivos iOS, optou-se por escolher o seguinte conjunto de plataformas:

• MacBook ProProcessador: 2.66 Ghz Intel Core 2 DuoMemória: 4 GB 1067 MHz DD3Sistema Operativo: Mac OS X 10.7.2

35

Testes e resultados

• MacMiniProcessador: Intel Core 2 DuoMemória: 3 GBSistema Operativo: Mac OS X 10.7.2

• iPhone 4Processador: Apple A4 1 GHzMemória: 512 MBSistema Operativo: iOS 5.0.1

• iPad 1Processador: Apple A4 1 GHzMemória: 236 MBSistema Operativo: iOS 5.0.1

• iPad 2Processador: Apple A5Memória: 512 MBSistema Operativo: iOS 5.0.1

Todos os cinco ambientes anteriormente listados têm características diferentes. Obenefício esperado da realização dos testes num diversificado número de plataformas éo de conhecer melhor o comportamento da framework nos dispositivos para a qual foidesenvolvida.

4.3 Testes

Naturalmente que os valores de latência flutuam bastante entre sensores. O proces-samento de vídeo é intrinsecamente mais complicado que o processamento de sinais deuma dimensão como, por exemplo, o de um giroscópio. Dito isto, é fundamental definircomo serão realizados os testes de forma a obter exclusivamente os dados que permitamavaliar o impacto da framework e não o dos componentes interligados.

A inclusão de threads, discutida no capítulo 3, trouxe a capacidade dos blocos seremexecutados paralelamente, sem terem de esperar que os anteriores terminem o seu proces-samento. A aplicação de testes a esta funcionalidade tem como objectivo perceber se auso de threads é, ou não, uma mais valia.

Para testar o atraso introduzido pela framework , foi utilizado, para cada um dos am-bientes de teste listados, um método simples que consiste em dois passos. Uma vez quese pretende medir a latência, basta registar o tempo imediatamente antes de uma chamadaà framework , e substraí-lo ao tempo registado logo após o seu retorno.

36

Testes e resultados

Figura 4.1: Medição da latência

A framework foi compilada sob a forma de um plugin. Para a sua utilização dentro doambiente do Unity3D basta fazer uma única chamada à framework . Como a latência deum ciclo completo executado pela framework é demasiado pequena, esse valor torna-seimensurável pelos relógios que marcam o tempo decorrido entre o início e o fim dessachamada. Para tornar possível a medição desse tempo, são efectuadas cem mil chamadasconsecutivas à framework , e medido o tempo total dessas cem mil invocações. Destaforma é possível calcular o tempo médio por invocação, obtendo assim um valor aproxi-mado do atraso em que incorre uma chamada ao sistema de abstracção.

4.4 Resultados

Os resultados, reunidos na tabela 4.2, mostram que a utilização da framework nãoacrescenta uma latência que justifique ser considerada. Os tempos são, portanto, despre-záveis. Na tabela 4.2, estão os valores apurados para cada ambiente de teste:

4.5 Casos de estudo

Após a definição e implementação da framework descrita em mais detalhe ao longodo capítulo 3, deu-se início à sua integração em casos reais. A sua aplicação em projectosde valor comercial é mais uma forma de experimentar a solução proposta, verificando se,de facto, contribui significativamente para a criação de uma framework para abstracçãode sensores.

4.5.0.1 Super Bock Classic

Aquando do lançamento de uma nova cerveja, a Super Bock encomendou à empresaGema Interactive Media , um jogo que representava um simulador de aviões e que preten-dia recriar o anúncio televisivo da nova cerveja chamada Classic. O anúncio consistia emescrever, no céu, o nome da bebida, através do fumo expelido pelo avião. Deste modo, foicriado um simulador de aviões e o jogador tinha de atravessar um determinado númerode arcos até chegar à pista de aterragem. Quando o jogador batia nos arcos tinha uma

37

Testes e resultados

Figura 4.2: Resultado dos testes de latência para diferentes dispositivos (em micro-segundos)

penalização de um segundo. Se passava ao largo dos mesmos, tinha uma penalização dedez segundos. Quem fizesse o percurso em menos tempo, sairia vencedor.

Um dos requisitos do jogo era funcionar em Windows, iPad e iPhone e ser igual emtodas as plataformas para garantir a equidade do funcionamento do jogo. No final, ojogador fazia o registo, a fim de, eventualmente, se habilitar ao prémio.

Numa primeira fase, durante dois meses, o jogo esteve disponível nos principais hiper-mercados e posteriormente na AppStore e nas páginas da internet da Super Bock. O factode este jogo ser igual em todas as plataformas, consistiu na sua mais valia. Verificou-seuma adesão aceitável, a rondar os dois mil downloads e cerca de dez mil participações.

4.5.0.2 AngryBots

O AngryBots, jogo incluído com o Unity3D a partir da versão 3.4, é mais um exemplode uma criação da Unity Tecnologies nascida com o propósito de evidenciar as poten-cialidades do motor. A acção desenrola-se num ambiente de ficção científica e, o actorprincipal, o jogador, pode vaguear pelo cenário livremente, disparando contra alvos ini-migos. O controlo da personagem é feito através de dois joysticks virtuais, ou seja, pelotoque. O objectivo neste caso passa por reescrever o código que controla o jogador tendopor base a framework .

38

Testes e resultados

4.6 Considerações sobre o Unity3D

Apesar do Unity3D não estar sujeito a conjunto específico de testes, existem algumasconsiderações que importa reter:

• A relação entre draw calls e o número de polígonos é, na maioria dos casos testados,o grande factor de estrangulamento na rapidez da aplicação. A regra é muito sim-ples. Quanto menos draw calls e polígonos numa determinada frame, mais rápido éo seu processamento.

• O sistema GUI é apenas satisfatório na medida em que cumpre as funções essen-ciais. É possível criar todo o tipo de controlos, com mais ou menos programação,incluindo a utilização de vídeo. No entanto, e principalmente no caso da Gema In-teractive Media, seria bastante útil um suporte radicalmente diferente relativamenteaos conteúdos 2D. Era desejável que a componente 2D do Unity3D estivesse maispróxima de outras tecnologias como o Adobe® Flash®. Mas a verdade é que estefacto está longe da realidade, pelo que o sistema GUI do Unity3D , apesar de satis-fatório, não está de acordo com as expectativas.

• A função de Lightmapping é uma mais valia para o produto final. As diferençasvisuais antes e depois da aplicação desta função são abismais, e o impacto da suautilização é sempre positivo. Resta dizer que os 10% de realismo extra [Uni12],obtido na versão paga do Unity3D , não é sequer perceptível.

39

Testes e resultados

40

Capítulo 5

Conclusões e Trabalho Futuro

Neste último capítulo, são retiradas as conclusões resultantes do trabalho desenvol-vido, e analisadas algumas opções tendo vista uma continuação e trabalho futuro.

5.1 Conclusões

Nunca na história do desenvolvimento de jogos existiram tão boas condições comonos dias de hoje. O natural avanço das tecnologias cria, como sempre criou, óptimasoportunidades para ampliar a já grande oferta de entretenimento. A realização deste tra-balho é prova disso mesmo. O Unity3D é, de facto, uma enorme mais valia para atingirdiferentes targets, fazendo com que um só jogo para múltiplas plataformas seja uma re-alidade. A sua portabilidade e as inúmeras funcionalidades que servem as necessidadesdos criados de conteúdos 3D, quer programadores, quer designers, colocam o Unity3D navanguarda do desenvolvimento de jogos.

Já na segunda parte deste trabalho, a demonstração que é possível criar um métodopara generalizar o input das aplicações, é um passo em frente na reutilização de códigoe na diminuição dos tempos de implementação. Com esta opção, é virtualmente possívelcombinar qualquer dispositivo de entrada com qualquer jogo.

5.2 Trabalho Futuro

Ambos os temas objecto de estudo desta dissertação podiam ser melhorados. Essasmelhorias passam pela inclusão de novas funcionalidades e também pelo aumento dasplataformas de teste. Em seguida apresenta-se uma lista dos pontos prioritários no quediz respeito ao futuro deste trabalho.

41

Conclusões e Trabalho Futuro

Na primeira parte desta dissertação, dedicada à escolha de um motor gráfico paradispositivos móveis, poderia eventualmente ser valorizada investigando alguns destes tó-picos:

• Testar o Unity3D em Android e restantes plataformas:

Apesar do âmbito desta dissertação estar orientada para o sistema iOS, seria muitointeressante estender os testes do Unity3D para as restantes plataformas, especial-mente em Android. Infelizmente, é necessário o pagamento das respectivas licençaspara cada uma dessas plataformas, o que representa um elevado custo. Por esta ra-zão, os jogos foram apenas testados no iPhone / iPad . Os testes em Android são degrande relevância porque, ao contrário do iOS , corre em dispositivos com recursosmuito diferentes, já que está disponível numa variada gama de telemóveis e tablets.

Relativamente à segunda metade da dissertação, o trabalho futuro passaria por estudaros seguintes pontos:

• Definir melhor o Protocolo: O Protocolo é uma peça fundamental para um bomfuncionamento da framework , uma vez que é com base nele que é possível pautar ocomportamento do sistema como um todo. É claro que se for o mesmo programadora implementar todos os componentes, o respeito pelo Protocolo é, grosso modo, irre-levante. Mas o mesmo já não é verdade se o contexto for outro, como, por exemplo,numa grande equipa de programadores ou com blocos desenvolvidos por terceiros.A melhoria que aqui se propõe, é estender o tipo de mensagens admissíveis combase num estudo mais aprofundado das necessidades retiradas do quotidiano.

• Possibilidade de carregar plugins: Apesar do planeamento inicial prever o usode plugins para configurar o diagrama, tal não foi possível devido às regras im-postas pela Apple. Como se pode ler na documentação da AppStore, as aplicaçõesque utilizem código carregado em runtime serão rejeitadas sem qualquer excepção.Ficou, portanto, por incorporar esta funcionalidade que seria uma mais valia paraflexibilizar e melhorar o produto final. Tendo em conta os objectivos propostos, aconsequência mais penalizadora reside no facto de ser impossível acrescentar novosblocos sem recompilar a aplicação. Não sendo uma limitação técnica, não há nada afazer para ultrapassar o problema a não ser esperar que a Apple decida levantar estarestrição.

42

Referências

[Boo12] Boost. Boost c++ library, Janeiro 2012. http://www.boost.org/.

[Ges12] GestureWorks. Multitouch actionscript 3 library, Janeiro 2012. http://gestureworks.com/.

[Ope12] OpenKinect. Openkinect, Janeiro 2012. http://openkinect.org/wiki/Main_Page.

[TUI12] TUIO. Tuio, Janeiro 2012. http://www.tuio.org/.

[Uni11a] Unity3D. Unity 3 audio, Janeiro 2011. http://unity3d.com/unity/engine/audio.

[Uni11b] Unity3D. Unity 3 bootcamp, Janeiro 2011. http://unity3d.com/gallery/live-demos/index.html#bootcamp.

[Uni11c] Unity3D. Unity 3 engine features, Janeiro 2011. http://unity3d.com/unity/engine/.

[Uni11d] Unity3D. Unity 3 fast facts, Janeiro 2011. http://unity3d.com/company/fast-facts.

[Uni11e] Unity3D. Unity 3 license comparison, Janeiro 2011. http://unity3d.com/unity/licenses.

[Uni11f] Unity3D. Unity 3 physics, Janeiro 2011. http://unity3d.com/unity/engine/physics.

[Uni11g] Unity3D. Unity 3 publishing, Janeiro 2011. http://unity3d.com/unity/publishing/.

[Uni12] Unity3D. Lightmapping com iluminação global, Fevereiro 2012. http://unity3d.com/unity/licenses.

[Wik11] Wikipedia. Ogre, Janeiro 2011. http://en.wikipedia.org/wiki/OGRE.

[Wre12] WreckedGames. Object oriented input system, Janeiro 2012. http://www.wreckedgames.com/.

43

REFERÊNCIAS

44