Este documento apresenta um relatório de projeto final de graduação sobre o desenvolvimento de um framework de game analytics para jogos móveis 2D do tipo plataforma utilizando o Unity. O relatório descreve estudos iniciais sobre taxonomia de jogos, jogos de plataforma e game analytics, além de especificar os requisitos, modelagem de classes e casos de uso do framework.

1. /
Pontifícia Universidade Católica do Rio de Janeiro
Framework de Game Analytics para Jogos Móveis 2D
tipo Plataforma
Beatriz Lopes Vaz Pinto
Projeto Final de Graduação
CENTRO TÉCNICO CIENTÍFICO - CTC
DEPARTAMENTO DE INFORMÁTICA
Curso de Graduação em Sistemas de Informação
Rio de Janeiro, dezembro de 2017

2. /
Beatriz Lopes Vaz Pinto
Framework de Game Analytics para Jogos Móveis 2D tipo Plataforma
Relatório de Projeto Final, apresentado ao programa
Sistemas de Informação da PUC-Rio como requisito
parcial para a obtenção do título de Bacharel em
Informática.
Orientador: Bruno Feijó
Rio de Janeiro
Dezembro de 2017.

3. /
Resumo
Lopes Vaz Pinto, Beatriz. Feijó, Bruno. Framework de Game Analytics para Jogos Móveis 2D
tipo Plataforma. Rio de Janeiro, 2017. 45 p. Relatório Final de Projeto Final II - Departamento
de Informática. Pontifícia Universidade Católica do Rio de Janeiro.
Este trabalho se propõe primeiramente a elaborar uma taxonomia dos principais
gêneros de jogos eletrônicos, para conhecer as principais caracterísitcas de cada um, em
particular jogos de plataforma, para definir como um jogo desse estilo deve ser. Também é feita
uma análise sobre as principais tecnologias a serem usadas e o processo de implementação
da plataforma. O propósito deste framework é criar uma estrutura genérica com suporte para
analytics e banco de dados, para permitir a fácil criação de jogos 2D para dispositivos móveis.
Para demonstrar seu funcionamento, um jogo simples do estilo plataforma, será implementado
com suporte para iOS e Android. Devido à complexidade do sistema, o presente trabalho está
sendo desenvolvido em colaboração com um outro aluno.
Palavras-chave
Game analytics, taxonomia de jogos, jogos de plataforma, jogos de ação, jogos móveis
Abstract
Lopes Vaz Pinto, Beatriz. Feijó, Bruno. Game Analytics Framework for 2D Mobile Platform
Games. Rio de Janeiro, 2017. 45 p. Final Project II Report- Information Technology Department.
Pontifícia Universidade Católica do Rio de Janeiro.
The purpose of this project is firstly to define a taxonomy for the main videogame
genres, in order to know the main characteristics of each one, especially platform games,
hoping to define how a game of this genre should be. An analysis of the main technologies
needed and of the implementation process is also made. The purpose of this framework is to
create a generic structure that supports data analytics and databases, allowing the easy
creation of 2D mobile games. To demonstrate its use, a simple platform game will be
implemented for iOS and Android. The present work is being developed in collaboration with
another student.
Keywords
Game analytics, game taxonomy, platform games, action games, mobile games

4. /
Sumário
1 Introdução…………………………………………………………………………………....1
2 Situação Atual……………………………………………………………………………….....2
3 Objetivos………………………………………………………………………………………..4
4 Atividades Realizadas………………………………………………………………………..5
4.1 Taxonomia……………………………………………………………………………….5
4.2 Jogos de Plataforma…………………………………………………………………….18
4.3 Unity………………………………………………………………………………….....26
4.4 Game Analytics………………………………………………………………………..29
5 Projeto e Especificação do Sistema…………………………………………………..31
5.1 Requisitos……………………………………………………………………………..31
5.2 Modelo de Classes……………………………………………………………………....34
5.3 Casos de Uso………………………………………………………………………….35
6 Implementação e Avaliação…………………………………………………………………...40
7 Considerações Finais………………………………………………………………..42
Referências…………………………………………………………………………………....43

5. /
Lista de Figuras
Figura 1 - Taxonomia de humor em jogos (Rossi, S)
Figura 2 - Um fluxo melhorado (Falstein, N. 2004)
Figura 3 - Fluxo fractal (Sala, T. 2011)
Figura 4 - Modelo conceitual do framework de Smith et al (2008)
Figura 5 - Dois grupos de ritmo em Super Mario World (Smith et al, 2008)
Figura 6 - Modelagem de classes da plataforma
Figura 7 - Início do nível 1 do modo plataforma
Figura 8 - Interface do Unity
Lista de Tabelas
Tabela 1 - Proposta para classificação de gêneros de jogos
Tabela 2 - Cronograma do Projeto I
Tabela 3 - Cronograma do Projeto II

6. /
1 - Introdução
Este projeto se propõe a definir e implementar um framework para jogos móveis 2D no
estilo plataforma, a partir do engine Unity, que utilize a funcionalidade de game analytics, a
ciência de fazer análise de dados sobre os jogadores e realizar previsões, melhorias,
mudanças, com base no comportamento do jogador. O estilo plataforma é um subgênero de
jogos de ação onde o personagem principal pula em plataformas suspensas e/ou pula por cima
obstáculos para avançar no ambiente. Game Analytics é uma ferramenta que permite que1
usuários possam fazer análises e obter métricas online de seus jogos. A pesquisa em game
analytics envolve a definição de estatísticas básicas e a coleta de dados de comportamento do
jogador que permitam o aprimoramento do jogo em suas missões mais vitais. Algumas dessas
missões são as seguintes: aumentar receita; evitar abandono de usuários (churn analysis); e
adequar o jogo às necessidades específicas de cada indivíduo, no sentido de satisfação,
interação e evolução na estória do jogo.
Como preparação para este tipo de trabalho, deverá ser feito um estudo sobre estilos
de jogos, com o objetivo de especificar uma taxonomia. Esta taxonomia é necessária para a
especificação correta do framework. E, para demonstrar o uso do framework, será
implementado um jogo simples 2D, no estilo plataforma. Este jogo deverá ter, no mínimo, dois
níveis.
Como a funcionalidade de game analytics requer a implementação de outras
funcionalidades para desenvolvimento de jogos, o projeto será realizado em cooperação com
um outro aluno. Este outro aluno terá o foco nas funcionalidades mais gerais e básicas.
Entretanto, esta cooperação envolverá várias investigações e especificações em comum.
Neste projeto serão explorados os desafios da implementação da plataforma, os
métodos de implementação, testes e outros aspectos técnicos. Uma versão mais detalhada da
taxonomia de jogos também foi feita, para poder englobar mais jogos e permitir uma
classificação com maior facilidade. Este documento apresenta seu conteúdo da seguinte forma:
uma seção sobre a situação atual das tecnologias, o objetivo do projeto, estudos teóricos e
atividades realizadas, especificação do sistema, metodologia de implementação e testes e
finalmente, considerações finais.
1
http://www.gameanalytics.com/

7. /
2 - Situação Atual
Hoje em dia, jogos para celular existem em abundância. Existem empresas
especializadas em desenvolvimento desses jogos, como por exemplo a Tapps Games, uma
empresa brasileira, que hoje já possui mais de cem jogos para iOS e Android, mas há também
desenvolvedores independentes que fazem jogos simples com bastante rapidez que podem
fazer sucesso. Muitos não fazem, o que não é um problema muito grave, já que o investimento
normalmente não é muito grande, o que leva pessoas e pequenas empresas a tentarem
diversas vezes até acertar.
Este é o caso da empresa finlandesa Rovio Entertainment, a criadora do famoso Angry
Birds (Rovio, 2009). Atualmente, todos conhecem, ou pelo menos já ouviram falar no Angry
Birds, que já virou até filme e deixou de ser um simples jogo: agora é uma marca. Apesar do
sucesso estrondoso da Rovio com esse jogo, antes dele, eles já haviam tentado e falhado 51
vezes. A empresa teve 51 jogos que não fizeram sucesso, mas como desenvolvê-los não era
trabalhoso em excesso, foi possível criar vários, até chegar a um que desse certo.
Contudo, para deixar o desenvolvimento ainda mais fácil, é interessante utilizar
ferramentas já prontas e testadas, para evitar problemas que possam comprometer o jogo.
Apesar da simplicidade, os jogos precisam se preocupar com uma série de questões, tais
como: onde e como vão armazenar dados, se informações sobre os jogadores devem ser
registradas, se a pontuação vai ser exibida online para outros jogadores, entre outros. Apesar
desses aspectos não serem sempre visíveis para o jogador, são tão importantes quanto o jogo
em si, então é essencial que sejam bem definidos. Ao fazer um único jogo, eles já serão
necessários, então, ao invés de usá-los uma vez só, seria interessante criar um framework que
possa ser usado para gerar novos jogos. Vale ressaltar também a importância do produto ser
multiplataforma. Como cada sistema operacional tem sua linguagem e sua arquitetura, seria
muito custoso desenvolver o jogo inteiramente para um sistema, e depois para um outro. Vale
mais a pena encontrar uma maneira de programar o jogo apenas uma vez em cima de alguma
base que permita que ele funcione em múltiplos dispositivos sem precisar de modificações.
Como visto, existem muitas empresas pequenas e pessoas autônomas que fazem diversos
jogos. Entretanto, não há nenhuma ferramenta desse tipo que tenha sido disponibilizada.

8. /
Existem diversas ferramentas que podem ser usadas para atingir esse objetivo, porém não
estão todas ligadas entre si. Estas questões serão tratadas neste projeto.
Uma ferramenta promissora que já existe é o MonoGame, um software open-source da
Microsoft, que pode ser usado em um IDE como o Visual Studio ou o Xamarin Studio para criar
jogos 2D e 3D multiplataforma. Ele pode ser usado tanto para jogos mobile quanto para jogos
de console, como PlayStation e Xbox. Jogos de sucesso tais como Fez (Polytron, 2012) e
Bastion (Supergiant Games, 2011) foram feitos utilizando-o. Para programar utilizando o
MonoGame, a linguagem necessária é o C#, usado em várias outras soluções multiplataforma
que serão vistas mais a frente. Apesar do MonoGame parecer bastante útil, faltam dois
aspectos que a plataforma deste projeto deve ter: persistência de dados e game analytics. Há
diversos bancos de dados que podem ser usados junto ao MonoGame, no entanto, não há
nenhum que seja diretamente compatível. O MonoGame também não oferece nenhum suporte
para analytics. O próprio MonoGame faz uma análise sobre o jogo em background caso o
desenvolvedor dê permissão, porém não é isso que é desejado para este projeto. Algumas
outras opções para desenvolvimento mobile multiplataforma, incluem: Marmalade SDK, Unreal
Engine e Unity. Dentre estas, a que atualmente melhor se encaixa nos requisitos do projeto é o
Unity.
Similar ao MonoGame, o Unity permite que jogos sejam feitos para dispositivos móveis,
consoles e computadores, e oferece uma série de funcionalidades já prontas para facilitar a
criação de um jogo. Uma funcionalidade essencial para o projeto é a integração com o Game
Analytics. Apesar de possuir sua própria biblioteca de análise de dados, Unity Analytics, é
possível utilizar os serviços do Game Analytics através da importação de um pacote gratuito,
disponível da loja online de assets do Unity (Silva, 2014). O desenvolvimento pode ser feito em
C#, como no MonoGame, ou em JavaScript, e em termos de armazenamento, pode-se integrar
o projeto com bancos de dado relacionais, como PostreSQL, ou NoSQL como Firebase. Por
unir diversas funcionalidades necessárias para este projeto, o Unity parece ser a engine mais
adequada, e será vista com maior profundidade mais a diante.
Em termos de analytics, apesar do Game Analytics ser o escolhido para este projeto,
vale lembrar que existem outras opções no mercado. Outras alternativas serão detalhadas na
seção sobre game analytics mais a frente, mas de forma geral, não são tão adequadas para
este projeto, por se tratarem de serviços de consultoria pagos. Ferramentas que oferecem
análise e previsões automatizadas, utilizando inteligência artificial, não estão disponíveis no
mercado para desenvolvedores de pequeno porte.

9. /
3 - Objetivos
O objetivo deste projeto é criar um framework para jogos móveis 2D no estilo
plataforma, a partir do engine Unity para a funcionalidade de game analytics. Esse framework
deve mirar para ser genérico de forma que diversos jogos possam ser feitos em cima dele,
utilizando as funcionalidades básicas que ele oferece: game analytics e persistência de dados.
Para demonstrar o uso do framework, será implementado um jogo simples 2D, no estilo
plataforma, com dois níveis, no mínimo. Um outro objetivo deste projeto é a elaboração de uma
taxonomia de jogos (estilos/gêneros) para apoiar a definição do framework, com suas
características e funcionalidades.
Neste trabalho também será detalhado o processo de implementação do framework,
que incluirá modelagem, casos de uso, teste e uma relação de quais requisitos foram
implementados.

10. /
4 - Atividades realizadas
Nesta seção serão abordadas as atividades realizadas necessárias para a
especificação e implementação do projeto. Uma das atividades inclui uma pesquisa sobre
fundamentos teóricos necessários para o desenvolvimento do framework e do jogo do gênero
plataforma que será feito. Estes conceitos analisados cobrem a parte de estudos preliminares e
estudos teóricos. Será analisada a taxonomia dos jogos eletrônicos, com uma breve descrição
sobre cada gênero, com foco em jogos de ação. Jogos de plataforma 2D são analisados em
detalhe, e as tecnologias que serão usadas na implementação da plataforma, com foco em
analytics também são exploradas. A parte de testes e método de implementação também será
explorada depois da teoria.

11. /
4.1 Fundamentos Teóricos
4.1.1 Taxonomia de Jogos Eletrônicos
O jogo proposto a ser desenvolvido em cima da plataforma base é um jogo do tipo
plataforma. Plataforma (platform ou platformer) é um subgênero de jogos de ação, que consiste
essencialmente em guiar um personagem pelo seu mundo, pulando em plataformas
suspensas, evitando buracos no chão e ultrapassando certos obstáculos. Essas características
são o principal diferencial entre jogos de plataforma e outros tipos de jogos, no entanto,
diversos outros podem incluir temas parecidos. Quais são esses outros jogos?
Jogos eletrônicos podem ser divididos em diversas categorias, gerando assim uma
taxonomia de gêneros. Como visto na Figura 1, que relaciona gêneros de jogos com traços de
humor e personalidade dos jogadores, jogos podem ser divididos nos seguintes tipos: ação,
aventura, luta, puzzle (quebra-cabeça), corrida, role-playing (jogo de interpretação de papéis),
shooter (jogos de tiro), simulação, esporte e estratégia. Essa classificação ainda pode se
estender para incluir mais três gêneros: party (festa), management (gerenciamento) e 4X (Gunn
E. A. A. et al). No entanto, essa taxonomia formal é mais utilizada mais por desenvolvedores e
acadêmicos. Usuários e a mídia geralmente encaixam os jogos em gêneros já existentes para
outros tipos de mídia, como filmes. No entanto, como o objetivo é criar um jogo, é importante
explorar a taxonomia definida e usada em pesquisas e desenvolvimento.
Para ser possível entender o que torna o jogo de plataforma diferente dos outros, é
necessário analisar resumidamente as características principais de cada um. Vale ressaltar, no
entanto, que grande parte dos jogos na verdade é uma combinação de gêneros.

12. /
Figura 1.Taxonomia de humor em jogos (Rossi, S)

