PROGRAMAÇÃO DE JOGOS PARA CELULAR EM JAVA

Transcrição

1 UNIVERSIDADE DO PLANALTO CATARINENSE DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE SISTEMAS DE INFORMAÇÃO (BACHARELADO) MARCELO ALVES MARCIANO PROGRAMAÇÃO DE JOGOS PARA CELULAR EM JAVA LAGES (SC) 2008

2 MARCELO ALVES MARCIANO PROGRAMAÇÃO DE JOGOS PARA CELULAR EM JAVA Trabalho de Conclusão de Curso submetido à Universidade do Planalto Catarinense para obtenção dos créditos da disciplina Metodologia da Pesquisa, no curso de Sistemas de Informação - Bacharelado. Orientação: Profª. Sabrina Bet Koerich, M.Sc. Prof. Angelo Augusto Frozza, M.Sc. LAGES (SC) 2008

3 MARCELO ALVES MARCIANO PROGRAMAÇÃO DE JOGOS PARA CELULAR EM JAVA ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO, DO 8º. SEMESTRE, OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE: BACHAREL EM SISTEMAS DE INFORMAÇÃO Lages (SC), 02 de dezembro de 2008 Profª. Sabrina Bet Koerich, M.Sc. Orientador Prof. Angelo Augusto Frozza, M.Sc. Co-Orientador BANCA EXAMINADORA: Prof. Marcos André Pisching, M.Sc. UNIPLAC Profª. Daiana Petry, M.Sc. UNIPLAC Prof. Wilson Castello Branco Neto, Dr. Professor de TCC Prof. Angelo Augusto Frozza, M.Sc. Coordenador de Curso

4 LISTA DE ILUSTRAÇÕES FIGURA 1 - Operação blit sendo feita por meio da definição de frames FIGURA 2 - Execução blit com parâmetros de mirroring FIGURA 3 - Exemplo de TileSet FIGURA 4 - Imagem fonte de um Sprite FIGURA 5 - Diagrama de Navegação do Jogo FIGURA 6 - Sprite do veículo FIGURA 7 - Tileset do mapa FIGURA 8 - Camadas do Mapa FIGURA 9 - Cenário completo do Mapa FIGURA 10 - Cenário completo dos Mapas 2 e FIGURA 11 - Tileset adicional dos mapa 2 e FIGURA 12 - Classes da Game API FIGURA 13 - Lógica seqüencial de um jogo QUADRO 1 - Método getfundo_areia() da classe GameDesign QUADRO 2 - Menu do Jogo QUADRO 3 - Loop Principal do Jogo Classe GamePanel QUADRO 4 - Método verificacolisaoparede() QUADRO 5 - Código do método. adjustviewport do Jogo QUADRO 1 - Método getfundo_areia()... 60

5 LISTA DE ABREVIATURAS E SIGLAS CLDC CPU CRT GPU JME MIDP RGB SRAM VRAM EA - Connected Limited Device Configuration - Central Processing Unit - Cathode-Ray Tube - Graphics Processing Unit - Java Micro Edition - Mobile Information Device Profile - Red, Green, Blue - Static Random Access Memory - Video Random Access Memory - Electronic Arts

6 RESUMO O desenvolvimento de jogos para celular normalmente segue as mesmas etapas do desenvolvimento de jogos para computadores, as quais podem ser resumidas em game design, desenvolvimento da arte, programação e testes. Como os jogos para celular são mais simples, as etapas de desenvolvimento levam muito menos tempo do que num jogo para computador. O desenvolvimento de jogos para celulares vem ganhando cada vez mais espaço e conseqüentemente, a plataforma JME (Java Micro Edition) também é exigida com maior intensidade. A JME trata-se de uma plataforma para pequenos dispositivos, com pouca capacidade de memória e processamento, como celulares e TV set-top boxes. Este trabalho descreve a etapa de programação de jogos para celular usando a plataforma Java ME através de um estudo de caso capaz de operar em diferentes celulares. Para viabilizar a programação são apresentadas as etapas e conceitos necessários para se programar um jogo em duas dimensões. São apresentados os principais conceitos relacionados com os gráficos dos jogos, tais como: os tiles que são as estruturas para montagem de cenários e os sprites usados para criação de animações. Também são apresentadas as principais funções realizadas sobre esses gráficos, tais como: espelhamento, transparência, cores, entre outros. Este levantamento bibliográfico é de grande importância para o entendimento de conceitos envolvidos na programação de jogos, podendo-se identificar e compreender os termos comumente utilizados nesta área. O estudo de caso refere-se a um jogo de corrida de tomada de tempo, o qual tem seu projeto descrito através de um Design Document, bem como a criação do layout do mesmo foi realizado através da IDE NetBeans 6.1 a qual possui uma ferramenta de criação visual de jogos, que possibilita a montagem das camadas do cenário do jogo, bem como dos tiles. Considerando os aspectos mais relevantes da programação de um jogo para celular, são detalhados os códigos do loop principal do jogo, do tratamento de colisão e movimentação da tela do celular. Com este projeto, objetiva-se auxiliar futuros trabalhos na área de programação de jogos para celular. Palavras-chave: Jogos; Programação; JME; Game API; Celular.

7 ABSTRACT The development of cellphone games usually follows the same steps as the development of computer games, which can be summarizes as game design, art development, programming and tests. Since cellphone games are simpler, the development steps take less time than those of a computer game. Since the development of cellphone games has been gaining more and more space on the market,, consequently, the JME (Java Micro Edition) platform is also required with more intensity. The JME is a platform for small devices, with little capability for memory and processing like cellphones, TV set-top boxes. This essay describes the programming step of the development of cellphone games using the Java ME platform through a case study capable of operating in various cellphones. To make the programming are presented the necessary steps and concepts to program a twodimensional game. Are presented the main concepts related with game graphics, such as: tiles which are structures for the assembly of the scenarios and sprites used for creating animations. Are also presented the main functions performed on these graphics, such as: mirroring, transparency, colors, among others. This reference survey is of big importance for the understanding of concepts involved on the programming of games, allowing the identification and understanding of the terms commonly used in this area. The case study refers to a time-making race game, which has it's project described through a Design Document, as well as the creation of the layout was performed through the NetBeans 6.1 IDE, which has a visual game-making tool, which allows the assembly of the layers of the scenario of the game, as well as those of the tiles. Considering the most relevant aspects on the programming of a cellphone game, are detailed the codes of the game's main loop, as well as collision treatment and the cellphone's screen movimentation. With this project, it's aimed in helping future works in the field of cellphone games programmin. Keywords: Games; Programming; JME; Game API.

8 SUMÁRIO 1 INTRODUÇÃO Apresentação Descrição do problema Justificativa Objetivo geral Objetivos específicos Metodologia PROGRAMAÇÃO DE JOGOS Gráficos Modos de vídeo Cores Superfícies Função blit Transparência Espelhamento (mirroring) Técnicas de animação Tiles Sprites Som Conclusão DESIGN DOCUMENT Apresentação Especificações técnicas Regras do jogo Navegação do jogo Layout do jogo Conclusão IMPLEMENTAÇÃO Java Micro Edition Características de implementações do Java Micro Edition IDE Netbeans Visão geral da versão Mobility pack Game API Menu do jogo... 39

9 4.6 Loop principal do jogo Implementação da colisão Implementação da movimentação da tela Testes do jogo Conclusão CONSIDERAÇÕES FINAIS REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICES... 52

10 10 1 INTRODUÇÃO 1.1 Apresentação O desenvolvimento de jogos para celular normalmente segue as mesmas etapas do desenvolvimento de jogos para computadores, as quais podem ser resumidas em game design, desenvolvimento da arte, programação e testes. Como os jogos para celular são mais simples, as etapas de desenvolvimento levam muito menos tempo do que num jogo para computador. Por outro lado, como em qualquer jogo, cada etapa de desenvolvimento exige os conhecimentos de um tipo de profissional diferente e a escolha das tecnologias adequadas para cada tarefa. O mercado de jogos está aquecido pelo mundo. Segundo o diretor-gerente da EA (Electronic Arts) na Alemanha, Thomas Zeitner (REUTERS, 2007), "Há 150 milhões de jogadores em todo o mundo, mas 2 bilhões de pessoas estão prontas para jogar". Para o presidente-executivo da produtora Ubisoft (ESTADÃO, 2007), "Há tantos clientes novos no negócio. Isso vai fazer o mercado crescer tremendamente. Espero que o mercado cresça 50% nos próximos quatro anos". No Brasil, muitos desenvolvedores vêem um futuro promissor na área de jogos para celular. Um ponto que influencia alguns desenvolvedores é o fato de a pirataria de jogos para celular não ser tão explorada como em outras plataformas. Para o Brasil, os jogos eletrônicos não só representam o segmento onde mais resultado pode ser obtido com pouco investimento, mas também a chance do país de estar na frente da corrida de geração de conteúdo digital, aliado a um potencial de exportação superior a qualquer outro conteúdo audiovisual. Finalmente, deve-se comentar que a área tem como contribuir e muito para o Brasil atingir a sua ousada meta de 2 bilhões de dólares de exportação de software em 2007 (AVELAR, 2007, p. 7). Diante das expectativas do mercado nacional de jogos e do aumento no

11 11 número de usuários de celulares, este trabalho tem como objetivo o estudo da etapa de programação de jogos para celular, realizando a criação de um jogo como estudo de caso. Para isto, este trabalho está estruturado em 5 Capítulos. O Capítulo 1 apresenta o contexto do trabalho de pesquisa na área de jogos. No Capítulo 2 são apresentados os conceitos relevantes para a programação de jogos. O Capítulo 3 apresenta o estudo de caso desenvolvido, identificando os componentes gráficos que o compõem. O Capítulo 4 trata da implementação do jogo. Finalmente, no Capítulo 5 são apresentadas as considerações finais deste projeto. 1.2 Descrição do problema Atualmente, os desenvolvedores têm que se preocupar com as limitações dos aparelhos para os quais os jogos são direcionadas, uma vez que cada aparelho possui características diferentes e essas diferenças podem ser encontradas também entre aparelhos de um mesmo fabricante. Assim, as limitações do hardware representam um complicador no desenvolvimento de jogos para celulares, principalmente aqueles que exigem interfaces gráficas ricamente trabalhadas. Os programadores devem buscar constantemente a otimização de seus códigos, a fim de obter maior desempenho com menor uso de recursos. Para desenvolver jogos para celulares, na escolha de tecnologias e ferramentas, a equipe de desenvolvimento deve se preocupar em cada etapa com as limitações existentes nos aparelhos a que se destinam os jogos. Este trabalho aborda, especificamente, as dificuldades relacionados com a etapa de programação de jogos para celular usando a plataforma Java ME (JME). 1.3 Justificativa A popularização dos celulares fez nascer um novo mercado, o desenvolvimento de aplicativos e jogos para equipamentos celulares, palms, smartphones etc. As empresas de telefonia celular têm investido em jogos como um

