03-趣味设计
趣味设计——核心机制、反馈密度与受控自由
一句话
「有趣」不等于「机制越多越好」，而更像是核心机制产生的反馈价值 × 玩家愿意持续接收这个反馈的成本。一个机制就是一台「趣味发生器」，关卡负责让玩家在受控自由里反复触发它。
游戏系统论把趣味浓缩成一句话（趣味 = 认知闭环的密度）；本线展开 11 篇的完整内容：Bug 即机制、核心机制可探索、反馈密度、教学曲线、内容不完整与交互闭环、开发者疲劳与新手测试、第三关陷阱、AI 测试与玩法涌现、关卡设计公式、受控自由与甜点区。
一、为什么充满 Bug 的游戏反而有趣
会觉得它「有趣」，恰恰可能不是因为它做得好，而是因为它暴露出了游戏系统本身的趣味性。
即使角色、敌人、平台、金币全都像 Bug 产物一样乱七八糟，玩家仍然能够看懂：我是谁 → 我能怎么移动 → 什么东西会伤害我 → 什么东西可以收集 → 我要怎么到达右边。这说明游戏的核心乐趣并不完全来自画面。
趣味来源六因素
- Bug 反而制造了「探索感」：正常游戏是「开发者设计规则 → 玩家学习规则 → 玩家利用规则」；Bug 游戏变成「玩家看到异常 → 猜测规则 → 尝试 → 发现结果 → 更新自己的理解」。玩家实际上是在探索一个不完全知道规则的系统
- Bug 让「系统」变得可观察：玩家看到的不是「代码」，而是「游戏规则发生了意外组合」，所以 bug 本身就成为了一种新的游戏内容
- 「不确定性」会增加乐趣：玩家会产生一种类似实验的感觉——「卧槽，怎么还能这样？」这种瞬间本身就是一种非常强的反馈
- 有一种「玩具感」：像一个可以随便摆弄的游戏世界——物理玩具/沙盒/积木的乐趣
- 「丑」本身也降低了心理负担：简单的几何图形让它更像一个游戏系统的实验场，你会开始关注「这些东西之间到底是什么关系」，而不是「这个角色画得好不好看」
- 真正有趣的可能正是「系统涌现」：
1 | Entity A + Entity B + Rule X + Bug Y |
正常游戏 vs Bug 游戏
| 正常游戏 | Bug 游戏 |
|---|---|
| 规则明确 | 规则部分未知 |
| 玩家执行设计 | 玩家探索系统 |
| 错误通常是失败 | 错误可能变成玩法 |
| 学习固定机制 | 不断发现新机制 |
| 内容由开发者提供 | 玩家自己发现内容 |
Bug 并不一定等于无趣。 真正决定趣味性的，是：玩家是否能够观察到规则、预测规则、利用规则，并在规则发生意外时产生新的可能性。
二、核心机制是可探索的规则系统
关键：把 Bug 提炼成正式机制（故障即机制）
完全可以做成一个真正完整的游戏。关键不是「修掉 bug」，而是把那些偶然现象提炼成正式的核心机制——一种「故障即机制」（Glitch as Mechanic）的平台游戏。
核心循环
1 | 探索关卡 → 发现异常 → 产生疑问 → 尝试操作 → 发现异常规律 |
把 Shift 机制正式化
1 | Shift → 进入 Glitch 状态 → 角色出现重影 → 碰撞规则发生变化 |
不要马上告诉玩家答案
- 第一关：正常移动、简单敌人、简单跳跃
- 第二关：某处出现短暂重影，玩家可以看到，但不知道原因
- 第三关：正常路线无法通过；Shift 会导致异常现象；玩家实验、发现异常状态
- 第四关以后：开始主动要求玩家利用异常
于是玩家自己完成「Bug → 机制」的认知转换。
建立多个「故障机制」
1 | Shift → 角色重影 → 碰撞异常 |
这些机制之间还可以组合——玩家自己发现组合以后，会产生非常强的「我破解了这个游戏」的感觉。
最终的三层结构
1 | 第一层：正常游戏 跑/跳/躲敌人/收集金币/到达终点 |
核心不是「如何跳得更准」，而是「这个世界到底遵循什么规则？」最漂亮的地方在于：开发者把规则设计出来，但不把规则全部告诉玩家。 玩家通过游玩、观察、失败和实验，把规则自己挖出来。
三、趣味公式：核心机制 × 反馈密度
「有趣」不等于「机制越多越好」，而更像是核心机制产生的反馈价值 × 玩家愿意持续接收这个反馈的成本。
一个机制就可以成为完整的「趣味发生器」：
1 | 移动 → 重影 → 异常 → 尝试 → 发现规律 → 利用 → 通关 |
操作 → 反馈 → 理解 → 再操作 → 更强反馈——只要这个闭环本身有吸引力，就已经能够成为游戏。所以：
1 个有价值的机制 × 高密度反馈，可能比 10 个普通机制 × 低密度反馈更好玩。
复杂游戏是在增加「可吸引面」
商业游戏不断加入东西（战斗/装备/升级/技能/剧情/探索/收集/建造/社交）并不单纯是因为「内容越多越高级」，而是因为不同的人喜欢不同的反馈——复杂游戏很多时候是在扩大自己的受众交集。
但每增加一个机制，也增加了认知成本
1 | 玩法增加 ≠ 趣味必然增加 |
于是复杂游戏会产生一个非常典型的分化：「好多东西，好有趣」vs「好多东西，好累」。
反馈时长：一次操作到获得反馈需要多久
这个原型：
1 | 按 Shift → 立即出现重影 → 立即死亡/移动异常 → 马上知道发生了什么 |
反馈非常短。而复杂游戏可能是：
1 | 接任务 → 跑地图 → 打怪 → 收集材料 → 回城 → 制作 → 装备 → 再打怪 |
几分钟甚至几十分钟才形成一次大的反馈。这不一定不好——长反馈周期也能产生期待、积累、成长、目标感，但它要求玩家愿意投入这段时间。
游戏体验的两个方向
1 | 高密度、小闭环： 尝试 → 反馈 → 理解 → 成功 → 下一次 |
两者没有谁天然更高级，只是玩家付出的时间尺度不同。
真正容易劝退的不是「复杂」，而是「复杂但反馈价值不够」
1 | 学习成本 ↑ 操作成本 ↑ 等待时间 ↑ 信息量 ↑ |
玩家就会觉得「我为什么要学这么多东西？」反过来：
1 | 学习一个规则 → 马上发现用途 → 马上获得反馈 |
玩家就会觉得「我刚学会这个，马上就有用了」。
一条很普遍的规律
核心机制负责产生趣味，额外机制负责扩展趣味。
核心机制如果本身很弱，加 20 个系统仍然可能不好玩；核心机制如果很强，一个机制就已经能玩，再通过内容、变化、组合把它延长。所以真正值得问的不是「我的游戏有多少机制？」，而是：
「玩家从一次操作到获得反馈，需要经过多少东西？」
「这个反馈本身值不值得玩家再操作一次？」
四、短周期认知反馈与教学曲线
这类游戏真正的核心可能不是「Bug 平台游戏」，而是「极短周期的发现—理解—利用—反馈」体验。
它为什么会让人停不下来
1 | 看到异常 → 「这是什么？」 → 尝试 → 出现反馈 → 「我懂了。」 |
这个「我懂了」的瞬间本身就是奖励。它和学习一个新东西非常像。
「每次只教一个东西」非常重要
不要一次教重影+瞬移+敌人复制+特殊碰撞+反重力。而应该：
1 | 第 1 小段：只认识重影 |
每一小段都像一次微型课程：观察 → 尝试 → 理解 → 应用 → 奖励。
为什么它不适合做很长
一个机制的完整体验是：陌生 → 困惑 → 发现 → 理解 → 熟练 → 失去新鲜感。它天然存在一个生命周期。所以这种游戏更适合短小、高密度、不断产生新发现——每个单元都有完整的「等等……啊！原来是这样！」
可以直接借鉴消消乐的结构
1 | 消消乐：看到局面 → 做一次决策 → 立即产生反馈 → 新局面出现 → 再决策 |
消消乐提供的是组合反馈，这个游戏提供的是认知反馈。成功点可能不是「+100 分」，而是「卧槽，我终于知道重影是什么了」。
「发现不了会不会挨骂」是非常真实的问题
会。这是这种设计最大的风险。「我没发现机制」和「这个游戏根本有 Bug」在玩家体验上非常接近。所以这种游戏绝不能依赖玩家纯猜。
最好的设计不是「完全隐藏」，而是「半隐藏」
答案不告诉你，但线索一定给你。
玩家虽然不知道答案，但能够推理出答案——这是关键区别。
真正的教学曲线应该是「快速递进」
1 | 00:00 正常平台游戏 |
整个游戏可以做成「机制短篇集」：Chapter 1 重影 → Chapter 2 死亡 → Chapter 3 碰撞 → Chapter 4 复制 → Chapter 5 时间。
真正的核心是：用极短的关卡，让玩家不断经历「我不知道 → 我发现了 → 我会用了」的认知跃迁。 几十个 10 秒～2 分钟的微型挑战，每个挑战只解决一个问题——这种从不理解到掌握的成长，可能才是它真正最强的成瘾点。
五、内容不完整与交互闭环完整
它有趣的地方可能恰恰来自「游戏没有被设计完整」，更准确的状态是：底层可玩的东西已经实现了，但上层内容设计没有跟上。
把游戏拆成两层
1 | 下层：程序实现 输入→移动→跳跃→碰撞→敌人→死亡→重生→关卡→终点（已经能运行） |
所以形成一个很奇怪的状态：「代码已经像一个游戏了，但游戏设计还不像一个完整产品。」
为什么「不完整」反而没让你立刻觉得无聊
因为它去掉了大量非核心摩擦：开始 → 玩 → 到终点，每一次操作都直接作用于核心目标。成熟游戏往往是在核心玩法外面包了非常厚的一层内容，而这个游戏外面的东西几乎没有——你会特别直接地感受到「我正在操作这个东西本身」。
内容不完整，但交互闭环完整。 这两者差别非常大。
六、开发者疲劳与新手测试验证
「开发者已经玩腻了」≠「玩家会觉得无趣」；但「开发者觉得有趣」也≠「玩家一定会觉得有趣」。
开发者没有办法恢复「第一次」，所以不能用自己的感觉判断游戏。
设计变量
这个原型已经出现几个非常重要的设计变量：目的明确、反馈快、失败成本低、重试快、难度递进、机制新颖、每个阶段只增加少量信息。 它靠的不是「内容很多」产生趣味，而是单位时间内不断产生有效反馈。
复刻旧游戏但加入新东西就是新游戏类型出现的方式
1 | 玩家已经熟悉的平台游戏框架 + 一个新的核心交互 → 产生过去没有体验过的行为 |
这也是为什么完全原创、完全陌生的玩法反而未必容易让人玩。
「不会卡住进度」尤其重要——难 ≠ 卡
- 好的挑战让玩家产生：「我再试一次，这次应该可以。」
- 坏的挑战让玩家产生：「我不知道该怎么办。」
不要用「我已经玩了很多次还觉得有趣」判断
游戏开发者应该问的是：一个从来没见过这个机制的人，在第一次 5～10 分钟里会经历什么？
最好的验证：拿一个完全没接触过的人，不要解释，让他直接玩。观察：
1 | 第一次看到重影：他会不会停顿？「嗯？」——如果有，这是好信号 |
可以刻意采用「短篇机制制」
1 | 机制 A（5～10分钟）→ 结束 → 机制 B（5～10分钟）→ 结束 → 机制 C…… |
每一章都重新产生一次「我没见过这个」。这比不停堆复杂系统更符合「反馈密度」原则。
「第三关只有不掉落、不碰障碍」其实是很好的主线
它把玩家注意力压缩到两个变量：不掉落 + 不碰障碍太多次 → 到达终点。金币存在但没有真正改变目标——此时金币不是「系统」，只是环境中的视觉刺激 / 可选目标。这样玩家的注意力不会被「任务 → 金币 → 升级 → 商店 → 装备」分散。
这个原型最大的价值，是它意外地找到了一个很干净的公式：旧游戏框架负责让玩家马上会玩；新机制负责让玩家第一次觉得「没见过」；短关卡负责保持反馈密度；低失败成本负责让玩家愿意实验；逐渐增加挑战负责把「发现」变成「掌握」。
七、第三关陷阱：多个差一点的假解
第三关真正有趣的不是「有一个 Bug 通关」，而是「关卡制造了多个看起来合理、但实际上都差一点的假解，最后唯一真正有效的是异常解」。
结构
1 | 上方异常路径 |
玩家第一眼会认为「这里应该有三四种办法可以过去」，于是开始尝试，结果每次都「差一点」——产生一种很特殊的排除式探索：假设 A → 实验 → 否定 → 假设 B → 实验 → 否定 → …… → 发现异常路径 → 成功。这已经很接近一个微型解谜了。
「差一点」是非常重要的设计信号
- 完全失败 → 游戏坏了？
- 差一点成功 → 我是不是快找到了？
后者会主动推动玩家继续尝试——这是非常强的反馈。但要注意：如果所有正常方法都只是「差一点」，而玩家不知道为什么差一点，很容易从「我要破解这个东西！」变成「作者是不是没测试过？」。所以不要让玩家尝试十几种假解，可能只需要：明显可行方法 A → 差一点；明显可行方法 B → 差一点；异常现象 C → 成功。
与前两关的「重影教学」完全接起来
1 | 前两关：重影 → 玩家认识 → Shift → 玩家发现异常 |
前面学到的东西，在后面突然拥有了真正的用途。 这是非常好的关卡设计结构——可以把第三关设计成一次「知识迁移」。
八、AI 测试通道与玩法涌现
Code Agent 并不擅长像人一样连续操作复杂游戏系统——需要实时观察、精确移动、判断时机、连续输入。如果 AI 的目标是「让游戏能够被自己测试并通关」，它可能会把引擎或游戏规则调整成：Shift 按住 → 速度增加 → 持续向前 → 减少需要精确操作的次数 → 甚至可以直接冲过关卡。 这样测试问题就骤然简单了。
这可能解释了几个奇怪现象
「前两关正常也能过，但 Shift 可以强行过；第三关正常路线似乎不行，而 Shift/异常路线能过」——从「玩家设计」的角度看会觉得奇怪；但从「AI 自己必须完成测试」的角度看非常合理：「我要减少操作复杂度。」 Shift 可能不是为了给人类玩家增加一个技能，而是为了让 Agent 能够可靠地完成「开始 → 前进 → 到达终点」——非常像一种为自动化测试而产生的控制通道。
两套「可玩性」意外重叠
1 | 人类玩家模式：正常移动/跳跃/规避/探索 |
本来只是为了让 AI 更容易操作的机制，被人类发现以后：「诶？这个东西可以这么玩？」——测试工具变成了玩法。
三种可能的成因
- 有意识设计：Agent 明确发现「正常控制太复杂 → 增加 Shift 加速 → 用它测试关卡」
- 局部工程修复：Agent 只是发现「角色移动太慢」于是加速，后来这个加速恰好解决了第三关
- 测试策略导致的涌现：Agent 的自动操作器本身就是「按右、必要时 Shift」，于是游戏逐渐被调整成最适合这套操作器的形态——最后并没有谁明确说「我要创造一个 Shift Bug 机制」，但整个系统最后演化出了这个机制（这其实更有意思）
这也可能解释为什么第三关特别奇怪
假设 Agent 的实际目标函数非常简单：goal = reach_goal。那么它根本不会关心金币、漂亮跳跃、正常路径、玩家技巧、关卡美感，只关心「能不能让角色到达终点」。人类玩家看到的「Bug 通关路线」，实际上可能只是Agent 找到的最低成本解——因为 AI 根本没有义务为你保留一个漂亮的正常解。
这反而给游戏带来了一个非常独特的身份
这是一个被 AI 测试过，但并没有完全理解其自身规则的游戏。玩家的任务就是：找出这个系统真正允许什么。
如何确认三种成因
要确认是不是 AI 特意把引擎调整成了这个样子，最可靠的办法是去看它修改代码的过程——例如 Shift 的处理、玩家速度参数、碰撞/重影逻辑，以及它进行自动测试时实际发出的输入序列。看到这些，就能区分「有意设计」「工程修补」「测试过程中涌现」三种情况。
九、关卡设计结构与设计公式
关键不是「故意做一个 Bug」，而是先构造一个正常规则下具有多种尝试、但都差一点的障碍，再让引擎里存在一个能够改变解空间的异常运动机制：
1 | 复杂但可理解的世界 → 正常规则 → 障碍由多个元素共同组成 |
这里最关键的是「差一点」
- 如果障碍是「碰一下就死」，玩家只会觉得残酷
- 如果是「怎么走都完全过不去」，玩家会怀疑关卡坏了
- 但如果「每一种方法都好像快成功了，只差一点」，玩家就会自然产生「是不是我的操作还不够？」，于是继续调整——这就是很好的实验诱因
「不一碰就死」特别重要
碰到障碍 → 扣一次机会 → 被撞开/改变位置 → 还能继续。这样玩家可以在一次尝试里获得大量信息：「这里碰到了」「速度不够」「跳早了」——一次失败不是浪费，而是一次实验结果。
最理想的递进
1 | 第一关：认识移动 → 第二关：发现加速 → 第三关前半：发现加速不能解决所有问题 |
第三关实际上完成的是：「从掌握操作 → 掌握机制 → 组合机制 → 解决问题」的一次完整学习。
「世界复杂」不能理解成「系统越多越好」
需要的是局部关系复杂——一个障碍区域只有平台+箱子+移动障碍+高度差+玩家速度+跳跃，单独都很简单，组合起来互相影响，已经足够产生很多行为。
不是不断增加机制，而是用少量机制组合出足够丰富的局部问题。
边界：看起来像 Bug，但行为必须稳定可重复
这个设计不能真的依赖「不可预测的 Bug」，最好变成：
1 | Shift + 跳跃 → 永远产生某种重影状态 |
玩家第一次可能不知道原因，但第二次尝试会发现「啊，它每次都是这样的」——这样才会从 Bug 变成隐藏规则。否则玩家每次结果都不一样，就不是探索，而是赌博。
十、受控自由与认知负担：甜点区
不是自由度越高越好，而是让玩家感觉「我可以自己决定」，同时设计者实际上控制了玩家的选择空间——表面自由，实际有界。
甜点区
1 | 选择数量 |
真正舒服的状态可能是：玩家面前有 2～4 个看起来合理的选择，但游戏通过环境、反馈、难度、路径把大部分注意力自然引向其中一两个。 玩家感觉「是我选择了这个」，而不是「游戏规定我必须这么做」。
引导也一样
- 引导太少：「我不知道应该干什么。」
- 引导太多：「你直接替我玩算了。」
- 最好的引导很多时候不是文字，而是环境本身在告诉玩家下一步大概是什么（环境引导，而不是说明书式引导）
内容丰富也存在同一个问题
1 | 太少 → 无聊；适量 → 探索、学习、理解（最舒服）；太多 → 认知负担 → 不知道哪个重要 |
优秀游戏不一定是让玩家知道很多东西，而更像：让玩家在当前时刻只需要知道最重要的那一点。
一种非常明确的原则
世界可以复杂，但玩家当前面对的问题要简单。
场景中有平台、金币、敌人、箱子、移动障碍、重影——但当前时刻玩家只需要关注那一个关键障碍。这就是「每次只专注一件事」在关卡层的落实。
世界的复杂度 > 玩家当前决策的复杂度。
玩家可以看到一个丰富的世界，但每次只解决一个小问题——既有丰富感，又不会产生信息爆炸。
再往前一步，这也连接难度：真正舒服的挑战不是「选择很多 + 操作很多 + 信息很多」，而是「信息少 + 选择少 + 结果明确 + 稍微有难度」然后成功，再增加一个因素再成功：
1 | 简单 → 简单 + 新东西 → 旧东西 + 新东西 → 两个东西组合 → 稍微复杂 |
这是自然的难度曲线；而不是「第一关 1 个机制 → 第二关 5 个 → 第三关 12 个 → 第四关 30 个」把玩家直接淹没。
与其他线的关系
- 与游戏系统论：游戏系统论把趣味浓缩成一句话（趣味 = 认知闭环的密度、核心机制 × 反馈密度）；本线展开完整推导（Bug 即机制、教学曲线、甜点区、AI 涌现）
- 与拆解游戏线：本线就是「拆解玩法」的子线之一——核心玩法是什么、为什么好玩
- 与关卡抽象模型（12-游戏/01·二·A）：关卡设计公式（差一点假解、知识迁移、受控自由）就是闯关游戏的关卡抽象模型（Actor/Environment/Interaction/Goal）的具体设计原则
- 与工程控制主题：AI 测试通道（减少操作复杂度让 Agent 能测试）是「测试驱动」在游戏领域的意外副产品
- 与验证线：开发者疲劳与新手测试 = 验证线的新手体验验证；AI 测试通道 = 验证线的可通关性验证（AI/Bot 迭代规则通关）；反馈密度 = 验证线的趣味性验证