13. /
Ação
Jogos de ação costumam ter um ritmo rápido, onde é necessário fazer julgamentos
rapidamente e decisões instantâneas. Também contam com NPCs (personagens não-jogáveis),
controlados pelo computador que podem ajudar ou dificultar o progresso ao longo do jogo.
Normalmente o jogador controla um personagem e tem que cumprir determinadas tarefas ou
missões para avançar no nível e no jogo de forma geral.
Outra característica importante é que a falha em cumprir um determinado objetivo
definido pelo jogo geralmente resulta em alguma punição. Alguns exemplos de punição
incluem: não completar uma fase dentro do tempo permitido, ser morto por um inimigo, não
conseguir resolver algum quebra-cabeça, entre outros. O que é considerado uma falha
depende do tipo de jogo, e como lidar com ela também (Juul J.). É essencial lembrar que
punição por falha existe para mostrar ao jogador que ele errou; ou seja, ele foi punido por ter
feito algo errado, algo que ia contra os objetivos ou regras do jogo. A punição não é uma
resposta errada do jogo ao jogador.
● Punição e Recompensa
Punição por falha pode ser de diversos tipos: perda de recursos, como dinheiro e itens,
perda de uma vida, e o mais comum, e às vezes mais grave, perda de progresso. Para avançar
em um jogo, é necessário investir bastante tempo, então a punição mais severa é descartar
parte do tempo investido, ao fazer o jogador voltar para um ponto anterior do jogo, do qual ele
já tinha passado. O tempo perdido afeta o jogador no mundo real, e não no mundo do jogo,
pois quando isso acontece, ele terá que jogar partes que ele já havia feito de novo. Alguns
jogos permitem que o progresso seja salvo a qualquer momento, quantas vezes o jogador
quiser, o que faz com que a perda seja menor, já que o jogador sempre irá retornar do seu
último estado salvo, o que normalmente não significa muito progresso perdido. No entanto, há
muitos jogos onde só se pode salvar o progresso em pontos determinados. Se o jogador falhar
em qualquer dado momento, ele volta para o último local onde pode salvar seu jogo, o que
pode significar uma perda de progresso significativa.
Por mais que falha e punição possa ser algo frustrante, é um aspecto importante para
os jogos, para que eles não sejam fáceis demais. A teoria Flow (Mihaly Csikszentmihalyi, 1990)
sugere que há um ponto ideal entre a dificuldade de um jogo e a habilidade do jogador que
evita tanto a ansiedade quanto o tédio, mantendo o jogador entretido sem ser punido ao ponto
de se frustrar e desistir do jogo. Um modelo novo (Figura 2), estipulado por Noah Falstein

14. /
(2004) sugere que o jogo não seja nem tão fácil, nem tão difícil, mas sua dificuldade não deve
aumentar linearmente, mas sim oscilar, proporcionando momentos mais fáceis e mais difíceis
do que esperados, e é essa irregularidade que proporciona maior aproveitamento (Juul J.).
Figura 2 - Um fluxo melhorado. (A Better Flow. © 2004 Noah Falstein)
Este fenômeno, também conhecido como fluxo, não se aplica exclusivamente a jogos.
Como sugerido por Baere (2012), o fluxo é uma sensação de foco completo e energizado em
uma atividade, que resulta em prazer e satisfação. Além disso, qualquer pessoa pode
experimentar fluxo em alguma atividade desde que a pessoa possua habilidades a altura dos
desafios e consiga perceber as oportunidades de atingir fluxo. Finalmente, para chegar lá, é
preciso dedicar uma certa quantidade de tempo e esforço à atividade em questão. Uma vez
que a pessoa se encontra no estado de fluxo, alguns fenômenos que podem ser notados são:
foco total na tarefa, perda da percepção do tempo e perda de auto-percepção. Para que uma
pessoa possa experimentar fluxo, a atividade deve possuir algumas características. As
principais, descritas por Schell (2011), são:
● Objetivos claros - Se os objetivos são claros e bem definidos, o participante tem
mais facilidade em focar na tarefa que ele está executando, mas quando não
são, não é possível manter o foco, pois não se sabe se as ações sendo
executadas são de fato úteis para a conclusão da tarefa. A importância dessa
característica também é ressaltada por Desurvire et al. que sugere que

15. /
objetivos, além de claros, estejam presentes desde o começo do jogo. Além
disso, deve haver objetivos de curto prazo ao longo de todo o jogo.
● Sem distrações - Distrações tiram o foco da tarefa, e sem foco, não há fluxo.
● Feedback direto - Após a realização alguma ação, é importante receber
reconhecimento, para que o participante saiba que ela teve efeito. Caso a
atividade demore a mostrar algum reconhecimento pela ação, de forma que o
participante não conheça o resultado da mesma, ele pode perder interesse e
foco.
● Desafio contínuo - Pessoas gostam de desafios, mas somente se sentirem que
há uma possibilidade de alcançá-lo. Se o desafio for difícil demais, e a pessoa
sentir que não é possível o alcançar, ela se sente desmotivada e frustrada, e
busca algo que possa ser mais recompensador. No entanto, caso o desafio seja
fácil demais, a pessoa pode ficar entediada, e acabar procurando uma atividade
diferente, mais recompensadora.
Voltando ao conceito de fluxo aplicado à jogos, como entendido por Cowley et al.
(Cowley, 2008), se olharmos para um jogo como uma atividade limitada por regras que o
jogador aceita obedecer ao escolher participar em tal atividade, temos que o fluxo é um estado
de operação ótimo de um sistema de informação, onde um sistema de informação é definido
como algo que recebe uma entrada, a processa, e gera uma saída. Um exemplo simples disso
seria um jogo onde o usuário aperta um botão, o sistema processa esta entrada, e como
resultado, faz o personagem pular.
Para melhor entender os conceitos do fluxo aplicados ao mundo dos jogos, pode-se
utilizar a correspondência feita por Baere (2012) que relaciona elementos do fluxo com
aspectos de gameplay. Se olharmos os principais, temos:
● Objetivos claros - O jogo deve possuir missões, enredo ou níveis, ou seja,
qualquer resultado claro de progresso em uma determinada seção de jogo.
● Sem distrações - O jogador deve estar imerso na tarefa, sem intromissões. Isso
se dá pela alta motivação para jogar, sem a sensação de obrigação, e pela
empatia pelo conteúdo.
● Feedback direto - Penalidades por falha e recompensas adequadas no momento
certo, após determinadas ações.
● Desafio contínuo - A experiência completa do jogo deve proporcionar tarefas
desafiadoras que podem ser completadas.

16. /
A chave é manter um equilíbrio entre desafios e habilidade. Uma abordagem
ligeiramente diferente desse equilíbrio pode ser visto no modelo de Fractual Flow Channel,
sugerido por Sala (2011). O fluxo fractal (Figura 3) difere dos outros por incluir uma quebra no
aumento da dificuldade em determinados pontos do jogo. Por exemplo, um jogo composto por
vários níveis ou mundos pode diminuir a dificuldade sempre que o jogador terminar um mundo.
Um nível ou mundo é um pedaço do ambiente do jogo que engloba uma missão específica. Em
alguns casos, a missão é simplesmente chegar ao final do nível. O nível é um espaço onde o
jogador encontrará desafios com dificuldade crescente. Vimos que uma boa tática para atingir o
fluxo é ter dificuldade oscilante ao longo do jogo. No entanto, pode ser cansativo ser desafiado
constantemente sem tempo para fazer uma pausa. Essa ideia que introduzir uma pausa depois
de uma longa série de dificuldade crescente é o que o fluxo fractal propõe.
Isso dá ao jogador uma sensação de calma, e alívio, após uma sessão difícil, que o
encoraja a continuar, porém mais calmo. Se o jogador possuir as habilidades necessárias para
completar aquela fase, ele será recompensado com uma dificuldade menor do que o esperado,
por um breve momento, antes que ela aumente de novo e o ciclo se repita. Essa quebra no
aumento de dificuldade também é importante para dar ao jogador um tempo de entender as
regras e características do novo mundo ou nível (Sala, 2011). O jogador pode ter se tornado
bastante experiente no nível anterior, mas pode não estar completamente preparado para o
que estar por vir. Então, ao invés que já começar o nível com desafios mais difíceis que os
anteriores, o começo do novo nível dá ao jogador tempo de conhecer o que há de diferente, e
só depois a dificuldade ultrapassa de fato a do nível anterior. Essa ideia também é apoiada por
Desurvire et al, que sugere que a fadiga e tédio do jodar são minimizados se o jogo oferece
atividades variadas e dificuldade alternada. É importante que o jogo faça pressão em cima do
jogador, mas sem frustrá-lo. A dificuldade deve variar de forma que seja cada vez mais
desafiador para o jogador, conforme ele melhora suas habilidades. De forma geral, o jogo deve
ser fácil de aprender, e difícil de dominar.

17. /
Figura 3. Fluxo fractal (Sala, T. 2011)
Considerando o que foi explorado, fica claro que uma característica importante que
jogos de ação, entre outros, devem ter é o equilíbrio entre desafio e habilidade, e punição por
falha quando algo não é cumprido. Mas como deve-se incentivar o jogador a querer jogar? É
desejável que ele também ganhe, por isso é importante abordar a noção de recompensa por
sucesso.
De acordo com Isbister et al (2008) enfatizar o sucesso no lugar da falha é uma
constatação óbvia. Porém, a forma como isso é feita em jogos de tipos diferentes chama
bastante atenção. Jogos casuais, ou seja, jogos mais simples, com menos demanda por tempo
e habilidade, normalmente possuem recompensas por sucesso muito mais frequentes e
significativas do que sua contrapartida, os jogos hardcore, que são mais complexos e muitas
vezes competitivos. Jogos hardcore como jogos de ação ou tiro, em média, não oferecem uma
recompensa muito interessante para o jogador quando ele tem sucesso. Por exemplo, matar
um inimigo com sucesso normalmente não resulta em nada além de ver seu corpo caindo. O
verdadeiro sentimento de sucesso e de realização é guardado para ser transmitido depois de
um desafio mais complexo, como eliminar um inimigo muito poderoso (chefe) ou por completar
um nível.
Em jogos mais imersivos, como Half-Life (Valve), exemplo selecionado por Isbister et al,
mesmo após um grande desafio, o feedback pelo sucesso é poupado, e o jogador não tem a
sensação de realização esperada. Isso serve para manter a consistência da narrativa, visto que
em jogos desse tipo a história é um elemento muito importante. Além disso, falha é punida mais
severamente do que em outros tipos de jogos. Muitos jogos hardcore seguem este modelo, de

18. /
dar mais ênfase na falha, de forma a ensinar aos jogadores que eles não devem contar com
sucesso de curto prazo, e que a realização está em grandes vitórias. Isso resulta é uma
mentalidade hardcore onde o jogo é visto como uma luta que deve ser ganha. Esse modelo
não é uma regra, e há jogos onde as recompensas e falhas são mais balanceadas.
Para ilustrar a diferença, temos o jogo casual Peggle (PopCap Games), do gênero
puzzle. Nesse jogo, a cada ação concluída, como quebrar um tijolo, ou encontrar um objeto, o
jogador ganha pontos. Os pontos são exibidos na tela constantemente e um som sempre toca
quando mais pontos são adicionados ao total. O jogador é sempre lembrado do seu sucesso, e
falha não é grave. Sons e reações para falha são mais discretos, e o maior falha possível
costuma ser apenas recomeçar um nível. Jogos casuais normalmente possuem níveis de curta
duração, e sempre mostram ao final de cada o sucesso e progresso do jogador. Isso faz com
que o jogo não seja uma série de obstáculos frustrantes, mas sim uma experiência que permita
que o jogador se sinta confiante com suas vitórias.
Por fim, como dito por Isbister et al, é importante lembrar que o jogo não pode ser fácil
demais e recompensas também não podem estar muito além do que de fato foi realizado. Se o
jogo não possuir desafio nenhum, o jogador vai ficar entediado e vai acabar desistindo do jogo.
É importante que exista tanto recompensa quando punição em momentos adequados, de forma
que o jogo seja desafiador, mas agradável de jogar. Jogadores frustrados demais podem
acabar abandonando o jogo também. Para reforçar esta ideia, como visto por Desurvire et al, o
jogo deve dar recompensas que ajudem a deixar o jogador mais imerso no jogo, ao melhorar
suas capacidades e, quando possível, aumentar sua habilidade de customização.
Esse gênero é bastante abrangente, então alguns jogos famosos, bastante diferentes,
selecionados para exemplificar são: a série Saints Row (Volition) e Super Mario World
(Nintendo). Saints Row é um jogo 3D que mistura ação com aventura. Ele é mundo aberto, ou
seja, o avatar pode percorrer todo o mapa como se fosse um único nível muito grande (ele não
está restrito à completar níveis diferentes sequencialmente), ele possui uma história, que é
contada conforme o jogador faz progresso ao concluir missões principais e missões
secundárias, que não interferem com a história mas pode dar recompensas como dinheiro,
armas e experiência. O jogador controla um personagem que pode ter sua aparência
totalmente customizada, pode ser aprimorado conforme sobe de nível, pode navegar pelo
mundo a pé ou de carro, pode interagir com pessoas, atirar em inimigos, e pode fazer
diversions, ou seja desvios (da história principal), como fazer uma corrida pela cidade, para

19. /
ganhar dinheiro e experiência. Além disso, o jogador possui um número ilimitado de vidas, ou
seja, ele pode morrer sem muitas consequências: se o jogador estiver no meio de uma missão,
ele perde e tem que recomeçá-la, ou tem que continuar de um checkpoint, um ponto durante a
missão onde o jogo salva o progresso já feito, ou, se não estiver, ele só perde um pouco de
dinheiro e seu personagem volta em algum lugar do mundo, normalmente perto de um hospital.
Saints Row é um jogo grande, onde o jogador é livre para fazer diversas atividades em
qualquer ordem, e no seu ritmo, tornando cada experiência única, apesar da história ser
sempre a mesma.
Já o Super Mario World, um dos muitos títulos da franquia Mario (Nintendo), é
completamente diferente, apesar de ser também um jogo de ação. Ele é do subgênero
plataforma, o mesmo a ser implementado neste projeto, que vai ter suas características
abordadas mais adiante. Mas de forma geral, suas principais diferenças são: ele é 2D, ele é
separado em níveis, ou seja, o jogador não pode ficar indo de um nível para outro a qualquer
momento, ele deve completar um nível antes de ir para o próximo, o jogador não pode
aprimorar suas habilidades do avatar, há um número limitado de vidas, mas que pode aumentar
conforme o avatar pega itens coletáveis. No entanto, é um jogo que também possui
checkpoints, que poupam o esforço do jogador ter que refazer o nível todo, caso ele morra
depois de passar e ativar um, mas vale notar que caso todas as vidas acabem, o jogador perde
e tem que começar de novo de qualquer jeito, permite que o jogador elimine inimigos e, apesar
de ser um jogo mais simples, possui diversos níveis, locais secretos, e vários desafios em cada
nível, que não são limitados à apenas andar por plataformas.
Concluindo, apesar de constar como um gênero separado na Figura 1, o gênero shooter
na verdade pode ser considerado um subgênero de jogos de ação. Jogos deste tipo
geralmente testam a velocidade e tempo de reação do jogador, cujo foco é a utilização de uma
arma de fogo, ou alguma arma de longo alcance, pelo personagem controlado. Um item
bastante comum que pode ser encontrado no jogo, e é essencial para o sucesso, é munição. O
objetivo é eliminar inimigos e completar missões sem ser atingido e morto. Uma franquia
conhecida desse estilo é Call Of Duty (Activision).

20. /
Aventura
Jogos do gênero aventura possuem foco na história e não nos gráficos ou ação. O jogo
pode ter uma estrutura bastante simples, mas se tiver um enredo complexo, ele entra nessa
categoria. Por exemplo, um jogo onde o jogador não pode interagir com o ambiente, mas pode
participar, ouvir ou desvendar uma história se encaixa como jogo de aventura. O objetivo nesse
tipo de jogo é ir descobrindo e efetivamente completar a história. Alguns exemplos desse
gênero: Until Dawn (Supermassive Games), Heavy Rain (Quantic Dream) e Life Is Strange
(Dontnod Entertainment) (Purchese R., 2014). Uma característica que esses três jogos têm em
comum é o sistema de capítulos. A história é contada em capítulos, e, diferentemente de jogos
de ação, o jogador não deve concluir missões, mas sim, ir progredindo ao longo da história.
Decisões tomadas em um capítulo afetam os seguintes, e novamente, diferentemente de
missões, normalmente o jogador não tem como falhar um capítulo. Se alguma decisão resultar
na morte de um personagem, ele não volta para o começo e tenta de novo; essa consequência
o acompanha até o final do jogo. Para enfatizar o peso das decisões ao longo da história, caso
o jogador queira mudar algo, ele deve recomeçar um capítulo inteiro, e tomar ações diferentes
para mudar o resultado. Jogos desse tipo normalmente também possui diversos finais, que
mudam de acordo com o que foi feito durante o percurso da história.
Os três jogos mencionados possuem outra coisa em comum: eles se encaixam na
subdivisão de jogos de narrativa, onde a jogabilidade geralmente consiste em resolver alguns
quebra-cabeças, percorrer árvores de conversas com outros personagens do jogo, e até
mesmo quick time events (momentos durante uma cena de ação onde o jogador tem que agir
rapidamente e pressionar algum botão conforme exibido na tela) para ajudar na imersão.
Outra subdivisão do gênero de aventura são é a de jogos point-and-click (apontar e
clicar). Normalmente, os inputs do usuário são limitados a mover o mouse e clicar em objetos
na cena para realizar alguma ação. O jogador pode ver ou coletar itens, se deslocar de um
ambiente para outro e falar com outros personagens. O objetivo, de forma geral, é coletar itens
e saber como e quando usá-los para chegar no final do jogo. Há especialização desse tipo de
jogo, conhecida como escape the room (escapar da sala), onde o ambiente é limitado a uma
sala, e o jogador deve resolver puzzles para conseguir sair de lá.
Jogos de aventura também podem focar em quebra cabeças (puzzle adventure), onde a
resolução dos desafios progride a história, ou apenas na exploração (exploration), onde ações
são quase inexistentes, e o máximo que o jogador pode fazer normalmente é andar pelo
mundo do jogo.

