MILENA: um Modelo para ImpLEmentação de jogos

distribuı́dos multijogadores em Nuvens computacionAis

Delano J. H. Maia1 , Leonardo O. Moreira1 , Danielo G. Gomes2
1
Instituto Universidade Virtual (IUVI)
Universidade Federal do Ceará (UFC) – Fortaleza, CE – Brasil
2
Departamento de Engenharia de Teleinformática
Universidade Federal do Ceará (UFC) – Fortaleza, CE – Brasil
delanomaia@virtual.ufc.br,{leoomoreira,danielo}@ufc.br

Abstract. Cloud computing environments are characteristically composed of

distributed infrastructure, heterogeneous and virtualized resources, besides ser-
ving concurrently a wide range of customers whose service level agreements
may require different levels of Quality of Service (QoS). Distributed multiplayer
games, in turn, are collaborative distributed applications that must have an ac-
ceptable level of QoS to maintain justice among its players. This article pro-
poses MILENA, a model for implementing distributed multiplayer games on
computer clouds. The proposed model meets the requirements of QoS, fault
tolerance, elasticity and justice. As a case study for verification and validation
of the proposal, we have developed a game and evaluated its performance by
SLA violations and response time of requests metrics. The results show that the
MILENA is scalable without loss of QoS, thus improving justice in distributed
multiplayer games.

Resumo. Os ambientes computacionais em nuvens são caracteristicamente

compostos por infraestruturas distribuı́das e com recursos heterogêneos e vir-
tualizados, além de servirem concomitantemente a uma grande diversidade de
clientes cujos acordos de nı́veis de serviço podem exigir nı́veis de Qualidade
de Serviço (QoS) distintos. Jogos distribuı́dos multijogadores, por sua vez,
são aplicações distribuı́das colaborativas que devem possuir um nı́vel de QoS
aceitável para manter a justiça entre seus jogadores. Este artigo propõe MI-
LENA, um modelo para implementação de jogos distribuı́dos multijogadores
em nuvens computacionais. O modelo proposto atende a requisitos de QoS, to-
lerância a falhas, elasticidade e justiça. Na qualidade de estudo de caso para
verificação e validação da proposta, desenvolvemos um jogo e avaliamos seu
desempenho a partir das métricas violações de SLA e tempo de resposta das
requisições. Os resultados mostram que o MILENA é escalável sem perda de
QoS, melhorando, assim, a justiça em jogos distribuı́dos multijogadores.

