UNIVERSIDADE FEDERAL DO PIAUÍ - UFPI

CENTRO DE CIÊNCIAS DA NATUREZA

COORDENAÇÃO DE ESTÁGIO DO CURSO DE
BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

RELATÓRIO DE ESTÁGIO CURRICULAR

Conexão Entre Elementos de Jogos Massivos Para Múltiplos Jogadores
Online

Ítalo Mendes da Silva Ribeiro

Teresina-PI
Fev. 2007
UNIVERSIDADE FEDERAL DO PIAUÍ - UFPI
CENTRO DE CIÊNCIAS DA NATUREZA
COORDENAÇÃO DE ESTÁGIO DO CURSO DE
BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

RELATÓRIO DE ESTÁGIO CURRICULAR

Conexão Entre Elementos de Jogos Massivos Para Múltiplos Jogadores
Online

Ítalo Mendes da Silva Ribeiro

Relatório apresentado ao Curso de

Bacharelado em Ciência da
Computação da Universidade Federal
do Piauí - UFPI, para estudar a Conexão
Entre Elementos de Jogos Massivos
Para Múltiplos Jogadores Online.

Teresina-PI
Fev. 2007
 IDENTIFICAÇÃO

ESTAGIÁRIO:_Italo Mendes da Silva Ribeiro_

MATRIC.Nº_ 03N10187 _

ANO.: __2007__ PERÍODO.: ____8º____ CURSO __Computação__

DOCENTE ORIENTADOR: ___Magno Alves dos Santos ___

Dedico este trabalho primeiramente a Deus, meus pais,
e meu supervisor do estagio que me ajudou durante a
elaboração do mesmo.
 AGRADECIMENTOS

Agradeço:

• A Deus;

• A meus pais;

• ao professor orientador campo que colaborou para meu aprendizado com

orientações e correções ns atividades desenvolvidas;

• aos colegas de turma, em geral, e aos membros dos fóruns aos quais discute
sobre o assunto.
 LISTA DE ILUSTRAÇÕES

FIGURA 1 – Técnicas para transmissão de mensagens: (a) broadcast, (b) unicast,

(c) multicast 29
FIGURA 2 – Arquiteturas de comunicação para jogos. (a) Ponto a ponto; (b)
Cliente/Servidor; (c) Replicação de Servidores; (d) Grid de servidores. 33
FIGURA 3 – Arquitetura hibrida 36
FIGURA 4 – Exemplo de um estado em que o jogo pode se encontrar num dado
instante. 41
FIGURA 5 – Algoritmo time warp (GVT – Global Virtual Time ou Tempo
do jogo) 43
FIGURA 6 – Terminologia TSS 45
FIGURA 7 – Execução correta 46
FIGURA 8 – Comando atrasado 46
FIGURA 9 – Detecção do atraso 47
FIGURA 10 – Rollback 47
 RESUMO

O texto aborda aspectos do desenvolvimento de jogos no que diz respeito a

sua comunicação. É feito uma classificação de ambientes em que os jogos podem ser
disputados, assim como caracteristicas relevantes para a sua implementação em cada
uma delas. Logo após é discutido alguns fatores que são responsaveis pora uma boa
execução de um jogo online. Mais adiante é mostrado algumas tecnicas de
sincronização de eventos, fator determinante para que o jogador não sinta problemas de
atrasos no jogo.
 SUMÁRIO

INTRODUÇÃO 09
1. PROTOCOLOS 11
1.1 TCP 11
1.2 UDP 13
2. JOGOS MULTIUSUARIOS 15
2.1 ESTILO DE JOGOS MULTIUSUARIOS 16
2.2 CENÁRIOS ATUAIS 18
2.2.1 JOGOS MULTIUSUARIOS EM PEQUENA ESCALA 18
2.2.2 JOGOS MÓVEIS MULTIUSUÁRIOS 19
2.2.3 JOGOS CONECTADOS 20
2.2.4 JOGOS MÓVEIS MASSIVAMENTE MULTIUSUÁRIOS 21
2.2.5 JOGOS PERVASIVOS 21
2.2.6 JOGOS BASEADOS EM LOCALIZAÇÃO 22
3. ASPECTOS TÉCNICOS EM JOGOS MULTIUSUÁRIOS 23
3.1 FATORES LIMITANTES PARA JOGOS MULTIUSUARIOS 24
3.1.1 PLATAFORMA FÍSICA 24
3.1.2 PLATAFORMA LÓGICA 25
3.1.3 SEGURANÇA 26
3.2 ASPECTOS RELEVANTES PARA JOGOS MULTIUSUÁRIOS 27
3.2.1 DISTRIBUIÇÃO DE MENSAGENS 27
3.2.2 COMPRESSÃO E AGREGAÇÃO DE MENSAGENS 28
3.2.3 GERENCIAMENTO DE ÁREAS DE INTERESSE 28
3.2.4 DEAD RECKONING 29
3.2.5 ARQUITETURA DE COMUNICAÇÃO 30
4. SINCRONIZAÇÃO 35
4.1 ABORDAGEM CONSERVADORA OU PESSIMISTA(STOP-AND-WAIT) 35
4.1.1 SIMULADOR CONSERVADOR 37
4.1.2 SIMULADOR OTIMISTA 37
4.1.3 SIMULADOR CONSERVADOR RESOLVENDO INTERAÇÕES 38
4.1.4 ROLLBACK E EXECUÇÃO CORRETIVA 39
4.2 TIME WARP 40
4.3 TRILING STATE SYNCHRONIZATION (TSS) 42
5. CONCLUSÃO 46
6. BIBLIOGRAFIA 47
INTRODUÇÃO

Os jogos Massively Multiplayer Online são um dos estilos que mais cresce
atualmente, em especial os do gênero MMORPG (Massively Multiplayer Online Role-
playing Game), em que frequentemente milhares de pessoas estão conectadas ao mesmo
tempo em um servidor, Tal progresso deve-se principalmente ao avanço das tecnologias
de comunicação e ao sucesso da Internet, despertando inclusive um crescente interesse
comercial nestas aplicações. Como exemplo, em 2005 o mercado de jogos multitusuário
online movimentou cerca de 3,4 bilhões de dólares.

Enquanto isso, também evolui e populariza-se cada vez mais a computação

móvel, com a inerente conectividade dos dispositivos móveis resultam em uma oferta
cada vez maior de serviços para esses dispositivos. Nos últimos anos, o aparecimento de
jogos multiusuário online para telefones celulares evidencia o potencial da computação
móvel para a área de entretenimento digital.

Uma das possíveis abordagens permite ao jogador permanecer sempre

conectado ao jogo a partir de seu dispositivo. É uma situação que se contrapõe à
tradicional idéia de jogos multiusuário, na qual jogadores possuem máquinas
estacionárias com grande poder computacional e dispondo geralmente de uma conexão
de alta velocidade. Sendo assim, um jogo específico pode oferecer aos usuários
características interessantes da plataforma para o qual foi desenvolvido: mobilidade,
para o caso de jogos multiusuário móveis, ou uma interface gráfica rica e altamente
interativa, para os jogos de computadores desktop ou consoles de videogame.

O fato de muitos jogadores estarem conectados ao mesmo tempo em um

único servidor causa uma grande quantidade de informações que passa pela rede, em
conexões do tipo cliente/servidor. Isso freqüentemente provoca paradas no jogo
(conhecidas como lag), o que ocasiona frustrações para os usuários e problemas para a
empresa, devido a desistência de jogadores com as péssimas condições do game.

Dessa forma é necessária a implementação de uma rede que possibilite a

troca de informações entre os elementos do jogo sem perda de dados ou paradas na
execução de forma otimizada.
 Serão vistos metodos para a sincronização dos eventos do jogo não ocorram
fora de paridade entre os jogadores, assim como tambem outros fatores que fazem a
diferença para que o jogo ocorra sem problemas.
1. PROTOCOLOS

A estrutura de comunicação de games utiliza estes protocolos para o

transporte de seus dados:

1.1.TCP

O TCP (acrónimo para o inglês Transmission Control Protocol) é um dos

protocolos sob os quais assenta o núcleo da Internet nos dias de hoje. A versatilidade e
robustez deste protocolo tornaram-o adequado para redes globais, já que este verifica se
os dados são enviados de forma correta, na seqüência apropriada e sem erros pela rede.

O TCP é um protocolo do nível da camada de transporte (camada 4) do

Modelo OSI e é sobre o qual assentam a maioria das aplicações cibernéticas, como o
SSH, FTP, HTTP — portanto, a World Wide Web. As características fundamentais do
TCP são:

• Orientado à conexão - A aplicação envia um pedido de conexão para o destino

e usa a "conexão" para transferir dados.
• Ponto a ponto - uma conexão TCP é estabelecida entre dois pontos.
• Confiabilidade - O TCP usa várias técnicas para proporcionar uma entrega
confiável dos pacotes de dados, que é a grande vantagem que tem em relação ao
UDP, e motivo do seu uso extensivo nas redes de computadores. O TCP permite
a recuperação de pacotes perdidos, a eliminação de pacotes duplicados, a
recuperação de dados corrompidos, e pode recuperar a ligação em caso de
problemas no sistema e na rede.
• Full duplex - É possível a transferência simultânea em ambas direcções (cliente-
servidor) durante toda a sessão.
• Handshake - Mecanismo de estabelecimento e finalização de conexão a três e
quatro tempos, respectivamente, o que permite a autenticação e encerramento de
uma sessão completa. O TCP garante que, no final da conexão, todos os pacotes
foram bem recebidos.
• Entrega ordenada - A aplicação faz a entrega ao TCP de blocos de dados com
um tamanho arbitrário num fluxo (ou stream) de dados, tipicamente em octetos.
O TCP parte estes dados em segmentos de tamanho especificado pelo valor
MTU (Maximum Trasmit Unit ou Unidade Máxima de Transmissão). Porém, a
 circulação dos pacotes ao longo da rede (utilizando um protocolo de
encaminhamento, na camada inferior, como o IP) pode fazer com que os pacotes
não cheguem ordenados. O TCP garante a reconstrução do stream no
destinatário mediante os números de sequência.
• Controle de fluxo - O TCP usa o campo janela ou window para controlar o
fluxo. O receptor, à medida que recebe os dados, envia mensagens ACK
(Acknowledgement), confirmando a recepção de um segmento; como
funcionalidade extra, estas mensagens podem especificar o tamanho máximo do
buffer no campo (janela) do segmento TCP, determinando a quantidade máxima
de bytes aceita pelo receptor. O transmissor pode transmitir segmentos com um
número de bytes que deverá estar confinado ao tamanho da janela permitido: o
menor valor entre sua capacidade de envio e a capacidade informada pelo
receptor.