21. /
Por fim, a última subdivisão dentro do gênero de aventura é a de visual novels. Visual
novel é um gênero de origem japonesa que consiste em acompanhar a história de um
personagem através de textos e imagens. Para progredir, o jogador deve avançar nos textos e
às vezes tomar decisões que podem mudar o andamento da história. Esse jogos são como um
filme interativo, onde quem joga escolhe o caminho que quer seguir. Um jogo conhecido dessa
categoria é Ace Attorney (Capcom), onde o jogador controla um advogado que está tentando
resolver um caso. Para descobrir evidências, o jogador deve avançar na história a ver o que os
personagens tem a dizer e obter itens ou provas. Para descobrir a verdade e concluir o caso, o
jogador deve saber que perguntas fazer em certas situações, e que itens usar. Caso o jogador
escolha apresentar uma prova incorreta, por exemplo, ele é penalizado, algo não tão comum
em jogos visual novel.
Corrida
Jogos de corrida, ou de carros no geral, consistem primeiramente no controle de um
veículo, e não de um personagem. O veículo existe em um mundo com abstrações da física do
mundo real para proporcionar ao jogador uma experiência mais realista. Pode-se ver jogos de
carro mais voltados para simulação e outros mais focados em corrida. Em ambos os tipo
geralmente há uma grande variedade de carros reais que podem ser usados, permitindo
customizações e alterações. Um exemplo é: Gran Turismo (Polyphony Digital).
Esporte
Jogos de esporte são jogos que simulam a prática de algum esporte. Muitos esportes já
existem na forma de jogos eletrônicos, o que inclui: esportes em time, atletismo, combate, entre
outros. Há algumas dúvidas ainda sobre o que pode de fato ser considerado um jogo de
esporte (Stein A. et al, 2013). Jogos de simulam esportes reais se encaixam nessa categoria,
claramente, mas e jogos de e-sport (esporte eletrônico) ou jogos de fitness digitais como yoga,
corrida, entre outros, presentes no Wii Fit (Nintendo). De forma geral, considera-se jogos com
objetivo de vencer ou treino como esporte.
Dentre este gênero, pode-se separar os jogos de esporte em duas categorias: foco na
estratégia por trás de gerenciar um esporte, ou uma carreira, por exemplo Out of the Park
Baseball (Out of the Park Development), ou foco na prática do esporte em si, como o FIFA
(EA).
Se considerarmos e-sports como um esporte, temos outra categoria. E-sports não
precisam refletir um esporte do mundo real, mas por possuírem a característica de alta
competitividade, estão sendo mais assistidos pelo público do que esportes de verdade em

22. /
algumas ocasiões (Statt N., 2015). Um dos e-sports mais conhecidos é a série Super Smash
Bros. (Nintendo).
Estratégia
Jogos de estratégia tiram o jogador da experiência baseada em um personagem e o
colocam em um perspectiva mais alto nível. Isso geralmente inclui a criação e controle de
grupos de personagens, estruturas e recursos. O objetivo em geral costuma completar
campanhas, como por exemplo conquistar aos poucos várias áreas de um país ou planeta. O
segredo para concluir o jogo está em saber distribuir seus recursos e personagens com a
melhor estratégia. E o que é estratégia? Estratégia é um plano de longo prazo cujo objetivo é
indiretamente trazer vantagem para um partido dentro de um ambiente, às custas do outro, por
exemplo, inimigos. Estratégias envolvem observação do ambiente, dos detalhes,
tranformando-os em vantagens futuras. Vale notar aqui que a estratégia deve ser livre para o
jogador elaborar. Caso esta esteja pré-determinada, e basta o jogador encontrá-la, o jogo se
torna um puzzle. Vale ressaltar que jogos de cartas podem ser considerados do gênero
estratégia.
Um jogo famoso por possuir essa característica é o Spore (Maxis). O objetivo no Spore
é manipular a evolução de uma criatura desde seu estágio inicial, como uma bactéria, até o
domínio do espaço. O jogador pode controlar que habilidades sua criatura vai ter, até que
métodos vai utilizar para conquistar cidades, na fase de civilização, como vai interagir com
outras civilizações no espaço,e muito mais. Não há um objetivo certo. Cabe ao jogador decidir
como vai ser a jornada da criatura. O único objetivo, de forma geral, é evoluir até a fase
espacial (Hall R. et al).
Há uma subdivisão do gênero estratégia, 4X, que é considerado por alguns um gênero
à parte. A categoria 4X (eXploring, eXpanding, eXploiting, eXtermination) é utilizada para
representar jogos que envolvem exploração do espaço e de recursos, expansão e extermínio.
Jogos 4X tem vários elementos em comum com jogos de estratégia, porém a principal
diferença entre os dois é o nível de abstração do jogador. Normalmente no caso de estratégia,
o jogador é quem controla o mundo do ponto de vista de um “deus”, enquanto em jogos 4X o
jogador controla um personagem, o líder do mundo. Um jogo que se encaixa nessa categoria,
onde o objetivo é conquistar a galáxia é o Endless Space (Amplitude Studios).

23. /
Luta
Jogos de luta consistem no controle de um personagem que entra em combate com
outro, que pode ser controlado por inteligência artificial, ou por outro jogador. Normalmente as
lutas consistem em diversos rounds, onde em cada round um jogador deve tentar derrotar o
outro. Quem vencer o maior número de rounds vence a partida. Os personagens também
costumam ter habilidades bem diferentes entre si que visam ser justas e balanceadas, ou seja,
nenhum personagem deve ter uma vantagem muito grande sobre o outro, de forma que
utilizá-lo torna o jogo muito mais fácil para o jogador (Newheiser M., 2009.). Se todos os
personagens tiverem habilidades equiparáveis, o que determina de quem será a vitória é a
habilidade do jogador. Saber como e quando utilizar técnicas como bloquear, atacar,
contra-atacar e combos, uma combinação de ataques, são essenciais para a vitória. A maioria
dos jogos também dá a cada personagem um ataque especial único, que é muito mais
poderoso que os normais, e requer uma combinação correta de inputs para ser executado.
Uma franquia bastante famosa deste gênero é o Mortal Kombat (Midway Games, Acclaim
Entertainment), que já está no seu décimo jogo, Mortal Kombat X.
Management
Jogos de gerenciamento, conhecido também como god games (jogos de Deus),
possuem similaridades com jogos de estratégia, por contarem com uma visão alto nível do
mundo e recursos a serem gerenciados. O jogador pode alterar o mundo com base nesses
recursos, afetando a população do mundo. Esses jogos podem ter um objetivo específico ou
não. Um exemplo é o SimCity (Maxis) onde a ideia do jogo é gerenciar uma cidade.
Música
A principal característica de jogos de música é o foco na interação do usuário com
músicas, ritmo e partituras. Esses jogos podem possuir diversos estilos diferentes, alguns
podendo até se encaixar no gênero puzzle por possuírem puzzles gerados ritmicamente
(Gudmundsen, J.), porém, o tipo mais comum é de jogos de ritmo, como Guitar Hero (Harmonix),
Patapon (SCE Japan Studio). Jogos de ritmo possuem uma similaridade com jogos de ação pois
exigem que o usuário esteja sempre atento e pronto para tomar decisões imediatas, porém, essas
ações são baseadas em uma música ou ritmo. Para o jogador conseguir que a ação seja concluída
com sucesso, ele deve fazer algo, como apertar um botão, em determinado ponto do ritmo.
Normalmente, esses jogos também contam com sinais visuais para ajudar o jogador a realizar a
ação no momento certo. O jogo Patapon, por exemplo, além de possuir o ritmo, mostra na tela qual
botão deve ser apertado em cada determinado momento. De forma geral, esses jogos testam a

24. /
memória musical do jogador e sua capacidade de apertar botões na hora certa. Jogos que
permitem a criação de músicas, como SimTunes (Maxis) também se encaixam nessa categoria.
Puzzle
Jogos de quebra cabeça costumam ser pequenos e sem atores ou personagens
jogáveis. O jogo geralmente pode ser completado utilizando lógica e dedução para atingir os
objetivos estabelecidos. Um jogo desse gênero bastante conhecido é o Bejeweled (PopCap)
que consiste em trocar gemas de posição, criando combinações necessárias para passar de
nível.
Elementos de puzzle podem também ser utilizados em conjunto com outros gêneros
para criar jogos mais complexos, como o Fez (Polytron Corporation), um jogo puzzle-platform
onde o jogador controla um personagem e o guia por um mundo, cumprindo objetivos para
avançar, onde cada objetivo é alcançado através de quebra cabeças complexos, que incluem
decifrar códigos, encontrar sequências de botões escondidas pelo mundo e até utilizar um leitor
de QR Code para encontrar uma solução. O jogo ficou até mais conhecido por um quebra
cabeça final quase impossível de resolver (Kubba S. et al, 2012).
Jogos de ritmo ou música, onde o jogador precisa acertar notas musicais, apertar
botões conforme um certo ritmo, ou tocar uma música, como Guitar Hero (Harmonix), também
se encaixam no gênero puzzle, por possuírem quebra-cabeças gerados ritmicamente. Jogos de
ritmo também podem, no entanto, ser considerados jogos de ação por desafiarem a habilidade
do jogador de acompanhar o ritmo e de ter precisão.
Party
Jogos do gênero party ou festa, são jogos cujo principal objetivo é ser utilizado em
eventos sociais como forma de entretenimento para várias pessoas ao mesmo tempo. Jogos
de festa podem servir como atividades para quebrar o gelo, mas também podem ser o motivo
da festa. Para proporcionar o entretenimento de todos os participantes, esses jogos costumam
ter regras simples, para que jogadores possam aprender com facilidade, eles permitem que
pessoas com diferentes níveis de habilidade participem, e raramente eliminam jogadores.
Essas características se aplicam tanto para jogos tradicionais quanto para jogos eletrônicos.
Outras características importantes que podem ser observadas nesses jogos são: a capacidade
de acomodar um grande número de jogadores, em alguns casos, um número indefinido;
cooperação entre jogadores é encorajada; jogadores participam com frequência, ou seja, jogos
onde cada jogador possui um turno, que pode ser muito longo, não são considerados
adequados para uma festa e o jogo deve possuir algum valor para espectadores, como nem

25. /
todos vão poder participar ao mesmo tempo, é importante que quem está de fora do jogo possa
ficar entretido ao ver os outros jogando.
Jogos eletrônicos desse gênero procuram ter essas características aplicadas,
normalmente a minigames (pequenos jogos muito simples e fáceis, que podem ser jogados
várias vezes). Um dos jogos mais famoso nesse estilo é o Mario Party (Nintendo). O jogo
consiste em um tabuleiro com quatro personagens e um determinado número de turnos,
previamente escolhido por um jogador, que determinará quando o jogo vai durar. A cada turno,
todos os jogadores têm uma chance de rolar um dado e andar um determinado número de
casas. Durante sua vez, um jogador pode ganhar moedas, perdê-las, comprar itens, e realizar
diversas outras ações, incluindo prejudicar outro jogador. Ao final de cada turno, o jogo sorteia
um minigame para ser jogado, valendo moedas para o vencedor. Os minigames podem ser em
dupla, três contra um, ou cada um por si. Os minigames são rápidos, possuem regras muito
simples (normalmente são limitados a apertar apenas um botão) e caso um jogador perca, no
três contra um, por exemplo, ele não é eliminado. A única punição por perder é não ganhar
moedas, o que não é grave, considerando que ao final do próximo turno haverá outra chance.
Vale ressaltar que a rapidez dos minigames é essencial para que nenhum jogador fique de fora
por muito tempo. Nos casos free-for-all, ou seja, todos contra todos, o primeiro a perder, fica
um tempo sem jogar, mas como o tempo limite para esses jogos são segundos, ele pode
rapidamente voltar a jogar no começo do próximo turno. O objetivo do jogo é ver quem chega
ao final com mais estrelas, um item especial que pode ser adquirido por sorte, pode ser
encontrado no mapa, ou pode ser comprado por 50 moedas. Essa disputa incentiva
competitividade entre os jogadores, mas permite que todos aproveitem o jogo até o final.
Mesmo que um jogador não pegue nenhuma estrela, ele ainda vai poder participar de todos os
minigames até o último turno.
Role-playing
Jogos de RPG permitem que o jogador assuma o papel de um personagem,
controlando-o no mundo. Um dos principais elementos é o aprimoramento do personagem ao
longo do jogo. Geralmente o personagem possui habilidades, e ao ganhar experiência
conforme atividades forem concluídas, suas habilidades aumentam, tornando-o mais apto para
avançar a concluir atividades e missões com um nível de dificuldade maior. Os objetivos
mudam bastante de um jogo para outro, dependendo do mundo, história e personagem, mas
de forma geral, o jogador deve buscar progredir ao cumprir missões dadas conforme o enredo
se desenvolve. Uma série de RPG de bastante sucesso é o Final Fantasy (Square Enix).

26. /
Simulação
Jogos de simulação consistem essencialmente em controlar um personagem de forma
que ele tenha uma vida de sucesso dentro do seu mundo, onde o sucesso é definido pelo
próprio jogador. Simulações não possuem objetivos e permitem que o jogador faça o que
quiser, dentro do possível, com seu personagem e o mundo. Também não há o conceito de
final, ou seja, o jogo não acaba. O jogador pode criar um personagem, controlá-lo até o final de
sua vida, depois criar outro, e assim por diante. O jogo mais famoso dessa categoria é o The
Sims (EA), onde o jogador pode criar um personagem, interagir com NPCs, viver situações da
vida real como ter um emprego, relacionamento, entre outros, mas também proporciona várias
situações fictícias, o que dão ao jogo um tom mais cômico.

27. /
Tabela Para Classificação de Jogos
A tabela a seguir (Tabela 1) pode ser utilizada para classificar um jogo baseado nas
suas características principais. Vale ressaltar que atualmente, a maioria dos jogos se encaixa
em mais de um gênero, porém, todos costuma ter algumas características dominantes que
determinam sua classificação. O objetivo desta tabela é facilitar a identificação desse gênero
dominante nos jogos.
Gênero Características Principais Exemplos
Ação ● Ritmo rápido
● Decisões instantâneas
● Possui NPCs que podem facilitar ou
dificultar progresso
● Jogador deve cumprir tarefas ou missões
para avançar
● Falhar geralmente resulta em punição
Saints Row, Super Mario
World, Call Of Duty,
Grand Theft Auto,
Assassin’s Creed, Metal
Gear Solid, Resident Evil,
The Evil Within
Aventura ● Foco na história
● Não precisam de gráficos ou ação
elaborados
● Objetivo é descobrir a história
● Podem possuir puzzles a serem
resolvidos
● Podem possuir sistema de capítulos
● Decisões tomadas em um capítulo
afetam os capítulos seguintes
● Podem possuir diversos finais
Life Is Strange, Until
Dawn, Heavy Rain, The
Stanley Parable, Ace
Attorney
Corrida ● Controle de um veículo e não de um
personagem
● Abstrações da física do mundo real para
uma experiência realista
● Grande variedade de carros reais
● Normalmente permite customização e
alteração dos carros
Gran Turismo, Need For
Speed
Esporte ● Simulam prática de algum esporte real
● Normalmente possuem o objetivo de
vencer ou treinar
● Foco pode ser no gerenciamento de um
esporte, ou na prática em si
Out of the Park Baseball,
FIFA, Wii Fit

