Jogo pervasivo SIVIRA
•
0 gostou•451 visualizações
Projeto do jogo pervasio "Sivira" produzido pela equipe safari. Mais informações: http://equipesafari.tumblr.com/
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Semelhante a Jogo pervasivo SIVIRA
Semelhante a Jogo pervasivo SIVIRA (20)
Jogo pervasivo SIVIRA
- 2. 1. Introdução Este documento descreve as especificações para o desenvolvimento do jogo pervasivo mobile SIVIRA. Este registro foi feito com o objetivo principal de fornecer à equipe uma visão mais holística do processo e de suas etapas para que, assim, o desenvolvimento ocorra de forma mais organizada. O jogo descrito neste documento consiste em um game pervasivo mobile, para plataforma Android, destinado aos calouros do curso de Sistemas e Mídias Digitais. Um jogo pervasivo é aquele cuja jogabilidade mescla elementos físicos e eletrônicos e que “pode borrar as fronteiras entre realidade e ficção com base no uso das novas mídias, usando o espaço urbano como pano de fundo para suas ações.” (ANDRADE, 2013, p. 02). 2. Objetivos a. Geral O objetivo geral do projeto é desenvolver um jogo pervasivo para a plataforma móvel Android que auxilie os calouros do curso de Sistemas e Mídias Digitais no processo de adaptação ao ambiente universitário e que lhe propicie uma nova experiência aos tradicionais trotes. b. Específicos (1) Desenvolver, inicialmente, o aplicativo do jogo para a plataforma Android. (2) Criar uma interface gráfica para o aplicativo que seja agradável e atraente para o públicoalvo. (3) Desenvolver uma interface que possibilite uma utilização fácil e intuitiva do aplicativo, a fim de propiciar uma experiência agradável ao usuário. (4) Criar uma identidade visual que seja condicente com o públicoalvo e com a proposta do jogo. (5) Desenvolver uma jogabilidade que cumpra com o objetivo geral e seja empolgante para os usuários. (6) Desenvolver um sistema web que faça o gerenciamento do jogo e dos jogadores. 3. Justificativa O ingresso no ensino superior na maioria das vezes apresenta importantes desafios pessoais e profissionais para os estudantes. Além de ser, normalmente, o início de uma carreira profissional mais independente, essa transição afeta intensamente o desenvolvimento psicológicos dos jovens. “O modo como os alunos se integram ao contexto do ensino superior faz com que eles possam aproveitar melhor (ou não) as oportunidades oferecidas pela universidade, tanto para sua formação profissional quanto para seu desenvolvimento psicossocial. Estudantes que se integram acadêmica e socialmente desde o início de seus cursos têm possivelmente mais chances de crescerem intelectual e pessoalmente do que aqueles que enfrentam mais dificuldades na transição à universidade.” (TEIXEIRA, 2008, p. 02).
- 3. Sabendo empiricamente dessas dificuldades, a equipe discutiu formas alternativa para ajudar os calouros nesse processo tão delicado. A partir daí, a proposta se direcionou específicamente para os trotes realizados no escopo do curso de Sistemas e Mídias Digitais. Então, formulouse um problema: de que forma essas atividades receptivas poderiam refletir a essência criativa e tecnológica do curso e ao mesmo tempo ser uma maneira eficiente de ajudar os “bixos” a enfrentarem suas maiores dificuldades no ambiente universitário? Após a identificação do problema, foi realizada uma pesquisa de públicoalvo a fim de analisar as características gerais dos calouros e suas maiores dificuldades no processo de transição para universidade. Para isso, um questionário aberto (anexo 01) foi aplicado junto aos estudantes do primeiro semestre do curso de Sistemas e Mídias Digitais. Por meio da pesquisa, podese compreender as principais dificuldades do públicoalvo, suas características e maiores desejos. Sendo assim, após a coleta desses dados, a equipe teve os insumos necessários para construir uma proposta mais consistente da solução. Abaixo, estão listadas as estatísticas mais importantes resultantes da pesquisa e pela qual a equipe foi norteada no processo de resolução do problema.
- 5. Em seguida, conhecendo o perfil do públicoalvo, a equipe definiu o meio pelo qual a solução atingiria seus objetivos: um jogo. Nada mais apropriado tanto para a proposta do curso quanto para o perfil do públicoalvo (calouros) que utilizar um jogo como meio para o nosso objetivo. Além disso, “os jogos são considerados fenômenos transculturais que acompanham a humanidade desde seus primórdios, sempre relacionados a algum tipo de aprendizado ou ganho cognitivo. (ANDRADE, 2013, p. 01).” Sendo assim, percebese que a utilização de um jogo como meio para promover o aprendizado desejado pelos calouros é totalmente viável. Portanto, a proposta do jogo Sivira se justifica devido às necessidade identificadas na pesquisa de públicoalvo e ao interesse da equipe em promover uma experiência de recepção diferente, criativa e útil para os ingressante no curso. Além disso, percebese uma carência de formas eficientes que auxiliem os calouros tanto a conhecerem o campus do Pici quanto a se integrarem socialmente com os colegas de curso. 4. Ideação A partir das necessidades dos alunos novatos do curso de Sistemas e Midias digitais, observada no resultado da pesquisa apresentada, foi pensado as soluções para resolver os problemas de interação e o conhecimento dos espaços físicos do campus do Pici entre os estudantes.
- 6. A ideia principal é construir um jogo pervasivo para dispositivos móveis no qual terá os seguintes recursos como ideia: ( é importante lembar que algumas ideias ainda necessitam de ajustes e que algumas podem ser excluídas, modificas ou melhoradas) De inicio, o jogo possuirá um objetivo principal, que será o Baú do tesouro, para abrir esse baú, as equipes procurarão partes de uma chave que desbloqueia o baú principal. As equipes começariam em pontos específicos, diferentes, ao qual conterá um baú menor com uma das partes da chave principal, dicas de lugares com outros baús e também dinheiro para trocas ou compras de itens. O jogo termina quando uma das equipes montar a chave principal e for coletar prêmio, ou seja o baú do tesouro. As ideias que foram concebidas durante as fases de ideação estão listadas abaixo. (1º vez do brainstorm) 1. Os integrantes trabalham em conjunto para realizar os objetivos. 2. Interagem em tempo real. 3. Um jogo curto. 4. O jogo terá marcado os pontos no mapa. 5. Compartilhamento de dicas dos pontos. 6. Jogo linear ou não? se uma equipe tem um caminho a seguir ou se ela é independente para procurar onde quiser. 7. Dinheiro no jogo, que pode ser usado para comprar dicas ou partes da chave. 8. Se terá prêmio para todos. 9. Se será utilizado um ou mais celulares por equipe. 10. Troca de itens entre as equipes. 11. Um informante que serviria como uma espécie de loja para compra de dicas e itens. 12. Os prêmios seriam pendrives, fones de ouvido, ou algo definido pela coordenação do curso. 13. Ajuste do app. 14. Painel de informações sobre outras equipes As ideias que foram concebidas durante as fases de ideação estão listadas abaixo. (2º vez do brainstorm em 15/04) 1. Serão 3 chaves 2. 10 enigmas (locais) 3. 10 dicas (1 para cada local/enigma) 4. 10 lugares (sem contar com o local do tesouro). 5. Antes de iniciar a partida: separar as 3 chaves nos locais com a condição de a última chave ficar sempre no ultimo local da rota. 6. As rotas serão aleatórias. 7. Todas as equipes partem do mesmo lugar (onde recebem o primeiro enigma). 8. Se forem 12 equipes, 2 terão o mesmo 1º enigma.
- 7. 9. Quando uma equipe achar a última chave, o local do tesouro aparece automaticamente no mapa. 10. Quando a equipe chegar em um local ela já tera acesso ao próximo enigma. Em seguida, aparecerá a pergunta de ajuda. 11. Se a equipe acertar a pergunta (sobre o local que acabou de passar) ganha uma dica sobre o enigma que está desvendando. 12. A pergunta vem depois do enigma e se não for respondida inicialmente, permanece como um ícone na tela até a equipe responder a pergunta ou desvendar aquele enigma. 13. Haverá uma opção para a equipe ver o status (quant. de chaves coletadas) das outras em ordem decrescente (ícone no menu) 14. Uso de QR Code para validar o enigma desvendado. Essas foram as ideias que foram concebidas que o app poderia ter, mas como sabemos que o processo de design thiking é um processo dinâmico, podemos fazer ajustes nos conceitos inserindo, excluindo ou melhorando as ideias já presentes. Um outro ponto importante a ser dito sobre app é que as ideias só serão de fatos concretizadas quando a mecânica do jogo for bem definida, pois em discussão, foi definido que muitas das ideias só poderiam ser executadas ao passar por essa etapa. 5. Proposta Final: Especificações do Produto Esperado a. Requisitos Requisitos funcionais RF1 Identificação Prioridade: alta Cada equipe tem que ter uma identificação no jogo, que deverá ser um nome e o nome de seus integrantes. Assim os integrantes das outras equipes podem conhecer o nome de seus companheiros de curso. RF2 Posicionamento Prioridade: alta A posição de cada equipe deve ser visível para as outras equipes. RF3 Competição Prioridade: alta As equipes devem competir entre si para ver qual resolve primeiro os enigmas e acha o tesouro. RF4 Movimentação Prioridade: alta As equipes deverão se movimentar fisicamente pelo campus para realizar seus objetivos.
- 8. RF5 Enigmas Prioridade: alta Devem existir enigmas para guiar os participantes aos locais de interesse. Os locais de interesse do jogo são locais úteis na vida real do estudante universitário: bibliotecas, banheiros, locais de xerox, bebedouros, auditórios, laboratórios, lanchonetes e blocos didáticos usados pelo curso de Sistemas e Mídias Digitais. RF6 Comunicação Prioridade: baixa As equipes devem poder se comunicar em tempo próximo ao tempo real através de um chat. RF7 Dica adicional Prioridade media As equipes podem receber uma dica adicional, mas para isso, eles deve responder uma pergunta sobre o local onde está. Requisitos não funcionais RNF1 Sistema operacional O jogo será executado em dispositivo com sistema Android versão 2.3 ou maior. RNF2 Posicionamento global O jogo deverá ter acesso ao GPS do dispositivo Android. RNF3 Servidor web Deverá existir um servidor de aplicação que fará o gerenciamento dos dados do jogo e será responsável por repassar esses dados para as equipes. RNF4 Persistência dos dados O sistema web terá um banco de dados MySql responsável por armazenar os pontos de interesse e enigmas para que esses dados não se percam quando o servidor for desligado. Possibilitando, assim, a edição do jogo com atualização desses pontos e adição de novos posteriormente. RNF5 Push Notifications Facilitar o RF5 e a comunicação do servidor com as equipes, o aplicativo fará uso do serviço de push notifications do Google, o Google Cloud Messaging. b. Mecânica O jogo consiste em uma caça ao tesouro em que os participantes devem percorrer rotas diferentes de uma mesma área, composta por 10 lugares importantes na vivência do estudante do campus (fora o local do tesouro, que não está dentro das rotas). Os calouros serão divididos em equipes (no máximo 12) e cada equipe, munida com o aplicativo do jogo, receberá por sorteio uma rota distinta e o primeiro
- 9. enigma (não haverá dicas para a sua resolução). Caso haja 12 equipes, 2 receberão o mesmo 1º enigma. No instante em que chegarem a um novo lugar, terão acesso ao próximo enigma e deverão desvendálo para saber qual é o próximo lugar da rota. Para auxiliar na tarefa, poderão responder a uma única pergunta relacionada com o lugar atual que, se corretamente respondida, dará dicas para a resolução desse enigma. A pergunta aparecerá imediatamente após o anuncio do enigma na tela do aplicativo na forma de ícone e, caso não seja respondida logo, permanecerá lá até a equipe responder a pergunta ou desvendar o enigma atual. Para a validação do enigma desvendado será usado QR Code. Na tela do aplicativo haverá uma opção, como um ícone no menu, para a equipe ver o status (quantidade de chaves coletadas) das outras equipes em ordem decrescente. Cada grupo terá 3 chaves (rotuladas como “S”, “M” e “D”) distribuídas na sua rota em lugares distintos. O grupo do CA (Centro acadêmico), que administrará a partida, deverá, ao fim do sorteio de rotas, distribuir as chaves de forma que a última chave de cada equipe sempre esteja no último ponto da respectiva rota. A equipe que coletar as 3 chaves e chegar primeiro no local do tesouro, indicado na tela, será o vencedor. c. Soluções e Tecnologias Inicialmente foi pensado como seria possível o desenvolvimento do projeto, que arquitetura usar e qual meio seria o ideal para a interação entre os jogadores. Pensando nisso, optouse por usar arquitetura clienteservidor, que é não é um modelo de interação novo, mas ainda é amplamente utilizado [Coulouris, 2005]. Ainda dentro desse modelo de comunicação, escolheuse usar também um paradigma de desenvolvimento baseado em camadas, o MVC (Modelo, Visão e Controle), que preza pela modularização do sistema e torna mais fácil o crescimento e portabilidade do sistema com a adição novos módulos ou criação de novas interfaces [Krasner and Pope, 1988]. A Figura 4 trás uma representação conceitual da arquitetura do produto. No “servidor”, estará executando a camada de modelo e parte da camada de controle, junto com uma camada adicional reponsável pela comunicação entre a parte do controle que está no servidor e a que está no dispositivo cliente. O dispositivos móveis serão responsáveis por manter um processo cliente, que vai ter a parte de controle apenas dos dados referentes a ele, e dos dados públicos do jogo, como posição dos outros jogadores, pontuação, porcentagem de concluído, etc. No
- 10. cliente também está localizado toda a interface de interação entre o usuário e o sistema e consequentemente entre ele e os outros jogadores. Além disso, o aplicativo móvel vai precisar ter acesso a recursos do sistema operacional que será a base das mecânicas do jogo, o sistema de posicionamento global, GPS. Figura 4 Com estrutura definida, o próximo passo era escolher as tecnologias, os padrões e as ferramentas que serão usadas na prática. Começando pelo servidor, optamos por transmitir as mensagens ao dispositivo móvel utilizando mensagens no padrão JSON
- 11. utilizando o protocolo HTTP por ser um protocolo já consolidado, e JSON por ter o intuito de ser leve, as mensagens serem pequenas e isso faz com que menos dados precisem trafegar pela rede [Crockford, 2006]. Além disso, por ser um padrão simples de ser implementado e entendido, pode tornar mais fácil a criação de novas interfaces de usuário posteriormente, como por exemplo um aplicativo para iOS. Para fornecer esse padrão de documento estruturado, escolhemos usar web service no padrão REST por vantagens no tamanho da mensagem, flexibilidade e tempo de resposta. “Advantages include less message sizes and response time. Results of performance comparison between conventional SOAP and RESTful show the obvious high performance RESTful over SOAP. Therefore, RESTful offers a perfectly good solution for the majority of implementations, with higher flexibility and lower overhead.” [Hamad, Saad e Abed, 2009]. A figura 5 mostra as ferramentas e padrões citados acima e suas respectiva versões. Mostra também o sistema operacional e a versão do dispositivo móvel que poderá ser hospedeiro do processo cliente.
- 12. Figura 5 d. Layout A estética da interface do jogo irá seguir o princípio de design KISS ("Keep it simple, stupid"). A proposta é simplificar o layout ao máximo até que ele contenha apenas seus elementos essenciais. Os elementos do design como cores, formas, ícones, texturas, etc., serão pensados para que sejam atraentes e satisfação o públicoalvo. Sendo assim, a composição do layout será pensada para que os usuários possam ter o mínimo de estresse e o máximo de eficiência e satisfação. A metáfora usada tanto na linguagem do jogo quanto na interface será de uma caça ao tesouro, com elementos do universo pirata ou outra proposta de tema.
- 14. Esboço do Layout 6. Protótipos Necessários Neste tópico está detalhada a especifiação dos produtos intermediários que a equipe considera necessários para o desenvolvimento. Em um primeiro momento, a equipe de desenvolvimento gráfico irá desenhar um protótipo de baixa fidelidade do design com o objetivo de ilustrar o fluxo das telas do jogo através de mockups simples. Depois, após uma produção gráfica inicial, será feito um protótipo de média fidelidade para teste das características de layout e usabilidade do jogo, a fim de detectar possíveis falhas de design. Em seguida, com o sistema em mãos, será feito um protótipo de alta fidelidade (versão beta) integrando a parte visual (com as suas possíveis alterações) às funcionalidades do software. Esse produto intermediário será testado pelos usuários finais a fim de detectarmos possíveis erros ou insatisfações do públicoalvo. Ao final desse segundo protótipo, a equipe terá a base necessária para finalizar o produto.