Slides em Português baseados no livro "Multiplayer Game Programming".

1. Tratamento de Latência
Prof. Fernando Vieira da Silva, MSc.

2. Terminal Burro
● A verdadeira simulação está
no servidor, e sempre ½ RTT
à frente
● Quake e outros jogos da
época enviavam informações
para o servidor, que
processava e retornava o
resultado, que era exibido
● Essa técnica conhecida
como terminal burro é um
algoritmo conservador, mas
a latência pode ser
perceptível

3. Interpolação no Cliente
● Não altera a posição do
personagem
automaticamente quando
recebe do servidor
● Ajusta (aka. Interpola) para
a posição atual do servidor
usando um filtro de
percepção local
● Interpolation Period deve
ser maior que o packet
period, para que o novo
estado chegue assim que a
interpolação terminar

4. Interpolação no Cliente
● Latência é de aprox. ½ RTT
+ Interpolation Period
● Logo: para reduzir latência,
IP deve ser o mínimo possível
● Logo: IP deve ser igual a
PP
● O servidor pode avisar o PP
ao cliente, ou o cliente pode
calcular usando o RTT.
● Também é um algoritmo
conservador

5. Predição no Cliente
● Servidor está sempre ½ RTT à frente do cliente
● Para exibir um estado mais atual, o cliente precisa trocar a interporlação
pela extrapolação (aka. previsão)
● Cliente pode sempre simular outro ½ RTT e exibir o resultado

6. Predição no Cliente
● Primeiro o cliente precisa calcular o RTT
● Obs: os relógios do cliente e servidor não estão necessariamente
sincronizados
● O cliente envia o pacote e conta o tempo até a resposta

7. Dead Reckoning
● Se o cliente tem uma cópia do código do servidor, pode simular o
comportamento de objetos determinísticos (ex: balas, inimigos, etc)
● Mas há um tipo de objeto totalmente não-determinístico: jogadores
humanos

8. Dead Reckoning
● O que fazer?
● Tentar adivinhar o que vai acontecer, e corrigir se estiver errado
● Esse processo é chamado de Dead Reckoning
● Trata-se de um algoritmo otimista
● Exemplo: RTT = 100ms. Aos 184ms, o cliente recebe a informação que o
servidor está em Pos (134,0) e Vel (0,1), refaz a simulação e descobre a Pos
(134, 50) e Vel(0,1)

9. O que fazer se a simulação errar?
● Atualização instantânea: apenas alterar a posição do objeto (o jogador
pode perceber o objeto “saltando”)
● Interpolação: ajustar a posição do jogador “suavemente” aos poucos
● Ajuste de estados de segunda ordem: Se a velocidade do objeto se
alterar, por exemplo, pode-se alterar a aceleração aos poucos até atingir a
velocidade desejada.

10. Previsão de Movimento de Client, e
Replay
● Dead Reckoning não resolve para o jogador local…
● Após pressionar um botão, ainda precisa enviar os dados para o servidor,
que processa e retorna, para então concretizar o movimento...

11. Previsão de Movimento de Client, e
Replay
● Solução: O client simula os movimentos do jogador local sem esperar o
retorno do servidor
● Quando o servidor recebe, também simula e atualiza o estado do cliente

12. Previsão de Movimento de Client, e
Replay
● Solução: O client simula os movimentos do jogador local sem esperar o
retorno do servidor
● Quando o servidor recebe, também simula e atualiza o estado do cliente
Se outro jogador colidir com o jogador local e o servidor
retornar uma posição diferente
Como o cliente pode ajustar a posição do jogador local
quando receber essa nova informação do servidor?

13. Previsão de Movimento de Client, e
Replay
● Problema: Se o servidor retornar uma nova posição para o jogador local,
INTERPOLAÇÃO NO CLIENTE NÃO FUNCIONA! (pareceria que o jogador
“perdeu o controle” de seu personagem)
● Também não dá para ignorar a resposta do Servidor…
● Solução: Ao receber a posição do servidor (que estará ½ RTT atrasada), o
cliente usa as informações REAIS do jogador local no último ½ RTT e obtem
a nova posição do jogador.

14. Truques para esconder latência
● Problema: Quando um jogador atira/usa algum poder, espera-se ver o
resultado imediatamente
● Solução: Jogos usam animações antes do golpe, que duram 1 RTT.
● Enquando a animação é exibida, a informação é enviada para o servidor,
que retorna a resposta
● Dead Reckoning avança o projétil ½ RTT à frente, e parece não haver
latência.

15. Server rewind
● Problema: Os truques para esconder latência não resolvem para armas de
longo alcance e instant-hit (ex: sniper)
● Solução Valve Source Engine: Fazer com que o servidor VOLTE ao
estado em que estava quando o jogador mirou e atirou (½ RTT atrás)
● Efeito colateral: o oponente pode ser atingido, mesmo que pense que está
protegido, se o atirador tiver muito lag

16. Ajustes para Server rewind
● Use interpolação no cliente, sem dead reckoning para jogadores
remotos: O servidor precisa saber o que o cliente está vendo, então o client
não pode fazer previsões
● Use previsão de movimento de client e replay: Apesar de não poder
prever o jogador remoto, deve-se manter para o jogador local, para evitar
percepção de latência
● Registre a visão do cliente em cada pacote enviado para o servidor:
Envie o ID dos frames que estão sendo interpolados e o percentual de
interpolação, para que o servidor saiba exatamente o que está sendo visto
pelo cliente
● No servidor, armazene os estados dos objetos relevantes dos últimos
frames: Quando um pacote chega do cliente, é necessário alterar os objetos
relevantes para os estados anteriores (momento que o cliente atirou),
usando interpolação

17. Fim!