28. /
Estratégia ● Perspectiva alto nível
● Crição e/ou controle de personagens,
estruturas, recursos
● Objetivo de completar campanhas
● Jogador deve ter plano de ação de longo
prazo
● Observação do ambiente, detalhes que
podem se tornar vantagens
● Estratégia deve ser livre para jogador
elaborar
● 4X - atividades são explorar, extrair,
expandir e exterminar
● Objetivo pode ser conquistar uma área,
que pode ser até mesmo uma galáxia
Spore, Civilization, Total
War, Endless Space
Luta ● Controle de um personagem que entra
em combate com outro
● Lutas podem consistir de rounds
● Personagens podem possuir diferentes
habilidades
● Nenhum personagem deve possuir
vantagem grande demais sobre outro
● Jogador deve dominar técnicas como
atacar, bloquear, contra-atacar e combos
Mortal Kombat, Marvel
vs. Capcom, Street
Fighter, Injustice, Super
Smash Bros.
Management ● Perspectiva alto nível
● Gerenciamento de mundo e recursos
● Jogador pode alterar e melhorar o mundo
com base nos recursos
● Podem possuir um objetivo específico ou
não
SimCity, Tropico
Música ● Orientado a interação do usuário com
músicas, ritmo, partituras
● Podem em alguns casos serem
considerados puzzles por possuírem
quebra cabeças/desafios gerados
ritmicamente
● Podem testar a memória do jogador
● Podem testar a habilidade de realizar
certas ações de acordo com um ritmo
● Alguns permitem que jogador crie suas
músicas
Guitar Hero, Dance
Dance Revolution,
PaRappa the Rapper,
SimTunes, Rhythm
Heaven Fever, Rez
Puzzle ● Podem ou não possuir um personagem
jogável
● Utilização de lógica, reconhecimento de
Bejeweled, Fez, Tetris,
Portal, Minesweeper,
Limbo, Scribblenauts

29. /
padrões e dedução para atingir objetivos
● Podem incluir elementos de ação, como
pressão por tempo
Party ● Feitos para serem jogados por várias
pessoas ao mesmo tempo
● Regras simples e fáceis de entender
● Devem acomodar pessoas com
diferentes níveis de habilidades
● Raramente eliminam jogadores
● Podem possuir minigames
● Nenhum jogador deve ficar de fora por
muito tempo
● Desejável que possa ser aproveitado por
pessoas que estão de fora
Mario Party, Wii Party,
Pac-Man Party, Sonic
Shuffle
Role-playing ● Jogador assume papel de um
personagem no mundo
● Foco no aprimoramento do personagem
● Personagem possui habilidades que
podem ser melhoradas conforme ele
passa de nível
● Personagem ganha experiência ao
concluir objetivos, aumentando seu nível
● Conforme suas habilidades aumentam,
personagem se torna mais apto para
concluir atividades mais difíceis
● Podem haver objetivos secundários, que
não avançam na história mas dão
experiência e/ou itens para o
personagem
Final Fantasy, Terraria,
The Witcher, Dark Souls,
Diablo, Fallout
Simulação ● Jogador controla personagem de forma
que ele tenha sucesso dentro do seu
mundo
● Sucesso é definido pelo jogador
● Não possuem objetivos fixos
● Jogador é livre para fazer o que quiser,
dentro dos limites do jogo
● Não há final, pode ser jogado
indefinidamente
The Sims, Goat Simulator
Tabela 1. Proposta para classificação de gêneros de jogos

30. /
4.1.2 - Jogos de Plataforma
Após explorar diversos gêneros de jogos diferentes, é necessário entender as
características que definem o jogo a ser desenvolvido neste projeto. O proposto é um jogo de
plataforma 2D, e como foi visto, plataforma é um subgênero de jogos de ação. Agora é preciso
ver o que exatamente é um jogo de plataforma, para garantir que o jogo proposto se encaixe de
fato nesse gênero.
Até onde o autor explora, de acordo com o texto A Framework for Analysis of 2D
Platformer Levels (Smith G. et al, 2008), level design, ou design de nível é um conceito vital
para que um jogo tenha sucesso. Um nível é como um recipiente para o gameplay
(jogabilidade), ou seja, onde toda a interatividade com o ambiente acontece. Cada tipo de jogo
possui características diferentes, que devem ser refletidas nos níveis, o que torna a tarefa de
level design, bastante complexa. Por exemplo, um jogo de tiro e outro de corrida; ambos
possuem necessidades completamente diferentes. Em um jogo de tiro, o nível precisa estar
equipado com munição, itens para recuperar vida, lugares para se esconder, enquanto um jogo
de corrida não precisa de nada disso, mas conta com suas leis da física para criar desafios
para o jogador. Já o nível de um RPG, por exemplo, pode possuir similaridades com um nível
de jogo de tiro, como possuir itens coletáveis que recuperam vida. Para entender essas
diferenças com mais profundidade, é preciso entrar no conceito de level design para cada tipo
específico de jogo. Aqui será abordado esse princípio para jogos de plataforma 2D.
Para explorar níveis de um jogo 2D, será utilizado como base o artigo de Smith et al,
onde um niveis serão partidos em pedaços que serão analisados para vermos suas
semelhanças e como eles se encaixam. O modelo proposto separa o nível em duas partes:
componentes e uma representação estrutural de como esses componentes se encaixam.
Componentes são divididos em cinco categorias que representam seu propósito no
nível:
Plataformas - Objetos que o jogador utiliza para transportar seu personagem ao longo
do nível, como plataformas suspensas, superfícies, caixas e loops
Obstáculos - Objetos que causam dano no personagem, como inimigos e buracos no
chão, apesar de não serem considerados objetos
Facilitadores de movimento - Objetos que ajudam o personagem a chegar de um
lugar para outro, como cordas, escadas e molas

31. /
Itens coletáveis - Objetos que dão uma recompensa para o jogador, como moedas,
power-ups, ou seja, alguma coisa que dá vantagem ao personagem, como obter um poder, ou
ficar mais forte, e pontuação
Gatilhos - Objetos que causam alguma mudança no estado atual do nível, como um
botão que troca blocos por moedas, um botão que acione uma plataforma temporariamente, ou
até mesmo algo que mude o comportamento do personagem
Essa classificação de componentes é reforçada pelo artigo “An Analysis of Platform
Game Design” (Gustafsson A., 2014), onde o autor utiliza as mesmas definições utilizadas por
Smith et al, por se basear no mesmo artigo que está sendo utilizado. Até onde foi possível explorar,
não foi encontrado nenhum outro modelo proposto para classificar objetos que compõem os níveis
de um jogo de plataforma 2D.
Continuando a explorar a base dada por Smith et al, além dos objetos, temos uma árvore
que relaciona como os componentes compõem um nível, e como estes compõem o jogo como um
todo. Podemos ver este diagrama na Figura 4.
Figura 4. Modelo conceitual do framework de Smith et al
O modelo proposto tem como a mais alta subdivisão de um nível uma entidade
chamada célula. Uma célula é uma seção de gameplay linear, que se conecta com outras
através de portais. Enquanto portais servem apenas para fazer a transição entre uma célula e
outra, cada célula individual é composta por um ou mais rhythm groups (grupos de ritmo).

32. /
Grupos de ritmo são conjuntos compostos de componentes de nível, que não se sobrepõem.
Esses grupos são pequenos e englobam desafios específicos que ocorrem ao longo de um
nível. Entre um grupo e outro, normalmente há uma pausa, ou seja, um local seguro onde o
jogador possa descansar antes de enfrentar o próximo desafio. Isso é claramente refletido no
fluxo fractal, onde há uma quebra na dificuldade após cada desafio/série de desafios. Para
entendermos como os componentes se encaixa, em um nível, exploraremos mais detalhes
sobre cada um a seguir.
Avatar
Um elemento que todo jogo de plataforma deve ter, mas não é considerado um objeto é
o personagem jogável, ou avatar. O avatar é um personagem do jogo que o jogador controla, e
o utiliza para navegar pelos níveis e cumprir objetivos. Normalmente, o jogador só controla um
avatar por vez. Em alguns jogos, o jogador pode trocar de avatar em determinadas situações.
Algumas mudanças podem ser apenas cosméticas, enquanto outras podem trazer habilidades
diferentes ao personagem, e às vezes podem ser a chave para concluir uma missão. Cada jogo
pode introduzir características diferentes em seus personagens, porém, de uma forma geral,
todos os avatares de jogos de plataforma 2D possuem controle sobre movimento na horizontal
e na vertical: ir para a esquerda, direita e pular. Alguns controles avançados podem ser vistos
no Super Mario World, onde o avatar, Mario, é capaz de quebrar blocos embaixo dele, com um
comando diferente do de pulo, e atacar inimigos caso ele esteja equipado com o powerup de
fogo.
Plataformas
O elemento mais básico de um jogo de plataforma, a plataforma em si. Uma plataforma
é definida como qualquer objeto que o avatar possa utilizar para andar ou correr por cima com
segurança, como o chão do nível, blocos ou planos suspensos. Plataformas possuem fricção,
inclinação e tamanho, onde fricção e inclinação podem afetar o movimento do personagem. Por
exemplo, uma plataforma com gelo, em Super Mario World, faz o avatar escorregar, e torna
mais difícil o controle sobre o movimento. Além disso, plataformas podem ser estáticas e
constantes, ou seja, não mudam de tamanho nem de posição, ou podem estar em constante
movimento, formando trajetos projetados pelo designer do nível, e podem ainda mudar de
tamanho e orientação. Plataformas também podem ser temporárias, permitindo que o avatar
ande sobre ela apenas um determinado número de vezes, ou apenas por um tempo
determinado, e podem ser invisíveis.

33. /
Obstáculos
Obstáculos são a principal fonte de desafio em um nível de um jogo de plataforma.
Qualquer objeto que tem a capacidade de prejudicar o avatar é considerado um obstáculo.
Obstáculos podem ser inimigos, ou seja, personagens com movimentos pré-programados que
podem causar dando ao personagem se colidirem com ele, ou objetos estáticos, como
espinhos no chão. Obstáculos não estáticos precisam ter seus padrões de movimento
pré-determinados, é necessário decidir se eles aparecerão uma única vez, várias vezes, ou
infinitamente, e se podem ser destruídos pelo avatar. Quando inimigos podem ser mortos, é
comum que eles deem ao jogador algum tipo de recompensa, às vezes ligado à dificuldade de
matá-lo.
Facilitadores de movimento
Facilitadores de movimento, ou movement aids são objetos que ajudam o avatar a
avançar pelo nível de formas diferentes dos movimentos tradicionais, como andar e pular.
Objetos como cordas, escadas, balanços, trampolins e molas são todos considerados
facilitadores de movimento. Estes objetos podem ser estáticos, ou seja, o avatar tem que
utilizá-lo no local onde ele está, ou podem ser móveis. Nesse segundo caso, parte do desafio é
descobrir onde deve-se colocar o facilitador de forma que seja possível progredir. Trampolins e
molas normalmente são móveis, enquanto cordas e escadas não são, mas isso pode variar de
um jogo para outro. Facilitadores de movimento requerem uma equação na sua programação
que determina como eles vão se comportar, mas em alguns casos, permitem que o jogador
modifique essa equação temporariamente quando necessário. Por exemplo, pode-se pular
diversas vezes em uma mola para fazer o avatar ir cada vez mais alto, até um certo limite. É
importante lembrar que isso só vale enquanto o avatar está interagindo com o objeto. Quando
ele para, o objeto volta a se comportar como deveria originalmente.
Itens colecionáveis
Jogos de plataforma sempre possuem algum tipo de sistema de recompensa. Essas
recompensas normalmente são na forma de itens colecionáveis. Itens colecionáveis são
qualquer objeto que dê uma recompensa ao jogador uma vez que são coletados pelo mesmo.
Ser coletado implica que o item, depois da interação com o usuário, desaparece, para que ele
só possa ser pego uma vez, a cada vez que o nível é jogado. Um nível pode ter diversos itens
colecionáveis, e eles podem ser de vários tipos: moedas, anéis, power-ups, pontos ou armas.
Personagens não jogáveis (NPCs) que ajudam o avatar ao longo da fase também podem ser
considerados itens colecionáveis, como o Yoshi, em Super Mario World. Ele modifica o

34. /
comportamento do avatar da mesma forma que um power-up como a flor de fogo modifica.
Ambos não são vitais para concluir um nível, mas se forem pegos, podem facilitar.
Itens colecionáveis, além de proporcionar alguma vantagem para o avatar durante o
jogo, normalmente também possuem um valor de recompensa associado, que é refletido como
pontos, um valor numérico, para o jogador. Pontos podem ser obtidos de diversas formas,
como: matar inimigos, pegar itens, terminar a fase ou até mesmo terminar com uma
determinada quantidade de tempo sobrando. Pontos nem sempre adicionam nada ao jogo, mas
podem ser satisfatórios para o jogador. De forma geral, como proposto por Desurvire et al, a
existência de itens colecionáveis em um jogo pode ser utilizados para avaliar sua jogabilidade,
ou seja, o quanto as pessoas gostam de jogá-lo. Em Super Mario World, por exemplo, a
principal forma de obter pontos é coletando moedas, porém, a principal recompensa está em
ganhar uma vida extra, a cada cem moedas coletadas.
Itens colecionáveis podem ser úteis também como apoio durante o nível, como guias.
Por exemplo, uma seta feita de moedas pode indicar para o jogador que ao seguir na direção
indicada, ele encontrará algo, além de obviamente ganhar pontos por pegar as moedas. Itens
colecionáveis também podem servir para mostrar a ideia de incentivo de risco (Bleszinski,
2000). Incentivo de risco é um modo de dar ao jogador uma chance de tomar uma decisão
baseada no quanto vale a pena a recompensa considerando o risco existente. Normalmente
isso é visto em situações em que fazer certa ação não é obrigatória, mas se for executada com
sucesso, oferece uma recompensa valiosa. Em Super Mario World, isso pode ser visto
claramente quando a recompensa em questão é uma vida extra. Esse é um item colecionável
raro, e pegá-lo normalmente não é fácil. É bastante comum ele estar em um lugar perigoso,
então, o jogador tem que avaliar se vale a pena tentar pegar uma vida extra, considerando que
ele pode possivelmente perder uma na tentativa, e ainda não ganhar nada. É comum que a
dificuldade de pegar um item esteja relacionada com seu valor; quanto maior a recompensa,
maior o risco para pegá-la.
Gatilhos
Gatilhos são objetos com os quais o avatar pode interagir que mudam o estado do nível
ou regras de jogo, como a física. Em Super Mario World, por exemplo, existe um objeto que é
um botão com a letra “P”, que ao ser utilizado pelo avatar, transforma todos os blocos em
moedas. O efeito de um gatilho pode ser temporário ou permanente, e introduz um elemento de
puzzle ou jogo, pois requer que o jogador saiba quando deve utilizar um gatilho para poder
progredir.