1. Introdução e Motivação
A computação em nuvens é hoje um paradigma bem consolidado de utilização de recur-
sos computacionais, segundo o qual infraestrutura de hardware, software e plataformas
para o desenvolvimento de novas aplicações são oferecidos como serviços disponı́veis
remotamente e em escala global [Sousa et al. 2009]. Os usuários de nuvens computa-
cionais abrem mão de uma infraestrutura computacional própria para dispô-la mediante
de serviços oferecidos por terceiros (provedores de nuvem), delegando responsabilidades
e assumindo custos proporcionais à quantidade de recursos que utilizam (pay-as-you-go
model). Uma das caracterı́sticas utilizadas, pela nuvem, é a elasticidade. Com a elastici-
dade pode-se adicionar ou remover recursos conforme o modelo de qualidade, ou melhor
QoS (Quality of Service), especificado pela aplicação [Coutinho et al. 2013].
Os ambientes computacionais em nuvens são caracteristicamente compostos por
infraestruturas distribuı́das e com recursos heterogêneos e virtualizados, além de servirem
concomitantemente a uma grande diversidade de clientes cujo SLA (Service Level Agre-
ement) pode exigir nı́veis de QoS distintos [Sousa et al. 2009]. Ademais, os datacenters
que compõem uma nuvem de recursos devem suportar um número virtualmente ilimitado
de aplicações, o que os obriga a lidar com demandas variantes por processamento, arma-
zenamento de dados e utilização de banda. Na nuvem, cada parte da infraestrutura, plata-
forma e software é provida como um serviço. As PaaS (Plataform As A Service) fornecem
um sistema operacional, linguagens de programação e ambientes de desenvolvimento para
as aplicações [Sousa et al. 2009]. No âmbito dos jogos computacionais, surge a necessi-
dade de uma plataforma que forneça suporte para o desenvolvimento destes jogos. Essa
plataforma é comumente chamada de GaaS (Game as a Service) [Moreno et al. 2012].
Jogos Distribuı́dos Multijogadores são aplicações multimı́dia distribuı́das e
de tempo real, as quais simulam um ambiente virtual colaborativo ou interativo
[Cecin and Trinta 2007]. Nestes tipos de aplicativos, os jogadores podem interagir tanto
com o ambiente quanto com outros jogadores. Dentre os principais desafios destas
aplicações estão: garantias de justiça, tolerância a falhas e QoS. A heterogeneidade dos
ambientes computacionais, onde os jogos são executados, pode causar interferência no
jogo e beneficiar jogadores que possuem maior recurso computacional. Em tais tipos de
jogos, mecanismos de sincronização e comunicação eficiente são utilizados para agre-
gar justiça e exclusão mútua em processos distribuı́dos. Outro fato a ser considerado é
a dinâmica no número de jogadores participantes on-line. Assim, técnicas de balancea-
mento de carga e escalabilidade tornam-se fundamentais para manter um nı́vel de QoS
aceitável pelos jogadores, pois, à medida que cresce sua quantidade, mais mensagens de
sincronização e dados são trocadas, o que pode inundar o sistema computacional a ponto
de saturar sua capacidade de processamento e banda disponı́vel.
No contexto de jogos distribuı́dos multijogadores, as nuvens computacionais e seu
modelo de SLA poderão prover um ambiente mais adequado e justo para sua execução
de aplicações deste contexto. Diversos trabalhos têm discutido o uso de arquiteturas e
estratégias distribuı́das para oferecer justiça e QoS em jogos distribuı́dos multijogadores.
Tais trabalhos propõem ou expõem o uso de técnicas de distribuição de recursos, balan-
ceamento de cargas, escalabilidade, sincronismo e tolerância a falhas. Contudo, alguns
deles não apresentam uma avaliação de desempenho e a escalabilidade é tratada da mesma
forma que em sistemas distribuı́dos tradicionais.
Este artigo apresenta um modelo de implementação para jogos distribuı́dos multi-
jogadores em nuvens, denominado MILENA, e um conjunto de experimentos para validar
o desempenho alcançado por tais jogos nestes tipos de ambientes. Para tanto, desenvol-
vemos um protótipo do jogo bomberman [Nintendo 2013], no intuito de mostrar a aplica-
bilidade do MILENA.
O objetivo geral deste trabalho é propor um modelo de implementação para jo-
gos distribuı́dos multijogadores em nuvens. Para alcançá-lo, traçamos quatro objetivos
especı́ficos: (i) elaborar uma arquitetura, orientada a nuvens, para servir como base estru-
tural de implementação; (ii) especificar as funcionalidades e estratégias de implementação
de cada componente arquitetural; (iii) implementar um estudo de caso para mostrar, na
prática, o desenvolvimento do jogo; e (iv) avaliar nossa proposta na perspectiva de de-
sempenho e QoS agregada pelo nosso modelo de implementação.

2. MILENA
Nesta seção apresentamos o MILENA, nosso modelo de implementação para jogos dis-
tribuı́dos multijogadores em nuvens. Primeiramente, projetamos uma arquitetura-guia
para o desenvolvimento de tais jogos em ambientes de computação em nuvens e, na
sequência, desenvolvemos um protótipo do jogo bomberman para verificar e validar o MI-
LENA. Ainda nesta seção, apresentamos a especificação do modelo de implementação.
Por fim, são descritas as regras de negócio e o detalhamento do protótipo do jogo.

2.1. Arquitetura
A arquitetura do MILENA é orientada a componentes que realizam comunicação tanto em
outros componentes quanto na infraestrutura da nuvem. Uma visão geral da arquitetura
proposta pode ser obtida na Figura 1, a qual utiliza algumas ideias do trabalho que deu
origem ao QoSDBC (Quality of Service for Database in the Cloud) [Sousa et al. 2012].
O QoSDBC é uma plataforma baseada em componentes e infraestrutura em nuvens para
o gerenciamento de banco de dados com QoS.

BALANCEADOR DE CARGA

MONITOR MONITOR MONITOR MONITOR CATÁLOGO

GAME
THREAD
GAME
THREAD
GAME
THREAD ... GAME
THREAD
VM1 VM2 VM3 VMN GAME STATE

SERVIÇO DE ARMAZENAMENTO DISTRIBUÍDO

Figura 1. Proposta arquitetural

