Desenvolvendo Jogos em Java ME, Notas de estudo de Automação

Baixe Desenvolvendo Jogos em Java ME e outras Notas de estudo em PDF para Automação, somente na Docsity! Daniel Ricardo dos Santos Diogo de Campos Mauricio Oliveira Haensch Desenvolvendo Jogos com Java ME Daniel Ricardo dos Santos Diogo de Campos Mauricio Oliveira Haensch Desenvolvendo Jogos com Java ME PET Computação UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA PROGRAMA DE EDUCAÇÃO TUTORIAL 4.2 Bibliotecas disponı́veis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14 5 Desenvolvendo para Dispositivos Móveis p. 16 5.1 Uso de memória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16 5.2 Resolução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16 5.3 Configurações e perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17 6 Desenvolvendo Jogos p. 18 6.1 A classe MIDLet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18 6.2 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19 6.3 Displays e Displayables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20 6.4 Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20 6.5 Sprites e Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21 6.5.1 Sprites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21 6.5.2 TiledLayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22 6.6 Sons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23 7 Estudo de Caso - Liga Quatro p. 26 7.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26 7.2 Estrutura do código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26 7.2.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26 7.2.2 Eventos do menu principal . . . . . . . . . . . . . . . . . . . . . . . p. 29 7.2.3 A classe TelaDoJogo . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30 7.2.4 A classe Bola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33 7.2.5 PlayTone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35 8 Bibliografia p. 36 5 1 Introdução 1.1 A plataforma Java Java é uma tecnologia que se estende muito além da própria linguagem de programação. Trata-se, na verdade, de uma plataforma de desenvolvimento. A plataforma Java compreende um conjunto de softwares e especificações da Sun Microsys- tems para o desenvolvimento de aplicativos. A grande vantagem desta plataforma é a sua com- patibilidade não apenas entre sistemas operacionais, mas também entre diversas arquiteturas, variando de PDAs e set-top boxes até servidores. As aplicações desenvolvidas nesta plataforma também são diversas, variando de aplicativos embarcados a jogos e aplicativos web. Devido a essa grande variedade a plataforma é dividida em quatro diferentes ”edições”. Cada edição é composta de um pacote de softwares que permitem o desenvolvimento e a execução de programas escritos na linguagem Java. As plataformas são desenhadas não para um processador especı́fico, mas para uma Java Vir- tual Machine (JVM) e um compilador com um conjunto de bibliotecas. A principal vantagem do uso da máquina virtual é aumentar a portabilidade do código. 1.2 Java Card Java Card é a edição mais limitada da plataforma Java e é destinada a smart cards ou dispo- sitivos similares com pouquı́ssima memória. Seu principal foco é a segurança, com suporte ao encapsulamento de dados no aplicativo, firewall entre aplicativos e criptografia. Atualmente, encontra-se em desenvolvimento a versão 3 da plataforma. 6 1.3 Java Micro Edition (ME) Voltada para dispositivos com pouca capacidade de processsamento e memória limitada, principalmente dispositivos móveis. Muito usada em celulares e PDAs, estende-se também para aparelhos como set-top boxes e Blu-ray players. Apresenta algumas dificuldades no de- senvolvimento devido a grande variedade de dispositivos e suas especificidades. A plataforma Java ME é detalhada no próximo capı́tulo. 1.4 Java Standard Edition (SE) É a edição usada para o desenvolvimento de aplicações portáveis de propósito geral. Contém o que necessário para o desenvolvimento de aplicações desktop e applets, como pacotes de in- terface gráfica, entrada e saı́da, comunicação com bancos de dados, etc. Atualmente, encontra-se na versão 6. 1.5 Java Enterprise Edition (EE) Java EE é a maior das edições de Java, compreendendo tudo o que está presente na Standard Edition além de coisas mais especı́ficas, como o servidor de aplicações GlassFish. Voltada para aplicações que rodam no lado do servidor e pensada para tornar as aplições robustas, seguras, escaláveis e portáveis. É usada para o desenvolvimento de aplicações web e baseadas na arquitetura orientada a serviços (SOA), como web services. Atualmente, encontra-se na versão 5. 9 Acesso ao sistema de arquivos: Para se ter acesso ao sistema de arquivos é necessário utilizar o PDA Profile, ou uma implementação especı́fica de um fabricante. Grupos de threads: O suporte a grupos de threads, threads que podem ser manipuladas em conjunto, também só é provido pelo CDC. A figura abaixo mostra uma visão geral dos componentes de Java ME e como eles se rela- cionam as outras tecnologias Java: 2.3 Configurações e perfis As configurações (Configurations) e perfis (Profiles) representam as configurações e APIs mı́nimas disponı́veis em um dispositivo móvel. Cada aplicativo desenvolvido necessita de uma configuração mı́nima para ser rodado, e a garantia de que o dispositivo alvo terá essa configuração é fornecida pelo sistema de Configu- rations e Profiles. As principais Configurations são o CDC e o CLDC e o principal Profile é o MIDP, que são explicados a seguir. O MIDP é a definição de uma arquitetura, e define várias APIs que devem estar disponı́veis em uma plataforma para promover um ambiente de desenvolvimento para as suas MIDlets. A diferença mais importante entre o MIDP 1.0 e o MIDP 2.0 é a introdução de uma API para jogos, 10 que facilita muito a criação deste tipo de aplicativo. A maioria dos aplicativos desenvolvidos para dispositivos móveis são capazes de rodar em plataformas MIDP 1.0, que devem ter as seguintes caracterı́sticas, entre outras: • Tamanho da tela mı́nimo de 96x54pixels. • Input através de “One handed keyboard” ou “Two handed keyboard” ou Touch Screen. • 128Kbytes de memória para os componentes MIDP. • 8Kbytes de memória para dados das aplicações. • 32Kbytes de memória dinâmica. O MIDP 1.0 é baseado em aparelhos que seguem a configuração CLDC, ou seja, os apare- lhos compatı́veis com MIDP também o serão com CLDC. Dispositivos CLDC (Connected Limited Device Configuration) são os aparelhos mais sim- ples, que possuem uma interface menor e pouca memória e velocidade de processamento. De- vem ter no mı́nimo as seguintes caracterı́sticas: • 128Kb de memória para rodar a máquina virtual. • 32Kb de memória dinâmica. • Comunicação em rede com baixa largura de banda. • Baixa potência (para diminuir o gasto de energia). Dispositivos CDC (Connected Device Configuration) são aparelhos mais potentes que os CLDC e devem ter pelo menos as seguintes caracterı́sticas: • 512Kb de memória para executar a máquina virtual. • 256Kb de memória dinâmica. • Capacidade para comunicação em rede com alta largura de banda. • Suporte à persistência. 11 2.4 JCP e JSRs O Java Community Process (JCP) é um processo formalizado para que várias partes inte- ressadas colaborem no desenvolvimento de especificações e futuras versões da plataforma Java. Entre os membros da JCP podemos encontrar operadoras de telefonia como a NTT Do- CoMo, desenvolvedores de dispositivos móveis como a Nokia, a Sony Ericsson e a Motorola, outras empresas e até mesmo pessoas fı́sicas. Os documentos descrevendo as especificações e tecnologias propostas são chamados Java Specification Request (JSR). Esses documentos são publicamente revisados até que um JSR se torne final e seja votado pelo Comitê Executivo da JCP. Um JSR final provê uma implementação de referência, na forma de código fonte e um Technology Compatibility Kit para verificar a especificação da API. O próprio JCP é descrito por um JSR, o JSR 215 de 2006. Os JSRs são especialmente importantes em Java ME, por causa do número de recursos novos e da velocidade com que mudam em dispositivos móveis. Alguns exemplos de JSRs em Java ME: • JSR 30: J2ME CLDC 1.0 • JSR 37: MIDP 1.1 • JSR 68: J2ME Platform Specification • JSR 82: Bluetooth • JSR 118: MIDP 2.0 • JSR 133: Java Game Profile • JSR 139: CLDC 1.1 • JSR 184: Mobile 3D Graphics API for J2ME 14 4 Bibliotecas Java ME 4.1 Java SE x Java ME O Java Micro Edition possui apenas um subconjunto dos componentes da Standard Edition, com uma máquina virtual e algumas APIs mais limitadas. As APIs presentes no Java ME são de- finidas no JCP (Java Community Process). A limitação de memória dos dispositivos que rodam Java ME acabou resultando na retirada de algumas das bibliotecas presentes no Java Standard Edition, para manter a plataforma pequena e adequada ao seu objetivo. Porém, o Java Micro Edition não possui apenas uma especificação. Dependendo da configuração e perfil escolhidos, você pode utilizar diferentes APIs para desenvolver sua aplicação. Com a evolução do poder de processamento e capacidade de memória dos dispositivos, surgem novas funcionalidades mais complexas através dos JSRs. Como exemplo disso, podemos citar a ausência de variáveis do tipo ponto flutuante (como o double) em versões mais antigas de configurações e perfis do Java ME. Devido à essa diferença entre as duas edições, nem toda aplicação desenvolvida em Java SE funcionará num dispositivo que roda Java ME. 4.2 Bibliotecas disponı́veis Como dito anteriormente, as APIs disponı́veis para desenvolver a sua aplicação resultam da combinação de configuração e perfil adotados pelo programador. Utilizando como exemplo a versão 1.1 do CLDC (Connected Limited Device Configuration), os pacotes presentes para o desenvolvimento da sua aplicação são: • java.io • java.lang • java.lang.ref • java.util 15 • javax.microedition.io Outra diferença de bibliotecas entre a Standard Edition e a Micro Edition é em relação à interface das aplicações. O SWT e Swing da edição padrão de Java não se encontram na versão ME. A Micro Edition conta com um novo pacote para este fim, chamado java.microedition.lcdui, que pode ser encontrado em qualquer versão do MIDP. A versão 2.0 do MIDP contém os se- guintes pacotes: • java.io • java.lang • java.util • javax.microedition.io • javax.microedition.lcdui • javax.microedition.lcdui.game • javax.microedition.media • javax.microedition.media.control • javax.microedition.midlet • javax.microedition.pki • javax.microedition.rms Como podemos notar, existe uma série de pacotes exclusivos do JavaME (os iniciados com javax.microedition). Assim, com a presença de alguns pacotes exclusivos, também pode-se afirmar que nem toda aplicação escrita em Java ME funcionará na plataforma Java SE. 16 5 Desenvolvendo para Dispositivos Móveis 5.1 Uso de memória Os dispositivos para os quais se desenvolve em Java ME, em geral, possuem pouca memória, sendo isso um fator de risco para o desenvolvimento de aplicações desse tipo, juntamente com a capacidade de processamento. Para evitar isso, deve-se ter um cuidado maior para essa classe de software. A utilização de estruturas de dados e tipos de dados mais simples é um bom começo para reduzir o uso de memória. Outra saı́da é reduzir o número de objetos criados, ou reduzir o tamanho dos objetos que são utilizados na aplicação. As imagens utilizadas também são uma grande fonte de Out of Memory Error, a exceção que ocorre ao se utilizar memória em excesso. Se mesmo com esses cuidados ainda existem problemas com memória, você pode usar um profiler para auxiliar a encontrar usos desnecessários ou ineficientes de memória. Um Profiler é uma ferramenta que ajuda a encontrar bottlenecks da sua aplicação, achando memory leaks e rastreando a vida dos objetos. Com essas informações, é mais fácil encontrar problemas na implementação que ocasionam os erros de uso de memória da sua aplicação. 5.2 Resolução Os diferentes dispositivos que suportam aplicações em Java ME possuem resoluções de tela diferentes. Assim, na hora de desenvolver esse tipo de software, é preciso ter em mente alguma resolução um pouco mais especı́fica para a qual será desenvolvida a aplicação. É muito mais fácil desenvolver para uma resolução especı́fica do que tentar fazer um software mais geral que rode em várias resoluções diferentes. Normalmente são lançadas algumas versões do software, cada uma para uma resolução di- 19 6.2 Commands Os commands do Java ME são usados para gerar e tratar eventos. Por exemplo, um comando pode ser associado a um botão, ou imagem, de modo que, quando este for selecionado, ou clicado, o evento será disparado. Um command guarda a informação semântica de uma ação, como pode ser visto pelos tipos de comandos existentes, mostrados mais abaixo. Desse modo, ele é responsável apenas pelo sig- nificado, e não à ação propriamente dita. A ação fica como responsabilidade da implementação de um CommandListener associado à tela em o Command se encontra. Um comando deve ser criado da seguinte maneira: Command(String shortLabel, String longLabel, int commandType, int priority) Onde shortLabel é o nome abreviado do comando, longLabel é o nome completo do co- mando e commandType é o tipo do comando. Há também um outro construtor para objetos da classe Command, com a ausência do parâmetro longLabel. Os tipos possı́veis do commandType são os seguintes: • OK • ITEM • SCREEN • HELP • BACK • CANCEL • EXIT • STOP A prioridade de um comando só é importante se algum objeto disparar mais de um evento de uma vez, neste caso, somente o comando de maior prioridade é avaliado. Estes comandos devem então ser tratados por uma classe que implementa a interface Com- mandListener. Nesta classe será definido o método commandAction que vai decidir que ação deve ser tomada quando cada evento é disparado. 20 Exemplos de implementações de commands e CommandListeners podem ser encontrados no final desta apostila, na seção Estudo de Caso - Liga Quatro ou neste site: http://pt. wikibooks.org/wiki/J2ME/Li%C3%A7%C3%B5es/CommandListener 6.3 Displays e Displayables O Display é único por MIDlet e é o responsável por funções relacionadas à tela do dispo- sitivo. Para obter uma referência ao Display, a aplicação deve utilizar o método getDisplay. Através dessa classe, é possı́vel chamar métodos para obter algumas informações importantes para a sua aplicação, como o número de cores do aparelho, ou até mesmo se ele suporta cores. A classe Display também possui métodos para controlar funções do dispositivo, como vibrar, através do método vibrate, e um efeito de luz do aparelho, com o método flashBackLight. Um objeto só possui a capacidade de ser inserido no Display ao estender a classe Dis- playable. Porém, um Displayable apenas tem capacidade para ter comandos, listeners, tı́tulos e tickers associados a ele. Tudo que é mostrado e a sua interação com o usuário é definida através de subclasse, como é o exemplo do Canvas. A utilização do Displayable é feita com os métodos setCurrent e getCurrent da classe Display, que troca e retorna o objeto do tipo Displayable atualmente na tela, respectivamente. Caso não seja definido nas subclasses do Displayable, a configuração inicial do seu objeto será: • Não visı́vel no Display; • Tı́tulo null; • Nenhum ticker associado ao Displayable em questão; • Nenhum command existente; • Nenhum listener para comandos. 6.4 Canvas A classe Canvas é uma subclasse de Displayable, e é utilizada para objetos da sua aplicação que precisam fazer alterações gráficas na tela, ou receber eventos de teclas pressionadas no dispositivo. Em geral, os jogos utilizam muito essa classe, para poder interagir com o usuário tanto na recepção de estı́mulos quanto na apresentação dos resultados desses estı́mulos. 21 Esta classe é responsável por tratar eventos de entrada, como teclas pressionadas, soltas ou mantidas pressionadas (keyPressed, keyReleased e keyRepeated, respectivamente) e também eventos com um pointer de um PDA (similares aos de tecla). É possı́vel verificar qual das teclas foi pressionadas com o método getKeyCode, mas em Java ME existe um artifı́cio que é recomendado para os desenvolvedores de jogos, que é o sistema de Game Actions. Os Game Actions são definidos para aplicações portáveis que utilizam as teclas de setas de um dispositivo e eventos relacionados a jogos. O MIDP provê os seguintes Game Actions: UP, DOWN, LEFT, RIGHT, FIRE, GAME A, GAME B, GAME C e GAME D. Cada Game Action pode estar a associado a mais de um Key Code, porém cada tecla só pode estar associada à um Game Action. A aplicação pode traduzir um Key Code para um Game Action através do método getGameAction e fazer o oposto através de getKeyCode. Apesar de vários Key Codes poderem estar associados ao mesmo Game Action, apenas um deles é retornado com este método. Outra função do Canvas é o controle gráfico do que é exibido. Isso é feito através do setFullScreenMode, que tanto coloca quanto tira do modo de exibição em tela cheia, e o método repaint, que renderiza o Canvas por completo ou apenas uma região dele, artı́ficio muito útil para reduzir o tempo gasto com processamento para repintar uma área sem alterações. 6.5 Sprites e Tiles Entre as bibliotecas do Java ME, existem as classes Sprite e TiledLayer, que são utiliza- das para fazer os objetos animados e o fundo do seu jogo, respectivamente. Um Sprite, por sua definição, é uma imagem ou animação em duas ou três dimensões que será utilizada para representar um objeto, e muitas vezes são usados para detectar colisões ou fazer algum tipo de interação do jogo. Já os Tiles são usados para representar o fundo da tela, usualmente uma paisagem, um tabuleiro ou alguma cena de um jogo. 6.5.1 Sprites Para a classe Sprite, um arquivo de imagem é dividido em vários frames de tamanho igual, e você pode criar livremente uma sequência dos frames para gerar sua animação. Para animar sua sequência, são usados métodos como o nextFrame, setFrame e prevFrame. Com esta classe do Java ME também é possı́vel definir a área de colisão de um sprite, assim como verificar se houve colisão entre dois sprites, entre um sprite e um Tile ou até mesmo entre um sprite e uma imagem, utilizando métodos como defineCollisionRectangle e collidesWith. 24 O estado Unrealized indica que o Player não possui nem informações nem recursos ne- cessários para funcionar. Realized indica que apenas os recursos não foram adquiridos ainda. O estado Prefetched significa que todos os recursos já foram adquiridos. Já o estado Closed mostra que o Player está fechado e, por fim, Started é o estado de um Player que já foi iniciado. Além dos estados e dos métodos para se trocar entre eles, a classe Player tem também métodos para descobrir a duração da mı́dia a ela atribuı́da, fixar um número de repetições para a mı́dia e descobrir o estado atual, entre outros (getDuration, setLoopCount e getState, respec- tivamente). A Mobile Media API também possui o Control, cujos objetos podem ser utilizados para controlar algumas funções das mı́dias. Por exemplo, o Player suporta um VolumeControl, que pode ser utilizado para controlar o volume do aúdio desse Player. Existe também o ToneControl, que é responsável por manipular sequências de tons monotônicos, uma outra forma de produzir sons para a sua aplicação. A classe Manager ainda possui o método playTone, que é uma maneira bem mais simples de se colocar sons no seu jogo. Este método recebe como parâmetros a nota, a duração e o volume, e produz um tom monotônico como resultado. Este tipo de som pode ser útil em diversos tipos de jogos ou aplicações, que não necessitam de algo mais complexo do que pequenos tons para os efeitos sonoros. Há apenas o risco de esse tipo de solução ocupar muitos recursos da CPU, 25 que acontece apenas em casos de dispositivos que não possuem suporte para geração de tons. 26 7 Estudo de Caso - Liga Quatro 7.1 Introdução Nesta seção vamos falar um pouco sobre o jogo que nós escolhemos para implementar na plataforma Java ME, o Liga Quatro. O jogo, também conhecido em inglês como Four in a Row, Four in a Line, ou pelo nome registrado Connect 4, é um jogo simples de tabuleiro para dois jogadores, que jogam em turnos alternados colocando suas fichas em colunas com o objetivo de ser o primeiro a conectar quatro fichas, seja na vertical, na horizontal ou em qualquer diagonal. Cada jogador escolhe uma coluna por turno e sua ficha é depositada no primeiro espaço livre daquela coluna. Este jogo foi escolhido por dois motivos principais: a possibilidade de se comparar a implementação do jogo em Java ME e Java SE, ampliando o aprendizado da tecnologia em estudo, e a interface simples. A possibilidade de comparação de implementações se deu porque os bolsistas envolvidos já estavam desenvolvendo o jogo em Java SE para a disciplina de Estruturas de Dados. Essa comparação permitiu uma análise detalhada das diferença entre as duas tecnologias e as dificul- dades de se portar o código para uma plataforma móvel. Uma das maiores dificuldades foi modificar alguns trechos para se adaptar à baixa capaci- dade de processamento e de memória dos dispositivos móveis. 7.2 Estrutura do código 7.2.1 Commands Aqui estão declarados os atributos da classe MidletL4 do tipo Command. O construtor do Command recebe como primeiro parâmetro o texto que será mostrado ao usuário para represen- tar o comando. Outro parâmetro é o tipo de comando, que pertence a um Enum (BACK, EXIT, 29 * Tela a ser exibida. */ public void trocarTela(Displayable proximaTela) { display = getDisplay(); display.setCurrent(proximaTela); } 7.2.2 Eventos do menu principal Os comandos executados na tela principal do jogo são tratados de forma um pouco diferente. Os comandos foram associados à botões da telaMenu. Assim, toda vez que um botão é pressi- onado, emitindo um evento, o comando é disparado e tratado por um ItemCommandListener. /** * Cria um Listener para comandos nos itens do menu principal do jogo. */ private ItemCommandListener listenerDeItens = new ItemCommandListener() { public void commandAction(Command comando, Item item) { if (item == botaoDeNovoJogo) { Controlador.getInstance().resetar(); comecarNovoJogo(); if (pausado == true) { pausado = false; telaMenu.delete(0); //Remove a opcao de continuar o jogo } } else if (item == botaoDeContinuarJogo) { trocarTela(telaJogo); pausado = false; telaMenu.delete(0); } else if (item == botaoDeOpcoes) { 30 trocarTela(getTelaOpcoes()); } else if (item == botaoDeAjuda) { trocarTela(getTelaAjuda()); } else if (item == botaoDeSobre) { trocarTela(getTelaSobre()); } else if (item == botaoDeSair) { fecharMIDlet(); } } }; Como cada Item (botão) possui somente um comando, o método só precisa avaliar qual foi o item pressionado. Abaixo, temos um exemplo de associação de um comando a um botão. Em seguida, associ- amos ao botão o ItemCommandListener mostrado no código acima. botaoDeNovoJogo.addCommand(botaoOK); botaoDeNovoJogo.setItemCommandListener(listenerDeItens); 7.2.3 A classe TelaDoJogo A classe TelaDoJogo estende GameCanvas e é responsável pela tela principal do jogo, incluindo detecção das teclas pressionadas, atualização do que é mostrado na tela e efeitos sonoros. O método abaixo é responsável pela atualização da tela. Os parâmetros recebidos servem para delimitar a região que será redesenhada na tela, para questões de minimização de esforço em certos momentos da execução do programa. O método flushGraphics chamado é o que atualiza na tela aquilo que estava no buffer dentro de área desejada. 31 /** * Atualiza uma parte da tela do jogo. * @param x * Posiç~ao horizontal em pixels onde começa a área a ser atualizada. * @param y * Posiç~ao vertical em pixels onde começa a área a ser atualizada. * @param largura * Largura em pixels da área a ser atualizada. * @param altura * Altura em pixels da área a ser atualizada. */ public void refresh(int x, int y, int largura, int altura) { layer.paint(g, 0, 0); flushGraphics(x, y, largura, altura); } Para a detecção de estı́mulos do usuário, o método keyPressed é definido recebendo o código da tecla pressionada como parâmetro. O que fazemos é detectar se o que foi passado corresponde às teclas 4, 6 ou 5, que movimentam a ficha do jogador para esquerda, para a direita ou confirma a jogada, respectivamente. Há outro trecho condicional que verifica se o código da tecla pressionada corresponde à algum gameAction. O gameAction é um mapeamento das teclas especiais de movimentação um aparelho celular especı́fico para jogos. Assim, com os dois tipos de verificação de teclas apresentados abaixo, é possı́vel utilizar tanto as teclas numéricas quanto as direcionais para se jogar. /** * Detecta as teclas que s~ao pressionadas durante o jogo. * @param keyCode * Código da tecla pressionada. */ public void keyPressed(int keyCode) { switch (keyCode) { case KEY_NUM4: 34 Para criar o sprite, passamos como parâmetro a imagem contendo os frames desejados, e também a dimensão do sprite (neste caso, a altura e a largura são iguais). bola = new Sprite(imagemDaAmarela, diametro, diametro); Abaixo temos o método responsável por mover a bola para a direita. O método inicia to- mando a posição atual da bola. A seguir, o sprite é atualizado para o último frame da sequência do sprite, que representa uma imagem vazia. Essa imagem é pintada na tela com o método refresh da classe TelaDoJogo. Isso faz com que a bola suma na tela do usuário. Logo após, o sprite é movido uma casa para a direita e o sprite é atualizado para o primeiro frame da sequência, que contém a bola cheia. Essa bola é pintada novamente na tela com o mesmo método, fazendo com que ela reapareça. Por questões de otimização, o método refresh() pinta apenas a área em que a bola está se movimentando, para não pintar desnecessariamente as regiões em que não há modificação na tela. /** * Move a bola para uma casa para a direita. */ public void moverParaDireita() { int x = bola.getX(); int y = bola.getY(); bola.setFrame(3); TelaDoJogo.getInstance().refresh(x, y, diametro, diametro); bola.move(diametro, 0); bola.setFrame(0); TelaDoJogo.getInstance().refresh(x + diametro, y, diametro, diametro); } Este método simples move o sprite x pixels no eixo x e y no eixo y. 35 public void mover(int x, int y) { bola.move(x, y); } 7.2.5 PlayTone Para a utilização de sons no jogo, optamos pelo uso do método playTone. Este método pertence à classe Manager do Java ME e é responsável por produzir um tom, dado sua duração e a nota. Os sons presentes no Liga Quatro são produzidos após cada jogada e ao mostrar a tela de vitória, derrota ou empate. Um exemplo pode ser conferido abaixo: /** * Toca o efeito sonoro da bola amarela. */ public void tocarEfeitoBolaAmarela() { try { Manager.playTone(79, 100, 100); Thread.sleep(100); Manager.playTone(77, 100, 100); } catch (InterruptedException ex) { ex.printStackTrace(); } catch (MediaException ex) { ex.printStackTrace(); } } O método playTone recebe como primeiro parâmetro a nota, que deve ser um número entre 0 e 127 e é calculada através de uma fórmula encontrada em http://java.sun.com/javame/ reference/apis/jsr118/. Como segundo parâmetro, é passada a duração da nota em milis- segundos. O terceiro parâmetro do método corresponde ao volume do tom, que deve ser entre 0 e 100. Assim, produzimos dois tons para o efeito sonoro da bola amarela, com uma pausa entre eles. O Thread.sleep é utilizado para que os tons produzidos não se sobreponham durante sua execução. 36 8 Bibliografia CLDC 1.1 http://java.sun.com/javame/reference/apis/jsr139/ MIPD 2.0 http://java.sun.com/javame/reference/apis/jsr118/ IDE Netbeans http://www.netbeans.org/ Sun http://www.sun.com/ Wikipedia http://en.wikipedia.org/wiki/Java_Community_Process The Java ME Frequently Asked Questions List http://bellsouthpwp.net/m/c/mcpierce/javamefaq.html