You are on page 1of 51

Agradecimentos

Este projeto contou com o apoio de muitas pessoas, no entanto existem algumas que merecem um agradecimento especial. Agradecemos Oficina do Telemvel, na pessoa de Marcolino Melo, pelo emprstimo de um terminal mvel que suportou o desenvolvimento do projeto. A Bruno Silva, pelo suporte prestado e pelo emprstimo de outro terminal. Aos nossos orientadores, professores Helder Caixinha e Licnio 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 relatrio do projeto uaQuest, sendo desenvolvido para a unidade curricular de Projeto do 3 ano da Licenciatura em Novas Tecnologias da Comunicao pela Universidade de Aveiro. Este apresenta-se como o culminar de um semestre de trabalho e pretende apresentar uma reflexo sobre todo o trabalho desenvolvido. O documento sustentado em oito captulos sendo efetuada uma anlise s vrias fases do projeto, desde a sua conceo at ao final do desenvolvimento, justificando opes tomadas e funcionalidades alteradas.

ndice
Captulo I - Introduo ............................................................................................................................. 9 Captulo II - Estudos Preliminares ........................................................................................................ 10 Estado da Arte ..................................................................................................................................... 10 Viabilidade Tcnica ............................................................................................................................. 11 Captulo III - Design Funcional .............................................................................................................. 13 Requisitos Funcionais ......................................................................................................................... 13 Design Grfico ..................................................................................................................................... 14 Contedos ............................................................................................................................................ 18 Captulo IV - Design Tcnico ................................................................................................................. 19 Demonstrador Tcnico ....................................................................................................................... 19 Componentes mapa de navegao ................................................................................................ 20 Arquitetura da Aplicao ................................................................................................................... 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 Limitaes .................................................................... 31 Base de dados ..................................................................................................................................... 31 ServerRequest ...................................................................................................................................... 32 Leitura de QrCodes ............................................................................................................................. 33 Sistema de Gesto de Contedos.................................................................................................... 34 Widget ................................................................................................................................................... 36 Captulo V - Testes .................................................................................................................................. 37

Teste de usabilidade ........................................................................................................................... 37 Teste de compatibilidade .................................................................................................................. 38 Teste de contedos............................................................................................................................. 39 Captulo VI - Manuteno e suporte ................................................................................................... 40 Suporte .................................................................................................................................................. 40 Manuteno ......................................................................................................................................... 40 Sistemas de ajuda............................................................................................................................... 40 Divulgao ............................................................................................................................................ 41 Captulo VII - Anlise Crtica e desenvolvimento futuro .................................................................. 42 Captulo VIII - Concluso ....................................................................................................................... 44 Bibliografia ............................................................................................................................................... 45 Anexos....................................................................................................................................................... 46 Anexo 1 Requisitos funcionais do sistema de gesto de contedos ..................................... 47 Anexo 2 Sistema de pastas aplicao Android .......................................................................... 49 Anexo 3 Fluxograma processamento ataque............................................................................. 50 Anexo 4 Tags de enigma e tags de informao ........................................................................ 51

uaQuest Relatrio do projeto

Captulo I - Introduo
O projeto uaQuest pretende reformular a forma como os novos alunos descobrem a Universidade de Aveiro. Atravs de um jogo de descoberta e resoluo de enigmas, o projeto visa facilitar a integrao dos novos alunos na vida acadmica, contribuindo para a socializao destes, e promover a UA (o seu ensino e a sua investigao). Utilizando as duas vertentes do projeto, a da explorao e a da interao 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, investigao Assim, dirigindo-se ao ponto de interesse e procurando tags de informao para ajudar na resposta, os novos alunos tm uma experincia imersiva, conhecendo os locais em primeira pessoa. A componente de interao/socializao assegurada pelos avatares da aplicao, que interagem com outros atravs de combates virtuais, e pelas funcionalidades de trocas e mensagens. A prestao dos avatares nos combates pode ser melhorada atravs de itens obtidos com a resoluo 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 slida e detalhada. Devido evoluo do prprio projeto existiram funcionalidades, inicialmente propostas, que tiveram de ser revistas e alteradas mas que no afetaram o conceito por detrs de toda a aplicao. O presente documento comea por expor os estudos preliminares que foram necessrios ao desenvolvimento do projeto, seguindo para o design funcional onde efetuada uma apreciao sobre os requisitos originalmente definidos e os efetivamente desenvolvidos, o desenvolvimento do grafismo da aplicao e os contedos existentes. Segue-se o design tcnico que engloba a arquitetura, a construo da API, a base de dados, o sistema de gesto de contedos e as componentes mais importantes da aplicao. So de seguida apresentados os testes efetuados e os benefcios resultantes para a aplicao, bem como a estratgia de manuteno, suporte e divulgao da aplicao. Por ltimo efetuada uma anlise crtica do desenvolvimento apresentando possveis funcionalidades adicionais a serem implementadas.

uaQuest Relatrio do projeto

10

Captulo II - Estudos Preliminares


Estado da Arte
Aps a definio do conceito 1 subjacente aplicao, procedeu-se a uma anlise do estado da arte de modo a demonstrar que tipos de aplicaes, com caractersticas similares s pretendidas, existiam no mercado. Desta forma efetuou-se uma pesquisa tendo em conta alguns termos chave como Realidade Aumentada, jogos multijogador e geolocalizao. Esta pesquisa possuiu duas frentes de ataque: a primeira pretendia compreender o que existe no mercado, enquanto a segunda procurava inspirao nas formas de interao com o utilizador e no aspeto grfico da aplicao em si. Pretendia-se igualmente compreender se existiam aplicaes que utilizassem as trs componentes j referidas. No foram encontradas aplicaes com tal interligao de componentes, no entanto verificaram-se algumas muito robustas nas vrias componentes mas de forma independente. A ttulo 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 geolocalizao transformando a posio do jogador numa rea a defender. 2 Concluiu-se que, muito provavelmente, no existia nenhuma aplicao que preenchesse todos os termos chave procurados, no entanto a pesquisa teve uma importncia elevada para o desenvolvimento do projeto, permitindo compreender, ainda que de forma leviana, alguns dos paradigmas utilizados aquando da utilizao destas tecnologias. Atravs da integrao das vrias tecnologias esta aplicao apresenta-se como um projeto inovador 3 tendo o objetivo de se transformar num jogo interativo e dinmico permitindo aos alunos descobrir a Universidade de Aveiro. Com o desenvolvimento do projeto surgiu a necessidade de efetuar investigao adicional sobre esta e outras temticas, como por exemplo avatares em 3D, formas de desenvolvimento de aplicaes Android nativas e prticas de apresentao de informao em ambientes Android, de forma a obter inspirao e compreender como construir uma aplicao coerente e funcional.

Consultar briefing no documento #entrega01 - Estado da Arte e Briefing, pg 29, em http://uaplay.blogs.ua.sapo.pt/1114.html 2 Mais informaes e outras aplicaes estudadas podem ser encontradas em http://uaplay.blogs.ua.sapo.pt/1114.html 3 Consultar anlise SWOT no documento #entrega01 - Estado da Arte e Briefing, pg 26, em http://uaplay.blogs.ua.sapo.pt/1114.html

