运行时引擎分层架构

游戏是什么样的软件

大多数二维、三维电子游戏是软实时 (soft real-time)、交互式、基于代理 (agent-based) 的计算机模拟（卷 I 1.1.1）：

• 模拟：对真实或虚构世界的数学近似与简化；近似和简化是游戏开发者最有力的工具之一。
• 基于代理：世界由许多相互作用的独立实体（角色、载具、火球……）组成，所以游戏大多至少部分采用面向对象范式。
• 交互式、时间性：世界状态随时间变化，并且要响应不可预测的玩家输入。
• 实时与截止时间：画面至少每秒约 24 次更新才有运动错觉（多数游戏 30 或 60 FPS）；物理可能要每秒 120 次才稳定；AI 感知每秒几次即可；音频库可能至少每 16.7 毫秒要调用一次以免缓冲断流。
• 软实时：错过截止时间不是灾难（帧率掉了玩家不会死），区别于直升机航电、核电站控制棒这类硬实时系统。

数学模型分解析和数值两种。恒定重力下下落的刚体有闭式解

可以对任意 $t$ 求值；但玩家输入不可预测，整个游戏不可能解析建模，所以游戏用数值模型 $y(t+\Delta t) = F\big(y(t), \dot y(t), \ddot y(t), \dots\big)$，在游戏循环的每次迭代里让 AI、玩法逻辑、物理等系统推进一个离散时间步，再“渲染”出画面、声音和手柄震动（卷 I 1.1.1；循环细节见 游戏循环与更新方法）。

什么算“游戏引擎”

• “游戏引擎”一词出现在 1990 年代中期，源于 Doom 把核心组件（渲染、碰撞、音频）与美术资产、关卡和玩法规则较清楚地分开；这种分离催生了授权和 mod 社区（卷 I 1.2）。
• 游戏与引擎的边界常常模糊：有的渲染代码“知道”怎么画兽人，有的则只提供通用材质着色，“兽人性”完全由数据定义。Gregory 认为数据驱动架构才是引擎与“只是一个游戏”的区别：硬编码规则或为特定对象写特例渲染代码，就很难复用来做别的游戏（卷 I 1.2）。
• 可复用性是一条连续谱：从只能做一款游戏（Pac-Man）、可定制做相似游戏（Hydro Thunder 引擎）、可 mod 出同类型任何游戏（Quake III 引擎），到能做几乎任何游戏（Unity、Unreal Engine 5、Source……），而“能播放任何游戏内容的通用引擎”可能永远做不到（卷 I 图 1.1）。
• 通用性与最优性的取舍：高效软件总要基于对用途和硬件的假设做取舍。室内引擎可能用 BSP 树或入口 (portal) 系统做精确遮挡，室外引擎则少用精确遮挡、大量依赖细节层次 (LOD)。硬件变强让类型间差异在缩小，但为特定游戏和平台精调总能做得更好（卷 I 1.2–1.3）。

不同类型对引擎的侧重

书中逐一列举了各类型的技术侧重（卷 I 1.3），摘要如下：

分层结构

引擎像所有大型软件一样分层构建，上层依赖下层，反之不行；下层依赖上层就形成循环依赖，会导致耦合、难以测试、妨碍复用（卷 I 1.5）。下图按书中图 1.16 的层次自下而上简化：

flowchart BT
  HW["目标硬件"] --> DRV["设备驱动"] --> OS["操作系统"] --> SDK["第三方 SDK 与中间件"]
  SDK --> PIL["平台无关层"] --> CORE["核心系统"] --> RM["资源管理器"]
  RM --> SUB["渲染 / 碰撞与物理 / 动画 / 音频 / HID / 网络 / 性能分析与调试"]
  SUB --> GF["游戏性基础层"]
  GF --> GS["游戏专属子系统"]

越往上越接近具体游戏；书中认为如果游戏与引擎之间能划出一条线，它就在游戏专属子系统与游戏性基础层之间，但实际中总有游戏专属知识渗入下层（卷 I 1.5.16）。

各层要点（卷 I 1.5.1–1.5.16）：

