一、我们想做的不是“更多解法”，而是一个规则可信的世界
OffMap 希望减少这样的交互：
有一扇特殊的门 → 找到对应能力 → 对门使用 → 门打开。
能力不应该只是钥匙，世界中的物体也不应该只是等待某个指定操作的机关。
更希望形成：
能力改变世界的条件，世界根据自己的规则产生结果。
例如碎石挡路，真正的问题是“它阻挡了道路，并且需要足够大的力量才能破坏”。
因此炸药可以炸开；放大的玩家也许可以砸开；大型怪物可能撞开；未来出现的其他高冲击力手段也可能做到。
墙不需要知道是谁、拿什么武器攻击了自己。
它只需要知道：
我承受的作用是否足以让我破坏？
二、能力改变的是问题的条件，而不一定直接提供答案
缩小/放大能力是一个很好的例子。
它的意义不应该是：
“缩小枪 → 打开缩小枪机关。”
而应该是改变 Size，并让世界对 Size 作出反应。
于是它可能自然产生：
- 缩小滚石 → 威胁降低；
- 缩小巨大钥匙 → 可以携带；
- 缩小玩家 → 可以进入狭窄空间；
- 放大玩家 → 获得更强的物理破坏能力；
- 放大物体 → 质量增加，可以压住机关；
- 改变大型敌人的尺寸 → 改变战斗条件。
这里没有哪个用途一定需要成为“缩放枪专属玩法”。
缩放本身是一条规则，用途来自规则与场景的组合。
三、软锁应该成为控制节奏的重要工具
我们仍然需要控制玩家节奏。
银河城需要硬锁，否则能力获得、区域开放和探索结构都会失去意义。
但不是每个障碍都需要硬锁。
例如：
碎石挡住道路。
早期可以故意移除其他可能性，让“放大”成为进入新区域所必需的能力。这时它就是硬锁。
后期面对类似障碍，则可以存在：
炸药 / 放大 / 大型敌人 / 消耗资源 / 绕路……
这时同一条世界规则自然变成软锁。
因此：
硬锁负责宏观节奏，软锁负责微观自由。
开发者控制玩家大致“什么时候能够来到这里”，但不必总是控制玩家“具体怎样解决这里的问题”。
四、多人游戏：第二个玩家不应该是一把钥匙
尽量警惕：
P1 站按钮 A，P2 站按钮 B，所以这是合作谜题。
如果 P2 临时不来，游戏就无法继续；如果允许 P1 自己解决，P2 回来后又可能觉得自己没有意义。
我们更希望：
单人拥有完整解，多人增加解空间。
例如重门需要足够大的力量：
单人可能需要寻找能源、机械装置、消耗道具或者绕路。
双人则可能一起推。
拥有放大能力以后，还可以放大其中一个玩家。
世界不需要判断：
player_count == 2
它只判断：
当前施加的力量够不够？
于是朋友今天没来，游戏仍然可以继续。
朋友明天回来，他也没有因此变得多余——因为世界里真的多了一个 Actor。
五、“一个人”本身就应该具有游戏价值
第二个玩家的价值不应该完全建立在等级和装备上。
一个刚加入、几乎没有装备的玩家仍然拥有：
位置、身体、体积、质量、力量、感知、携带能力、操作能力，以及被世界影响的能力。
因此他天然可以：
- 吸引敌人；
- 制造声音；
- 操作机关；
- 搬运物体；
- 占据一个位置；
- 压住压力板；
- 接住/传递物品；
- 被队友缩小或放大；
- 被冰冻；
- 帮助施力；
- 与另一个玩家同时出现在两个地方。
所以多人合作的一个重要原则是：
第二个玩家增加世界中的可能性，而不是增加一个必须填写的玩家槽位。
六、进度落后的玩家应该能够快速成为“有用的人”
Drop-in / Drop-out 合作不应该要求：
“你先自己去打两小时新手区域，我们再一起玩。”
世界进度与个人进度最好不要完全绑定。
进度领先的玩家可以利用已有能力帮助后来者：
我没有缩小能力，但你可以把我缩小。
我没有炸药，但我们可以一起搬东西。
我的装备很差，但我可以吸引敌人，你去操作机关。
你已经拥有资源，可以帮助我快速获得基础装备。
这样，“追赶进度”本身也可能成为合作体验。
我们不一定需要让后来者瞬间复制房主的所有装备。
重要的是：
玩家的战斗力可以落后，但参与世界的能力不能接近于零。
七、资源差异可能比单纯的数值缩放更适合多人平衡
不要首先想到：
1P：敌人 100 HP
2P：敌人 180 HP
人数增加以后，更有趣的变化可能发生在解决问题的成本上。
例如：
单人消耗一颗炸药开路；
双人通过合作保存了这颗炸药。
那么炸药以后就可以用于别处。
于是合作产生的收益继续传播：
合作 → 节省资源 → 后续拥有更多选择 → 承担不同风险。
多人优势因此不只是“DPS 更高”，而是：
更多的人，意味着更多分工、更多物理条件、更多信息来源和更高的资源利用效率。
八、世界应该提供“事实”，而不是规定“用途”
一个物品不必拥有：
“用途：测量洞穴深度。”
它只需要：
会受重力影响；
会碰撞；
撞击会产生声音。
于是某个玩家站在黑暗洞穴边，可能自己想到：
“我扔个东西下去，听多久以后落地，不就大概知道有多深了吗？”
他因此决定绳索够不够长，或者直接跳下去会不会死。
开发者甚至可能从来没有想到过这种玩法。
这没有关系。
真正重要的是世界诚实地回答了玩家的实验。
因此实现系统时也可以经常问：
我们是在输出一个世界事实，还是提前替玩家规定这个事实的用途？
例如：
物体高速撞击 → 产生 SoundEvent
通常比：
石头 → 可以用来测量洞穴
更有价值。
因为前者还可能被玩家拿来：
引怪、测试陷阱、确认下面有没有地面、触发声控机关……
九、让玩家能够“实验”
我们希望玩家逐渐形成这样的思考：
我觉得这个世界可能这样运作。
然后：
提出假设 → 尝试 → 得到反馈 → 理解规则 → 作出决策
例如：
“敌人似乎会追逐声音。”
玩家扔一个东西。
敌人真的过去了。
从此以后，玩家学会的不是：
“石头可以引怪。”
而是：
“敌人会调查声音。”
后者的意义大得多，因为玩家以后可能用枪声、爆炸、掉落物甚至队友制造声音。
玩家学习的是世界规律，而不是攻略答案。
十、不要刻意制造“涌现”
这一条可能反而最重要。
不要要求：
每个谜题必须有五种解法。
每个道具必须有八种用途。
每个房间必须让玩家产生一次“还能这样？”。
那样反而会变成另一种点对点设计，只不过开发者提前设计了更多的“点”。
我们真正负责的是：
规则一致。
反馈清楚。
后果有意义。
然后适时停手。
开发者认真设计一个好玩的正常解，控制好资源、区域、能力获得和风险。
如果玩家后来通过理解世界规则，发现了一个我们没有想到的合理办法——
让它发生。
这种体验珍贵恰恰是因为它不是被安排好的。
十一、自由不意味着放弃设计
OffMap 不应该成为：
“扔给玩家一个物理沙盒，你们自己找乐子吧。”
开发者仍然需要设计：
关卡、谜题、敌人、资源、能力顺序、风险、奖励、区域结构、Boss 和节奏。
我们追求的是：
宏观节奏由开发者掌握，微观方法允许玩家发挥。
必要的时候使用硬锁。
需要明确谜题的时候就设计明确谜题。
只有那些会被大量玩法重复利用的性质，才值得成为通用世界规则，例如：
Size、Mass、Temperature、Friction、Force、Sound、Damage、Destructibility、Carryability、Actor State……
不要为了“系统化”而把整个游戏做成物理模拟器。
十二、以后设计新机制时，可以问自己几个问题
- 这个能力是在改变世界状态，还是只在打开对应的锁？
- 这个对象是在识别“玩家用了什么”，还是在判断“世界现在是什么状态”？
- 如果删除 P2，这个场景仍然能完成吗，只是成本、风险或时间增加？
- 如果加入一个什么装备都没有的 P2，他的身体和行为本身有没有价值？
- 这个机制能不能和已有规则自然组合，而不是互相写特殊判断？
- 玩家能否通过观察和实验理解它，而不是必须看教程才能知道指定用途？
- 如果玩家找到我们没想到的合理办法，我们有没有不必要地阻止他？
- 这里真的需要通用系统，还是一个精心设计的专用谜题反而更好？
最后可以用一句话提醒我们自己：
设计世界，而不是设计所有答案。
能力改变条件，关卡控制节奏，系统提供事实，玩家产生办法。
单人保证完整，多人增加可能。
至于那些“原来还能这样”的瞬间——不要强求，让它自己发生。
我觉得这份笔记很适合以后直接放进 OffMap 的设计文档里，而且最好和 gameplay_foundation.md 分开：Foundation 管“代码应该怎么组织”，这份管“为什么要这样设计游戏”
