projeto uaquest - relatório final

Agradecimentos

Este projeto contou com o apoio de muitas pessoas, no entanto existem algumas que merecem um agradecimento especial.

Agradecemos à Oficina do Telemóvel, na pessoa de Marcolino Melo, pelo empréstimo de um terminal móvel que suportou o desenvolvimento do projeto.

A Bruno Silva, pelo suporte prestado e pelo empréstimo de outro terminal.

Aos nossos orientadores, professores Helder Caixinha e Licínio Mano, que sempre nos apoiaram e ajudaram no decurso deste desafio.

E, por último, aos docentes da disciplina de projeto e a todos os que prestaram suporte nestes meses de trabalho intenso.

Muito obrigado!

Resumo

O presente documento apresenta o relatório do projeto uaQuest, sendo desenvolvido para a unidade curricular de Projeto do 3º ano da Licenciatura em Novas Tecnologias da Comunicação pela Universidade de Aveiro.

Este apresenta-se como o culminar de um semestre de trabalho e pretende apresentar uma reflexão sobre todo o trabalho desenvolvido. O documento é sustentado em oito capítulos sendo efetuada uma análise às várias fases do projeto, desde a sua conceção até ao final do desenvolvimento, justificando opções tomadas e funcionalidades alteradas.

Índice

Capítulo I - Introdução ............................................................................................................................. 9

Capítulo II - Estudos Preliminares ........................................................................................................ 10

Estado da Arte ..................................................................................................................................... 10

Viabilidade Técnica ............................................................................................................................. 11

Capítulo III - Design Funcional .............................................................................................................. 13

Requisitos Funcionais ......................................................................................................................... 13

Design Gráfico ..................................................................................................................................... 14

Conteúdos ............................................................................................................................................ 18

Capítulo IV - Design Técnico ................................................................................................................. 19

Demonstrador Técnico ....................................................................................................................... 19

Componentes mapa de navegação ................................................................................................ 20

Arquitetura da Aplicação ................................................................................................................... 20

Server Comunication Engine ......................................................................................................... 22

Augmented Reality Framework .................................................................................................... 22

Google Maps Framework .............................................................................................................. 22

Configuration Manager .................................................................................................................. 22

Item Manager .................................................................................................................................. 22

QrCode Manager ............................................................................................................................. 22

uaQuest Widget ............................................................................................................................... 22

Application Resources .................................................................................................................... 23

Android Activities ............................................................................................................................. 23

API .......................................................................................................................................................... 24

Combate ............................................................................................................................................... 28

Ataque ............................................................................................................................................... 28

Barras de Energia e Vida ............................................................................................................... 30

Realidade Aumentada – Problemas e Limitações .................................................................... 31

Base de dados ..................................................................................................................................... 31

ServerRequest ...................................................................................................................................... 32

Leitura de QrCodes ............................................................................................................................. 33

Sistema de Gestão de Conteúdos.................................................................................................... 34

Widget ................................................................................................................................................... 36

Capítulo V - Testes .................................................................................................................................. 37

Teste de usabilidade ........................................................................................................................... 37

Teste de compatibilidade .................................................................................................................. 38

Teste de conteúdos ............................................................................................................................. 39

Capítulo VI - Manutenção e suporte ................................................................................................... 40

Suporte .................................................................................................................................................. 40

Manutenção ......................................................................................................................................... 40

Sistemas de ajuda ............................................................................................................................... 40

Divulgação ............................................................................................................................................ 41

Capítulo VII - Análise Crítica e desenvolvimento futuro .................................................................. 42

Capítulo VIII - Conclusão ....................................................................................................................... 44

Bibliografia ............................................................................................................................................... 45

Anexos....................................................................................................................................................... 46

Anexo 1 – Requisitos funcionais do sistema de gestão de conteúdos ..................................... 47

Anexo 2 – Sistema de pastas aplicação Android .......................................................................... 49

Anexo 3 – Fluxograma processamento ataque ............................................................................. 50

Anexo 4 – Tags de enigma e tags de informação ........................................................................ 51

uaQuest – Relatório do projeto 9

Capítulo I - Introdução

O projeto uaQuest pretende reformular a forma como os novos alunos descobrem a Universidade de Aveiro. Através de um jogo de descoberta e resolução de enigmas, o projeto visa facilitar a integração dos novos alunos na vida académica, contribuindo para a socialização destes, e promover a UA (o seu ensino e a sua investigação).

Utilizando as duas vertentes do projeto, a da exploração e a da interação social, os alunos conseguem saber mais sobre a universidade e integrar-se e socializar-se com a comunidade.

Os enigmas, agrupados em percursos, consistem em pequenas perguntas sobre as diversas vertentes da Universidade como, por exemplo, o ensino, investigação… Assim, dirigindo-se ao ponto de interesse e procurando tags de informação para ajudar na resposta, os novos alunos têm uma experiência imersiva, conhecendo os locais em primeira pessoa.

A componente de interação/socialização é assegurada pelos avatares da aplicação, que interagem com outros através de combates virtuais, e pelas funcionalidades de trocas e mensagens. A prestação dos avatares nos combates pode ser melhorada através de itens obtidos com a resolução de enigmas.

Estas duas componentes completam-se mutuamente, permitindo uma aprendizagem em prol de um objetivo. Quanto mais a UA for descoberta, melhor se irá combater.

O conceito geral do projeto manteve-se inalterado ao longo de todo o desenvolvimento uma vez que foi definido de uma forma sólida e detalhada. Devido à evolução do próprio projeto existiram funcionalidades, inicialmente propostas, que tiveram de ser revistas e alteradas mas que não afetaram o conceito por detrás de toda a aplicação.

O presente documento começa por expor os estudos preliminares que foram necessários ao desenvolvimento do projeto, seguindo para o design funcional onde é efetuada uma apreciação sobre os requisitos originalmente definidos e os efetivamente desenvolvidos, o desenvolvimento do grafismo da aplicação e os conteúdos existentes. Segue-se o design técnico que engloba a arquitetura, a construção da API, a base de dados, o sistema de gestão de conteúdos e as componentes mais importantes da aplicação. São de seguida apresentados os testes efetuados e os benefícios resultantes para a aplicação, bem como a estratégia de manutenção, suporte e divulgação da aplicação. Por último é efetuada uma análise crítica do desenvolvimento apresentando possíveis funcionalidades adicionais a serem implementadas.


Capítulo II - Estudos Preliminares

Estado da Arte

Após a definição do conceito1 subjacente à aplicação, procedeu-se a uma análise do estado da arte de modo a demonstrar que tipos de aplicações, com características similares às pretendidas, existiam no mercado. Desta forma efetuou-se uma pesquisa tendo em conta alguns termos chave como Realidade Aumentada, jogos multijogador e geolocalização. Esta pesquisa possuiu duas frentes de ataque: a primeira pretendia compreender o que existe no mercado, enquanto a segunda procurava inspiração nas formas de interação com o utilizador e no aspeto gráfico da aplicação em si. Pretendia-se igualmente compreender se existiam aplicações que utilizassem as três componentes já referidas.

Não foram encontradas aplicações com tal interligação de componentes, no entanto verificaram-se algumas muito robustas nas várias componentes mas de forma independente. A título de exemplo o jogo Paparazzi usa a componente de realidade aumentada de modo a que o utilizador consiga interagir com a personagem e vice-versa, enquanto o FoursqWar utiliza a geolocalização transformando a posição do jogador numa área a defender.2

Concluiu-se que, muito provavelmente, não existia nenhuma aplicação que preenchesse todos os termos chave procurados, no entanto a pesquisa teve uma importância elevada para o desenvolvimento do projeto, permitindo compreender, ainda que de forma leviana, alguns dos paradigmas utilizados aquando da utilização destas tecnologias.

Através da integração das várias tecnologias esta aplicação apresenta-se como um projeto inovador3 tendo o objetivo de se transformar num jogo interativo e dinâmico permitindo aos alunos descobrir a Universidade de Aveiro.

Com o desenvolvimento do projeto surgiu a necessidade de efetuar investigação adicional sobre esta e outras temáticas, como por exemplo avatares em 3D, formas de desenvolvimento de aplicações Android nativas e práticas de apresentação de informação em ambientes Android, de forma a obter inspiração e compreender como construir uma aplicação coerente e funcional.

1 Consultar briefing no documento #entrega01 - Estado da Arte e Briefing, pg 29, em http://uaplay.blogs.ua.sapo.pt/1114.html 2 Mais informações e outras aplicações estudadas podem ser encontradas em http://uaplay.blogs.ua.sapo.pt/1114.html 3 Consultar análise SWOT no documento #entrega01 - Estado da Arte e Briefing, pg 26, em http://uaplay.blogs.ua.sapo.pt/1114.html

http://uaplay.blogs.ua.sapo.pt/1114.html




Viabilidade Técnica

