好的多人/ mmo客户端服务器游戏是否在运动计算中使用延迟？

Question

这里有几个问题。

想象一下，我有一个客户端A将要向服务器发送以下消息：“START START VVEMENT FORWARD”。

服务器不会立即收到此消息，因为延迟会导致延迟。

问题1：ping（或更好：round trip time）是客户端向服务器发送消息并接收响应所需的时间。如果您可以忽略服务器注意到它已收到消息并开始发送响应（这应该非常短）所需的时间，这是否意味着以下内容？

1. 客户端向服务器发送内容所需的时间=往返时间/ 2
2. 服务器向客户端发送内容所需的时间=往返时间/ 2

因此，当客户端A发送该消息时，服务器将在客户端发送消息后的往返时间/ 2毫秒内接收该消息。这引出了我的下一个问题。

问题2：如果客户端首先发送包，然后等待往返时间/ 2毫秒，然后实际执行该命令客户端（在这种情况下：向前移动）以补偿延迟/滞后？< / p>

现在，服务器将向所有附近的玩家发送以下消息：“客户端A现在正在向前移动”。然后，这些客户端将确保客户端a的角色开始移动，这将引导我进入下一个问题。

问题3：客户端是否应该收到其他客户端已移动的消息，并考虑到此消息是由服务器往返时间/ 2毫秒发送的？因此，用于运动计算时间戳的当前时间应减少往返时间/ 2？

我认为所有这些方法都会确保客户端之间的同步得到改善，因为延迟会被考虑在内。这是正确的做事方式吗？大多数其他好的多人游戏都这样做吗？您想提供的任何评论，建议，替代方案或随机但相关的呼喊？提前谢谢。

Answer 1

我认为在大多数mmo中，除非出现严重延迟，否则您的客户主要在没有与服务器交互的情况下移动。服务器借助客户端发送到服务器的消息再现移动。因此，如果服务器滞后，客户端将停止接收来自服务器的反馈并恢复到服务器确定您所处的位置。这就是为什么你会在糟糕的滞后期间跳回几帧。这样服务器也可以控制你的速度，这样你就不会速度快。如果您的客户端以超过服务器确定的速度的特定速率移动，您只需跳回额外的帧。

如果没有服务器在一定时间内给出响应，其他客户端根本不会让您移动。这是您遇到“冻结滞后”的时间。

当然也会出现服务器只占用客户端发送的位置并盲目信任它的情况。这些游戏通常容易受到传送黑客攻击。

当涉及到其他玩家的位置时，确实有一个延迟，如果你拿两台电脑，连接到诸如哇的游戏并同时移动这两个角色就可以看到。您会看到，在您开始移动他之后，非本地角色将在两台计算机上开始移动。

客户通常会有某种滞后补偿。因此，如果另一个玩家朝某个方向移动然后停止，您的客户仍将模拟该玩家的移动，直到您从服务器收到他改变方向或停止移动的消息。这就是为什么其他玩家可以在ping高时来回跳转的原因。这也是为什么当你的客户从服务器接收位置时，当你遇到lagspikes然后回到他们的真实位置时，玩家似乎只是滑动/跑/走。

当然，这会从引擎变为引擎，但这是一个相当普遍的方法。

编辑：忘了补充一点，服务器也常常使用滞后补偿。如果你遇到某个mmo范围内的人，那么该人可能不在服务器视图的范围内。因此，如果你真的处于彼此的范围内，那么服务器会为你的客户带来延迟并尝试匹配。

Answer 2

Answer 3

对于Q1来说，这看起来是正确的。

Q2：我过去这样做的方式是：如果你想让事情做出反应，立即开始在客户的模拟上执行动作，那么服务器就会在游戏时模拟前进。即客户端知道它开始的游戏模拟时间是什么时间，所以服务器也可以在那时启动它（注意：这总是从服务器当前的时间点开始倒退，所以你必须及时保存状态去做这个）。

问题3：客户真正需要知道他们在X时刻模拟，服务器说事件{A，B，C}发生在时间{X，Y，Z}。然后，客户端和服务器可以使用相同的信息模拟转发，并且通常保持同步（除非发生同时发生冲突）。在这些情况下，您可以让服务器重新同步，这样您通常会在相当紧密的误差范围内获得最佳平滑体验。

如果你的目标是改善对延迟的看法，你也可以尝试信任客户。

Answer 4

有几种网络模型可以解决这些问题;

在网络游戏中，你需要同步两件事，一件是时间，另一件是空间。

1. 一种名为lockstep的网络游戏模型;

你应该看看empire2游戏工作室时代写的文章，它描述了锁步模型的细节。

在此模型中，客户端和服务器逐帧运行游戏逻辑，例如，RTS使用100ms作为帧，服务器和客户端将同步帧ID，这意味着同步时间。

客户端在第50帧，发送命令MoveForward，但不立即运行，客户端将告诉服务器在第51帧运行move命令; 然后当第51帧到来时，服务器和客户端将同时运行命令。 所以客户端和服务器逻辑是一样的。

在这种模型中，在第50帧，客户端和服务器可能会运行在第49帧发出的命令，因此客户端输入反馈总是有100ms或更长的延迟。

客户端和服务器之间的延迟不仅包含网络RTT，还包含逻辑帧延迟，即100ms;

在这个模型中，为了同步空间，你需要使你的客户端代码和服务器代码具有确定性，因此它们只能同步命令和frameId，没有必要同步实体状态。

在这个模型中，输入反馈很大，所以你需要播放动画或声音来帮助玩家忽略滞后。

1. 其他型号使用状态同步

在这个模型中，我们还需要同步时间，因此客户端会猜测服务器中的当前时间。

当玩家输入时，客户端立即移动，然后将移动命令或客户端目标pos发送到具有当前服务器时间戳的服务器，该时间戳由客户端估计。

当服务器收到客户端命令时，它知道客户端在服务器时间发出命令的时间，它将尝试使用外推法运行命令。

所有其他客户端将收到命令，其服务器时间，所有其他客户端将尝试推断该命令。

这些技术包括客户端预测，服务器延迟补偿，服务器实体插值。

在这个模型中，客户端输入反馈很短，但是对于某些脉冲命令，比如使用技巧，我们仍然需要使用锁步方法，用动画，声音和粒子效果来构成输入反馈时间。

在网络游戏中，至少有两种命令，首先是移动，命令会运行一段时间，就像一个稳定的流，它具有连续性属性。

另一个喜欢用冷时间的技巧，命令效果会有冲动，我们应该区别对待它们。

Answer 5

一些好的多人游戏使用一种机制，允许玩家在繁重的往返时间内顺利移动，允许客户决定并将玩家的位置发送到服务器。有欺诈检查机制，但客户是免费的。因此，如果往返时间变得很糟糕，那么当您顺利移动时，您会看到人们从一个地方跳到另一个地方。甚至一些MMO游戏也允许客户在未经服务器同意的情况下处理单个播放器内容，从而将其带入下一个阶段。只有统计数据，战斗报告和其他一些信息会被发送到服务器，同时还有很少的欺诈检查数据。