一个网络游戏掉落系统的设计实例

theninth1985

序言

　　最近比较忙，主要是在找工作和设计自己的地图，就没太关注设计区的事情，这两天闲了自己补一篇原创的内容来将功补过吧，写的不好，大家轻喷。>_<

　　在游戏设计中，并不是所有的系统都像玩法设计一样需要大量的原创设计，很多服务型的系统，他们只需要照搬已有的成熟设计方案就可以了，比如：物品系统、掉落系统、背包系统、拍卖行系统、聊天系统、邮件系统等等。

　　总结现有的设计，借鉴成熟的方案，能够节省很多时间。我想把能想到的这类无需原创的系统设计方案，都总结一下，方便自己和以后用到的人，希望能对大家的设计有些帮助。

　　必须说明的是这些设计案例都是我个人的一些经验总结，难免会有粗鄙、疏漏之处，请大家帮我指正，我会不断改进这些设计按，并且让它们都达到“执行案”的程度，这样才能真正方便大家应用。

　　第一篇从掉落系统开始吧。

1.  为了DNF！！！

　　最开始研究掉落系统是为了玩DNF这个游戏，在DNF里想自己刷极品装备是非常困难的，用RMB直接买的话，随便一件装备都要两三百块，而玩DNF的时候我刚工作不久，月薪只有1800块……

　　可是好想要啊！！！file:///C:/Users/user/AppData/Local/Temp/msohtmlclip1/01/clip_image001.gif

　　于是只好看看有没有其他歪门邪道的装备获取手段了，经过观察，我发现DNF里有一种“开罐子”的抽奖方式，有几率抽出极品装备来。这种抽奖方式，一个角色每天最多抽奖30次（开30个罐子）。

　　我觉得对这样一个极品装备产出方式的产量是要进行控制的，不能太多也不能太少，太多的话会对经济系统造成冲击，太少的话这种物品产出的方式会被玩家认为很“坑爹”，玩家们就不会来抽奖了，但这种开罐子的方式，抽奖次数是通过角色进行限制的，一个账号下面可能有多个角色，并且服务器有大量的账号是闲置的，那么单纯的用低概率（1/100000这样的）来控制极品装备的产量是很难得到一个合适的概率的。

　　如此说来这样的方式可能相对合理，首先设置一个较高的中奖概率，比如5/1000，然后让服务器记录某些珍惜物品的产量，当产量达到一定值的时候，即使再次被玩家抽中，也会被服务器悄悄的替换成其他的非珍惜物品，这样就能达到一个比较好的效果了。玩家经常能看到别人抽中，所以自己抽不中完全就是“人品问题”了……

　　按照上面的假设，服务器记录一定时间之内的珍惜物品产量，但它肯定有把记录归零的时间点，来实现周期性发放一定数量装备的效果，如果在一定时间内玩家们抽奖的次数是固定的，比如每分钟都有200人抽奖，那么中奖分布比较密集的时间，就是服务器记录清零的时间点，经过观察我发现整点前后经常有玩家中奖，那么极品装备获取方案就诞生了：

　　首先要在整点前后进行抽奖，其次要保证同时抽奖的玩家比较少，你才有比较高的概率中奖，于是我选择23:00之后抽奖，30次抽奖要消耗90万游戏币，而如果抽中的话随便一件装备都能卖两三千万游戏币，实际实行的结果就是我的角色什么装备都有了~~~

file:///C:/Users/user/AppData/Local/Temp/msohtmlclip1/01/clip_image002.gif

　　

　　以上的DNF产出机制完全出自我的假设，可能内部的实现机制和我说的完全不同，但不可否认的是，从外部表现上完全符合我假设的规则，而且我也通过这个方式获得了大量的极品装备，什么CC、王星、流星落，不过可怜我那时完全没想到的是如果把这些装备拿到5173上买RMB，能使我当时拮据的生活改善不少，我的经济头脑可真是差劲……

　　不管DNF的产出机制是怎样的，通过上面那个例子我们都可以知道，游戏对物品产出机制是有一定的“性能”需求的，比如限制某些物品的产量；随机选择产出物品（抽奖）等等。

　　这篇文章就根据我的经验来分析一下物品产出系统的常见需求，同时分享一下我之前的一些设计方案。

