从“告诉玩家怎么按”到“让玩家理解规则”
这节课的核心不是教程 UI，也不是怎么写提示语。
真正的问题是：
一个玩家原本不知道某条规则，怎样通过游玩逐渐把它变成自己的知识？
这也是谜题设计、银河城设计、系统性游戏设计共同的核心。
一、先区分：动作知识、规则知识、策略知识
这是这一课最重要的第一个框架。
假设游戏里有一把冰冻枪。
动作知识
按左键可以发射冰冻枪。
这是最低层。
规则知识
水受到低温后可以结冰。
再进一步：
冰是一种可以承重、滑动、破坏的物质状态。
这就开始有意义了。
策略知识
如果水流正在推动一个危险物，我可以先冻结水流改变环境，再处理它。
这已经不是开发者直接“教”的东西。
这是玩家用前两层知识自己推导出来的。
所以我们以后应该尽量追求：
动作
↓
规则
↓
关系
↓
策略
↓
创造性应用而不是一直停留在：
“按哪个键？”
二、真正好的教学不是“告诉答案”，而是控制变量
这点非常像科学实验。
假设你第一次要教：
风会推动轻物体。
最差的教学环境可能是：
强风
+
敌人
+
移动平台
+
三个箱子
+
悬崖
+
计时器
+
队友玩家即使成功，也不知道为什么成功。
所以第一次应该把其他变量删掉。
比如：
玩家
↓
一个轻箱子
↓
稳定风流
↓
风把箱子推走就够了。
玩家观察到：
风 → 轻物体移动。
这个因果关系必须清楚。
这也是为什么 Portal 的教学那么值得研究。
Valve 在 Portal 2 的开发分享里提到，他们必须同时照顾完全没玩过 Portal 的新玩家和已经很熟练的老玩家。为了让反馈更清楚，他们甚至把 Portal 1 中会弹跳的能量球改成了位置更稳定、关系更容易读取的激光，因为后者更容易让玩家持续看到“输入和结果之间的关系”。Game Developer
这其实就是：
减少解释噪音。
三、第一次教学的目标不是“难”，而是“因果关系清楚”
比如假设 OffMap 有一种新机制：
某种大型真菌吸收声音并膨胀。
第一次遇到，不要做谜题。
场景可能只是：
玩家走近
↓
枪声
↓
真菌明显膨胀甚至出口都不依赖它。
玩家只是：
看到。
第二次：
真菌堵住一条小孔
↓
玩家制造声音
↓
它膨胀得更大玩家可能开始意识到：
原来它真的会响应声音。
第三次再反转：
需要让它缩回去才能通过。
于是玩家开始问：
那怎么让环境安静下来？
这才逐渐变成玩法。
四、“教学”和“考试”之间需要缓冲
一个很常见的错误是：
第一次介绍机制
↓
立刻综合大题玩家会懵。
更健康的结构通常是：
Observe
↓
Try
↓
Repeat
↓
Vary
↓
Combine
↓
Master也可以写成我们之前提到的：
Introduce
Develop
Variation
Combine
Mastery它不是死公式，但非常实用。
GDC 的《Teaching by Design: Tips for Effective Tutorials from Mushroom 11》专门讨论了如何通过实际游戏谜题进行渐进、聚焦的教学，而不是依赖大量手把手提示。GDC Vault
五、一个完整例子：风
我们故意用一个现在 OffMap 完全没有的机制。
假设世界里存在：
定向气流。
它可以影响：
- 轻物体；
- 投射物；
- 烟雾；
- 小型生物；
- 缩小后的玩家；
- 声音传播？也许。
现在设计教学。
第一次：Observe
玩家进入一个大厅。
旁边有纸屑：
风 →→→
纸屑 →→→什么都不要求。
只是告诉玩家：
这里有风，而且它不是装饰。
第二次：Try
一个轻箱子挡路。
旁边有风闸。
玩家打开：
风
↓
箱子被吹走玩家第一次主动使用。
第三次：Variation
出现：
重箱子。
同样的风。
不动。
玩家学到第二条知识：
风不是“推动所有东西”。
而是：
效果和质量有关。
这一步特别重要。
因为它在建立规则边界。
第四次：Combine
现在出现：
缩小枪。
玩家把重箱子缩小。
它变轻。
风把它吹走。
这时候玩家第一次组合：
Size + Mass + Wind。
开发者只需要提供条件。
第五次：Transfer
后来出现一个深谷。
风从左向右吹。
没有箱子。
但玩家突然想到：
“如果把队友缩小，会不会被风吹过去？”
这就是知识迁移。
如果游戏系统真的支持，那就是非常漂亮的一刻。
六、规则边界和规则本身一样重要
这点特别容易被忽略。
假设：
火能烧木头。
玩家第一次看到：
火
+
木箱
→
燃烧很好。
但如果：
- 木箱能烧；
- 木门不能烧；
- 木桥不能烧；
- 木桌不能烧；
- 只有“设计师指定的木箱”能烧；
玩家最终学到的不是：
“木材会燃烧。”
而是：
“某些开发者允许的东西会燃烧。”
系统可信度就会下降。
所以真正的机制教学还包括：
教边界。
例如：
普通木材会烧，湿木材不会立即烧，石头当然不会烧。
这比教程文字重要得多。
七、玩家什么时候才算“真的学会”？
不是第一次成功。
第一次成功可能只是：
蒙的。
我更建议用四个层级判断。
Level 1：识别
玩家知道：
“这个东西有用。”
Level 2：复现
在相似环境里能再次使用。
Level 3：迁移
环境换了以后还能想到这条规则。
Level 4：组合
能够和另一条规则一起使用。
真正的知识通常从 Level 3 开始变得有趣。
八、一个很好的测试方法：移除显眼提示
假设第一次谜题：
蓝色按钮
+
蓝色门玩家成功。
你不知道他学会了：
“按钮控制门。”
还是只是：
“蓝色配蓝色。”
下一次：
按钮换颜色
门换位置他还能解决：
规则学会了。
不能：
之前可能只是表面模式匹配。
这就是测试“概念理解”。
九、知识教学可以使用反例
这是很强但很少被新手使用的方法。
比如要教：
磁力只影响金属。
第一次：
磁场
+
铁箱
→
吸过去第二次：
磁场
+
木箱
→
完全不动不需要文字。
玩家通过对比知道：
不是所有物体都会被吸。
这种 contrast teaching 很有效。
十、再来一个完全假想机制：潮湿与导电
假设 OffMap 世界允许：
水让某些表面变得导电。
第一次：
破损电线
↓
水洼
↓
水洼冒电火花玩家看见。
第二次：
一个敌人站在干地上。
旁边有水管。
打爆：
水流到敌人脚边
↓
电线
↓
敌人受到电击第三次：
一个门的控制线路断了。
玩家需要：
人为制造导电路径。
第四次：
水既是导电工具，也是危险。
于是玩家必须决定：
我要不要把整个房间淹掉？
这就从：
“水 + 电 = 伤害”
变成：
“导电性是一条世界规则。”
十一、机制最好有“积极用途”和“危险用途”
如果一条规则永远只代表：
有利。
它很快会变成按钮。
比如：
冰永远是平台。
那看到水就：
冻。
没有决策。
但如果冰：
- 能承重；
- 很滑；
- 可以碎；
- 会融化；
- 可能堵住水流；
- 可能困住东西；
那么：
冻不冻？
开始成为选择。
你刚才那个“冰面后来可以破坏通往下层”的例子就在这里特别漂亮。
第一次玩家理解：
冰 = 桥。
后来理解：
冰 = 临时实体。
再后来：
冰 = 可能阻塞水流的结构。
同一个东西不断获得新语义。
十二、这种设计有一个很重要的名字：Recontextualization
可以翻成：
重新语境化 / 重新理解。
东西没变。
玩家对它的理解变了。
例如：
第一次：
水面 → 障碍
获得冰冻知识：
水面 → 可以造桥
获得破冰知识：
水面 → 可以先造桥，再打开下层
获得水流知识：
水面 → 甚至可以改变整个区域的流体状态所以以后银河城回溯时，最好的奖励之一不是：
“以前门是红色，现在拿红钥匙回来。”
而是：
以前的地图现在看起来不一样了。
即使模型完全没变。
十三、Knowledge Gate 的公平性
知识锁特别迷人，但也特别危险。
一个公平的知识锁应该满足：
规则之前已经被建立
玩家至少见过。
反馈稳定
同样规则不会忽然反过来。
当前环境存在足够线索
不要求玩家凭空联想。
失败成本合理
如果尝试错误就丢两小时进度，那玩家不敢实验。
解决后能解释自己为什么成功
玩家应该：
“啊，原来如此。”
而不是：
“啊？居然是这样？”
后者偶尔可以，不能一直这样。
十四、Puzzle 是一种“契约”
Clara Fernández-Vara 在 GDC 的 Puzzle Writing 分享里把谜题描述成设计师和玩家之间的一种契约：设计师必须提供足够的信息使问题可解，同时仍然保持挑战。GDC Vault
我觉得这个观点特别适合知识锁。
你可以：
不告诉答案。
但不能：
缺关键规则还要求玩家猜中。
十五、玩家的错误理解也是教学内容
假设你想教：
大型敌人会攻击发出最大噪声的东西。
玩家可能误解成：
敌人永远攻击最近的人。
这时候设计一个场景：
P1 比较近
但安静
P2 更远
制造巨大爆炸敌人转向 P2。
玩家原来的模型被推翻。
这种东西可以叫：
Prediction Error
玩家：
“咦？为什么？”
然后更新自己的规则理解。
这种教学往往比一行文字：
“敌人会优先攻击噪声来源。”
更有记忆点。
十六、再来一个灵感：材料脆性
假设世界里：
温度改变材料性质。
不是简单：
冰冻敌人减速。
而是：
金属极冷
↓
脆性增加
橡胶极冷
↓
失去弹性
某些植物受热
↓
快速膨胀教学可以这样：
第一次：
一根冻裂的金属管自己断掉。
第二次：
玩家主动冰冻薄金属板，再撞击。
第三次：
巨大金属门正常炸药炸不开。
玩家想到：
先冻。
第四次：
一座桥本身也是金属。
于是冰冻就不一定总是好事。
这开始产生：
机制的后果。
十七、再来一个灵感：浮力
假设物体有：
Density / Buoyancy。
第一次：
木箱浮在水上。
第二次：
金属物沉底。
第三次：
缩小一个金属物以后，它仍然沉吗？
这里我们甚至可能故意决定：
Size 改变体积但不同比例改变质量。
于是可以产生非常有趣的结果。
第四次：
玩家需要让一个平台浮起来。
可以：
- 放轻物体；
- 排水；
- 改变尺寸；
- 找浮力材料；
- 多人共同分配重量。
这就是很 OffMap 的系统谜题。
十八、再来一个：声音传播，而不是“敌人听声音”
假设声音不是一个简单半径：
10m 内敌人听见。
而是：
- 墙会阻挡；
- 金属管会传声；
- 空洞空间会产生更远传播；
- 水下传播不同。
那么教学：
第一次：
墙后敌人没听见。
第二次：
管道把声音带过去。
第三次：
玩家用管道远距离引怪。
第四次：
玩家想测某个封闭空间里是否有东西。
敲一下管道。
听回应。
这里就可能自然产生你喜欢的那种：
开发者没有专门设计的用途。
十九、多人游戏会出现“社会教学”
这对 OffMap 非常值得利用。
传统游戏：
UI 教新玩家。
多人游戏还有：
老玩家教新玩家。
这个体验本身可以很好玩。
例如：
老玩家：
“你站那别动。”
新人：
“干嘛？”
老玩家：
*把他缩小*
新人：
“草。”新人瞬间理解：
玩家自身也是 Size 系统的一部分。
这比：
Tutorial Popup：Players can also be resized!
有效得多。
二十、所以不要所有机制都在新手区教完
这特别适合 drop-in co-op。
如果教程承担：
把整个游戏系统全部讲一遍，
后来加入的人就必须：
去上课。
很烦。
更好的模型可能是：
新手区域只教学最低生存语言
比如：
- 移动；
- 交互；
- 基础战斗；
- Inventory；
- 基本世界响应。
之后大部分高级知识：
通过世界逐渐学习。
于是后来者即使跳过前期，也可以：
- 听朋友解释；
- 看朋友操作；
- 自己尝试；
- 在后续区域重新学习。
这会让知识结构更加弹性。
二十一、但要防止“老玩家替新人把游戏玩了”
这是合作游戏很容易出现的问题。
例如谜题：
老玩家：
“别动，我知道答案。”
三秒解决。
新人：
???
所以多人谜题最好不是只依赖：
一次性答案知识。
而更多依赖：
实时合作、位置、执行和系统交互。
这样老玩家即使知道：
“这里要利用风。”
新人仍然可能负责：
- 操作风闸；
- 抬东西；
- 当诱饵；
- 被吹过去；
- 控制敌人。
他仍然在玩。
二十二、一个很实用的谜题设计三问
《What Lies in the Multiverse》的开发者分享过一个受 Portal 启发的框架。他们设计谜题时会问：
这个谜题在教玩家什么？
玩家需要已经知道什么？
这个谜题希望玩家在哪个机制上进一步提高？
这种方法帮助他们控制谜题顺序和难度递进。Game Developer
这个我们以后完全可以直接用。
每个 OffMap Puzzle Card 写：
Teaching:
What new idea?
Prerequisite:
What must player already know?
Practice:
What existing knowledge is exercised?非常实用。
二十三、不要每个房间都教新东西
这是一个非常重要的节奏问题。
如果：
Room 1 新机制
Room 2 新机制
Room 3 新机制
Room 4 新机制玩家会：
信息过载。
所以最好有一些房间只是：
玩。
比如：
Teach A
↓
Practice A
↓
Play A
↓
Teach B
↓
Combine A+B
↓
Play A+B知识需要时间沉淀。
二十四、教学还可以被当成奖励
例如玩家找到隐藏区域。
里面没有装备。
只有一个奇怪场景：
两种世界规则发生了以前没见过的组合。
玩家实验以后发现：
“卧槽，原来还能这样。”
这本身就是奖励。
也就是：
Knowledge Reward。
以后他带着这个知识去主线区域，可能拥有新的捷径。
这种奖励特别适合你们想做的游戏。
二十五、Mechanic Discovery 不一定来自开发者
这点要克制。
假设我们做了：
- Size
- Wind
- Mass
- Rope
玩家自己发现：
缩小箱子后，用风吹起来，再用绳子拉到高处。
开发者以前根本没想过。
不要马上：
做一个教程告诉所有人！
有些知识就应该保持：
社区发现。
这会让玩家之间产生：
- 分享；
- 视频；
- 讨论；
- “你知道可以这样吗？”
这对系统性游戏是很有生命力的东西。
二十六、所以知识可以分成四种
我很建议以后 OffMap 内部这么分类。
Essential Knowledge
不懂就无法正常玩。
必须可靠教学。
例如：
基础交互。
Progression Knowledge
用于推动主线能力理解。
需要逐渐建立。
例如：
Size 对质量/空间的影响。
Advanced Knowledge
不是必须，但能节省资源、提高效率。
例如：
某材料在低温下变脆。
Emergent Knowledge
开发者甚至不主动教学。
例如：
利用落地声音测洞深。
这个分类可以帮我们决定：
到底该不该弹提示。
二十七、本课最大的一个原则
以后设计教学时，不要问：
“我要怎么告诉玩家这个机制？”
而是问：
“我要创造什么样的环境，让玩家能够自己建立这条因果关系？”
这是完全不同的设计姿态。
第四课 Gym
这一课我不建议马上写正式游戏机制。
我们可以做纸面设计。
新建自己的设计笔记：
Mechanic Teaching Exercises随便挑三条假想规则。
比如：
A
风影响轻物体。
B
金属在低温下变脆。
C
声音可以沿管道传播。
然后每个设计：
1. Observe
2. Try
3. Repeat
4. Variation
5. Combine
6. Transfer六个场景。
不需要建出来。
先练：
教学顺序。
一个完整练习模板
Mechanic
声音沿金属传播。
Player should learn
声音传播并不只与直线距离有关。
Observe
敌人在很远的管道出口处，被玩家这边的敲击吸引。
Try
玩家敲管道，引开守门敌人。
Repeat
管道出口改变方向。
Variation
墙体完全隔音，但管道仍能传。
Combine
利用管道制造声音 + 队友潜入。
Transfer
一个封闭房间无法进入。
玩家敲管道，听到里面传来敌人的反应。
现在声音系统变成了：
信息获取工具。
这里就开始出现真正的系统性玩法。
本课完成标准
学完这一课以后，你看到一个新机制，不应该首先想到：
“它能做什么谜题？”
而应该依次问：
它是什么规则？
玩家怎样观察到这条规则？
玩家怎样亲自验证它？
它的边界是什么？
怎样证明玩家真的理解，而不是蒙对？
它能否迁移到完全不同的情境？
它能和哪些旧知识组合？
哪些用途我们应该教，哪些最好永远别教？
当你开始这样思考的时候，“教程”就已经不再是游戏开始那十五分钟的东西了。
整个游戏其实都在教学。
只是前期教：
怎么操作。
中期教：
世界有什么规律。
后期则让玩家自己问：
既然世界是这样运作的，那我还能干什么？
