Técnicas de Desenvolvimento de Games para Android

Transcrição

1 IV SRST SEMINÁRIO DE REDES E SISTEMAS DE TELECOMUNICAÇÕES INSTITUTO NACIONAL DE TELECOMUNICAÇÕES INATEL ISSN AGOSTO DE 2016 Técnicas de Desenvolvimento de Games para Android Leandro Castelli Silverio 1, Márcio Emílio Cruz Vono de Azevedo 2 Abstract This document describes graphical technics and Design Patterns to develop games to Android devices. A description of the OpenGL ES versions supported by Android platform is made and also your inner workings. Besides, the Game Loop pattern, which is commonly used to develop games, is described and some variances of the implementations is presented. Index Terms Android, Games, Game Pattern, OpenGL ES. Resumo Este documento descreve técnicas gráficas e padrões de desenvolvimento para Games em dispositivos Android. É feita uma descrição da API OpenGL ES suportadas pela plataforma Android e do seu funcionamento. Além disso é descrito o padrão de Game Loop e suas variações, utilizados constantemente em games. Palavras chave Android, Games, OpenGL ES, Padrões de Desenvolvimento. I. INTRODUÇÃO O mercado de games mundial vem crescendo a cada ano (movimentou US$ 91,5 bilhões em 2015, aumentando em 9,4% em relação ao ano anterior [1]) e já pode ser comparado ao rendimento da indústria cinematográfica. Esse mercado atinge todas as faixas etárias, principalmente adultos entre 18 e 49 anos (aproximadamente 50% dos jogadores) porém também atinge pessoas acima dos 50 anos (cerca de 25% dos adeptos)[2]. O que demostra que já não é mais considerada uma brincadeira somente de crianças. Outro mercado de destaque nos últimos anos foi o de smartphones, desde 2011 o número de aparelhos cresceu muito. Em 2015, mais de 1,6 bilhões de pessoas faziam o uso dessa tecnologia [3]. Além das muitas utilidades dos smartphones, eles entraram no mercado como uma nova plataforma de games, concorrendo com os portáteis (Nintendo DS, PS Vita entre outros) e alcançando pessoas que não eram adeptas aos games[4]. Dentre os smartphones, podemos destacar a plataforma Android, desenvolvida pela Google que possui 82.5% da fatia desse mercado [5]. Por ser um sistema Open Source, baseado no kernel do Linux, ele possui uma comunidade de desenvolvedores ativa e uma vasta documentação que auxilia no desenvolvimento de aplicações e jogos. Trabalho de Conclusão de Curso apresentado ao Instituto Nacional de Telecomunicações, como parte dos requisitos para a obtenção do Certificado de Pós-Graduação em Engenharia de Redes e Sistemas de Telecomunicações e Desenvolvimento. Orientador: Prof. Márcio Emílio Cruz Vono de Azevedo. Trabalho aprovado em 08/2016. Outro incentivo para se desenvolver para o Android é a Google Play Store. Aberta em 2008 para o público, é uma loja de software online que habilita os usuários a procurar e instalar aplicativos de terceiros[4]. A Google Play Store permite que desenvolvedores publiquem o seus aplicativos de maneira gratuita ou paga, sendo assim uma maneira simples dos desenvolvedores distribuírem o seu trabalho em todo o mundo. Desde o seu lançamento em 2008, o Android tem recebido várias versões de atualização, introduzindo novas funcionalidades e suporte a novas tecnologias a cada versão [6]. Isso mostra que a plataforma está em constante desenvolvimento e facilita para que seja portada para diferentes tipos de dispositivos. Apesar dessas atualizações serem importantes, elas criam um problema de compatibilidade para os desenvolvedores, já que algumas tecnologias e características mudam entre as versões. Assim como os diferentes tipos de dispositivos criam a necessidade de se desenvolver pensando em diferentes tamanhos de telas, quantidade de memória, número de processadores. Algo que não atinge tanto o ios, seu principal concorrente. Contudo, o objetivo desse trabalho é mostrar técnicas que são usadas para desenvolvimento de jogos para a plataforma Android. Buscando um bom desempenho mediante a diferentes tipos de hardware e versões de Android, assim como uma boa aceitação dos usuários. Dentre os assuntos abordados, podemos citar a biblioteca gráfica OpenGL ES, que consiste em uma versão reduzida da API OpenGL, com o intuito de ser usado em dispositivos embarcados[7]. Além do estudo do Game Loop que é um padrão de desenvolvimento fortemente usado em todos os tipos de games. II. INTERFACE GRÁFICA As APIs do Android framework proveem uma série de 2Ddrawings APIs que permitem renderizar a parte gráfica da sua aplicação, permitindo desenhar e fazer animações gráficas através de sua API. [8] Provendo tipicamente duas opções: Desenhar e fazer animações em uma View de seu layout. Dessa forma, a responsabilidade de desenhar a parte gráfica da aplicação é do próprio processo de desenho hierárquico da View. Essa opção é mais indicada para aplicações estáticas ou que já contém animações previamente definidas[8].

