Rollback netcode: replay determinístico e efeitos colaterais controlados

Avançar primeiro, corrigir depois

O rollback permite que o jogo avance enquanto algumas entradas remotas ainda são desconhecidas. Quando uma suposição se mostra errada, a simulação volta a um estado anterior e recupera o atraso com a entrada corrigida. O jogador deve receber resposta local imediata, mas a implementação precisa permitir refazer um trabalho que parecia já ter acontecido.

O contrato do replay

O rollback clássico baseado apenas em entradas exige uma simulação determinística a partir do mesmo estado e das mesmas entradas; este artigo trata dessa arquitetura. As variantes que sincronizam estado têm requisitos diferentes. A explicação de arquitetura da SnapNet cobre previsão de entrada, restauração e replay. [1] A interface de integração do GGPO exige callbacks para salvar/carregar o estado do jogo e para avançar um frame, o que faz da posse do estado uma responsabilidade da aplicação. [2]

Exemplo prático

Um cliente ilustrativo concluiu o frame 105 depois de prever a entrada remota do frame 102. A entrada real chega e é diferente. Restaure o estado salvo no fim do frame 101 e simule os frames 102, 103, 104 e 105 com a entrada corrigida e as entradas retidas de cada frame. São quatro frames reexecutados antes de qualquer novo frame.

Se um estado salvo ocupa 256 KiB, manter 8 desses estados custa 2048 KiB, ou 2 MiB, sem contar entradas, metadados e overhead de alocação. Esses tamanhos são hipotéticos, não resultados de benchmark. O estado salvo mais antigo também limita até onde este buffer específico consegue restaurar; ao contar, deixe explícito se os snapshots representam o início ou o fim de cada frame.

Fluxo de implementação

Faça um inventário de todo valor que afeta o gameplay futuro: ordem de criação de entidades, temporizadores, estado do gerador de números aleatórios, tempo de acerto dependente de animação e comandos em fila. Serialize ou reconstrua esses valores de forma reproduzível. Não use o horário do sistema (wall-clock time) nem a ordem de conclusão de operações assíncronas não controladas como entradas ocultas da simulação.

Execute duas vezes a mesma gravação de entradas e compare, frame a frame, hashes canônicos do estado. No primeiro desvio, examine as diferenças estruturadas do estado em vez de olhar apenas para a posição final do personagem. Depois, force rollbacks mesmo em uma conexão local. Faça o profiling da pior janela de replay suportada junto com o trabalho normal de renderização e simulação.

Efeitos colaterais e limites

Dê aos efeitos previstos identidades de evento estáveis. Um registro de efeitos (effect ledger) pode distinguir um som que já foi tocado de um evento recém-descoberto após o replay. Decida quais efeitos podem ser cancelados, quais podem terminar apesar de uma correção e quais resultados irreversíveis devem esperar pela confirmação. [1]

O determinismo pode falhar por causa do comportamento de ponto flutuante, da ordem de iteração ou de estado ausente. Janelas de previsão mais longas aumentam a exposição a correções e o trabalho de replay. Defina como recuperar quando a entrada for mais antiga que o histórico retido ou quando o orçamento de trabalho se esgotar. O atraso de entrada (input delay) pode ser um controle complementar deliberado; o rollback não elimina a latência nem garante que as correções sejam invisíveis.

Fontes

[1] Netcode architectures: rollback — SnapNet.

[2] GGPO integration interface — Tony Cannon and GGPO contributors.