game-systems-design

游戏系统设计

设计游戏随时间演变的行为，而不只是列出功能。将预期的玩家体验与明确的状态、规则、反馈和证据联系起来。

保持与引擎无关。除非用户指定实现环境，否则使用状态表、方程、图示、转换规则和伪代码来表达行为。

核心原则

• 将系统边界视为一种设计选择，针对具体问题和时间跨度确定。
• 根据各部分的状态和行为对其建模，再对使这些部分能够相互影响的关系建模。
• 区分放大变化的增强反馈与抑制偏差的平衡反馈。两者本身都无所谓好坏。
• 将核心循环定义为反复出现的意图—行动—状态变化—反馈循环，它持续吸引玩家的即时注意力。
• 将元循环定义为较慢的循环，它会改变未来核心循环尝试、游戏场次或章节的条件。
• 区分游戏中的实际状态、玩家可见的证据，以及玩家可能作出的解读。玩家无法推断的规则，无法可靠地支持规划。
• 优先采用少量可复用且能产生有意义交互的规则，而非大量例外。
• 在打磨或扩展系统之前，先验证风险最高的假设。
• 将试玩反馈视为体验或问题的证据，而非自动视作正确解决方案。
• 确保意图、模型、原型、实现和当前证据彼此可追溯。

前期调研

在提出替代方案之前，先检查现有的设计笔记、数据、图示、构建版本、测试和约束条件。根据任务需要，尽可能明确以下内容：

• 玩家承诺：玩家的角色、期望作出的决策、期望体验的情绪和掌握程度。
• 受众与情境：预期的知识水平、游戏时长、玩家人数，以及竞技或合作环境。
• 设计问题：要解决的不确定性或失败。
• 范围：单次遭遇、一场游戏、持久进度，或完整游戏。
• 当前系统：各部分、规则、资源、接口和已知依赖。
• 约束条件：制作预算、内容预算、无障碍要求、平台、联网、持久化和业务规则。
• 证据：观察结果、试玩笔记、遥测数据、模拟结果，或仅有假设。
• 所需交付物及受众。

不要因缺少信息而停滞。说明重要假设，标记未知项，并指出哪些证据可以消除这些未知。

工作流程

1. 明确预期体验

在绘制系统之前，先简明描述目标：

The player repeatedly [decision/action] to pursue [goal].
The interesting tension is [tradeoff or uncertainty].
The player should learn [model] and eventually master [skill].
Success looks like [observable behavior or result].
The design must avoid [failure experience].

将模糊的品质转化为行为。不要只说“深度制作”，而应提出这样的具体主张：“玩家可以从至少两种适用于当前情境的配方中作出选择，并能说明每种配方分别适合什么需求。”

2. 设定边界和时间尺度

说明系统边界之内、之外以及跨越边界的内容。指定与问题相关的最小时间步长和最长时间跨度。

使用 系统建模 查看边界工作表、组成部分清单、关系图、反馈分析和示例。

避免不加说明地混用不同尺度。1 秒的战斗反应、10 分钟的遭遇和持续 10 场游戏的升级周期可能会相互作用，但每种都需要各自的状态和节奏。

3. 清点组成部分及其关系

针对每个相关部分，记录：

• 状态：可变数值、单位、初始值和范围。
• 行为：它能够感知、决策、创建、消耗、转换或传达什么。
• 所有权：哪些规则可以改变其状态。
• 可见性：玩家在何时能看到什么。
• 关系：什么内容会在何种条件下、经过多长延迟后传递给另一部分。

移除与当前问题无关的装饰性名词。当时间、注意力、容量、威胁、声誉或回合顺序等非物理部分会实质性地改变行为时，应将其补充进来。

4. 闭合并分类反馈

追踪每个重要输出，直到它离开边界，或返回并影响先前状态。

对于每条闭合路径：

1. 命名面向玩家的目的。
2. 标记每种关系是同向还是反向。
3. 将循环分类为增强型或平衡型。
4. 标记延迟、阈值、上限和非线性区域。
5. 识别谁可以扰动循环，以及什么反馈会显露结果。
6. 预测数值处于低位、正常、高位和对抗性水平时的故障。

检查增强型循环是否会导致优势失控、稀缺性加剧和不可逆的衰退。检查平衡型循环是否存在反应迟缓、振荡、隐性补偿和已获得优势被移除的问题。

5. 连接核心循环与元循环

用动词而非功能名称描述核心循环：

read situation -> choose -> act -> resolve -> perceive result -> choose again

分别描述每个较慢的循环：

complete attempt -> earn or lose persistent resources -> invest -> alter future options -> begin next attempt

然后找出它们之间的每个桥接关系。桥接关系应说明：

• 有什么从核心循环流出。
• 元循环如何转换或储存它。
• 有什么返回后续的核心循环。
• 它是扩展决策空间、单纯提升数值，还是使先前的学习失效。

如果核心循环有趣，但元循环只是不得不做的记账工作，就简化元循环。如果元循环让下一次核心尝试变成自动操作，就限制或转移它的影响力。

6. 设计玩家的心智模型

对于每条影响决策的规则，补全以下链条：

game state -> perceivable cue -> player interpretation -> prediction -> action -> confirming or correcting feedback

思考新玩家能否注意到线索、将线索与正确原因联系起来、预测有用的后果，并从错误的心智模型中恢复。只有当在不确定性下推理本身就是游戏体验的一部分时，才保留不确定性。

不要仅靠增加说明来解决沟通问题。应先改善规则一致性、状态可见性、因果时序和反馈层级。