Durante a fase de transferência o TCP está equipado com vários

mecanismos que asseguram a confiabilidade e robustez: números de seqüência que
garantem a entrega ordenada, código detector de erros (checksum) para detecção de
falhas em segmentos específicos, confirmação de recepção e temporizadores que
permitem o ajuste e contorno de eventuais atrasos e perdas de segmentos.

Se pode observar pelo cabeçalho TCP, existem permanentemente um par de

números de seqüência, doravante referidos como número de seqüência e número de
confirmação (ACKnoledgement). O emissor determina o seu próprio número de
seqüência e o receptor confirma o segmento usando como número ACK o número de
seqüência do emissor. Para manter a viabilidade, o receptor confirma os segmentos
indicando que recebeu um determinado número de bytes contíguos. Uma das melhorias
introduzidas no TCP foi a possibilidade do receptor confirmar blocos fora da ordem
esperada. Esta característica designa-se por selective ACK, ou apenas SACK.

A reassemblagem ordenada dos segmentos é feita usando os números de

seqüência, de 32 bit, que reiniciam a zero quando ultrapassam o valor máximo, 2 31-1,
tomando o valor da diferença. Assim, a escolha do ISN (Primeiro número da seqüência
usado em uma conexão) TCP torna-se vital para a robustez deste protocolo.

O campo checksum permite assegurar a integridade do segmento. Este

campo é expresso em complemento para um consistindo na soma dos valores (em
complemento para um) da trama. A escolha da operação de soma em complemento para
um deve-se ao fato de esta poder ser calculada da mesma forma para múltiplos desse
comprimento - 16 bit, 32 bit, 64 bit, etc - e o resultado, quando encapsulado, será o
mesmo. A verificação deste campo por parte do receptor é feita com a recomputação da
soma em complemento para um que dará zero caso o pacote tenha sido recebido intacto.

Esta técnica (checksum), embora muito inferior a outros métodos detectores,

como o CRC, é parcialmente compensada com a aplicação do CRC ou outros testes de
integridade melhores ao nível da camada 2, logo abaixo do TCP, como no caso do PPP e
Ethernet. Contudo, isto não torna este campo redundante: com efeito, estudos de tráfego
revelam que a introdução de erro é bastante freqüente entre hops protegidos por CRC e
que este campo detecta a maioria desses erros.

As confirmações de recepção (ACK) servem também ao emissor para

determinar as condições da rede. Dotados de temporizadores, tanto os emissores como
receptores podem alterar o fluxo dos dados, contornar eventuais problemas de
congestão e, em alguns casos, prevenir o congestionamento da rede. O protocolo está
dotado de mecanismos para obter o máximo de desempenho da rede sem a congestionar
— o envio de tramas por um emissor mais rápido que qualquer um dos intermediários
(hops) ou mesmo do receptor pode inutilizar a rede. São exemplo a janela deslizante, o
algoritmo de início-lento

1.2.UDP

O UDP dá às aplicações acesso direto ao serviço de entrega de datagramas,

como o serviço de entrega que o IP dá. O UDP é pouco confiável, sendo um protocolo
não orientado para conexão. O "pouco confiável" significa que não há técnicas no
protocolo para confirmar que os dados chegaram ao destino corretamente.

O UDP é um acrónimo do termo inglês User Datagram Protocol que

significa protocolo de datagramas de utilizador (ou usuário). O UDP faz a entrega de
mensagens independentes, designadas por datagramas, entre aplicações ou processos,
em sistemas host. A entrega é não confiável, porque os datagramas podem ser entregues
fora de ordem ou até perdidos. A integridade dos dados pode ser gerida por um
"checksum" (um campo no cabeçalho de checagem por soma).
 Os pontos de acesso do UDP são geralmente designados por "Portas de
protocolo" ou "portas" ou até "portos", em que cada unidade de transmissão de dados
UDP identifica o endereço IP e o número de porta do destino e da fonte da mensagem,
os números podendo ser diferentes em ambos os casos.

O UDP é o protocolo irmão do TCP. A diferença básica entre os dois é que o

TCP é um protocolo orientado à conexão, que inclui vários mecanismos para iniciar e
encerrar a conexão, negociar tamanhos de pacotes e permitir a retransmissão de pacotes
corrompidos. No TCP tudo isso é feito com muito cuidado, para garantir que os dados
realmente cheguem inalterados, apesar de todos os problemas que possam existir na
conexão.

O UDP por sua vez é uma espécie de irmão adolescente do TCP, feito para
transmitir dados pouco sensíveis, como streaming de áudio e vídeo. No UDP não existe
checagem de nada, nem confirmação alguma. Os dados são transmitidos apenas uma
vez, incluindo apenas um frágil sistema de CRC. Os pacotes que cheguem corrompidos
são simplesmente descartados, sem que o emissor sequer saiba do problema.

A idéia é justamente transmitir dados com o maior desempenho possível,

eliminando dos pacotes quase tudo que não sejam dados em si. Apesar da pressa, o UDP
tem seus méritos, afinal você não gostaria que quadros fantasmas ficassem sendo
exibidos no meio de um vídeo, muito menos se isso ainda por cima causasse uma
considerável perda de performance.

Em geral, os programas que utilizam portas UDP recorrem também à uma

porta TCP para enviar as requisições de dados a serem enviados e também para checar
periódicamente se o cliente ainda está online.

Os protocolos de games tem como característica comum, uma grande

quantidade de mensagens enviadas do cliente para o servidor, que este por sua vez tem a
tarefa de em muitos casos realizar um processo de validação nas mesmas para
posteriormente repassar a todos ou para um pequeno grupo de jogadores conectados a
ele.

2. JOGOS MULTIUSUÁRIO
 Jogos multiusuário são simulações de ambientes onde os jogadores estão
inseridos realizando ações, interagindo com outros jogadores e com os elementos do
ambiente, para completar algum objetivo.

Este mundo virtual tipicamente constitui-se do mapa do jogo, personagens

controlados por diferentes jogadores, objetos mutáveis (alimentos, ferramentas, armas,
construções, dentre outros), além de personagens controlados pelo computador,
chamados de Non-player Characters (NPC), que servem como ajudantes ou guias para
realizar determinadas tarefas, como quests, que são missões a serem cumpridas pelos
jogadores para conseguir algum item ou aumentar seu level, por exemplo.

Cada elemento do jogo possui um estado associado, composto por atributos

como sua posição no mundo virtual e um conjunto de propriedades específicas de cada
jogo, e de cada elemento como habilidades, quantidade de vida, de mana, itens
possuídos, peso atual carregado. O conjunto dos estados de cada elemento em um dado
momento reflete o estado global do jogo. Este estado é visualizado, compartilhado e
modificado de acordo com ações dos jogadores presentes no jogo. Em geral, um jogador
pode realizar três tipos de ações: a mudança de posição de seu personagem, interações
com objetos do mundo virtual e interações com outros jogadores, estando cada uma
destas ações sujeita às regras determinadas especificamente pelo projeto e modelagem
do jogo.

Mesmo sendo aplicações de espaço compartilhado, os jogos multiusuário

possuem alguns aspectos que os diferenciam, que são a competição e a tolerância a
trapaças pelos usuários. O primeiro é conseqüência direta dos jogos, a competição entre
os jogadores, buscando a vitória, através de seus atos é a sua essência. E a tolerância a
falhas é uma conseqüência do aspecto anterior, pois procurando levar vantagem de
forma rápida em relação aos outros jogadores, muitos buscam formas de burlar as regras
do jogo.

2.1.ESTILO DE JOGOS MULTIUSUÁRIOS

Jogos multiusuário podem ser classificados sob diferentes aspectos. Em

relação ao andamento da simulação, um jogo de tempo real é aquele onde o jogador
envia comandos de forma independente à passagem do tempo da simulação. Em outras
palavras, os jogadores realizam ações sem uma ordem pré-definida, enviando dados
continuamente e modificando concorrentemente o estado do jogo. Em um jogo baseado
em turnos, por sua vez, cada participante tem bem definido o seu momento de realizar
uma jogada, havendo uma alternância entre as ações de cada jogador. Um exemplo é o
jogo de xadrez, no qual a partida não avança até que o jogador da vez realize a sua
jogada.

O turno também pode representar a quantidade máxima de ações que um

jogador pode executar nesse espaço de tempo, evitando assim que ele sobrecarregue o
servidor com muitos comandos ou que ele seja mais privilegiado por possuir um
computador ou uma rede de conexão melhor que os outros jogadores.

Jogos multiusuário de tempo real geralmente impõem restrições quanto ao

atraso máximo entre o envio de um comando pelo jogador e a efetivação do comando
no jogo. A influência deste atraso na percepção do andamento do jogo varia de pessoa
para pessoa, mas geralmente pode-se estabelecer um valor representativo para o atraso
máximo tolerado em um jogo multiusuário. Para jogos representados graficamente
como ambientes bidimensionais ou tridimensionais, este atraso é dependente da
perspectiva do usuário e da reatividade necessária para conservação da jogabilidade, e
da ação realizada. Baseado nesta perspectiva, três estilos principais de jogos são
definidos: jogos em primeira pessoa, o de jogos de estratégia em tempo real, conhecidos
também como RTS (Real Time Strategy) e os MMOG online.

