ARQUITETURA SERVIDORA DE JOGOS DE CELULAR ONLINE MASSIVAMENTE MULTIPLAYER

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO BACHARELADO ARQUITETURA SERVIDORA DE JOGOS DE CELULAR ONLINE MASSIVAMENTE MULTIPLAYER JONI BASSO CEREJA BLUMENAU /1-20

2 JONI BASSO CEREJA ARQUITETURA SERVIDORA DE JOGOS DE CELULAR ONLINE MASSIVAMENTE MULTIPLAYER Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciências da Computação Bacharelado. Prof. Paulo Fernando da Silva, Ms - Orientador BLUMENAU /1-20

3 ARQUITETURA SERVIDORA DE JOGOS DE CELULAR ONLINE MASSIVAMENTE MULTIPLAYER Por JONI BASSO CEREJA Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Paulo Fernando da Silva, Ms Orientador, FURB Prof. Paulo César Rodacki Gomes, Dr FURB Prof. Francisco Adell Péricas, Ms FURB Blumenau, 9 de Julho de 2008

4 AGRADECIMENTOS À minha família e a todos os meus amigos, por todo o apoio que me deram para o desenvolvimento deste trabalho. Ao meu orientador, Paulo Fernando da Silva, que acreditou na conclusão deste trabalho.

5 Sirvam nossas façanhas de modelo à toda terra. Hino do Rio Grande do Sul

6 RESUMO Um jogo Massively Multiplayer Online (MMO), de acordo com Online Evolution Pty (2002, tradução nossa), é um videogame onde um jogador se conecta através da internet em um mundo virtual persistente, unindo-se a centenas de milhares de jogadores em uma experiência compartilhada. Esta é uma área que não está sendo explorada como deveria, por ser inovadora. A fim de que se verifique a viabilidade desta área para celulares, este trabalho desenvolve um jogo MMO para celulares, o qual é doravante denominado Galaxy Navigator. Uma arquitetura de servidores, além de um cliente demonstrativo suportado por esta arquitetura, compõem este jogo. Ambos são desenvolvidos neste trabalho. Palavras-chave: J2ME. MMO. Celular.

7 ABSTRACT A Massively Multiplayer Online (MMO) game, according to Online Evolution Pty (2002), is a video game where a player connects through the Internet to a persistent virtual world, joining with hundreds of thousands of other gamers in a shared experience. This is an area that isn t being explored as it should, for the reason it s a new area. To verify the viability of this area to mobiles, this paper develops a MMO game for mobiles, which now is called Galaxy Navigator. A server architecture and a demonstrative client supported by that architecture composes this game. Both are developed in this paper. Key-words: J2ME. MMO. Mobile.

8 LISTA DE ILUSTRAÇÕES Figura 1 Meridian 59, o primeiro jogo MMO...15 Figura 2 Captura de tela do jogo Risk Your Life...16 Figura 3 - TibiaME, um jogo MMO para celulares...17 Figura 4 Elementos principais do jogo...22 Figura 5 Topologia geral do jogo...23 Figura 6 Caso de Uso da arquitetura servidora...24 Quadro 1 Cenários dos Casos de Uso...25 Figura 7 Diagrama de Classes do módulo cliente...26 Figura 8 Diagrama de Classes da arquitetura servidora...27 Figura 9 Diagrama de Seqüência...29 Figura 10 Diagrama de Estados...30 Figura 11 Modelo de dados...32 Quadro 2 Protocolo de comunicação...34 Quadro 3 Conectando com Socket em J2ME...36 Quadro 4 Recebendo as conexões via socket...36 Quadro 5- Construtor da classe PlayerAction...37 Figura 12 Inicialização da arquitetura servidora do jogo...39 Figura 13 Interface J2ME com sede centralizada...40 Figura 14 Menu com ações...41 Quadro 6 Comparativo com trabalhos correlatos...43

9 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA J2ME E JOGOS PARA CELULAR Jogos para celular J2ME Desenvolvimento de jogos para celular JOGOS MMO Origem, definição e características de jogos MMO JOGOS MMO PARA CELULARES TRABALHOS CORRELATOS TíbiaME Protótipo de motor de servidor de jogos online em massa DESENVOLVIMENTO REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ESPECIFICAÇÃO Regras do jogo Galaxy Navigator Diagramas de Caso de uso Diagramas de Classe Diagramas de Seqüência Diagramas de estado Modelagem de dados Protocolo de comunicação IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Operacionalidade da implementação RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES...45 REFERÊNCIAS BIBLIOGRÁFICAS...46

10 9 1 INTRODUÇÃO Os avanços tecnológicos na área de dispositivos móveis se fazem tão presentes na vida das pessoas que chamam cada vez mais a atenção de programadores para este promissor nicho de mercado. É possível encontrar em praticamente todos os lugares alguém utilizando pelo menos um telefone celular. Várias funcionalidades foram agregadas a estes dispositivos ao longo dos anos: agendas eletrônicas, reprodutores de músicas, máquinas fotográficas digitais, e muitas outras. Dentre esta gama de inovações, destaca-se os jogos para celular e a possibilidade de acessar a internet através dos mesmos. Uma das motivações para o crescimento acelerado do mercado de jogos para celular é o aumento da produção destes aparelhos. Mattos (2005, p. 5) salienta que a produção de dispositivos móveis é, em escala mundial, superior à de Personal Computers (PCs), criando um mercado de trabalho em potencial que faz programadores buscarem especializações na principal ferramenta utilizada, o Java 2 Micro Edition (J2ME). Já Knudsen (2003, p. 1) afirma que o Java para pequenos dispositivos, o J2ME, é a segunda revolução desta linguagem de programação, e ela está acontecendo exatamente agora, além de que o mercado destes pequenos dispositivos está rapidamente expandindo. Ocorre que estes jogos para celular, por terem surgido antes da freqüente utilização da internet nestes dispositivos, ainda não aproveitam este meio de comunicação de dados da maneira como poderiam. Desta maneira, a grande maioria dos jogos disponíveis no mercado são softwares que apenas executam no dispositivo em que estão. A concorrência já está presente nesta área de desenvolvimento de jogos para celular, e há demanda de jogos cada vez mais complexos, com novos recursos e mais desafio aos jogadores. Constantemente novos aparelhos são lançados, e com eles jogos melhores e mais modernos podem ser elaborados. Com o advento da internet para os telefones móveis e a constante melhoria neste tipo de serviço, surge a oportunidade de se criar também para celulares os jogos Massively Multiplayer Online (MMO). Um jogo MMO, de acordo com Online Evolution Pty (2002, tradução nossa), é um videogame onde um jogador se conecta através da internet em um mundo virtual persistente, unindo-se a centenas de milhares de jogadores em uma experiência compartilhada. Do mesmo modo, em um jogo MMO para celulares cada jogador poderá conectar o cliente instalado em seu aparelho a uma arquitetura de servidores deste jogo, assumindo seu próprio papel num universo compartilhado entre milhares de jogadores. Portanto, este gênero pouco

