约 19 分钟技术学习游戏引擎

Games104学习笔记(1)

GAMES104:游戏引擎导论

课程:GAMES104《现代游戏引擎:从入门到实践》
讲次:Lecture 01 / Overview of Game Engine
讲者:王希(Xi Wang,Booming Tech)
视频时长:约 75 分 48 秒
笔记性质:根据本地视频中的幻灯片与讲解主题整理,不是逐字稿;时间点为复习定位用的近似值。

一句话理解

游戏引擎不是“负责把模型画出来的一套代码”,而是一个在有限算力和严格实时约束下,帮助团队构建、编辑、运行、调试和持续迭代虚拟世界的技术底座与生产力平台。

可以把游戏引擎理解为三者的结合:

  1. 构建虚拟世界的底层框架:提供世界状态、规则、模拟和表现的公共基础。
  2. 创作工具:让程序员、美术师、设计师能够共同生产内容。
  3. 复杂性的艺术:在性能、画质、可扩展性、稳定性和开发效率之间做工程取舍。

本讲学习目标

  • 了解游戏引擎为什么值得系统学习,以及它已经扩展到哪些领域。
  • 梳理游戏引擎从“单个游戏的专用代码”到“通用开发平台”的演化过程。
  • 建立对引擎组成的整体认识:运行时、工具链、资源、功能系统和平台抽象。
  • 理解实时计算中的核心矛盾:想模拟一个复杂世界,但每一帧只有有限时间和资源。
  • 掌握后续课程的主干路线,知道阅读一个陌生引擎时应该从哪里开始。

1. 为什么要学习游戏引擎

1.1 游戏引擎是“皇冠上的钻石”

游戏引擎汇集了计算机科学中许多方向的成果:图形学、物理模拟、动画、人工智能、网络、操作系统、数据结构、并行计算、工具开发和软件工程等。它的难点不在于某一个单独算法,而在于把大量系统组织成一个可运行、可创作、可维护的平台。

1.2 游戏引擎已经不只服务于游戏

视频中用多个方向说明了游戏引擎技术的外延:

应用方向 引擎提供的能力
游戏 实时渲染、输入、玩法、动画、物理、网络和资源管理
虚拟人 / 数字人 角色、皮肤、毛发、表情、动作和实时交互
影视、动画和虚拟制片 实时布景、灯光预览、镜头和高质量画面
仿真与训练 对现实规则、物体和行为进行可交互模拟
数字孪生 对真实工厂、城市、设备或流程建立可视化映射
三维交互界面 在汽车、设备和空间计算场景中提供实时 3D 交互

因此,学习游戏引擎,本质上是在学习一类成熟的实时交互软件平台。


2. 游戏引擎的发展历史

2.1 早期:代码和游戏紧密绑定

早期游戏运行在存储、内存和计算能力都非常有限的硬件上。开发者通常围绕某一款游戏直接编写全部代码:数据格式、渲染方式、输入、关卡和玩法逻辑混在一起,代码复用和跨项目迁移都很困难。

这一阶段的主要矛盾是:如何在极少的资源中让游戏运行起来。

2.2 John Carmack 与早期引擎思想

随着《Wolfenstein 3D》和《Doom》等作品的发展,开发者开始意识到:

  • 底层渲染、输入和资源处理等技术可以在多个项目中复用。
  • 可复用的技术应该从具体游戏内容中抽离出来。
  • 游戏内容和底层技术分离后,可以更快地制作新游戏,甚至授权给其他团队使用。

这标志着“游戏代码”逐步向“游戏引擎 + 游戏内容”的模式演进。

2.3 3D 硬件推动现代引擎出现

显卡和 3D 加速硬件出现后,图形计算逐渐从完全依赖 CPU 转向 CPU 与 GPU 协同。以《Quake》为代表的作品展示了实时、完整 3D 世界的可能性,也提出了网络对战、同步和大规模系统协作等新问题。

硬件进步带来的不是简单的“画面更清楚”,而是让引擎可以承担更多类型的模拟与表现,同时也使引擎架构变得更加复杂。

2.4 现代游戏引擎生态

现代生态大致可以分为以下几类:

类型 例子 特征
商业通用引擎 Unreal、Unity、CryEngine 面向大量开发者,提供完整编辑器和工具链
大型团队自研引擎 Frostbite、Source、RAGE、Anvil Next 等 针对特定项目、平台和生产流程深度定制
免费或开源引擎 Godot、Stride、Torque 等 便于学习、研究、二次开发或小团队使用
中间件 Havok、PhysX、Wwise、FMOD、TrueSky、SpeedTree、Simplygon 等 为引擎提供物理、音频、天空、植被或几何处理等专门能力

