Desenvolvimento de jogos em rede – Parte 01

fevereiro 10, 2017 12:00 pm Publicado por Deixe um comentário

Olá, pessoal!

Depois de longa licença, estou voltando a escrever. Volto falando sobre desenvolvimento de jogos em redes. Vou mostrar como pensar, organizar, planejar e desenvolver jogos multiplayer em redes (inclusive Internet, afinal, a Internet também é uma rede).

Portanto, hoje, como um ponto de partida, vou trazer alguns fatos sobre o desenvolvimento de jogos.

Jogos multiplayer em rede possuem abordagem diferente de um single player

Desenvolver jogos para serem jogados em rede não é a mesma coisa que desenvolver um jogo para ser jogado de forma simples no PC. Muitas mecânicas que foram programadas para o “Single Player” acabam falhando miseravelmente quando precisam ser portados para o “multiplayer”. Pois muitos jogos têm a ideia inicial de possuir um modo multiplayer, mas no final, o multiplayer acaba sendo cancelado nas últimas horas, ou pior, o jogo inclui o multiplayer da forma que está.

Esse problema foi encarado pela 2K Games durante o desenvolvimento de Civilization IV: a adaptação do jogo de single player para multiplayer foi problemática. Entretanto, perceberam que adaptar um jogo multiplayer para single é um caminho muito mais fácil do que o contrário. Assim, começaram a rotina de desenvolver primeiro o multiplayer e depois focarem no single.

Jogos multiplayer dependem de muito planejamento

Desenvolver um jogo multiplayer é um desafio de engenharia de software. Você deve planejar os chamados “protocolos”, que são as informações transmitidas na rede. Quem recebe a informação deve interpretá-la. Deve se levar em conta latência de rede, tipos de conexão e muitas outras variáveis. Um erro de planejamento pode fazer com que a rede congestione e o torne inviável.

Jogos multiplayer possuem limitações

Largura de banda da Internet, capacidade de processamento do servidor, congestionamento na rede, capacidade da placa de rede, peculiaridades de conexões TCP, UDP, entre outros. Esses são os motivos pelos quais muitas salas de jogos limitam a 8, 16 ou 32 jogadores, ou MMO ficar com filas para entrar no servidor.

Os modelos de  arquitetura de redes

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. Seu uso se aplica 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 seu 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-o 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 em muitas pessoas. 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á!

***

Artigo publicado originalmente em Fábrica de Jogos

Source: IMasters

Categorizados em:

Este artigo foi escrito pormajor

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *