网络游戏：玩过去还是玩未来

几年前，我读了一系列关于网络物理的文章，其中包括一些很棒的演示电影，之后我对网络游戏的工作原理着迷了。我并不是真的理解它。当客户端和服务器之间有大约100毫秒的网络延迟时，游戏怎么可能是可玩的呢？我决定制作一个网络游戏的小演示，试着找出答案。然而，就像我开始的大多数项目一样，我在上面花了几个小时就放弃了。几个月前，我重新发现了它，并把它弄到了一个合理的完成状态。该演示展示了一款游戏的客户端和服务器状态，并允许您调整模拟的延迟。这让我非常欣赏用来制作快节奏游戏的聪明技巧，这些游戏可以在互联网上玩。特别是，我发现客户无论是在过去还是在未来都在玩这款游戏，这很令人惊讶，但它仍然能创造出一种互动的体验。

一个重要的教训是，即使是本地游戏也有延迟。让我们忽略键盘延迟或显示延迟之类的事情，它们中的每一个都可以很容易地增加约50毫秒的延迟。让我们考虑一下游戏循环，它包括读取输入，模拟世界，然后绘制世界。这意味着在按钮按下后，游戏直到下一帧才会响应。许多显示器最多可以显示每秒60帧(FPS)，这相当于平均8毫秒的延迟(均匀分布在0-16毫秒之间)。最初的一帧也可能只是记录玩家正在向前移动，但实际上直到下一帧才会将玩家向前移动，所以这意味着在您按下按钮和看到变化之间最多33毫秒。许多游戏的运行速度都比这慢，这就扩大了延迟。结论是，即使是你在本地游戏中得到的那种快速反应也不是瞬间的，在输入和看到更新之间实际上可能有大约100毫秒的延迟。

最简单的网络游戏模型，也是我的演示中实现的模型，是让客户端向服务器发送命令，并让服务器将状态发送回客户端，客户端显示这些命令。在此实施中，当您按下按钮进行操作(如向前移动)时，需要整个网络往返一次才能看到移动。“末日”和“地震”的最初版本使用了这种方法，因为它们是为本地网络而不是互联网设计的。地震是在家庭互联网普及的时候发布的，不管怎样，人们确实在互联网上玩游戏，只有在网络往返时间低的情况下才能奏效。在我的演示中，感觉可以播放高达50ms的单向延迟。

对我来说，最有趣的部分是，与服务器状态相比，这意味着玩家正在玩过去的游戏。我画了下面的图表，试图说明我的意思。客户端和服务器同时开始游戏，t=0。此时，播放器按下“向前移动”按钮，因此客户端将此消息发送到服务器。到达服务器需要一个时间单位/帧，因此在t=1时，服务器接收并处理按钮按下。在t=2处，服务器模拟玩家向前移动一个单元，并将状态发送给客户端。最后，在t=3，客户端接收更新的位置显示它。这意味着客户端的显示更新时间为t=3，而不是本地版本中的t=1。这会延迟一个网络往返时间(本例中为2个单位)。在任何时刻，客户端都比服务器晚一个时间单位，这就是我过去玩游戏的意思。

当我在模拟中尝试移动和射击时，我想我可以注意到哪怕是很小的延迟。然而，我觉得我可以适应它，这个游戏可以玩到大约50毫秒。超过这一点，它开始感觉到不可能的缓慢和真正令人不快。这意味着这个简单的模拟只对物理近距离玩家有效。根据gcpping.com的衡量，从我在纽约市的家中连接到Google Cloud的数据中心，我只能玩北美东半部(弗吉尼亚州、南卡罗来纳州和蒙特利尔)托管的游戏。

为了隐藏潜伏期的影响，现代游戏预测他们行动的效果。因此，客户现在是未来的，而不是过去的。让我们重新考虑一下我们的例子，在这个例子中，游戏开始，玩家立即开始向前移动，如下所示。在第一个时刻，客户端处理前移命令，因此将其发送到服务器。在下一个时刻，客户端预测前进一步，服务器收到消息。在第二个时刻(t=2)，客户端预测将前进另一步。服务器模拟移动并发送官方状态。在下一个时刻(t=3)，客户端接收到用户确实向前移动的确认。棘手的部分是

网络物理：让我感兴趣的原创系列文章。有关更多详细信息，请参阅系列索引。

Quake 3网络：通过审阅源代码来描述Quake 3是如何工作的。将它与最初的Quakeworld的工作方式进行比较很有启发意义，因为它在地震中增加了客户端预测。

客户端/服务器游戏中的延迟补偿方法：值得注意的是，这篇文章描述了Half Life如何使即时命中武器与客户端预测一起工作，以及这如何成为游戏设计的选择，因为有一些基本的必要的权衡。