cloud game report: uma plataforma para coleta e …
TRANSCRIPT
CLOUD GAME REPORT: UMA PLATAFORMA PARA COLETA E ANALISE DE DADOS DE JOGOS
EDUCACIONAIS EM AMBIENTE WEB
Pedro Corrêa da Silva
Projeto de Graduação apresentado ao Curso de Engenharia Eletrônica e de Computação da Escola Politécnica, Universidade Federal do Rio de Janeiro, como parte dos requisitos necessários à obtenção do título de Engenheiro. Orientador: Sérgio Barbosa Villas-Boas
Rio de Janeiro
Julho de 2015
ii
CLOUD GAME REPORT: UMA PLATAFORMA PARA COLETA E ANALISE DE DADOS DE JOGOS
EDUCACIONAIS EM AMBIENTE WEB
Pedro Corrêa da Silva PROJETO DE GRADUAÇÃO SUBMETIDO AO CORPO DOCENTE DO CURSO DE ENGENHARIA ELETRÔNICA E DE COMPUTAÇÃO DA ESCOLA POLITÉCNICA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE ENGENHEIRO ELETRÔNICO E DE COMPUTAÇÃO Autor:
_________________________________________________ Pedro Corrêa da Silva
Orientador:
_________________________________________________ Prof. Sérgio Barbosa Villas-Boas
Examinador:
_________________________________________________ Prof. Antônio Cláudio Gómez de Sousa
Examinador:
_________________________________________________ Prof. Sérgio Palma da Justa Medeiros
Rio de Janeiro – RJ, Brasil
Julho de 2015
iii
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politécnica – Departamento de Eletrônica e de Computação
Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária
Rio de Janeiro – RJ CEP 21949-900
Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que
poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem
finalidade comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).
iv
DEDICATÓRIA
Dedico este trabalho a minha família e amigos por acreditarem em mim e por
todo o suporte que sem a qual não teria conseguido concluir essa etapa.
v
AGRADECIMENTO
Agradeço aos professores do Departamento de Engenharia Eletrônica e da
Computação da UFRJ pelas excelentes aulas e noites mal dormidas e também aos meus
colegas por ajudarem a revisarem esse documento. Também agradeço ao povo brasileiro
por pagar pelo meu curso superior.
vi
RESUMO
Esse trabalho descreve o desenvolvimento de uma plataforma em ambiente web
criada para coletar e exibir dados de jogos educacionais de forma clara e cômoda. Essa
plataforma é composta de um portal web de uso simples voltado para professores e
educadores e uma API voltada para desenvolvedores de jogos educacionais.
Além dessa plataforma, esse trabalho também descreve o desenvolvimento de
um jogo educacional de teste que faz uso da plataforma descrita acima.
Palavras-Chave: Jogos Educacionais, Cloud, Mobile, API, Web, Framework,
Desenvolvimento de jogos
vii
ABSTRACT
This work describe the development of a web-based platform created to collect
and show data from educational games in a simple and easy to use manner. This
platform is composed of a Web Portal for the teachers and educators and an API for
developers of educational games.
Aside from this platform, this work also describe the development of an
educational game used to test the above-described platform.
Key-words: Educational Games, Cloud, Mobile, API, Web, Framework, Game
Developing
viii
SIGLAS
UFRJ – Universidade Federal do Rio de Janeiro
CGR – Cloud Game Report
ESIa – Educational Space Invaders Advance
API – Application Programming Interface
MVC – Model, View, Controller
XML – eXtensible Markup Language
JSON – JavaScript Object Notation
UML – Unified Modeling Language
HTTP – Hypertext Transfer Protocol
ix
Sumário
1 Introdução
1.1 - Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 - Delimitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 - Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 - Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 - Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 - Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Spring MVC
2.1 - Mode, View e Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 - Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 - Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 - View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 7
2.2 - Arquitetura das plataformas . . . . . . . . . . . . . . . .. . . . . . . . . . . . 8
3 Desenvolvimento do Cloud Game Report
3.1 - Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 - Portal Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 - Painel do Professor . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 - Gerenciador de Sala de Aula. . . . . . . . . . . . . . . . . . . . 13
3.2.3 - Gerando Relatórios . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3.1 - Relatório Individual. . . . . . . . . . . . . . . . . . . 15
3.2.3.2 - Relatório de Atividade . . . . . . . . . . . . . . . . 16
3.2.4 - Criador de Novo Tipo de Jogo. . . . . . . . . . . . . . . . . . . 17
x
3.3 - API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 – Fluxo do Uso da API . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2 - Serviços da API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2.1 - Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.2.2 - Listar Salas de Aula . . . . . . . . . . . . . . . . . 20
3.3.2.3 - Requisitar Inscrição . . . . . . . . . . . . . . . . . . 20
3.3.2.4 - Lista de Jogos . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2.5 - Salvar Dados . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 - Modelo do Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Unity3D
4.1 - Elementos Básicos do Unity3D . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 - Ambiente Unity3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 - Exemplo de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Educational Space Invaders Advance
5.1 - Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 - Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.1 - Cena de Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.1 - Cena de Lobby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3 - Portal Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.1 - Listagem de Jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3.2 - Editor de Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 - API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4.1 - Criar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.2 - Logar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.3 - Listagem Jogos Disponíveis . . . . . . . . . . . . . . . . . . . . 36
xi
5.4.4 - Criar Novo Jogo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4.5 - Listar Dados de Um Jogo . . . . . . . . . . . . . . . . . . . . . . 37
5.4.6 - Atualizar dados do Jogo . . . . . . . . . . . . . . . . . . . . . . . 37
5.4.7 - Deletar Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.4.8 - Atualizar asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.4.9 - Deletar Asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5 - Modelo do Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6 Conclusões
6.1 - Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2 - Melhorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A Formatação JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
xii
Lista de Figuras
2.1 – Diagrama de Fluxo do MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 – Tela Inicial do Cloud Game Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 – Painel do Professor . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 – Tela do gerenciador de Sala de aula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 – Tela de Criação de Relatórios Individuais . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 – Tela de Criação de relatório de atividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 – Tela de Criação de tipo de jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.7 – Fluxo de Uso da API do CGR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.8 – Diagrama UML do modelo de banco de dados do CGR . . . . . . . . . . . . . . . . 22
4.1 - Tela Principal do Unity3D . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 – Exemplo de uso do Unity3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 – Screenshot final da cena do jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 – Diagrama dos relacionamentos dos GameObjects do jogo ESIa . . . . . . . . . . 30
5.3 – Imagens do menu principal, listagem de jogos disponíveis . . . .. . . . . . . . . . 31
5.4 – Diagrama do fluxo de dados nos principais GameObjects . . . . . . . . . . . . . . 32
5.5 – Listagem de Jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.6 – Tela de Edição de jogo do ESIa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.7 – Diagrama UML do modelo de banco de dados implementado. . . . . . . . . . . . 39
xiii
Lista de Tabelas
3.1 – Relação de parâmetros da API do CGR . . . . . . . . . . . . . . . . . . . . . . . . . . ... 19
5.1 – Relação de parâmetros da API do ESIa . . . . . . . . . . . . . . . . . . . . . . . . . . ... 35
1
Capítulo 1
Introdução
1.1 – Tema
Esse trabalho aborda jogos educacionais em plataforma mobile com foco na
gerencia e processamento dos dados gerados por esses jogos usando conceitos de Cloud
Computing como o armazenamento e análise de dados através de uma máquina remota.
1.2 – Delimitação
Jogos educacionais tem se tornado cada vez mais uma poderosa plataforma
educacional devido a sua grande popularidade, baixo custo e grande facilidade de
escalabilidade [1]. Porém, apesar desse crescimento pouco tem sido desenvolvido com
relação a avaliação do resultado desses jogos.
Observamos que cada jogo educacional tem a capacidade de gerar uma grande
quantidade de dados a respeito do jogador que podem ser utilizados para avaliar o quão
bem o aluno aprendeu um determinado assunto. Apesar desse potencial esses dados são
geralmente ignorados. Para amenizar esse problema foi desenvolvido o Cloud Game
Report, uma plataforma em ambiente web para gerenciamento de dados de jogos
educacionais e analise de resultados.
Esse projeto não visa, necessariamente, melhorar os jogos educacionais atuais
porem facilitar o trabalho dos professores e educadores, oferecendo uma plataforma
unificada e genérica para o problema descrito.
1.3 – Justificativa
2
Tão importante quanto ensinar é avaliar o que foi ensinado e o quão bem foi
ensinado. Sem essa avaliação o processo de educação se torna incompleto e incapaz de
se desenvolver de forma correta.
Os jogos educacionais trouxeram novas formas de aprendizagem que necessitam
de novas formas de avaliação capazes de considerar uma grande quantidade de dados
que são recebidos a todo momento por um grande número de alunos além de trazer
conveniência para os professores que fazem uso dos dados.
1.4 – Objetivos
O objetivo desse trabalho foi de desenvolver uma plataforma online que seja
capaz de capturar dados de qualquer jogo educacional que implemente a API
(Application Programming Interface) da plataforma proposta. Após a captura, o sistema
é capaz de tratar e exibir essas informações de forma que o professor responsável possa
analisar o progresso dos alunos com facilidade em qualquer lugar através de um portal
na internet.
Para validar a plataforma acima também foi desenvolvido um jogo educacional
que a utilize de forma desacoplada, ou seja, apenas fazendo uso da API pública
desenvolvida. O jogo teste em questão é uma versão educacional do clássico Space
Invaders, sua jogabilidade é descrita no Capitulo 5
Esse trabalho, começou como um projeto final da disciplina “Software para
Smartphone” com o objetivo implementar um serviço Cloud que desse suporte a jogos
educacionais. Esse conceito foi ampliado, melhorado e tornado mais genérico ao longo
do desenvolvimento desse trabalho.
1.5 – Metodologia e Materiais
A metodologia utilizada para o desenvolvimento do projeto é o Scrum
Academic, uma versão acadêmica do Scrum [2], onde são feitas entrevistas com o
3
cliente conforme o projeto avança. O cliente foi representado pelo orientador deste
projeto o professor Sérgio Villas-Boas.
A plataforma de gerência de dados foi desenvolvida em Java, usando os
frameworks SpringMVC [3] e Jackson que fornecem ferramentas que facilitam o
desenvolvimento de páginas web. Também foi utilizado o banco de dados relacional
PostgreSQL em conjunto com o framework Hibernate [4] que permite o acesso ao
banco de dados sem a necessidade do uso da sua linguagem especifica. Por último,
utilizamos JavaScript, JQuery [5] e GoogleCharts [6] para criação de gráficos em
responsivos e dinâmicos para navegadores web.
O jogo educacional de teste foi criado utilizando o Unity3D [7] vista com
maiores detalhes no Capitulo 4. Além do jogo uma plataforma web foi desenvolvida
com intuito de permitir à criação de jogos personalizados. Tal plataforma foi criada com
as mesmas tecnologias e ferramentas usadas no desenvolvimento da plataforma de
coleta de dados em conjunto com AngularJS [8].
Todo o código desenvolvido foi armazenado em um repositório GIT online
chamado GitHub, de forma aberta para qualquer pessoa interessada possa copiá-la,
modificá-la e fazer uso das tecnologias desenvolvidas.
1.6 – Descrição
O Capítulo 2 apresenta uma breve introdução ao framework SpringMVC,
utilizado para criação dos portais web Cloud Game Report e ESIa, além de explicitar a
arquitetura básica utilizada no projeto.
No Capítulo 3 é descrito a plataforma Cloud Game Report proposta. O capitulo
está dividido em duas partes o portal web e a API proposta. As funcionalidades do
portal web são descritas na visão do professor enquanto a API é descrita na visão de um
desenvolvedor de jogos.
4
O Capítulo 4 é reservado para introduzir a plataforma de desenvolvimento de
jogos Unity3D vital para o entendimento do capítulo seguinte onde é feito uso da
mesma. O capitulo descreve os principais conceitos do framework assim como seu
ambiente gráfico. No final é dado um exemplo prático para consolidar os conceitos
descritos.
No Capítulo 5 descreve o jogo educacional ESIa usado para os testes da
plataforma Cloud Game Report. O capítulo é dividido em duas partes, o primeiro foca
no desenvolvimento do jogo mobile e a segunda parte no desenvolvimento de uma
plataforma web que permite a personalização do jogo mobile. Essa última também é
dividida em duas partes, o portal web em si e uma API desenvolvida para a criação da
mesma.
O Capitulo 6 é reservado para resultados, conclusões e possíveis oportunidades
de melhorias observadas ao longo do projeto.
O Apêndice A defini a formatação JSON a qual é usada por todas as APIs do
projeto.
5
Capítulo 2
Spring MVC SpringMVC é um framework escrito em Java que auxilia o desenvolvimento de
aplicações Web baseado no design pattern MVC (model, view, controller) para criar
páginas dinâmicas. O framework automatiza uma serie de tarefas repetitivas diminuindo
o tamanho final do código além de modularizar seus componentes auxiliando na
manutenção do mesmo.
Este framework e os conceitos explicados nesse capitulo foram utilizados para o
desenvolvimento da plataforma CloudGamerReport e de parte do jogo educacional de
teste.
2.1 – Model, View e Controller
O MVC é um dos padrões de design mais utilizados para criação de aplicações
de todos os tipos que separa a representação da informação da interação do usuário.
Esse padrão divide o código em três partes com conceitos distintos a fim de facilitar a
reusabilidade de código.
6
Figura 2.1 - Diagrama de fluxo do MVC
2.1.1 – Model
O Model (ou modelo) é o conjunto de estruturas de dados armazenados e suas
funções de acesso. Os dados no banco de dados só podem ser acessados através dos
seus modelos que representam as estruturas dos dados de um sistema.
No SpringMVC os modelos são representados por classes conhecidas como
JavaBeans. Essas classes possuem apenas seus parâmetros definidos e métodos de
acesso (Getters e Setters) usados para definir ou capturar os valores de cada parâmetro.
Nesse projeto utilizamos a biblioteca de ORM (Object-relational mapping)
Hibernate que faz o mapeamento de cada objeto JavaBeans a uma entrada no banco de
dados com isso eliminamos a necessidade de carregar manualmente os dados do banco
de dados nos objetos. Ele também automatiza a criação das estruturas que representam
os modelos no banco de dados o que torna o qualquer projeto que utiliza o ORM
independente da linguagem e do banco de dados utilizado.
7
2.1.2 – Controller
Os controllers são a parte central do padrão MVC. Eles são responsáveis por
capturar os pedidos do usuário pelo navegador, acessar os dados a partir dos modelos e
efetuar o processamento necessários que gera o resultado desejado para o usuário, como
por exemplo calcular uma média de uma sequência de números.
No SpringMVC os controlados são definidos como classes Java simples que
esperam um objeto com o pedido do usuário. Cada classe possui uma função especifica
e precisa ser chamado de acordo com a URL que faz o pedido. Esse mapeamento de
cada URL para cada controller é feito com anotação simples do próprio Java antes de
cada classe. Cada controller, permite a chamada de uma view ou de um outro controller
o que permite o encadeamento de processos com facilidade.
2.1.3 – View
A View é responsável por gerar o resultado final do pedido do usuário. Ela
utiliza os dados coletados do Model e processados no controller para gerar a
visualização desejada. Ela pode vir no formato que for necessário, por exemplo, JSON
ou HTML.
O SpringMVC permite a criação de páginas especificas HTML com o layout no
formato JSP (JavaServer Pages). Nela é possível criar o layout com código HTML puro
e usar tags especiais para inserir dados específicos ou alterar o layout antes de ser
enviado ao cliente.
O framework também dá suporte a biblioteca Jackson que permite mapear
objetos ou listas de objetos Java em documentos JSON com facilidade apenas
adicionado uma notação ao controller que gera a view desejada. Esse mapeamento foi
utilizado na criação das APIs desenvolvidas.
8
2.2 – Arquitetura das plataformas
As arquiteturas de ambos os portais criados nesse projeto seguem o modelo
MVC descrito acima tanto para criação dos portais web quanto as APIs (Application
Programming Interface). Cada chamada URL é mapeada a um controller que tem o
papel de coletar ou inserir os dados necessários e gerar a página web desejada. Todos os
controllers referentes as APIs fazem uso da biblioteca Jackson para gerar suas saídas em
JSON.
Cada projeto possui 3 pacotes de código-fonte um para os modelos, outro para
os controladores e outro para o DAO (Data Access Object) que é faz uso do Hibernate
para coletar os dados no banco de dados. Além dos pacotes cada projeto tem uma pasta
com as Views no formato JSP que são utilizadas pelos controllers parar gerar cada
pagina no portal web.
9
Capítulo 3
Cloud Game Report
O Cloud Game Report (CGR) é a plataforma responsável pela coleta e
gerenciamento dos dados. Ela pode ser dividida em duas partes fundamentais: a
primeira é o portal web que é usado pelo professor para gerenciar salas de aulas e
analisar os dados coletados; a segunda parte é uma API (Application Programming
Interface) em ambiente web desenvolvida para permitir que os jogos educacionais
coletem informações sobre salas de aulas e enviem os dados das partidas para o sistema.
Ambas as partes foram desenvolvidas utilizando Java e o framework
SpringMVC (Capitulo 2).
3.1 - Terminologia
O CGR utiliza o conceito de Salas de Aulas para facilitar a agregação dos dados
coletados. Salas de aulas são, basicamente, versões virtuais das salas de aulas de um
professor onde é possível organizar as informações relacionadas as mesmas.
As Atividades são instancia de jogos educacionais a qual os alunos inscritos na
sala de aula podem participar. Uma atividade pode ser entendida como o “tema de um
jogo educacional”. Por exemplo, caso o professor crie uma atividade “Historia Geral no
Educational Space Invaders” teremos um jogo do tipo ESI com o tema “Historia
Geral”. Com isso o professor pode criar várias atividades usando o mesmo jogo
educacional porem cada atividade com um tema diferente.
Os Tipos de Jogo são os diversos jogos educacionais que uma atividade pode
ter como por exemplo o Educational Space Invaders.
10
Um Professor é definido como o usuário que gerenciar uma sala de aula e tem
permissão para gerar relatórios referentes a mesma.
Por último, o Aluno é definido como um usuário que pertente a uma sala de aula
e, caso inscrito, pode participar das atividades da sala e que envia dados ao sistema
sobre seus resultados.
3.2 - Portal Web
O Portal CGR foi criado com o foco nos professores. Ele permite que um
professor acesse os dados coletados de forma simples a fim de fazer análises e tirar
conclusões sobre o quão bem um aluno aprendeu. Além dessa funcionalidade principal
ele também pode gerenciar os alunos inscritos numa sala de aula e cadastrar quantas
atividades desejar.
Para utilizar a plataforma, tanto o professor quanto o aluno devem estar
inscritos. Depois disso, o professor poderá criar suas salas de aulas e dentro delas criar
atividades e inscrever seus alunos. O cadastro implementado é simples, basta adicionar
um nome de usuário e senha.
11
Figura 3.1 – Tela Inicial do Cloud Game Menu
12
3.2.1 - Painel do Professor
Após acessar o sistema com seu nome de usuário e senha o professor é
direcionado ao seu painel principal, onde é possível gerenciar ou deletar suas salas de
aulas, além de poder criar uma nova sala de aula.
Para criar uma sala de aula basta adicionar um nome e uma descrição. Após sua
criação é possível acessa-la clicando em Manage Class.
Figura 3.2 – Painel do Professor
13
3.2.2 - Gerenciador de Sala de Aula
No gerenciador de Sala de Aula o professor poderá ver estatísticas sobre a sala
de aula, o número de alunos inscritos e a quantidade de partidas jogadas, criar novas
atividades e remover ou aceitar a inscrição dos alunos na sala de aula.
Cada uma dessas funcionalidades será explicada em maiores detalhes a seguir
Figura 3.3 – Tela do Gerenciador de Sala de Aula
14
3.2.3 - Gerando Relatórios
O professor poderá gerar dois tipos de relatórios. O individual, para cada aluno,
e um para toda a turma. Para gera-los basta clica no botão respectivo a cada um no
Gerenciador de Sala de Aula como mostra a Figura 3.2.
Os relatórios assumem o formato de gráficos que podem ser personalizados para
melhor representar o parâmetro que está sendo analisado. O professor responsável
poderá criar quantos gráficos desejar.
Um detalhe importante é que diferentes jogos possuem diferentes parâmetros e
métricas, por exemplo, jogos diferentes possuem maneiras diferentes calcular a
pontuação do jogador. Por causa disso comparar jogos diferentes não ajuda na análise
da situação do aluno ou da sala de aula. Isso só seria possível após uma meta-analise
dos valores de forma que pudessem ser comparados.
Como criar um método para meta analise desses dados sai do escopo de projeto
os relatórios são divididos em atividades, ou seja, cada relatório criado é feito para
apenas uma atividade por vez, o que evita a mistura das métricas.
Os gráficos são construídos usando GoogleChart no próprio navegador do
usuário. Um pedido referente a atividade é enviado para o servidor que responde uma
estrutura JSON utilizada pelo GoogleCharts para criar os gráficos. Essa estrutura se
resume a uma matriz onde cada linha é um ponto no gráfico e cada coluna um
parâmetro do ponto (como posição, valor, nome, etc.).
15
3.2.3.1 - Relatório Individual
Na página de Relatório Individual é possível criar relatórios referentes para o
aluno selecionado aluno. Nessa página o professor deverá escolher para qual atividade
ele deseja analisar devido ao problema de meta analise citado em 3.2.3. Após
selecionado o professor poderá criar gráficos que ajudam a visualizar os dados referente
aquele aluno naquela atividade e ajudar na avaliação do estudante de forma individual.
Figure 3.4 - Tela de Criação de Relatórios Individuais
Vários tipos de gráficos estão disponíveis como: Gráfico de Área, Gráfico de
Linha, Gráfico de Torta e Gráfico de Barras. Em cada gráfico é possível escolher qual
parâmetro será exibido, também é possível limitar a quantidade de resultados exibidos e
ordena-los.
16
Em especial o Gráfico de Bolhas permite a escolha dos eixos horizontal vertical
e um peso para cada ponto no gráfico, permitindo uma analises mais complexas dos
dados coletados.
3.2.3.2 - Relatório de Atividade
Além do relatório individual o professor também pode criar relatórios de turma
para cada atividade listada. Aqui o professor terá a mesma facilidade dos relatórios
individuais porem de forma mais limitada já que nem todos os gráficos são ideais para
visualização dos dados de mais de um aluno ao mesmo tempo.
A partir desses gráficos é possível avaliar a situação de um aluno para com o
resto da turma e detectar qualquer aluno que precise de atenção especial.
Figure 3.5 - Tela de Criação de Relatório de Atividade
17
3.2.4 - Criador de Novo Tipo de Jogo
Caso o professor deseje criar uma atividade com um tipo de jogo inexistente ele
poderá criar um novo tipo de jogo personalizado. Para isso é necessário informar o
nome desejado e seus parâmetros (como pontos, tempo de jogo, acertos e etc.). Cada
parâmetro possui dois valores, um nome e um identificador. O identificador é o valor da
chave da resposta JSON a qual a API espera receber. Por exemplo, caso um parâmetro
tenha o identificador "total_points" o sistema espera receber um arquivo JSON no
formato {"total_points": "100"}.
Cada tipo de jogo possui um identificador único dentro do sistema a qual deve
ser enviado junto com as informações no momento de salvar os dados do jogador na
plataforma.
Figura 3.6 - Tela de criação de Tipo de Jogo
18
3.3 - API
O objetivo principal da API do CGR é de enviar os dados de uma partida de um
jogo especifico para o servidor onde se encontra a plataforma. Porem ela não é limitada
apenas a isso. Com a API é possível listar as salas de aulas disponíveis para aquele jogo,
requisitar uma inscrição de salas de aula e listar as atividades do aluno. Essas funções
secundarias se fazem necessárias para configuração correta da API que salvará os dados
na plataforma.
Essa parte da plataforma é destinada não ao professor e sim ao desenvolvedor do
jogo educacional.
3.3.1 - Fluxo do uso da API
Para facilitar o entendimento vamos explicar o fluxo do uso da API antes de
explicarmos cada um de seus serviços. Esse fluxo demonstra cada etapa necessária para
salvar o dado na plataforma de forma correta.
Figura 3.7 - Fluxo de uso da API do CGR
O fluxo de uso da API é o seguinte:
1. O usuário começa o jogo educacional em questão
2. O usuário efetua o login no sistema CGR usando seu Username e Senha. Se a senha
for correta o CGR retornara uma chave alfanumérica (SessionHash) armazenada
pelo jogo deve armazenar. Todas os passos a seguir exigem a chave alfanumérica
para autenticar o usuário.
19
3. O usuário lista as salas de aulas disponíveis ou as suas atividades disponíveis o CGR
retorna os dados no formato JSON.
4. O usuário seleciona uma das atividades disponíveis para participar. Com isso o jogo
saberá qual atividade carregar.
5. O jogador participa da atividade
6. Ao final da atividade os dados o jogo deve fazer o envio dos dados coletados para o
CGR usando os parâmetros do seu Tipo de Jogo como explicado na seção 3.2.4
3.3.2 - Serviços da API
A API funciona através de chamadas em endereços web específicos para cada
função. Para cada função uma resposta no formato JSON é recebida com o resultado e
dados relevantes. O resultado final desejado do uso da API, como explicado na seção
anterior, é efetuar um envio dos dados do jogo corretamente par ao sistema. A tabela 3.1
lista os parâmetros utilizados junto com uma breve descrição.
Tabela 3.1 - Relação de parâmetros da API do CGR
Parametro Descrição
GameID Identificador único do jogo, esse valor é dado pelo Tipo de Jogo
Username Username do usuário
Password Senha do usuário
SessionHash Chave de autenticação do usuário
ClassID Identificador da sala de aula
Data Dados a serem salvados, eles devem seguir os padrões descritos no Apêndice A
ActivityID Identificador da atividade
As chamadas dos serviços a seguir estão no formato relativo, ou seja, antes de
cada serviço deve-se adicionar o local onde o servidor se encontra. Por exemplo caso o
servidor da plataforma esteja em www.cloudgamereport.com o serviço login estaria
em www.cloudgamereport.com/services/login/.
20
3.3.2.1 - Login
/services/login/{GameID}
Esse serviço é utilizado para logar o usuário na plataforma. Para efetuar o Login
o Username e o Password devem ser dicionários ao cabeçario da chamada do endereço
no formato BasicAuth padrão do protocolo HTTP. Sua resposta é uma sequência
alfanumérica que servirá como chave de autenticação e irá validar as demais ações do
sistema. O jogo deverá salvar essa chave para utilizar o restante da API.
3.3.2.2 - Listar Salas de Aula
/services/ListOfAvailableClasses/{sessionhash}
Esse serviço retorna um JSON com as informações básicas de todas as salas de
aulas que possuem pelo menos um jogo do tipo igual ao jogo fazendo uso da API
3.3.2.3 - Requisitar Inscrição
/services/SubscribeToClass/{sessionhash}/{ClassID}
Esse serviço envia uma requisição de inscrição de um estudante em uma sala de
aula e retorna o status da operação.
21
3.3.2.4 - Lista de Jogos
/services/ListOfSubscribedGameEntries/{sessionhash}
Esse serviço lista todos os jogos de todas as salas de aulas onde o estudante está
devidamente inscrito. Os jogos listados são apenas do mesmo tipo a qual o jogador está
jogando.
3.3.2.5 - Salvar Dados
/services/Save/{sessionhash}/{Activity}
Essa é a função principal da API, ela envia os dados da partida após o jogador
ter terminado. Para isso o jogador deve estar inscrito na sala de aula da atividade em
questão. O jogo então deve enviar os dados no formato JSON como definido em 3.2.4.
Exemplo:
{ “body” : { "pontuation_field" : "10", "gameplay_time" : “290" } }
Os identificadores precisam estar cadastrados no tipo de jogo como visto na
sessão 3.1.3. Caso não estejam os valores desses identificadores não serão salvos.
22
3.4 - Modelo do banco de Dados
Os dados são armazenados em um banco de dados relacional. Abaixo temos o
diagrama UML descrevendo como os dados estão relacionados.
Figura 3.8 - Diagrama UML do modelo de banco de dados implementado
23
Capítulo 4
Unity3D
O jogo de teste ESIa foi desenvolvido com o framework Unity3D para a criação
de jogos. Sua escolha foi devido ser uma plataforma de desenvolvimento de jogos
extremamente popular na indústria por sua flexibilidade, facilidade de uso e
possibilidade de compilação para diversos dispositivos desde computadores até
videogame e celulares. Nesse capitulo apresentaremos alguns conceitos básicos do
Unity3D e seu ambiente de desenvolvimento.
4.1 - Elementos Básicos do Unity3D
Unity3D divide a aplicação em Cenas. Cada cena é isolada uma da outra e tem a
funcionalidade principal de separar os componentes para facilitar sua criação e melhorar
a performance já que só os componentes relevantes a cada cena são carregados.
O segundo conceito importante é o de GameObjects. Eles funcionam como
objetos que possuem uma posição tridimensional no espaço virtual do jogo. Apesar de
possuírem uma posição na cena eles não possuem uma representação gráfica e são por
si só invisíveis e precisam de um componente que os dê alguma representação gráfica.
O último conceito importante são os de Componentes que nada mais são do que
scripts que adicionam funcionalidades a um GameObject. Vários componentes já são
disponíveis out-of-the-box como o Mesh (que dá uma representação gráfica 3D ao
GameObject), o Rigidbody (que adiciona propriedades de física básica como gravidade
ao GameObject) e o Collider (que permite a detecção de colisão entre GameObjects).
24
4.2 - Ambiente Unity3D
Figura 4.1 - Tela Principal do Unity3D
O framework funciona em volta do editor de cena. Nele é possível adicionar
GameObjects e configurar componentes. Suas principais abas são:
Cena: Permite a visualização e manipulação dos GameObjects da Cena sendo
editada. Parâmetros de posição, tamanho e rotação podem ser alterados diretamente.
Também é possível posicionar a posição da câmera do jogador para facilitar a
visualização do projeto.
Hierarquia: Lista todos os GameObjects daquela cena e permite visualizar
também os GameObjects aninhados a outros.
Inspetor: Permite a visualização de propriedades de algum GameObject
selecionado. Além disso também lista todos os componentes associados a esse
25
GameObject e também exibe alguns parâmetros dos mesmos onde é possível configura-
los
Game: É onde o resultado final do jogo deve aparecer. Para rodar a aplicação
basta apertar no botão “Play” no topo do Unity3D. Ao rodar a aplicação a aba Game
deve mostrar a câmera principal e ativar todos os componentes da Cena.
4.3 - Exemplo
Figura 4.2 - Exemplo de uso do Unity3D
Um exemplo simples é a criação de uma bola elástica. Para isso utilizaremos
alguns GameObjects usuais já pré-configurados do próprio Unity3D.
Primeiro criamos um GameObject do tipo Cubo e o expandimos editando suas
propriedades de largura e comprimento no inspector. Depois adicionamos uma esfera e
26
deslocamos ela para cima desse plano. Por final basta adicionar o componente do tipo
Collider em ambos os objetos e um componente do tipo Rigidbody (que adiciona
capacidades físicas como gravidade) para a esfera e pronto. Ao apertar play a esfera
deverá cair e pular algumas vezes sobre o cubo esticado.
Vale ressaltar que os GameObjects predefinidos de cubo e esfera nada mais são
que GameObjects vazios com um componente Mesh com um modelo 3D do elemento.
Unity3D permite a criação de componentes personalizados através de scripts. É
possível criar scripts em 2 linguagens diferentes, C# e JavaScript. Scripts são tratados
da mesma forma que os componentes e podem possuir parâmetros e alterar outros
componentes do mesmo objeto ou de outros
Scripts servem apenas para definir propriedades gráficas ou físicas mas também
para implementar qualquer tipo de funcionalidade desejada como acesso e manipulação
de arquivos e comunicação via protocolo HTTP.
A flexibilidade e o poder são grande. Além disso os scripts são reutilizáveis e, se
forem desenvolvidos corretamente.
27
Capítulo 5
Educational Space Invaders Advance
O Educational Space Invaders (ESIa) é dividido em duas partes, seu portal web
e o jogo multi-plataforma com foco em mobile. No portal é possível criar novos jogos
educacionais e no jogo podemos baixa-los e joga-los.
O portal web e a API de suporte foram desenvolvidas utilizando Java e o
framework SpringMVC (Capitulo 2).
5.1 - Terminologia
Herdaremos a ideia de atividade do glossário do capitulo 3, definida como uma
instancia de jogo. As diversas imagens que são utilizadas para criar uma atividade são
chamadas de Assets. A nave do jogador é a representação do usuário no jogo. As
respostas são as possíveis respostas que uma partida possui. O projetil é um objeto que
é disparado pela nave do jogador. Cada cópia de um projetil possui uma resposta
associada. Inimigos são definidos como as perguntas de uma partida. Cada inimigo
possui uma resposta associada da mesma forma que o projetil.
5.2 - Jogo
O jogo ESIa foi criado utilizando a ferramenta Unity3D introduzida no capítulo
anterior. Três cenas foram criadas ao total. Uma de introdução, uma para gerenciamento
de menus e a última onde o jogo em si é criado. Como a primeira cena é trivial e apenas
serve para apresentação iremos ignora-la. Abaixo descreveremos as duas restantes e
suas estruturas assim como o funcionamento de cada.
28
5.2.1 - Cena de Game
Na cena do jogo existem quatro GameObjects principais, o de gerenciador de
asset, o gerenciador do jogo, o controlador do jogador e o controlador dos inimigos.
O gerenciador de asset é responsável por carregar os assets da memória do
dispositivo e definir seus parâmetros para cada um (como a resposta e o Mesh de
colisão). Após carregar cada um dos assets eles são carregados nos seus respectivos
locais, como o player, respostas e fundo.
Figura 5.1 - Screenshot final da cena do jogo
29
O controlador do jogo é responsável por instanciar os inimigos no topo da tela.
Para isso ele utiliza a lista de inimigos carregada pelo gerenciador de assets. Para cada
inimigo instanciado o gerenciador define sua imagem, uma posição aleatória no eixo
horizontal e sua resposta.
O controlador do jogador é responsável pela movimentação da nave do jogador,
detectar colisões de inimigos com a mesma e de disparar os projeteis. Os botões de
respostas são conectados ao componente de controle do jogador. Ao apertar um dos
botões o componente de controle do jogador cria um projetil no topo da nave do jogador
e associa o valor da resposta do botão ao projetil
O controlador dos inimigos é um componente interno de cada inimigo ele é
responsável por detectar colisões com os projeteis do jogador e verificar se a resposta
associada ao projeto é a mesma associada do inimigo. Caso ambas sejam iguais o
inimigo é destruído e o gerenciador do jogo adiciona 10 pontos ao placar, caso errado
ele remove 5 pontos do placar. Para adicionar ou remover pontos o controlador do
inimigo faz uma chamada ao controlador do jogo.
Quando um dos inimigos colide com a nave do jogador o controlador do jogador
faz uma chamada ao controlador do jogo que finaliza a partida. Caso o jogador esteja
numa atividade de uma sala de aula os dados serão enviados para o CGR e uma tela de
fim do jogo irá aparecer. Caso contrário apenas a tela de fim do jogo irá aparecer.
30
Abaixo temos um diagrama das chamadas dos entre os principais GameObjects
citados acima:
Figura 5.2 - Diagrama dos relacionamentos dos GameObjects do Jogo ESIa
31
5.2.2 - Cena de Lobby
Antes do jogo é necessário selecionar a atividade que irá rodar no mesmo, essa
seleção é feita na cena de lobby. No menu “All Games” é possível listar todos os jogos
disponíveis para serem baixados. Após baixados os jogos ficam armazenados no
dispositivo para serem jogados quando quiser.
Na listagem de jogos baixados é possível visualizar todos os jogos armazenados
no dispositivo. Ao clicar em uma delas o jogo é carregado como descrito no capítulo
anterior (Figure 5.3)
Figura 5.3 - Imagens do Menu Principal, Listagem de jogos disponíveis e Login no CGR
Além de baixar e listar jogos podemos acessar o sistema CGR onde podemos
selecionar uma atividade disponível para aquele aluno. Ao selecionar uma atividade a o
o jogo é carregado automaticamente e o a API do CGR é configurada para o envio dos
dados. Ao fim do jogo os dados daquela partida são enviados para o CGR onde poderão
ser visualizadas e analisadas pelo professor na página web.
32
Figura 5.4 - Diagrama do fluxo de dados nos principais GameObjects
5.3 - Portal Web
O Portal ESIa permite a criação de novas atividades para o jogo base do ESIa.
Ele foi criado no formato One-Page, ou seja apenas uma página é carregada e toda a
comunicação é feita utilizando JavaScript e uma API desenvolvida. O portal web foi
criado utilizado o framework JavaScript, AngularJS, feito pelo Google, permitindo o
carregamento de partes da página conforme a demanda, gerenciamento dos dados da
página usando estruturas JSON e a criação de módulos dinâmicos reutilizáveis o que
facilita a criação de páginas dinâmicas.
O portal é dividido em duas partes principais a listagem de jogos criados e o
editor de jogos.
33
5.3.1 - Listagem de Jogos
Na listagem de jogos é possível visualizar todo os jogos criados pelo usuário.
Ele também poderá criar um novo jogo clicando no botão “+”, deleta-lo ou edita-lo.
Figure 5.5 - Listagem de Jogos
5.3.2 - Editor de Jogos
Ao clicar em editar jogo o usuário é enviado para o editor do jogo onde os dados
da atividade selecionada são carregados (caso seja um jogo novo o editor aparecerá
limpo). O editor está dividido em 2 partes: preview do jogo e o gerenciador de asset.
No gerenciador de asset é possível selecionar assets para os diversos
componentes do jogo. Para enviar uma imagem basta selecionar qual componente você
esta editando e clicar no seu respectivo botão upload. O usuário pode alterar o fundo do
jogo, a imagem que representa o jogador e as perguntas e respostas.
É possível adicionar até 3 respostas e quantas perguntas forem desejadas. Para
isso basta subir as imagens para as respostas e para as perguntas. Para cada pergunta
após subir a imagem é necessário escolher uma das 3 respostas previamente definidas.
Os componentes de respostas permitem definir um nome para facilitar esse processo.
34
A cada novo asset adicionado, o preview é atualizado automaticamente
mostrando o resultado final do jogo. Todos os dados são salvos em tempo real, sem a
necessidade de salvar o projeto de jogo.
Figura 5.6 - Tela de edição de Jogo do ESIa
Após os assets adicionados o jogo se torna ativo e disponível para ser listado,
baixado e jogado pelos alunos.
35
5.4 - API
A API do ESIa foi desenvolvida para possibilitar baixar os dados de cada
instancia de jogo educacional criada assim como permitir a criação de jogos pelo portal
como visto na seção 5.3. Isso justifica o número maior de parâmetros e serviços dessa
API comparada com a do CGR a qual serve apenas para receber dados de uma atividade
ao sistema.
Tabela 5.1 - Relação de Parâmetros da API do ESIa
Parâmetro Descrição
GameID Identificador único do jogo, esse valor é dado pelo Tipo de Jogo
Username Username do usuário
Password Senha do usuário
SessionHash Chave de autenticação do usuário
Mode Opção de listagem de dados (“all” para todos, “mine” para do usuário)
GameID Identificador da instancia de Jogo
GameName Nome da instancia de Jogo
GameDescription Descrição da instancia de Jogo
AssetID Identificador do Asset
AssetType Tipo do Asset
AssetText Texto auxiliar do Asset
ImageID Identificador da Imagem
A seguir é listado uma relação de cada serviço, os parâmetros utilizados em
cada e uma breve definição.
36
5.4.1 - Criar Usuário
/createUser/{Username}/{Password}
Esse serviço serve para criar um novo usuário. O status da transação é recebido
em um formato JSON.
5.4.2 - Logar Usuário
/login/{Username}/{Password}
Esse serviço loga o usuário no sistema. Sua resposta é uma chave alfanumérica
utilizada pelos demais serviços para autenticar o usuário no sistema.
5.4.3 - Listar Jogos Disponíveis
/GetGameList/{SessionHash}/{Mode}
Esse serviço retorna uma lista com os dados principais de todos os jogos
disponíveis no formato JSON. Ele é utilizado tanto para o jogo quanto para o portal por
isso possui um parâmetro “mode” a qual pode ser “mine”, para listar todos os dados do
jogador logado ou “all” para todos os jogos cadastrados no sistema
37
5.4.4 - Criar novo Jogo
/createNewGame/{SessionHash}/
Esse serviço cria um jogo vazio no banco de dados do sistema. Ele não possui
nenhum asset ou dado cadastrado além do usuário que criou e um ID. O serviço retorna
o ID do jogo criado.
5.4.5 - Listar Dados de Um jogo
/GetGameData/{GameID}
Esse serviço serve para pegar todos os dados de um jogo no formato JSON. Ele
é utilizado tanto pelo jogo quanto pelo site para pegar os dados de um jogo que será
editado ou baixado para ser jogado.
5.34.6 - Atualizar dados do Jogo
/UpdateGame/{SessionHash}/{GameID}/{GameName}/{GameDescription}
Esse serviço segue para atualizar os dados de um jogo, no caso são apenas os
parâmetros de nome e descrição. O serviço retorna um JSON com as informações do
jogo mais recentes (no caso, pós atualização).
38
5.4.7 - Deletar Jogo
/DeleteGame/{SessionHash}/{GameID}
Esse serviço serve para deletar um jogo provido seu identificador. Ele retorna
um JSON com o resultado da operação.
5.4.8 - Atualizar Asset
/updateAsset/{SessionHash}/{GameID}/{AssetID}/{AssetType}/{AssetText}/{AnswerId}
Essa é a função principal do editor do jogo. Ela cria ou atualiza assets de um
jogo. Caso um parâmetro tenha o valor -1 o serviço assume que o dado é vazio. Caso o
valor AssetID seja -1 um novo asset é criado. A resposta desse serviço é um JSON com
todos os dados daquele JSON como, URL da imagem, ID, AssetText, etc....
5.4.9 - Deletar Asset
/DeleteAsset/{hash}/{assetId}
Esse serviço serve para apagar algum asset desnecessário. Ele pode ser utilizado
para qualquer um. A imagem referente ao asset porém não é apagada. Isso se deve a
uma funcionalidade não desenvolvida ao longo do projeto, a de reutilizar as imagens
como outro asset para outras atividades.
39
5.5 - Modelo do banco de Dados
Os dados são armazenados em um banco de dados relacional. Abaixo temos o
diagrama UML (Unified Modeling Language) descrevendo como os dados são
conectados.
Figura 5.7 - Diagrama UML do modelo de banco de dados implementado
40
Capítulo 4
Conclusões
6.1 - Resultados
A plataforma foi capaz de cumprir com seus requisitos. Nos testes
desenvolvidos todos os dados do jogo de teste ESIa foram enviados para o CGR e
armazenados. Esse processo foi repetido para diversos jogadores diferentes.
Após o armazenamento desses dados foi possível criar os dois tipos de gráficos
propostos: um para cada atividade com todos os dados de todos os alunos; e o segundo
com todos os dados de todas as atividades para apenas um aluno.
Um outro resultado secundário foi a facilidade de implementação da API do
CGR no jogo ESIa.
6.2 - Melhorias
Muitas ideias de melhorias surgiram ao longo do desenvolvimento, infelizmente
elas custariam tempo para serem desenvolvidas e também sairiam do escopo desse
projeto. Dentre elas as mais interessantes são:
A Capacidade de meta análise dos dados de jogo diferentes, como citado em
3.1.4. Devido a metodologias diferentes de pontuação fica inviável fazer uma
comparação direta dos resultados de jogos diferentes. Uma normalização de alguns
tipos de dados (como pontuação) seria interessante e simples de implementar mas
limitaram a plataforma a apenas esses tipos de dados.
41
Outra ideia é a de permitir que o professor possa enviar mensagens para os
alunos inscritos com algum tipo de feedback do seu resultado e até mesmo permitir que
o aluno tenha acesso os próprios dados.
Algumas melhorias também foram pensadas para o ESIa, como a capacidade de
inserir mais do que 3 respostas e a possibilidade de "aumentar a dificuldade" do jogo
fazendo a velocidade de queda aumentar. Foi levantado também a ideia de diferentes
modalidades de jogabilidade como a modalidade de jogo com tempo limitado.
42
Bibliografia
[1] KLOPFER, E., OSTERWEIL, S., SALEN, K., “Moving Learning Games Forward”, Institute of Technology, The Education Arcade, 2009.
[2] Guia do Scrum, Ken Schaber e Jeff Sutherland, 2013
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf (Acessado em 15 Janeiro 2015) [3] Spring MVC: Beginner's Guide, Amuthan G, 2014 Packt Publishing [4] Guide to Java Persistence and Hibernate, Sebastian Hennebrueder, 2013
https://www.laliluna.de/download/java-persistence-developer-guide.pdf (Acessado em 15 Janeiro 2015)
[5] JQuery Introduction
http://www.ccc.commnet.edu/faculty/sfreeman/cst%20250/jQueryNotes.pdf (Acessado em 15 Janeiro 2015)
[6] GoogleCharts Reference Documentation
https://developers.google.com/chart/interactive/docs/reference (Acessado em 15 Janeiro 2015)
[7] – Unity 3D Game Development by Example, Ryan Henson Creighton, 2010
Packt Publishing [7] – AngularJS In 60MinutesIsh, DanWahlin, 2013
http://fastandfluid.com/publicdownloads/AngularJSIn60MinutesIsh.pdf (Acessado em 15 Janeiro 2015)
43
Apêndice A
Formatação JSON
O formato JSON ("JavaScript Object Notation", é um formato leve para
intercâmbio de dados computacionais. JSON é um subconjunto da notação de objeto de
JavaScript, mas seu uso não requer JavaScript exclusivamente. Apesar de não ser tão
robusto quanto o XML (eXtensible Markup Language) sua simplicidade e leveza são
atrativos para tramitação de dados online onde tamanho e velocidade são fundamentais.
JSON funciona com a ideia de dicionários que não fica distante da ideia de um
array. Cada elemento de um dicionário possui dois componentes: uma chave e um
conteúdo.
{ "nome" : "João" }
Um conteúdo não se limite apenas a texto mas também a uma array de
elementos ou textos:
{ "nome": "João", "notas": [ 8, 9, 7 ] }
Além disso também é possível utilizar um dicionário como conteúdo.
"Alunos" : [ { "nome": "João", "notas": [ 8, 9, 7 ] },
{ "nome": "Maria", "notas": [ 8, 10, 7 ] },
{ "nome": "Pedro", "notas": [ 10, 10, 9 ] } ]
A grande vantagem dessa estrutura de dados sobre o XML além do tamanho é
sua facilidade de leitura e de geração, o que facilita o uso dos serviços criados nesse
projeto.