Engine para o jogo - parte 1

Olá a todos!!! 

O último post marcou a primeira fase do projeto Android, a qual tinha como objetivo estudar as tecnologias envolvidas, assim como as facilidades e dificuldades para o desenvolvimento do jogo. Neste post, irei contextualizar o resultado dos estudos para o desenvolvimento do jogo.

Para o projeto, juntei tudo que havia aprendido e iniciei o desenvolvimento de uma engine baseada no framework do livro já citado Beginning Android 4 Games Development. A seguir, os principais elementos da engine:

• Audio: A engine possui suporte para os formatos de audio reproduzíveis pelo Sistema Operacional, mas é encorajado o uso do formato OGG por ser free e ser muito utilizado em games. 
• Um aspecto importante é que toda música reproduzida no Android não pertence ao escopo da aplicação, mas sim ao próprio sistema. Ou seja, se não nos precavermos quanto ao pausamento dos sons a cada saída e fechamento, a música continuará tocando com a aplicação fechada.
• A parte de audio da engine é dividida em três partes:
• Uma classe principal que deve servir de fábrica para músicas e sound effects;
• Uma classe para tratamento de sound effects, que usa como base os recursos da classe Sound Pool do Android;
• Uma classe para tratamento de músicas, a qual usa como base os recursos da classe Media Player do Android;

• Leitor de arquivos: Apesar do Android possuir suporte a SQLite, para jogos pequenos seria mais interessante gravar os dados de um jogo em um arquivo de persistência no formato txt. Essa classe é responsável por facilitar a leitura e escrita em arquivo das informações desejadas.

• Game Loop: O game loop do jogo é controlado pela thread que contém a Surface View. 
• Para resolver os problemas de diferença de velocidade entre os dispositivos, esse game loop foi programado para tentar seguir uma quantidade definida de frames por segundo, fazendo a aplicação dormir caso sobrem alguns milissegundos para que o celular possa processar outras aplicações, e guardando os milissegundos excedidos caso a aplicação não tenha rodado no tempo máximo que o fps em questão suportaria. 
• Quando o tempo excedido alcançar o tempo por loop (representado por 1 segundo dividido pelo número de fps), o game loop trata esse excesso e pula uma quantidade de quadros para compensar o tempo perdido, levando em consideração que o gargalo está no desenho. Ou seja, pulando o desenho e mantendo o update da lógica do jogo, o mesmo não apresentará problemas de lentidão em dispositivos mais lentos.
• A forma como construí esse game loop foi essencial para rodar os jogos na mesma velocidade no celular, tablet e emulador.

Estarei especificando as demais funcionalidades relevantes da engine no próximo post.

Até la!