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

(1)

F

ACULDADE DE

E

NGENHARIA DA

U

NIVERSIDADE DO

P

ORTO

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)

(2)

(3)

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

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)

(4)

(5)

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 dispositivos móveis mais capazes, como telemóveis e tablets, abrem a porta à criação de aplicações 3D bastante 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úblico alvo mais alargado. No entanto, esta expansão levanta novos problemas. É agora mais difícil abranger todos os sistemas operativos e sensores disponíveis, obrigando, quase sempre, a escrever código específico para cada situação. A solução consiste em encontrar ou desenvolver alternativas multi-plataforma para o motor gráfico 3D e para a camada de inputda aplicação.

(6)

(7)

Abstract

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

(8)

(9)

Conteúdo

1 Introdução 1 1.1 Contexto . . . 2 1.2 Problema . . . 2 1.3 Motivação e Objectivos . . . 3 1.4 Estrutura do documento . . . 3 2 Estado da Arte 5 2.1 Motores Gráficos . . . 5 2.1.1 Unity3D . . . 6 2.1.2 OGRE . . . 9 2.1.3 Irrlicht Engine . . . 10 2.1.4 ShiVa3D . . . 11 2.1.5 Análise comparativa . . . 13 2.2 Sensores . . . 13

2.2.1 Jogos com utilização de sensores . . . 15

2.2.2 Exemplos de dispositivos com sensores complexos . . . 17

2.2.3 Análise . . . 19

2.3 Conclusão . . . 19

3 Framework para abstracção de sensores 21 3.1 Introdução . . . 21 3.2 Requisitos . . . 21 3.3 Arquitectura . . . 22 3.3.1 Diagrama . . . 22 3.3.2 Blocos . . . 22 3.3.3 Acções . . . 24 3.3.4 Mensagens . . . 26 3.3.5 Protocolo . . . 26 3.4 Implementação . . . 28 3.4.1 Tecnologias . . . 28 3.4.2 Classes principais . . . 29 3.4.3 Dependências . . . 33 4 Testes e resultados 35 4.1 Introdução . . . 35 4.2 Ambiente de testes . . . 35 4.3 Testes . . . 36

(10)

CONTEÚDO

4.4 Resultados . . . 37

4.5 Casos de estudo . . . 37

4.6 Considerações sobre o Unity3D . . . 39

5 Conclusões e Trabalho Futuro 41

5.1 Conclusões . . . 41

5.2 Trabalho Futuro . . . 41

(11)

Lista de Figuras

2.1 Editor 3D do Unity . . . 7

2.2 Pequeno exemplo desenvolvido em OGRE 3D . . . 10

2.3 Editor 3D do Irrlicht . . . 11

2.4 Editor 3D do Shiva . . . 12

2.5 Labyrinth 2 . . . 16

2.6 Doodle Jump . . . 16

2.7 Cut the rope . . . 17

2.8 WiiSports . . . 18

2.9 Esquema representativo do funcionamento do Kinect . . . 19

2.10 Equipamento necessário para a utilzação do PlayStationMove . . . 20

3.1 Visão geral da arquitectura . . . 23

3.2 Hierarquia de acções . . . 24

3.3 Possível estrutura da árvore de acções . . . 25

3.4 Mensagems . . . 27

3.5 Demonstração de IConnection . . . 30

3.6 Utilização de threads . . . 32

4.1 Medição da latência . . . 37

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

(12)

(13)

Lista de Tabelas

(14)

(15)

Abreviaturas e Símbolos

3D 3 Dimensões

API Application Programming Interface CPU Central Processing Unit

iOS Sistema operativo criado pela Apple para dispositivos móveis OGRE Object-Oriented Graphics Rendering Engine

PSP PlayStation Portable

(16)

(17)

Capítulo 1

Introdução

