数据驱动与游戏世界编辑器

数据驱动的收益与代价

早期游戏几乎全由程序员硬编码，因为内容少、质量要求低。现在内容量增长快于团队规模：第九代主机（Xbox Series X/S、PS5）时代，团队常说要用不比上一代大多少的团队做出十倍的内容（卷 II 16.3）。

• 收益：程序员稀缺昂贵，产出内容比美术和策划慢得多；把创造内容的能力交给负责内容的人，能充分利用每个人、减轻程序团队压力；改一个小参数或整关重做都能很快看到效果，最好无需程序员帮忙，从而把游戏打磨到很高质量。
• 代价：要为美术和策划写定义数据的工具；运行时代码要能健壮地处理各种可能的输入；还要提供游戏内预览和排错工具。这些都要花大量时间编写、测试和维护。
• 常见失败：很多团队一窝蜂地数据驱动化，不研究对自己游戏和成员需求的影响，结果工具和引擎系统过于复杂、难用、bug 多、难以适应需求变化，生产力反而不如老式硬编码。
• 原则：每个引擎都该有一些数据驱动组件，但要非常谨慎地选择哪些部分数据驱动：比较实现该功能的成本与它在项目周期内预计节省的时间；牢记 KISS（"保持简单"），借爱因斯坦的话说，"尽可能简单，但不能更简单"。配置层面的数据驱动见 引擎配置系统。

世界编辑器

所有商业引擎都有某种世界编辑器（卷 II 16.4）：Quake/Doom 系的 Radiant；Valve Source/Source 2 的 Hammer（曾名 Worldcraft、The Forge，用于《半衰期 2》《传送门》《求生之路》《泰坦陨落》等）；CRYENGINE 的 Sandbox（可同时在 2D 和立体 3D 下实时编辑多平台环境）。

世界编辑器通常能设定游戏对象的初始状态（属性值），也能控制动态对象的行为：可以用数据驱动的配置参数（A 初始不可见、B 生成后立即攻击玩家、C 可燃），也可以用脚本语言，这就把策划的工作推进了编程领域；有的编辑器甚至允许几乎不靠程序员定义全新的对象类型。

典型功能

（卷 II 16.4.1）

多对象编辑：各对象某属性值相同就显示该值，编辑后写入所有选中对象；值不同就留空，输入新值会覆盖全部使它们一致。选中异构对象时只显示所有类型共有的属性；因为游戏对象类型通常继承自共同基类，至少位置、朝向这类共享属性仍能一起编辑（卷 II 16.4.1.6）。

自由属性 (free-form properties)：属性集合和类型一般按对象类型定义（可渲染对象有位置、朝向、缩放、网格；光源有位置、朝向、颜色、强度、类型）。有的编辑器允许逐实例添加用户自定义的键值对，名字、类型、值都由用户定，非常适合原型化新玩法或一次性场景（卷 II 16.4.1.6）。

需要特殊处理的对象类型（卷 II 16.4.1.8）：

• 光源：没有网格，用图标表示；编辑器最好能近似显示光照效果，方便实时调整。
• 粒子发射器：独立渲染器的编辑器里可能只显示图标或做近似模拟；编辑器在游戏内或与游戏实时连接时不成问题。
• 声源：可视化全向声源的最大半径，或定向声源的方向和锥形（3D 音频模型见 三维音频渲染）。
• 区域：用来检测对象进出等事件或划定用途的空间体积。有的只支持球或定向盒，有的支持俯视为任意凸多边形、侧面竖直的形状，甚至 k-DOP 等更复杂几何；球形只需一个半径属性，任意形状就需要专门的编辑工具。
• 样条：由控制点（可能还有切线）定义的三维曲线。常用 Catmull-Rom，因为它只需控制点、且曲线经过所有控制点（见 埃尔米特与 Kochanek-Bartels 样条）。编辑器要能显示样条并选中、操作单个控制点；有的提供"粗选"（选对象）和"细选"（选控制点、区域顶点）两种模式。
• AI 导航网格：用二维三角网格描述可行走区域边界并为寻路提供连通信息，编辑器通常是 AI 策划创建、查看、编辑它的核心工具（UE5 侧见 AI 感知、EQS 与导航）。
• 其他自定义数据：例如给 AI 用的"可供性 (affordance)"（窗、门、可攻防点）、掩体点、可攀爬边缘。

迭代时间

具体机制不重要，关键是从修改到在游戏里看到效果的往返迭代时间足够短。迭代不必是瞬时的，应与修改的范围和频率相称：改角色最大生命值应该很快，整块世界的灯光大改则可以接受更长时间（卷 II 16.4.1.10）。代码侧的快速迭代见 Live Coding 实时编译，运行时调参见 游戏内调试工具。

集成资产管理

有的引擎把世界编辑器和资产数据库管理的其他方面集成在一起：网格与材质属性、动画、混合树、动画状态机、碰撞与物理属性、纹理资源等（卷 II 16.4.2）。最著名的是 UnrealEd：它直接集成在引擎里，编辑器中的修改直接作用于运行中游戏的动态元素，快速迭代很容易；它管理从动画、音频片段到网格、纹理、材质和着色器的整个资产数据库，提供统一、实时、所见即所得的视图（Content Browser 访问全部资产）。

数据处理成本：资产管线通常分两步：先从 DCC 导出到只含游戏相关数据的平台无关中间格式，再处理成针对特定平台优化的格式（多平台项目中一个中间资产会生成多个平台资产）。各工具管线的关键差别在于第二步发生的时机（卷 II 16.4.2.1）：

与 UE5 文档的对照：GEA 说 UnrealEd 在导入时就做平台相关优化。本库依据 UE 5.8 文档的 烘焙、打包与 Zen 加载器 则写明，引擎内部以 PNG、WAV 等格式存资产，转换为各平台格式发生在打包流程的 Cook 阶段。两种说法并列记录：至少就 UE5 的官方描述而言，平台相关转换属于烘焙阶段，而不是导入阶段。

ACP 的整体结构见 资产管线与工具链，UE5 编辑器的扩展方式见 编辑器扩展与 Python 脚本。