35. /
Grupos de ritmo
Tendo em vista todos os elementos que estão presentes em um nível de um jogo de
plataforma 2D, podemos agora analisar a estrutura definida por Smith et al. Todos os
elementos ficam em uma hierarquia que compõe o nível. Acima dos objetos, temos os grupos
de rítmo. A ideia de relacionar composição musical com o level design de um jogo de
plataforma é proposta por Compton e Mateas (2006), e sugere que o level design depende
fortemente de rítmo. Ações rítmicas executadas pelo jogador, em resposta ao ritmo do jogo
ajudam o jogador a chegar no estado de Flow (Csikszentmihalyi, 1990), que como foi visto
anteriormente, é um estado de alta concentração. Compton e Mateas sugerem que quando o
jogador está em fluxo, ou no rítmo do jogo, pular por plataformas não requer, além de cálculos
de distância, tempo, ou cronometragem. Ou seja, além de saber o quão longe se pode ir,
deve-se saber o tempo certo para tomar uma ação, como dar o input para o avatar pular. A
colocação de obstáculos em um nível de uma forma rítmica cria uma sequência de movimentos
que seguem um ritmo, tornando por consequência, cada pulo individual mais fácil, por conhecer
o momento (tempo) necessário no qual se deve agir.
Entendendo agora a importância de rítmo, veremos o que de fato é um grupo de rítmo.
Um grupo de ritmo, como definido por Smith et al é um pequeno grupo de objetos, não
sobrepostos, que encapsulam um desafio. Grupos de ritmo permitem a fácil identificação das
áreas de um nível que são desafiadoras, além de permitir a reutilização das mesmas. O mesmo
grupo de ritmo pode ser usado várias vezes ao longo de um mesmo nível, mas pode não
parecer o mesmo, graças a mudanças da sua representação gráfica ou visual.
Os grupos de ritmos propostos possuem começo, meio e fim, e culminam em uma
cadência. Neste contexto, a cadência é um local onde o ritmo do movimento do jogador muda
de forma significante, como por exemplo, um local seguro, sem desafios, onde o jogador pode
relaxar antes de continuar. Esses locais são especialmente importantes em níveis grandes e
difíceis, pois longos períodos de ação e desafio sem descanso tem maior chance em resultar
em erro do jogador. A necessidade do espaço entre um grupo de ritmo e outro onde o jogador
pode descansar é reforçada pelo fluxo fractal (Sala, 2011), onde percebe-se uma quebra na
dificuldade a cada vez que um mundo é completado. Aqui, temos que cada grupo de ritmo é
um mundo, e é essencial que a cada um haja uma pausa, antes de seguir para o próximo,
possivelmente mais difícil que o anterior. Esse ponto seguro também pode ser usado para
permitir que o jogador salve seu progresso ou ganhe alguma recompensa por ter completado
uma parte difícil do nível.

36. /
O ritmo em si pode ser encontrado nas plataformas quando o jogador executa alguma
ação, como pular. As ações são mapeadas diretamente para o controle, e o ritmo com o qual o
jogador deve apertar os botões é o ritmo que vai ser definido, conforme Smith et al. Um grupo
de ritmo pode ser, por exemplo, uma sequência de pulos curtos ou pulos alternados para frente
e para trás. Um dos exemplos escolhidos por Smith et al que mostra um grupo de ritmo com
bastante clareza, é a seguinte parte de um nível de Super Mario World, como visto na Figura 5.
Figura 5. Dois grupos de ritmo em Super Mario World (Smith et al, 2008)
Nesta figura, podemos ver com clareza o que Smith et al entendem como um grupo de
ritmo. Nesse trecho do nível, existem dois grupos de ritmo distintos, com começo, meio e fim. O
começo e o final de cada grupo é facilmente identificado por uma pausa no ritmo. Na figura,
vemos duas plataformas mais altas, sem moedas e inimigos: a primeira, é o começo do
primeiro grupo, e a segunda, e o final do primeiro, e o começo do segundo grupo. Essa pausa
da uma chance ao jogador relaxar antes de enfrentar outro desafio. Apesar dos dois grupos
serem similares, e parecerem um único grupo, eles são considerados distintos pela diferença
na colocação das moedas e inimigos, que afeta o ritmo que o jogador precisará ter para passar.
Nesse caso em particular, o segredo para completar o primeiro grupo sem pausa é:
pular no primeiro inimigo, pegar as moedas, com o momento do primeiro pulo, cair na
plataforma do meio, pegar as moedas, e ao fazer o próximo pulo, pular no segundo inimigo,
pegar as moedas, e aterrissar na plataforma que marca o final do grupo. Nessa plataforma de
pausa, o jogador tem a chance de planejar o próximo pulo, para pegar a moeda, eliminar o
inimigo embaixo, e na mesma sequência, eliminar o último. Sem essa pausa, o jogador teria
maior chance de errar a segunda parte, por causa da mudança de ritmo, e do tamanho do

37. /
desafio. É importante que sempre haja a preocupação de equilibrar o desafio com pausas, para
não frustrar o jogador.
Células e portais
Os últimos elementos que formam um jogo de plataforma são células e portais. Células
são regiões, não sobrepostas, de gameplay linear, que são conectadas por portais. Portais são
responsáveis por conectar células, por exemplo: em um nível com diversos caminhos possíveis
para chegar no objetivo final, temos que cada caminho é uma célula, e o ponto onde um
caminho encontra outro, e o jogador pode trocar de caminho, é um portal. Os limites de uma
célula são definidos por transições que entram e saem da região, como a entrada para outro
nível ou uma passagem secreta. Em Super Mario World, por exemplo, os canos, que levam
para outra parte do nível, são portais, e a região que existe fora do cano, é uma célula.
Agora que definimos todos os elementos presentes nos níveis de um jogo de
plataforma, podemos utilizar este modelo, proposto por Smith et al, junto com as noções
básicas sobre jogos de ação, como visto na taxonomia, como base para fazer o level design
para o jogo que será implementado em cima da plataforma criada neste projeto.

38. /
4.1.3 - Unity
Para desenvolver a plataforma e o jogo proposto, um platformer 2D, será utilizada a
engine Unity. O Unity é uma engine e um IDE , utilizado para criar mídia interativa,2
principalmente jogos eletrônicos (Haas, 2014). Em essência, ele é um conjunto de ferramentas
que executa gráficos, áudio, física e interações, além das ligações entre estes elementos. Ele
dá suporte a jogos 2D e 3D e permite a exportação multiplataforma, incluindo iOS e Android, as
duas plataformas alvo para o jogo a ser desenvolvido.
O Unity foi desenvolvido inicialmente por três colegas, David Helgason, Joachim Ante e
Nicholas Francis na Dinamarca, e teve sua primeira versão disponibilizada em 2005. O objetivo
dos três era criar um produto com funcionalidades profissionais que pudesse ser usado por
desenvolvedores amadores. Eles se inspiraram no fluxo simples e na interface de
drag-and-drop (arrastar e largar), do produto de edição de vídeo Apple’s Final Cut Pro. No
momento em que foi lançado, a engine era compatível apenas com o sistema operacional OS
X, da Apple e permitia exportação para uma variedade pequena de plataformas. Hoje, o Unity
pode ser utilizado também em Windows, e oferece suporte de exportação para diversas
plataformas, incluindo dispositivos móveis e consoles, como PlayStation e Xbox.
Desde sua primeira versão, o Unity já possuía uma interface simples com uma aba para
a cena (Scene View), ou seja, onde se constrói o jogo com objetos, personagens, entre outros,
uma para os elementos do jogo (Project Browser), uma para propriedades avançadas de cada
elemento (Inspector), uma para ver a hierarquia dos elementos do jogo (Hierarchy) e uma que
mostra como as coisas vão aparecer no jogo de fato (Game View). Hoje, estas janelas ainda
são as mais utilizadas. Cada componente já foi estudado previamente, mas estes resumos se
baseiam no trabalho de Haas.
Project Browser - Possui todos os ativos (assets) que foram importados para o Unity
que podem ser usados, como modelos 3D de objetos, sprites 2D, sons, animações e scripts. O
layout é similar ao do Explorer no Windows, e Finder no Mac, para que desenvolvedores
tenham facilidade em utilizá-lo, por ser parecido com algo usado diariamente.
Scene View - Este é o local onde o jogo é construído. O desenvolvedor pode arrastar
objetos que se encontram no Project Browser, ou objetos primitivos do Unity, como, por
exemplo, cubos, e colocá-los na cena. Os controles disponíveis permitem que se coloque cada
2
IDE - integrated development environment (ambiente de desenvolvimento)

39. /
objeto na posição desejada, seja arrastando-o, ou modificando suas coordenadas através do
Inspector. Nessa janela também pode-se atribuir texturas a objetos e visualizar como elas
ficarão, pode-se modificar o terreno e adicionar sistemas de partículas, para criar efeitos como
fogo.
Inspector - Exibe detalhes sobre cada objeto e permite que modificações sejam feitas.
Em caso de um objeto como um cubo, por exemplo, pode-se alterar textura, tamanho, rotação,
entre outros. Pode-se também ver os componentes associados a cada objeto, como scripts,
física, colliders, som e animação. Variáveis declaradas em scripts podem ser preenchidas aqui.
Game View - Permite que o usuário veja como o jogo vai ficar sem a necessidade de
compilar o projeto para uma plataforma específica. Ele permite input, executa scripts, sons e
animações e permite a fácil modificação de qualquer elemento. A qualquer momento, o usuário
pode pausar o jogo, voltar para a cena, mudar algo, e retornar para o jogo, para ver sua
modificação.
Hierarchy - A hierarquia é utilizada para exibir uma lista de todos os objetos presentes
na cena atual. Sempre que um novo objeto é adicionado, ela é atualizada. O desenvolvedor
pode facilmente gerenciar pais e filhos ao arrastar um objeto para dentro de outro. Um objeto
pode ter vários filhos, e pode-se também criar um objeto vazio (Empty Game Object)
simplesmente para agrupar outros, por exemplo: se há um certo número de árvores em uma
cena, pode-se criar um objeto vazio, e colocar todas as árvores como seus filhos. Hierarquia é
essencial para manter a organização da cena.
Outra característica do Unity que o torna bastante popular para desenvolvedores, além
de sua interface simples, é a facilidade para importar assets de terceiros para dentro do projeto.
Para criar um jogo, o desenvolvedor não precisa saber nada de modelagem 3D, por exemplo,
pois ele pode importar modelos criados por outras pessoas, já com direito a texturas e
animações. Pode-se importar também scripts para controlar o comportamento de objetos do
jogo, sons e efeitos visuais. O próprio Unity disponibiliza alguns objetos e scripts para o
desenvolvedor utilizar gratuitamente. Um exemplo bastante utilizado é o script Bloom (Unity,
2017), usado para dar uma aparência mais realista à fontes de luz, fazendo com que ela
pareça vazar e se espalhar em objetos ao redor. Um desenvolvedor pode adicionar esse efeito
ao seu jogo sem programar nada, apenas utilizado o script já pronto. Assets podem ser
gratuitos ou pagos, e podem ser visualizados e baixados dentro do próprio Unity, através da
loja, ou podem ser colocados dentro do projeto caso o arquivo tenha sido baixado de outro
lugar, pois o Unity oferece suporte para vários tipos de arquivos.

40. /
O Unity também é muito usado por possuir vários comportamentos já prontos,
especialmente física. O desenvolvedor pode modificar cada característica de acordo com sua
preferência, mas com os básicos oferecidos, ele já pode ter um sistema de colisões que
impede que um objeto atravesse outro. Com o uso de colliders, ou seja, recipientes capazes de
detectar colisão, pode-se, com facilidade, fazer com que objetos colocados na cena se
comportem como na vida real. Um collider é um recipiente que pode possuir várias formas,
como cubo, esfera ou malha, que é colocado em volta de um objeto, podendo ter seu tamanho
e posição ajustados, que detecta quando outro collider interage com ele. Pode-se utilizar isso
para impedir que dois objetos se sobreponham, ou como um gatilho, para detectar quando um
objeto cruzou com outro.
Por fim, o desenvolvimento pode ser feito em C#, Javascript e Boo, apesar deste não
ser muito utilizado, há uma abundância de tutoriais, oferecidos pelo próprio Unity e há também
uma grande comunidade de usuários assíduos que criam conteúdo, oferecem tutoriais, aulas, e
mais, fazendo com que ele seja uma boa escolha tanto para novatos quanto para profissionais,
e possui tanto uma versão gratuita, bastante completa, quanto uma paga. Vários jogos
populares hoje, para as mais diversas plataformas foram feitos com o Unity. Entre eles, alguns
notáveis, de diferentes portes e para diferentes plataformas, são: Pokémon GO (Niantic),
Hearthstone (Blizzard Entertainment), Digimon World: Next Order (B.B. Studio) e Layers of Fear
(Bloober Team).

41. /
4.1.4 - Game Analytics
Game Analytics é uma ferramenta que proporciona análise de vários aspectos de um
jogo ao ser integrada no sistema. Algumas de suas funcionalidades incluem: observar o
progresso dos usuários, descobrir em quais níveis eles ficam presos, ou seja, não conseguem
avançar, em que itens eles mais gastam as moedas do jogo, em que itens eles mais gastam
dinheiro real, entre outras. Essas informações são bastante importantes para sempre melhorar
a experiência do usuário. Pode-se facilitar níveis em que pessoas têm muita dificuldade,
adicionar uma variedade maior de itens populares, mudar preços, de forma a reter usuários
mais antigos, dando à eles sempre a melhor experiência possível.
A ferramenta, em essência, apenas monitora e produz dados de todos os tipos sobre o
jogo ao longo do tempo. Há quatro tipos principais de métricas: consumidores, comunidade,
performance, e gameplay. Como não é possível medir absolutamente tudo, vale ressaltar de
deve-se focar nas métricas importantes para cada tipo de jogo. Um jogo como o deste projeto,
um jogo de plataforma single player não precisa, por exemplo, de medir informações sobre
comunidade, já que não haverá interação nenhuma entre um jogador e outro. Os dados mais
importantes a serem medidos são: quando os usuários fecham ou desistem do jogo, média de
quanto tempo eles o jogam, o quanto eles progridem no jogo e quantos moedas coletam. Em
uma versão futura, outras métricas devem ser analisadas, como, por exemplo, em que os
usuários estão gastando as moedas coletadas.
Para monitorar algo que ocorre no jogo, é preciso possuir as funcionalidades do Game
Analytics dentro do projeto. Dentro do Unity, pode-se obter as funcionalidades do Game
Analytics ao importar uma biblioteca gratuita, disponível na loja de assets do Unity. Após
instalá-la, pode-se começar a usar o que ela disponibiliza. Para monitorar ou controlar algo, é
preciso primeiro decidir o que pode e deve ser medido. Um dado que pode ser interessante,
por exemplo, pode ser o número de inimigos que um jogador eliminou durante o jogo. Como
proposto pelo próprio Game Analytics, um jeito de fazer isso seria separando as realizações
que um jogador pode fazer em grupos diferentes como eliminação e exploração, por exemplo.
Dentro do grupo de eliminação, temos inimigos e neutros, e dentro de cada, podemos ter
marcos como dez mortos, cinquenta mortos, e assim por diante. Dessa forma, a cada vez que
um marco específico é concluído, podemos acionar o Game Analytics para armazenar esta

42. /
informação sobre nosso jogador, para ver, por exemplo, quanto tempo ele levou para concluir
um marco.
Eventos enviados podem ser vistos na seção Explore do Game Analytics. Nela, pode-se
visualizar gráficos e detalhes sobre o que foi medido no jogo. Outro tipo de informação que
pode ser medido é o progresso do jogador, ou seja, o quão longe ele já chegou, quantos níveis
ele percorreu, quantas missões ele já fez, entre outros dados. Pode-se analisar também, por
exemplo, quais recursos, como moedas e outros itens colecionáveis já foram pegos. É possível
também monitorar dados referentes à transações feitas, como a compra de um item, com
dinheiro real, em um jogo. Erros também podem ser monitorados, e são enviados para o painel
de visualização das métricas em tempo real.
Apesar do Game Analytics ser o escolhido para este projeto, existem outras soluções
de analytics para jogos. Jogos de grandes empresas normalmente possuem suas próprias
ferramentas de analytics, específicas para seu conteúdo, que não estão disponíveis para uso
de terceiros. Empresas menores ou desenvolvedores independentes podem contar com
algumas soluções disponíveis no mercado para atingir os mesmos fins, porém de forma mais
limitada.
Um dos serviços disponíveis é provido pela empresa DeltaDNA , que oferece coleta de3
dados para análise e consultoria. A análise de dados é similar ao Game Analytics,
disponibilizando dashboards e funis, mas também oferece benchmarking, mineração de dados
e um otimizador de aquisição, para gerar previsões que ajudem o desenvolvedor a melhorar o
jogo para reter os usuários. O serviço de consultoria utiliza todos os dados coletados para dar
ao criador do jogo ainda mais insights sobre como melhorar, incluindo informações sobre
monetização, como otimizar anúncios, prevenção de abandono, segmentação de jogadores
entre outros. Os serviços oferecidos pela DeltaDNA são bem completos e mais elaborados do
que os do Game Analytics, porém, são pagos. Outro serviço similar é oferecido pela empresa
Keen IO . A empresa oferece contratação de desenvolvedores, suporte, treinamento e4
consultoria. O serviço de consultoria inclui analytics para gerar previsões, ciência de dados,
pipeline, entre outros. Esta solução não é voltada para jogos, e também é paga. Por fim, há a
ferramenta Xsolla que, como o Game Analytics, basicamente oferece dashboards com os5
dados coletados.
3
https://deltadna.com/
4
https://keen.io/
5
https://www.xsolla.com/en/

