English
简体中文
“系统驱动类游戏（Systemic Games）”当下正在游戏界中流行。从任天堂的护航大作《塞尔达传说：旷野之息》，到继承了 Looking Glass Studios 衣钵的《杀出重围》与《耻辱》系列，再到育碧正在进行的一系列开放世界游戏，我们都能从其中看到“系统驱动型设计”的影子。
然而，不同设计师对于“系统驱动”的理解都各不相同，尤其是当这个概念与3A 大作挂钩时。很多人认为“系统驱动”是线性叙事的对立概念，另一些人则认为它的本质在于弱化设计师在关卡设计上的控制力。事实上这些分歧并不难理解。开发者可以决定在哪使用、如何使用、使用多少“系统（System）”，是因为它本身就是一个灵活可变的、柔性的设计元素。就像我们经常提到的“机制（mechanism）”一样，他们都是那种能代表一切的词。
1 最简形式的开始
为了开始理解系统驱动设计思想，我们先假设设计师们所有需求都能被简化成一个最精炼的形式：
我需要一个物品，它具有功能 X。
要想让这个设计贴近实际，那么“具有功能 X”必须是一个可实现的具体目标，比如“当事件【下雨】发生时，我想让整个世界中物体的纹理质感发生改变”，又或者“当玩家完成一个任务时，我希望他们能收到一封邮件”。
然而在游戏设计的开始阶段，这个目标通常过于庞大。像“我希望我的关卡能实现自我设计”这样的宏伟设想层出不穷。这个时候，设计师们就需要将他们的需求与设想打碎、分解、降级，就像“我希望关卡的地面能够基于玩家和载具的导航目标来自动生成材质的排列组合”。这个表述比起之前的宏伟设想更加“过程化”而非“系统化”，是因为你实际上是在使用系统创建内容。当设计师能够自信地说出“‘我需要一个物品，它具有功能 X。’这个设计已经具有可实现、可执行性”的时候，一个系统的雏形就已经诞生了。
最终经过一系列设计、分析、拆解与再设计后，你会发现这种设计思想最终将你的目标转化成为了许多“具有功能 X 的物品”。换句话说，这就是很多的系统。而如果一个游戏的绝大部分体验是由系统带来的，那么它就可以被称为是一款“系统驱动型”游戏。
2 什么是好的“系统”
评判一个系统是好是坏的最根本标准就是它能否为玩家持续提供高质量的游戏体验。这段时间越长，那么这个系统的设计就越有价值。然而设计师们经常对这个标准产生错误的理解，将其视为一种对庞大、复杂机制的鼓励。但是就像我在前面写到的，至少在实现上，庞大的设计远远没有最简形式优秀。而接下来，我将说明为什么在效果上同样如此。
与其费尽心思设计庞大复杂的系统，不如建立一系列“具有功能 X 的物品”的最简系统，然后让它们相互兼容并自洽。这样的设计带来的系统间的交互明显能创造出更优质的游戏体验。
举个例子，假设我们正在制作一款背景设定在遥远太空中外星雨林中的探险游戏。我们已经运用之前的最简形式创造了星球上一系列天气系统例如灼热的白天，晴朗的夜晚，热带雨林中的典型暴雨和星球特殊位置所带来的火焰流星雨。
现在让我们开始添加怪物，一只巨大的蜥蜴。如果我能设法让蜥蜴的 AI 系统“知道”我们已经设定好的天气系统，即让两个小系统产生交互，或许会产生一些有趣的反应。比如火焰流星雨突然降临，蜥蜴四散奔逃。亦或是在暴雨中它们的侦查视野范围相比晴天明显减小。这些小的交互细节明显能创造出更加有趣的游戏体验。换个角度说，如果我们的蜥蜴 AI 和天气系统完全独立，外面在发生什么它们都浑然不觉，那么当火焰流星雨一样的极端天气出现时，它们一定看起来相当愚蠢。而且在天气事件发生时和蜥蜴之间的交互可能会让玩家大失所望，因为不管天气如何，他们获得的交互结果都是相同的。这可能会让人感到十分沮丧并带来无聊感，甚至让整个游戏世界失真。
3 一个好的理解角度：编程思想
如果你曾经接触过计算机科学的相关知识，那么你可能会发现前面所说的“系统驱动型”设计思想其实与编程中的面向对象思想有着很大程度上的相似：他们都是通过对于复杂任务的拆分与简化，最终分解成一系列明确可解的问题（类与对象），并最终通过底层元素之间的相互交互完成复杂的问题，实现惊人的效果。
某种程度上来说，“系统驱动型”设计也可以被称为是“面向系统”的游戏设计。而且计算机科学中的一些独有概念比如继承、多态在游戏设计中也有一些价值。总而言之，面向对象思想是理解“系统驱动型”设计的一个良好角度。深入理解二者之间的联系对于游戏程序开发也会很有帮助。
4 所以为什么选择“系统驱动型”设计？
不可否认的是，“手工制作”的内容在整个游戏设计中是不可或缺的。几乎所有的 boss 战斗都包含了独特逻辑、专有脚本与在游戏其他地方无法重复再次使用的内容。而这也是许多高质量游戏选择的道路：为玩家提供那些绝对令人印象深刻的“初见”瞬间。然而“系统驱动型”设计也同样有着它的过人之处。玩家们能在其中获得更长时间的高质量游戏体验，同时游戏的开发成本也要相对低于那些大场面制作。
我们仍然需要记得，系统可以变成任何开发者想要的东西。他们只是一个具有功能 X 的物品，为了满足开发者的特定需求而被设计出来，仅此而已。而且比起“系统驱动型”游戏，在其中穿插“系统驱动型”玩法设计的游戏似乎显得更加触手可及。“系统”和“手工制作”并非相互对立的两个元素，他们只是不同的方式。如果将二者有机结合，也许能产生更加令人惊叹的结果
运用系统的眼光来看待游戏设计只是创造更好游戏的一条途径，但是或许这条路能引领我们走向游戏设计的新纪元，以及蕴藏在系统交互中无限的可能。
有没有“系统驱动设计”相关的书籍推荐
@lucasho：可以看看这两篇文章：
https://www.gamasutra.com/blogs/MikeSellers/20150518/243708/Systems_Game_Systems_and_Systemic_Games.php
https://www.gamasutra.com/blogs/TrentPolack/20161122/286003/A_Systemic_Approach_to_Game_Design.php
我始终认为systemic design很容易产生机制bug，当然，这种所谓的“bug”本身就是各种有趣而惹人会心一笑的“秘技”的源泉（例如旷野之息的最著名的“秘技矿车无限飞行大法”），然而不幸地一旦情况是恶性的，就很惹人烦了（例如黑魂1重置版的PVP模式利用“蛋头人”塞道具害别人被ban）
举个例子，假设某游戏有这些规则：
0、【暂时省略】
1、主角（是一种生物）有个四次元背包，可以用来装道具，容量无限，但不能用来装其他生物。
2、咯咯（也是一种生物）受某生物攻击后，会一直尽可能地“翻山越岭”追着攻击该生物，直至自身死亡或该生物死亡为止。当咯咯发现附近有某生物放置地面的可作饲料用的道具时，会吃下（消耗）该道具，并且会在一段较长的时间之内尽可能地“翻山越岭”追随着该生物。
3、青虫（是一种道具，不是生物）可作饲料、地图画面标记物或通用货币使用；青虫放置在主角背包内一段时间之后，会自动复制增殖（增殖数量与背包内持有数量成正比）。若希望停止青虫的自动增殖，可以在背包内放入将蜡制类道具（如：蜡烛、蜡人像）
4、体衰症是一种疾病，当生物感染该疾病后会传染给同种同类的生物，唯一的疾病症状：每过一段时间，生物身上就会随机掉落一件道具。可通过对染病生物使用果汁类道具治愈。
5、主线剧情NPC（也是生物）们都可以被其他生物攻击。他们被攻击之后，取决于攻击者的身份与之间的关系，会有各种的反应；默认状态下，NPC会追着反击袭击者。在这里，“默认状态”指与该NPC（与及他的关联NPC）第一次发生交流的时候的状态。
我的语言能力不太好，说得有点啰嗦而无谓，希望大致上能表达清楚了。
可以想象，在这样的一部游戏里，应该会有些玩家能想到可以利用青虫当饲料、非正式地“雇佣”咯咯当自己的“随从”（打上双引号，是因为这个“随从”并非机制内的生物的属性之一）把咯咯带到精英怪区域，引诱咯咯和精英怪互殴，自己在旁坐渔翁之利。有的玩家想进一步省事，不想每走一段路就打开背包扔道具，因而可能会让主角感染体衰症，清空背包其他道具，只带着青虫（以单位时间内，增殖与掉落的数量能维持平衡来确定在这里的随身携带数量），让撒饲料吸引咯咯的带路过程全自动化。
如果在这个过程中的路上，主角无意（或有意）攻击了某重要剧情NPC，之后，该NPC奋力反击主角的期间顺带攻击了主角身边的咯咯，咯咯于是就会开始至死不渝地追击攻击者（在这里，就是这位NPC）若一旦发生这种事故，主角唯一的阻止NPC被杀的方法只能是力战咯咯杀死咯咯，或者祈祷NPC足够强大不会输给咯咯。
最近我在黑魂3里遇到了一件类似的事故。
在不死聚落第一次遇到洋葱骑士时，我不知道他是盟友，因为他外观长得很奇怪，我以为他是敌人，砍了他几下，立刻就跟他成为了敌对关系，差点儿就在本周目内彻底毁掉了发展他的支线的可能性。因为不同游戏里屡次遇到的这类事故，我越发觉得，主角可以在任何时候攻击任何NPC这种机制并不总是一种很美妙的主意。
我是有点儿啰嗦了，望谅解。语文水平不好。
@方程：简而言之就是systemic game拥有更多体验gaming the game乐趣的机会。但是这样的乐趣与整体的游戏体验并不一定相符。黑魂就是一个很好的例子，因为gaming the game与它所要表现的氛围、提供的体验几乎完全违背，而dishonored在这方面就不存在这些问题，因为它本身就是对一个精心设计暗杀计划的刺客的沉浸式模拟，所使用的一切手段（包括gaming the game）都是为了最终目标服务。
因此在什么地方使用systemic design是一个设计师需要深入考虑的问题。
@Atlas_w：
以前《体验引擎：游戏设计全景探秘》那书刚刚出中文版那时候，站内热切讨论了好一阵子“跳桌效应”；也许是当时 “systemic” 这概念还不怎么有名吧，以 systemic 的角度谈论“跳桌”和 immersive sims 的人并不多。我觉得，当时留下的许多内容（经调整后）是还可以用在现在这个议题上面的。稍后我试试在站内找找。
@方程：把社区历史翻了一遍也没找到记忆中那几篇关于“跳桌”与immersive sims的文章，也许是我记错了，将自己在梦里面读到的东西当成是记忆了。算了，作罢吧。(ŏ_ŏ)
换个名字，或许可以叫“面向对象游戏设计”？