12 12 dos diferenciais de seus produtos. Esse mercado é muito promissor e, atualmente, fatura algo em torno de R$ 20 milhões, com um crescimento anual de 30% ao ano (ESTADO DE SÃO PAULO, 2007). De uma maneira geral, a indústria nacional de jogos vem crescendo, mas em especial, a indústria de jogos em Santa Catarina vem crescendo acima da média nacional, devido aos investimentos públicos e privados nos últimos anos. Esses investimentos foram obtidos devido à disponibilidade de mão-de-obra existente no Estado (ESTADO DE SÃO PAULO, 2007). Os jogos para celulares, comparados aos jogos para computador de mesa, podem ser criados em menos tempo e a um custo bem menor. Como o desenvolvimento de jogos para celulares vem ganhando cada vez mais espaço, conseqüentemente, a plataforma JME (Java Micro Edition) também é exigida com maior intensidade. A JME trata-se de uma plataforma para pequenos dispositivos, com pouca capacidade de memória e processamento como celulares e TV set-top boxes (OGLIARI, 2007). Pensando nisso, a MIDP (Mobile Information Device Profile ) 2.0 apresenta um pacote direcionado exclusivamente aos jogos, a Game API. Com a chegada desta API (Application Program interface), o desenvolvedor tem inúmeras vantagens, como por exemplo, uma facilidade maior na portabilidade dos jogos, isto porque, não será mais necessário o uso de bibliotecas de fabricantes para funcionalidades específicas, como é o caso dos Sprites. Ainda existe a evolução de algumas classes como, por exemplo, a classe Canvas existente na MIDP 1.0 evolui para sua sucessora, a GameCanvas (OGLIARI, 2007). Assim, justifica-se esse Trabalho de Conclusão de Curso (TCC), que propõe um estudo mais aprofundado sobre o desenvolvimento de jogos para celular utilizando a Game API. 1.4 Objetivo geral Descrever a etapa de programação de jogos para celular usando a plataforma Java ME e a IDE NETBEANS, aplicado a um estudo de caso.

13 Objetivos específicos Os objetivos específicos desse trabalho são: Identificar os pontos críticos na programação de jogos para celular; Demonstrar como é programado um jogo para celular usando JME; Disponibilizar um estudo de caso capaz de operar em diversos celulares, de forma a identificar possíveis problemas que possam ocorrer nas diferentes versões. 1.6 Metodologia O presente trabalho iniciou com a definição do projeto, problema, justificativa, objetivos e metodologia. Para a elaboração dos mesmos, foram necessárias pesquisas sobre o mercado de jogos, mercado de celulares e vantagens da utilização da linguagem JME. Na seqüência, foi realizado um levantamento bibliográfico sobre as características técnicas que influenciam a programação de jogos para celulares para, em seguida, realizar um estudo mais aprofundado da linguagem Java. Esse levantamento bibliográfico foi realizado através de revistas, artigos publicados em eventos e páginas da web. Na etapa seguinte, foi descrito um estudo de caso, que consistiu em definir o roteiro para um jogo e identificar elementos gráficos que possam ser utilizados para o desenvolvimento do estudo de caso. Em seguida, iniciou-se a implementação do jogo, na qual foram identificados os pontos críticos desta etapa, detalhando-se os mesmos. Os testes do jogo foram realizados paralelamente à etapa de implementação. Ao final dessas etapas, foram elaboradas as considerações finais deste trabalho e identificada possibilidades de trabalhos futuros.

14 14 2 PROGRAMAÇÃO DE JOGOS O objetivo deste capítulo é apresentar as etapas e conceitos necessários para se programar um jogo em duas dimensões. São apresentados os principais conceitos relacionados com os gráficos dos jogos, tais como: os tiles que são as estruturas para montagem de cenários e os sprites usados para criação de animações. Também são apresentadas as principais funções realizadas sobre esses gráficos, tais como: espelhamento, transparência, cores, entre outros. Por fim, são apresentados conceitos sobre a ambientação sonora. 2.1 Gráficos No passado, o processador do computador era responsável por todo o processamento de vídeo. Hoje, foram modificados os conceitos de modo que a CPU esteja mais disponível para execução de outras funções. O sistema de vídeo moderno se divide em (PERUCIA et al., 2005): Memória de vídeo (VRAM): é a memória onde estão todas as imagens do jogo, a qual é mapeada diretamente no monitor. Se acontecer dessa memória se perder, a memória principal, chamada memória RAM que mesmo sendo mais lenta, pode alocar as imagens também; GPU (Graphics Processing Unit): é o processador gráfico. Hardware que faz todo o processamento 2D e 3D das aplicações. Onde se localiza o Blitter, responsável pela transferência de dados e imagens de uma parte da memória para outra; Memória principal (RAM): é a parte da memória que armazena temporariamente os dados como: textos, sons etc.;

15 15 CPU (Central Processing Unit): cérebro do computador. É responsável pela execução dos códigos dos programas. Com a chegada do GPU, a CPU ficou cada vez mais disponível para realizar outras funções que não o processamento gráfico; Barramento: Conjunto de sinais digitais que serve para o processador comunicar-se com outros dispositivos Modos de vídeo Monitores permitem diversos modos de vídeo, que se dividem em (PERUCIA et al., 2005): Resolução: define a quantidade de pixels que se obtém por meio da multiplicação entre a altura e a largura. Quanto mais pixels possuir, melhor é a definição de imagens e o processamento da GPU; Formato: define a profundidade das cores. Quanto maior quantidade de cores disponíveis, mais processamento é requerido. Por exemplo, 8 bits = 256 cores e 32 bits = 16 milhões de cores; Freqüência: número de vezes por segundo que o monitor é atualizado Cores Os jogos eletrônicos têm suas cores representadas por uma combinação de três cores: verde, azul e vermelho. Os sistemas computacionais identificam uma cor de acordo com um valor numérico chamado tripla RGB (Red, Green, Blue). Tripla RGB é um conjunto de três valores de 8 bits em que cada valor representa a composição da cor (AZEVEDO, 2003). Assim, o preto possui a intensidade mínima de componentes (0,0,0). O branco possui a intensidade máxima (255, 255, 255). O valor 255 é o número máximo que 8 bits pode representar. O formato de cor diz respeito ao número de bits que o sistema emprega para expor a cor na tela, o qual se ajusta quando se define o modo de vídeo. Os formatos mais comuns são os que empregam 16, 24 ou 32 bits para significar cada cor. Para os formatos de cor de 16 bits usa-se o chamado bits para cada

16 16 componente de cor. E o chamado bits para os componentes vermelho e azul e 6 bits para verde. Os formatos 24 e 32 bits utilizam 8 bits para significar cada cor. No formato 24 bits a representação é por 3 bytes; já no 32 bits é através de uma variável, onde os últimos 8 bits são ignorados Superfícies Superfícies, ou surfaces, são regiões que armazenam dados de imagens lidas de arquivos bitmaps. Podem estar alocadas na memória de vídeo (tratadas pela GPU) ou na memória do sistema (mais lentas, pois são tratadas pela CPU) (PERUCIA et al., 2005). Uma superfície é gerenciada como um retângulo ou uma folha virtual que a aplicação copia, combina, embaralha e rearranja com outras para composição do jogo, produzindo efeitos gráficos e de animação. As superfícies se dividem em três categorias (PERUCIA et al., 2005): Superfície primária representa a área visível de tela e é diretamente mapeada na memória de vídeo. Essa superfície é chamada de front buffer; Superfície secundária denominada de back buffer, tem a mesma estrutura da primária. Utilizada sempre como espaço de trabalho para desenhar um próximo quadro de animação do jogo, que então vai em cópia para o front buffer para exibição na tela; Superfícies offscreen: são usadas para armazenar bitmaps, sprites, itens do jogo, entre outros. Geralmente, os dados são copiados para o back buffer para ser apresentados na tela. Em um jogo pode-se possuir várias offscreen, de diversos tamanhos. Todas as superfícies feitas devem ter o mesmo formato (8, 16 ou 32 bits); Portanto, em relação às superfícies, a primária deve ser sempre a primeira superfície a ser criada, logo depois vem a secundária. Somente após a criação destas, pode-se criar as superfícies offscreen que contêm todos os dados visuais do jogo.

17 Função blit A função blit é a mais importante função do modo de processamento gráfico. Um blit significa a operação de cópia de dados. A função copia uma região retangular de uma superfície para outra. Trata-se de um processo simples: deve-se definir o frame de origem (onde a imagem está) e o frame de destino (para onde a imagem de origem deve ser copiada), conforme mostre a figura 1. É habitual em funções de blit a mudança do valor nulo para os parâmetros que representam os frames, mostrando que toda a superfície é copiada de uma região para outra. Em algumas ferramentas, se o frame de origem e o de destino forem de tamanhos diferentes é feita uma escala, de modo que a imagem seja desenhada de forma aumentada ou reduzida, em efeito zoom Transparência FIGURA 1 - Operação blit sendo feita por meio da definição de frames (PERUCIA et al., 2005) Uma função muito importante no jogo refere-se a transparência de imagens. Esse recurso é empregado quando se quer desenhar imagens que tem regiões transparentes. Para isso, é definida uma cor que não seja copiada para o quadro destino, chamada de color key ou cor-chave. Assim que a cópia da superfície é feita,

18 18 são ignorados todos os pixels que possuem essa cor, criando assim, o efeito de transparência (PERUCIA et al., 2005). É comum se definir a cor rosa como padrão de transparência (R=255, G=0, B=255) Espelhamento (mirroring) É uma técnica para espelhar a imagem, a qual é obtida pela inversão dos pixels da imagem a ser desenhada em um ou dois eixos (X e Y). (figura 2). Dessa forma, é possível combinar os dois tipos de espelhamento (horizontal e vertical) fazendo com que a imagem seja desenhada com os eixos X e Y invertidos. O espelhamento é aplicado pela GPU no instante em que se faz um blit para uma região de memória Técnicas de animação FIGURA 2 - Execução blit com parâmetros de mirroring (PERUCIA et al., 2005) Na computação, existem dois métodos principais para a animação de um jogo: page flipping e double buffering. Ambas as técnicas usam a superfície do back buffer para fazer o desenho das imagens do jogo (PERUCIA et al., 2005). Desta forma, o back buffer deve ser usado para desenhar qualquer objeto no