Uma vez que a aplicação que nos propusemos a desenvolver possuía diversas tecnologias envolvidas, existindo algumas das quais o grupo não tinha conhecimento, foi necessário efetuar um estudo de viabilidade técnica extensivo para compreender se o conceito criado tinha a possibilidade de um real desenvolvimento.

O projeto possuiu duas vertentes de desenvolvimento correspondendo à aplicação móvel para sistemas Android e o motor de jogo, constituído pela API e seus serviços, alojado num servidor web.

No que diz respeito ao motor do jogo foi utilizado o PHP para o desenvolvimento da API e processamento dos dados, e o MySQL como sistema de gestão de base de dados. Após o desenvolvimento do projeto o grupo concluiu que a escolha das tecnologias foi corretamente efetuada. A comunidade que utiliza estas tecnologias e a documentação que é produzida desempenharam um papel muito importante para esta conclusão, sendo que os problemas encontrados ao longo do desenvolvimento tiveram uma rápida resolução devido a esta mesma comunidade e documentação.

Já no que se refere à aplicação móvel, esta foi desenvolvida para sistemas Android, utilizado o próprio SDK disponibilizado pelo Google. Desta forma, recorrendo à linguagem JAVA, foi possível a integração com as bibliotecas de leitura de QrCodes (ZXing) e de Realidade Aumentada (AndAr). O grupo tinha preferência pelo desenvolvimento em sistemas Android e a escolha deste sistema revelou-se adequada tendo este beneficiado com a qualidade dos documentos e a grande comunidade existente. Apesar do grupo não ter conhecimentos prévios sobre a construção de aplicações para esta plataforma, decidiu aceitar o desafio obtendo uma grande satisfação com os resultados alcançados.

Procedamos agora para as especificidades da aplicação, nomeadamente as bibliotecas de leitura de QrCodes e Realidade Aumentada utilizadas.

A deteção e interpretação dos QrCodes representa uma componente fulcral da aplicação permitindo o acesso aos enigmas e informações existentes nos pontos de interesse, e o acesso a funcionalidades adicionais como a montagem, loja, combate e trocas4. Pretendia-se que esta leitura fosse efetuada internamente pela aplicação sem ter de recorrer a aplicações de terceiros e obrigar o utilizador a instalações adicionais. A biblioteca ZXing permitiu cumprir este objetivo de uma forma facilitada, sendo que através da interpretação de um exemplo fornecido5 foi possível a adaptação para os propósitos do projeto.

O grupo pretendia utilizar a Realidade Aumentada em várias componentes da aplicação, tornando o uso desta mais interessante para o utilizador, no entanto devido a restrições técnicas tal não foi possível. Desta forma, a realidade aumentada, foi aplicada apenas no combate e, no entanto, carece de algumas funcionalidades como, por exemplo, não permitir animações, detetar os markers de forma incorreta e falta de fluidez.

4 Mais informação sobre a leitura de QrCodes pode ser encontrada no Capítulo IV, secção Combate, subseção Leitura de QrCodes. 5 Programa exemplo em http://code.google.com/p/zxing/downloads/detail?name=ZXing-2.0.zip&can=2

http://code.google.com/p/zxing/downloads/detail?name=ZXing-2.0.zip&can=2


Foi escolhida a biblioteca AndAr uma vez que, dentro das pesquisadas, era a que apresentava um exemplo mais similar ao que se pretendia tornando a sua adaptação mais fácil. Fazendo uma análise reflexiva, podemos agora compreender que esta escolha não foi a mais correta uma vez que a biblioteca possui várias limitações explicadas em detalhe no Capítulo IV, seção Combate, subseção Realidade Aumentada – Problemas e Limitações. Uma alternativa mais apropriada seria a biblioteca Qualcomm AR (Vuforia), apresentando, à data da entrega do projeto com uma comunidade mais desenvolvida e uma documentação um pouco mais detalhada, permitindo assim uma melhor compreensão sobre a sua utilização. No entanto aquando do desenvolvimento a biblioteca AndAr era mais acessível devido aos conhecimentos do grupo sobre as tecnologias utilizadas.

Para a construção do ecrã principal (mapa-mundo) apresentado a posição do jogador e os pontos de interesse no seu apósito local foi utilizada a API do Google Maps, cuja implementação foi executada sem qualquer problema revelando-se uma escolha adequada para o que era pretendido.

A utilização da aplicação obriga o utilizador a passar por um processo de registo, e para facilitar pretendia-se que este fosse efetuado recorrendo ao sistema de utilizador universal da Universidade de Aveiro. Uma vez que o contexto de uso da aplicação está, neste momento, restrito à própria universidade, a utilização deste sistema faria todo o sentido, no entanto devido a restrições de acesso ao mesmo, não foi possível proceder à sua implementação tendo-se adotado o sistema de registo tradicional, requerendo a inserção dos dados por parte do utilizador. Porém, se a aplicação for realmente integrada na universidade, poder-se-á adaptar para utilizar este sistema. Para utilização noutros contextos novas soluções, além do registo tradicional, teriam de ser pensadas.

Originalmente tinha sido pensada a hipótese da aplicação possuir uma banda sonora, no entanto esta foi suspensa de modo a dar prioridade ao desenvolvimento de outras componentes. No entanto, não foi descartada correspondendo a um desenvolvimento futuro.

Aparte a questão da banda sonora e registo não existiram outras alterações no que diz respeito ao estudo de viabilidade técnica efetuado inicialmente. Importa também referir o cuidado do grupo em ter efetuado uma pesquisa bastante exaustiva permitindo escolhas fundamentadas e que se verificaram corretas.

Um ponto originalmente não ponderado pelo grupo refere-se ao desenvolvimento da aplicação utilizando uma framework como por exemplo Titanium. No momento atual, e após todo o trabalho efetuado já é possível tecer uma opinião sobre este tema. O desenvolvimento da aplicação com recurso à linguagem nativa permitiu ter um controlo muito superior sobre as prestações da mesma, bem como integrar, da forma pretendida, as bibliotecas utilizadas. Permitiu, de igual modo, compreender o ciclo de vida e a estrutura/organização das aplicações Android adquirindo um conhecimento mais aprofundado sobre o funcionamento deste sistema, facto desejado pelo grupo e que pode trazer inúmeros benefícios no futuro profissional do mesmo.


Capítulo III - Design Funcional

Requisitos Funcionais

Os requisitos funcionais do projeto, organizados em dois grupos: aplicação e website, foram-se modificando com a evolução do mesmo e existem alterações que são importantes referir.

Originalmente o website permitia a interação com os dados da aplicação através da visualização da tabela classificativa, das mensagens e do inventário, servindo assim de suporte à aplicação em si. Uma vez que se deixou de permitir ao utilizador efetuar o registo, todos os requisitos que descendiam da possibilidade de registo e autenticação no website caíram por terra6. Estas funcionalidades foram restringidas ao terminal móvel uma vez que é mais prático para o utilizador ter acesso a todas as funcionalidades no mesmo sistema.

O website permitia ainda a consulta do inventário de outro jogador no entanto este requisito foi eliminado por dois motivos: em primeiro lugar pretendia-se que existisse interação real entre os vários jogadores para, por exemplo, obter informação sobre os itens que cada um possui, em segundo para impedir que todos os utilizadores conhecessem o inventário de outro sem a sua autorização.

Inicialmente o registo tinha de ser efetuado no website, no entanto, para comodidade do utilizador esta funcionalidade foi portada para o terminal tendo sido adicionadas funcionalidades de recuperação e alteração da password escolhida. Funcionalidades originalmente trascuradas pelo grupo mas que rapidamente se impuseram como imprescindíveis devido a representarem uma necessidade real.

O website funciona agora como suporte à aplicação permitindo a sua obtenção e apresentando informações adicionais como a história dos avatares. Para dar mais consistência ao projeto foi criado um sistema de gestão de conteúdos que, apesar de ser um protótipo, permite gerir os percursos, pontos de interesse, enigmas e informação. Estes novos requisitos foram adicionados ao projeto e podem ser consultados no Anexo 1.

No que diz respeito à aplicação móvel os requisitos inicialmente definidos foram atingidos e foram adicionadas novas funcionalidades para melhorar a experiência do utilizador. Aparte da já referida funcionalidade de recuperação de password foi adicionada a possibilidade de consultar o próprio perfil. Este apresenta a posição atual do utilizador, as características atualizadas do avatar (contabilizando os efeitos dos itens possuídos), bem como os ataques especiais7 do mesmo. Foi ainda desenvolvido um widget cujos detalhes podem ser encontrados no Capítulo IV, seção Widget.