11 10 explorado para celulares ainda é um nicho de mercado em potencial, já que os mesmos fazem muito sucesso na plataforma PC, e a cada dia que passa novos celulares são lançados com mais recursos e funcionalidades. Todos esses aspectos motivaram o desenvolvimento de um jogo MMO para celulares, para demonstrar que os celulares atuais já suportam este estilo de jogo. O jogo MMO desenvolvido é doravante denominado Galaxy Navigator. O mesmo é composto por uma arquitetura de servidores, além de um cliente demonstrativo suportado por esta arquitetura. Cada jogador pode instalar a versão cliente em seu celular e efetuar login no mundo virtual compartilhado de Galaxy Navigator. As conexões de todos os jogadores são controladas pela arquitetura de servidores, a qual dispõe de servidores de login, de suporte a Non-Player Characters (NPCs) e de servidores que controlam uma aplicação distribuída. Esta por sua vez persiste o universo do jogo compartilhado entre os jogadores. 1.1 OBJETIVOS DO TRABALHO O objetivo deste trabalho é o desenvolvimento de um jogo MMO para celulares, composto por uma arquitetura servidora e por um cliente suportado pela mesma. Os objetivos específicos do trabalho desenvolvido são: a) permitir que centenas de pessoas, através de seus celulares, compartilhem um mesmo universo no jogo demonstrativo Galaxy Navigator; b) armazenar e atualizar o perfil de cada jogador, permitindo que estes dados sejam corretamente carregados no instante em que o jogador acessasse novamente o jogo; c) suportar a interação com personagens robôs conhecidos por NPCs; d) controlar o universo e as regras desenvolvidas para o jogo Galaxy Navigator, ações dos jogadores e interação com NPCs valendo-se de uma aplicação principal suportada por servidores distribuídos.

12 ESTRUTURA DO TRABALHO O presente trabalho é organizado em quatro capítulos distintos para que haja melhor compreensão do tema. No primeiro capítulo, é apresentada uma introdução, com a finalidade de expor os motivos que levaram ao desenvolvimento deste trabalho. Também neste capítulo são esclarecidos os objetivos deste trabalho. No segundo capítulo, são aprofundados os conceitos, técnicas e ferramentas que possuem maior grau de relevância com o tema de jogos MMO para dispositivos móveis. No terceiro capítulo são detalhados os passos do desenvolvimento deste trabalho, apresentando os resultados obtidos com o mesmo. Por fim, no quarto capítulo são expostas as conclusões a respeito do desenvolvimento do trabalho, bem como suas limitações e possíveis melhorias.

13 12 2 FUNDAMENTAÇÃO TEÓRICA Para a construção da arquitetura servidora e do cliente do jogo Galaxy Navigator, são apresentadas nas seções deste capítulo os conceitos que envolvem o J2ME, além do uso desta tecnologia para desenvolvimento de jogos para celular. Após, é descrito o ramo de jogos MMO, já que o mesmo se destaca de qualquer outro. Na seqüência, são apresentados trabalhos correlatos, cujas características relacionam-se diretamente com o trabalho proposto. 2.1 J2ME E JOGOS PARA CELULAR Com a finalidade de fundamentar a programação de jogos para dispositivos móveis, esta seção aprofunda o J2ME e algumas de suas principais características, assim como seu uso no desenvolvimento de aplicativos para celulares Jogos para celular A história dos jogos eletrônicos é extensa, iniciando em meados dos anos 70 e evoluindo até hoje. A rápida popularização de jogos eletrônicos teve início com plataformas console, os videogames. Essa popularização gerou concorrência entre as empresas desenvolvedoras de jogos, que evoluíam o hardware de seus aparelhos. Deste modo, tornavase possível o desenvolvimento de jogos com mais qualidade, assim se destacando no mercado. Hoje, os jogos possuem um alto grau de complexidade. Há um processo contínuo de desenvolvimento de hardware para diversas plataformas, dentre elas computadores e videogames. Destaca-se, principalmente, a constante melhoria das placas de vídeo com grande potencial de processamento, as quais permitem qualidade gráfica em jogos que se aproximam muito da realidade. Com o repentino avanço tecnológico na área de telefonia móvel, os celulares já não servem apenas como meio de comunicação. Diversas funcionalidades estão sendo agregadas a estes dispositivos, e o advento de celulares capazes de executar softwares programados na linguagem Java abriu uma nova área no ramo de desenvolvimento de jogos eletrônicos.

