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.
13.
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.