6 Consultar o documento #entrega02 - Requisitos Funcionais e Viabilidade Técnica, pg 4-5, em http://uaplay.blogs.ua.sapo.pt/2481.html 7 Os ataques especiais permitem ao utilizador aumentar o poder de ataque do seu avatar durante um combate e derivam dos itens lendários. Cada ataque especial tem um custo energético e um multiplicador que irá ter influência sobre o ataque original do avatar. Estes diferem dos ataques normais uma vez que para os utilizar tem de ser desenhado o gesto correspondente.



Imagem 1 - Mapa de navegação com componentes não previstas.

A imagem 1 representa o mapa de navegação da aplicação atualizado para o momento atual, sendo as componentes assinaladas a laranja as funcionalidades que foram adicionadas após a definição dos requisitos. Originalmente o website iria conter um manual do jogo explicativo que os utilizadores teriam de consultar para compreender como utilizar a aplicação. Esta solução possuía vários problemas sendo que a aplicação perdia o seu carácter móvel se fosse sempre necessário possuir um computador para aceder ao manual. Este facto, juntamente com a complexidade da aplicação obrigou a adotar uma nova solução que passou pela criação te pequenos tutoriais inseridos antes de ecrãs críticos.

Em suma, o grupo não se limitou a desenvolver o que originalmente tinha proposto mas teve o cuidado de melhorar o projeto tornando-o mais sólido, completo e orientado para o utilizador.

Design Gráfico

Para o projeto foi necessário criar uma imagem marcante, possuindo um design apelativo, funcional e um logótipo fácil de memorizar. Antes de proceder à definição do design foi necessário alterar o nome originalmente definido para um mais indicado às especificidades do projeto. uaQuest foi o nome escolhido8 e possui um duplo significado, “ua” referindo-se 8 O processo de escolha do nome pode ser encontrado em http://uaplay.blogs.ua.sapo.pt/6272.html



ao local de onde decorre o jogo, Universidade de Aveiro, e o “Quest” de demanda, objetivo, algo a ser atingido, visto ser um jogo orientado para a descoberta da universidade.9

Pretendia-se que a aplicação assumisse um estilo futurista, de modo a transmitir os ideais de tecnologia e inovação associados à universidade. Foi, desta forma, efetuada uma pesquisa com o objetivo de compreender qual a melhor abordagem a tomar. As interfaces dos vários elementos presentes no Tron e Iron Man serviram este propósito. Estas apresentam uma imagem muito futurista possuindo alguns elementos decorativos de modo a tornar a interface mais apelativa e tecnológica. Estado definidas as guias base do design adotado foi construída a primeira versão gráfica.

Imagem 2 - Primeira versão do design da aplicação. Ecrãs mapa e inventário e respetivas grelhas.

O azul uaQuest e ao branco estão sempre presentes tanto na aplicação como no logótipo, e assumem uma elevada importância na aplicação devido aos valores que transmitem: paz, sucesso, tranquilidade, compreensão, associando desta forma a universidade a um local calmo de conhecimento e sucesso, valores positivos a transmitir aos novos alunos.10

Com o desenvolvimento e aplicação da interface no dispositivo móvel, e após algumas discussões, conclui-se que existia a necessidade de revisitar a especificação gráfica efetuando algumas alterações.

9 Mais informações sobre o nome no documento #entrega04 - Especificação Gráfica, pg 6, em http://uaplay.blogs.ua.sapo.pt/7778.html 10 Consultar documento #entrega04 - Especificação Gráfica, pg 7, em http://uaplay.blogs.ua.sapo.pt/7778.html




Estas passaram pela remoção de alguns dos elementos decorativos que apenas acrescentavam ruido à interface. No canto inferior direito e no canto superior esquerdo encontravam-se pequenos textos, colocados para dar a sensação de que aplicação estava a realizar alguma tarefa em segundo plano. Nos vários ecrãs existia também uma moldura com o intuito de tornar a aplicação numa “janela para o futuro”, no entanto esta apenas diminuía o espaço disponível não acrescentando valor.

Quando a interface foi aplicada num terminal apresentava-se demasiado “pesada” e “cansativa”. Com a remoção dos elementos já referidos tronou-se mais “leve” e “limpa” continuando a transmitir os valores pretendidos inicialmente.

Imagem 3 - Segunda versão do design da aplicação. Ecrãs mapa e inventário e respetivas grelhas.

Mesmo com as alterações já realizadas continuaram a existir problemas, relacionadas com a usabilidade da aplicação. Quando a aplicação era utilizada pela primeira vez surgiram dúvidas em relação aos botões e aos rótulos existentes. A aparência dos mesmos era similar levando os utilizadores a considerar os rótulos como botões, como pode ser compreendido pela imagem abaixo.

Para a resolução deste problema foi criada uma barra na parte superior do ecrã contendo os rótulos deixando os botões com um pequeno triângulo branco no canto inferior direito.


Imagem 4 - Evolução dos botões (1ª linha) e rótulos (2ª linha)

Foi desta forma definido o que seria a linha gráfica de toda a aplicação, permitindo continuar o desenvolvimento dos restantes ecrãs de uma forma facilitada.

Imagem 5 - Versão final do design da aplicação. Ecrãs mapa e inventário e respetivas grelhas.

Aquando do desenvolvimento da versão beta foram efetuados testes de usabilidade que revelaram novos problemas, sendo que a maior dificuldade encontrada referia-se ao botão de ajuda. Este encontrava-se no canto superior do ecrã e apresentava um tamanho reduzido dificultando a sua visualização quando os utilizadores procuravam algum elemento na interface que lhes proporcionasse assistência. Outros problemas e soluções são apresentados no Capítulo V.


Conteúdos

Como já referido no conceito do projeto a aplicação conta com duas vertentes: descoberta da universidade e interação social. Na descoberta da universidade os enigmas assumem-se como pedra basilar visto que estes encorajam os novos alunos a procurar informação sobre as várias vertentes da universidade.

Os percursos existentes na aplicação (que contêm os enigmas11) deverão ser temáticos, por exemplo arquitetura, ensino, investigação… Este facto não é um requisito no entanto é uma abordagem aconselhada permitindo ao utilizador possuir uma visão sequencial e organizada de todas as vertentes da UA.

Os enigmas neste momento disponíveis não seguem esta abordagem uma vez que foram construídos para tipificar os enigmas que poderão surgir nos diferentes percursos. Estes foram elaborados pelo grupo, com a ajuda dos orientadores, contanto com informação real e válida.

Na componente de interação social da aplicação foram desenvolvidos Avatares em 3D para que fosse possível apresentá-los através da Realidade Aumentada.

Imagem 6 - Avatares da aplicação. Da esquerda para direita Smoona, P31 X3, Mr Moustacha, Berk, Lacertilia

Aquando da criação dos avatares pretendia-se criar personagens que fossem carismáticas e que refletissem de algum modo as suas características de combate. Juntamente com o desenvolvimento destes modelos foram criadas histórias que fornecem algum contexto e robustecem as personagens. Estas histórias não se encontram disponíveis na aplicação, no entanto podem se consultadas no website de suporte.

Para além dos enigmas e avatares os itens também tiveram desenvolvimento próprio, seguindo uma linguagem gráfica diferente não sendo possível associar a imagem às suas características. Pretende-se assim transmitir a ideia de que se trata de um artefacto futurista e, tal como os avatares, cada item tem a sua história estando também relacionada com a universidade. Todos os conteúdos presentes ou relacionados com a aplicação encontram-se disponíveis em inglês e português garantindo o suporte bilingue da aplicação e facilitando o seu uso por alunos externos que usufruem da universidade como no caso de alunos do programa Erasmus.

11 Mais informação sobre a relação entre percurso, ponto de interesse e enigma pode ser encontrada no Capítulo IV, secção Sistema de Gestão de Conteúdos


Capítulo IV - Design Técnico

Demonstrador Técnico

Após a especificação do projeto foi desenvolvido um demostrador técnico12 que permitiu efetuar um teste às várias tecnologias que se pretendiam implementar. Este demonstrador englobou a utilização de leitura de QrCodes, comunicação com o servidor e apresentação de modelos em realidade aumentada.

“Após a validação do QrCode é enviado um pedido ao servidor web com o ID do mesmo recebendo em resposta o nome do modelo que deve ser apresentado e, terminado a receção dos dados, é iniciada a realidade aumentada apresentando o modelo escolhido. Todos os modelos estão integrados na aplicação sendo que o servidor apenas fornece o nome do modelo a apresentar.”

Funcionamento do demonstrador técnico, em http://uaplay.blogs.ua.sapo.pt/4857.html

O desenvolvimento deste demonstrador e os resultados alcançados tiveram uma importância crucial, uma vez que permitiu compreender que era efetivamente possível integrar e interligar todas as tecnologias pretendidas. Esta integração revelou-se um grande desafio para o grupo tendo sido necessário, no caso das bibliotecas de Realidade Aumentada e Leitura de QrCodes, interpretar o código desenvolvido por outrem, detetar as suas limitações, bem como compreender como utilizá-lo e modifica-lo de modo a conseguir o efeito pretendido.