生态的形成说明:现代引擎并不一定要从零实现所有功能,但必须有能力把不同系统组织起来,并让它们适应自己的运行时和生产流程。


3. 什么是游戏引擎

3.1 游戏引擎是虚拟世界的技术底座

游戏世界可以被看成一组不断变化的状态,以及一组决定状态如何变化的规则:

输入 / 网络消息
       ↓
世界状态与游戏规则更新
       ↓
动画、物理、AI 等系统模拟
       ↓
渲染、音频与其他输出
       ↓
玩家看到并操作到的世界

引擎负责提供这条链路所需要的公共能力,并协调各系统的执行顺序、数据交换和资源使用。

3.2 游戏引擎远不止渲染器

渲染只是把世界状态表现成画面的一部分。一个完整的现代引擎通常还需要:

  • 运行时框架:主循环、时间、对象生命周期、事件和系统调度。
  • 渲染系统:模型、材质、纹理、光照、阴影和渲染管线。
  • 动画系统:骨骼、蒙皮、动画剪辑、混合和角色表现。
  • 物理系统:碰撞、刚体、约束和玩法中的物理交互。
  • Gameplay 系统:输入、相机、角色、脚本、事件和游戏规则。
  • 资源系统:资源导入、加载、卸载、缓存、序列化和版本管理。
  • 工具链与编辑器:关卡、材质、动画、特效、脚本和调试工具。
  • 平台抽象:操作系统、文件系统、图形 API、输入和硬件差异。
  • 网络系统:客户端、服务器、同步、延迟和一致性处理。

3.3 引擎的核心价值是“生产力”

引擎的用户不只有程序员,还包括美术师、动画师、关卡设计师、策划和技术美术。优秀的引擎需要把复杂的底层能力包装成可理解、可操作、可协作的工具。

对程序员,重点是:

  • 提供稳定、清晰、可扩展的 API。
  • 允许增加玩法和工具,而不必频繁修改引擎核心。
  • 通过反射、脚本或数据驱动方式,让其他角色使用程序能力。

对美术师和设计师,重点是:

  • 提供编辑器和实时预览。
  • 支持从 DCC 工具导入并管理资产。
  • 让参数、规则和内容可以被非程序员直接调整。
  • 支持多人协作、版本管理和重复迭代。

所以,引擎的评价标准不仅是“能不能渲染出漂亮画面”,还包括“团队能不能高效地用它做出内容”。


4. “拥有神的能力,但只有有限的力量”:实时性的挑战

视频中的一个核心比喻是:引擎要像“神”一样模拟一个复杂世界,但手里只有有限的计算资源,而且必须实时完成工作。

4.1 每一帧都有时间预算

帧时间预算可以粗略表示为:

帧时间预算 = 1 秒 / 目标帧率

常见目标帧率对应的预算如下:

目标帧率 单帧预算
30 FPS 约 33.3 ms
60 FPS 约 16.7 ms
120 FPS 约 8.3 ms

这段时间要被输入处理、玩法逻辑、动画、物理、AI、可见性判断、渲染、音频、网络和画面提交等工作共同分配。

4.2 资源始终有限

引擎无法无限增加计算量。必须面对:

  • CPU 和 GPU 的计算能力。
  • 内存、显存和存储空间。
  • 文件读取和资源加载速度。
  • 网络带宽与延迟。
  • 不同设备之间的性能差异。
  • 多线程同步、任务依赖和调度成本。

因此,工程上的关键问题不是“能否用最精确的算法模拟一切”,而是:

在给定的平台和帧时间预算内,怎样用足够好的近似,稳定地提供目标体验?

4.3 复杂性还来自团队和内容规模

大型引擎往往有大量模块、代码和资产,并由不同角色同时使用。引擎升级时还要尽量兼容既有项目、旧资源和已有工作流。

视频用“在飞行中更新部件和引擎”来强调这个问题:引擎不是一次性写完的程序,而是一个持续演进的平台。更新不能只考虑新功能,还要考虑:

  • 老内容是否还能打开和运行。
  • 工具链是否仍然适合生产。
  • 运行时和编辑器的数据是否兼容。
  • 新旧系统能否并存和逐步迁移。

4.4 常见的工程思路

后续课程会分别展开很多方法,但本讲需要先建立方向感:

  • 用分层和模块化控制复杂性。
  • 用缓存、批处理、裁剪、细节等级和预计算减少工作量。
  • 用并行计算和任务系统利用多核硬件。
  • 用数据驱动和工具链提高内容生产效率。
  • 用平台抽象隔离操作系统与硬件差异。

5. 如何学习游戏引擎:沿着主干道建立知识地图

5.1 目标不是立刻成为某个细节专家

