代码之家 › 专栏 › 技术社区 › Kasper Holdum

多人游戏同步

synchronization networking c#

Kasper Holdum · 技术社区 · 15 年前

我实现了一个服务器/客户机架构,其中所有状态更改都发送到函数,验证并广播到所有连接的客户机。这工作得相当好,但是系统目前还没有在游戏的客户端实例之间保持同步。

如果服务器和特定客户机之间碰巧有5秒的延迟,那么他将在其他客户机之后5秒收到状态更改,从而使他与游戏状态不同步。我一直在寻找各种方法来实现客户端之间的同步系统,但到目前为止还没有找到很多。

我对网络编程很陌生,并不是那么天真地认为我可以自己发明一个工作系统而不需要投入大量的时间。不过,我一直以来的想法是保持某种时间系统,因此每个状态变化都会连接到游戏中的特定时间戳。这样,当客户机收到状态更改时,它将确切地知道更改发生在游戏的哪个阶段,并进而能够关联延迟。这种方法的问题在于 n 几秒钟后,游戏将在客户端继续,因此客户端将不得不及时回滚以更新状态更改,这肯定会变得混乱。

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

5 回复 | 直到 9 年前

Martin Harris 15 年前

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

有一些更先进的方法建立在这个概念的基础上,但这是一个很好的起点。

还可以描述如何在源引擎(上半场游戏的阀门引擎)中处理这个问题。 here ,原理基本上是相同的-直到服务器告诉您使用预测算法沿预期路径移动实体-但是本文处理这对尝试更深入地拍摄某个内容的影响。

Kevin 15 年前

我在这方面找到的最好的资源是Valve Software的这两篇文章:

Kylotan 15 年前

永远不会有办法保证实时多个视角之间的完美同步——物理定律使之不可能实现。如果太阳现在爆炸了,你怎么能保证半人马座α星上的观测者和我们地球上的观测者同时看到超新星呢?信息需要时间旅行。

因此,您的选择要么是精确地建模每件事,延迟可能会因查看器不同而不同(这是您当前拥有的)。或者在没有延迟的情况下对它们进行不准确的建模,并在观众之间进行广泛的同步(这就是预测/航位推算/外推的来源)。像实时策略这样速度较慢的游戏往往走第一条路线,速度较快的游戏走第二条路线。

尤其是,你不应该认为旅行所需的时间是恒定的。这意味着,在两种模型下,仅仅向移动实体发送开始和停止消息是不够的。您需要发送实际状态的周期性更新(通常为更快的游戏每秒数次),以便接收方能够纠正其预测和插值中的错误。

Lasse V. Karlsen 15 年前

您最好的选择是将更改从未来发送回客户机,从而在与其他没有延迟问题的客户机相同的时间点到达客户机。

Havenard 15 年前

如果客户端看到事件以服务器提供给他的速率发生,这是正常的方法(我已经使用了Ultima Online、Kalonline和一点魔兽世界的协议),那么这一瞬间的5秒延迟只会让他在一旦看到这些事件真的很快或接近立即通过,就像其他玩家会看到他“走”很快很短的距离,如果他的输出也延迟。之后一切又恢复正常。实际上,除了图形和物理规范化之外,我看不出有什么特殊需要使它正确同步,它只是同步本身。

如果你曾经在两台附近的电脑上玩过阀门游戏,你会注意到他们并不太在意诸如“你死的确切地点”或“你的尸体碎片飞到哪里”之类的小细节。这完全取决于客户端,完全受延迟的影响,但这无关紧要。

毕竟,落后的球员必须接受他们的条件,或关闭他们该死的鸸鹋。