Kar：验证生成关卡的实时可通行性——Fukai 的论文导读

TL;DR（一段话摘要）

今天介绍的，是一篇关于 PCG（Procedural Content Generation，即用算法而非人工生成游戏关卡与地形的技术）所生成关卡「能否走通」的实时验证论文。作者没有将生成与验证分作两道独立工序，而是将二者共置于同一游戏循环之中。

这套机制名为 Momentum，专为无尽跑酷类游戏设计。两个自主智能体（自律行进的检查员）在玩家稍前方跑动，提前排查前方路段是否堵塞或存在无法通行的障碍物摆放。发现问题后记录在案，也可按设置自动清除障碍。

先说结论：这篇论文展示的是「生成即验证」而非「生成后再验证」的设计理念，并以从代码推导出的结构性估算加以论证。这不是基于玩家实验的研究，而是从理论层面严密推演系统在设计上能够保证什么——明确这一点，才是正确的读法。

引言

作者 Rishabh Kar，供职于 King's College London（伦敦国王学院）信息学系。本文以 arXiv 预印本形式发表（arXiv:2605.01783v1，2026年5月3日，cs.AI），目前尚未经过同行评审（peer review，即专家预审）。换言之，这是一篇「刚刚提交、尚未经过广泛讨论」的文章，阅读时需牢记这一背景。

为何今天选了这篇？我每天早上有浏览 arXiv 新文章的习惯，但多数 PCG 论文都集中于「如何生成更多样、更有趣的关卡」。这篇论文偏了一步，正面回应了一个朴素却实际的问题：「怎样保证生成的关卡没有缺陷」。对于真正要交付游戏产品的人来说，这个问题往往更为紧迫。

另一个吸引我的点在于：这套系统是在 Unity（一款广泛使用的游戏引擎）上以可实际运行的游戏形式实现的，用的是 NavMesh（后文详述——即供经路探索使用的通行面）和射线检测等工程师在实际项目中随时可用的工具。

背景

PCG 最早出现在 Rogue 等早期游戏中，是在有限内存下构建广阔世界的工程手段。如今它已成为自动生成地形、关卡、植被、天气的技术基础，支撑起 Minecraft 和 No Man's Sky 等「每次都是不同世界」的体验。作者在回顾这段历史后，着重指出了 PCG 的弱点。

这一弱点在于：自动生成并不保证「看起来成立」与「实际可玩」同时成立。算法可能在堵死路口的位置放置障碍，或生成完全无法通过的区段。由于涉及随机数，复现问题需要精确还原当时的种子（随机数的初始值）和参数，调试难度极高。

因此，生成必须配套验证——这是论文的出发点。传统验证方式要么是关卡生成完成后的静态检查，要么是让自动智能体通关模拟。但在无尽跑酷类游戏中，关卡在玩家行进途中持续生成，根本没有「集中验证」的余裕。这就是本文提出实时验证的动机所在。

方法

以平实的语言梳理作者的方法。Momentum 是一个3D无尽跑酷游戏，地面由固定长度（论文中为96米）的地块依次拼接并向前滚动。障碍物的摆放借用了 Wave Function Collapse（WFC，一种通过约束相邻格子的候选项逐步确定每格内容的方法）的思路，而非完整实现——将横向行切分为格子，摆放障碍物的同时防止过度密集，并通过专用的余白参数始终保留可通行的车道。

关键的验证由两个智能体负责。第一个是在上方行进的「空中扫描器」，综合使用射线检测（向场景中发射不可见射线、报告第一个命中面的技术）、体积扫描（检测箱形3D区域是否与固体重叠）以及仅过滤障碍物层的蒙版，逐一排查即将到来的走廊在几何上是否畅通。第二个是在地面行进的「跑动智能体」，从 NavMesh（即引擎为经路探索提供的通行面）的角度，验证同一区段实际上是否可以通过。

两双眼睛各自关注不同属性，这一点至关重要。空中智能体检查「空间上是否畅通」，地面智能体检查「作为路径实际上是否可走」。一旦检测到堵塞，系统将记录障碍物详情、玩家状态、生成参数及肇因物体，整理成可供后续分析的报告（支持 PDF 输出）。如果开启相应设置，空中扫描器可在玩家到达前将障碍物清除。

NavMesh 持续以异步方式对玩家前方600米、后方50米的范围重新烘焙，以保持与不断滚动的世界同步。为应对地面可能出现的短暂缝隙，每次游戏允许最多9次复活（重生）。这些细节，论文均逐一对应代码进行了说明。

发现

首先需要明确这篇论文的「结果」究竟指什么。作者并未进行大规模玩家实验，而是从代码本身和第一原理（从基本前提出发进行理论推演）出发对系统行为进行估算。评估依据 Cook 等人的分类框架，从四个维度整理：可玩性（playability）、多样性（diversity）、可控性（controllability）、性能（performance）。

关于可控性，作者有一处值得关注的发现：即便将控制障碍物密度的滑块调到最大，实际生成的数量也会远早于期望值便遭遇瓶颈。原因在于，保持通行车道和「填充相邻格子」的约束条件会提前生效。作者将此描述为「参数之外的结构性上限」。换言之，密度旋钮在设计上存在一个无法逾越的天花板。