uaQuest Relatrio do projeto

11

Viabilidade Tcnica
Uma vez que a aplicao que nos propusemos a desenvolver possua diversas tecnologias envolvidas, existindo algumas das quais o grupo no tinha conhecimento, foi necessrio efetuar um estudo de viabilidade tcnica extensivo para compreender se o conceito criado tinha a possibilidade de um real desenvolvimento. O projeto possuiu duas vertentes de desenvolvimento correspondendo aplicao mvel para sistemas Android e o motor de jogo, constitudo pela API e seus servios, 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 gesto de base de dados. Aps o desenvolvimento do projeto o grupo concluiu que a escolha das tecnologias foi corretamente efetuada. A comunidade que utiliza estas tecnologias e a documentao que produzida desempenharam um papel muito importante para esta concluso, sendo que os problemas encontrados ao longo do desenvolvimento tiveram uma rpida resoluo devido a esta mesma comunidade e documentao. J no que se refere aplicao mvel, esta foi desenvolvida para sistemas Android, utilizado o prprio SDK disponibilizado pelo Google. Desta forma, recorrendo linguagem JAVA, foi possvel a integrao com as bibliotecas de leitura de QrCodes (ZXing) e de Realidade Aumentada (AndAr). O grupo tinha preferncia 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 no ter conhecimentos prvios sobre a construo de aplicaes para esta plataforma, decidiu aceitar o desafio obtendo uma grande satisfao com os resultados alcanados. Procedamos agora para as especificidades da aplicao, nomeadamente as bibliotecas de leitura de QrCodes e Realidade Aumentada utilizadas. A deteo e interpretao dos QrCodes representa uma componente fulcral da aplicao permitindo o acesso aos enigmas e informaes existentes nos pontos de interesse, e o acesso a funcionalidades adicionais como a montagem, loja, combate e trocas 4. Pretendiase que esta leitura fosse efetuada internamente pela aplicao sem ter de recorrer a aplicaes de terceiros e obrigar o utilizador a instalaes adicionais. A biblioteca ZXing permitiu cumprir este objetivo de uma forma facilitada, sendo que atravs da interpretao de um exemplo fornecido 5 foi possvel a adaptao para os propsitos do projeto. O grupo pretendia utilizar a Realidade Aumentada em vrias componentes da aplicao, tornando o uso desta mais interessante para o utilizador, no entanto devido a restries tcnicas tal no foi possvel. Desta forma, a realidade aumentada, foi aplicada apenas no combate e, no entanto, carece de algumas funcionalidades como, por exemplo, no permitir animaes, detetar os markers de forma incorreta e falta de fluidez.
Mais informao sobre a leitura de QrCodes pode ser encontrada no Captulo IV, seco Combate, subseo Leitura de QrCodes. 5 Programa exemplo em http://code.google.com/p/zxing/downloads/detail?name=ZXing-2.0.zip&can=2
4

uaQuest Relatrio do projeto

12

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 adaptao mais fcil. Fazendo uma anlise reflexiva, podemos agora compreender que esta escolha no foi a mais correta uma vez que a biblioteca possui vrias limitaes explicadas em detalhe no Captulo IV, seo Combate, subseo Realidade Aumentada Problemas e Limitaes. Uma alternativa mais apropriada seria a biblioteca Qualcomm AR (Vuforia), apresentando, data da entrega do projeto com uma comunidade mais desenvolvida e uma documentao um pouco mais detalhada, permitindo assim uma melhor compreenso sobre a sua utilizao. No entanto aquando do desenvolvimento a biblioteca AndAr era mais acessvel devido aos conhecimentos do grupo sobre as tecnologias utilizadas. Para a construo do ecr principal (mapa-mundo) apresentado a posio do jogador e os pontos de interesse no seu apsito local foi utilizada a API do Google Maps, cuja implementao foi executada sem qualquer problema revelando-se uma escolha adequada para o que era pretendido. A utilizao da aplicao 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 aplicao est, neste momento, restrito prpria universidade, a utilizao deste sistema faria todo o sentido, no entanto devido a restries de acesso ao mesmo, no foi possvel proceder sua implementao tendo-se adotado o sistema de registo tradicional, requerendo a insero dos dados por parte do utilizador. Porm, se a aplicao for realmente integrada na universidade, poder-se- adaptar para utilizar este sistema. Para utilizao noutros contextos novas solues, alm do registo tradicional, teriam de ser pensadas. Originalmente tinha sido pensada a hiptese da aplicao possuir uma banda sonora, no entanto esta foi suspensa de modo a dar prioridade ao desenvolvimento de outras componentes. No entanto, no foi descartada correspondendo a um desenvolvimento futuro. Aparte a questo da banda sonora e registo no existiram outras alteraes no que diz respeito ao estudo de viabilidade tcnica efetuado inicialmente. Importa tambm referir o cuidado do grupo em ter efetuado uma pesquisa bastante exaustiva permitindo escolhas fundamentadas e que se verificaram corretas. Um ponto originalmente no ponderado pelo grupo refere-se ao desenvolvimento da aplicao utilizando uma framework como por exemplo Titanium. No momento atual, e aps todo o trabalho efetuado j possvel tecer uma opinio sobre este tema. O desenvolvimento da aplicao com recurso linguagem nativa permitiu ter um controlo muito superior sobre as prestaes da mesma, bem como integrar, da forma pretendida, as bibliotecas utilizadas. Permitiu, de igual modo, compreender o ciclo de vida e a estrutura/organizao das aplicaes Android adquirindo um conhecimento mais aprofundado sobre o funcionamento deste sistema, facto desejado pelo grupo e que pode trazer inmeros benefcios no futuro profissional do mesmo.

uaQuest Relatrio do projeto

13

Captulo III - Design Funcional


