game-mechanics-design

游戏机制设计

使用此技能，将期望的玩家体验转化为一小组连贯、可测试的机制。不要从类型特征清单入手，而要从玩家反复做出的决策，以及判断这些决策是否带来预期体验所需的证据入手。

核心原则

• 将玩家动机视为假设，而非固定的人格标签。
• 与其设计许多彼此孤立的功能，不如优先设计少数能产生强烈互动的机制。
• 让重要选项清晰易懂、真正各不相同，并会产生实际影响。
• 挑战应建立在玩家习得的技能和易于理解的规则之上，而非隐藏的例外规则。
• 只有在能强化游戏体验本身时，才加入成长系统、奖励和货币。
• 通过安排安全的机会，让玩家行动、观察、重试，并在之后组合运用技能，以此进行教学。
• 珍惜玩家的时间。失败应带来教训，重复应有明确目的。

工作流

1. 检查当前游戏

提出更改前：

• 确认 Godot 版本、目标设备、输入方式、受众、单局时长和多人游戏假设。
• 阅读项目入口场景、游戏场景、输入映射、拥有状态的脚本、资源、存档模型和现有测试。
• 尽可能体验最小可运行循环。记录玩家能做什么、发生了什么变化、成功与失败如何判定，以及玩家能看到哪些反馈。
• 区分已发布版本中的约束与仅在备注中提及或未使用代码中的想法。

如果项目尚不存在，请提出明确假设或说明这些假设，而不是自行臆造开发约束。

2. 写明体验目标

用一句话表达目标：

玩家应通过反复进行<活动>，在权衡<取舍>时，感受到<体验>。

然后确定：

• 主要动机假设，例如精通、探索、表达、完成、社交联结、叙事好奇心或放松。
• 预期的情绪节奏，包括压力、缓解、惊喜和反思。
• 可接受的认知、动作、时间和失败负担。
• 关于变现、随机性、损失、社交压力和留存的伦理边界。

使用动机、选择与挑战来完善并检验这一目标。

3. 梳理核心循环

将最短的可重复循环写成：

观察 -> 选择 -> 行动 -> 反馈 -> 状态变化 -> 下一个决策

针对每个步骤，记录：

• 玩家可获得的信息。
• 玩家行动及其输入负担。
• 需要考虑的规则和资源。
• 即时和延迟的后果。
• 视听反馈。
• 下一个决策与上一个决策有何不同。

如果连续两个步骤都没有改变玩家的理解或可作出的决策，就合并或移除其中一个。

4. 有意识地选择机制

提出多个候选机制，然后根据它们与体验目标、平台、范围、无障碍性、互动深度、教学成本、内容负担和技术风险的契合度进行评分。即使某个机制单独看来很吸引人，只要不符合不可妥协的约束，就应舍弃。

使用机制选择工作坊获取选择矩阵、机制规范和垂直切片流程。

5. 塑造选择与挑战

针对每个重要决策：

• 确保当前情境下至少有两个可行选项。
• 说明玩家在选择前掌握哪些信息。
• 为每个选项设定成本、机会成本、风险或承诺。
• 在适当时机让后果清晰可见。
• 决定选择是否可逆，并如实告知玩家。

通过改变时机、空间、资源压力、不确定性、协作或规划来构建挑战。教学时一次改变一种要求；之后再组合已知要求。如果一次小失误不应决定整局结果，就提供补救途径。

6. 添加支撑系统

只有在核心交互可行后，才评估以下内容：

• 成长与解锁。
• 任务与目标结构。
• 战斗遭遇与敌人定位。
• 收集与库存限制。
• 资源的创建、转换、存储与消耗。
• 教程提示与练习空间。

参考 成长、任务与教程 和 战斗、收集与经济系统。追溯每个支撑系统与核心循环的关联。移除那些会激励玩家绕过预期玩法的奖励。

7. 为风险最高的问题制作原型

创建一个最小可玩测试，用于证伪设计。使用占位呈现、确定性场景和可调参数。要测试某个战斗决策是否有趣，不必构建完整的成长树或内容目录。

在测试前记录预期观察结果，例如：

• 玩家无需设计师帮助就能解释其中的取舍。
• 至少有两种策略能以不同理由取得成功。
• 首次失败能让玩家获得下次尝试时会用到的信息。
• 玩家能通过正常游玩注意到状态变化，而不是依赖调试显示。

8. 根据证据迭代

先观察行为，再询问意见。记录困惑、犹豫、重复选择、误操作、未使用的系统、恢复行为以及玩家停止的位置。条件允许时，每次测试只改变一个因果变量。保留简短的决策日志，将每次修改与相应证据关联起来。

验证

设计检查

• 每个机制都支持体验目标或必要约束。
• 重要选择会带来不同后果，且没有永久占优的选项。
• 挑战依赖的知识或技能，都是游戏已让玩家能够学会的。
• 奖励不会抹消其本应支持的取舍。
• 成长会改变决策，而不只是提升数值。
• 教程可以跳过、重玩，并能使用重新映射后的输入完成。

实现检查

• 在项目条件允许时，将可调数据与不可逆状态转换分开。
• 对经济交易、任务转换、解锁前置条件、奖励范围和确定性随机表进行单元测试。
• 在所有持久状态下测试存档与读档，包括任务中途、库存已满以及奖励仅部分消耗时。
• 对预警提示、反馈时机、HUD 可读性、不依赖颜色的提示以及镜头取景进行视觉测试。
• 在高、低帧率下进行测试；在支持的情况下，使用键盘、控制器和触屏进行测试。

游戏测试边缘情况

• 新手与专家玩家达到不同的挑战极限。
• 玩家忽略预期奖励，或通过优化规避预期活动。
• 发放必需奖励时库存已满。
• 任务目标不可用、已被击败、重复出现或在重新加载时被移除。
• 随机奖励导致长时间运气不佳，或只出现重复结果。
• 货币溢出、变为负数，或可通过重试或断开连接重复获取。
• 玩家已经学会或重新绑定操作后，教程条件才被触发。
• 合作玩家加入、离开，或未按顺序完成目标。

预期输出

生成一份精简的设计文档，包含：

1. 体验目标与约束。
2. 核心循环与重大决策。
3. 已选机制，以及被否决的替代方案和原因。
4. 实际适用的成长、任务、战斗、收集、经济系统和教程方面的影响。
5. 原型范围、可调变量、边缘情况和验证计划。
6. 明确标注有待验证的未确定假设。