14 J2ME A linguagem de programação Java, segundo Keogh (2003, p. 8-9), fora inicialmente desenvolvida para ser utilizada em sistemas portáveis, como por exemplo, algum microcomputador que controle um automóvel. Soma-se a isto o fato de que, na virada deste século, os telefones celulares passaram a servir não apenas para realizar chamadas telefônicas, mas também como assistentes digitais para seus usuários. Da mesma maneira, o potencial de computadores passou a ser transferido para estes dispositivos móveis. Assim, houve uma evolução na linguagem Java, sendo reduzidas suas Application Program Interfaces (APIs) e também a máquina virtual Java, para que esta linguagem pudesse ser utilizada em dispositivos com poucos recursos físicos. A esta versão reduzida da linguagem Java, deu-se o nome de J2ME. De acordo com Mattos (2005, p ), dispositivos que rodam o J2ME como os celulares, apesar de terem características em comum, diferem nas formas, funções e componentes internos. Por esta razão, os desenvolvedores da plataforma J2ME adotaram duas camadas: uma de configuração e outra de perfil. A camada de configuração especifica a máquina virtual Java e as APIs básicas, sendo a Connected, Limited Device Configuration (CLDC) a configuração voltada para dispositivos com poucos recursos, como os celulares. Já os perfis são uma camada superior às configurações, adicionando APIs e especificações necessárias para que se construa aplicativos para uma família de dispositivos. Mattos (2005, p. 23) também realça que atualmente o J2ME resume-se nos perfis Mobile Information Device Profile (MIDP) e Personal Profile, sendo o MIDP voltado a estes terminais menos avançados como aparelhos celulares Desenvolvimento de jogos para celular Para que se desenvolva jogos destinados a dispositivos móveis como os celulares, Hamer (2004, p. xv) torna claro que é totalmente inviável escrevê-los utilizando a versão 1.0 do MIDP, já que os recursos adicionados no MIDP 2.0 permitem que sejam criados jogos com ambientes mais ricos. Além disso, há um pacote novo que otimiza os gráficos dos jogos e os controles, além da possibilidade de se adicionar música e suportar melhor a utilização de sockets, o que ajuda na criação de jogos em rede para vários jogadores. De acordo com a

15 14 própria Sun Microsystems (2007), o MIDP é um conjunto de APIs que, juntamente com a CLDC, provêem um ambiente de execução para aplicativos J2ME, voltados para dispositivos móveis como celulares e pagers. Com o perfil MIDP é possível solucionar problemas nestes aparelhos, como interface com usuário, persistência de dados, comunicação e modelos de aplicações. 2.2 JOGOS MMO Os jogos do gênero MMO podem ser descritos como um universo onde centenas de jogadores participam coletivamente, através de uma rede como a internet, em busca de objetivos que venham a ajudar a si próprios ou a um grupo de jogadores, sendo que este universo é controlado e mantido por servidores que funcionam 24 horas por dia Origem, definição e características de jogos MMO De acordo com GameSpy (2003), o primeiro jogo no estilo MMO poderia ser considerado o Habitat. Este jogo do final dos anos 80, que executava em plataforma Commodore 64, era um universo virtual acessado por mais de 16 pessoas ao mesmo tempo através de um Quantum Link, o que na época poderia ser considerado como massivo. Outras companhias, como Sierra Online, possuíam jogos com mundos virtuais persistentes suportados por estrutura de rede privada. Porém, o primeiro jogo MMO a permitir que um grande número de jogadores compartilhassem do mesmo mundo virtual persistente foi o Meridian 59. A figura 1 mostra uma captura de tela deste jogo. Ainda segundo GameSpy (2003), foi este jogo o responsável pelas denominações massively multiplayer e mundo 3D persistente a este gênero de jogos. Estes termos teriam sido popularizados pelo marketing da empresa Eletronic Arts, ao mesmo tempo em que o pioneiro jogo Ultima Online teria sido lançado.

16 15 Fonte: adaptado de Near Death Studios (2001). Figura 1 Meridian 59, o primeiro jogo MMO Portanto, uma possível definição para um jogo MMO é que são jogos com um ambiente virtual único para vários jogadores ao mesmo tempo. Este universo também é suportado por um ou vários servidores, que persistem todos os dados do ambiente compartilhado entre os jogadores, inclusive dos próprios jogadores. Deste modo, possíveis problemas com clientes ou com os servidores não interferem no andamento do jogo persistido. Há jogos no estilo MMO que podem ou não ter um objetivo que sinalizem o fim do jogo. Segundo Travian Games GmbH (2004), seu jogo MMO Travian é organizado por rodadas que tem seu fim quando um jogador termina uma determinada construção. Deste modo, o jogo é reiniciado após este evento. Há outros jogos, porém, que não possuem nenhuma ação ou objetivo que signifiquem fim de jogo. De acordo com Youxiland Digital, Gamasoft e Planetwide Games (2005), o jogo Risk Your Life (Figura 2) é um universo 3D que permite que os jogadores criem seus personagens, explorando um mundo virtual juntamente com milhares de pessoas. Cada personagem virtual pode interagir com o ambiente da maneira que lhe for conveniente, buscando objetivos próprios ou de um grupo virtual específico, como uma aliança virtual, por exemplo. Porém, não há nada que delimite um fim específico, cabendo aos próprios jogadores seguirem objetivos relevantes.

17 16 Fonte: adaptado de GameSpy(2007). Figura 2 Captura de tela do jogo Risk Your Life Com a persistência correta deste universo virtual, jogadores, itens de jogo e outras características virtuais dos jogos MMO são mantidas. Havendo graves erros com a persistência dos dados, pode ocorrer que haja a necessidade dos administradores destes jogos de forçar o reinicio do jogo. Estes erros podem ser ocasionados por diversos motivos, como erros em bases de dados ou má programação, que podem ter causado danos irreversíveis aos dados persistidos. É o caso por exemplo do jogo World of Warcraft, o qual, segundo France Presse (2007), uma doença virtual posta no jogo como um evento para os jogadores, tornou-se incontrolável. Para resolver este problema, os administradores foram obrigados a reinicializar o jogo. 2.3 JOGOS MMO PARA CELULARES A respeito dos MMOs, Presser (2006, p. 17) afirma que este novo formato, onde milhares de pessoas compartilham um mesmo servidor, leva ao limite o conhecimento que se tinha de ambientes online para jogos, pois se trata de um segmento que conta com pouco tempo de pesquisa, se comparado a outros setores, como a computação gráfica e o áudio. Este pouco tempo que fora dedicado aos jogos MMOs deve-se à inviabilidade de se desenvolver este gênero com pouca taxa de transferência de dados pela internet. É o que também afirma Presser (2006, p.17), salientando que a popularização do gênero de jogos