游戏引擎涉及的方向非常多。初学时更重要的是先知道:

  • 一个问题属于哪个系统。
  • 这个系统在整个引擎中的位置。
  • 它和哪些系统交换数据。
  • 进一步深入时应该查找哪些概念和代码。

这是一种“先建立地图,再深入支路”的学习方法。

5.2 阅读引擎代码的入口:主循环 / Update

面对一个陌生引擎,可以先寻找 main loop、run、update、tick 或类似入口,然后顺着一帧的执行过程追踪:

  1. 输入在哪里被采集?
  2. 时间步长 delta time 如何产生和传递?
  3. 游戏对象和系统何时更新?
  4. 动画、物理、AI 与玩法逻辑如何协作?
  5. 资源何时加载、缓存和释放?
  6. 渲染数据如何准备并提交给 GPU?
  7. 一帧何时结束,下一帧如何开始?

从 Update 函数开始,可以把看似庞大的引擎逐步拆成一条可追踪的数据流。

5.3 推荐的前置基础

学习后续内容时,以下基础会反复出现:

  • C / C++ 基础和面向对象编程。
  • 数据结构与算法。
  • 线性代数、坐标系和变换。
  • 计算机系统、内存和并行计算基础。
  • 计算机图形学、物理和网络的基本概念。

不必等所有基础都学完才开始,但遇到概念时要及时补齐对应的基础知识。


6. 课程内容总览

后续课程围绕以下主干展开:

模块 主要问题 关键词
基础架构 引擎如何分层、组织和调度系统? Engine Structure、Layer、Data Organization、Management
渲染 如何把模型和材质组织成实时画面? Model、Material、Shader、Texture、Light、Shadow、Render Pipeline
动画 如何让角色动作连续、可组合、可交互? Animation Concepts、Structure、Pipeline、Blending
物理 如何让世界遵守可控的物理规则? Physics Basics、Gameplay Application、Optimization
Gameplay 如何把模拟世界变成“可玩的”规则? Event、Script、Graph-driven、Input、Camera、Character
其他系统 如何补足世界的表现和交互? Effects、Navigation、Camera、Audio 等
工具链 如何让不同角色高效生产和协作? Editor、Reflection、Data Schema、Asset Pipeline
网络游戏 多个客户端如何看到一致的世界? Lockstep、State Synchronization、Consistency
前沿技术 如何继续提升规模、效率和表现? Motion Matching、PCG、DOP、Job System、Lumen、Nanite

6.1 基础架构与数据组织

首先要理解引擎的分层结构、模块边界以及数据如何在系统间流动。架构和数据组织决定了后续功能能否扩展,也决定了性能问题是否容易定位。

6.2 渲染系统

重点不是孤立地学习某个图形学公式,而是理解工程上如何把以下对象串起来:

模型 / Mesh
    + 材质 / Material
    + 纹理 / Texture
    + Shader
    + 光照与阴影
    + 渲染管线
    → 最终画面

课程还会涉及天空、地形、后处理等更完整的场景表现问题。

6.3 动画系统

动画系统要处理美术制作的动画数据,并将其组织成运行时可以播放、混合和响应环境的角色动作。重点包括动画的基本概念、数据结构、处理管线和动画融合。

6.4 物理系统

物理系统负责让对象之间发生可控的碰撞、运动和交互。游戏中的物理不一定追求绝对精确,而是要在可信度、稳定性、可控性和性能之间取得平衡。

6.5 Gameplay 系统

渲染和物理让世界“存在”,Gameplay 让世界“好玩”。事件系统、脚本系统和图形化表达方式,帮助设计师定义角色行为、关卡规则和玩家反馈。

一个重要观点是:编程不等于手写脚本。用编辑器连接节点、配置数据、定义事件和规则,同样是在进行逻辑构建。

6.6 工具链与数据驱动

工具链是连接程序员、美术师和设计师的共同工作平台。反射系统可以把代码中的变量和函数暴露给编辑器;数据 Schema 则用正式结构描述数据,使资源、工具和运行时之间能够稳定协作。

6.7 在线游戏

联网游戏不仅是“把数据发给另一台机器”,还要解决:

  • 多个客户端的世界状态如何保持一致。
  • 网络延迟和丢包如何影响体验。
  • 哪一端负责决定结果。
  • 如何在带宽有限的条件下同步足够的信息。

课程会介绍锁步同步、状态同步和一致性等基础概念。

6.8 前沿方向

