面对浮点非确定性，确定性游戏怎么可能？

为了使游戏像RTS网络游戏一样，我在这里看到了许多答案，这些建议建议使游戏完全具有确定性。那么您只需要彼此转移用户的操作，并稍微延迟所显示的内容，以便在呈现下一帧之前“锁定”每个人的输入。这样，诸如单位位置，健康状况之类的事情就不需要通过网络不断更新，因为每个玩家的模拟都是完全相同的。我也听到过建议进行重放的同一件事。

但是，由于浮点计算在机器之间，甚至在同一机器上同一程序的不同编译之间是不确定的，真的可以这样做吗？我们如何防止这一事实在整个游戏中引起波动的玩家（或重播）之间产生微小差异？

我听说有人建议完全避免使用浮点数int来表示小数的商，但这对我来说并不实用-例如，如果我需要取一个角度的余弦值怎么办？我是否真的需要重写整个数学库？

请注意，我主要对C＃感兴趣，据我所知，在这方面，C＃与C ++存在完全相同的问题。

浮点是确定性的吗？

几年前，当我想使用与您相同的锁步体系结构编写RTS时，我做了很多阅读。

我对硬件浮点的结论是：

• 如果您谨慎使用浮点标志和编译器设置，则最有可能使用相同的本机汇编代码。
• 有一个开源RTS项目声称它们使用包装器库在不同的编译器上进行了确定性的C / C ++编译。我没有核实这一说法。（如果我没记错的话，那是关于STREFLOP图书馆的）
• .net JIT留有很大的余地。特别是允许使用比要求更高的精度。它还在x86和AMD64上使用不同的指令集（我认为在x86上它使用x87，AMD64在它上使用某些SSE指令，它们的行为对于denorms有所不同）。
• 复杂的指令（包括三角函数，指数，对数）尤其成问题。

我得出结论，无法确定地使用.net中的内置浮点类型。

可能的解决方法

因此，我需要解决方法。我考虑过：

1. FixedPoint32用C＃实现。虽然这不太难（我已经完成了一半），但是很小的值范围使使用起来很烦人。您必须时刻小心，以免溢出或失去太多精度。最后，我发现这并不比直接使用整数容易。
2. FixedPoint64用C＃实现。我发现这很难做到。对于某些操作，128bit的中间整数将很有用。但是.net不提供这种类型。
3. 将本机代码用于在一个平台上确定的数学运算。在每个数学运算上产生委托调用的开销。失去跨平台运行的能力。
4. 使用Decimal。但是它很慢，占用大量内存，并且容易引发异常（除以0，溢出）。对于财务用途来说非常好，但不适用于游戏。
5. 实现自定义的32位浮点。起初听起来相当困难。在实现此功能时，缺少BitScanReverse内部函数会引起一些麻烦。

我的SoftFloat

受到您在StackOverflow上的帖子的启发，我刚刚开始在软件中实现32位浮点类型，结果令人鼓舞。

• 内存表示形式与IEEE浮点数二进制兼容，因此在将它们输出到图形代码时，我可以重新解释类型转换。
• 它支持SubNorm，无限和NaN。
• 确切的结果与IEEE的结果并不完全相同，但是通常对于游戏来说并不重要。在这种代码中，对于所有用户而言结果都是相同的，而对最后一位数字无误才是重要的。
• 表现不错。一项简单的测试显示，与220-260MFLOPS float进行加/乘运算（2.66GHz i3上的单线程）相比，它可以完成约75MFLOPS的处理。如果有人对.net拥有良好的浮点基准，请发送给我，因为我当前的测试非常初级。
• 舍入可以改善。当前它会截断，这大致相当于向零舍入。
• 还很不完整。目前，除法运算，强制转换和复杂的数学运算已丢失。

如果有人想贡献测试或改进代码，请与我联系，或在github上发出拉取请求。https://github.com/CodesInChaos/SoftFloat

其他不确定因素

.net中还有其他不确定性来源。

• 迭代a Dictionary<TKey,TValue>或HashSet<T>以未定义的顺序返回元素。
• object.GetHashCode() 每次运行都不同。
• 内置Random类的实现未指定，请使用您自己的。
• 具有天真锁定的多线程会导致重新排序和不同的结果。要非常小心地正确使用线程。
• 当WeakReferences丢失时，它们的目标是不确定的，因为GC可以随时运行。

这个问题的答案来自您发布的链接。具体来说，您应该阅读Gas Powered Games的报价：

我在Gas Powered Games工作，我可以直接告诉您浮点数学是确定性的。您只需要相同的指令集和编译器，并且用户的处理器当然符合IEEE754标准，该标准包括我们所有的PC和360客户。运行DemiGod，最高指挥官1和2的引擎依赖于IEEE754标准。更不用说市场上所有其他RTS对等游戏。

然后是下面的一个：

如果将重放存储为控制器输入，则不能在具有不同CPU体系结构，编译器或优化设置的计算机上重放。在MotoGP中，这意味着我们无法在Xbox和PC之间共享保存的重放。

确定性游戏仅在使用相同编译的文件并在符合IEEE标准的系统上运行时才具有确定性。跨平台同步的网络模拟或重放将无法进行。

