前言我进入游戏行业的时候正值《塞尔达传说旷野之息》发售不久让业界感受到了大世界游戏的魅力而 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 向 TAD. 人为调控场景美术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 网格体。类似于数学模型是对一个问题的数学抽象产出的是一系列用于求解的数学公式而程序化模型表示的是一项内容在程序化步骤上的抽象产出的是像 HDAHoudini 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 行为进行调控。BPCG 生成的数据怎样与手工编辑的数据互不干扰。C计算时间过长问题。E增量生成功能的开发。D场景美术分不清自己调控完 PCG 之后需要上传什么样的数据。BPCG 生成数据的性能问题。……这部分有很多细节问题一时想不起来太多后续想到了再补充上去吧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 技术的开发者又是场景美术对最终场景效果负责——这样也能减少耦合带来的问题。