如何输出稳定灵活的系统框架？

作者：骄傲公鹿（ID：jiaoaogonglu）2018-12-17

写在前面

建立《系统关联表》的意义在于，帮助新手更加客观地审视自己设计出的系统，是否足够稳定、灵活。在工作前期，输出规则文档时更加全面、中期频繁改动时降低连锁反应的发生几率和影响范围、以及后期添加新玩法时使新系统与主体耦合性更高

游戏设计策划案总是太笼统？

系统规则文档总是丢三落四？

需求一改就牵一发而动全身？

新增玩法老跟主体格格不入？

归根结底，是不清楚自己的设计框架是否灵活稳定

没关系，一张《系统关联表》，祝你生发快乐！

正文开始

建立《系统关联表》的意义在于，帮助新手更加客观地审视自己设计出的系统，是否足够稳定、灵活。在工作前期，输出规则文档时更加全面、中期频繁改动时降低连锁反应的发生几率和影响范围、以及后期添加新玩法时使新系统与主体耦合性更高

在游戏中，将“可以对自己或他人产生效果的事物”称之为“元素”

（并不纠结命名，随便你们叫什么。为了不在辨识上浪费时间&方便沟通，最好命名有意义，参考程序中的驼峰命名法、匈牙利命名法）

元素类型并没有特定的范围，所有你认为对你的设计框架可能产生影响的元素都可以标记出来，验证关联。如果游戏略大，可以通过归纳元素类型，优化显示，有利于检索。

例如这里是我自己使用的归纳类型：

资源型：金币/钻石/体力/宝箱……
行为型：跳跃/攻击/冲刺/聊天……
系统型：镜头/地图/图鉴/排行……

Ok，了解到这里就足够了

识图

我们来看一张表，这个就是今天的主角啦——《系统关联表》（以下简称《表》）：

（图为个人demo示例）

我们通过制表的方式对设计元素间的关联性做梳理。这其中：

1.表示主体元素

2.表示对象元素

3.表示元素之间的关联性

4.表示图例项

5.表示关联内容

我们要做的就是，用关联性判断语句对每个元素进行检查：

——“XXX对YYY会产生什么影响/产出什么？”

在制表时有以下几条规则需要了解：

1.每新增一个元素，在行&列末尾各追加一栏，并对其做关联性判断

2.任意关联只发生在两个元素之间，不经过&不指向第三个元素

3.在关联内容中，若宾语非元素时，应给予标记&注释

4.元素指向只表示“产生了什么”，不计算消耗

5.每个元素应至少与其他两个或以上的元素产生关联

6.行表示元素对其他元素的关联性、列表示被关联

OK，了解到这里就足够了

下面我们用实战来解释《表》的使用：

实例&流程

1.确认元素：在跑酷游戏中，镜头和场景的流畅过渡和转换是我认为很重要的元素，所以我决定先输入到《表》中：

2.添加元素：（建议按照优先级和重要性进行罗列）

3.用关联性判断语句对元素进行口头判断：?（只需要在表中X√就好）

i. “镜头会对镜头产生影响吗？”“不会”

ii.“镜头会对场景产生影响吗？”“不会”

4.输出图例项：

5.追加元素：

【移动】是跑酷中相当重要的元素，在行&列的末尾各追加一栏：

在demo中移动设定有跑动/冲刺/跳跃三种状态，具体影响会在关联内容中详述，在表中统称为【移动】。

如果你认为必要，可以将每种状态作为元素纳入表中，比如马里奥的【跳跃】是整个游戏的主旋律，直接拿出来做判断会更加直观。具体视游戏而定。

对【移动】做判断：

a.“移动会对镜头产生影响吗？”“会，跳跃&冲刺时镜头有延迟偏移”

b.“移动会对场景产生影响吗？”“会，冲刺时给场景一个滚动速度增量”

c.“移动会对移动产生影响吗？”“不会”

d.“镜头会对移动产生影响吗？”“会,角色移动到镜头外，视为死亡”

