networking - 客户端预测和服务器对账

Question

我读过一些关于客户端预测和服务器协调的文章，但我遗漏了一些部分，我参与了客户端预测的部分，但我不明白协调是如何完成的。我以这两篇著名的文章作为引用:

http://www.gabrielgambetta.com/fpm2.html

#2. So applying client-side prediction again, the client can calculate the “present” state of the game based on the last authoritative state sent by the server, plus the inputs the server hasn’t processed yet

http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

In effect the client invisibly “rewinds and replays” the last n frames of local player character movement while holding the rest of the world fixed

好的，我认为客户端收到了来自服务器的确认，但是输入是如何重新应用的？我可以用两种方式来解释这一点。

从客户端的角度来看，游戏循环每秒执行“x”次(每秒帧数)

第一:未处理的输入在同一帧中重新应用，因此这里的表达“隐形倒带和重播”非常合适，因为最终您在屏幕上看到的是重新应用上次输入的结果。

我没有看到这样做的好处，因为我认为将服务器更新中的最后 n 个输入重新应用到当前时间与保持客户端状态与更新前的状态没有区别，我们事先知道结果将是相同的。

第二:输入在连续帧中一一重新应用。一个人无法注意到正在重播的几帧，但我不禁想到，如果客户端经历了严重的延迟，他会注意到自己回到过去并重播了最后的“n”帧。

任何人都可以指出我正确的方向吗？谢谢

Answer 1

我知道您发布这个问题已经有一段时间了，但它在谷歌的提要上，所以我会回答。

I don’t see the benefit of doing this because I see no difference between re-applying the last n inputs from the server update to the present time and keeping the client state as it was before the update, we know in advance that the result will be the same.

协调的重点是与服务器同步。我们真的不知道我们的行为会产生什么结果。我们只是预测一下。有时结果实际上是不同的，我们仍然希望获得服务器上正在发生的事情的图像。

第一种方式绝对是要走的路。

第二种方式真的没有任何意义。请记住，播放器会定期收到更新。这意味着，在 200 毫秒的延迟下，他将始终看到过去大约 200 毫秒的角色。