Requisitos Funcionais
Os requisitos funcionais do projeto, organizados em dois grupos: aplicao e website, foramse modificando com a evoluo do mesmo e existem alteraes que so importantes referir. Originalmente o website permitia a interao com os dados da aplicao atravs da visualizao da tabela classificativa, das mensagens e do inventrio, servindo assim de suporte aplicao em si. Uma vez que se deixou de permitir ao utilizador efetuar o registo, todos os requisitos que descendiam da possibilidade de registo e autenticao no website caram por terra 6. Estas funcionalidades foram restringidas ao terminal mvel uma vez que mais prtico para o utilizador ter acesso a todas as funcionalidades no mesmo sistema. O website permitia ainda a consulta do inventrio de outro jogador no entanto este requisito foi eliminado por dois motivos: em primeiro lugar pretendia-se que existisse interao real entre os vrios jogadores para, por exemplo, obter informao sobre os itens que cada um possui, em segundo para impedir que todos os utilizadores conhecessem o inventrio de outro sem a sua autorizao. 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 recuperao e alterao da password escolhida. Funcionalidades originalmente trascuradas pelo grupo mas que rapidamente se impuseram como imprescindveis devido a representarem uma necessidade real. O website funciona agora como suporte aplicao permitindo a sua obteno e apresentando informaes adicionais como a histria dos avatares. Para dar mais consistncia ao projeto foi criado um sistema de gesto de contedos que, apesar de ser um prottipo, permite gerir os percursos, pontos de interesse, enigmas e informao. Estes novos requisitos foram adicionados ao projeto e podem ser consultados no Anexo 1. No que diz respeito aplicao mvel os requisitos inicialmente definidos foram atingidos e foram adicionadas novas funcionalidades para melhorar a experincia do utilizador. Aparte da j referida funcionalidade de recuperao de password foi adicionada a possibilidade de consultar o prprio perfil. Este apresenta a posio atual do utilizador, as caractersticas atualizadas do avatar (contabilizando os efeitos dos itens possudos), bem como os ataques especiais 7 do mesmo. Foi ainda desenvolvido um widget cujos detalhes podem ser encontrados no Captulo IV, seo Widget.
Consultar o documento #entrega02 - Requisitos Funcionais e Viabilidade Tcnica, 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 lendrios. Cada ataque especial tem um custo energtico e um multiplicador que ir ter influncia sobre o ataque original do avatar. Estes diferem dos ataques normais uma vez que para os utilizar tem de ser desenhado o gesto correspondente.
6

uaQuest Relatrio do projeto

14

Imagem 1 - Mapa de navegao com componentes no previstas.

A imagem 1 representa o mapa de navegao da aplicao atualizado para o momento atual, sendo as componentes assinaladas a laranja as funcionalidades que foram adicionadas aps a definio dos requisitos. Originalmente o website iria conter um manual do jogo explicativo que os utilizadores teriam de consultar para compreender como utilizar a aplicao. Esta soluo possua vrios problemas sendo que a aplicao perdia o seu carcter mvel se fosse sempre necessrio possuir um computador para aceder ao manual. Este facto, juntamente com a complexidade da aplicao obrigou a adotar uma nova soluo que passou pela criao te pequenos tutoriais inseridos antes de ecrs crticos. Em suma, o grupo no se limitou a desenvolver o que originalmente tinha proposto mas teve o cuidado de melhorar o projeto tornando-o mais slido, completo e orientado para o utilizador.

Design Grfico
Para o projeto foi necessrio criar uma imagem marcante, possuindo um design apelativo, funcional e um logtipo fcil de memorizar. Antes de proceder definio do design foi necessrio alterar o nome originalmente definido para um mais indicado s especificidades do projeto. uaQuest foi o nome escolhido 8 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

uaQuest Relatrio do projeto

15

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 aplicao assumisse um estilo futurista, de modo a transmitir os ideais de tecnologia e inovao associados universidade. Foi, desta forma, efetuada uma pesquisa com o objetivo de compreender qual a melhor abordagem a tomar. As interfaces dos vrios elementos presentes no Tron e Iron Man serviram este propsito. Estas apresentam uma imagem muito futurista possuindo alguns elementos decorativos de modo a tornar a interface mais apelativa e tecnolgica. Estado definidas as guias base do design adotado foi construda a primeira verso grfica.

Imagem 2 - Primeira verso do design da aplicao. Ecrs mapa e inventrio e respetivas grelhas.

O azul uaQuest e ao branco esto sempre presentes tanto na aplicao como no logtipo, e assumem uma elevada importncia na aplicao devido aos valores que transmitem: paz, sucesso, tranquilidade, compreenso, 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 aplicao da interface no dispositivo mvel, e aps algumas discusses, conclui-se que existia a necessidade de revisitar a especificao grfica efetuando algumas alteraes.

Mais informaes sobre o nome no documento #entrega04 - Especificao Grfica, pg 6, em http://uaplay.blogs.ua.sapo.pt/7778.html 10 Consultar documento #entrega04 - Especificao Grfica, pg 7, em http://uaplay.blogs.ua.sapo.pt/7778.html

uaQuest Relatrio do projeto

16

Estas passaram pela remoo 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 sensao de que aplicao estava a realizar alguma tarefa em segundo plano. Nos vrios ecrs existia tambm uma moldura com o intuito de tornar a aplicao numa janela para o futuro, no entanto esta apenas diminua o espao disponvel no acrescentando valor. Quando a interface foi aplicada num terminal apresentava-se demasiado pesada e cansativa. Com a remoo dos elementos j referidos tronou-se mais leve e limpa continuando a transmitir os valores pretendidos inicialmente.

Imagem 3 - Segunda verso do design da aplicao. Ecrs mapa e inventrio e respetivas grelhas.

Mesmo com as alteraes j realizadas continuaram a existir problemas, relacionadas com a usabilidade da aplicao. Quando a aplicao era utilizada pela primeira vez surgiram dvidas em relao aos botes e aos rtulos existentes. A aparncia dos mesmos era similar levando os utilizadores a considerar os rtulos como botes, como pode ser compreendido pela imagem abaixo. Para a resoluo deste problema foi criada uma barra na parte superior do ecr contendo os rtulos deixando os botes com um pequeno tringulo branco no canto inferior direito.

uaQuest Relatrio do projeto

17

Imagem 4 - Evoluo dos botes (1 linha) e rtulos (2 linha)

Foi desta forma definido o que seria a linha grfica de toda a aplicao, permitindo continuar o desenvolvimento dos restantes ecrs de uma forma facilitada.

Imagem 5 - Verso final do design da aplicao. Ecrs mapa e inventrio e respetivas grelhas.

Aquando do desenvolvimento da verso beta foram efetuados testes de usabilidade que revelaram novos problemas, sendo que a maior dificuldade encontrada referia-se ao boto de ajuda. Este encontrava-se no canto superior do ecr e apresentava um tamanho reduzido dificultando a sua visualizao quando os utilizadores procuravam algum elemento na interface que lhes proporcionasse assistncia. Outros problemas e solues so apresentados no Captulo V.

uaQuest Relatrio do projeto

18

Contedos
Como j referido no conceito do projeto a aplicao conta com duas vertentes: descoberta da universidade e interao social. Na descoberta da universidade os enigmas assumem-se como pedra basilar visto que estes encorajam os novos alunos a procurar informao sobre as vrias vertentes da universidade. Os percursos existentes na aplicao (que contm os enigmas11) devero ser temticos, por exemplo arquitetura, ensino, investigao Este facto no um requisito no entanto uma abordagem aconselhada permitindo ao utilizador possuir uma viso sequencial e organizada de todas as vertentes da UA. Os enigmas neste momento disponveis no seguem esta abordagem uma vez que foram construdos para tipificar os enigmas que podero surgir nos diferentes percursos. Estes foram elaborados pelo grupo, com a ajuda dos orientadores, contanto com informao real e vlida. Na componente de interao social da aplicao foram desenvolvidos Avatares em 3D para que fosse possvel apresent-los atravs da Realidade Aumentada.

Imagem 6 - Avatares da aplicao. Da esquerda para direita Smoona, P31 X3, Mr Moustacha, Berk, Lacertilia