Nos jogos de estilo em primeira pessoa o jogador simula a visão do próprio

personagem controlado no jogo. Boa parte destes jogos são jogos de tiro, chamados
então First Person Shooter (FPS), como exemplo temos Counter Strike, Quake, Doom,
American Army, etc. Esta perspectiva dá ao jogador uma intensa sensação de imersão
no jogo, exigindo reflexos rápidos e tempo de respostas quase instantâneo dessa forma
as ações devem ser transmitidas e executadas o mais breve possível pelo jogo. Com isso
essas aplicações utilizam o protocolo UDP para a comunicação entre seus elementos,
sendo que não existe confirmação de chegada de um determinado pacote, pois o tempo
de envio e recebimento de resposta é muito grande para ser utilizado nessas aplicações.

Mesmo que exista perda de pacotes, ela pode ser desprezada em numero
pequeno, pois os pacotes que sucedem o perdido podem revelar o que o pacote não
recebido iria fazer(dead reckonig), ou então essa perda pode ate não ser percebida
durante o jogo.

Nos jogos de estrategia em tempo, cada jogador controla um conjunto de

unidades independentes, tomando o papel de um comandante ou chefe de uma raça ou
exército. O jogador instrui suas unidades (como por exemplo: soldados, veículos,
trabalhadores, dentre outros) nas ações que cada unidade deve realizar como obtenção
de itens e suprimentos para a evolução de seus exércitos, atacarem inimigos ou
deslocar-se para determinadas áreas do mapa. Os jogadores competem entre si para
destruir o exército do inimigo ou capturar algum objeto vital no mundo virtual. Nestes
jogos, o jogador visualiza o jogo como em uma tomada aérea do mundo virtual e suas
ações não necessitam de tempos de resposta tão imediatos quanto jogos FPS.

O MMOG tem como característica principal a grande quantidade de

jogadores conectados ao game ao mesmo tempo, em alguns jogos chegando a ter certa
de 7000 pessoas conectadas ao mesmo tempo em um servidor. A maioria destes jogos é
do tipo Role Playing Game (RPG), caracterizados por uma narrativa mais complexa, no
qual cada jogador assume o papel de um personagem pertencente a uma dentre
diferentes categorias, cada uma com características próprias, e deve cumprir missões
como encontrar objetos ou destruir inimigos. RPGs focam no comportamento e na
evolução de cada personagem, a partir do acúmulo de riquezas, itens e experiências
adquiridas durante o cumprimento de suas missões.

O modelo de negócios para MMOGs difere dos jogos tradicionais. Um

MMOG é encarado como um serviço, oferecido pela empresa responsável pela infra-
estrutura do jogo, cobrado periodicamente de cada usuário pelo seu acesso. Certas
vezes, o software cliente é disponibilizado gratuitamente para atrair ainda mais
jogadores. Alguns dos mais populares MMOGs, como os jogos da série Ragnarok,
Lineage e o World of Warcraft ultrapassam 1,5 milhões de usuários. Porém, apesar de
seu sucesso e potencial, MMOGs apresentam uma série de problemas ainda a serem
solucionados, principalmente no que diz respeito a questões sobre escalabilidade e
custos associados à manutenção da infra-estrutura necessária ao funcionamento do jogo.

Neste tipo de jogo as ações normalmente não são criticas podendo haver um
pequeno atraso na execução destas, mas existe uma necessidade de haver um
processamento de validação no servidor para evitar que jogadores maus intencionados
se aproveitem de falhas no jogo para tirar proveito. Devido a grande quantidade de
pessoas conectadas ao game ao mesmo tempo, existe uma restrição, selecionando para
quem deve ir determinado pacote. Normalmente o protocolo utilizado também é o UDP,
mas com a implementação de alguns elementos do TCP, como mensagens de
confirmação, de ordem do recebimento dos pacotes, entre outras.

2.2.CENÁRIOS ATUAIS

Esta seção apresenta diferentes cenários de utilização de jogos multiusuário.

Eles ilustram a evolução tecnológica ocorrida desde o surgimento das primeiras
experiências de jogos multiusuário em redes locais até a utilização de dispositivos
móveis como plataforma para tais jogos nos dias atuais.

Estes cenários levam em conta fatores como o número de jogadores, a

utilização de dispositivos móveis e o uso de informações de contexto, especialmente a
localização física do jogador. Neste levantamento são considerados apenas jogos de
tempo real para computadores pessoais e dispositivos móveis, e que apresentem alguma
interface gráfica não textual 2D ou 3D.

2.2.1.JOGOS MULTIUSUÁRIOS EM PEQUENA ESCALA

Estes jogos representam a primeira geração de jogos multiusuário para

computadores pessoais. Seu surgimento aconteceu em meados da década de noventa,
como conseqüência da popularização dos computadores pessoais, do surgimento da
multimídia digital e da massificação das redes de computadores. Jogos para PCs até
então eram aplicações tipicamente monousuário. Em 1993, porém, a IdSoftware lançou
o jogo Doom, que revolucionou o mundo dos jogos para computador, tanto por ser um
dos primeiros FPSs lançado no mundo, mas principalmente por introduzir o conceito de
jogos multiusuário em redes de computadores.

Nestes jogos, a máquina de um jogador atua como servidor onde a

simulação é executada. Esta máquina é responsável por iniciar uma sessão de jogo, a
partir da qual jogadores se conectam, permitindo sua interação. Outra característica
destes jogos é seu número limitado de jogadores, chegando no máximo a algumas
dezenas de usuários em uma única sessão, devido as limitações das redes e dos
computadores na época.

Com o surgimento da Internet, estes jogos permitiram que jogadores de

diferentes partes do mundo pudessem participar de uma mesma sessão através da rede
mundial de computadores. Jogos multiusuário começaram desta maneira, a criar uma
cultura própria. Comunidades foram formadas em torno dos jogos mais populares, como
Quake, Starcraft, Warcraft e Diablo, debatendo estratégias, assuntos correlatos ao jogo,
campeonatos e outros eventos. Atualmente, tais jogos representam boa parte dos jogos
multiusuário disponíveis para PC, servindo de mola propulsora para o surgimento de
estabelecimentos especializados em oferecer suporte adequado em jogos multiusuário,
as chamadas lan-houses.

2.2.2.JOGOS MÓVEIS MULTIUSUÁRIOS

A computação móvel é o cenário mais recente de aplicação de jogos

multiusuário. Este cenário é conseqüência de diversos fatores. A popularização de
dispositivos móveis, como telefones celulares e computadores de mão, o aumento do
poder computacional destes dispositivos e o surgimento de plataformas abertas como
Java ME permitiu a criação de aplicações simples para tais dispositivos, principalmente
jogos monousuário, chamados então “jogos móveis”. O número crescente de
tecnologias de comunicação sem fio como GPRS, Bluetooth e Wi-Fi (802.11)
aproximam cada vez mais dispositivos móveis das redes de computadores tradicionais.
Seguindo esta evolução, a inclusão do aspecto multiusuário aparece como conseqüência
natural para jogos móveis.

Este processo evolutivo segue os passos dos jogos em computadores

pessoais, onde jogos multiusuário surgiram após o amadurecimento e proliferação das
redes de computadores tradicionais. De fato, o uso da tecnologia de comunicação acaba
sendo um fator determinante no projeto de um jogo multiusuário móvel. Redes de
operadoras de telefonia móvel utilizam tecnologias que costumam apresentar latência
elevada e alto grau de intermitência na conexão do usuário. Além destes problemas
técnicos, existem questões de mercado ainda em aberto, como o modelo de tarifação a
ser utilizado entre empresas desenvolvedoras de jogos, distribuidores e operadoras. Por
tais motivos, a utilização da rede limita-se a jogos não tão interativos, como jogos em
turno, como por exemplo, Batalha Naval e Xadrez.

Em relação às redes espontâneas (ad-hoc) ou redes locais sem fio, Wireless

Local Área Networks (WLAN), os problemas de latência e intermitência são atenuados,
permitindo jogos mais interativos. Contudo, eles oferecem suporte a um número
limitado de usuários, devido às restrições das tecnologias utilizadas e abrangência de
alcance destas redes. Apesar das deficiências de cada tecnologia, os resultados da
implantação de jogos
móveis multiusuário são promissores. Telefones celulares são conectados
por natureza, estão sempre perto de seus usuários e podem ser utilizados em
praticamente todo lugar e a todo momento. A penetração destes dispositivos na
população mundial faz com que estas aplicações possam revolucionar a indústria do
entretenimento digital, atingindo uma audiência até então inimaginável, com receitas
igualmente proporcionais.

2.2.3.JOGOS CONECTADOS

Jogos Conectados (Connected Games) aparecem como uma alternativa para

criação de jogos multiusuário em dispositivos móveis mesmo em face aos problemas de
conexão de redes sem fio. Nestes jogos, a jogabilidade básica não requer uma conexão
permanente com outras entidades, como servidores ou outros jogadores, mas
funcionalidades suplementares são acessadas através de uma rede. Exemplos de funções
possíveis é a publicação da pontuação dos jogadores ao final de cada partida ou o
download de novos níveis de dificuldade ou itens do jogo.

Neste caso, não há interação direta entre os jogadores, o que de certa forma
acaba comprometendo o uso do termo “multiusuário” para tal cenário. Porém, a idéia de
jogos
conectados permite que jogadores possam competir indiretamente, como na
publicação das maiores pontuações ou na ativação de níveis mais avançados.

Um exemplo de um jogo conectado desenvolvido no Brasil é o “Meu Big

