这次我们来讨论一些没那么有趣，但是至关重要、与执行息息相关的话题。在游戏的原型体验达到设计预期后，就算正式开始投入制作了。在这一步，通常会需要将各类系统的结构和数据流清晰的整理出来。这一步是非常重要、但是经常被人忽视的。在投入制作之前，将系统结构清晰的整理出来，有助于多线程的推进进度，还可以降低后期维护和更新的成本（前提是能够坚持每次能进行结构整理）。所以这一次我们就尝试把匹诺曹的战斗系统的核心部分抽象地剥离出来，并且进行一些说明。

本文所展示的内容并不是完整的匹诺曹战斗系统，仅仅只是作为一个示例，讲述一下构建系统的基本方法。

要确认第一个要点是：从不同层级来观察系统，关注的侧重点也不同。如果在最顶层讨论战斗系统，那么我们就会更加关注模块之间的沟通和数据流动；对于涉及到模块内部的沟通，可以暂且忽略不计，然后在下一层级中考虑。例如，在匹诺曹的武器系统中，最有特色莫过于武器组合功能。玩家可以将武器拆分为刃和柄，并且可以自由地将不同武器的刃和柄组合起来，构成一把独特的武器。刃会决定武器的基础属性和处决模组；柄会影响武器的加成类型和攻击模组。但是在讨论顶层系统的时候，其他系统并不需要了解这些数据是从何而来的。对于伤害计算的模块来说，它只需要了解武器所产生的攻击数值，再从怪物模块中获得抗性，就能够得到最终的伤害。所以在这一层级进行讨论的时候，武器系统只需要对外提供攻击这一数据。

那么到底要如何开始呢？首先可以将注意力集中在某个最出挑的系统上。以匹诺曹为例的话，就会选择武器系统上。除了上面提到的伤害数值，武器系统中还可以抽象出以下的几个数值。

在这些数值里，我们暂时可以将“耐久度”、“加成类型”、“攻击模组”和“处决模组”放到一边，重点关注顶层层级的数据沟通。“重量”将会影响角色的负重，进一步影响精力恢复的效率。“虚构技”消耗虚构值；“虚构恢复”恢复虚构值。这样我们就能引出战斗资源的模块。战斗资源的最大值又受到角色属性的影响。这样就基本上能够将战斗系统的主要部分。

随后再从图中已有的数据出发，反推其影响因素就能够得到战斗系统的核心部分。例如武器的重量会累计在角色负重上，那么还有什么其他的系统会影响角色负重呢？这样就能引出防御零件系统和义手系统。以此类推，就能逐渐完善系统的结构。

然后我们再以武器系统为例，做一个子层级的系统图。首先将刃和柄的概念带入。然后简单调整一下刚刚提到的几个数据，就能得到下面的图。可以看出来的是，在子层级的视角下，模块内部的数据沟通是关注的重点。其次就是对外的数据接口，也就是“该系统需要给其他系统提供什么信息”。

在武器系统里，武器面板和最终伤害的计算相对复杂一点。首先，刃提供基础数值，柄提供加成类型，再根据加成类型获取对应的角色属性，得到加成数值。基础数值和加成数值相加，就得到武器的面板数值。除此之外，游戏将攻击的动作分为“斩击”和“戳刺”。武器的刃也有一个叫做攻击类型的参数，用于表示刃对不同攻击动作的适应程度。如果刃的攻击类型的柄的攻击动作不匹配的话，那么就会降低最终伤害。

如果设计者对整个系统是有完整的想象和预期的，那么完成系统构建本身其实并没有什么难度。因此拆解一个完整的系统其实就是在描述已知的规则和交互，我们是站在一个完整的视角去看待系统的。只要对这个游戏足够的了解就能够一点一点的理出系统结构。但是实际工作中的难点在于一边调整设计目的和结构性内容，一边还需要维护系统稳定、推进工作流程。尤其是当需求通过表层的现象被提出来的时候，就可能因为图方便，随意地从表层修改，相当于在系统中搭上手脚架。搭着搭着，日积月累，整个系统就开始变成黑盒了，没有人知道完整的逻辑和系统之间的影响，每次微小的改动都可能有极高的风险。这种情况还是希望能尽量避免的。

真的能避免吗……