O Monitor é um componente que se comporta como um agente coletor de

informações e está incluso em todas as VMs (Máquinas Virtuais) do ambiente. Este com-
ponente é muito similar ao QoSDBCAgent do QoSDBC. Entretanto, nosso escopo de
coleta de dados é bem reduzido; estamos apenas interessados em saber o estado de cada
VM e os tempos de resposta das requisições que foram executadas naquela VM. Neste
sentido, coletamos informações sobre os recursos de CPU, memória RAM, conexões de
jogadores e, para cada requisição, o tempo de resposta. O Catálogo é um banco de da-
dos que é alimentado pelos componentes Monitor. Neste sentido, o Catálogo contém
todas as informações de CPU, memória, número de conexões socket ativas e os tempos
de resposta de cada requisição. Cada VM possui uma entrada neste banco de dados.
Já o componente Game Thread contém uma instância do jogo em cada VM. A
ideia deste componente é ter uma cópia da implementação do jogo em cada VM, o que
torna possı́vel o uso da elasticidade de recursos para garantir a QoS desejada no jogo.
Ressaltamos que o Game Thread só contém as regras de negócio do jogo. O estado
global do jogo fica em um banco de dados distribuı́do na nuvem denominado Game State.
Neste sentido, as regras de negócio devem manipular os dados que estão neste banco
de dados para fazer a manutenção do estado global do jogo. Toda interação com esse
banco de dados, que contém o estado global do jogo, é feita por meio de transações.
Isso é importante para garantir que as requisições sejam livres de anomalias de acesso
concorrente. Outro ponto importante da arquitetura do MILENA é que todo estado do
jogo é persistido em um Serviço de Armazenamento Distribuı́do, o que torna o jogo
tolerante a falhas.
O componente Balanceador de Carga é o front-end de interação com a nuvem.
Este componente possui a função de decidir qual VM deve atender à requisição de um
dado jogador. Para isso, o Balanceador de Carga consulta o componente Catálogo para
verificar a VM que está menos sobrecarregada. O critério de decisão é a VM que possui
menos conexão, mais memória primária disponı́vel e maior tempo livre de CPU. Após
verificar qual VM é a mais adequada, o Balanceador de Carga repassa a requisição para
que esta VM responda ao jogador.

2.2. Especificação
Cada VM é constituı́da de uma distribuição Linux, instalação da JVM (Java Virtual Ma-
chine), componente Monitor e o Game Thread. Quando uma VM é inicializada, sua
localização fica descrita no Catálogo. Para iniciar o jogo, é necessário a disponibilidade
de, no mı́nino, uma VM para colocar o Catálogo e o Game State no ambiente. Após
isso, as VMs que possuem as regras de negócios e que vão responder as solicitações dos
jogadores podem ser colocadas à disposição na nuvem.
Quando uma VM, que possui o Monitor e o Game Thread, é iniciada, essa VM
se registra no Catálogo e estabelece uma sessão com o Game State. Os esquemas de
banco de dados do Catálogo e Game State podem ser visualizados na Figura 2. Como
podemos observar na figura, o Catálogo possui duas tabelas para guardar os estados das
VMs do ambiente e uma tabela para armazenar os estados das requisições dos jogadores.
A tabela VM ACTIVE tem como objetivo persistir as informações de localização de
cada VM e sua configuração, uma vez que o ambiente em nuvens pode possuir recursos
de hardware heterogêneos. Já a tabela VM STATE tem a responsibilidade de atualizar
as informações sobre o uso de recursos em cada VM. Essas informações são obtidas por
meio do componente Monitor que está contido em cada VM, a qual possui as regras de
negócio do jogo. Lembramos que estas informações são importantes para dar suporte à
 VM_STATE VM_ACTIVE
REQUESTS_STATE
PK vm_id PK vm_id
PK vm_id GLOBAL_STATE
PK timestamp host
PK timestamp PK variable_id
cpf_free port
request_type variable_value
memory_free memory_size
response_time last_update
disk_free disk_size

socket_connections

Figura 2. Esquema do Catálogo e o do Game State

