Académique Documents
Professionnel Documents
Culture Documents
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
Teresina-PI
Fev. 2007
2
IDENTIFICAÇÃO
MATRIC.Nº_ 03N10187 _
3
Dedico este trabalho primeiramente a Deus, meus pais,
e meu supervisor do estagio que me ajudou durante a
elaboração do mesmo.
4
AGRADECIMENTOS
Agradeço:
• A Deus;
• A meus pais;
• aos colegas de turma, em geral, e aos membros dos fóruns aos quais discute
sobre o assunto.
5
LISTA DE ILUSTRAÇÕES
6
RESUMO
7
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 22
2.2.6 JOGOS BASEADOS EM LOCALIZAÇÃO 23
3. ASPECTOS TÉCNICOS EM JOGOS MULTIUSUÁRIOS 24
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 29
3.2.4 DEAD RECKONING 29
3.2.5 ARQUITETURA DE COMUNICAÇÃO 30
4. SINCRONIZAÇÃO 36
4.1 ABORDAGEM CONSERVADORA OU PESSIMISTA(STOP-AND-WAIT) 36
4.1.1 SIMULADOR CONSERVADOR 37
4.1.2 SIMULADOR OTIMISTA 38
4.1.3 SIMULADOR CONSERVADOR RESOLVENDO INTERAÇÕES 39
4.1.4 ROLLBACK E EXECUÇÃO CORRETIVA 40
4.2 TIME WARP 41
4.3 TRILING STATE SYNCHRONIZATION (TSS) 42
5. CONCLUSÃO 48
6. BIBLIOGRAFIA 57
8
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.
9
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.
10
1. PROTOCOLOS
1.1.TCP
11
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.
12
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.
1.2.UDP
13
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)[07].
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.
14
2. JOGOS MULTIUSUÁRIO
15
2.1.ESTILO DE JOGOS MULTIUSUÁRIOS
16
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.
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
18
dos primeiros FPSs lançado no mundo, mas principalmente por introduzir o conceito de
jogos multiusuário em redes de computadores.
2.2.3.JOGOS CONECTADOS
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
20
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.
21
2.2.5.JOGOS PERVASIVOS
22
2.2.6.JOGOS BASEADOS EM LOCALIZAÇÃO
3.1.1.PLATAFORMA FÍSICA
24
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 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
25
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
3.2.1.DISTRIBUIÇÃO DE MENSAGENS
27
problema de escalabilidade e desempenho, devido ao congestionamento da rede para
jogos que utilizem tal abordagem.
Figura 1 – Técnicas para transmissão de mensagens: (a) broadcast, (b) unicast, (c) multicast
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
3.2.5.ARQUITETURAS DE COMUNICAÇÃO
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,
30
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.
Figura 2 – Arquiteturas de comunicação para jogos. (a) Ponto a ponto; (b) Cliente/Servidor; (c)
Replicação de Servidores; (d) Grid de servidores.
31
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.
32
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.
34
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.
35
4. SINCRONIZAÇÃO
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.
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.
36
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.
4.1.1.SIMULADOR CONSERVADOR
38
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.
39
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 [06].
4.2.TIME WARP
41
Figura 5 – Algoritmo time warp (GVT – Global Virtual Time ou Tempo do jogo)
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
43
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.
A figura acima ilustra uma execução normal, o pacote (linha verde) não
chegou atrasado.
Figura 10 - Rollback
45
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
46
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.
6. BIBLIOGRAFIA
47
[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.
[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
[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
[10] IEEE 801. IEEE 802.11, The Working Group Setting the Standards for Wireless
LANs, Acessado em: Outubro de 2006. http://grouper.ieee.org/groups/802/11/.
[16] NCsoft. Lineage 2, The Chaotic Chronicle – the official web site. NCsoft, Inc.
Disponível em http://www.lineage2.com. Acesso em: dezembro de 2006.
49