Desde o seu aparecimento que os jogos têm vindo a marcar uma forte presença na sociedade 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 de conceitos e dinamização de marcas pois permitem aproximar e cativar potenciais alvos de negócio, sejam eles jogadores ou empresas. À medida que o hardware evoluiu, também os jogos acompanharam esse progresso tirando partido das capacidades dos processadores e placas gráficas que foram surgindo. O 3D emergiu, trazendo consigo novos ambientes e experiências ao utilizador final.

Mais recentemente, os telemóveis passaram de simples ferramentas do quotidiano para verdadeiras 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 fabricantes de dispositivos móveis criarem aparelhos com elevado poder de processamento e de os equiparem com vários tipos de sensores, abrindo novas oportunidades de interacção com as aplicações desenvolvidas. Estão assim reunidas boas condições para a produção de conteú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 empresa e que decorrem das constantes mudanças registadas no mercado tecnológico. O ramo das aplicações móveis está em forte crescimento exigindo uma actuação eficaz, capaz de satisfazer as expectativas dos clientes da Gema Interactive Media , quer pela sua abran-gência, quer pela qualidade das experiências proporcionadas. É neste contexto que surge esta dissertação.

(18)

Introdução

1.1 Contexto

Hoje em dia é muito comum recorrer a aplicações multimédia para promover even-tos, conceitos e produeven-tos, tais como mapas interactivos e superfícies multi-toque. São aplicações que pretendem causar um impacto imediato e captar rapidamente a atenção dos utilizadores. É por isso importante garantir que despertam a curiosidade do maior nú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 partilhadas por várias pessoas em simultâneo. Os computadores desktop têm vindo a desempenhar um papel fundamental neste tipo de iniciativas já que é neles que este tipo de aplicações sã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 recente aparecimento de dispositivos portáteis, como são os tablets, veio alimentar as expectati-vas que os utilizadores depositam neste tipo de iniciatiexpectati-vas. Ao contrários dos anteriores, estes dispositivos não obrigam a uma solução fixa num determinado espaço. Pelas suas características, é possível, por exemplo, dispersar uma solução interactiva por diferentes locais 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 interaccria-çã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ível deixar de lado os antigos ratos e teclados, substituídos pelos acelerómetros, giroscópios e ecrã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 os botõ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 interface de 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 esta evolução reúne, levanta, também, inúmeros desafios. É agora mais difícil conseguir lidar com 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, som e 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

(19)

Introdução

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

O trabalho a ser desenvolvido pode ser dividido em duas partes. A primeira parte consiste em estudar a viabilidade da utilização de um motor gráfico 3D em dispositivos móveis. Os computadores são máquinas bem mais capazes que este tipo de aparelhos o que significa que podem existir diferenças entre características de motores para PC e as características de motores para dispositivos móveis. É objectivo desta primeira parte identificar o motor com melhor compromisso entre desempenho e funcionalidades que permita 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 desta frameworké 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ção de 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. Sendo possível abstrair o tipo de dispositivos de entrada, é possível direccionar esforços para melhorar a qualidade e as funcionalidades de cada jogo. As empresas e programadores ficam assim livres de trabalho que, embora obrigatório, não acrescenta valor aos seus conteú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 para dispositivos 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 ser necessá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 os objectivos propostos ou parte deles. É feita uma avaliação de cada uma dessas alternativas para uma reflexão sobre a sua aplicabilidade no trabalho desenvolvido.

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

(20)

Introdução

O quarto capítulo é dedicado aos testes aplicados à framework. São apresentados os respectivos resultados e feita uma análise dos mesmos. É também possível encontrar neste capí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 retiradas ao longo da criação deste documento e de todo o trabalho a ele associado. São sugeridos alguns melhoramentos bem como referidas algumas expectativas de trabalho futuro.

(21)

Capítulo 2

Estado da Arte

Neste capítulo é feito um estudo sobre as actuais tecnologias que estão relacionadas com 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 ser dividida 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 em que 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 menos estabelecidas, 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 software que têm vindo a ganhar mercado e que estão cada vez mais presentes em diversos tipos de computadores e dispositivos. Os motores gráficos têm acompanhado esta tendência tentando garantir a compatibilidade com o maior número de sistemas operativos. Isto permite 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álise dos 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 considerados mais adequados para os objectivos definidos. Cada um desses motores foi avaliado com base no seguinte conjunto de critérios:

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

