Documente Academic
Documente Profesional
Documente Cultură
Monografia apresentada ao Departamento de Cincia da Computao da Universidade Federal de Lavras, como parte das exigncias do Curso de Cincia
da Computao, para obteno do ttulo de Bacharel.
Orientador
Prof. Ricardo Martins de Abreu Silva
Lavras
Minas Gerais - Brasil
Junho de 2003
Monografia apresentada ao Departamento de Cincia da Computao da Universidade Federal de Lavras, como parte das exigncias do Curso de Cincia
da Computao, para obteno do ttulo de Bacharel.
Lavras
Minas Gerais - Brasil
vi
Sumrio
1
Introduo
9
10
10
11
12
14
16
18
18
19
21
25
30
50
51
53
53
56
57
58
60
62
65
66
67
67
68
69
73
77
89
93
Resultados e discusses
101
4.1 Vantagens na utilizao do profile MIDP 1.0 para a construo de
jogos multiplayers . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.2 Desvantagens na utilizao do profile MIDP 1.0 para a construo
de jogos multiplayers . . . . . . . . . . . . . . . . . . . . . . . . 103
Concluses
105
5.1 Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2 Sugestes para trabalhos futuros . . . . . . . . . . . . . . . . . . 106
viii
Lista de Figuras
1.1
1.2
1.3
1.4
4
4
5
7
2.1
ix
13
14
16
18
23
27
28
32
33
35
37
38
40
46
47
48
49
51
52
53
53
54
54
56
59
60
61
61
62
63
68
72
73
74
74
76
76
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
79
80
80
81
81
82
82
83
84
85
85
87
88
90
90
92
92
93
95
97
98
xii
99
Lista de Tabelas
3.1
3.2
5.1
70
71
Resumo das concluses obtidas com relao a utilizao da plataforma J2ME no desenvolvimento de jogos multiplayers. . . . . . . 107
Captulo 1
Introduo
Atualmente, vivemos em um mundo onde a informao a principal ferramenta das pessoas e empresas para garantir a sua sobrevivncia no mercado. Este
novo paradigma iniciou-se com a chegada da Internet, em meados da dcada de
90. Considerada o maior repositrio de informaes do mundo, ela permite a troca
de conhecimentos de maneira mais rpida e fcil.
Os pequenos dispositivos mveis (como o Personal Digital Assistant (PDA) e,
recentemente, os celulares mais poderosos) e a comunicao wireless formam uma
das principais armas das pessoas para que estas se mantenham constantemente informadas, conectadas ao mundo, onde quer que estejam e sem que tenham que
carregar muito peso. Portanto, estas tecnologias foram as responsveis por criar
um mercado totalmente novo, o de desenvolvimento de aplicaes para os dispositivos mveis. Alguns tipos de aplicaes geralmente procuradas so acesso
informaes e notcias, leitura de correio eletrnico, transaes bancrias e entretenimento. O uso da Internet por estes dispositivos tambm tem crescido muito
nestes ltimos tempos, caracterizando o conceito de Internet Mvel (ou Internet
sem fio).
A Figura 1.1 apresenta uma pesquisa da Revista Poder [POD2002] sobre os
principais usos da Internet sem fio por parte das pessoas. A Figura 1.2 tambm
apresenta uma pesquisa desta mesma revista com relao ao tipo de contedo mais
desejado pelos consumidores do mercado de dispositivos mveis.
De acordo com a diviso proposta por Monica Pawlan[PAW2002], o mercado
para os servios e aplicaes wireless muito grande, podendo ser dividido em
dois segmentos:
Segmento consumidor: consiste de jogos, servios standalone, aplicaes de
3
No restante desta monografia, quando se for realizar uma referncia a plataforma Java 2 Platform Micro Edition, se utilizar a sigla J2ME.
2
Por vrias vezes, no restante desta monografia, ser utilizada a abreviao Sun quando se for
fazer uma referncia a Sun Microsystems.
cipantes variaram grandemente, mas isto no significa que este mercado no crescer, uma vez que a pior previso apresentada ainda revela aumento de mercado.
O grfico, elaborado pelo autor, apresentado pela Figura 1.4 ilustra as previses de
crescimento esperadas no mercado de jogos para celulares nos prximos anos.
Captulo 2
2.1
Comunicaes wireless
2.2
Produtos de consumo baseados em microprocessadores, como os alarmes, mquinas de caf, televises, ar condicionados e telefones so chamados de dispositivos embutidos (ou dispositivos embarcados) pelo fato de eles possurem pequenos
computadores dentro deles com uma funo muito bem delimitada. Os celulares tradicionais so exemplos de dispositivos embutidos. Entretanto, os aparelhos
mais novos j se assemelham aos computadores deskop, ou seja, permitem a execuo de aplicaes variadas.
Dispositivos embutidos de consumo e que no esto conectados a parede por
um fio, mas ao invs disso usam tecnologia wireless para se comunicar so chamados de dispositivos mveis embutidos. Entre os vrios tipos destes dispositivos
podemos citar o handheld, telefones celulares, pagers e todos os tipos de PDAs
10
[PAW2002].
A maioria destes dispositivos pode se comunicar atravs de links wireless. Estes links podem ser estabelecidos atravs de luz infravermelha (IR, do ingls infrared) ou, mais freqentemente, ondas de rdio (RF, do ingls radio frequency)
[JON2002].
Um exemplo comum de dispositivo mvel que utiliza IR para estabelecer um
link de comunicao o controle remoto do aparelho de som ou da televiso. Os
telefones celulares e dispositivos wireless usam RF para se comunicar e utilizam
um sistema mais elaborado, baseado em antenas, que no ser detalhado neste
projeto [JON2002].
vegador chamado de WebRunner, foi desenvolvido. Ele foi apresentado por Gosling no Hollywood-Meets-Silicon-Valley juntamente com dois exemplos de applets animadas, aplicativos Java que executam em um navegador web.
O lanamento oficial ocorreu em 23 de maio de 1995 durante a conferncia
SunWorld.
Nesta poca, a tecnologia Java fugiu um pouco de sua idia original, que era
trabalhar com dispositivos embutidos, e utilizou a web para ganhar popularidade.
Entretanto, atualmente, sabe-se que seu campo de atuao bem maior do que
apenas o desenvolvimento de applets.
As pessoas geralmente se referem a tecnologia Java no sentido nico da linguagem de programao Java, mas isto no est correto. Na verdade, trata-se de
uma linguagem de programao e de uma plataforma. As prximas subsees iro
explicar melhor estes dois conceitos.
2.3.1
2.3.2
A plataforma Java
2.3.3
verso 1.2 foi chamada de Java 2 e uma diviso da plataforma em edies foi realizada. Esta diviso permite organizar melhor o desenvolvimento e crescimento
da tecnologia Java em trs grandes reas:
Servidores;
Desktops;
Pequenos Dispositivos.
Cada edio possui todas as ferramentas e suprimentos necessrios para o desenvolvimento e execuo de aplicativos. Por fim, as edies que fazem parte da
atual plataforma Java 2 so:
Java 2 Platform, Standard Edition (J2SE) [JSE2002], cujo alvo so as aplicaes desktop convencionais;
Java 2 Platform, Enterprise Edition (J2EE) [JEE2002], com nfase no desenvolvimento de aplicaes server-side para empresas com necessidade de
servir seus consumidores, fornecedores e empregados com solues slidas e completas de negcios pela Internet. Projetada para multiusrios e
aplicaes que tem por base a modularizao, reutilizao e padronizao
de componentes. Ela um superconjunto da J2SE e adiciona APIs para a
computao do lado do servidor;
Java 2 Platform, Micro Edition (J2ME) [JME2002], um conjunto de tecnologias e especificaes desenvolvidas para pequenos dispositivos como
smart cards, pagers e telefones celulares. Ela usa um subconjunto dos componentes J2SE, tais como subconjuntos das mquinas virtuais e APIs mais
fracas. Representa um retorno s origens do Java.
A Figura 2.4 ilustra de maneira didtica a relao entre as edies atuais da
plataforma Java 2 e os dispositivos que elas buscam atender. Alguns nomes citados
na figura sero explicados posteriormente neste captulo.
As especificaes para J2SE, J2EE e J2ME so desenvolvidas de acordo com
o Java Community Process (JCP). Uma especificao comea seu ciclo de vida
como uma Java Specification Request (JSR). Um grupo de experts consistindo de
representantes dos interesses de companhias formado para criar a especificao.
O JSR ento ir passar por vrios estgios na JCP at ser terminado. Quem continua decidindo tudo a Sun Microsystems, mas as empresas passam a ter acesso a
revises de produtos e podem dar as suas opinies sobre eles. Maiores informaes
sobre o JCP podem ser encontradas no site oficial[ORT & GIG2003].
17
2.4
2.4.1
2.4.2
Um pouco de histria
O J2ME no a primeira aventura da Sun Microsystems no mundo dos dispositivos embutidos e dos handhelds, mas sim uma volta ao objetivo inicial da empresa
ao iniciar o projeto que deu origem ao Java. Ele o descendente das primeiras plataformas da Sun para pequenos dispositivos: a parte Oak do projeto Green (no
incio de 1990), JavaCard (1996), PersonalJava (1997), EmbeddedJava (1998) e,
mais recentemente, o Spotless System e o KVM (1999). Hoje, a plataforma J2ME
atinge todos os tipos de dispositivos eletrnicos, dos low-end aos high-end, com
uma nica plataforma Java. O JavaCard ainda est separado do J2ME, embora
altamente relacionado a ele1 .
Em seguida, sero apresentados maiores detalhes das tecnologias anteriores ao
J2ME citadas acima.
Oak - O projeto Green: o surgimento da tecnologia Java deu-se com o Oak,
uma linguagem de programao orientada a objetos, independente de mquina e
um ambiente para a programao de dispositivos de consumo eletrnicos. O Oak
foi uma linguagem interpretada e projetada para executar em dispositivos com
restries de recursos. Mas, como j apresentado, seu surgimento aconteceu em
um mercado que no estava preparado para seus novos ideais. A Sun, por sua vez,
no mais dedicou esforos na tecnologia Java para dispositivos eletrnicos at a
chegada do PersonalJava.
1
Esta seo foi baseada no artigo de Enrique Ortiz[ORT2002A] sobre J2ME, onde o autor dedica
um pouco do seu espao para falar sobre o mundo wireless da Sun antes da chegada do J2ME e como
se deu o seu surgimento.
19
PersonalJava: esta nova tecnologia buscou atingir os dispositivos com capacidade de conexo a algum tipo de rede e com interface grfica, tais como os PDAs
e outros dispositivos baseados na web.
O ambiente de aplicaes PersonalJava, baseado primeiramente nas APIs do
JDK1.1 (com poucos pacotes da JDK1.2), requer suporte completo tanto para a
especificao da linguagem Java como da mquina virtual Java. A atual e talvez a
ltima verso da especificao do PersonalJava a verso 1.2a.
Esta tecnologia deixar de surgir como uma parte separada da plataforma Java,
pois na prxima reviso ela ser includa no Personal Profile, uma parte do J2ME
que ser discutida posteriomente neste captulo.
EmbeddedJava: o ambiente de aplicaes EmbeddedJava foi criado com o objetivo de atingir os dispositivos embutidos com funcionalidade dedicada e restries de memria, tais como dispositivos de controle de processos ou automotivos
(como um sistema de localizao). Baseado na JDK1.1, este ambiente de execuo
muito similar ao ambiente de execuo PersonalJava, mas ao invs de definir um
subconjunto especfico da plataforma Java ele permite a companhias ou indivduos
licenciarem a tecnologia para o uso somente dos componentes necessrios para um
dispositivo em particular. A ltima verso do EmbeddedJava a verso 1.1.
As especificaes EmbeddedJava deixam que o licenciado escolha quais so
as caractersticas da plataforma Java que eles querem dar suporte em seus dispositivos. A idia que eles no podem expor estas caractersticas para uso por uma
terceira parte, somente os seus prprios desenvolvedores podem escrever aplicaes que executem neste dispositivo.
A Sun descontinuou a especificao EmbeddedJava e parou de oferecer suporte para ela, aconselhando queles que usam EmbbededJava a procurarem a
configurao e profile J2ME que mais se adequarem as suas necessidades2 .
JavaCard: a tecnologia JavaCard complementar a do J2ME. Ela adapta a
plataforma Java para o uso em smart cards, um ambiente muito especializado, com
severas restries de memria e processamento, no adequado para a programao
de propsito geral. Um tpico dispositivo JavaCard tem uma CPU de 8 a 16 bits,
de 1 a 5MHz e com memria da ordem de 1KB de RAM e 32KB de memria no
voltil (EEPROM ou flash).
Aplicaes comuns da tecnologia JavaCard (chamadas applets JavaCard) incluem identificao digital, armazenamento seguro e cartes Subscriber Identity
Module (SIM), que podem ser inseridos em diferentes celulares para fazer ligaes utilizando a prpria conta pessoal. Os celulares GSM utilizam este tipo de
2
20
2.4.3
Arquitetura
A plataforma J2ME no define uma nova linguagem. Ela faz uma adaptao
da tecnologia Java existente para handhelds e outros dispositivos embutidos.
J2ME mantm a compatibilidade com a J2SE sempre que possvel. De fato,
ele procura ao mesmo tempo remover partes desnecessrias das outras plataformas e definir novas classes para as extremas limitaes dos pequenos dispositivos
[ORT2002A].
Ao contrrio do J2SE, J2ME no uma pea de software e nem uma especificao nica. Ao invs disso, ele uma coleo de tecnologias e especificaes
que foram projetadas para diferentes partes do mercado de pequenos dispositivos.
[SUN2003A].
O J2ME possui objetivos diferentes quando comparado com J2SE e J2EE,
resultando em uma arquitetura muito diferente. Segundo James White e David
Hemphill[WHI & HEM2002], os objetivos chave que guiam esta arquitetura so:
Proporcionar suporte a uma grande variedade de dispositivos com diferentes
capacidades. Estes dispositivos freqentemente variam em caractersticas
como interface com o usurio, armazenamento de dados, conectitividade a
rede, largura de banda, memria, consumo de energia, segurana e requisitos
de desenvolvimento;
21
Proporcionar uma arquitetura que possa ser otimizada para dispositivos pequenos e com alta restrio de recursos;
Foco em dispositivos que podem ser altamente personalizados, freqentemente utilizados apenas por uma nica pessoa;
Proporcionar conectitividade a rede atravs de uma grande variedade de servios e capacidades de acesso. A conectitividade a rede fundamental para
os dipositivos que fazem parte do campo de atuao de J2ME;
Proporcionar uma maneira de entregar as aplicaes e dados sobre uma rede,
principalmente wireless, para o cliente;
Proporcionar uma maneira de se desenvolver aplicaes para dispositivos
sem ter que se preocupar com o modelo e fabricante para o qual se est
desenvolvendo;
Maximizar a atuao de Java entre as vrias plataformas possveis e, ao
mesmo tempo, utilizar das vantagens nicas de cada dispositivo.
Para atender a estes objetivos o J2ME foi dividido em configuraes e profiles3 .
Uma configurao define o ambiente de execuo J2ME bsico. Este ambiente inclui uma mquina virtuale um conjunto de classes derivadas da plataforma
J2SE. Cada configurao est voltada para uma famlia especfica de dispositivos
que possuem capacidades similares. Uma configurao, por exemplo, pode ser
projetada para dispositivos que tem menos que 512KB de memria e uma conexo
intermitente a rede.
Um profile construdo sobre uma configurao de maneira a extend-la atravs da adio de APIs mais especficas para criar um ambiente completo para
a construo de aplicaes. Em outras palavras, os profiles proporcionam classes que esto voltadas a usurios de um tipo de dispositivo mais especfico que o
abrangido por uma configurao e cuja algumas funcionalidades (como a interface
com o usurio) no foram cobertas por ela. Nem todos os dispositivos suportam
todos os profiles. No Japo, por exemplo, a NTT DoCoMo lanou um grande
nmero de celulares baseados em CLDC, mas com seu prprio profile. Assim,
aplicaes escritas para estes dispositivos no iro trabalhar com celulares que no
foram desenvolvidos pela NTT DoCoMo [ORT & GIG2001].
3
O termo profiles, apesar de ser em ingls, ser altamente utilizado neste texto, devido ao seu uso
consagrado, ao invs de perfis, sua traduo para o portugus.
22
No restante desta monografia, quando se utilizar a sigla CDC ser para indicar uma referncia a
Connected Device Configuration
5
No restante desta monografia, quando se utilizar a sigla CLDC ser para indicar uma referncia
a Connected Limited Device Configuration
23
JSR 169: JDBC for CDC/FP. JDBC a maneira atravs da qual as aplicaes Java padres se comunicam com banco de dados relacionais. Este
pacote cria uma verso otimizada e reduzida do JDBC padro para o profile
CDC.
As prximas subsees apresentam as configuraes e profiles mais importantes que integram a plataforma J2ME 6 .
2.4.4
As caractersticas da configurao CLCD e das duas verses do profile MIDP sero apresentadas
em maiores detalhes, pois esta organizao a mais adequada para o desenvolvimento de aplicaes
para celulares. Como o objetivo principal deste projeto analisar a tecnologia J2ME no desenvolvimento de jogos multiplayers para celulares, as anlises, discusses e concluses sero feitas sobre
esta organizao. Assim, justifica-se a importncia de defini-las corretamente e de maneira ampla.
25
Figura 2.6: Classes que fazem parte do Generic Connection Framework (GCF),
segundo a especificao CLDC.
27
128 KB. As especificaes dos dispositivos apropriados para trabalhar com esta
mquina so: processador de 16/32 bits RISC/CISC com pelo menos de 160KB
de memria total, sendo 128 KB para a mquina virtual e o restante destinado s
aplicaes. Esta mquina foi desenvolvida na linguagem C e objetiva ser completa
(de acordo com a especificao CLDC) e to rpida quanto possvel (executando
de 30% a 80% mais rpido que a mquina padro do J2SE). A KVM, como conhecida esta mquina virtual, apenas uma implementao de referncia da Sun,
ou seja, ela foi construda apenas para exemplificar a especificao CLDC. Assim, os fabricantes de dispositivos podem escolher port-la para seus aparelhos ou
simplesmente desenvolver sua prpria mquina virtual.
A mquina virtual CLDC HotSpot foi projetada para a nova gerao de dispositivos mveis que possuem grande memria disponvel. As especificaes
dos dispositivos que podem utilizar esta mquina so: processadores de 32 bits
RISC/CISC com memria de 512KB a 1MB.
Atualmente, a verso da configurao CLDC mais utilizada a 1.0, que possui
as caractersticas citadas acima. No entanto, encontra-se em processo de desenvolvimento a verso 1.1, que acrescentar caractersticas to importantes quanto o
suporte a pontos flutuantes.
2.4.5
Durante o restante da monografia, a sigla MIDP ser por vrias vezes utilizada como uma referncia a Mobile Information Device Profile.
8
Esta seo encontra-se fortemente baseada na documentao da API das duas verses do profile
MIDP.
30
instanciado. Aps a instanciao, um Item, do tipo StringItem, contendo a frase a ser exibida no celular adicionado ao objeto mMainForm,
seguido por um objeto Command. A linha 13 diz a MIDlet qual classe ir
responder aos eventos do tipo Command. Neste exemplo a prpria classe
ir tratar este tipo de evento.
Na linha 17, obtm-se uma referncia ao objeto Display que utilizada
para setar a tela atual para mMainForm, que por ser do tipo Screen pode
ser apresentado no display do dispositivo.
A sada deste programa pode ser vista na Figura 2.12, que apresenta a captura de uma tela de celular.
Figura 2.13: Modificaes feitas no GCF pelo profile MIDP verso 1.0. As novas
interfaces implementadas encontram-se circuladas de vermelho.
Classes adicionadas do J2SE pelo MIDP 1.0. As classes java.lang.
IllegalStateException, java.util.Timer e java.util. TimerTask foram includas de maneira a possibilitar a escrita de cdigo que
executa em threads de background em tempos especficos;
APIs de acesso ao sistema. O MIDP 1.0 no possui classes que permitem
o acesso direto as caractersticas de um dispositivo, como gerenciamento de
energia e telefonia;
Segurana. O MIDP 1.0 no acrescenta nenhum pacote com mecanismos
de segurana ao CLDC. Em particular, apesar de suportar o protocolo HTTP
no suporta o protocolo HTTPS, que a verso segura do HTTP.
Resumindo, os pacotes que fazem parte da API do MIDP 1.0, excludos os
implementados pelo CLDC, so:
javax.microedition.lcdui, interface com o usurio;
javax.microedition.rms, armazenamento persistente;
javax.microedition.midlet, ciclo de vida da aplicao;
javax.microedition.io, acesso a rede e incluso de suporte ao protocolo HTTP.
O Mobile Information Device Profile verso 2.0[MID2003] (JSR-118) acrescentou diversas caractersticas e melhorias a especificao MIDP 1.0, mas continuou com o objetivo da primeira verso de ser um ambiente de desenvolvimento
aberto e desenvolvido em conjunto com diversas empresas.
40
O MIDP 2.0 objetiva explorar melhor a capacidade dos novos aparelhos celulares que esto chegando no mercado. Segundo Qusay Mahmoud[MAH2003], no
MIDP 2.0, um dispositivo deve possuir as seguintes caractersticas mnimas:
Uma tela de tamanho 96x54 e profundidade de 1 bit (preto e branco);
Um dos seguintes mecanismos de entrada: teclado de telefone, teclado QWERTY
ou toque na tela;
Conectividade a rede: wireless e com largura de banda limitada;
Habilidade de reproduzir tons (suporte a sons);
256KB de memria (incluindo CLDC), 8 KB de memria no voltil para
armazenamento persistente e 128KB de memria voltil para o ambiente de
execuo Java.
A especificao do MIDP 2.0 baseada na do MIDP 1.0 e completamente
compatvel com ela. Assim, aplicaes escritas para MIDP 1.0 iro executar sem
problemas nos novos aparelhos que suportam MIDP 2.0. Algumas novas caractersticas do MIDP 2.0, enumeradas por [MAH2003], so:
Comunicao via sockets e datagramas;
Suporte a HTTPS e secure sockets (SSL);
Incluso do over-the-air provisioning, apresentado na seo 3.2;
APIs especficas para o desenvolvimento de jogos;
APIs para udio e vdeo.
Os novos pacotes adicionados pelo MIDP 2.0 foram:
javax.microedition.lcdui.games, voltado ao desenvolvimento
de jogos;
javax.microedition.pki, voltado a segurana, permite o uso de certificados para autenticar informaes em conexes seguras;
javax.microedition.media, proporciona acesso a funes multimdias;
41
Melhorias nos objetos de interface de alto nvel com o usurio. As grandes mudanas foram realizadas nas classes Form e Item. O layout de formulrios consideravelmente mais sofisticado que no MIDP 1.0. Os itens
antigamente s podiam ser colocados da esquerda para a direita em linhas
de cima para baixo. Agora, este layout pode ser modificado, mas a implementao que ainda decide exatamente onde os itens sero colocados e o
seu tamanho. A novidade que agora pode-se definir um tamanho mnimo
e preferencial que pode ser escolhido pela aplicao.
Um novo integrante dos objetos de layout no MIDP 2.0 o Spacer, Item
no navegvel que representa um espao em branco e permite um ajuste
mais cuidadoso do layout. O seu funcionamento idntico as imagens espaadoras que so utilizadas na confeco de sites. No item ChoiceGroup
foi includo o tipo POPUP.
Comandos podem ser adicionados a qualquer Item em MIDP 2.0, no apenas a um Displayable.
Um novo Item, chamado CustomItem, foi implementado. Este novo
item auxilia na personalizao dos controles, permitindo a criao de novos
itens pelo prprio desenvolvedor. O conceito similar ao de um Canvas,
o CustomItem permite o desenho de qualquer nova forma e a resposta a
eventos de interface com o usurio.
A API de jogos (GAME API). Este pacote ser muito detalhado devido a
sua importncia no desenvolvimento de jogos e tambm para tornar possvel
uma comparao com a implementao do jogo modelo que foi desenvolvido sem as novas tcnicas disponibilizadas por este pacote.
Esta foi uma das grandes mudanas no MIDP 2.0. A Sun e as empresas
que ajudaram no desenvolvimento dessa nova especificao reconheceram
a importncia do mercado de jogos para celulares e deram especial ateno
na construo de um pacote especfico para a sua criao. Este novo pacote
possibilita a automatizao de vrios processos necessrios a fase de desenvolvimento de um jogo e especialmente til para jogos 2D baseados em
tiles.
A idia bsica por trs deste novo pacote est no fato de o contedo de
uma tela poder ser composto de diferentes camadas. Assim, pode-se colocar qualquer contedo em uma camada e ir encaixando-as uma sobre a
outra para formar o efeito desejado. As camadas podem ser manipuladas
independentemente.
43
Este ndice negativo e comea a partir do -1. Cada tile animado faz
referncia a um esttico que corresponde a figura inicial que ser apresentada.
As clulas na matriz de um objeto TiledLayer possuem todas o
mesmo tamanho, sendo que o nmero de linhas e colunas de cada clula especificado no construtor. O tamanho das clulas o mesmo
tamanho dos tiles.
O contedo de cada clula especificado pelo ndice do tile. Um ndice
0 indica que a clula est vazia, portanto nada ser desenhado em seu
lugar. Por padro todas as clulas contm o ndice 0.
O contedo alterado atravs dos mtodos setCell() e fillCells(). Vrias clulas podem conter o mesmo tile, entretanto, uma
nica clula no pode conter mais de um tile.
A Figura 2.15 ilustra como construir um fundo utilizando uma TiledLayer.
Figura 2.17: Modificaes feitas no GCF pelo profile MIDP verso 2.0. As novas
interfaces includas por esta especificao encontram-se circuladas de vermelho.
A seguir encontra-se uma descrio das classes que no faziam parte da
verso anterior do profile MIDP:
CommConnection, define uma conexo com uma porta serial;
HttpsConnection, define os mtodos e constantes necessrios para
estabelecer uma conexo segura via rede;
SecureConnection, define um fluxo de conexo por sockets seguro;
SecurityInfo, define os mtodos necessrios para se accessar informaes sobre uma rede segura;
ServerSocketConnection, define um servidor baseado em sockets;
SocketConnection, define uma conexo por sockets;
UDPDatagramConnection, esta interface define uma conexo por
datagramas no confivel.
49
Para este projeto foi utilizada a interface SocketConnection para estabelecer uma conexo com o servidor. A utilizao da API do MIDP 2.0
restringiu-se a esta classe.
Push Registry. Este novo sistema permite que um servidor inicie remotamente uma aplicao, devidamente registrada, no aparelho do usurio;
Compartilhamento de dados. Aplicaes em MIDP 2.0 podem compartilhar seus arquivos de registro.
O Personal Digital Assistant Profile estende as capacidades do MIDP 1.0 (por
isso, deve ser construdo sobre este profile) e requer o CLDC 1.1. Ela proporciona
APIs para a interface com o usurio e o armazenamento de dados para dispositivos
como o handheld, Personal Digital Assistants e Palm Pilots, com as seguintes
caractersticas:
No menos que 1000KB de memria total (ROM + RAM) disponvel para
o ambiente de execuo Java e bibliotecas e no mais que 16MB;
Potncia limitada;
Tipicamente operado a bateria;
Acesso bidirecional a rede, intermitente e com largura de banda limitada;
Interfaces com o usurio com variados graus de sofisticao, mas tendo displays com uma resoluo mnima de pelo menos 128x128 pixels, um dispositivo de apontamento e uma entrada de caracteres.
O PDA o primeiro profile baseado na CLDC criado especificamente para
dispositivos PDAs. Esta especificao foi desenvolvida com o objetivo de aproveitar melhor alguns recursos comuns a todos os PDAs, como acesso a agenda
de endereos e a listas de coisas a fazer. Os PDAs tambm tender a possuir mais
capacidades que os simples dispositivos baseados no MIDP.
A relao entre o MIDP e o PDAP ilustrada na Figura 2.18, retirada do artigo
de Enrique Ortiz[ORT2002A].
2.4.6
A especificao J2ME Connected Device Configuration (CDC), JSR36, baseada na especificao da mquina virtual Java clssica. Ela define um ambiente
50
2.4.7
2.4.8
Como j apresentado, os telefones celulares tn caractersticas que vo de encontro as especificaes da configurao CLDC. Assim, eles iro implementar os
profiles existentes para esta configurao, mais especificamente o profile MIDP.
Com isso, as anlises realizadas no prsimo captulo sero realizadas exclusivamente sobre esta organizao.
A Figura 2.21 apresenta a organizao atualmente implementada pelos aparelhos celulares.
2.4.9
Distribuindo a aplicao
Neste cenrio, um consumidor vai a uma pgina web, ou pgina wap. A pgina
lista as aplicaes disponveis para cpia.
Se o consumidor quer comprar sua aplicao, ele a seleciona da pgina web
usando seu aparelho de telefone mvel. Ao selecionar a aplicao inicia-se automaticamente o download do arquivo .jad, da ordem de dezenas de bytes, da rede
para o aparelho. Como este arquivo muito pequeno ele copiado rapidamente e
de maneira barata atravs da conexo wireless.
O arquivo JAD tem a funo de dizer algumas coisas bsicas ao consumidor,
como:
A verso da aplicao a ser instalada, evitando assim que se faa o download
de uma verso igual ou menor a uma j instalada no aparelho;
Tamanho da aplicao atual, se o usurio tem somente 2KB de espao disponvel e a aplicao tem 6KB ele pode mostrar uma janela dizendo que o
usurio no tem espao suficiente para armazenar aquela aplicao. Isto
bom para o consumidor porque ele no perde tempo e dinheiro na sua conexo wireless copiando uma aplicao para a qual ele no tem memria
suficiente.
Uma vez que o consumidor est pronto para fazer o download da aplicao e
o JAM confirmou que h espao suficiente, a cpia inciada. O JAM ir salvar a
aplicao no dispositivo e ento apresentar um menu de seleo para que o usurio
possa inici-la.
Segundo a especificao MIDP, a abilidade de realizar o download e instalao
de contedo, por demanda, sobre uma rede wireless conhecida pelo termo overthe-air provisioning (OTA).
Da perspectiva dos clientes mveis, como j foi apresentado, o conceito de
OTA est relacionado como a maneira com que o dispositivo se comporta na operao de encontrar uma aplicao interessante na web, iniciar o download via rede
wireless, instal-la e deix-la pronta para o uso.
Segunto Enrique Ortiz[ORT2002B], os participantes deste processo so:
Dispositivo Cliente, que deve possuir uma aplicao que torne possvel a
busca de aplicaes na rede;
A rede, que qualquer rede wireless;
Servidor de downloads, que um servidor visvel na rede onde se est executando um aplicativo web server que tem acesso a um repsitrio de contedo. o responsvel por apresentar ao cliente as aplicaes disponveis;
55
2.5
2.6
A tecnologia Java, como j foi dito anteriormente, est presente em uma grande
gama de dispositivos, desde cartes de crdito, passando por mquinas desktop at
aplicaes para servidores. Assim, possvel interligar todos estes dispositivos,
fazendo com que eles trabalhem juntos, atravs do uso de uma nica linguagem.
A Sun Microsystems[SUN2003A] apresenta trs grandes vantagens na utilizao da tecnologia Java e da plataforma J2ME para o desenvolvimento de projetos:
A plataforma Java segura. Cdigos Java sempre executam dentro dos limites da mquina virtual que, por sua vez, prov um ambiente seguro para
a execuo de cdigo abaixado da Internet. Uma aplicao binria poderia travar o aparelho ou at mesmo obrigar-nos a reinici-lo. No caso de
uma aplicao Java, o mximo que poderia ocorrer algum problema com
a mquina virtual, sem afetar o funcionamento do aparelho;
A linguagem Java excelente e permite uma programao robusta. Algumas
caractersticas, como o coletor de lixo automtico, so muito eficientes na
preveno de bugs comuns em outras linguagens de programao. A sintaxe
de Java torna fcil a escrita de programas e a sua compreenso;
Portabilidade uma grande vitria para a tecnologia Java wireless. Um
nico executvel pode ser executado em mltiplos dispositivos. Por exemplo, quando se escreve um MIDlet, uma aplicao MIDP, ela ir executar
em qualquer dispositivo que implementa a especificao MIDP. At mesmo
se uma aplicao Java faz uso de APIs especficas de um certo fabricante, as
aplicaes escritas em Java so mais fceis de serem modificadas em comparao quelas feitas em C ou C++.
57
2.7
Jogos multiplayers
mais conhecidos 9 :
Topologia Peer-to-Peer (ponto-a-ponto). Em um projeto de sistema ponto
a ponto, existem diferentes estaes de trabalho interconectadas de maneira
que cada uma delas pode enviar mensagens diretamente a qualquer ponto
da rede. Aqui podem ocorrer trs tipos de comunicao entre os pontos da
rede:
Multicast. Neste tipo de comunicao as mensagens so enviadas a
grupos de pontos dentro da rede ou at mesmo para a rede toda.
Unicast. Permite a comunicao apenas entre dois pontos de cada vez.
Neste tipo de topologia os clientes, geralmente, mantm informaes completas do estado atual do jogo. Esta caracterstica cria um problema em potencial: o fato de ela no ser escalvel, ou seja, quanto maior for o nmero de
clientes maior vai ser o nmero de atualizaes a serem feitas e conseqentemente o overhead de mensagens ser enorme. Assim, ela freqentemente
utilizada quando o nmero de clientes reduzido.
A Figura 2.25 ilustra este tipo de arquitetura.
O modelo utilizado por este projeto ser melhor detalhado no prximo captulo.
59
Neste tipo de topologia deve-se evitar sobrecarregar o servidor, visto que ele
ser o elemento crtico da rede. O ideal otimizar a freqncia com que as mensagens so enviadas. Os problemas ocorrem quando o servidor no consegue responder a tempo todas as requisies vindas dos clientes.
A Figura 2.26 ilustra os modelos de arquitetura baseados em servidor.
2.8
Esta seo foi escrita com base no captulo de sockets do Java Tutorial[SUN2002E].
60
3. Se tudo ocorrer bem, o servidor aceita a conexo e obtm um novo socket com uma porta diferente. Esta etapa de criao de um novo socket
necessria para permitir que a porta atual fique livre para continuar a receber requisies de outros clientes enquanto atende as necessidades do atual
cliente conectado;
4. Do lado do cliente, se a conexo aceita, um socket criado e passa a ser
utilizado para realizar a comunicao com o servidor. Note que o socket do
lado do cliente no limitado ao nmero de porta usado para conectar-se ao
servidor. Ao invs disso, ao cliente atribudo um nmero de porta local,
ou seja, da sua prpria mquina;
5. O cliente e o servidor podem agora comunicar-se livremente, apenas escrevendo e lendo de seus sockets.
A Figura 2.27 e a Figura 2.28 representam, respectivamente, um cliente tentando realizar uma conexo com um servidor e uma conexo j estabelecida entre
dois computadores.
2.9
Threads de execuo
Esta seo foi escrita com base no captulo de threads do Java Tutorial[SUN2002E].
62
mesmo programa, ao mesmo tempo e realizando tarefas diferentes. Esta caracterstica torna possvel a construo de aplicaes muito mais complexas. Este
esquema ilustrado na Figura 2.30
63
64
Captulo 3
3.1
3.2
3.2.1
Editores de cdigo
Um editor de cdigos utilizado para escrever o cdigo das aplicaes a serem desenvolvidas. Ele pode ser um simples editor de texto, como o notepad do
Windows ou o joe do Linux, ou estar incorporado a um grande ambiente de desenvolvimento integrado (IDE, do ingls Integrated Development Environment),
como o Sun One Studio[ONE2003] da Sun Microsystems ou o JBuilder[JBU2003]
da Borland.
Java no exige que se use nenhum editor em especial, permitindo ao desenvolvedor utilizar aquele que mais lhe agrada.
Alguns editores gratuitos e famosos para se escrever aplicaes em Java so o
JCreator LE[JCR2003], o Sun One Studio e o JEdit[JED2003]. Segue uma breve
descrio de cada uma destas ferramentas:
O Sun One Studio, como o prprio nome j diz, distribudo pela Sun e
um ambiente totalmente integrado para o desenvolvimento de aplicaes
Java em qualquer plataforma. Est disponvel em verses para Linux e Windows.
O JCreator LE uma verso gratuita de um ambiente mais poderoso chamado JCreator Pro. Est disponvel somente para Windows.
O JEdit um editor muito famoso pela quantidade de plug-ins que oferece
e tambm por ser totalmente escrito em Java, o que garante a sua portabilidade.
No fcil determinar critrios que permitam avaliar qual o melhor editor
a ser utilizado por um projeto, na maioria das vezes esta escolha uma questo
pessoal. Neste projeto, o JEdit foi o escolhido devido a sua grande facilidade de
67
uso, a alta funcionalidade apresentada, o fato de ser portvel e por j ser utilizado
freqntemente pelo autor do projeto.
A Figura 3.1 apresenta a janela de trabalho do JEdit.
3.2.2
Emuladores
3.2.3
Criao de aplicaes
Antes de se iniciar uma discusso sobre o processo de criao de uma aplicao necessrio apresentar uma definio para o termo MIDlet, que ser freqentemente citado. Uma MIDlet uma aplicao feita segundo o profile MIDP. Caso
fosse utilizado o profile PDA seria uma PDAlet.
1
As tabelas foram compiladas a partir dos manuais do Wireless Toolkit, distribudos pela Sun
Microsystems[SUN2002B][SUN2003B].
69
MIDP
1.0 e 2.0
DefaultGrayPhone
1.0 e 2.0
MinimumPhone
1.0
RIMJavaHandheld
1.0
Motorola_i85s
1.0
PalmOS_Device
1.0
MediaControlSkin
2.0
QwertyDevice
2.0
Descrio
Telefone genrico
com um display colorido.
Telefone genrico
com um display em
tons de cinza.
Telefone genrico
com um display
de
capacidade
limitada.
RIM do Research
In Motion Ltd.
Motorola i85s da
Motorola, Inc.
Palm OS Personal
Digital Assistant da
Palm, Inc (A emulao usa o POSE.).
Telefone genrico
com controles de
udio e vdeo
Dispositivo
handheld
genrico que usa o
estilo de teclado
QWERTY.
Um outro termo utilizado ser a sute de MIDlet. Uma sute de MIDlet, segundo a Sun Microsystems[SUN2002B], um agrupamento de MIDlets que podem compartilhar recursos em tempo de execuo. Mais formalmente, uma sute
de MIDlet inclui:
70
Dispositivo
Display
Resoluo Mecanismos de
Entrada
DefaultColorPhone
180x208
256 cores
DefaultGrayPhone
180x208
MinimumPhone
96x54
RIMJavaHandheld
198x202
Motorola_i85s
111x100
MediaControlSkin
180x208
256 tons
de cinza
preto e
branco
preto e
branco
preto e
branco
256 cores
QwertyDevice
640x240
256 cores
ITU-T
keypad
ITU-T
keypad
ITU-T
keypad
teclado
QWERTY
ITU-T
keypad
ITU-T
keypad
teclado
QWERTY
Nmero Teclas
de
EspeciSoft
ais
Buttons
2
2
0
0
BACK,
MENU
MENU
MENU
2
2
MENU,
Shift,
Ctrl,
Char
Um arquivo manifesto descrevendo o contedo do arquivo JAR (parecido com o arquivo JAD).
A Figura 3.2 apresenta a organizao dos componentes citados acima:
Uma explicao detalhada sobre como utilizar o J2ME Wireless Toolkit e sua ferramenta KToolBar pode ser encontrada nas duas verses dos manuais Users Guide Wireless
Toolkit[SUN2002B][SUN2003B] distribudos pela Sun Microsystems.
72
3.3
O jogo Alea Jacta Est foi desenvolvido de acordo com a arquitetura clienteservidor. Neste modelo, o servidor controla toda a lgica do jogo e o cliente fica
responsvel apenas pela renderizao de imagens e outras tarefas mais simples.
73
75
Figura 3.6: Classes que fazem parte do jogo Alea Jacta Est.
A pilha de especificaes definidas pela plataforma J2ME e que foi utilizada
no desenvolvimento do Alea Jacta Est est ilustrada na Figura 3.7.
3.3.1
A interface
mveis utilizando o profile MIDP. Alm disso, ele tambm possui uma viso geral
de todos os componentes disponveis para a construo destas interfaces. Assim,
recomenda-se a sua leitura antes de se iniciar o desenvolvimento de softwares com
esta especificao.
A API do profile MIDP 1.0, conforme apresentado no captulo 2, proporciona
dois modelos para a construo de interfaces: alto nvel e baixo nvel.
O jogo Alea Jacta Est foi desenvolvido sempre pensando em manter a portabilidade da aplicao. No entanto, no possvel desenvolver um jogo apenas com
os componentes de alto nvel disponibilizados. H a necessidade de se controlar a
tela completamente, permitindo a manipulao pixel a pixel dos elementos a serem
inseridos. Assim, os elementos de alto nvel, apesar de garantirem a portabilidade
das aplicaes, no puderam ser utilizados em todas as telas do jogo.
Os elementos de interface de alto nvel foram utilizados na confeco das telas
relacionadas com a apresentao do jogo, ajuda, opo de escolha de qual servidor
se deseja conectar e se o participante ir criar um novo jogo ou entrar em uma
sesso existente. Alm destas, apenas a tela apresentada ao vencedor ou perdedor
do jogo e a que possibilita a escolha da unidade a ser construda por uma cidade
usaram componentes de alto nvel.
A interface de baixo nvel precisou ser utilizada na confeco da tela onde
ocorre a interao do jogo.
Alea Jacta Est, portanto, uma aplicao desenvolvida de acordo com os
dois modos de interface existentes.
O desenvolvimento de um jogo multiplayer seguir sempre o padro de se
utilizar componentes de alto nvel para as telas iniciais e de baixo nvel para a tela
onde ocorre a interao definida pelo jogo.
O restante desta seo ir apresentar como foi a implementao da interface do
jogo, iniciando pelas de alto nvel, onde sero apresentados trechos de cdigos de
algumas telas criadas, mostrando a facilidade de sua construo. Por fim, ser feito
uma apresentao do desenvolvimento da interface onde ocorre toda a interao do
jogo, que foi desenvolvida com componentes de baixo nvel.
Os detalhes de implementao apresentados neste captulo dizem repeito a
como os componentes foram utilizados e no como se pode us-los. Para maiores
informaes sobre os mtodos definidos por cada classe dos pacotes MIDP deve-se
consultar a sua especificao, disponvel no site ofical deste profile[MID2003].
Para iniciar a discusso, a Figura 3.8 apresenta o modelo navegacional das
interfaces desenvolvidas, do ponto de vista das classes. Nesta figura, a nica interface de baixo nvel a definida pela TelaJogo.
78
Figura 3.8: Modelo navegacional das interfaces desenvolvidas para o jogo Alea
Jacta Est. A classe TelaInicial corresponde ao incio do fluxo.
Para analisar os detalhes de implementao dos componentes da interface de
alto nvel foram escolhidas duas das classes da Figura 3.8, a TelaInicial e a
TelaIniciarJogo.
A Figura 3.9 apresenta a interface definida pela classe TelaInicial e ressalta
alguns detalhes de implementao.
A classe TelaInicial, por ser um Form, pode ser apresentada na tela dos
celulares. O trecho de cdigo da Figura 3.10 apresenta a definio da classe, permitindo verificar que ela herda Form.
O objetivo desta classe e criar uma tela de apresentao do programa. Para
isso foram utilizados os seguintes elementos:
um componente ImageItem, que apresenta o logotipo do jogo. O trecho
de cdigo da Figura 3.11 apresenta como ele foi implementado.
um StringItem que foi utilizado como texto de apresentao e uma breve
descrio do programa. O trecho de cdigo da Figura 3.12 ilustra o seu
processo de criao e utilizao.
trs elementos Command, que permitem a realizao de aes ao serem
selecionados. As aes definidas para esta classe foram: sair do programa,
iniciar um jogo e visualizar a ajuda. Note que, quando so inseridos mais de
trs Commands ao mesmo tempo em uma tela um menu suspenso, como o
79
jados. A nica preocupao que deve-se possuir com relao a ordem com que os
elementos sero inseridos na tela, pois o tamanho e todas as outras caractersticas
so definidas pela implementao do profile MIDP no celular.
81
Figura 3.20: Estrutura de classes criadas para utilizar a idia de sprite, tile e janela
de visualizao.
completa.
Os tpicos a seguir apresentam como algumas classes do pacote de jogos do
MIDP 2.0 poderiam facilitar e melhorar a implementao do Alea Jacta Est.
A classe Sprite implementa mtodos de verificao de coliso com outro
sprite ou tile na tela, mas como esta verificao feita pelo servidor no
chega a ser uma vantagem para jogos multiplayers. A criao de sprites animados possvel atravs da definio de um conjunto de quadros de mesmo
tamanho e uma seqncia de exibio. A utilizao de tais sprites seria
interessante para aplicar animao as unidades militares disponibilizadas.
A classe TiledLayer j abstrai toda a estrutura de matriz de tiles criada para
a manipulao da tela.
A classe LayerManager possibilita a manipulao de vrias TiledLayer
de modo a gerenciar o modo como a tela repintada. Abstrai tambm o
conceito de janela de visualizao, permitindo que a classe que gerencia o
jogo se preocupe apenas com a manipulao correta dos ndices (x, y) que
indicam a posio atual da janela no sistema de coordenadas do LayerManager.
A utilizao da API de jogos do MIDP 2.0 altamente recomendada pelo
fato de j fornecer as implementaes otimizadas de quase todos os elementos
necessrios a criao de jogos 2D baseados em tiles.
Caso o Alea Jacta Est tivesse sido elaborado a partir da API de jogos do
MIDP 2.0 o seu desenvolvimento se daria de um modo muito mais rpido e um
ganho de performance seria obtido.
88
3.3.2
A dinmica do jogo
No cliente, a classe responsvel por coordenar a renderizao da tela, armazenar as informaes necessrias do jogador, manipular estes dados e formatar as
mensagens que sero definidas a partir das interaes do jogador com o dispositivo
a TelaJogo.
Para ilustrar o fluxo de execuo implementado, o processo de criao de uma
cidade pelo jogador que se encontra em seu turno ser detalhado. Em MIDP 1.0
existem trs threads que em conjunto determinam o fluxo de controle do jogo: a
de manipulao de eventos de teclado, a de pintura e a de controle. A Figura 3.21
ilustra o fluxo de jogo definido para a thread de manipulao de eventos de teclado
no Alea Jacta Est.
Voltando ao exemplo proposto, o jogador que deseja criar uma cidade pressiona o boto 0 do aparelho celular. Ao pressionar uma tecla o manipulador de
eventos de teclado ativado e inicia o processamento desta tecla. No caso do
Alea Jacta Est, ele primeiro verifica se a ao que est sendo executada de um
sprite ou de uma cidade, pois para cada um destes elementos as teclas so mapeadas de modo diferente. Como a ao de um sprite ele vai iniciar o processamento
89
Figura 3.23: Loops de controle de execuo definidos pelos profiles MIDP 1.0 e
2.0.
Figura 3.24: Trecho de cdigo que mostra a estrutura tradicional utilizada por uma
classe em MIDP 1.0 para um loop de jogo.
Figura 3.25: Trecho de cdigo que mostra a estrutura tradicional utilizada por uma
classe em MIDP 2.0 para um loop de jogo.
3.3.3
A arquitetura de comunicao
por ser do tipo request-response, no pode ser utilizado pelo jogo e muito menos
por qualquer outro jogo multiplayer, uma vez que h situaes onde necessrio
enviar dados para o cliente sem que este os tenha requisitado.
Outra caracterstica do protocolo HTTP que dificulta a sua utilizao em aplicaes multiplayers est no fato de ele ser baseado em sesses e cada uma ser
independente da outra. Por isso, feito um request e recebido o response a sesso
de comunicao ser encerrada, no havendo meio de se manter o estado da comunicao durante toda a partida sem a utilizao de algum tipo de controle extra.
A sesso tambm encerrada caso o response demore para ocorrer aps um tempo
pr-definido.
No Alea Jacta Est, quando no se possui a vez, o jogador colocado em uma
situao onde permanece escutando por mensagens do servidor e processando-as.
Este tipo de comunicao impossvel de ser realizada sobre um protocolo que
no mantm informaes sobre os clientes conectados durante toda a partida e
tambm no permite o envio de mensagens quando estas no so solicitadas.
No entanto, a verso 2.0 do profile MIDP apresenta a estrutura de classes necessrias a abertura de conexes via sockets, mas ainda no obriga a sua implementao. O MIDP 2.0 exige apenas que o aparelho tenha suporte ao HTTP e ao
HTTPS. Entretanto, enquanto na verso 1.0 no definido nem ao mesmo as classes que um fabricante deveria escrever caso quisesse permitir o uso do protocolo
de sockets, a verso 2.0 deixa claro que caso ele venha a ser oferecido deve-se
implementar as classes presentes na documentao da especificao.
No MIDP 1.0 o suporte a sockets realizado apenas atravs de APIs prprias
do fabricante, obrigando uma reescrita do cdigo de acordo com o aparelho em
que se deseje executar a aplicao. Entretanto, no MIDP 2.0 todos os dispositivos
que permitem a utilizao deste protocolo implementam a mesma API.
No MIDP 2.0 utiliza-se da classe SocketConnection do pacote javax.
microedition.io para fazer alguma requisio de conexo a um servidor via
sockets.
O fato de no haver suporte obrigatrio a um protocolo de comunicao to comum quanto sockets em MIDP 1.0 representa uma grande falha desta plataforma
na hora de se desenvolver jogos multiplayers. No caso de aplicaes enterprise o
protocolo HTTP suficiente. J o MIDP 2.0, apesar de definir uma API para sockets, ainda no obriga a sua implementao. Assim, o problema de suporte a este
tipo de conexo foi apenas parcialmente resolvido na nova verso da especificao.
O jogo Alea Jacta Est s no completamente portvel devido ao fato de
utilizar sockets para se conectar ao servidor.
94
Figura 3.26: Trecho do cdigo do Alea Jacta Est que mostra a abertura de conexes por sockets.
Na arquitetura cliente-servidor, alm de se preocupar com o protocolo de comunicao, necessrio definir o formato de mensagens a serem trocadas.
As primitivas envolvidas na comunicao do jogo modelo construdo so classificadas em trs categorias: primitivas de ao (formatadas pelo cliente), primitivas de notificao (formatadas pelo servidor) e primitivas de gerncia de sesso de
jogo (abertura e manuteno das partidas). Um subconjunto delas est relacionado
na listagem abaixo:
NOV_ACT: utilizada para solicitar ao servidor a criao de uma nova sesso
de jogo.
SES_NOT: primitiva enviada como resposta a uma solicitao de criao de
sesso de jogo ou em resposta a solicitao de participar de uma sesso de
jogo pr-existente.
COM_ACT: primitiva enviada pelo jogador que criou a sesso solicitando o
incio da mesma.
COM_NOT: primitiva enviada pelo servidor para o jogador que realizou uma
solicitao COM_ACT indicando o incio do jogo.
95
MOV_ACT: primitiva utilizada para indicar uma ao envolvendo o movimento de alguma unidade militar.
CID_ACT: primitiva utilizada para indicar uma requisio para construir
uma cidade a partir de uma unidade construtora.
SPR_ACT: primitiva utilizada para indicar uma requisio para construir
unidades militares a partir de uma cidade pr-existente.
MAP_ACT: primitiva utilizada para codificar uma requisio para o servidor
enviar um trecho do mapa do jogo.
Para cada ao de um cliente enviada ao servidor ele recebe uma notificao
correspondente. Um exemplo desta comunicao pode ser verificado atravs da
troca que ocorre quando uma mensagem de MOV_ACT enviada pelo cliente ao
servidor. O formato da primitiva MOV_ACT o seguinte:
MOV_ACT;<id_sprite>;<posX>;<posY>;
Uma possvel conversa com o servidor na qual o cliente quer movimentar
o sprite de identificador igual a 5 para a posio (10, 15) ocorreria da seguinte
maneira:
1. Cliente envia para o servidor: MOV_ACT;5;10;15;
2. Servidor recebe a mensagem, processa, verifica que a movimento possvel e retorna para o cliente: MOV_NOT;5;10;15;
O formato das demais mensagens trocadas entre o jogador e o servidor no
ser apresentado neste projeto. A discusso ser realizada com relao as maneiras
utilizadas para se manipular tais mensagens.
As duas verses do profile MIDP no apresentam suporte a serializao de
objetos. Por isso, no existe a possibilidade de se transmitir e receber objetos
atravs dos fluxos de comunicao com o servidor. Para se transmitir dados
necessrio convert-los em bytes. Esta abordagem exige que se utilize um sistema
de cabealho fixo em conjunto com as mensagens a serem transmitidas.
A estrutura de cabealhos foi implementada da seguinte forma:
Primeiro definiu-se um tamanho padro para o cabealho, tanto do lado do
servidor quanto do cliente. Este valor foi fixado em trs bytes;
96
Figura 3.28: Trecho de cdigo mostrando a maneira como o cliente envia ou recebe
mensagens.
Na classe GerenciadorMensagem foram definidas rotinas que lem e escrevem nos fluxos de acordo com o sistema de cabealhos definido.
A seqncia de troca de mensagens entre o servidor e a MIDlet ocorre da
seguinte maneira: ao receber uma mensagem de notificao dizendo que o turno
do jogador em questo, inicia-se uma contagem do nmero de aes que podero
ser realizadas pelo jogador (que varia de acordo com o nmero de sprites e de
cidades que no esto em produo). Passada esta etapa, o jogador pode executar
aes de movimento, construo de sprites, construo de cidades entre outros.
Cada ao gera uma mensagem que enviada ao servidor para que ele a processe e retorne as notificaes necessrias. Enquanto isso, os demais participantes
encontram-se em um loop que os obriga a ler o fluxo de entrada com o servidor at
que o jogador atual termine seu turno e o servidor decida qual jogador possuir a
98
vez.
A Figura 3.29 apresenta o trecho de cdigo onde o jogador, que no est na
sua vez, fica parado lendo as mensagens enviadas pelo servidor.
99
100
Captulo 4
Resultados e discusses
Este captulo objetiva expor em maiores detalhes e de um modo mais claro as
caracterticas positivas e negativas encontradas na plataforma J2ME para o desenvolvimento de jogos multiplayers para celulares.
Para cumprir o objetivo proposto, o captulo foi dividido em duas sees. A
seo 4.1 apresenta as caractersticas identificadas no projeto que justificam a escolha da plataforma J2ME para o desenvolvimento de jogos multiplayers e a seo 4.2 aquelas que poderiam ser responsveis pela no escolha da tecnologia no
desenvolvimento de aplicaes com estas caractersticas. Estas anlises sero realizadas tendo como base o profile MIDP 1.0, pelo fato de este perfil ser o mais
adequado para o desenvolvimento de aplicaes para celulares em J2ME e a verso 1.0 ter sido utilizada durante a maior parte da implementao do jogo modelo.
No entanto, sempre que for necessrio, ser realizada uma referncia a verso 2.0
do profile.
4.1
facilidade na manipulao de bytes. A API do MIDP 1.0 bastante completa com relao ao fornecimento de mtodos para a manipulao de bytes.
Esta caracterstica facilita a manipulao das mensagens a serem trocadas
entre o cliente e o servidor.
4.2
104
Captulo 5
Concluses
Este captulo apresenta as concluses finais do projeto com relao ao uso da
tecnologia J2ME no desenvolvimento de aplicaes multiplayers para celulares e
algumas sugestes para trabalhos futuros. Para tal, o captulo foi dividido em duas
sees: a seo 5.1 apresenta as concluses finais e a seo 5.2 as propostas para
trabalhos futuros.
5.1
Concluses
A utilizao do profile MIDP 1.0, apesar dos problemas encontrados, pode ser
considerada adequada para o desenvolvimento de jogos multiplayers para celulares.
Entretanto, apesar de ainda no ser implementado por nenhum dispositivo real,
a utilizao do profile MIDP verso 2.0 torna o o desenvolvimento de jogos no
estilo 2D, baseados na idia de tiles, muito simples e tambm deixa as aplicaes
mais eficientes. Estas melhoras ocorrem pois a API desta verso do MIDP possui
classes altamente otimizadas que abstraem a maioria dos conceitos necessrios ao
desenvolvimento de jogos deste estilo.
O nico problema real verificado nas duas verses do profile MIDP est relacionado com o fato de no ser obrigatria a implementao de outros protocolos
de comunicao que no o HTTP. Este problema deve ser bem dimensionado ao
se desenvolver qualquer tipo de aplicao em J2ME para celulares, pois no pode
ser resolvido atravs de nenhuma tcnica fornecida pela linguagem. Esta questo totalmente dependente da arquitetura do aparelho alvo. A falta de suporte a
conexes via sockets uma de suas principais deficincias.
105
Conclui-se, ento, que a utilizao da plataforma J2ME ou, mais especificamente, do profile MIDP no desenvolvimento de jogos multiplayers baseados em
tiles para celulares satisfatria quando se estiver utilizando a verso 1.0 deste perfil. No entanto, ao se utilizar a verso 2.0, esta qualificao sofrer uma melhora
considervel, devido as grandes facilidades implementadas. A integrao com
as outras plataformas da tecnologia Java e a facilidade de construo de cdigos
nesta linguagem so caractersticas que acrescentam pontos positivos a plataforma
J2ME.
A construo de jogos multiplayers que no usam tiles para construir a sua interface torna-se mais complexa nesta plataforma, pois exige a manipulao constante das primitivas grficas e um controle maior sobre os mtodos de desenho na
tela. A API de jogos do MIDP 2.0 no apresenta muita utilidade nesta situao.
No entanto, ainda vivel utilizar J2ME para este tipo de aplicao.
A Tabela 5.1 apresenta as consideraes mais importantes obtidas com relao
a utilizao da plataforma J2ME no desenvolvimento de aplicaes multiplayers
para celulares.
5.2
Atravs dos resultados obtidos por este projeto pode-se ainda desenvolver outros trabalhos. Algumas propostas de continuidade so:
melhorar a especificao do jogo modelo, permitindo tambm uma melhora
no quesito diverso proporcionada ao jogador;
implementar a verso cliente do jogo modelo de uma maneira mais eficiente,
utilizando ainda a verso 1.0 do profile MIDP;
implementar a verso cliente do jogo modelo utilizando-se das melhorias
oferecidas pela API do MIDP 2.0;
definir mtricas que permitam uma comparao mais detalhada das duas
verses do profile MIDP no desenvolvimento de jogos multiplayers;
realizar testes em aparelhos e emuladores de dispositivos reais. Estes testes
permitiriam verificar a performance da aplicao em uma rede celular real.
definir uma proposta de metodologia para o desenvolvimento de jogos multiplayers em celulares usando o profile MIDP. Esta metodologia forneceria
106
Tabela 5.1: Resumo das concluses obtidas com relao a utilizao da plataforma
J2ME no desenvolvimento de jogos multiplayers.
Caractersticas
Potencial para comercializao
Manipulao
bytes
Fluxo de jogo
de
Controle
centralizado no MIDP
2.0.
Fcil manipulao.
Interface
Imagens
Arquitetura
comunicao
de
Linguagem Java
API
Vantagens
Grande nmero de
dispositivos com
suporte a MIDP
1.0.
Fcil manipulao.
Desvantagens
MIDP 2.0 ainda
no disponvel no
mercado.
Threads separadas
no MIDP 1.0.
No suporta grficos 3D.
Suporte nico a
imagens do tipo
png.
Suporta apenas o
protocolo HTTP.
Interpretada.
tcnicas para tratar melhor os problemas que possam ocorrer na implementao deste tipo de aplicao e maximizar os benefcios oferecidos pela plataforma.
107
108
Referncias Bibliogrficas
[POD2002] Revista Poder. URL: http://www.poderonline.com.br.
Acessado em novembro de 2002.
[PAW2002] Pawlan, Monica. Introduction to Wireless Technologies. URL:
http://wireless.java.sun.com/getstart/articles/
intro/. 09 de outubro de 2002.
[INF2002A] InfoExame, Planto Info. 32 milhes de celulares no pas, diz Anatel.
URL: http://www.infoexame.com.br. 21 de novembro de 2002.
[INF2002B] InfoExame, Planto Info. H mais linhas celulares do que fixas na
AL. URL: http://www.infoexame.com.br. 08 de janeiro de 2002.
[INF2001] InfoExame, Planto Info. Mais de 90% dos jovens finlandeses tm celular. URL: http://www.infoexame.com.br. 17 de julho de 2001.
[IBI2002] IBiznet 2002, Estatsticas. URL: http://www.ibiznet.com.
br. Acessado em 26 de novembro de 2002.
[FOX2002] Fox, David. Will Mobile Games Sweep the Nation? URL: http:
//www.onjava.com. 10 de dezembro de 2002
[NOK2002] Site Oficial da Nokia. URL: http://www.nokia.com.br.
Acessado em 26 de novembro de 2002.
[DAT2002] Data Monitor Market Analysis. URL: http://datamonitor.
com/. Acessado em 28 de novembro de 2002.
[TEL2002] Telecom Web. URL: http://www.telecomweb.com.br. Acessado em 26 de novembro de 2002.
109
R Technology.
[SUN2003A] Sun Microsystems. Introduction to Wireless Java
URL: http://wireless.java.sun.com/getstart/. 04 de fevereiro de 2003.
[SUN2003B] Sun Microsystems. Users Guide Wireless Toolkit Version 2.o Beta
R 2 Platform, Micro Edition. Janeiro de 2003.
2 - Beta Draft. Java
[SUN2002A] Sun Microsystems. A Brief History of the Green Project. URL:
http://java.sun.com/people/jag/green/. 28 de novembro de
2002.
[SUN2002B] Sun Microsystems. Users Guide Wireless Toolkit Version 1.0.4.
R 2 Platform, Micro Edition. Junho de 2002.
Java
[SUN2002C] Sun Microsystems. Version 2.0 of Mobile Information Device Profile Specification. URL: http://jcp.org/aboutJava/
communityprocess/final/jsr118/index.html. 2002.
[SUN2002D] Sun Microsystems. Wireless Toolkit. URL: http://java.sun.
com/j2me/toolkit. Acessado em novembro de 2002.
R Tutorial URL: http://java.
[SUN2002E] Sun Microsystems The Java
sun.com. 2002.
[GOS & MCG1996] Gosling, James & McGilton, Henry. The Java Language
Environment. A White Paper. URL: http://java.sun.com/docs/
white/langenv/index.html. Maio de 1996.
[GOS, JOY, STE & BRA2000] Gosling, James & Joy, Bill & Steele, Guy & Bracha, Gilad. The Java Language Specification. Second Edition. 2000.
110
[CAM & WAL2002] Campione, Mary & Walrath, Kathy. About the Java Technology. URL: http://developer.java.sun.com/developer/
onlineTraining/new2java/overview.html. Janeiro de 2002.
R Virtual Machine
[LIN & YEL1999] Lindholm, Tim & Yellin, Frank. The Java
Specification. Second Edition. 1999.
[ORT & GIG2003] Ortiz, C. Enrique & Gigure, Eric. Java Comunnity Process.
URL: http://jcp.org. Acessado em 22 de maro de 2003.
[ORT2002A] Ortiz, C. Enrique. A Survey of J2ME Today. URL: http://
wireless.java.sun.com/getstart/articles/survey/. Novembro de 2002.
[ORT2002B] Ortiz, C. Enrique. Introduction to OTA Application Provisioning.
URL:
http://wireless.java.sun.com/midp/articles/
ota/. November 2002.
[ORT & GIG2001] Ortiz, C. Enrique & Gigure, Eric. Mobile Information Device
Profile for Java 2 MicroEdition. Wiley Computer Publishing. 2001.
[JSE2002] Java 2 Standard Edition. URL: http://java.sun.com/j2se/.
Acessado em 02 de novembro de 2002.
[JEE2002] Java 2 Enterprise Edition. URL: http://java.sun.com/
j2ee/. Acessado em 02 de novembro de 2002.
[JME2002] Java 2 Micro Edition. URL: http://java.sun.com/j2me/.
Acessado em 02 de novembro de 2002.
[MUC2002] Muchow, John W. Core J2ME Technology & MIDP. Sun Press. 2002.
[WHI & HEM2002] White, james P. & Hemphill, David A. Java 2 Micro Edition,
Java in Small Things. Manning Publications. 2002.
[GIG2002] Giguere, Eric. J2ME[tm] Optional Packages. URL: http:
//wireless.java.sun.com/midp/articles/optional/. Dezembro de 2002.
[CLC2003] Connected Limited Device Configuration - CLDC. URL: http://
java.sun.com/products/cldc. Abril de 2003.
111
112
113
114
Resumo estendido
Assis, Wendel Malta. AVALIAO DA TECNOLOGIA J2ME NO CONTEXTO DE DESENVOLVIMENTO DE JOGOS MULTIPLAYERS PARA
CELULARES. 121p. 2003. Este trabalho apresenta uma avaliao da utilizao da plataforma Java 2 Platform Micro Edition (J2ME) da Sun Microsystems,
que vem se destacando no mercado de construo de aplicaes para dispositivos
mveis, no desenvolvimento de jogos multiplayers para celulares.
Atualmente, a telefonia celular encontra-se em uma fase de grande expanso,
momento em que esto surgindo novas tecnologias de transmisso e aparelhos
cada vez mais modernos e com maiores funcionalidades. Estes novos aparelhos,
por apresentarem um maior poder computacional, permitem o desenvolvimento de
aplicaes mais complexas, como os jogos.
Dentre o mercado de jogos para celulares e outros dispositivos mveis, os jogos multiplayers vem se destacando por permitirem disputas entre vrios jogadores
ao mesmo tempo e no apenas contra o computador, garantindo um maior nvel
de diverso durante as partidas. Assim, apresentam um maior grau de interao
com os usurios e exigem um controle de concorrncia avanado, representando
um grande desafio de implementao.
O objetivo deste trabalho consiste em apresentar as dificuldades e facilidades
encontradas ao se utilizar a plataforma J2ME no desenvolvimento de um jogo modelo multiplayer para celulares, chamado Alea Jacta Est, e, em seguida, avalila de um modo geral com relao ao desenvolvimento deste tipo de aplicao.
Para se desenvolver aplicaes para celulares utilizando J2ME deve-se escolher entre uma das verses da especificao Mobile Information Device Profile
(MIDP) definida pela plataforma. A concluso final do projeto foi que a utilizao
do MIDP 1.0 cumpre satisfatoriamente com as necessidades de um desenvolvedor
de jogos multiplayers para celulares. No entanto, a verso 2.0 do MIDP, ainda
no implementada em aparelhos reais, proporciona melhores ferramentas para o
desenvolvimento de tais aplicaes.