tomada de decisão quando nosso modelo de qualidade não estiver sendo cumprido, ou
seja, o SLA.
Na Figura 2, também, é exposto um esquema de banco de dados que reflete o es-
tado global do jogo. Uma tabela, denominada GLOBAL STATE, foi implementada para
gerenciar as variáveis globais do jogo. A ideia é que os vários Game Thread manipu-
lem essas variáveis e que a manipulação seja visı́vel por toda a nuvem. Neste sentido,
podemos ter várias cópias de VMs para servir de regras de negócio, já que as regras são
estáticas. Com isso, implementamos uma maior disponibilidade e escalabilidade para a
nossa arquitetura. É válido ressaltar que o acesso ao Game Thread é feito via esquema
de transação para evitar anomalias de acesso concorrente.
Quando a requisição de um jogador chega em nosso servidor, o componente Ba-
lanceador de Carga intercepta e decide para qual VM irá responder a essa requisição.
Para isso, o Balanceador de Carga consulta informações sobre os estados das VMs e
dos tempos de resposta de todas as requisições. Essas informações estão disponı́veis no
Catálogo. O critério de decisão é repassar a requisição para a VM que possui maior
tempo livre de CPU, memória disponı́vel e que esteja atendendo a menos usuários na-
quele momento. Lembramos que a tabela VM STATE guarda o número de conexões
ativa em cada VM. Neste sentido, fazemos com que a VM que esteja menos sobrecarrega
atenda à solicitação de um dado jogador.

2.3. Estudo de Caso

Para conduzir nosso estudo de caso, implementamos um subconjunto de regras do jogo
bomberman produzido pela Nintendo [Nintendo 2013]. Nossa implementação, doravante
chamada de Bomber Cloud, assim como no original, só aceita no máximo cinco joga-
dores. Ao contrário do original, o Bomber Cloud não possui itens que aumentam o
desempenho do jogador. O jogador dispõe de um número fixo de bombas; quando as
bombas explodem, outras podem ser jogadas. Quando uma bomba atinge um jogador,
este está eliminado do jogo. O jogo acaba quando há, apenas, um jogador sobrevivente.
O jogo foi implementado utilizando-se a linguagem Java. Como nosso objetivo é
mostrar um modelo de implementação, optamos por desenvolver as interfaces do jogador,
utilizando o esquema gráfico Swing do Java. Essa interface se comunica com a nuvem
por meio da tecnologia Java Socket da linguagem. É válido ressaltar que a interface do
 Figura 3. Seleção do personagem

Bomba Boneco
id : integer id : integer
duracao : long x : integer
x : integer y : integer
y : integer imagem : string
host : string
port : integer
bomba : List<Bomba>
Mapa - void mover(int, int)

id : integer
inicioJogo : long Bloco
terminoJogo : long
id : integer
boneco : List<Boneco>
parede : List<Parede> x : integer
obstaculo : List<Obstaculo> y : integer
bomba : List<Bomba> imagem : string
- void adicionarBloco(Parede)
- void adicionarBloco(Obstaculo)
- void adicionarBomba(Boneco,
int, int) Parede Obstaculo
- void removerBoneco(Boneco)
- void moverBoneco(Boneco, int, invisivel : boolean ativo : boolean
int) - void invisibilidade(boolean) - void mudarEstado(boolean)
- void removerBomba(Bomba,
Boneco, int, int)

Figura 4. Diagrama de Classes do protótipo do estudo de caso

jogador só serve como meio para submissão de requisições e exibição das respostas que
foram processadas na nuvem. A Figura 3, lado esquerdo, exibe a tela inicial do jogador.
Nesta tela o jogador pode escolher seu avatar, ou melhor, seu personagem no jogo. É
válido ressaltar que o jogo não permite dois jogadores com o mesmo avatar. A Figura
3, lado direito, mostra o comportamento da tela inicial quando um avatar é selecionado.
Além disso, essa mesma tela mostra que os outros avatares já foram selecionados por
outros jogadores que estão em uso. Após a seleção do avatar, o botão “Iniciar Partida” é
habilitado.
Na nuvem, as regras de negócio foram construı́das utilizando-se a linguagem Java.
Para o armazenamento dos dados do estado global do jogo e da nuvem, optamos por
utilizar o PostgreSQL [PostgreSQL 2013] como gerenciador de banco de dados. Nele,
implantamos o Catálogo e o Game State. A Figura 4 expressa o diagrama de classes do
nosso estudo de caso, ou seja, as classes que foram implementadas no Game Thread. Já a
 Figura 5. Jogo em andamento

Figura 5, por sua vez, apresenta um cenário onde, simultanemente, estão cinco jogadores
interagindo no servidor do estudo de caso.

3. Material e Método de Avaliação