43. /
4.2 - Método e Testes
Após escolher e estudar a ferramenta a ser utilizada para o desenvolvimento, o próximo
passo era decidir o método de implementação. Por não possuir conhecimento prévio sobre
como estruturar um jogo, especialmente em uma ferramenta complexa como o Unity, foi
preciso realizar algumas pesquisas sobre como criar um jogo de maneira geral. O que a engine
tem a oferecer, o que deve ser programado, o que pode ser feito via a interface, e muitas outras
perguntas, deveriam ser respondidas antes de começar. Um tempo antes de começar a
implementação deste projeto, várias dessas dúvidas foram resolvidas utilizando tutoriais em
vídeo, disponíveis no YouTube. O que foi de maior ajuda, foi a série “Unity Tutorial For
Beginners How To Make A Game” (Vegas, J.), que apesar de focar em um jogo 3D e ser em
JavaScript, serviu seu principal propósito, que era ajudar a entender o funcionamento geral do
Unity.
O tutorial serviu como base para estruturar o projeto. A lógica do jogo é dada pelos
scripts, que são atribuídos a um ou mais game objects (o objeto mais primitivo que engloba
todos os elementos do jogo, como personagens, objetos de cenário, câmera, etc.), e são
executados quando a cena onde estão é carregada. No caso de C#, todos os scripts de
herdam da classe MonoBehaviour, que dá a eles os dois principais métodos necessários para
determinar o comportamento de um jogo: start() e update(). O start() é chamado uma vez,
quando o script é carregado e é utilizado para inicialização quando necessário. O update() é
chamado uma vez por frame e é utilizado para atualizar tudo que ocorre no jogo, como por
exemplo, a posição de um personagem. Para manter o jogo organizado, é importante limitar o
que é colocado em cada script. Como visto no tutorial mencionado, o ideal é possuir scripts
pequenos que determinem um comportamento específico. Esse aprendizado foi incorporado ao
jogo, e gerou resultados como: um script que controla o movimento do personagem, outro para
o movimento dos inimigos, outro para coletar moedas, entre outros. Dessa forma, é fácil
modificar detalhes de comportamentos específicos e identificar problemas.
Estes conhecimentos já haviam sido colocados em prática, antes de começar a
implementação deste projeto, durante a criação de outro jogo simples 2D. Após esse jogo estar
completo, um protótipo para este projeto foi implementado. O protótipo serviu para aprender e
testar as funcionalidades básicas de um jogo de plataforma: movimentação e colisão. O

44. /
protótipo foi testado manualmente apenas para verificar que os movimentos ocorriam como
desejado.
A seguir, foi criado um modelo para testar o Game Analytics. A integração com o Unity
foi simples, pois bastava instalar um pacote disponível na asset store, dentro da própria engine.
Paralelamente, foi necessário criar uma conta no Game Analytics e criar um jogo. Na interface
do Game Analytics, o jogo não passa de um projeto vazio, com um nome, dado pelo usuário, e
um par de códigos gerados automaticamentes. Dentro do Unity, após a instalação do pacote, é
preciso criar uma conexão com o jogo criado no site do Game Analytics. Feito isso, uma vez
que o jogo começa a enviar dados, depois de alguns dias, eles começam a aparecer dentro da
parte de métricas do jogo criado no site. Para testar se toda a integração funcionou
corretamente, foi criado um script com apenas uma funcionalidade: ao ser iniciado, mandar um
evento para o Game Analytics informando o início de um nível. Isso foi testado diversas vezes
manualmente, e uma vez que foi comprovado que funcionava de fato, o protótipo foi concluído,
dando início à implementação do projeto em si.
O projeto foi implementado seguindo o mesmo método utilizado no protótipo: scripts
pequenos e modulares que controlam comportamentos específicos. As atividades
desenvolvidas foram: controlar o movimento do personagem, criar inimigos que se
movimentam sozinhos e que ao colidirem com o jogador, o matam, criar plataformas que se
movimentam, criar moedas que podem ser coletadas e dar ao personagem a habilidade de
pular em inimigos para eliminá-los. A parte de interface e navegação também foi baseada no
que foi visto no tutorial de Vegas. Telas de menu, seleção de fase, pausa, reiniciar nível e ir
para o próximo nível foram todas criadas durante a implementação do jogo. Por fim, a parte de
analytics foi implementada seguindo o design pattern chamado Singleton, que permite que os
métodos contidos nela estejam acessíveis em qualquer ponto do código, e que só haja uma
instância dessa classe.
Paralelamente, o outro projeto se encarregou de acrescentar a parte de banco de
dados, utilizado a ferramenta Firebase, do Google e implementar o modo endless. O projeto
era mantido sempre atualizado utilizando a ferramenta BitBucket para versionamento Git,
permitindo que ambos os projetos possuíssem os dois modos, Game Analytics e banco.

45. /
4.2.1 - Cronograma
A implementação do projeto ocorreu de forma bem diferente de como havia sido
planejada originalmente. Apesar de quase tudo que foi planejado ter sido implementado de
fato, a ordem de prioridades foi bastante diferente, e para isso, o cronograma de planejamento
do Projeto I (Tabela 3) deve ser comparado com o cronograma realmente executado neste
projeto (Tabela 2).
Atividade Data
Projeto Final II
● Começo de implementação de protótipo. Testes com
movimentação de personagem e animações utilizando imagens
gratuitas obtidas no site Open Game Art.
● Expansão da taxonomia.
● Pesquisa sobre métodos de implementação de jogos no Unity.
Julho
● Incorporação do Game Analytics no protótipo. Expansão do
protótipo, mais testes.
● Início de testes com Firebase no protótipo.
Agosto
● Testes com versão compilada do protótipo para enviar dados para
Game Analytics.
● Início da implementação do projeto que será o produto final.
Incorporação de tudo testado no protótipo. Game Analytics e
movimentos básicos já funcionais.
● Implementação dos modos endless e plataforma.
Setembro
● Implementação de elementos de interface, criação de telas e
navegação.
● Criação de componente gráficos (cenário, personagem e botões)
e utilização de imagens gratuitas para inimigos e objetos de
cenário para o design dos níveis no modo plataforma e o modo
endless.
● Mecânicas avançadas implementadas: eliminar inimigos, coletar
moedas, plataformas com movimento, obstáculos.
● Finalização do nível 1 para modo plataforma.
● Finalização do modo endless com 3 tipos de obstáculos.
● Criação de controles para dispositivos móveis.
● Conexão com Firebase.
● Criação métodos para medir uso para enviar ao Game Analytics.
● Adição de música de fundo.
Outubro
● Finalização da adaptação de controles para dispositivos móveis.
● Finalização do nível 2 para modo plataforma.
● Mudança de componentes gráficos. Cenário e objetos obtidos do
site Open Game Art para garantir a consistência dos gráficos,
sendo todos da mesma fonte.
Novembro

46. /
● Criação de mais cenários para modo endless.
● Finalização da navegação entre telas e níveis.
● Criação de usuário no Firebase, com identificador e
armazenamento de sua pontuação.
● Documentação do que foi feito.
● Disponibilização de verão final da plataforma e jogo com os dois
modos no sistema iOS.
Dezembro
● Redação final. Dezembro
Tabela 2. Cronograma do Projeto Final II
Atividade Data
Projeto Final I
● Definição das funcionalidades básicas do framework
● Pesquisa sobre as tecnologias a serem utilizadas: Engine, Banco
de dados, Analytics.
Abril
● Definição das tecnologias a serem usadas
● Pesquisa sobre teorias: Taxonomia, jogos de plataforma, Unity,
bancos NoSQL.
Maio
● Redação sobre as pesquisas.
● Modelagem, casos de uso e levantamento de requisitos.
Junho
● Redação final. 26/06/2017
Projeto Final II
● Início do planejamento dos sprints e das tarefas.
● Começo da criação da parte visual do jogo, como sprites e
animações.
Julho
● Implementar plataforma, conectar com banco de dados. Agosto
● Incorporar game analytics, começar jogo base. Setembro
● Implementar mecânicas do jogo. Outubro
● Criar cenários e seus componentes (plataformas, coletáveis),
inimigos e obstáculos, customização.
● Implementar esses elementos no jogo.
Novembro
● Implementar autenticação.
● Adicionar in-app-purchases.
Dezembro
● Redação final. Dezembro
Tabela 3. Cronograma do Projeto Final I

47. /
Como pode ser visto, comparando o cronograma do Projeto I com o deste projeto,
muitas coisas mudaram. A maioria das coisas que haviam sido planejadas foram
implementadas, com exceção da autenticação e in-app-purchases. Graças a implementação do
protótipo, o desenvolvimento de vários aspectos do jogo foi mais simples do que originalmente
planejado. A incorporação do Game Analytics também foi mais fácil do que planejado, portanto,
apesar de algumas dificuldades iniciais, não custou tanto tempo.
A implementação do jogo também ocorreu antes do planejado. Por conta da
oportunidade de ir para a feira Brasil Game Show e demonstrar o jogo, foi preciso focar em
deixar os dois modos de jogo jogáveis e minimamente funcionais, para que pudesse ser
testados por usuários reais. Como está parte foi bem adiantada, o jogo estava quase todo
completo até outubro. Após a feira, ajustes foram feitos para acrescentar mais funcionalidades
do Game Analytics, e para melhorar os controles e gráficos. Apesar do desenvolvimento ter
sido mais rápido do que esperado, para que o jogo pudesse ter uma boa qualidade, foi
necessário descartar funcionalidades não essenciais, como in-app-purchases, para focar em
aspectos que fossem mais importantes para a satisfação do cliente, considerando o que foi
estudado na feira: controles fáceis e gráficos melhores.

48. /
5 - Projeto e especificação do sistema
O sistema foi desenvolvido em partes, dado que foi feito em colaboração com outro
aluno. O sistema como um todo, é composto de um jogo com dois modos, plataforma e
endless, e um framework com suporte para persistência de dados e analytics. O foco neste
projeto foi implementar o modo plataforma e a integração com o Game Analytics. Como o jogo
possui coisas em comum, um repositório Git foi criado para organizar o código e gerenciar o
versionamento.
Neste projeto, primeiramente, foram implementadas as funcionalidades já testadas do
protótipo. Foram utilizados recursos gráficos gratuitos para alguns elementos visuais como
inimigos, plataformas e objetos de cenário. O personagem principal e o plano de fundo, foram
feitos durante o processo de implementação. Por ambos os modos de jogo possuírem o
mesmo tema, diversos sprites e imagens eram compartilhados. Para manter organização, para
cada recurso, como imagens e scripts, foram criadas três pastas, para separar o que era do
modo plataforma, endless ou compartilhado. Toda a parte de interface como menus, botões e
transições entre as telas também foi feita neste projeto.
Este projeto também contou com o desenvolvimento de mais funcionalidades de um
jogo de plataforma, incluindo: plataformas móveis, coleta de moedas e inimigos. Cada
funcionalidade está associada à um script. A transição de controle por teclas, no protótipo, para
controle por toque, também foi implementada.
O diferencial deste projeto está no uso conjunto de Game Analytics com persistência de
dados para criar com mais facilidade jogos para dispositivos móveis. Nesta parte do projeto,
apenas as funcionalidades do Game Analytics foram implementadas. Apesar das limitações do
sistema, como visto anteriormente, por não haver tantas outras soluções no mercado, o Game
Analytics é um bom ponto de partida para pequenos desenvolvedores como forma de analisar
o comportamento dos usuários de um jogo.
A contribuição deste projeto é fornecer uma maneira mais eficiente de desenvolver
jogos multiplataforma. A parte de desenvolvimento multiplataforma já é bem comum no
mercado. A engine Unity é apenas uma de muitas outras que fornecem essa mesma
funcionalidade. Além disso, estas ferramentas normalmente também disponibilizam diversos
adicionais para ajudar o desenvolvedor. Por exemplo, no caso do Unity, o desenvolvedor pode
baixar vários componentes de terceiros ou do próprio Unity através da asset store para

49. /
incrementar seu jogo, como fontes, gráficos, scripts, e mais. No entanto, não há nada que
forneça uma solução completa de analytics. Há o pacote do Game Analytics, que foi utilizado
neste projeto, mas ele sozinho não é o suficiente. Por isso, nesta plataforma, foi utilizado este
pacote e foram implementados diversos métodos genéricos que podem ser usados em
diversos tipos de jogos para mandar dados sobre seu uso. O modo como foi implementado o
serviço que se comunica com o Game Analytics permite que ele seja utilizado em qualquer
parte do jogo, e permite que novos métodos sejam incluídos de acordo com a necessidade do
desenvolvedor. Dessa forma, a plataforma cobre as necessidades básicas de um jogo,
permitindo que um desenvolvedor tenha acesso à análise de dados de uso do seu jogo sem
trabalho adicional.
O uso do sistema é bastante simples, pois é todo feito via Unity e um IDE ou editor de
texto para a codificação. Caso o desenvolvedor deseje apenas utilizar as funcionalidades do
Game Analytics, basta adicionar a classe GameAnalyticsService ao projeto, e o pacote do
GameAnalytics, e chamar os métodos desejados em qualquer ponto do jogo. Caso o jogo
desejado seja do tipo plataforma, o desenvolvedor pode utilizar scripts já existentes para
elementos básicos como a movimentação do personagem. Outro produto resultante deste
projeto é o jogo no modo plataforma em si. Para jogá-lo, basta obtê-lo em um dispositivo iOS
ou Android, e iniciar o modo de jogo story, e selecionar o nível que deseja jogar. No momento,
existem dois níveis apenas.

50. /
5.1 - Requisitos
Nesta seção serão apresentados os requisitos para o jogo e para a plataforma.
Requisitos são funcionalidades que o sistema deve possuir, mas também incluem
características mais subjetivas, que são detalhadas na seção de requisitos não funcionais.
Estes requisitos foram estabelecidos antes da etapa de implementação, como guias de como o
sistema deveria ser.
Requisitos funcionais para o jogo:
● O jogo é gratuito para baixar, mas possui in-app purchases.
● O jogo deve poder ser jogado offline.
● O jogo deve possuir dois modos de jogo: plataforma e endless.
● O progresso de um modo não deve afetar o progresso do outro.
● O modo plataforma deve ter no mínimo dois níveis.
● Cada nível possui um número pré-determinado de plataformas, obstáculos e
colecionáveis.
● Podem ser adquiridos bônus em um modo que podem ser utilizados no outro.
● O avatar é um pinguim.
● Itens cosméticos (skins, acessórios) uma vez adquiridos podem ser utilizados nos dois
modos.
● Dinheiro premium pode ser adquirido através de in-app purchases.
● Itens cosméticos não afetam o comportamento do personagem no jogo.
● O personagem pode ser aprimorado tanto permanentemente quanto temporariamente.
● O personagem pode adquirir pontos de experiência conforme vai progredindo e os
utiliza para passar de nível.
● Subir de nível dá um ponto, que pode ser usado para adquirir um aprimoramento
permanente (mais vida, mais velocidade).
● Não é possível diminuir o nível.
● É possível resetar os pontos gastos com um item, para poder redistribuí-los.
● O jogo deve ter uma tela de configurações.
● O jogo no primeiro momento terá dois idiomas: inglês e português.
● O idioma pode ser trocado a qualquer momento na tela de configurações.
● O idioma default será baseado no idioma do aparelho.
● O volume dos efeitos sonoros e música podem ser mudados no menu de configuração.
● O jogo possui um menu inicial com um botão de iniciar, um botão de configurações e
um botão de créditos.
● Após clicar em iniciar, o jogo vai para um menu com botões de iniciar cada modo e um
de customizar o personagem.

