Desenvolvimento de Jogos em Rede: Arquitetura de Rede P2P

Olá, pessoas! No último artigo eu falei sobre os jogos em redes e algumas considerações. Uma das abordagens foram ter uma forma diferente de desenvolvimento que normalmente são feitas nos jogos “Single Player”. Também citei  a necessidade de planejamento e algumas limitações. Pois então, hoje, vamos entrar em detalhes, porém do ponto de vista da comunicação entre os computadores.

Basicamente temos dois modelos de arquitetura de redes utilizadas em desenvolvimento de jogos: O modelo Peer-to-Peer, também conhecida como P2P e o modelo Cliente-Servidor.

O Modelo P2P

O modelo P2P foi o primeiro modelo utilizado em jogos e ainda é o mais utilizado, dado a sua simplicidade. Ele é utilizado em jogos de RTS como Dota, League of Legends, Age of Empires, entre outros.

Esse modelo é responsável por cada computador enviar os comandos realizados para os outros computadores participantes. A ideia é que todas as máquinas iniciem no mesmo estado e com os comandos recebidos. Assim, cada computador processa os acontecimentos dos eventos independente dos outros.  Esse modelo, além de fácil implementação, também possui a vantagem de que, caso um jogador caia, os outros jogadores não são desconectados. Também a partida pode continuar sem a interferência da queda da conexão.

No entanto, apesar da simplicidade, este modelo possui diversas limitações.

Sincronização

Começando, por exemplo, pela latência da rede. Latência é o tempo em que os dados de um computador levam para chegar até o outro. Isso significa que no teu computador, os comandos que você realiza são instantâneos. Agora o teu comando somente será realizado nos computadores dos outros jogadores quando ele for enviado para a rede. Depois, ser transportado e chegar ao computador do adversário. Isso significa que se algum jogador tiver uma latência alta, esse vai demorar a ter o comando executado. Enquanto isso, diversos outros comandos já podem ter sido feitos e executados no teu computador. E mesmo que a latência seja realmente baixa, ela ainda existe. Isso com o tempo, essas latências acumuladas acabam por ter um jogo totalmente dessincronizado. Ou seja, o estado do jogo em um computador pode estar diferente do outro.

Para diminuir essa falha de sincronia, você pode dividir o tempo em “turnos” e fazer com que os comandos sejam realizados a cada início de turno. Perceba que a duração dos turnos vai ser no mínimo o tempo de duração do jogador com a maior latência. Ou seja, os comandos serão tratados como se todos tivessem essa latência. Os jogos geralmente, para disfarçar esses processos de turnos, realizam diversas distrações. Alguns exemplos: efeitos sonoros, explosões, tudo para distrair as possíveis lags causadas pela alta latência.

Outro problema do modelo P2P é que como cada computador realiza seus próprios procedimentos, inclusive o processamento dos comandos vindo dos outros jogadores. Havendo a possibilidade de um comando que seja uma função heurística, podem ocorrer resultados diferentes entre os computadores. Por exemplo, um jogo como Age of Empires, você pode ter comandado ele para ir a algum lugar usando um algoritmo como A*. No seu computador, sua unidade pegou um caminho e o outro computador pegou outro. Isso contribui também para a falha de sincronia entre os computadores e esse tipo de algoritmo deve ser usado com muita cautela.

Limite de jogadores

A próxima limitação das redes P2P explica o motivo da razão pelo qual muitos jogos possuem “lobbies” antes de iniciar o jogo e não permitem o ingresso de novos jogadores. Para haver sincronia, todos os jogadores se reúnem em uma sala e somente quando todos estiverem prontos, o jogo inicia. Ao terminar de carregar todos os recursos, todos os computadores estão no mesmo estado de jogo. Agora imagine a situação em que você queira inserir um novo jogador durante a partida. Enquanto o novo jogador estiver carregando as informações para entrar na partida, a mesma continua, mudando as informações e dificultando o ingresso do novo jogador.

Outra limitação é o tráfego gerado na rede. A quantidade de dados a ser enviado para cada computador é de n-1, ou seja, se eu estiver em um jogo com 4 jogadores, meu computador precisará se comunicar com outros 4-1=3 computadores. Entretanto, os outros computadores também vão precisar se comunicar com os outros participantes. Logo, se for considerar esses outros 3 computadores enviando dados, então teremos (4-1)+(4-1)+(4-1)+(4-1)=12 pacotes de comandos na rede. Agora, vamos supor que tenhamos mais dois computadores, formando uma rede com 6 computadores: isso dará (6-1)=5 pacotes para 6 computadores = 5+5+5+5+5=30 pacotes. Com 7 computadores, já temos 56 pacotes.

Perceba que quanto mais jogadores na partida, mais o número de pacotes que estará na rede em cada turno vai aumentando de forma exponencial. Se não houver limite, a rede pode colapsar com tanto tráfego. Por isso o limite de jogadores mais baixos para os jogos que utilizam esse tipo de conexão.

Apesar do problema de escalabilidade, a maioria dos jogos que utilizam esse tipo de conexão são de partidas de poucos jogadores. A maioria são partidas de 4 jogadores, e acho que o maior número que eu já encontrei por experiência própria foi de 16 jogadores. Então, mesmo que a limitação de jogadores seja um fato, também é fato que muitos jogos não são nem feitos para serem jogados com grandes quantidades de jogadores. Isso torna a comunicação P2P atrativa na maioria dos casos.

Conclusão

Hoje mostrei como funciona um jogo em rede com comunicação em P2P. Ela não possui suporte para grande quantidade de jogadores e necessita de cuidados com a sincronização entre os computadores participantes. Porém, é um modelo simples de ser implementado e ainda é o mais utilizado nos jogos de hoje. A limitação de usuários pouco importa quando o escopo dos jogos a serem desenvolvidos já limitam a quantidade de jogadores.

Uma leitura complementar que recomendo é o artigo do Gamasutra 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond, que mostra como foi desenvolvido a comunicação em redes da série de jogos “Age of Empires”.

No próximo artigo, vamos ver o outro modelo de comunicação, que vai ser o Cliente-Servidor e como ele funciona. Até lá!

Thalisson Christiano de Almeida

Thalisson Christiano de Almeida

Formado em Ciência da Computação (UDESC). Foi Programador da Céu Games e professor do Técnico em Informática do SENAI-SC. Atualmente, trabalha na empresa By Seven. Já foi jogador de xadrez e praticou kung-fu, ambos por 4 anos. Hoje é praticante do Jiu-jitsu, esperando que não fique nos 4 anos. Não tem preferência de tipos de jogos em especifico, variando desde jogos casuais de Facebook até jogos mais hardcore.

Send this to a friend