第1章：引言 — 零基础讲义

讲义说明
本讲义基于 Jason Gregory 所著《Game Engine Architecture Volume I》第4版第1章（Introduction, p.1-57），逐节翻译推导，面向零基础读者。
本版插画由 ImageGen + Guizang 材质插画标准流程生成。

学习目标

1. 理解"游戏"和"游戏引擎"的概念边界
2. 知道不同类型的游戏需要不同技术侧重的引擎
3. 了解主流商业引擎（Unreal/Unity）和自研引擎的区别
4. 掌握引擎运行时架构的基本分层（Core Systems → Gameplay → Rendering → Platform）
5. 建立"工具链 = 引擎的一部分"的认知

1.1 什么是游戏？

图1-1：游戏定义三要素（Guizang流程生成）

1.1.1 游戏的学术定义

1.1.1.1 四个必备要素

Gregory 引用游戏学者 Jesse Schell 的定义，一款"游戏"必须同时具备以下四个要素：

1.1.1.2 四要素之间的关系

技术是底层基础：没有技术，机制无法执行，故事无法呈现，美学无法渲染。但技术服务于设计——优秀的引擎隐藏技术的复杂性，让设计师和艺术家专注于机制、故事和美学。

1.1.2 电子游戏的独特性

1.1.2.1 互动性（Interactivity）

电子游戏区别于小说和电影的核心特征是互动性：玩家的输入实时改变虚拟世界的状态。电影是"观看"，游戏是"参与"。

1.1.2.2 实时性（Real-Time）

游戏必须每一帧（通常 16.7ms）完成输入处理→状态更新→画面渲染。任何一个环节超过时间预算就会导致丢帧。

1.1.3 游戏的组成模型

1-1-3-1 对象模型（Object Model）

游戏世界被抽象为一组游戏对象（Game Objects）。每个对象有属性和行为：

• 代理型（Agent-based）： 世界中有多个独立的实体相互交互——敌人、队友、NPC（Non-Player Character，非玩家角色）、道具
• 属性： 位置、旋转、缩放、生命值、速度
• 行为： AI 决策、物理碰撞、动画播放

1-1-3-2 组件模型（Component Model）

单个游戏对象 不是一个"巨大的类"，而是由多个小组件拼起来的。一个敌人可能由这些组件组成：Transform + MeshRenderer + Collider + AIComponent + HealthComponent + AnimationComponent。

// 组件模型的表示（伪代码）
class Enemy {
    TransformComponent transform;
    MeshComponent       mesh;
    ColliderComponent   collider;
    HealthComponent     health;    // HP = 100
    AIComponent         ai;        // 行为：巡逻/追击/攻击
    AnimationComponent  anim;      // 播放走路/跑步/攻击动画
}
// 每个组件独立运作，通过消息（Event）互相通信
// 比如：collider 检测到子弹 → 发消息给 health → health 减少 HP

1.2 什么是游戏引擎？

图1-2：引擎可复用性光谱（Guizang流程生成）

1.2.1 游戏引擎的定义

1.2.1.1 一个实用定义

Gregory 给出的定义："游戏引擎是一套可扩展的软件框架，它提供游戏开发所需的核心功能，并允许开发者在此基础上构建特定的游戏内容。"

1.2.1.2 引擎 vs 游戏的边界

这条边界是模糊的——同一个代码模块在不同语境下可能属于"引擎"或"游戏"。一般来说：

• 引擎层： 可复用的通用功能（渲染、物理、音频、输入、文件系统）
• 游戏层： 特定于当前游戏的数据和逻辑（角色技能、关卡布局、对话树）

1.2.2 引擎的可复用性光谱

1.2.2.1 从专用到通用的五级光谱

1.2.2.2 为什么自研引擎还存在？

尽管 Unreal 和 Unity 几乎"能做什么游戏"，自研引擎仍有一席之地：

• 完全控制： 不需要等待 Epic/Unity 修 bug
• 极致优化： 针对特定游戏类型深度优化（如 id Tech 针对 FPS）
• 无授权费： 大厂每年省下数百万美元引擎授权费
• 技术壁垒： 自研引擎本身是竞争优势

1.2.3 引擎的典型边界

1.2.3.1 引擎通常包含什么

• 渲染器（Renderer）——把 3D 数据变成屏幕上的像素
• 物理引擎（Physics）——碰撞检测、刚体动力学
• 音频引擎（Audio）——3D 空间声、混响、动态混合
• 动画系统（Animation）——骨骼动画、动作混合、IK
• AI 系统（AI）——寻路、行为树、感知
• 输入系统（Input）——键盘/鼠标/手柄→游戏动作
• 资源管理（Resource Manager）——加载/卸载/引用计数
• 工具管线（Tool Pipeline）——编辑器、资产导入/导出