12 Pode ser consultado um vídeo do funcionamento em http://uaplay.blogs.ua.sapo.pt/4857.html




Componentes Mapa de Navegação

Imagem 7 - Mapa de navegação com componentes desenvolvidas nas várias fases.

Esta secção tem o simples propósito de apresentar o mapa de navegação final da aplicação destacando, através de cores, as componentes desenvolvidas em cada fase do projeto. Assim as componentes assinaladas a amarelo integraram o protótipo de alta-fidelidade, a laranja integraram a versão beta e, por último, a vermelho estão assinaladas as últimas componentes desenvolvidas para a entrega do projeto. De notar que o perfil e opções não estavam originalmente previstas.

Arquitetura da Aplicação

Durante o desenvolvimento da aplicação foi necessário proceder à revisão da arquitetura da mesma. A aprendizagem que foi efetuada sobre o desenvolvimento de aplicações Android revelou que esta se apresentava pouco precisa.

A principal alteração refletiu-se na remoção do integration engine uma vez que este se apresentava num conceito demasiado abstrato não existindo realmente. Agora, os componentes principais de toda a aplicação centram-se nas Android Activities. Estas, como definidas no Android dev são:


“An Activity is an application component that provides a screen with which users can interact in order to do something (…). Each activity is given a window in which to draw its user interface. (…)”

Em http://developer.android.com/guide/components/activities.html

Sempre que necessário estas Activities requisitam dados a outros componentes da arquitetura, como por exemplo o Server Comunication Engine.

Imagem 8 - Arquitetura da aplicação.

Procedamos agora à descrição sumárias dos elementos da arquitetura compreendendo a sua importância para o sistema.

http://developer.android.com/guide/components/activities.html


Server Comunication Engine

Responsável por efetuar pedidos à API e devolver os dados em formato JSON à Activity requisitante. São submetidos os parâmetros necessários ao funcionamento do serviço da API através de “POST variables”13.

Augmented Reality Framework

Esta framework é responsável pela apresentação dos modelos 3D em realidade aumentada. Recebe, por parte da Activity do combate, quais os modelos a apresentar.

Google Maps Framework

Responsável pela apresentação do mapa no ecrã principal, sendo que esta Activity requisita ao Server Communication Engine as coordenadas do ponto a apresentar transmitindo-as posteriormente à framework. Assegura também o correto posicionamento do ponto que representa o utilizador, obtendo as suas coordenadas geográficas do sistema de GPS do terminal ou, quando este não está disponível, do Wi-fi e rede móvel.

Configuration Manager

Armazena todas as informações de configuração necessárias ao funcionamento da aplicação.

Item Manager

Assegura a gestão dos itens da aplicação (Item Normal, Item Loja, Item Peça Lendária, Item Lendário) fornecendo um conjunto de métodos para obter os seus dados.

QrCode Manager

Assume-se como controlador entre a validação de QrCodes e as ações a tomar, ou seja, assim que o validador é iniciado o QrCode Manager14 obtém os dados do QrCode e executa uma ação consoante o valor deste.

uaQuest Widget

Este componente é utilizado quando o widget da aplicação é ativado. Efetua a interação com o Server Communcation Engine e possui dois componentes que lhe permitem apresentar o widget e as notificações quando necessário.

13 Mais informação na seção ServerRequest deste mesmo capítulo. 14 Mais informação na seção Leitor de QrCodes deste mesmo capítulo.


Application Resources

Numa aplicação para sistemas Android, os recursos têm de ser organizados de forma muito específica15. Esta organização reflete-se no sistema de pastas existindo uma clara distinção entre os vários tipos de recursos.

O conjunto de pastas drawable permite armazenar imagens e ficheiros xml (ficheiro de estados, formas, etc.), sendo que o sistema irá utilizar os ficheiros mais adequados ao dispositivo. Por exemplo, quando a língua do dispositivo é portuguesa, o sistema irá procurar os ficheiros primeiramente na pasta drawable-pt e de seguida nas restantes consoante a densidade de pixéis16.

Já as pastas values armazenam todos os recursos textuais da aplicação sendo possível efetuar uma adaptação linguística com relativa facilidade.

A pasta layout, também de grande importância, armazena, como o próprio nome indica, todos os ficheiros xml que definem os layouts dos vários ecrãs.

Android Activities

Cada activity permite a apresentação de um ecrã ao utilizador existindo um total de 24: ARLauncher, Crafting, Enigma, EnigmaSuccess, FightResult, Inventory, Login, MessageNew, Messages, MessageSolo, Options, Profile, QrCodeReader, Ranking, Regist, RegistAvatar, Shop, Splash, TableFight, Trade, Tutorial, WorldMap, CaptureActivity, AugmentedModelViewerActivity.

15 Consultar esquema de diretórios no anexo 1 16 Todas as informações sobre a estrutura de pastas e possíveis “qualifiers” podem ser encontradas em http://developer.android.com/guide/topics/resources/providing-resources.html#ResourceTypes

http://developer.android.com/guide/topics/resources/providing-resources.html#ResourceTypes


API

O motor do jogo encontra-se alojado num servidor tendo sido necessário desenvolver uma API para poder efetuar interações com o mesmo. Esta é constituída por um conjunto de serviços que processam dados e devolvem uma resposta em formato JSON.

Imagem 9 - Arquitetura do servidor.

Através do Server Communication Engine da aplicação é submetido um pedido a um dos serviços fornecidos pela API obtendo uma resposta que, dependendo do código de erro terá processamentos diferentes. Todos os serviços fornecidos pela API devolvem uma reposta com pelo menos dois campos: error e exectime, sendo que este último permite monitorizar o tempo de processamento do serviço.

{ "exectime":{ "start":"04-07-2012 21:37:24.271682", "end":"04-07-2012 21:37:24.271752", "processing":"7.00950622559E-5" }, "error":{ "errorCode":"10", "errorDesc":"The API_SECRET is wrong or missing." } }

Trecho de Código 1 - Exemplo de resposta do servidor em JSON

Pode ser aqui observada uma resposta a um pedido onde não foi fornecida a API_SECRET. Este parâmetro é obrigatório permitindo limitar e proteger o acesso aos serviços. Quando o terminal processa este erro apresenta ao utilizador a informação que a aplicação em uso poderá estar desatualizada. Este mecanismo impede que utilizadores com aplicações antigas efetuem pedidos a serviços inexistentes ou alterados. Após o utilizador estar autenticado, o pedido terá de ser acompanhado do token único e identificativo do utilizador. No caso dos enigmas e informações, o pedido deverá ser acompanhado da língua do terminal permitindo a obtenção dos conteúdos no idioma correto.


/** * API userLogin * Verifica se o utilizador existe atribuindo-lhe um token * * @param apiSecret * @param username * @param password * * @responseFields * exectime: * "start", * "end", * "processing" * error: * "errorCode", * "errorDesc" * token */ http://uaquest.co.cc/API_v2/userLogin.php

Trecho de Código 2 – Documentação serviço userLogin.

O serviço userLogin fornecido pela API permite à aplicação autenticar um utilizador criando um token único que será guardado no terminal e enviado em todos os pedidos como forma de validar a sessão.

Um exemplo de outro serviço utilizado é o checkTurn este, de carácter bem mais complexo, é responsável processar o fluxo nos combates e gerir os turnos. Este serviço é requisitado ciclicamente modificando os parâmetros fornecidos permitindo que o combate se desenrole.

/** * API checkTurn * Verifica o estado atual do combate devolvendo um dos seguintes valores: * FIGHT_TURN_NOT_SET * FIGHT_TURN_USER * FIGHT_TURN_OPPONENT * FIGHT_TURN_SET_LOADING_MODELS * FIGHT_WINNER_USER * FIGHT_WINNER_OPPONENT * * Se existir um vencedor este é definido na BD * * @param apiSecret * @param token * @param fightId * @param firstData - Se true serão devolvidos os dados sobre os jogadores e avatares no combate. Usado para

inicializar as variáveis iniciais. * @param modelsLoaded - Se true indica ao sistema que os modelos foram carregados garantido alguma

sincronização entre os dois jogadores. * * @responseFields * exectime: * "start", * "end", * "processing" * error: * "errorCode","errorDesc" * * firstData == true? * firstData: * user: * "avatarId","avatarLife","avatarEnergy","name" * opponent: * "avatarId","avatarLife","avatarEnergy","name" * specialAttack * * Se for o turno do utilizador:

http://uaquest.co.cc/API_v2/userLogin.php


* attack: * "code","power","userEnergy","opponentEnergy","userLife" */ http://uaquest.co.cc/API_v2/checkTurn.php

Trecho de Código 3 - Documentação serviço checkTurn