(22)

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 dos motores gráficos desenvolvidos em C ou C++, e uma vez que essas linguagens são subconjuntos do Objective-C, essa compatibilidade estará desde logo garantida. • Sistemas de rendering: A possibilidade de escolher entre vários subsistemas de

rendering, como o OpenGL e DirectX, é uma mais valia que deve ser tida em conta na avaliação das diferentes alternativas.

• Outros subsistemas de jogo: A inclusão de outros subsistemas de jogo, como física e audio, é um critério de menor importância relativamente aos restantes mas que deve estar presente no processo de decisão. Apesar de não ser obrigatório a inclusão de 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óprio para o efeito). A quantidade de formatos que podem ser importados pelo motor grá-fico é mais uma componente na apreciação global. A compatibilidade com software de modelação é um ponto a ter em conta pois permite agilizar o desenvolvimento de aplicações no contexto da Gema Interactive Media. Actualmente, os programas mais 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 utilizado e 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 no software 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 escolha do 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 qual delas 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 e que foi desenhada para a criação de gráficos de alta qualidade. O seu desenvolvimento começou em 2001 pela Unity Technologies e desde então várias versões foram surgindo no

(23)

Estado da Arte

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

Distingue-se dos restantes sistemas descritos neste documento por incluir um vasto conjunto 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 o mundo dentro da aplicação. Isto permite ter um feedback imediato e uma representação exacta do que será visto em runtime.

O Unity3D disponibiliza uma série de motores que visam acelerar o desenvolvimento de 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 leis da física. Inclui também um motor de audio capaz de reproduzir sons em 3D e vários mé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 é a possibilidade de desenvolvimento para múltiplas plataformas e dispositivos. É até pos-sível criar um jogo para a Web com características e desempenho tipicamente esperados apenas em ambientes desktop. Um exemplo está disponível em [Uni11b], sob a forma de um jogo que em fullscreen facilmente se confunde com uma aplicação nativa a ser executada directamente pelo sistema operativo. A possibilidade de exportar o jogos 3D criados para diferentes targets faz parte do tema desta dissertação e, no caso da web, uma

(24)

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 para diferentes plataformas, tais como Windows, Mac OSX, iOS e Android [Uni11g].

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

• Video playback e Streaming: É de grande interesse ter a possibilidade de integrar ví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 partir da imagem captada por uma câmara e ainda permite a criação de água com reflexões e refracções em tempo real.

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

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

• Profiler: É uma ferramenta indispensável na optimização de um jogo. Permite monitorar 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ça profissional 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 peso na escolha de um motor gráfico, não só pela portabilidade que o caracteriza, mas também por todas as facilidades que oferece na criação e implementação de conteúdos 3D.

(25)

Estado da Arte

2.1.2 OGRE

O acrónimo OGRE significa Object-Oriented Graphics Rendering Engine e, tal como o nome indica, trata-se exclusivamente de um motor gráfico. Não tem, portanto, outros subsistemas tais como motor de física e de audio. O projecto nasceu em 1999 pela mão de Steve Streeting mas só dois anos mais tarde, em 2001, surgiram os primeiros resultados que 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ões com melhoramentos e novas funcionalidades. Até à data, a versão estável do OGRE é a 1.7.2estando 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 software de desenvolvimento 3D, como motores de física, audio, rede, etc. Existem no entanto vários suplementos que podem ser usados para ultrapassar essas necessidades mas que oficialmente 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. Por ser exclusivamente um motor de rendering não impõe quaisquer restrições à escolha de motores externos. Esta flexibilidade é um factor a ter em conta para esta dissertação, pois a disponibilidade do hardware nos vários dispositivos pode exigir soluções adaptadas a cada caso.