18 17 MMOs cresceu vertiginosamente com o advento da banda larga no final da década de Este cenário pode estar se repetindo com os telefones móveis. A rápida popularização da internet em celulares aumentou a oferta de planos de transferência de dados por parte das operadoras, com a venda, por exemplo, de pacotes de 1 Gigabyte a preços relativamente baixos, em contraste com a comum cobrança tendo em base a quantidade de Megabytes transferida. Percebe-se desta maneira que as principais barreiras ao desenvolvimento de jogos MMOs começam a ser quebradas, como a transferência de dados na telefonia móvel, além do constante avanço dos recursos para celulares. Um jogo MMO que já foi desenvolvido para celulares é o TibiaME, da empresa CipSoft GmbH (Figura 3). Mais detalhes sobre este jogo são esclarecidos na próxima seção. Fonte: adaptado de CipSoft GmbH(2006). Figura 3 - TibiaME, um jogo MMO para celulares 2.4 TRABALHOS CORRELATOS Por ser um assunto extremamente recente e pouco explorado, existem poucos trabalhos que desempenham funções semelhantes ao presente trabalho proposto. A seguir são apresentados o jogo MMO para celular TibiaME (CIPSOFT GMBH, 2006) e o protótipo de motor de servidor de jogos online em massa (PRESSER, 2006).

19 TíbiaME O TibiaME é um jogo para celular classificado como Massively Multiplayer Online Role Playing Game (MMORPG), já que neste MMO cada jogador assume o papel de um personagem, e sua interação com o universo, conhecida pela expressão Role Play, pode contribuir ou não para o desenvolvimento do mesmo. Segundo CipSoft GmbH (2006), o jogo TibiaME foi desenvolvido aos moldes do conhecido Tibia, um MMORPG para a plataforma PC que desde 1997 é um grande sucesso nesta área, principalmente na Europa, possuindo mais de 250 mil jogadores atualmente. CipSoft GmbH (2006) também afirma que o TibiaME é o primeiro jogo de Role Play online para celulares, e centenas de jogadores podem interagir numa mesma aventura virtual, além de admitir que o jogo MMO para celular é conhecido principalmente em países próximos à Rússia, no leste europeu, e na região da Indonésia, no extremo oriente asiático. Também é esclarecido que durante o jogo, o telefone móvel é conectado a um servidor de jogo centralizado, além de que a conexão pelo celular é feita utilizando GPRS/UMTS Protótipo de motor de servidor de jogos online em massa Este protótipo de motor de jogos MMO foi desenvolvido por Presser (2006). Trata-se de um protótipo de um servidor genérico que pode ser utilizado para jogos no estilo MMORPG. Presser (2006, p ) explica que, para o desenvolvimento deste trabalho, optou em utilizar a estrutura de rede proposta por Lyra Studios (2003, p. 1-4) que consiste em quatro camadas: a camada alternativa, utilizada opcionalmente para manter o software cliente sempre atualizado; a camada cliente, que abstrai detalhes de conexão e troca de mensagens com o servidor; a camada de sessão, que autentica o cliente e gerencia as transferências de dados entre o cliente e o servidor; e a camada do servidor de localização, que mantém o ambiente de 1 De acordo com GSM Association (2007), GPRS é uma solução de conectividade baseada em protocolos de internet e que suporta uma grande variedade de aplicações avançadas, como por exemplo transferência de vídeos e multimídia. Possui uma taxa de transferência de dados simular a um modem dial-up, mas com a vantagem de poder ser utilizado em qualquer lugar.

20 19 um jogo. A escolha de trabalhar com esta estrutura de rede foi motivada pelo fato de ser impossível a utilização de apenas um computador para servir um jogo no estilo MMO. Presser (2006, p ) explica que os jogos aumentam em quantidade de usuários, tamanho e complexidade, tornando necessário que se divida este mundo compartilhado pelos jogadores em vários servidores, inclusive para que não haja um único ponto de falha. Para a arquitetura interna do servidor, utilizou-se a divisão do universo em partes menores, para que se reduza a quantidade de informações enviadas a um determinado cliente. Desta maneira, apenas informações realmente relevantes da região do ambiente onde o cliente se encontra são enviadas aos mesmos. O autor utilizou dois canais de comunicação em cada parte, sendo um deles para o envio de informações ao jogador sobre a área em que o jogador se situa, e outro para o envio ao servidor da interação do jogador com o cenário do jogo.

21 20 3 DESENVOLVIMENTO Este capítulo tem por objetivo detalhar os principais requisitos que a ferramenta deve atender, assim como descrever os passos e os resultados obtidos com a implementação. Na seção abaixo são apresentados os requisitos do trabalho desenvolvido. 3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO A arquitetura de servidores distribuída do jogo MMO deverá: a) efetuar login de clientes do jogo Galaxy Navigator devidamente instalados em telefones celulares (Requisito Funcional RF); b) permitir a conexão de todos os clientes de celulares que efetuarem login, até um limite máximo estabelecido pelo administrador do servidor (RF); c) persistir os perfis de cada jogador na base de dados (RF); d) controlar as regras do jogo estabelecidas (RF); e) suportar a interação dos jogadores humanos com personagens NPC (RF); f) ser implementado na linguagem de programação Java (Requisito Não Funcional RNF); g) ser fortemente distribuído, o que engloba estratégias para ser tolerante a falhas e realizar a distribuição de sobrecarga entre os servidores distribuídos (RNF). Já o cliente do jogo Galaxy Navigator deverá: a) efetuar conexão com um servidor de contas, também denominado Login Server (RF); b) constantemente atualizar e exibir o ambiente em que se encontra o usuário, a partir dos dados recebidos dos servidores distribuídos de jogo, ou Game Servers (RF); c) repassar aos servidores de jogo as ações pretendidas pelo usuário (RF); d) funcionar em celulares com máquina virtual Java, perfil MIDP 2.0 e acesso à internet (RNF); e) ser implementado em J2ME (RNF).