Brother”, onde cada jogador escolhe um personagem associado a um dos participantes
do conhecido reality show de televisão para controlar. Cada jogador deve manter seu
personagem limpo, bem-humorado, alimentado, dando presentes ou punindo-o quando
ele não estiver se comportando. O jogo interage em tempo real com o programa,
podendo ser influenciado pelos eventos do mesmo. O jogo permite que cada jogador
receba informações sobre o programa, notícias, questionários e enquetes. O desempenho
de cada jogador é enviado para um servidor que estabelece o ranking entre os jogadores.

2.2.4.JOGOS MÓVEIS MASSIVAMENTE MULTIUSUÁRIOS

Jogos móveis massivamente multiusuário, 3MOGs são jogos que utilizam as

redes das operadoras de telefonia celular de modo a permitir o suporte a um alto número
de jogadores. De certa forma, as operadoras possuem um interesse especial nos jogos
multiusuário, pelo potencial de geração de tráfego adicional de dados nas suas redes e
conseqüente aumento da receita. Os problemas decorrentes das infra-estruturas de redes
de telefonia podem ser comuns. No entanto, são atenuados através de projetos
adequados às limitações existentes, como o uso de batalhas por turnos ou retardo na
execução das ações dos jogadores.

Um dos primeiros 3MOGs comerciais foi Samurai Romanesque, lançado no

Japão em 2001. Destaca-se por incorporar uma série de soluções para os problemas de
limitação técnica dos celulares, como a utilização de vários módulos separados que
representam cada fase do ciclo de vida do jogador. Outro 3MOG de destaque é Tibia
Micro Edition, concebido como a versão móvel de um conhecido jogo para PCs.
Permite situações de interação entre jogadores, mesmo com alta latência, através do uso
de esquemas de estimativas.

2.2.5.JOGOS PERVASIVOS

A contínua evolução tecnológica que transforma o cotidiano da sociedade

moderna impulsiona novos tipos de jogos eletrônicos. Um conceito mais recente neste
sentido é o de jogos pervasivos ou jogos ubíquos. Estes jogos aproveitam a visão de
Computação Pervasiva para criar novas formas de interação e entretenimento que vão
além daquelas realizadas em frente a computadores ou consoles de videogame,
permitindo que jogadores desloquem-se e interajam de diferentes formas, através de
diversos dispositivos e tecnologias de comunicação. Seu campo de aplicação é um
ambiente real, como uma sala, um prédio ou uma cidade, de forma semelhante a antigos
jogos tradicionais de crianças (perseguição, captura de bandeira, etc), mas com
acréscimo de serviços computacionais em tempo real.

Estas aplicações combinam o real e o virtual em jogos que aproveitam os

inovadores aparatos tecnológicos para utilizar informações do mundo real como
elemento influente no mundo virtual que compõe o jogo. Os jogos são concebidos com
base em três tecnologias principais: dispositivos móveis, comunicação sem fio e
tecnologias capazes de capturar informações no contexto do mundo real dos jogadores,
particularmente sua localização física.

Muitos dos experimentos relacionados com jogos pervasivos trazem

conceitos de realidade virtual, como utilização de dispositivos como capacetes ou
utensílios que permitem mesclar objetos do mundo virtual na visão dos jogadores. Em
exemplo é o Human Pacman (“Come-Come Humano”) que apresenta uma versão do
conhecido jogo Pacman, mesclando o mundo real com o mundo virtual. Os personagens
do jogo são jogadores que se movem em uma área do mundo real, mapeada em um
mapa virtual. O labirinto e os elementos do jogo são embutidos no mundo real, criando
uma experiência inovadora aos jogadores. A informação do mapa é distribuída através
de uma WLAN por um servidor central. Os movimentos e as posições de cada jogador
são obtidos através de GPS e enviados ao servidor que mantém o estado do jogo. Este
estado é repassado a todos os jogadores. Cada jogador usa um visor que apresenta o
mundo real mesclado com elementos do mundo virtual.

2.2.6.JOGOS BASEADOS EM LOCALIZAÇÃO

Dentre as tecnologias que aparecem como mais promissoras como veículos

de jogos pervasivos estão os telefones celulares, visto que estes são, sem dúvida, a
plataforma mais comum da sociedade moderna. O lançamento de serviços de
localização (LBS, ou Location Based Services) pelas operadoras de telefonia celular
gerou uma busca por aplicações que utilizassem seus recursos e que chamassem a
atenção do mercado consumidor. Assim, foi possível o surgimento de jogos com
características pervasivas via telefones móveis.

Típicos jogos LBS (Location Based Services ou Serviços Baseados em

Localização) oferecem suporte a um número alto de jogadores interagindo com seus
telefones celulares, em batalhas realizadas nas ruas e bairros de uma cidade. As
oportunidades abertas por estes jogos são vastas, em termos de novas oportunidades de
lazer, novos modelos de negócio e suporte a comunicação em grupo para aprendizado,
socialização e atividades culturais. Jogos LBS representam um emergente mercado
comercial para jogos. As primeiras experiências destes jogos ocorreram nos mercados
europeu e asiático, onde a cultura de jogos é mais forte. O primeiro jogo deste tipo foi
Botfighters lançado em 2000 e desenvolvido pela empresa sueca It’s Alive, que foi
posteriormente incorporada por outra empresa sueca chamada DayDream. O jogo
simula batalhas entre robôs nas ruas de uma cidade, e permite o uso de celulares tanto
com tecnologia SMS como Java. Outro exemplo semelhante e de grande sucesso foi
Undercover, lançado em junho de 2003 pela empresa portuguesa YDreams, que teve
cerca de 5000 inscritos nos 3 primeiros dias após o seu lançamento. No Brasil, o
primeiro experimento de um jogo massivo móvel foi Alien Revolt. Através da
tecnologia de localização, o jogo possibilita a localização de jogadores através de um
mapeamento de uma região, como o estado do Rio de Janeiro.

3. ASPECTOS TÉCNICOS DE JOGOS MULTIUSUÁRIO

Sendo aplicações de espaço compartilhado, é fundamental para jogos

multiusuário manter o estado global consistente entre os jogadores. Para isto, as ações
de cada jogador devem ser repassadas entre os jogadores de forma rápida, confiável e
ordenada, de modo a garantir a correta execução dos eventos no jogo. Porém, a
separação física dos componentes e jogadores decorrente da natureza distribuída de
ambientes virtuais em rede impõe obstáculos para a manutenção de um estado global
consistente entre os jogadores.

Desta forma, diversos aspectos como latência, largura de banda,

escalabilidade e segurança têm um impacto significativo sobre as técnicas existentes
para implementação de jogos multiusuário. A seguir são detalhados como tais aspectos
influenciam a implementação de jogos multiusuário em geral, e são também
apresentadas as técnicas mais utilizadas para atenuar o impacto destes problemas.

3.1.FATORES LIMITANTES PARA JOGOS MULTIUSUÁRIO

 Helin[02] aponta três grandes problemas a serem enfrentados por jogos
multiusuário em rede. Primeiramente, a infra-estrutura de rede afeta diretamente o
andamento e consistência do jogo. Em seguida, a arquitetura de comunicação entre
jogadores, servidores e demais componentes criam obstáculos para escalabilidade em
jogos multiusuário. Por fim, a necessidade de garantia de um jogo justo através da
prevenção de trapaça por certos jogadores constitui um problema relevante para jogo
multiusuário. Cada um destes problemas é melhor abordado a seguir:

3.1.1.PLATAFORMA FÍSICA

A plataforma física de suporte ao jogo trata-se da infra-estrutura de rede

utilizada. Esta plataforma apresenta limites com os quais jogos multiusuário devem
conviver, como latência e largura de banda.

Largura de banda é definida como a capacidade de transmissão através de

uma linha de comunicação. Para jogos multiusuário esta medida é de fundamental
importância, uma vez que representa um limitador na quantidade de informação que
pode ser transferida entre os jogadores. Em redes locais, a largura de banda atinge altas
taxas de transmissão, diferentemente da Internet. Além disso, a largura de banda
necessária para um jogo multiusuário depende também do número de jogadores e das
técnicas de distribuição de mensagens utilizadas no jogo.

Por sua vez, latência caracteriza-se pela medida de tempo entre o envio da
mensagem e sua recepção pelo destinatário. Este atraso decorrente da inerente separação
física entre os participantes existe em várias escalas e nunca poderá ser totalmente
eliminado. Para jogos multiusuário, a latência na troca de informações afeta diretamente
a percepção de andamento e continuidade do jogo, influenciando negativamente o nível
de interatividade (ou reatividade) ao qual os jogadores estarão sujeitos. De fato, avanços
em dispositivos multimídia como placas de vídeo e som mais apurados, bem como
monitores de alta resolução, permitiram que a sensação de imersão nos jogos eletrônicos
aumentasse cada vez mais. Porém, para jogos multiusuário, mesmo possuindo o melhor
hardware disponível no mercado, a sensação de imersão será totalmente comprometida
caso o andamento do jogo seja constantemente interrompido por atrasos na troca de
informações entre os jogadores.
 Para aplicações interativas distribuídas, pesquisas mostram que atrasos nas
trocas de dados não devem ultrapassar 200 ms sob pena de afetar a percepção de
continuidade para o usuário. Porém, para jogos multiusuário este número varia de
acordo com o estilo do jogo. Em jogos de estratégia em tempo real, latências de até 350
ms são aceitáveis, contanto que se mantenham estáveis. Entretanto, em jogos de alta
interação e de maior imersão como aqueles em primeira pessoa, a latência média deve
ficar próxima a 100 ms.

