Lag Compensation

Este é o mecanismo do servidor, e o erro dele custa a vida de um jogador — em favor de quem tem a pior conexão. Tudo nesta página parte dessa assimetria.

A pergunta que ele responde é bem específica: o que o atirador realmente viu? Uma ação pode trazer um momento de visualização (view time), o tick que o ator estava vendo quando agiu, e a plataforma restaura as poses dos alvos nesse tick para que o tiro seja julgado pelo que estava na tela dele.

O momento de visualização é uma alegação, não um fato

Ele vem do cliente, então é uma afirmação de quem chamou e é tratado como tal. Duas consequências:

A janela de compensação é limitada, e fora dela a plataforma recusa. Ela não extrapola para ajudar: uma recusa é uma decisão que você vê; uma extrapolação silenciosa, não.
Ler o estado passado de um alvo continua obedecendo à visibilidade. Perguntar sobre um tick histórico não é um jeito de contornar o Visibility — o que você não podia ver naquele momento, também não pode ler agora.

E “o acerto não valeu” é um veredito, não um erro: uma resposta bem-sucedida, com um motivo legível por máquina.

O que sofre rollback é declarado, e não é tudo

Fazer rollback de tudo gera abates duplos: dois jogadores atiram um no outro, os dois são retrocedidos a um momento em que ambos estão vivos, e os dois acertam. Não fazer rollback de nada anula a própria compensação de lag. A fronteira entre os dois extremos é uma lista declarada.

O retrocesso em si fica aqui, e não nos módulos retrocedidos. O anel de histórico restaura as poses do tick em disputa, e então o Collision responde à pergunta de sobreposição de sempre sobre essas poses — o módulo de colisões não tem histórico próprio, e nada nele sabe o que é um tick de visualização. O próprio anel é a trilha de histórico da entidade, não um segundo armazenamento.

A decisão é tomada no passado; o efeito vale no presente

A compensação de lag responde a uma pergunta sobre o momento de visualização do atirador. As consequências — dano, morte, recompensa — se aplicam ao estado atual. O que aconteceu entre o momento de visualização e o momento da decisão não é cancelado nem recalculado.

Um jogador pode atirar depois de ser abatido

Um jogador pode disparar depois de ter sido abatido pelo tiro retrocedido de outra pessoa. Isso é intencional: cancelar o disparo exigiria re-simular o mundo em cima de um retrocesso que não garante reprodutibilidade, o que criaria divergência em vez de eliminá-la.

A re-simulação no servidor está fora do escopo. Recalcular consequências a partir de uma nova verdade exige um ponto de referência fixo que o estado em ponto flutuante não oferece. Fica tudo aquilo em que o módulo se apoia: o cliente reaplicando os próprios inputs não confirmados (Prever o próprio movimento) e a compensação de lag como leitura do passado para uma única decisão. É assim que o favor-the-shooter funciona na prática.

Se você vem de outra ferramenta

Compensação de lag favor-the-shooter, como a da maioria dos shooters competitivos: é o mesmo mecanismo, e é disso que esta página trata.
Netcode de rollback completo. O retrocesso está aqui; a re-simulação do mundo depois dele, não, e o parágrafo acima explica por quê. Se o seu design depende de recalcular consequências depois do fato, fale com a gente sobre essa dependência cedo, em vez de descobri-la tarde.

Vale saber também

A implementação pode ser sobrescrita. Se o seu jogo precisa de outra regra de compensação, você pode substituir a nossa, e a substituta declara quais das declarações ela respeita.
Não há pontos de extensão no caminho de predição e correção. Esse caminho roda na taxa de tick.
Nada disso se aplica com autoridade externa. A compensação de lag existe para as salas (room) que a simulação da plataforma executa. Quando o tick pertence ao servidor de jogo de um estúdio ou a um cliente mestre, a compensação é de quem o executa — veja Quem executa o tick.