Relatorio final - Blinded Walker

1,343
-1

Published on

TCC sobre desenvolvimento de jogos em Android.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,343
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
43
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Relatorio final - Blinded Walker

  1. 1. Serviço Nacional de Aprendizagem Comercial do Rio Grande do Sul Faculdade Senac Porto Alegre Curso de Tecnologia em Análise e Desenvolvimento de Sistemas RELATÓRIO FINAL DE PROJETO Blinded Walker Desenvolvimento de um jogo para a plataforma Android Tiago Rodrigues Mattos da Cunha Prof. MSc. Luciano Zanuz (Orientador) Porto Alegre 2012
  2. 2. AGRADECIMENTOSA todos aqueles que de alguma forma participaram deste projeto. Vocês sabem quem vocês são.
  3. 3. RESUMO O desenvolvimento de jogos é um assunto que atrai muito interesse, emespecial nos dias de hoje. É fácil ter acesso a recursos computacionais, kits dedesenvolvimento, documentação e aos diversos dispositivos clientes existentes nomercado. Entretanto, muitas vezes não se tem certeza por onde começar, nem setem ideia de que tipo de desafios podem estar presentes. Este trabalho tem o intuitode documentar o desenvolvimento de um jogo, trazendo consigo uma apresentação,e uma possível solução, para as diversas dificuldades encontradas no processo.Como resultado são apresentadas diversas soluções para dificuldades comuns nodesenvolvimento de jogos na plataforma Android.PALAVRAS-CHAVE: Desenvolvimento de jogos. Jogos. Android.
  4. 4. SUMÁRIO1   Apresentação Geral do Projeto  .........................................................................................  6  2   Definição do Problema  ..........................................................................................................  7  3   Objetivos  .....................................................................................................................................  8  4   Análise de Tecnologias/Ferramentas  ..............................................................................  9   4.1   Android SDK  ....................................................................................................................................  9   4.2   Linguagem Java  .............................................................................................................................  9   4.3   IDE Eclipse  .......................................................................................................................................  9   4.4   Fireworks  ..........................................................................................................................................  9   4.5   GarageBand  ..................................................................................................................................  10   4.6   Audacity  ..........................................................................................................................................  10   4.7   Astah*  ..............................................................................................................................................  10   4.8   ObjectAid  .......................................................................................................................................  10   4.9   OpenGL  ...........................................................................................................................................  10  5   Descrição da Solução  .........................................................................................................  11  6   Abordagem de Desenvolvimento  ...................................................................................  12  7   Arquitetura do Sistema  ......................................................................................................  14   7.1   Game Design Document  ..........................................................................................................  15   7.1.1   Título  ...........................................................................................................................................................  15   7.1.2   Descrição Curta  ....................................................................................................................................  15   7.1.3   Tipo/Gênero do Jogo  .........................................................................................................................  15   7.1.4   Cenário  ......................................................................................................................................................  15   7.1.5   Descrição Longa  ..................................................................................................................................  15   7.1.6   Sistema de Jogo  ...................................................................................................................................  16   7.1.7   Game Play  ...............................................................................................................................................  16   7.1.8   Tela de título e telas de informações  ........................................................................................  17   7.1.9   Requisitos de Áudio  ............................................................................................................................  17   7.2   Modelagem Funcional   ...............................................................................................................  19   7.2.1   Casos de Uso  ........................................................................................................................................  19   7.2.2   Mapa de Transição  .............................................................................................................................  20   7.2.3   Backlogs  ...................................................................................................................................................  21   7.2.4   Diagramas de Classes  ......................................................................................................................  23   7.3   Modelagem dos Dados  .............................................................................................................  24   7.4   Modelagem de Interface Gráfica do Usuário  ...................................................................  25  8   Funcionamento do Sistema  .............................................................................................  26  9   Descrição dos desafios e soluções encontrados  ...................................................  27   9.1   O mundo como uma coleção de lista de vetores (ArrayList)  ...................................  27   9.2   Renderizando de forma eficiente: aceleração na GPU   ................................................  27   9.3   Sentindo você: um sistema para entrada de dados  .....................................................  30   9.4   Estou tocando em você, ou não?  ........................................................................................  31   9.5   Definindo Níveis  ..........................................................................................................................  32   9.6   Colisão: o que acontece entre nós  ......................................................................................  33   9.7   O mundo é mais que imagens estáticas: um sistema de animação  .....................  33   9.7.1   Sprites, o inicio do movimento  ......................................................................................................  34   9.7.2   Uma breve história no tempo: Uma explicação do OpenGL e os estados  ...........  35   9.7.3   Detalhes tão pequenos de nós dois, ou mais: como funciona a animação  ..........  36   9.8   Produzindo os gráficos e uma descoberta  ......................................................................  37   9.8.1   Benchmarking  ........................................................................................................................................  38   9.9   Eu posso ouvir você: um sistema sonoro   ........................................................................  39  
  5. 5. 9.9.1   Produzindo sons  ...................................................................................................................................  39   9.10   Sistema de menus  ....................................................................................................................  39   9.11   Montando níveis: mais desafios  ........................................................................................  47   9.12   Pontuação  ...................................................................................................................................  47   9.13   Persistindo dados  ....................................................................................................................  48  10   Validação  ...............................................................................................................................  49   10.1   Estratégia  .....................................................................................................................................  49   10.2   Consolidação dos Dados Coletados  ................................................................................  51  11   Considerações  ....................................................................................................................  60  12   Referências Bibliográficas  .............................................................................................  61   ...........................................................................................  62  13   Componentes Re-utilizados  14   APÊNDICE A - Formulário de validação  ...................................................................  63  15   APÊNDICE B – Formulários de validação preenchidos  .....................................  64  
  6. 6.   6  1 Apresentação Geral do Projeto O projeto é centrado no desenvolvimento de um jogo e os desafiosencontrados ao longo do mesmo. Este tema foi escolhido uma vez que o mercadode entretenimento está cada vez maior, apontando novas possibilidades. Dentrodeste mercado, os jogos se colocam como uma das formas mais interativa,possibilitando que um consumidor possa, de forma controlada e limitada, decidir oque irá acontecer, como e quando. No ano de 2011, o mercado de jogos paradispositivos móveis movimentou mais de 12 bilhões de dólares americanos eempresas como a Rovio, do sucesso Angry Birds, fazem cerca de 6 milhões dedólares americanos por mês apenas com propagandas em seus jogos (BussinessDegree, 2012). Outro ponto importante que temos nos últimos anos é o crescimentoacelerado das plataformas móveis. Em especial, os smartphones têm atingido umaenorme fatia da população, independente de cultura, sexo e idade. O crescimento demercado dos smartphones foi de 42,5% ano a ano, com um total de 144,9 milhõesde dispositivos colocados no mercado no primeiro trimestre deste ano, comparadocom os 101,7 milhões no mesmo período do ano passado (IDC, 2012). Dentrodesses dispositivos, existem algumas opções de Sistema Operacional (SO), cadaqual com suas ferramentas, forças e fraquezas. Destas opções, foi escolhido oAndroid (Android, 2011), sistema mais aberto e de fácil acesso paradesenvolvimento. O Android está presente em diversos aparelhos no mercado epossui um kit de desenvolvimento de software, Software Development Kit (SDK)(Android SDK, 2011), disponível a diversos sistemas operacionais. Outra vantagemdo Android é ser baseado na linguagem Java, cuja vasta documentação é de sumaimportância para o trabalho. Sendo assim, esse trabalho se propõe a juntar essas duas vertentes:entretenimento e dispositivos móveis. Neste caso específico, um jogo para Android.Ambos os campos possuem possibilidades interessantes, e desafios ainda maisinteressantes. Este trabalho é exatamente sobre esses desafios.
  7. 7.   7  2 Definição do Problema Um software de negócio costuma nascer da necessidade de resolver umproblema. Como organizar certos dados a ponto de gerar a informação necessária.Um jogo, com algumas exceções, não se propõem a resolver um problema. Sendoassim, a definição do problema leva em conta os problemas encontrados ao longodo desenvolvimento. • Como gerenciar os recursos de forma a evitar gargalos? • Como capturar e tratar o evento de toque? • Como gerenciar um nível carregado e repassar a seus componentes uma requisição de atualização e como capturar os resultados dessa requisição? • Os diversos sons devem ser sincronizados a seus eventos. Como manter o tempo correto? • Como gerenciar um sistema de animação, que faça sentido com os eventos e movimentos existentes? • Para um jogo, manter certo nível de performance é essencial. Essa performance se apresenta ao usuário como fluidez no jogo. Como manter a performance necessária para não comprometer o projeto?
  8. 8.   8  3 Objetivos O objetivo é a criação de um jogo no estilo plataforma/puzzle para aplataforma Android que terá sua interação baseada em toque. Ao final do projeto éesperado: • 10 fases diferentes, com complexidade crescentes; • Sistema de renderização que reutilize diversas texturas; • Sistema de controle de toque do usuário, identificando o toque da tela a um ponto do jogo; • Sistema de animação; • Sistema de som, com capacidade para músicas de fundo e efeitos sonoros; • Verificar se a forma escolhida para apresentação da dinâmica de jogo sem tutoriais funciona.
  9. 9.   9  4 Análise de Tecnologias/Ferramentas Para o desenvolvimento deste projeto, diversas ferramentas e tecnologiasforam utilizadas. A seguir temos uma breve apresentação de cada uma delas ecomo a mesma se encaixa no projeto em questão.4.1 Android SDK Para o desenvolvimento foi utilizado o SDK oficial da plataforma Android(Android SDK, 2011). O mesmo possui todas as bibliotecas básicas para odesenvolvimento Android, incluindo um depurador e um simulador (permitindo testesem ambientes controlados), entre outros. Existem outros SDKs que geram código para Android, mas a escolha foipela SDK oficial para que fosse possível trabalhar com a plataforma nativamente.4.2 Linguagem Java A linguagem utilizada pela plataforma Android é Java. Portanto, ao utilizar oSDK oficial, a escolha pela linguagem Java é um pré-requisito. Entretanto, amáquina virtual não é a padrão, e sim uma máquina criada especialmente para aplataforma, conhecida como Dalvik. Sendo assim, existe um namespace específicodo Android, com classes especialmente criadas para este ambiente. Outra grande vantagem é a ampla documentação existente para Javadisponível na Internet. A linguagem Java foi criada pela Sun Microsystems, que foicomprada pela Oracle, tendo como base o paradigma de orientação a objetos. Maisdetalhes sobre a linguagem podem ser obtidos no site oficial da linguagem em<http://www.oracle.com/technetwork/java/index.html>.4.3 IDE Eclipse O ambiente de desenvolvimento, Integrated Development Environment(IDE), utilizado é o Eclipse (Eclipse, 2011). É o IDE recomendado peladocumentação oficial do SDK da plataforma Android, além de ser um IDE bastantecompleto e com variados recursos úteis ao desenvolvimento (tais como: integraçãocom controles de versão e suporte a refatoração).4.4 Fireworks A criação dos gráficos (imagens) foi feita utilizando o Fireworks (Fireworks,2011). O Fireworks é um software proprietário da Adobe. O mesmo possui umperíodo de experiência onde todas as suas funcionalidades estão disponíveis. É umeditor fácil de usar e com recursos suficientes ao trabalho aqui realizado.
  10. 10.   10  4.5 GarageBand A ferramenta que foi utilizada para a produção sonora é o GarageBand(GarageBand, 2011). O mesmo faz parte de um pacote de softwares da Appleconhecido como iLife. Ele está disponível na instalação padrão do Mac OS X SnowLeopard e possui os recursos necessários para a confecção dos sons necessários. O mesmo possui uma biblioteca com efeitos sonoros e trechos de som quefacilitam a criação de diversos conteúdos sonoros sem, necessariamente, precisartocar algum instrumento.4.6 Audacity Como software sonoro auxiliar, o Audacity (Audacity, 2012) foi utilizado, umavez que o mesmo permite a conversão de um formato de áudio para outro. OAudacity é um software open source.4.7 Astah* Para a modelagem dos casos de uso foi utilizado o Astah* Community(Astah, 2011). O mesmo dá suporte a diagramas do UML 2.0 e, na versãoCommunity, é totalmente gratuito.4.8 ObjectAid O ObjectAid (ObjectAid, 2011) foi utilizado para a geração dos diagramas declasse, uma vez que permite que os mesmos sejam gerados a partir do códigoexistente.4.9 OpenGL O OpenGL é uma especificação padrão para escrever aplicações e simularfísica, que produzem gráficos 2D e 3D. O padrão foi criado em 1992 pela SiliconGraphics Inc. (SGI) com o objetivo de ser uma Interface de Programação deAplicativos, Application Programming Interface (API) ,independente. O OpenGL possui diversas versões, cada qual especificando um conjunto defunções que devem ser suportadas para que um hardware possa ser certificado parauma versão específica. Isso permite que tenhamos o processamento paralelo de informações emum hardware específico para este fim. No caso deste projeto, os gráficos sãoprocessados via OpenGL.
  11. 11.   11  5 Descrição da Solução Dada a natureza e complexidade de um jogo, o mesmo foi dividido empartes menores, possibilitando o seu desenvolvimento. Neste caso, há algunsmódulos básicos dentro da arquitetura proposta: renderização, detecção de colisão,animação, som e entrada de dados. Esses módulos fazem parte de um todoconhecido como máquina de jogo (ou game engine). Cada um dos módulos foidesmembrado em suas funções menores e implementado dentro de um sprint. Maisdetalhes sobre o que é um sprint estão presentes na Abordagem deDesenvolvimento. Entretanto, dentro do abordagem de desenvolvimento adotada, é importantea entrega de valor ao final de cada sprint. Como algumas tarefas podem serdivididas e abortadas em mais de um sprint, isso faz com que nem sempre, nodesenvolvimento de jogos, se possa ter algo jogável ao final de um sprint. O queocorre, neste caso, é uma diminuição da incerteza. Essa diminuição vem com o fatode que pequenas partes podem ser desenvolvidas e testadas, garantindo não sóque o código funciona, mas que a ideia sendo trabalhada é aceita como esperado.Ao diminuir as incertezas de um jogo rumo ao mercado, estamos garantindo que omesmo terá mais chances de dar certo, o que, por sua vez, agregará valor aoproduto. Ou, de acordo com KEITH (2010, p. 18) “Um projeto ágil diminui a incertezaem pequenas iterações que incluem todas as partes do desenvolvimento”. Dentro deste relatório, encontra-se o Documento de Design de Jogo (GameDesign Document – GDD). No mesmo temos detalhado o que será realizado emtermos de jogo, com todos os detalhes sobre o mesmo. Entretanto, o GDD não dáuma visão macro de como o sistema é em relação a sua implementação. Essa visãoficará clara nos capítulos posteriores, por hora a figura 1 abaixo demonstra umavisão geral do sistema. Maiores detalhes são encontrados no capítulo 9.Figura 1 - Visão geral do sistema
  12. 12.   12  6 Abordagem de Desenvolvimento A estratégia escolhida é o Scrum, na sua variante Scrum Solo. O motivodesta escolha está na descrição da solução, a capacidade de diminuir as incertezasao longo do tempo. Dado o caráter exploratório do projeto, gerenciar as incertezas éfundamental. De acordo com Keith (2010, p. 36), o Scrum é um framework para a criaçãode produtos complexos. Ao invés de desenvolver toda a documentaçãoanteriormente a qualquer implementação, o Scrum encoraja ciclos menores dedesenvolvimento, onde cada característica do produto é estudada, implementada,testada e entregue, para que o cliente possa avaliar o produto. Dentro do Scrum, em especial para desenvolvimento de jogos, existem,segundo Keith (2010, p. 44) os seguintes papéis: • Clientes e Stakeholders: Apesar de o cliente final de um jogo ser o jogador (ou gamer), este não influi diretamente sobre o projeto, entretanto os stakeholders os representam. Eles podem ser diversas pessoas envolvidas externamente, tal como publishers. Eles costumam definir vários itens do Product Backlog e prioriza-los; • Product Owner: É o membro do Scrum Team responsável pela intermediação entre os clientes e stakeholders e o Scrum Team. Ele representa os primeiros dentro do ciclo do Scrum, ao mesmo tempo em que facilita a comunicação entre as partes. É, também, responsável pelo Product Backlog; • Scrum Team: “É composto por um Scrum Master, um Product Owner e um time de desenvolvedores.” (Keith, 2010, p. 44); • Scrum Master: Responsável por facilitar o desenvolvimento, garantindo que o time tenha acesso aos recursos necessários e eliminando distrações; • O Time: O time de desenvolvimento, englobando profissionais de diversas áreas de conhecimento, de acordo com a necessidade do projeto. O Scrum também é formado pelos seguintes artefatos: • Product Backlog: É a lista de requisitos ou características necessárias ao projeto; • Sprint Backlog: É a lista de PBIs (Product Backlog Item) que serão realizados durante um Sprint; • Sprint: Uma iteração do processo de Scrum. Um sprint tem uma duração fixa entre duas a quatro semanas (o tempo exato depende de time para time). O Scrum também possui os seguintes encontros na sua prática: • Sprint Planning: é o encontro que define o que será trabalhado no próximo sprint; • Daily Scrum/Meeting: encontro diário do time de desenvolvimento; • Sprint review: encontro onde o resultado do Sprint é demonstrado; • Sprint retrospective: encontro onde o time de desenvolvimento avalia o sprint finalizado.
  13. 13.   13   Entretanto, o Scrum, da forma demonstrada, é de difícil aplicação quando háapenas uma pessoa no desenvolvimento. Para isso, o Scrum Solo é a soluçãoencontrada. Nesta modalidade, os diversos papéis são descartados, mas osprincípios e os artefatos do Scrum são respeitados, seguindo-se, então, as boaspráticas do Scrum.
  14. 14.   14  7 Arquitetura do Sistema O Scrum, apesar de valorizar mais software funcionando do quedocumentação completa (Beck et al, 2001), não exclui a documentação que fazparte do processo de desenvolvimento, principalmente em um trabalho como umTCC. O desenvolvimento de jogos apresenta um documento próprio para omesmo, conhecido como documento de design de jogo. O documento de design dejogo (GDD) é o principal documento no desenvolvimento de um jogo. É nele que seconcentram todas as informações sobre o jogo e suas regras. É com ele que osdiferentes envolvidos no processo irão basear suas decisões, pois é este documentoque deve deixar claro o que é o jogo, numa linguagem acessível a todo o grupo. Fazendo um paralelo com um software de negócios, é no GDD que seencontram as regras de negócio, requisitos funcionais e não funcionais e outrosnecessários. O modelo utilizado é baseado no disponível em Digital Worlds (2010). Omodelo foi produzido durante a preparação para um curso na The Open University(The Open University, 2011). Acrescenta-se a este documento, alguns outros documentos normalmenteutilizados no desenvolvimento de software. Sendo assim, os mesmos se encontrampresentes nas próximas subseções.
  15. 15.   15  7.1 Game Design Document7.1.1 Título Blinded Walker7.1.2 Descrição Curta O jogo consiste em guiar um protagonista vendado através de um cenáriocom diversas armadilhas.7.1.3 Tipo/Gênero do Jogo O jogo é um misto de plataforma e puzzle.7.1.4 Cenário O jogo passa em um mundo de fantasia. Este mundo não possui umahistória específica ou especial. Ele apenas serve como fundo ao jogo e justificativapara a forma que o jogo se constitui. Neste mundo existem perigos aos seushabitantes: buracos sem fundo e afins. A gravidade neste mundo, também, é diferente, pois existem plataformasflutuantes. Essas plataformas fazem parte dos caminhos e rotas possíveis para seandar. Diversas escadas permitem que seus habitantes possam facilmente andarentre elas.7.1.5 Descrição Longa O jogo é sobre um personagem (Bob) que gosta de se arriscar. Ele éconhecido como Blinded Walker, pois ele tem a mania de andar vendado. Ele dizque a sorte sempre está ao seu lado, e que não vai acontecer nada demais com ele.Ele possui uma equipe de uma pessoa (Arthur), que está sempre estressado com oseu colega. Bob sempre se venda e sai caminhando até encontrar com Arthur, queretira a sua venda e acaba com o desafio (assim, vencendo-se uma fase). Ao jogador cabe ‘guiar’ Bob através das fases, retirando os obstáculos ecriando os caminhos necessários. O jogador, portanto, faz o papel da ‘sorte’ aolongo do jogo. O jogador só pode agir sobre regiões pré-definidas do cenário e sobreo personagem principal. As regiões pré-definidas são as regiões de blocos. Existemalguns tipos de blocos: pedra rachada, que pode ser destruída somente, espaçopontilhado sem identificação, pode ser criado e apagado, espaço pontilhado comrelógio, cria bloco que dura por pouco tempo (tempo a ser verificado/ajustado) eespaço pontilhado com um ‘x’, bloco que pode ser criado e não mais apagado. Ao tocar sobre o personagem, ele muda o sentido do seu caminhar, eletambém muda o sentido ao bater em algum obstáculo, mas cai em um buraco se omesmo existir. O personagem, também, sobe escadas automaticamente e cabe aojogador derrubá-lo caso não queira que o mesmo suba.
  16. 16.   16   A câmera se movimenta automaticamente, sempre mantendo o foco nopersonagem principal. O jogador não pode movimentar a câmera em momentoalgum do jogo.7.1.6 Sistema de Jogo O sistema comporta os seguintes elementos: • Personagem do Jogador (Bob): caminha automaticamente durante todo o tempo de jogo, tendo o seu movimento modificado pelos seguintes eventos: o Blocos na altura do personagem ou paredes: muda o sentido do movimento para seu oposto; o Escadas: o movimento se torna vertical, sempre no sentido de baixo para cima (subida); o Toque do jogador: muda o sentido do movimento, seja o horizontal (forçando o personagem a caminhar no sentido oposto), seja o vertical (este só existente quando o personagem estiver subindo uma escada, fazendo o personagem cair da escada); o Ponto de chegada (Arthur): para o movimento e finaliza a fase (vitória); o Queda em armadilhas: para o movimento e finaliza a fase (fim de jogo). • Blocos: existem quatro tipos de blocos que reagem ao toque, sendo eles: o Rachado: bloco que poderá ser destruído através do toque do jogador, não pode ser construído; o Pontilhado: bloco que, através do toque do jogador, pode ser criado e destruído tantas vezes quanto forem requeridas; o Pontilhado com relógio: bloco que pode ser criado, mas que dura um curto período de tempo (especificar o tempo); o Pontilhado com um ‘x’: bloco que pode ser criado e não mais destruído. • Escadas: servem para subir, e somente subir, para um nível acima de plataformas. A escada não reage ao toque do jogador. Ativa a ação subir do personagem principal; • Ponto de chegada (Arthur): define o destino final de uma fase. Ativa o evento de vitória; • Armadilhas: as armadilhas são locais que ativam o evento de fim de jogo (o jogador perde). São representadas por diversos buracos (falhas) nas plataformas.7.1.7 Game Play O jogo é jogado apenas através do toque. A mecânica é simples, o jogadorapenas pode tocar em certos elementos que se destacam na tela e, a partir dessetoque, um evento ocorre. Este evento pode disparar uma mudança no cenário (aotocar em um bloco) ou mudar o sentido do movimento do personagem principal.
  17. 17.   17   Toques em outras regiões não causam nenhum evento. O jogador nãopoderá aplicar efeitos de zoom, nem arrastar a tela para visualizar outras partes docenário.7.1.8 Tela de título e telas de informações Devem existir as seguintes telas que não pertencem ao gameplay: • Tela de identificação do desenvolvedor: Uma tela simples, não necessariamente animada, onde o logo do desenvolvedor é claramente identificável; • Tela Título: Tela contendo o título do jogo e a opção de iniciar o jogo, indo para a tela de menu inicial. Esta tela deve aparecer após a tela de identificação do desenvolvedor. É esperado o título do jogo e um tema musical; • Tela de menu inicial: deve conter o mesmo background da tela título. Devem existir as opções básicas de inicio de jogo: [jogar], [pontuações], [opções] e [sair]. O item de menu [sair] será adicionado, prevendo uma possível adaptação a dispositivos sem botão físico de voltar; • Tela de pontuações: listará as fases já vencidas pelo usuário e a pontuação obtida em cada uma delas; • Tela de opções: o usuário poderá definir o nível sonoro para as músicas de fundo e para os efeitos sonoros. Devem ser utilizados sliders para este fim; • Tela jogar: na primeira inicialização dessa tela, aparecerá uma introdução aos personagens e a história do jogo (com a opção de pular). Na segunda utilização em diante, o jogador irá direto para a tela que lista os níveis existentes. Nessa listagem, o primeiro item será a possibilidade de rever a introdução, o segundo item em diante serão as fases em sua sequencia de jogo, sendo que uma fase só se torna disponível após a anterior ser vencida; • Tela de vitória de fase: a tela apresentará a pontuação obtida e irá parabenizar o jogador pela vitória, possibilitando ir diretamente para a próxima fase, ou voltar para a lista de fases; • Tela de fim de jogo: a tela apresentará uma mensagem de encorajamento e as opções de tentar novamente a fase ou ir para a lista de fases; • Menu in-game: durante o gameplay, o jogador poderá chamar um sistema de menu ao pressionar o botão de [pausar] na tela de jogo. Este menu será composto das opções de voltar para a fase, reiniciar a fase, voltar para a listagem de fases ou ir diretamente para a tela de menu inicial (facilitando o jogador sair do jogo).7.1.9 Requisitos de Áudio As seguintes características são esperadas na parte sonora: • Deve existir a possibilidade de desabilitar os sons do jogo;
  18. 18.   18   • Música de background: tema musical que acompanhe o jogador durante o game play de uma fase; • Sons de alerta: devem existir diversos sons de alerta, vinculados a certos eventos do jogo: o Seleção de item de menu; o Seleção de nível para jogar; o Toque no protagonista; o Destruição do bloco ’rachado’; o Criação de bloco; o Temporizador do bloco temporário; o Inicio de fase; o Final de fase; o Queda em armadilha; o Troca de folha ao introduzir os personagens/história.
  19. 19.   19  7.2 Modelagem Funcional Estão presentes os Casos de Uso (para modelagem do sistema de menus euso geral do jogo), mapa de transição (demonstrando a relação entre as telas dojogo), diagramas de classes e backlogs (Sprint).7.2.1 Casos de UsoFigura 2 - Diagrama de caso de uso
  20. 20.   20  7.2.2 Mapa de Transição O mapa de transição demonstra a transição existente de uma tela para outrano jogo. A figura 3 abaixo apresenta o mapa de transição deste projeto.Figura 3 - Mapa de Transição
  21. 21.   21  7.2.3 Backlogs Aqui são apresentados os backlogs dos sprints realizados ao longo doprojeto. • Sprint 01 o Sistema de Renderização § Criação da Atividade § Criação da superfície § Criação do buffer1 de renderização § Criação do sistema de câmeras § Criação do laço básico de jogo § Criação do thread2 de jogo o Ajustes GDD § Título § Descrição Curta § Tipo/Gênero do Jogo § Cenário § Descrição Longa § Sistema de Jogo § Game Play § Tela de título e telas de informações § Requisitos de Áudio • Sprint 02 o Sistema de Input § Captura do evento de toque § Transformação do ponto de toque de espaço em tela para espaço em jogo § Criação do mecanismo de tratamento do evento de toque o Sistema de carregamento e armazenamento de níveis § Definição do formato a ser utilizado § Criação dos elementos dentro do formato § Carregamento e gerenciamento dos recursos • Sprint 03 o Sistema de Colisão § Adaptação do BBox3 § Sistema de gravidade § Tratamento do evento de queda do personagem jogável • Sprint XX o Rescrita do sistema § Sistema gráfico (render) utilizando OpenGL § Colisão § Armazenamento de níveis (utilizando TXT) § Input • Sprint 04 o Sistema de animação                                                                                                                1  Memória  de  uso  temporário.  2  Unidade  de  trabalho.  3  Classe  inicialmente  utilizada  para  tratamento  de  colisões.  
  22. 22.   22   § Definição dos sprites4 § Definição de vértices § Tratamento de animações § Sistema para desenhar os sprites § Sistema de gerenciamento de recursos • Sprint 05 o Assets gráficos § Plano de fundo (background) § Personagem principal (Bob) § Personagem secundário (Arthur) § Blocos diversos § Mensagem de vitória § Mensagem de derrota (game over) o Ajustes na documentação • Sprint 06 o Sistema de som § Música § Efeitos sonoros o Ajustes na documentação • Sprint 07 o Assets sonoros § Música de jogo § Efeitos sonoros diversos • Ação em blocos • Ação em personagem principal o Ajustes na documentação • Sprint 08 o Sistema de menus § Tela de logo § Tela de menu principal § Seleção de níveis § Menu durante jogo (nível) • Sprint 09 o Níveis de jogo • Sprint 10 o Validação § Criação dos formulários § Aplicação da validação § Análise dos resultados                                                                                                                4  Maiores  detalhes  no  capítulo  9.7.1  
  23. 23.   23  7.2.4 Diagramas de Classes7.2.4.1 Renderização A figura 4 demonstra o diagrama de classes vinculado ao sistema derenderização.Figura 4 - Diagrama de classes do sistema de renderização7.2.4.2 Input A figura 5 demonstra o diagrama de classes vinculado ao sistema de input.Figura 5 - Diagrama de classes do sistema de input
  24. 24.   24  7.2.4.3 Colisão A figura 6 demonstra o diagrama de classes vinculado ao sistema decolisão.Figura 6 - Diagrama de classes do sistema de colisão7.2.4.4 Uma visão geral das classes restantes A figura 7 demonstra uma visão geral das outras classes existentes nesteprojeto.Figura 7 - Uma visão geral de outras classes do sistema  7.3 Modelagem dos Dados Inicialmente foi pensado que existiria a necessidade de um armazenamentoutilizando o SQLite, padrão na plataforma. Entretanto uma outra solução foiencontrada com o Shared Preferences, conforme item 9.13 deste trabalho.
  25. 25.   25  7.4 Modelagem de Interface Gráfica do Usuário A figura 8 demonstra o protótipo inicial para a interface gráfica do usuáriodurante o desenvolver de um nível.Figura 8 - Protótipo de interface com o usuário Bloco fixo Personagem não jogável (chegada) Escada Personagem jogável Bloco interativo
  26. 26.   26  8 Funcionamento do Sistema Com os trabalhos encerrados, o comportamento esperado do sistema éaquele previsto no nosso GDD. O jogo inicializa com uma tela de logo, sendo amesma seguida de uma tela de menu principal, onde o nome do jogo esta presente.Os níveis são selecionáveis a partir de uma interface própria. O som pode serativado, ou desativado, a partir do menu principal. Uma exceção está presente em relação ao conteúdo do GDD: os slidescontando a história. Para tais slides, é importante um bom desenho, que possatraduzir o que pretendemos passar de forma visual. Infelizmente não possuímos,ainda, um profissional que possa produzir tal material. O jogo inicia com uma tela que apresenta o logotipo do desenvolvedor,seguida por outra tela com o título do jogo. Essa segunda tela possui três ícones: umpara a tela de créditos, outro para ativar/desativar o som e o terceiro para a tela deseleção de níveis. Para escolhe uma opção, basta tocar sobre o ícone desejado. A seleção de níveis tem o formato de um rolo de filme onde, tocando umadas pontas do rolo, é possível escolher um nível. Existe um ícone para retornar atela de título e para entrar em um nível basta tocar sobre o mesmo. Durante o jogo existe a opção de pausar, representada por um ícone.Estando o jogo pausado, é possível voltar a seleção de níveis, reiniciar o nível oucontinuar jogando. Essas opções são, também, representadas por ícones. Existe,ainda, alguns ícones nas telas de fim de jogo (quando o jogador perde) e vitória.Esses ícones permitem que, na tela de fim de jogo, voltar a seleção de níveis outentar novamente o nível e, na tela de vitória, voltar a seleção de níveis, ir para opróximo nível ou tentar novamente o nível atual. Maiores detalhes de como o jogo funciona podem ser verificados no GDD eno item 9.10 deste mesmo documento.
  27. 27.   27  9 Descrição dos desafios e soluções encontrados Dado que este formato de relatório favorece um projeto de negócio maisclássico, iremos abrir este espaço, onde os diversos questionamentos queaparecerem durante o desenvolvimento serão colocados, juntos com suas possíveissoluções e razões que levaram a certas escolhas.9.1 O mundo como uma coleção de lista de vetores (ArrayList) O primeiro desafio encontrado foi como organizar o mundo do jogo. Omundo do jogo, dentro deste jogo específico, é cada nível disponível. Os níveis sãocompostos de diversos objetos, que descrevem o cenário de fundo, os blocos fixos,os blocos interativos, escadas, personagem jogável e não jogável. Há diversasformas que podem ser utilizadas: uma matriz, um vetor... etc. Inicialmente foi pensado em um modelo de grafo, pois o mesmo facilita apropagação de um evento, dada a sua estrutura. Um grafo permite que, a partir donó raiz, seja simples enviar um evento de atualização aos nós existentes, uma vezque existe uma ligação direta entre eles. A figura 9 demonstra como um evento pode se propagar em um grafo.Figura 9 – Um evento se propagando em um grafo Um evento disparado na raiz facilmente se propaga. Esse modelo foi descartado após o TCC I, pois para lidar com os diversostipos de elementos e eventos relacionados ao jogo havia uma complexidade acimado esperado. Houve uma falha em prever o quão complexo o sistema se mostraria. A solução encontrada para tanto foi a de trabalhar com lista de vetores.Essas listas são utilizadas para definir todos os blocos existentes no cenário,existindo uma lista, portanto, para cada tipo específico de bloco. As escadastambém são definidas desta forma. Outros elementos (personagem principal,background, chegada, menus) são definidos individualmente. Isso facilita trabalhar com esses elementos e ainda mantem a facilidade parapropagar um evento para todos estes elementos e parar esta propagação, senecessário. Em termos de código a estrutura a ser utilizada foi o ArrayList, um tipo deestrutura padrão do Java, o que nos garante uma boa documentação.9.2 Renderizando de forma eficiente: aceleração na GPU Ainda em TCC I, a ideia era utilizar o SurfaceView (um dos elementos paratrabalhar com interface padrão no Android) para a apresentação das diversasimagens ao usuário. Este view, apesar de ser otimizado para performance, aindaassim poderia causar situações de queda de performance. A solução na época foi a
  28. 28.   28  de restringir o que seria desenhado em cada chamada do método de desenhar,limitando a quantidade de trabalho realizada para este fim. Pensando nisso, foi criado um elemento responsável por representar oespaço nos eixos x e y que um objeto ocupasse. Com este intuito foi criado o BBox,que nada mais era do que uma classe para guardar os pontos que demarcavam ocanto inferior esquerdo e o canto superior direito de um objeto, permitindo facilmentedefinir sua área para os testes necessários. Entretanto, mesmo com esse cuidado, alguns problemas de performanceocorriam. Outro ponto importante é a complexidade que este sistema agregava aojogo. Refatorar o código, seja para reorganizar, ou por causa de novascaracterísticas, estava sendo muito custoso. Dada essa realidade, uma outra solução foi procurada. Esta solução acabousendo o uso de um outro elemento padrão para trabalhar com gráficos no Android: oGLSurfaceView (GLSurfaceView, 2011). Em relação ao SurfaceView, a mudança mais importante para oGLSurfaceView é a utilização de OpenGL. O OpenGL é um padrão amplamenteutilizado no mercado para trabalhar com gráficos que são processados por umdispositivo gráfico especializado, a unidade de processamento de gráficos (GraphicsProcessing Unit – GPU). Este processamento especializado oferece um outro nívelde performance, não somente por trabalhar com um processador especializado emgráficos, mas também por não precisar compartilhar a unidade central deprocessamento (Central Processing Unit – CPU) com outros processos do própriojogo. O padrão específico utilizado neste projeto é o OpenGL ES 1.0 (OpenGL ES1.0, 2011), que é o padrão com maior suporte entre os dispositivos com Android,uma vez que o mesmo é suportado pela plataforma desde a versão 1.0. Apesar de apresentar um novo padrão de performance para o projeto, onde,até agora, não foi necessário controlar o que deve ou não ser apresentado aousuário, essa mudança apresentou um novo grupo de desafios. O OpenGL trabalha, por padrão, com um plano cartesiano que possui trêseixos, sendo eles denominados x, y e z. O eixo x é um eixo horizontal, com o sentidode crescimento em direção para a direita. O eixo y é vertical, com o sentidocrescimento em direção para cima. O eixo z é perpendicular ao plano formado peloseixos x e y, e seu sentido de crescimento é em direção ao observador. Claro que épossível observar esse plano de outros ângulos, mas esta é a forma padrão detrabalhar com os mesmos. Para exibir imagens a uma saída, no OpenGL trabalha-se com o conceito decâmeras e cenas. Uma cena é um conjunto de objetos gráficos que são trabalhadospara serem exibidos. Uma câmera define que espaço dentro do plano que oobservador está vendo, definindo limites dentro do plano cartesiano onde os gráficosgerados são retornados ao dispositivo de saída. Essa câmera pode trabalhar commais de um tipo de projeção, que deve ser escolhida também de acordo com o queé necessário. Em uma das formas, as imagens são geradas levando emconsideração a posição do observador em relação a cena, criando um efeito deperspectiva, na outra a posição do observador não é levada em conta, criando umaimagem sem perspectiva. Esta segunda forma é a escolhida para trabalhar nestejogo que é em duas dimensões, e a aplicação de perspectiva poderia deformar asimagens. É importante lembrar que até é possível apresentar todo o espaço doOpenGL em uma tela, mas essa representação dificilmente teria algum valor prático,o mesmo pode ser dito em relação a apresentação de um nível de uma só vez. Para
  29. 29.   29  isso o sistema de câmeras deve definir qual o volume onde os gráficos geradosserão levados a tela do dispositivo. É válido lembrar que, apesar de que não vamostrabalhar com o eixo z, este volume definido na câmera deve contem algum valor emz e não zero. Por isso citamos volume, e não área. Este volume onde a câmeraconsidera válido e, portanto, ‘filma’ o nosso conteúdo é chamado de view frustum. Outro ponto importante é que o OpenGL trabalha com vértices e superfícies.Um vértice é um ponto, dentro do espaço definido pelos três planos, que define umaborda de uma superfície. Uma superfície é um conjunto de vértices, a partir dosquais é definido o seu formato. Geralmente são usados três vértices, o que resultaem um triangulo. Vértices e superfícies não possuem informação de imagens, no máximoalguma cor. Para possibilitar o uso de imagens diversas, tais como as dos blocosque compõem um nível, é necessário passar ao OpenGL uma imagem e ligar uma,ou mais, superfícies a mesma. Esta imagem dentro do OpenGL é conhecida comotextura. O que acontece é que neste projeto são trabalhadas imagens retangulares(os blocos, escadas, personagem e etc se baseiam em quadrados e retângulos,lembrando que o quadrado nada mais é do que um caso específico do retângulo),logo um triangulo não é a superfície mais recomendada as nossas necessidades.Para resolver esse problema, trabalhamos com dois triângulos encostados, o quenos permite ter a superfície adequada de forma simples e rápida. Mas nem tudo étão simples. Ao trabalhar com dois triângulos, e tentar movimenta-los ao mesmotempo, pequenas falhas na linha onde os dois se tocam podem ocorrer, gerandoerros gráficos. Logo, simplesmente gerenciar dois triângulos lado-a-lado não é amelhor opção. A solução para este caso está dentro do próprio OpenGL. Existe comodefinir um certo número de vértices e utilizar índices que indicam ao OpenGL quaisvértices utilizar para cada triângulo, nós apenas trabalhamos com esses vértices eíndices. Desta forma, criamos os quatro vértices e os seis índices, e deixamos oOpenGL cuidar deste ‘retângulo’. Para isso ser possível, além dos quatro vértices edos seis índices é preciso passar outra informação ao OpenGL, qual a forma básicaque ele irá utilizar para aproveitar esses vértices. Com isso, o problema de existir umespaço entre os triângulos deixa de existir. Tendo a superfície pronta, só falta aplicar a textura a mesma. Isso é feitoassociando os vértices anteriormente citados com as coordenadas da textura. Logo,cada ‘ponta’ da textura é associada a um vértice, o que faz com que a textura sejaaplicada ao longo de toda a superfície. Uma nota importante aqui, podemos utilizarquaisquer pontos das coordenadas da textura com os vértices que definimos para asuperfície. Essa informação será de grande valia quando formos ver o sistema deanimação. Finalizando o novo sistema de renderização encontra-se o fato de que osistema foi pensado para ser independente da resolução física do dispositivo. Esse éum cuidado já prevendo a utilização do jogo em telas de diferentes resoluções eproporções. Este sistema é feito aproveitando que o sistema de eixos do OpenGL éindependente do dispositivo utilizado para output. Neste projeto isso funciona daseguinte forma: uma câmera possui a informação da resolução física do aparelho equal o tamanho nos eixos x e y do nosso view frustum. A partir dessas duasinformações, passamos ao OpenGL que nosso viewport (a visão final para a qual anossa câmera irá desenhar) vai da posição (0,0) até (resolução x da tela, resoluçãoy da tela), garantindo que o que a câmera capturar será automaticamente
  30. 30.   30  escalonado pelo OpenGL para a nossa tela. Ou seja, o OpenGL captura a imagemutilizando nosso view frustum (que tem um tamanho arbitrário qualquer) e escalonapara nosso viewport, de forma automática e sem perdas de performance. Temosque levar em conta que, ao fazer isso, o OpenGL pode escalonar nossa imagempara uma tela maior, ou menor, do que nosso espaço virtual do view frustum. Aoescalonar, algum algoritmo deve ser aplicado para permitir este trabalho. Oalgoritmo aqui escolhido é o que utiliza a cor mais próxima, o que garante que nãohaverá um efeito de perda de definição da imagem, caso a diferença entre os doisviews seja muito grande. Por outro lado, isso pode levar aos gráficos apresentaremum fenômeno conhecido como pixelização, exemplificado na figura abaixo. A figura 10 demonstra o efeito de pixelização. A partir da imagem daesquerda a da direita é gerada e, ao escalonar a imagem, os pontos (pixels) que acompõe se tornam mais visíveis.Figura 10 – Exemplo de pixelização No jogo em questão o efeito não é um problema, na verdade é o que éesperado. Todo caso, a escolha por essa forma de trabalhar tem implicações emcomo a identificação de um toque foi feita, o que veremos a seguir.9.3 Sentindo você: um sistema para entrada de dados Um jogo, para garantir a sua interatividade, precisa prover uma forma de ousuário participar ativamente do que está ocorrendo. A plataforma Android permitediversas formas de interação com o usuário: teclado, acelerômetros e toque. Dentroda dinâmica esperada neste jogo, o toque é a opção que supre todas as nossasnecessidades. Para tanto, uma pequena coleção de classes foram criadas. • TouchEvent guarda um evento de toque. Basicamente possui o tipo de toque e a posição nos eixos x e y em que este toque ocorreu. • TouchEventPool é uma classe para pooling 5 de TouchEvent. Isso serve para tentar reutilizar os objetos de TouchEvent, diminuindo a instanciação e destruição de objetos durante a execução do jogo. • InputHandler é a classe que gerencia a entrada de dados, buscando objetos do pool, guardando-os de volta no pool e passando os objetos necessários as classes que os pedirem.                                                                                                                5  Uma  classe  utilizada  para  pooling  é  uma  classe  responsável  por  instanciar  outra  classe  e  manter  a  referência  desses  objetos,  deixando-­‐os  disponíveis  para  quando  necessário.  
  31. 31.   31  9.4 Estou tocando em você, ou não? Outro problema que é encontrado no desenvolvimento de um jogo é aquestão de para onde no jogo o input do jogador foi direcionado. No caso de umjogo baseado em toque, onde existir algum tipo de scrolling (movimento de câmera aoutras regiões do nível), o tratamento dessa entrada de dados passa por converter oponto de tela em um ponto de jogo. O ponto de jogo é onde, efetivamente para o sistema, o jogador interagiu. Apartir desse ponto é que deve ser calculado se o jogador solicitou que o personagemjogável se movimente em outra direção, ou se um bloco deve ser acionado, ou senada deve ocorrer. Na figura 11 temos uma representação da diferença entre a área de tela e aárea de toque em um jogo onde existam scrolling horizontal e vertical. Notamos queum toque em área de tela equivalente as coordenadas (X, Y) = (10, 10), não serianecessariamente o mesmo ponto em área de jogo.Figura 11 – Diferença entre a área de tela e a área de jogo Área de jogo Área de tela Para descobrir qual é o ponto em área de jogo, para então saber onde deverdade foi o toque, devemos aplicar um cálculo que permita essa conversão. Aquitemos o impacto direto de trabalhar com um sistema independente de resolução dodispositivo que rodará o jogo. Para facilmente identificar este ponto dentro doespaço de jogo, começamos normalizando o vetor do toque e transformando omesmo para uma região com a mesma área do nosso view frustum. Após isso,adicionamos a posição da tela a este vetor. Como a posição da tela está sendo,neste projeto, definida pelo ponto central da mesma, descontamos metade dotamanho do view frustum de cada eixo. Após essas operações, temos o ponto dentro do espaço de jogo definido deforma correta, e já podemos trabalhar com ele. Ter o ponto correto é o primeiro passo, o segundo é definir em qual objetoeste toque foi dado. Para tanto, temos que testar esse toque contra uma regiãodefinida para cada objeto que compõem o nível e que pode reagir a um toque. Paraeste fim, a classe que era conhecida como BBox no TCC I foi rescrita e se tornou onosso BoundingBox. A ideia por trás de um BoundingBox é definir as fronteiras deum objeto dentro do espaço de jogo, permitindo verificar se um ponto qualquer estácontido dentro de sua área.
  32. 32.   32   Para o toque no personagem principal foi verificado que a proporçãoescolhida inicialmente entre os dois views existentes criava uma área muitopequena, o que dificultava acertar o personagem. Este problema foi corrigido aomudar essa proporção, fazendo com que todos os elementos do jogo tenhamrepresentações maiores em tela. Esta sugestão veio do professor orientador e,temos de admitir, fez uma diferença considerável.9.5 Definindo Níveis Um dos objetivos do jogo é possuir 10 níveis diferentes. Para tanto, deveexistir uma forma de armazenar estes níveis de forma que seja possível edita-los demaneira simples (para permitir ajustes) e que não ocupem muito espaço (para nãoonerar demais o dispositivo do usuário). Algumas possibilidades para tanto seria o armazenamento em banco dedados, em um arquivo binário pré-compilado, um XML ou um TXT. O banco dedados poderia se tornar um pouco complexo, e nada amigável a uma rápidamodificação. O binário pré-compilado seria a forma com maior desempenho paracarregamento, mas seria necessário uma ferramenta que gerasse esse compiladointegrada ao desenvolvimento. O XML, escolhido como opção em TCC I, foidescartado em pró do TXT, uma vez que, para o design desse jogo, o XML nãoapresentava vantagens sobre o TXT, além de que o TXT é um formato mais simplesde trabalhar. Sendo assim, o TXT foi o caminho escolhido, por oferecer um meio termoentre complexidade, facilidade de edição e desempenho. Este TXT é posicional,onde cada posição em cada linha representa um espaço no nível. Comotrabalhamos basicamente com retângulos, é fácil definir um mapa em TXT aomesmo tempo que se tem ideia de como o mesmo está ficando em relação ao queserá apresentado ao usuário, vide exemplo abaixo. A figura 12 apresenta um exemplo de TXT com a definição de um nível paratestes.Figura 12 – Exemplo de um TXT com um nível para testes Para o carregamento deste TXT para um nível de jogo, algumas regrasdevem ser respeitadas: • Um espaço em branco representa um local sem item no jogo, mas o espaço vazio deve ser respeitado e levado em conta no posicionamento dos demais elementos; • Um ‘S’ representa um bloco sólido sem possibilidade de interação; • Um ‘B’ representa a posição inicial do personagem jogável. Na possibilidade de mais de um ‘B’ presente no TXT, apenas o último será considerado; • Um ‘C’ representa um bloco rachado, que pode apenas ser removido do cenário;
  33. 33.   33   • Um ‘W’ representa um bloco que pode ser ativado apenas uma vez; • Um ‘A’ representa um bloco que pode ser ativado e desativado quantas vezes o jogador julgar necessário, que inicializa desativado; • Um ‘a’ representa um bloco que pode ser ativado e desativado quantas vezes o jogador julgar necessário, que inicializa ativado; • Um ‘T’ representa um bloco que, após ativado, se mantem ativo por um intervalo de tempo; • Um ‘G’ representa o ponto de chegada (Arthur); • Um número natural entre 1 e 9 representa o índice do número de escadas a ser empilhadas. Este índice é multiplicado por quatro para se definir o número de escadas até o próximo andar.9.6 Colisão: o que acontece entre nós Colisão é o que ocorre quando dois objetos dentro do jogo se tocam. Desdeque, claro, eles possam se tocar. É comum trabalhar com mais de um plano, o quefaz que existam objetos que não colidam, assim como alguns tipos de objetos quenão colidem de forma alguma. Neste jogo, a colisão entre objetos é toda centrada nopersonagem principal. É ele que se movimenta podendo colidir com um bloco emseu caminho, é ele que pode colidir com uma escada, com o ponto de chegada e,até, com o chão, o que permite controlar se ele deve cair ou não. Para trabalhar com colisões, o BoundingBox criado para tratar eventos detoque foi modificado para testar a colisão com outro BoundingBox, uma vez que omesmo já define a área de um objeto. Mesmo podendo reaproveitar uma classe já existente, isso não resolviatodos os casos de colisão do personagem principal com o espaço de jogo. Pararesolver todos os casos, o personagem principal possui quatro BoundingBox, sendoeles: • BoundingBox padrão, com o nome de bounds: define a área exata do personagem. Utilizado para testes de toque do jogador e para verificar se, em uma queda, o personagem chegou ao chão; • BoundingBox groundBounds: utilizado para testar se o personagem ainda está caminhando sobre uma superfície. Quando o mesmo não está, ele começa a cair. Este BoundingBox está levemente deslocado para baixo no eixo y em relação ao padrão; • BoundingBox directionBounds: utilizado para verificar se o personagem bateu contra uma parede. É menor no eixo y em relação ao padrão, mas um pouco maior no eixo x. Isso evita que o personagem entre em uma parede antes de detectar a colisão; • BoundingBox ladderBounds: utilizado para testes contra escadas, para verificar se o personagem deve subir. É menor no eixo x em relação ao padrão, para evitar que o personagem suba pela escada sem estar na frente dela. Com essas quatro regiões é possível atendar a todos os casos existentes nojogo em questão.9.7 O mundo é mais que imagens estáticas: um sistema de animação
  34. 34.   34   Até agora o jogo trabalhava com imagens estáticas para todos os seusobjetos. Não que isso seja necessariamente ruim, é comum trabalhar com materialtemporário enquanto testamos um conceito ou outro ponto do sistema. Entretanto,ao entregar um jogo pronto, é esperado que os personagens se movimentem dealguma forma, refletindo o seu movimento em tela, por exemplo. Para este ponto o sistema de animação foi desenvolvido, buscandoacrescentar de forma fácil esses movimentos aos elementos do jogo. Entretanto,antes de entrar em detalhes sobre como foi feito em código a solução, vamos vercomo, em um jogo 2D, definimos os quadros de animação de um objeto.9.7.1 Sprites, o inicio do movimento Jogos 2D costumam ter suas imagens desenhadas em 2D (sem surpresasaqui). O que acontece é que para ter um personagem caminhando, por exemplo,alguém deve desenhar todos os quadros dessa animação. Por quadro de animaçãose entende uma imagem estática que representa o movimento de um objeto emdeterminado tempo. Um movimento, logo, é composto de vários quadros que, ao serem trocadosde forma ordenada, passam a impressão de movimento. Esses quadros, e aquelesque representam objetos sem animação também, possuem o nome de spritesquando trabalhamos com jogos 2D. Sendo assim, para cada movimento temos um conjunto de sprites, o que fazcom que a técnica normalmente utilizada para trabalhar com essa animação sebasear em utilizar um arquivo de imagem que agrupe todos esses sprites, arquivoeste conhecido como sprite sheet. A partir desse agrupamento, criamos uma regiãode tamanho padrão e, então, percorremos este arquivo, utilizando um sprite por vez.Abaixo temos uma ilustração desta técnica. A figura 13 demonstra um sprite sheet com o sprite que representa o quadrode animação atual selecionado.Figura 13 – Exemplo de sprite sheet com um sprite selecionado Quando o sistema de renderização estava sendo apresentado, foi citado quequaisquer pontos nas coordenadas da textura podem ser utilizados para seremligados a um conjunto de vértices. Como também já citado, para o OpenGL asimagens são texturas, logo com o sprite sheet não seria diferente. Sendo assim, épossível criar uma forma de vincular um conjunto de vértices a um pedaço específicode uma textura, permitindo o uso da técnica de animação anteriormente explicada. Osistema de animação é todo construído em torno dessa ideia, possuindo osseguintes pontos importantes: • Uma animação possui o tempo que a mesma deve levar em conta para mudar a imagem que deverá ser apresentada ao jogador;
  35. 35.   35   • Uma animação deve controlar se a mesma ocorre em loop, ou seja, se após o último quadro voltamos ao primeiro, ou se não existe loop; • Uma animação deve conter os diversos quadros utilizados para a sua necessidade. Definido como o sistema de animação deve se portar, a classe Animation foicriada, mas falta ainda definir como seriam definidos os quadros da animação. Como os quadros nada mais seriam do que regiões de uma textura, a classeTextureRegion foi criada, com o objetivo de guardar as informações necessáriassobre os diversos sprites contidos em uma textura, e poder passa-los a umaanimação. Esta classe guarda a textura que é utilizada e em quais pontos dentro dascoordenadas de textura a imagem que queremos se encontra. Essas informaçõessão posteriormente utilizadas para ligar aos vértices necessários para apresentar aimagem ao jogador. Partindo desse principio, em que todas as imagem de uma animação podemestar presentes em uma única textura, por que não centralizar todos os objetospossíveis em uma só textura? Essa abordagem trás uma vantagem importante, utilizando uma textura aoinvés de várias, temos menos chamadas para ligar a textura ao OpenGL e, portanto,menos mudança de estados, o que resulta em melhor performance. Mas o queexatamente queremos dizer com isso?9.7.2 Uma breve história no tempo: Uma explicação do OpenGL e os estados O OpenGL define uma forma padrão e eficiente de trabalhar comdispositivos gráficos especializados, mas isso já sabemos. O que vamos ver temhaver mais com a forma de como ele funciona internamente. Iremos traçar um paralelo com uma fábrica, o que é um bom exemplo. ComOpenGL configuramos um estado, que é como se fosse configurada uma fábricapara produzir um determinado produto. Uma vez feita essa configuração, bastainiciar o processo e fabricar várias peças iguais, mas em alta velocidade. Quandoocorre de precisar fabricar um produto diferente, a fábrica precisa parar e serreconfigurada, o que faz com que ela não possa produzir neste meio tempo, semfalar que é uma operação demorada. O OpenGL funciona de forma análoga. Aosetar uma configuração com um viewport, um view frustum, um padrão paraescalonar, uma textura e etc, basta apresentar a imagem resultante ao dispositivo desaída em alta velocidade (o que resulta em vários quadros por segundo, tambémconhecido como frames per second – FPS). Se precisarmos trocar de textura, cadatroca força um novo setup, o que gera uma mudança de estado, operação que émuito custosa dado a velocidade em que o OpenGL trabalha. Voltando a animação e a apresentação de imagens ao jogador, vamos,então, colocar todos os objetos possíveis no menor número de texturas, evitandoquedas de performance por mudança de estados. Para possibilitar o trabalho comessas (utilizando uma expressão comum em fabricação em fábricas) bateladas, aclasse SpriteBatcher foi criada. Ela é a ponte entre o sistema de animação, e asoutras imagens apresentadas ao jogador, para o OpenGL.
  36. 36.   36  9.7.3 Detalhes tão pequenos de nós dois, ou mais: como funciona a animação Agora que temos o sistema de animação definido, podemos explicar comotodo o sistema de animação e renderização funciona em sua versão final. Tudo inicia com a classe Game, que é responsável pelo bootstrap6 do jogo.Essa classe estende a classe Activity, que é uma classe padrão Android para umaatividade, e implementa a interface Renderer, que é a interface que devemosimplementar quando queremos que uma classe possa ser usada como umrenderizador para a classe GLSurfaceView (mais sobre essa classe adiante). Nesta classe Game é configurado que o jogo utilizará a tela cheia dodispositivo, escondendo a barra de status do sistema, também é configurado quenão haverá a barra de título, com o nome do aplicativo. Como estendemos Activity,passamos a instância de Game para o construtor do GLSurfaceView e após, porimplementarmos Renderer, setamos a instancia de Game como renderizador danossa instância do GLSurfaceView. O GLSurfaceView é uma classe padrão do Android que representa umasuperfície OpenGL para trabalharmos. O Android roda seus processos em umthread a parte, sem que precisemos fazer toda essa configuração. Outraresponsabilidade do Android é fazer o loop que garante que o método onDrawFrame(que é utilizado para desenhar no dispositivo de saída) seja chamado o maiornúmero de vezes possível. Esse método, junto com alguns outros utilizados peloGLSurfaceView, estão presentes na classe Game, pois são os métodos queprecisamos implementar da interface Renderer. O motivo de concentrar Activity e Renderer na classe Game é facilitar ogerenciamento do jogo, outras implementações podem separar esses elementos seassim acharem necessário. Tendo essa inicialização feita, guardamos a instancia do GLSurfaceView emum objeto auxiliar: Graphics. A partir deste, podemos facilmente acessar o próprioGLSurfaceView e algumas de suas propriedades mais utilizadas (largura e altura).Claro, uma classe somente com esse intuito não teria o por que de existir. A classeGraphics vai um pouco mais longe, guardando a instancia de OpenGL ES 1.0(GL10) que utilizaremos em nosso processo. Assim, as classes relacionadas aosgráficos ficam agrupadas em um mesmo objeto. Uma observação importante é que recebemos uma nova instancia da classeGL10 toda vez que a superfície é criada (método onSurfaceCreated). Isso significaque toda a vez que nosso jogo perde o foco do dispositivo (quando, por exemplo,uma ligação é recebida), perdemos a superfície que temos (nossa instância de GL10é invalidada). Logo, devemos sempre trabalhar com a instancia recebida por essemétodo. Esse comportamento se dá por uma escolha da plataforma, e que fazsentido: quando perdemos o foco, nossa aplicação não se apresenta na tela dodispositivo, logo não existe porque um processo que só serve para gerar imagens semanter rodando, consumindo recursos de forma desnecessária. Todo caso, essa instancia de OpenGL é que será utilizada no nossoprocesso de renderização. Ela é nossa instancia do OpenGL, e é ela responsávelpor receber todas as informações que resultarão em um belo jogo animado na telade um smartphone.                                                                                                                6  No  desenvolvimento  de  software,  uma  classe  responsável  pelo  bootstrap  é  a  classe  que  inicializa  as  outras  necessárias  e  garante  que  o  sistema  seja  inicializado  de  forma  correta.  
  37. 37.   37   Garantindo o acesso ao OpenGL, podemos começar a criar nossarepresentação gráfica, para isso duas outras classes servem de base: Stage eStageRenderer. A classe Stage representa uma abstração padrão de um nível de jogo. Elaguarda as instancias de todos os objetos num nível, e é responsável por passar oevento de atualização a todos eles. O Stage, também, executa os testes de colisão enotifica os outros objetos conforme necessário. Por fim, o Stage é responsável porreceber um StageFile, que é um estágio carregado a partir de um arquivo TXT, epopular o nível com os objetos de acordo com o definido. O StageRenderer recebe a instancia de Stage, de Graphics e doSpriteBatcher (mais sobre este último mais adiante). Ele é responsável posicionar acâmera dentro do espaço de jogo, capturar o OpenGL e setar algumas opções,iniciar a batelada, passando a textura a ser utilizada pelo SpriteBatcher, passar osobjetos a serem desenhados ao SpriteBatcher e chamar o método do SpriteBatcherque desenha a nossa tela. No processo de buscar os objetos ao SpriteBatcher, oStageRenderer busca as regiões de textura (TextureRegion) a serem utilizados,fazendo chamadas aos diversos objetos e suas respectivas classes de animação(Animation). Para facilitar o trabalho com as diversas texturas e regiões de texturas aclasse AssetCollection foi criada. A mesma possui uma coleção estática de objetos aserem utilizados dentro do jogo. Atualmente a coleção inclui Animation, Texture eTextureRegion. Em breve teremos a inclusão das classes relativas aos efeitossonoros e músicas.9.8 Produzindo os gráficos e uma descoberta Após a definição do sistema de animação, chegou o momento de produziras imagens que são utilizadas no jogo. Essas imagens deveriam conter um mínimode elementos para que fosse possível representar todos os elementos do jogoconforme o GDD. Durante algum tempo, existiu um bom número de tentativas de produzir umaarte original, mas foi algo que não se provou produtivo. Apesar de todo o esforço,uma verdade ficou: faltou talento para desenhar. Para que o jogo não ficasse sem asimagens necessárias, o que poderia comprometer o trabalho, a solução foi buscaressas imagens em algum lugar na internet. Foram encontrados dois conjuntos de imagens, um proveniente do‘WidgetWorx’ (WidgetWorx, 2012), disponíveis com uma licença ‘Common PublicLicense’ versão 1.0 (CPL, 2012), o outro conjunto proveniente de ‘The SpritersResource’ (TSR, 2012), disponíveis sem uma licença específica. É importante frisarque o jogo não será publicado com nenhuma imagem pertencente a essesconjuntos. O que será realizado, como trabalhos futuros, é a contratação de umprofissional para este fim: produzir os diversos elementos gráficos do jogo. Sendo assim, o que temos atualmente pode ser visto como imagens do tipoplace holder em versão de luxo. Em especial por conta do segundo conjunto deimagens, o qual se mostrou uma surpresa.
  38. 38.   38  9.8.1 Benchmarking Como citado anteriormente, o segundo conjunto de imagens foi umainteressante surpresa. Talvez, até mais do que isso. É muito comum, em termos detrabalhos diversos, que existam sistemas com funcionalidades próximas a um novosendo produzido, ou até mesmo um concorrente para o mesmo segmento quedesejamos atender. Neste caso, é comum que certas similaridades ocorram. Omesmo pode ocorrer com jogos. Jogos eletrônicos existem a mais de 30 anos, conforme podemos verificarpela data de lançamento do Atari, por exemplo. O Atari (Atari, 2008) foi lançado em1977 e é considerado o primeiro console de grande sucesso. Isso faz com quemuitas ideias já tenham sido convertidas em jogos. Algumas vezes, esses jogosusam hardware adicional em relação a aquele lançado inicialmente, e o mouse doSuperNES (SNES), um console da Nintendo, é um exemplo desse tipo de hardware. O mouse do SNES foi lançado em 1992 e recebeu uma coleção de jogosque utilizavam o dispositivo. Entre eles um conhecido como ‘Mario & Wario’, lançadooficialmente somente no Japão em 1993. O jogo em questão, publicado pelaNintendo, possui premissas praticamente idênticas a do jogo deste trabalho: umpersonagem que não pode enxergar deve ser guiado por um cenário. Entretanto, otrabalho da Nintendo possui algumas diferenças: • Um personagem vilão (Wario) cobre a cabeça do personagem jogável com um objeto (balde, casca de ovo, etc); • Como o jogo não é para telas de toque, e sim para ser jogado com um mouse, um ponto de referencia é necessário, neste jogo o ponto é uma fada, que é controlada pelo jogador; • Existem 3 personagens selecionáveis, cada um representando um nível de dificuldade (existe uma diferença na velocidade de caminhar entre eles); • Existem blocos com tamanhos variados; • Existem blocos com outros efeitos (andar mais rápido, escorregar); • Existem combates com o personagem vilão em batalhas; • Existem moedas a serem coletadas ao longo das fases; • Existem inimigos que devem ser impedidos de tocar o personagem principal ao longo das fases. O jogo da Nintendo em questão foi jogado utilizando-se de emulação, o quepermitiu a coleta dessas informações. Tendo esse conhecimento em mãos, a decisão foi em tornar o ‘Mario &Wario’ um benchmarking para o jogo desenvolvido neste trabalho. Ter uma basepara comparações permite explorar onde há possibilidades de melhorias e nãocometer os mesmos erros que em outras plataformas. Todo caso, uma dúvida legítima ficou neste caso. Ao longo desses 31 anos,muitos jogos foram jogados. Alguns com mais dedicação, outros apenas paraconhecer. É possível que tenha existido um contato anterior com o ‘Mario & Wario’, eisso tenha influenciado o conceito desenvolvido aqui. Entretanto, não existemrecordações sobre o mesmo.
  39. 39.   39  9.9 Eu posso ouvir você: um sistema sonoro Sons fazem parte do nosso dia-a-dia, e estão associados aos mais diversoseventos. Uma corda que vibra (violão), uma borracha sendo utilizada paradesacelerar uma grande massa (um carro freando), e etc. Nada mais natural de tersons associados a eventos em nosso jogo, mais uma música de fundo para animar oclima. A plataforma Android disponibiliza duas classes para trabalhar com sons,uma mais adequada para músicas, MediaPlayer (MediaPlayer, 2011), e outra maisadequada para efeitos sonoros, SoundPool (SoundPool, 2011). Ambas são fáceis delidar, mas para simplificar o seu uso neste jogo, duas classes foram criadas Music eSoundFX. A classe Music serve para controlar as músicas que tocarão no jogo. Elaencapsula MediaPlayer, adicionando algumas facilidades para o tratamento com osom. Já SoundFX serve para os efeitos sonoros do jogo. Ela recebe uma instânciade SoundPool e o identificador de um efeito sonoro presente no SoundPool, assimagrupando os pré-requisitos para executar um efeito sonoro.9.9.1 Produzindo sons Os sons que devem acompanhar os diversos acontecimentos no jogo, seja amúsica de fundo, que não teve distrair o jogador, ou os diversos efeitos sonoros,devem possuir um mesmo tema. Isso significa que os sons não podem seremdiscrepantes num sentido de que um som seja típico de desenhos animados, e outrode um disparo extremamente realista. E, claro, os sons devem acompanhar o estilodo jogo, sendo tão alegres, ou sinistros, quanto o ambiente a ser criado. O programa utilizado, GarageBand, possui um grande número de sons parapossibilitar a montagem de músicas em diversos estilos. Alguns desses sonspossuem a denominação de cartoon, ou seja, desenho. Estes sons de desenhoforam a base para as montagens e cortes utilizados no jogo. O Audacity auxiliounesta tarefa permitindo um corte mais fácil de segmentos de sons e a conversãopara um formato melhor para trabalhar com a plataforma Android.9.10 Sistema de menus O sistema de menus deve atender o diagrama de caso de uso presente noitem 7.2.1 deste trabalho. Para tanto, algumas imagens tiveram de ser criadasespecificamente para este fim. Estas imagens representam a possibilidade de ir apróxima tela, retornar, tentar novamente um nível, ativar e desativar o som e ver oscréditos. O sistema de menus funciona com o toque, entretanto não utiliza a dinâmicade arrastar para mostrar outros conteúdos, como poderia ter sido realizado na telade seleção de fases. Mas vamos entrar em mais detalhes sobre as telas,comentando uma a uma. A primeira tela é a tela de logo. Nela apresentamos o nosso logotipo, paraque o jogador possa identificar quem é o responsável pelo jogo. Não há nenhum tipode interação nesta tela, a mesma fica presente durante um tempo pré-determinado edepois dispara a próxima tela. Na figura 14 abaixo, a tela em questão.
  40. 40.   40  Figura 14 - Tela de logotipo (logo) Logo após transcorrido o tempo da tela de logo, a tela que é apresentada aojogador é a tela de título. Esta tela mostra o título do jogo, possibilitando facilmenteidentificar o jogo a ser jogado. Neste tela é possível acessar os créditos, pelo itemde menu que se assemelha a um ‘i’, ativar e desativar o som, pelo ícone que seassemelha a uma caixa de som, e entrar na tela de seleção de fase, no ícone que seassemelha a uma seta apontando para a direita. Ainda sobre o som, o retorno visualde que o som está ativo ou não acontece no próprio ícone que representa o som:linhas que representam o som saindo da caixa significa que o som está ativo, um ‘x’ao lado da caixa representa que o som não está ativo. A figura 15 abaixo demonstraa tela de título.
  41. 41.   41  Figura 15 - Tela de título A próxima tela que abordaremos é a de seleção de nível (figura 16). Nestatela é possível voltar a tela de título, utilizando a seta apontando para a esquerda, ouselecionar e entrar em um dos níveis disponíveis. Os níveis estão disponibilizadosem um formato que lembra um rolo de filme. É uma metáfora que ainda funciona,mas que no futuro, com a falta de filmes físicos neste formato, pode não dar tãocerto. Para selecionar uma fase é necessário tocar nos cantos do rolo, e a próximafase rola até a visão do usuário. Uma vez centralizada na tela, basta tocar no nívelpara inicia-lo. Entretanto, existe um mecanismo que limita o acesso a um próximonível: um novo nível só se torna disponível após o nível imediatamente anterior aomesmo for vencido. Centralizado sobre o quadro que representa o nível existe o número do nívele sua melhor pontuação. Pelo número do nível o jogador sabe onde está, e apontuação permite que ele possa rapidamente verificar qual foi o seu melhordesempenho em um nível qualquer. No caso de ser um novo nível, ainda nãojogado, a pontuação aparece zerada (um zero), indicando que o jogador ainda nãopossui pontuação na mesma.
  42. 42.   42  Figura 16 - Tela de seleção de nível Após a seleção de um nível, chegamos a tela de jogo (figura 17). O jogoinicia em um estado de espera. Assim que o jogador realiza o primeiro toque emtela, o jogo começa a acontecer (Bob começa a caminhar) e, então, o jogador devefazer o possível para conquistar esse nível. A tela de jogo possui mais um deestado: a espera inicial, onde o jogo aguarda o toque inicial do jogador, o estado dejogando, onde Bob caminha pelo cenário e deve ser guiado, o estado de pausado,onde o jogador pode dar um tempo para descansar, o estado de nível conquistado eo estado de perder o jogo, quando Bob cai em algum buraco. A tela com o estado de jogo rodando é igual a de estado de jogo em esperainicial (figura 17). A diferença para a espera inicial é que Bob está ativamente semovimentando e o jogador deve guia-lo. Durante esse estado, um ícone de pausafica disponível na parte superior esquerda da tela para que o jogador possa pausar ojogo assim que necessário.
  43. 43.   43  Figura 17 - Tela de jogo Ao tocar o ícone de pausa, a tela de pausa é apresentada ao jogador (figura18). Nesta tela existe uma mensagem avisando que o jogo está pausado e trêsícones para ações: uma seta apontando para a esquerda, que serve para voltar atela de seleção de fase, uma seta apontando para a direita, que serve para voltar aojogo atual, e uma flecha girando, que serve para reiniciar o nível. Esta tela tambémaparece automaticamente se o jogo perder o foco do dispositivo, seja por umaligação ou outro evento. Desta forma, ao voltar ao jogo, o jogador tem tempo parafocar novamente na tarefa que estava realizando no nível em questão.
  44. 44.   44  Figura 18 - Tela de pausa Existem duas alternativas de final de nível: conquistar o nível ou perder onível. Para cada condição uma tela diferente é apresentada ao jogador. A tela de fim de jogo (figura 19) é apresentada quando o jogador perde onível. Esta condição é alcançada quando Bob cai em algum buraco existente em umnível. Nesta tela, junto com a mensagem de fim de jogo, dois ícones estãodisponíveis: uma seta apontando para a esquerda, para retornar a tela de seleçãode nível, e uma flecha girando, para tentar novamente o nível atual.

×