Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
JOGO MUSICAL PARA AUXILIAR O EXERCÍCIO DE EXECUÇÃO RÍTMICA
por
Rodrigo Lyra
Itajaí (SC), julho de 2013
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
JOGO MUSICAL PARA AUXILIAR O EXERCÍCIO DE EXECUÇÃO RÍTMICA
Área de Jogos Digitais
por
Rodrigo Lyra Relatório apresentado à Banca Examinadora do Trabalho Técnico-científico de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Elieser Ademir de Jesus, M.-Sc.
Itajaí (SC), julho de 2013
AGRADECIMENTOS
Não sou muito bom em fazer agradecimentos. A ordem que vou utilizar não é
necessariamente em grau de importância e peço desculpas se esqueci de alguém.
Agradeço a minha família por tudo que fizeram por mim e por nunca questionar as
minhas escolhas, sem eles não teria chegado até aqui.
Também gostaria de agradecer a todos os amigos que fiz na faculdade, desde os
companheiros de programação até as companhias para uma partida de truco no bar. Embora
que com alguns guarde comigo um sentimento de decepção, muitos deles se tornaram
companhias que pretendo guardar para a vida inteira.
Agradeço também aos professores, que durante esses anos tanto me ensinaram, e
também aqueles que me proporcionaram as oportunidades de trabalhar em projetos dentro da
universidade.
E por último, mas não menos importante, agradeço ao meu orientador por toda a ajuda
e paciência que teve comigo
"There are three things all wise men fear: the sea in storm, a night with no moon, and the anger of a gentle man."
-Patrick Rothfuss
RESUMO
LYRA, Rodrigo. Jogo Musical para auxiliar o exercício de execução rítmica. Itajaí, 2013. 92 f. Trabalho Técnico-científico de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2013. Este trabalho trata da criação de um jogo musical para utilização em exercícios de execução rítmica. O aprendizado de rítmica que ocorre nos cursos de músicas tem o apoio de diferentes formas de exercícios, mas pode ser interessante uma alternativa em forma de jogo para o processo de aprendizagem. O objetivo do trabalho proposto foi criar um jogo do gênero runner que possa ser utilizado como uma alternativa lúdica aos exercícios de execução rítmica, ele apresenta partituras e sequências sonoras que devem ser reproduzidas utilizando um microfone e a reprodução de sons ritmados ou o toque de tela como formas de interação. O jogo foi criado para dispositivos móveis por ser uma plataforma que normalmente já tem um microfone e por conta de sua mobilidade. Para a criação do trabalho foram pesquisadas diferentes fontes nas áreas de desenvolvimento de jogos e também de conceitos musicais, também foram analisados trabalhos que apresentam similaridades com o projeto proposto. Como plano de fundo para o jogo foi criada a história de James, um menino que sonha em ser baterista e atravessa a cidade atrás de uma audição para participar de uma banda, no caminho ele tem que enfrentar diversos obstáculos, que para serem superados, uma sequência musical deve ser reproduzida pelo jogador no ritmo correto. O jogo foi feito utilizando a engine de jogos Unity3D para as plataformas Android e iOS. Palavras-chave: Jogo. Jogo Musical. Ritmo.
ABSTRACT
This work treats with the creation of a musical game for use in rhythmic execution exercises. The rhythmic learning in music courses has support of different forms of exercises, but can be an interesting alternative a way to play in learning process. The goal of the proposed work was to create a runner game that can be used as an alternative to the playful rhythmic exercises, it presents music and sound sequences should be replicated playing rhythmic sounds in microphone or using the touch screen as forms of interaction. The game was created for mobile devices because this platform usually already have a microphone and by their mobility. For work creation were researched different sources in the game development and musical concepts areas, and analyzed studies that show similarities with the proposed project. As background for the game was created the story of James, a boy who dreams of being a drummer, he crosses the city after an audition to join in a band, on the way he has to face many obstacles that must be beaten by the player, playing the musical sequence assigned to them in the correct rhythm. The game was made using the Unity3D game engine for Android and iOS platforms. Keywords: Game. Musical Game. Rythm.
LISTA DE FIGURAS
Figura 1. Patapon, exemplo de um jogo musical ...................................................................... 22 Figura 2. Temple Run, exemplo de um runner ........................................................................ 23 Figura 3. Super Mario World, exemplo de um jogo 2D ........................................................... 24 Figura 4. Zelda: Skyward Sword, exemplo de um jogo 3D ..................................................... 25 Figura 5. Street Fighter IV, exemplo de um jogo 2.5D ............................................................ 26 Figura 6. Exemplo de arte conceitual e arte final ..................................................................... 28 Figura 7. Exemplo de modelo tridimensional e suas texturas mapeadas ................................. 29 Figura 8. Exemplo de Sprite Sheet ........................................................................................... 30 Figura 9. Trecho de partitura demonstrando a pauta e dividido em cinco compassos ............. 33 Figura 10. Representação visual e nome das durações de notas e pausas ................................ 35 Figura 11. Imagem do jogo Só Soprando ................................................................................. 36 Figura 12. Protótipo de tela do jogo Rainbow Strings ............................................................. 37 Figura 13. Tela do jogo Patapon ............................................................................................... 38 Figura 14. Minigame do jogo Rythm Heaven Fever ................................................................ 39 Figura 15. Imagem do jogo BIT.TRIP RUNNER .................................................................... 40 Figura 16. Sprite Sheet com as posições do personagem ......................................................... 44 Figura 17. Exemplo do processo de captura de áudio .............................................................. 47 Figura 18. Exemplo do tratamento de entradas ........................................................................ 49 Figura 19. Exemplo de entradas em uma sequência ................................................................. 51 Figura 20. Exemplo de partitura ............................................................................................... 53 Figura 21. Captura de tela do jogo no momento em que um obstáculo é disparado ................ 53 Figura 22. Fluxograma das telas do jogo .................................................................................. 70 Figura 23. Tela Inicial .............................................................................................................. 71 Figura 24. Tela de Opções ........................................................................................................ 72 Figura 25. Tela de Ajuda .......................................................................................................... 73 Figura 26. Tela de Seleção de Níveis ....................................................................................... 74 Figura 27. Tela do jogo ............................................................................................................. 75 Figura 28. Tela de Relatório ..................................................................................................... 76 Figura 29. Sequência de obstáculos de cada nível .................................................................... 83 Figura 30. Diagrama de classes do jogo ................................................................................... 89 Figura 31. Diagrama de atividades da fase ............................................................................... 90
LISTA DE QUADROS
Quadro 1. Pseudocódigo da estrutura do código de um jogo ................................................... 27 Quadro 2. Quadro comparativo de trabalhos similares ............................................................ 41 Quadro 3. Movimentação do personagem ................................................................................ 45 Quadro 4. Estrutura do XML de partituras ............................................................................... 52
LISTA DE ABREVIATURAS E SIGLAS
2D Duas dimensões 2.5D Duas dimensões e meia 3D Três dimensões GDD Game Design Document GUI Graphical User Interface IMCARTI Instituto de Música, Canto e Arte de Itajaí RMS Root Mean Square TTC Trabalho Técnico-científico de Conclusão de Curso UNIVALI Universidade do Vale do Itajaí XML Extensible Markup Language
SUMÁRIO
1 INTRODUÇÃO .......................................................................................................................... 15 1.1 PROBLEMATIZAÇÃO .................................................................................................................... 16 1.1.1 Formulação do Problema .................................................................................................................... 16 1.1.2 Solução Proposta ..................................................................................................................................... 16
1.2 OBJETIVOS ...................................................................................................................................... 17 1.2.1 Objetivo Geral ........................................................................................................................................... 17 1.2.2 Objetivos Específicos ............................................................................................................................. 17
1.3 Metodologia .................................................................................................................................... 17 1.4 Estrutura do trabalho ................................................................................................................. 18
2 FUNDAMENTAÇÃO TEÓRICA .............................................................................................. 19 2.1 Desenvolvimento de jogos ........................................................................................................ 19 2.1.1 GDD ............................................................................................................................................................... 20 2.1.2 Gênero de jogos ........................................................................................................................................ 21 2.1.3 Duas dimensões, três dimensões, ou duas dimensões e meia ............................................. 23 2.1.4 Programação de jogos e engines ....................................................................................................... 26 2.1.5 Arte para jogos ......................................................................................................................................... 28 2.1.6 Som ................................................................................................................................................................ 31
2.2 Conceitos musicais ....................................................................................................................... 32 2.2.1 Ritmo ............................................................................................................................................................ 32 2.2.2 Notação musical ....................................................................................................................................... 32 2.2.3 Execução Rítmica .................................................................................................................................... 35
2.3 Trabalhos Similares .................................................................................................................... 35 2.3.1 Só Soprando ............................................................................................................................................... 36 2.3.2 Rainbow Strings ....................................................................................................................................... 37 2.3.3 Patapon ........................................................................................................................................................ 38 2.3.4 Rythm Heaven Fever ............................................................................................................................. 39 2.3.5 BIT.TRIP RUNNER .................................................................................................................................. 39 2.3.6 Quadro comparativo dos trabalhos similares ............................................................................ 40
3 Desenvolvimento ................................................................................................................... 42 3.1 Análise de tecnologias para desenvolvimento do jogo .................................................... 42 3.2 Ferramentas utilizadas .............................................................................................................. 43 3.3 Detecção de som ........................................................................................................................... 45 3.4 Interação do usuário ................................................................................................................... 48 3.5 Verificação de entrada ................................................................................................................ 50 3.6 Modificadores de jogabilidade ................................................................................................ 51 3.7 Obstáculos e CheckPoints ........................................................................................................... 51 3.8 Testes ............................................................................................................................................... 53
4 CONCLUSÕES ........................................................................................................................... 56 APÊNDICE A. GDD .............................................................................................................. 63 APÊNDICE B. DIAGRAMAS DE MODELAGEM ............................................................. 88 APÊNDICE C. QUESTIONÁRIO DOS TESTES ............................................................... 91
15
1 INTRODUÇÃO
Na metade do século XX os computadores eram principalmente utilizados para
propósitos de pesquisa. Nessa época começaram a surgir os primeiros jogos digitais, o
primeiro deles apareceu em 1958 com o nome “Tennis for Two” criado pelo Brookhaven
National Laboratory dos Estados Unidos. Depois disso os jogos passaram a se popularizar em
arcades, um videogame montado em um gabinete com monitor que era normalmente
encontrado em ambientes de entretenimento, e consoles de videogame, somente anos mais
tarde com o crescimento do número de computadores pessoais foi que os jogos se tornaram
populares nesses equipamentos (NOVAK, 2011).
Com a popularização da internet e a diversidade do perfil de jogadores, uma nova
categoria de jogos surgiu, os jogos casuais, onde não são necessárias horas de dedicação para
aprender a jogar, o que não significa que não tenham qualidade ou não prendam a atenção dos
jogadores. Os jogos casuais se propagaram principalmente com a chegada dos jogos nos
navegadores de internet, dispensando a necessidade de instalar programas e outros recursos. E
agora esse seguimento está passando para os dispositivos móveis, que por sua mobilidade são
acessados de diferentes lugares e servem como um rápido passatempo. Essa categoria de
jogos atinge um grande grupo de jogadores e é um mercado que pode ser explorado (LOPES;
SORIANO; OLIVEIRA, 2009).
Um dos objetivos na evolução nos jogos é a procura por novas formas de interação
humano computador. O WII (NINTENDO, 2010) com o seu controle especial deu um grande
passo nessa área, e foi seguido alguns anos mais tarde pelo Kinect (MICROSOFT, 2012) que
faz o reconhecimento de movimento e voz. Nos computadores pessoais a pesquisa partiu
principalmente em periféricos comuns como microfones (FAVA, 2008) e webcams (SOUZA;
COUTO; DAZZI, 2009) e tem avançado mais a cada ano, sempre tentando dar mais opções e
melhorar a interação entre o jogador e o jogo.
Um gênero de jogos muito utilizado em dispositivos móveis é o runner. Esse gênero
normalmente traz um personagem principal que fica em constante movimento na tela e deve
se desviar de diferentes obstáculos que tentam impedir sua passagem. O jogador não tem
controle total da movimentação como em um jogo de plataforma, mas pode ter algum controle
limitado, e ele deve conseguir transpor os obstáculos para progredir.
16
Um ponto importante na maioria dos jogos é a música, ela normalmente está no plano
de fundo e ajuda na imersão da atmosfera do jogo. Também existem jogos onde a música faz
parte da jogabilidade, fazendo com que ela influencie o modo como o jogador interage com o
universo do jogo. E dentro deste grupo de jogos existe uma fatia que utiliza o ritmo, que faz
com que as ações do jogo tenham um fator adicionado, o tempo. Além de executar o comando
correto o jogador deve executar essa ação no tempo certo, imposto pelo ritmo do jogo
(PICHLMAIR; KAYALI, 2007).
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Realizou-se uma conversa com o professor Rodrigo Gudin Paiva, professor de
disciplinas que envolvem ritmo no curso de Música da UNIVALI (Universidade do Vale do
Itajaí), que relatou uma dificuldade dos alunos no momento de realizar avaliações de
execução rítmica e também mencionou que os exercícios de execução rítmica existentes não
são muito atrativos, principalmente aos alunos iniciantes que não tem conhecimento em
leitura de partituras.
1.1.2 Solução Proposta
A proposta do trabalho é um jogo do gênero runner onde em cada fase existem
diferentes chaves musicais, um sequência de notas corretas, e o jogador deve conseguir
acertá-las para progredir no jogo. O jogador utiliza a reprodução de sons ritmados através de
um microfone para fazer a entrada da sequência, e se preferir, pode utilizar toques ritmados na
tela como opção. Esse jogo pode ser uma alternativa aos exercícios convencionais de
execução rítmica, trazendo uma forma lúdica de apresentar o conteúdo para tornar o processo
de aprendizagem mais atrativo.
O jogo foi desenvolvido utilizando a plataforma de dispositivos móveis, pela sua
mobilidade e porque um grande número deles apresenta microfone.
17
1.2 OBJETIVOS
1.2.1 Objetivo Geral Desenvolver um jogo digital do gênero runner onde o jogador deve acertar o ritmo de
sequências de notas musicais utilizando como entrada a reprodução de sons ritmados, e com
isso auxiliar estudantes de música a exercitar a leitura rítmica de partituras.
1.2.2 Objetivos Específicos Os objetivos específicos deste trabalho são:
• Pesquisar outros trabalhos que utilizem conceitos similares ao projeto;
• Pesquisar sobre os conceitos musicais relacionados ao ritmo e a notação musical.
• Analisar as tecnologias disponíveis para a criação do jogo;
• Criação de um GDD (Game Design Document – Documento de Game Design);
• Realizar a implementação do jogo de acordo com o GDD;
• Efetuar testes visando a correção de possíveis falhas e a também disponibilizar o jogo
para analisar a avaliação dos jogadores;
• Documentar o trabalho desenvolvido.
1.3 Metodologia
Para alcançar os objetivos do trabalho, foi realizada uma pesquisa sobre o
desenvolvimento de jogos, partindo de conceitos de desenvolvimento, documentação, gêneros
e outros detalhes técnicos partindo de obras de diferentes autores (NOVAK, 2011;
BALDWIN, 2005; LOBÃO et al, 2009). Também foi feita uma pesquisa sobre conceitos
musicais pertinentes ao projeto, como ritmo e notação musical (POZZOLI, 1978; LACERDA,
1961; SCHAFER, 1992). As principais fontes de pesquisa foram livros, os anais do SBGames
e o Google acadêmico.
Na pesquisa de trabalhos similares foram consultados alguns artigos como o do jogo
Só Soprando (FAVA, 2008) e a proposta do jogo Rainbow Strings (VIANNA, 2010) e
também alguns produtos comerciais (NINTENDO, 2012; SONY, 2011; GAIJIN, 2010). Os
trabalhos acadêmicos foram analisados pelos seus respectivos artigos e os produtos
comerciais pelos sites oficiais e pela experiência do orientando deste TTC (Trabalho Técnico-
científico de Conclusão de Curso).
18
Após a fundamentação foi feita uma seleção de possíveis tecnologias a serem
utilizadas no desenvolvimento do projeto (ver Seção 1), utilizando parâmetros como
facilidade de uso e conhecimento da ferramenta. A lista de ferramentas selecionadas foi
analisada e reunindo as características de cada uma foi definido o que foi utilizado para o
TTC II. Por fim gerou-se um GDD especificando os principais aspectos do jogo criado, como
jogabilidade, ferramentas auxiliares e ambientação.
No processo do TTC II inicialmente foi pesquisada, definida e implementada a melhor
forma de fazer a captação e o tratamento do áudio do microfone, depois foi feito a tratamento
e a calibragem do microfone para identificar as execuções de entradas do jogador. Para a
seleção das imagens de partitura foi criado um esquema de XML(eXtensible Markup
Language). Por fim, o restante da estrutura do jogo foi criada.
1.4 Estrutura do trabalho
Este documento está estruturado em quatro capítulos. O Capítulo 1, Introdução, apresenta
uma visão geral do trabalho. No Capítulo 2, Fundamentação Teórica, é realizada uma revisão
bibliográfica sobre os temas pertinentes ao trabalho, contemplando conceitos relacionados ao
desenvolvimento de jogos e conceitos musicais de ritmo e notação musical. Também é
mostrada uma análise sobre trabalhos similares. O Capítulo 3 apresenta os processos de
desenvolvimento do sistema, o GDD e os diagramas feitos no TTC I estão nos apêndices. Por
fim, no Capítulo 4, apresentam-se as Conclusões, onde são abordados os resultados
alcançados e outras observações.
19
2 FUNDAMENTAÇÃO TEÓRICA
Esta seção trata da fundamentação teórica do trabalho proposto, utilizando referências
de autores sobre os assuntos abordados no desenvolvimento do projeto. Inicialmente se expõe
o conceito de jogos digitais de uma forma geral e em seguida os conceitos musicais utilizados
no TTC, por último são analisados trabalhos similares.
2.1 Desenvolvimento de jogos
O processo de desenvolvimento normalmente começa com um conjunto de reuniões
para elaboração da ideia geral do jogo que será desenvolvido. Nesta etapa são analisados
fatores como o público alvo, a plataforma para a qual o jogo será desenvolvido e as
possibilidades de mercado. Após essas reuniões, começa a etapa de elaboração do game
design, ele estabelece como será a jogabilidade, como serão os controles, a interface e os
elementos do jogo. Essa etapa é documentada em um GDD, ele registra e organiza todas as
características definidas do game design (PERUCIA et al, 2005).
A partir desse documento são definidas as tarefas para os programadores e artistas e é
feito um cronograma. Com as tarefas definidas começa a etapa de desenvolvimento, é nessa
etapa onde o jogo começa a ganhar vida, os artistas fazem os primeiros esboços e os
programadores criam as funcionalidades básica e se inicia a produção de protótipos e versões
intermediárias, com o tempo a arte fica mais complexa e definida, surgem os efeitos sonoros e
músicas e a mecânica do jogo ganha forma, até chegar ao resultado esperado e descrito no
GDD (PERUCIA et al, 2005).
No desenvolvimento de jogos normalmente ocorre a criação de pacotes de elementos
do jogo, chamados de assets. Estes componentes podem ser executados de forma
independente do restante do jogo, isso auxilia no processo de testes de funcionalidades
individuais. Isso também auxilia no trabalho entre diferentes equipes, onde uma equipe pode
enviar partes do que produziu em forma de assets para a outra, isso torna o processo menos
isolado (ANDRÉ, 2010). A produção de assets também pode ser um modelo de negócio, a
engine de jogos Unity3D, por exemplo, tem uma loja dedicada a compra e venda de assets.
Os testes normalmente são uma das últimas etapas no processo de criação de jogos.
Eles podem ocorrer ao decorrer da etapa de projeto e desenvolvimento com a elaboração de
20
casos de testes, mas o mais comum são os testes com versões executáveis do jogo. Os
testadores devem identificar, além de erros e comportamentos inesperados, se o jogo é
consistente e divertido. O testador é tratado como uma amostra do público final do jogo e as
informações passadas por ele são recolhidas pela equipe de desenvolvimento e fazem as
mudanças necessárias e aplicam um novo teste. Outra tarefa associada com os testes é o
controle de qualidade, o seu foco é identificar se o jogo está de acordo com as normas
estabelecidas pelo desenvolvedor e pela editora. Além de utilizar testadores internos, alguns
jogos disponibilizam uma versão do jogo para o público avaliar. Chamada de versão beta, ela
normalmente não apresenta o jogo completo, e serve para que jogadores opinem sobre o jogo
e identifiquem possíveis erros remanescentes antes que o jogo final seja lançado (NOVAK,
2011).
2.1.1 GDD
O GDD é um documento que registra todas as características que estão presentes no
jogo, ele é o esquema para os programadores e artistas construírem o produto final. Existem
diferentes modelos de GDD e cada jogo precisa ter documentos adaptados para o seu tipo.
Alguns jogos precisam de detalhamento dos elementos de cada fase ou detalhamento da sua
mecânica, enquanto em outros estes aspectos não são importantes. Com o decorrer do
processo de desenvolvimento o GDD será analisado várias vezes pela equipe de
desenvolvimento com o objetivo de obter informações sobre o que será feito a seguir. Este
documento precisa ser escrito de forma clara e as informações precisam ser de fácil
entendimento. O documento não é imutável, e no decorrer do processo de desenvolvimento
ele pode sofrer alterações de acordo com as novas necessidades e ideias (BALDWIN, 2005).
Neste projeto utiliza-se como base o esquema proposto por Baldwin (2005), e a partir
dele serão feitas algumas modificações na estrutura para ficar mais adequado ao tipo de jogo
proposto. Algumas seções referentes a conteúdo criado não estão presentes, pois o projeto não
está em fase de produção. Também foram retirados elementos não presentes no jogo, como
economia e diálogo entre personagem. A seção de níveis foi simplificada pela estrutura de
todos os níveis do jogo serem parecidas. Foi adicionada uma seção para detalhamento dos
obstáculos.
21
2.1.2 Gênero de jogos
Jogos normalmente são classificados através de gêneros, mas existem controvérsias
quanto ao termo. Inicialmente o objetivo desta classificação era se assemelhar a usada
comercialmente na literatura e no cinema. A confusão se estende às empresas produtoras de
jogos e também aos autores e pesquisadores. Enquanto alguns abordam o gênero derivando da
jogabilidade apresentada, outros costumam classificar os jogos de acordo com o seu público
alvo, isto ocasiona confusões devido a fontes divergentes e a até mesmo à escassez delas para
a definição de alguns gêneros (SATO; CARDOSO, 2008).
A seguir discutem-se dois gêneros relevantes ao trabalho e que estão presentes no jogo
desenvolvido.
2.1.2.1 Jogos musicais
O gênero de jogos musicais representa jogos onde a música é o ponto central da
jogabilidade. Estes jogos podem ser classificados em duas categorias principais: os jogos
instrumentais e os baseados em ritmo. Os jogos instrumentais utilizam diferentes padrões,
como associação do sentido da audição com a visão, associando cores e formas a sons. Ele
também pode motivar o jogador a se movimentar por meio da música, como acontece em
jogos de dança. Existem também jogos que fazem a simulação de um desempenho musical
real, como o Guitar Hero (PICHLMAIR; KAYALI, 2007).
Na categoria dos jogos baseados em ritmo, o foco principal é impor um ritmo que deve
ser seguido pelo jogador para que ele consiga progredir. Os jogos podem mapear as notas de
uma música, não necessariamente de forma fiel, para serem reproduzidas pelo jogador.
Alguns jogos, mesmo fora da categoria musical, podem apresentar desafios onde apresentam
uma sequência rítmica que deve ser repetida. Outra forma deste tipo de jogo é onde são
criadas representações de diferentes comandos do jogador usando sequências rítmicas
distintas, que podem usados de forma não linear durante o jogo, como é o caso do jogo
Patapon (Figura 1) (PICHLMAIR; KAYALI, 2007).
22
Figura 1. Patapon, exemplo de um jogo musical
Fonte: Eurogamer (2008)
2.1.2.2 Runner
O gênero de jogos runner é relativamente novo e carece de fontes. Esta terminologia é
conhecida entre os jogadores, mas ainda não é considerado relevante no meio acadêmico.
Uma nomenclatura mais usual que normalmente é utilizada para o gênero é a de ação-
plataforma. Um dos pioneiros nesse gênero é o Canabalt e mesmo esse jogo é classificado
utilizando outros gêneros. O que estes jogos possuem em comum é a semelhança com o
gênero de plataforma, como o Sonic, e o constante movimento do personagem. Os controles
de movimentação do jogador são limitados e seu principal objetivo é o desvio de obstáculos
que aparecem pelo caminho. Devido a facilidade dos controles, os mais simples utilizam
somente a ação de pular. Este gênero possui diversos exemplos, entre os mais populares
encontram-se o Temple Run (Figura 5), o Jetpack Joyride e o Subway Surfer.
23
Figura 2. Temple Run, exemplo de um runner
Fonte: ATOMICONLINE (2012)
2.1.2.3 Jogos Educacionais
Além do seu papel no entretenimento, os jogos podem ter um papel importante na
educação, pois já fazem parte da nossa vida e podem ser um complemento na aprendizagem.
Nos jogos casuais o jogador interage com um mundo novo de inúmeras possibilidades, e esse
ambiente interativo consegue proporcionar uma maior atenção e motivação do aluno, e pode
trazer a ele experiências que não poderiam ser reproduzidas na vida real. Mesmo existindo
uma discussão sobre a definição correta de jogos educacionais, para análise, pode-se
considerar como todas as aplicações que podem ser usadas para algum objetivo educacional
ou estão embasadas pedagogicamente. Partindo deste pensamento, o jogo criado pode ser
considerado como educacional (TAROUCO et al, 2004; GUERRA, 2009).
2.1.3 Duas dimensões, três dimensões, ou duas dimensões e meia
No momento da elaboração da ideia de um jogo existe um importante fator a ser
decidido: como será a forma de representação gráfica. O jogo pode utilizar somente duas
dimensões de espaço e ser 2D (duas dimensões), fazer uma representação espacial mais
24
próxima da realidade e ser 3D (três dimensões), ou um nível intermediário entre os dois
conceitos e formar a representação 2.5D (duas dimensões e meia) (NOVAK, 2011).
Os jogos 2D foram os primeiros a surgirem no mercado, eles utilizavam somente duas
dimensões que formam um plano, um exemplo pode ser visto na Figura 1. Este tipo de jogo,
pelo fato da tela onde é exibido ser um plano também, utiliza as coordenadas de altura e
largura em relação a ela como base para desenho. Diferente do 3D que precisa trabalhar com
uma medida própria e depois ser convertido para um plano antes de ser exibido. Os jogos
casuais normalmente utilizam a representação em duas dimensões, pois a complexidade para
produção é menor e exige menos recursos de hardware (SILVA et al, 2009; LOPES;
SORIANO; OLIVEIRA, 2009).
Figura 3. Super Mario World, exemplo de um jogo 2D
Fonte: Pedro (2011)
Os jogos 3D sugiram como uma alternativa ao 2D. Estes jogos conseguem transmitir
muitas vezes uma imersão maior ao jogador por utilizar três dimensões de espaço, semelhante
ao mundo real. Com este tipo de representação é possível criar jogos onde o ambiente é
desvinculado da tela e o ponto de vista do jogador pode viajar por ele. Um exemplo disso são
os jogos em primeira pessoa, onde o jogador não tem uma representação da personagem na
tela, ele enxerga o ambiente do jogo como se estivesse olhando através da visão da
25
personagem. Uma das desvantagens do 3D é o aumento de complexidade para a criação e
execução dos jogos em relação ao 2D. Os cálculos matemáticos do jogo crescem devido às
possibilidades acrescentadas com a nova dimensão. Outro processo que não existe em jogos
2D e que pode comprometer o desempenho é a conversão do ambiente, que levando em
consideração o ponto de vista do jogo naquele momento e outros fatores, deve ser
transformada em um plano antes de ser exibido na tela ao jogador (CLUA; BITTENCOURT,
2005).
Figura 4. Zelda: Skyward Sword, exemplo de um jogo 3D
Fonte: IGN (2011)
Existe um meio termo entre o 2D e o 3D, chamado de 2.5D ou pseudo-3D, que
mistura os conceitos de 2D e 3D de diferentes formas. Um modo muito comum é a utilização
de um ambiente 2D dividido em vários setores iguais, chamados tiles, como base para a
mecânica e a arte destas partes utiliza modelos tridimensionais. Existem outras formas de
2.5D, como a utilização de personagens 2D com um cenário de fundo em 3D, personagens em
3D utilizando um cenário de duas dimensões e o jogo totalmente em 3D mas com o
deslocamento restrito a duas dimensões, um exemplo é mostrado na Figura 5. Um dos
objetivos da representação 2.5D é a utilização de recursos 3D para a arte sem elevar sua
complexidade muito além da dos jogos 2D (SANTOS; SANTOS, 2009).
26
Figura 5. Street Fighter IV, exemplo de um jogo 2.5D
Fonte: IGN (2009)
O jogo projetado neste TTC utiliza o modelo de 2.5D, com um personagem e cenários
modelados em três dimensões, mas com a jogabilidade limitada a duas dimensões.
2.1.4 Programação de jogos e engines
A programação de um jogo normalmente segue uma estrutura de código, com funções
em ordens pré-definidas. Começa com a inicialização das entradas e variáveis do sistema, são
carregados os elementos gráficos e sons do jogo e se inicia o laço de repetição principal do
jogo. Diferente de outros tipos de aplicações computacionais, nos jogos é necessário que o
programa continue executando independentemente de uma ação do usuário, e este laço
continua até que seja atingida uma condição para o fim do jogo. No desenrolar do jogo, além
da verificação da condição de parada também são verificadas as entradas do usuário, e a partir
delas são realizadas as operações lógicas. Além disso, a tela é redesenhada com o novo estado
do jogo e se necessário, efeitos sonoros são reproduzidos. É comum manter as operações de
desenho do jogo separadas das operações lógicas para que estas últimas não tenham sua
velocidade comprometida pela falta de desempenho do computador. Outra prática comum é
tratar o movimento do jogo através do tempo decorrido ao invés do número de quadros
processados, fazendo com que máquinas de desempenho diferente executem o jogo de uma
forma mais uniforme (LOBÃO et al, 2010).
27
Inicializar os controladores gráficos, som e dispositivos de entrada
Carregar os recursos (conteúdo gráfico e de sons) do jogo
Iniciar o game loop. A cada repetição:
Ler a entrada de dados do usuário
Realizar os cálculos necessários (I.A, movimentos, colisão,...)
Desenhar a tela e gerar sons
Finalizar o controle de gráficos, som e entrada de dados
Liberar os recursos do jogo
Quadro 1. Pseudocódigo da estrutura do código de um jogo
Fonte: Lobão et al (2010);
Um ramo da programação muito utilizado no desenvolvimento de jogos é o uso de
scripts. As linguagens de script, diferentemente das compiladas, cujo código é transformado
em linguagem de máquina antes de ser executado, são interpretadas em tempo de execução.
Programas que utilizam scripts têm normalmente um desempenho menor que os compilados.
Por outro lado, os scripts podem ser independentes do restante do programa e podem ser
alterados sem que seja necessária a modificação dos elementos com que interagem (JARGAS,
2008).
As engines são uma forma para rápida prototipagem e um facilitador para criação de
jogos. Elas são um conjunto de ferramentas para auxiliar no processo de desenvolvimento.
Elas normalmente possuem componentes prontos para prototipagem rápida, como
personagens com controles e movimentação prontas. Normalmente já possuem física básica,
como gravidade e colisões, e também scripts de uso geral e de inteligência artificial. As
engines também normalmente possuem facilitadores para o gerenciamento de recursos de
hardware e para gerar o executável do jogo. Esta abstração faz com que muitas dessas engines
consigam exportar um mesmo projeto para diferentes plataformas, poupando ou ao menos
diminuindo o processo de conversão de plataforma do jogo criado (NAVARRO; PRADILLA;
RIOS, 2012).
O jogo foi feito utilizando uma engine que possui elementos facilitadores para a
conclusão do projeto do jogo. Para facilitar o desenvolvimento da interação entre os
elementos do jogo foram utilizadas linguagens de script reconhecidas pela engine.
28
2.1.5 Arte para jogos
A construção dos elementos artísticos de um jogo envolve a criação dos seus
elementos visuais, e este processo é dividido em diferentes tarefas. Inicialmente é feita a arte
conceitual, onde são feitos esboços do ambiente, objetos e personagens, um exemplo é
mostrado na Figura 6.
Figura 6. Exemplo de arte conceitual e arte final
Fonte: Remontti (2012)
Em jogos 2D são criados desenhos finais a partir da arte conceitual de acordo com as
proporções e o estilo do jogo. Em jogos 3D são criados modelos tridimensionais e geradas
texturas 2D que são mapeadas e aplicadas a regiões desses modelos (Figura 7). Após isso é
feita a animação de objetos não estáticos (NOVAK, 2011).
29
Figura 7. Exemplo de modelo tridimensional e suas texturas mapeadas
Os desenhos finais dos jogos em 2D, também conhecidos como sprites, podem ser
agrupados em um único arquivo de imagem, chamado de sprite sheet. Esse processo facilita o
acesso aos sprites, já que o hardware precisa carregar somente uma imagem e cada sprite
pode ser acessada somente informando sua posição e tamanho nessa imagem. Esse processo
também ajuda na composição de cenários segmentados, que são formados por diferentes
partes de imagens, como se fossem azulejos, permitindo que partes do cenário similares
possam ser exibidas sem a necessidade de carregar duas imagens. Outro uso do sprite sheet é
a criação de animação, onde todas as posições que o personagem pode assumir ficam na
mesma imagem (ver Figura 8) (NOVAK, 2011; LOBÃO et al 2010).
30
Figura 8. Exemplo de Sprite Sheet
Fonte: adaptado de GAMEMEDIA (2011)
2.1.5.1 Animação
Em ambientes 3D, após a modelagem dos objetos que representam os personagens,
são incorporados a eles estruturas que fazem o papel de ossos, elas podem ser conectadas e
formar articulações que podem ter movimento. Cada um desses ossos pode ser configurado
sobre como seu movimento irá afetar os ossos adjacentes e a área do modelo próxima a ele.
Depois desse processo é criada a linha de tempo da animação que é dividida em frames, para
cada movimento é definido o estado inicial e final dos ossos do modelo, o software de
modelagem faz a interpolação entre estes dois frames de acordo com as configurações feitas
anteriormente. Para animações simples que utilizam somente operações de movimento,
rotação e/ou escalamento, a criação de ossos não é necessária, sendo que o software consegue
fazer esse tipo de movimento sem a necessidade deles (MAESTRI, 2006).
Em jogos 2D são usadas as animações por sprites, o objeto é desenhado no seu estado
inicial, final e em posições intermediárias. No jogo esses desenhos são exibidos em sequência
31
para passar a impressão de movimento, o que define o realismo e a suavidade do movimento é
o número de imagens intermediárias, que consegue ser cada vez maior com o avanço na
tecnologia das plataformas para desenvolvimento de jogos. Em alguns jogos são feitos
modelos 3D e retiram uma representação 2D de diferentes estados da animação para
construção dos sprites (BATTAIOLA; VIEIRA; KIRA, 2004), o que comumente se chama
2.5D, um conceito intermediário entre duas e três dimensões.
2.1.6 Som
O som é muito importante em um jogo, ele ajuda a criar a atmosfera e consegue até
mesmo alterá-la. A capacidade imersiva dos sons de um jogo muitas vezes pode ser maior que
a obtida apenas pela parte gráfica, a tecnologia atual consegue, por exemplo, reproduzir com
mais veracidade o rugido de um gorila do que sua forma, movimentos e textura. Além de
auxiliar na atmosfera do jogo, os sons podem auxiliar o jogador fornecendo indicações
sonoras de seus atos (NOVAK, 2011), e em alguns jogos o som está diretamente ligado à
jogabilidade, como visto no gênero de jogos musicais (ver Seção 2.1.4.1).
2.1.6.1 Trilha sonora
A trilha sonora de um jogo é utilizada para complementar a parte visual, ela procura
ajudar o jogador a entrar na atmosfera apresentada a ele. A música passa ao jogador o que está
acontecendo no momento, mudando de uma música alegre em um momento de felicidade
para uma música de suspense quando algo inesperado está prestes a acontecer.
Diferentemente do cinema, onde a etapa de criação da trilha sonora normalmente só acontece
depois do filme gravado, nos jogos esse processo ocorre junto com o desenvolvimento. Como
no jogo não existe um caminho linear, o jogador pode fazer ações diferentes e em ordem
diferente e a trilha precisa ser adequada a essa mecânica (NOVAK, 2011).
2.1.6.2 Sonoplastia
Os efeitos sonoros são utilizados normalmente quando uma ação é feita pelo jogador
ou algo acontece no ambiente. Os efeitos podem ter o objetivo de tornar o jogo mais real,
trazendo os sons que acontecem na realidade, tornando o ambiente mais imersivo, alguns
desses sons podem ser obtidos gravando a ação no mundo real ou reproduzindo um som
semelhante. Os efeitos sonoros também são utilizados como feedback para ações do usuário,
como por exemplo ao clicar um botão. Isso, além de deixar mais clara as ações também torna
32
o jogo mais acessível a pessoas com problemas visuais (SALEN; ZIMMERMAN, 2004;
NOVAK, 2011).
2.2 Conceitos musicais
O trabalho propõe a criação de um jogo musical para o uso em aulas de execução
rítmica e apresentará trechos de partituras com sequências rítmicas a serem seguidas. Por esse
motivo alguns conceitos musicais serão abordados na fundamentação teórica, iniciando por
uma breve descrição dos elementos fundamentais da música: melodia, harmonia e ritmo.
A melodia é o conjunto sequencial de notas ao longo de uma música, essas notas
possuem variação de altura entre elas (SCHAFER, 1992). A harmonia acompanha a melodia
utilizando paralelamente diferentes sequências de notas (GUEST, 2006). O ritmo divide a
linha de tempo da música em partes menores. Ele é irregular, utilizando uma combinação de
notas e pausas de diferentes durações (SCHAFER, 1992).
Dentre os elementos melodia, harmonia e ritmo, somente o terceiro será abordado, já
que na detecção de sons de entrada não são analisadas harmonia e melodia.
2.2.1 Ritmo
O ritmo é a direção da música, acompanhando e dividindo arbitrariamente o seu fluxo.
Ele pode ser regular ou irregular, o que não está necessariamente ligado ao quão agradável ele
é aos ouvidos (SCHAFER, 1992).
O ritmo é uma divisão musical do tempo, cada espaço de tempo pode ser dividido em
partes iguais. A duração desses espaços de tempo e a sua divisão em mais ou menos partes
gera a diversidade de ritmo. A música utiliza dois ritmos fundamentais: o ritmo binário e o
ritmo ternário. O ritmo binário é a divisão de um espaço de tempo em duas partes iguais
enquanto o ternário é a divisão entre três partes iguais (POZZOLI, 1978).
2.2.2 Notação musical
Notação musical é um nome genérico utilizado pelas diferentes formas de representar
graficamente os elementos presentes na música. O sistema mais utilizado atualmente é o
sistema gráfico ocidental (esse sistema foi utilizado na fundamentação teórica e no projeto),
que combina diferentes elementos musicais para formar as partituras. A marcação do tempo
33
da música, as pausas, e principalmente as notas e suas propriedades são escritas nas partituras
juntamente com outros elementos complementares (WIKIPEDIA, 2012).
O jogo projetado neste TTC apresenta partituras na sua jogabilidade e os elementos
musicais utilizados são detalhados a seguir.
2.2.2.1 Pauta
A pauta é o conjunto de cinco linhas horizontais paralelas que formam quatro espaços
entre si, também chamada de pentagrama (Figura 9). Nas linhas e espaços da pauta são
representados os sons, sendo que a altura de cada som está relacionada com a altura em que
ele foi escrito na pauta. As posições mais altas da pauta representam os sons mais agudos,
enquanto as mais baixas representam os sons mais graves. No caso de um som ser muito
agudo ou grave para ser representado na pauta são criados linhas e espaços suplementares
(LACERDA, 1961).
2.2.2.2 Compasso
Para criar as divisões do ritmo inicialmente é preciso especificar o espaço de tempo
primário, uma sequência de períodos de mesma duração com início e fim perceptíveis ao
ouvido. Quando esses períodos são divididos eles geram diferentes momentos. A primeira
fração do período de tempo da a impressão de ser mais forte ao ouvido pois saí de um estado
de repouso, e é chamado de acento forte, enquanto as partes restantes estão em estado de
movimento e são chamadas de acento fraco. Na notação musical tanto acentos fortes quanto
fracos tem a mesma representação e para fazer a distinção antes de todo acento forte é
colocada uma linha de divisão vertical. O espaço de tempo representado entre duas dessas
linhas é um compasso. A Figura 9 demonstra um trecho de partitura sem notas divido em
cinco compassos (POZZOLI, 1978).
Figura 9. Trecho de partitura demonstrando a pauta e dividido em cinco compassos
2.2.2.3 Tempo musical
34
As representações das divisões de duração dos sons e silêncios dentro de um compasso
são denominadas de tempos. Assim, um compasso de dois tempos, por exemplo, possui entre
duas linhas de divisão dois momentos com a mesma duração, sendo que o primeiro é forte e o
segundo fraco. Cada tempo pode ser dividido em espaços com duração mais breves do que
eles, essa divisão para ser distinguida da primeira é chamada de subdivisão. Essas subdivisões
também são divididas em acentos fortes e fracos, mantendo no compasso um acento forte
principal, mas podendo ter vários secundários. É valido afirmar que o resultado dessas
subdivisões pode ser novamente dividido em períodos mais breves, e o resultado disto
dividido em períodos ainda mais breves, podendo seguir nesta linha até o infinito (POZZOLI,
1978).
2.2.2.4 Figuras musicais e suas durações
Os tempos e suas divisões utilizam figuras musicais para representar as notas musicais
e as pausas, elas possuem variações dependendo da duração do som ou silêncio. Como
mostrado na figura 10, a nota com duração mais longa é representada pela imagem da
semibreve e partindo dela cada nota seguinte corresponde a um som com metade da duração
da anterior. As pausas são silêncios na música, que podem ter durações variadas e possuem
um esquema de representação semelhante ao utilizados pelas notas (Figura 9). Na forma de
notação mais comum cada tempo do compasso é representado pela figura semínima
(LACERDA, 1961).
35
Figura 10. Representação visual e nome das durações de notas e pausas
Fonte: Idrani (2012)
2.2.3 Execução Rítmica
A execução rítmica, ou solfejo rítmico, é praticada em aulas de cursos de Música. Ela
é praticada através de exercícios onde os alunos devem ler trechos de partituras musicais e
executar o ritmo descrito reproduzindo sons utilizando instrumentos, batendo os pés, com a
voz ou utilizando a batida de palmas. A partitura também pode ser executada por um
professor e o aluno em seguida tenta reproduzir o que foi ouvido. O objetivo deste exercício é
melhorar a percepção rítmica e a leitura de partituras do aluno (PRINCE, 1993). Existem
muitos livros que trazem exercícios de execução rítmica para serem praticados pelos alunos,
como é caso de Prince (1993) e Pozzoli (1978).
2.3 Trabalhos Similares
Esta parte do trabalho apresenta os trabalhos relacionados com o proposto pelo TTC.
Com a escassez de trabalhos acadêmicos na área são apresentados também alguns produtos
comerciais que possuem alguma conexão com o presente trabalho. Eles são divididos em
36
diferentes áreas, procurando trabalhos que utilizem o microfone como mecanismo de
interação, aprendizado em jogos musicais, jogos que utilizam ritmo e jogos do gênero runner.
2.3.1 Só Soprando
Só Soprando é um jogo que propõe a interação somente com a utilização do
microfone. Ele busca proporcionar ao público com deficiência de coordenação motora, que
não consegue utilizar meios comuns de interação, a experiência de jogar utilizando somente o
sopro. O jogo inicia com um balão em um cenário com vários obstáculos em seu caminho,
quando o jogador sopra o balão sobe e quando ele para de soprar o balão começa a cair. O
objetivo do usuário é desviar de todos os obstáculos regulando a altura do balão. Esse jogo
não possui características, como pontuação e níveis de dificuldade, já que ele não procura ter
todas as características de um jogo, seu principal objetivo é o de avaliar a utilização do
microfone em jogos de acessibilidade (FAVA, 2008). Uma imagem do jogo pode ser visto na
Figura 11.
A similaridade deste jogo com o trabalho proposto é a utilização do microfone como
mecanismo de interação, mesmo tendo focos diferentes ambos procuram proporcionar ao
jogador uma experiência diferente utilizando o microfone.
Figura 11. Imagem do jogo Só Soprando
Fonte: Fava (2008)
37
2.3.2 Rainbow Strings
Rainbow Strings é a proposta de um jogo em que o jogador deve acompanhar as notas
de uma música de violino, para diversão ou aprendizado. O jogo poderá ser jogado através do
teclado e também de um violino real. O modo lúdico possui três níveis de dificuldade onde
nos mais fáceis ele subtrai algumas notas trazendo ao jogador uma versão simplificada da
música. No modo de estudo o jogo apresenta a possibilidade de música e exercícios, onde o
jogo apresenta ao usuário uma partitura a ser seguida. Em ambos os modos o jogo analisa o
nível de acerto do jogador pela proximidade da nota tocada com a esperada para determinar o
desempenho conseguido (VIANNA, 2010). Um protótipo da tela do jogo pode ser visto na
Figura 12.
A similaridade deste projeto com o trabalho proposto é a utilização de um jogo para
fins de aprendizado em música, ambos apresentam um partitura ao jogador e buscam observar
o seu desempenho de uma forma lúdica.
Figura 12. Protótipo de tela do jogo Rainbow Strings
Fonte: Vianna (2010)
38
2.3.3 Patapon
O jogo Patapon (SONY, 2011) foi lançado em 2007 e já possui duas sequências, ele
transporta o jogador para uma tribo de seres chamados Patapons e tem como objetivo a
sobrevivência desse grupo, levando o jogador a batalhas contra exércitos adversários,
monstros ou animais de caça. Para participar destas batalhas o jogador tem a sua disposição
quatro tambores, que são acionados utilizando diferentes botões do controle do videogame.
Cada comando possui uma sequência lógica de botões, por exemplo, para atacar o jogador
deve pressionar três vezes o botão correspondente ao tambor ‘pata’ e uma vez o
correspondente ao tambor ‘pon’, gerando a sequência ‘pata pata pata pon’. O jogo apresenta
uma batida rítmica de fundo que deve ser seguida pelo jogador. A sequência de comando,
além de conter os tambores corretos deve ser executada no ritmo certo e caso a pausa esteja
correta entre dois comandos, rende uma vantagem extra. Uma imagem do jogo pode ser vista
na Figura 13.
Este jogo assim como o trabalho proposto neste TTC apresenta o ritmo como fator
determinante na jogabilidade, a diferença é que enquanto o Patapon utiliza diferentes botões
em um ritmo pré-determinado, o jogo proposto neste TTC traz um único tipo de entrada, a
execução de sons, e um ritmo variado, representado por uma partitura.
Figura 13. Tela do jogo Patapon
Fonte: Grimjaw (2009)
39
2.3.4 Rythm Heaven Fever
O jogo Rithm Heaven Fever foi lançado em 2012 pela Nintendo. Ele é uma coletânea
com mais de cinquenta minigames utilizando diferentes temáticas. O jogo possui somente
duas formas de comando: pressionar um botão ou segurar dois botões simultaneamente. Cada
minigame pode utilizar um dos comandos ou ambos, eles apresentam uma situação ao jogador
e os elementos do cenário, junto com sua movimentação e o som que produzem, transmitem
ao jogador um ritmo a ser seguido para a execução das ações. Um exemplo é o minigame
onde uma mão lança ervilhas sobre a mesa que devem ser capturadas pelo jogador com um
garfo. O movimento da mão junto com o som que é produzido pelo disparo e o movimento da
ervilha dão ao jogador a dica do ritmo que os botões devem ser pressionados (NINTENDO,
2012). A Figura 14 mostra a tela de um dos minigames do jogo.
Este jogo é bastante similar ao trabalho proposto trazendo pouca variação de interação
e uma grande variação de ritmo, as principais diferenças são a não utilização do microfone e o
objetivo unicamente para entretenimento.
Figura 14. Minigame do jogo Rythm Heaven Fever
Fonte: Nintendo Everything (2012)
2.3.5 BIT.TRIP RUNNER
BIT.TRIP RUNNER é um jogo criado em 2010 pela Gaijin Games e traz um
personagem que corre através de um cenário ultrapassando diversos obstáculos e coletando
itens para melhorar sua pontuação. O personagem está em constante movimento e o jogador
40
deve utilizar diferentes comandos para chegar ao fim do nível com o maior número de pontos
possível, sendo que os comandos vão sendo desbloqueados ao decorrer das fases. O jogo
possui uma música de fundo cujo ritmo se encaixa com o som produzido pelos obstáculos e
itens alcançados. Esse ritmo não é fator determinante na jogabilidade como nos jogos citados
anteriormente, mas serve de dica e incentivo para que o jogador consiga chegar ao fim da fase
(GAIJIN, 2010). Uma imagem do jogo pode ser vista na Figura 15.
Esta foi a principal inspiração para a criação da mecânica do jogo do projeto deste
TTC. O jogo utiliza elementos muito parecidos com os que serão apresentados no TTC, mas
utiliza uma forma de interação diferente e tem como objetivo somente o entretenimento.
Figura 15. Imagem do jogo BIT.TRIP RUNNER
Fonte: Kanedags (2010)
2.3.6 Quadro comparativo dos trabalhos similares
O Quadro 2 mostra uma comparação entre os trabalhos similares pesquisados e o
trabalho proposto em três quesitos: O mecanismo utilizando para a interação do jogador,
como a música é utilizada no jogo e o feedback que o jogo proporciona para o jogador
compreender o ritmo.
Jogo Mecanismo de interação
Utilização da Música Feedback Ritmico
Só Soprando Microfone (Sopro) Não utiliza Não utiliza
41
Rainbow Strings Teclado ou Violino
Reproduz músicas e exibe as notas para serem reproduzidas pelo jogador
As notas percorrem a tela e devem ser tocadas quando passam por um ponto específico
Patapon Joystick
Utiliza música para sinalizar sucesso ou falha do jogador
Uma margem branca pulsa em volta da tela do jogo no ritmo que deve ser seguido
Rythm Heaven Fever Joystick Não utiliza
Cada minigame utiliza um contexto diferente de sons e imagens sinalizando o ritmo
BIT.TRIP RUNNER Teclado
Utiliza uma música de fundo que é complementada pelos sons dos obstáculos
O jogo emite sons diferentes para cada obstáculo no ritmo da música de fundo
Jogo proposto no TTC
Microfone (Palma) ou toque na tela
A música é utilizada para definir os diferentes obstáculos do jogo
É mostrada uma partitura e é reproduzida uma sequencia de sons no ritmo esperado. Depois um som diferente indica o momento do jogador executar os comandos.
Quadro 2. Quadro comparativo de trabalhos similares
42
3 DESENVOLVIMENTO
Este capitulo tem como objetivo descrever os processos utilizados na modelagem e
desenvolvimento do projeto do TTC. O objetivo do projeto foi o desenvolvimento de um jogo
rítmico que utiliza como mecanismo de entrada a detecção de sons pelo microfone. Alunos de
música podem utiliza-lo como uma ferramenta de auxilio no aprendizado de execução rítmica.
3.1 Análise de tecnologias para desenvolvimento do jogo
Inicialmente se pensou em fazer o jogo para ser executado através da internet, devido
a facilidade de distribuição e a flexibilidade, pois não seria necessária a instalação de arquivos
para conseguir jogá-lo. Foram pré-selecionadas três alternativas de tecnologias utilizando
como critérios a familiaridade do autor do TTC com ambiente de desenvolvimento e a
quantidade de informação disponível na internet e a plataforma web.
A primeira tecnologia analisada foi a HTML5 com Javascript, já que a sua utilização
está crescendo, como por exemplo, pelo Youtube ao abandonar os players em Flash
(MORENO, 2011), e isso está gerando uma comunidade a sua volta que cria conteúdo e pode
ser usada de apoio para tirar dúvidas. A respeito do áudio existem algumas alternativas, umas
com bons recursos para este TTC, tais como a existência de funções que utilizam o ritmo
como um parâmetro de entrada. O grande problema desta tecnologia está relacionado com a
utilização do microfone. A captura de áudio, normalmente acontece na forma de gravação de
um arquivo, sem que se possa ter um controle do que está acontecendo com o microfone até a
gravação terminar.
A segunda tecnologia analisada foi a plataforma Flash, ainda possui ampla utilização
no mercado e tem o seu plugin para reprodução em navegadores de internet. Esta plataforma
possui uma grande comunidade e uma documentação on-line. Porém o Flash foi
descontinuado em algumas plataformas, como Android, iOS e Linux e mesmo no Windows
ele vem perdendo espaço para a HTML5, reconhecido pela própria Adobe (WINOKUR,
2011), e o Unity3D. Esta plataforma possui uma biblioteca de áudio que consegue reproduzir
sons e o áudio do microfone pode ser monitorado em tempo real, o que é uma característica
fundamental para o jogo que foi desenvolvido neste TTC.
43
A terceira tecnologia analisada foi a Unity3D, uma engine voltada para a criação de
games e que tem como ponto forte a capacidade de gerar o jogo produzido para diferentes
plataformas. Os recursos de saída de som trazem uma forma organizada para edição de
parâmetros de scripts básicos já prontos. Quanto a parte de entrada de áudio na plataforma
web, esta tecnologia se comporta de uma forma parecida com a HTML5, consegue gravar
sons, mas não permite que o programador saiba o que está acontecendo com o microfone em
tempo real, pois é necessário terminar a gravação para manipular o que foi gravado.
Das três opções a única viável para o trabalho seria a segunda, a tecnologia Flash, mas
existe o receio em se utilizar uma plataforma que está perdendo espaço no mercado e pode se
tornar obsoleta em breve. Com isso, surgiu a ideia de uma nova alternativa que será
empregada: utilizar a Unity3D, mas modificar a plataforma em que o jogo será gerado. Ao
invés de utilizar a internet, agora o jogo será construído para a plataforma Android,
plataforma que abrange o maior número de aparelhos móveis. O monitoramento do microfone
para essa plataforma é possível, já que o Unity3D consegue acessar classes nativas do
Android que lidam com este dispositivo de entrada. Todos os celulares e a maioria do tablets
já vêm com microfone embutido, o que garante o funcionamento do jogo que será
desenvolvido neste TTC em tais dispositivos.
3.2 Ferramentas utilizadas
O jogo foi criado utilizando a engine Unity3D como base, ela auxilia na organização
dos diversos elementos do jogo, na criação de objetos de formas básicas, como cubos e
esferas, e também traz um conjunto de bibliotecas para facilitar o uso de alguns recursos,
como a interface com o usuário, a reprodução de sons, etc.
Para a programação foi utilizada a linguagem de programação C# Script, que integrada
com a Unity3D proporciona uma maior facilidade na manipulação e modificação de objetos
dentro do jogo. A engine utiliza uma metodologia baseada em componentes, que são
anexados a objetos fornecendo-lhes funcionalidades. Os scripts trabalham desta forma, eles
são agregados a objetos, e além de gerar novas propriedades e comportamentos a eles com
suas variáveis e funções, também têm a capacidade de manipular outros componentes desses
objetos e os modificadores de posição, rotação e escalonamento no cenário. Scripts associados
a objetos também herdam funções básicas de controle de jogo que podem ser sobrecarregadas,
44
elas ajudam a trabalhar com o loop de eventos do jogo, o tratamento de colisões entre objetos
e a mudança de estados do objeto.
Um exemplo do funcionamento dos scripts é exibido no Quadro 3, ele mostra a função
de movimentação e animação do personagem principal do jogo. A função FixedUpdate vem
da própria Unity3D e junto com a função Update são chamadas em loop. A diferença entre
elas é que Update é chamada baseada numa taxa de frames variável, sofrendo alterações de
tempo dependendo do que está acontecendo no jogo. A função FixedUpdate, por outro lado, é
chamada de acordo com uma taxa fixa de frames, sempre mantendo constante o tempo entre
as chamadas, tornando-a preferível para o uso em funções que necessitem de uma mudança
uniforme. O código do Quadro 3 inicialmente movimenta o objeto do personagem no eixo X,
em seguida são utilizados incrementos e verificações baseados na velocidade do personagem
e na quantidade de frames passados para definir qual imagem da lista de posições(Figura 16)
será utilizada na textura do objeto. Essas imagens são modificadas de forma sequencial e em
loop para simular o movimento do personagem.
Figura 16. Sprite Sheet com as posições do personagem
45
Quadro 3. Movimentação do personagem
Alguns componentes importantes utilizados no jogo são: As texturas, que armazenam
imagens e podem ser aplicadas a objetos 3D e a interface com o usuário; As fontes de
reprodução de áudio, que além de reproduzir sons também podem modificar propriedades
como volume, duração e localização no espaço, modificando a intensidade e direção do som
de acordo com a posição da fonte em relação a câmera do jogo; o controle do microfone que
consegue captar os sons a partir do dispositivo que esta sendo utilizado; os skyboxes, que
preenchem o fundo do cenário com imagens de horizonte; botões e outros elementos da GUI
(Graphical User Interface) para a interação com o usuário.
Também foram utilizadas as ferramentas PaintBrush e GIMP para a criação e
manipulação das imagens que foram aplicadas como texturas nos objetos das fases.
3.3 Detecção de som
Dentro da engine Unity3D existem elementos facilitadores para manipulação de áudio,
os utilizados neste projeto são: o controle do microfone, que obtém as informações captadas
pelo microfone em tempo real e a fonte de reprodução de áudio, usada para reproduzir sons
dentro do jogo. O controle do microfone não oferece acesso ao áudio que está sendo
capturado em tempo real, enquanto a fonte de reprodução tem acesso do que está sendo
reproduzido a qualquer momento. Por conta disso foi utilizada uma fonte de saída de áudio, e
ao invés de utilizar um arquivo de som para ser reproduzido, a entrada do microfone é
direcionada para a saída de áudio em tempo real. Depois disso o volume da reprodução do
46
microfone é reduzido a zero, pois a reprodução do microfone poderia causar problemas
confundindo o jogador ou se mesclando as execuções de sons interferindo no jogo.
Quando o jogo começa, caso o jogador estiver com a opção de entrada pelo microfone
ativada, uma tela para calibragem do microfone surge, essa calibragem é dividida em quatro
etapas: (1) A captura do som ambiente sem interferência, (2) a verificação de presença de
ruído de fundo, (3) a captura da entrada do usuário, e (4) a comparação de efetividade da
entrada capturada em relação ao som ambiente.
Inicialmente verifica-se o som ambiente para detectar se há grande variação na intensidade de
ruído, caso o nível de variação esteja dentro do intervalo aceitável estabelecido inicia-se a
segunda etapa do processo. O intervalo de variação foi estabelecido a partir diferentes testes
realizados com ambiente em silencio e com presença de ruído. Ambientes com um volume de
ruído muito baixo mas que ainda apresenta uma variação acima do limite são rejeitados, pois
mesmo não se sobressaindo a intensidade do som das entradas do jogador essa variação
apresenta pequenos picos de áudio que podem ser interpretados como entradas. Após a
calibragem do som ambiente inicia-se uma nova captura, só que esperando que o jogador
reproduza o som que irá utilizar como entrada, para isso é requisitado um número de entradas
que deve ser executado.
Depois da captura, são recuperadas amostras de intensidade áudio a cada intervalo de
frames, esses valores são conseguidos através da função GetOutputData() da própria Unity3D,
ela espera um array de tamanho variável e o retorna preenchido com a intensidade do som
nos últimos milissegundos passados, quanto maior o tamanho do array, maior a duração do
período retornado. São somados o quadrado dos valores de retorno da função e divididos pela
quantidade de elementos no array, em seguida é retirada a raiz quadrada desse número para
conseguir o valor em RMS(Root mean square) e depois, com uma função logarítmica, esse
resultado é convertido para decibéis, que é utilizado em todos os valores de medida de
intensidade de som do jogo.
Ao final do processo, que aciona a função GetOutputData() um grande número de
vezes, gera-se uma lista de médias contendo a intensidade do som durante todo o intervalo de
captura, que tem a duração de cinco segundos. Os elementos da lista retornada chegam
organizados pelo tempo em que foram capturados e cada um deles é comparado com o limiar
de captura, que é a soma do limite de variação, estipulado baseado em testes envolvendo
diferentes ambientes, e a média do valor de intensidade do ruído ambiente recuperado
anteriormente. Depois disso cada elemento é comparado com o valor posterior a ele na linha
temporal para verificar mudanças de intensidade. Ao final das comparações são então
47
identificados os picos de áudio, uma sequência continua de elementos que ultrapassam o
limiar de captura. Quando um elemento ultrapassa o limite de captura é iniciado o registro do
pico, e são comparados os valores seguintes da lista enquanto eles estiverem acima do limiar,
quando volta a ser verificado um elemento abaixo do limiar o registro daquele pico é
finalizado. A verificação é realizada em todos os elementos da lista e os picos identificados
são registrados para verificação no final do processo.
Esses picos de áudio são distúrbios do som ambiente e são considerados como sendo
as entradas emitidas pelo usuário. Caso o número de picos identificados seja igual ao número
de entradas requisitados para que o jogador reproduza, ele fica apto a iniciar o jogo utilizando
o microfone como entrada, caso contrário ele decide se refaz a calibragem ou inicia o jogo
utilizando toques de tela. O limiar de comparação é utilizado posteriormente para definir as
entradas do jogador na execução dos obstáculos.
Uma representação dessa captura pode ser vista na Figura 17, a linha azul representa a
intensidade de som ambiente capturado e a linha verde o limiar de captura. A cada intervalo
de tempo é retirada a média de intensidade das amostras de som capturadas pelo microfone,
representado pela linha vermelha, e comparado com o limiar. Na imagem são identificados
dois picos de áudio, um com duração de dois elementos da amostra e outro com duração três,
eles representam um grande aumento de intensidade do som ambiente que depois retorna ao
normal, fazendo com que provavelmente signifiquem entradas reproduzidas pelo usuário.
Figura 17. Exemplo do processo de captura de áudio
48
3.4 Interação do usuário Todos os menus do jogo são ativados através de botões utilizando o toque na tela, e a
interação com os obstáculos dentro dos níveis pode ocorrer também com a utilização do
microfone que é calibrado como citado na seção 3.2. Quando o personagem se aproxima de
um obstáculo uma partitura com uma sequência rítmica é exibida, e opcionalmente também
uma reprodução sonora dessa sequência, que condizem com os tempos do ritmo da música de
fundo.
Em seguida é iniciado o processo de captura das entradas, onde o jogador deve iniciar
a execução de sons. O processo de registro de uma entrada é similar ao feito na calibragem,
procurando picos de áudio que ultrapassem o limiar de captura. Cada pico localizado é
considerado como uma entrada e o tempo do primeiro elemento desse pico é definido como
sendo o momento de inicio da entrada que é utilizado para as verificações.
Para o processo de captura o jogador tem o tempo total de duração da execução de
todas as notas da sequência mais uma margem de segurança, para cobrir as possíveis
diferenças de tempo entre a execução da nota pelo jogo e a entrada do jogador. O tempo
decorrido entre o inicio da captura e a primeira entrada do jogador é descartado,
desconsiderando o delay do microfone e o atraso da reação do jogador. Com isso o tempo da
primeira entrada é marcado como zero e as seguintes como o tempo relativo entre elas e a
primeira.
A Figura 18 demonstra o este processo, a linha azul demonstra os tempos computados
inicialmente, sendo o tempo real de entrada do jogador marcado pelos traços vermelhos. A
linha verde representa os tempos de entrada depois de tratados, no exemplo da imagem, ela
elimina os 100 milissegundos que o jogador demorou para iniciar a sequência e o delay do
microfone, pode-se observar que o tempo das entradas em relação ao início da contagem foi
adiantado, mas a distância relativa entre elas, que é o que realmente interessa, se manteve
igual.
49
Figura 18. Exemplo do tratamento de entradas
Existe um atraso entre o som produzido pelo usuário e o seu processamento pelo
microfone, a quantidade desse atraso pode variar dependendo do dispositivo que está
reproduzindo o jogo ou a quantidade de elementos presentes no jogo, o que causa uma
diferença de tempo entre a entrada do jogador e a sua detecção dentro do jogo. Marcar o
início da sequência com a primeira entrada minimiza esse problema, que afeta principalmente
o tempo da primeira detecção, pois mesmo o atraso variando entre diferentes ambientes ele é
quase constante em um mesmo obstáculo, atrasando a primeira entrada, mas mantendo a
diferença entre elas correta. Além disso, essa abordagem de detecção de início de sequência
elimina a necessidade de determinar um tempo exato para início da execução de entradas, e
foca no tempo relativo a partir da primeira.
Ao final da captura de cada obstáculo, o tempo das entradas do jogador que foram
registradas são armazenadas em ordem crescente de tempo em uma lista, que é utilizada no
processo de verificação descrito a seguir.
50
3.5 Verificação de entrada
Ao final da captura de entrada do jogador inicia-se a comparação com o que era
esperado para o acerto. Inicialmente é verificado se o número de notas esperadas é igual a
quantidade de entradas do jogador. Caso isso seja confirmado, uma lista similar a de entradas
é gerada a partir da sequência do obstáculo, adicionando os tempos esperados para cada nota,
então o tempo de representação de cada elemento da lista de entradas é comparado com seu
correspondente da nova lista. A comparação gera uma nova lista contendo a diferença de
tempo entre cada nota esperada e cada entrada, que depois de gerada tem o valor de seus itens
comparados com um valor máximo de erro, que é a diferença de tempo que pode existir entre
a entrada do jogador e o som que era esperado para ser considerado como acerto. Esse valor
diminui a cada nível para aumentar a dificuldade do jogo.
A Figura 19 traz o exemplo do que pode ocorrer em um obstáculo. A sequência
associada a ele é representada pela partitura do topo da imagem. Na cor azul estão os tempos
em relação ao início da sequência, em milissegundos, em que cada nota esperada será
reproduzida. Na cor verde está o tempo em que o jogador executou as entradas, notando que a
primeira entrada é sempre marcada como zero milissegundos pois desconsiderada o delay e o
atraso de resposta como citado anteriormente. Na cor vermelha está o erro entre o som
esperado e a entrada do jogador. Caso todos erros estejam dentro do limite de erro o obstáculo
é superado, do contrário o jogador retorna ao último creckpoint ou ao inicio da fase. No caso
da Figura 19, se o limite de erro fosse de no máximo 150 milissegundos, o teste passaria nas
três primeiras entradas, mas falharia na última, fazendo o jogador errar o obstáculo.
Independente do acertar ou errar a lista de diferença de tempos é armazenada para gerar um
relatório de desempenho no final da fase.
51
Figura 19. Exemplo de entradas em uma sequência
3.6 Modificadores de jogabilidade
Existem modificares dentro do jogo que mudam o comportamento dos obstáculos, os
seus efeitos estão descritos no GDD (Apêndice A, Seção 2.7.4). Eles podem facilitar ou
dificultar o progresso do jogador e podem surgir sempre que um obstáculo é executado sem
um modificador ativo e o seu efeito dura até o fim do desafio seguinte. Ao finalizar a jogada
de um obstáculo sem a presença de modificadores ativos, um sorteio utilizando valores
pseudo-aleatórios é realizado. Existe a probabilidade de 50% do sorteio não causar nenhum
efeito, caso contrário, um novo modificador é atribuído, sendo ele positivo depois de um erro
e negativo depois de um acerto, procurando equilibrar a dificuldade do jogo.
3.7 Obstáculos e CheckPoints
Os checkpoints são objetos dentro do jogo que possuem uma posição e dois estados,
desativado ou ativado. Todos os checkpoints começam desativados e mudam de estado
quando são ultrapassados pelo jogador. Sempre que o jogador erra um obstáculo retorna a
posição do checkpoint ativado com a posição mais avançada.
52
Os obstáculos possuem uma posição, o número de compassos da partitura associada a
ele, o nível de dificuldade dessa partitura e também dois estados, aguardando e ultrapassado.
No inicio de cada nível são geradas partituras para cada um dos obstáculos de acordo com a
quantidade de compassos e dificuldades, esses valores são consultados dentro de um arquivo
XML e um elemento da lista conseguida é sorteado para ser a sequência da partitura. O
Quadro 4 mostra parte da estrutura do XML, as sequências numéricas são a representação das
notas, cada número maior que zero representa uma nota e a quantidade de tempos musicais
dela e o zero representa um tempo de pausa. Se, por exemplo, a sequência sorteada for a
“484” será gerada uma partitura de três notas, a primeira e a terceira de quatro tempos e a
segunda de 8 tempos (Figura 20). A lista de verificação do obstáculo conterá três elementos,
com um intervalo entre o primeiro e o segundo igual a quatro vezes a duração do tempo
musical e oito vezes entre o segundo e o terceiro. A duração de cada tempo é pré definida e
foi baseada na batida de fundo que provê o ritmo do jogo. Essa quantidade de tempos só tem
efeito para a representação da sequência de notas, pois não são verificadas as durações das
entradas do jogador. Todos as sequências são retiradas dos exercícios apresentados no livro
Guia teórico-prático para o ensino do ditado musical do autor Pozzoli(1978).
Quadro 4. Estrutura do XML de partituras
53
Figura 20. Exemplo de partitura
O obstáculo é disparado em um ponto calculado a partir do número de compassos da
partitura e o tempo de duração de cada nota, para que, baseado no movimento constante do
personagem, ele tenha tempo de analisar a partitura e executar a sequencia antes que a posição
do obstáculo seja alcançada (Figura 21).
Figura 21. Captura de tela do jogo no momento em que um obstáculo é disparado
3.8 Testes
Os testes do jogo foram realizados com 10 pessoas ligadas a área de música, incluindo
professores, músicos, alunos e ex-alunos de música. Os dispositivos utilizados para os testes
foram um iPhone 4S e um iPod 4 com sistema iOS 6 e um Samsung Galaxy SIII com Android
4. Os ambientes onde os testes ocorreram foram na UNIVALI e no IMCARTI (Instituto de
Música, Canto e Arte de Itajaí). As sessões de jogo duraram entre 10 e 15 minutos e foram
54
feitas separadamente. Após a realização do teste um questionário foi respondido (Apêndice C)
, as suas perguntas estão divididas em duas categorias principais: as de aspecto geral do jogo;
e as relativas ao ensino de ritmo.
Seis perguntas do questionário foram realizadas utilizando uma escala que a pior
qualificação é Muito Ruim, e em sequência até a melhor existe: Ruim, Normal, Bom e Muito
Bom. A opinião dos testadores em relação a história e os efeitos sonoros ficaram em sua
maioria com Bom, com algumas opiniões em Muito Bom e Normal. O fato do jogo ser para
dispositivos móveis e a apresentação das informações do relatório no fim da fase tiveram a
maioria das opiniões em Muito Bom, com opiniões em Bom e uma em normal. A opinião
sobre o uso do microfone e os gráficos do jogo ficaram divididos entre Bom e Muito Bom. A
Tabela 1 mostra a relação entre cada uma dessas seis perguntas e o número de pessoas que
assinalou cada opção.
Pergunta Muito Ruim Ruim Normal Bom
Muito Bom
O que achou da história do jogo? 0 0 1 6 3 O que achou dos gráficos do jogo? 0 0 1 5 4 O que achou dos efeitos sonoros do jogo? 0 0 1 6 3 O que achou de o jogo ser para celulares? 0 0 1 2 7 O que achou do uso do microfone? 0 0 2 4 4 O que achou das informações apresentadas no final da fase? 0 0 1 3 6
Tabela 1. Número de respostas em cada opção
Sobre a apresentação das partituras, 8 dos testadores acharam ela muito adequada,
enquanto uma pessoa colocou como pouco adequada e outra não respondeu a questão. O nível
de dificuldade do jogo foi considerado bom por 7 pessoas e difícil pelas outras 3.
Nove testadores consideraram que o jogo pode auxiliar no aprendizado de ritmo, que o
uso do microfone colabora com o aprendizado e utilizaria o jogo em atividades de
aprendizado. Uma pessoa considerou que jogo pode colaborar pouco o aprendizado de ritmo,
que o microfone não colabora e que talvez utilizasse em atividades de aprendizado de ritmo.
55
Em uma escala de 1 a 10 o jogo recebeu uma nota média de 8,4. Duas pessoas
deixaram sugestões de melhoria para o jogo. A primeira sugeriu que houvesse a oportunidade
de corrigir um erro feito na metade de partitura e a segunda a possibilidade de retirar a música
de fundo que pode confundir o ritmo dos exercícios.
Além de preencher os formulários, principalmente os professores de violão e bateria,
reforçaram a sua opinião de que o jogo é muito interessante para o aprendizado de ritmo, e
que mesmo sem utilizar o microfone, o movimento do toque na tela já ajuda na associação do
ritmo, e que o feedback que o jogo proporciona auxilia a correção de erros do aluno.
A única pessoa que não achou que o jogo fosse muito útil para o aprendizado era uma
aluna iniciante, e mostrou muita dificuldade para executar o jogo. Isso demonstra que o jogo
pode não ser aconselhável para pessoas que não possuem conhecimento de música.
As pessoas que jogaram mostraram diferentes graus de competência ao jogar os níveis,
sendo que todas conseguiram executar as partitura da primeira fase, a partir do segundo
cenário algumas demonstraram dificuldades em avançar no jogo, e no terceiro cenário apenas
3 conseguiram avançar, sendo duas delas professores
.
56
4 CONCLUSÕES
Foram feitas pesquisas de trabalhos similares tanto no meio acadêmico quanto entre
produtos comercias. A maior parte dos trabalhos tem familiaridade somente com uma parte do
projeto, mas cada um colaborou na construção do projeto do TTC.
A pesquisa sobre os conceitos musicais foi muito importante para o entendimento do
funcionamento do jogo e sua utilização nos exercícios de execução rítmica. O foco da
pesquisa foi principalmente a notação musical, para o entendimento dos trechos de partitura
que foram apresentados no jogo.
A análise de ferramentas para criação do jogo, junto com a fundamentação dos
aspectos de desenvolvimento, foi importante para a definição das tecnologias que foram
utilizadas e como o processo de criação foi organizado durante o TTC II.
A criação do GDD foi de grande importância durante o TTC II. Todos os principais
aspectos do jogo que foram discutidos e definidos durante o TTC I estão descritos neste
documento e ele serviu como guia no processo de desenvolvimento.
Diferente do que foi observado no TTC I, não foi necessária a utilizando de bibliotecas
específicas das plataformas móveis para utilização do microfone, conseguindo um bom
resultado utilizando a combinação de atributos de diferentes componentes presentes na
própria engine utilizada.
Os valores utilizados como comparativos de intensidade de som, como a variação
mínima ambiente e o limiar de captura, foram conseguidas através de testes e observações em
diferentes ambientes, coletando informações até chegar aos valores finais utilizados no jogo.
As imagens e sons presentes no jogo em sua maior parte não foram criadas pelo
orientando do TTC, elas vieram principalmente de repositores livres de licença na internet e
também do auxilio de amigos.
57
O processo de criação do jogo correu sem maiores problemas, apenas com algumas
divergências e limitações em relação ao carregamento das partituras e também ao processo de
representação e interpretação das sequências musicais dentro do código.
Os testes demonstraram que há interesse nas pessoas da área de música no jogo
proposto. E que talvez ele possa se mostrar uma opção para o aprendizado de ritmo.
Como trabalho futuro é possível a expansão do processamento de captura não só para
o ritmo, mas também para a melodia.
58
REFERÊNCIAS
ANDRÉ, Leonardo Moreira. Um estudo sobre a relação entre os artistas e os programadores dentro da esfera de criação de jogos. 2010. Disponível em: <http://www.cin.ufpe.br/~tg/2010-1/lma4.pdf>>. Acesso em: 5 nov. 2012. ATOMICONLINE. Temple Run screenshots. 2012. Disponível em: <http://www.gamerevolution.com/screen/temple-run/1>. Acesso em: 5 nov. 2012. BALDWIN. Mark. Game Design Document Outline. 2005. Disponível em: <http://web.ics.purdue.edu/~fwinkler/AD41700/AD41700_student_recommended_resources.pdf>. Acesso em: 5 nov. 2012. BATTAIOLA, André Luiz; VIEIRA, Tássia Vidal; KIRA Gustavo. O processo de criação gráfica de um jogo em Flash. 2004. . Disponível em: <http://projetofinal1.googlecode.com/svn/trunk/refer%C3%AAncias/material%20bruto/GameArt_2004_-_Processo_de_criacao_grafica.pdf>. Acesso em: 5 nov. 2012. CLUA, Esteban Walter Gonzalez; BITTENCOURT, João Ricardo. Desenvolvimento de jogos 3D: concepção, design e programação. 2005. Disponível em: <http://www.lbd.dcc.ufmg.br/colecoes/jai/2005/003.pdf>. Acesso em: 5 nov. 2012. EUROGAMER. Patapon. 2008. Disponível em: <http://www.eurogamer.net/articles/patapon-screenshot-gallery>. Acesso em: 5 nov. 2012. FAVA, Fabricio. Jogando com o ar: o sopro como instrumento de acessibilidade nos jogos eletrônicos. In: SIMPÓSIO BRASILEIRO DE JOGOS E ENTRETENIMENTO DIGITAL – SBGAMES, 2008, Belo Horizonte. Anais do Simpósio Brasileiro de Jogos e Entretenimento Digital. GAIJIN. BIT.TRIP RUNNER. 2010. Disponível em: <http://bittripgame.com/bittrip-runner.html>. Acesso em: 5 nov. 2012. GAMEMEDIA. Game sprite sheet. 2011. Disponível em: <http://gamemedia.wcgame.ru/game-sprite-sheet.html>. Acesso em: 5 nov. 2012. GRIMJAW. Análise: Patapon 2. 2009. Disponível em: <http://www.takeitgame.com/analises/item/5452-an%C3%A1lise-patapon-2>. Acesso em: 5 nov. 2012. GUERRA, Rafael Couto. Modelando prédios do jogo da cabanagem. 2009. Disponível em: < http://engcomp.ufpa.br/tcc/2009-s1/rafael%20couto%20guerra%20-%200800.pdf>. Acesso em: 5 nov. 2012. IDRANI, Juliana. 6A SÉRIE - horizontalidade e verticalidade do som nos elementos fundamentais da música – melodia, ritmo e harmonia. 2012. Disponível em: <http://artenoolavo.blogspot.com.br/2012/04/6a-serie-horizontalidade-e.html>. Acesso em: 5 nov. 2012.
59
IGN. Street Fighter images. 2009. Disponível em: < http://www.ign.com/images/games/street-fighter-iv-ps3-14211548/4fa6cb29cdc388ed13f2c937>. Acesso em: 5 nov. 2012. IGN. Zelda Skyward Sword images. 2011. Disponível em: < http://www.ign.com/images/games/the-legend-of-zelda-skyward-sword-wii-872155/4fa6cb70cdc388ed13f6372e >. Acesso em: 5 nov. 2012. KANEDAGS. Latest BIT.TRIP RUNNER screenshots and first Impressions from NintendoLife. 2010. Disponível em: <http://www.aksysgames.com/2010/03/04/latest-bit-trip-runner-screenshots/>. Acesso em: 5 nov. 2012. JARGAS, Aurélio Marinho. Shell script profissional. São Paulo: Novatec Editora, 2008; LACERDA, Osvaldo. Compêndio de teoria elementar da música. 14.ed. São Paulo: Ricordi Brasileira, 1961. LOBÃO, Alexandre Santos et al. XNA 3.0 para desenvolvimento de jogos no Windows, Zune e Xbox 360. Rio de Janeiro: Brasport, 2010. LOPES, Rafael Oliveira; SORIANO, Thomaz Gaio; OLIVEIRA, Yanko Gitahy. Evolução e Inovação no Mercado de Jogos Eletrônicos. 2009. Disponível em: <http://devoidgames.com/blog/downloads/Evolucao_e_Inovacao_no_Mercado_de_Jogos_Eletronicos(devoidgames.com).pdf>. Acesso em: 5 nov. 2012. MAESTRI, George. Digital character animation 3. Berkeley: New Riders, 2006. MICROSOFT. Kinect. 2012. Disponível em: <http://www.xbox.com/pt-BR/Kinect>. Acesso em: 5 nov. 2012. MORENO, João Brunelli. YouTube melhora player HTML5 e se prepara para abandonar Flash. 2008. Disponível em: < http://www.tecnoblog.net/82828/youtube-novo-player-html5/>. Acesso em: 5 nov. 2012. NAVARRO, Andres; PRADILLA, Juan Vicente; RIOS, Octavio. Open source 3D game engines for serious games modeling. 2012. Disponível em: <http://cdn.intechopen.com/pdfs/28868/InTech-Open_source_3d_game_engines_for_serious_games_modeling.pdf>. Acesso em: 5 nov. 2012. NINTENDO. WII. 2010. Disponível em: <http://wii.com/>. Acesso em: 5 nov. 2012. NINTENDO. Rythm Heaven Fever. 2012. Disponível em: <http://rhythmheavenfever.nintendo.com/>. Acesso em: 5 nov. 2012. NINTENDO EVERYTHING. Rythm Heaven Wii. 2012. Disponível em: <http://nintendoeverything.com/games/wii/rhythm-heaven-wii/>. Acesso em: 5 nov. 2012. NOVAK, Jeannie. Desenvolvimento de games. São Paulo: Cengage Learning, 2011.
60
PAULA, Bruno Campagnolo de. Adaptando e desenvolvendo jogos para uso com o Microsoft Kinect. . In: SIMPÓSIO BRASILEIRO DE JOGOS E ENTRETENIMENTO DIGITAL – SBGAMES, 2011, Salvador. Anais do Simpósio Brasileiro de Jogos e Entretenimento Digital. PEDRO, Luiz. Mario World. 2011. Disponível em: <http://allgamesonlines.blogspot.com.br/2011/09/mario-world.html >. Acesso em: 5 nov. 2012. PERUCIA, Alexandre Souza et al. Desenvolvimento de jogos eletrônicos: teoria e prática. São Paulo: Novatec Editora, 2005. PICHLMAIR, Martin; KAYALI, Fares. Levels of sound: on the principles of interactivity in music video games. 2007. Disponível em: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.190.2004&rep=rep1&type=pdf>. Acesso em: 5 de novembro de 2012. POZZOLI, Heitor. Guia teórico-prático para o ensino do ditado musical. São Paulo: Ricordi Brasileira, 1978. PRINCE, Adamo. Método prince: leitura e percepção – ritmo. 4 ed. Rio de Janeiro: Lumiar Editora, 1993. REMONTTI, Flavio. Conheça a arte de Dan Scott. . Disponível em: <http://theconceptartblog.com/2012/10/05/conheca-a-arte-de-dan-scott/>. Acesso em: 5 nov. 2012. SALEN, Katie; ZIMMERMAN, Eric. Rules of play: game design fundamentals. Cambrigde: Massachusetts Institute of Technology. 2004. SANTOS, Raul Joaquim C. dos; SANTOS, Selan Rodrigues dos. Bricking: Modelagem Tridimensional de Cenários de Jogos em Camadas. In: SIMPÓSIO BRASILEIRO DE JOGOS E ENTRETENIMENTO DIGITAL – SBGAMES, 2009, Rio de Janeiro. Anais do Simpósio Brasileiro de Jogos e Entretenimento Digital. SATO, Adriana Kei Ohashi; CARDOSO, Marcos Vinicius. Além do gênero: uma possibilidade para a classificação de jogos. In: SIMPÓSIO BRASILEIRO DE JOGOS E ENTRETENIMENTO DIGITAL – SBGAMES, 2008, Belo Horizonte. Anais do Simpósio Brasileiro de Jogos e Entretenimento Digital. SCHAFER, R. Murray. O ouvido pensante. São Paulo: UNESP, 1992. SILVA, Maycon Rocha Prado et al. Elementos de computação gráfica utilizados em jogos digitais 2D. 2009. Disponível em: <http://www.dca.fee.unicamp.br/~martino/disciplinas/ia369/trabalhos/t3g1.pdf>. Acesso em: 5 nov. 2012. SONY. Patapon 2011. Disponível em: < http://www.patapon-game.com/>. Acesso em: 5 nov. 2012.
61
SOUZA, Edmar; COUTO, Nátalia Ellery Ribeiro; DAZZI, Rudimar L.S. Coleta Seletiva: Educação ambiental com webcam game. In: SIMPÓSIO BRASILEIRO DE JOGOS E ENTRETENIMENTO DIGITAL – SBGAMES, 2009, Rio de Janeiro. Anais do Simpósio Brasileiro de Jogos e Entretenimento Digital. TAROUCO, Liane Margarida Rockenbach et al. Jogos educacionais. 2004. Disponível em: <http://www.virtual.ufc.br/cursouca/modulo_3/Jogos_Educacionais.pdf>. Acesso em: 5 nov. 2012. VIANNA, Paulo R. R. et al. Rainbow Strings: jogo para aprendizado de violino com processamento de áudio. . In: SIMPÓSIO BRASILEIRO DE JOGOS E ENTRETENIMENTO DIGITAL – SBGAMES, 2010, Florianópolis. Anais do Simpósio Brasileiro de Jogos e Entretenimento Digital. WIKIPEDIA. Notação musical. 2012. . Disponível em: <http://pt.wikipedia.org/wiki/Nota%C3%A7%C3%A3o_musical> Acesso em: 5 nov. 2012. WINOKUR, Danny. Flash to focus on PC browsing and mobile Apps; Adobe to more aggressively contribute to HTML5. 2011. . Disponível em: < http://blogs.adobe.com/conversations/2011/11/flash-focus.html> Acesso em: 5 nov. 2012.
62
GLOSSÁRIO
Compasso São blocos de tempos musicais definidos em uma partitura. Os compassos são divididos por linhas verticais.
Execução rítmica É a reprodução de uma sequência de notas musicais no ritmo correto utilizando instrumentos, palmas, batidas de pé e a voz.
Nota Musical É um período de tempo onde um som é produzido dentro de uma música.
Pausa Musical É um período de tempo de silêncio dentro de uma música.
Pauta ou Pentagrama São as cinco linhas horizontais onde as notas e pausas são escritas dentro de um partitura.
Ritmo É a divisão do fluxo da música em partes menores e de diferentes durações.
Tempo Musical É o nome dado a duração das notas e pausas e musicais.
63
APÊNDICE A. GDD
1 CABEÇALHO
1.1 Nome do Jogo Ritmo da cidade, uma corrida pela batida certa.
1.2 Autor e data Rodrigo Lyra
4 de Julho de 2013
2 VISÃO GERAL DO JOGO
2.1 Conceito do Jogo
O jogo traz a história de um menino que sonha em ser baterista e que está correndo
através da cidade em direção a uma audição. Ele está desatento pois está utilizando fones de
ouvido, na esperança de se preparar para o concurso. O Jogador utiliza a música para
controlar os braços do garoto e fazer o ritmo de suas batidas ajudá-lo a chegar com segurança
ao seu destino.
2.2 Conjunto de Recursos
2.3 Gênero
O gênero do jogo é uma mistura de um jogo de ação-plataforma, também conhecido
como runner, e um jogo musical baseado em ritmo.
2.4 Público alvo
O principal público alvo do jogo são alunos de música que estão aprendendo os
conceitos de execução rítmica.
O jogo também visa o público que procura se divertir com jogos musicais.
64
2.5 Sumário do fluxo de Jogo
O personagem corre através dos cenários da cidade e o jogador deve auxiliá-lo a
desviar dos diferentes obstáculos utilizando a reprodução de sons ritmados através de um
microfone.
2.6 Aparência do jogo
O jogo é em 2.5D, feito utilizando modelos tridimensionais mas contando com um
jogabilidade em duas dimensões.
Os gráficos do jogo contam com elementos que fogem do aspecto realista e partem
para um lado mais “cartunesco”, com personagens e cenários utilizando proporções de
tamanho diferente das reais e forte utilização de cores vivas.
2.7 Escopo do Projeto
2.7.1 Número de locais
O jogo é dividido entre 3 locais diferentes:
• O bairro onde o protagonista vive: um lugar pacato com poucas casas e muita
vegetação;
• A periferia da cidade: um lugar onde tem muita desordem e é mais
movimentada que o bairro inicial;
• O centro da cidade: muito movimentado, com vários cruzamentos. É onde a
audiência acontece.
2.7.2 Número de níveis
Cada local tem três diferentes níveis com um conjunto diferente de obstáculos. Em
cada nível há diferentes checkpoints a cada conjunto de obstáculos para salvar o progresso do
jogador.
65
2.7.3 Número de obstáculos
Cada um dos obstáculos está vinculado a um trecho de partitura e uma sequência
rítmica de sons que deverá ser reproduzido pelo jogador.
Os diferentes tipos de obstáculo serão:
• Cachorro: Um cachorro estará atrás de uma madeira solta da cerca atrás do
cenário e poderá atacar quando ele se aproxima. Se o jogador fizer a sequência
correta o personagem percutirá na cerca e a madeira solta voltará ao lugar e
impedirá o cachorro.
• Valentão: Um garoto ficará atrás da lata de lixo e poderá atacar o personagem
quando ele passar. Se o jogador fizer a sequência correta o personagem
percutirá na lata de lixo e assustará o garoto.
• Mangueira de água: Uma mulher estará limpando calçada e poderá molhar o
personagem. Se o jogador fizer a sequencia correta o personagem percutirá na
caixa de correio e chamará a atenção da mulher que irá virar a mangueira para
o outro lado.
• Vaso: Um vaso que está pendurado na janela de uma casa poderá cair na
cabeça do jogador quando ele passar por baixo. Se o jogador fizer a sequencia
correta o personagem percutirá na parede da casa e o vaso vai cair antes que o
jogador passe por baixo.
• Carro: Em um cruzamento o personagem atravessa com o semáforo aberto
distraído e um carro pode o atropelar. Se o jogador fizer a sequencia correta o
personagem percutirá na base do semáforo e o sinal irá fechar, parando o carro.
• Esquilo: Um esquilo em uma árvore pode jogar uma noz na cabeça do
personagem. Se o jogador fizer a sequencia correta o personagem percutirá n
árvore e o esquilo entrará em sua toca.
• Pichador: Um rapaz está pichando o muro e poderá jogar tinta no rosto do
personagem. Se o jogador fizer a sequencia correta o personagem percutirá na
lata de spray e ela irá estourar na mão do pichador.
66
• Construção: Uma pilha de tijolos na frente de uma construção poderá fazer
com que o jogador esbarre nela. Se o jogador fizer a sequencia correta o
personagem percutirá na pilha e ela irá cair.
2.7.4 Número de modificadores
No decorrer do jogo, dependendo da precisão com que o jogador consegue transpor os
obstáculos ele ganha modificadores, que podem auxiliar ou atrapalhar o progresso do jogador.
Os diferentes tipos de modificadores são:
• Tempo acelerado: Faz com que o jogador tenha que reproduzir a sequência
mais rapidamente.
• Tempo desacelerado: Faz com que o jogador possa reproduzir a sequência em
um espaço de tempo maior.
• Maior precisão: Faz com o jogador precisa reproduzir a sequência mais
precisamente.
• Menor precisão: Faz com que o jogador possa fazer a sequência com uma
precisão menor.
• Metade dos sons: Faz com que o jogador precise reproduzir somente metade da
sequência.
• Dobro dos sons: Faz com que o jogador precise reproduzir a sequência duas
vezes.
• Imunidade: Faz com que o jogador possa ultrapassar o obstáculo mesmo
errando.
67
3 JOGABILIDADE E MECÂNICAS
3.1 Jogabilidade
3.1.1 Progressão no Jogo
O jogo começa na casa do personagem e irá acompanhá-lo transpondo os obstáculos e
as fases até alcançar o objetivo final que é a audição.
3.1.2 Estrutura da Missão
A missão do jogo é conseguir chegar a tempo e preparado para a audição que acontece
no centro da cidade sem perder tempo, já que o personagem está atrasado e precisa treinar sua
execução rítmica no caminho.
3.1.3 Obstáculos
Os obstáculos são o centro da jogabilidade, quando o personagem se aproxima de um
obstáculo um trecho de uma partitura musical é exibido e uma sequência sonora referente a
ela é reproduzida. Em seguida um sinal sonoro diferente é tocado indicando que o jogador
deve reproduzir a sequência no ritmo apresentado anteriormente.
3.1.4 Estrutura do Desafio
O desafio do jogo é a cada obstáculo analisar a partitura e reproduzir o ritmo
apresentado no tempo correto. O jogador possui uma margem de erro para cada som
reproduzido, essa margem diminui ao decorrer das fases, tornado o jogo mais difícil.
Quanto mais próximo do tempo correto o jogador reproduz os sons, maiores são suas
chances de conseguir modificadores positivos para o próximo obstáculo, enquanto reproduzir
sons próximos do limiar da margem de erro aumenta as chances de conseguir modificadores
negativos.
3.1.5 Objetivos
O objetivo é que o personagem não chegue atrasado a sua audição, sem perder tempo
no caminho e reproduzir o ritmo corretamente para conseguir passar na audição.
68
3.1.6 Fluxo do Jogo
O jogo é linear, o jogador deve passar as fases em sequência, ele não pode pular
nenhuma, mas pode retornar para uma fase já superada. Cada fase tem diferentes obstáculos
que aparecerão um por vez. O jogo é salvo automaticamente ao fim de cada fase e também a
cada checkpoint alcançado.
3.2 Mecânica
3.2.1 Física
A física do jogo obedece às regras da física real. Ela não tem muita relevância, a sua
principal presença é na utilização da gravidade.
3.2.2 Movimento
3.2.2.1 Movimento Geral
O movimento do personagem é uma constante corrida da esquerda para a direita com a
câmera acompanhando, exceto quando é parado por algum obstáculo não ultrapassado
corretamente.
3.2.2.2 Outros Movimentos
Outros pequenos movimentos são executados pelos obstáculos, como o vaso caindo ou
o carro parando.
3.2.3 Objetos
3.2.3.1 Objetos coletáveis
Os únicos objetos coletáveis do jogo são representações de notas musicais que estarão
a intervalos regulares de obstáculos dentro de cada fase. Elas representam a evolução do
personagem dentro do jogo e marcam os checkpoints, fazendo com que quando o personagem
não consiga ultrapassar um obstáculo retorne a partir do lugar da última nota coletada.
69
3.2.3.2 Objetos móveis
Os objetos móveis estão representados em cada obstáculo e cada um tem duas formas
de movimento, a que ocorre com o acerto do usuário e a que ocorre com o erro.
3.2.4 Ações
3.2.4.1 Botões e alavancas
Os dispositivos de acionamento do jogo são os obstáculos. Eles são acionados com o
batuque das baquetas do personagem no cenário quando o jogador acerta o ritmo daquele
obstáculo.
3.2.4.2 Coletando
Os únicos itens coletáveis são os marcadores de checkpoints, eles não são acumuláveis
e somente o último coletado é válido. Quando o jogador erra ele recomeça do ponto onde o
último item foi coletado.
3.2.5 Combate
O conflito do jogo não é abordado diretamente, ele se resolve de forma indireta em
cada obstáculo dependendo do sucesso ou fracasso do jogador.
3.3 Fluxo de telas
3.3.1 Fluxograma de telas
A Figura 22 mostra o fluxo de telas presentes no jogo.
70
Figura 22. Fluxograma das telas do jogo
3.3.2 Descrição de telas
3.3.2.1 Menu Principal
Tela onde apresenta o título do jogo e os botões para avançar para as telas: Opções,
Seleção de Níveis e Ajuda (Figura 23). Todas as outras telas podem retornar ao Menu
Principal.
71
Figura 23. Tela Inicial
3.3.2.2 Opções
Tela onde o jogador pode modificar algumas preferências de jogo (ver Seção 3.4)
(Figura 24).
72
Figura 24. Tela de Opções
3.3.2.3 Ajuda
Tela onde são apresentadas informações sobre elementos presentes no jogo (Figura
25).
73
Figura 25. Tela de Ajuda
3.3.2.4 Seleção de níveis
Tela onde o jogador decide se começará um novo jogo, continuará o anterior ou
escolherá um nível já concluído anteriormente, qualquer opção levará o jogador à tela Jogo
(Figura 26).
74
Figura 26. Tela de Seleção de Níveis
3.3.2.5 Jogo
Principal tela onde o jogo se desenvolve, neste ponto ocorre a interação do jogador.
Todos os níveis pertencem a esta tela, quando o jogador ultrapassa todos os obstáculos um
relatório de como foi seu desempenho no nível é apresentado e logo em seguida é carregada a
próxima fase. Caso seja o último nível o jogador é direcionado para a tela Final. O jogador
também pode retornar a qualquer momento para a tela Seleção de Níveis. Um exemplo de
como será a tela pode ser visto na Figura 27, que mostra um obstáculo sendo executado.
75
Figura 27. Tela do jogo
3.3.2.6 Relatório
No final de cada fase é gerado um relatório com dados retirados dos obstáculos
ultrapassados pelo jogador, e esses dados são exibidos na tela. A Figura 28 mostra um
exemplo do relatório gerado, primeiramente são exibidas a quantidades de que obstáculos
foram jogados, contando-se as jogadas feitas e não obstáculos únicos, e a quantidade e
percentual de erros e acertos desse total. Depois são mostrados os valores referentes a média
de erro que as entradas do jogador tiveram em relação aos tempos esperados, é calculada a
média de erro de todos os obstáculos que tiveram o número de entradas igual ao número de
comparações, para todos os valores serem calculados em pares, depois a média somente dos
acertos e dos erros separadamente, todos esses valores são exibidos em milissegundos. Por
último é atribuída uma nota de desempenho ao jogador
• “S”: Fase completada sem errar nenhum obstáculo e com uma margem de erro inferior
a 50% do limite máximo de acerto;
• “A”: Fase completada sem errar nenhum obstáculo e com uma margem de erro
superior a 50% do limite máximo de acerto;
76
• “B”: Fase completada errando obstáculos, mas com percentual de acerto superior a
66%;
• “C”: Fase completada com o percentual de acertos entre 66% e 50%;
• “D”: Fase completada com percentual de acerto inferior a 50% e com o número de
obstáculos errados com número de entradas diferentes da sequência inferior a 3;
• “E”: Fase completada com percentual de acerto inferior a 50% e com o número de
obstáculos errados com número de entradas diferentes da sequência superior ou igual a
3;
Figura 28. Tela de Relatório
3.4 Opções de jogo
O jogador pode optar por ativar ou desativar a reprodução sonora do ritmo do
obstáculo junto com a partitura, ou desativar a partitura. Também pode trocar o uso do
microfone com a reprodução de sons pela utilização de toques na tela.
77
3.5 Salvando e Reiniciando
O jogo é salvo automaticamente no final de cada fase e também em checkpoints a cada
conjunto de obstáculos, toda vez que o jogador erra um obstáculo retorna automaticamente
para o início da fase ou para o último checkpoint alcançado.
4 SEÇÃO – DEFINIÇÕES, HISTÓRIA E PERSONAGEM
4.1 História e narrativa.
4.1.1 História
O jogo apresenta a história de James, um menino que sonha ser um baterista e quando
volta da escola descobre que tem uma audição para entrar em uma banda no centro da cidade,
o único modo para chegar lá é ir a pé. Ele corre para conseguir chegar a tempo, mas
simultaneamente utiliza seu aparelho de música com fones de ouvidos e duas baquetas para se
preparar, isso faz com que ele não preste muita atenção no caminho e algo pode impedi-lo de
chegar a tempo.
4.1.2 Elementos de Enredo
Os principais elementos do enredo são: os obstáculos da cidade que o personagem
atravessa, a audiência que está acontecendo no centro e a vontade do personagem de se tornar
baterista.
4.1.3 Progressão do Jogo
A progressão do jogo é apresentada com a saída do personagem de seu bairro e se
aprofundando na cidade até chegar ao centro.
4.1.4 Cut Scenes
4.1.4.1 Cut scene #1
4.1.4.1.1 Atores
James: O protagonista.
78
4.1.4.1.2 Descrição
Essa é a cena de início do jogo, onde apresenta o protagonista do jogo e mostra o
objetivo final.
4.1.4.1.3 Story Board
James chega em casa da escola ouvindo sua musica e brincando com duas baquetas,
quando se aproxima da casa um panfleto no chão chama sua atenção, é o anúncio de uma
audição para entrar para uma banda conhecida da cidade, ela fica muito animado até olhar a
data e hora no panfleto, ele percebe que precisa atravessar a cidade em pouco tempo para
conseguir chegar na audiência. Ele encara os prédios do centro da cidade e começa a correr
naquela direção, mas sem parar de ouvir sua música e batucar suas baquetas.
4.1.4.2 Cut scene #2
4.1.4.2.1 Atores
James: O protagonista
4.1.4.2.2 Descrição
Essa cena ocorre na transição do jogador entre o seu bairro e a periferia da cidade.
4.1.4.2.3 Storyboard
O personagem chega ao fim do seu bairro, por um lado ele visualiza um caminho
aparentemente mais tranquilo e que normalmente usa para chegar ao centro da cidade, mas o
caminho mais curto para o centro é passando pela periferia, um lugar estranho e em completa
desordem. Depois de um curto momento de hesitação ele encara o caminho mais curto,
mesmo com medo a sua necessidade de chegar a tempo faz ele decidir por este caminho,
então ele retoma sua corrida em direção a periferia.
4.1.4.3 Cut scene #3
4.1.4.3.1 Atores
James: O protagonista
4.1.4.3.2 Descrição
Essa cena ocorre na transição do jogador entre a periferia e o centro da cidade.
79
4.1.4.3.3 Storyboard
O personagem fica aliviado em conseguir chegar ao fim da periferia, a sua frente estão
finalmente os prédios do centro da cidade, o movimento ali é muito maior do que no seu
bairro o que o deixa um pouco apreensivo. Ele retira o panfleto do seu bolso e verifica como
chegar até a audição, ele sorri por estar perto do destino, vira para direita e retoma sua corrida.
4.1.4.4 Cut scene #4
4.1.4.4.1 Atores
James: O protagonista
4.1.4.4.2 Descrição
Essa cena ocorre no fim do jogo, quando o jogador finalmente alcança seu objetivo.
4.1.4.4.3 Storyboard
O personagem chega até o prédio indicado pelo mapa, está em cima da hora e ele
consegue entrar no último minuto, ele se inscreve e senta aliviado esperando sua vez. Na sua
vez ele utiliza o que aprendeu no caminho na sua apresentação. A cena final mostra James
fazendo parte da banda em um show com várias pessoas na plateia.
4.2 Mundo do Jogo
4.2.1 Aparência geral do mundo
O jogo apresenta uma cidade comum, dividida entre o bairro mais afastado, a periferia
e o centro da cidade. Ele deixa de lado o realismo e busca um universo encontrado em
desenhos animados.
4.2.2 Área #1
4.2.2.1 Descrição Geral
Bairro pacato e tranquilo onde fica a casa que o personagem vive
80
4.2.2.2 Características Físicas
Bairro afastado da cidade, somente casas de cores vivas, pouca movimentação nas ruas
e uma presença grande de árvores e arbustos.
4.2.2.3 Níveis que utilizam a área
Os três primeiros níveis do jogo utilizam esta área
4.2.2.4 Conexão com outras áreas
Logo depois de passar os níveis referentes a esta área o jogador ganha acesso aos
níveis da periferia
4.2.3 Área #2
4.2.3.1 Descrição Geral
Periferia da cidade, local pouco amistoso, mas o menor caminho até o centro.
4.2.3.2 Características Físicas
Bairro cheio de desordem e com cores escuras, latas de lixo viradas. Casas muito
próximas e alguns prédios, possui mais movimento que o bairro inicial.
4.2.3.3 Níveis que utilizam a área
Do quarto ao sexto nível do jogo utilizam esta área.
4.2.3.4 Conexão com outras áreas
O jogador deve passar por seu bairro para chegar a essa área e depois de passar por ela
ganha acesso ao centro da cidade.
4.2.3.4.1 Área #3
4.2.3.4.1.1 Descrição Geral
Centro da cidade, local onde a audição acontece.
4.2.3.4.1.2 Características Físicas
81
Centro da cidade, as cores voltam a aparecer, porém é mais movimentada que a
periferia. Somem as casas e agora existem somente prédios e outras construções.
4.2.3.4.1.3 Níveis que utilizam a área
Os três últimos níveis do jogo utilizam esta área.
4.2.3.4.1.4 Conexão com outras áreas
Logo depois de sair da periferia o personagem atinge essa última área.
4.2.3.5 Personagens
4.2.3.5.1 Personagem #1
4.2.3.5.1.1 História de fundo
O personagem principal da história é James, um menino que mora num bairro
tranquilo de uma cidade. Ele frequenta regularmente a escola e vive uma vida normal como a
dos outros garotos da sua idade.
4.2.3.5.1.2 Personalidade
Seu sonho é ser baterista. Anda sempre com suas baquetas batucando qualquer coisa
que esteja ao seu alcance enquanto ouve seu aparelho de som usando fones de ouvido. Por
conta disto normalmente está distraído ao que acontece a seu redor.
4.2.3.5.1.3 Aparência
4.2.3.5.1.3.1 Características Físicas
Ele tem a estatura média de um garoto de 12 anos, tem um físico magro e é
caucasiano. Anda sempre utilizando seu moletom vermelho, calça jeans azul, seu aparelho de
som, seus fones de ouvidos e suas baquetas.
4.2.3.5.2 Animações
Sua principal animação é a de corrida. Também existe a animação de batuque quando
passa por algum obstáculo e as animações quando ele quando ele não consegue passar por
eles.
82
4.2.3.6 Habilidades Especiais
Ele consegue fazer as coisas a sua volta se comportarem de uma maneira especial
quando acerta o ritmo de suas batucadas.
4.2.3.7 Relevância a história
Toda a história é focada na sua vontade de chegar a audição a tempo.
4.2.3.8 Relação com outros personagens
Ele é o único personagem que tem relevância com a história do jogo.
5 NÍVEIS
A Figura 29 representa a disposição dos obstáculos e checkpoints em cada uma das
nove fases do jogo. A ordem em que os obstáculos aparecem no nível parte do primeiro
elemento a esquerda e segue para a direita.
83
Figura 29. Sequência de obstáculos de cada nível
5.1 Níveis principais
5.1.1 Sinopse
Todos os níveis do jogo possuem a sinopse parecida, modificando o cenário e os
obstáculos encontrados. Sempre é focado no personagem principal correndo e ouvindo
música, tentando conseguir chegar ao seu destino final.
84
5.1.2 Introdução
Os níveis iniciais de cada Cenário possuem uma cut scene introdutória mostrando ou
atualizando a estado do personagem. A primeira fase também possui antes dela um nível de
treinamento.
5.1.3 Objetivos
O objetivo de cada fase é conseguir chegar ao seu fim ultrapassando todos os
obstáculos sem cometer erros.
5.1.4 Caminho
O caminho de cada fase é linear e não pode ser modificado, com movimento do
personagem da esquerda para a direita do cenário em velocidade constante, exceto quando é
parado por algum obstáculo não ultrapassado.
5.1.5 Encontros
O personagem se encontra em cada nível com diferentes obstáculos e com elementos
de checkpoints que salvam seu progresso.
5.1.6 Progressão
Ao decorrer do jogo os níveis aumentam seu grau de dificuldade, trazendo uma
diversidade maior de obstáculos a serem ultrapassados e com sequências mais difíceis de
serem reproduzidas.
5.1.7 Fechamento
Ao final de cada nível são exibidos ao jogador o número de obstáculos superados e a
quantidade de erros cometidos. Ao final da última fase é exibida uma cut scene com o
desfecho da história do personagem.
5.2 Nível de treinamento
Muito similar aos níveis regulares, tem o intuito de instruir o jogador com a forma de
interação e fazer uma demonstração de como será a jogabilidade. O nível se repete até que o
85
jogador consiga acertar os comandos requisitados e saiba como ultrapassar os obstáculos dos
níveis seguintes.
6 INTERFACE
Nesta seção é detalhado como é apresentada como funciona a interação com o usuário.
6.1 Sistema Visual
6.1.1 HUD
O HUD comtém a distância percorrida pelo usuário e quanto falta para chegar até o
fim da fase e o número da fase onde ele se encontra. Também contém um sinal para o início
da execução da sequência e quando se aproxima de um obstáculo apresenta a partitura
correspondente a ele.
6.1.2 Menus
O jogo possui um menu na tela Menu Principal do jogo com botões que redirecionam
para outra telas. Sempre há um botão para retornar a tela Menu Principal. Na tela Seleção de
Níveis existem botões referentes a cada fase do jogo, as fases já concluídas ou iniciadas
anteriormente estarão clicáveis e as ainda restantes estarão com um ícone de cadeado e não
poderão ser acessadas. Na tela Jogo existe um botão para pausar a fase e com isso exibir um
menu onde o jogador poderá retornar a tela Seleção de Níveis ou Menu Principal. Os botões
dos menus podem ser acessados através de toques na tela ou emitindo sons ritmados.
6.1.3 Sistema de renderização, câmera e iluminação
A engine utilizada (Unity3D) para a criação do jogo já traz seu próprio sistema de
renderização, especificação de câmeras e iluminação.
86
6.2 Sistema de Controle
O principal controle do jogador é feito através do microfone, o jogador deve colocar o
aparelho sobre alguma superfície e interagir com o jogo produzindo sons ritmados. Uma
opção ao microfone é a utilização de toques na tela. Ambas as formas de interação devem ser
feitas no ritmo imposto pelo jogo para serem válidas. Os botões dos menus do jogo são
acionados através de toques na tela.
6.3 Música
A música utilizada no jogo tem como instrumento predominante a bateria, para
contextualizar com o personagem principal que está a caminho de uma audição para tocar
bateria.
6.4 Efeitos Sonoros
Todo obstáculo quando o jogador se aproximar iniciará, junto com a exibição da
partitura, uma sequência sonora que deverá ser reproduzida. O jogo utiliza um aviso sonoro
para indicar quando o jogador deve iniciar a sequência para ultrapassar o obstáculo. Também
há sons indicando quando o jogador recolhe um item de checkpoint e sons de feedback dos
obstáculos.
6.5 Sistema de Ajuda
O sistema de ajuda é ativado quando o jogador errar muitas vezes um obstáculo. São
mostradas imagens e pequenos textos do que deve ser feito para o obstáculo ser ultrapassado e
também aparecere a sugestão de o jogador retornar ao nível de treinamento.
7 INFORMAÇÕES TÉCNICAS
7.1 Hardware alvo
O alvo são dispositivos móveis que utilizam o sistema operacional Android e iOS.
7.2 Hardware e Software de Desenvolvimento
Os softwares utilizados:
87
• Unity3D: Engine de Jogo utilizada como ambiente de desenvolvimento.
MonoDevelop: IDE para a programação de scripts.
• Blender: Para modelagem de objetos tridimensionais.
• Inkscape, GIMP: Para edição de imagens 2D.
• Audacity: Para edição de áudio.
Hardware:
• Macbook Pro: Onde o jogo será desenvolvido.
• Samsung Galaxy Y: Aparelho para testes do sistema Android.
• iPod, iPad: Aparelhos para testes do sistema iOS.
Também foram utilizados assets disponibilizados na internet de uso livre.
7.3 Linguagem de Script Foi utilizado o C# Script, por ele já fazer parte do engine utilizada.
88
APÊNDICE B. DIAGRAMAS DE MODELAGEM
A Figura 30 representa o diagrama de classes das principais classes do jogo projetado
para este TTC. O diagrama não demonstra classes que serão utilizadas e já existem na
Unity3D.
89
Figura 30. Diagrama de classes do jogo
A Figura 31 apresenta um diagrama de atividades demonstrando a sequência de ações
que ocorrem dentro de cada fase do jogo.
90
Figura 31. Diagrama de atividades da fase
91
APÊNDICE C. QUESTIONÁRIO DOS TESTES
Idade: Sexo : ☐ Masculino ☐ Feminino O que achou da história do jogo? ☐ Muito Ruim ☐ Ruim ☐ Normal ☐ Boa ☐ Muito Boa O que achou dos gráficos do jogo? ☐ Muito Ruim ☐ Ruim ☐ Normal ☐ Bom ☐ Muito Bom O que achou dos efeitos sonoros do jogo? ☐ Muito Ruim ☐ Ruim ☐ Normal ☐ Bom ☐ Muito Bom O que achou de o jogo ser para celulares? ☐ Muito Ruim ☐ Ruim ☐ Normal ☐ Boa ☐ Muito Boa Achou a representação das partituras adequada? ☐ Não ☐ Pouco ☐ Muito
O que achou do nível de dificuldade do jogo ? ☐ Fácil ☐ Bom ☐ Difícil O que achou do uso do microfone? ☐ Muito Ruim ☐ Ruim ☐ Normal ☐ Bom ☐ Muito Bom O que achou das informações apresentadas no final da fase? ☐ Muito Ruim ☐ Ruim ☐ Normal ☐ Boa ☐ Muito Boa Alguma outra informação deveria ser apresentada? ___________________________________________________ ______________________________________________________________________________________________________
92
Você acha que o jogo pode auxiliar no aprendizado de ritmo? ☐ Não ☐ Pouco ☐ Muito Você acha que o uso do microfone colabora com o aprendizado? ☐ Não ☐ Pouco ☐ Muito Você utilizaria esse jogo no aprendizado de ritmo? ☐ Não ☐ Talvez ☐ Sim Que nota você da ao jogo: ☐ 1 ☐ 2 ☐ 3 ☐ 4 ☐ 5 ☐ 6 ☐ 7 ☐ 8 ☐ 9 ☐ 10 Alguma sugestão de melhoria para o jogo? ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________