19 19 jogo, para depois passar para a superfície primária. Caso contrário, ocorre um efeito chamado de flicker. O efeito flicker ocorre justamente porque os dados de vídeo que estão na VRAM são atualizados de forma muito mais rápida que a velocidade com que o monitor ou visor pode ser desenha. O que pode acontecer é que, quando começar a desenhar a animação de um objeto e chegar ao fim do desenho, o canhão já está desenhando um outro quadro de animação do objeto que está na VRAM, fazendo com que a tela seja desenhada de forma assíncrona. Dessa forma, basta fazer a sincronização da superfície primária (front buffer) que é representada pela memória de vídeo com o canhão do monitor, ou seja, a atualização do front buffer (escrita) não pode ser feita enquanto o canhão do monitor estiver desenhando na tela. Essa atualização deve ser feita sempre em intervalos, que é o período em que o monitor fica parado esperando o retorno do último pixel inferior à direita até o primeiro pixel superior à esquerda. Assim, garante-se que o front buffer só é atualizado quando o monitor estiver parado ou retornando, para recomeçar o desenho. Esse procedimento torna os gráficos sempre suaves, sem flicker O page flipping é um método de animação muito utilizado, que evita o efeito flicker, e deve ser feito da seguinte forma: Desenhar as imagens do jogo no back buffer. Quando for gerado um VBlack do monitor, fazer o back buffer virar o front buffer e vice-versa. Voltar à operação 1. Dessa forma, quando desenho chega no fim da tela, o front buffer torna-se back buffer e vice-versa, o que faz com que o visor sempre tenha dados que não vão ser mudados durante a sua escrita. O flip altera o endereço da memória onde os dados são apresentados ao monitor. Este endereço muda sempre que o monitor entra no modo Blank. Vale ressaltar que a técnica de page flipping é extremamente rápida e

20 20 funciona somente em modo de tela cheia. O double buffering, Por sua vez, consiste em se ter dois buffers, o front buffer e o back buffer. Todas as imagens do jogo são desenhadas no back buffer e ao iniciar o jogo tudo é passado para o front buffer através de uma cópia de dados. Através desse método é possível que o jogo funcione em modo janela, tal como ter tamanhos diferentes de front buffer e back buffer. 2.2 Tiles Tileset são conjuntos de imagens que podem ser combinadas para compor cenários de jogos (TONYPA, 2005). Esse conjunto deve ser dividido em pedaços iguais de tamanho fixo. O quadro resultante dessa divisão chama-se tile. A figura 3 apresenta o exemplo de um Tileset. Dessa forma, os cenários de jogos são formados de pequenos blocos que se repetem e dão forma ao ambiente. FIGURA 3 - Exemplo de TileSet 2.3 Sprites Sprites são estruturas com imagens próprias que permitem a criação de animações e o livre posicionamento na tela. De forma básica, todos os objetos que tem animação ou movimentação em um jogo são nomeados sprites (WIKIPEDIA, 2008). Assim, um sprite sempre tem uma imagem com um quadro fixo definido e

21 21 pode ter muitos conjuntos de animações configuradas. A figura 4 apresenta um exemplo sprite com a animação de um personagem de jogo. FIGURA 4 - Imagem fonte de um Sprite 2.4 Som Um aspecto muito importante do jogo é a ambientação sonora. Os recursos de áudio dão mais vida ao jogo, deixando a experiência de jogá-lo muito mais valiosa e emocionante. É fundamental valorizar o momento da produção sonora, pois os sons, ao mesmo tempo em que desenvolvem, também podem atrapalhar ou mesmo desestimular o jogador caso não estejam em acordo com a proposta do jogo. Sempre que um som é lido por meio de um arquivo é criado um buffer sonoro, o qual é formado por blocos contínuos de memória, usados para a rápida reprodução de sons em jogos (PERUCIA et al., 2005). Os buffers sonoros são blocos contíguos de memória que guardam os dados de um determinado som, o qual pode ser uma música, efeito sonoro ou qualquer outro ruído desejável em um jogo. Dessa forma, todos os sons que são lidos para serem reproduzidos podem ser alocados tanto na SRAM (Static Random Access Memory) (buffer de som em hardware), encontradas nas placas sonoras sofisticadas, como também na memória RAM (buffer de som de software). Porém, os sons alocados na SRAM são imediatos, pois são colocados na placa de som e já reproduzidos pelo hardware. Já, os sons alocados na RAM são mais

22 22 lentos, pois são transferidos para a placa de som antes de serem reproduzidos. É comum, ao carregar sons, se tentar alocar buffers em hardware. Caso a memória não seja de hardware ou estiver ocupada, os sons são criados em software. Então, primeiro deve-se criar os sons principais, pois são candidatos a ficarem alocadas em hardware, para ser executados de forma mais rápida, e depois é que se deve alocar os sons menos freqüentes. Existem dois tipos de buffers de som principais em uma arquitetura de som: o secundário e o primário. O buffer secundário é a região de memória que guarda um som alocado. Este se divide em (PERUCIA et al., 2005).: Buffer estático (static buffer) é aquele cujo som é pequeno e pode ser totalmente alocado em memória. Esses buffers, em geral, são bons candidatos a ficar alocados no hardware da placa de som, pois devem possuir uma resposta imediata quando solicitados para a reprodução. Quase sempre, um buffer estático contém um simples efeito sonoro que é utilizado ao longo do jogo. O barulho de um tiro ou o pulo de um personagem são modelos de sons que estão nestes buffers. Buffer sob demanda (Streaming buffer) - geralmente é usado para arquivos mais potentes de som, como uma música. Assim, se um jogo tem seis músicas e cada uma tem 50 megabytes de tamanho, então é preciso 300 megabytes de RAM ou SRAM para alocar este som na memória. Dessa forma, reduz-se a necessidade da memória com a técnica de Streaming, que cria um pequeno buffer para um som, pois periodicamente é alimentado com um pedaço da música que está no disco rígido para ser reproduzida. O buffer primário é o primeiro a ser criado. Sempre que um som é reproduzido, o buffer secundário (que contém os dados do som) é enviado e somado aos dados do buffer primário, que então é enviado para reprodução pelos alto-falantes. 2.5 Conclusão

23 23 Este levantamento bibliográfico é de grande importância para o entendimento dos conceitos envolvidos na programação de jogos, podendo-se identificar e compreender os termos comumente utilizados nesta área. Com o conteúdo de sprite é possível utilizá-los para a criação dos carros. Os tiles são utilizados para a criação dos mapas (pistas). Bem como o esquema de superfície fornece a estrutura básica de funcionamento de um jogo. Assim, é importante esta pesquisa para entender conceitos das cores, superfícies, função blit, transparências, espelhamento, como as técnicas de animação e som em geral. Enfim, são conhecimentos essenciais na criação dos jogos.

24 24 3 DESIGN DOCUMENT O Design Document é um documento de descrição do jogo. Esse capítulo tem com objetivo mostrar as características do jogo, especificações, regras, entre outros detalhes do estudo de caso. 3.1 Apresentação Este estudo de caso trata-se de um jogo para celular na categoria de jogos de corrida, no qual o jogador representa o condutor de um veículo terrestre. O jogo tem como objetivo a simples quebra de record, no qual o jogador conta com máximo desempenho para assegurar seu melhor tempo. O jogo proposto é baseado em um jogo chamado TrackMania Nations ESWC, da Nadeo em parceria com a NVidia. O seu objetivo principal é ter o melhor tempo (que o seu tempo anterior) no modo solo. Possui pistas anormais, que são divididas em três categorias: Begginer (Iniciante), Advanced (Avançado) e Expert (Experiente). O jogo TrackMania Nations ESWC é exclusivo para computador e pede uma configuração baixa para rodar. Desta forma, o jogo desenvolvido nesse trabalho de conclusão de curso é baseado no modo solo desse jogo. O jogo proposto, quanto aos desafios, apresenta características de desenvolvimento de habilidades, tais como rapidez, e inclui ainda a simulação de esportes, dentro de um ambiente virtual para entretenimento. Oferece recursos para um único jogador (SinglePlayer), sendo que também nesta versão não há oponentes representados por agentes autônomos controlados pelo computador, pois os mesmo exigiriam a implementação de IA, o qual foge do objetivo

25 25 deste trabalho. As fases são compostas de pistas de asfalto em circuitos fechados e cercados de grama, sendo todos os objetos do jogo estáticos. A câmera do jogo sempre acompanha o carro do corredor, podendo ter uma visão em primeira ou terceira pessoa. Trata-se de um jogo casual, acessível ao grande público. Diferentemente dos jogos tradicionais que são mais complexos e exigem tempo de dedicação do jogador, os jogos casuais são simples e rápidos de aprender. Desta forma, podem ser uma opção de diversão para um simples passatempo de alguns minutos. 3.2 Especificações técnicas O jogo foi implementado utilizando a versão MIDP 2.0 a qual dá suporte à configuração CLDC 1.0, permitindo assim, que recursos adicionais como multimídia, Game API, entre outros possam ser utilizados na implementação do jogo. Com base na plataforma especificada, foram levantados os requisitos mínimos para a execução do jogo: Resolução da tela: 240 x 320 pixels; cores; Teclado direcional e numerico; Linguagem de programação Java ME. 3.3 Regras do jogo Geralmente, jogos casuais, em especial para celulares, não são feitos com o intuito de serem complexos, inclusive porque os celulares possuem bem menos recursos que os jogos para consoles e PCs. Desta forma, o jogo deve apresentar uma baixa curva de aprendizagem, sendo que esta curva indica o tempo que o jogador leva para assimilar os comandos e as regras do jogo. Um jogo com poucas regras e comandos tem uma curva de aprendizagem pequena, pois após poucos minutos de jogo, o jogador está

26 26 familiarizado com suas possíveis ações e objetivos. Nesse caso, um menu simples contendo uma opção de ajuda, informando quais as possíveis ações do jogo e como realizá-las, é utilizado para que o jogador se familiarize com o mesmo. Como alternativa, as fases iniciais tem um nível de dificuldade mais baixo, para que aos poucos o jogador assimile os comandos (MORETTO, 2006). Conforme já comentado, o jogo conta com uma quantidade determinada de pistas com circuitos fechado, possuindo, essas pistas, diferentes grau de complexidade. Os níveis de dificuldade de cada pista são baseados no tempo gasto para completar as pistas, sendo esses níveis definidos por tempos pré determinados para seu fechamento, classificados como tempo ruim, regular, bom e excelente. O tempo excelente é dado para aqueles jogadores que conseguem o melhor tempo descrito na pista. Vale lembrar que para conseguir os melhores tempos é importante fazer uma volta limpa, sem colisões, o que faz o carro ir mais rápido. O jogador pode abortar, a qualquer hora durante a sua volta, caso ache que fez algo errado ou que não vá melhorar o seu desempenho. Não há um tempo limite para o jogador terminar a pista. Melhorando o tempo sugerido, o jogador tem o direito a passar para a próxima pista. O jogo tem uma quantidade de carros disponíveis, sendo que inicialmente apenas dois estão habilitados para a escolha e, conforme o desenrolar do jogo, com a quebra de recordes, novos carros são disponibilizados. O jogador tem a chance de executar duas voltas por pista na tentativa de bater o recorde na mesma. Durante o jogo são utilizadas as teclas para cima, para baixo, direita e esquerda para fazer as movimentações, sendo que cada tecla movimenta o jogo em sua respectiva direção. 3.4 Navegação do jogo A Figura 5 apresenta a estrutura de navegação do jogo.