2 Desenhar a parte gráfica diretamente na tela utilizando a API de Canvas. O Canvas funciona como uma representação da própria tela onde a parte gráfica vai ser desenhada. A utilização dessa API geralmente é utilizada quando a aplicação/jogo necessita redesenhar-se regularmente[8]. Apesar de apresentar uma performance melhor do que desenhar na própria View, utilizar a API de Canvas possui algumas limitações. Ao se tratar de jogos mais complexos ou com um intenso processamento gráfico, a API não consegue manter um bom desempenho. Além de performance, ela não provê suporte a gráficos 3D. Para contornar essa limitação, a plataforma Android provê suporte a API OpenGL ES (Open Graphics Library for Embedded Systems). OpenGL ES é uma API de desenvolvimento de gráficos 3D para sistemas portárteis e dispotivios embarcados. Ela é a API gráfica dominante nos smartphones atuais, ela é atualmente suportada em diversas plataformas, como Android, ios, Blackberry, bada, Linux e Windows[9]. Ela é baseada na OpenGL API, que é fortemente utilizada em desenvolvimento de jogos de alto desempenho, pois ela utiliza a aceleração de hardware, que é muito superior a qualquer software de renderização[12]. A. OpenGL ES A API foi criada e é mantida pelo Kronos Group que consiste em um conglomerado que contém empresas como NVIDIA, ATI e Intel[10]. Essa API consiste em uma série de procedimentos e funções que permite o programador a especificar os shaders, objetos e operações envolvidas em produzir imagens gráficas de alta-qualidade, especificamente imagens em cores de objetos tridimensionais[11]. A OpenGL é uma API muito grande e complexa, o objetivo da OpenGL ES foi reduzir essa API para que fosse possível utiliza-la em dispositivos portáteis e embarcados. Para que esse objetivo fosse alcançado, todas as redundâncias da API OpenGL foram removidas e, em caso de alguma operação poder ser realizada de mais de uma maneira, somente o método mais útil foi mantido[9]. Essa API provê C header files especificando como essa API deve se comportar. Sendo assim, fabricantes de hardware usam essa especificação para implementar as Unidades de Processamento Gráfico (GPU)[4]. As GPUs modernas aceleram quase todas as operações providas pela OpenGL ES, armazenando dados e imagens de framebuffer na memória da GPU e executam os shaders nos processadores gráficos dedicados[11]. A qualidade dessa implementação costuma variar de acordo com o fabricante da GPU, o que pode vir a causar alguns problemas relacionados especificamente a GPU, não tendo relação com o Android em si mas sim com os drivers providos pelos fabricantes de hardware[4]. OpenGL ES 2.0: Suportada em dispositivos Android a partir do versão 2.2 (Android API 8) da plataforma Android. OpenGL ES 3.0: Suportada em dispositivos Android a partir do versão 4.3 (Android API 18) da plataforma Android. Porém, requer uma implementação do fluxo gráfico pelo fabricante, ou seja, um dispositivo com Android 4.3 ou acima pode suportar ou não essa versão da especificação. OpenGL ES 3.1: Suportada em dispositivos Android a partir da versão 5.0 (Android API 21) da plataforma Android. Sendo assim, ao iniciar o desenvolvimento de uma aplicação/jogo utilizando as funcionalidades da API OpenGL ES, primeiramente é necessário definir qual versão da API será suportada. Para auxiliar essa escolha, a Google disponibiliza a porcentagem de dispositivos ativos com cada versão da plataforma Android e também com a versão de OpenGL ES suportada [6]. Na Tabela 1, temos a porcentagem de cada versão da plataforma Android em dispositivos ativos, sendo que na Figura 1 temos a representação gráfica dessa porcentagem. TABELA I VERSÕES DE ANDROID EM DISPOSITIVOS COLETADOS DURANTE UM PERÍODO DE 7 DIAS ATÉ 4 DE ABRIL DE 2016[6]. B. Versões de OpenGL ES No contexto da plataforma Android, várias versões da API são suportadas, dependendo da versão da plataforma Android[13]: OpenGL ES 1.0 e 1.1: Essas versões da especificação da API são suportadas a partir do Android 1.0.

