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.
Mecanismo de Utilização da Jogo Feedback Ritmico interação Música Microfone Só Soprando Não utiliza Não utiliza (Sopro)
41
As notas Reproduz músicas percorrem a tela e e exibe as notas Teclado ou devem ser tocadas Rainbow Strings para serem Violino quando passam por reproduzidas pelo um ponto jogador específico Uma margem Utiliza música branca pulsa em para sinalizar Patapon Joystick volta da tela do sucesso ou falha jogo no ritmo que do jogador deve ser seguido Cada minigame utiliza um contexto Rythm Heaven Fever Joystick Não utiliza diferente de sons e imagens sinalizando o ritmo Utiliza uma O jogo emite sons música de fundo diferentes para que é BIT.TRIP RUNNER Teclado cada obstáculo no complementada ritmo da música de pelos sons dos fundo obstáculos É mostrada uma partitura e é reproduzida uma A música é sequencia de sons Microfone utilizada para Jogo proposto no no ritmo esperado. (Palma) ou definir os TTC Depois um som toque na tela diferentes diferente indica o obstáculos do jogo 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.
Muito Muito Pergunta Ruim Ruim Normal Bom 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:
ATOMICONLINE. Temple Run screenshots. 2012. Disponível em:
BALDWIN. Mark. Game Design Document Outline. 2005. Disponível em:
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:
CLUA, Esteban Walter Gonzalez; BITTENCOURT, João Ricardo. Desenvolvimento de jogos 3D: concepção, design e programação. 2005. Disponível em:
EUROGAMER. Patapon. 2008. Disponível em:
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:
GAMEMEDIA. Game sprite sheet. 2011. Disponível em:
GRIMJAW. Análise: Patapon 2. 2009. Disponível em:
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:
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:
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:
MAESTRI, George. Digital character animation 3. Berkeley: New Riders, 2006.
MICROSOFT. Kinect. 2012. Disponível em:
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:
NINTENDO. WII. 2010. Disponível em:
NINTENDO. Rythm Heaven Fever. 2012. Disponível em:
NINTENDO EVERYTHING. Rythm Heaven Wii. 2012. Disponível em:
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:
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:
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:
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:
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:
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:
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? ______