《游戏引擎原理与实践·卷1》权威学习地图

按2020年人民邮电出版社版本140个目录节点建立从基本系统到模型与LOD的完整基础框架路线。逐项覆盖13个权威目录坐标，并用对象、资源、场景和预算实验复核。

为什么基础框架要从状态和证据开始

《游戏引擎原理与实践·卷1》权威学习地图承担 按2020年人民邮电出版社版本140个目录节点建立从基本系统到模型与LOD的完整基础框架路线。 本课程不复制原书正文、插图或配套代码，而把目录中的示例引擎机制重构为状态合同、可运行实验、故障样本与验收工件。本页逐项覆盖13个目录坐标：第1章引擎的纷争、第2章起航、第3章基本系统、第4章基本数据结构、第5章数学库、第6章初始化与销毁、第7章应用程序框架、第8章对象系统、第9章资源管理、第10章引擎的设计哲学、第11章场景管理、第12章模型与贴图、第13章 LOD。

引擎基础框架不是模块名称集合。内存分配器决定对象能否安全创建，反射决定对象如何进入工具与存储，资源代理决定异步内容能否稳定引用，场景结构决定每帧查询规模，LOD又把视觉误差换成时间和带宽。任何一层缺少身份、生命周期或失败语义，问题都会在更高层以随机崩溃、错误画面或帧抖动出现。

版次、目录与改编合同

本路径采用程东哲《游戏引擎原理与实践（卷1）：基础框架》，人民邮电出版社，2020年2月，ISBN 9787115518071。授权电子书目录列出版权信息、内容提要、推荐序、前言、资源与支持、13章及各级小节、练习和示例，共140个正式目录节点。课程按“书前资料 + 13章”组成14个正式单元，另设学习地图与全书复核，共16页。

示例中的 VSSystem、Unreal Engine 3/4、OpenGL 和 DirectX 属于原书出版时的工程语境。课程保留其架构问题与目录位置，但当前项目应以现行SDK和官方文档校正接口；历史实现不能直接推出今天的性能、平台支持或最佳实践。

五个贯穿本卷的工程术语

、、、、。

对象身份把反射、序列化、克隆与复制串在一起；资源代理让对象不直接依赖加载地址；场景节点把空间与生命周期组织起来；屏幕误差则给LOD一个可测目标。属性反射必须和版本迁移、权限、编辑事务一起设计，不能只做“根据字符串找字段”。

四个可复算指标

端到端帧时间保留CPU/GPU重叠与等待：

T_{frame} = max(T_{update}, T_{render}) + T_{wait}

按对齐要求申请内存后的实际尺寸为：

A(n,a) = lceil n/a ceil a

资源缓存命中率必须按真实请求计算：

H = N_{hit} / N_{request}

LOD用投影误差连接世界误差、焦距、距离与屏幕高度：

e_{screen} = e_{world} f / (z h)

帧时间要报告P50、P95和P99；内存要报告峰值、碎片和生命周期；命中率要区分预热与冷启动；LOD还要观察切换抖动、轮廓破坏和纹理带宽。公式只建立可复算口径，不替代目标设备上的视觉与性能验收。

权威目录逐节坐标

第1章引擎的纷争

目录节点 1/13。 从定义、历史选择和游戏边界回答为什么需要引擎以及何时应自研。

落实“第1章引擎的纷争”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察目录完整：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

本节点至少保存一次正常运行、一次压力运行和一次故障注入。记录构建版本、平台、对象或资源ID、调用阶段、分配变化、耗时分位数与最终状态；当优化改变画质、精度、编辑体验或可移植性时，必须把这些代价与速度收益一起报告。

第2章起航

目录节点 2/13。 起航章建立编程、编辑器、数学、空间、图形API、汇编与生产工作流的全景入口。

落实“第2章起航”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察生命周期：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

第3章基本系统

目录节点 3/13。 基本系统用可复现工程、内存抽象与类型判断构成全部上层代码的最低运行地基。

落实“第3章基本系统”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察对象身份：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

第4章基本数据结构

目录节点 4/13。 数据结构章从示例引擎容器基类扩展到常用结构与委托通信，强调访问模式决定选择。

落实“第4章基本数据结构”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察空间组织：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

第5章数学库

目录节点 5/13。 数学库用稳定数值约定、空间类型与几何单元连接引擎全部运行时系统。

落实“第5章数学库”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察画质预算：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

第6章初始化与销毁

目录节点 6/13。 初始化与销毁章把系统依赖转成可执行的启动DAG和严格逆序回收。

落实“第6章初始化与销毁”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察目录完整：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

第7章应用程序框架

