Predição no cliente e reconciliação com um servidor autoritativo

Responsividade com autoridade

Esperar o round trip até o servidor antes de mostrar cada movimento faz o controle local parecer atrasado. A predição permite que o cliente reaja à entrada imediatamente, enquanto o servidor continua definindo o estado de jogo aceito. A parte difícil é incorporar uma resposta atrasada sem descartar entradas mais recentes nem aplicá-las duas vezes.

Compare com o momento confirmado

Numere as entradas e guarde os comandos ainda não confirmados. Ao receber uma atualização autoritativa, restaure o estado correspondente e reexecute os comandos restantes em ordem. [1] Compare o resultado do servidor com a predição feita para esse mesmo momento confirmado, e não com o presente mais avançado do cliente. A implementação de predição da Valve faz explicitamente uma comparação de erro no estado confirmado. [2]

Exemplo prático

Num controlador unidimensional ilustrativo, o cliente previu os comandos 101, 102 e 103. Uma atualização do servidor confirma 101 na posição 5.0 m; o cliente havia previsto 5.1 m após esse comando. Os comandos 102 e 103 movem 0.2 m cada um a partir do estado restaurado.

Descarte o histórico de comandos até 101, restaure 5.0 m e reexecute 102 e depois 103. O presente reconciliado passa a ser 5.4 m, contra o presente previsto anterior de 5.5 m. A correção relevante é de -0.1 m; simplesmente forçar a posição para 5.0 m também apagaria dois movimentos que ainda estão pendentes.

Na apresentação, um deslocamento visual separado pode decair da aparência antiga até a posição corrigida da simulação. A colisão e a predição futura, porém, devem usar o estado corrigido imediatamente. Trate um teleporte como uma descontinuidade explícita, em vez de suavizá-lo através das paredes que estejam no caminho.

Fluxo de implementação

Defina exatamente o que um comando de entrada significa: tick, duração, botões e quaisquer valores quantizados. Compartilhe as regras de movimento sempre que for viável e inclua todo o estado necessário para a reexecução, como velocidade, modo de movimento e cooldowns. Apenas a posição pode não bastar para reconstruir o resultado seguinte.

Faça com que os efeitos reexecutados sejam identificáveis, para que a predição repetida não duplique áudio, partículas ou transações. O servidor valida a progressão dos comandos e as regras do jogo; receber de um cliente uma posição plausível não equivale a simular uma entrada válida. Limite o histórico armazenado e defina como recuperar o estado quando uma atualização for anterior ao estado disponível.

Limites e validação

A predição não consegue conhecer todas as ações remotas nem obstáculos recém-revelados. Correções frequentes podem indicar passos de simulação incompatíveis, estado de reexecução incompleto, geometrias diferentes ou incerteza genuína. Meça separadamente a frequência e a magnitude das correções, a idade dos comandos e o custo da reexecução.

Teste perda, duplicação e reordenação de atualizações, plataformas em movimento e entradas durante o respawn. Rejeite atualizações autoritativas obsoletas de acordo com a ordenação do protocolo. Ajuste a suavização visual só depois de confirmar que a simulação está correta: uma imagem suave pode esconder uma divergência persistente sem corrigi-la.

Fontes

[1] Client-side prediction and reconciliation — Gabriel Gambetta.

[2] Source SDK prediction implementation — Valve.