Steam 游戏关卡生产实战：2021 年 4 月个人项目从灰盒到可发布场景的流程

关卡生产要有阶段

个人开发者做关卡时，最常见的问题是边摆美术边改玩法，最后场景看起来有内容，但无法解释它到底验证了什么机制。等到 Steam Demo 或正式版准备发布时，才发现新手关太难、后期关卡没有存档点、截图漂亮但玩家找不到路、性能在某个场景突然掉下去。

关卡生产需要阶段。每个阶段只解决一类问题：灰盒验证路径和机制，白盒补完整流程，替换美术资源，加入音频和反馈，做性能与 QA，最后冻结。个人项目人少，更要让关卡状态清楚，否则很容易把半成品当成可发布内容。

先写关卡卡片

每个关卡开始前，先写一张卡片：

这张卡片能帮助你判断关卡是否必要。如果一个关卡没有新机制、没有节奏变化、也没有叙事或视觉任务，它可能只是填充内容。Steam 玩家不关心你做了多少房间，他们关心每段体验是否有理由存在。

灰盒阶段只测路径

灰盒阶段不要急着上纹理和光照。用简单形状搭出墙、平台、门、敌人、触发器和目标点，先验证：

• 玩家是否知道下一步去哪。
• 核心机制是否被自然使用。
• 失败后是否能快速重试。
• 摄像机是否看得到关键物。
• 关卡时长是否接近预期。

灰盒测试时可以找不熟悉项目的人，只告诉他基本操作，不解释解法。观察他在哪里停顿、哪里误解、哪里觉得无聊。不要在旁边提醒，因为 Steam 玩家下载 Demo 时也不会有开发者坐在旁边。

节奏要有起伏

一个关卡不能一直高压，也不能一直教学。可以用节奏表规划：

这样的节奏对小关卡也适用。比如 10 分钟解谜关，前 1 分钟让玩家观察，2 分钟学习新机关，4 分钟做组合谜题，2 分钟做压力变化，最后 1 分钟给出口和奖励。如果全程都是同一种谜题，玩家会疲劳；如果一上来就高压，玩家会觉得不公平。

检查点和失败恢复

关卡越长，检查点越重要。检查点不是随便放在地图中间，而要放在稳定状态：玩家已经完成一组挑战，世界状态容易恢复，读档后不会站在危险物体或事件中间。

检查点记录要包括：

如果关卡里有复杂物理对象，读档后要特别测试。物体堆叠、移动平台、触发器边缘状态都容易出 bug。不要只测从头玩到尾，还要测每个检查点读档。

美术替换要保护可读性

美术资源上来后，关卡可能变漂亮，也可能变难读。灰盒里清楚的门，在复杂贴图和光影中可能不明显；敌人路径可能被装饰物遮挡；可交互物和背景颜色太接近，玩家看不出来。

替换美术后要检查：

• 目标点是否仍然显眼。
• 可互动对象是否有统一视觉语言。
• 危险物是否比装饰物更突出。
• 前景遮挡是否影响操作。
• 截图好看的角度是否也是玩家实际视角。

个人开发者容易为了截图效果牺牲游玩可读性。Steam 商店截图可以漂亮，但游戏内必须先能玩明白。

关卡资源预算

每个关卡都要有资源预算，尤其是大场景。预算可以很简单：

预算不是为了限制创作，而是为了避免某个场景成为性能黑洞。每次新增大型装饰、敌人群或动态效果，都要回到性能测试场景看一次。

发布验收表

关卡进入候选版本前，做一张验收表：

只要一项不通过，就不要把它当成完成关卡。个人项目最大的问题不是没做内容，而是过早相信内容已经完成。

关卡删减也要有依据

发布前如果发现时间不够，删关卡比硬上未完成关卡更稳。删减时看三件事：它是否承载核心机制，删掉后节奏是否断裂，商店页是否已经承诺。不是所有做过的关卡都必须上线。

删掉一个关卡后，要检查存档、章节编号、成就、地图、剧情文本、商店截图和宣传视频。关卡不是孤立文件，它连接了很多系统。删减也要走流程。

最终检查清单

• 每个关卡有卡片，说明机制、目标和风险。
• 灰盒先验证路径和机制，不提前沉迷美术。
• 节奏包含引入、组合、压力和释放。
• 检查点放在稳定状态，并完成读档测试。
• 美术替换后重新检查可读性。
• 资源预算和性能测试相连。
• 候选版本前有验收表。
• 删减关卡同步检查相关系统。

关卡生产的本质是把创意变成可交付内容。对 Steam 个人游戏来说，少量完成度高、目标清楚、能稳定运行的关卡，比大量半成品更能支撑商店页和玩家口碑。

关卡命名和文件组织

关卡文件也需要规则。不要让文件名停留在 test_new_final_2。建议包含章节、顺序和用途：

ch01_010_tutorial_movement
ch01_020_first_puzzle
ch02_030_factory_gate
ch02_040_boss_entrance

文件名和关卡 ID 要尽量一致。存档、日志、任务和构建记录都引用同一套 ID，后期排查才不会混乱。关卡重命名时，要检查存档迁移和商店截图说明。

关卡内可交互物的规范

门、机关、宝箱、NPC、触发器都要有统一规范。比如所有可交互物都有高亮、交互提示、音效、失败反馈和日志事件。不要让某些门能按键，某些门只能靠近自动开，某些门没有任何提示。

统一交互规范能降低玩家学习成本，也能减少测试遗漏。QA 可以按规则检查：是否显示提示、是否支持手柄、是否能重复触发、读档后状态是否正确、不可用时是否说明原因。

灰盒反馈要保留

灰盒测试发现的问题不要在美术替换后丢掉。建议把每次灰盒观察写进关卡卡片：玩家在哪里停顿，哪里误以为可跳，哪里不知道目标，哪里觉得重复。美术阶段再回头检查这些点是否被解决。

很多关卡返工是因为早期反馈没有记录，开发者凭印象觉得“应该修过了”。记录让关卡迭代更可靠。

关卡和叙事的接口

即使不是剧情游戏，关卡也常常承担叙事或世界观信息。NPC 对话、环境文字、过场触发、收集品说明都可能依赖关卡状态。关卡生产时要列出叙事接口：进入时播放什么，完成机关后哪个 NPC 改台词，Boss 死亡后哪些门打开。

这些接口要和任务系统、存档系统同步。否则玩家读档后可能看到旧对话，或者跳过某段触发导致剧情不连贯。个人项目里，叙事和关卡经常由同一个人处理，更容易凭记忆工作，反而需要表格约束。

关卡完成后的截图检查

每个完成关卡都可以留一组内部截图：入口、关键机制、最高压力点、奖励或出口。截图不是为了宣传，而是为了版本对比。后续改光照、换 UI、优化性能时，可以对照这些截图看关卡是否失去可读性。

如果某张截图也用于 Steam 商店页，就在关卡卡片中标记。这样删减或重做关卡时，你会知道哪些宣传素材需要同步替换。

小团队的关卡命名习惯

不要让“临时关卡”长期存在。临时测试场可以统一放到 test_ 前缀，并明确不进入发行包。正式关卡使用 chXX_ 或类型前缀。构建脚本可以排除测试场，避免玩家下载到未完成内容。