MODELOS DE SUPORTE DISTRIBUÍDO PARA JOGOS …

[Pages:20]MODELOS DE SUPORTE DISTRIBU?DO PARA JOGOS ONLINE MACI?AMENTE MULTIJOGADOR

Carlos Eduardo Benevides Bezerra*

F?bio Reis Cecin*

Cl?udio Fernando Resin Geyer *

*Universidade Federal do Rio Grande do Sul {carlos.bezerra, fcecin, geyer}@inf.ufrgs.br

Abstract Massively multiplayer online games require a large amount of resources from the server, when using a centralized architecture to provide support to them. In this work, we present a few distribution models for these games, in order to relieve the server from such costs, making it possible for small companies and independent game development groups to release such a game, for example.

Resumo Jogos online maci?amente multijogador requerem grande quantidade de recursos do servidor, quando se utiliza uma arquitetura centralizada para lhes prover suporte. Neste trabalho, s?o apresentados alguns modelos de distribui??o para esses jogos, visando a desonerar o servidor de tais custos, tornando poss?vel a disponibiliza??o de um jogo desta natureza por empresas de menor porte e/ou grupos independentes de desenvolvimento de jogos, por exemplo.

Palavras-chave: balanceamento, MMOGs, p2p, trapa?a.

Introdu??o

1. MMOGs Jogos online maci?amente multijogador (ou MMOGs) t?m se popularizado bastante nos ?ltimos tempos. Al?m de poderem ser jogados online, permitem a intera??o simult?nea de um grande n?mero de participantes. Nos casos de maior sucesso, como World of Warcraft (BLIZZARD, 2004), por exemplo, ? dado suporte a uma base de dezenas a centenas de milhares de jogadores simult?neos (CHEN e MUNTZ, 2006). Estes jogadores podem, ent?o, interagir entre si e com o ambiente virtual do jogo. Geralmente, cada jogador controla uma entidade chamada de avatar, que executa as a??es determinadas por ele, interferindo na hist?ria e no encaminhamento do jogo. Cada a??o executada por cada avatar deve ser processada pelo servidor, que calcular? o estado resultante dessa a??o no jogo. Esse novo estado ? ent?o difundido para os outros jogadores. No entanto, percebe-se que tal mecanismo pode facilmente saturar a do servidor. Geralmente o que se faz ? montar uma infraestrutura com conex?o ? Internet de algumas centenas ou milhares de MBps (FENG, 2007), de onde vem o maior custo dos MMOGs. ? a? que surge a id?ia de utilizar abordagens descentralizadas, com o prop?sito de desonerar o servidor do jogo. Diversas abordagens foram propostas para prover um suporte distribu?do ? e, portanto, mais barato ? para jogos MMOG. Por?m, para evitar que o custo do sistema como um todo seja semelhante ao custo de um servidor tradicional, ? necess?rio fazer algumas otimiza??es, que ? um dos objetivos dos modelos que ser?o apresentados aqui. Al?m disso, pelo fato de n?o haver um ?nico ?rbitro central para decidir o encaminhamento do jogo e verificar a exist?ncia de trapa?a, foi criado um modelo de distribui??o que visa a mitigar a possibilidade de viola??es das regras por parte dos jogadores passarem desapercebidas pelo sistema. Nas pr?ximas se??es ser?o apresentados alguns dos conceitos utilizados e os modelos propostos, com resultados obtidos.

2. Trapa?a em MMOGs

Jogos online s?o atividades competitivas, o que os diferencia de trabalhos em ambientes virtuais colaborativos (CVEs) (ROBERTS e WOLFF, 2004). Em um CVE, n?o ? um problema distribuir o estado do mundo virtual entre as m?quinas dos participantes. Por exemplo, pode-se deixar a cargo da m?quina de cada participante