27 27 FIGURA 5 - Diagrama de Navegação do Jogo Uma breve descrição desta das telas do jogo: - Tela de abertura (Splash Screen), a qual devem permanecer com uma imagem por 3segundos. - Tela Menu Principal, o qual contem uma lista de opções para iniciar novo jogo, continuar, visualizar recordes ou tela ajuda. - Novo jogo: inicia um novo jogo, possibilitando a escolha de um carro e de uma pista para iniciar o jogo. - Continuar jogo: possibilita continuar um jogo já iniciado anteriormente. - Recordes: apresenta uma lista com os 5 melhores tempos de cada pista. - Ajuda: apresenta um resumo do jogo, e descrição dos comandos do mesmo. 3.5 Layout do jogo

28 28 Para o desenvolvimento do layout do Jogo foi utilizada a ferramenta Game Design, do NetBeans versão Esta ferramenta permite a criação de cenários, camadas que irão compor um cenário, bem como a definição de sprites. O veículo do jogo foi criado a partir do Sprite da Figura 6. Pode-se observar que o sprite possui as diversas opções de movimento do carro, permitindo a animação em curvas, por exemplo. FIGURA 6 - Sprite do veículo O mapa 1 foi baseado no conjunto de tiles apresentado na Figura 7. FIGURA 7 - Tileset do mapa 1 Para a montagem do primeiro mapa foram criadas duas camadas: uma camada de fundo, a qual permite que o veículo percorra, e a camada de limitação do cenário, com a qual o personagem vai colidir. A figura 8 apresenta essas camadas respectivamente. A criação dessas camadas faz a geração automática dos métodos. O Quadro 1 apresenta o método getfundo_areia(), o qual possui a matriz do mapa da camada de fundo do mapa1.