51. /
● As seguintes características podem ser customizadas: cor, chapéu, espécie, roupa,
arma.
● No modo plataforma os movimentos do avatar são limitados à: ir para a esquerda e
direita e pular.
● Nos dois modos, é exibida a pontuação do jogador.
● No modo plataforma o jogador ganha pontos por derrotar inimigos e pegar moedas.
● O jogo deve exibir propagandas em forma de banner apenas no menu, de forma a não
atrapalhar o usuário durante uma sessão de jogo.
● O jogo deve oferecer recompensas pequenas por assistir uma propaganda em forma de
vídeo, que pode aparecer em determinados momentos durante a sessão.
● O sistema não pode permitir transações com dinheiro premium se o jogador estiver
offline.
● Todas as fases do jogo devem ser possíveis de ser completadas sem ter que gastar
dinheiro.
Requisitos não-funcionais para o jogo:
● O sistema deve ser compatível com iOS e Android.
● O sistema deve exibir uma interface de simples e intuitiva.
Requisitos funcionais para a plataforma:
● Deve possuir uma classe singleton que fala diretamente com o banco de dados, que
cuida de dados do usuário, progresso do jogo, entre outros.
● Qualquer jogo feito em cima da plataforma deve utilizar apenas a classe singleton para
se comunicar com o banco, incluíndo comunicação com servidor remoto (por exemplo,
para leaderboards).
● Deve possuir uma classe singleton para o Game Analytics.
● Todo jogo deve utilizar os serviços do Game Analytics através da classe singleton .
● A plataforma deve ser utilizada apenas para criar jogos mobile 2D.
● A engine a ser utilizada na plataforma deve ser o Unity.
● Utilização do Game Analytics deve ser feito através do pacote para Unity do mesmo.
● A linguagem a ser utilizada no Unity deve ser C#.
Requisitos não-funcionais para a plataforma:
● Métodos a serem utilizados pelos jogos (comunicação com banco e analytics) devem
possuir nomes simples e intuitivos, de modo que seja fácil para qualquer um fazendo
um jogo saber o que usar a qualquer momento.
● Classes devem ser bem organizadas e autoexplicativas, de modo que seja fácil
identificar que cada uma faz.

52. /
● 5.2 - Modelagem de Classes
Nesta seção, será apresentado um modelo simplificado das classes principais utilizadas
no desenvolvimento do jogo e da plataforma. Como visto na Figura 6, as principais
funcionalidades das classes e o relacionamento entre elas estão representadas utilizando UML.
Como a implementação das mecânicas do jogo no Unity requer um número grande de scripts,
normalmente um por tipo de entidade (inimigo, moeda, plataforma) apenas os mais importantes
para um jogo básico são exibidos.
Figura 6. Modelagem de classes da plataforma

53. /
Player - Classes que controlam os movimentos do personagem. Ambas possuem algumas
similaridades, porém uma controla os movimentos no modo plataforma, o que inclui, por
exemplo, pular em um inimigo, e a outra controla apenas o pulo e movimento sem fim no modo
endless.
Level N - Estrutura que engloba tudo de define um determinado nível do jogo. Atualmente,
cada nível é composto de uma câmera, personagem e um game object (no caso do primeiro
nível, por exemplo, ele se chama Level001) que possui todas as plataformas, inimigos e
moedas presentes naquele nível, além do plano de fundo e o local onde o nível acaba. Todas
essas entidades ficam dentro de uma cena, Level001, a estrutura onde tudo é exibido e permite
a interação com o usuário. Neste caso, cada nível pode ter apenas um personagem (player),
mas o mesmo personagem pode estar presente em vários níveis.
Endless - Estrutura que engloba tudo que define o modo endless. Como esse modo possui
apenas um único nível, todos os objetos necessários estão definidos aqui. Os objetos de maior
importância são: AvailableRooms (cenários pré-prontos que são repetidos aleatoriamente para
complementar o plano de fundo), obstáculos (colocados em cena aleatoriamente para criar
desafio), parallax background (plano de fundo que anda mais lentamente que o resto do
cenário), e padrões de moedas colocados aleatoriamente. O modo endless possui um
personagem apenas.
Coin - Uma moeda é um item coletável que está presente tanto no modo endless quando no
modo plataforma. Atualmente, todas possuem o valor de um e possuem um método que indica
que elas foram coletadas quando colidem com o jogador.
GameAnalyticsService - Classe singleton que contém todos os métodos definidos para
mandar dados para o Game Analytics. Pode ser acessada de qualquer parte do jogo, e possui
conexão direta com o pacote Game Analytics.
DatabaseService - Classe singleton que possui métodos para salvar dados no Firebase. Pode
ser acessada de qualquer parte do jogo, apesar de no momento ser usada apenas pelo modo
endless e se comunica diretamente com o pacote Firebase.
Game Analytics Package - Pacote externo disponibilizado pelo Game Analytics para incluir
suas funcionalidades no Unity.
Firebase Package - Pacote externo disponibilizado pelo Google para incluir alguns de seus
serviços, incluindo o Firebase, no Unity.

54. /
5.3 - Casos de Uso
Nesta seção são detalhados casos de uso para a plataforma e para o jogo. Casos de
uso descrevem um cenário onde algum usuário deseja utilizar alguma funcionalidade do
sistema, o que ocorre durante esta interação, e o que ocorre caso alguma etapa da interação
falhe. Há dois tipos de caso de uso abaixo: três para o desenvolvedor, ou seja, uma pessoa
que quer utilizar a plataforma para adicionar uma das funcionalidades disponíveis ao seu jogo,
ou utilizá-la para criar um jogo desde o princípio, e um para o jogador, cuja única interação
possível no momento é jogar um dos dois modos do jogo.
Casos de Uso do Desenvolvedor:
Nome Conectar jogo com banco de dados
Descrição Utilizar classe chamada DatabaseService que possui conexão
pré-definida com banco para armazenar dados sobre jogo, como fase
atual, número de moedas coletadas e pontuação
Ator Primário Desenvolvedor
Pré-condição Classe já está implementada e métodos de conexão com banco já
funcionam. Banco já existe e possui tabelas prontas
Gatilho Desenvolvedor tem necessidade de usar funcionalidades do banco
Fluxo Principal 1. Desenvolvedor cria instância do singleton DatabaseService
2. Desenvolvedor escolhe métodos disponíveis de acordo suas
necessidades
3. Desenvolvedor inclui métodos de bancos de dados nas classes
necessárias
4. Desenvolvedor passa para métodos as informações que deseja
armazenar, obter ou atualizar
Fluxo Altenativo 2.1 Desenvolvedor não encontra método que desejava
1. Desenvolvedor escolhe outro método que se aproxime
da funcionalidade que ele buscava
2. Desenvolvedor utiliza método escolhido
2.2 Desenvolvedor não encontra método que desejava
1. Desenvolvedor implementa e adiciona método desejado
na interface
2. Desenvolvedor utiliza novo método

55. /
Nome Conectar jogo com Analytics
Descrição Utilizar classe chamada GameAnalyticsService, que utiliza pacote
externo GameAnalytics para adicionar ao jogo métodos de coleta de
dados
Ator Primário Desenvolvedor
Pré-condição Pacote externo já foi instalado, classe está implementada e funciona
Gatilho Desenvolvedor tem necessidade de analisar dados do jogo
Fluxo Principal 1. Desenvolvedor cria instância do singleton GameAnalyticsService
2. Desenvolvedor escolhe métodos disponíveis de acordo suas
necessidades
3. Desenvolvedor seleciona o tipo de dado que deseja analisar
4. Desenvolvedor inclui métodos de análise nas classes
necessárias
5. Desenvolvedor passa para métodos as informações que quer
medir
Fluxo Alternativo 2.1 Desenvolvedor não encontra método que desejava
1. Desenvolvedor escolhe outro método que se aproxime
da funcionalidade que ele buscava
2. Desenvolvedor utiliza método escolhido
2.2 Desenvolvedor não encontra método que desejava
1. Desenvolvedor implementa e adiciona método desejado
na interface
2. Desenvolvedor utiliza novo método
3.1 Desenvolvedor deseja analisar algum dado que não é oferecido
1. Desenvolvedor busca documentação do Game Analytics
e vê quais informações podem ser medidas
2. Desenvolvedor adiciona método para analisar o dado
que ele deseja na interface
3. Desenvolvedor utiliza novo método

56. /
Nome Usar plataforma para fazer jogo do tipo plataforma
Descrição Utilizar funcionalidades da plataforma e do Unity, para criar um jogo
com suporte para iOS e Android
Ator Primário Desenvolvedor
Pré-condição Possuir interfaces de banco de dados e Analytics
Gatilho Desenvolvedor quer fazer jogo
Fluxo Principal 1. Desenvolvedor adiciona elementos externos necessários, como
sprites para personagem, obstáculos e plataformas
2. Desenvolvedor monta nível colocando fundo, personagem,
plataformas e obstáculos nos lugares desejados
3. Desenvolvedor cria scripts para modelar comportamento dos
elementos do jogo, como personagens e inimigos
4. Desenvolvedor cria tela para menu, selecionar modo de jogo,
customização e configurações
5. Desenvolvedor cria script para permitir navegação entre telas
6. Desenvolvedor utiliza interface de banco de dados para permitir
que o jogo possua persistência de dados
7. Desenvolvedor utiliza interface de Game Analytics para coletar
dados sobre o uso do jogo
8. Desenvolvedor compila arquivos e gera arquivo executável do
jogo
Fluxo Alternativo 2.1 Desenvolvedor quer que nível seja procedural
1. Desenvolvedor cria script para desenhar cada imagem
conforme necessário
3.1 Desenvolvedor quer utilizar scripts externos
1. Desenvolvedor busca scripts de terceiros na Asset Store
do Unity
2. Desenvolvedor importa scripts para dentro do seu projeto
3. Desenvolvedor associa scripts aos objetos que precisam
ter seu comportamento definido
3.2 Desenvolvedor quer utilizar script já pronto fora do Unity
1. Desenvolvedor importa seu script do seu computador
para dentro do projeto
2. Desenvolvedor associa scripts aos objetos que precisam
ter seu comportamento definido
4.1 Jogo não possui customização e só possui um modo
1. Desenvolvedor cria apenas tela para menu e
configurações
7.1 Jogo não vai fazer coleta de dados
1. Desenvolvedor não adiciona métodos do Game Analytics

57. /
Casos de Uso do Jogador:
Nome Jogar o jogo
Descrição Usuário abre o aplicativo para iniciar uma sessão de jogo
Ator Primário Jogador
Pré-condição Usuário possui jogo instalado em um dispositivo móvel
Gatilho Usuário abre jogo
Fluxo Principal 1. Tela de menu inicial é apresentada para o usuário
2. Usuário escolhe opção de entrar no jogo
3. Tela com modos de jogo e customização é apresentada para
usuário
4. Usuário escolhe modo de jogo
5. Usuário inicia jogo
6. Usuário joga o jogo no modo desejado
Fluxo Alternativo 2.1 Usuário escolhe opção de configuração
1. Usuário muda configurações de acordo com o necessário
2. Usuário volta pra tela de menu inicial
3.1 Usuário opta por customizar avatar
1. Usuário entra na seção de customização
2. Usuário customiza avatar de acordo com o desejado
3. Usuário volta para tela anterior

58. /
6 - Implementação e avaliação
O sistema foi testado principalmente de forma manual. Primeiramente, foi feito um
protótipo, que foi testado diversas vezes, em Windows, para verificar se os básicos de um jogo
de plataforma funcionavam, e se dados eram mandados para o Game Analytics. Após
determinar que o protótipo funcionava, o projeto em si foi iniciado. Conforme cada
funcionalidade era implementada, o jogo era testado extensivamente. Nos estágios iniciais, ele
foi testado apenas em um computador Windows. Para testar funcionalidades do jogo, como o
comportamento dos personagens e dos inimigos, era usado o próprio editor do Unity, isso é,
não era gerado um executável, e o jogo rodava dentro da engine. Para testar o Game
Analytics, foi necessário pela primeira vez gerar o executável do jogo. A ferramenta não
permite que dados sejam enviados do editor do Unity, portanto, apenas produtos compilados,
que não dependem da engine para executar, funcionam. Isso já havia sido determinado na fase
de prototipação, então, após gerar o executável, em poucos dias foi possível ver dados de uso
do jogo nos relatórios do Game Analytics. Inicialmente, apenas dados de início de um nível
eram enviados.
Outra parte muito importante da fase de teste do projeto foi a de teste com usuários
reais. Uma oportunidade de ir para a feira de jogos Brasil Game Show surgiu e uma versão
simples porém funcional do jogo foi testada por outros desenvolvedores independentes e
visitantes da feira. A versão utilizada rodava em dispositivos iOS, uma das plataformas
propostas para o produto final. Essa experiência foi bastante útil para observar se os usuários
conseguiam jogar o jogo, se achavam interessante, divertido, e para obter feedback de como
melhorar. Apesar do foco deste projeto ser o modo plataforma, ambos este modo e o endless
do outro projeto, eram exibidos igualmente, porém, o modo endless foi mais jogado por possuir
controles mais simples e estar inteiramente funcional. O modo plataforma não estava com os
controles do personagem totalmente funcionais até a feira.
Como o jogo havia sido testado principalmente em desktop, não era visível o quão
deficiente estava o controle touch, que é, obviamente essencial para o sucesso do jogo. Os
controles que haviam sido planejados originalmente para os dispositivos móveis eram a base
de botões na tela. Após o primeiro dia de feira, e feedback de alguns desenvolvedores
independentes, chegou-se à conclusão de que esses controles não eram adequados. Os
botões ocupavam uma parte da tela, tornando menor a área visível do nível, os botões exibiam

59. /
uma pequena defasagem entre o tempo de apertá-los e o personagem responder, era difícil
controlar movimentos precisos e ao tentar pular e se movimentar para a esquerda, o
personagem virava para a direita por um momento, atrapalhando o movimento desejado. No
computador, esses problemas não eram percebidos, pois o personagem era controlado com o
teclado, então, com esses problemas em mente, novas formas de controlar foram elaboradas e
testadas para que no próximo dia, o jogo estivesse diferente e pudesse ser testado novamente.
A primeira tentativa foi criar um controle que emulasse um analógico virtual, ou seja, ao
clicar na tela, o usuário poderia movimentar o dedo para esquerda e direita, para a
movimentação horizontal, e para cima para pular. Os botões então foram removidos e o jogo foi
apresentado novamente. O objetivo nessa etapa foi ver se os usuários se adaptavam aos
controles novos, ou se tinham sugestões para melhorá-los. Desenvolvedores que também
faziam jogos para dispositivos móveis deram sugestões bastante úteis, porém divergentes.
Alguns sugeriram botões novamente, alguns preferiam toque, alguns preferiam que os dois
tipos de movimento fossem separados como em um controle de console, entre outros. A
solução que pareceu mais adequada, pois englobava a maior parte das exigências dos
usuários foi dividir a tela em duas seções, onde cada uma controla um tipo de movimento. O
lado esquerdo funciona como um analógico virtual, onde o usuário pode movimentar o
personagem para a esquerda ou direita com um dedo, e o lado direito é para controlar o pulo
com um toque. Dessa forma, o usuário não há nada cobrindo a tela fora os dedos do usuário, e
os controles são mais intuitivos, dado que em consoles os controles normalmente são dessa
forma: o movimento é controlado com um analógico (joystick ou em alguns casos setas
direcionais) do lado esquerdo do controle, e ações, como pular ou atacar são controladas com
botões do lado direito.
Uma versão primitiva desses controles foi implementada e apresentada. A única
desvantagem foi ter que sacrificar uma ação que havia sido planejada. Antes de modificar os
controles, haveria um botão para o personagem atacar. Dada a necessidade de simplificar os
controles e remover os botões, essa ação foi removida, e o único ataque que restou foi pular
em cima dos inimigos. Apesar deste pequeno sacrifício, foi possível ver o quanto o jogo
melhorou com os novos controles. Os controles ainda não estavam totalmente funcionais,
porém, era um pouco mais fácil de controlar o personagem, e agradou os usuários que haviam
visto o jogo no primeiro dia, quando ele ainda possuía botões. No geral, o resultado desses
testes com usuários foi bastante positivo. Foi possível melhorar o jogo em poucos dias e obter
várias ideias de como melhorar o jogo no futuro, considerando as expectativas de diferentes