Neste seção expomos nossa metodologia de avaliação. Para isso, utilizamos nosso estudo
de caso para conduzir a experimentação. Um ambiente experimental foi especificado e a
avaliação será feita na perspectiva do desempenho alcançado pela elasticidade mediada
pelo modelo de qualidade imposto ao nosso estudo de caso. Avaliamos nosso trabalho
aumentando o número de usuários no jogo e a taxa de requisições por jogador. Por fim,
observamos o comportamento da nuvem diante das imposições de QoS.

3.1. Ambiente
Para o ambiente de experimentação utilizamos o OpenNebula [OpenNebula 2013] como
estratégia de gestão de nuvem. Foi criada uma VM com 4 VCPU, 4GB de RAM e 50
GB de disco. Essa VM foi utilizada para fazer a gestão dos componentes Catálogo e
Game State. Uma imagem de VM foi feita para acelerar o processo de provisionamento
de novas VM. Nesta imagem foi colocado uma versão do Sistema Operacional Ubuntu
12.04 LTS, OpenJDK 7 e os componentes Game Thread e Monitor. Preliminarmente,
duas VMs foram iniciadas com a instalação descrita na imagem. Cada uma destas VMs
possui 2 VCPU, 2 GB de RAM e 30 GB de disco.
Para simular as jogadas, simultâneas, utilizam-se de no máximo cinco jogado-
res. Nós implementamos uma aplicação baseada em Threads, onde cada Thread possui
as mesmas interfaces de comunicação com o jogo, ou seja, representa um jogador inte-
ragindo com o servidor na nuvem. Nesta aplicação, podemos especificar o número de
operações de jogadas por unidade de tempo e a quantidade de Threads. Com isso, temos
como objetivo, simular uma carga de trabalho no jogo. Basicamente, foram agregadas
as operações de mudança de localização do avatar e a adição de bombas. Para que um
jogador não seja eliminado facilmente, desabilitamos o impacto de bombas nos jogadores.

3.2. Resultados Experimentais

Para implementarmos nossos experimentos voltados para a categoria de desempenho, re-
alizamos dois experimentos. Um, aumentando a taxa da carga de trabalho, ou seja, o
número de requisições, por segundo, para cada usuário. Já no segundo, mostramos o
desempenho da nossa proposta com o aumento do número de jogadores. Em ambos os
experimentos, fixamos o SLA como tempo de resposta médio, para as requisições dos
usuários, em no máximo 0.5 segundo. Para o primeiro experimento utilizamos nosso es-
tudo de caso com 5 conexões simulando os jogadores. A Tabela 1 apresenta os parâmetros
de tempo e taxa da carga de trabalho utilizados neste experimento.

Tabela 1. Parâmetros utilizados para o experimento que ilustra o aumento do

número da taxa
Tempo (segundos) Número de operações por segundo
0 – 30 2
31 – 60 4
61 – 90 6
91 – 120 8
121 – 150 10
Tempo de Resposta Médio
(milisegundos)

Taxa (número de operações por segundo)

Figura 6. Aumento do Número da Taxa

A Figura 6 mostra o desempenho da nosso jogo diante do aumento da carga de

trabalho. No ı́nicio do experimento não houve nenhum provisionamento. Só houve pro-
visionamentos no momento em que um SLA foi violado. Quando a taxa passou para 4,
no intervalo de tempo entre 31 e 60 segundos, surgiu a necessidade de provisionar mais
uma VM.
Quando a VM entrou em uso no ambiente, o Balanceador de Carga começou
a usá-la para diminuir a sobrecarga das outras VMs e melhorar QoS, diminuindo as
violações SLA. O resultado deste proviosamento pôde ser observado melhor quando a
taxa aumentou para 6. Enquanto a VM estava sendo provisionada, violações SLA ocor-
reram; quando a nova VM entrou em ação, a qualidade melhorou. Quando a taxa passou
para 8, houve mais violações de SLA; neste momento, uma nova VM foi adicionada ao
ambiente. Com a adição da nova VM, os tempos de resposta médio diminuiram; conse-
quentemente, melhorou a QoS do jogo.

Tabela 2. Parâmetros utilizados para o experimento que ilustra o aumento do

número de jogadores
Tempo (segundos) Número de jogadores ativos
0 – 30 1
31 – 60 2
61 – 90 3
91 – 120 4
121 – 150 5
Tempo de Resposta Médio
(milisegundos)