O serviço começa por fazer uma verificação inicial de modo a averiguar o estado dos turnos, sendo que enquanto dois jogadores não estiverem registados na mesa os turnos não serão definidos. Assim que o segundo jogar entrar no combate os turnos serão definidos e, antes de verificar quem deverá jogar, o serviço estabelece se deverá devolver os dados de inicialização do combate (firstData) controlando o estado deste parâmetro. Verifica ainda se ambos os jogadores já possuem os modelos 3D carregados.

Passada esta fase inicial, o sistema verifica qual o turno em curso. Se for o turno do utilizador controla se existe algum ataque efetuado pelo oponente por processar, verificando se esse ataque levou à derrota do utilizador. Se for o turno do oponente verifica se existe um vencedor e em caso negativo indica ao dispositivo que deverá continuar a aguardar. O fluxograma seguinte permite compreender a o funcionamento deste serviço de forma mais detalhada.

http://uaquest.co.cc/API_v2/checkTurn.php


Imagem 10 - Fluxograma serviço API - checkTurn


Combate

O combate reflete uma das componentes de maior complexidade da aplicação sendo que a sua implementação acarretou muitos desafios devido ao elevado número de tecnologias utilizadas.

Esta componente tem uma forte comunicação cíclica com a API desenvolvida utilizando 6 serviços, descritos de seguida:

registForFight – Regista o utilizador na mesa de combate ocupando uma das duas posições.

checkTurn17 – Responsável pela gestão dos turnos e fluxo de combate .

processAttack – Efetua o processamento de um ataque calculando o seu valor.

processSurrender – Processa a desistência do jogador estabelecendo o vencedor e atribuindo os pontos e créditos.

timeoutWinner – Define o vencedor do combate quando o tempo de jogo disponível termina.

clearFight – Efetua uma limpeza do registo quando nenhum oponente se junta ao combate libertando a mesa para um combate sucessivo.

Ataque

Durante o combate o utilizador pode escolher entre dois tipos de ataque: normal e especial. O ataque especial requer uma certa quantidade de energia e necessita que o gesto correspondente seja desenhado. Após o utilizador efetuar esta ação o gesto é comparado com os existentes numa biblioteca obtendo a melhor correspondência.

Imagem 11 - Ataques especiais na aplicação (gestos). O primeiro é obtido através do item lendário Ytsanid, o segundo está presente em todos os avatares.

O algoritmo desenvolvido para calcular o ataque requereu algum cuidado pois era necessário ter em conta as várias características do avatar como o valor do Ataque, Defesa e velocidade18. Estas influenciam-se mutuamente modificando os valores do ataque. Existem 4 possíveis resultados do processamento do ataque originando:

• Ataque Total – A totalidade do valor de ataque do avatar é deferido sobre o oponente.

17 Explicado na secção anterior. 18 Fluxograma do algoritmo de ataque pode ser encontrado no anexo 3


• Ataque Parcialmente Defendido – O valor do ataque sofreu uma redução segundo uma fórmula explicada mais abaixo.

• Ataque Esquivado – O ataque foi esquivado não infligindo qualquer dano. • Ataque Crítico – O valor do ataque do avatar é multiplicado por 1.5 e deferido sobre o

oponente.

Começa-se por verificar se o ataque efetuado é especial ou normal. No caso de ser especial a probabilidade (em percentagem) de ser um ataque crítico aumenta de 5% para 10% e é utilizado um multiplicador de ataque associado ao próprio ataque especial. Se as probabilidades ditarem que o ataque deve ser crítico o valor deste será aumentado de 50%.

A defesa de um avatar pode influenciar o valor do ataque sendo que pode existir uma defesa parcial. Todos os ataques têm 50% de probabilidade de serem parcialmente defendidos sendo o seu valor final calculado da seguinte forma:

//Max amount of damage that can be dealt $attackMAX = $userAttack - rand(1, $opponentDefense); //$attackMax can't be less than 1/4 of $userAttack $attackMIN = 1/4*$userAttack; $attackMAX = ( $attackMAX<$attackMIN )? $attackMIN : $attackMAX;

Trecho de Código 4 – Calculo do valor de ataque considerando a defesa do oponente

A velocidade tem um papel importante na probabilidade de esquivar um ataque. Tendo em conta a diferença entre as velocidades do utilizador e oponente é calculada esta probabilidade (em percentagem):

probabilidade = (velOponente*100)/(velUtilizador *5);

Para a fórmula atual a probabilidade de esquivar um ataque é de 20% quando os valores de velocidade são iguais, sendo que a probabilidade aumentaria para 100% quando existe uma diferença entre as velocidades de 5 vezes. No entanto, para impedir combates impossíveis a probabilidade é limitada a 90%.

//calc the dodge probability $dodgeProb = ($opponentSpeed*100)/($userSpeed*5); //the probability can't be more the 90% $dodgeProb = ( $dodgeProb>90 )? 90 : $dodgeProb; if(rand(1, 100)>$dodgeProb){ //ATTACK!!! (…) }else{ //DODGED!!! (…) }

Trecho de Código 5 – Cálculo da probabilidade de esquivo considerando as velocidades dos avatares


Barras de Energia e Vida

O desenvolvimento do combate obrigou à construção de novos elementos de interface uma vez que, apesar de uma pesquisa extensiva, não se conseguiram encontrar uns que servissem o propósito. Procedeu-se assim à criação de duas novas Views19, apelidadas de LifeView e EnergyView20.

Uma vez que estas devem manter a aparência e efetuar animações tiveram de ser criadas programaticamente, sendo utilizadas coordenadas para a sua definição.

/** * Defines the paths for the energy bar */ private void preparePaths(){

Path energyPathCell = new Path(); if(invertEnergyView){

//Draw inverted energy cell (Right side usage) energyPathCell.moveTo(12*d, 0*d); energyPathCell.lineTo(12*d, 12*d); energyPathCell.lineTo(0*d, 12*d); energyPathCell.lineTo(0*d, 3*d); energyPathCell.lineTo(3*d, 0*d); energyPathCell.close();

}else{ //Draw energy cell (Left side usage) energyPathCell.moveTo(0, 0); energyPathCell.lineTo(9*d, 0*d); energyPathCell.lineTo(12*d, 3*d); energyPathCell.lineTo(12*d, 12*d); energyPathCell.lineTo(0*d, 12*d); energyPathCell.close();

} energyPath = new Path(); energyPath.addPath(energyPathCell);

//Add 7 more energy cells for(int i=0;i<7;i++){

//offset path by its size +3 energyPath.offset(15*d, 0); //add path again energyPath.addPath(energyPathCell);

} (…)

}

Trecho de Código 6 – Construção programática da barra de Energia

Estas barras são integradas no layout do combate por XML, tal como os restantes elementos já existentes no sistema Android.

<ua.ntc.uaquest.view.EnergyView android:id="@+id/fight_energy_user1" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignLeft="@+id/fight_life_user1" android:layout_below="@+id/fight_life_user1" android:layout_marginTop="5dp" uaquest:invertLifeView="true" />

Trecho de Código 7 – Inserção da barra de energia no layout do combate

19 “This class represents the basic building block for user interface components. A View occupies a rectangular area on the screen and is responsible for drawing and event handling. View is the base class for widgets, which are used to create interactive UI components (buttons, text fields, etc.).” Mais em http://developer.android.com/reference/android/view/View.html 20 Consultar exemplo em http://uaplay.blogs.ua.sapo.pt/12602.html

http://developer.android.com/reference/android/view/View.html



Assim que o combate for definido é estabelecido o valor máximo da barra atualizando-o posteriormente conforme necessário. (No caso da EnergyView são utilizados os métodos setMaxEnergy(int energy) e updateEnergy(int energy) ).

Realidade Aumentada – Problemas e Limitações

A biblioteca de realidade aumentada (AndAr) permite a apresentação dos modelos em 3D, no entanto durante o desenvolvimento foram detetados vários problemas inerentes ao seu uso.

A deteção dos markers tem de ser efetuada sobre condições ótimas sendo que ocasionalmente, e apesar da grande diferença entre estes, são confundidos apresentando os avatares nos locais errados.

Percebeu-se que os ficheiros dos avatares (Wavefront Obj21) deviam ser reduzidos a 2MB impedido a utilização de um elevado nível de detalhe. Pretendia-se também implementar animações nos modelos porém, através da análise da biblioteca, compreendeu-se que isto não seria possível desistindo desta abordagem.

Outro problema associado com esta biblioteca relaciona-se com a fluidez da mesma. Apesar do terminal utilizado no desenvolvimento (Samsung Galaxy S) possuir uma elevada capacidade de processamento, não existia fluidez na apresentação dos objetos sendo o framerate reduzido. Isto assume-se como um problema bastante sério sendo que a grande maioria do público-alvo não possui um terminal do nível do Samsung Galaxy S.

Uma outra limitação crítica refere-se ao facto da biblioteca não permitir interrupções no uso. Assim se o combate for interrompido devido à receção de uma chamada, este terá de ser reiniciado.

