《游戏引擎架构》阅读笔记-第1章 导论

• 本系列博客为《游戏引擎架构》一书的阅读笔记，旨在精炼相关内容知识点，记录笔记，以及根据目前（2022年）的行业技术制作相关补充总结。
• 本书籍无硬性阅读门槛，但推荐拥有一定线性代数，高等数学以及编程基础，最好为制作过完整的小型游戏demo再来阅读。
• 本系列博客会记录知识点在书中出现的具体位置。并约定（Pa b），其中a为书籍中的页数，b为从上往下数的段落号，如有lastb字样则为从下往上数第b段。
• 本系列博客会约定用【】来区别本人所书写的与书中观点不一致或者未提及的观点，该部分观点受限于个人以及当前时代的视角所限，请谨慎阅读。
• 再次重申，请支持正版。

目录

• 笔记前言
• 目录
• 第1章 导论
  • 1.1 典型游戏团队的结构
  • 1.2 游戏是什么
  • 1.3 游戏引擎是什么
  • 1.4 不同游戏类型中的引擎差异
  • 1.5 游戏引擎概观
  • 1.6 运行时引擎架构【重点中的重点】
  • 1.7 工具及资产管道

笔记前言

• 本人目前学习方式分为两种。第一种为工作以及实践中遇到问题去专项学习，解决问题；另一种为提纲掣领，主动学习未来所必学之内容。《游戏引擎架构》一书的学习则为第二种。
• 私以为，如若制作游戏仅为个人兴趣，该书可以不用花费心思阅读。但若想精进技术，夯实基础，则需至少通读各类基础底层原理书籍，从总纲基础入手，进而再细化学习进阶内容。
• 本书虽然为引擎架构，但实则是为游戏中各类问题提供整体性解决方案，让读者能够从底层入手，从全局角度考虑，如何切实解决游戏开发中遇到的种种困难，同时主动培养系统性解决方案的思维和能力。
• 学习编程切勿纸上谈兵，正如书中序言所说“游戏科技是一个活生生、会呼吸的家伙，永远不可能将之束缚于书本之上。”

目录

• 第一部分：基础 第1章 导论 第2章 专业工具 第3章 游戏软件工程基础 第4章 游戏所需的三维数学
• 第二部分：低阶引擎系统 第5章 游戏支持系统 第6章 资源及文件系统 第7章 游戏循环及实时模拟 第8章 人体学接口设备（HID） 第9章 调试及开发工具
• 第三部分：图形及动画 第10章 渲染引擎 第11章 动画系统 第12章 碰撞及刚体动力学
• 第四部分：游戏性 第13章 游戏性系统简介 第14章 运行时游戏性基础系统
• 第五部分：总结 第15章 还有更多内容吗？

第1章 导论