7. 增加内容前先诊断系统

用有代表性的过程轨迹在纸面上测试模型：

• 首次体验轨迹：没有先前知识或升级。
• 典型轨迹：具备预期技能和资源。
• 专家轨迹：选择经过优化，执行水平较高。
• 恢复轨迹：玩家起步落后或犯下代价高昂的错误。
• 饱和轨迹：达到上限、终局库存和成熟策略。
• 对抗性轨迹：囤积、拖延、串通、退化循环或反复利用漏洞。

症状出现时，应先沿关系链向上追溯，再调整数值。显而易见的故障可能与其原因相隔数个关系。

8. 为一种不确定性制作原型

选择能保留待测互动的最低成本媒介：纸张、卡片、电子表格、由主持人按脚本操作、小型模拟，或交互式数字版本。

使用 原型制作与游玩测试 编写假设卡、测试脚本、观察表、心智模型探查问题和迭代记录。

每个游戏玩法原型都必须让玩家能够形成意图、采取行动、收到依状态而定的结果，然后再次选择。非交互式模型可以测试内部动态，但无法验证游玩体验。

9. 进行游玩测试并重建理解

尽早开展简短测试。先观察，再解释。分别记录：

• 发生了什么。
• 玩家似乎相信什么。
• 玩家之后说了什么。
• 系统记录了什么。
• 团队得出了什么解读。

提出关于预测和解释的问题，而不只询问偏好。例如：“你预计这个选择会改变什么？”以及“下次你会如何获得不同的结果？”

比较新玩家与回访玩家。新玩家能揭示易学性；回访玩家能揭示深度、适应能力，以及先前学到的知识是否仍然有用。

10. 在正确的层级进行修改

选择能解决已诊断原因的最小改动：

• 部件层级：数值、边界、状态或局部行为。
• 关系层级：速率、条件、延迟、方向或可见性。
• 循环层级：缺失的制动机制、薄弱的奖励、死锁或断开的桥梁。
• 整体体验层级：系统产生的结果连贯，却与预期游戏不符。

每次只改动一个因果组合。记录假设、预期结果、观察结果和决策。每次结构性改动后，都重新运行此前的边缘轨迹。

11. 沟通当前设计

使用 设计沟通 编写单页简报、系统规格说明、决策日志、图表标记法，并完成交接检查。

分层组织交付内容：

1. 用于达成共识的单页意图与循环概要。
2. 用于设计评审的系统图和状态规则。
3. 用于实施的数据定义和验收检查。
4. 面向决策者的测试证据和未解决风险。

保持文档及时更新。明确区分提案、已测试行为和已发布行为。

诊断信号

• 只有功能清单，没有系统： 列出了名词，但没有状态变化关系形成闭环。添加行为，并追踪随时间发生的变化。
• 边界不清： 每提出一个问题，模型就会扩大。重新陈述决策和时间范围；将外部细节转化为明确的输入或输出。
• 领先者滚雪球： 成功会让人更快获得更多成功，而反制措施的发展速度跟不上。增加成本、暴露风险、饱和效应、替代路线或情境平衡循环。
• 失败螺旋： 失败会夺走恢复所需的手段。保障最低行动额度，设计有风险的恢复路线，或让挫折改变策略，而不是剥夺行动能力。
• 振荡： 修正措施反复越过目标。降低增益、缩短或显露延迟、扩大容差，或减弱响应。
• 主导路线： 某个选项在所有情境下都最好。加入真正的取舍或不同的适用情境；不要用复杂性掩盖其优势。
• 核心与元系统脱节： 奖励不会影响后续决策，或持久强化让核心玩法变得毫无挑战。重新设计两者之间的桥梁，而不是再添加一种货币。
• 心智模型失灵： 类似行动产生了无法解释的不同结果。去掉例外、明确显示条件，或让反馈更能体现因果关系。
• 模拟有余，玩法不足： 内部动态看似健康，但玩家没有有意义的干预方式。添加决策点和可观察的后果。
• 走过场式试玩： 原型打磨精良，但测试结果不会改变任何决策。测试前先提出一个可证伪的问题。
• 规格说明过时： 实现与文档不一致。先协调两者并明确以哪一方为准，再继续迭代。

必需的交付内容

除非用户要求范围更窄的成果，否则请提供：

• 体验目标和明确假设。
• 系统边界、时间尺度和依赖项列表。
• 部件／状态／行为清单。
• 关系与反馈循环图。
• 核心循环、元循环和两者之间的桥梁说明。
• 玩家心智模型和反馈计划。
• 针对一项不确定性的原型或试玩计划。
• 诊断、失败风险和边缘轨迹。
• 验证标准和当前证据。
• 决策日志或建议的下一项实验。

验证

在将设计标记为就绪之前：

• 每个重要状态都有所属对象、单位或类别、初始条件和边界。
• 每次状态变化都有规则、触发条件和目标状态。
• 每个重要循环都会闭合，或有意退出边界。
• 强化循环有已知限制；平衡循环有目标和可接受的响应时间。
• 核心循环和元循环会交换明确的状态信息，且不会使预期决策失效。
• 决策关键状态有及时且可区分的反馈。
• 玩家经过有限的体验后，能够做出有用的预测。
• 至少检查过一条典型、边界、恢复和利用路径。
• 原型以恰当的保真度测试了所述不确定性。
• 证据与推断分开，未知事项仍明确标注。
• 沟通材料足够精确，能让受众做出或实施下一步决策。