Número de Jogadores

Figura 7. Aumento do Número de Jogadores

A Tabela 2 mostra as configurações de tempo e número de jogadores que foram

utilizados para demonstrar o comportamento do nosso estudo de caso diante do cresci-
mento do número de jogadores.
A Figura 7 exibe o desempenho do jogo guiado pelo aumento do número de jo-
gadores no ambiente. Como ressaltado, nosso cenário de experimentação iniciou com 2
VMs para processar as regras de negócio do nosso estudo de caso. A taxa, para cada jo-
gador, ficou fixada em 4. O cenário inicial conseguiu manter a QoS com até 2 jogadores.
Quando o terceiro jogador entrou no cenário, houve a necessidade de provisionar uma
nova VM, pois ocorreram violações de SLA. Pode-se observar que, com a existência de 3
VMs, a QoS se manteve com até 4 jogadores. Para não violar SLA com 5 jogadores, foi
necessário o provisionamento de uma quarta VM.

4. Trabalhos Relacionados
[Bezerra et al. 2009] apresentaram modelos para distribuição de jogos distribuı́dos mul-
tijogadores e, por meio destes modelos, descentralizar cargas de trabalho no servidor do
jogo. Os modelos, descritos no trabalho, são voltados para jogos massivos que reque-
rem grande quantidade de recursos do lado servidor. Entretanto, os modelos mostrados
têm como objetivo otimização de infraestrutura do servidor. É dito que um dos modelos
pode comtemplar aspectos de escalabilidade. No entanto, não são apresentados experi-
mentos que comprovem a adição de recursos, o que caracteriza a escalabilidade. Já nossa
estratégia é guiada pela elasticidade para garantia de QoS.
Já [Madeira et al. 2000] demonstram o desenvolvimento de um jogo distribuı́do
multiusuário utilizando Java e CORBA como plataforma de distribuição. Além disso,
o trabalho identifica os problemas e soluções relacionados à construção de aplicações
distribuı́das servindo-se de uma plataforma CORBA. No entanto, o trabalho tem como
foco aspectos de implementação, somente em Java e CORBA, do jogo e de aplicações
deste contexto. O jogo foi construı́do sobre uma arquitetura cliente/servidor. Aspectos
de implementação para sincronização, consistência, inteligência e tráfego de rede são
discutidos. Não são apresentados aspectos de QoS, somente implementação. Nossa pro-
posta, além de contribuir com uma arquitetura e modelo de implementação, apresenta
uma solução escalável para a garantia de QoS e justiça em jogos distribuı́dos deste mesmo
âmbito.
O trabalho proposto por [Cecin and Trinta 2007] mostra uma visão geral de jogos
distribuı́dos multijogadores. Além disso, o trabalho discute as alternativas de modelagem
e desenvolvimento de jogos para estes cenários. Para complementar, é descriminado um
conjunto de interfaces de programação e bibliotecas, em Java, para implementação do
jogo na plataforma cliente-servidor. No entanto, a trabalho tem como objetivo servir
de suporte para que seja implementado um jogo e não apresenta nenhuma avaliação da
proposta. Apesar de se assemelhar ao nosso trabalho, nós propusemos uma arquitetura
com foco na QoS, na elasticidade, com uma arquitetura voltada para nuvem e mostramos
experimentos baseados em um estudo de caso.
[Menezes et al. 2006] discutem a importância das plataformas para o desenvol-
vimento de jogos móveis massivamente multijogadores. Além disso, o trabalho propõe
critérios para avaliar tais plataformas de implementação. Para isso, o trabalho apresenta
um estudo de caso, baseado na tecnologia Java, para guiar a avaliação. No entanto, o tra-
balho não apresenta uma avaliação de desempenho e só propõe um conjunto de serviços
e técnicas para guiar a implementação de tais jogos. Nosso tabalho, além de contemplar
esses requisitos para jogos distribuı́dos multijogadores, exibe o desempenho de um jogo
e o ganho alcançado pelo ambiente de computação em nuvem por meio de experimentos
de QoS.
Em [Brasil 2007] foi descrito a construção de um servidor multijogos que tem
como finalidade a sincronização dos jogadores em uma mesma partida. Para isso, foi
implementado um framework que permita o acesso ao servidor por parte dos jogos e,
também, que possa ser utilizado pelos desenvolvedores dos jogos. A ideia é deixar abs-
trato os detalhes de comunicação, via rede, e que os desenvolvedores implementem seus
jogos focando nas regras de negócio. Contudo, o trabalho não dá suporte à escalabilidade
no servidor de jogos, e seu funcionamento é voltado para a plataforma Java. Além disso,
não é apresentada nenhuma avaliação de desempenho do framework proposto. Nosso tra-
balho não propõe um framework, nós disponibilizamos uma arquitetura para que possa
ser implementada em qualquer linguagem de programação suportada pela plataforma da
nuvem. E, ainda, nossos experimentos são voltados para o desempenho, ponto crucial em
jogos distribuı́dos multijogadores.
Na Tabela 3 apresentamos um comparativo entre os trabalhos elencados durante
a fase de levantamento bibliográfico. Para isso, criamos uma taxonomia para guiar a
comparação. A taxonomia utilizou os seguintes critérios: se o trabalho propõe uma arqui-
tetura ou modelo de implementação, qual o modelo de QoS utilizado, se foi feita alguma
avaliação experimental e se a proposta é independente de tecnologia ou linguagem de
programação.

