游戏机制设计2：道具系统的设计思考过程

上篇文章咱们讨论了掉落机制，有掉落就会有道具。这篇文章我想和小伙伴们分享一下关于道具和背包的设计思路。因为我目前主要工作方向就是游戏中的经济系统，或者说一个开放世界游戏的产销循环。产销循环除了必要的数值调配以外，这些底层系统的设计也十分必要。
有小伙伴和我交流认为，这些核心的、底层的系统，是不需要多“出彩”的，只需要“稳”。我几分认同吧。但我这里想设计的并非多“出彩”，而是足够“兼容”，拓展性足够强。特别是在迭代非常频繁的项目中，这一点尤为宝贵。要做到数据尽量可配置，也就是我们常说的“数据驱动”。
最后，就是求留言，求关注。
定义
按照惯例，我们先用直觉给游戏内的“道具”下一个定义：

游戏里玩家可以使用的虚拟物品。
这看起来没有错，但是当我们给一个名词下定义时候，不应该想着没错，更多时候应该是十分正确。所以我们来抽象游戏道具的含义：

通过某种方式产生的，比如击杀怪物、完成任务或者什么的，概括说就是“和系统交互”；
是有用的，这种有用是多方面的，最基础的是可以改变角色属性的，当然，除了属性外，也可能改变状态；
可以被使用的，但并不会自己使用自己的
所以通过进一步概括，我这里先抛砖引玉的定义一下：

游戏世界中，玩家操控的游戏角色，通过与游戏系统交互产生的、可以被动使用的、使用后多为改变角色属性或状态（也可能是游戏世界）的就可以称之为道具。
这里多说一句，为什么我这里执着于给各种游戏名词下定义。这也是因为我最近正在研究ecs编程模式，在这种模式中entity（游戏中的万事万物）都是各种component（组件，或者说标签）组成的，然后被各种相关的system去观察并且使用。

例如，这里的道具（entity）就是指有“可使用”“是道具”和“可装备”等标签（component）组成的。

道具分类
使用类，可以使用的道具。在使用前不会产生效果，使用的一刻产生效果，并且销毁的道具（一般道具在使用后默认销毁，当然，这里也可以额外设计成可配合的“使用次数”或“不销毁”），从这个意义上讲，游戏内的货币也都应该在数据层面抽象为道具，而在表现层做差异；
装备类，可以装备的道具。一般游戏角色会有一个或多个装备栏，装备在装备栏中的道具会改变角色的属性或状态。装备栏能装备的道具通常有限制；
剧情类，这类道具通常是和任务相关的，是游戏剧情推进的重要工具。玩家并不能使用或装备。除了完成任务、交代剧情，并没有其他作用；
其他，以上三类已经涵盖了游戏中通用的大部分。但依然存在一些其他类型的道具，这类道具是根据游戏类型、游戏内容量身定做的，就不在这篇文章的讨论之内。
数据表设计
按照我的习惯，设计一个系统首先是整理思维导图，然后定义数据表结构，最后才是根据数据表结构整理成程序可执行的设计文档。

数据表结构的设计思路是这样的：

思考数据表的职能：这在设计数据表的时候尤为关键，只有深入思考各种数据表的职能，才能将一些看似密不可分的功能“解耦”，正如前文中所说，这在迭代频率高的情况下尤为关键。一个系统制作出来，就尽可能的复用。是一个游戏策划应该有的思维方式。
定义数据列：数据表中的每一行代表一个entity的话，那么每一列就是组成这个entity所需的component，或者说是这个entity的属性
在道具系统中，我们只需要道具数据表。但正如上文中所说的思考数据表的职能中所说的。我曾经见过糟糕的设计：将武器装备甚至技能相关的功能全部放在item表中，导致item表的列数夸张。并且在大型项目开发中，不同功能的数据是不同人维护的，这也造成了维护成本的提升。试想负责道具的策划和负责武器装备的策划，所关注的数据信息是不一样的。但现在它们在数据表中是同一行。这通常是悲剧的开始。

所以我们先看一下，一个道具大概需要哪些字段，注意，我这里所列出的字段是较为常规的，大部分情况下可以复用的，并且本文的宗旨也不是针对某一项目设计一套完美的道具系统，更多的是提供一种思考问题的方式：

道具ID：唯一标识，数据主键
道具名称：
道具描述：我见过一种比较极端的方式是只配置唯一资源key索引，然后所有的资源都通过同一个key来查找，包括名称文本、描述文本、图标和模型等；
类型：通常包括类型、子类型
能否堆叠&堆叠上限
图标i：索引到图标表
获取途径：一段文字描述或者索引到一个获取途径表
道具等级：或道具品质，用以表示道具的强弱优劣
使用效果：或者通过道具类型区分具体含义，例如药水则索引到技能表，武器则索引到武器表
装备条件
物品保护：特别是网络游戏中对道具进行各种限制，来避免其他玩家角色对游戏平衡的破坏
拾取保护：能否拾取，通常只有触发掉落的个人或团队可以拾取
交易保护：能否交易，部分物品是“绑定的”，或者说游戏设计者人为的限制了道具的交易
丢弃保护：能否丢弃，防止玩家因为误操作而丢弃珍贵的游戏装备。通常是通过二次确认提示框的方式提示玩家
除此以外，还有一些属性是和具体设计方式相关的，没有优劣之分。比如上文中提到的糟糕设计。我一般采用的方案是道具表和装备表分开，通过外键来确认一对一的关系即可。这里只需要在道具表中通过类型字段确认外键需要索引到哪张表。但具体的装备效果请看装备表：

装备表索引：外键，索引到具体的装备效果表中
道具规划
道具是一个游戏中信息量最为庞大的系统之一，因此尽早的规划游戏前期（一般指需要严控产出的前7天）道具的大体数量十分必要。

在很多单机游戏中，“负重”是一个很常见的设计。

但在手机游戏的发展过程中，这一设计逐渐被淡化。这也是因为背包在不同游戏类型中的定义不同，在单机游戏中，背包是游戏性的一环。但在手机游戏中，背包更多时候只是作为一个存放道具的容器。
所以，在手机游戏中背包更常见的方式是格子限制。而且这种格子限制通常也不会收取费用。而是玩家通过更多的在线时间即可获得。这样做也可以侧面鼓励玩家更多的在线时长。