Os jogos online têm problemas que os jogos de um jogador ou apenas LAN não precisam se preocupar, como jitter, tempo de ida e volta (RTT) ou perda de pacotes.

Qualquer tipo de atraso entre o envio, recebimento e enfileiramento de informações entre clientes e servidores pode causar um problema para o jogo. Para uma lista completa de definições e problemas, confira este guia aqui.

Para resolver com sucesso os problemas de latência, você precisa considerar a prioridade e o relacionamento entre os seguintes elementos:

1. Segurança

2. Reatividade

3. Precisão e consistência

Nenhuma solução é perfeita, e cada maneira de abordar problemas de latência tem pontos fortes e fracos. A chave é encontrar o caminho que funciona melhor para o seu jogo e este guia o ajudará a entender como tomar essa decisão.

Autoridade define quem tem o direito de tomar decisões finais de jogo sobre objetos na relação cliente-servidor. O modelo de autoridade que você seleciona tem implicações para a latência da rede em seu jogo.

Existem dois tipos de autoridade em jogos multiplayer, e cada um tem sua própria relação com segurança, reatividade e consistência:

• Autoridade do servidor: Mais seguro, menos reativo, sem problemas de sincronização.
• Autoridade do cliente: Menos seguro, mais reativo, possíveis problemas de sincronização.

Qualquer código que exista do lado do cliente pode ser manipulado e os jogadores podem forjar mensagens de rede falsas enviadas ao servidor.

Se você quiser saber como isso pode acabar parecendo em seu jogo, considere o exemplo de um jogo onde você não pode matar imps a uma certa distância.

Se você especificar em sua lógica de cliente que não pode matar esses diabretes a mais de 10 metros de distância, mas a mensagem "matar diabrete" é um RPC do servidor que não verifica a distância do lado do servidor, os jogadores podem forjar essa mensagem de rede para contornar sua lógica do lado do cliente.

Infelizmente, algumas pessoas sempre tentarão atrapalhar seu jogo, então você deve sempre ter em mente que nunca pode confiar totalmente nos clientes. Para o bem daqueles pobres diabinhos e de todos os outros jogando seu jogo, seu servidor precisa de lógica para validar as ações dos jogadores que vêm dos clientes.

Um jogo autoritativo de servidor tem todas as suas decisões finais de jogabilidade executadas pelo servidor.

Segurança ✅

Dados críticos, como a saúde ou a posição do seu personagem, podem ser autoritários do servidor para garantir que trapaceiros não possam interferir. Nesse caso, o servidor terá a palavra final sobre o valor desses dados.

Consistência ✅

Uma vantagem dos jogos autoritários de servidor é a consistência do seu mundo. Como todas as decisões de jogo são tomadas pelo mesmo nó na rede (o servidor), você pode ter certeza de que essas decisões são tomadas ao mesmo tempo.

Reatividade 🚫

Um problema com a autoridade do servidor é que você acaba esperando que seu servidor lhe diga para atualizar seu mundo. No entanto, fique atento, pois existem padrões que você pode usar para resolver esse problema enquanto ainda permanece autoritário no servidor.

Em um jogo autoritativo de cliente, você ainda tem um servidor que é usado para compartilhar o estado do mundo, mas os clientes possuirão e imporão sua própria realidade.

Reatividade ✅

Um modelo autoritativo de cliente pode frequentemente ser usado quando você confia em seus usuários ou em seus dispositivos, e é um modelo útil para reatividade. Como o próprio cliente está tomando todas as decisões importantes de jogabilidade, ele pode exibir o resultado das entradas do usuário assim que elas acontecem.

Consistência 🚫

Os jogos autoritários do cliente podem enfrentar problemas de sincronização. Se você deixar seu cliente tomar uma decisão autoritária usando informações desatualizadas, você enfrentará desincronizações, objetos físicos sobrepostos e outros problemas semelhantes.

Segurança 🚫

A autoridade do cliente é uma porta bastante perigosa para deixar aberta no seu servidor, já que qualquer jogador malicioso poderia forjar mensagens para ganhar o jogo.

Ao projetar seu recurso, use a autoridade do servidor como padrão e, em seguida, identifique qual recurso precisa de reatividade e não tem um grande impacto na segurança ou na consistência do mundo.

As entradas do usuário são um bom exemplo. Como os usuários já possuem suas entradas (eu possuo minha tecla pressionada, o servidor não pode me dizer "não, você não pressionou a tecla W"), os dados de entrada do usuário podem ser facilmente impulsionados pelo cliente.

Em jogos de FPS, sua direção de olhar pode ser facilmente controlada pelo cliente sem muito impacto. O cliente enviará ao servidor sua direção de olhar em vez de movimentos do mouse. Ter uma correção sobre onde você olha pareceria estranho e a segurança para isso tem seus próprios desafios.

A previsão pode manter seu servidor de jogo autoritário enquanto permanece reativo. Seu cliente simula e executa o código de jogo que antecipa as entradas de gatilho dos seus jogadores em vez de esperar um RTT completo pelos resultados da ação.

É aqui que "reconciliação" entra em cena - quando ocorrem erros na previsão. O cliente mantém um histórico das posições que previu e, sendo o servidor autoritativo, o cliente ainda recebe posições vindas do servidor. O cliente irá validar se as posições que previu no passado se encaixam com as antigas posições vindas do servidor.

O cliente pode então detectar discrepâncias e corrigir sua posição de acordo com a posição autoritativa do servidor.

Nota: Este método não é totalmente suportado pelo Netcode para GameObjects neste momento.

Existem várias razões para não ter o código de jogo autoritário do servidor rodando tanto do lado do cliente (com previsão) quanto do lado do servidor. Mas como você garante que o lançamento pareça responsivo e que seu cliente não precise esperar um RTT completo antes de ver qualquer coisa reagir à sua entrada?

Um truque frequentemente usado para esconder o lag é acionar uma animação, som ou VFX que não impacte a jogabilidade imediatamente ao input do jogador, mas ainda assim esperar que os elementos de jogabilidade autoritários do servidor conduzam o restante da ação.

Se o servidor tiver um estado diferente, o pior que acontece do lado do cliente é que você reproduziu uma animação rápida, mas inútil. É fácil apenas deixar a animação terminar ou cancelá-la. Isso é referido como lançamento de ação ou antecipação de ação.

O retrocesso do servidor é uma verificação de segurança em um recurso acionado pelo cliente para garantir que permaneçamos autoritários no servidor.

O cliente envia junto com sua entrada uma mensagem dizendo ao servidor "Eu atingi meu alvo no tempo t". O servidor, ao receber isso no tempo t+RTT/2, irá retroceder sua simulação para o tempo t-RTT, validar o tiro e corrigir o mundo no último momento (ou seja, eliminar o alvo). Isso permite que o jogador sinta que o mundo é consistente, enquanto ainda permanece seguro e autoritário do servidor.

Observação: A retroceder do estado do jogo no servidor é feito tudo no mesmo quadro e isso é invisível para os jogadores. Esta é uma verificação do lado do servidor que permite validar um cliente dizendo o que fazer.

Nota: Este método não é totalmente suportado pelo Netcode para GameObjects neste momento.

Construir um jogo multiplayer é um empreendimento desafiador, mas também emocionante. Seja você está construindo o próximo sucesso de battle royale ou um aconchegante co-op online, entender as nuances da latência e como gerenciá-la é essencial.

Confira nossa documentação multiplayer para começar seu próximo projeto hoje.