22 ESPECIFICAÇÃO A finalidade desta seção é especificar a ferramenta desenvolvida, através de imagens e diagramas definidos pela Unified Modeling Language (UML). A ferramenta Enterprise Architect é o meio para o desenvolvimento destes diagramas. Para aprofundar o funcionamento da ferramenta da melhor maneira possível, os diagramas escolhidos para a especificação são os de caso de uso, de classes, de seqüência e de estados. Na primeira seção, são especificadas as regras do jogo Galaxy Navigator, sendo os diagramas da UML apresentados nas quatro seções subseqüentes. A seção que segue logo após a diagramação tem por finalidade apresentar a modelo de dados que persiste o universo virtual do jogo Galaxy Navigator Regras do jogo Galaxy Navigator O jogo Galaxy Navigator é um jogo que tem por finalidade demonstrar se há viabilidade na construção de jogos MMO para a plataforma de aparelhos celulares. Para tal, o mesmo possui regras que caracterizam jogos classificados como MMO. Há um ambiente virtual único que é compartilhado entre vários jogadores ao mesmo tempo, cada qual administrando sua civilização espacial em seu celular. Os servidores do jogo realizam a persistência dos dados do universo compartilhado entre os jogadores, inclusive dos próprios jogadores. Assim, o universo deste jogo consiste em um universo matricial, com 128 linhas e 128 colunas. Cada coordenada representa um sistema solar que pode ser conquistado pelos jogadores. Estes sistemas solares possuem três recursos a serem explorados pelos jogadores: alimento, metal e combustível. Há sistemas solares que possuem mais recursos que outros. Cada jogador deve possuir um login e uma senha cadastrados na base de dados da arquitetura servidora, assim como qual raça escolheu para jogar. Ao conectar no jogo pela primeira vez, o jogador recebe uma sede inicial de sua civilização. Nela é possível erguer construções, como refinarias de recursos, laboratório tecnológico, fábrica de naves espaciais, além de ser possível melhorar as defesas contra ataques. É possível para cada sede construir até 3 refinarias que aumentam a extração do recurso escolhido, sendo que não é possível construir 2 refinarias para extrair um mesmo recurso. Possuindo uma fábrica, é possível

23 22 construir naves transportadoras, com as quais o jogador poderá colonizar outros sistemas solares. Com a fábrica também podem ser construídas naves de ataque que sempre acompanham as naves transportadoras. É necessário que haja uma nave transportadora no mesmo sistema solar onde há a sede com a fábrica. Possuindo um laboratório tecnológico, melhores defesas e melhores naves que acompanham as naves transportadoras podem ser construídos. Possuindo uma nave transportadora, o jogador pode movê-la para sistemas solares vizinhos, podendo construir sedes novas em sistemas não colonizados. Havendo sedes ou naves transportadoras de jogadores adversários ao lado do sistema solar em que se encontra a nave transportadora do jogador, o mesmo pode realizar um ataque. Destruindo a sede adversária, o jogador pode construir sua nova sede nesta coordenada. Cada ação efetuada pelo jogador possui um determinado tempo para que seja executada. O jogo Galaxy Navigator baseia-se em unidades de tempo próprias, que equivalem a uma quantia de tempo real, em segundos. Uma construção que demore 5 unidades de tempo para ser construída é finalizada em aproximadamente 25 minutos de tempo real, caso o servidor do jogo Galaxy Navigator seja configurado para contar o tempo interno do jogo a cada 5 minutos de tempo real. A figura 4 mostra os elementos principais referentes ao jogo, da maneira como são mostrados aos jogadores na interface gráfica dos dispositivos móveis. Figura 4 Elementos principais do jogo A maneira como os jogadores acessam o jogo persistido na arquitetura servidora é demonstrado na figura 5, a qual caracteriza uma topologia geral do funcionamento da arquitetura do jogo. Cada jogador, com seu celular, acessa um servidor de autenticação, o LoginServer.

24 23 Este servidor, além de iniciar os servidores GameServer e NPCServer, autentica cada jogador na base de dados. Após o sucesso na autenticação, o servidor LoginServer cria uma thread de PlayerAction. Cada PlayerAction comunica-se com um único cliente de cada jogador. Deste modo, cada jogador pode solicitar ações em seu cliente, as quais passam a ser tratadas pela threads de PlayerAction correspondente. PlayerAction persiste diretamente na base de dados estas ações dos jogadores. O servidor GameServer tem por finalidade, de tempos em tempos, verificar as ações dos jogadores persistidas na base de dados, executando-as de acordo com as regras do jogo. Este espaço de tempo pode ser configurado pelo administrador que iniciar a arquitetura servidora. Quanto maior o espaço de tempo configurado para que as ações dos jogadores sejam processadas, maior o tempo de evolução de cada jogador no universo compartilhado. Figura 5 Topologia geral do jogo

25 Diagramas de Caso de Uso O diagrama de caso de uso apresentado na figura 6 tem por finalidade especificar quais as ações que um jogador pode realizar a partir de seu módulo cliente com a arquitetura servidora. Possuindo um celular devidamente configurado com o módulo cliente, o ator jogador inicia o processo de conexão à arquitetura servidora de jogo enviando seu login e senha. Após a autenticação ser efetuada, o jogador recebe no seu aparelho móvel todas as informações de sua civilização virtual. Inicialmente uma de suas sedes é centralizada no mapa regional que é exibido. Esse mapa regional consiste nesta sede visualizada inicialmente e em todas as posições adjacentes à mesma, além de mostrar sedes e naves transportadoras do próprio jogador e de seus adversários. O jogador pode então escolher na interface apresentada pelo módulo cliente visualizar outra sede ou nave transportadora que a ele pertença. Efetuando esta ação, o objeto selecionado é centralizado na tela, e um mapa regional correspondente àquele objeto é carregado e exibido na tela. Caso não deseje visualizar outro objeto, o jogador pode efetuar uma ação com o objeto já centralizado, como começar uma construção numa sede, ou solicitar que a nave transportadora se movimente. Figura 6 Caso de Uso da arquitetura servidora Logo abaixo, no Quadro 1, são apresentados os cenários que dizem respeito à interação que o usuário pode realizar com a arquitetura servidora. Primeiramente, é explanado o cenário principal do caso de uso Realiza Login, seguido dos cenários do caso de uso Solicita

