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

Question

这里有几个问题。

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

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

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

1. 花费的时间为客户发送成才服务器=往返时间/ 2
2. 花费的时间服务器送东西给客户端=往返时间/ 2

因此，当客户端A发送该消息时，服务器应该在客户端发送消息之后往返/ 2毫秒接收该消息。这导致我到下一个问题。

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

现在，服务器会发送以下消息给所有附近的玩家：“客户A现在正在向前移动”。然后这些客户会确保客户a的角色开始移动，这导致我接下来的问题。

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

所有这些方法都会在我的脑海中确保客户端之间的同步得到改善，因为考虑了延迟。这是做事的正确方式吗？大多数其他好的多人游戏能做到这一点吗？任何意见，建议，选择或随机但相关的留言，你想给？提前致谢。

Answer 1

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

其他客户端不会让你动弹没有一定量的时间内，来自服务器的响应。这是你遇到“冻结滞后”的时候。

当然也有OCCURENCES所在服务器简单地采取客户端发送位置和盲目信任它。这些是通常易受传送黑客攻击的游戏。

当涉及到的其他球员确实存在的位置是一个延迟，由此可以看出，如果你把两台电脑，连接到游戏如WOW和同时放移动两个字符。你会发现，在你开始移动他之后，两个电脑上的非本地角色会开始移动。

客户通常有某种滞后补偿。因此，如果另一位玩家正朝某个方向移动然后停下来，您的客户仍然会模拟该玩家的移动，直到您从服务器收到他改变方向或停止移动的消息。这就是为什么其他球员可以在平稳时跳来跳去的原因。这也是为什么玩家看起来只是在您碰到低点时滑动/跑步/走开，然后在您的客户从服务器接收位置时返回其真实位置的原因。

当然，这个从发动机到发动机的变化，但这是一个相当普遍的问题。

编辑：忘了补充，这是很常见的服务器也使用滞后补偿。如果您以范围内的某个mmo命中某个人，该人可能不在服务器视图范围内。因此，服务器会为您的客户端提供延迟，并尝试匹配，如果您真的在彼此的范围内。第一季度：

Answer 2

一些优秀的多人游戏通过允许玩家决定并发送玩家位置到服务器，即使在往返时间较长的情况下也允许玩家顺利移动。有欺诈检查机制，但客户端是免费的。所以如果往返时间变得怪异，你会看到有人在你移动的过程中从一个地方跳到另一个地方。即使是一些MMO游戏，它也允许客户在未经服务器同意的情况下处理单个玩家内容，从而进入下一个阶段。只有统计数据，战斗报告和其他一些信息才会被发送到服务器以及很少的欺诈检查数据。

Answer 3

：这对我来说很合适。第二季度：我过去这样做的方式是：如果你想让事情感觉到反应迅速，在客户端的模拟中立即开始执行动作，然后服务器在游戏时间模拟游戏时间，行动。即客户端知道它开始的游戏模拟时间是多少ms，所以服务器也可以在那个时候启动它（注意：从服务器的当前时间点开始，这个时间总是倒退，所以你必须及时保存状态去做这个）。

Q3：客户端只有真正需要知道，他们是在一次X模拟，服务器说，事件集{A，B，C}发生在次{X，Y，Z}。然后，客户端和服务器可以使用相同的信息进行模拟，并且通常保持同步（除非发生同时冲突）。在这种情况下，您可以让服务器重新同步事物，这样您通常会在相当紧密的错误和最平滑的体验中结束。

如果你的目标是改善延迟的感觉你可能也只是尝试信任的客户端。

Answer 4

这是一个老问题，但我最近研究出类似的代码，所以也许这会帮助某人。

是延迟在计算中总是有用的。但它比RTT稍微复杂一些。往返时间总是在变化......您的网络代码可以保持平均值，但与平均值的差异很大。

本地客户端，远程客户端和服务器都使用算法预测当前位置。下面的数据是接近典型：

• 时间：吨
• 放置：位置（X，Y，Z）和方向（X，Y，Z，W）
• 机芯：线性运动矢量给予与长度为速度（X，Y，Z），并 旋转运动向量赋予轴线与长度为转速（X，Y，Z）

方向您需要一个从[T，P推断算法，M]设置为simtime。我不会在这里提供这些。

当客户端在[T，P，M]的船舶驱动器中记录更改时，在T + deltaT之前不会到达服务器。但是，如果deltaT在典型网络延迟的容忍范围内，服务器可以说“是的，它发生在T，我接受”。否则，它可能需要纠正客户说“没有那么容忍，它发生在我的时间T'”，在这种情况下，客户将不得不重新从服务器的纠正的一个更新所有随后驱动的[T，P，M]变化（这意味着你需要保持一个队列或列表）。