Por último foram ainda detetados problemas no carregamento dos modelos no Sapo A5, tornando a visualização dos avatares impossível.

Base de dados22

A base de dados representa uma parte muito importante do desenvolvimento da aplicação sendo que armazena todos os dados relativos ao jogo, e permite efetuar as interações entre utilizadores, como o caso dos combates e trocas.

Existiram algumas alterações desde a sua definição original23 e, sendo este um modelo evolutivo, esta é a sua forma final. A base de dados é composta por 5 seções representadas no diagrama. A secção verde relaciona-se com os dados relativos ao utilizador, a laranja armazena os dados dos enigmas, percursos as relações entre estes e os enigmas dos

21 Informações sobre Wavefront Obj em http://en.wikipedia.org/wiki/Wavefront_.obj_file 22 Devido às dimensões da base de dados o diagrama foi colocado online, http://fotos.ua.sapo.pt/Z2Mc1DCcg5nV3jYQkWzO/ 23 Modelo original pode ser encontrado no documento #entrega04 - Especificação Gráfica e Especificação Técnica, pg 11, em http://uaplay.blogs.ua.sapo.pt/7778.html

http://en.wikipedia.org/wiki/Wavefront_.obj_file

http://fotos.ua.sapo.pt/Z2Mc1DCcg5nV3jYQkWzO/



utilizadores, a azul claro estão representadas as tabelas de interação utilizadas nas trocas e combate, a azul-escuro apresentam-se as tabelas relacionadas com os itens e por fim, a roxo, as tabelas necessárias ao funcionamento do sistema de mensagens.

Foi igualmente necessário proceder a criação de uma View que permitisse obter as características do avatar em função dos itens possuídos pelo utilizador. Esta é denominada de avatarData.

Durante a construção da base de dados, principalmente no caso das tabelas dos enigmas e informação, teve-se o cuidado de garantir a possibilidade de adicionar a língua aos conteúdos. Desta forma, com grande facilidade os conteúdos da aplicação podem ser adaptados para múltiplos idiomas garantindo uma aplicação escalável possibilitando o seu uso em vários contextos.

ServerRequest

A aplicação tem a constante necessidade de interagir com o servidor para obter e armazenar os dados do utilizador. Esta necessidade obrigou à criação de um Server Communication Engine responsável por efetuar e tratar os pedidos à API desenvolvida. Foi assim desenvolvida a classe ServerRequest sendo uma das mais importantes de toda a aplicação.

Imagem 12 - Diagrama funcionamento ServerRequest


A classe ServerRequest nunca é utilizada diretamente sendo criada uma classe descendente que contém a interface (serverRequestResponse(JSONObject JSONData)) que recebe os dados em formato JSON provenientes do servidor. É apresentado de seguida um exemplo da implementação da classe:

private class ServerRequestExample extends ServerRequest{ public ServerRequestExample(Context context, String url) { super(context, url); } @Override public void serverRequestResponse(JSONObject JSONData) { if(JSONData != null){ //Processar dados }else{ //A resposta do servidor não pode ser convertida em JSONObject

//Por defeito a classe mostra uma Toast //Pode modificar-se o comportamento através do @Override onErrorResponse();

} } }

Trecho de Código 8 – Implementação classe ServerReques

Após ser definida a classe descendente o pedido pode ser construído e executado. É apresentado o pedido efetuado ao serviço userLogin da API:

ServerRequestLogin request = new ServerRequestLogin(Login.this, uaQuestConf.API.USER_LOGIN); request.addKeyValuePair("apiSecret", uaQuestConf.API_SECRET); request.addKeyValuePair("username", username); request.addKeyValuePair("password", password); request.executeRequestUI();

Trecho de Código 9 – Construção objeto SererRequest

Leitura de QrCodes

O QrCode Manager desempenha um papel crucial na aplicação permitindo o funcionamento de toda a componente de enigmas e garantido o acesso a outros menus como é o caso da mesa de combate e mesa de montagem.

Imagem 13 - Validação de uma tag enigma com Samsung Galaxy Gio


Sempre que o validador é acionado este obtém o valor da leitura e age em conformidade. A aplicação conta com quatro tipos de QrCodes diferentes:

• uaQuest_enigma_#(id) • uaQuest_info_#(id) • uaQuest_table_battle_p(1|2)_# (id) • uaQuest_table_craft