6.重复1~4，直到你认为元素关联已足够工作使用（在任何时候，你都可以对本《表》进行增删改查，同时要记得及时将改动同步到其他关联的文件中去）。

7.输出关联内容：

8.调整关联表：我认为道具对障碍这部分，优先级不高，可以放到后面当成优化内容做，于是我重新标记其在《表》中的位置为“？”（待定）

至此，你已经完成了对一个游戏的系统设计梳理！！！

篇末答题

现在回答文章开头的三个问题：

1.游戏设计策划案总是太笼统？

——视系统大小，从关联内容中选取内容做进一步描述

2.系统规则文档总是丢三落四？

——根据规则文档规范，将关联内容再加工，形成文档

3.需求一改就牵一发而动全身？

——接到需求时查看对应元素在《表》中与其他元素的关联情况，精准改动，使影响范围处于可控范围

4.新增玩法老跟主体格格不入？

——设计玩法前查看《表》，对关联性不强的元素给予更多权重

Q&A：

1.Q：为什么只计算产出而不计算消耗？

A：《系统关联表》的主要功能是为了缕清系统、功能、元素之间的关系。为了更加清晰的表明各元素间的指向性。只需要知道父与子的继承关系即可。而消耗产出属于经济模型，暂不在讨论范围内。（如果你一定要表明消耗，就将其视为默认消耗自身把，如体力与金币有关联，你可以理解为（消耗）体力产出了金币。）

2.Q：将系统全部打碎成元素好像并没有理顺思绪啊？

A：举个例子：我推荐的《系统关联表》是这样的：

如果都堆到一起，是这样的：

这仅仅是三个元素而已，如果是7个、20个呢？

图表可以通观全局，但是太过繁杂的关联性一般人很难画出美观/便于理解的总览，表格的优势就在于可以清晰有序表明单个元素的位置与内容

当我们需要查看某一元素时，只需在表中快速找到对应元素所在的行&列即可。如需追查元素链（不是炉石传说）也可以临时拿高亮颜色标记即可。

Less is more. 《系统关联表》是一个辅助向的工具，而非你有了这张表就一定能设计出完美的系统。关键在于理解。

3. Q：绿色问号的意思你没有解释

A：待定的意思请根据你个人的实际情况赋予含义，它可以是你不确定有没有关联、也可能是下个版本可以优化的点……标记的含义是在众多内容中提醒你“不要忘记，这里还有需要确定的东西”

4. Q：你是从哪里得到设计这种表格的灵感的呢？

A：灵感来源于日常生活中对知识的广泛涉猎和思考总结。

我自以为促成这张表格的灵感来源于《游戏设计艺术》一书的【28号透镜：状态机】和【49号透镜：优雅】也给予了我一些灵感。比如：“哪个对象拥有哪些属性、属性又有哪些状态，决定权完全在你”，以及“还有一条好莱坞传下来的经验法则：如果剧本中有一行的目的不足两个，就该砍掉……在自己的游戏中寻找那些只有一个设计目的的东西，然后考虑哪些可以合并起来”

有关联的也有：复式记账法、二维表、穷举法、状态机，虽然这个答案看起来跟游戏一点关联都没有。但，灵感不就是将元素从原有的框架中拯救出来，再重新组合又不显得突兀么~

5. Q：《系统关联表》好像只能在小游戏里用，大型游戏如何使用呢？

A：如果你按照“游戏—系统—功能—元素”的顺序一层层剥离开来，使用《系统关联表》是可以重新梳理任何类型任何复杂度的游戏的

可以看到，在下图中，公会系统与其他元素具有很强的关联性，因为我想要的【公会】是一个强社交状态（决定权完全在我！而这也符合【公会】的一般形象）

【商店】则仅能售卖官方道具（目的不足两个），我在之前的设计中将道具回收放在了商店里，但是在测试过程中要频繁跑商店卖掉战利品真是太繁琐了，于是我将【回收】放到了背包里。

“？”位置是我决定为它赋予一个新的关联，与另外一个元素，以增强它与游戏整体的关联性（如果元素拟人化，他们一定是互帮互助，团结一致的好伙伴~）。