Games104学习笔记(1)
GAMES104:游戏引擎导论
课程:GAMES104《现代游戏引擎:从入门到实践》
讲次:Lecture 01 / Overview of Game Engine
讲者:王希(Xi Wang,Booming Tech)
视频时长:约 75 分 48 秒
笔记性质:根据本地视频中的幻灯片与讲解主题整理,不是逐字稿;时间点为复习定位用的近似值。
一句话理解
游戏引擎不是“负责把模型画出来的一套代码”,而是一个在有限算力和严格实时约束下,帮助团队构建、编辑、运行、调试和持续迭代虚拟世界的技术底座与生产力平台。
可以把游戏引擎理解为三者的结合:
- 构建虚拟世界的底层框架:提供世界状态、规则、模拟和表现的公共基础。
- 创作工具:让程序员、美术师、设计师能够共同生产内容。
- 复杂性的艺术:在性能、画质、可扩展性、稳定性和开发效率之间做工程取舍。
本讲学习目标
- 了解游戏引擎为什么值得系统学习,以及它已经扩展到哪些领域。
- 梳理游戏引擎从“单个游戏的专用代码”到“通用开发平台”的演化过程。
- 建立对引擎组成的整体认识:运行时、工具链、资源、功能系统和平台抽象。
- 理解实时计算中的核心矛盾:想模拟一个复杂世界,但每一帧只有有限时间和资源。
- 掌握后续课程的主干路线,知道阅读一个陌生引擎时应该从哪里开始。
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 或类似入口,然后顺着一帧的执行过程追踪:
- 输入在哪里被采集?
- 时间步长
delta time如何产生和传递? - 游戏对象和系统何时更新?
- 动画、物理、AI 与玩法逻辑如何协作?
- 资源何时加载、缓存和释放?
- 渲染数据如何准备并提交给 GPU?
- 一帧何时结束,下一帧如何开始?
从 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. 迷你引擎与实践路线
课程配套的实践不是单纯做一个画面效果,而是通过一个规模较小的引擎框架,逐步理解:
- 运行时如何启动和更新。
- 数据和资源如何组织。
- 基础系统如何协同。
- 编辑器如何修改世界。
- 内容如何从创作工具进入运行时。
建议按以下顺序实践:
- 先让最小运行时启动,并确认主循环可以稳定运行。
- 找到一帧中的输入、更新、渲染和呈现路径。
- 增加最小对象、资源和场景数据。
- 逐步加入渲染、动画、物理和玩法系统。
- 再考虑编辑器、脚本、网络和性能优化。
实践时应优先理解模块之间的关系,而不是一开始追求复杂效果。
8. 本讲最重要的工程认识
8.1 引擎是平台,不是效果集合
一个漂亮的 Demo 只能证明某个功能可行;一个可用的引擎还必须解决资源管理、工具操作、数据兼容、性能预算、调试、协作和持续升级。
8.2 实时性是第一约束
所有系统都必须在有限帧时间内完成工作。算法的理论精度、画面效果和系统复杂度,都必须服从目标平台的实时预算。
8.3 生产力决定引擎的实际价值
引擎的用户是整个内容团队。只有把底层技术转化为可理解的工具、接口和数据流程,技术才真正转化为生产力。
8.4 架构的核心是管理复杂性
分层、模块化、数据驱动、平台抽象、工具链和任务系统,都是为了让系统在变大之后仍然可以理解、修改和运行。
8.5 先建立知识地图,再深入局部
学习引擎时,不要一开始就被某个 API 或某个 Shader 细节困住。先知道它属于哪一层、解决什么问题、和哪些系统交换数据,再逐步深入。
9. 复习用速记
游戏引擎 = 虚拟世界底座 + 创作生产力工具 + 复杂系统工程
历史:专用游戏代码
→ 可复用技术抽离
→ 3D 硬件推动实时世界
→ 通用引擎、内部引擎、中间件生态
核心约束:有限 CPU/GPU/内存/带宽 + 严格帧时间预算
核心用户:程序员、美术师、设计师
读引擎入口:主循环 / Update / Tick
课程主干:
架构与数据 → 渲染 → 动画 → 物理 → Gameplay
→ 工具链与网络 → 数据导向、任务系统及其他前沿技术
10. 自测题
- 为什么说游戏引擎不只是渲染器?请至少列出四个非渲染系统。
- 早期游戏代码与现代游戏引擎的根本差别是什么?
- 60 FPS 时一帧大约有多少时间?这段时间会被哪些工作共同消耗?
- 商业引擎、自研引擎和中间件分别解决什么问题?
- 为什么引擎需要同时服务程序员、美术师和设计师?
- 你打开一个陌生引擎时,为什么可以先找
Update、Tick或主循环? - “把模拟世界变成可玩的游戏”主要对应哪些 Gameplay 能力?
- 反射和数据 Schema 为什么能帮助编辑器与运行时协作?
- 如果一个新功能导致帧率下降,你会从哪些资源和阶段检查问题?
- 用自己的话解释“引擎是复杂性的艺术”。
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. 参考资料
- GAMES104 官方课程主页
- GAMES104 官方课程 PPT 与视频页面
- 推荐阅读:Jason Gregory,《Game Engine Architecture / 游戏引擎架构》