　　嗯，再提醒一下刚刚参加工作而待遇又比较差的新人策划，我们也是可以利用自己的专业知识赚点儿小钱的，如果工资实在不够花的话，就业余时间从其他游戏里找点儿零花钱吧~~~

2.  物品发放系统                         2.1    物品发放系统的结构

　　这篇文章的标题是“一个网络游戏掉落系统的设计实例”，可上面讲了那么多“开罐子”的内容，这并不是跑题了，而是在我看来无论“掉落”还是“开罐子”，实现方式都是一致的，都是一个随机抽取一些物品给玩家的功能，只不过掉落系统大概是这个功能最广为人知的表现形式了。

　　我把这系统叫“物品发放系统”，我通常这样设计它的结构，首先要有一个核心的“奖励库”，这个“奖励库”负责最基本的“互斥奖励物品”生成，即从一组预先配置好的物品中按概率随机挑选出一个物品（和这个物品的数量），之后不同系统会按照其特有规则调用这个奖励库，产生物品给玩家，比如“Npc死亡时从奖励库的3组和5组分别挑选1个物品给玩家”这样的规则，明显就是掉落系统的具体规则了。

                         2.2    奖励库的设计

　　我们先来看看奖励库的逻辑设计，首先我们要建立奖励库的数据库结构，这应该是一个二维表，表头和含义如下：

表头	含义
奖励库ID	奖励库的主键，主键值相同的记录属于同一奖励库物品组
子ID	用于区分同一组物品中不同记录的子ID
概率	某一行记录中物品的出现概率，为[1,10000]之间的整数，同一组物品所有行的出现概率之和必须为10000
物品ID	生成具体物品时物品的ID，用以查找物品表
物品个数	生成物品时具体的生成个数

　　实际填写一下这个表格相信大家能看得更清楚：

奖励库ID	子ID	概率	物品ID	物品个数
1	1	2500	262145（铜矿）	2
1	2	1000	262145（铜矿）	3
1	3	3000	262146（猫眼石）	1
1	4	3500	262147（黄水晶）	1
2	1	5000	65536（护腕）	1
2	2	5000	65537（腰带）	1

根据上面的表格，举例说明奖励库生成物品的逻辑：

1、  由调用奖励库的系统提供“奖励库ID”来确定由哪个组来生成物品。这里我们假设ID为1，也就是从1组中挑选1项物品。

2、  Roll一个1到10000的整数，确定从1组中挑选哪一条记录配置的物品来生成。这部分的逻辑稍微复杂：

　　a)        首先安装1组中概率的配置生成4个区间，分别是[1,2500]，[2501,3500]，[3501,6500]，[6501,10000]

　　b)        根据之前Roll的那个[1,10000]的随机数属于上面哪个区间，来决定生成对应的物品。比如Roll了6750，那么就应该生成1组中“子ID”为4的记录所配置的物品。

　　c)        当然这个是人的思考模式，换成程序逻辑的话应该是先把同一组内按照“子ID”升序排列，拿Roll到的值和每条记录概率值的累加值相比较，当Roll到的值小于累加值时，就是这行物品。

3、  之后根据“物品ID”在物品表中寻找到此物品的信息，再根据“物品个数”生成指定数量的此物品。

　　大家可以看到，由于生成的概率区间没有交集，所以这个物品生成规则是互斥的。

　　另外说明一点，之所以要在奖励库的字段中加上“物品个数”，是由于可能有这样的需求“挖奥术水晶的时候，有时产生1个，有时产生两个”，那么我们只要在奖励库中配置一组“奥术水晶”掉落组，1个的概率是80%，2个是20%就OK了，非常方便，只需要调用一次奖励库。

　　而且有时候的确会有比较蛋疼的需求，比如：掉落A物品1000个，那这个时候你要是用调用奖励库1000次来生成这1000个物品，效率是很低的，所以还是在奖励库上加一个“物品个数”字段比较方便。

至于概率为啥要用整数而不用小数，这是由于服务器处理整数的效率要高于浮点数，所以用整数更科学~~~

3.  掉落系统

　　上面讲了奖励库的实现，现在终于轮到标题的内容了“掉落系统”。其实掉落系统的实现无非是根据Npc死亡时的一些信息来筛选奖励库中的奖励组的过程，重点是归纳好筛选条件，这些筛选条件是根据实际的掉落需求而来的。