• 操作系统：PC 上是抢占式多任务，游戏不能假设独占硬件；早期主机的“系统”只是编进游戏的薄库，而现代主机系统会打断游戏、在后台录像和下载，主机与 PC 开发的差距在缩小。
• 第三方 SDK：容器与算法（Boost、Folly、STL）、图形 API（DirectX、OpenGL、Vulkan、Metal、主机底层接口）、物理（Havok、PhysX、ODE）、动画（Granny、Havok Animation、OrbisAnim）、字体（FreeType、HarfBuzz）、平台服务（Steamworks、EOS）。
• 平台无关层：包装文件系统、网络、高精度计时器、线程、图形与物理等接口。理由有二：各平台 API（甚至 C 标准库的部分函数）差异很大，包装后上层得到一致接口；即使库本身跨平台（如 Havok），包装也能隔离未来更换中间件的影响。通常只有第一方工作室才不跨至少两个平台。
• 核心系统：断言（发行版中通常剥离）、自定义内存分配（追求高速并抑制碎片）、数学库、自定义容器与算法（常为避免动态分配而手写），以及字符串与哈希 ID、日志、随机数、反射与序列化、对象句柄、本地化、配置等。
• 资源管理器：为所有类型的资产提供统一访问接口；有的引擎高度集中（Unreal 的 package），有的则让程序直接读磁盘文件或压缩包（Quake 的 PAK）。
• 渲染引擎常再分层：底层渲染器只管尽快尽好地画出提交的图元（含图形设备接口、材质与着色器、光照、相机、文字、调试绘制），除背面剔除和把三角形裁剪到视锥之外基本不关心可见性；图形设备接口负责枚举与初始化图形设备、建立渲染表面（后台缓冲、模板缓冲等），PC 上还要写“消息泵”在处理 Windows 消息之余反复运行渲染循环；场景图与剔除层用视锥剔除或 BSP、四叉树、八叉树、k-d 树等空间划分快速求出潜在可见集 (PVS)，入口或遮挡剔除也可放在这一层。书中提醒空间划分有时被叫作“场景图”，但严格说场景图是一种特定数据结构，并不涵盖空间划分。理想情况下底层渲染器不依赖具体用哪种划分，这样各游戏团队能复用图元提交代码、只为自己的游戏定制 PVS 判定（OGRE 的可插拔场景图是例子）；视觉效果（粒子、贴花、光照贴图与环境贴图、动态阴影、全屏后处理如 HDR 色调映射与泛光、全屏抗锯齿、调色）——粒子和贴花通常是独立组件、作为底层渲染器的输入，光照贴图、环境贴图和阴影通常在渲染引擎内部处理，后处理则要么是渲染器的一部分、要么是作用于其输出缓冲的独立组件；前端（HUD、菜单、开发者控制台、全动态视频 FMV、游戏内过场 IGC）——二维元素通常用正交投影画带纹理的四边形，或在 3D 中以始终朝向相机的公告板四边形绘制。
• 性能分析与调试：除 VTune、PIX、Razor 等通用工具外，引擎通常自带代码插桩计时、屏显统计、内存与泄漏统计、分类调试输出、事件录制回放；PS4/PS5 的崩溃转储还附带崩溃前的截图和录像。
• 碰撞与物理：二者通常紧密耦合，因为检测到碰撞后几乎总在物理积分与约束求解中处理；如今很少有公司自写，通常集成第三方 SDK。
• 动画：五种基本类型：精灵/纹理动画、刚体层级动画、骨骼动画、顶点动画、变形目标；骨骼动画最普遍。动画系统为每根骨骼输出姿势，以矩阵调色板交给渲染器做蒙皮；布娃娃 (ragdoll) 则让动画与物理紧密配合。
• HID：把平台底层手柄细节与高层游戏操作分开：摇杆死区、按键去抖、按下/抬起事件、加速度计平滑、按键映射，以及组合键、按键序列和手势检测。
• 网络：单屏多人、分屏多人、联网多人、MMOG 四种形态。多人会深刻影响对象模型、渲染、输入、角色控制和动画；给单机引擎补多人很难，最好从第一天就设计；反过来很简单，许多引擎把单人模式当成只有一个玩家的多人游戏（Quake 的客户端叠在服务器上运行）。
• 游戏性基础层：在引擎底层与玩法代码之间提供游戏世界（静态与动态元素）、游戏对象模型、事件/消息系统、脚本系统、AI 基础（导航网格、寻路、避障）、世界加载与流送。对象模型要回答：是否面向对象、用什么语言、类层级是单一巨型还是松耦合组件、如何引用对象（裸指针、智能指针、句柄）、如何唯一标识（地址、名字、GUID）、如何管理生命周期、如何随时间模拟状态（详见卷 II 第 17 章）。
• 脚本系统：没有脚本时改逻辑和数据要重新编译链接；有脚本时改脚本并重新加载即可，有的引擎甚至支持运行中热重载。

与 UE 和本知识库其他页的对应

• UE 的渲染线程、场景代理和 RHI 分层，对应上面“底层渲染器 + 场景与剔除层”的分工，见 UE5 渲染架构。
• UE 的 Actor/组件、GameMode 等，属于“游戏性基础层”的一种具体实现，见 Gameplay 框架；对象模型中“单一巨型层级还是组件”的问题，在 组件模式 中有模式层面的讨论。
• 分层与解耦的代价、性能与灵活性的取舍，可与 游戏编程模式选型：解耦与性能 对照阅读。
• 运行时之外的另一半是工具与资产管线，见 资产管线与工具链。