3 Figura 1- Gráfico com as versões de Android coletadas durante um período de 7 dias até 4 de abril de 2016 [6]. Na Tabela 2 é mostrado a porcentagem de versões da API OpenGL ES suportada em dispositivos ativos. Sendo que na Figura 2 temos a representação gráfica desses dados. TABELA II VERSÕES DE OPENGL ES SUPORTADAS COLETADAS DURANTE UM PERÍODO DE 7 DIAS ATÉ 4 DE ABRIL DE 2016[6]. Figura 2 - Gráfico vom as versões de OpenGL ES coletadas durante um período de 7 dias até 4 de abril de 2016[6] Todas as versões de OpenGL ES mencionadas proveem interfaces gráficas de alta performance para a criação de jogos, visualizações e interface de usuários. A programação utilizando as versões de API 2.0 e 3.0 são bastante semelhantes, com a versão 3.0 representando uma extensão da versão 2.0 com algumas características adicionais[13]. Porém, outros fatores devem ser levados em consideração ao escolher qual versão de API utilizar: Desempenho: No geral, as APIs 2.0 e 3.0 apresentam um desempenho gráfico mais rápido em relação as APIs 1.0/1.1. Contudo, essa diferença de desempenho pode variar de acordo com o dispositivo Android que a sua aplicação está rodando, devido às diferenças de implementação por parte dos fabricantes de hardware da especificação OpenGL ES (como já mencionado anteriormente)[13]. Compatibilidade de dispositivos: o desenvolvedor deve levar em consideração os tipos de dispositivos, versões de Android e versões suportadas de OpenGL ES que ele quer atingir[13]. Conveniência de Código: as versões 1.0/1.1 da API OpenGL ES proveem um fluxo de funções fixa e convenientes que não estão presentes nas versões 2.0 e 3.0. Novos desenvolvedores que não estão acostumados a programação OpenGL tendem a achar mais conveniente utilizar essas versões [13]. Controle Gráfico: A OpenGL ES 2.0 e 3.0 permite um alto grau de controle provendo um pipeline totalmente programável através do uso de shaders. Com esse controle mais direto do pipeline de processamento gráfico, os desenvolvedores conseguem criar efeitos que seriam muito difíceis de serem criados nas versões de OpenGL ES 1.0/1.1 [13]. Suporte a Texturas: A API OpenGL ES 3.0 contempla o melhor suporte à compressão de texturas já que ela garante o suporte ao formato de compressão ETC2 (Ericsson Texture Compression 2), que suporta transparência. As outras versões da API geralmente incluem suporte ao ETC1, que não contempla transparência, e tipicamente provê recursos em outros formatos de compressão suportados pelos dispositivos alvos [13][14]. C. Desenvolvimento Java e Desenvolvimento Nativo A plataforma Android suporta a API OpenGL ES (e todas as suas versões) de duas maneiras: através do próprio framework Android utilizando a linguagem de programação Java ou através do Native Development Kit (NDK) que utilizando linguagem nativa (C/C++)[13]. Como a API OpenGL ES é uma API provida em C, ela é acessada pelo framework através de uma chamada JNI (Java Native Interface). Isso significa que qualquer chamada a API OpenGL ES através do framework Android passa por essa JNI que chama diretamente a API OpenGL nativa em C. Nas primeiras versões de Android, essa operação poderia ser custosa mas evoluiu com as versões mais recentes da plataforma (apesar de ainda gerar um processamento a mais)[4]. Apesar da pouca diferença de performance mencionada e da facilidade do desenvolvimento em Java que é uma linguagem que trabalha em nível de aplicação, desenvolver diretamente com a API OpenGL ES em linguagem nativa pode ser interessante devido ao controle maior da API (muitas vezes a

4 implementação da chamada OpenGL ES via JNI contém chamadas adicionais) e da portabilidade para outras plataformas (muitos desenvolvedores criam uma biblioteca em C/C++ para que se possa portar para outras plataformas)[12]. D. Conceitos de OpenGL ES O OpenGL funciona como uma câmera mostrando uma cena. Essa cena é composta por objetos e cada um desses objetos possuem uma posição e diferentes materiais e texturas. Essa câmera também possui propriedades como posição, orientação, campo de visão, resolução de imagem entre outros[4]. A Figura 3 mostra uma representação abstrata de uma cena OpenGL. Figura 3 - Representação abstrata de uma cena OpenGL [4] Na figura 3, a câmera é representada pela figura do olho, e assim como os outros objetos na cena, possui uma posição relativa à origem da cena. A pirâmide demostrada na figura representa o quanto da cena é captado pela câmera e a orientação da mesma. A esfera branca no fundo da imagem representa a fonte de luz da cena, que também possui uma posição relativa à origem. Podemos descrever essa cena com os seguintes elementos[4]: Objetos (modelos): compostos por quatro características[4]: o Geometria: especificada por um conjunto de triângulos, cada triângulo é composto por três pontos no espaço 3D, essas coordenadas são relativas à origem da cena. o Cor: geralmente especificada no sistema RBG. o Textura: é um container de uma ou mais imagens aplicada sobre o objeto. o Material: o material do objeto influencia como a luz é refletida no mesmo. Luz: na API OpenGL ES são oferecidos alguns tipos de iluminação com alguns atributos. Esses pontos de iluminação são objetos matemáticos com posição e/ou direção no espaço 3D. Câmera: Assim como o ponto de iluminação, é um objeto matemático que possui uma posição e uma orientação no espaço 3D. Como um de seus parâmetros, é definido quanto da cena será mostrado na imagem final. Como demonstrado na figura 3, a pirâmide demonstra a parte da cena que será mostrada. Janela de exibição(viewport): Ela é a definição do tamanho e resolução da imagem final. E. Projeções Como mencionado anteriormente, uma cena OpenGL é definida em um espaço 3D. Para mapear essas coordenadas para a tela, o OpenGL precisa saber quais são essas coordenadas no framebuffer que é baseado em pixels. Sabendo quais são essas coordenadas, ele simplemente pode desenhar os objetos da cena diretamente no framebuffer. Esse processo é chamado de projeção e os tipos frequêntimente utilizados são[4]: Projeção Paralela (Ortográfica): Esse tipo de projeção é comumente utilizada para renderizar gráficos 2D. Ela não leva em consideração a distância que o objeto está da câmera, o objeto sempre terá o mesmo tamanho na imagem final. Projeção Perpectiva: Já nesse tipo de projeção, a distância é levada em consideração. Ou seja, quanto mais longe o objeto estiver da câmera, menor ele irá aparecer na imagem. Esse tipo de projeção é mais utilizado em renderizações 3D. Independentemente de qual tipo de projeção é utilizado, o OpenGL utiliza um mecanismo parecido com a retina humana chamado plano de projeção (Projection Plane). Esse plano de projeção é representado na figura 3 como o retâgulo próximo a câmera e é nele que o OpenGL irá projetar os pontos que serão desenhados da cena. Essa área é chamada de near clipping pane e tem o seu próprio sistema de coordenadas. A Figura 4 mostra uma representação do plano de projeção[4]. Figura 4- Near Clipping Pane ou Plano de projeção[4] Na Figura 5 é demostrada a diferença entre a projeção perspectiva e a projeção paralela.