Para jogos em turno, o problema da reatividade é mais simples, uma vez que
as ações de cada jogador acontecem em intervalos de tempo controlados e previsíveis.
Porém, a consistência do estado do jogo é imprescindível. Para jogos em tempo real, a
consistência do estado global pode ser relaxada em benefício da reatividade de cada
jogador. Como exemplo, jogadores podem utilizar estimativos (previsões, dead
reckoning) sobre a posição do jogador para permitir um fluxo contínuo no andamento
do jogo, mas isso requer uma maior complexidade no jogo, e que as vezes não traz bons
resultados.

3.1.2.PLATAFORMA LÓGICA

Além das limitações impostas pela infra-estrutura de rede, as arquiteturas de

comunicação (cliente/servidor, ponto a ponto ou clusters de servidores), bem como
arquiteturas de controle e de dados (centralizado, replicado ou distribuído) formam a
plataforma lógica, criando outros fatores limitantes a serem considerados,
principalmente em relação à escalabilidade de um jogo. Enquanto não há muito a ser
feito em relação à plataforma física (a não ser investir em hardware e/ou rede, quando
de sua propriedade), a plataforma lógica assume um papel fundamental para atenuar os
efeitos prejudiciais que a plataforma física pode impor. Um erro lógico pode causar
grande latência no jogo, e pode se passar despercebido inicialmente.

3.1.3.SEGURANÇA

Questões sobre a segurança em jogos multiusuário vêm se tornando uma das

maiores preocupações para os envolvidos no desenvolvimento e manutenção de tais
aplicações. Enquanto para jogos monousuário as maiores preocupações recaem sobre
pirataria, para jogos multiusuário novos problemas surgem. Primeiramente, jogos online
estão sujeitos a problemas como a segurança dos dados confidenciais de seus usuários,
autenticidade e disponibilidade dos sistemas que hospedam o próprio jogo. Estes
problemas são comuns a outros domínios de aplicação como comércio eletrônico ou
agências bancárias na Internet, onde medidas já utilizadas, como criptografia, também
se aplica a jogos multiusuário.

Porém, um segundo problema de segurança é peculiar apenas a jogos online.

Relaciona-se à possibilidade de jogadores trapaceiros utilizarem-se de recursos ou
meios antiéticos no intuito de obter vantagens ilegais sobre os demais jogadores.
Embora o conceito de trapaça já exista e seja tolerável em jogos monousuário, seu efeito
para jogos multiusuário é completamente indesejável. Jogos monousuário permitem que
jogadores utilizem códigos e ferramentas para facilitar a realização de certos objetivos
sem maiores esforços.

Para jogos multiusuário, jogadores trapaceiros criam desequilíbrio,

desencorajando os demais jogadores, principalmente iniciantes, a participarem do jogo
conforme as regras. Num mercado onde o jogador deve ser estimulado a permanecer o
maior tempo possível no jogo, a facilidade de trapacear pode arruinar a viabilidade
comercial de um jogo, pois o jogador conseguindo seus objetivos em um curto espaço
de tempo, irá diminuir o tempo de jogo.

A trapaça em um jogo multiusuário pode ocorrer de várias formas.

Pritchard[06] criou uma primeira classificação para as formas de trapaça existentes em
jogos multiusuário. Para estes tipos de trapaça, é difícil imaginar medidas preventivas,
como diagnosticar trapaça por conivência em que, por exemplo, um administrador de
um site de jogos vende clandestinamente senhas de acesso. Porém, certos mecanismos
podem ser utilizados para dificultar as ações de hackers. Mecanismos tradicionais de
segurança como criptografia, assinaturas digitais e controle de integridade podem ser
bem empregados para jogos online, embora individualmente não possam ser
considerados como soluções definitivas.

Atualmente um dos grandes problemas é o uso de bots, onde um jogador

utiliza um programa o qual se passa pelo jogador. Dessa forma o utilizador do bot pode
continuar no jogo mesmo enquanto esta dormindo, ou mesmo estudando. Isso é uma
forma ilícita de conseguir maior experiência, dinheiro ou itens raros, o que torna o jogo
desigual.
3.2. ASPECTOS RELEVANTES PARA JOGOS MULTIUSUÁRIO

Os conceitos relativos à plataforma lógica impõem limites que devem ser

tratados em níveis mais altos que aqueles que lidam com a plataforma física de um jogo
multiusuário. O uso de diferentes topologias e técnicas de distribuição de mensagens
permite a definição de arquiteturas de comunicação, de controle e dados, que ajudar a
atenuar os efeitos destes limitadores.

3.2.1.DISTRIBUIÇÃO DE MENSAGENS

A largura de banda necessária para um jogo multiusuário depende do

número de jogadores e das técnicas de distribuição de mensagens utilizadas no jogo. A
figura 1 apresenta as principais formas de distribuição das mensagens entre os jogadores
de um jogo multiusuário.

A primeira técnica, conhecida como broadcast figura 1 (a), repassa a

mensagem de um jogador para todos os jogadores presentes na partida. Ao receber uma
mensagem, cabe ao jogador utilizá-la ou descartá-la de acordo com seu conteúdo. Esta
técnica gera uma má utilização da capacidade de transmissão da rede, visto que
mensagens são enviadas para todos os jogadores e podem ser irrelevantes para a
maioria. Este problema acentua-se no caso do aumento de jogadores, criando um sério
problema de escalabilidade e desempenho, devido ao congestionamento da rede para
jogos que utilizem tal abordagem.

Uma segunda técnica, chamada unicast, representada pela figura 1 (b),

determina que cada mensagem possua um único emissor e um único receptor. Embora
mais eficiente que broadcast no envio de mensagens para um único destinatário, torna-
se desinteressante quando há múltiplos destinatários para uma única mensagem, caso
comum na maioria dos jogos multiusuário. Neste cenário, unicast utiliza mensagens
redundantes, fazendo com que novamente haja uma sobrecarga na rede.
 Figura 1 – Técnicas para transmissão de mensagens: (a) broadcast, (b) unicast, (c) multicast

3.2.2.COMPRESSÃO E AGREGAÇÃO DE MENSAGENS

Enquanto a compressão das mensagens diminui o tamanho das mensagens

transmitidas através da redução do número de bits necessários para representar a
informação enviada, a agregação mescla informações de várias mensagens em uma
única mensagem maior, porém diminuindo o overhead gerado com cabeçalhos de
mensagens. Dependendo do tamanho do cabeçalho e do número de mensagens
mescladas, uma economia considerável na largura de banda pode ser alcançada. Com
isso procura-se diminuir o consumo da banda utilizada ao custo de processamentos e
atrasos adicionais pela execução de tais procedimentos.

3.2.3.GERENCIAMENTO DE ÁREAS DE INTERESSE

Dependendo do projeto do jogo, o mundo virtual pode ser dividido em áreas

menores. Nesta subdivisão, as áreas de interesse para um jogador são aquelas próximas
a sua localização dentro do mundo virtual. O conceito de área (ou aura) de interesse
refere-se a parte do mundo com a qual o usuário pode interagir, e conseqüentemente,
que é de seu interesse. O gerenciamento destas áreas permite que os jogadores
expressem seus interesses em subconjuntos de informações do jogo.

Sem esta divisão, o servidor teria que repassar todos os eventos ocorridos no
mundo virtual, ocasionando um alto consumo de largura de banda e tempo de CPU. O
esquema de gerenciamento e filtragem de mensagens pode ser intrínseco (no nível da
aplicação) ou extrínseco (no nível dos protocolos de rede). No primeiro, o filtro utiliza
informações específicas da aplicação para determinar quais nós devem receber uma
mensagem, proporcionado informações bem apuradas a um custo maior de
processamento. Neste esquema, o gerenciamento é tipicamente feito através de uma
divisão do mapa do jogo em regiões menores, onde um jogador só recebe e repassa
informações aos jogadores que estejam na sua mesma região. No segundo caso, os
receptores de uma mensagem são determinados pelos seus atributos de rede, como seu
endereço IP. Multicasting figura 1 (c) é um exemplo de tal esquema.

3.2.4.DEAD RECKONING

Outra forma de atenuar o consumo dos recursos da rede é diminuir a

freqüência de envio de mensagens entre jogadores. Embora a princípio esta abordagem
traga problemas em relação à consistência do jogo, é possível utilizar técnicas de
previsão para diminuir o impacto da ausência de informações de atualização. Para isto,
dead reckoning, técnica navegacional que utiliza estimativas de cálculo para o estado
atual de um objeto a partir de dados anteriores, podem ser utilizadas para diminuir o
tráfego de mensagens e melhorar a reatividade para os jogadores. Neste caso, a
consistência é de certa forma relaxada em benefício de um melhor andamento do jogo.
Dependendo da qualidade dos algoritmos de previsão utilizados, objetos podem ser
postos em posições diferentes da sua real localização. Para correção destes erros é
estabelecida uma tolerância na diferença entre os valores previstos e os valores reais.
Enquanto a diferença se mantiver dentro do valor tolerado, o usuário não envia
informações para os demais jogadores. Caso contrário, as devidas correções são feitas
através de algoritmos de convergência, de modo a eliminar possíveis inconsistências e
tornar imperceptível o erro ao jogador.

Os esquemas de previsão podem basear-se tanto na entrada do jogador

quanto nas últimas informações recebidas do objeto controlado, como direção,
velocidade e aceleração. Para cada jogador, previsões são realizadas em sua máquina
local, de acordo com algoritmos de simulação e entradas realizadas pelo usuário.
Fatores como o valor da tolerância, bem como o estilo do jogo é bastante influentes para
o sucesso de dead reckoning para jogos multiusuário.

3.2.5.ARQUITETURAS DE COMUNICAÇÃO
 A arquitetura de comunicação de um jogo multiusuário baseia-se nas
diferentes formas como os computadores envolvidos em um jogo estão interconectados.
A figura 2 ilustra as mais conhecidas arquiteturas para jogos multiusuário.

A figura 2 (a) apresenta a arquitetura ponto a ponto. Neste modelo, a