29 29 FIGURA 8 - Camadas do Mapa 1 Ainda no quadro 1, pode- se observar que a matriz (linhas 7 a 26) é formada por 0 (zero) e 1 (um). Zero indica que não existe nenhuma imagem relacionada com aquela posição. O número 1 indica qual o índice da imagem do tileset faz parte daquela posição. No caso especifico deste mapa, o fundo é formado por uma única imagem. Já o loop formado pelo for (linha 29), faz a leitura desta matriz e desenha a mesma na tela QUADRO 1 - Método getfundo_areia() da classe GameDesign public TiledLayer getfundo_areia() throws java.io.ioexception { if (fundo_areia == null) { // write pre-init user code here fundo_areia = new TiledLayer(20, 20, gettopview_tiles(), 16, 16); int[][] tiles = { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, { 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, { 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0,

30 { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, { 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; // write mid-init user code here for (int row = 0; row < 20; row++) { for (int col = 0; col < 20; col++) { fundo_areia.setcell(col, row, tiles[row][col]); Os métodos das demais camadas, seguem o mesmo padrão. Na figura 9 pode-se observar o cenário criado a partir dessas duas camadas. FIGURA 9 - Cenário completo do Mapa 1 A figura 10 apresenta o layout finalizado dos mapas 2 e 3.

31 31 FIGURA 10 - Cenário completo dos Mapas 2 e 3 A figura 11 apresenta um tileset adicional utilizado para criação das camadas de fundo dos mapas 2 e 3. FIGURA 11 - Tileset adicional dos mapa 2 e Conclusão Este capítulo permitiu uma descrição detalhada do jogo, de forma a viabilizar a etapa de implementação deste projeto. A criação do layout do jogo através do Game Design, do Netbeans, já faz a criação de uma classe, permitindo a reutilização da mesma no desenvolvimento do jogo, sendo que resta para a parte de implementação a lógica do jogo. Devido a complexidade do jogo, algumas etapas não foram implementadas, como a definição de voltas, marcação de tempo, recordes e quantidade de carros. Nesta etapa foi muito importante a revisão bibliográfica realizada do capítulo 2, principalmente para criação de tiles e sprites do jogo.

32 32 4 IMPLEMENTAÇÃO Este capítulo apresenta a descrição da etapa de implementação do Jogo. Primeiramente é apresentada uma descrição da estrutura básica da tecnologia JME, a qual foi utilizada nesta etapa, bem como sua Game API. E, posteriormente, são apresentados os principais fragmentos de código do jogo, tais como, menu principal, sistema de colisão, loop principal do jogo e método de movimentação da tela. 4.1 Java Micro Edition O JME (Java Micro Edition) é dividido em configurations, profiles e APIs opcionais. A configuration mais básica do JME é o CLDC (Connected Limited Device Configuration). É, também, a mais importante, pois ela dá base para a outra configuration, CDC (Connected Limited Configuration), a qual provê algumas funcionalidades a mais, e requer um pouco mais de hardware (CARNIEL et al., 2005). Uma configuration provê algumas bibliotecas básicas e a VM (Virtual Machine), ou seja, a parte mais básica que necessita estar presente em todo e qualquer dispositivo que suporta essa tecnologia (CARNIEL et al., 2005). O CLDC (Connected Limited Device Configuration), rege as configurações para aparelhos bem pequenos, como celulares ou PDAs, e fica acima das diretrizes JME, juntamente com CDC (Connected Device Configuration), o que rege as configurações para aparelhos um pouco maiores, mas mesmo assim pequenos (CARNIEL et al., 2005). Um profile nada mais é que uma série de APIs padrões que, combinadas com

33 33 alguma configuration, no caso o CLDC, provê um serviço completo para que aplicações possam ser executadas. Celulares, em sua quase totalidade hoje no mercado, trabalham com o profile MIDP1.0 e a configuration CLDC Características de implementações do Java Micro Edition A implementação de aplicativos para aparelhos celulares utilizando a plataforma JME possui características inerentes às limitações dos dispositivos físicos (hardware) a que se destinam os aplicativos, tais como baixa capacidade de processamento e pouco espaço para armazenamento. Desta forma, alguns princípios devem ser seguidos para a programação em JME (CARNIEL et al., 2005): O aplicativo deve possuir a menor quantidade possível de objetos; Os objetos devem possuir a menor quantidade possível de atributos e métodos; Laços de repetição, variáveis e objetos estáticos devem ser utilizados com cautela. E, ainda, devido ao tamanho reduzido das telas dos aparelhos celulares, conforme comenta Muchow (2004), as mensagens e os textos são curto, claros e precisos. 4.2 IDE Netbeans O IDE NetBeans é um ambiente de desenvolvimento integrado (IDE), modular e baseado em padrões, escrito na linguagem de programação Java. O projeto NetBeans consiste em um IDE de código-fonte aberto e em uma plataforma de aplicativos, utilizada como uma estrutura genérica para construir qualquer tipo de aplicativo Visão geral da versão

34 34 O NetBeans IDE versão 6.1 fornece diversos novos recursos e melhorias, sendo estes recursos ricos de edição JavaScript, suporte para utilização de framework web Spring, uma integração MySQL mais estreita, e uma forma melhorada de compartilhar livrarias entre projetos dependentes. O suporte aclamado para Ruby/JRuby foi melhorado com novas correções rápidas do editor, um gerenciador de plataforma Ruby, suporte de depuração rápida para JRuby, e muitos outros recursos e correções novos. Por demanda popular, o padrão 'bean' e os recursos de geração JSF CRUD que estavam faltando na versão 6.0 voltaram. Além disso, versões anteriores de módulos atualizados, como suporte ClearCase, estão disponíveis como plug-ins. Essa versão também fornece desempenho melhorado, especialmente inicialização mais rápida (de até 40%), consumo inferior de memória e tempo de resposta melhorada trabalhando com grandes projetos. Veja abaixo uma lista dos recursos dispostos nesta versão. Recursos Melhorias de desempenho Inicialização 40% mais rápida Análise inteligente, de forma que auto-completar código seja mais rápido Consumo inferior de memória Suporte a JavaScript Realce de semântica Auto-completar código e análise de tipo Correções rápidas e verificações semânticas Refatoração Suporte a Spring Framework Biblioteca Spring Framework 2.5 agrupada Assistentes para arquivos de configuração XML e controladores Spring Web MVC Auto-completar código de nomes 'bean' e classes e propriedades Java Suporte de Framework Spring Web MVC no projeto web Novo suporte a MySQL no explorador de banco de dados

35 35 Registro de servidores MySQL Visualizar, criar e excluir bancos de dados Fácil inicialização da ferramenta de administração para MySQL Suporte a Java Beans Padrões Bean no Navegador Gerar propriedade Bean Editor BeanInfo Gerador JSF CRUD Gera um aplicativo JavaServer Faces CRUD a partir de classes de entidade Suporta todos os tipos de relações de entidade (um para um, um para muitos, muitos para um, muitos para muitos). Suporta todos os tipos de chaves primárias (coluna única, composta, e gerada). Suporte Ruby/JRuby Melhorias do editor, incluindo novas dicas e correções Suporte para depuração rápida JRuby Gerenciador de plataforma Melhorias de integração de servidor e banco de dados em projetos Rails Auto-completar código Javadoc Suporta etiquetas etc. Auto-completar código para parâmetros, exceções, etc. Suporte para APIs Populares da Web Crie aplicativos mashup facilmente Arraste e solte operações em um POJO, Servlet, JSP e serviços web RESTful e o NetBeans IDE gera todos os códigos para os serviços de acesso Suporta APIs da web como Google, Facebook, Yahoo, e YouTube Suporte ao serviço Web RESTful

36 36 Construir serviços web RESTful compatíveis com JSR311 usando Jersey Teste seus aplicativos com o novo Cliente de Teste REST Use os assistentes para criar serviços REST de classes de entidade JPA e gerar talões de cliente JavaScript a partir de WADL Compartilhamento de projetos (também conhecido como Bibliotecas compartilháveis) Especificar dependências de biblioteca usando caminhos de biblioteca relacionada (para padrão Java, Web, e todos os tipos de projeto Java EE) Projetos mais fáceis de compartilhar com outros membros da equipe, por exemplo, ao usar sistemas de controle de versões Permite construções autônomas para os projetos Novos plug-ins Controle de versão ClearCase Suporte AXIS Suporte SOAP UI Suporte Hibernate Framework Java Mobility Emulador Mpowerplayer MIDP para aplicativos MIDP no MacOS X (disponível a partir da Central de plug-ins) SVG Composer para componentes personalizados SVG Documentação e estabilidade avançada Visualizações dos recursos do Post-6.1 Suporte de Editor para PHP: auto-completar código, realce de sintaxe, navegação, depuração, e muito mais Depurador JavaScript 4.3 Mobility pack O NetBeans Mobility Pack é um plugin para o desenvolvimento de

37 37 aplicações Java ME na IDE NetBeans. O Mobility Pack pode ser utilizado para escrever, testar e depurar aplicações para a plataforma Java Micro Edition. Ele suporta emuladores e SDKs de vários fabricantes, incluindo os da Nokia. Ele suporta: CLDC 1.0 e 1.1 com MIDP 1.0, MIDP 2.0 e MIDP 2.1 CDC com Personal Profile Recursos Desenvolvimento rápido de aplicações (Rapid Development Application - RAD) em um editor visual (GUI Builder). Você pode facilmente gerar o esquema da aplicação no modo Flow Design do Visual Mobile Designer. Você pode adicionar ao seu Form MIDP 2.0 novos controles personalizados desenvolvidos pela equipe do NetBeans, como o controle Table-Layout. Suporta gráficos SVG (JSR 226) com o editor visual de desenho, testes JMUnit, assinatura MIDlet, gestão de certificado, simulação integrada. Adicionar e executar código de dispositivos específicos como configuração em sua aplicação para múltiplos dispositivos de destino a partir de uma fonte. Ele irá gerar um JAD e JAR para cada configuração. Suporta aplicações multi-linguais. Suporta Web Services diretamente para telefones com Web Services API (JSR 172) disponível. Integra-se com emuladores e SDKs da Nokia. Versão 6.0 inclui: Editor visual de Jogos para GAME API Sprites, Layers e Tiles. Novo editor visual com novos controles, como um explorador de arquivos e compositor de SMS. 4.4 Game API

38 38 O desenvolvimento de jogos para celulares vem ganhando cada vez mais espaço, conseqüentemente, a plataforma JME também é exigida com maior intensidade. Pensando nisso, a MIDP (Mobile Information Device Profile) 2.0 traz um pacote direcionado exclusivamente aos jogos, a Game API, sendo que o mesmo se encontra em javax.microedition.lcdui.game (OGLIARI, 2007). Esta API trás inúmeras vantagens ao desenvolvedor, entre elas uma maior facilidade na portabilidade dos jogos, isto porque, não é mais necessário o uso de bibliotecas de fabricantes para funcionalidades específicas, como é o caso dos Sprites. Desta forma, a Game API é formada pelo conjunto de cinco classes no pacote javax.microedition.lcdui.game, que oferecem poder e simplicidade para formação de jogos para celulares: Game canvas, Layer, Sprites, TiledLayer e LayerManager (Figura 12). FIGURA 12 - Classes da Game API (Fonte: CARNIEL, et al., 2005) A classe Game Canvas é responsável pelo ciclo do jogo, que consiste a verificar os estados das teclas (entrada do usuário), atualizar os estados do jogo, atualizar o buffer gráfico e enviar as imagens à tela (Figura 13). Esta classe é uma melhoria da classe Canvas.

39 39 FIGURA 13 - Lógica seqüencial de um jogo (Fonte: CARNIEL et al., 2005) Toda a implementação do ciclo do jogo é através do método run, o qual vai fazer com que o jogo seja executado em uma thread independente. Para examinar a tecla que está pressionada é usado o método getkeystates e para comparar com uma das constantes que indica uma tecla, utiliza-se o operador &. A classe Layer possui duas subclasses: Classe sprite e Classe tiledlayer. Todo o jogo possui elementos gráficos, mas, conforme apresentado no Capítulo 2, existe um tipo especial de gráfico chamado Sprite; o qual pode ser um personagem ou monstro e, geralmente, são animados e sofrem algum tipo de ação. A classe LayerManager ajuda na renderização de objetos sprites e tiledlayers, pois, ao invés do programador chamar o método paint de cada objeto separado, ele complementa ao LayerManager e chama o método paint desta classe, que é responsável por desenhar as imagens na ordem determinada. Desta forma, o LayerManager organiza as camadas gráficas do jogo (cenário, Sprites. Etc.). 4.5 Menu do jogo Nas linhas 5 a 8 do código apresentado no quadro 2, é feita a configuração das fontes de texto que foram utilizadas no menu. Nas linhas 10 a 12 são configuradas as cores do texto do menu principal. Nas linhas 23 e 24 é definido o vetor com as opções de menu. Na linha 44 cria-se a thread e a linha 45 inicializa a thread. Nas linhas 57 a 63 é verificada a tecla pressionada no menu.

40 QUADRO 2 - Menu do Jogo import javax.microedition.lcdui.*; public class MenuScreen extends Canvas implements Runnable { static final Font lowfont = Font.getFont (Font.FACE_MONOSPACE, Font.STYLE_PLAIN, Font.SIZE_SMALL); static final Font highfont = Font.getFont (Font.FACE_MONOSPACE, Font.STYLE_BOLD, Font.SIZE_MEDIUM); static final int lowcolor = 0x0000FF00; // Not Highlighted static final int highcolor = 0x000000FF; // Highlighted static final int highbgcolor = 0x00CCCCCC; // Highlighted Background static int width; // screen largura static int height; // screen algura static int startheight; // height static final int spacing = highfont.getheight()/2; //espaço entre os itens static final String[] mainmenu = {"Novo Jogo","Continuar Jogo","Recordes","Ajuda"; static int menuidx; // To hold the current highlighted menu option Thread menuthread; // Menu Thread Image bgimage; // BG Image public MenuScreen() {... try { bgimage = Image.createImage("/bg.png"); catch (Exception e) { System.out.println("Error ao carregar a imagem :: "+e); menuthread = new Thread(this); menuthread.start(); public void run() {... // Paint Main Menu public void paint(graphics g) {

41 // Verifica tecla precionada no menu protected void keypressed (int code) { if (getgameaction(code) == Canvas.UP && menuidx - 1 >= 0) { menuidx--; else if (getgameaction(code) == Canvas.DOWN && menuidx + 1 < mainmenu.length) { menuidx++; 4.6 Loop principal do jogo O Quadro 3 apresenta o Loop principal do jogo, definido pela classe Game Canvas. Como já apresentado na figura 13 da sessão 4.2 o jogo possui uma estrutura básica a qual deve ser implementada no loop principal. Nas linhas 9 e 10 pode-se perceber a definição de dois objetos do tipo TiledLayer, os quais forma as camadas de cenário do jogo. O objeto Sprite (linha 11) define a imagem do jogador. Todas esses objetos serão reutilizados a partir da classe GameDesign, a qual foi apresentada na sessão 3.5, durante a criação do layout do jogo. Na linha 19 tem-se a criação do gerenciador de camadas, o qual irá comportar todas as camadas de TiledLayer e Sprites do jogo. No construtor da classe GamePanel (linhas 25 a 53) está a criação e inicialização dos objetos. Nas linhas 33 a 35 está a chamada aos métodos get da classe GameDesign. Na linha 48 está a criação do objeto do lm e, na seqüência, a inclusão (append) do TiledLayer e Sprite nas camadas. O método movimenta (linha 55) é responsável por realizar as leituras das teclas direcionais e alterar a posição do carro em X e Y. O método Start (linha 100) faz a inicialização da thread do jogo. E o método run possui o loop principal do jogo, o qual chama os métodos de leitura de teclas, verificação de colisões e o desenho da tela.

42 QUADRO 3 - Loop Principal do Jogo Classe GamePanel import java.io.ioexception; import javax.microedition.lcdui.*; import javax.microedition.lcdui.game.*; import javax.microedition.media.*; public class GamePanel extends GameCanvas implements Runnable{ private boolean executando; private final TiledLayer superficie; private final TiledLayer fundo; private final Sprite spritecarro; private GameDesign design; private int viewportx = 22; private int viewporty = 22; private long delay; private static final int SPEED = 2; private char direcao; //Verifica direção da tecla de leitura private LayerManager lm; //Gerenciador de Camadas private static final int MIN_BUFFER = 2; private int largura; // Largura Tela private int altura; // Algura da Tela public GamePanel() throws IOException{ super(true); design = new GameDesign(); largura = getwidth(); altura = getheight(); direcao = 'n'; fundo = design.getfundo_areia(); superficie = design.getsuperficie_1(); spritecarro = design.getcarro_3(); delay = 0; lm = new LayerManager(); lm.append(spritecarro); lm.append(superficie); lm.append(fundo); public final void movimenta(int quantidade){ int keystates = getkeystates(); if ((keystates & LEFT_PRESSED)!= 0) { viewportx -= quantidade; spritecarro.setframe(0); spritecarro.move(-speed, 0);

43 if ((keystates & RIGHT_PRESSED)!= 0) { if (direcao!='d'){ spritecarro.settransform(sprite.trans_none); direcao = 'D'; spritecarro.move(-speed, 0); adjustviewport(viewportx + SPEED, viewporty); viewportx+=quantidade; spritecarro.setframe(6); if ((keystates & UP_PRESSED)!= 0) { viewporty-=quantidade; spritecarro.setframe(4); if ((keystates & DOWN_PRESSED)!= 0) { if (direcao!='b'){ direcao = 'B'; spritecarro.setframe(5); spritecarro.move(0, SPEED); viewporty+=quantidade; adjustviewport(viewportx, viewporty+speed); spritecarro.setposition(viewportx, viewporty); private final void verificacolisaoparede() {... public void start(){ executando = true; Thread t = new Thread(this); t.start(); public void stop(){ executando = false; public void run() { Graphics g = getgraphics(); while(executando){ movimenta(1); verificacolisaoparede();

44 desenhatela(g); try{ Thread.sleep(delay); catch(interruptedexception ie){ private void desenhatela(graphics g) { layermanager.paint(g,0, 0); flushgraphics(); private void adjustviewport(int x, int y) { Implementação da colisão A função da colisão é verificar se o pixel de um Sprite colide ou sobrepõe com o pixel de outro Sprite. A classe Sprite possui o método collideswith para fazer a verificação se dois objetos gráficos se chocam. O Quadro 4, apresenta o código do método verificacolisaoparede(). Nele verifica-se (linha 2) se o spritecarro está colidindo com a superfície. Caso ocorra a colisão, o objeto carro retorna para uma posição estável, ou seja, a posição anterior à colisão, evitando que o objeto fique preso na parede, por exemplo. Conforme previsto no projeto, ao colidir com uma parede, o carro perde energia (linha 4) QUADRO 4 - Método verificacolisaoparede() private final void verificacolisaoparede() { if(spritecarro.collideswith(superficie, true)){ movimenta(-1); vida--; 4.8 Implementação da movimentação da tela A movimentação da tela é necessária, pois o cenário é maior que o visor do

45 45 celular. Desta forma, foi implementado o método adjustviewport (Quadro 5), o qual recebe como parâmetro a posição X e Y do visor sobre o cenário. O método é organizado praticamente em duas verificações: Verifica-se se o Sprite não está próximo do fim da tela, desta forma ele não faz o ajuste (linhas 14 a 32). Verifica se a movimentação da tela não vai deixar um espaço em branco visível, tanto em X quanto em Y (linhas 34 a 51). Caso ocorra uma dessas duas verificações, a tela não é movimentada, caso contrário, é feita a movimentação (linha 53) QUADRO 5 - Código do método. adjustviewport do Jogo private void adjustviewport(int x, int y) { int sx = spritecarro.getx(); int sy = spritecarro.gety(); int xmin = viewportx + MIN_BUFFER; int ymin = viewporty + MIN_BUFFER; int xmax = viewportx + largura - spritecarro.getwidth() - MIN_BUFFER; int ymax = viewporty + altura - spritecarro.getheight() - MIN_BUFFER; if (sx >= xmin && sx <= xmax && sy >= ymin && sy <= ymax) { return; if (direcao == 'E' && sx >= xmin) { return; if (direcao == 'D' && sx <= xmax) { return; if (direcao == 'C' && sy >= ymin) { return; if (direcao == 'B' && sy <= ymax) { return; if (x < fundo.getx()) { //nao mostrar espaco em branco viewportx = fundo.getx();

46 else if (x > fundo.getx() + fundo.getwidth() - getwidth()) { viewportx = fundo.getx() + fundo.getwidth() - getwidth(); else { viewportx = x; //verifica buffer if (y < fundo.gety()) { viewporty = fundo.gety(); else if (y > fundo.gety() + fundo.getheight()- getheight()) { viewporty = fundo.gety() + fundo.getheight() -getheight(); else { viewporty = y; lm.setviewwindow(viewportx, viewporty, getwidth(), getheight()); 4.9 Testes do jogo Além da execução do jogo no simulador disponível do NetBeans, foram realizados testes do jogo em um celular Nokia modelo 6125, Samsung SGH-U600, Sony Ericsson W580. Foi observado que no jogo apresenta falha, na escolha das pistas, uma vez que as opções escolhidas não são executadas na primeira tentativa, porém, se insistir e possível entrar na opção desejada. O cronômetro tem inicio a partir do momento que entra no jogo, mesmo antes da escolha das pistas, o que não deveria acontecer. No entanto, o jogo teve um comportamento normal em todos os celulares testados Conclusão Neste capítulo foi apresentada uma breve descrição do JME, com um intuito de conhecer melhor a tecnologia utilizada para o desenvolvimento do jogo proposto. Utilizando a ferramenta NetBeans, Mobility Pack, foi possível a criação de um jogo para celular usando JME, usando a ferramenta Projeto de Jogo Visual, que

47 47 possibilita a criação do Sprite, criação de Layer, para criação das pistas e montagem da cena do jogo. A partir da modelagem e do layout foi possível iniciar a criação do jogo, sendo apresentados neste capítulo os principais fragmentos de códigos disponíveis. Melhoras ainda devem ser realizadas no código, como por exemplo o método de colisão e a implementação de uma aceleração e desaceleração gradativa do carro.

48 48 5 CONSIDERAÇÕES FINAIS O aparelho celular faz parte da vida da maioria da população mundial. Sendo assim, pode-se perceber a importância desta pesquisa sobre jogos. Nesta pesquisa, ao analisar os jogos de computadores e para celulares, bem como as funções específicas de cada um, pode-se perceber que eles apresentam muitas diferenças, dentre elas, as limitações tecnológicas (memória, vídeo), porém a programação do jogo segue uma seqüência lógica semelhante. Assim, o desenvolvimento de jogos para celulares torna-se mais complexo por necessitar tratar das limitações e, em qualquer jogo, é necessário o uso tecnológico e profissional específico de cada aplicativo, bem como a análise de características e capacidade de cada dispositivo. É percebido que os investimentos públicos e privados na indústria de jogos para celular é bem relativo uma vez que o custo de jogos para celular é reduzido, comparando com os de jogos para computadores, devido ao maior tempo necessário na programação, design etc. considerando que os jogos para celulares não envolvem tanta complexidade quando os de computadores. Entre os jogos casuais mais utilizados, estão os jogos de corrida, justamente por serem de simples aprendizado. Porém é notável que todo jogador busque algo no jogo, ou seja, ele sempre quer o melhor e usa do jogo para suprir um desejo de ser o melhor, o campeão. Por essas características, foi definido como estudo de caso para este trabalho um jogo de corrida com tomada de tempo. Com base nesta pesquisa, use a plataforma JME, a qual supre as exigências de pequenos dispositivos, com pouca capacidade de memória, como os aparelhos de celulares. É relevante o fato de que programas produzidos com JME são capazes de

49 49 operar em diversos aparelhos. De forma geral, o processo de desenvolvimento deste trabalho apresentou algumas dificuldades, tais como a criação da arte do jogo, que teve seu processo prejudicado devido a problemas na tentativa de encontrar ferramentas mais apropriadas e a implementação de colisões entre o sprites e o mapa. Buscou-se na revisão bibliográfica a identificação dos pontos críticos na programação. Sendo também demonstrado neste trabalho como é programado um jogo para celular usando JME e a ferramenta NetBeans. Foram realizados testes preliminares em celulares Nokia, Sony Ericsson e Samsung, os quais tiveram seu comportamento adequado, comparando-se aos testes realizados no simulador disponível pela NetBeans. Ainda, para trabalhos futuros, sugere-se a implementação de um modo de jogo multiplayer utilizando a tecnologia Bluetooth, bem como agregar personagens guiados por computador, o que envolve uma programação com Inteligência Artificial dos mesmos.

50 50 REFERÊNCIAS BIBLIOGRÁFICAS AVELAR, Luis. Jogos + celulares. Web Mobile. Curitiba: Neofício, ano I. p , fev./mar AZEVEDO, E. Computação Gráfica: teoria e prática. Rio de Janeiro: Elsevier, BRINCADEIRA DE GENTE GRANDE. O Mercado de games em Florianópolis. 22 ago Disponível em: < /. Acessado em: 05 out CARNIEL, J. et al. Introdução ao J2ME. Web Mobile. Curitiba: Neofício, ano I. p , fev./mar CRESTE, G. Jogos com MIDP 2.0: Personagens. Devmedia. Rio de Janeiro, 16 jan Disponível em: < =4180&hl= >. Acessado em: 05 out ESTADO DE SÃO PAULO. Mercado de videogames deve crescer 50% em quatro anos. O Estado de São Paulo, São Paulo, 23 ago Disponível em: < tecnologia/not_tec39804,0.htm>. Acessado em: 21 out MORETTO, F. E. Desenvolvimento de Jogos com JME f. Trabalho de Conclusão de Curso (Bacharel em Sistemas de Informação) Departamento de Ciências Exatas e Tecnológicas, Universidade do Planalto Catarinense, Lages MUCHOW, J. W. Core J2ME: tecnologia & MIDP. São Paulo: Pearson Education, p. OGLIARI, R. da S. Jogos com MIDP 2.0: Personagens. JavaFree, São Paulo, 23 ago Disponível em: < Acessado em: 06 out PAVETITS, L. Conexão em movimento. WebMobile. Rio de Janeiro, 07 jan ed. 01, ano 01. Disponível em: < forprint.asp?comp=2719 /.. Acessado em: 16 out PERUCIA, A,.S. et al. Desenvolvimento de jogos eletrônicos: teoria e prática. São Paulo: ed. Novatec, 2005 REUTERS. PCs, internet e celulares farão mercado de games crescer 50%. O Globo.

51 51 23 ago Caderno Tecnologia. Disponível em: < Acessado em: 16 out TONYPA. Tile Based Game. Web site com tutorial de Tiles Disponível em: < Acessado em: 27 out WIKIPEDIA Website. Sprite (gráfico). Disponível em: < Sprite_(gráfico)>. Acessado em: 27 out

52 APÊNDICES APÊNDICE A - ARTIGO... 53

53 APÊNDICE A - ARTIGO Programação de jogos para celular em java Marcelo Alves Marciano, Sabrina Bet Koerich, Angelo Augusto Frozza, Departamento de Ciências Exatas Curso de Sistemas de Informação Universidade do Planalto Catarinense (UNIPLAC) Lages SC - Brasil {mam, sabrina, frozza@uniplac.net Abstract. The development of cellphone games usually follows the same steps as those of the development of computer games, which can be summaryzed in game design, art development, programmming and tests. Since cellphone games are simpler, the steps take much less time than in the making of a computer game. On the other hand, like any other game, each development step requires the knowledge of a different king of professional and right technologies for each task. To develop cellphone games, in the chossing of technologies and tools, the development team must pay attention, in every step, to the limitations of the cellphones for which the games are made. This essay addresses, especifically, to problems related with the programming for cellphone games using the Java ME (JME) platform. Resumo. O desenvolvimento de jogos para celular podem ser resumidas em game design, desenvolvimento da arte, programação e testes. Como os jogos para celular são mais simples que os de computadores as etapas de desenvolvimento levam muito menos tempo. Porém, cada etapa de desenvolvimento exige os conhecimentos de um tipo de profissional diferente e a escolha das tecnologias adequadas para cada tarefa. Para desenvolver jogos para celulares, na escolha de tecnologias e ferramentas, a equipe de desenvolvimento deve se preocupar em cada etapa com as limitações existentes nos aparelhos a que se destinam os jogos. Este trabalho aborda, especificamente, os problemas relacionados com a etapa de programação de jogos para celular usando a plataforma Java ME (JME). 1 Introdução O mercado de jogos está aquecido pelo mundo. Segundo o diretor-gerente da EA (Electronic Arts) na Alemanha, Thomas Zeitner (O GLOBO, 2007), "Há 150 milhões de jogadores em todo o mundo, mas 2 bilhões de pessoas estão prontas para jogar". Para o presidenteexecutivo da produtora Ubisoft (ESTADÃO, 2007), "Há tantos clientes novos no negócio. Isso vai fazer o mercado crescer tremendamente. Espero que o mercado cresça 50% nos próximos quatro anos".

54 Descrever a etapa de programação de jogos para celular usando a plataforma Java ME., possibilita um estudo de caso capaz de operar em diversos celulares, de forma a identificar possíveis problemas que possam ocorrer nas diferentes versões. Assim, é importante identificar os pontos críticos na programação de jogos para celular; para entender como é programado um jogo para celular usando JME; No Brasil, muitos desenvolvedores vêem um futuro promissor na área de jogos para celular. Um ponto que influencia alguns desenvolvedores é o fato de a pirataria de jogos para celular não ser tão explorada como em outras plataformas. Diante das expectativas do mercado nacional de jogos e do aumento no número de usuários de celulares, este trabalho tem como objetivo o estudo da etapa de programação de jogos para celular, realizando a criação de um jogo como estudo de caso. Este artigo, nos propõe uma pesquisa sobre o desenvolvimento de jogos para celular utilizando a Game API. Seu desenvolvimento e as diferentes programações, adequadas a cada aparelho. 2 Jogos e programações A popularização dos celulares fez nascer um novo mercado, o desenvolvimento de aplicativos e jogos para equipamentos celulares, palms, smartphones etc. As empresas de telefonia celular têm investido em jogos como um dos diferenciais de seus produtos. Esse mercado é muito promissor e, atualmente, fatura algo em torno de R$ 20 milhões, com um crescimento anual de 30% ao ano (ESTADÃO, 2007). De uma maneira geral, a indústria nacional de jogos vem crescendo, mas em especial, a indústria de jogos em Santa Catarina vem crescendo acima da média nacional, devido aos investimentos públicos e privados nos últimos anos. Esses investimentos foram obtidos devido à disponibilidade de mão-de-obra existente no Estado (MERCADO DE GAMES EM FLORIANÓPOLIS, 2007). Os jogos para celulares, comparados aos jogos para computador de mesa, podem ser criados em menos tempo e a um custo bem menor. Porém, os desenvolvedores têm que se preocupar com as limitações dos aparelhos para os quais os jogos são direcionadas, uma vez que cada aparelho possui características diferentes e essas diferenças podem ser encontradas também entre aparelhos de um mesmo fabricante. Assim, as limitações do hardware representam um complicador no desenvolvimento de jogos para celulares, principalmente aqueles que exigem interfaces gráficas ricamente trabalhadas. Os programadores devem buscar constantemente a otimização de seus códigos, a fim de obter maior desempenho com menor uso de recursos. Para o Brasil, os jogos eletrônicos não só representam o segmento onde mais resultado pode ser obtido com pouco investimento, mas também a chance do país de estar na frente da corrida de geração de conteúdo digital, aliado a um potencial de exportação superior a qualquer outro conteúdo audiovisual. Finalmente, deve-se comentar que a área tem como contribuir e muito para o Brasil atingir a sua ousada meta de 2 bilhões de dólares de exportação de software em 2007 (AVELAR, 2007, p. 7). Como o desenvolvimento de jogos para celulares vem ganhando cada vez mais espaço, conseqüentemente, a plataforma JME (Java Micro Edition) também é exigida com maior intensidade. A JME trata-se de uma plataforma para pequenos dispositivos, com pouca capacidade de memória e processamento como celulares, TV set-top boxes (OGLIARI, 2007).

55 Pensando nisso, a MIDP (Mobile Information Device Profile ) 2.0 apresenta um pacote direcionado exclusivamente aos jogos, a Game API. Com a chegada desta API (Application Program interface), o desenvolvedor tem inúmeras vantagens, como por exemplo, uma facilidade maior na portabilidade dos jogos, isto porque, não será mais necessário o uso de bibliotecas de fabricantes para funcionalidades específicas, como é o caso dos Sprites. E existe a evolução de algumas classes como por exemplo a a classe Canvas existente na MIDP 1.0 evolui para sua sucessora, a GameCanvas (OGLIARI, 2007). Para entendermos esta pesquisa, foram necessárias pesquisas sobre o mercado de jogos, mercado de celulares e vantagens da utilização da linguagem JME. Consta um levantamento bibliográfico sobre as características técnicas que influenciam a programação de jogos para celulares para, em seguida, realizar um estudo mais aprofundado da linguagem Java. Esse levantamento bibliográfico foi realizado através de revistas, artigos publicados em eventos e páginas da web. Em seguida, iniciou-se a implementação do jogo, onde foram identificados os pontos críticos desta etapa, detalhando-se os mesmos. Sendo que os testes do jogo foram realizados paralelamente à etapa de implementação. É importante apresentar as etapas e conceitos necessários para se programar um jogo em duas dimensões. São apresentados os principais conceitos relacionados com os gráficos dos jogos, tais como: os tiles que são as estruturas para montagem de cenários e os sprites usados para criação de animações. Também são apresentadas as principais funções realizadas sobre esses gráficos, tais como: espelhamento, transparência, cores, entre outros. E por fim, são apresentados conceitos sobre a ambientação sonora. 3. Gráficos No passado, o processador do computador era responsável por todo o processamento de vídeo. Hoje, foram modificados os conceitos de modo que a CPU esteja mais disponível para execução de outras funções. Os jogos eletrônicos têm suas cores representadas por uma combinação de três cores: verde, azul e vermelho. Os sistemas computacionais identificam uma cor de acordo com um valor numérico chamado tripla RGB (Red, Green, Blue). Tripla RGB é um conjunto de três valores de 8 bits em que cada valor representa a composição da cor (AZEVEDO, 2003). Assim, o preto possui a intensidade mínima de componentes (0,0,0). O branco possui a intensidade máxima (255, 255, 255). O valor 255 é o número máximo que 8 bits pode representar. O formato de cor diz respeito ao número de bits que o sistema emprega para expor a cor na tela, o qual se ajusta quando se define o modo de vídeo. Os formatos mais comuns são os que empregam 16, 24 ou 32 bits para significar cada cor. Para os formatos de cor de 16 bits usa-se o chamado bits para cada componente de cor. E o chamado bits para os componentes vermelho e azul e 6 bits para verde. Os formatos 24 e 32 bits utilizam 8 bits para significar cada cor. No formato 24 bits a representação é por 3 bytes; já no 32 bits é através de uma variável, onde os últimos 8 bits são ignorados. Superfícies, ou surfaces, são regiões que armazenam dados de imagens lidas de arquivos bitmaps. Podem estar alocadas na memória de vídeo (tratadas pela GPU) ou na memória do sistema (mais lentas, pois são tratadas pela CPU) (PERUCIA et al., 2005).

56 Uma superfície é gerenciada como um retângulo ou uma folha virtual que a aplicação copia, combina, embaralha e rearranja com outras para composição do jogo, produzindo efeitos gráficos e de animação. Portanto, em relação às superfícies, a primária deve ser sempre a primeira superfície a ser criada, logo depois vem a secundária. Somente após a criação destas, pode-se criar as superfícies offscreen que contêm todos os dados visuais do jogo. A função blit é a mais importante função do modo de processamento gráfico. Um blit significa a operação de cópia de dados. A função copia uma região retangular de uma superfície para outra. Trata-se de um processo simples: deve-se definir o frame de origem (onde a imagem está) e o frame de destino (para onde a imagem de origem deve ser copiada) (Figura 1). É habitual em funções de blit a mudança do valor nulo para os parâmetros que representam os frames, mostra que toda a superfície é copiada de uma região para outra. Em algumas ferramentas, se o frame de origem e o de destino forem de tamanhos diferentes é feita uma escala, de modo que a imagem seja desenhada de forma aumentada ou reduzida, em efeito zoom. Uma função muito importante no jogo refere-se a transparência de imagens. Esse recurso é empregado quando se quer desenhar imagens que tem regiões transparentes. Para isso, é definida uma cor que não seja copiada para o quadro destino, chamada de color key ou corchave. Assim que a cópia da superfície é feita, são ignorados todos os pixels que possuem essa cor, criando assim, o efeito de transparência (PERUCIA et al., 2005). É comum se definir a cor rosa como padrão de transparência (R=255, G=0, B=255).) É uma técnica para espelhar a imagem; a qual é obtida pela inversão dos pixels da imagem a ser desenhada em um ou dois eixos (X e Y). Dessa forma, é possível combinar os dois tipos de espelhamento (horizontal e vertical) fazendo com que a imagem seja desenhada com os eixos X e Y invertidos. O espelhamento é aplicado pela GPU no instante em que se faz um blit para uma região de memória. Na computação, existem dois métodos principais na animação para um jogo: page flipping e double buffering. Ambas as técnicas usam a superfície do back buffer para fazer o desenho das imagens do jogo (PERUCIA et al., 2005). Desta forma, o back buffer deve ser usado para desenhar qualquer objeto no jogo, para depois passar para a superfície primária. Caso contrário, ocorre um efeito chamado de flicker. O efeito flicker ocorre justamente porque os dados de vídeo que estão na VRAM são atualizados de forma muito mais rápida que a velocidade com que o monitor ou visor pode ser desenha. O que pode acontecer é que, quando começar a desenhar a animação de um objeto e chegar ao fim do desenho, o canhão já está desenhando um outro quadro de animação do objeto que está na VRAM, fazendo com que a tela seja desenhada de forma assíncrona. Dessa forma, basta fazer a sincronização da superfície primária (front buffer) que é representada pela memória de vídeo com o canhão do monitor, ou seja, a atualização do front buffer (escrita) não pode ser feita enquanto o canhão do monitor estiver desenhando na tela. Essa atualização deve ser feita sempre em intervalos, que é o período em que o monitor fica parado esperando o retorno do último pixel inferior à direita até o primeiro pixel superior à esquerda.

57 Assim, garante-se que o front buffer só é atualizado quando o monitor estiver parado ou retornando, para recomeçar o desenho. Esse procedimento torna os gráficos sempre suaves, sem flicker Assim, o page flipping é um método de animação muito utilizado que evita o efeito flicker, que deve ser feito da seguinte forma: (a) Desenhar as imagens do jogo no back buffer. (b) Quando for gerado um VBlack do monitor, fazer o back buffer virar o front buffer e viceversa. (c) Voltar à operação 1. Dessa forma, quando desenho chega no fim da tela, o front buffer torna-se back buffer e vice-versa, o que faz com que o visor sempre tenha dados que não vão ser mudados durante a sua escrita. O flip altera o endereço da memória onde os dados são apresentados ao monitor. Este endereço muda sempre que o monitor entra no modo Blank. Vale ressaltar que a técnica de page flipping é extremamente rápida e funciona somente em modo de tela cheia. Já o double buffering consiste em se ter dois buffers, o front buffer e o back buffer. Todas as imagens do jogo são desenhadas no back buffer e ao iniciar o jogo tudo é passado para o front buffer através de uma cópia de dados. Através desse método é possível que o jogo funcione em modo janela, tal como ter tamanhos diferentes de front buffer e back buffer. Tileset são conjuntos de imagens que podem ser combinadas para compor cenários de jogos. Esse conjunto deve ser dividido em pedaços iguais de tamanho fixo. O quadro resultante dessa divisão chama-se tile. A figura 3 apresenta o exemplo de um Tileset. Dessa forma, os cenários de jogos são formados de pequenos blocos que se repetem e dão forma ao ambiente. Sprites são estruturas com imagens próprias que permitem a criação de animações e o livre posicionamento na tela. De forma básica, todos os objetos que tem animação ou movimentação em um jogo são nomeados sprites. Assim, um sprite sempre tem uma imagem com um quadro fixo definido e pode ter muitos conjuntos de animações configuradas. A figura 4 apresenta um exemplo sprite com a animação de um personagem de jogo. Um aspecto muito importante do jogo é a ambientação sonora. Os recursos de áudio dão mais vida ao jogo, deixando a experiência de jogá-lo muito mais valiosa e emocionante. É fundamental valorizar o momento da produção sonora, pois os sons ao mesmo tempo em que desenvolve também podem atrapalhar ou mesmo desestimular o jogador caso não estejam em acordo com a proposta do jogo. Sempre que um som é lido por meio de um arquivo é criado um buffer sonoro, o qual é formado por blocos contínuos de memória, usados para a rápida reprodução de sons em jogos (PERUCIA et al., 2005). Os buffers sonoros são blocos contíguos de memória que guardam os dados de um determinado som, o qual pode ser uma música, efeito sonoro ou qualquer outro ruído desejável em um jogo. Dessa forma, todos os sons que são lidos para serem reproduzidos podem ser alocados tanto na Static Random Access Memory (buffer de som em hardware), encontradas nas placas sonoras sofisticadas, como também na memória RAM (buffer de som de software). Porém, os sons alocados na SRAM são imediatos, pois são colocados na placa de som e já reproduzidos pelo hardware. Já, os sons alocados na RAM são mais lentos, pois são transferidos para a placa de som antes de serem reproduzidos.

58 É comum, ao carregar sons, se tentar alocar buffers em hardware. Caso a memória não seja de hardware ou estiver ocupada, os sons são criados em software. Então, primeiro deve-se criar os sons principais, pois são candidatos a ficarem alocadas em hardware, para ser executados de forma mais rápida, e depois, é que se deve alocar os sons menos freqüentes. Existem dois tipos de buffers de som principais em uma arquitetura de som: o secundário e o primário. O buffer secundário é a região de memória que guarda um som alocado. Este se divide em (PERUCIA et al., 2005).: O buffer primário é o primeiro a ser criado. Sempre que um som é reproduzido, o buffer secundário (que contém os dados do som) é enviado e somado aos dados do buffer primário, que então é enviado para reprodução pelos alto-falantes. 4. Design Document Com o conteúdo de sprite foi possível utilizá-los para a criação dos carros, os tiles foram utilizados para a criação dos mapas (pistas). Este estudo de caso trata-se de um jogo para celular na categoria de jogos de corrida, no qual o jogador representa o condutor de um veículo terrestre; O jogo tem como objetivo a simples quebra de record, no qual o jogador conta com a ajuda de um fantasma que lhe mostra o caminho referente ao seu melhor tempo. O jogo proposto é baseado em um jogo chamado TrackMania Nations ESWC, da Nadeo em parceria com a NVidia. O seu objetivo principal é ter o melhor tempo (que o seu tempo anterior) no modo solo. Possui pistas anormais, que são divididas em três categorias: Begginer (Iniciante), Advanced (Avançado) e Expert (Experiente). O jogo TrackMania Nations ESWC é exclusivo para PC e pede uma configuração baixa para rodar. Desta forma, o jogos a ser desenvolvido projeto é baseado no modo solo desse jogo. O jogo proposto, quanto aos desafios, apresenta características de desenvolvimento de habilidades, tais como rapidez, e inclui ainda a simulação de esportes, dentro de um ambiente virtual para entretenimento. Oferece recursos para um único jogador (SinglePlayer), sendo que também nesta versão não há oponentes representados por agentes autônomos controlados pelo computador, pois os mesmo exigiriam a implementação de IA, o qual foge do objetivo deste trabalho. As fases são compostas de pistas de asfalto em circuitos fechados e cercados de gramas, sendo todos os objetos do jogo estáticos. A câmera do jogo sempre acompanha o carro do corredor, podendo ter uma visão em primeira ou terceira pessoa. Trata-se de um jogo casual, acessível ao grande público. Diferentemente dos jogos tradicionais que são mais complexos e exigem tempo de dedicação do jogador, os jogos casuais são simples e rápidos de aprender. Desta forma, podem ser uma opção de diversão para um simples passatempo de alguns minutos. O jogo é implementado utilizando a versão MIDP 2.0 a qual dá suporte à configuração CLDC 1.0, permitindo assim, que recursos adicionais como multimídia, Game API, entre outros possam ser utilizados na implementação do jogo. Com base na plataforma especificada, foram levantados os requisitos mínimos para a execução do jogo: Resolução da tela: 240 x 320 pixels;

59 cores; Teclado direcional e numeric; Linguagem de programação Java ME. Geralmente, jogos casuais, em especial para celulares, não são feitos com o intuito de serem complexos, inclusive porque os celulares possuem bem menos recursos que os jogos para consoles e PCs. Desta forma, o jogo deve apresentar uma baixa curva de aprendizagem, sendo que esta curva indica o tempo que o jogador leva para assimilar os comandos e as regras do jogo. Um jogo com poucas regras e comandos tem uma curva de aprendizagem pequena, pois após poucos minutos de jogo, o jogador está familiarizado com suas possíveis ações e objetivos. Nesse caso, um menu simples contendo uma opção de ajuda, informando quais as possíveis ações do jogo e como realizá-las, é utilizado para que o jogador se familiarize com o mesmo. Como alternativa, as fases iniciais tem um nível de dificuldade mais baixo, para que aos poucos o jogador assimile os comandos (MORETTO, 2006). Conforme já comentado, o jogo conta com uma quantidade determinada de pistas com circuitos fechado, possuindo, essas pistas, diferentes grau de complexidade. Os níveis de dificuldade de cada pista são baseados no tempo gasto para completar as pistas, sendo esses níveis definidos por tempos pré determinados para seu fechamento, classificados como tempo ruim, regular, bom e excelente. O tempo excelente é dado para aqueles jogadores que conseguem o melhor tempo descrito na pista. Vale lembrar que para conseguir os melhores tempos é importante fazer uma volta limpa, sem colisões, o que faz o carro ir mais rápido. O jogador pode abortar sua volta a qualquer hora durante a sua volta, caso ache que fez algo errado ou que não vá melhorar a sua volta. Não há um tempo limite para o jogador terminar a pista. Melhorando o tempo sugerido, o jogador tem o direito a passar para a próxima pista. O jogo tem uma quantidade de carros disponíveis, sendo que inicialmente apenas dois estão habilitados para a escolha e, conforme o desenrolar do jogo, com a quebra de recordes, novos carros são disponibilizados. O jogador tem a chance de executar duas voltas por pista na tentativa de bater o recorde na mesma. Para o desenvolvimento do Layout do Jogo, foi utilizada a ferramenta de Game Design do NetBeans versão Esta ferramenta permite a criação de cenários, camadas que irão compor um cenário, bem como a definição de sprites. O veículo do jogo foi criado a partir do Sprite da Figura 1. Figura 1 - Sprite do veículo O mapa 1 foi baseado no conjunto de tiles apresentado na figura 2.

60 Figura 2 - Tileset do mapa 1 Figura 3 - Camadas do Mapa 1 A criação dessas camadas faz a geração automática dos métodos. O Quadro 1 apresenta o método getfundo_areia(), o qual possui a matriz do mapa da camada de fundo do mapa1. Pode observar que esta matriz (linhas 7 a 26) é formada por 0 (zero), onde não existe nenhuma imagem relacionada com aquela posição, já o número 1, indica qual o índice da imagem do tileset fará parte daquela posição. No caso especifico deste mapa, o fundo é formado por uma única imagem. Já o loop formado pelo for (linha 29), faz a leitura desta matriz e desenha a mesma na tela QUADRO 1 - Método getfundo_areia() public TiledLayer getfundo_areia() throws java.io.ioexception { if (fundo_areia == null) { // write pre-init user code here fundo_areia = new TiledLayer(20, 20, gettopview_tiles(), 16, 16); int[][] tiles = { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, { 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, { 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0,

61 { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, { 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, { 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; // write mid-init user code here for (int row = 0; row < 20; row++) { for (int col = 0; col < 20; col++) { fundo_areia.setcell(col, row, tiles[row][col]); Os métodos das demais camadas, seguem o mesmo padrão. Para a montagem do primeiro mapa, foram criadas duas camadas, uma camada de fundo, a qual permite que o veículo percorra, e a camada de limitação do cenário, com a qual o personagem irá colidir. A figura 3 apresenta essas camadas respectivamente. Já na figura 4, pode-se observar o cenário criado a partir dessas duas camadas. Figura 4 - Cenário completo do Mapa 1

62 A figura 5, apresenta o layout finalizado dos mapas 2 e 3. Figura 5 - Cenário completo dos Mapa 2 e 3 A figura 6 apresenta um tileset adicional utilizado para criação das camadas de fundo dos mapas 2 e 3. Figura 6 - Tileset adicional dos mapa 2 e 3 A etapa de criação do layout do jogo através do GameDesign do Netbeans, já faz a criação de uma classe, permitindo a reutilização da mesma no desenvolvimento do jogo, sendo que resta para a parte de implementação a lógica do jogo. 5. Implementação O JME (Java Micro Edition) basicamente é dividido em configurations, profiles e APIs opcionais. A configuration mais básica do JME é o CLDC (Connected Limited Device Configuration). É, também, a mais importante pois ela dá base para a outra configuration, CDC (Connected Limited Configuration), a qual provê algumas funcionalidades a mais, e requer um pouco mais de hardware (CARNIEL. et al., 2005):. O configuration basicamente provê algumas bibliotecas básicas e a VM (virtual machine), ou seja, a parte mais básica que necessita estar presente em todo e qualquer dispositivo que suporta essa tecnologia (CARNIEL. et al., 2005):. O CLDC (Connected Limited Device Configuration), que rege as configurações para aparelhos bem pequenos como celulares ou PDA's, o qual fica acima das diretrizes JME juntamente com CDC (Connected Device Configuration) o que rege as configurações para aparelhos um pouco maiores, mas mesmo assim pequenos (CARNIEL. et al., 2005):. Um profile, nada mais é que uma série de APIs padrões que, combinadas com alguma configuration, no caso o CLDC, provê um serviço completo para que aplicações possam ser