Desenvolvido na totalidade em C++, o OGRE consegue chegar às plataformas mais importantes, o Windows, Mac OS X e Linux. Tem também vários templates com projectos para os IDE mais conhecidos, como, por exemplo, o Visual Studio.NET e o Xcode. Estas duas 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 independambi-entemambi-ente da plataforma à 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 o iOS, nomeadamente, o iPhone , iPad e iPod . Também está a ser desenvolvido, embora não oficialmente, o suporte para o sistema operativo Android. Este avanço coloca o OGRE como 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ácil encontrar vários livros e e-books dedicados ao OGRE e que dão uma explicação detalhada sobre a sua arquitectura e funcionamento.

Já foi referida anteriormente a independência conseguida pelo OGRE relativamente a motores externos. Na verdade, essa flexibilidade está presente em toda a sua estrutura e 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

(26)

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 ser anexados em runtime para desempenhar tarefas específicas e controlar diferentes aspectos do 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 equipa constituída por vários programadores. Tal como no caso do OGRE, é apenas um motor gráfico tratando exclusivamente do rendering de uma cena. Sem física, audio e outros componentes tão esperados em conteúdos 3D. É importante referir que contém na sua base 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 foi usado 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 dois sã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 ao facto de ser implementado em C++, o Irrlicht pode ser usado em múltiplas plataformas,

(27)

Estado da Arte

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

As funcionalidades presentes neste motor aproximam-no mais do OGRE do que dos restantes. 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êm de 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 relativamente ao 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 francesa responsável pelo desenvolvimento do ShiVa3D, um motor de jogo capaz de criar todo o tipo de aplicações multimédia em três dimensões. O objectivo principal de Philip e Nicolas consistia na criação de uma solução completa para a implementação de vídeos jogos multi-plataforma. É com este intuito que dão início ao seu projecto que já conta com mais de oito mil aplicações e trezentos jogos.

(28)

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 um motor de jogo que coloca à disposição sistemas de partículas, física, audio, entre outras funcionalidades. 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 as diversas 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, chega também ao iPhone , iPad , Android e Palm . Além destas, estão prometidas para breve no seu site oficial as plataformas Wii, PSP e PS3. Um facto que merece especial destaque nesta 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 para o Windows, o que significa que a criação de jogos para o iOS obriga o licenciamento de dois sistemas operativos, o Microsoft Windows e o Mac OSX.

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

(29)

Estado da Arte

2.1.5 Análise comparativa

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

Com base na tabela anterior, é fácil concluir que o Unity3D é o motor que melhor se encaixa no âmbito desta dissertação. Quer pelas suas funcionalidades, quer pela sua portabilidade. Tem no entanto duas desvantagens importantes: não é possível exportar os jogos 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ões que justificam a escolha são:

• Editor gráfico: O editor WYSIWYG facilita a configuração das propriedades dos objectos 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 profissionais do Unity3D é uma segurança adicional.

Portar jogos desktop para dispositivos móveis apresenta vários desafios uma vez que esses 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 parte desta dissertação.

2.2 Sensores

A proliferação dos meios tecnológicos registada nos últimos anos tem transformado profundamente o mundo em que vivemos. Desde ferramentas que nos ajudam a desem-penhar tarefas do quotidiano a simples objectos de entertenimento, é difícil, ou mesmo impossí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ção trouxe consigo novas oportunidades de interacção com os jogos e aplicações, resultando em experiências mais ricas, mais próximas da realidade e mais fáceis de usar para o utili-zador final.

(30)

Estado da Arte

Tabela 2.1: Comparação entre os vários motores Critérios Unity3D OGRE Irrlicht Engine ShiVa3D Plataformas

Linux - sim sim sim

Mac OSX sim sim sim sim

Windows sim sim sim sim

iOS sim sim sim sim

Android sim - - sim

Palm - - - sim

Playstation 3 sim - -

-PSP sim - -

-Xbox 360 sim - -

-Wii sim - - sim

Web sim - - sim

Objective-C(a) sim sim sim sim

Rendering

OpenGL sim sim sim sim

OpenGLES sim sim sim sim

Software Rendering - - sim

-Motores