Aquando da criao dos avatares pretendia-se criar personagens que fossem carismticas e que refletissem de algum modo as suas caractersticas de combate. Juntamente com o desenvolvimento destes modelos foram criadas histrias que fornecem algum contexto e robustecem as personagens. Estas histrias no se encontram disponveis na aplicao, no entanto podem se consultadas no website de suporte. Para alm dos enigmas e avatares os itens tambm tiveram desenvolvimento prprio, seguindo uma linguagem grfica diferente no sendo possvel associar a imagem s suas caractersticas. Pretende-se assim transmitir a ideia de que se trata de um artefacto futurista e, tal como os avatares, cada item tem a sua histria estando tambm relacionada com a universidade. Todos os contedos presentes ou relacionados com a aplicao encontram-se disponveis em ingls e portugus garantindo o suporte bilingue da aplicao e facilitando o seu uso por alunos externos que usufruem da universidade como no caso de alunos do programa Erasmus.

11

Mais informao sobre a relao entre percurso, ponto de interesse e enigma pode ser encontrada no Captulo IV, seco Sistema de Gesto de Contedos

uaQuest Relatrio do projeto

19

Captulo IV - Design Tcnico


Demonstrador Tcnico
Aps a especificao do projeto foi desenvolvido um demostrador tcnico 12 que permitiu efetuar um teste s vrias tecnologias que se pretendiam implementar. Este demonstrador englobou a utilizao de leitura de QrCodes, comunicao com o servidor e apresentao de modelos em realidade aumentada. Aps a validao 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 receo dos dados, iniciada a realidade aumentada apresentando o modelo escolhido. Todos os modelos esto integrados na aplicao sendo que o servidor apenas fornece o nome do modelo a apresentar.
Funcionamento do demonstrador tcnico, em http://uaplay.blogs.ua.sapo.pt/4857.html

O desenvolvimento deste demonstrador e os resultados alcanados tiveram uma importncia crucial, uma vez que permitiu compreender que era efetivamente possvel integrar e interligar todas as tecnologias pretendidas. Esta integrao revelou-se um grande desafio para o grupo tendo sido necessrio, no caso das bibliotecas de Realidade Aumentada e Leitura de QrCodes, interpretar o cdigo desenvolvido por outrem, detetar as suas limitaes, bem como compreender como utiliz-lo e modifica-lo de modo a conseguir o efeito pretendido.

12

Pode ser consultado um vdeo do funcionamento em http://uaplay.blogs.ua.sapo.pt/4857.html

uaQuest Relatrio do projeto

20

Componentes Mapa de Navegao

Imagem 7 - Mapa de navegao com componentes desenvolvidas nas vrias fases.

Esta seco tem o simples propsito de apresentar o mapa de navegao final da aplicao destacando, atravs de cores, as componentes desenvolvidas em cada fase do projeto. Assim as componentes assinaladas a amarelo integraram o prottipo de alta-fidelidade, a laranja integraram a verso beta e, por ltimo, a vermelho esto assinaladas as ltimas componentes desenvolvidas para a entrega do projeto. De notar que o perfil e opes no estavam originalmente previstas.

Arquitetura da Aplicao
Durante o desenvolvimento da aplicao foi necessrio proceder reviso da arquitetura da mesma. A aprendizagem que foi efetuada sobre o desenvolvimento de aplicaes Android revelou que esta se apresentava pouco precisa. A principal alterao refletiu-se na remoo do integration engine uma vez que este se apresentava num conceito demasiado abstrato no existindo realmente. Agora, os componentes principais de toda a aplicao centram-se nas Android Activities. Estas, como definidas no Android dev so:

uaQuest Relatrio do projeto

21

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 necessrio estas Activities requisitam dados a outros componentes da arquitetura, como por exemplo o Server Comunication Engine.

Imagem 8 - Arquitetura da aplicao.

Procedamos agora descrio sumrias dos elementos da arquitetura compreendendo a sua importncia para o sistema.

uaQuest Relatrio do projeto

22

Server Comunication Engine


Responsvel por efetuar pedidos API e devolver os dados em formato JSON Activity requisitante. So submetidos os parmetros necessrios ao funcionamento do servio da API atravs de POST variables 13.

Augmented Reality Framework


Esta framework responsvel pela apresentao dos modelos 3D em realidade aumentada. Recebe, por parte da Activity do combate, quais os modelos a apresentar.

Google Maps Framework


Responsvel pela apresentao 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 tambm o correto posicionamento do ponto que representa o utilizador, obtendo as suas coordenadas geogrficas do sistema de GPS do terminal ou, quando este no est disponvel, do Wi-fi e rede mvel.

Configuration Manager
Armazena todas as informaes de configurao necessrias ao funcionamento da aplicao.

Item Manager
Assegura a gesto dos itens da aplicao (Item Normal, Item Loja, Item Pea Lendria, Item Lendrio) fornecendo um conjunto de mtodos para obter os seus dados.

QrCode Manager
Assume-se como controlador entre a validao de QrCodes e as aes a tomar, ou seja, assim que o validador iniciado o QrCode Manager 14 obtm os dados do QrCode e executa uma ao consoante o valor deste.

uaQuest Widget
Este componente utilizado quando o widget da aplicao ativado. Efetua a interao com o Server Communcation Engine e possui dois componentes que lhe permitem apresentar o widget e as notificaes quando necessrio.

13 14

Mais informao na seo ServerRequest deste mesmo captulo. Mais informao na seo Leitor de QrCodes deste mesmo captulo.

uaQuest Relatrio do projeto

23

Application Resources
Numa aplicao para sistemas Android, os recursos tm de ser organizados de forma muito especfica 15. Esta organizao reflete-se no sistema de pastas existindo uma clara distino entre os vrios 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 lngua do dispositivo portuguesa, o sistema ir procurar os ficheiros primeiramente na pasta drawable-pt e de seguida nas restantes consoante a densidade de pixis16. J as pastas values armazenam todos os recursos textuais da aplicao sendo possvel efetuar uma adaptao lingustica com relativa facilidade. A pasta layout, tambm de grande importncia, armazena, como o prprio nome indica, todos os ficheiros xml que definem os layouts dos vrios ecrs.

Android Activities
Cada activity permite a apresentao 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 16

Consultar esquema de diretrios no anexo 1 Todas as informaes sobre a estrutura de pastas e possveis qualifiers podem ser encontradas em http://developer.android.com/guide/topics/resources/providing-resources.html#ResourceTypes

uaQuest Relatrio do projeto

24

API
O motor do jogo encontra-se alojado num servidor tendo sido necessrio desenvolver uma API para poder efetuar interaes com o mesmo. Esta constituda por um conjunto de servios que processam dados e devolvem uma resposta em formato JSON.

Imagem 9 - Arquitetura do servidor.