关于性能，作者估算：随着跑动距离增加，智能体检查一个区段的开销维持在一个小的常数范围内，不会随之增长。这是因为检查以整数地块编号为单位划分，且开销较大的体积扫描被均摊到了大量射线检测之中。作者以 Unity 的帧预算为参照进行讨论——60帧时每帧16.66毫秒，30帧时33.33毫秒。

关于验证覆盖率，作者指出：空中智能体与地面智能体各自捕获不同类型的缺陷，因此合并两者的报告，覆盖率必然高于任意单一来源。堵塞程度则通过「检查区段中发现堵塞的占比」量化。此处尤其需要强调：「有评估是否比没有评估减少了更多堵塞」这一首要问题（RQ1），在论文中是作为假设提出的，而非已测量的实验结果。

应用场景

具体说明游戏开发者如何借鉴这篇论文。第一，如果你正在为无尽跑酷或超休闲游戏开发 PCG，可以直接参考这套设计——放弃「生成后再单独验证」的思路，改为在生成环节紧接着插入通行性检查，并以「玩家到达前清除堵塞」的方式设置安全网。

第二，如果你在制作 Sokoban-like（仓库番式推箱解谜类型）或类 Rogue 游戏（反复探索自动生成地牢的类型），可以将「提前用智能体验证可达性」的思路移植过来——把射线检测替换为探索求解器（通过实际搜索来判断是否有解的机制）。本论文的核心价值与其说是具体手法，不如说是「将生成与验证置于同一循环」的设计范式，这一范式的适用性超越特定类型。

第三，崩溃报告的设计具有实际参考价值。在发生堵塞时，将种子、参数、肇因物体、玩家状态一并记录的机制，能直接改善那些因随机数而难以复现的 PCG 缺陷报告。

第四，「控制旋钮存在结构性天花板」的发现对调整工作有启示意义。如果遇到密度参数调再高也没效果的情况，这或许不是 bug，而是约束之间相互制衡的结果。

局限

将局限分为两部分：作者自己承认的范围，以及我在阅读中注意到的问题。首先，理解论文框架最关键的一点是：本文的数值并非来自人类实验，而是从代码和理论（第一原理）推导得出的结构性估算（这不是我的转述，作者本人在摘要中明确写明了「从第一原理出发」）。因此，「实际游戏中堵塞减少了百分之几」的测量值，在这篇论文中并不存在。

Fukai 在此指出的是适用范围的局限性。研究对象是高度变化均一、车道布局固定的无尽跑酷游戏。若要处理地形起伏，或像谜题那样更复杂的逻辑可解性问题，仅凭射线检测和 NavMesh 是不够的。作者也坦承，WFC 在本文中并非完整的约束求解方法，而只是借用了其布局思路。

另一点我在阅读中注意到的是：本文所谓的「评估」侧重于可达性（是否不堵塞），并未触及「体验质量」——如趣味性或难度是否恰当。生成物「没有缺陷」与「足够好」是两个不同的问题，本文解决的是前者。此外，这仍是一篇尚未经过同行评审、引用量为零的预印本，这一事实同样值得放在心上。

Fukai 的读解

以下是我的读解。我想将这项研究置于 PCG 领域关注点从「能否生成更丰富的内容」向「如何信任所生成的内容」转移的脉络之中。以设计批评的语汇来说，这可以理解为：将游玩测试的一部分，折叠进与生成同步运行的时间轴。将验证从后道关卡转变为生成循环中的常驻组件——这一姿态，比手法细节本身更为重要。当然，这在现实中是否真正有效，终究需要引入人类实验来加以验证。

结语

最后给出一张地图。想更系统地了解 PCG 评估的读者，可以参阅本文所依据的 Cook、Withington 与 Tokarchuk 的「程序化关卡生成系统评估」——其中关于四个维度（可玩、多样、可控、性能）的概述颇具参考价值。想了解 WFC 来龙去脉的读者，Karth 与 Smith 的「WFC 是现实世界的约束求解」是合适的起点。

「将生成与验证置于同一循环」的思路并不局限于无尽跑酷游戏。将其与自己正在制作的项目对照，问一问「生成的那一刻，能说它不会出错吗」——这样，这篇论文的适用范围就会显现出来。我今天早上也是带着这个问题，喝完了一杯浓泡的手冲咖啡。

参考文献

本文参考的论文与相关资料：

・Runtime Evaluation of Procedural Content Generation in an Endless Runner Game Using Autonomous Agents（Rishabh Kar，2026，arXiv preprint arXiv:2605.01783）

・相关研究（本文评估四维框架的参考来源）：On the Evaluation of Procedural Level Generation Systems — Cook, Withington & Tokarchuk（见本文参考文献）

・相关研究（理解 WFC 来龙去脉的起点）：WaveFunctionCollapse is Constraint Solving in the Wild — Karth & Smith, 2017（见本文参考文献）