使用定点算法。或选择一个权威服务器，使其不时地同步游戏状态-MMORTS就是这样做的。（至少，《战争元素》的工作原理是这样的。它也是用C＃编写的。）这样，错误就没有机会积累。

编辑：到定点类的链接（请当心！-我没有用过...）

您总是可以退回定点算法。有人（至少要创建一个rts）已经完成了stackoverflow的相关工作。

您将支付性能损失，但这可能是（或可能不是）问题，因为.net在这里将不会特别有用，因为它不会使用simd指令。基准！

注意：显然intel的某人似乎有一个解决方案，允许您使用c＃中的intel性能基元库。这可能有助于对定点代码进行矢量化以补偿性能较慢的情况。

我从事过许多大型游戏。

简短的回答：如果您疯狂地严谨，但可能不值得，这是可能的。除非您使用的是固定体系结构（请参阅：控制台），否则它会很灵活，脆弱并且会带来许多次要问题，例如后期加入。

如果您阅读其中提到的一些文章，则会注意到，虽然可以设置CPU模式，但在某些奇怪的情况下，例如打印驱动程序由于位于相同的地址空间而切换了CPU模式。我遇到了一个应用程序被框架锁定到外部设备的情况，但是一个有故障的组件导致CPU由于热量而节流，并且在早上和下午报告的方式有所不同，从而使午饭后它实际上变成了另一台机器。

这些平台差异在芯片而不是软件中，因此回答您的问题C＃也受到影响。诸如融合乘加（FMA）与ADD + MUL之类的指令会更改结果，因为它在内部仅舍入一次而不是两次。C通过排除FMA之类的操作使事情“成为标准”，从而使您具有更多控制权，从而迫使CPU基本完成您想要的工作-但要牺牲速度。内在函数似乎最容易出现差异。在一个项目中，我不得不掏出150年前的acos表，以获取值进行比较，以确定哪个CPU是“正确的”。许多CPU对触发函数使用多项式逼近，但并不总是具有相同的系数。

我的建议：

无论您选择整数锁定还是同步，都应独立于演示文稿处理核心游戏机制。使游戏玩法准确，但不必担心表示层的准确性。还要记住，您不需要以相同的帧速率发送所有联网的世界数据。您可以确定消息的优先级。如果您的模拟匹配率为99.999％，则无需频繁传输即可保持配对。（除了防止作弊。）

有一篇关于Source引擎的不错的文章，解释了一种进行同步的方法：https : //developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

请记住，如果您对后期加入感兴趣，则无论如何都要硬着头皮同步。

请注意，我主要对C＃感兴趣，据我所知，在这方面，C＃与C ++存在完全相同的问题。

是的，C＃与C ++存在相同的问题。但是它还有很多。

例如，以肖恩·霍格雷夫斯（Shawn Hawgraves）的说法：

如果将重放存储为控制器输入，则不能在具有不同CPU体系结构，编译器或优化设置的计算机上重放。

确保这在C ++中发生是“足够容易的”。但是，在C＃中，这将变得很难处理。这要归功于JIT。

如果解释器将您的代码运行一次，但是第二次JIT将其JIT化，您会怎么办？还是它在别人的机器上解释了两次，但是之后是JIT吗？

JIT不确定，因为您对其几乎没有控制。这是您放弃使用CLR的事情之一。

如果有人使用.NET 4.0来运行您的游戏，而其他人使用Mono CLR（当然是使用.NET库），那么上帝会帮助您。甚至.NET 4.0与.NET 5.0可能也有所不同。您只需要对平台的低级细节进行更多控制即可保证这种情况。

您应该能够摆脱定点数学的困扰。就是这样。

在写完这个答案后，我意识到它实际上并没有回答这个问题，特别是关于浮点非确定性的问题。但是，如果他要以这种方式制作网络游戏，无论如何这可能对他有帮助。

除了将要广播给所有玩家的输入共享之外，创建并广播重要游戏状态的校验和（例如玩家位置，健康状况等）也非常有用。在处理输入时，断言针对以下内容的游戏状态校验和所有远程播放器都处于同步状态。您一定可以修复不同步（OOS）的错误，这将使之更容易-您将更早地注意到出现了问题（这将帮助您确定复制步骤），并且应该可以添加更多内容游戏状态记录可疑代码，以便您将引起OOS的所有事件括起来。

我认为与该博客相关的想法仍然需要定期同步才能可行-我已经看到网络RTS游戏中有足够多的错误采用了这种方法。

网络有损，缓慢，有延迟，甚至可能污染您的数据。“浮点确定性”（听起来似乎很笼统，让人怀疑）实际上是您最少的担心……尤其是如果您使用固定的时间步长。对于可变的时间步长，您将需要在固定的时间步长之间进行插值，以避免确定性问题。我认为这通常是不确定的“浮点”行为的意思-只是可变的时间步长导致积分发生偏差-与数学库或低级函数无关。

同步是关键。

您使它们具有确定性。有关一个很好的例子，请参阅Dungeon Siege GDC演示文稿，了解它们如何使世界各地实现互联。

还请记住，确定性同样适用于“随机”事件！