目录节点 7/13。 应用程序框架把平台事件、主循环和逻辑输入映射成可移植的程序骨架。

落实“第7章应用程序框架”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察生命周期：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

第8章对象系统

目录节点 8/13。 对象系统用身份、反射、序列化、克隆、编辑绑定和复制建立数据驱动引擎的核心元模型。

落实“第8章对象系统”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察对象身份：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

第9章资源管理

目录节点 9/13。 资源管理把外部资产转换为有类型、有身份、有依赖且受预算约束的运行时对象。

落实“第9章资源管理”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察空间组织：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

第10章引擎的设计哲学

目录节点 10/13。 设计哲学章从世界关系和分层推导对象图垃圾回收，而不是把GC当孤立算法。

落实“第10章引擎的设计哲学”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察画质预算：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

第11章场景管理

目录节点 11/13。 场景管理用层级变换、空间索引、相机裁剪、对象动态性和光源影响控制世界查询成本。

落实“第11章场景管理”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察目录完整：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

第12章模型与贴图

目录节点 12/13。 模型与贴图章把DCC内容转换成坐标正确、布局高效、材质完整且可流送的运行时资源。

落实“第12章模型与贴图”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察生命周期：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

第13章 LOD

目录节点 13/13。 LOD章用离散或连续复杂度控制模型与地形的屏幕误差、切换稳定性和资源预算。

落实“第13章 LOD”时，先写输入、输出、所有者、状态、线程和失败回收，再沿“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”执行。重点观察对象身份：如果只展示正常截图，却没有边界值、资源身份、内存与帧轨迹，就无法判断实现是否符合本节机制。

最小实现骨架

struct EngineRecord {
    uint64_t objectId;
    uint64_t resourceId;
    uint32_t generation;
    enum class State { Loading, Ready, Failed, Retired } state;
    double updateMs;
    double renderMs;
};
 
bool valid(const EngineRecord& value, uint32_t expectedGeneration) {
    return value.generation == expectedGeneration &&
           value.state == EngineRecord::State::Ready;
}

type FrameSample = {
  objects: number;
  cacheHits: number;
  requests: number;
  updateMs: number;
  renderMs: number;
  waitMs: number;
};
 
const frameTime = (s: FrameSample) =>
  Math.max(s.updateMs, s.renderMs) + s.waitMs;

{
  "unit": "gep1-official-learning-map",
  "edition": "ptpress-2020-volume-1",
  "target": "record-device-and-build",
  "evidence": ["object-graph", "resource-trace", "frame-capture"]
}

实现迁移到其他引擎时可以更换类型名和API，但必须保留对象身份、代际、资源身份、状态、更新时间和渲染时间。只有这些字段稳定，序列化、热重载、场景查询和LOD决策才能在同一证据链上复核。

本单元的验收工件

第一件工件是边界图：把“核定140个节点、搭建底层系统、建立对象资源、组织场景资产、验证LOD输出”画成有向图，逐边标出数据、所有者、状态、线程与失败返回。第二件是目标机轨迹：固定构建和输入，保存正常帧、尾延迟帧与故障帧中的对象、资源、分配和呈现事件。第三件是反例报告：主动破坏目录完整或空间组织，定位第一个不变量失效点，并证明修复后没有把成本转移到画质、编辑器或关闭阶段。

先预测再运行

运行交互前先预测：对象规模翻倍时更新还是渲染先越界；缓存命中下降时等待如何传到帧尾；LOD阈值收紧时画质与三角形数量怎样变化。若观察与预测不一致，优先检查异步队列、跨帧流水、预热状态和统计窗口。

本章回顾

《游戏引擎原理与实践·卷1》权威学习地图是“核定140个节点 → 搭建底层系统 → 建立对象资源 → 组织场景资产 → 验证LOD输出”中的基础框架合同。掌握本页意味着能逐项定位13个权威目录节点，解释目录完整、生命周期、对象身份、空间组织、画质预算的适用边界，复算时间、内存、资源与LOD指标，并用正常、压力和故障轨迹让结论可迁移。

术语复核

阅读导航

下一页：书前资料：版权、提要、推荐序、前言与资源

《游戏引擎原理与实践·卷1》权威学习地图

为什么基础框架要从状态和证据开始

版次、目录与改编合同

五个贯穿本卷的工程术语

四个可复算指标

权威目录逐节坐标

第1章 引擎的纷争

第2章 起航

第3章 基本系统

第4章 基本数据结构

第5章 数学库

第6章 初始化与销毁

第7章 应用程序框架

第8章 对象系统

第9章 资源管理

第10章 引擎的设计哲学

第11章 场景管理

第12章 模型与贴图