Física sim - - sim

Áudio sim - - sim

Rede sim - - sim

Modelos 3D(b)

3D Studio Max sim sim sim sim

Blend sim sim sim sim

COLLADA sim sim sim sim

Maya sim sim sim sim

Documentação Completa Completa Completa Razoável

Preço 3 300 C(c) 0 C 0 C 1 499 C

(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 restantes plataformas é necessário entrar em contacto com a Unity Technologies.

(31)

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, pois implica 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ódigo específico para cada situação pode simplesmente não ser viável.

É este problema que a segunda parte desta dissertação pretende resolver. O principal objectivo 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 jogo pode estar orientada às acções do jogador, sem a preocupação de conhecer o estado de um controlador num determinador instante de tempo. Espera-se que em virtude desta nova abordagem 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 aos sensores para gerar acções. A seguinte lista de jogos consiste num conjunto de exemplos que 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 com uma 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 como o utilizador interage com o labirinto. Inclinando o dispositivo influencia o trajectória da bola, 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és do 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 jogo mais emocionante.

2.2.1.3 Cut the rope

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

(32)

Estado da Arte

Figura 2.5: Labyrinth 2

(33)

Estado da Arte

Neste caso, a interacção é feita através do toque e muito intuitiva. O dedo do participante tem 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 principalmente pela 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 a realidade. O WiiSports é um bom exemplo de reconhecimento gestual através do uso de giroscó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 tradicional comando composto por teclas direccionais e vários botões, é agora possível desempenhar acções através de gestos. Os pontos seguintes são alguns exemplos desse tipo de soluções.

(34)

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 e interaja 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 tecnologia abandonam-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 interpreta apenas 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 e que 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 plataforma de controlo sensível ao movimento. Criada pela Sony Computer Entertainment, tem um modo de utilização semelhante ao concorrente Wii Remote, embora ofereça uma precisão bastante maior. A plataforma consiste numa câmara PlayStation Eye e um ou mais (até 4) comandos PlayStation Motion Controller que, em conjunto, conseguem determinar qual a 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. Durante esse processo cada um dos comandos faz brilhar a esfera com uma cor distinta de todas as

(35)

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ções porque as operações no jogos são executadas através de gestos e movimentos do Motion Controller. Tal como no caso do Kinect, não é uma solução genérica porque baseia-se exclusivamente 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 estivesse alinhada com os principais requisitos que foram propostos. Existem no entanto inúmeras bibliotecas que abstraem vários sensores permitindo ao programador escrever código não específico de uma plataforma em particular. Essas bibliotecas disponibilizam sob a forma de uma API um conjunto de classes e métodos que permitem conhecer o estado de cada dispositivo ao longo do tempo. Esta abordagem não é diferente da que já é seguida na Gema Interactive Mediauma vez que continua a depender de código específico de cada controlador. O trabalho que se propõe é justamente desenvolver uma framework que esteja de 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

(36)

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 motor de jogo, já que permite a junção das duas componentes desta dissertação nos dispositivos com sistema operativo iOS. Conclui-se, também, que é mais proveitoso implementar uma frameworkde abstracção de sensores ao invés de utilizar uma já existente.

(37)

Capítulo 3

Framework para abstracção de sensores

No presente capítulo é abordado o trabalho desenvolvido após a análise do estado da arte, 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 uma API que sirva de interface entre qualquer tipo de sensor e o input de um programa de computador, 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 novos dispositivos 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 vantagens que o sistema pretende oferecer e se será capaz de ultrapassar as dificuldades específicas de uma determinada área. Estando esta dissertação ligada ao desenvolvimento de jogos em dispositivos móveis, é natural que os requisitos tenham sido pensados especificamente para 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 entrada que ainda não estejam contemplados, é importante garantir que existe uma forma fácil de os integrar no sistema.

(38)

Framework para abstracção de sensores

• Sistema de plugins: A framework deve implementar um sistema de plugins. A principal 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 de aplicação em que se verifica uma intensiva utilização dos recursos disponíveis, quer em processamento, quer em memória. É um requisito fundamental porque se for ignorado, pode tornar o sistema inutilizável em situações reais.

• Multiplataforma: Espera-se que esta framework consiga chegar ao maior número de 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 um conjunto de passos a serem executados dentro de um diagrama. O input esperado são os 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 forma a 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 de blocos, alterando o output de acções gerados pela framework . Na próximo ponto serão analisados 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 blocos sã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 bloco deve ser executado.

3.3.2 Blocos

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

(39)

Figura 3.1: Visão geral da arquitectura

servir de output da framework . Os blocos não são executados todos ao mesmo tempo. A ordem 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 um conjunto de blocos a serem executados. O método utilizado para construir o mapa de associaçõ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 de saída estão na iteração i + 1.

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

Dentro de cada iteração os blocos são executados sem uma ordem definida e, por defeito, sequencialmente. Isto significa que um bloco só começará o seu processamento depois de todos os anteriores terminarem os seus. Isto levanta o problema de reduzir a utilidade da framework . Blocos que gastem demasiado tempo a interpretar sinais, algo bastante 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 podem executar o seu processamento em paralelo, utilizando threads.

(40)

3.3.3 Acções

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

Existem dois tipos de acções: as simples e compostas. As simples são indivisíveis e foram 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 em aplicações multi-toque. No contexto desta eventual aplicação, é possível classificar um toque na superfície como uma acção simples. No entanto, a acção de zoom, realizada com dois dedos é classificada como uma acção composta, pois, na sua origem, estão duas acções simples. Na prática, a diferença mais marcante entre as duas é que no caso das acções compostas existe uma LinkedList<Action *> com todas as acções que serviram de base para a sua criação. As classes seguintes servem justamente para representar esta situação:

Figura 3.2: Hierarquia de acções

Segundo este modelo é fácil perceber que é possível ignorar se a acção é simples ou composta, 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ções mais 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 exemplo seguinte mostra uma possível estrutura:

(41)

(42)

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ão obrigatoriamente do tipo RootAction. Esta estrutura permite, por exemplo, que um IActi-onListenerfica à espera de acções do tipo Translate, sendo notificado sempre que ocorrer um 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 vizinhos presentes no diagrama, levanta-se um problema que precisa de ser resolvido, sob pena de limitar a flexibilidade da framework : Como comunicar entre blocos independentemente da configuração do diagrama? É neste contexto que surgem as mensagens.

As mensagens são mecanismos de controlo que permitem alterar o funcionamento de um 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 acontecimentos importantes. 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 mensagem Forget, que serve justamente para esse propósito. Não sendo possível forçar que todos os blocos esqueçam, de facto, as suas possíveis acções compostas, é da responsabilidade dos mesmos que implementem o protocolo e, quando sinalizados, executem a respectiva ordem. Não o fazer significa que o bloco não está de acordo com o protocolo e a sua inclusã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, devem chegar a todos os destinatários. Recorrendo novamente ao exemplo anterior, a mensagem Forgetnã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 os programadores 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 uma alternativa viável para tornar públicos quais os acontecimentos chave da framework .

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

(43)

(44)

• 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 contexto em 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 essencialmente para criar um canal de comunicação entre um ou mais blocos;

Um aspecto negativo relativamente à adopção de um protocolo é a possibilidade de serem acrescentadas mensagens em novas versões da framework , correndo o risco dos blocos 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 esta opção são:

• Multiplataforma: É a linguagem de programação mais compatível entre todos os sistemas 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 forem implementados 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 projecto em 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 nesse mesmo programa, o uso desta aplicação não acarreta custos adicionais.

(45)

• Linguagem C++: A linguagem escolhida foi o C++. Esta linguagem é suportada por 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 pode configurar todo o sistema e onde todas as funcionalidades são acessíveis. É expectável que 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 que existe apenas uma única instância de InputSystemRoot, o que significa que a referência para tal objecto teria de ser passada para os níveis mais baixos de toda a arquitectura. A natureza desta situação enquadra-se no singleton pattern, um modelo de desenvolvimento que 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 vezes considerados como anti-pattern, é que cria uma certa dependência à framework já que fica mesclada com grande parte do projecto. A vantagem, por outro lado, é que facilita a sua 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á encapsulada dentro 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é ao output, ou seja, as acções.

3.4.2.3 DiagramConnection

Uma vez dentro do diagrama, os blocos só realizam trabalho útil se estiverem ligados uns aos outros. Essas ligações têm um propósito simples: criar uma estrutura partilhada por 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, quando um bloco emite um valor por um dos seus canais de saída, está a adicionar esse mesmo valor ao fim da fila em DiagramConnection. O bloco seguinte, o receptor, retira, caso existam 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ão ser recebidos.

(46)

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 dos seus 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 primeira aproximação. Como já foi referido em cima, uma ligação entre dois blocos pode ser visto como uma fila. Assim sendo, sempre que um bloco envia um pacote para outro, está, no fundo, a adicioná-lo à cauda da fila do bloco seguinte. Como as filas são uma estrutura de dados de um só tipo, isto é, todos os items tem de ser do mesmo tipo, levanta-se uma questão. Se a ligação entre blocos só pode transmitir um tipo de dados, como fazer para enviar diferentes valores e objectos? Existem linguagens em que qualquer variável é uma instâ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 se verificasse no C++, bastaria generalizar o tipo de dados a serem trocados como sendo NSObjects. No entanto, essa não é uma possibilidade real pois, como sabemos, os tipos primitivos, 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âncias dessa 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ão o seu respectivo valor.

3.4.2.5 Árvore de acções

As classes que implementem a interface IActionListener são classes que podem ser notificadas 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ção que se está a desenvolver. A estrutura em árvore que representa o conjunto de acções disponí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érico de acção. Recorrendo ao exemplo da figura 3.3, um IActionListener pode aguardar que ocorra a TranslateAction, que por sua vez será desencadeada sempre que JumpAction, LeftActionou RightAction for detectada. Por outro lado, é fácil determinar os nós pai de

(47)

uma determinada acção. Basta percorrer a árvore ascendentemente para retirar a lista das acçã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, numa LinkedList, 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 como um grafo mais genérico, ao invés de uma árvore (um caso particular de grafo). Nessa situação, as acções não teriam pais nem filhos mas antes vizinhos. A razão pela qual não foi escolhida esta opção é que torna demasiado complexa a tarefa de determinar de que tipos mais abrangentes é uma dada acção. Recorde-se que, no caso de uma árvore, basta percorrer 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 natureza de 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 delay bastante mais curto que uma câmara / entrada de vídeo. Se o diagrama não for capaz de executar 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 apresentadas anteriormente, nomeadamente pela rapidez exigida à solução, é imperativo que os blocos, se assim o exigirem, possam ser executados em threads diferentes. Por forma a evitar o protelamento de um ciclo que aguarda o final de uma tarefa de um bloco, foi introduzida a possibilidade de cada IDiagramBlock pedir à framework que seja executado numa thread diferente. Para esta funcionalidade havia duas maneiras de a implementar:

• Criação de threads serem criadas por cada bloco, ficando à sua responsabilidade a sua 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 menos complexa. Deixa de ser necessário conhecimentos específicos sobre threads e reduz a probabilidade 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 resultar numa melhoria de desempenho da globalidade do sistema.

(48)

Figura 3.6: Utilização de threads

3.4.2.7 XML

A capacidade de ler diagramas em XML é um requisito fundamental da framework pois 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ível serializare 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"?> <name > t o u c h < / name > < t y p e > V i r t u a l J o y s t i c k B l o c k < / t y p e > < 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 >

(49)

Framework para abstracção de sensores < j o y s t i c k c e n t e r X = " 1 0 " c e n t e r Y = " 2 0 " r a d i u s = " 3 0 " / > </ params > <name > i n v e r t < / name > < t y p e > I n v e r t A x i s B l o c k < / t y p e >

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 para referenciar blocos, sendo a propriedade <type> que indica a que class pertence. É ainda possível passar alguns parâmetros que podem ser acedidos a qualquer momento dentro da class Block. A lista de <connection>, tal como o nome indica, contém a lista de ligações de 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 um diagrama a partir de um ficheiro XML. Com excepção de algumas situações, referidas no capítulo de 5 Conclusões e trabalho futuro, é assim possível alterar o comportamento do sistema sem voltar a compilar toda a aplicação. Para o processamento de um documento XML, foi utilizada a biblioteca libxml2, compatível com todos os ambientes de testes listados no capítulo 5.

(50)

(51)

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 o objectivo 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 esta abordagem introduza um atraso suficientemente grande ao ponto de não ser desprezável aquando 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 com um ambiente de desenvolvimento 3D. Neste sentido, a framework criada foi sujeita a uma bateria de testes para medir os tempos de resposta e a quantidade de memória utilizada em diferentes situações.

4.2 Ambiente de testes

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

• MacBook Pro

Processador: 2.66 Ghz Intel Core 2 Duo Memória: 4 GB 1067 MHz DD3

(52)

Testes e resultados

• MacMini

Processador: Intel Core 2 Duo Memória: 3 GB

Sistema Operativo: Mac OS X 10.7.2 • iPhone 4

Processador: Apple A4 1 GHz Memória: 512 MB

Sistema Operativo: iOS 5.0.1 • iPad 1

Processador: Apple A4 1 GHz Memória: 236 MB

Sistema Operativo: iOS 5.0.1 • iPad 2

Processador: Apple A5 Memória: 512 MB

Sistema Operativo: iOS 5.0.1

Todos os cinco ambientes anteriormente listados têm características diferentes. O benefí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 foi desenvolvida.

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 procesproces-samento de sinais de uma dimensão como, por exemplo, o de um giroscópio. Dito isto, é fundamental definir como serão realizados os testes de forma a obter exclusivamente os dados que permitam avaliar 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 serem executados 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 a uso 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 que se 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.

(53)

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 do ambiente do Unity3D basta fazer uma única chamada à framework . Como a latência de um ciclo completo executado pela framework é demasiado pequena, esse valor torna-se imensurável pelos relógios que marcam o tempo decorrido entre o início e o fim dessa chamada. Para tornar possível a medição desse tempo, são efectuadas cem mil chamadas consecutivas à framework , e medido o tempo total dessas cem mil invocações. Desta forma é 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ão acrescenta 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 longo do capítulo 3, deu-se início à sua integração em casos reais. A sua aplicação em projectos de 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ção de sensores.

4.5.0.1 Super Bock Classic

Aquando do lançamento de uma nova cerveja, a Super Bock encomendou à empresa Gema 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 em escrever, no céu, o nome da bebida, através do fumo expelido pelo avião. Deste modo, foi criado um simulador de aviões e o jogador tinha de atravessar um determinado número de arcos até chegar à pista de aterragem. Quando o jogador batia nos arcos tinha uma

(54)

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 de dez 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 em todas as plataformas para garantir a equidade do funcionamento do jogo. No final, o jogador 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 facto de este jogo ser igual em todas as plataformas, consistiu na sua mais valia. Verificou-se uma 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 exemplo de 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 actor principal, 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, pelo toque. O objectivo neste caso passa por reescrever o código que controla o jogador tendo por base a framework .

(55)

Testes e resultados

4.6 Considerações sobre o Unity3D

Apesar do Unity3D não estar sujeito a conjunto específico de testes, existem algumas consideraçõ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 relativamente aos conteúdos 2D. Era desejável que a componente 2D do Unity3D estivesse mais próxima de outras tecnologias como o Adobe® Flash®. Mas a verdade é que este facto 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ças visuais antes e depois da aplicação desta função são abismais, e o impacto da sua utilização é sempre positivo. Resta dizer que os 10% de realismo extra [Uni12], obtido na versão paga do Unity3D , não é sequer perceptível.

(56)