本文主要想罗列出游戏中常见的一些抽奖概率模型，并对其做简要的分析和讨论（本文是简书转掘金系列的第二篇）。
游戏中经常会有一些含有随机性质的抽奖设计，以此增加游戏的可玩性和收入点。比如说抽卡、随机礼包、每日抽奖机会等等。它们都可以分为下面这两大类：
1. 纯随机概率计算：
我这里所说的纯随机是指：随机结果不受外界影响，并且随机模型和随机概率一直恒定不变的随机情形。
模型介绍：随机宝箱里面会有N种物品，每种物品的获得几率已经固定下来，这些物品的获得几率并不会因为你开宝箱的次数或其他外在因数（比如玩家充值金额）不同而不同（没有特权没有保底，非洲人做到底）。不管10次还是100次，次次相同；不管是大R还是白嫖，众生平等。
实现方式：实现上很简单，只要确保使用的随机函数正确即可。
int randomRewardId() {
int rewardFactor = random(1, 100);
return getRewardIdByFactor(rewardFactor);
}
// 从min - max之间随机一个数（包括min和max）
int random(int min, int max);
// 根据奖励因子rewardFactor，得到不同的奖励
int getRewardIdByFactor(int rewardFactor);
2. 伪随机概率计算：
我这里所说的伪随机是指：玩家的相关操作或其操作结果会对之后的随机策略和结果造成影响。
伪随机模型1：连抽保底概率模型：
模型介绍：保底模型主要是考虑到非洲人玩家的游戏体验。比如说一个大R非洲人玩家，为了一张中奖概率为5%的金卡连续抽了50次（这个概率大概在7%左右），那么这个玩家受到的打击应该是巨大的很有可能导致退游甚至打12315电话，一百个金主玩家可能出现七个这种情况，我估计是个老板都不能接受。为了避免这种情况的发生，就有了保底这个设计。非洲人没关系，只要你抽20次都没中过，我就保底必给你一张金卡。
实现方式：
- 简单的实现方式 ———— 记录玩家已经连续几次没有抽中金卡的次数（获得金卡就重置该值），如果这个值等于20 ，那么下次抽奖就给一张金卡。
int continuedMissTimes; // 连续没抽中金卡次数
// 随机卡片
int randomCardId() {
// 20表示保底次数，5表示金卡的中奖概率
if (continuedMissTimes >= 20 || random(1, 100) <= 5) {
continuedMissTimes = 0;
return 1; // 金卡id
} else {
continuedMissTimes++;
return 2; // 普通卡id
}
}
// 从min - max之间随机一个数（包括min和max）
int random(int min, int max);
- 如果想把这个保底做的平滑一点 ———— 同样记录玩家已经连续几次没有抽中金卡的次数（获得金卡就重置该值），根据这个次数算出本次抽到金卡的概率（次数越大概率越大），同时保证次数为20时中金卡的概率为100%。
int continuedMissTimes; // 连续没抽中金卡次数
// 随机卡片
int randomCardId() {
// 20表示保底次数，5表示金卡的中奖概率
if (continuedMissTimes >= 20 || random(1, 100) <= calGoldCardProbabilityByContinuedMissTimes()) {
continuedMissTimes = 0;
return 1; // 金卡id
} else {
continuedMissTimes++;
return 2; // 普通卡id
}
}
// 从min - max之间随机一个数（包括min和max）
int random(int min, int max);
// 根据连续没抽中金卡次数计算本次抽中金卡的概率
int calGoldCardProbabilityByContinuedMissTimes() {
return continuedMissTimes * 95 / 20;
}
额外参考：《10 连抽保底的概率模型》
伪随机模型2：全服根据抽奖人数固定比例数量奖品概率模型：
模型介绍：假设某件物品A是100个人才能有1个人拥有，并且这个比例必须要得到保证。
实现方式：后端记录总抽奖人数，玩家一抽奖就马上计算出服务器此时总的抽奖次数(算上他这次的抽奖)，抽奖次数对100取余等于自己指定的数，那么他就是抽中。对于大并发的解决方案就是 ———— 中奖、领奖流程与抢数流程分离。用户线程抢数（AtomicInteger），自己判断是否中奖。
AtomicInteger totalPlayerNum = new AtomicInteger(0); // 总抽奖人数
boolean randomIsReward() {
int i = totalPlayerNum.incrementAndGet();
if (i % 100 == 50) {
return true;
} else {
return false;
}
}
伪随机模型3：抽奖不中概率逐渐加大模型：
模型介绍：和模型1（10 连抽保底的概率模型）不一样，这里不是一个保底的方案。比如说有一类稀有物品A类物品、普通类型物品B类物品。保证每抽4次只可能有且仅有1次中A类物品，第1、2、3、4次抽中A类概率分别为10%、30%、50%、70%，并且4次之内只要中了A类物品，这4次内后面的几次再中A类物品概率为0。每4次进行一个新的轮回。
实现方式：根据次数计算本次概率，获得A即重置
int rewardTimes;
boolean isHit;
// 随机卡片
int randomCardId() {
rewardTimes++;
int res = 0;
if (!isHit && random(1, 100) <= calGoldCardProbabilityByRewardTimes()) {
isHit = true;
res = 1; // A物品id
} else {
res = 2; // 普通物品id
}
if (rewardTimes >= 4) {
rewardTimes = 0;
isHit = false;
}
return res;
}
// 从min - max之间随机一个数（包括min和max）
int random(int min, int max);
int calGoldCardProbabilityByRewardTimes();
伪随机模型4：保证稀有物品最后抽到模型。
如上图所示，玩家只能进行8次抽奖。奖品分为 普通类:普通符文礼盒、金装类:金装符文礼盒、稀有类：圣龙/奥丁英雄。为提高玩家的付费率，策划设计了一种伪随机抽奖方式：
- 稀有类两种奖品会安排到最后才会被抽取（其中必定有一个是最后一次抽到，另外一个则可能是第6次或第7次）。
- 金装符文礼包在前四次抽到的几率权重为普通符文礼盒的十分一。
- 8次抽奖所得组成必须是——4个普通符文礼盒、2个金装符文礼盒、2个稀有类英雄。
下表表示：抽奖次数与所得奖品的权重关系（如果玩家该类奖品已达上限，则权重将改为0）
相关概率模型实现：
对于纯随机概率模型，有很多实现的方案。这里我写了一个MutexRandomUtil，其利用了TreeMap的floorEntry这个方法实现纯随机概率抽取，代码如下：
public class MutexRandomUtil<T> {
private TreeMap<Double, T> map = new TreeMap<Double, T>();
private double endRate = 0;
public MutexRandomUtil() {
}
// 注册可随机项物品t（随机概率为rate）
public void registerData(double rate, T t) {
if (rate <= 0 || rate > 1) {
throw new IllegalArgumentException("ERROR RATE!!!");
}
map.put(endRate, t);
endRate += rate;
}
public T random() {
// 0-endRate 随机挑一个数（每个项目实现不一样，这里套用自己项目的随机实现）
double r = MutexRemoveRandom.avgRandom(0, endRate);
Map.Entry<Double, T> e = map.floorEntry(r);
return e != null ? e.getValue() : null;
}
}
对于伪随机概率模型1,3,4这种抽过即无法再中第二次的情况，借鉴MutexRandomUtil，我的实现是将所有将会抽到的物品及其抽取概率值都封装到MutexRemoveRandom中。每次从该类随机抽取物品，抽到的物品都进行移除，这样既可以保证概率的延续性，也能保证抽中奖品不重复，代码如下：
public class MutexRemoveRandom<T> {
private TreeMap<Double, Entry<T>> map = new TreeMap<Double, Entry<T>>();
private double endRate = 0;
private static Random r = new Random();
// 注册可随机项物品t（随机概率为rate）
public void registerData(double rate, T t) {
if (rate <= 0 || rate > 1) {
throw new IllegalArgumentException("ERROR RATE!!!");
}
map.put(endRate, new Entry<T>(t, rate));
endRate += rate;
}
// 抽取物品并移除
public T randomAndRemove() {
double r = avgRandom(0, endRate);
Double key = map.floorKey(r);
if (key != null) {
T t = map.get(key).t;
reorganizeMap(key);
return t;
} else {
return null;
}
}
private void reorganizeMap(Double key) {
TreeMap<Double, Entry<T>> tempMap = new TreeMap<>();
map.remove(key);
double tempEndRate = 0;
for (Map.Entry<Double, Entry<T>> entry : map.entrySet()) {
tempMap.put(tempEndRate, entry.getValue());
tempEndRate += entry.getValue().rate;
}
this.endRate = tempEndRate;
this.map = tempMap;
}
public static double avgRandom(double min, double max) {
if (min > max) {
double temp = max;
max = min;
min = temp;
}
double rNum = r.nextDouble() * (max - min);
return rNum + min;
}
private static class Entry<T> {
final T t;
final double rate;
Entry(T t, double rate) {
this.t = t;
this.rate = rate;
}
}
}
游戏中的抽奖套路实在有很多种，这里无法一一列举。写关于抽奖逻辑时，需要注意是否自己的代码会出现下面几种常见的问题：
- 正确性问题：写多几个测试用例进行测试，保证随机出来的结果和策划所要求的的一致。这个问题测试和策划并不容易被发现，所以开发正确性的主要人员。
- 线程安全问题：这个问题有一个很重要的判断标准————是否会存在多个用户对公共资源进行访问、修改（比如物品概率的查询、随机数的获取）。如果存在这种情况，就需要确保这个公共资源是线程安全的。
- 性能问题：性能问题也是许多经验不丰富开发人员经常面临的问题。比如我就看到过有人for循环创建Random对象导致的性能问题、要求从几千种情况中挑一种，然后每次随机都创建了几千个对象从中随机选一个、等等问题不一而足，不过幸好这些都及时发现没有留到线上。
- 代码/注释是否清晰：代码越是清晰，越能表达代码的实现意图这样出现bug的可能性越小。我们的随机套路很有可能会被别人复用，注释会帮助他们更快判断是否适合他们面临的需求。
