多人游戏同步

Question

我已经实现了一个服务器/客户端体系结构，其中所有状态更改都发送到该函数，验证并广播给所有连接的客户端。这很有效，但系统并没有保持游戏的客户端实例之间的同步。

如果在服务器和特定客户端之间发生了5秒的延迟，那么他将在剩余客户端5秒后收到状态更改，从而导致游戏状态不同步。我一直在寻找各种方法来实现客户端之间的同步系统，但迄今为止还没有发现。

我是网络编程的新手，并不那么天真地认为我可以自己创造一个工作系统，而不用花费大量的时间。然而，我一直在想的是保持某种时间系统，因此每个状态变化都会连接到游戏中的特定时间戳。这样，当一个客户收到状态改变时，它会准确地知道游戏的哪个时期发生了改变，并且反过来能够关联滞后。这种方法存在的问题是，在那些时间滞后的游戏中，客户端会继续游戏，因此客户端将不得不及时回滚以更新状态更改，这肯定会变得混乱。

所以我正在寻找论文讨论的主题或解决它的算法。也许我对整个多人游戏系统的设计是有缺陷的，因为客户端的游戏实例不应该更新，除非从服务器接收到概念。现在客户只是在游戏循环中更新自己，假设任何状态都没有改变。

Answer 1

对此的基本方法是所谓的Dead Reckoning和一个相当不错的文章可以在这里找到。基本上它是一个预测算法，用于在服务器更新之间的时间猜测实体位置。

在这个概念的基础上有更先进的方法论，但这是一个很好的起点。

---

同样的这是如何在源引擎处理（Valve的第一个半条命游戏引擎），可以发现here的描述，其原理基本上是相同的 - 直到服务器告诉你，否则使用预测算法将实体沿着预期路径移动 - 但本文处理了这种尝试更深入地拍摄某些东西的效果。

Answer 2

您最好的选择是从未来将更改发回客户端，从而在相同时间点为客户端发送更改，而不会出现滞后问题。

Answer 3

我已经在这方面找到的最好的资源是由Valve软件这两篇文章：

• Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization
• Source Multiplayer Networking

Answer 4

如果客户看到事件的服务器是发生率喂它，这是正常的做法（我已经使用了Ultima Online，KalOnline和一些魔兽世界的协议），那么这个瞬间5秒的延迟只会让他接受这5秒的事件我会立即看到那些事件真的很快或者接近瞬间传递，因为其他玩家如果他的输出延迟也会看到他“很快行走”很短的距离。之后，一切都会正常流动。实际上，除了图形和物理规范化之外，我看不到任何特殊的需求来使它正确同步，它只是同步自己。

如果你曾经在两台电脑附近玩过Valve游戏，你会注意到他们并不在乎诸如“死亡的确切位置”或“尸体死亡的地方”等小细节。这完全取决于客户端，完全受延迟影响，但这是无关紧要的。

毕竟，落后的球员必须接受他们的状况，或关闭他们该死的eMule。

Answer 5

永远不可能有办法保证实时跨多个视点的完美同步 - 物理定律使它不可能实现。如果太阳现在爆炸了，你怎么能保证阿尔法半人马星座上的观测者能够在地球上同时看到超新星？信息需要时间旅行。因此，您的选择是要么准确地建模每件事物的准确度，以便查看者之间的延迟时间不同（或者您目前正在使用这种方式），或者在没有延迟的情况下对其进行准确建模，并在观众之间进行大致同步（这是预测/推算/推算进来）。像实时战略这样的较慢的游戏往往走第一条路线，更快的游戏走第二条路线。

尤其是，您绝对不应该假设旅行所需的时间将保持不变。这意味着仅仅发送启动和停止消息来移动实体在两种模式下都是不够的。您需要定期更新实际状态（对于更快的游戏，通常每秒更新几次），以便收件人可以更正其预测和插值中的错误。