处理网络游戏的延迟问题

时间:2008-09-03 20:32:26

标签: networking latency dead-reckoning

我正在考虑建立一个联网游戏。我对此有点新意,并且已经遇到了很多问题,试图为航位推算和网络延迟制定一个好的计划,所以我很想看到关于这个主题的一些好的文献。我将描述我考虑过的方法。

最初,我只是将玩家的输入发送到服务器,在那里进行模拟,并将游戏状态的变化广播给所有玩家。这使作弊变得困难,但是在高延迟下,事情有点难以控制,因为你不会立即看到自己行为的结果。

This GamaSutra article有一个解决方案可以节省带宽,并通过在客户端上进行模拟使本地输入看起来很流畅,但它似乎会在窗口中防止欺骗。此外,当玩家开始操纵环境,推动岩石之类的时候,我不知道该怎么办。这些先前中立的对象将暂时成为客户端发送PDU所需的对象,或者可能是多个玩家同时执行的对象。谁的PDU会赢?每个玩家何时停止双重跟踪物体(与死亡计算版本进行比较)?天堂禁止两名玩家参加相扑比赛(例如开始互相推进)。

This gamedev.net bit显示gamasutra解决方案不合适,但描述了一种不能真正修复我的协作巨石推动示例的不同方法。我发现的大多数其他东西都是针对射手的。我希望看到一些更适合像SNES Zelda这样的游戏的东西,但需要更多的物理/动力。

  • 注意:我不是在这里询问物理模拟 - 其他图书馆已经涵盖了这些。尽管存在网络延迟,但只是让游戏变得流畅和反应的策略。

5 个答案:

答案 0 :(得分:21)

查看Valve在Source Engine中的表现:http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

如果是第一人称射击游戏,你可能需要深入研究他们提到的一些主题,例如:预测,补偿和插值。

答案 1 :(得分:11)

我找到了Glenn Fiedler的this network physics blog post,而且下面的回复/讨论更是如此,真棒。这是相当漫长的,但值得一试。

总结

在现代游戏物理模拟(即车辆或刚体动力学)中收到客户输入时,服务器无法跟上重复模拟。因此,服务器在服务器之前命令所有客户端延迟+抖动(时间),以便在服务器需要之前,所有进入的数据包都进入JIT。

他还概述了如何处理您要求的所有权类型。他在GDC上展示的幻灯片非常棒!

作弊

费德勒先生(以及其他人)表示,这种算法不会受到非常欺骗的影响。这不是真的。与传统的客户端/服务器预测一样,此算法也不容易或难以利用(请参阅@CD Sanchez' answer中有关传统客户端/服务器预测的文章)。

绝对清楚:服务器不容易欺骗,因为它及时接收网络物理定位(而不是像传统预测那样迟到x毫秒)。客户端根本不受影响,因为他们都接收到对手的位置信息,其延迟与传统预测完全相同。

无论您选择哪种算法,如果您要发布主要标题,您可能需要添加作弊保护。如果您是,我建议针对stooge bots添加加密(例如an XOR stream cipher,其中“密钥流由伪随机数生成器生成”)以及针对裂缝的简单完整性检查。一些开发人员还实现算法来检查二进制文件是否完整(以降低破解风险)或确保用户没有运行调试器(以降低开发破解的风险),但这些更有争议。

如果你只是制作一个较小的独立游戏,这可能只有几千个玩家玩,不要在实施任何反作弊算法之前直到1)你需要它们;或2)用户群增长。

答案 2 :(得分:2)

我们已经实施了一个基于强制服务器和远程玩家进行预测的多人游戏蛇游戏。每隔150毫秒(在大多数情况下),服务器会发回一条消息,其中包含每个远程播放器发送的所有合并动作。如果远程客户端移动迟到服务器,他会丢弃它们。客户将重播最后的动作。

答案 3 :(得分:0)

在XNA Creator俱乐部网站上查看网络教育主题。它深入研究了诸如网络架构(点对点或客户端/服务器),网络预测等一些主题(当然在XNA的上下文中)。这可以帮助您找到您正在寻找的答案。

http://creators.xna.com/education/catalog/?contenttype=0&devarea=19&sort=1

答案 4 :(得分:0)

您可以尝试对所有客户端施加延迟,具体取决于该区域的平均延迟时间。这样,客户端可以尝试解决延迟问题,对大多数玩家来说都会感觉类似。

我当然不是建议你对所有人施加500毫秒的延迟,但50分钟的人可以罚款150(额外增加100毫秒),以使游戏更加流畅。

简而言之;如果你有3名球员:

  • John:30ms
  • 保罗:150毫秒
  • 艾米:80毫秒

在计算之后,不是将数据同时发送回客户端,而是考虑他们的延迟,并开始在John之前发送给Paul和Amy。

但是这种方法在极端延迟的情况下是不可行的,在这种情况下,拨号连接或无线用户可能真的让每个人都搞砸了。但这是一个想法。