5 Figura 5 - Representação da projeção perspectiva e paralela[4] F. Vértices e Matrizes Na API OpenGL, objetos geométricos são representados usando vértices. Nesse contexto, um vértice (na terminologia OpenGL vertex) é determinado por uma série de atributos genéricos. Dentre esses atributos podemos encontrar coordenadas de posição, cores, coordenadas de textura e qualquer outro atributo relacionado com aquele ponto no espaço. Sendo que para definir o posicionamento desse vertex são utilizadas quatro coordenadas. [4][11][15][16]. Para que a cena no mundo OpenGL seja manipulada, são aplicadas matrizes nos pontos dos nossos modelos. Esses pontos são transformados por matrizes 4x4. No OpenGL ES três diferentes tipos de matriz são aplicadas[4][15]. G. Model-View Matrix Essa matriz é utilizada para mover, rotacionar, escalar os pontos dos objetos geométricos. Além disso, ela é utilizada para especificar a posição e orientação da câmera[4]. Vamos usar como exemplo uma cena que precise de quatro triângulos representados em diferentes posições e orientações. Como é sabido, cada triângulo é representado por três vértices. Para que esses triângulos sejam representados seriam necessários 12 vértices mapeados em coordenadas OpenGL como mostrado na Figura 6[17]. Mas, no caso desses triângulos precisarem serem duplicados 20 vezes, 60 vértices precisariam ser armazenados. O que poderia piorar a situação seria a representação de um objeto mais complexo formado por vários triângulos e que precisasse ser replicado em várias posições, orientações e tamanhos diferentes.[17] Para resolver esse problema, ao invés de armazenar a posição de todos os vértices, são aplicadas matrizes de transformação para que se possa transportar, escalar e rotacionar os objetos[4][17]. Sendo o vertex representado pelo vetor x,y,z,w, para que seja transportado em T, sendo que T é representado por tx, ty, tz,1, podemos multiplicar o vertex pela matriz representada na Figura 7. Figura 7- Matriz de transporte [15] Já no caso da Escala, é possível que o objeto fique mais estreito, seja ampliado em qualquer um dos três eixos utilizando a matriz representada na Figura 8[15]. Figura 8 - Matriz de escala [15] Além da escala e do transpote, é possível que o objeto seja rotacionado em qualquer um dos eixos. Porém, nesse caso, são definidas matrizes diferentes dependendo do eixo a ser rotacionado. Na Figura 9, as matrizes representam rotação nos eixos Ox, Oy e Oz respectivamente[4][17]. Figura 6 - Representação de quatro triângulos com diferentes posições e orientação [17] Figura 9- Matrizes de rotação nos eixos Ox, Oy e Oz [17] Ao aplicar mais de uma matriz em um objeto, a ordem que a API de OpenGL ES multiplica as matrizes dita a ordem de que as operações são aplicadas no modelo. A última matriz ativa será a primeira a ser aplicada no modelo[4]. Além das transformações no modelo, essa matriz também é responsável por especificar a posição e orientação da câmera. É ela que controla o modo que a cena é mostrada. Assim como

