大部分游戏策划使用权值来配置随机概率，因为权值有个好处就是可以在增加随机物品时，可以不对之前的配置进行更改，比如：白卡 30，蓝卡 10，紫卡 10，转为概率即是：白卡 60%，蓝卡 20%，紫卡 20%。
文/ HuangWeI
这段时间公司开发的游戏上线测试，许多玩家在抽卡时抱怨脸黑，很难抽到所需要的卡牌，而又有一部分玩家反应运气好能连着抽到紫卡，检查了下随机相关逻辑代码，并没有找出问题所在，玩家运气好与坏只是觉得真有可能是概率原因。
测试开服了几天之后，需要开放某个限时抽卡活动，在内部测试时，我们发现玩家反应的问题在限时抽卡中格外明显，尤其是其中最主要的一张稀有卡牌，猜测因为限时抽卡库配置的种类较少，然后就拿该活动来检查了下我们游戏随机机制问题。
5%概率？20次出现一次？
大部分游戏策划使用权值来配置随机概率，因为权值有个好处就是可以在增加随机物品时，可以不对之前的配置进行更改，比如：白卡 30，蓝卡 10，紫卡 10，转为概率即是：白卡 60%，蓝卡 20%，紫卡 20%。
而上述限时抽卡的例子中，我们的权值配置是5和95，模拟50000次随机（使用系统随机函数，如C的rand函数，Python的random库）得到如下结果：
上图绘制的是权值为5的卡牌的随机状态，红色的图是分布图，X轴是出现的次数，Y轴是相同卡牌再次出现的间隔。绿色的图是分布概率图，X轴是间隔数，Y轴是概率。按策划的想法，5%概率应该等同于20次出现一次，那上图很明显并不满足20次出现一次出现规则，实际间隔从近到远呈下坡形状分布，就是说相邻的概率最大，间隔最大超过160，这与玩家所吐槽的抽卡体验是一致的。但50000次随机总共出现了2508次，从统计的意义上来说又是符合5%概率的。所以这个问题，究其原因就是所谓的概率是统计意义上的还是分布意义上的问题。
最原始的实现
我用列表里取元素的方式来模拟20次出现一次，为了方便比较异同，直接随机的方式我也贴上相关代码。
|
1
2
|
pool = [0]*5 + [1]*95result = [random.choice(a) for i in xrange(N)] |
上面是直接随机的方式，只保证5%概率。
|
1
2
3
4
5
6
7
8
|
pool = []result = []for i in xrange(N):if not pool:pool = [0]*1 + [1]*19random.shuffle(pool)result.append(pool[-1])del pool[-1] |
上面是打乱列表，然后依次取元素的方式，保证20次出现一次，而5%概率则是隐含在内的，生成效果如下图。
该图明显跟第一个实现的图不一样，上图表明了间隔基本上是落在[0, 40]的区间内，并且均匀分布在20那条蓝色对称线附近。这个才是最终想要的随机的效果。红色的线是正态分布曲线，是不是很相似？后面我会讲到。
眼尖的会发现在第一个实现中我用的pool是[0]*5 + [1]*95，而第二个实现中我用的是[0]*1 + [1]*19。
这里20次出现一次并不等同于100次出现五次，也是从分布的意义上来说的，100次出现五次是存在5次连续出现的可能。
针对策划的配置，我们需要进行预处理，怎么处理？GCD啊~，5和95的最大公约数是5，所以在第二个实现的代码中我直接使用了1和19。
但这里有个问题，一般策划配置的随机库中肯定有多个物品。权值如果配置的比较随意的话，很可能就导致GCD为1，这样想要实现XX次出现一次就不可行了。比如刚才的权值配置5和95，再加一个权值为11的话，就只能实现111次出现5次。
所以这两种依赖列表的随机方式并不适用，一是需要维护的列表内存会比较大，二是对策划配置方式有过多约束。
更通用更优美的实现
20次出现一次是以20为标准周期，当然不能每次都是间隔20出现，这样就太假了，根本没有随机感受可言，为了模拟随机并可以控制一定的出现频率，我选择正态分布来进行伪随机分布生成，原因是分布会更自然一些。
关于正态分布这里就不详细描述了，只需关心分布的两个参数即可，位置参数为μ、尺度参数为σ。根据正态分布，两个标准差之内的比率合起来为95%；三个标准差之内的比率合起来为99%。
用上面的例子来定下参数，μ=20,σ=20/3，这样每次按正态分布随机，就能得到一个理想的随机分布和概率区间。
C语言标准函数库中只有rand，如何生成符合正态分布的随机数可以参见WiKi上的介绍。这里我直接使用Python中random库中的normalvariate函数，当然gauss函数也是一样的，官方文档上说gauss函数会快些，StackOverFlow上说gauss是非线程安全函数，所以会快。我自己简单测试了下，在单线程情况下，gauss是会快些，但只是快了一点点而已。
首先，我直接生成权值为5的卡牌的间隔，检验下正态分布的随机效果。
|
1
2
3
|
NN = int(N*0.05)mu, sigma = 20, 20/3.delta = [int(random.normalvariate(mu, sigma)) for i in xrange(NN)] |
这图是不是比第二个实现的图更好看一些，分布也更平滑一些呢。OK，接下来就是替换旧的随机算法了。
细节和优化
刚才说了随机库中会有很多物品，都需要按照各自的权值随机，并各自出现频率符合正态分布。下面我们来说说细节。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
wtp = [1.*x/sum(wt) for x in wt]result = []p = [random.normalvariate(1./x, 1./x/3.) for x in wtp]for i in xrange(N):minp = 1.e9minj = -1for j, pp in enumerate(p):if pp < minp:minp = ppminj = jresult.append(minj)for j, pp in enumerate(p):p[j] -= minpp[minj] = random.normalvariate(1./wtp[minj], 1./wtp[minj]/3.) |
这里我使用了统一的随机种子，随机测试了500万次后，所得的结果与多个随机种子差别不大。
简单解释下代码：初始化对所有物品按权值进行正态分布随机，每次取位置最小值的物品（也就是最先出现的），然后其它物品均减去该值，被取出的物品再单独进行一次正态分布随机，再次循环判断位置最小值。
这里，每次都需要对所有物品进行求最小值和减法，都是需要遍历的运算，我们可以有如下优化。
例如：(1,3,4) -> 取1减1, (0,2,3) -> 随机1, (1,2,3)，其实我们只是为了保持各物品之间位置的相对顺序即可，将对其它物品的减法变成对自己的加法，操作量级立马从O(N)缩为O(1) 。
如上面的例子：(1,3,4) -> 取1, (0,3,4) -> 随机1加1, (2,3,4)，这样的操作不会改变物品序列的正确性。
熟悉最小堆的朋友，将查找最小值优化到O(1)应该也没啥问题吧。
|
1
2
3
4
5
6
7
8
|
wtp = [1.*x/sum(wt) for x in wt]result = []p = [(random[i].normalvariate(1./x, 1./x/3.), i) for x in wtp]heapq.heapify(p)for i in xrange(N):minp, minj = heapq.heappop(p)result.append(minj)heapq.heappush(p, (random[minj].normalvariate(1./wtp[minj], 1./wtp[minj]/3.)+minp, minj)) |
测试结果
问题分析和算法实现就到这了，替换进我的游戏里看看什么效果，我已经迫不及待了。
物品测试权值序列[10, 30, 50, 110, 150, 200, 250, 500]，随机测试500万次。
第一个随机实现
第一个实现是只符合统计要求，不符合分布要求。
第二个随机实现
第二个实现中对权值序列进行了GCD，可以看到只有绿色是符合分布要求的，而蓝色和青色退化成第一种实现。
基于正态分布的随机实现
完美！
其它
当然，实现20次出现一次这样的分布伪随机还有其它方法，比如保存一个计数器，每随机一次就加到计数器上，当计数器的值大于或等于1，即必然出现。但这种实现需要计数器，每个玩家每个随机库每个物品都需要这么一个计数器字段，空间上实在太大了。
关于随机种子，除非是全服竞争类资源，不然最好每个玩家有各自的随机种子，否则会造成体验上的误差，比如抽卡、关卡掉落等这些只针对玩家自身的系统随机。服从正态分布的全局随机序列，不同玩家任意取走序列中一段或者一些值，就可能导致对于每个玩家而言，各自取出的随机序列不再服从正态分布。
结束
我只能感叹Python的库太强大了，matplotlib绘制出来的图形也挺漂亮的，感兴趣的童鞋可以查阅用Python做科学計算。
如若转载，请注明出处：http://www.gamelook.com.cn/2015/10/230942