Tabela 3. Análise comparativa entre os trabalhos relacionados

Trabalhos \Taxonomia Propõe uma Modelo para Possui Portabilidade
arquitetura QoS avaliação para outras
ou modelo experimental tecnologias
[Bezerra et al. 2009] Sim Escalabilidade Não Sim
parcial
[Madeira et al. 2000] Sim Não Sim Não
[Cecin and Trinta 2007] Sim Propõe o uso Não Não
da escalabili-
dade
[Menezes et al. 2006] Sim Escalabilidade Não Não
[Brasil 2007] Não Nenhum Não Não
MILENA Sim Elasticidade Sim Sim

De acordo com nosso levantamento de trabalhos correlatos, existe uma escassez

de ensaios que implementem jogos distribuı́dos multijogadores, com QoS, em ambientes
de computação em nuvem. Os resultados do nosso estudo irão servir de base e ponto
de partida para que desenvolvedores e projetistas de jogos distribuı́dos multijogadores
utilizem a computação em nuvem para o contexto de suas aplicações.

5. Conclusão e Trabalhos Futuros

Este trabalho apresentou o MILENA, uma modelo de implementação para jogos dis-
tribuı́dos multijogadores em ambientes de computação em nuvens. Esta modelo é ori-
entado ao desempenho para agregar QoS e justiça em tais tipos de jogos. Avaliamos o
MILENA por meio de um estudo de caso considerando caracterı́sticas de desempenho
com foco na violação de SLA. Pela análise dos resultados obtidos, foi possı́vel verificar
que o MILENA contempla as caracterı́sticas de implementação de jogos com uma vari-
dade de usuários simultâneos e pode ser utilizado como modelo de implementação, com
QoS, paras jogos em nuvens computacionais.
A principal contribuição deste artigo é fornecer aos projetistas e desenvolvedores
de jogos um modelo de implementação a ser seguido para alcançar QoS em ambientes de
computação em nuvens. O modelo é composto de uma arquitetura padrão e um conjunto
de especificações a serem implementadas. Durante a apresentação dos trabalhos rela-
cionados, podemos perceber as vantagens obtidas, do ponto de vista de QoS, agregada
pela nuvem e sua caracterı́stica de elasticidade. Além disso, o levantamento de tais tra-
balhos reforçam a escassez de propostas, no âmbito de jogos distribuı́dos multijogadores,
que disponibilizem uma arquitetura, avaliem a arquitetura em métricas de desempenho e
sejam portáveis para diversas tecnologias.
Em trabalhos futuros e como alternativa a ser considerada para o nosso Game
State, pretendemos utilizar estrutura baseada em DHT (Distributed Hash Tables)
[Wu et al. 2009]. Essa motivação vem pelo fato de que o DHT oferece, como carac-
terı́sticas, as seguintes vantagens: dados distribuı́dos em múltiplos nós, nós do sistema
mantêm informações sobre seus vizinhos, carga balanceada, buscas percorrem no máximo
O(logN ) nós de sistema e por possuir uma API (Application Programming Interface)
simples para manipulação das informações [Schindelhauer and Schomaker 2005].
Nosso modelo de implementação foi avaliado com um jogo que suporta, no
máximo, cinco jogadores. Outros direcionamentos para investigar uma melhor eficácia
do MILENA é a implementação de um jogo que possua suporte a um número maior de
jogadores. Com isso, será possı́vel avaliar o desempenho da nuvem e sua elasticidade
com uma carga maior de usuários.
Visando aumentar a disponibilidade e o desempenho no acesso ao Catálogo, su-
gerimos implementar uma estratégia de replicação. Para isso, é possı́vel utilizar o Re-
pliC [Sousa and Machado 2012], o qual consiste numa estratégia de replicação de dados
relacionais para ambientes de computação em nuvens mediante a restrição de QoS nas
consultas de manipulação dos dados. Como métricas de monitoramento, o RepliC poderá
utilizar o próprio Catálogo e servir de guia para o nosso Balanceador de Carga pois esse
último é o componente que recebe as requisições dos jogadores.