Atravs do Server Communication Engine da aplicao submetido um pedido a um dos servios fornecidos pela API obtendo uma resposta que, dependendo do cdigo de erro ter processamentos diferentes. Todos os servios 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 servio.
{ "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 Cdigo 1 - Exemplo de resposta do servidor em JSON

Pode ser aqui observada uma resposta a um pedido onde no foi fornecida a API_SECRET. Este parmetro obrigatrio permitindo limitar e proteger o acesso aos servios. Quando o terminal processa este erro apresenta ao utilizador a informao que a aplicao em uso poder estar desatualizada. Este mecanismo impede que utilizadores com aplicaes antigas efetuem pedidos a servios inexistentes ou alterados. Aps o utilizador estar autenticado, o pedido ter de ser acompanhado do token nico e identificativo do utilizador. No caso dos enigmas e informaes, o pedido dever ser acompanhado da lngua do terminal permitindo a obteno dos contedos no idioma correto.

uaQuest Relatrio do projeto

25

/** * 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 Cdigo 2 Documentao servio userLogin.

O servio userLogin fornecido pela API permite aplicao autenticar um utilizador criando um token nico que ser guardado no terminal e enviado em todos os pedidos como forma de validar a sesso. Um exemplo de outro servio utilizado o checkTurn este, de carcter bem mais complexo, responsvel processar o fluxo nos combates e gerir os turnos. Este servio requisitado ciclicamente modificando os parmetros 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 sero devolvidos os dados sobre os jogadores e avatares no combate. Usado para inicializar as variveis iniciais. * @param modelsLoaded - Se true indica ao sistema que os modelos foram carregados garantido alguma sincronizao 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:

uaQuest Relatrio do projeto

26

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

* attack: * "code","power","userEnergy","opponentEnergy","userLife" */

Trecho de Cdigo 3 - Documentao servio checkTurn

O servio comea por fazer uma verificao inicial de modo a averiguar o estado dos turnos, sendo que enquanto dois jogadores no estiverem registados na mesa os turnos no sero definidos. Assim que o segundo jogar entrar no combate os turnos sero definidos e, antes de verificar quem dever jogar, o servio estabelece se dever devolver os dados de inicializao do combate (firstData) controlando o estado deste parmetro. 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 servio de forma mais detalhada.

uaQuest Relatrio do projeto

27

Imagem 10 - Fluxograma servio API - checkTurn

uaQuest Relatrio do projeto

28

Combate
O combate reflete uma das componentes de maior complexidade da aplicao sendo que a sua implementao acarretou muitos desafios devido ao elevado nmero de tecnologias utilizadas. Esta componente tem uma forte comunicao cclica com a API desenvolvida utilizando 6 servios, descritos de seguida: registForFight Regista o utilizador na mesa de combate ocupando uma das duas posies. checkTurn 17 Responsvel pela gesto dos turnos e fluxo de combate . processAttack Efetua o processamento de um ataque calculando o seu valor. processSurrender Processa a desistncia do jogador estabelecendo o vencedor e atribuindo os pontos e crditos. timeoutWinner Define o vencedor do combate quando o tempo de jogo disponvel 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. Aps o utilizador efetuar esta ao o gesto comparado com os existentes numa biblioteca obtendo a melhor correspondncia.

Imagem 11 - Ataques especiais na aplicao (gestos). O primeiro obtido atravs do item lendrio Ytsanid, o segundo est presente em todos os avatares.

O algoritmo desenvolvido para calcular o ataque requereu algum cuidado pois era necessrio ter em conta as vrias caractersticas do avatar como o valor do Ataque, Defesa e velocidade 18. Estas influenciam-se mutuamente modificando os valores do ataque. Existem 4 possveis resultados do processamento do ataque originando: Ataque Total A totalidade do valor de ataque do avatar deferido sobre o oponente.

17 18

Explicado na seco anterior.

Fluxograma do algoritmo de ataque pode ser encontrado no anexo 3

uaQuest Relatrio do projeto

29

Ataque Parcialmente Defendido O valor do ataque sofreu uma reduo segundo uma frmula explicada mais abaixo. Ataque Esquivado O ataque foi esquivado no infligindo qualquer dano. Ataque Crtico O valor do ataque do avatar multiplicado por 1.5 e deferido sobre o oponente.

Comea-se por verificar se o ataque efetuado especial ou normal. No caso de ser especial a probabilidade (em percentagem) de ser um ataque crtico aumenta de 5% para 10% e utilizado um multiplicador de ataque associado ao prprio ataque especial. Se as probabilidades ditarem que o ataque deve ser crtico 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 tm 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 Cdigo 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 diferena entre as velocidades do utilizador e oponente calculada esta probabilidade (em percentagem):
probabilidade = (velOponente*100)/(velUtilizador *5);

Para a frmula atual a probabilidade de esquivar um ataque de 20% quando os valores de velocidade so iguais, sendo que a probabilidade aumentaria para 100% quando existe uma diferena entre as velocidades de 5 vezes. No entanto, para impedir combates impossveis 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 Cdigo 5 Clculo da probabilidade de esquivo considerando as velocidades dos avatares

uaQuest Relatrio do projeto

30

Barras de Energia e Vida


O desenvolvimento do combate obrigou construo de novos elementos de interface uma vez que, apesar de uma pesquisa extensiva, no se conseguiram encontrar uns que servissem o propsito. Procedeu-se assim criao de duas novas Views 19, apelidadas de LifeView e EnergyView 20. Uma vez que estas devem manter a aparncia e efetuar animaes tiveram de ser criadas programaticamente, sendo utilizadas coordenadas para a sua definio.
/** * 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 Cdigo 6 Construo programtica da barra de Energia

Estas barras so 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 Cdigo 7 Insero 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

uaQuest Relatrio do projeto

31

Assim que o combate for definido estabelecido o valor mximo da barra atualizando-o posteriormente conforme necessrio. (No caso da EnergyView so utilizados os mtodos setMaxEnergy(int energy) e updateEnergy(int energy) ).

Realidade Aumentada Problemas e Limitaes


A biblioteca de realidade aumentada (AndAr) permite a apresentao dos modelos em 3D, no entanto durante o desenvolvimento foram detetados vrios problemas inerentes ao seu uso. A deteo dos markers tem de ser efetuada sobre condies timas sendo que ocasionalmente, e apesar da grande diferena entre estes, so confundidos apresentando os avatares nos locais errados. Percebeu-se que os ficheiros dos avatares (Wavefront Obj 21) deviam ser reduzidos a 2MB impedido a utilizao de um elevado nvel de detalhe. Pretendia-se tambm implementar animaes nos modelos porm, atravs da anlise da biblioteca, compreendeu-se que isto no seria possvel 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, no existia fluidez na apresentao dos objetos sendo o framerate reduzido. Isto assume-se como um problema bastante srio sendo que a grande maioria do pblico-alvo no possui um terminal do nvel do Samsung Galaxy S. Uma outra limitao crtica refere-se ao facto da biblioteca no permitir interrupes no uso. Assim se o combate for interrompido devido receo de uma chamada, este ter de ser reiniciado. Por ltimo foram ainda detetados problemas no carregamento dos modelos no Sapo A5, tornando a visualizao dos avatares impossvel.

Base de dados22
A base de dados representa uma parte muito importante do desenvolvimento da aplicao sendo que armazena todos os dados relativos ao jogo, e permite efetuar as interaes entre utilizadores, como o caso dos combates e trocas. Existiram algumas alteraes desde a sua definio original 23 e, sendo este um modelo evolutivo, esta a sua forma final. A base de dados composta por 5 sees representadas no diagrama. A seco verde relaciona-se com os dados relativos ao utilizador, a laranja armazena os dados dos enigmas, percursos as relaes entre estes e os enigmas dos

Informaes sobre Wavefront Obj em http://en.wikipedia.org/wiki/Wavefront_.obj_file Devido s dimenses da base de dados o diagrama foi colocado online, http://fotos.ua.sapo.pt/Z2Mc1DCcg5nV3jYQkWzO/ 23 Modelo original pode ser encontrado no documento #entrega04 - Especificao Grfica e Especificao Tcnica, pg 11, em http://uaplay.blogs.ua.sapo.pt/7778.html
22

21

uaQuest Relatrio do projeto

32

utilizadores, a azul claro esto representadas as tabelas de interao utilizadas nas trocas e combate, a azul-escuro apresentam-se as tabelas relacionadas com os itens e por fim, a roxo, as tabelas necessrias ao funcionamento do sistema de mensagens. Foi igualmente necessrio proceder a criao de uma View que permitisse obter as caractersticas do avatar em funo dos itens possudos pelo utilizador. Esta denominada de avatarData. Durante a construo da base de dados, principalmente no caso das tabelas dos enigmas e informao, teve-se o cuidado de garantir a possibilidade de adicionar a lngua aos contedos. Desta forma, com grande facilidade os contedos da aplicao podem ser adaptados para mltiplos idiomas garantindo uma aplicao escalvel possibilitando o seu uso em vrios contextos.

ServerRequest
A aplicao tem a constante necessidade de interagir com o servidor para obter e armazenar os dados do utilizador. Esta necessidade obrigou criao de um Server Communication Engine responsvel por efetuar e tratar os pedidos API desenvolvida. Foi assim desenvolvida a classe ServerRequest sendo uma das mais importantes de toda a aplicao.

Imagem 12 - Diagrama funcionamento ServerRequest

uaQuest Relatrio do projeto

33

A classe ServerRequest nunca utilizada diretamente sendo criada uma classe descendente que contm a interface (serverRequestResponse(JSONObject JSONData)) que recebe os dados em formato JSON provenientes do servidor. apresentado de seguida um exemplo da implementao 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 no pode ser convertida em JSONObject //Por defeito a classe mostra uma Toast //Pode modificar-se o comportamento atravs do @Override onErrorResponse(); } }

Trecho de Cdigo 8 Implementao classe ServerReques

Aps ser definida a classe descendente o pedido pode ser construdo e executado. apresentado o pedido efetuado ao servio 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 Cdigo 9 Construo objeto SererRequest

Leitura de QrCodes
O QrCode Manager desempenha um papel crucial na aplicao 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 - Validao de uma tag enigma com Samsung Galaxy Gio

uaQuest Relatrio do projeto

34

Sempre que o validador acionado este obtm o valor da leitura e age em conformidade. A aplicao conta com quatro tipos de QrCodes diferentes: uaQuest_enigma_#(id) uaQuest_info_#(id) uaQuest_table_battle_p(1|2)_# (id) uaQuest_table_craft

Utilizando expresses regulares estes so validados sendo extrados os dados necessrios como o nmero 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 Cdigo 10 Validao contedo QrCode para mesa de combate

Sistema de Gesto de Contedos


A presente aplicao encontra muita da sua essncia e vive dos contedos que a integram. Os enigmas, sendo que podem debruar-se sobre os projetos de investigao de determinado departamento, devero ser atualizados quando esse mesmo projeto for terminado e outro for iniciado. O mesmo acontece com as informaes presentes nos pontos de interesse. Desta forma tornou-se importante o desenvolvimento de um sistema de gesto de contedos permitindo a contnua atualizao e garantindo a fidedignidade da informao. A construo desta componente no tinha sido planeada no entanto o grupo considerou-a de importncia elevada tendo sido desenvolvido um prottipo. Importa frisar que se trata apenas de um prottipo o qual ainda ir requerer melhorias, de qualquer forma, j possvel obter uma viso geral do seu funcionamento e operaes que vai permitir. Antes de proceder explicao das funcionalidades do gestor de contedos convm explicar a forma como percurso, ponto de interesse e enigma se interligam. Estes seguem algumas premissas enumeradas de seguida: Um percurso constitudo por pontos de interesse numa ordem especfica; Um ponto de interesse pertence sempre, no mnimo, a um percurso; Um enigma tem de estar sempre ligado a um ponto de interesse e um percurso. No podem existir enigmas iguais em percursos diferentes. Um ponto de interesse pode possuir mltiplos enigmas que diferem consoante o percurso;

O sistema permite gerir percursos, pontos de interesse, enigmas e informaes (presentes nas tags de informao). Aps criar percursos e pontos de interesse possvel relacion-los indicando qual o percurso, o ponto de interesse e a ordem do mesmo no percurso.

uaQuest Relatrio do projeto

35

Imagem 14 - Sistema de gesto de contedos - Adicionar pontos de interesse a percursos.

Aps estarem definidos os percursos e respetivos pontos de interesse pode proceder-se adio dos enigmas. Estes tm de ser introduzidos em portugus e ingls de modo a garantir o suporte bilingue da aplicao sendo ainda necessrio selecionar o percurso e o ponto de interesse ao qual se pretende associar o enigma atravs de um menu dropdown.

Imagem 15 - Sistema de gesto de contedos - Adicionar enigmas

ainda possvel adicionar informaes bastando fornecer o nome e contedo das mesmas nas duas lnguas semelhana do que acontece com os enigmas. Aquando da adio de informaes ou enigmas gerado um QrCode 24 nico que ser posteriormente utilizado pela aplicao para obter os dados.

24

Os QrCodes so gerados atravs de uma API Google e integrada no gestor de contedos. Mais informaes em

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

uaQuest Relatrio do projeto

36

Ainda no que diz respeito aos enigmas, um desenvolvimento futuro, passaria pela construo 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 investigao na UA e no percurso de descoberta do DeCA. Com a utilizao de etiquetas a construo dos percursos poderia ser efetuada de uma forma quase automtica. Na verso atual, no possvel, o mesmo enigma pertencer a diversos percursos, no entanto o sistema poder ser adaptado.

Widget25
A aplicao conta com um widget que permite aceder diretamente quer aplicao quer as mensagens. A sua funo principal passa por efetuar verificaes peridicas sobre a existncia de novas mensagens e notificar o utilizador atravs do sistema de notificaes presente nos sistemas Android. Desta forma o utilizador pode saber, mesmo quando no est a utilizar a aplicao, se algum utilizador lhe enviou uma mensagem.

Imagem 16 - Widget da aplicao e sistema de notificaes.

Este elemento, tal como o sistema de gesto de contedos, apenas um prottipo e no explora por completo todas as potencialidades deste componente. De qualquer forma, permite ter uma ideia geral de como funciona, da sua utilidade e importncia que pode assumir na aplicao. Um exemplo de uma funcionalidade a implementar ser informar o utilizador sobre a existncia de atualizaes para a aplicao.

25

Definio de android widget em http://developer.android.com/guide/topics/appwidgets/index.html

uaQuest Relatrio do projeto

37

Captulo V - Testes
Durante todo o desenvolvimento do projeto teve-se o cuidado de efetuar testes para averiguar a compatibilidade da aplicao em vrios dipositivos, no entanto a verso beta contou com uma fase de testes documentada que permitiu compreender, entre outros, os problemas de usabilidade que enfraqueciam a qualidade da aplicao. Alm destes testes o grupo gostaria de ter realizado um teste s componentes de combates e trocas, visto requererem a interao entre utilizadores, e ter procedido a um teste no terreno verificando como a aplicao e o utilizador se comportam numa situao de uso real.

Teste de Usabilidade
O teste de usabilidade pretendia efetivamente compreender quais as dificuldades que os utilizadores sentiam a utilizar a aplicao. Esta portadora de alguma complexidade na sua utilizao devido variedade de tecnologias e paradigmas de interao que a compem, desde a utilizao de QrCodes, navegao em espao real recorrendo ao GPS utilizao de elementos em realidade aumentada. Os sistemas de ajuda da aplicao, constitudos por um tutorial explicativo antes de ecrs importantes, como caso o mapa-mundo, combate, trocas, montagem e um boto de ajuda nos ecrs de mapa-mundo e enigma revelaram estar mal concebidos tendo sido o centro dos problemas. No momento do teste o nico tutorial disponvel ao utilizador referia-se ao mapa-mundo e, sendo este constitudo essencialmente por texto, os utilizadores no efetuaram uma leitura atenta. Neste caso a soluo passou pela construo de tutoriais imagticos e com uma componente textual muito reduzida.

Imagem 17 Tutorial antes (em cima) e aps reviso (sequncia de trs imagens).

uaQuest Relatrio do projeto

38

Esta soluo foi a aplicada a todos os outros tutoriais sendo agora constitudos por trs imagens apresentadas em sequncia e explicativas dos objetivos. O boto de ajuda presente nos ecrs de mapa-mundo e enigma apresenta uma mensagem sobreposta ao ecr aquando do seu clique. Este cone era demasiado pequeno e as frases no eram coerentes com as informaes anteriormente apresentadas, confundindo os utilizadores no que diz respeito diferena entre as tags de informao e tags de enigma, tendo o problema das tags sido corrigido atravs da adio de umas barras de cor26. O boto foi aumentado e efetuou-se uma reviso das frases existindo agora uma normalizao da nomenclatura utilizada. Uma vez que os utilizadores no associaram o boto de opes do telemvel ao surgimento de um menu, apesar de ser um comportamento standard no Android, foi acrescentada essa indicao no sistema de ajuda.

Teste de Compatibilidade
O teste de compatibilidade pretende aferir o nvel de consistncia da aplicao nos diferentes equipamentos com SO Android. Num equipamento deste tipo existem trs variveis a ter em considerao: a densidade do ecr, a resoluo do ecr e a verso do sistema operativo. Para efetuar estes testes e tendo em conta as possveis combinaes das variveis apresentadas foram utilizados trs terminais com caractersticas distintas sendo: Samsung Galaxy S, Samsung Galaxy Gio, Asus Transformer TF101. Como referido, o grupo preocupouse em fazer testes regulares para assegurar a constante compatibilidade entre os vrios equipamentos, facto que assegurou a inexistncia de anomalias aquando dos testes.

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

A nica ilao a tirar deste teste referiu-se apresentao da aplicao 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 no foi desenhada para este tipo de dispositivo, um resultado perfeitamente esperado e que no compromete a integridade funcional da aplicao.

26

Consultar exemplo no anexo 4

uaQuest Relatrio do projeto

39

Teste de Contedos
Existiu, desde o incio do projeto uma preocupao com a utilizao de contedos corretos e fidedignos tornando o teste de contedos importante, no s para o sucesso da aplicao, como tambm para o grupo. O facto de a aplicao fornecer suporte lngua portuguesa e inglesa acresceu a importncia deste mesmo teste. Efetuou-se assim uma reviso de todos os contedos existentes na aplicao procurando erros ortogrficos, de sintaxe e de coerncia estando no presente momento corrigidos. Desde a execuo deste teste novos contedos foram adicionados aplicao, nomeadamente novos enigmas e informaes, e os itens passveis de serem comprados atravs da loja. Estes contedos tambm foram validados e revistos no entanto importa referir que uma reviso geral por parte de um especialista em lnguas poderia aumentar a qualidade dos mesmos, reviso esta que o grupo gostaria de ver realizada.

uaQuest Relatrio do projeto

40

Captulo VI - Manuteno e Suporte


Suporte
No website de suporte aplicao existe uma seco que permite ao utilizador reportar erros, submeter sugestes 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 aplicao. Poderia ser igualmente implementado um sistema de gesto de erros na aplicao que os reportasse automaticamente aquando do acontecimento, permitindo um rastreamento e soluo mais eficiente.

Manuteno
Como j referido, o sistema de gesto de contedos no fazia parte do nosso projeto, mas tento em conta a complexidade da relao entre contedos tornou-se importante a criao de um prottipo. Num desenvolvimento futuro, um dos possveis melhoramentos a realizar passaria pela implementao de um sistema em que qualquer utilizador conseguisse inserir enigmas, permitindo que os contedos crescessem com o contributo dos seus jogadores. Esta abordagem teria alguns inconvenientes sendo necessrio a validao de todos os enigmas inseridos prevenindo o aparecimento de SPAM e enigmas de baixa qualidade. Uma alternativa seria permitir o acesso apenas a elementos especficos e responsveis de cada departamento da universidade garantindo que os enigmas seriam criados por pessoas com conhecimentos sobre o tema em questo. Isto permitiria uma correta manuteno do sistema garantindo que os utilizadores tivessem sempre novos desafios para resolver.

Sistemas de Ajuda
Quando ainda se desenvolvia o conceito do projeto no era esperado que a aplicao assumisse a presente dimenso e complexidade. Ao iniciar o desenvolvimento tronou-se visvel que esta teria que possuir algum suporte para ajudar o utilizador durante uso. Este problema encontrou soluo na criao de tutoriais antes dos ecrs considerados principais e na colocao de mensagens noutros. Com a utilizao da aplicao e receo de comentrios ir ser possvel compreender se estes sistemas de ajuda so suficientes ou ser necessrio proceder sua melhoria. O website poder, futuramente, englobar manuais de jogo e sistemas de F.A.Q., permitindo simplificar a curva de aprendizagem da aplicao.

uaQuest Relatrio do projeto

41

Divulgao
A aplicao teria de ser promovida junto do seu pblico-alvo, ou seja, os novos alunos da universidade de Aveiro. Isto seria conseguido abordando os alunos durante a semana das matrculas no edifcio da reitoria e integrando uma utilizao global da aplicao na semana de acolhimento. De modo a atingir os atuais alunos seria utilizada a newsletter da universidade conseguindo assim a divulgao desejada. Apesar de a aplicao estar atualmente restringida universidade de Aveiro esta poderia ser portada para outras universidades servindo o mesmo propsito, a descoberta da universidade e interao social. Assim, entrar-se-ia em contacto com outras universidades dos pas tentando disseminar o uso. Poderia inclusive ser utilizada noutros contextos de utilizao fora da universidade. A ttulo de exemplo, a sua instalao num festival poderia dinamizar o espao, sendo necessrio modificar o especto grfico, alterar os contedos e adaptar o sistema de mapa.

uaQuest Relatrio do projeto

42

Captulo VII - Anlise Crtica e Desenvolvimento Futuro


Agora que o desenvolvimento foi terminado -nos possvel efetuar uma reflexo crtica sobre todo o percurso e decises que foram tomadas. Apesar de ter sido possvel cumprir com os objetivos que foram propostos e ainda melhorar, restam alguns detalhes que gostaramos de ver implementados. do conhecimento do grupo que a aplicao complexa quer na construo, quer na utilizao tornando-se pertinente efetuar um teste no terreno de modo a entender qual a real curva de aprendizagem da aplicao e se as ajudas ao uso so suficientes. Seria igualmente necessrio efetuar um teste de usabilidade s novas componentes como o caso do combate, trocas e montagem. Estas so 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 so geridas pelo motor do jogo armazenado dados numa base de dados o que resulta em atrasos e, no caso de falhas na ligao, em erros severos diminudo drasticamente a usabilidade da aplicao. Uma soluo para este problema seria a utilizao de uma ligao direta entre os dois terminais recorrendo por exemplo ao Bluetooth. Isto tornaria a transmisso de dados muito mais rpida diminuindo a ocorrncia de falhas. Um outro ponto a ponderar seria relativo continuidade do jogo. Assim que o utilizador resolver todos os enigmas recebe uma congratulao, 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 tpico que necessita de estudos futuros. A aplicao foi desenvolvida medida que os conhecimentos necessrios eram adquiridos, tendo esta e o grupo evoludo conjuntamente. Desta forma existiram abordagens iniciais que no foram as mais indicadas apesar de cumprirem a sua funo. Seria portanto necessrio proceder a uma reviso do cdigo construdo efetuando alteraes por forma a melhorar a eficincia e construo da aplicao. Por ltimo so apresentadas algumas funcionalidades que o grupo considera importantes e cuja implementao permite melhorar a experincia 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 acentuao para a resposta ser considerada errada. Relativamente aos avatares seria importante construir um sistema que facilitasse a sua adio, descarregando-os do servidor assim que novos surgissem. Deveria ainda ser estudada uma forma de utilizar animaes nos mesmos durante o combate.

uaQuest Relatrio do projeto

43

Para finalizar e no que diz respeito aos itens, trs funcionalidades seriam importantes: possibilidade de efetuar a troca de mltiplos itens simultaneamente; desenvolver um sistema de inventrio do avatar em que apenas os itens selecionados seriam equipados; criao de uma seco no gestor de contedos que permitisse a adio de novos itens. As funcionalidades referidas neste captulo, bem como as expostas ao longo de todo o documento, so importantes para o projeto sendo que o grupo gostaria de ter a possibilidade de as implementar permitindo a construo de um produto ainda mais completo.

uaQuest Relatrio do projeto

44

Captulo VIII - Concluso


Chegando ao trmino 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 aplicao mvel 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 nvel muito superior. De qualquer forma o grupo est orgulhoso e satisfeito com os resultados atingidos. Existiram inmeros 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 perseverana permitiram atingir o estado atual. Houve uma explorao do desconhecido, uma aventura que proporcionou ao grupo novas formas de pensar e abordar os desafios bem como inmeros novos conhecimentos. Foram aprendidas tecnologias novas e foram aprofundados os saberes existentes sendo importante para o futuro profissional do grupo.

uaQuest Relatrio do projeto

45

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-xmlresource-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-activitystartup consultado a 25 de Junho 2012 http://developer.android.com/guide/topics/ui/controls/text.html consultado a 26 de Junho 2012

uaQuest Relatrio do projeto

46

Anexos

uaQuest Relatrio do projeto

47

Anexo 1 Requisitos Funcionais do Sistema de Gesto de Contedos


# 1 2 3 4 5 Requisitos funcionais O utilizador poder autenticar-se no sistema de gesto de contedos RNF Aps autenticao o utilizador dever ser encaminhado para a pginas dos percursos. O utilizador poder ver os percursos existentes O utilizador poder criar novos percursos O utilizador poder editar percursos O utilizador poder apagar percursos RNF Deve ser apresentada uma mensagem de confirmao quando o utilizador tentar apagar um percurso. RNF Deve ser apresentada uma mensagem de sucesso ou erro da operao quando o utilizador editar, criar ou apagar percursos 6 7 8 9 O utilizador poder ver os pontos de interesse existentes e a que percurso esto associados O utilizador poder criar pontos de interesse O utilizador poder editar os pontos de interesse O utilizador poder apagar os pontos de interesse RNF Deve ser apresentada uma mensagem de confirmao quando o utilizador tentar apagar um ponto de interesse. RNF Deve ser apresentada uma mensagem de sucesso ou erro da operao quando o utilizador editar, criar ou apagar pontos de interesse 10 11 O utilizador poder adicionar pontos de interesse aos percursos O utilizador poder remover pontos de interesse dos percursos RNF Deve ser apresentada uma mensagem de confirmao quando o utilizador tentar remover pontos de interesse dos percursos RNF Deve ser apresentada uma mensagem de sucesso ou erro da operao quando o utilizador adicionar ou remover pontos de interesse dos percursos 12 13 14 15 O utilizador poder ver uma lista dos vrios enigmas existentes nos vrios percursos O utilizador poder criar novos enigmas O utilizador poder editar enigmas O utilizador poder apagar enigmas RNF Deve ser apresentada uma mensagem de confirmao quando o utilizador tentar apagar um enigma RNF Deve ser apresentada uma mensagem de sucesso ou erro da operao quando o utilizador editar, criar ou apagar enigmas Perfis utiliza. Administrador

uaQuest Relatrio do projeto

48

16 17 18 19

O utilizador poder ver a lista de informaes existente O utilizador poder criar novas informaes O utilizador poder editar informaes O utilizador poder apagar informaes RNF Deve ser apresentada uma mensagem de confirmao quando o utilizador tentar apagar uma informao RNF Deve ser apresentada uma mensagem de sucesso ou erro da operao quando o utilizador editar, criar ou apagar enigmas

uaQuest Relatrio do projeto

49

Anexo 2 Sistema de Pastas da Aplicao Android

uaQuest Relatrio do projeto

50

Anexo 3 Fluxograma Processamento Ataque

uaQuest Relatrio do projeto

51

Anexo 4 Tags de Enigma e Tags de Informao

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

Uma tag de informao caracterizada pelas faixas verdes e indica o ponto de interesse a que se refere e, entre parntesis, o tema que trata.