我正在考虑制作网络游戏。我对此并不陌生，已经遇到了很多问题，试图为航位推测和网络延迟制定一个好的计划，因此，我很乐意看到一些有关该主题的好文献。我将描述我考虑过的方法。

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

这篇GamaSutra文章提供了一种解决方案，该解决方案可以节省带宽并通过在客户端上进行模拟来使本地输入看起来更平滑，但似乎使防骗措施显得格格不入。另外，我不确定当玩家开始操纵环境，推开石头之类的东西时该怎么做。这些以前中立的对象将暂时成为客户端需要发送PDU的对象，或者可能有多个播放器一次执行。谁的PDU会获胜？什么时候将停止对每个玩家进行双重跟踪(以与推算得出的版本进行比较)？天堂禁止两名玩家进行相扑比赛(例如，开始互相推动)。

这个gamedev.net位显示gamasutra解决方案不够充分，但是描述了一种其他方法，该方法并不能真正解决我的协作式推石示例。我发现的大多数其他事情都是针对射手的。我很乐意看到一些更适合SNES Zelda这样的游戏，但涉及更多的物理/动量。

• 注意：这里我不是在问物理模拟-其他库已经介绍了。尽管存在网络延迟，但使游戏流畅且反应灵敏的只是策略。

解决方案

回答

查看Valve在源引擎中的工作方式：http：//developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

如果是第一人称射击游戏，我们可能必须深入研究他们提到的一些主题，例如：预测，补偿和插值。

回答

在XNA Creator's Club网站上查看网络教育主题。它深入研究了诸如网络体系结构(对等或者客户端/服务器)，网络预测以及其他一些内容(当然在XNA的背景下)的主题。这可以找到所需的答案。

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

回答

我发现Glenn Fiedler撰写的该网络物理学博客文章，甚至更多，因此其下的响应/讨论很棒。这是很长的，但值得。

总之

每当在现代游戏物理模拟(例如，车辆或者刚体动力学)中收到客户输入时，服务器就无法跟上重复模拟的步伐。因此，服务器在服务器之前命令所有客户端延迟和抖动(时间)，以便所有传入的数据包在服务器需要它们之前都进入JIT。

他还概述了如何处理我们要求的所有权类型。他在GDC上展示的幻灯片真棒！

作弊

Fiedler先生本人(及其他人)指出，该算法的防骗能力很差。这不是真的。与传统的客户端/服务器预测相比，该算法的使用同样容易或者难于使用(请参阅@CD Sanchez的答案中有关传统客户端/服务器预测的文章)。

绝对要清楚：服务器不仅仅因为及时收到网络物理定位(而不是像传统的预测那样晚x毫秒)就容易作弊。客户端根本不会受到影响，因为它们都以与传统预测完全相同的延迟来接收对手的位置信息。

无论我们选择哪种算法，如果要发布主要标题，都可能需要添加作弊保护。如果我们愿意的话，我建议添加针对欺骗性僵尸程序的加密(例如XOR流密码，其中"密钥流是由伪随机数生成器生成的")，并针对漏洞进行简单的完整性检查。一些开发人员还实现了算法来检查二进制文件是否完整(以降低破解风险)或者确保用户未在运行调试器(以降低开发出裂缝的风险)，但是这些算法更具争议性。

如果我们只是在制作较小的独立游戏，而该游戏只能由几千名玩家玩，则不要费心实现任何反作弊算法，直到1)我们需要它们；或者2)用户群不断扩大。

回答

我们可以尝试对所有客户端施加延迟，具体取决于该区域的平均延迟。这样，客户端可以尝试解决延迟问题，并且对于大多数播放器来说，感觉都差不多。

我当然不建议我们对每个人强加500ms的延迟，但是对于50ms的人，可以将其设置为150(额外增加100ms)，这样才能使游戏玩法更加流畅。

简而言之;如果我们有3位玩家：

• 约翰：30ms
• 保罗：150ms
• 艾米：80ms

计算之后，我们无需考虑将数据同时发送回所有客户端，而是考虑它们的延迟，然后开始在John之前发送给Paul和Amy。

但是，这种方法在极端延迟的情况下不可行，在这种情况下，拨号连接或者无线用户可能真的将所有人搞砸了。但这是一个主意。