60. /
usuários ao jogá-lo. O único problema foi que esse método não testou as funcionalidades do
Game Analytics. Como parte do desenvolvimento do jogo foi apressado para que o jogo fosse
exibido, a parte de analytics foi desabilitada para evitar que o jogo parasse de funcionar,
travasse ou ficasse lento durante as demonstrações, já que a ferramenta ainda não havia sido
testada em iOS.
De modo geral, só houveram dois problemas durante a implementação. Um foi no
começo do projeto, mas também acabou afetando outras partes do processo: a integração com
o Game Analytics. A ferramenta possui documentação sobre como integrá-la com o Unity em
seu site, bem sobre como utilizar os métodos disponíveis para enviar dados. Após seguir todo o
processo descrito e executar o jogo, foi percebido que os dados nunca chegavam aos relatórios
no site. Havia um erro, sugerindo que a ferramenta não funcionava com o editor do Unity,
porém, na documentação, não havia nada que explicasse isso. Fóruns de usuários da
ferramenta ou do próprio Unity também não possuíam nenhuma informação sobre este
problema. Para tentar resolvê-lo, foi preciso entrar em contato com o suporte do Game
Analytics. Após poucos dias, o suporte respondeu e solucionou o problema: o jogo precisava
ser compilado para que os dados fossem enviados. Isso então foi feito, e após um tempo, os
dados começaram a aparecer. Dados sobre novos usuários aparecem antes de dados sobre
uso do jogo, como início de um nível, o que inicialmente pareceu um problema. Para esclarecer
se os dados sobre progresso estavam de fato sendo enviados, foi necessário entrar em contato
com o suporte novamente. Dessa forma, sabendo que certos dados demoram mais tempo para
chegar, não houveram mais preocupações sobre dados não serem registrados. Era necessário
apenas dar mais tempo para eles serem processados. Posteriormente, em uma fase mais
adiantada da implementação, na tentativa de criar eventos adicionais, como enviar o tempo
levado para concluir uma fase, foram encontrados mais problemas. A ferramenta disponibiliza
eventos do tipo design, que podem ser utilizados para rastrear eventos totalmente
customizados, onde o desenvolvedor atribui um nome, uma fase, e até mesmo um valor. Esses
eventos, mesmo após diversos testes, não apareciam nos relatórios gerados. Por falta de
tempo nessa etapa, o suporte não foi contatado, então, para contornar isso, os valores em
questão, como o tempo em segundos, eram enviados como parte do nome do evento. Nos
relatórios, o valor do evento aparece como 0, porém, no nome, pode-se ver o que deveria ser o
valor. Posteriormente, vale a pena explorar esse problema e encontrar uma solução.
O outro problema foi o dos controles para dispositivos móveis. Como detalhado
anteriormente, apesar do objetivo do projeto ser criar um jogo para iOS e Android, ele era

61. /
testado todo em Windows. Quando ele foi compilado para um dispositivo iOS, problemas com
os controles começaram a aparecer. Por não haver conhecimento prévio sobre como lidar com
toque no Unity, foi difícil traduzir os controles de teclado para uma tela de celular. O principal
problema foi lidar com o reconhecimento de múltiplos toques, ou seja, um dedo para o
movimento horizontal, e um para o pulo. Levou tempo para resolver este problema, mas com o
tempo, diversas buscas na internet, e diversos testes, este problema foi completamente
resolvido. A sensibilidade do toque ainda é algo a ser ajustado no futuro, porém, o jogo já está
totalmente jogável.
Por fim, na Figura 7, pode-se ver como o jogo está atualmente, depois de todo o
feedback, a remoção dos botões e melhoria dos gráficos. Nela pode-se ver o personagem,
moedas, uma plataforma que se movimenta verticalmente e uma interface com um botão de
pausa, total de pontos e total de moedas coletadas. A Figura 8 mostra a mesma cena no editor
do Unity. Pode-se observar que está dividida em diversas partes: a hierarquia mostra todos os
game objects em cena, a aba projeto mostra todos os arquivos que compõem o projeto, o
inspetor que mostra detalhes sobre um game object, e no meio temos a cena, onde se coloca
todos os elementos visuais do jogo. Nesta figura, o inspetor exibe os detalhes sobre o objeto
MovingPlatform001, a plataforma logo abaixo das moedas na Figura 7. Esta plataforma é
composta: de duas imagens, que dão a ela seu visual; um Box Collider 2D um script já
existente do Unity que dá a um objeto propriedades de detecção de colisão e um script, que
determina seu movimento. O script se encarrega de movimentar a plataforma dependendo de
algumas variáveis. Variáveis declaradas como públicas em scripts, após o script ser adicionado
a um game object, ficam visíveis na interface do Unity, podendo ser editadas com facilidade.
Neste exemplo, temos variáveis como Movement Type e Speed, que determinam se o
movimento é vertical ou horizontal, e a velocidade do movimento, respectivamente. Esses
valores podem ser mudados diretamente na interface, então, se por exemplo, fosse preciso
mudar a plataforma para que ela se movesse verticalmente, bastava mudar o valor de
Movement Type para 0, sem a necessidade de abrir um IDE.

62. /
Figura 7. Início do nível 1 do modo plataforma.
Figura 8. Interface do Unity.

63. /
7 - Considerações finais
Por fim, após tudo estudado e criado, pode-se dizer que este trabalho foi uma pequena
contribuição para a comunidade de desenvolvedores de jogos. A primeira contribuição feita foi
uma taxonomia dos gêneros dos jogos baseada nas características mais dominantes de cada
jogo e uma tabela para auxiliar a classificação de grande parte dos jogos, relacionando gênero
com suas características principais e alguns jogos de exemplo. O conceito de taxonomia não é
algo novo, então este trabalho se propõe a dar mais uma opinião sobre a classificação de
jogos, contando com uma seção adicional sobre punição e recompensa em jogos de ação, algo
não muito explorado em outras taxonomias.
A outra contribuição foi a plataforma para jogos 2D com suporte para analytics.
Soluções para desenvolvimento multiplataforma de jogos já existem, porém, nenhum possui
integração nativa com serviços de analytics, então, com uso da ferramenta Game Analytics, a
plataforma desenvolvida neste projeto criou uma solução simples para permitir que um jogo
mande dados sobre seu uso para que o desenvolvedor possa constantemente melhorá-lo e
evitar a perda de jogadores.
Neste trabalho foi aprendido como organizar, estruturar e implementar um jogo desde o
início. Conceitos básicos sobre como um jogo funciona, particularmente a forma como toda a
lógica é controlada (update) eram desconhecidos antes das pesquisas feitas para este projeto,
e foram de grande importância. Aprender a utilizar a engine Unity também foi bastante
importante, pois possibilita o desenvolvimento de mais jogos multiplataforma no futuro. O
conceito de analytics também é totalmente inédito, e foi bastante interessante. Porém, para um
projeto de maior escala, serviços mais completos que o Game Analytics provavelmente seriam
necessários. O entendimento sobre essa ciência de dados como forma de fidelizar jogadores é
muito importante para aumentar as chances de sucesso de um jogo, e é um conhecimento para
ser levado no futuro.
Caso houvesse outra oportunidade para desenvolver este projeto de novo, uma das
principais mudanças que a serem feitas seria criar modelos mais genéricos para objetos e
agentes de um jogo. Por exemplo, os scripts que controlam os personagem jogável e os
inimigos possuem métodos para movimentação em duas dimensões. No entanto, um jeito
melhor de fazer talvez fosse possuir uma classe abstrata ou interface para métodos de
movimentos, que os personagens pudessem implementar de acordo com suas necessidades,

64. /
podendo até ser usados em jogos 3D. Outro elemento do jogo que deveria ter sido
implementado de forma mais genérico é o modelo de item coletável. Como nesse jogo só
haviam moedas para serem pegas, não foi feito uma classe genérica para qualquer item
coletável. Apesar da organização dos scripts não ter sido ideal, as tecnologias utilizadas foram
adequadas e cumpriram com o que foi esperado. Para um trabalho futuro, talvez fosse
necessário fazer uma pesquisa maior sobre melhores práticas de implementação de um jogo.
Outra funcionalidade que poderia ter sido desenvolvida com mais calma é a de analisar dados
do usuário. Várias possibilidades foram consideradas, como sucesso e falha em um nível,
tempo para completar um nível, entre outros, porém, estas foram feitas durante a
implementação. Seria mais vantajoso planejar de antemão tudo que deve ser analisado, para
que não falte durante o processo de implementação.
A oportunidade futura que pode ser aproveitada por outro aluno é explorar o conceito de
analytics em maior profundidade. Nesse projeto, a ferramenta Game Analytics foi utilizada
apenas para apenas enviar dados e gerar gráficos sobre o uso do jogo. Todos os gráficos eram
analisados manualmente para ver como o jogo estava sendo jogado. Um passo adiante seria
encontrar uma forma de pegar esses dados e utilizar algum método de machine learning para
prever o comportamento dos jogadores, baseado no que foi feito, e prever mudanças que
poderiam ser feitas para aumentar a captação de novos jogadores, além da retenção dos
atuais. Como o jogo implementado é pequeno e foi utilizado por poucas pessoas, era fácil
visualizar todos os gráficos individualmente, pois a quantidade de dados era pequena. Porém,
um jogo maior tornaria essa tarefa muito custosa, tornando o auxílio do computador necessário.
Havendo um processo automatizado para coletar e analisar dados, o desenvolvedor não teria
necessidade de verificar periodicamente gráficos e relatórios, ele seria apenas notificado de
quais predições foram feitas, e tomar decisões sobre o que fazer. Empresas muito grandes e
com muito orçamento possuem ferramentas que fazem isso, dedicadas para seus jogos,
porém, no mercado ainda não há nada parecido disponível para pequenos desenvolvedores,
portanto, seria um grande avanço implementar algo desse tipo.
Outra oportunidade futura é expandir a taxonomia para incluir outras visões sobre
classificação de jogos. A taxonomia exibida aqui se baseia em características de gameplay
para encaixar jogos em um determinado gênero, porém, esta é apenas uma visão, então seria
interessante explorar outros métodos, como por exemplo, machine learning para gerar novos
agrupamentos de jogos.

65. /
Referências
Baere, B., 2012. Um estudo sobre adaptatividade dinˆamica de dificuldade em jogos
Disponível em:
http://www.icad.puc-rio.br/~baere/pdfs/1012625_2012_completa.pdf
Bleszinski, C., 2000. The Art and Science of Level Design
Disponível em:
http://gamedevs.org/uploads/the-art-science-of-level-design.doc
Compton K., Mateas M., 2006. Procedural Level Design for Platform Games
Disponível em:
https://pdfs.semanticscholar.org/ff35/3255097e2ad97e6e8b858ff6d09814aa9ad6.pdf
Desurvire H., Caplan M., Toth J. A., 2004. Using Heuristics to Evaluate the Playability of
Games
Disponível em:
http://nexus.hs-bremerhaven.de/Library.nsf/0946dbe6a3c341e8c12570860044165f/5d8dbf94a7f
9688ac1257c9a003d8baf/$FILE/p1509-desurvire%20PlayabilityHeuristics.pdf
Gundmundsen, J. 2007. Songs from 'High School Musical' showcased in rhythm game
Disponível em:
https://usatoday30.usatoday.com/tech/columnist/jinnygudmundsen/2007-08-23-high-school-mus
ical_N.htm
Gunn E. A. A., Craenen B. G. W., Hart E. A Taxonomy of Video Games and AI
Disponível em:
http://www.aisb.org.uk/convention/aisb09/Proceedings/AIGAMES/FILES/GunnE.pdf

66. /
Gustafsson A., 2014. An Analysis of Platform Game Design
Disponível em:
https://webcache.googleusercontent.com/search?q=cache:eOUahJlbXkwJ:https://www.diva-port
al.org/smash/get/diva2:728079/FULLTEXT01.pdf+&cd=9&hl=pt-BR&ct=clnk&gl=br
Haas J., 2014. A History of the Unity Game Engine
Disponível em:
https://web.wpi.edu/Pubs/E-project/Available/E-project-030614-143124/unrestricted/Haas_IQP_
Final.pdf
Hall R., Novak J. Game Development Essentials - Online Game Development
Disponível em:
https://books.google.com.br/books?id=9cIWAAAAQBAJ&pg=PT150&lpg=PT150&dq=spore+ga
me+strategies&source=bl&ots=5Y6y_5ZMuF&sig=AjPNV4uq7AJh_GlljY227lUnmCE&hl=pt-BR
&sa=X&ved=0ahUKEwjLuu23zZrUAhUIHJAKHQ_xBYc4ChDoAQgyMAU#v=onepage&q=spore
%20game%20strategies&f=false
Isbister K., Schaffer N., 2008. Game Usability: Advancing the Player Experience
Juul J. Fear of Failing? The Many Meanings of Difficulty in Video Games
Disponível em:
https://www.jesperjuul.net/text/fearoffailing/
[Acessado 05/06/2017]
Juul J. In Search of Lost Time:On Game Goals and Failure Costs
Disponível em:
https://www.jesperjuul.net/text/losttime/
[Acessado 05/06/2017]

67. /
Kubba S., Orland K., 20 de abril de 2012. Practically Impossible: The quest to decipher
Fez’s cryptic final puzzle. Ars Technica.
Disponível em:
https://arstechnica.com/gaming/2012/04/why-it-took-almost-a-week-for-the-world-to-completely-f
inish-fez/
[Acessado 31/05/2017]
Newheiser M., 9 de março de 2009. Playing Fair: A look at competition in gaming. Strange
Horizons.
Disponível em:
http://strangehorizons.com/non-fiction/articles/playing-fair-a-look-at-competition-in-gaming/
[Acessado 05/06/2017]
Purchese R., 12 de setembro de 2014. Life is Strange: It takes time to be different.
Eurogamer.net.
Disponível em:
http://www.eurogamer.net/articles/2014-09-10-life-is-strange-it-takes-time-to-be-different
[Acessado 31/05/2017]
Sala T., 10 de agosto de 2011. Game Theory Applied: The Flow Channel. Indie Dev Stories.
Disponível em:
http://indiedevstories.com/2011/08/10/game-theory-applied-the-flow-channel/
[Acessado 12/06/2017]
Schell, J., 2011. The Art Of Game Design: A Book of Lenses
Silva L., 2014. Game Analytics: Mineração de Dados para Desenvolvimento e Avaliação
de Jogos
Disponível em:
https://www.researchgate.net/publication/303484347_Game_Analytics_Mineracao_de_Dados_p
ara_Desenvolvimento_e_Avaliacao_de_Jogos?enrichId=rgreq-134eb2b7add54ed2358d962e82
c6bac8-XXX&enrichSource=Y292ZXJQYWdlOzMwMzQ4NDM0NztBUzozNjUzNDg3MjY1NTg3
MjBAMTQ2NDExNzMzMjYxNA%3D%3D&el=1_x_3&_esc=publicationCoverPdf

68. /
Smith G., Cha M., Whitehead J., 2008. A Framework for Analysis of 2D Platformer Levels
Disponível em:
https://users.soe.ucsc.edu/~gsmith/sandbox_examples/sandbox08_pictures.pdf
Statt N., 16 de junho de 2015. Football, soccer and...Super Smash Bros? E-sports
becoming a big business. CNET.
Disponível em:
https://www.cnet.com/news/football-soccer-and-super-smash-bros-e-sports-becoming-big-busin
ess/
[Acessado 31/05/2017]
Stein A., Konstantin M., Consalvo M., 2013. Sports Videogames
Disponível em:
https://books.google.com.br/books?hl=pt-BR&lr=&id=ee0cAAAAQBAJ&oi=fnd&pg=PP1&dq=sp
ort+videogames&ots=p0PLjzYwTj&sig=hsklxL_XOylCM7imzGM2uN6Hyac#v=onepage&q=spor
t%20videogames&f=false
Unity, 2017. Bloom
https://docs.unity3d.com/550/Documentation/Manual/script-Bloom.html
Game Analytics, 2016. Implementing your tracking
http://www.gameanalytics.com/docs/implementing-your-tracking
Vegas, J. Jimmy Vegas Tutorials
https://jvunity.weebly.com/
[Acessado 23/11/2017]
Open Game Art
https://opengameart.org/
[Acessado 27/11/2017]