a fun??o de manter e a de determinar o estado do pr?prio avatar. Em outras palavras, cada participante tem a autoridade final sobre parte do estado do mundo virtual ? no exemplo, a autoridade ? sobre o estado do seu pr?prio avatar. Este tipo de solu??o geralmente ? mais simples de ser suportado e resulta em um aumento da responsividade do sistema. Por exemplo, quando um participante interage com dispositivos de entrada (teclado, mouse), o seu processo simulador local pode mover a vers?o local do avatar do jogador imediatamente, j? que possui autoridade para tal, e s? ent?o enviar o movimento realizado pela rede, para que os outros participantes percebam o seu comando. O sistema resultante ? responsivo pois cada participante tem a sensa??o de controlar o seu avatar sem lat?ncia significativa entre a realiza??o do comando e a visualiza??o do resultado do comando. Tais solu??es simples, que delegam partes do estado do mundo virtual para as m?quinas dos participantes de forma indiscriminada, s?o vulner?veis ? trapa?a. Por exemplo, em um jogo de tiro, onde os jogadores disparam proj?teis uns contra os outros com o objetivo de "matar" os avatares advers?rios, um jogador que arbitra sobre o estado do seu pr?prio avatar pode simplesmente decidir que o seu avatar nunca "morre". Para isso, basta ele alterar o seu programa para simplesmente n?o receber mensagens de tiro oriundas de m?quinas remotas, por exemplo. Este jogador est? trapaceando, pois, no jogo online competitivo, ele quebra as regras do jogo e efetivamente obt?m uma clara vantagem sobre os seus advers?rios. Se o sistema possui este tipo de vulnerabilidade, e n?o prov? m?todos para detectar jogadores que exploram estas vulnerabilidades, o aspecto competitivo do jogo ? anulado ? que sentido h? em tentar derrotar advers?rios que podem programaticamente decidir se s?o derrotados ou n?o? Em jogos online comerciais, o problema da trapa?a ? tratado primeiramente pela ado??o da arquitetura cliente-servidor (KABUS et al., 2005). A maioria dos jogos online comerciais s?o sistemas cliente-servidor, centralizados, com pouqu?ssimas exce??es (GAUTHIERDICKEY et al., 2004). Neste modelo, o servidor, que ? mantido por uma parte confi?vel, ? respons?vel pela maioria das tarefas que seriam pass?veis de trapa?a se delegadas para partes n?o-confi?veis. Por exemplo, o servidor ? respons?vel por manter o estado corrente, oficial do jogo. Al?m disso, o servidor ? respons?vel por realizar transi??es de estado, isto ?, de aplicar as regras do jogo para atualizar o estado do jogo periodicamente, movendo objetos, resolvendo colis?es, etc. Desta forma, atrav?s de uma escolha de arquitetura, os

jogos online comerciais evitam a maior parte das trapa?as. Outras trapa?as n?o tratadas implicitamente pela arquitetura cliente-servidor s?o resolvidas atrav?s de m?dulos que detectam jogadores trapaceiros e os removem dos servidores (KABUS et al., 2005; WEBB e SOH, 2007). Apesar da sua simplicidade de implementa??o em software, e da sua popularidade, o modelo cliente-servidor possui algumas desvantagens. No contexto de jogos massivos, onde milhares de m?quinas clientes (jogadores) precisam conectar ao servidor, este se torna um gargalo de processamento. Al?m disso, o custo de comunica??o imposto sobre a infra-estrutura servidora ? significativo, podendo a manuten??o do servi?o de comunica??o chegar a milh?es de d?lares mensais no caso de jogos massivos cliente-servidor (FENG, 2007). Isto torna a barreira de entrada muito alta para entidades com menor poder financeiro, como pequenas empresas ou grupos de pesquisa. Neste contexto, muita pesquisa tem sido dedicada para suporte descentralizado a jogos massivos. Por exemplo, tem-se tentado utilizar o paradigma par-a-par, que j? ? utilizado para dar suporte a sistemas descentralizados de troca de arquivos, para suportar jogos massivos. Por?m, muitos modelos par-a-par de suporte a jogos massivos j? propostos tem apresentado problemas de trapa?a que s?o uma conseq??ncia direta do abandono do paradigma cliente-servidor. Estas vulnerabilidades se somam a outras j? presentes mesmo em solu??es centralizadas. Muitos modelos par-a-par de suporte a jogos massivos simplesmente delegam tarefas cr?ticas, que requerem uma parte confi?vel para a sua execu??o, para as m?quinas dos jogadores. Como mencionado anteriormente, este tipo de solu??o ? geralmente pass?vel de trapa?a.

2.1 Tratando seletivamente de trapa?as

Existem diversas maneiras de se trapacear em jogos online, e j? existem at? taxonomias de trapa?as (YAN e RANDELL, 2005). Como se tem visto na pr?tica, em jogos online cliente-servidor, ? muito dif?cil projetar um sistema de jogo que seja imune a todos os tipos conceb?veis de trapa?as. Se torna ainda mais dif?cil tratar todas as trapa?as poss?veis em uma arquitetura par-a-par (descentralizada) de suporte a jogos online massivos pois, neste contexto, ? necess?rio confiar em muito mais resultados de computa??o fornecidos pelas m?quinas dos jogadores, que est?o ativamente buscando oportunidades para obterem vantagem f?cil no jogo.

