这节课的核心问题不是：
玩家能跳多远？
而是：
玩家能不能根据空间外观，准确预测自己接下来能做什么？
这个差别非常重要。
一、先建立一个新概念：Affordance
你以后会经常见到这个词。
可以简单理解为：
一个物体或空间，看起来“允许”你做什么。
比如：
- 一个平台看起来像能跳上去；
- 一堵矮墙看起来像能翻；
- 一个窗口看起来像能射击；
- 一个窄洞看起来像能钻；
- 一块突出边缘看起来像能抓住。
如果它看起来能做，但实际上不能：
玩家会觉得游戏在骗人。
如果它看起来完全不能做，但玩家莫名其妙能做到：
世界尺度也会变得不可信。
所以 Metrics 的一个真正目标是：
让视觉语言和玩法能力逐渐一致。
二、跳跃不是一个数字，而是三个区间
假设玩家最大奔跑跳跃距离最终测出来是 3.4m。
千万不要以后所有坑都做：
3.3m。
😂
应该建立三个区域。
例如纯示意：
0m ──────────────── 2.0m
安全区
2.0m ────────────── 2.8m
注意区
2.8m ────────────── 3.4m
极限区它们分别承担不同关卡功能。
安全跳
玩家几乎不用思考：
跑过去，跳。
用途：
- 保持移动节奏；
- 轻量平台移动；
- 不希望玩家真的失败的场景。
注意跳
玩家站到边缘：
嗯……应该可以。
用途：
- 制造一点风险；
- 让玩家认真操作；
- 探索路线。
极限跳
玩家：
这真的能过去？
用途：
- 隐藏路线；
- 技巧奖励；
- Sequence Break；
- 高风险捷径。
极限跳不能成为普通导航语言。
否则玩家每次移动都像考试。
三、真正要测试的是“起跳状态”
以后 OffMap 至少要区分：
原地跳
行走跳
奔跑跳
奔跑 + 极限边缘起跳甚至如果以后滑铲、坡度、动量都稳定了：
高速状态跳跃
斜坡辅助跳跃可能又是另一组 Metrics。
但现在不要急着把它们正式化。
先记录当前玩家。
四、跳跃测试场怎么搭
继续放在：
levels/
level_design_gym/
metrics_zoo.tscn增加一个：
Jump_Test里面做平行坑。
比如：
Gap_100
Gap_150
Gap_200
Gap_250
Gap_300
Gap_350
Gap_400单位按 Godot 默认：
1 unit ≈ 1 meter
如果你们项目本身也是这个尺度。
然后每个坑都测试三次左右，不要只成功一次就下结论。
五、记录“可靠距离”而不是世界纪录
假设：
3.4m 偶尔能跳过去。
但：
3.0m 基本每次都可以。
那么对于普通关卡：
3.0m 比 3.4m 更重要。
所以 Metrics 表里最好出现：
| 项目 | 距离 |
|---|---|
| 舒适奔跑跳 | ? |
| 需要认真操作 | ? |
| 当前可靠极限 | ? |
| 理论极限 | ? |
“理论极限”通常只对：
高技巧路线
有意义。
六、高度也要建立语言
第一课我们已经测平台高度。
现在进一步分类。
例如最后可能得到：
0 ~ 0.3m
几乎被理解为地面起伏
0.3 ~ 0.8m
明显台阶
0.8 ~ 1.4m
需要跳跃
1.4 ~ X
困难但可达
>X
普通跳跃不可达具体数字我们不预设。
你们自己测。
然后这里就会出现非常重要的：
可达性语言
以后玩家看到：
1.2m 平台多次经验告诉他：
我能上去。
看到：
2.5m 光滑墙面经验告诉他：
普通跳跃不行。
于是他不需要：
到每堵墙前疯狂按空格。
这就是良好的空间语言。
七、一个新手非常容易犯的错误：到处放“差一点能上去”的高度
这种最烦。
比如角色稳定只能跳上 1.4m。
结果地图到处都是：
1.5m～1.6m。
玩家每次都会觉得：
“是不是我操作不好？”
然后：
跳
跳
跳
跳最后发现：
根本上不去。
这其实是一种非常糟糕的信息噪音。
所以不能只考虑：
“不可达。”
还要考虑：
看起来是否明确不可达。
八、坠落 Metrics：危险必须可以被阅读
我们之前聊的黑洞例子，是一种故意让高度未知的特殊场景。
但大多数普通高台：
高度应该具有一定可预测性。
所以建立：
Fall_Test例如：
Fall_100
Fall_200
Fall_300
Fall_400
Fall_500
Fall_600
Fall_800
Fall_1000测试：
- 完全安全；
- 有落地反馈但不伤血；
- 轻伤；
- 重伤；
- 接近致命；
- 必死。
九、但更重要的是记录心理阈值
你站在：
3m 高处。
你的第一感觉是什么？
完全敢跳
有一点犹豫
感觉危险
感觉肯定会死然后和真实规则对比。
比如：
| 高度 | 玩家直觉 | 实际 |
|---|---|---|
| 2m | 安全 | 安全 |
| 4m | 有点危险 | 安全 |
| 6m | 很危险 | 轻伤 |
| 10m | 感觉必死 | 致命 |
如果大体一致：
世界容易理解。
如果：
| 高度 | 看起来 | 实际 |
|---|---|---|
| 3m | 小落差 | 当场暴毙 |
那玩家会很难建立空间直觉。
十、这里就连接到“风险设计”
假设未来一个捷径：
正常路线
→ 5 分钟
跳下去
→ 30 秒
→ 损失 40% HP这就是一个很简单的：
Health for Time
交易。
玩家可以自行判断：
我现在血够不够？
这就是很好的软锁/资源决策。
而不是：
“这里是捷径按钮。”
十一、第三人称游戏真正麻烦的地方：玩家视点 ≠ 玩家身体
现在进入这一课非常重要的部分。
第三人称：
Camera
●
/
/
Player ●
玩家实际上在通过 Camera 理解世界。
但是：
- 碰撞体在 Player；
- 枪口在武器；
- Camera 在身后/侧后方。
所以同一个空间同时要满足：
身体能过
镜头能看
武器能射
这就是为什么第三人称空间设计比你想象中复杂很多。
十二、窗口是一个极好的测试对象
想象：
Camera
●
\
\
Player ● —— Gun →
██████ ██████
WINDOW
██████ ██████Camera 可以看见目标：
准星在敌人身上。
但是枪口可能：
啪。
打在窗框。
这正是我们之前已经实际遇到过的问题。
而现在不要把它只理解为：
Shooting bug。
它其实也是：
Level Metrics + Camera Framing 问题。
十三、所以要建 Window Zoo
在 metrics_zoo.tscn 里增加：
Window_Test至少研究三个变量：
窗台高度
例如：
0.6m
0.8m
1.0m
1.2m
1.4m窗口宽度
0.5m
0.8m
1.2m
1.8m墙厚
0.2m
0.4m
0.8m
1.2m第三个非常容易被忽略。
十四、为什么墙厚也重要？
看俯视：
薄墙：
──── ────
↑
窗口厚墙：
████ ████
████ ████
████ ████窗口其实变成一条小隧道。
玩家站偏一点：
Camera
●
\
\ 看得见
\
Gun ● ──X████于是：
Camera 看得到。
枪口路径却被内侧窗框挡住。
所以以后真正的第三人称战斗窗口，不只是：
洞多大？
还要考虑：
墙多厚？
十五、Window Test 要怎么测
拿现有手枪。
站：
A. 正中央
射。
B. 靠窗口左边
射。
C. 靠窗口右边
射。
D. 离窗口很近
射。
E. 后退两三米
射。
F. 横向移动过程中
连续观察。
记录三种状态：
视觉明确可射击
↓
视觉有点模糊
↓
视觉上像能射，但实际枪口被挡最后一种尤其重要。
因为它就是：
误导性 Affordance。
十六、这会成为以后 Line-of-Fire Feedback 的测试标准
我们之前已经决定以后可能做：
Line-of-Fire Feedback。
这张 Metrics Zoo 以后就是非常好的回归测试场。
例如：
Window_Thin_Wide
Window_Thick_Wide
Window_Thin_Narrow
Window_Thick_Narrow等 Line-of-Fire UI 做好以后：
每个窗口跑一遍。
看看提示是不是和实际弹道一致。
所以这个 Gym 不只是学习作业。
以后真的会变成：
开发工具。
十七、接下来是掩体高度
建立：
Cover_Test例如：
Cover_060
Cover_080
Cover_100
Cover_120
Cover_140
Cover_160测试：
- 玩家身体暴露多少；
- Camera 是否还能看见前方；
- 枪口是否被挡；
- 敌人是否能打到；
- 玩家是否自然理解它是掩体。
十八、掩体也存在“视觉承诺”
如果：
玩家整个胸口都露在外面但敌人怎么都打不到：
很怪。
如果：
玩家看起来完全蹲在石墙后面但 Hitbox 还露了一大片：
更怪。
所以掩体需要让：
Visual
Collision
Combat Hitbox
Camera
Ballistics大体讲同一种语言。
十九、第三人称 Camera 会制造“假安全感”
比如：
Camera ●
█████████████
Player ●
Camera 已经越过墙角看到敌人。
但玩家身体还完全藏着。
这不是一定有问题。
第三人称游戏天生就允许：
Peeking。
但你需要知道它存在。
否则设计 stealth / enemy vision 时，很容易突然发现：
玩家可以躲在墙后用上帝视角观察整个房间。
这可能是：
- 你接受的游戏特性；
- 需要限制的特性；
- 需要设计空间去适应的特性。
但首先要：
测出来。
二十、做一个 Corner Test
这个非常推荐。
████████
█
Player █
● █
█
█ Enemy ●让玩家躲墙角。
测试：
玩家身体完全不露的时候，Camera 能看到多大范围？
然后：
玩家移动多少以后，枪口才真正获得射线？
这里你会第一次非常直观地看到：
Camera Visibility
≠
Line of Fire
≠
Body Exposure三个完全不同的空间概念。
这对以后做战斗关卡特别重要。
二十一、于是战斗空间至少有三张“隐形地图”
这是很重要的理论。
玩家走进一个房间，其实存在：
Movement Map
我能走到哪里？
Visibility Map
我能从哪里看到哪里？
Ballistics Map
我能从哪里真正射到哪里？
这三张图经常重合。
但不总是。
例如窗口：
Movement:
不能穿墙
Visibility:
可以穿窗口看
Ballistics:
取决于枪口和窗框好的战斗空间，本质上就在玩这三个关系。
二十二、再加敌人以后还有第四张
Threat Map
站在哪里会被敌人威胁？
例如：
Sniper
●
|
|
██████ | █████
安全 | 安全
|
危险
然后玩家才会利用：
- 掩体；
- flank；
- 高低差；
- 时间；
- 敌人注意力。
Encounter Design 就开始出现了。
但我们现在还不正式进入。
下一单元才会重点讲。
二十三、多人 Metrics 现在只需要提前留一个问题
以后两个人：
P1 ● ● P2很多当前舒服的空间：
可能立刻不舒服。
比如：
- 一个人舒服的门；
- 一个人舒服的楼梯；
- 一个人舒服的掩体；
- 一个人舒服的战斗房。
所以现在在 Metrics 表里先留：
Solo Comfortable
Co-op Comfortable两列。
哪怕目前多人系统还没真正做完，也提前知道：
“舒适”不是绝对值。
二十四、这一课最终要开始建立第一份正式 Metrics Sheet
不要现在填数字，我先给你结构。
OffMap Level Design Metrics v0.1
Player Movement
| Metric | Safe | Standard | Risky | Limit |
|---|---|---|---|---|
| Horizontal jump | ||||
| Vertical reach | ||||
| Fall height |
Navigation
| Metric | Tight | Normal | Comfortable | Large |
|---|---|---|---|---|
| Door width | ||||
| Corridor width | ||||
| Room size |
Combat
| Metric | Low | Standard | High |
|---|---|---|---|
| Cover height | |||
| Window sill | |||
| Window width | |||
| Wall thickness |
Camera
记录：
最低可接受走廊；
角落窥视程度；
窗口近距离问题；
SpringArm 明显收缩的位置。
这部分甚至不一定全是数字。
可以写观察。
二十五、不要把 Metrics Sheet 当圣经
假设最后：
Normal corridor = 3m。
这绝对不意味着：
全游戏走廊必须 3m。
真正用途是：
我现在要普通空间
→ 3m 附近作为起点
我想压迫
→ 故意低于标准
我想打大规模战斗
→ 故意高于标准所以 Metrics Sheet 是：
参照系。
有了标准，你才知道自己什么时候是在有意识地偏离标准。
第二课作业
这次增加四块：
D. Jump Test
E. Fall Test
F. Window Test
G. Cover + Corner Test仍然放在：
levels/
level_design_gym/
metrics_zoo.tscn仍然：
不需要新 GDScript。
你真正需要记录的不是全部数字，而是这些问题
Jump
什么距离可以无脑跳？
什么距离需要认真操作？
什么距离属于极限？
Fall
玩家什么时候开始犹豫？
实际伤害什么时候开始？
视觉直觉和伤害规则是否一致？
Window
Camera 认为可以射击，枪口实际上不行的范围有多严重？
墙厚对此影响多大？
Cover
哪个高度玩家自然理解为掩体？
Visual / Hitbox / Ballistics 是否一致？
Corner
玩家完全不暴露身体时，能通过 Camera 获得多少信息？
这个以后对敌人 AI 和遭遇设计会特别重要。
第二课的真正毕业标准
不是：
“我测出了跳跃最大 3.27m。”
而是你看到一个灰盒空间以后开始能说：
“这个坑是普通移动，不应该失败。”
“这个坑明显是在要求技巧。”
“这个窗口看起来能射，但当前枪口大概率会碰墙。”
“这个墙角允许玩家安全观察，所以敌人放这里会产生这种行为。”
也就是说，你开始从：
看几何形状
变成：
看玩家行为。
这就是 Metrics 真正开始转化成 Level Design 的时刻。