那么让我们总结一下一般网游有哪些常用的筛选条件：

1、  根据级别掉落。这个是个尝试了，高级怪掉落高级物品，低级怪掉落低级物品。

2、  根据地域掉落。不同地域的Npc掉落内容也是不同的，比如这种掉落需求：A副本产出金沙，B副本产出钻石。

3、  根据种族掉落。比如，人形怪掉落各种布料，野兽掉落毛发。

4、  特殊Npc掉落。比如拉格纳罗斯掉落炎魔之手。

　　等等。

　　我们就暂时总结这么多筛选条件，如果大家用到的时候有独特的筛选条件可以举一反三自行处理。我们用以上这些条件建立一个掉落系统的筛选逻辑。

　　还是需要先建立一个掉落筛选数据库，同样是一个二维表歌，字段如下：

分组	表头	含义
筛选条件	Id	掉落组Id，作为主键
	地图ID	用地图Id进行掉落筛选
	级别下限	用级别进行掉落筛选时的级别下限
	级别上限	用级别进行掉落筛选时的级别上限
	种族Id	用种族Id进行掉落筛选
	NpcId	用NpcId进行掉落筛选
调用方式	掉落概率	掉落被触发的概率，小于10000的整数
	掉落次数	掉落被触发时执行的次数
	奖励库Id	此次掉落调用的奖励库的奖励组Id

　　我们尝试一下数据填充：

Id	地图ID	级别下限	级别上限	种族Id	NpcId	掉落概率	掉落次数	奖励库Id
1	101	5	10	0	0	5000	1	1
2	101	0	0	1（人形Npc）	0	1000	2	2
3	101	0	0	0	57（尤达）	3000	1	3
4	102	5	10	0	0	1000	1	1
5	102	0	0	0	0	500	1	2
6	103	5	10	0	0	500	1	3
7	0	5	10	0	0	500	1	4

　　以上面这个表格为例，我们来讲一下筛选逻辑：

1、             首先筛选条件是有优先级别的，比如“地图ID”字段就是被首先判断的条件，如果地图ID不符合条件，那么后面的就根本不看了，但也有特殊情况，比如“所有地图的人形Npc死后都掉落布料”这样的需求，所以需要和程序约定一下，在筛选逻辑中，如果地图Id一项填的是0，那么这项就是对任何地图都适用的。

2、             其次符合筛选条件的记录可能有很多条，我们需要对每条记录Roll一次10000，如果Roll的值在[1,“掉落概率”字段中的值]区间内，则词条掉落被触发。

3、             一条掉落配置被触发，则调用指定的奖励组进行物品生成，生成的次数为“掉落次数”字段中的值。

4、             将所有掉落记录中生成的物品作为此次掉落的最终结果。

　　上面就是用奖励库和掉落规则实现掉落系统的基础逻辑。用上面的逻辑，我们能够实现WOW中的一些Boss掉落，比如“MC8号Boss死亡时，掉落两件胸甲和其他一些物品”这种需求，我们只需要配置一个所有职业胸甲的奖励库组，然后在指定MC8号NpcId，在其死亡时用此奖励组生成两次物品就OK了。

　　除了掉落系统之外，运用这种模式，我们可以实现很多的功能，比如开宝箱获得物品、分解装备得到材料等等，方法都是一致的。

　　这种方法有个好处，就是只要用这套规则搭建起来的系统，其生成物品都是配置在奖励库表格中的，在以后的维护中非常方便查阅，而且程序猿使用的也都是一个接口，方便Debug和监测产量这些，总之好处很多。

4.  物品发放的一些限制

　　我们回到开始DNF那个例子中，在生成物品的时候，有时会需要对一些类型的物品产量进行控制，通过上面讲的这套物品发放机制，我们可以明白，只需要设定一些监测机制，就能满足我们的需求，比如：

1、  监测并记录某珍惜物品掉落组被调用的次数

2、  监测并记录某物品Id被生成的次数

　　就不再多说了，大家都懂的。

　　这篇东西还有一个比较通用的需求没有提到，那就是任务物品掉落，这部分的逻辑以后再不上吧，就到这里了，希望大家指正。