26 25 Visualização e finalmente os cenários do caso de uso Realiza Ação. Realiza Login Descrição: Cada jogador, com um módulo cliente instalado em seu celular, tenta conectar-se à arquitetura servidora distribuída. Ator Principal: Jogador Cenário Principal: realiza login 1. o jogador informa login e senha na interface do módulo cliente instalado no celular; 2. o módulo cliente envia as informações para serem autenticadas pela arquitetura de servidores; 3. a arquitetura servidora confirma que o login e senha informados são válidos; 4. a arquitetura servidora envia para o módulo cliente as informações do jogador. Cenário de Exceção: dados inválidos No passo 3 do cenário principal realiza login, caso os dados informados sejam inexistentes ou inválidos, a arquitetura servidora deve enviar um protocolo caracterizando que o login falhou por dados inválidos. Pré-condição: o jogador deve possuir dados já cadastrados na base de dados da arquitetura servidora. Pós-condição: o jogador pode efetuar ações. Solicita Visualização Descrição: O jogador pode solicitar visualizar a área em que está outra sede ou nave transportadora, para interagir com este objeto. Ator Principal: Jogador Cenário Principal: solicita visualização 1. o jogador seleciona na interface do módulo cliente o objeto que deseja visualizar no mapa. 2. o módulo cliente envia as coordenadas correspondentes ao objeto que deseja centralizar no mapa à arquitetura servidora. 3. a arquitetura servidora prepara a área correspondente, enviando ao jogador as informações de sedes e naves transportadoras vizinhas ao objeto centralizado. Pré-condição: o jogador deve ter realizado login. Realiza Ação Descrição: O jogador realiza uma ação com a sede ou nave transportadora centralizada no mapa. Ator Principal: Jogador Cenário Principal: realiza ação 1. o jogador seleciona na interface do módulo cliente uma ação possível com o objeto que está centralizado no mapa. 2. o módulo cliente envia os dados relativos à ação executada pelo jogador à arquitetura servidora. 3. a arquitetura servidora interpreta a ação do jogador, que no tempo designado será executada. Pré-condição: o jogador deve ter realizado login. Quadro 1 Cenários dos casos de uso Na seção abaixo, são apresentados os diagramas de classe do módulo cliente, assim como da arquitetura servidora distribuída Diagramas de Classes Na seqüência são exibidos os diagramas de classe do módulo cliente, situado no dispositivo móvel de cada jogador, e da arquitetura servidora, gerenciada pelo administrador

27 26 deste jogo. Assim, demonstra-se a estrutura interna que compõe este jogo demonstrativo. O diagrama de classes da Figura 7 mostra a organização do módulo cliente. A classe GN estende MIDlet e implementa CommandListener, sendo deste modo a classe responsável pela inicialização do cliente no dispositivo do jogador. Para isso, possui uma instância da classe GNCanvas, que permite exibir na tela comandos possíveis, além de desenhar uma região visualizada pelo jogador no jogo. Uma instância da classe Comunicador permite que haja conexão com a arquitetura servidora, uma vez que sejam informados os dados relativos ao jogador, assim como o endereço em que se localiza a arquitetura servidora. Cada vez que o jogador seleciona uma ação exibida na tela, o método commandaction() identifica o código dessa ação, que é repassado à instância de Comunicador. Através de conexão via socket, a ação é enviada à arquitetura servidora, e os resultados são repassados pela arquitetura servidora através desta mesma conexão. Toda vez que informações precisam ser atualizadas para o jogador, as mesmas são repassadas para a instância da classe GNCanvas. Além de ser responsável por exibir os dados na tela ao jogador, a instância de GNCanvas armazena os dados do jogador recebidos da arquitetura servidora, como informações sobre suas sedes e transportes, por exemplo. Assim, mudanças nestes dados são repassados ao jogador ao redesenhar a tela, função executada pelo método repaint(). Figura 7 Diagrama de classes do módulo cliente

28 27 Para demonstrar a estrutura interna da arquitetura servidora, a Figura 8 mostra o diagrama de classes desta arquitetura. Figura 8 Diagrama de classes da arquitetura servidora A inicialização da arquitetura é feita pela classe LoginServer, a qual deve ser iniciada

29 28 por um administrador. Ela é responsável por chamar remotamente a inicialização das classes GameServer e NPCServer. A classe GameServer controla o tempo interno do jogo em que são executadas as ações enfileiradas na base de dados. A classe NPCServer administra uma civilização artificial, que ataca jogadores em determinados momentos. LoginServer recebe pedidos de autenticação dos clientes J2ME, encaminhando os Sockets como parâmetro para novas Threads de PlayerAction. Cada Thread é responsável pela comunicação com o cliente J2ME e, assim como GameServer e NPCServer, podem chamar métodos remotos da classe Banco. Esta classe Banco é responsável por acessar o banco de dados para execução de várias operações de persistência dos dados dos jogadores, assim como aquisição dos dados já persistidos. Cada instância da classe PlayerAction acessa remotamente o método logajogador() da classe Banco, para que receba uma instância da classe Logon. Esta classe Logon é uma estrutura que possui todas as informações referentes ao jogador que está efetuando login. A classe PlayerAction também acessa os demais métodos da classe Banco para efetuar atualizações nos dados do jogador sempre que necessário, assim como enfileiramento de ações e solicitação de visualização de uma nova área do mapa do universo. Na próxima seção, é apresentado o diagrama de seqüência que descreve os passos da comunicação a partir de cada conexão Diagramas de Seqüência O diagrama de seqüência da Figura 9 tem por objetivo mostrar uma visão interna da arquitetura servidora durante a comunicação com cada jogador. Primeiramente, um administrador do servidor distribuído necessita iniciar os servidores, ativando deste modo o servidor LoginServer. Este por sua vez ativa remotamente os servidores GameServer e NPCServer. O GameServer é responsável por controlar o tempo interno do jogo, além de executar as ações armazenadas na base de dados no momento correto. Já o NPCServer é responsável por controlar uma civilização rebelde, que realiza ataques em sedes aleatórias no mapa, em determinados espaços de tempo. Logo após, o LoginServer estará pronto para receber conexões via Socket de celulares. Ao receber uma conexão de um celular, o LoginServer dispara uma Thread de PlayerAction que realiza toda a comunicação subseqüente com o cliente que conectou. Para

30 29 que isso aconteça, esta instância de PlayerAction recebe como parâmetro em seu método construtor o Socket com a conexão do cliente J2ME. Ao ser ativada através do método start(), a Thread solicita ao servidor de base de dados, através do método remoto logajogador(), todas as informações de objetos pertencentes ao jogador em questão. Figura 9 Diagrama de seqüência Repassando estes dados ao módulo cliente do jogador, o mesmo pode solicitar visualizar no mapa outra sede ou outra nave transportadora. O jogador pode, ao envés disso,