6 na transformação, ela é representada por uma matriz 4x4 e é determinada por 3 parâmetros[4][17]: O olho, ou a posição do observador. O padrão é (0,0,- 1). O centro, ou o ponto de foco da câmera, cujo padrão é (0,0,0). O up, que define a parte superior do observador que por padrão é dado pelo valor positivo no eixo Oy (0,1,0). H. Projection Matrix Responsável pelo tamanho da cena que será mostrada, essa matriz controla o chamado view frustrum que é representado pela pirâmide na Figura 3. Ela é responsável por definir os limites da cena que serão mostrados, (Near, Far, Left, Right, Up, Down Clipping Pane). Toda a parte da cena fora desses limites representados pela pirâmide são descartados pelo OpenGL. Esse processo é chamado de clipping [4][15][17]. I. Texture Matrix Utililzada no mapeamento de texturas aos objetos OpenGL. Para esse mapeamento, é necessário que em cada vertex do objeto seja aplicada uma coordenada da textura. Cada textura carregada no OpenGL é mapeada por essas coordenadas tendo sua origem no canto superior esquerdo (0,0) e o seu final no canto inferior direito (1,1)[4]. J. OpenGL Pipeline Na versão da API do OpenGL ES 1.0 a pipeline (estágios de processos) de renderização era um sistema de função fixas. É sempre seguido um fluxo de operações até a renderização completa da imagem. Na figura 10 temos a representação simplificada dos estados e processos para a renderização de um triângulo no OpenGL ES 1.0/1.1.[4][15]. Figura 10- Representação da renderização de um triângulo no OpenGL 1.0 [4] Como discutido anteriormente, as matrizes de estado são aplicadas aos vértices do objeto. Primeiramente o triângulo é transformado pelas matrizes de Model-View, movendo e modificando o objeto nas coordenadas OpenGL. Já em um segundo estágio, esse objeto é multiplicado pela matriz de projeção, transformando as coordenadas 3D em coordenadas 2D referentes ao plano de projeção. Em paralelo são aplicados a luz e como ela á refletida no objeto (material). Em seguida a cena passa pelo processo de clipping limitando o que será mostrado e transformando em coordenadas do framebuffer. E por último são aplicadas texturas e é feito o processo de blending que consistem em verificar se cada pixel do objeto deve ou não ser combinado com os outros pixels do framebuffer[4]. Esse modelo de pipeline, representado na Figura 11, se manteve até a versão da API OpenGL ES 2.0 (apesar de nessa versão ele está disponível, porém não é mandatório). A partir da versão da API OpenGL ES 3.1 esse pipeline foi removido ficando disponível somente o pipeline programável (representado na Figura 12), que foi introduzido a partir da versão 2.0 da API também conhecido como shader-based pois introduziu o conceito de shaders[4][15]. Figura 11- Pipeline de função fixa[15] Figura 12- Pipeline programável ou "shader-based"[15] K. Shaders O pipeline programável do OpenGL ES contém um estágio programável para os vertexs e outro estágio programável para fragmentos. Esse conjunto de unidades de cada estágio programado é chamado de shader. Um programa é um conjunto completo de shaders que são compilados e linkados juntos. Esses shaders são desenvolvidos em uma linguagem chamada GLSL (OpenGL Shading Language) e são executados diretamente na GPU. Os shaders são divididos em dois tipos na API OpenGL, vertex shaders e fragment shader[4][9][19]. Os vertex shaders implementam um método programável para operar nos valores dos vértices e os dados associados a eles. Vertex shaders podem ser utilizados para operações tradicionais nos vértices, como transformação de posição por uma matriz, cálculo da equação de iluminação para geração das cores do vértice e geração ou transformação das coordenadas de textura. Como uma alternativa ao processo tradicional, pelo fato que os vertex shaders são definidos pela aplicação, eles podem ser utilizados para realizar operações matemáticas customizadas que permitem novas transformações, iluminação, ou efeitos baseados nos vértices que não eram possíveis com o pipeline de função fixa [9][19]. Na Listagem 1 temos um exemplo de implementação de um vertex shader. #version 300 es uniform mat4 u_mvpmatrix; // matrix to convert //a_position from model // space to normalized // device space // attributes input to the vertex shader in vec4 a_position; // position value in vec4 a_color; // input vertex color

