一般我们处理随机率，使用Random.Range(MIN,MAX)，如果返回值在我们设定的范围内，则随机命中成功。
打个比方：牛魔王掉裁决的概率为0.1%，也就是说，搞死牛魔王1000次（默哀），会掉一把裁决。
我们来模拟下，10组玩家击杀牛魔王1000次的结果：
可以看出，大部分结果还是比较真实的反应了概率，但是值得注意的是第6组打了1000次，还是没有出裁决，这玩家肯定要骂娘了，为什么？还是思想“不患寡而患不均”在作祟，“你承诺了千分之一掉宝率，为什么我起早摸黑打下来毛都没有，第三组爆了三把？”
同样的，比如镶嵌宝石成功率为20%，也就是理论上5次成功一次，那么镶嵌5次全部失败的概率是多少？0.8*0.8*0.8*0.8*0.8=32.768%，如果我们还加上镶嵌失败，装备爆掉的惩罚，估计玩家能郁闷很久。
这个时候，光靠计算机那双“看不见的手”来控制随机率已经不够了，我们需要加入自己“看得见的手”
那么我们如何修改呢？
每次失败，随机值累加一次！成功之后，随机值还原。
拿镶嵌宝石来说
| 次数 | 成功率 |
| 1 | 20% |
| 2 | 40% |
| 3 | 60% |
| 4 | 80% |
| 5 | 100% |
那么代码需要怎么修改呢？
裁决掉宝率为千分之一：Random.Range(0,1001)，我们设定命中值为最大的1000
每次掉宝失败，随机范围的起始值+=掉宝率，这样，随着失败的增加，随机范围的起始值越接近命中值； 掉宝成功，起始值还原
这样修改，可以保证游戏厂家对玩家做出的千分之一的掉宝率是有效的。
但是我们也可以看出，由于我们的干预，在随机的过程中，随机范围是在不断缩减的，这导致掉宝的命中率不断提高。模拟的结果也证实了我们的猜测，掉宝的实际结果会比千分之一要高
玩家是不会抱怨掉宝率的增加的。
这个机制适用于各种用到随机值得地方，比如晕眩几率、任务触发几率、暴击几率等等。
在比如BOSS掉宝、装备合成成功率的地方，将累加值存储起来，在玩家上下线之后，累加计数的影响依然存在。（一般在数据库设计的时候，在掉宝率所在的表里，把随机累加值作为字段添加进该表就好了）
在频繁的实时战斗模块（比如晕眩、暴击），进入当前场景后，初始化累加值就好了。