前言
我进入游戏行业的时候，正值《塞尔达传说：旷野之息》发售不久，让业界感受到了大世界游戏的魅力；而 Far Cry 5 和 Ghost Recon 又在 GDC 上分享了他们使用 PCG 技术来生成大世界的经验。我想正是在这个时候，游戏行业很热衷于做大世界游戏，并期望借用 PCG 技术来帮助完成大世界中海量内容的铺设。我刚进入游戏行业没什么技术背景，也就被分配来研究这个问题。
然而结果并不好：我加入的第一个项目，还没上线时我就感到很不妙，而我离开后项目虽然上线了，但很快就"下线"了。接着我去第二个项目，也是大世界游戏，拥有远非上一个项目可比的资金与技术。这个项目最后也上线了------先不谈商业成果，大世界场景的品质我认为是达标的，但是这并不归功于所谓的"PCG"技术（特别是 GDC 上分享的那些 PCG 技术）。
到了现在，PCG 这个话题的讨论度显然降低了很多。如果 PCG 是一个神，那么这个神的权柄已经被 AI 这个新神夺去了大半。当然，我也并非 PCG 的狂热信徒。在我看来，我们追求的应该是"工业化"，而"工业化"意味着"标准化"和"自动化"。PCG 只是服务于"自动化"的一种方式------如果 AI（准确来说是最近崛起的大语言模型和扩散模型）在某些自动化问题上做得更好，那没理由不用它。
但我一直在思考的是：为什么各路 PCG 分享那么多、且看似成功落地了不少，而在我待过的项目（以及很多我了解到的项目）中，PCG 技术都没有发挥那么强的作用呢？三年前我讨论过这件事，分享在《游戏项目中的程序化生成(PCG)：算法之外的问题与问题》。现在又过了三年，可惜的是这期间我在 PCG 上也没积累更多的实践经验，不过我偶尔还是会思考这个问题。我感觉之前分析的问题太零散，现在也许可以将这些问题系统化地串联起来。我目前的想法是：PCG 落地的真正难点不在算法本身，而在于从内容决策到自动化流水线，各个环节的负责人之间存在双向的信息依赖------也就是耦合，这就是下文要展开的内容。
0. 问题层级
我认为一项 PCG 内容要最终落地，会涉及五个层面的工作，分别由不同角色负责；而所有的问题也都可以归结为这五个层面的子问题，或是它们之间的交叉问题。
这五个层面从上到下依次是：
- A. 内容规划（核心决策领导负责）
- B. 引擎内数据形式（渲染向引擎程序）
- C. 程序化模型（PCG 向 TA）
- D. 人为调控（场景美术）
- E. 自动化流程（工具向程序/TA）
下面按顺序解释：
A. 内容规划
首先，玩家在游戏中会体验到什么样的内容，一定是由核心决策团队 决定的。
而在这些内容中的场景美术方面，我认为应该由主美 或首席TA来决定，其中哪些内容适合借助 PCG 的力量。
这些内容对于不同的游戏是完全不一样的。比如在之前翻译的《漫威蜘蛛侠 2》：Insomniac Games 程序化内容创作的十年历程中可以看到，蜘蛛侠项目中的 PCG 内容主要都是蜘蛛侠游戏所特有的：
- 曼哈顿的高楼大厦（这是蜘蛛侠故事发生的地方）
- 楼的远景 Impostors（蜘蛛侠经常需要站在高处远眺城市天际线）
- 屋顶间的跳跃轨迹（有一类敌人经常与蜘蛛侠在高楼间穿梭追逐）
- 雪景（《漫威蜘蛛侠：迈尔斯·莫拉莱斯》从秋季到冬季的季节转变）
- 蜘蛛网
理想情况下，这个层面最终要得出结论：我们游戏中有哪些内容是要用 PCG 生成的、或有 PCG 技术参与的。
B. 引擎内数据形式
当明确了哪些内容要用 PCG 生成后，接下来就要决定这些内容在引擎中的数据形式是什么。
比如，在《Far Cry 5 的程序化世界生成》中，崖壁是 mesh：
这样的做法可以让崖壁很好地贴合地形，但大量的崖壁会产生大量的 mesh 资源。对于 Far Cry 5 这样的主机游戏来说这不是问题，但对于移动平台或许就是个问题了，所以移动平台的游戏可能需要改用 instance 的方式来实现崖壁相关的效果。
因此，我认为"引擎内数据形式"这个层面的问题，主要由引擎程序基于性能方面的考量来决定。甚至，如果某种内容完全找不到合适的数据形式来实现，那就需要驳回这个内容需求。
理想情况下，这个层面最终要得出结论：那些由 PCG 参与的内容，最终落地到引擎中是什么样的数据形式。
C. 程序化模型
当确定了数据形式，核心的 PCG 开发者（一般是TA ）就可以来建立程序化模型 了。
此处所说的"模型"并非美术意义上的 3D 网格体。类似于"数学模型"是对一个问题的数学抽象，产出的是一系列用于求解的数学公式；而"程序化模型"表示的是一项内容在程序化步骤上的抽象，产出的是像 HDA（Houdini Digital Asset）这样针对某项内容的生成器。
例如在《GDC 2017 'Ghost Recon Wildlands': Terrain Technology and Tools - Settlement Builder》中的村落构建器，他们将村落的构建抽象为：基于地形上的某个中心点，由若干曲线、参数、建筑集合所控制的程序化生成器。
理想情况下，这个层面要开发一套算法（或者说"工具"、"生成器"）来生成内容，并明确出：
- 它的输入（比如基础地形、数值参数、空间中的曲线或 volume 等等）
- 它的输出（应当是引擎所能接受的数据形式）
D. 人为调控
虽然TA 已经提供了用 PCG 生成内容的方式，但可惜的是，内容的质量一般并不是由 TA 负责的------对于场景的美术内容而言，通常是由 场景美术师（LA） 来负责的。
也就是说，TA 负责制作 PCG 工具，而场景美术 负责使用 PCG 工具最终产出内容。
（截图来自《Twisting Terrain and Populating Forests on an Anomalized Olympic Peninsula for Pacific Drive》，其中关卡设计师分享如何用他们的工具来制作地图）
理想情况下，这个层面需要确定：要给上一阶段所构建的程序化模型填入什么样的输入。这可能是一些数值、一些空间中的曲线或 volume，或是其他需要从美术角度来决定的、对 PCG 行为的调控。
E. 自动化生成
场景美术在调控 PCG 行为的时候，肯定会预览生成的效果，也可以把最终调整好的生成结果保存下来。但是，并不能在任何时候都依赖场景美术去人工执行生成计算，尤其是当规模大 且依赖环节多 的时候。"规模大"意味着你改变了一个参数后，可能只在一个局部的范围验证了参数的合理性，但这个参数实际上需要推广到全世界重新生成；"依赖环节多"意味着你改了一个环节的输入，下游环节也需要重新生成来匹配。例如 Far Cry 5 的生成环节就有明确的依赖关系：
这时候，一般就需要一套自动化流水线，以固定的节奏（比如每晚执行一次）让构建机按照预期的顺序自动执行生成并上传结果。
这个层面的开发一般由工具向的程序员/TA 来负责。这个开发本身没有技术壁垒，毕竟说白了就是让一台机器自动执行一个程序而已。但落地过程中需要大量的跨部门沟通：需要了解流水线最终上传的数据结构是什么、PCG 各环节之间的依赖关系是什么、以及美术预期的执行节奏是什么。
1. 结构化问题：耦合
然而现实是，很难按照理想顺序依次推进 A→B→C→D→E 各层面的工作。一方面是因为，除了 PCG 方向的 TA 外，其他层面的负责人未必有PCG 方面的经验 。另一方面是因为，很多预先做的决定，在具体执行后可能并不如当初设想的那样。所以经常出现以下情况：
- 决策者视角：在决策什么内容需要用 PCG 技术的时候，决策者因为不了解 PCG，所以要去问负责 PCG 的人"PCG 能做什么"。
- PCG 技术开发者视角：但是，"PCG 能做什么"这个问题太发散了------毕竟不加限定的话，PCG 能做无数的内容。所以负责 PCG 技术的人需要先知道"限定条件"是什么，即我们游戏到底有哪些内容？但这个问题决策者可能也不确定（尤其是在做一个全新项目而非续作的时候）。其次，他还需要知道"哪些内容可以落地到引擎中"，也需要知道"场景美术希望怎样调控 PCG 行为"。
- 渲染向引擎程序视角：同样，"哪些内容可以落地到引擎中"这个问题也太发散了，所以他需要知道我们的性能预算是多少、以及内容具体的形式是什么------而这同样充满了不确定性。
- 场景美术视角：当被问到"希望怎样调控 PCG 行为"时，场景美术由于不了解 PCG，很难清楚地表述自己希望怎样调控。
- 自动化流水线开发者视角：尽管自动化流水线要在有基础的数据结构与流程之后才可以开发，但也经常在开发前就被上游层面的人问道"如果我们要生成 XX 数据，那么能否做个流水线让它自动生成"。这个问题同样很难回答，因为这取决于生成流程本身是否合理（比如各环节之间没有冲突）以及生成流程本身的速度是否符合预期。
可见，这些层面的负责人在做决定时，不仅需要知道上游层面的信息，还在一定程度上需要了解下游层面的信息。这种双向的依赖关系，我觉得可以称为 "耦合" 。这经常导致的一种情况是：一开始不太确定是否要用 PCG 技术的内容，被强行用 PCG 实现，并提供了美术不太预期的操作方式，实现后的效果也不符合预期。而当看到了实际情况后，各个层面的负责人都会加深对整个 PCG 流程的理解，于是各层面重新调整，最后重新实现一轮新的流程------这被称为一次 "迭代"。
迭代开发本身可以理解，毕竟再有经验也不太可能一开始就想好所有的东西。但问题是，不能一直迭代，流程总要收敛。更糟糕的是，如果迭代的过程中顶层设计还一直在变，那迭代就永远收敛不了。如果一直收敛不了，最后大家可能就会失去信心，认为无法迭代出一版正确的流程，从而在这个内容上彻底放弃使用 PCG 技术。
因此，我认为这种各层面工作相互依赖（不管是因为缺乏 PCG 经验，还是其他原因）所产生的耦合，是 PCG 系统难以落地的结构性问题。
2. 细节问题
除了上面说到的结构性问题，每个层面内部以及层面的交界处，还有不少细节问题。这些就比较零碎了，之前在《游戏项目中的程序化生成(PCG)：算法之外的问题与问题》中已经讨论过很多。所以这里我仅罗列部分问题，不做深入讨论：
- （ACD）手动/PCG 的划分与协调问题：有时候一个内容并非完全是手动或 PCG 的。可能是基于编辑层级 进行划分，比如高层手动（手动摆放 volume）、低层 PCG（在 volume 内生成植被）；或者相反，高层 PCG（自动生成植被）、低层手动（手调个别植被）。又或者是基于空间区域进行划分，比如划定某些区域只允许手动编辑而非 PCG 生成，或者相反。
- （A）编辑阶段问题：在初期阶段用 PCG 生成，在末期阶段关闭 PCG、改为全部手动编辑。
- （BC）引擎数据与程序化模型的载体（比如 Houdini）之间的交互接口 （Houdini 的顶点数据如何转换为 UE 的 StaticMesh），以及计算流程（将什么样的 StaticMesh 传给 Houdini，计算完之后传给引擎的数据放在哪）。
- （CD）用户用什么样的交互界面对 PCG 行为进行调控。
- （B）PCG 生成的数据怎样与手工编辑的数据互不干扰。
- （C）计算时间过长问题。
- （E）增量生成功能的开发。
- （D）场景美术分不清自己调控完 PCG 之后需要上传什么样的数据。
- （B）PCG 生成数据的性能问题。
- ......
（这部分有很多细节问题，一时想不起来太多，后续想到了再补充上去吧）
3. 当某层面问题简化/不存在时，落地难度大幅度下降
尽管 PCG 流程的落地充满困难，但并非所有 PCG 内容都无法落地。回顾实际项目的经历以及看过的资料，我发现成功落地的 PCG 内容，其实都在某些层面的问题上得到了简化，或者说这个层面的问题根本不需要考虑。下面按顺序举例：
- A. 不需要考虑"什么内容需要使用 PCG 技术"：意思是此问题已经完全确定。比如你要做的项目是一个续作 ，或者你有一个完美的竞品参考。这时候大家对于什么内容需要 PCG、什么内容不需要 PCG，是有清晰而统一的认识的，不需要领导层再去决策。
- B. 不需要考虑"PCG 生成的内容在引擎内的数据结构"：意思是你要生成的数据是非常常见的数据。比如说，你就要生成一些石头，那么毫无疑问它们就是 instance。但如果你要生成一些并不寻常的数据结构------比如你们项目开发了一套比较特别的体积云技术------那么此时这个问题就需要认真考虑了：你需要考虑你的 PCG 接口如何生成这套体积云技术所支持的数据结构。
- C. 不需要考虑"程序化模型的开发"：这种情况，要么是指此方面的技术已经完全确定，没有、也无需再去调整算法逻辑；要么是指程序化的算法非常简单直接。例如："在场景中根据地形情况摆放树木"的算法需要开发，但"为场景中符合某类标准的物体打上 tag"则几乎没有 PCG 层面上的开发工作。
- D. 不需要人为调控：意思是此内容的生成几乎不需要美术基于效果去决定什么参数、或在空间中摆放什么指引类几何体。例如：在场景中建筑的上表面生成积雪，几乎不需要美术向的参数。
- E. 不需要自动化流水线：意思是此内容的生成直接由人工控制，每次需要重新生成的时候手动触发并手动上传数据即可。当内容的规模比较小、计算比较快、且改动频率比较低的时候，这种情况很常见。
我实际感觉上，ABCDE 之中至少有一到两个层面无需考虑时，才能顺利落地这项 PCG 内容。其中"B. 引擎数据结构"的影响较小，就算这个问题不存在，也没有减少太多落地难度。而"D. 人为调控"和"E. 自动化流水线"的影响最大------至少需要简化其中一个。如果真的既要求美术在场景中精细调整参数并上传，又要自动化流水线每天重新生成数据，那将对 PCG 系统提出极高的要求，此时"A. 内容规划"层就必须尽早确定下来。
如果全部都需要考虑的话------即需要判断哪些内容适合用 PCG、且不清楚 PCG 生成的内容该用什么引擎数据结构、且需要新开发 PCG 算法、且需要人为精细调控、且需要自动化流水线周期生成------那么由于前文所说的耦合性，落地难度会非常大。此时或许就要考虑将多个层面的职责收束到同一个人身上：比如同一个人既是 PCG 技术的开发者，又是场景美术，对最终场景效果负责------这样也能减少耦合带来的问题。