1.2.3.2 引擎通常不包含什么

• 具体游戏逻辑（角色技能、关卡目标、数值平衡）
• 具体游戏资源（模型、纹理、音频文件、关卡数据）
• 游戏设计决策（虽然引擎提供基础，但设计是团队的工作）

1.3 各类型游戏的引擎差异

生活类比： 不同类型的游戏就像不同的运动——篮球鞋和跑鞋都是"鞋"，但篮球鞋强调侧向支撑（横向急停），跑鞋强调缓震（纵向冲击）。同理，FPS 引擎和 RTS 引擎都是"引擎"，但技术侧重点完全不同。

图1-3：六种主流游戏类型的技术关注点对比（Guizang流程生成）

1.3.1 不同类型的技术侧重点

1.3.1.1 第一人称射击（FPS）

1.3.1.2 第三人称动作冒险（如战神、刺客信条）

1.3.1.3 大型多人在线（MMO）

1.3.1.4 即时策略（RTS）

1.3.1.5 体育/竞速游戏

1.3.1.6 格斗游戏

1.3.2 室内 vs 室外引擎的技术取舍

1.3.2.1 两种根本不同的渲染策略

Gregory 用一个经典对比说明：同一个引擎不能同时最优处理室内和室外：

1.3.2.2 混合场景的挑战

现代 3A 游戏几乎都是混合场景——既有室内（地牢/建筑内）也有室外（开放世界）。处理这种过渡是现代引擎的重大挑战。Unreal 5 的 Nanite（虚拟化几何体）部分解决了这个问题——几何复杂度不再限制引擎选择。

1.3.3 VR/AR/MR 的特殊要求

1.3.3.1 VR（虚拟现实）的极端要求

• 极高帧率： 最低 72fps，推荐 90fps+（每帧 11ms）
• 极低延迟： "头部旋转→画面更新"必须 < 20ms，否则玩家会晕
• 立体渲染： 每帧渲染两个画面（左右眼），GPU 负载翻倍
• 追踪系统： 6DOF 头部+手柄追踪精度要求毫米级
• TimeWarp/SpaceWarp： 在帧渲染完成后根据最新头部姿态扭曲画面，将感知延迟降到 1ms

1.3.3.2 AR/MR 的额外挑战

AR（Augmented Reality，增强现实）和 MR（Mixed Reality，混合现实）还需要：实时环境理解（平面检测、深度感知）、虚拟物体与真实环境的光照一致性。

1.4 游戏引擎生态

1.4.1 主流商业引擎

1.4.1.1 Unreal Engine（Epic Games）

• 语言： C++（引擎核心）+ Blueprint（可视化脚本）
• 授权模式： 收入超过100万美元后收取5%版税
• 强项： 顶级画质、开放世界、Nanite/Lumen、完整工具链
• 知名作品： 堡垒之夜、黑神话：悟空、最终幻想7重制版

1.4.1.2 Unity（Unity Technologies）

• 语言： C#（游戏逻辑）+ C++（引擎底层）
• 授权模式： 多级订阅制（个人免费/Pro/Enterprise）
• 强项： 跨平台极其广泛（25+平台）、上手快、2D 支持出色
• 知名作品： 原神、空洞骑士、Cities: Skylines

1.4.1.3 Godot（开源）

• 语言： GDScript（类Python）+ C# + C++
• 授权模式： 完全免费开源（MIT License）
• 强项： 轻量、零授权费、社区驱动

1.4.2 大厂自研引擎

• EA Frostbite： 战地系列、FIFA（已停产自研部分）
• Capcom RE Engine： 生化危机、怪物猎人
• CD Projekt REDengine： 巫师3、赛博朋克2077（已转向UE5）
• Rockstar RAGE： GTA V、荒野大镖客2
• id Tech： DOOM Eternal（FPS 优化极致）

1.4.3 选择引擎的核心因素

1.4.3.1 六个关键决策维度

1.5 引擎运行时架构

1.5.1 引擎的分层结构

1.5.1.1 经典五层架构（自底向上）

1.5.1.2 层间依赖规则

严格从上到下依赖：游戏层依赖功能层，功能层依赖核心系统，核心系统依赖平台层。绝不允许反向依赖——渲染器不应该知道"玩家"的存在。

1.5.2 各子系统详解