7 // output of the vertex shader - input to //fragment shader out vec4 v_color; // output vertex color void main() v_color = a_color; gl_position = u_mvpmatrix * a_position; Listagem 1- Exemplo de um vertex shader[9] Assim como os vertex shaders, os fragment shaders implementam um método de operações programáveis. Porém, ao invés de atuar nos vertexs esses métodos atuam diretamente nos fragments. No contexto do OpenGL, os Fragments são o resultado do processo de rasterização, que é o processo que converte cada objeto primitivo (ponto, linha, triângulo e outros) em um conjunto de fragments bi-dimensionais. Esses fragments bi-dimensionais representam pixels que podem ser desenhados na tela[9]. Na Listagem 2 é demostrada um exemplo de implementação de um fragment shader. #version 300 es precision medium float; in vec4 v_color; //input vertex color from vertex shader out vec4 fragcolor; //output fragment color void main() fragcolor = v_color; Listagem 2- Exemplo de um fragment shader[9] III. PADRÕES DE DESENVOLVIMENTO DE JOGOS Algumas técnicas e padrões foram sendo definidos para o desenvolvimento de games. Um conceito que pode ser considerado essencial é o padrão Game Loop. O Game Loop executa continuamente durante o jogo, sendo que cada turno do loop se baseia em: receber as entradas do jogo (touch screen, acelerômetro, controle, entre outros) sem bloquear o jogo, atualizar o estado do jogo (posição dos personagens, cálculos de movimentação, detecção de colisão) e renderização da parte gráfica do jogo[20]. Apesar de parecer simples existem alguns problemas que devem ser levados em consideração nessa implementação. Como o jogo pode ser executado em diferentes máquinas (os próprios dispositivos Android disponíveis no mercado são bem heterogêneos) não é possível que se tenha o controle de quão rápido o jogo vai ser executado em determinado dispositivo. Caso seja um hardware com um poder computacional alto, o jogo pode ser executado muito rápido. Em contraponto, em um dispositivo mais simples esse jogo pode ter seu desempenho afetado. Em ambos os casos a experiência do usuário será afetada[4][20]. A primeira maneira de que se evitar esse tipo de problema é utilizar o tempo decorrido para controlar o andamento do jogo. Digamos que um jogo queira atingir a meta de executar em 60 frames por segundo (fps). Dessa maneira, temos 16 milissegundos para cada frame do jogo ser calculado e renderizado. Desde que o cálculo e a renderização levem menos que esse tempo o jogo vai ser executado normalmente, garantindo somente que esse processo espere o restante dos 16 milissegundos que não foram utilizados[4][20]. Na Figura 13 temos uma representação gráfica desse processo e na Listagem 3 uma implementação simplificada. Figura 13- Game loop baseado em tempo [20] while (true) double start = getcurrenttime(); processinput(); update(); render(); sleep(start + MS_PER_FRAME - getcurrenttime()); Listagem 3 - Representação do Game loop baseado em tempo [20] Essa espera pelo tempo definido para o quadro no final do turno do Game Loop ajuda quando o jogo está sendo executado rápido demais, porém não corrige o problema do jogo estar mais lento do que o esperado. Uma alternativa para minimizar essa lentidão poderia ser diminuir a qualidade dos gráficos ou simplificar os cálculos realizados durante a atualização. O problema é que a qualidade do jogo seria afetada até para usuários com um dispositivo com maior poder de processamento[20]. Para resolver esse problema podemos definir cada turno do Game Loop da seguinte maneira: cada atualização avança o tempo de jogo em um determinado tempo e demora um período de tempo real para que se processe essa atualização. Se o tempo real gasto para se fazer essa atualização é maior que o tempo de jogo avançado o jogo vai ser executado lentamente. Em outras palavras, se levarmos mais de 16 milissegundos de processamento para avançar 16 milissegundos em tempo de jogo, não vai ser possível atingir o ritmo desejado. Mas se avançarmos o tempo de jogo em mais de 16 milissegundos em um único turno podemos atualizar o jogo em uma frequência menor e acompanhar o ritmo desejado[20]. Desse modo o tempo de jogo que vai ser avançado em cada atualização é baseado no tempo real que se passou desde o último quadro. Quanto mais tempo o quadro demorar para ser calculado e renderizado, maior será o avanço no tempo do jogo. Essa técnica é chamada de passo de tempo variado (variable time step)[20]. Na Listagem 4 é mostrado uma implementação simplificada do passo de tempo variado.

