Uma Plataforma para Jogos Móveis Massivamente Multiusuário
CARLOS EDUARDO SILVA1
DANIEL ARRAES2
DAVI PEDROSA1
FERNANDO TRINTA1
ISABEL WANDERLEY2
MARCELO PITA2
MARCIO PORTELA1
MARCUS MACHADO2
RAFAEL BORGES2
GEBER RAMALHO1
1
Universidade Federal de Pernambuco – Centro de Informática
{cesps,dvp,famt,mpl,glr}@cin.ufpe.br
2
Centro de Estudos e Sistemas Avançados do Recife
{dap,iws,mrsp,mvlm,rmb}@cesar.org.br
__________________________________________________________________________________________
Resumo
Jogos móveis massivamente multiusuário representam um nicho importante a ser
explorado. Neste artigo, apresentamos os pré-requisitos, a arquitetura e o
protótipo de uma plataforma open-source extensível que ofereça serviços de
suporte ao desenvolvimento e à execução deste tipo de jogo, ocultando alguns dos
problemas comuns neste cenário.
Palavras Chave: Jogos Móveis Massivamente Multiusuário, Plataforma, MMMOG.
__________________________________________________________________________________________
1 Introdução
No modelo de jogos multiusuário, os jogadores
interagem através da troca de mensagens em
uma rede. Inicialmente, devido a restrições de
largura de banda e latência, estes jogos
limitavam-se a um pequeno número de usuários
situados na mesma rede local. Entretanto, com o
avanço das tecnologias de comunicação e o
sucesso da Internet, foi possível criar jogos nos
quais milhares de jogadores interagem
simultânea e continuamente num mundo virtual
persistente. Graças a isso, estes jogos foram
classificados como massivamente multiusuário
(MMOG).
Em uma linha paralela, a melhoria da
capacidade de processamento e de comunicação
dos dispositivos móveis permite a criação de
jogos móveis cada vez mais elaborados.
Da convergência entre a computação móvel
e os jogos massivamente multiusuário, ambos
bastante populares, nascem os jogos móveis
massivamente multiusuário (MMMOGs). Estes
têm um grande poder de entretenimento e apelo
comercial, haja vista que a maioria dos jogos
disponíveis hoje para celulares é monousuário e
off-line.
Neste nicho, as primeiras experiências já
foram realizadas em jogos como TibiaME [1] e
Era of Eidolon [2], lançados na Europa, e
Samurai Romanesque [3], no Japão. Entretanto,
ainda não há um consenso sobre a arquitetura de
uma plataforma para MMMOGs.
Diante deste contexto e da somente
existência de soluções proprietárias (e.g., Snap
Mobile [4] e TerraPlay MOVE [5]), a nossa
proposta é, com o apoio da FINEP1 [6] e da
parceria entre o C.E.S.A.R [7], a Meantime [8],
a UFPE [9] e a Unicamp [10], criar uma
plataforma open-source extensível que ofereça
serviços de suporte ao desenvolvimento e à
execução de jogos móveis, multiusuário e
massivos.
2 Pré-requisitos
A plataforma deve assumir o papel de um
middleware [11] especializado que se baseia na
topologia cliente/servidor, onde o acesso dos
jogadores dar-se-á através da infra-estrutura
formada por vários servidores. Esta topologia foi
a escolhida dadas as restrições tecnológicas
(como a latência e o baixo poder de
processamento) para a construção de jogos
massivos via rede ponto a ponto em dispositivos
móveis.
Este middleware deve fornecer os principais
serviços necessários e comuns a jogos móveis,
multiusuário e massivos, atuando como elo entre
os jogadores e a infra-estrutura de servidores.
Além
disso,
deve
transparecer
aos
desenvolvedores problemas recorrentes nestas
aplicações como, por exemplo, a troca de
mensagens e a persistência das informações.
Os principais serviços disponibilizados pela
plataforma serão: Gerência de Contas,
Pontuação, Chat, Download de Conteúdo,
Notícias, Tarifação e Monitoramento do
Servidor. Para viabilizar o acesso a estes
serviços, deve existir uma infra-estrutura que
trata as questões relacionadas à comunicação
entre os serviços, à persistência, ao
escalonamento e à tolerância a falhas.
3 Plataforma
A plataforma é dividida em dois módulos:
cliente e servidor. O módulo cliente é composto
por uma Application Programming Interface
(API) que provê abstrações e acesso aos serviços
implementados no servidor da plataforma. Já o
módulo servidor é composto pela infra-estrutura
1
O projeto Plataforma para Jogos Móveis
Massivamente Multiusuário. Aprovado pela FINEP, edital
número 0104097300, assinado em 15/12/2004.
Anais do SBgames, novembro de 2005
(middleware) e pelos serviços disponibilizados.
A
infra-estrutura
é
responsável
pelo
balanceamento, escalonamento e monitoramento
das chamadas aos serviços e pela alocação e
desalocação destes.
Os serviços são entidades autocontidas
responsáveis por prover funcionalidades
específicas. Os mesmos podem se comunicar e
serem coordenados por outros serviços providos
pelos desenvolvedores (third-parties). Por sua
vez, o jogo residente no cliente comunica-se
com um dispatcher capaz de entender suas
solicitações e encaminhá-las para os reais
executores.
No módulo servidor também é oferecido um
console web para o monitoramento da
plataforma (como alocar e desalocar serviços), a
gerência de usuários (bloqueio e desbloqueio de
contas de jogadores, remoção de jogadores), o
envio de notícias, dentre outras atividades
pertinentes à administração.
A parte necessária para o funcionamento da
plataforma em um servidor é chamada Platform
Runtime. Ela contém os agentes monitores do
estado da máquina (processamento e memória),
as entidades, os utilitários necessários e as
interfaces de acesso aos serviços. A Figura 1
representa a macro visão da arquitetura da
plataforma.
Figura 1: Macro Visão da Plataforma
Várias instâncias de um mesmo serviço
podem estar em execução num dado instante;
podem ser distribuídas e cabe a elas manter a
consistência de seu estado (seja via
UMA PLATAFORMA PARA JOGOS MÓVEIS MASSIVAMENTE MULTIUSUÁRIO
sincronização, particionamento do estado ou
compartilhamento de dados).
4 Arquitetura
A visão da plataforma mais detalhada,
especificando as entidades e como elas estão
relacionadas é ilustrada na Figura 2. É
importante destacar que a figura apresenta a
infra-estrutura necessária para a execução da
plataforma. Os detalhes funcionais de cada
serviço não estão aqui especificados, uma vez
que a intenção é prover um arcabouço nos quais
os serviços são adicionados, contanto que
implementem uma interface previamente
acordada.
Figura 2: Entidades e relacionamentos da Plataforma
Abaixo, segue a descrição destas entidades
com suas respectivas funcionalidades:
Session Dispatcher: responsável pela
comunicação inicial do jogador. É o ponto de
acesso externo (via URL) e sua função é
direcionar a conexão do jogo para uma das
possíveis instâncias de Session Manager.
Session Manager: representa o jogo na
requisição das tarefas na plataforma. Possui uma
conexão com o mesmo (via HTTP) e tem como
função repassar suas solicitações para a melhor2
instância de um determinado tipo de serviço.
Service Balancer: responsável pelo
balanceamento da carga dos servidores. Sua
referência é conhecida por todas as outras
entidades e é requisitada sempre que for
necessário solicitar um serviço. Esta entidade
está intrinsecamente relacionada a outras duas, o
Directory Service e o Monitor, e também
representa um ponto de acesso às mesmas. Esta
entidade constitui ponto crítico para a
plataforma.
Directory Service: constitui um serviço de
diretórios semelhante a serviços de nomes
tradicionais em sistemas distribuídos orientados
a objetos, possuindo informações acerca dos
serviços disponíveis no momento. Qualquer
serviço da plataforma deve se registrar no
Directory Service (através do Service Balancer)
para então receber solicitações do Session
Manager e/ou de outros serviços.
Monitor: coleta informações sobre o estado
(como o nível de processamento ou consumo de
memória) dos servidores. Esses dados são
utilizados pelo Service Balancer para decidir
qual serviço é mais apropriado para atender a
uma solicitação.
Service Manager: responsável pela alocação
e desalocação de serviços. Esta entidade se
comunica com o Platform Runtime de cada
servidor para realizar tais operações.
Platform Runtime: constitui o conjunto de
serviços básicos oferecidos pela plataforma aos
serviços instalados em um determinado servidor.
Possui uma instância por servidor e
disponibiliza funcionalidades como persistência,
alocação local de serviços e monitoramento
local.
Scheduler: responsável por automatizar a
alocação e desalocação dos serviços baseado em
políticas pré-definidas. É um componente
fundamental para aspectos como tolerância a
falhas e escalabilidade.
2
Entende-se aqui por melhor instância aquela que,
sob a avaliação critérios pré-definidos de desempenho,
possui a melhor classificação.
5 Protótipo
Desenvolvemos um protótipo para validação da
arquitetura utilizando a linguagem Java (J2SE
[12] no servidor e J2ME [13] no cliente). Neste
protótipo, três serviços foram implementados
(Gerência de contas, Notícias e Chat), além de
autenticação e autorização dos jogadores e parte
da infra-estrutura.
Para garantir a segurança em nível de
autenticação e autorização dos usuários,
utilizamos a API Java Authentication and
Authorization Service (JAAS) [14]. Esta API
provê
uma
interface
de
autenticação
independente de mecanismo e oferece acesso
aos papéis desempenhados pelos usuários e
verificação das respectivas permissões. A
segurança dos dados transmitidos pela rede e
persistidos na base de dados é garantida através
da utilização de algoritmos de criptografia.
As entidades da plataforma, sejam elas
sobre o estado do jogo ou informações de contas
de usuários, utilizam a especificação Java
Persistence API [15] implementada pelo projeto
Hibernate [16], cuja tecnologia serviu de base
para a especificação.
A comunicação entre o cliente e o servidor
da plataforma é via HTTP, uma vez que a
plataforma deve abarcar a maior variedade de
dispositivos móveis. Em conseqüência disto, a
comunicação acontece através de mensagens
que obedecem a um protocolo bem definido.
Por fim, a comunicação inter-serviços
utiliza Remote Method Invocation (RMI) [17].
6 Conclusão
Neste artigo, apresentamos os pré-requisitos, a
arquitetura e o protótipo de uma plataforma para
jogos móveis massivamente multiusuário. Esta
reflexão é de suma importância, haja vista que
se trata de uma nova tendência, sem literatura
suficiente sobre o tema.
É importante ressaltar que este projeto de
pesquisa ainda está em andamento. A
implementação de outros serviços bem como o
suporte a variados tipos de jogos (como os
baseados em turnos e os massivos) serão nossos
próximos passos; em paralelo, estamos
Anais do SBgames, novembro de 2005
desenvolvendo um jogo para efetuar a validação
da plataforma (o Mobies Multiplayer).
7 Referências
[1] CipSoft. Tíbia ME, http://www.tibiame.com/
(29/04/05).
[2] Watagame. Era of Eidolon,
http://www.eraofeidolon.com/ (29/04/05).
[3] Krikke, J. Samurai Romanesque, J2ME, and the
Battle for Mobile Cyberspace. IEEE Computer
Graphics and Applications, 2003.
[4] Nokia. Snap Mobile, http://snapmobile.nokia.com/
(18/07/05).
[5] Terraplay Systems. TerraPlay MOVE,
http://www.terraplay.com/ (14/06/05).
[6] FINEP. Financiadora de Estudos e Projetos,
http://www.finep.gov.br.
[7] C.E.S.A.R. Centro de Estudos e sistemas Avançados
do Recife, http://www.cesar.org.br.
[8] Meantime Mobile Creations.
http://www.meantime.com.br.
[9] Cin-UFPE. Centro de Informática da Universidade
Federal de Pernambuco, http://www.cin.ufpe.br.
[10] Unicamp. Universidade de Campinas,
http://www.unicamp.br.
[11] Emmerich, W. Software Engineering and
Middleware: A Roadmap. In Proceedings of the
Conference on the Future of Software Engineering,
pp. 117-129, June 2000.
[12] Sun Microsystems. Java 2 Platform, Standard
Edition, http://java.sun.com/j2se/index.jsp (25/04/05).
[13] Sun Microsystems. Java 2 Platform, Micro Edition,
http://java.sun.com/j2me/index.jsp (25/04/05).
[14] Sun Microsystems. Java Authentication and
Authorization Service (JAAS),
http://java.sun.com/products/jaas/ (26/08/05).
[15] Sun Microsystems. JSR 220: Enterprise JavaBeans
3.0, http://www.jcp.org/en/jsr/detail?id=220
(20/07/05).
[16] JBoss Inc. Hibernate, http://www.hibernate.org
(22/07/05).
[17] Sun Microsystems. Java Remote Method Invocation
(RMI), http://java.sun.com/products/jaas/ (26/08/05).