topologia de comunicação entre jogadores é formada por um conjunto de nós, onde
todos possuem características iguais em relação ao software necessário para
participação no jogo. Logo, cada nó precisa se comunicar com todos demais
participantes para trocar informações. Como exemplo, para enviar uma mensagem aos
demais jogadores, um jogador realiza um broadcast (ou multicast) de sua mensagem
para cada participante do jogo.

Cada participante possui uma cópia local do estado do jogo, fazendo com
que seja essencial o uso de esquemas de sincronização para garantir a consistência do
estado do jogo entre os jogadores. Devido a tal característica, arquiteturas ponto a ponto
apresentam certos problemas de escalabilidade: primeiro, o andamento do jogo é
determinado pelo nó com pior taxa de transmissão entre os usuários. No caso da
Internet, é comum ter entre os jogadores, usuários com baixas taxas de transmissão,
prejudicando o andamento do jogo como um todo. Um segundo fator é que não se
espera que as máquinas dos jogadores tenham capacidade para manipular
adequadamente um número muito alto de conexões, como por exemplo, no caso de um
jogo com centenas ou milhares de usuários.

Na arquitetura cliente/servidor, representada pela figura 2 (b), um nó da rede

é promovido ao papel de servidor do jogo, responsável pela comunicação entre os
jogadores. O servidor mantém o estado do jogo centralizado e recebe notificações sobre
as atualizações de cada jogador. A partir destas informações, o servidor atualiza o estado
do jogo e repassa as atualizações para os demais jogadores. Apesar de possuir
implementações diferentes para os jogadores e o servidor, tal modelo traz certas
vantagens em relação ao modelo ponto a ponto: Primeiro, funcionalidades
administrativas desejáveis, como controle de acesso ao jogo e tarifação de jogadores,
são mais facilmente implementadas em uma topologia cliente/servidor. Outra vantagem
é que a ação de um jogador só precisa ser comunicada ao servidor, fazendo com que seu
tempo de resposta seja consideravelmente diminuído. Por estas características, jogos em
primeira pessoa são tradicionalmente implementados usando a arquitetura
cliente/servidor. Por fim, a manutenção do estado do jogo no servidor torna a arquitetura
bem resistente a ações de jogadores trapaceiros.

No entanto, o modelo cliente/servidor também apresenta problemas: o

primeiro e o mais observável, é a criação de um potencial risco representado pela
possibilidade de falha ou indisponibilidade do servidor. Na arquitetura ponto a ponto,
como não há centralização do estado do jogo, a queda de um nó não representa risco à
continuidade do jogo.

Figura 2 – Arquiteturas de comunicação para jogos. (a) Ponto a ponto; (b) Cliente/Servidor; (c)
Replicação de Servidores; (d) Grid de servidores.

Um segundo problema é a latência adicional representada pelo

processamento do estado do jogo pelo servidor, caso seu poder computacional não seja
suficiente para tratar as requisições dos jogadores.

Dependendo da audiência, o custo do servidor será um problema. Jogos que

utilizam servidores dedicados para suporte a milhares de usuários online apresentam
custos anuais de manutenção de até US$ 10 milhões em hardware, bem como alta
demanda de recursos de rede para suportar tal escala. Apesar destes fatores, arquiteturas
cliente/servidor são utilizadas na maioria dos jogos comerciais atuais ou então através
de clusters de servidores, como veremos a seguir.

A figura 2 (c) ilustra a arquitetura de replicação de servidores, que

representa um modelo híbrido entre as arquiteturas anteriores. Nesta, a infra-estrutura de
comunicação dos jogadores pode ser vista como uma arquitetura ponto a ponto de
servidores de arquiteturas cliente/servidor. Com isto, acaba-se com o potencial risco de
se possuir um único ponto de falha como na arquitetura cliente/servidor convencional.
No caso da queda de um servidor, jogadores podem ser realocados para outro servidor.
Este mesmo princípio é válido para o balanceamento de carga entre servidores
sobrecarregados ou subutilizados. A arquitetura de replicação de servidores reduz os
requisitos computacionais impostos ao servidor, promovendo uma maior escalabilidade
do jogo. Porém, como efeito colateral, a complexidade para a gerência do tráfego das
informações entre jogadores e servidores é consideravelmente aumentada, além de na
maioria dos casos, não permitir uma comunicação direta de jogadores em diferentes
servidores.
A figura 2 (d) apresenta o modelo onde os servidores do jogo são
organizados de modo a formar um grid computacional onde o estado do jogo é
distribuído entre os vários servidores. De acordo com a alocação dos jogadores, mais
servidores podem ser alocados de forma a dar suporte adequado à entrada de novos
jogadores. Da mesma forma, se houver uma saída de jogadores, os servidores podem ser
realocados para outras aplicações ou outros jogos dinamicamente. O uso de grid
computacional põe fim a um dilema onde a empresa hospedeira de um jogo acabe com
poder computacional de sobra no caso de um jogo com poucos usuários, ou com uma
sobrecarga de servidores quando do sucesso do jogo. Outra vantagem é que o uso de
computação em grade elimina as fronteiras entre jogadores, deixando transparente aos
desenvolvedores e jogadores as partições do mundo virtual. Porém, a utilização de grids
não acaba com o alto consumo de banda do lado servidor do jogo.

Para procurar resolver o problema de grande consumo de banda pelo

servidor alem de outros, existe o modelo híbrido que visa diminuir o gargalo que é o
servidor devido ao grande numero de conexões estabelecidas.

A maioria, se não todos, os MMOGs comerciais usam a estrutura cliente-

servidor, onde toda a simulação do mundo virtual é realizada de forma distribuída entre
nós servidores. Esses nós são servidores dedicados que ficam em lugares seguros, com
uma grande capacidade de tráfego à sua disposição, assegurando uma baixa latência na
comunicação mesmo com centenas de conexões simultâneas. A manutenção desse tipo
de estrutura impõe um custo significativo ao projeto, que poderia ser reduzido se fossem
utilizadas outras soluções para a distribuição da carga computacional.

A distribuição da simulação dos MMOGs nas máquinas dos jogadores é

atualmente um tópico de pesquisa, tendo como objetivo eliminar ou diminuir o custo
com os servidores dedicados. Nesse modelo, o mundo do jogo é representado não como
um espaço contíguo, mas como uma coleção de espaços separados.
 Muitos jogos massivos multi-jogador, como o World of Warcraft e Lineage
II, oferecem ao jogador a ilusão de um ou diversos grandes espaços virtuais contíguos,
que podem ser explorados. Mas esses grandes espaços são na realidade, uma coleção de
pequenos espaços unidos de forma transparente ao jogador. Essa divisão só é percebida
pelo lado do servidor onde cada nó servidor é responsável por um número limitado de
áreas do jogo. Alguns desses “grandes” espaços virtuais podem ser unidos através de
“portais”, que permitam que o jogador se transporte para diferentes espaços do jogo.

O jogo Guild Wars introduz um novo aspecto no design de jogos MMOGs,

que no escopo desse artigo se refere a um modelo de instâncias. Guild Wars provê dois
tipos de espaços virtuais. O primeiro tipo é um espaço onde alguns milhares de usuários
interagem socialmente: vendendo, trocando itens, conversando ou organizando sessões
de jogo, este pode ser chamado de “espaço social”. O segundo tipo de espaço virtual é
pequeno, conectando algumas dezenas de jogadores, mas que requer uma alta
consistência, é nesse espaço que acontecerá a ação do jogo, este outro espaço pode ser
chamado de “espaço de ação”.

A interação entre os espaços acontece da seguinte maneira. A sessão de jogo

é iniciada quando um grupo de jogadores se reúne no espaço social e decide ir a um
espaço de ação. Na sessão de ação eles lutam, interagem e ganham bens virtuais, como
itens, status entre outros. Quando a sessão de jogo no espaço de ação termina, os
jogadores retornam para o ambiente social, carregando seus novos bens virtuais. Os
espaços sociais são como os espaços normais, ou mais especificamente, espaços comuns
nas cidades do World of Warcraft e Lineage II, enquanto que os espaços da ação são
criados dinamicamente para suportar somente uma sessão provisória do jogo com um
pequeno número de jogadores.

Assim como outros MMOGs, Guild Wars foi implementado seguindo o

modelo cliente-servidor. Nessa proposta é apresentada uma fusão dos modelos cliente-
servidor e ponto-a-ponto como solução da comunicação em MMOGs. Os espaços
sociais (conversa e trocas) continuam no modelo cliente/servidor, mas têm a exclusiva
função de “espaço social”.
 Com essa modificação a necessidade de consistência é baixa, por isso os
servidores podem diminuir sua taxa de comunicação com os clientes sem que isso
interfira nos objetivos do espaço social. Por outro lado, os espaços de ação adotam um
modelo ponto-a-ponto, onde um grupo de usuários fica conectado diretamente, e o
processamento é feito em suas máquinas. Em outras palavras, o servidor é liberado da
necessidade de maior taxa de comunicação e poder de processamento, os tornando
responsabilidade do cliente. Sendo assim, a estrutura e os custos do servidor são
reduzidos e a estabilidade de cada nó servidor aumentaria, pois em grande parte do
tempo a maioria dos jogadores se encontraria no espaço de ação, ou seja, instâncias
ponto-a-ponto mantidas pelos próprios usuários. A figura 3 seguinte ilustra a arquitetura
hibrida.

Figura 3 – Arquitetura hibrida

 Essa proposta, por outro lado, introduz problemas relacionados à trapaça no
jogo. Dependendo do modelo de sincronização adotado pelos espaços de ação, alguns
jogadores podem manipular o jogo para obter vantagem para si próprio, retornando para
o espaço social com somas arbitrárias de bens virtuais, como dinheiro, itens e
experiência.

