字符级马尔可夫链与受限代码量下的程序化命名实践

在 Roguelike 游戏的设计哲学中，每次运行都应该是独特的 —— 不仅体现在程序生成的地牢布局、怪物属性和物品分布上，还应该渗透到游戏的叙事元素中。Xs of Y 项目展示了一种极端的做法：游戏本身在每次启动时都会为自己生成一个独特的标题，例如「Gazebos of Mounting Dread」或「Labyrinths of Garbage Collection」，同时生成一个荒诞但符合程序员幽默美学的任务目标，如「retrieve the Spatula of Futility」。这种程序化命名（Procedural Naming）技术不仅增加了游戏的可重玩性，更是一种将极简代码约束与丰富内容生成相结合的工程实践。

程序化命名的技术路径

程序化命名并非 Roguelike 领域的独创技术，它在游戏开发、密码学、诗歌生成乃至大型语言模型的提示工程中都有广泛应用。从技术实现的角度看，程序化命名系统通常遵循两条主要路径：基于词表的随机组合与基于马尔可夫链的概率生成。前者实现简单、可控性强，后者则能产生更具变化性和「自然感」的输出。Xs of Y 项目采用了前一种方案，通过预定义的词表实现标题生成 —— 一个由约 40 个名词组成的「X 列表」（如 Catacombs、Crypts、Depths、Vaults 等）与另一个约 90 个名词组成的「Y 列表」（如 Recursion、Nil、Stack Overflow、Technical Debt 等），每次游戏启动时随机选取并拼接。这种设计的优势在于生成结果完全可预测且风格统一，缺点是输出受限于词表的规模与覆盖范围。

字符级马尔可夫链（Character-Level Markov Chain）代表了一种更为通用的程序化命名方法。其核心思想是根据已有文本库中字符序列的出现频率建立转移概率模型，然后依据该模型逐字符生成新名称。以一个阶数为 2 的马尔可夫链为例，它会分析输入文本中所有长度为 2 的字符序列（如「ab」「bc」「ca」）的出现频率，并据此预测下一个字符最可能是什么。当训练语料足够丰富时，生成的名称既能保持一定的「可信度」，又能展现出超越简单词表组合的变化性。许多经典的 Roguelike 游戏 —— 如 NetHack 和 Angband—— 就使用了类似的技术来生成怪物名称、物品前缀和地牢标题。

Xs of Y 的命名架构解析

深入审视 Xs of Y 的源代码可以发现，其程序化命名系统被封装在 xsofy/title.lg 模块中，主要包含三个命名生成函数：generate-title 负责生成游戏主标题，generate-quest 负责生成任务物品名称，generate-quest 还附带随机选择入口描述信息。这些函数都遵循统一的架构模式：首先定义静态词表（作为 Clojure 的向量字面量），然后通过 rand-int 函数从词表中随机选取元素进行组合。值得注意的是，词表的设计本身反映了开发者的幽默感和审美取向 ——X 列表侧重于地牢相关的建筑学术语（如 Crypts、Sepulchres、Oubliettes），而 Y 列表则充满了程序员梗（如 Recursion、Stack Overflow、Technical Debt、Dependency Hell）。

从代码工程的角度看，这种设计的优雅之处在于其极致的简洁性。generate-title 函数本身只有两行代码，通过 str、nth 和 rand-int 三个操作的组合完成了全部逻辑。词表的维护也极为方便，开发者可以在不触及任何算法逻辑的情况下自由扩展命名空间。项目的 README 提到整个游戏主体仅用约 6900 行 let-go 代码实现，这意味着平均每个命名规则的实现成本极低 —— 如果使用字符级马尔可夫链，开发者需要额外编写状态机管理、概率累积计算和结束条件判断等逻辑，代码复杂度会显著上升。

极简约束下的工程权衡

将字符级马尔可夫链的实现与受限代码量目标结合时，会产生一系列需要权衡的设计决策。首先是模型阶数的选择：阶数越高，生成的名称越接近训练语料的风格，但计算开销也越大，且可能出现严重的「过拟合」—— 生成的名称几乎就是训练文本的直接复制。对于一个 4k 行代码量级的项目，建议将马尔可夫链的阶数控制在 2 到 3 之间，这样既能保持生成结果的新颖性，又不会引入过高的计算复杂度。

其次是训练语料的管理策略。在资源受限的环境中，可以采用「紧凑语料」方案：从公开领域的小说、诗歌或主题相关的文本中提取目标词汇（如科幻 / 奇幻名词、技术术语等），而非加载完整的原始语料。语料的预处理也值得优化 —— 例如将所有输入转为小写并过滤掉非字母字符，可以显著降低状态空间的大小。Xs of Y 项目选择词表而非马尔可夫链，本质上也是一种语料管理的简化：开发者完全掌控输出质量，无需担心训练数据中的噪声导致的生成偏差。

第三是边界情况的处理。字符级马尔可夫链在遇到罕见字符组合或未知上下文时可能陷入「冷启动」问题。常见的解决方案包括引入回退机制（当高阶状态不存在时回退到低阶状态）、设置最大生成长度限制、以及在词表末尾添加显式的结束标记。实现这些机制需要额外的代码行数，但在 4k 行总量约束下，建议采用「确定性回退」策略：始终在当前状态不可达时回退到阶数为 1 的状态，而非尝试更复杂的概率回退。

可落地的参数配置清单

基于上述分析，以下是在 4k 行代码量约束内实现字符级马尔可夫链程序化命名系统的推荐参数与监控要点。

模型配置参数：马尔可夫链阶数建议设为 2，这是代码量与生成质量之间的最优平衡点；最大生成长度设为 12 到 15 个字符，适用于大多数游戏中的物品名和地点名；最小生成长度设为 3 个字符，避免生成无意义的短字符串；词尾判定可采用字符频率阈值法 —— 当当前上下文的下一个字符中结束标记（如空格或换行）的累积概率超过 0.3 时触发终止。

语料预处理参数：输入文本统一转为小写并过滤掉非字母字符（保留空格用于分词）；移除长度小于 3 的单词以减少噪声；去重后保留的独特词汇数控制在 500 到 1000 之间；语料编码统一使用 UTF-8。

生成质量监控指标：建议追踪生成名称与训练语料的最低编辑距离，确保输出不是直接复制；监控平均生成长度与目标长度的偏差；定期抽检生成结果的语义可读性；在游戏测试阶段收集玩家对「最有趣 / 最怪异名称」的评价，作为质量反馈。

代码组织建议：将马尔可夫链的状态转移逻辑封装为独立函数，控制在 30 行以内；词表 / 语料作为只读数据在初始化阶段加载；为每个命名上下文（如怪物名、地点名、物品前缀）维护独立的状态机实例，避免状态混淆。

结语

程序化命名是 Roguelike 游戏中「无限内容感」的重要来源之一。Xs of Y 项目通过词表随机组合的方式，以极低的代码成本实现了每次运行都独一无二的标题与任务命名，展示了受限代码量下工程决策的智慧。对于追求更高生成变化性和「自然语言感」的开发者而言，字符级马尔可夫链是值得探索的方向，但需要在模型复杂度、代码行数和输出质量之间做出审慎的权衡。最终，无论选择何种技术路径，程序化命名的成功与否都取决于开发者对目标风格的理解和对细节的把控 —— 毕竟，一个好的名称不仅要让玩家记住，更要成为游戏体验的有机组成部分。

资料来源：GitHub - nooga/xsofy（https://github.com/nooga/xsofy）

systems