视频预告了若干现代引擎方向:

  • Motion Matching:从动作库中匹配更合适的动作,使角色运动更自然。
  • PCG(Procedural Content Generation):通过规则或算法自动生成游戏内容。
  • DOP / Data-Oriented Programming:围绕数据布局和访问模式组织代码,提高缓存和并行效率。
  • Job System:把工作拆成任务,利用多核 CPU 执行并管理依赖。
  • Lumen:虚幻引擎 5 中的动态全局光照方向。
  • Nanite:虚拟化几何和 GPU 驱动的高细节渲染方向。

这些内容建立在前面的架构、数据、渲染和性能基础之上。


7. 迷你引擎与实践路线

课程配套的实践不是单纯做一个画面效果,而是通过一个规模较小的引擎框架,逐步理解:

  • 运行时如何启动和更新。
  • 数据和资源如何组织。
  • 基础系统如何协同。
  • 编辑器如何修改世界。
  • 内容如何从创作工具进入运行时。

建议按以下顺序实践:

  1. 先让最小运行时启动,并确认主循环可以稳定运行。
  2. 找到一帧中的输入、更新、渲染和呈现路径。
  3. 增加最小对象、资源和场景数据。
  4. 逐步加入渲染、动画、物理和玩法系统。
  5. 再考虑编辑器、脚本、网络和性能优化。

实践时应优先理解模块之间的关系,而不是一开始追求复杂效果。


8. 本讲最重要的工程认识

8.1 引擎是平台,不是效果集合

一个漂亮的 Demo 只能证明某个功能可行;一个可用的引擎还必须解决资源管理、工具操作、数据兼容、性能预算、调试、协作和持续升级。

8.2 实时性是第一约束

所有系统都必须在有限帧时间内完成工作。算法的理论精度、画面效果和系统复杂度,都必须服从目标平台的实时预算。

8.3 生产力决定引擎的实际价值

引擎的用户是整个内容团队。只有把底层技术转化为可理解的工具、接口和数据流程,技术才真正转化为生产力。

8.4 架构的核心是管理复杂性

分层、模块化、数据驱动、平台抽象、工具链和任务系统,都是为了让系统在变大之后仍然可以理解、修改和运行。

8.5 先建立知识地图,再深入局部

学习引擎时,不要一开始就被某个 API 或某个 Shader 细节困住。先知道它属于哪一层、解决什么问题、和哪些系统交换数据,再逐步深入。


9. 复习用速记

游戏引擎 = 虚拟世界底座 + 创作生产力工具 + 复杂系统工程

历史:专用游戏代码
    → 可复用技术抽离
    → 3D 硬件推动实时世界
    → 通用引擎、内部引擎、中间件生态

核心约束:有限 CPU/GPU/内存/带宽 + 严格帧时间预算

核心用户:程序员、美术师、设计师

读引擎入口:主循环 / Update / Tick

课程主干:
架构与数据 → 渲染 → 动画 → 物理 → Gameplay
→ 工具链与网络 → 数据导向、任务系统及其他前沿技术

10. 自测题

  1. 为什么说游戏引擎不只是渲染器?请至少列出四个非渲染系统。
  2. 早期游戏代码与现代游戏引擎的根本差别是什么?
  3. 60 FPS 时一帧大约有多少时间?这段时间会被哪些工作共同消耗?
  4. 商业引擎、自研引擎和中间件分别解决什么问题?
  5. 为什么引擎需要同时服务程序员、美术师和设计师?
  6. 你打开一个陌生引擎时,为什么可以先找 Update、Tick 或主循环?
  7. “把模拟世界变成可玩的游戏”主要对应哪些 Gameplay 能力?
  8. 反射和数据 Schema 为什么能帮助编辑器与运行时协作?
  9. 如果一个新功能导致帧率下降,你会从哪些资源和阶段检查问题?
  10. 用自己的话解释“引擎是复杂性的艺术”。

11. 术语表

术语 含义
Runtime 游戏运行时,负责加载内容、更新世界并输出结果
Editor 编辑器,用于创建和修改场景、资源、规则和参数
Toolchain 工具链,连接内容制作、数据转换、调试和发布流程
DCC Digital Content Creation,数字内容创建工具,如建模和动画软件
Middleware 中间件,为引擎提供某一类专门能力的可复用软件
Reflection 反射,让程序结构、变量或函数能够被工具和编辑器发现、读取或调用
Data Schema 数据 Schema,对数据结构、字段和约束的正式描述
Lockstep Synchronization 锁步同步,各端按相同输入或步骤推进模拟
State Synchronization 状态同步,传输世界或对象的状态,使各端逐步接近一致
PCG 程序化内容生成
DOP 面向数据编程,围绕数据布局和访问组织系统
Job System 任务系统,把工作拆分为可调度任务并利用多核执行
Lumen 虚幻引擎 5 的动态全局光照技术方向
Nanite 虚拟化几何和 GPU 驱动几何管线技术方向

12. 参考资料