8 double lasttime = getcurrenttime(); while (true) double current = getcurrenttime(); double elapsed = current - lasttime; processinput(); update(elapsed); render(); lasttime = current; Listagem 4- Tempo de jogo atualizado de acordo com o tempo real gasto [20] As vantagens dessa implementação é que o jogo é executado de maneira consistente independente do hardware que é executado. Além disso, dispositivos com um poder computacional maior são recompensados com uma experiência de jogo mais suave já que são feitos mais atualizações no mesmo período de tempo do que um dispositivo mais simples[20]. Porém essa implementação é não-determinística e instável. Se o mesmo jogo é executado em dois dispositivos diferentes com poderes computacionais diferentes podemos ter alguns comportamentos inesperados. Por exemplo, se o mesmo objeto viaja de um lado a outro da tela em um dispositivo com maior poder computacional A que consegue uma taxa de 50 fps e um dispositivo mais simples B que consegue apenas 5 fps. Isso significa que a posição do objeto no dispositivo A será feita 50 vezes enquanto no dispositivo B apenas 5. Muitos jogos utilizam funções com pontos flutuantes que são suscetíveis a erros de arredondamentos. Se no dispositivo A são feitos 10 vezes mais cálculos do que no dispositivo B, o erro de arredondamento será maior podendo causar uma posição diferente em cada um dos dispositivos[20]. Um ponto que não é afetado pelo passo de tempo variável é a renderização. Já que essa renderização reflete um determinado instante de tempo, ela não leva em consideração quanto tempo levou desde a última atualização. Portanto outra técnica utilizada é a atualização utilizando um período fixo de tempo e deixando flexível quando a renderização irá ocorrer[20]. Desse modo, a mesma quantidade de atualizações irá ocorrer em qualquer dispositivo, deixando assim os cálculos mais estáveis. O atraso entre um quadro e outro é calculada e as atualizações são feitas até que o ritmo desejado seja alcançado e a renderização é feita. O fato de algumas renderizações não serem feitas acaba poupando alguns ciclos de CPU, o que facilita dispositivos mais simples acompanharem o ritmo desejado. Já os dispositivos com um poder computacional maior são recompensados com uma maior frequência de renderizações[20]. Na Listagem 5 é demonstrado a implementação desse conceito. double previous = getcurrenttime(); double lag = 0.0; while (true) double current = getcurrenttime(); double elapsed = current - previous; previous = current; lag += elapsed; processinput(); while (lag >= MS_PER_UPDATE) update(); lag -= MS_PER_UPDATE; render(); Listagem 5 - Game loop com tempo fixo [20]. Na implementação do método, o atraso é calculado logo no ínicio baseado em quanto tempo real foi gasto desde o último quadro e é feito um loop interno atualiza o jogo a cada passo fixo até que o tempo de jogo acompanhe o ritmo desejado. Assim que esse ponto chega, a renderização é feita[20]. A Figura 14 faz uma representação gráfica desse fluxo. Figura 14- Representação gráfica do Game Loop baseado em tempo fixo [20]. IV. CONCLUSÕES O desenvolvimento de games para a plataforma Android apresenta uma dificuldade elevada devido a grande quantidade de dispositivos heterogêneos encontrados no mercado e da complexidade de se trabalhar com uma API gráfica como o OpenGL ES. Algumas ferramentas e frameworks podem facilitar esse desenvolvimento. Elas abstraem a complexidade da API OpenGL ES além de permitir o desenvolvimento para multiplataformas. Podemos citar como exemplo o Unity, Corona, Phonegap e LibGDX[21][22][23][24]. Com a utilização das ferramentas de desenvolvimento citadas, o desenvolvedor ganha em agilidade porém a um custo de desempenho considerável. Portanto, a utilização da API OpenGL ES e dos padrões de desenvolvimento de jogos são uma ótima escolha para se desenvolver um game para Android. Apesar de toda a complexidade nela encontrada. Um estudo mais aprofundado da API OpenGL ES, entrando em detalhes de implementação, o tratamento de Áudio e Vídeo assim como outros padrões de desenvolvimento de Games como movimentação a partir de vetores, detecção de colisões e aplicações de leis da física serão alvos de trabalhos futuros.