Esse problema pode ser inibido pela réplica das entradas sincronizadas de
dados dos jogadores. Se os eventos forem executados na mesma ordem, usando os
mesmos timestamps nos clientes, então um único nó honesto é requerido para se
detectar inconsistências e com isso negar os bens teoricamente adquiridos na sessão da
instância do jogo de forma inapropriada. Nós observadores são adiconados a instancia
do jogo para verificar execução das ações no jogo.

4. SINCRONIZAÇÃO

4.1. ABORDAGEM CONSERVADORA OU PESSIMISTA (STOP-AND-

WAIT)

Nessa seção será mostrada uma técnica de simulação para um jogo de ação
de baixa escalabilidade com grandes volumes de trocas de dados. A proposta defende o
uso de duas cópias do estado do jogo em cada máquina: sendo a primeira a
conservadora e a segunda a otimista.

A cópia conservadora será atualizada depois de o nó receber todas as

informações, referentes ao passo, de todos os jogadores. Por outro lado, a otimista é
atualizada seguindo o modelo do “mais rápido que puder”, onde as ações dos jogadores
são executadas assim que são recebidas e as ações dos jogadores que não enviaram suas
ações são extrapoladas com base na simulação conservadora. A cópia conservadora tem
por objetivo detectar a utilização de trapaças pela replicação dos estados da simulação,
sendo também a base para os rollbacks e execuções corretivas de passos quando eventos
chegam atrasados.

A técnica proposta requer que todos os nós de um grupo compartilhem um

relógio assíncrono. Quanto menos sincronizados os relógios estiverem, mais as
simulações poderão divergir temporalmente. Entretanto, o algoritmo sempre garante a
convergência das simulações, mesmo que seus relógios não estejam sincronizados, ou
seja, mesmo que os pacotes cheguem com vários segundos de atraso as simulações em
todas as máquinas manterão a sua consistência.

A única evidência desse atraso será o atraso da ação do personagem do

jogador com lag, a qual pode ser eliminada ou pelo envio das ações atrasadas ou por
“voto de desconexão”, em que os outros nós decidem se o usuário que esta muito
atrasado em relação aos outros deve ser retirado do jogo.

Assume-se que todos os nós podem sincronizar seus relógios com o servidor
através de técnicas de sincronização. A técnica ponto-a-ponto também requer que todos
os nós comecem com uma cópia sincronizada do estado do mundo virtual e um acordo
sobre o tempo inicial da simulação.

Como mencionado anteriormente, esse modelo trabalha com duas cópias do

estado do jogo na memória em cada máquina: a otimista e a conservadora. A cada turno
é feita uma comparação dessas cópias, e quando encontra divergências significativas
entre a cópia otimista e a cópia conservadora, realiza um rollback de estados com base
na cópia conservadora e executa novamente alguns passos do jogo. Esse rollback tem o
objetivo de alinhar as cópias otimistas e conservadoras, corrigindo assim a divergência
introduzida pela extrapolação executada na cópia otimista. O custo computacional para
execução do rollback e de alguns passos de simulação depende do atraso da rede entre o
nó local e o nó remoto.

Um evento gerado localmente, na sua criação, recebe um timestamp, um

valor do seu relógio local. Partindo da premissa que todos os relógios estão,
teoricamente, sincronizados, isso significa que o evento é executado simultaneamente
em todos os nós, de acordo com a técnica de escalonamento empregada, stop-and-wait.
Entretanto, isso é o mesmo que afirmar que todos os eventos gerados localmente estão
sempre “atrasados” para o nó remoto, que compara o timestamp do pacote recebido com
o seu valor de relógio local. Mesmo com esse problema essa solução é viável, pois em
jogos de ação executar os movimentos “o mais rápido possível” é preferencial a
executá-los localmente com um atraso para manter todos os nós com a mesma
velocidade de visualização.

4.1.1.SIMULADOR CONSERVADOR
 O simulador conservador em um nó trabalha em turnos, que são divisões
fixas de tempo Sc (foi utilizado Sc de 50ms no protótipo). A cópia conservadora só é
atualizada para o tempo Tc quando se garante que todos os eventos de todos os
jogadores com o timestamp no intervalo [Tc, Tc + Sc] foram recebidos. Para evitar
“travadas” desnecessárias no simulador, todos os nós devem enviar ao menos um evento
a cada intervalo de tempo Sc. Se o nó não gerou nenhum evento significativo naquele
intervalo, ele envia um “ping” vazio.

Essa requisição de eventos no simulador conservador deve ser acoplada com

o restante do código determinístico do simulador (como movimento de objetos e
colisão), com isso serão produzidos os mesmos resultados para todos os jogadores em
todos os nós, se os módulos de física dos simuladores também forem determinísticos.

4.1.2.SIMULADOR OTIMISTA

O simulador otimista é aquele responsável pela imagem que o usuário vê na

tela. Ele a atualiza de acordo com a última mensagem recebida. Esse simulador avança
seu estado recebendo os eventos de todos usuários ou não. O simulador otimista avança
seu tempo To usando como referência o tamanho do passo So. No modelo proposto foi
usado um So de 50ms.

Quando avança o tempo de To para To + So, o valor final To + So deve ser,

idealmente, igual ao instante atual To do relógio sincronizado da simulação. Durante o
passo, todos os eventos conhecidos no intervalo [To, To+So] são usados na computação
para o próximo estado. Quando se deve avançar um passo do simulador otimista e um
jogador ainda não enviou seus eventos, sua posição é extrapolada para onde ele deveria
estar no momento atual (dead reckoning). Isso é feito com base no simulador
conservador. Entretanto se o jogador passar mais de três ciclos do simulador otimista
sem enviar nenhum evento, seu personagem ficará imóvel, evitando assim diferenças
abruptas de posição do seu personagem quando seus eventos atrasados chegarem e for
executado rollback e execução corretiva de passos.

Essas extrapolações ajudam a diminuir a inconsistência entre o que o

jogador está vendo e o que ele deveria estar vendo, se soubesse os eventos de todos os
usuários. A figura 4 seguinte ilustra um caso prático desse problema no protótipo, onde
o cliente A fica 230ms sem receber informações do cliente B. Isso força que a simulação
de A extrapole as ações do cliente B. Essa extrapolação causa inconsistências que serão
corrigidas, através do rollback das ações, assim que o pacote de dados do cliente B
chegar em A.

O estado otimista de A possui a ultima localização de A definida pelo

usuário, enquanto que a de B não esta de acordo com ultima localização de B. o jogador
A tenta definir a localização de B através da técnica de dead reckoning, visando
diminuir a diferença dos estados vistos pelo jogador A do que realmente esta
acontecendo.

Mas para a cópia conservadora do jogo de A, ela ainda esta no ultimo estado
que B enviou. Enquanto isso jogador B esta vendo a localização definida por ele em seu
ultimo comando para movimentação, assim como mostra cópia otimista de B.

4.1.3.SIMULADOR CONSERVADOR RESOLVENDO INTERAÇÕES

Quando um jogador vê um objeto com atraso (através do simulador otimista que é

responsável pelo desenhado na tela), é necessário aplicar a compensação de lag no
simulador conservador, ao invés de simplesmente deixar os objetos colidirem no
momento Tc, ou senão os resultados apresentados pelo simulador otimista seriam de
pouca utilidade.

O modelo trabalha da seguinte maneira: os nós dos jogadores enviam a cada

intervalo de tempo Sc, para todos outros nós participantes, um vetor de inteiros mostran-
 Figura 4 – Exemplo de um estado em que o jogo pode se encontrar num dado
instante.

do a última posição conhecida de cada jogador. O simulador conservador, ao passar do

Tc para Tc + Sc, pode usar essa informação para, por exemplo, checar a colisão entre um
projétil do jogador P no momento Tc e o corpo do personagem do oponente O no
momento Tc - A, onde A é o atraso enviado por P relativo a vinda na mensagem pela
rede de O. Em um jogo isso pode ser percebido quando um jogador é atingido depois
que ele se escondeu atrás de uma caixa. Dessa forma, o tiro que foi executado no
momento Tc deveria atingir o corpo do oponente no momento Tc - A, ou seja, quando
ele ainda não estava escondido.

4.1.4.ROLLBACK E EXECUÇÃO CORRETIVA

Uma parte importante do simulador otimista é o modo como esse trata os

eventos atrasados, ou seja, quando um nó com o tempo do simulador otimista To recebe
um evento com o timestamp Te, onde Te - To. Cada atraso pode introduzir erro, ou seja,
diferença entre o que o simulador otimista mostra para o usuário e o que o simulador
conservador aprova como feito pelos usuários.

Entretanto, mostrar os objetos dos jogadores remotos “no passado” quando

recebidos com atraso, só introduz erro se esses interagem com objetos controlados por
outro jogador. Ou seja, eventos atrasados de tiro ou movimento só introduzirão erro se o
jogador remoto estiver interagindo com eles, que em um jogo de tiro, por exemplo,
acontece em uma pequena parcela de tempo se comparada com o tempo que se passa
“fora de combate”.

Depois de um passo do simulador otimista, o estado otimista se torna ou

aceitável ou inaceitável, diferente do estado conservador que é sempre aceito. Se
inaceitável, um rollback corretivo seguido de execução corretiva é necessário. A forma
como decidir se um estado é aceitável ou não, assim como o modo como o rollback será
executado fica a cargo da aplicação, visto que isso é especifico das características do
jogo.

É importante ressaltar que o acionamento do rollback e da operação de

execução corretiva não necessitam ser executados todos de uma vez, bloqueando outras
funcionalidades do jogo, como desenho ou comunicação de rede. O custo de CPU para
executar um rollback e execuções corretivas de turnos pode ser muito alto, sendo
necessário alguns segundos de processamento no mundo real. Por esse motivo a
execução corretiva de muitos passos é dividida em etapas, suavizando assim o
processamento na máquina do jogador, reduzindo o impacto visual e a diminuição da
resposta do controle.

