Ludo Atlas · 引擎轨道 · Unreal Engine¶
引擎轨道。定位：以高保真实时渲染与影视级内容管线见长的商业引擎，3D 高规格项目的默认候选之一。 配套：《技术实现手册》·《美术与音频手册》·《制作管理手册》·《全平台上架手册》。 原则：本文不贴 API 代码、不写版本号；接口与配置细节随引擎迭代变化，以官方文档与你的性能分析工具为准。
1. 定位与选型¶
Unreal 是把高保真渲染与影视级内容管线做成核心卖点的商业引擎：实时渲染质量向离线渲染看齐，资产与工具链和影视制作的流程高度重合；从三五个人的小组到数百人的工业管线都有团队在用，但引擎复杂度与内容成本要靠人力摊薄，人数不够时，只有画面即卖点的项目才划算。
- 渲染与画面：虚拟化几何、动态全局光照、时间超采样这类高规格方案开箱可用，画面的起跑线在同类引擎里最高。
- 内容管线：模型、材质、特效、动画、过场演出共用一套编辑器，从美术软件导入到实时预览的流程按工业化量产设计。
- 双语言：C++ 是引擎本体语言，蓝图是可视化脚本，两者混用是标准工作方式（§4.2）。
- 商业模式：引擎免费使用；产品营收超过约定门槛后按比例向官方支付分成，比例与门槛以官方许可协议为准。源码通过官方渠道提供，可自行编译与改造。
适合：
- 3D 高保真项目：写实画面、大场景、电影化演出，引擎的默认能力与这类目标最匹配。
- 中大型团队：角色框架、资产管线与协作流程按多职能分工设计，团队越完整，引擎复杂度越能被摊薄。
- 影视与虚拟制片：实时渲染与影视制作共用工具链，实拍与数字内容可以在同一套资产上协作。
- 已有 C++ 积累、愿意维护编译流程的团队：引擎的能力上限在 C++ 这一侧。
需要三思：
- 2D 与小体量玩法原型：引擎复杂度与内容成本远大于收益，轻量引擎更划算。
- 个人与两三人团队的非画面导向项目：内容产能喂不饱画面上限，范围容易被拖垮。
- 低端设备与轻量包体目标：高规格渲染有代价，向下适配要专门投入（§5）。
跨引擎取舍收口成四行（其余轨道见 docs/engines/）：
| 项目画像 | 常规选择 |
|---|---|
| 高保真 3D、影视级管线、内容团队完整 | Unreal（本页） |
| 通用商业项目、要生态与招人 | Unity（docs/engines/unity/） |
| 完全开源、轻工程、独立开发 | Godot（docs/engines/godot/） |
| 纯 Web 交付、页面级轻量玩法 | Web 技术栈（docs/engines/web/） |
选型检查清单：
- 项目的第一卖点是画面还是玩法？画面优先选 Unreal 才顺；玩法优先，先掂量引擎复杂度能不能接受（§7 第 4 条）。
- 团队里谁负责 C++ 编译与构建？没有明确的人，先补上再立项。
- 目标平台里有没有移动与 Web？有，就把包体与性能验证提前，别默认「引擎能导出就等于能发」。
- 内容产能有多少？画面上限要靠内容量喂饱，先估美术与关卡产能，再定画面规格。
2. 生态与工程结构¶
2.1 工程结构¶
Unreal 工程把源内容与生成产物分得比较开，骨架由几类目录构成：
| 位置 | 内容 | 进版本库 | 说明 |
|---|---|---|---|
Content/ |
关卡、蓝图、材质、模型、音视频等资产 | 是 | 资产工作区，组织规范见 §2.2 |
Source/ |
C++ 源码，按模块拆分 | 是 | 模块边界决定编译影响范围（§3.3） |
Config/ |
渲染、输入、默认类等工程级配置 | 是 | 团队共享，改动要评审 |
Plugins/ |
自研与第三方插件 | 按需 | 第三方插件先隔离评估再进主工程 |
Binaries/、Intermediate/、Saved/、DerivedDataCache/ |
编译产物、缓存、日志与本地设置 | 否 | 可再生成，提交只会制造冲突与体积 |
.uproject标记工程身份，记录引擎关联与插件启用清单，必须进版本库。- 引擎与工程分离：全队统一引擎版本，升级单独排期验证，避免各用各的（§7 第 9 条）。
- 官方模板（第一人称、第三人称等）自带一套完整的 Gameplay 示例，基于模板改造比空工程造轮子快；用不到的内容清掉，保留的部分读懂再改。
- 插件是能力组织方式：官方不少功能与第三方中间件以插件提供，按需启用；引入前评估维护状态、许可证与体积。
2.2 内容组织：目录与命名¶
Content Browser 里的路径就是资产引用路径，目录与命名失控的代价会贯穿项目全程。
- 目录按领域分（角色、环境、特效、界面、核心系统、关卡），领域内再按子系统细分；深度控制在三四层以内，再深就要重新分组。各领域的资产留在领域内，跨领域共用的放共享目录，不要既按类型又按功能重复归属。
- 命名用社区通用前缀，团队固化成一份对照表，评审时照表检查：
| 前缀 | 资产类型 |
|---|---|
BP_ |
蓝图类 |
WBP_ |
界面控件蓝图 |
M_ / MI_ |
主材质 / 材质实例 |
T_ |
纹理 |
SM_ / SK_ |
静态网格 / 骨骼网格 |
ABP_ |
动画蓝图 |
NS_ |
Niagara 特效系统 |
DT_ |
数据表 |
- 改名与移动尽量在编辑器内做，让引用自动跟随；移动后的重定向器（Redirector）要清理，否则会在 Content Browser 里越积越多。
- 关卡只做摆放与编排；可复用逻辑做成蓝图类与组件，不要长在关卡里。
2.3 版本控制¶
Unreal 工程与普通代码仓库的最大差异：资产默认是二进制（.uasset、.umap），改了什么看不见，冲突无法手工合并。
- 忽略清单第一天配好：
Binaries/、Intermediate/、Saved/、DerivedDataCache/与各类构建产物，全部可再生成。 - 二进制资产与大文件（视频、音频、模型源）走 Git LFS，仓库里只留指针；
.uasset、.umap也进 LFS 名单。 - Git LFS 在文件锁与协作流程上的工具支持弱于集中式方案；大团队与美术量产场景更常见集中式版本控制加文件锁，同一资产同一时刻只有一人改。工具之外还要有约法：同一关卡、同一关键蓝图，同一时间只归一人改。
- 蓝图的评审无法靠 diff：约定评审方式（截图、录屏、结对过一遍），意图靠命名与注释留痕。
3. 核心工作流¶
3.1 编辑器里的日常循环¶
日常节奏：在编辑器里搭关卡、拼 Actor、调材质与特效，蓝图或 C++ 写逻辑，进运行模式（Play In Editor）验证。三条纪律：
- 改内容与改 C++ 的反馈成本不同：内容迭代几乎即时，C++ 改动要走编译，两类工作分开安排节奏（§3.3）。
- 复现问题用最小关卡：从主关卡剥离出只含相关对象的测试关卡，别在完整关卡上调试。
- 重复操作工具化：批量改名、规范检查、资产处理，做成编辑器工具一次执行。
3.2 资产管线：从美术软件到引擎¶
- 外部资产走引擎导入流程进
Content/：模型、贴图、动画各有导入选项（LOD、碰撞、材质槽、压缩），选项按项目规范固化成清单。 - 材质在引擎内搭建（§4.3），与模型的接口是材质槽；同类表面共用主材质，变体走实例。
- 导入后的资产规格（分辨率、面数、LOD）属于验收的一部分，和命名一样进评审。
3.3 编译与打包¶
- C++ 编译循环是项目的节奏基准：改动范围决定等待时间，头文件依赖失控会把每次小改放大成大面积重建。控制手段：模块拆分、依赖收敛、稳定系统放进 C++、高频迭代的部分放蓝图与数据（§4.2）。
- 热重载只覆盖一部分改动；动了类结构或数据布局，通常要完整重编并重启编辑器，排期时把这一点算进去。
- 打包按目标平台出产物，区分内测构建与发布构建；命令行打包接进 CI，每天留一份可下载、可运行的构建（基建清单见《技术实现手册》§6）。
- 主机与移动的发布另有平台方授权、开发机与提审流程，提前排期（《全平台上架手册》）。
4. 关键系统惯用法¶
4.1 Gameplay Framework：规则、意志、身体¶
引擎内置一套角色分工框架，理清它，多数「这段逻辑放哪」的问题都有答案：
| 角色 | 职责 | 要点 |
|---|---|---|
| GameMode | 一局或一关的规则：装配默认类、出生与胜负条件 | 联机时只跑在服务器侧；单机项目里就是规则的唯一定义处 |
| PlayerController | 玩家的代言：输入路由、界面交互、视角朝向 | 身体死亡重生只换 Pawn，控制者留存 |
| Pawn | 世界里的身体：位置、移动、碰撞、被控制 | 人形角色用带移动组件的 Character 子类 |
| GameState / PlayerState | 对局与个人的可同步状态 | 比分、阶段这类信息放这里，不进界面 |
| GameInstance | 跨关卡留存的会话对象 | 会话级数据：登录态、全局设置 |
- 心智模型一句话：GameMode 定规矩，PlayerController 代表意志，Pawn 是身体。重生换身体不换意志，是检查分工有没有摆对的最快方式。
- AI 与玩家对称：AI 控制器驾驶 AI 的 Pawn，与玩家侧同源；写 AI 时沿用同一套「控制器加身体」的框架。
- 规则别写在关卡蓝图：规则进 GameMode 与系统类，关卡蓝图只做这一关的编排，否则同一套规则会在每个关卡各写一份。
4.2 蓝图与 C++：分工与混合¶
| 维度 | 蓝图 | C++ |
|---|---|---|
| 上手 | 可视化，无需编译，引擎能力全曝光 | 需要 C++ 与引擎框架知识 |
| 迭代速度 | 改完即跑，原型期最快 | 每次改动都走编译流程 |
| 性能 | 够用，逐帧重活会吃亏 | 热路径与大批量逻辑更稳 |
| 评审与合并 | 资产形态，diff 与代码评审不适用 | 可 diff、可评审、可回滚 |
| 适用落点 | 原型、内容逻辑、表现编排、策划自助调整 | 系统底层、性能敏感路径、第三方集成、长期公共代码 |
选择规则：
- 原型与玩法验证：用蓝图，速度就是生产力。
- 性能敏感与系统层：用 C++，把稳定骨架定下来，向蓝图暴露可调参数与可扩展事件。
- 混合是常态：C++ 定义类与参数，蓝图做子类与配置；改行为改 C++，调数值调蓝图数据。
- 边界写进团队约定：逐帧逻辑、循环内重活不进蓝图；蓝图资产的评审方式单独约定（§2.3）。
4.3 材质与 Niagara：美术驱动的性能敏感资产¶
- 材质系统用节点图定义表面如何响应光照（基色、粗糙度、金属度等 PBR 输入），是画面风格的主要实现处。
- 主材质与材质实例分工：主材质搭骨架、留参数开关，具体资产用材质实例调参、共享编译结果；为每个资产复制主材质，会把着色器数量与维护面一起放大。
- Niagara 是粒子与特效系统：节点化搭建，CPU 与 GPU 模拟可选，参数暴露给美术在资产上直接调。
- 两者的共同身份是「美术驱动的性能敏感资产」：编辑器里搭起来轻松，运行时按数量、面积与复杂度放大开销。规范先于技巧：实例化、按平台设特效质量档位、材质复杂度进预算（§5）。
4.4 系统惯用法清单¶
对照《技术实现手册》§2 的跨引擎清单，Unreal 语境下各系统的落点：
- 输入：逻辑动作与物理按键分层，输入缓冲与状态机收进角色逻辑；按键重映射交给引擎的输入体系（《技术实现手册》§2.1）。
- 界面：用引擎自带的控件体系（UMG）；数据与视图分离，频繁变化的元素与静态元素分开。
- 存档：只存状态不存对象引用；带版本号与迁移；写入先临时文件再替换（《技术实现手册》§2.4）。
- 对象池：高频生成销毁的对象（子弹、特效、拾取物）池化；引擎已内建池化的类型不要重复造。
- 相机：跟随与震屏参数按（《技术实现手册》§2.3）执行；过场演出相机与玩法相机统一管理，别互抢控制权。
- 网络：引擎自带复制框架与服务端权威模型；单机项目也按同一分工写，联机能力的复用面更大（《技术实现手册》§5）。
5. 性能与优化要点¶
方法论继承《技术实现手册》§3：先定预算、先测后改、真机大于编辑器。Unreal 项目多发的热点集中在五处：
| 热点 | 症状 | 对策 |
|---|---|---|
| 渲染特性全开 | 高规格特性叠加，帧率与显存双杀 | 按目标平台分档开关（虚拟化几何、动态全局光照各有成本模型），控制分辨率与场景复杂度 |
| GPU 提交与过绘制 | 半透明与粒子层叠处掉帧 | 控制透明面积与粒子密度，材质实例化减少切换 |
| 蓝图逐帧开销 | 大量蓝图对象各自每帧执行 | 事件驱动替代轮询，重逻辑转 C++，同类对象合并驱动 |
| 着色器编译 | 改材质后长时间等待，打包前集中编译 | 主材质进冻结期管理，改动集中处理，编译时间计入 CI 预算 |
| 内存与加载 | 高分辨率资产与大世界拖垮加载 | 异步加载与流送，资产规格与压缩按平台，显存进预算表 |
- 测量工具链：引擎性能分析套件（Insights）看帧与任务，GPU 抓帧工具定位渲染管线真凶，平台工具做真机确认。编辑器数据常常失真，结论以打包版本与目标设备为准。
- 预算表：帧预算按目标帧率切给逻辑、渲染、物理、界面；内存与显存预算分平台；包体预算分渠道（《技术实现手册》§3.1）。
- 优化纪律：一次只改一个变量；改前改后记录同一场景同一路径的数据；没有测量不做优化。
6. 学习路线¶
按产物分四段，每段的里程碑都是做出来的东西：
- 引擎基本功（2-4 周量级）：编辑器操作、关卡与 Actor、材质与蓝图入门。做两个小东西：一个基于官方模板改造的可玩原型，一个带界面与存档的小关卡。
- Gameplay 与蓝图（1-2 个月量级）：把 §4.1 的角色分工挨个用一遍（自定义规则、重生、对局状态），再用蓝图完成一个完整玩法原型；对照§2 做最小系统实现。
- C++ 与混合模式（1-2 个月量级）：从一个「C++ 基类加蓝图子类」的小系统起步，把编译、调试、热重载的脾气摸熟；之后深入引擎内部可走《引擎源码阅读路线》。
- 完整项目：进《制作管理手册》的流程，把版本控制、CI 构建、打包拉满，走一次完整发布。
学习纪律：官方文档与学习门户是概念与行为的权威依据，教程滞后于引擎迭代是常态，分歧以官方为准；演示级画面不等于项目级内容成本，评估能力以走完一个垂直切片为准。
7. 常见坑¶
- 蓝图膨胀：一个蓝图堆出几百个节点，没人敢改、无法评审，逐帧逻辑悄悄吃帧。系统与内容的边界要早立（§4.2）：逻辑进 C++ 与组件，蓝图做配置与编排。
- C++ 编译循环失控：一个头文件的改动触发大面积重编，迭代被迫改成「攒一批再编」，反馈变慢。对策见 §3.3：模块拆分、依赖收敛、稳定系统放进 C++。
- 资产命名与目录失控：没有前缀与目录约定，找资产靠记忆；随手改名与移动制造断引用与重定向器垃圾。规矩建仓第一天立（§2.2）。
- 个人项目误选：两三个人的玩法驱动项目选了内容成本最重的引擎，工期被引擎复杂度与美术规格吃光。选型看项目画像（§1），不追画面演示。
- 商城资产整包导入：换来用不到的依赖、规格不一的资产与自带的目录结构。先隔离评估、只取需要的部分，导入后按项目规范改造。
- 版本控制按纯代码项目管：二进制资产当文本处理、缓存目录进库、大文件走普通提交，体积与冲突失控后很难回头（§2.3）。
- 材质复制而非实例化：每个资产复制一份主材质，着色器数量与维护面成倍增长（§4.3）。
- 只在编辑器里看性能：编辑器流畅，打包后与真机落差大；性能结论只认打包版本与目标设备（§5）。
- 多人各用各的引擎版本：资产互不兼容、现场互相覆盖；统一版本，升级单独排期验证（§2.1）。