Utilizando expressões regulares estes são validados sendo extraídos os dados necessários como o número do jogador e o id no caso da mesa de combate.

}else if(QrCodeValue.matches("^uaQuest_table_battle_p[1|2]_#[0-9]{1,}$")){ uaQuestConf.log("QrCodeValidator: BATTLE TABLE"); //BATTLE TABLE int tableBattleID = getIdfromQrCodeValue(QrCodeValue); int tablePlayerNum = getPlayerfromQrCodeValue(QrCodeValue); (…) }

Trecho de Código 10 – Validação conteúdo QrCode para mesa de combate

Sistema de Gestão de Conteúdos

A presente aplicação encontra muita da sua essência e vive dos conteúdos que a integram. Os enigmas, sendo que podem debruçar-se sobre os projetos de investigação de determinado departamento, deverão ser atualizados quando esse mesmo projeto for terminado e outro for iniciado. O mesmo acontece com as informações presentes nos pontos de interesse.

Desta forma tornou-se importante o desenvolvimento de um sistema de gestão de conteúdos permitindo a contínua atualização e garantindo a fidedignidade da informação. A construção desta componente não tinha sido planeada no entanto o grupo considerou-a de importância elevada tendo sido desenvolvido um protótipo. Importa frisar que se trata apenas de um protótipo o qual ainda irá requerer melhorias, de qualquer forma, já é possível obter uma visão geral do seu funcionamento e operações que vai permitir.

Antes de proceder à explicação das funcionalidades do gestor de conteúdos convém explicar a forma como percurso, ponto de interesse e enigma se interligam. Estes seguem algumas premissas enumeradas de seguida:

• Um percurso é constituído por pontos de interesse numa ordem específica; • Um ponto de interesse pertence sempre, no mínimo, a um percurso; • Um enigma tem de estar sempre ligado a um ponto de interesse e um percurso. Não

podem existir enigmas iguais em percursos diferentes. • Um ponto de interesse pode possuir múltiplos enigmas que diferem consoante o

percurso;

O sistema permite gerir percursos, pontos de interesse, enigmas e informações (presentes nas tags de informação). Após criar percursos e pontos de interesse é possível relacioná-los indicando qual o percurso, o ponto de interesse e a ordem do mesmo no percurso.


Imagem 14 - Sistema de gestão de conteúdos - Adicionar pontos de interesse a percursos.

Após estarem definidos os percursos e respetivos pontos de interesse pode proceder-se à adição dos enigmas. Estes têm de ser introduzidos em português e inglês de modo a garantir o suporte bilingue da aplicação sendo ainda necessário selecionar o percurso e o ponto de interesse ao qual se pretende associar o enigma através de um menu dropdown.

Imagem 15 - Sistema de gestão de conteúdos - Adicionar enigmas

É ainda possível adicionar informações bastando fornecer o nome e conteúdo das mesmas nas duas línguas à semelhança do que acontece com os enigmas. Aquando da adição de informações ou enigmas é gerado um QrCode24 único que será posteriormente utilizado pela aplicação para obter os dados.

24 Os QrCodes são gerados através de uma API Google e integrada no gestor de conteúdos. Mais informações em https://developers.google.com/chart/infographics/docs/qr_codes

https://developers.google.com/chart/infographics/docs/qr_codes


Ainda no que diz respeito aos enigmas, um desenvolvimento futuro, passaria pela construção de um sistema de etiquetas aplicadas aos enigmas. Esta abordagem iria facilitar o agrupamento de enigmas em percursos.

Exemplificando, o enigma do CETAC.MEDIA, poderá aparecer no percurso da investigação na UA e no percurso de descoberta do DeCA. Com a utilização de etiquetas a construção dos percursos poderia ser efetuada de uma forma quase automática. Na versão atual, não é possível, o mesmo enigma pertencer a diversos percursos, no entanto o sistema poderá ser adaptado.

Widget25

A aplicação conta com um widget que permite aceder diretamente quer à aplicação quer as mensagens. A sua função principal passa por efetuar verificações periódicas sobre a existência de novas mensagens e notificar o utilizador através do sistema de notificações presente nos sistemas Android. Desta forma o utilizador pode saber, mesmo quando não está a utilizar a aplicação, se algum utilizador lhe enviou uma mensagem.

Imagem 16 - Widget da aplicação e sistema de notificações.

Este elemento, tal como o sistema de gestão de conteúdos, é apenas um protótipo e não explora por completo todas as potencialidades deste componente. De qualquer forma, permite ter uma ideia geral de como funciona, da sua utilidade e importância que pode assumir na aplicação. Um exemplo de uma funcionalidade a implementar será informar o utilizador sobre a existência de atualizações para a aplicação.

25 Definição de android widget em http://developer.android.com/guide/topics/appwidgets/index.html

http://developer.android.com/guide/topics/appwidgets/index.html


Capítulo V - Testes

Durante todo o desenvolvimento do projeto teve-se o cuidado de efetuar testes para averiguar a compatibilidade da aplicação em vários dipositivos, no entanto a versão beta contou com uma fase de testes documentada que permitiu compreender, entre outros, os problemas de usabilidade que enfraqueciam a qualidade da aplicação. Além destes testes o grupo gostaria de ter realizado um teste às componentes de combates e trocas, visto requererem a interação entre utilizadores, e ter procedido a um teste no terreno verificando como a aplicação e o utilizador se comportam numa situação de uso real.

Teste de Usabilidade

O teste de usabilidade pretendia efetivamente compreender quais as dificuldades que os utilizadores sentiam a utilizar a aplicação. Esta é portadora de alguma complexidade na sua utilização devido à variedade de tecnologias e paradigmas de interação que a compõem, desde a utilização de QrCodes, navegação em espaço real recorrendo ao GPS à utilização de elementos em realidade aumentada.

Os sistemas de ajuda da aplicação, constituídos por um tutorial explicativo antes de ecrãs importantes, como é caso o mapa-mundo, combate, trocas, montagem e um botão de ajuda nos ecrãs de mapa-mundo e enigma revelaram estar mal concebidos tendo sido o centro dos problemas.

No momento do teste o único tutorial disponível ao utilizador referia-se ao mapa-mundo e, sendo este constituído essencialmente por texto, os utilizadores não efetuaram uma leitura atenta. Neste caso a solução passou pela construção de tutoriais imagéticos e com uma componente textual muito reduzida.

Imagem 17 – Tutorial antes (em cima) e após revisão (sequência de três imagens).


Esta solução foi a aplicada a todos os outros tutoriais sendo agora constituídos por três imagens apresentadas em sequência e explicativas dos objetivos.

O botão de ajuda presente nos ecrãs de mapa-mundo e enigma apresenta uma mensagem sobreposta ao ecrã aquando do seu clique. Este ícone era demasiado pequeno e as frases não eram coerentes com as informações anteriormente apresentadas, confundindo os utilizadores no que diz respeito à diferença entre as tags de informação e tags de enigma, tendo o problema das tags sido corrigido através da adição de umas barras de cor26. O botão foi aumentado e efetuou-se uma revisão das frases existindo agora uma normalização da nomenclatura utilizada. Uma vez que os utilizadores não associaram o botão de opções do telemóvel ao surgimento de um menu, apesar de ser um comportamento standard no Android, foi acrescentada essa indicação no sistema de ajuda.

Teste de Compatibilidade

O teste de compatibilidade pretende aferir o nível de consistência da aplicação nos diferentes equipamentos com SO Android. Num equipamento deste tipo existem três variáveis a ter em consideração: a densidade do ecrã, a resolução do ecrã e a versão do sistema operativo.

Para efetuar estes testes e tendo em conta as possíveis combinações das variáveis apresentadas foram utilizados três terminais com características distintas sendo: Samsung Galaxy S, Samsung Galaxy Gio, Asus Transformer TF101. Como referido, o grupo preocupou-se em fazer testes regulares para assegurar a constante compatibilidade entre os vários equipamentos, facto que assegurou a inexistência de anomalias aquando dos testes.

Imagem 18 - Terminais utilizados. Da esquerda Samsung Galaxy S, Samsung Galaxy Gio, Asus Transformer TF101

A única ilação a tirar deste teste referiu-se à apresentação da aplicação no Asus Transformer TF101, uma vez que este difere dos restantes terminais pelo facto de ser um tablet. Neste a interface é apresentada de forma desequilibrada no entanto, uma vez que a interface não foi desenhada para este tipo de dispositivo, é um resultado perfeitamente esperado e que não compromete a integridade funcional da aplicação.

26 Consultar exemplo no anexo 4


Teste de Conteúdos

Existiu, desde o início do projeto uma preocupação com a utilização de conteúdos corretos e fidedignos tornando o teste de conteúdos importante, não só para o sucesso da aplicação, como também para o grupo. O facto de a aplicação fornecer suporte à língua portuguesa e inglesa acresceu a importância deste mesmo teste. Efetuou-se assim uma revisão de todos os conteúdos existentes na aplicação procurando erros ortográficos, de sintaxe e de coerência estando no presente momento corrigidos.

Desde a execução deste teste novos conteúdos foram adicionados à aplicação, nomeadamente novos enigmas e informações, e os itens passíveis de serem comprados através da loja. Estes conteúdos também foram validados e revistos no entanto importa referir que uma revisão geral por parte de um especialista em línguas poderia aumentar a qualidade dos mesmos, revisão esta que o grupo gostaria de ver realizada.


Capítulo VI - Manutenção e Suporte

Suporte

No website de suporte à aplicação existe uma secção que permite ao utilizador reportar erros, submeter sugestões ou enviar outro tipo de mensagem. Apesar de existir esta possibilidade de submeter mensagens no website poderia ser implementado um sistema que permitisse enviar as mesmas diretamente a partir da aplicação. Poderia ser igualmente implementado um sistema de gestão de erros na aplicação que os reportasse automaticamente aquando do acontecimento, permitindo um rastreamento e solução mais eficiente.

Manutenção

Como já referido, o sistema de gestão de conteúdos não fazia parte do nosso projeto, mas tento em conta a complexidade da relação entre conteúdos tornou-se importante a criação de um protótipo.

Num desenvolvimento futuro, um dos possíveis melhoramentos a realizar passaria pela implementação de um sistema em que qualquer utilizador conseguisse inserir enigmas, permitindo que os conteúdos crescessem com o contributo dos seus jogadores. Esta abordagem teria alguns inconvenientes sendo necessário a validação de todos os enigmas inseridos prevenindo o aparecimento de SPAM e enigmas de baixa qualidade.

Uma alternativa seria permitir o acesso apenas a elementos específicos e responsáveis de cada departamento da universidade garantindo que os enigmas seriam criados por pessoas com conhecimentos sobre o tema em questão. Isto permitiria uma correta manutenção do sistema garantindo que os utilizadores tivessem sempre novos desafios para resolver.

Sistemas de Ajuda

Quando ainda se desenvolvia o conceito do projeto não era esperado que a aplicação assumisse a presente dimensão e complexidade. Ao iniciar o desenvolvimento tronou-se visível que esta teria que possuir algum suporte para ajudar o utilizador durante uso.

Este problema encontrou solução na criação de tutoriais antes dos ecrãs considerados principais e na colocação de mensagens noutros. Com a utilização da aplicação e receção de comentários irá ser possível compreender se estes sistemas de ajuda são suficientes ou será necessário proceder à sua melhoria. O website poderá, futuramente, englobar manuais de jogo e sistemas de F.A.Q., permitindo simplificar a curva de aprendizagem da aplicação.


Divulgação

A aplicação teria de ser promovida junto do seu público-alvo, ou seja, os novos alunos da universidade de Aveiro. Isto seria conseguido abordando os alunos durante a semana das matrículas no edifício da reitoria e integrando uma utilização global da aplicação na semana de acolhimento. De modo a atingir os atuais alunos seria utilizada a newsletter da universidade conseguindo assim a divulgação desejada.

Apesar de a aplicação estar atualmente restringida à universidade de Aveiro esta poderia ser portada para outras universidades servindo o mesmo propósito, a descoberta da universidade e interação social. Assim, entrar-se-ia em contacto com outras universidades dos país tentando disseminar o uso.

Poderia inclusive ser utilizada noutros contextos de utilização fora da universidade. A título de exemplo, a sua instalação num festival poderia dinamizar o espaço, sendo necessário modificar o especto gráfico, alterar os conteúdos e adaptar o sistema de mapa.


Capítulo VII - Análise Crítica e Desenvolvimento Futuro

Agora que o desenvolvimento foi terminado é-nos possível efetuar uma reflexão crítica sobre todo o percurso e decisões que foram tomadas. Apesar de ter sido possível cumprir com os objetivos que foram propostos e ainda melhorar, restam alguns detalhes que gostaríamos de ver implementados.

É do conhecimento do grupo que a aplicação é complexa quer na construção, quer na utilização tornando-se pertinente efetuar um teste no terreno de modo a entender qual a real curva de aprendizagem da aplicação e se as ajudas ao uso são suficientes. Seria igualmente necessário efetuar um teste de usabilidade às novas componentes como é o caso do combate, trocas e montagem. Estas são importantes e torna-se essencial compreender as dificuldades dos utilizadores.

Verificou-se, ao longo do desenvolvimento, que as componentes combate e trocas pecam devido à necessidade de estar continuamente a contactar um servidor. Estas são geridas pelo motor do jogo armazenado dados numa base de dados o que resulta em atrasos e, no caso de falhas na ligação, em erros severos diminuído drasticamente a usabilidade da aplicação. Uma solução para este problema seria a utilização de uma ligação direta entre os dois terminais recorrendo por exemplo ao Bluetooth. Isto tornaria a transmissão de dados muito mais rápida diminuindo a ocorrência de falhas.

Um outro ponto a ponderar seria relativo à continuidade do jogo. Assim que o utilizador resolver todos os enigmas recebe uma congratulação, no entanto, seria pertinente estudar uma forma de permitir que o jogo continuasse indefinidamente. Apesar da facilidade de adicionar novos enigmas, poderia ser implementado, por exemplo, um sistema que permitisse ao utilizador obter itens mais fortes para o seu avatar. De qualquer forma, este representa um tópico que necessita de estudos futuros.

A aplicação foi desenvolvida à medida que os conhecimentos necessários eram adquiridos, tendo esta e o grupo evoluído conjuntamente. Desta forma existiram abordagens iniciais que não foram as mais indicadas apesar de cumprirem a sua função. Seria portanto necessário proceder a uma revisão do código construído efetuando alterações por forma a melhorar a eficiência e construção da aplicação.

Por último são apresentadas algumas funcionalidades que o grupo considera importantes e cuja implementação permite melhorar a experiência do utilizador. Aquando da resposta aos enigmas deveria ser indicado ao utilizador se esta se encontra parcialmente correta, uma vez que atualmente é suficiente uma falta de acentuação para a resposta ser considerada errada.

Relativamente aos avatares seria importante construir um sistema que facilitasse a sua adição, descarregando-os do servidor assim que novos surgissem. Deveria ainda ser estudada uma forma de utilizar animações nos mesmos durante o combate.


Para finalizar e no que diz respeito aos itens, três funcionalidades seriam importantes: possibilidade de efetuar a troca de múltiplos itens simultaneamente; desenvolver um sistema de inventário do avatar em que apenas os itens selecionados seriam equipados; criação de uma secção no gestor de conteúdos que permitisse a adição de novos itens.

As funcionalidades referidas neste capítulo, bem como as expostas ao longo de todo o documento, são importantes para o projeto sendo que o grupo gostaria de ter a possibilidade de as implementar permitindo a construção de um produto ainda mais completo.


Capítulo VIII - Conclusão

Chegando ao término do projeto o grupo considera que conseguiu cumprir com o que se tinha proposto bem como desenvolver mais componentes. O culminar de um semestre de trabalho resulta numa aplicação móvel que promete aos seus utilizadores uma nova forma de descobrir a universidade e de interagir com outros alunos.

Esta possui alguns pormenores que podem ser melhorados permitindo ao projeto crescer para um nível muito superior. De qualquer forma o grupo está orgulhoso e satisfeito com os resultados atingidos.

Existiram inúmeros desafios a ultrapassar, no entanto o grupo dedicou-se de “corpo e alma” ao projeto procurando incansavelmente até resolver um problema para encontrar outro de seguida. Um grande desejo de ver o projeto crescer junto com um boa dose de perseverança permitiram atingir o estado atual. Houve uma exploração do desconhecido, uma aventura que proporcionou ao grupo novas formas de pensar e abordar os desafios bem como inúmeros novos conhecimentos. Foram aprendidas tecnologias novas e foram aprofundados os saberes existentes sendo importante para o futuro profissional do grupo.


Bibliografia

http://creating-industrial-solutions.com/2011/06/threads-in-android-part-1-infinite-loop/ consultado a 20 de Maio 2012

http://developer.android.com/guide/components/processes-and-threads.html consultado a 20 de Maio 2012

http://android-developers.blogspot.pt/2009/05/painless-threading.html consultado a 20 de Maio 2012

http://blog.infidian.com/2008/05/02/android-tutorial-42-passing-custom-variables-via-xml-resource-files/ consultado a 24 de Maio 2012

http://www.androidcompetencycenter.com/2009/08/creatingcustomviews/ consultado a 24 de Maio 2012

http://www.yvision.com/wp-content/uploads/AROnlineMarkerGenerator.pdf consultado a 26 de Maio 2012

http://www.artoolworks.com/support/library/Creating_and_training_new_ARToolKit_markers consultado a 26 de Maio 2012

http://android-developers.blogspot.pt/2009/10/gestures-on-android-16.html consultado a 30 de Maio 2012

http://developerlife.com/tutorials/?p=343 consultado a 3 de Junho 2012

http://stackoverflow.com/questions/1555109/stop-edittext-from-gaining-focus-at-activity-startup consultado a 25 de Junho 2012

http://developer.android.com/guide/topics/ui/controls/text.html consultado a 26 de Junho 2012

http://creating-industrial-solutions.com/2011/06/threads-in-android-part-1-infinite-loop/

http://developer.android.com/guide/components/processes-and-threads.html

http://android-developers.blogspot.pt/2009/05/painless-threading.html

http://blog.infidian.com/2008/05/02/android-tutorial-42-passing-custom-variables-via-xml-resource-files/

http://blog.infidian.com/2008/05/02/android-tutorial-42-passing-custom-variables-via-xml-resource-files/

http://www.androidcompetencycenter.com/2009/08/creatingcustomviews/

http://www.yvision.com/wp-content/uploads/AROnlineMarkerGenerator.pdf

http://www.artoolworks.com/support/library/Creating_and_training_new_ARToolKit_markers

http://android-developers.blogspot.pt/2009/10/gestures-on-android-16.html

http://developerlife.com/tutorials/?p=343

http://stackoverflow.com/questions/1555109/stop-edittext-from-gaining-focus-at-activity-startup

http://stackoverflow.com/questions/1555109/stop-edittext-from-gaining-focus-at-activity-startup

http://developer.android.com/guide/topics/ui/controls/text.html


Anexos


Anexo 1 – Requisitos Funcionais do Sistema de Gestão de

Conteúdos

# Requisitos funcionais Perfis utiliza.

Administrador 1 O utilizador poderá autenticar-se no sistema de gestão de conteúdos

RNF – Após autenticação o utilizador deverá ser encaminhado para a páginas dos percursos. 2 O utilizador poderá ver os percursos existentes 3 O utilizador poderá criar novos percursos 4 O utilizador poderá editar percursos 5 O utilizador poderá apagar percursos

RNF – Deve ser apresentada uma mensagem de confirmação quando o utilizador tentar apagar um percurso.

RNF – Deve ser apresentada uma mensagem de sucesso ou erro da operação quando o utilizador editar, criar ou apagar percursos

6 O utilizador poderá ver os pontos de interesse existentes e a que percurso estão associados

7 O utilizador poderá criar pontos de interesse 8 O utilizador poderá editar os pontos de interesse 9 O utilizador poderá apagar os pontos de interesse

RNF – Deve ser apresentada uma mensagem de confirmação quando o utilizador tentar apagar um ponto de interesse.

RNF – Deve ser apresentada uma mensagem de sucesso ou erro da operação quando o utilizador editar, criar ou apagar pontos de interesse

10 O utilizador poderá adicionar pontos de interesse aos percursos 11 O utilizador poderá remover pontos de interesse dos percursos

RNF – Deve ser apresentada uma mensagem de confirmação quando o utilizador tentar remover pontos de interesse dos percursos

RNF – Deve ser apresentada uma mensagem de sucesso ou erro da operação quando o utilizador adicionar ou remover pontos de interesse dos percursos

12 O utilizador poderá ver uma lista dos vários enigmas existentes nos vários percursos 13 O utilizador poderá criar novos enigmas 14 O utilizador poderá editar enigmas 15 O utilizador poderá apagar enigmas

RNF – Deve ser apresentada uma mensagem de confirmação quando o utilizador tentar apagar um enigma

RNF – Deve ser apresentada uma mensagem de sucesso ou erro da operação quando o utilizador editar, criar ou apagar enigmas


16 O utilizador poderá ver a lista de informações existente 17 O utilizador poderá criar novas informações 18 O utilizador poderá editar informações 19 O utilizador poderá apagar informações

RNF – Deve ser apresentada uma mensagem de confirmação quando o utilizador tentar apagar uma informação

RNF – Deve ser apresentada uma mensagem de sucesso ou erro da operação quando o utilizador editar, criar ou apagar enigmas


Anexo 2 – Sistema de Pastas da Aplicação Android


Anexo 3 – Fluxograma Processamento Ataque


Anexo 4 – Tags de Enigma e Tags de Informação

A tag de enigma é apresentada com duas faixas laterais vermelhas e permite o acesso ao enigma do ponto de interesse.

Uma tag de informação é caracterizada pelas faixas verdes e indica o ponto de interesse a que se refere e, entre parêntesis, o tema que trata.

projeto uaquest - relatório final

Documents