Prever o próprio movimento

Você age com base no próprio input antes de o servidor responder e, quando os dois discordam, o seu cliente se corrige. Um erro aqui custa uma pequena correção visual e nada mais. Por isso, dos três mecanismos de predição, este é o único em que dá para ser agressivo sem risco.

A predição reaplica as regras declaradas, não é uma segunda cópia delas

O seu cliente não roda uma implementação paralela do movimento. Ele roda o mesmo modelo declarado que a plataforma roda — o modelo pertence ao Locomotion, e a predição só o aplica mais cedo. É por isso que os dois lados concordam na maior parte do tempo: um único conjunto de regras, aplicado duas vezes.

Então não existe uma operação “prever” para chamar, nem uma operação “corrigir”. A predição acontece porque o aspecto foi declarado previsível.

O que é previsto se declara por aspecto

A previsibilidade é uma declaração no aspecto da entidade, não uma chave global:

Um aspecto que o cliente consegue calcular — a posição a partir do seu próprio input — pode ser previsto.
Um aspecto que a autoridade altera por regras que o cliente não tem não pode ser previsto. Se o cliente não consegue deduzi-lo, chutar o valor produz um rollback que o jogador entende como o jogo mentindo.

O protocolo de correção e os dois números que o definem

O estado autoritativo chega com o número do último input que aplicou, então o seu cliente sabe exatamente quanto do próprio buffer ainda não foi confirmado. A partir daí:

Aceite o estado autoritativo.
Reaplique os inputs do buffer que vieram depois do input confirmado.
Reconcilie o resultado com o que você já estava mostrando.

Dois números declarados definem a sensação. O limiar de divergência: abaixo dele, a correção é suavizada; acima, o cliente salta para o estado da autoridade e reaplica os inputs. E o limite do buffer de inputs não confirmados: estourá-lo não é comportamento indefinido — a degradação é declarada e observável, então um cliente com conexão ruim sabe que parou de prever, em vez de ir se desviando em silêncio.

A divergência é observável pelo cliente que a teve, e só por ele. Você consegue saber que a sua predição foi corrigida e em quanto — útil para ajustes e para mostrar ao jogador um indicador de conexão preciso. Você não consegue ler a divergência de outra pessoa: o tamanho de um erro de predição é informação sobre a conexão dela, não sobre o jogo. A correção acontece no cliente, porque o estado da autoridade é o que todos os outros já estavam vendo.

Se você vem de outra ferramenta

Mover 2.0 do Unreal. A estrutura é conhecida: inputs marcados com o tick, um modelo de movimento, correções vindas da autoridade. A diferença é onde o modelo fica — aqui você o declara e a plataforma o simula, então não existe um componente de movimento nosso para você estender ou substituir.
Netcode de rollback e replay, como no Photon Fusion. Reaplicar os próprios inputs não confirmados depois de uma correção é o mesmo mecanismo, e ele está aqui por completo. O que, de propósito, não está aqui é re-simular o mundo depois do fato — veja em Lag Compensation o que acontece no lugar disso, e por quê.

O que isto não cobre

As entidades dos outros jogadores não são previstas, são exibidas — isso é Como mostrar outros jogadores. Julgar um tiro na linha do tempo do atirador é um mecanismo do servidor e fica em Lag Compensation. E nenhum dos três se aplica quando o modo de autoridade da sala (room) é externo: aí o tick pertence a quem o executa, e a predição também.