写在前面：猛然想起，已经很久没有写游戏设计相关的文章了，最近沉迷GamePlay的实现，并且跟风研究ECS框架，属实是有点儿“不务正业”了。昨天晚饭时和同事说起一些策划领域的事，觉得很有意思，索性整理成系列文章，和小伙伴们分享，权当是抛砖引玉。
（之前要是很多系列文章随随便便开坑，但都没有填平，这个之后逐步完善吧。）

定义

今天和大家聊聊游戏中的“掉落”。所以首先我们先一起给掉落下一个定义。对于任何一个游戏玩家来说，所谓掉落，就是：

击杀游戏内怪物会掉落在地上游戏道具的功能。
不过这个说法不够完善，也不太严谨。我们再尽量抽象一点的概括。

首先，不一定是通过击杀怪物，也可以是其他途径；
再者，不一定是掉落在地上，也有其他的表现形式；
最后，也是掉落的核心，游戏性的体现——“随机性”；
所以这个定义应该回答几个问题：谁掉落？掉落什么？怎么掉落？为了回答这几个问题，我们试着重新下一个定义：

掉落是指游戏玩家通过和游戏对象交互触发的，通过一套随机规则最终产生玩家可获得的游戏道具（采用掉在地面或其他表现形式的）的过程。
当然，这只是我给掉落的一个定义。如果你有更好的定义，欢迎评论中交流。

设计

定义是设计的罗盘，保证设计不会跑偏，我认为一个好的设计就是满足定义的，解决问题的。

我对“系统策划”的理解，是不能停留在“需求”层面的，一个有价值的系统策划，应该更深入的关注“设计”层面。换句话说，从写“需求文档”转而变为写“设计文档”。然而可悲的是很多人没有这种意识，而更多的人是没有这种能力的。

这里所说的需求文档，就是指“我要什么”，通常是站在玩家的角度，从外向内的去提出需求；而设计文档，是指“我要的怎么实现”，这需要更进一步的，由内向外的去推敲。将需求抽象成一步步可实现的功能点。

我在实际工作中的方式就是参与或者直接负责表结构的定制。表结构是策划和程序之间沟通的媒介。这样就可以最大可能的约束代码的实现，并且帮助程序更方便的理解需求。实施经验证明，如果策划放任表结构不管，那么程序做出的表结构可能是很难以维护的。策划和程序在表结构上产生的分歧，本身就是“需求”和“实现”之间的分歧。这种分歧在写代码之前暴露出来，无疑是好事。

话说回来，继续聊“掉落”，还记得我们在上文中聊到的三个问题么。我设计表结构时的思路就是每一张表分别回答上边的问题。这也是每一张表的“职能”。下面举例说明：

• 掉落组表：掉落的约束
• 掉落包表：掉落物的随机规则
• 掉落物表：掉落物的表现
• 掉落机制作为游戏中的底层机制之一，是供给上层使用者调用的，而掉落本身不需要关注上层调用者具体是谁。可以是怪物死亡、可以是宝箱开启、可以是抽奖类活动。

掉落组

掉落主表，供上层调用，和掉落包一对多，用以规定归属对象、归属类型、掉落表现和其他限制。

掉落包

我在从前的文章中说过，“随机性”是游戏性的三要素之一。而掉落的核心恰恰在于随机性。

所以这么重要的东西，想也知道我们不可能使用完全随机（“真”随机）。

我一般的方案是使用两种方式：

万分比掉落：按照概率掉落的，多个掉落物互不影响，各自进行随机判断的方式。
权重随机：按照一组掉落物中每个掉落物的权重，随机出一个的方式。
此外，对于权重随机，这里我进行一波拓展，那就是随机次数和随机去重。这也是比较常见的功能需求，很好理解。

最后，另一个有意思的需求就是掉落包的嵌套。这个功能其实有利有弊。但我认为利大于弊，因此一般也会要求实现。所谓掉落包的嵌套，是指掉落包不仅可以索引掉落物，也可以索引其他掉落包，来达到更复杂的掉落规则。

至于掉落包嵌套可能带来的循环引用的问题，完全可以在策划填表时通过自己制作（或者程序帮忙制作）检查工具来判断。在数据配置这一层就要杜绝。

掉落物

实际上，掉落包可以直接索引Item表。是否需要掉落物这一层，主要因项目类型而定。这一层的职能就是处理各种不同的美术表现。

比如，游戏中掉落方式多种多样，有些道具掉落在游戏场景中是模型方式，有一些是图标方式，另一些还可能是粒子方式。这时就可以考虑通过填表来控制，来为策划争取更多的功能自由度，同时解放程序小伙伴。也未尝不是一件好事（岂不美哉？）

后记

游戏中的功能模块，一类是更为独立的玩法或养成系统，另一类则是为整个游戏提供底层支持的核心机制。在本系列文章中，我想和小伙伴们更多的聊一聊在大多数游戏中适用的更为底层的机制的设计思路。以后有机会再开新系列和大家谈谈这些机制的代码实现过程。

预告一下，之后的文章中咱们聊聊游戏里的“刷新”、“技能”及“属性”等功能的设计思路。

小弟不才，见笑。