9 REFERÊNCIAS [1] "Mundo vai gastar R$ 275 bilhões em videogames este ano", O Globo, [Online]. Disponível em: bilhoes-em-videogames-este-ano [Acessado em: 30- Maio- 2016]. [2] "Video Game Industry Statistics Entertainment Software Rating Board", Esrb.org, [Online]. Disponível em: [3] "Número de usuários de smartphones cresce 25% em um ano no mundo", Hora 1, [Online]. Disponível em: [Acessado em: 31- Maio- 2016]. [4] M. Zechner and R. Green, Beginning Android 4 games development. Berkeley, CA: Apress, [5] "IDC: Smartphone OS Market Share", [Online]. Disponível em: [6] "Dashboards Android Developers", Developer.android.com, [Online]. Disponível em: [7] "OpenGL ES - The Standard for Embedded Accelerated 3D Graphics", The Khronos Group, [Online]. Disponível em: [8] C. Drawables, "Canvas and Drawables Android Developers", Developer.android.com, [Online]. Disponível em: [9] D. Ginsburg and B. Purnomo, OpenGL ES 3.0 programming guide. Upper Saddle River, NJ: Addison-Wesley, [10] "The Khronos Group Inc.", The Khronos Group, [Online]. Disponível em: [Acessado em: 31- Maio- 2016]. [11] OpenGL ES Version 3.1, 1st ed. The Khronos Group Inc, 2015[Online]. Disponível em: [12] V. Silva and M. Nardone, Pro Android games. [New York]: Apress, [13] O. ES, "OpenGL ES Android Developers", Developer.android.com, [Online]. Disponível em: [14] O. ES, "OpenGL ES Android Developers", Developer.android.com, [Online]. Disponível em: [Acessado em: 31- Maio- 2016]. [15] "Introduction to Modern OpenGL Programming", University of Texas at Austin, [16] "OpenGL 101: Drawing primitives - points, lines and triangles Solarian Programmer", Solarianprogrammer.com, [Online]. Disponível em: [17] "OpenGL 101: Matrices - projection, view, model Solarian Programmer", Solarianprogrammer.com, [Online]. Disponível em: [18] "Shader - OpenGL.org", Opengl.org, [Online]. Disponível em: [19] The OpenGL ES Shading Language. The Khronos Group Inc., [20] "Game Loop Sequencing Patterns Game Programming Patterns", Gameprogrammingpatterns.com, [Online]. Disponível em: [Acessado em: 31- Maio- 2016]. [21] "Unity - Game engine, tools and multiplatform", Unity3d.com, [Online]. Disponível em: [Acessado em: 31- Maio- 2016]. [22] "Develop Cross Platform Mobile Apps and Games Corona Labs!", Coronalabs.com, [Online]. Disponível em: [Acessado em: 31- Maio- 2016]. [23] "PhoneGap", Phonegap.com, [Online]. Disponível em: [24] "libgdx", Libgdx.badlogicgames.com, [Online]. Disponível em: Leandro Castelli Silverio nasceu em Marília, SP, em 27 de maio de Recebeu o título de Bacharel em Ciência da Computação pelo Centro Universitário Eurípedes de Marília em Desde 2008 é Engenheiro de Software na LG Electronics do Brasil e possui interesse nas áreas de Desenvolvimento Mobile, Dispositivos Embarcados e Desenvolvimento de Jogos. Márcio Emílio Cruz Vono de Azevedo Possui graduação em Engenharia Elétrica Modalidade Eletrônica pelo Instituto Nacional de Telecomunicações(1999) e mestrado em Ciência e Tecnologia da Computação pela Universidade Federal de Itajubá(2012). Atualmente é Especialista em Sistemas do Instituto Nacional de Telecomunicações, Professor do Instituto Nacional de Telecomunicações e Professor da Universidade do Vale do Sapucaí.