Portanto, torna-se necess?rio tratar do problema de forma seletiva, priorizando-se algumas trapa?as sobre outras. Uma maneira de priorizar ? ignorar trapa?as irrelevantes para um determinado tipo de jogo: ? evidente que cada vulnerabilidade possui um impacto que depende principalmente da aplica??o. Para validar esta afirma??o, basta considerarmos um caso lim?trofe: o suporte a ambientes virtuais colaborativos (CVEs). Um CVE pode ser visto como um jogo online que, por?m, n?o possui competi??o. Neste contexto, n?o ? poss?vel um participante obter vantagem sobre os outros participantes, simplesmente porque n?o h? uma sem?ntica de "vantagem" em um ambiente colaborativo. De forma similar, em um jogo online de onde n?o ? poss?vel extrair uma vantagem sobre os advers?rios atrav?s da manipula??o da posi??o de avatares, n?o ? um problema delegar a tarefa de c?lculo e dissemina??o da posi??o dos avatares para as m?quinas dos respectivos jogadores. Quando n?o pode-se simplesmente ignorar um tipo de trapa?a, visto que o seu impacto n?o ? nulo, a nossa abordagem ? a de avaliar o impacto relativo de cada vulnerabilidade. Mais especificamente, n?s buscamos dedicar uma maior quantidade de recursos para tratar de trapa?as de maior impacto. Por exemplo, pode-se utilizar um algoritmo mais custoso, que emite mais mensagens e que realiza mais processamento, para prevenir ou detectar trapa?as de alto impacto, ao passo em que emprega-se um algoritmo mais simples e menos custoso, com menor taxa de detec??o por exemplo, para tratar de trapa?as de menor impacto. A solu??o para um determinado tipo de trapa?a n?o precisa ser algor?tmica. Por exemplo, uma maneira simples, e perfeitamente v?lida, para se tratar de trapa?as em uma arquitetura par-a-par para jogos massivos consiste em propor que o estado do jogo seja mantido e atualizado por um conjunto reduzido de super-pares (superpeers) cujos administradores confiam mutuamente uns nos outros. Este tipo de solu??o, por?m, precisa ser avaliado n?o s? dos pontos de vista tradicionais, como escalabilidade, como tamb?m deve ter seus aspectos n?o-funcionais considerados. Por exemplo, deve-se considerar se o modelo de confian?a ? escal?vel: qual a dificuldade de se estabelecer uma rede de confian?a entre 10, 100 ou 1000 superpares? Quantos super-pares s?o necess?rios para se suportar uma determinada quantidade de jogadores?

2.2 Economias virtuais e a trapa?a de fabrica??o de estado (state cheating)

Um jogo massivo ?, em princ?pio, um ambiente virtual online onde um n?mero elevado de participantes podem interagir simultaneamente, em tempo real, para modificar um estado de jogo que ? persistido em longo prazo. Na pr?tica, existe apenas um tipo espec?fico de jogo que se popularizou sobre este paradigma massivo, que s?o os Role Playing Games (RPGs) massivos (MMORPGs). Em um MMORPG frequentemente existe uma economia virtual. Os jogadores acumulam bens virtuais ("itens"), que podem ser comprados ou vendidos atrav?s de uma moeda virtual, que por sua vez tamb?m pode ser acumulada. Desde os primeiros MMORPGs sabe-se que a manuten??o destas economias virtuais ? vital para o sucesso de um MMORPG (THOMPSON, 2000). As economias virtuais s?o t?o significativas para os jogadores de MMORPGs que os mesmos est?o dispostos a comprar itens virtuais utilizando dinheiro real. Em 2007, estimou-se que a compra e venda de riquezas de economias virtuais movimentou o equivalente a US$ 2 bilh?es (LEHTINIEMI e LEHDONVIRTA, 2007). O estado atual de uma economia virtual, isto ?, a quantidade de riqueza atualmente alocada para cada jogador, faz parte do estado de um jogo massivo, da mesma maneira que outras vari?veis como a posi??o corrente de cada avatar. Por?m, n?s entendemos que proteger a economia virtual de um jogo massivo contra trapa?as deve ser uma prioridade. A maioria, sen?o todos, os MMORPGs comerciais atuais s?o sistemas cliente-servidor, e a arbitragem sobre o estado da economia virtual ? sempre realizado por m?quinas servidoras, sob o controle centralizado do operador do servi?o. Desta forma, o estado das economias virtuais n?o pode ser manipulado por jogadores, salvo devido a defeitos no software servidor ou no protocolo (MCGRAW e HOGLUND, 2007) que s?o pass?veis de conserto. A trapa?a de fabrica??o de estado, ou state cheating, consiste em uma vulnerabilidade, especificamente encontrada em arquiteturas descentralizadas de suporte a jogos massivos, onde um jogador ? capaz de alterar o estado do jogo de forma arbitr?ria. Por exemplo, um jogador ? capaz de determinar um valor arbitr?rio para a quantidade de moeda virtual que possui, ou este ? capaz de acrescentar uma quantidade arbitr?ria de itens virtuais quaisquer ao estado do jogo. Visto que o conte?do da mem?ria na m?quina de um jogador ou de um peer an?nimo na Internet n?o pode ser garantido, deve-se portanto ter cuidado ao delegar autoridade sobre