4.2.TIME WARP

O Time Warp é considerado um algoritmo otimista. A abordagem é, ao invés

de impedir que o erro ocorra (conservadorismo), detecta e corrigi quaisquer diferenças
nos estados do jogo. Os algoritmos otimistas executam eventos antes de saberem ao
certo que nenhum evento anterior pode chegar e, se erram, reparam as inconsistências.
Este tipo de algoritmo se comporta bem melhor em situações interativas e contínuas.
 A sincronização Time Warp trabalha utilizando um snapshot (snapshot
guarda um estado do jogo), de cada estado antes de cada execução, e executa um
rollback para um estado anterior caso algum evento anterior ao último executado seja
recebido.

O rollback restaura o estado do snapshot anterior ao evento que deveria ter

sido executado, executa-o e, posteriormente, executa todos os outros eventos
novamente. O problema da sincronização Time Warp é que ela requer uma máquina
rápida e muita memória. Afinal, é necessário um snapshot para cada mensagem e as
mensagens costumam chegar em uma frequência muito alta (uma a cada 30
milissegundos em média, dependendo do jogo). Manter um “histórico” do jogo pode
sair caro.

Figura 5 – Algoritmo time warp (GVT – Global Virtual Time ou Tempo do jogo)
Uma otimização para remover este gargalo é capturar o snapshot
periodicamente, ao invés de fazê-lo a cada mensagem. Porém os rollbacks acabam
perdendo um pouco de precisão. Outra complicação para os rollbacks é que o Time
Warp assume que eventos geram novos eventos diretamente. Se um evento A gera o
evento B, o cancelamento de A, provocará o cancelamento de B.

Eventualmente, uma geração encadeada de anti-messages (cancelamento de

evento nos rollbacks) pode ocorrer, fazendo com que a rede e o jogo percam tempo
“corrigindo” ao invés de “executando” o jogo. Sem contar o aspecto pouco amigável do
rollback para o jogador. Para compensar um pouco este fato, o algoritmo acelera a
aplicação até chegar no estado onde o jogo estava quando se iniciou o processo de
rollback. Para completar, Time Warp executa o rollback imediatamente após detectar um
comando atrasado. Por um lado isso é bom, pois faz com que os rollbacks sejam
pequenos. Por outro lado, acaba causando a execução de excessivos rollbacks caso
ocorram muitos atrasos.

4.3. TRAILING STATE SYNCHRONIZATION (TSS)

O TSS, assim como o Time Warp, é um algoritmo otimista e também

executa rollbacks quando inconsistências são detectadas. Porém, ele não utiliza
snapshots e é capaz de agregar vários rollbacks em um único. Quando um rollback se
faz necessário, ao invés de copiar o estado de um snapshot anterior, o TSS copia o
estado de uma “segunda cópia” do mesmo jogo. Esta segunda cópia estava, com um
delay relativo, trilhando (trailing) a principal. Eventualmente, esta “segunda cópia” não
possuirá a inconsistência. Na verdade, veremos que é ela a responsável pela detecção da
inconsistência.

O TSS mantém e atualiza um número fixo de copias dos estados do jogo,

porém com diferentes tempos de simulação. Cada cópia terá um atraso embutido. O
estado principal, possuidor do menor delay, é o que será renderizado para a tela dos
clientes enquanto os outros trailing states (trilha de estados, em outras palavras buffers
onde serão guardados os comandos) são utilizados para detectar e corrigir as
inconsistências.

Figura 6 – Terminologia TSS

Em um dado tempo T da simulação, se o estado principal S0 esta

executando um comando no tempo T – D0, então o trailing state S1 estará executando
um comando T – D1 e assim sucessivamente, onde D0 < D1 < D2 < ... < DN. Os delays
podem não se dividir linearmente.

O TSS assume que o custo de executar os comandos (trailing states) muitas

vezes é menor que o custo de capturar snapshots. Quando os comandos chegam, eles
são colocados em uma lista de "pendentes" para cada trailing state em ordem de tempo
(timestamp). Se um comando chega atrasado e perde seu tempo de execução, ele é
inserido como próximo evento e é executado imediatamente.

Para detectar inconsistências, cada trailing state compara seu estado com o
do precedente. Quando um comando é executado no último dos trailing states, este
comando é deletado de todos os trailing states, pois ele se torna inútil. O último traling
state não possui um estado de "backup", logo, inconsistências nele não são detectadas.
Se alguma inconsistência é detectada, um rollback para o estado correto é realizado. Isto
consiste em copiar o estado do trailing state para o estado principal adicionando na lista
de "pendentes" do mesmo todos os comandos que foram executados incorretamente.
Finalmente, o estado principal executa novamente estes comandos e acaba retornando
para o tempo de execução apropriado. Nota-se que inconsistências nos trailing states
promovem uma correção em cascata até chegar no estado principal.

No Time Warp, o rollback ocorre no momento em que se recebe um evento

fora de ordem. Em contrapartida, no TSS os rollbacks sofrem um delay até o trailing
state chegar no ponto da inconsistência. Com esta característica, o TSS é capaz de
corrigir vários eventos atrasados em um único rollback eliminando a necessidade de
futuras correções para tais inconsistências.

Um exemplo de rollback ocorre quando a posição do jogador retrocede para

a posição correta e o jogo continua. Ocasionalmente, rollbacks podem causar algumas
mudanças drásticas como fazer um jogador "ressuscitar".

Segue um exemplo de rollback durante a execução do protocolo:

 Figura 7 – execução correta

A figura acima ilustra uma execução normal, o pacote (linha verde) não
chegou atrasado.

Figura 8 – Comando atrasado

A ilustração acima demonstra um comando atrasado. S0 executa-o

imediatamente e ele será detectado por S1 que o comando chegou fora de ordem.

Figura 9 – Detecção do atraso

Na figura acima detecta a inconsistência.

 Figura 10 - Rollback

Nesta o rollback é executado. A parte correta de S1 sobrepõe a parte

incorreta de S0. Os comandos da lista azul escura são movidos para "pendentes" de S0 e
serão executados novamente. Note, na área azul escura da quarta figura, que um outro
evento chegou atrasado, mas foi envolvido pelo rollback e será corrigido pelo mesmo.

A tabela 1 seguinte mostra o resultado de testes realizados com o algoritmo

TSS no jogo Quake. Delays são os tempos de “atraso” em que foram utilizados nos
trailing states. Comandos executados possui o numero de comando executados no
cliente e no servidor durante o teste. Tempo de execução é o tempo gasto para executar
estes comandos. Número de rollbacks informa a quantidade de rollbacks realizados, e
tempos de rollback informa o tempo gasto para estes rollbacks. Custo dos comandos é a
razão entre tempo de execução e o número de comandos. Custo dos rollbacks é a razão
entre tempo de rollback e o número rollbacks realizados.

Custo dos
Comandos Tempo de Nº de Tempo de Custo dos
Delays(ms) Comandos(ms
Executados Execução(seg) Rollbacks Rollback(seg) Rollbacks(ms)
)
1 0,50 40.780 6.14 817 1.15 0.15 1.41
2 0,100 45.401 6.37 870 1.23 0.14 1.41
3 0,50,100 59.981 9.02 938 1.32 0.15 1.40
4 0,100,1000 331.687 26.20 6.687 10.11 0.08 1.51
5 0,50,100,150 79.357 12.15 1.092 1.53 0.15 1.41
6 0,50,100,500 99.730 13.26 2.370 3.36 0.13 1.42
7 0,50,500,1000 251.044 23.22 6.995 10.51 0.09 1.50
Tabela 1 – Resultados de testes realizados com o algoritmo TSS
5. CONCLUSÃO

Como visto no decorrer do texto, existem varias formas de se implementar

um jogo, com varias arquiteturas e maneiras de se estabelecer a comunicação entre os
jogadores. Com isso deve se escolher aquela que melhor se adapta para o que seu jogo
se propõe. Levando em consideração outros fatores que foram abordados no texto,
como a compressão das mensagens a serem enviadas.

Com o desenvolvimento e melhoria das comunicações entre os

computadores os jogos estão em uma tendência irreversível de que os jogos devem
possuir alguma forma de possibilitar que os jogadores possam disputar partidas online.

Em virtude da “profissionalização” (E-Sports) dos jogadores e da

modernização dos jogos (evolução da tecnologia) este campo tende ao
desenvolvimento. É um prato cheio para os apaixonados por jogos multi-player e por
computação.
6. BIBLIOGRAFIA

[01] PRITCHARD, Matt. How to hurt the hackers: The scoop on internet cheating
and how you can combat it, Julho 2000. Disponível em
http://www.gamasutra.com/features/20000724/pritchard_01.htm. Acesso em
outubro de 2006.

[02] HELIN, Ville. Development of modern multiplayer games. Master’s thesis,

Helsinki University of Technology, Julho 2003.

[03] CRONIN E., KURC A., FILSTRUP B. e JAMIN S.: 2003, An Efficient
Synchronization Mechanism for Mirrored Game Architectures. Kluwer
Academic Publishers. http://warriors.eecs.umich.edu/games/papers/mtap-tss.pdf

[04] LIANG, Xuebo: 2005, Incorporating Inconsistency Into Network Computer

Games. Master Degree Research Project, McGill University,
http://www.cs.mcgill.ca/~xliang4/ResearchProjectReport.pdf

[05] CRONIN, Eric; FILSTRUP Burton; KURC, Anthony: 2001, A Distributed

Multiplayer Game Server System. UM EECS589 Course Project Report,
http://www.eecg.toronto.edu/~ashvin/courses/ece1746/2003/reading/cronin-
umtr01.pdf

[06] RABELLO, Solon A.; CECIN, Fábio; BARBOSA, Jorge L. V.; GEYER,
Cláudio F. R. Modelo de Comunicação Híbrido para Jogos Massivos Multi-
jogador