本系列博客为《游戏引擎架构》一书的阅读笔记，旨在精炼相关内容知识点，记录笔记，以及根据目前（2022年）的行业技术制作相关补充总结。 本书籍无硬性阅读门槛，但推荐拥有一定线性代数，高等数学以及编程基础，最好为制作过完整的小型游戏demo再来阅读。 本系列博客会记录知识点在书中出现的具体位置。并约定（Pa b），其中a为书籍中的页数，b为从上往下数的段落号，如有lastb字样则为从下往上数第b段。 本系列博客会约定用【】来区别本人所书写的与书中观点不一致或者未提及的观点，该部分观点受限于个人以及当前时代的视角所限，请谨慎阅读。 再次重申，请支持正版。 本人目前学习方式分为两种。第一种为工作以及实践中遇到问题去专项学习，解决问题；另一种为提纲掣领，主动学习未来所必学之内容。《游戏引擎架构》一书的学习则为第二种。 私以为，如若制作游戏仅为个人兴趣，该书可以不用花费心思阅读。但若想精进技术，夯实基础，则需至少通读各类基础底层原理书籍，从总纲基础入手，进而再细化学习进阶内容。 本书虽然为引擎架构，但实则是为游戏中各类问题提供整体性解决方案，让读者能够从底层入手，从全局角度考虑，如何切实解决游戏开发中遇到的种种困难，同时主动培养系统性解决方案的思维和能力。 学习编程切勿纸上谈兵，正如书中序言所说“游戏科技是一个活生生、会呼吸的家伙，永远不可能将之束缚于书本之上。” 第一部分：基础 第二部分：低阶引擎系统 第三部分：图形及动画 第四部分：游戏性 第五部分：总结 虽然市面引擎结构和实现细节千差万别，但几乎所有的游戏引擎都含有一组常见的核心组件，例如渲染引擎、碰撞及物理引擎、动画系统、音频系统、游戏世界对象模型、人工智能系统等。而这些组件内也开始显现一些半标准的设计方案。（P3 1） 从本书中读者能学习到以下内容：1、如何架构工业级生产用游戏引擎。 2、现实中的游戏开发团队怎样组织及运作。 3、有哪些主要子系统及设计模式不断出现在几乎所有游戏引擎里。每个主要子系统的典型需求。 4、有哪些子系统与游戏类型或具体游戏无关，有哪些子系统是为某游戏类型或具体游戏而设计的。 5、引擎和游戏的边界位于何处。 大规模软件工程中的一些技巧及工具：1、逻辑软件架构和物理软件架构的区别。 2、配置管理(configuration management)、版本控制(revision control）及生成系统( build system)。 3、最常用的C/C++开发环境——微软Visual Studio——的窍门及技巧。
典型游戏团队的人员配置。游戏工作室(game studio）通常由5个基本专业领域的人员构成，包括工程师(engineer)、艺术家( artist)、游戏设计师(game designer)、制作人( producer）及其他管理/支持人员（市场策划、法律、信息科技/技术支持、行政等)。每个专业领域可细分为多个分支。 工程师（程序员）：分为两类运行时程序员（runtime programmer)和工具程序员(tool programmer)。运行时程序员制作引擎和游戏本身;工具程序员制作离线工具，供整个团队使用，以提高团队的工作效率。运行时/工具两方面的工程师都各有专长。有些工程师在职业生涯里专注单一的引擎系统，诸如渲染、人工智能、音效或碰撞/物理;有些工程师专注于游戏性( gameplay)和脚本编程(scripting);也有一些工程师喜欢系统层面的开发，而不太关心游戏实际上怎么玩；还有些工程师是通才(generalist），博学多才，能应付开发中不同的问题。（P4 1） 艺术家：（P5 3） 游戏设计师（国内一般称为策划，而国外一般成为设计师->designer）：例如关卡、剧情、系统、战斗策划等，分别负责设计游戏的各个方向。 制作人：在不同的工作室里，制作人（producer)的角色不尽相同。有些游戏公司，制作人负责管理时间表，并同时承担人力资源经理的职责。有些游戏公司里，制作人主要做资深游戏设计师的工作。还有些游戏工作室，要求制作人作为开发团队和商业部门（财政、法律、市场策划等）之间的联系人。有些工作室甚至是完全没有制作人。例如在顽皮狗(NaughtyDog)公司，几乎所有员工，包括两位副总裁，都直接参与游戏制作，工作室的资深成员分担了团队管理工作及公司事务。（P6 last） 其他工作人员：游戏开发团队通常需要一支非常重要的支持团队，包括工作室的行政管理团队、市场策划团队（或一个与市场研究公司联系的团队)、行政人员及IT部门。IT部门负责为整个团队采购、安装及配置软硬件，并提供技术支持。（P7 2） 发行商及工作室：游戏的市场策划、制造及分销，通常由发行商( publisher）负责，而非开发游戏的工作室本身。发行商通常是大企业，例如艺电（Electronic Arts，EA)、THQ、维旺迪(Vivendi)、索尼(Sony)、任天堂(Nintendo）等。很多游戏工作室并不隶属于个别发行商。另外，第一方开发商(first-partydeveloper）是指游戏工作室直接隶属于游戏主机生产商（索尼、任天堂、微软)。例如，顽皮狗是索尼的第一方开发商。这些工作室独家为母公司的游戏硬件制作游戏。（P7 3）
对于游戏的定义也可以参考《游戏的人》一书。 基于本书主旨，我们会集中讨论游戏的一个子集，子集里的游戏由二维或三维虚拟世界组成，并有少量的玩家(1~16个左右)。本书大部分的内容也可以应用到互联网上的Flash游戏、纯解谜游戏（如《俄罗斯方块（Tetris)》）或大型多人在线游戏(massivelymultiplayer online games，MMOG)。但我们主要集中讨论一些游戏引擎，这些游戏引擎可以用来开发第一人称射击、第三人称动作/平台游戏、赛车游戏、格斗游戏等。 大部分二维或三维的电子游戏，会被计算机科学家称为软实时(soft real-time）互动( interactive）基于代理（agent-based)计算机模拟(computer simulation）的例子。（P8 3）
游戏和其引擎的分界线是模糊的，数据驱动架构或许可以用以区分。若一个游戏包含硬编码逻辑或游戏种类的游戏对象，则复用该软件去制作新游戏就会变得困难甚至不可行。因此，这里说的“游戏引擎”是指可扩展的软件，而且不需要大量修改就能成为多款游戏软件的基础。（P10 3） 我们完全可以说，游戏引擎或中间件组件越通用，在特定平台运行特定游戏的性能就越一般。（P10 last） 【现如今（2022年）的游戏引擎可以说是在功能方面发展趋于完善，因此例如U3D，如果你需要制作什么类型的工具，那么就在引擎中加载该类型的相关工具即可达到基本的使用需求，如有更多需求则可以在引擎中书写代码来定制相关功能特性。以及再跨平台方面有IL2CPP的存在，也变得很方便，且对于出现新的平台也可以很快的做到基本的兼容】
不同类型游戏引擎有差异也有重叠部分，譬如都会有低阶用户输入（例如手柄，键盘，鼠标），某形式的三维网格渲染，显示输出等。（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游戏中的街机里面可以玩各种小游戏。】
雷神之锤引擎家族（P22 2） 虚幻引擎（P23 3） Source引擎（P24 1） 微软XNA Game Studio（P24 2） 其他商业引擎（P24 last2） 专有内部引擎（P24 last） 开源引擎（P25 2）
如同所有软件系统，游戏引擎也是以软件层(software layer）构建的。通常上层依赖下层，下层不依赖上层。当下层依赖上层时，称为循环依赖（circular dependency)。在任何软件系统中，循环依赖都要极力避免，不然会导致系统间复杂的耦合（coupling)，也会使软件难以测试，并妨碍代码重用。对于大型软件系统，如游戏引擎，此问题尤其重要。（P27 3） 【如果你已经做过一些游戏demo，使用过例如U3D或者虚幻这样的引擎那么你应该会对游戏引擎有一个初步的了解，如果没有那么再看下图可能会较为的困难，此时推荐先回去尝试用上述游戏引擎制作一款完整的小游戏并总结自己所用到的技术点，然后再来阅读】 运行时引擎架构（P26） 目标硬件：用来执行游戏的计算机系统或游戏主机。 设备驱动程序：由操作系统或硬件厂商提供的最低阶软件组件。驱动程序负责管理硬件资源，也隔离了操作系统及上层引擎，使上理解不同硬件版本的通信细节差异。 操作系统：【如对PC操作系统有不明白之处，请学习完操作系统课程再来阅读此书】 第三方软件开发包（SDK）和中间件：SDK提供基于函数或基于类的接口，一般称为应用程序接口（API），例如数据结构及算法，图形，碰撞和物理，角色动画，人工智能，生物力学角色模型等（P28 3） 平台独立层：大多数游戏引擎需要运行于不同的平台上，因此，大部分游戏引擎都架构有一个平台独立层在硬件、驱动程序、操作系统及其他第三方软件之上，以此把其余的引擎部分和大部分底层平台隔离。平台独立层包装了常用的标准C语言库、操作系统调用及其他基础API，确保包装了的接口在所有硬件平台上均为一致。这是必须的，因为不同平台间有不少差异，即使所谓的“标准”库，如标准C语言库，也有平台差异。（P31 last2）【平台差异确实造成了很多问题，例如指令集的不同，因此例如服务器验证工作就很高效进行】 核心系统：常见功能有：（P32 1） 资源管理：每个游戏引擎都有某种形式的资源管理器，提供一个或一组统一接口，去访问任何类型的游戏资产及其他引擎输入数据。有些引擎使用高度集中及一致的方式（例如虚幻的包( package)、OGRE的ResourceManager类)。其他引擎使用专案(ad hoc)）方法，比如让程序员直接读取文件，这些文件可能来自磁盘，也可能来自压缩文件（如雷神之锤引擎使用的PAK文件)。（P32 last） 渲染引擎：任何游戏引擎中，渲染引擎是最大及最复杂的组件之一。渲染器有很多不同的架构方式。虽然没有单一架构方式，但是大多数现在的渲染引擎都有些通用的基本设计哲学，这些哲学大部分是由底层三维图形硬件驱动形成的。 剖析和调试工具：用于剖析游戏性能。通常包含一下功能： 碰撞和物理：术语是刚体动力学模拟（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)。 人体学接口设备：例如键盘鼠标，游戏手柄，其他专用游戏控制器（方向盘，鱼竿，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、摄像机。 事件系统：游戏对象总要和其他对象通信。有多种方法可完成通信，例如，对象要发消息，可简单调用接收对象的成员函数。事件驱动架构（event-driven architecture)，常用于典型图形用户界面，也常用于对象间通信。在事件驱动系统里，发送者建立一个称为事件（event）或消息(message）的小型数据结构，其中包含要发送的消息类型及参数数据。事件传递给接收对象时，调用接收对象的事件处理函数(event handler function)。事件也可储存于队列上，以推迟在未来处理。 脚本系统：很多游戏引擎使用脚本语言，使游戏独有游戏性的规则和内容，能更易、更快地开发。没有脚本语言，每次改动引擎中的游戏逻辑或数据结构，都须重新编译、链接方可执行程序。若集成了脚本语言至引擎，要更改游戏逻辑或数据，只需修改脚本代码并重新载入即可。有些引擎容许在游戏运行中重载脚本，其他引擎则需要终止后才能重编脚本。但两种形式所需的作业时间，总比重编、重链程序快得多。 人工智能基础：【例如A*算法等带有算法决策方面的内容即可称之为人工智能。但目前所指人工智能多为神经网络学习为主，包括敌人的AI，图像识别等。】 个别游戏专用子系统：例如背包、武器、载具系统等。
游戏引擎都需要读取大量数据，数据形式包括游戏资产(game asset）、配置文件、脚本等。 数字内容创作工具：例如Adobe全家桶,3DS等。（P47 1） 资产调节管道：数字内容创作软件的存储方式复杂，读取速度通常过慢，而且有些格式是不公开的专有格式，因此需要导出为容易读取的标准格式或自定义格式。从数字内容创作软件到游戏引擎的管道有时成为资产调节管道，每个引擎都有某种形式的资产调节管道。（P47 last2） 三维模型/网格数据：游戏中可见的几何图形，通常由两种数据组成。（P48 1） 骨骼动画数据：骨骼网格(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） << Unity底层如何处理C#《游戏引擎架构》阅读笔记 第一部分第2-3章 >>
