Breachers：用 AssetPostprocessor 和 Blender 快速迭代设计

这篇文章来自比利时游戏公司 Triangle Factory 关卡设计负责人/技术美术 Jel Sadones 和开发负责人 Pieter Vantorre，将与我们分享"Blender到Unity"的生产管线，以及团队最新作品 VR 战术 FPS 游戏 Breachers 的制作方式。

本文首发于 Unity 社区，欢迎阅读专栏原文：

https://developer.unity.cn/projects/64410366edbc2a001ef95e81

Unity 在过去十多年来一直是 Triangle Factory 首选的引擎和开发环境，而在环境建模和设计上，团队已在多年来尝试过许多工作流，试过 ProBuilder 这类引擎内的建模工具，也试过从其他建模软件导入做好的预制件来组装场景。至于目前的项目，团队选择在 Blender 里建立关卡模型，依赖 Unity 的 AssetPostprocessor 把资产导入到项目中。这里，制作团队希望与大家分享为何选择这种流程，以及它怎样支撑起快速的设计迭代。

找到合适的工作流程

从 2019 年 Triangle Factory 开始开发首款大型 VR 游戏 Hyper Dash —— 一个快节奏的 5v5 竞技射击游戏时，很多人就已经熟悉了团队采用的“Blender 到 Unity”流程：用 Blender 建立模型，导出为 FBX 文件，再导入到 Unity。整个手动流程包含以下几步：

1. 创建场景里的动态对象，比如武器弹药、重生点、占领点；

2. 加入碰撞体来防止玩家走到或传送到特定区域；

3. 创建看不见的路线让机器人能正确行动；

4. 其他

这种流程适合较小的项目，但会随项目变大而愈发繁琐。在计划开发下一个游戏时，已经不可避免要改进工作流程。

从原型中寻找痛点

Breachers 带有复杂的关卡布局、微妙的游戏机制、更多技术系统，以及更加高级的图形质量，其目标平台为最新一代的独立 VR 硬件。它比 Hyper Dash 更复杂，这点很快体现在了工作流程里。

在制作原型阶段，团队仍大量依靠预制件来保存动态对象，比如窗户挡板。这些挡板会在热身阶段阻隔内部与外部的视线，防止队伍双方看到对方。

在测试原型时，经常要四处变更窗户的位置来改进游戏玩法，于是也经常需要到 Blender 里修改模型并将它重新导出到 Unity，再手动摆放挡板来契合修改。因此，很多时间都花在了在 Scene 视图中四处观察、手动检查和改正模型上。即便如此，在多次游戏测试中还是会经常发现不对劲的地方。

很明显，这种流程无法实现在测试期间快速更新地图设计，无论是内部测试还是 alpha 公测。团队本想在公测期间让玩家们免费试玩一张地图来收集反馈，用户反馈当然非常宝贵，但随反馈而来的大量手动修改也让人压力山大。

基于预制件流程的另一个缺点在于性能。团队的主要目标平台是便携的独立 VR 头显，同时又想提高画质，因此希望尽可能榨取每一点性能。

用预制件组装关卡并没有直接在建模软件里创建一片连续的模型网格来得高效。就算把两个墙的组件拼在一起，贴合处也依旧有看不到的面。只要用预制件，关卡里就会有许多看不见的面（或位于对象底部，或和墙贴在一起），它们会占用宝贵的光照贴图空间。在一整个关卡里，这些性能浪费积少成多，最终影响视觉质量。

最后一个问题是，某些看起来不相关的修改一旦应用到 Blender 的原模型上就会产生问题，比如重命名某个对象。随着游戏或关卡不断完善，资产一般都需要重新组织，取些更清晰、连贯的名称。但在 Blender 里重新命名对象再导出很容易毫无征兆地破坏 Unity 里的覆写和附加内容，导致回滚。

重命名后的模型再导入 Unity 时，引擎无法根据名称来找到模型网格，便会从预制件里移除它。被移除对象的子对象会被转交给预制件的根对象，脚本会被移除，新对象需要手动清理。

明确目标

Breachers 原型制作阶段结束后，团队在 2022 年初开始准备进入生产阶段，美术和开发聚在一起讨论了怎样解决以上这些问题。团队明确了理想资产管线所应具备的几个特征，以支持 Breachers 快速、灵活的迭代：

1. 所有关卡模型的创建和修改都应当用 Blender 完成。