Referências
Bezerra, C. E. B., Cecin, F. R., and Geyer, C. F. R. (2009). Modelos de suporte distribuı́do
para jogos online maciçamente multijogador. Revista Diálogo.
Brasil, L. d. S. (2007). Suporte ao desenvolvimento de jogos multi-jogador, sem exigência
de tempo real.
Cecin, F. and Trinta, F. (2007). Jogos multiusuários distribuı́dos. In Simpósio anual da
Comissão Especial de Jogos e Entretenimento Digital da SBC, SBGAMES ’07.
Coutinho, E. F., Sousa, F. R., Gomes, D. G., and Souza, J. N. (2013). Elasticidade em
computação na nuvem: Uma abordagem sistemática. SBRC, pages 215–258.
Madeira, C. A. G., Araújo, A. C. M., Macedo, H. T., Andrade, R. d. C., Cavalcanti,
D. A. T., Ferraz, C. A. G., and Ramalho, G. L. (2000). Netmaze: um jogo de ação
multimı́dia distribuı́do. In Simpósio Brasileiro de Sistemas Multimı́dia e Hipermı́dia
(SBMIDIA ’2000), SBMIDIA ’00.
Menezes, A., Silva, C. E., Arraes, D., Pedrosa, D., Brayner, F., Trinta, F., Wanderley,
I., Machado, M., Borges, R., and Ramalho, G. (2006). Uma Plataforma para Jogos
Móveis Massivamente Multiusuário. In Simpósio anual da Comissão Especial de Jo-
gos e Entretenimento Digital da SBC, SBGAMES ’06.
Moreno, C., Tizon, N., and Preda, M. (2012). Mobile cloud convergence in gaas: A
business model proposition. 2013 46th Hawaii International Conference on System
Sciences, 0:1344–1352.
Nintendo (2013). Nintendo Official Site: Games. http://www.nintendo.com/
games.
OpenNebula (2013). OpenNebula: Flexible Enterprise Cloud Made Simple. http:
//www.opennebula.org.
PostgreSQL (2013). PostgreSQL: The world’s most advanced open source database.
http://www.postgresql.org.
Schindelhauer, C. and Schomaker, G. (2005). Weighted distributed hash tables. In Proce-
edings of the Seventeenth Annual ACM Symposium on Parallelism in Algorithms and
Architectures, SPAA ’05, pages 218–227, New York, NY, USA. ACM.
Sousa, F. R. C. and Machado, J. C. (2012). Towards elastic multi-tenant database replica-
tion with quality of service. In Proceedings of the 2012 IEEE/ACM Fifth International
Conference on Utility and Cloud Computing, UCC ’12, pages 168–175, Washington,
DC, USA. IEEE Computer Society.
Sousa, F. R. C., Moreira, L. O., and Machado, J. C. (2009). Computação em Nuvem: Con-
ceitos, Tecnologias, Aplicações e Desafios. In: MOURA, R. S. (Org.) ; SOUZA, F. V.
(Org.) ; OLIVEIRA, A. C. (Org.). Escola Regional de Computação (Ceará, Maranhão
e Piauı́, ERCEMAPI 2009, 1. ed. EDUFPI, Piauı́.
Sousa, F. R. C., Moreira, L. O., Santos, G. A. C., and Machado, J. C. (2012). Quality of
service for database in the cloud. In Leymann, F., Ivanov, I., van Sinderen, M., and
Shan, T., editors, CLOSER, pages 595–601. SciTePress.
Wu, D., Tian, Y., and Ng, K.-W. (2009). Resilient and efficient load balancing in distri-
buted hash tables. J. Netw. Comput. Appl., 32(1):45–60.