Professional Documents
Culture Documents
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
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.
10
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
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
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.
13
14
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
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
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.
17
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.
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
19
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
20
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:
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.
Procedamos agora descrio sumrias dos elementos da arquitetura compreendendo a sua importncia para o sistema.
22
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.
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
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.
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." }
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.
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
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:
26
http://uaquest.co.cc/API_v2/checkTurn.php
* attack: * "code","power","userEnergy","opponentEnergy","userLife" */
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.
27
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
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;
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!!! () }
30
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" />
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
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) ).
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
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.
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(); } }
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();
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.
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); () }
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.
35
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.
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
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.
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
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).
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
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.
40
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.
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.
42
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.
44
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
46
Anexos
47
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
49
50
51
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.