关于游戏随机数系统(指Utilities.UnifiedRandom.cs里的UnifiedRandom方法)，这个方法本身的来源，应当是微软.NET Framework源码，微软的源码中引用的来源则是Numerical Recipes in C (2nd Ed.)，这本书我找着了电子版，其提供的源码如下：

一个超奇怪的不同是变量inextp，这个值在书中是31，但微软和relogic的源码里都写成了是21，而且这个常数是特殊的（根据Knuth的书，不过我没去看，估计想看懂也得费老大劲）。
BUG是源于这个笔误吗？如果是的话，其实锅可能不是relogic，而是微软的23333

突然想到最初的来源会不会是速通社区的，毕竟他们估计对世纪之花灯泡的生成规律十分热心

可能现在的版本也有？之前我打了三个南瓜月一个黑暗收割都没有，第四次打的时候爆了六个

我说怎么有一回我测武器原本dps五千退了重进变三千七

如果是真的话很多事都能解释，所以我宁愿相信

Knuth的书找到了，居然是1997年的。但我不会去看算法的理论解释的，问就是懒，再问就是看不懂。
这书里还聊了一些关于随机性检测的玩意，比如Frequency test，Serial test，Gap test之类的用来检测随机数生成器的质量。或许可以对游戏用的随机数生成器跑一跑这些测试，等我有心情了的时候（
另外好在游戏里随机数生成器本身是个独立的模块，很容易就能单独摘下来转写成我习惯的语言，比如Python...

所以等我有心情的时候就继续搞（

此外，楼主目前并不清楚31写成21的后果，也不能确定游戏里许多脸黑事件是否应该由这个笔误来背锅（可以想象的是即使随机数生成器没有问题，依然会有大量玩家遭遇脸黑事件）。
在我们甚至没有搞清楚随机数生成器的行为前，任何简单的归咎都是武断的。

随机数居然能出这样的问题🤔

不太清楚这是否真的是问题所在，我试着复现了一下代码，但是并没有观察到伪随机数集中出现在某个区间的情况