31 30 simplesmente solicitar uma ação com o objeto já centralizado inicialmente, mas no exemplo exposto no diagrama de seqüência abaixo, optou-se por demonstrar uma solicitação de visualização primeiramente. O jogador pode, portanto, continuar solicitando visualização de outros objetos à Thread correspondente, assim como realizar possíveis ações com estes objetos centralizados. Ao solicitar desconexão (ou logoff) a Thread é interrompida chamando-se o método stop(). A próxima seção apresenta o diagrama de estado da arquitetura servidora Diagramas de Estados Logo abaixo, os estados em que a arquitetura servidora pode estar são apresentados na Figura 10, bem como os eventos que realizam as transições entre estes estados. Figura 10 Diagrama de estados Inicialmente, a arquitetura servidora aguarda por conexões dos módulos clientes. No momento em que um cliente envia seus dados para efetuar uma autenticação, já é estabelecida

32 31 uma conexão com a arquitetura. Partindo deste ponto, caso o login esteja correto, as informações do jogador são carregadas. Caso o login esteja incorreto, é repassado um alerta para o módulo cliente e não prossegue a comunicação. Sendo as informações carregadas, são repassadas ao cliente J2ME, e a arquitetura servidora permanece aguardando alguma ação do jogador. Este, então, pode solicitar visualizar uma área de uma sede ou de uma nave transportadora diferente da qual está apresentada. Do mesmo modo, o jogador pode estar já satisfeito com o objeto que está centralizado, e deste modo efetuar uma ação com o mesmo. A comunicação com o cliente termina com a solicitação de logoff, finalizando a autenticação Modelagem de dados A classe Banco acessa diretamente o banco de dados MySQL e possui métodos que podem ser acessados de maneira remota. Deste modo, há uma sobrecarga menor à arquitetura servidora, podendo este servidor de banco de dados ser inicializado em outra máquina. Na Figura 11, é apresentada a modelagem da base de dados, a qual é utilizada para que haja o funcionamento do jogo Galaxy Navigator.

33 32 Figura 11 Modelo de dados A tabela users tem por finalidade armazenar a informações dos usuários cadastrados no servidor distribuído do jogo Galaxy Navigator. Cada usuário pode possuir mais de uma sede e mais de uma nave transportadora. Já a tabela sistema possui sistemas solares e as informações dos recursos de cada sistema solar que fora previamente gerado. Cada sistema solar pode possuir mais de uma nave transportadora, porém apenas uma sede. As tabelas sede e transporte armazenam as informações de cada sede ou nave transportadora, assim como os usuários a quem pertencem e em qual sistema solar estão. Cada sede ou nave transportador pode efetuar apenas uma ação ao mesmo tempo, sendo a tabela acoes responsável pelo enfileiramento de ações solicitadas por todos os usuários.

34 Protocolo de comunicação Para que o módulo cliente possa enviar e receber informações das Threads instanciadas da classe PlayerAction, foi necessário estabelecer um protocolo de comunicação. A comunicação é feita bilateralmente com envios de 4 bytes através de conexão via Socket. Os bytes transmitidos seguem rigorosamente o protocolo estabelecido. Caso contrário, o resultado final é totalmente diferente do desejado. No quadro 2 é apresentado o protocolo para transmissão de informações através de 4 bytes enviados por vez. Ao solicitar conexão com a arquitetura servidora, o software instalado no dispositivo móvel envia a seqüência de bytes, sendo que o primeiro deles é um caractere L, sinalizando a solicitação de login. Os demais bytes desta seqüência inicial não são utilizados. A arquitetura servidora realiza o processo de login, reenviando ao módulo cliente uma seqüência de 4 bytes, onde o primeiro indica através do caractere L que trata-se do retorno da solicitação de login. Já o segundo byte desta seqüência indica o sucesso do processo de login. Caso trate-se de um caractere A, isto significa que não houveram problemas no processo de autenticação, enquanto um caractere B sinaliza uma falha. Os 2 bytes à direita não são utilizados. Após a autenticação, o módulo cliente permanece na espera por suas informações, que são repassadas pela arquitetura servidora através de 2 sequências de 4 bytes para cada sede ou transporte que o jogador possua. Inicialmente todas as sedes são repassadas ao módulo cliente. O primeiro byte da primeira seqüência de bytes informa o caractere S com a finalidade de sinalizar uma sede. Os próximos 2 bytes indicam as coordenadas x e y onde se encontra esta sede no universo, e o último byte indica o nível da fábrica nesta sede. Outra seqüência de 4 bytes completam as informações referentes à sede em questão, repassando ao cliente, respectivamente, a defesa convencional, a defesa avançada, o nível do laboratório de tecnologia e as informações a respeito das refinarias. Outros pares de seqüências são enviados, sempre identificados como sedes, caso o primeiro byte da primeira seqüência represente um caractere S. Ao receber um caractere T, as duas seqüências de bytes são interpretadas como informações sobre um transporte do jogador, sendo que estas seqüências informam as coordenadas e informações de cada transporte. Recebendo uma seqüência com o primeiro byte representando um caractere L e o segundo um caractere F, o software cliente pode solicitar visualizar uma sede ou um transporte. Assim, envia uma seqüência cujo primeiro byte representa o caractere V, seguido de