• 虽然市面引擎结构和实现细节千差万别，但几乎所有的游戏引擎都含有一组常见的核心组件，例如渲染引擎、碰撞及物理引擎、动画系统、音频系统、游戏世界对象模型、人工智能系统等。而这些组件内也开始显现一些半标准的设计方案。（P3 1）
• 从本书中读者能学习到以下内容：1、如何架构工业级生产用游戏引擎。 2、现实中的游戏开发团队怎样组织及运作。 3、有哪些主要子系统及设计模式不断出现在几乎所有游戏引擎里。每个主要子系统的典型需求。 4、有哪些子系统与游戏类型或具体游戏无关，有哪些子系统是为某游戏类型或具体游戏而设计的。 5、引擎和游戏的边界位于何处。
• 大规模软件工程中的一些技巧及工具：1、逻辑软件架构和物理软件架构的区别。 2、配置管理(configuration management)、版本控制(revision control）及生成系统( build system)。 3、最常用的C/C 开发环境——微软Visual Studio——的窍门及技巧。

1.1 典型游戏团队的结构

• 典型游戏团队的人员配置。游戏工作室(game studio）通常由5个基本专业领域的人员构成，包括工程师(engineer)、艺术家( artist)、游戏设计师(game designer)、制作人( producer）及其他管理/支持人员（市场策划、法律、信息科技/技术支持、行政等)。每个专业领域可细分为多个分支。
• 工程师（程序员）：分为两类运行时程序员（runtime programmer)和工具程序员(tool programmer)。运行时程序员制作引擎和游戏本身;工具程序员制作离线工具，供整个团队使用，以提高团队的工作效率。运行时/工具两方面的工程师都各有专长。有些工程师在职业生涯里专注单一的引擎系统，诸如渲染、人工智能、音效或碰撞/物理;有些工程师专注于游戏性( gameplay)和脚本编程(scripting);也有一些工程师喜欢系统层面的开发，而不太关心游戏实际上怎么玩；还有些工程师是通才(generalist），博学多才，能应付开发中不同的问题。（P4 1） 资深工程师有时候会被赋予技术领导的角色。比如，首席工程师(（lead engineer）通常仍会设计及编写代码，但同时协助管理团队的时间表，并决定项目的整体技术方向。从人力资源的角度来说，首席工程师有时候也会直接管理下属。 有些公司设有一位或多位技术总监(technical director，TD)，负责从较高层面监督一个或多个项目，确保团队能注意到潜在的技术难点、业界走势、新技术等。某些工作室可能还有一个和工程相关的最高职位，这就是首席技术官（chief technical officer，CTO)。CTO类似整个工作室的技术总监，并履行公司的重要行政职务。
• 艺术家：（P5 3） 概念艺术家(concept artist）通过素描或绘画，让团队了解游戏的预设最终面貌。概念艺术家的工作始于游戏开发的概念阶段，一般会在项目的整个生命周期里继续担任美术指导。游戏成品的屏幕截图常会不可思议地贴近概念艺术图（concept art）。 三维建模师（3D modeler）为游戏世界的所有事物制作三维几何模型。这类人员通常会再细分为两类:前景建模师（foreground modeler）及背景建模师(backgroundmodeler)。前景建模师负责制作物体、角色、载具、武器及其他游戏中的对象，而背景建模师则制作静态的背景几何模型（如地形、建筑物、桥梁等)。 纹理艺术家(texture artist）制作称为纹理(texture）的二维影像。这些纹理用来贴附于三维模型之上，以增加模型的细节及真实感。 灯光师(lighting artist）布置游戏世界的静态和动态光源，并通过颜色、亮度、光源方向等设定，加强每个场景的美感及情感。 动画师(（animator）为游戏中的角色及物体加入动作。如同动画电影制作，在游戏制作过程中，动画师充当演员。但是，游戏动画师必须具有一些独特的技巧，以制作符合游戏引擎技术的动画。 动画捕捉演员(motion capture actor）提供一些原始的动作数据。这些数据经由动画师整理后，置于游戏中。 音效设计师(sound designer）与工程师紧密合作，制作并混合游戏中的音效及音乐。配音演员( voice actor）为游戏角色配音。 作曲家（composer）为游戏创作音乐。
• 游戏设计师（国内一般称为策划，而国外一般成为设计师->designer）：例如关卡、剧情、系统、战斗策划等，分别负责设计游戏的各个方向。
• 制作人：在不同的工作室里，制作人（producer)的角色不尽相同。有些游戏公司，制作人负责管理时间表，并同时承担人力资源经理的职责。有些游戏公司里，制作人主要做资深游戏设计师的工作。还有些游戏工作室，要求制作人作为开发团队和商业部门（财政、法律、市场策划等）之间的联系人。有些工作室甚至是完全没有制作人。例如在顽皮狗(NaughtyDog)公司，几乎所有员工，包括两位副总裁，都直接参与游戏制作，工作室的资深成员分担了团队管理工作及公司事务。（P6 last）
• 其他工作人员：游戏开发团队通常需要一支非常重要的支持团队，包括工作室的行政管理团队、市场策划团队（或一个与市场研究公司联系的团队)、行政人员及IT部门。IT部门负责为整个团队采购、安装及配置软硬件，并提供技术支持。（P7 2）
• 发行商及工作室：游戏的市场策划、制造及分销，通常由发行商( publisher）负责，而非开发游戏的工作室本身。发行商通常是大企业，例如艺电（Electronic Arts，EA)、THQ、维旺迪(Vivendi)、索尼(Sony)、任天堂(Nintendo）等。很多游戏工作室并不隶属于个别发行商。另外，第一方开发商(first-partydeveloper）是指游戏工作室直接隶属于游戏主机生产商（索尼、任天堂、微软)。例如，顽皮狗是索尼的第一方开发商。这些工作室独家为母公司的游戏硬件制作游戏。（P7 3）

1.2 游戏是什么

• 对于游戏的定义也可以参考《游戏的人》一书。
• 基于本书主旨，我们会集中讨论游戏的一个子集，子集里的游戏由二维或三维虚拟世界组成，并有少量的玩家(1~16个左右)。本书大部分的内容也可以应用到互联网上的Flash游戏、纯解谜游戏（如《俄罗斯方块（Tetris)》）或大型多人在线游戏(massivelymultiplayer online games，MMOG)。但我们主要集中讨论一些游戏引擎，这些游戏引擎可以用来开发第一人称射击、第三人称动作/平台游戏、赛车游戏、格斗游戏等。
• 大部分二维或三维的电子游戏，会被计算机科学家称为软实时(soft real-time）互动( interactive）基于代理（agent-based)计算机模拟(computer simulation）的例子。（P8 3）

1.3 游戏引擎是什么

• 游戏和其引擎的分界线是模糊的，数据驱动架构或许可以用以区分。若一个游戏包含硬编码逻辑或游戏种类的游戏对象，则复用该软件去制作新游戏就会变得困难甚至不可行。因此，这里说的“游戏引擎”是指可扩展的软件，而且不需要大量修改就能成为多款游戏软件的基础。（P10 3）
• 我们完全可以说，游戏引擎或中间件组件越通用，在特定平台运行特定游戏的性能就越一般。（P10 last）
• 【现如今（2022年）的游戏引擎可以说是在功能方面发展趋于完善，因此例如U3D，如果你需要制作什么类型的工具，那么就在引擎中加载该类型的相关工具即可达到基本的使用需求，如有更多需求则可以在引擎中书写代码来定制相关功能特性。以及再跨平台方面有IL2CPP的存在，也变得很方便，且对于出现新的平台也可以很快的做到基本的兼容】

1.4 不同游戏类型中的引擎差异

• 不同类型游戏引擎有差异也有重叠部分，譬如都会有低阶用户输入（例如手柄，键盘，鼠标），某形式的三维网格渲染，显示输出等。（P11 last2）
• 第一人称射击：FPS是开发技术难度极高的游戏类型之一。能与此相比的或许只有第三人称射击/动作/平台游戏，以及大型多人在线游戏。这是因为FPS要让玩家面对一个精细而超现实的世界时感到身历其境。FPS游戏常会注重技术，例如：1、高效地渲染大型三维虚拟世界 2、快速反应的摄像机控制及瞄准机制。玩家的虚拟手臂和武器的逼真动画。各式各样的手持武器。 3、宽容的玩家角色运动及碰撞模型，通常使游戏有种“漂浮”的感觉。非玩家角色（如玩家的敌人及同盟)有逼真的动画及智能。 4、小规模在线多人游戏的能力(通常支持多至同时64位玩家在线)，及无处不在的死亡竞赛(death match）游戏模式。（P12 1）
• 平台及其他第三人称游戏：主要的游戏机制是在平台之间跳跃。第三人称游戏和第一人称射击游戏有许多共通之处，但第三人称游戏比较看重主角的能力(ability）及运动模式(locomotion mode）。第三人称游戏特别注重的技术：1、移动平台、梯子、绳子、棚架及其他有趣的运动模式。用来解谜的环境元素。 2、第三人称的“跟踪摄像机”会一直注视玩家角色，也通常会让玩家用手柄右摇杆（在游戏主机上）或鼠标（在PC上）旋转摄像机（虽然在PC上有很多流行的第三人称射击游戏，但平台游戏类型几乎是游戏主机上独有的)。 3、复杂的摄像机碰撞系统，以保证视点不会穿过背景几何物体或动态的前景物体。（P13 last2）
• 格斗游戏：通常是两个玩家控制角色在一个擂台上互相对打。传统格斗类型游戏注重以下技术：1、丰富的格斗动画。 2、准确的攻击判定。 3、能侦测复杂按钮及摇杆组合的玩家输入系统。 4、人群，或相对静态的背景。（P15 last3）
• 竞速游戏：例如赛车等。典型竞速游戏有以下技术特性：1、使用多种“窍门”去渲染遥远的背景，例如使用二维纸板形式的树木、山岳和山脉。 2、赛道通常切开成较简单的二维区域，称为“分区(sector )”。这些数据结构用来实现渲染优化、可见性判断(visibility determination)，帮助非玩家操控车辆的人工智能及路径搜寻，以及解决很多其他技术问题。 3、第三人称视角摄像机通常追随在车辆背后，第一人称摄像机有时候会置于架驶舱里。 4、如果赛道经过天桥底及其他狭窄空间，必须花精力防止摄像机和背景几何物体碰撞。（P17 1）
• 实时策略游戏：RTS游戏的惯用手法如下：1、每个作战单元使用相对较低解析度的模型，使游戏能支持同时显示大量单元。 2、游戏的设计和进行多是在高度场地形（height field terrain）画面上展开的。 3、除了部署兵力，游戏通常准许玩家在地形上兴建新的建筑物。 4、用户互动方式通常为单击及以范围选取单元，再加上包含指令、装备、作战单元种类、建筑种类等的菜单及工具栏。（P18 last2）
• 大型多人在线游戏：注重与网络通信。（P20 1）
• 其他游戏类型：体育游戏、角色扮演游戏、上帝模拟游戏、环境或社会模拟游戏、解谜游戏、非电子游戏的移植（例如象棋）、基于网页的游戏，其他。（P21 last）
• 【随着时代不断发展，现如今有很多游戏都无法用其中一个类别来归纳总结，往往一个游戏会掺杂几种游戏类型（即以一种类型为主，再辅以其他类型的玩法模块），或者把一些体型较小的游戏完全嵌入到自己的游戏中，例如一些RPG游戏中的街机里面可以玩各种小游戏。】

1.5 游戏引擎概观

• 雷神之锤引擎家族（P22 2）
• 虚幻引擎（P23 3）
• Source引擎（P24 1）
• 微软XNA Game Studio（P24 2）
• 其他商业引擎（P24 last2）
• 专有内部引擎（P24 last）
• 开源引擎（P25 2）

1.6 运行时引擎架构【重点中的重点】

• 如同所有软件系统，游戏引擎也是以软件层(software layer）构建的。通常上层依赖下层，下层不依赖上层。当下层依赖上层时，称为循环依赖（circular dependency)。在任何软件系统中，循环依赖都要极力避免，不然会导致系统间复杂的耦合（coupling)，也会使软件难以测试，并妨碍代码重用。对于大型软件系统，如游戏引擎，此问题尤其重要。（P27 3）
• 【如果你已经做过一些游戏demo，使用过例如U3D或者虚幻这样的引擎那么你应该会对游戏引擎有一个初步的了解，如果没有那么再看下图可能会较为的困难，此时推荐先回去尝试用上述游戏引擎制作一款完整的小游戏并总结自己所用到的技术点，然后再来阅读】

运行时引擎架构（P26）

• 目标硬件：用来执行游戏的计算机系统或游戏主机。
• 设备驱动程序：由操作系统或硬件厂商提供的最低阶软件组件。驱动程序负责管理硬件资源，也隔离了操作系统及上层引擎，使上理解不同硬件版本的通信细节差异。
• 操作系统：【如对PC操作系统有不明白之处，请学习完操作系统课程再来阅读此书】 在游戏主机上，操作系统通常只是个轻量级的库，链接到游戏的执行档里。在游戏主机上，游戏通常“拥有”整台机器。可是，自从Xbox 360和PlayStation 3的出现，这一说法变得不太准确。例如，这些新主机的操作系统会中断游戏的执行，接管某些系统资源以显示在线信息，或容许玩家暂停游戏以进入PS3的跨界导航菜单(Xross Media Bar，XMB)或Xbox 360的Dashboard。所以（不管是好是坏）游戏机和PC开发的分野正慢慢收窄。
• 第三方软件开发包（SDK）和中间件：SDK提供基于函数或基于类的接口，一般称为应用程序接口（API），例如数据结构及算法，图形，碰撞和物理，角色动画，人工智能，生物力学角色模型等（P28 3）
• 平台独立层：大多数游戏引擎需要运行于不同的平台上，因此，大部分游戏引擎都架构有一个平台独立层在硬件、驱动程序、操作系统及其他第三方软件之上，以此把其余的引擎部分和大部分底层平台隔离。平台独立层包装了常用的标准C语言库、操作系统调用及其他基础API，确保包装了的接口在所有硬件平台上均为一致。这是必须的，因为不同平台间有不少差异，即使所谓的“标准”库，如标准C语言库，也有平台差异。（P31 last2）【平台差异确实造成了很多问题，例如指令集的不同，因此例如服务器验证工作就很高效进行】
• 核心系统：常见功能有：（P32 1） 1、断言（ assertion):断言是一种检查错误的代码。断言会插入代码中捕捉逻辑错误或找出与程序员原来假设不符的错误。在最后的生产版本中，一般会移除断言检查。 2、内存管理:几乎每个游戏引擎都有一个或多个自定义内存分配系统，以保证高速的内存分配及释放，并控制内存碎片所造成的负面影响（见5.2.1.4节)。 3、数学库:游戏本质上就是高度数学密集的。因此，每个游戏引擎都有一个或以上数学库，提供矢量（vector)、矩阵(matrix)、四元数(quaternion）旋转、三角学(trigonometry)、直线/光线/球体/平截头体（frustum）等的几何操作、样条线(spline）操作、数值积分(numerical integration)、解方程组，以及其他游戏程序员需要的功能。 4、自定义数据结构及算法:除非引擎设计者想完全依靠第三方软件包，如STL,否则引擎通常要提供一组工具去管理基础数据结构（链表、动态数组、二叉树、散列表等)，以及算法（搜寻、排序等)。这些数据结构及算法有时需要手工编码，以减少或完全消去动态内存分配，并保证在目标平台上的运行效率为最优。
• 资源管理：每个游戏引擎都有某种形式的资源管理器，提供一个或一组统一接口，去访问任何类型的游戏资产及其他引擎输入数据。有些引擎使用高度集中及一致的方式（例如虚幻的包( package)、OGRE的ResourceManager类)。其他引擎使用专案(ad hoc)）方法，比如让程序员直接读取文件，这些文件可能来自磁盘，也可能来自压缩文件（如雷神之锤引擎使用的PAK文件)。（P32 last）
• 渲染引擎：任何游戏引擎中，渲染引擎是最大及最复杂的组件之一。渲染器有很多不同的架构方式。虽然没有单一架构方式，但是大多数现在的渲染引擎都有些通用的基本设计哲学，这些哲学大部分是由底层三维图形硬件驱动形成的。 渲染引擎的设计通常采用分层架构（layered architecture)，以下会使用这行之有效的方法： 1、低阶渲染器（low-level renderer）包含引擎中全部原始的渲染功能。这一层的设计着重于高速渲染丰富的几何图元(geometric primitive）集合，并不太考虑那些场景部分是否可见。这组件可以分拆为几个子组件：①图形设备接口：使用图形SDK，如DirectX及OpenGL，都需要编写不少代码去枚举图形设备，初始化设备，建立渲染表面（如后台缓冲、模板/ stencil缓冲）等。这些工作通常由笔者称为图形设备接口(graphics device interface）的组件负责（然而各个引擎都有自己的术语)。②其他渲染器组件，低阶渲染层的其他组件一起工作，目的是要收集须提交的几何图元( geometric primi-tive，又称为渲染包/render packet）。几何图元包括所有要绘画之物，如网格( mesh)、线表(line list)、点表( point list)、粒子(particle)、地形块〈terrain patch)、字符串等。最后，把收集到的图元尽快渲染。低阶渲染器通常提供视区(viewport）抽象，每个视区结合了摄像机至世界矩阵( camera-to-world matrix)，三维投影参数如视野（nield of vlew) 、近远剪切平面（clipping plane）的位置等。低阶渲染器也便用材质系统（materal system）及动态光照系统(dynamic lighting system）去管理图形硬件的状态和游戏的着色器(shader)。每个已提交的图元都会关联到一个材质及被照射的n个动态光源。材质是描述当渲染图元时，该使用什么纹理(texture)，设置什么设备状态，并选择哪一对顶点着色器(vertex shader）和像素着色器（pixel shader)。光源则决定如何应用动态光照计算于图元上。光照和着色是个复杂的课题，计算机图形学有很多优质书籍深入探讨这个课题。 2、场景图/剔除优化：低阶渲染器绘画所有被提交的几何图形，不太考虑那些图形是否确实为可见（除了使用背面剔除（back-face culling）和摄像机平截头体的剪切平面)。一般需要较高层次的组件，才能基于某些可视性判别算法去限制提交的图元数量。非常小的游戏世界可能只需要简单的平截头体剔除(frustum cull）算法（即去除摄像机不能“看到”的物体)。比较大的游戏世界则可能需要较高阶的空间细分(spatial sub-division）数据结构，这种数据结构能快速判别潜在可见集(potentially visible set，PVS),令渲染更有效率。空间分割有多种形式，包括二元空间分割树(binary space partitioning,BSP tree）、四叉树（quadtree）、八叉树（octree)、kd树、包围球树（bounding sphere。空间分割有时候称为场景图(scene graph)，尽管技术上场景图是另一种数据结构，并不归入空间分割。此渲染引擎软件层也可应用入口(portal）及遮挡剔除（occlusionculling）等方法。 3、视觉效果：粒子系统（烟、火、水花等）、贴花系统（弹孔、脚印等）、光照贴图及环境贴图、动态阴影、全屏后期处理效果，在渲染三维场景至屏外缓冲后使用。 全屏后期处理效果：高动态范围（High Dynamic Range，HDR）光照及敷霜效果（bloom）、全屏抗锯齿（Full-Screen Anti-Aliasing，FSAA）、颜色矫正及颜色偏移效果，包括略过漂白、饱和度、去饱和度等。 4、前端：大多数游戏为了不同目的，都会使用一些二维图形去覆盖三维场景。目的包括：①游戏的平视显示器（Heads-Up Display，HUD） ②游戏内置菜单、主控台、其他开发工具（可能不会随最终产品一起发行)。③游戏内置图形用户界面(graphical user interface，GUI）让玩家操作角色装备配置战斗单元，或完成其他复杂的游戏任务。 前端二维图形通常会用附有纹理的四边形（一对三角形）集合正射投影来渲染。另一个方法是用完全三位的四边形公告板渲染，这些公告板能一直面向摄像机。 这一层也包含了全动视频(full-motion video，FMV)）系统，该系统负责播放之前录制的全屏幕电影（可以用游戏引擎录制，也可以用其他渲染软件录制)。 另一个相关的系统是游戏内置电影(in-game cinematics，IGC）系统，该组件可以在游戏本身以三维形式渲染电影情节。例如，玩家走在城市中，两个关键角色的对话可用IGC实现。IGC可能包括或不包括玩家角色。IGC可以故意暂停游戏，期间玩家不能控制角色;GC也可悄悄地整合在游戏过程中，玩家甚至不会发觉有IGC在运行。
• 剖析和调试工具：用于剖析游戏性能。通常包含一下功能： 1、手工插入测量代码，为某些代码计时。 2、在游戏进行期间，于屏幕上显示性能统计数据。把性能统计写入文字或Excel文件。 3、计算引擎及子系统所耗的内存，并显示在屏幕上。 4、在游戏过程中或结束时，把内存使用率、最高使用率、泄漏等统计输出。 5、容许在代码内布满调试用打印语句( print statement)，可以开关不同的调试输出种类，并设置输出的冗长级别(verbosity level）。 6、游戏事件录制及回放的能力。这很难做得正确，倘若做对，便是追踪bug的非常宝贵的工具。
• 碰撞和物理：术语是刚体动力学模拟（Rigid Body Dynamics）因为游戏中通常只考虑刚体的运动(motion)，以及产生运动的力( force)和力矩(torque）。研究运动的物理分支是运动学(kinematics),而研究力和力矩是动力学（dynamics)。
• 动画：5中基本动画：1、精灵/纹理动画(sprite/texture animation)。2、刚体层次结构动画(rigid body hierarchy animation)。3、骨骼动画(skeletal animation）。4、每顶点动画(per-vertex animation)。5、变形目标动画（morph target animation)。 骨骼动画是最流行的动画方式。【部分小游戏也会采用帧动画的形式来制作动画】 蒙皮：骨骼网格渲染组件是连接渲染器和动画系统的桥梁。虽然这些组件能非常紧密地合作，但它们的接口还是有明确定义的。动画系统生成骨骼中所有骨头的姿势，这些姿势以矩阵调色板（matrix palette）形式传至渲染引擎。之后，渲染器利用矩阵表去转换顶点，每个顶点用一个或多个矩阵生成最终混合顶点位置。此过程称为蒙皮（skinning)。
• 人体学接口设备：例如键盘鼠标，游戏手柄，其他专用游戏控制器（方向盘，鱼竿，Wii遥控器等）【最近兴起的VR设备也应该算入此行列中】
• 音频：DSP/效果，三维音频模型，音频播放管理等。
• 在线多人/网络：多人游戏的4种基本形式：1、单屏多人，几个人共用一个屏幕 2、切割屏多人：每人拥有自己单独的摄像机，显示在同一块屏幕上 3、网络多人 4、大型多人在线：服务器支持的一个巨大、持久的在线世界。
• 游戏性基础系统：游戏性(gameplay)这一术语是指:游戏内进行的活动、支配游戏虚拟世界的规则(rule)、玩家角色的能力（也称为玩家机制/player mechanics)、其他角色和对象的能力、玩家的长短期目标(goal and objective)。游戏性通常用两种编程语言实现，除了用引擎其余部分使用的原生语言，也可用高阶脚本语言，又或者两者皆用。为了连接低阶的引擎子系统和游戏性代码，多数游戏引擎会引入一个软件层，因无标准术语，书中称之为游戏性基础层(gameplay foundation layer）
• 游戏世界和游戏对象模型：组成游戏的对象类型集合称之为游戏对象模型。典型的游戏对象包括：1、静态背景几何物体，如建筑、道路、地形（常为特例）等。2、动态刚体，如石头、饮料罐、椅子等。3、玩家角色（ player character，PC) 4、非玩家角色（non-player character，NPC) 。5、武器。6、抛射物（projectile）。7、载具(vehicle）。8、光源（可在运行时用于动态场景，也可离线用于静态场景)。9、摄像机。 软件对象模型要回答以下问题：1、游戏引擎是否使用面向对象方式设计? 2、使用什么编程语言?C、C 、Java还是OCaml? 3、怎样组织静态类层阶?一个巨大的层阶，或很多低耦合组件? 4、使用模板（template）及基于原则设计（policy-based design)，或传统的多态( poly-morphism)? 5、如何参考对象?简明的旧式指针，智能指针(smart pointer）还是句柄(handle)?如何独一无二地标识对象?只凭内存地址，用名字，或用全局统一标识符(globalunique identifier，GUID)? 6、如何管理对象的生命周期? 7、如何随时间模拟对象的状态?
• 事件系统：游戏对象总要和其他对象通信。有多种方法可完成通信，例如，对象要发消息，可简单调用接收对象的成员函数。事件驱动架构（event-driven architecture)，常用于典型图形用户界面，也常用于对象间通信。在事件驱动系统里，发送者建立一个称为事件（event）或消息(message）的小型数据结构，其中包含要发送的消息类型及参数数据。事件传递给接收对象时，调用接收对象的事件处理函数(event handler function)。事件也可储存于队列上，以推迟在未来处理。
• 脚本系统：很多游戏引擎使用脚本语言，使游戏独有游戏性的规则和内容，能更易、更快地开发。没有脚本语言，每次改动引擎中的游戏逻辑或数据结构，都须重新编译、链接方可执行程序。若集成了脚本语言至引擎，要更改游戏逻辑或数据，只需修改脚本代码并重新载入即可。有些引擎容许在游戏运行中重载脚本，其他引擎则需要终止后才能重编脚本。但两种形式所需的作业时间，总比重编、重链程序快得多。
• 人工智能基础：【例如A*算法等带有算法决策方面的内容即可称之为人工智能。但目前所指人工智能多为神经网络学习为主，包括敌人的AI，图像识别等。】
• 个别游戏专用子系统：例如背包、武器、载具系统等。

1.7 工具及资产管道

• 游戏引擎都需要读取大量数据，数据形式包括游戏资产(game asset）、配置文件、脚本等。

• 数字内容创作工具：例如Adobe全家桶,3DS等。（P47 1）
• 资产调节管道：数字内容创作软件的存储方式复杂，读取速度通常过慢，而且有些格式是不公开的专有格式，因此需要导出为容易读取的标准格式或自定义格式。从数字内容创作软件到游戏引擎的管道有时成为资产调节管道，每个引擎都有某种形式的资产调节管道。（P47 last2）
• 三维模型/网格数据：游戏中可见的几何图形，通常由两种数据组成。（P48 1） 1、笔刷几何图形。由凸包集合定义，每个凸包则由多个平面定义。优点为：制作迅速简单。便于游戏设计师用来建立粗略关卡，制作原型。既可以用作碰撞体积（collision volume)，又可用作可渲染几何图形。其缺点为:分辨率低，难以制作复杂图形。不能支持有关节的（ articulated）物体或运动的角色。 2、三维模型（网格）：网格是复杂的图形，由三角形和顶点( vertex)组成。网格也可以由四边形和高次细分曲面(higher order subdivision surface）建立。但现时的图形硬件，几乎都是专门为渲染光栅化三角形而设计的，渲染前须把所有图形转换为三角形。每个网格通常使用一个或多个材质(material)，以定义其视觉上的表面特性，如颜色、反射度（reflectivity)、凹凸程度(bumpiness)、漫反射纹理(difuse texture)等。本书中，以“网格”一词代表可渲染的图形，并以“模型”一词代表一个组合对象，可能包含多个网格、动画数据和为游戏而设的其他元数据（metadata)。
• 骨骼动画数据：骨骼网格(skeletal mesh）是一种特殊网格，为关节动画而绑定到骨骼层次结构(skeletal hierarchy)之上。骨骼网格在看不见的骨骼上形成皮肤，因此，骨骼网格有时候又称为皮肤(skin)。骨骼网格的每个顶点包含一组关节索引 (joint index)，表明顶点绑定到骨骼上的哪些关节。每个顶点也包含一组关节权重( joint weight)，决定每个关节对该顶点的影响程度。游戏引擎需要3种数据去渲染骨骼网络：1、骨骼本身 2、骨骼层次架构，包含关节名字、父子关系、当网格绑定到骨骼时的姿势（bind pose)。一个至多个动画片段（ animation clip），指定关节如何随时间而动。（P49 2）
• 音频数据：音频片段（audio clip）通常由Sound Forge或其他音频制作工具导出，有不同的格式和采样率(sampling rate)。音频文件可为单声道(mono)、立体声(stereo)、5.1、7.1或其他多声道配置(multichannel configuration)。Wave文件(.wav)最普遍，但其他格式如PlayStation的自适应差分脉冲编码(ADPCM）文件（.vag及.xvag）也是常见的。音频文件通常组织成音频库（ audio bank)，以方便管理、容易载入及串流。（P49 last）
• 粒子系统数据：当今的游戏采用复杂的粒子效果( particle effect)。粒子效果由视觉特效的专门设计师制作。一些第三方工具，如Houdini，可制作电影级别的效果，可是，大部分游戏引擎不能渲染Houdini制作的所有效果。因此，多数游戏引擎有自制的粒子效果编辑工具，只提供引擎支持的效果。定制的编辑器，也可以让设计师看到与游戏一模一样的效果。（P50 1）
• 游戏世界数据及世界编辑器：（P50 2）
• 一些构建工具的方法：（P50 last）