partes do estado do jogo, especialmente quando as partes do estado se referem a uma economia virtual. Um esquema de distribui??o simples, onde cada jogador determina localmente, sem supervis?o, qual a quantidade de riqueza virtual que possui, ? vulner?vel a state cheating. Este sistema, portanto, n?o ? vi?vel para, ao menos, suportar um MMORPG cuja jogabilidade depende de uma economia virtual funcional. O problema de state cheating pode ser tratado de v?rias maneiras. Como mencionado anteriormente, ele pode n?o ser relevante dependendo do tipo de jogo a ser suportado. Por exemplo, pode-se estar planejando suportar jogos de tiro em primeira pessoa massivos, que n?o s?o atualmente suportados em escala massiva ? com algumas poucas exce??es, como o jogo PlanetSide (SONY ONLINE ENTERTAINMENT, 2008). Pode-se projetar jogos de tiro massivos que n?o dependem de economias virtuais, ou onde uma economia virtual possui um papel secund?rio. Outra solu??o ? utilizar arquiteturas h?bridas, que combinam o clienteservidor com o par-a-par. Neste modelo, ? poss?vel manter o estado da economia virtual exclusivamente em m?quinas servidoras mantidas por um operador central do jogo, ao passo que outras tarefas s?o descentralizadas em uma rede par-a-par a ser formada a partir das m?quinas e das conex?es Internet dos jogadores. Ainda outra solu??o seria a ado??o de uma rede de super-pares, onde a honestidade dos superpares ? garantida implicitamente, como mencionado em exemplo anterior. Estes super-pares, ent?o, poderiam concentrar a atividade de manter a economia virtual e outras partes do estado do jogo que n?o podem ser manipuladas por jogadores. Por fim, tamb?m pode-se prevenir state cheating utilizando-se replica??o (GAUTHIERDICKEY et al., 2004). Em arquiteturas baseadas em replica??o, o estado do jogo ? dividido em c?lulas, e cada c?lula ? replicada em v?rios n?s que, em princ?pio, n?o s?o confi?veis. A confiabilidade emerge na medida em que um n?, sozinho, n?o pode alterar o estado do jogo de forma arbitr?ria: ele pode apenas alterar a sua c?pia local. Um observador externo qualquer de uma c?lula, seja um jogador ou um servidor, sempre ir? perceber (ler) o estado da c?lula como um consenso entre as v?rias vers?es da c?lula. Partindo-se do princ?pio que a maioria dos participantes ou s?o honestos ou, ao menos, n?o est?o trapaceando de forma massivamente coordenada, tem-se que um algoritmo de consenso (por exemplo, consenso bizantino) ir?, na maioria absoluta dos casos, retornar uma vers?o do estado que ? condizente com as regras do jogo.

Desenvolvimento

3. O modelo FreeMMG 2 O FreeMMG 2 ? uma arquitetura h?brida, par-a-par e cliente-servidor, de suporte a jogos massivos. O modelo visa suportar jogos massivos com economias virtuais, portanto, tratar de state cheating se torna essencial. Como, no nosso entendimento, state cheating ? a trapa?a que possui maior impacto em um jogo massivo baseado em uma economia virtual, n?s projetamos a arquitetura primeiramente pensando em como prevenir esta trapa?a. Uma abordagem preventiva, ao contr?rio de uma abordagem de detec??o, dispensa o desenvolvimento de um algoritmo que desfa?a altera??es ilegais ao estado do jogo. Pois, ? evidente que, ap?s a detec??o de um jogador que altera ilegalmente o estado do jogo (a economia) de forma arbitr?ria, estas altera??es devem ser desfeitas, pois a inje??o discriminada de riqueza em uma economia pode destruir o valor dos bens (THOMPSON, 2000). Isto pode ocorrer mesmo quando os jogadores que realizaram tais inje??es ilegais s?o identificados e removidos do jogo.

Figura 1: Vis?o geral da arquitetura FreeMMG 2.

 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download