35 34 dois bytes que indicam as coordenadas x e y a visualizar. Ao mesmo passo, tem como retorno da arquitetura servidora 9 seqüências de bytes que representam a área ao redor da coordenada solicitada, com informações de sedes e transportes. Se a seqüência possuir o primeiro byte representando um caractere A ao envés de um caractere V, então a arquitetura servidora interpreta a seqüência como uma ação do jogador, sendo o segundo byte o tipo de ação realizada, e os últimos dois bytes identificam a coordenada x e y para o caso da ação ter sido um ataque. Ainda caso o primeiro byte da seqüência não representar nem um caractere A, nem um caractere V, pode significar solicitação de desconexão, caso seja um caractere F seguido de outro byte representando um caractere F. [L***] - L - Solicitação de login do cliente - * - irrelevante [LA**] - LA - login correto [LB**] - LB - login inválido - * - irrelevante [S(x)(y)(f)] - S - Sede - (x)(y) - coordenadas - (f) - nível da fábrica [(dc)(da)(t)(r)] - (dc) - defesa convencional - (da) - defesa avançada - (t) - nível lab. tecnologia - (r) - refinarias [T(x)(y)*] - T - transporte - (x)(y) - coordenadas - * - irrelevante [(cr)(ca)**] - (cr) - cruzadores - (ca) - cacas [LF**] - LF - fim da transmissão inicial dos dados do jogador - * - irrelevante [V(x)(y)*] - V - visualização de área - (x)(y) - coordenadas - * - irrelevante [(x)(y)(tsv)(r)] - (x)(y) - coordenadas - (tsv) - transp./sede/vazio - (r) - raça [A(tipo)(x)(y)] - A - ação no objeto - (tipo) - tipo de ação - (x)(y) - local(p/ ataques) [FF**] - FF - logoff - * - irrelevante Quadro 2 Protocolo de comunicação

36 IMPLEMENTAÇÃO Esta seção visa descrever os passos da implementação da arquitetura servidora e do módulo cliente. Na primeira seção, são apresentadas as ferramentas utilizadas para tornar possível a elaboração do jogo, assim como as técnicas escolhidas. Após, é detalhada a operacionalidade da implementação, a fim de esclarecer como o usuário utiliza a aplicação final Técnicas e ferramentas utilizadas Para especificação da arquitetura servidora e do módulo cliente, foi utilizado o software Enterprise Architect. A modelagem dos dados foi feita utilizando o software DBDesigner, e para o desenvolvimento do trabalho, foi utilizado o software Netbeans 5.5, juntamente com o simulador de J2ME Wireless Toolkit 2.2. A base de dados utilizada foi o MySql. A comunicação com o cliente utiliza a conexão via Socket, da mesma maneira que utiliza Hamer (2004), enviando bilateralmente 4 bytes que seguem o protocolo descrito na seção anterior. Hamer (2004, p.218 tradução nossa) afirma que é importante manter simples os dados enviados quando se trata de dispositivos móveis pequenos como celulares. Deste modo, o protocolo estabelecido realiza de maneira simples todas as trocas de informações entre o módulo cliente e a arquitetura servidora. Para o dispositivo móvel, programado com J2ME, a conexão via Socket é iniciada da maneira como mostrado no Quadro 3.

37 36 public static final String SERVER_URL = "socket:// :8007"; private GNCanvas mycanvas; DataInputStream dis = null; DataOutputStream dos = null; SocketConnection conn = null; byte[] fourbytes = new byte[4]; try { mycanvas.setmsg("aguarde..."); mycanvas.repaint(); conn = (SocketConnection)Connector.open(SERVER_URL); conn.setsocketoption(socketconnection.keepalive, 1); dos = conn.opendataoutputstream(); dis = conn.opendatainputstream(); fourbytes[0]='l'; fourbytes[1]='j'; fourbytes[2]='b'; fourbytes[3]='c'; dos.write(fourbytes,0,fourbytes.length); dis.readfully(fourbytes); String respserver = "" + (char)fourbytes[0] + (char)fourbytes[1] + (char)fourbytes[2] + (char)fourbytes[3]; Quadro 3 Conectando com socket em J2ME A classe GNCanvas é a responsável por desenhar no display do dispositivo móvel e atualizar o conteúdo com as chamadas ao método repaint(). O objeto do tipo SocketConnection realiza a conexão via socket com o endereço do servidor estabelecido. Ao mesmo passo, disponibiliza para os objetos do tipo DataInputStream e DataOutputStream leitura e gravação, respectivamente, através desta conexão socket. ServerSocket ss; ss = new ServerSocket(porta); Socket socketcelular = ss.accept(); socketcelular.setkeepalive(true); PlayerAction playeraction = new PlayerAction(socketCelular); playeraction.start(); Quadro 4 Recebendo as conexões via socket A classe LoginServer é inicializada pelo administrador do sistema, e é a responsável, na arquitetura servidora, pela escuta de conexões socket, assim como inicializar uma Thread específica para gerenciar a comunicação com cada conexão. Também é ela que ativa o

38 37 GameServer e o NPCServer, através de uma referência remota para cada um destes servidores. Um objeto do tipo ServerSocket aceita conexões via socket, armazenando estas conexões num objeto do tipo Socket, como é mostrado no quadro 4. A classe LoginServer, neste ponto, cria e ativa uma nova Thread, instância da classe PlayerAction. Esta classe implementa uma Thread e manterá a comunicação com o módulo cliente que efetuou a conexão, já que lhe é passada como parâmetro o objeto do tipo Socket que possui a conexão. Nesta classe PlayerAction, conforme é demonstrado no quadro 5, há um objeto do tipo Socket, o qual é inicializado no construtor da classe PlayerAction com a conexão socket passada como parâmetro. Logo em seguida, os dois objetos dos tipos OutputStream e InputStream recebem meios para escrita e leitura através da conexão via socket. No construtor da classe PlayerAction ainda é recebida uma referência remota da classe Banco, armazenada num objeto do tipo BancoInterface. Deste modo, há um acesso remoto ao banco de dados, permitindo operações como login de usuários, ou relativas às regras do jogo. Portanto, cabe à classe LoginServer receber todas as conexões vindas de módulos clientes. Porém, cada instância desta classe PlayerAction é apta a realizar a comunicação com um único módulo cliente, o qual é passado como parâmetro na construção da classe. Todas as instâncias executam como Threads paralelamente, cada uma recebendo do processador da máquina uma fatia de tempo para comunicação com os clientes e demais operações. private Socket celularsocket; private OutputStream myoutput; private InputStream myinput; BancoInterface banco; PlayerAction(Socket celularqueconectou) { try { celularsocket = celularqueconectou; myoutput = celularsocket.getoutputstream(); myinput = celularsocket.getinputstream(); try { banco = (BancoInterface)Naming.lookup("//" + " " + "/Banco"); } catch (Exception e) {} } catch (Exception e) {} } Quadro 5- Construtor da classe PlayerAction