2. 所得即所见：设计师用 Blender 创建的内容应当尽量在 Unity 中还原。

3. Blender 里的更新应当自动导入 Unity，无需手动完成。

Making Blender love Unity

正如上方提到的，团队的主要目标是在 Blender 里精确地可视化游戏——不仅要正确地反映 Unity 里的成果，还要反映游戏机制的建立方式。Breachers 的游戏玩法不仅基于关卡布局，还基于动态对象（比如可打破的墙壁）和其他不可见的元素（比如音量和碰撞体）。团队希望在设计阶段就暴露出这些信息，并将其精确地搬到 Unity。

自定义属性与 Unity 的 AssetPostprocessor

自定义属性（Custom Properties）是整个流程的关键之一，主要在 Blender 里添加。这些属性会经由 FBX 文件导入 Unity，用于查看或运行自定义逻辑。

这让流程更加灵活、稳定。这些属性会一直保留在对象身上，让我们能重新组织和命名关卡内容，不必担心造成破坏或失去同步。

Unity 有一个强大的 AssetPostprocessor，可以在导入时对资产做出修改。团队正是应用了这个以在导入时解读自定义属性并执行操作。

用例

预制件关联（Prefab links）

自定义属性 PrefabLink 会告诉 Unity 导入的 Blender 对象应当被替换成哪个已存在的预制件，同时保留模型的变换（transform）。我们可以在 Blender 里摆放动态对象，在导入 Unity 后继续使用预制件。上方 Blender 场景里的窗户挡板就是个很好的例子。

表面类型

关于表面的定义对 Breachers 也非常重要。行走在金属阶梯上的声音必须不同于水泥地，子弹穿过木材的声音需要不同于穿过金属，每种表面在接受冲击时会有不同的效果。在 Unity 里一件件地标注道具的表面类型会耗费大量时间，于是团队同样在 Blender 里为模型碰撞体设定相应的自定义属性。  

静态标记（Static flags）

另一个重要的优化设定是 Unity 的静态标记。正确地设立标记可以极大影响可见度遮挡、光照烘焙和批处理。团队用 Blender 的自定义属性为关卡的每一部分设好了标记，包括可重复使用的道具，并将这些信息导入到了 Unity。

碰撞体

最后，我们要分享的是碰撞体的建立方式。Unity 有一个简单却高效的系统能自动为带有 _LOD0、_LOD1 等后缀的模型检测其所处的细节级别。受此启发，团队为碰撞体创建了一个类似的系统：通过在名称里加入 _BoxCollider 或 _NoCollision 后缀来确定从 Blender 导出的模型网格是否要替换成碰撞体。

代码示例

下方是团队 LevelSetupPostprocessor 的一段代码，它会读取自定义属性，并为每个导入的对象分配对应的静态标记：

为 Unity 定制 Blender

要让所有这些流畅运行，我们还需要在 Blender 中做些工作。

自定义属性不容易被发现，每次还要手动输入，这种体验并不是很好。依靠手动输入也很容易出错，使得 Blender 流程带来的优势化为乌有。抛弃预制件工作流也让我们没法利用预制件的优点，比如建立一个对象库来浏览和挑选对象。幸好 Blender 也和 Unity 一样非常灵活、可以扩展。

Blender 资产库

预制件库问题可以用 Blender 3.2 的资产库（Asset Libraries）解决。新系统类似于 Unity 的预制件系统：可以将资产保存为单独的文件，然后导入到场景，文件上的修改也会自动反映到场景中。另外，所有自定义属性或碰撞体都会正确地应用到每个资产的实例上。

自定义 Blender 插件

团队为 Blender 写了一个内部插件来用更清晰的界面设置自定义属性。只需选中对象、点击按钮就行，不再需要手动输入。团队还使用了开源的 Bundle Exporter 插件来一键导出所有 FBX 文件，修改了插件使之能导出自定义属性，并更新了 UI 用于满足快速导出的需要。

总结

建立 Breachers 的关卡设计流程最初耗费了大量时间，但团队一直相信这是正确的选择。从最初 alpha 测试的简单布局到几个月后的最终发布，关卡的迭代一直都非常迅速、轻松。工作流程的设计移除了不少设计师与美术肩上的重担，同时也给予了他们部分程序员的权力和职责。相信正是 Unity 和 Blender 之间流畅的整合过程让 Breachers 成为团队乐于与世界分享且引以自豪的游戏。

谢谢你看到这里，祝玩得开心，创作愉快！