下一个客户端将在T + deltaT + differentdeltaT获取它。它不可能改变它已经模拟的东西，所以如果它不延迟它的模拟，它将跳过远程船，你会看到一个混乱的框架。这就是为什么远程驱动的船只应该使其模拟延迟一段时间，持续时间大于2 *typicalδT。这应该是一个恒定的延迟，或者逐渐改变的延迟，严重滞后的时候，你会看到混蛋帧仍然

可以流畅的额外平滑代码的所有抽搐，但不这样做，直到你的代码，否则完美无瑕，因为它会让人不可能看到问题出在哪里。

你必须有一个很好的同步时间参考。很多代码都比较滑落（例如RakNet没有（或没有）非常好）。这里有一个很好的提示：短时间内，你可以假定每个人的时钟都以相同的速率运行，你只需要计算出偏移量是多少，所以保持一个最大和最小偏移量的窗口，并在学习时关闭它;从长远来看，您需要补偿时钟快速或慢速运行的客户，因此，如果您确实知道必须打开窗口，请打开该窗口。您必须使用单调递增的本地时间源，并且不要使用处理器速度（现在是可变的）。

不，当本地“头像”移动时不要延迟本地模拟。这看起来太没有反应了。你可以稍微延迟一段时间（最多50毫秒）以帮助改善同步，但是一直延迟到RTT会使你的游戏看起来令人沮丧地失去响应。为本地延迟设置一个选项并播放它，因为一个小的一致延迟是可以接受的，并且可以改善同步。但这不是必要的，可能会导致很多问题，所以我建议最后一次执行该代码。 （如果你正在尝试做一个FPS近战游戏，你需要做这个，所有其他的帮助你可以得到）。

至于防止欺诈与模拟平滑：首先，客户不应该从最后一个已知的位置推断，当官员的位置发生变化时。它应该注册一个调整矢量，然后慢慢地从旧路径移动到新路径以获得平滑（但就像我上面所说的那样，最后执行此代码或者将屏蔽其他错误）。其次，服务器应该容忍大范围的延迟......即使在同一个以太网上的机器上，数据包延迟通常会运行5ms到100ms左右......这是一个很大的范围。当然，你需要把它关掉，并说“如果你说你在时间T移动，但我在T + some_large_number得到了数据包，那么我认为你正试图调整过去并对我说谎。” some_large_number不应该比平均RTT大得多，以保持诚实。

模拟不会严格同步。他们应该在互联网上停留不超过400毫秒，但肯定会在滞后时间以外流失到30秒或更长时间，而且你需要容忍那些因为它们并不稀有的东西。鉴于互联网受铜缆中光速的限制，您可以始终期望单向延迟通常至少为您的远端客户100ms，通常为500ms或更长。

因此我强烈建议你不要试图通过互联网混战的FPS游戏（一些大公司尝试，但总是有麻烦）。如果您使用投射物（通过在一次模拟中快速运行它们并在另一次模拟中运行速度较慢），您可以执行一些技巧，以便即使计时关闭，它也会显示。另外，FPS游戏使用命中检测基于攻击者模拟的规则......当攻击者知道他已经死于目标并且未命中时，感觉更加错误，然后当防御者知道他已经挡住并被击中时无论如何。你必须选择一个或另一个，并且从心理上来看，这是如何完成的。近战需要一定程度的同步，这是坦率的不可能的，大多数游戏公司不会触及MMORPG FPS近战，而是使用自动瞄准（尝试玩Mortal Online，你会明白我的意思）。

祝你好运。

Answer 5

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

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

1. 的网络游戏模式叫步调一致;

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

在由帧此模型，客户端和服务器运行的游戏逻辑框架，例如，RTS使用100毫秒，帧，服务器和客户端将同步帧ID，这意味着同步时间。

客户在第50帧，发送命令MoveForward，但不立即运行，客户端会告诉服务器以51帧运行移动命令; 然后当框架51到来时，服务器和客户端将同时运行命令。 因此客户端和服务器逻辑将是相同的。

在这样的模型中，在第50帧，客户端和服务器将运行在框架49也许发出的命令，所以有在客户端输入反馈送花儿给人100毫秒或更多的延迟。

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

在这个模型

，同步空间，你需要让你的客户端代码和服务器代码确定性，所以他们只能sync命令和frameId，有没有需要同步实体状态。

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

其他车型使用状态同步

在这个模型中，我们还需要时间同步，所以客户端将在服务器猜测当前时间。

当玩家输入时，客户端立即移动，然后发送移动命令或客户端目标位置到服务器与当前服务器时间戳，这是由客户端估计。

当服务器接收到客户端命令时，它知道客户端在服务器端发出命令时，它会尝试运行外部命令。

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

这些技术包括客户端预测，服务器滞后补偿，服务器实体内插。

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

在网络游戏中，至少有两种命令，第一种就像运动，命令会运行一段时间，就像一个稳定的流，它具有连续性的属性。另一方面喜欢用冷时间技能，指挥效应会冲动，我们应该以不同的方式对待他们。