Como sincronizo cliente e servidor ao enviar alterações na velocidade do player?

Estou implementando uma previsão do lado do cliente. A maioria das explicações pressupõe que o cliente envie mensagens como " Mover meu player em 1 posição ". E se eu enviar mensagens como " Defina a velocidade do meu player como x "?

gráfico explicativo; mostrando mensagens enviadas e posições calculadas no cliente e servidor ao longo do tempo

No cliente, o jogador define sua própria velocidade (por previsão do lado do cliente) antes do servidor, resultando na perda de sincronia dos dois. Esse problema persiste mesmo considerando a latência média.

Como posso resolver isso?

networking client-server movement-prediction

— Blu3
fonte

Você deve enviar dados redundantes, o que aqui significa enviar a posição e a velocidade. Mesmo se você estiver fora de sincronia, o fato de ter a posição e a velocidade permite corrigir a trajetória usando uma função de interpolação.

Em seguida, usar alguns truques, como animações atrasadas, acelerações, etc., permite ocultar a latência.

Edit: Eu assumo que o servidor é autoritário.

— Thelvyn
fonte

Obrigado pela sua resposta. Sim, o servidor é autoritário, mas mesmo que eu envie dados redundantes com a minha velocidade, o cliente poderá corrigir seus erros, mas leio frequentemente coisas como "Se o cliente / servidor usar código compartilhado para suas entidades, erros de previsão nunca realmente ocorrerão", mas no meu caso, eles SEMPRE ocorrerão um pouco, o que causaria gagueira por toda parte.

— Blu3

@ user13842 o cliente sempre ficará fora de sincronia; você deve corrigir a posição e a velocidade do lado do cliente, como disse Thelvyn, de acordo com o servidor que o envia. Dessa forma, você não terá o movimento da gagueira, a menos que seu cliente esteja completamente fora de sincronia, e será necessário ajustar os valores, pois a correção levaria muito tempo.

— Dreta 24/10/12

Esse é o principal motivo para usar uma função de interpolação. Você não pode evitar a latência; portanto, é necessário corrigir o movimento de maneira suave. O cliente e o servidor simulam o mundo, mas o cliente precisa ouvir o servidor e executar as correções. Algumas técnicas usadas nas redes do Source Engine: developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

— Thelvyn

-lo de brevemente mencionado neste google talk também, ele deve ficar com a ideia através youtube.com/watch?v=Prkyd5n0P7k#t=18m47s

— dreta

Eu encontrei outra solução para esse problema em particular. Acrescento o tempo em que o cliente aplicou sua entrada em cada pacote. O significado # 1 teria tempo: 0 e a segunda vez: 100. Agora o servidor sabe que o cliente pressionou o botão no momento: 100 e não antes.

— Blu3