1.5.2.1 渲染器（Renderer）

将 3D 场景转化为屏幕像素。涉及：视锥剔除、LOD 选择、绘制调用提交、着色器执行、后处理（抗锯齿/运动模糊/HDR）。这是引擎中代码量最大、性能要求最高的子系统。

1.5.2.2 物理引擎（Physics）

模拟真实世界中的碰撞和运动。包括：刚体动力学（F=ma）、碰撞检测（Broad Phase → Narrow Phase）、约束求解（关节/铰链/弹簧）、射线检测。常用方案：集成第三方物理库（PhysX/Havok/Bullet）。

1.5.2.3 音频引擎（Audio）

管理音效的播放、混合、空间化。包括：3D 定位（离声源距离→音量衰减）、环境效果（混响/遮挡）、动态混合（音乐+音效+语音的实时音量平衡）。常用方案：Wwise/FMOD。

1.5.2.4 前端/UI（Front-End）

用户界面系统：HUD（Heads-Up Display，平视显示器——血条/弹药/小地图）、菜单、过场动画、游戏状态管理（主菜单→加载→游戏中→暂停→结束）。

1.5.3 游戏循环（Game Loop）

1.5.3.1 主循环的基本结构

// 简化的游戏主循环
while (gameRunning) {
    ProcessInput();          // 1. 收集输入
    UpdateGameLogic(dt);     // 2. 更新游戏状态
    RenderFrame();           // 3. 渲染画面
    SwapBuffers();           // 4. 交换前后缓冲区（显示到屏幕）
}

1.5.3.2 帧率与时间步长

时间步长 dt（delta time）是"上一帧到这一帧过去了多少秒"，用来保证游戏速度与帧率解耦——60fps 和 30fps 时角色移动速度一样快。

// 使用 deltaTime 解耦帧率和游戏速度
void Update(float dt) {
    position += velocity * dt;         // 角色移动
    timer    -= dt;                    // 冷却倒计时
    animState += dt * animSpeed;       // 动画进度
}
// 这样：无论 dt=0.016（60fps）还是 dt=0.033（30fps）——角色每秒移动的速度都是一样的

1.6 工具与资产管线

1.6.1 工具链 = 引擎的重要组成

1.6.1.1 Gregory 的核心观点

引擎不是只有运行时代码。一套完整的游戏引擎至少包含：

• 运行时（Runtime）： 玩家机器上运行的可执行文件
• 工具（Tools）： 编辑器、资产导入器、构建工具
• 管线（Pipeline）： 资产从 DCC（Digital Content Creation，数字内容创作工具，如 Maya/Blender/Photoshop）到引擎的完整流程

1.6.1.2 资产管线流程图

// 典型 3D 模型资产管线
Maya/Blender 导出 .fbx
    ↓
引擎的 Asset Importer 解析 .fbx
    ↓
Cook/Build 处理（压缩、LOD 生成、碰撞体生成）
    ↓
运行时加载为 GameObject（含 Mesh + Material + Collider）

1.6.2 典型开发工具

1.6.2.1 关卡编辑器（Level Editor）

这是设计师最常使用的工具。允许拖拽放置模型、调整光照、绘制地形、设置触发区域。"做游戏"的过程在相当程度上就是"在编辑器里摆关卡"的过程。

1.6.2.2 资产浏览器（Asset Browser）

管理游戏中的所有数字资产：纹理、模型、音频、动画、字体。支持搜索、标签、缩略图预览、依赖关系查看。

1.6.2.3 脚本编辑器

允许设计师编写游戏逻辑（如 Blueprint、Lua）。可视化脚本（Blueprint）极大地降低了编程门槛——拖线连接节点就能实现逻辑。

1.6.2.4 Profiler & 调试工具

引擎内置的性能分析和调试工具。见第10章的详细讲解。

1.7 全章总结

这一章建立了游戏引擎的宏观概念地图：

1. 游戏 = 机制+故事+美学+技术，技术是底层支撑
2. 游戏引擎是可复用的软件框架，边界在"通用能力"和"特定逻辑"之间
3. 不同类型游戏需要不同的技术侧重点（"没有万能引擎"是原书核心观点之一）
4. 主流选择：商业引擎（UE/Unity）降本增效，自研引擎提供极致控制权
5. 引擎分层架构（平台→核心→资源→功能→游戏）是设计和理解引擎的基石
6. 工具链不是引擎的附属品——它就是引擎的一部分

本章核心洞察

📝 课后练习题（含答案）

🤖 qAagent 零基础问答区