系列文章前言
《游戏引擎架构》一直被奉为游戏引擎方向的泰斗之作，难能可贵的是其不但内容翔实，可读性也非常强。往往三言两语就把艰深晦涩的知识点讲的清楚明白，可见作者及译者的功力深厚，笔者在读书过程中愈发觉得书中包罗万象，有必要为其做一个个人的总结提炼。
游戏是什么
“游戏”是什么，每个人都有非常直观的理解。我们接触过的有棋类游戏，纸牌游戏，赌场游戏，军事战争游戏，计算机游戏等等。这里给出几个经典的关于游戏的定义：
-
学术上有个“博弈论”，它是指在一个明确的游戏规则框架下，多个代理人选择策略及战术，以求达到利益的最大化。
-
拉夫·科斯特把游戏定义为一种互动体验，为玩家提供一系列渐进式挑战，玩家最终能通过学习精通整个游戏。拉氏把学习和精通作为游戏的乐趣，正如你听一个笑话，明白笑点的一瞬间才感觉有趣。
-
在计算机科学家口中，游戏被称为 软实时互动基于代理的计算机模拟。这个词组实在精妙，可能是从科学层面对电子游戏最好的概括，我们把这个词组拆分讨论以便理解
计算机模拟是指在大部分电子游戏中，会用数学的方式为一些真实世界的子集建模。但很明显，我们不可能完全模拟世界的所有细节，所以这些模型只是真实世界的简化或近似化版本，“近似化”和“简化”是游戏开发者最重要的工具。
代理则是指模拟中多个独立的实体一起互动，游戏中的载具，角色，火球等都可视为代理。从这个角度上说，更广为人知的说法是“对象”。
互动是游戏世界的另一个重要概念。随着游戏事件和故事的展开，游戏世界的状态随着时间改变，游戏也必须回应玩家的输入，这些输入是游戏本身不可预知的。
时限则是所有实时互动模拟的核心概念，在电子游戏中，典型的例子是屏幕每秒最少更新24次以造成动作的错觉。当然电子游戏也有其他类型的限制，如物理模型可能需要每秒更新120次以保持稳定，这里就不赘述。
软实时系统是指一些系统即使错过期限也不会造成灾难性后果。如果帧数不足，人类玩家在现实中不会怎么样，与此相对的是直升机的航空电子系统这类“硬实时系统”。
模拟虚拟世界许多时候要用到数学建模。数学模型可分为“分析式”，或“数值式”。例如一个刚体受地心引力以恒定加速度落下，其分析式可写为：
对于给定的初始条件，就能设任意时间t求y(t)的值，可是大部分数学问题并没有这种闭型解。在游戏世界中，用户输入是不能预知的，因此不能期望对整个游戏完全用分析式。
刚体受地心引力落下的数值式模型可写为，即是说刚体在未来一段时间的高度，可以用目前的高度，高度的第一导数，高度的第二导数及目前时间t作为参数来表示。为实现数值式模拟，通常需要不断重复计算，以决定每个离散时间的系统状态。游戏也是如此运作，一个主循环不断执行，在循环的每次迭代中，各个游戏系统就有机会计算或更新出下一离散步时的状态。这些结果最后可渲染成图形显示，或者输出到其他设备。
游戏引擎是什么
“游戏引擎”这个术语最早出现于20世纪90年代中期。与著名的FPS游戏《Doom》有关,《Doom》当时的软件架构被相当清楚的划分为核心软件组成，美术资产，游戏世界，游戏规则。这种划分的价值在后续逐渐体现出来，另一个开发商取得授权后，只需要改动很少一部分，就可以把游戏打造成一个新产品。同时它也引发了mod社区的兴趣。
20世纪90年代末，一些游戏开发商在设计时已经有意识的考虑到复用性和mod，如《雷神之锤》。同时，游戏工作室也开始对外授权引擎。
通常，游戏和引擎之间的区分是很模糊的。如果要做个区分，我们大概可以用“数据驱动架构”来分辨软件的哪一部分是引擎，哪一部分是游戏。若一个游戏包含硬编码逻辑，复用该软件去制作另一个游戏会变得非常困难。因此，这里的“游戏引擎”值得就是可扩展可复用的软件，不需要过多修改就能作为大多数游戏的基础。
很显然，这样的游戏引擎不可能变成一个通用软件，大部分引擎是针对特定游戏或者特定硬件平台微调的。出现这种现象的原因是设计高效的软件总是要经过取舍的，例如一个为渲染紧凑的室内环境而设计的引擎就不能很好的渲染广阔的室外场景。随着计算机技术和硬件的发展，不同游戏类型的图形引擎差异已经缩小，但通用性和最优性依然需要取舍。实际上，现在的一些比较通用的游戏引擎，也只是适合制作某些类型的游戏。
运行时引擎架构
游戏引擎通常由工具套件和运行时组件两部分构成，下图展示了一个典型三维游戏引擎的主要运行时组件。可见，游戏引擎无疑是一个非常庞大的软件系统。正如所有的大型软件系统，游戏引擎也进行了分层，通常上层依赖下层，下层不依赖上层。
王希老师的Games104课程中把游戏引擎分为工具层，方法层，资源层，核心层，平台层和第三方软件包，这样5+1的架构。本文余下部分会综合这两种说法简要介绍各部分组件。
-
硬件，驱动和操作系统：硬件层表示用来执行游戏的计算机系统或游戏主机，典型平台包括PlayStation,Windows等。驱动程序负责管理硬件资源并隔离了操作系统和上层引擎。而操作系统负责协调一台硬件设备上多个程序执行。本系列大部分内容与这三部分无关。
-
第三方软件包：大部分游戏引擎都会借用第三方软件开发包（SDK）及中间件（middleware），它们提供一些基于函数或类的接口（API），下面介绍几个例子
- 数据结构和算法：STL
- 图形：OpenGL，DirectX
- 碰撞和物理：Havok
- 角色动画：Granny，Havok Animation
- 人工智能：Kynapse
-
平台独立层：大多数游戏引擎需要运行在多平台之上，而平台独立层包装了一些基础API，确保包装了的接口在所有的硬件平台上均为一致。平台独立层位于硬件，驱动，操作系统和第三方软件之上，把引擎的其余部分同底层平台隔离。
-
核心层：核心层包括了一些实用软件，包括容器创建，内存分配，数学计算，线程管理等，核心层为更上层提供支持。
-
资源层：每个游戏引擎都有某种形式的资源管理器，提供一组统一接口，去访问任何类型的游戏资产和输入数据。
-
方法层：方法层提供游戏绘制，运动等基础功能，它包括很多内容，最主要的有：
- 渲染：在任何游戏引擎中，渲染都是最大和最复杂的组件之一。虽然现代渲染器有很多不同的架构方式，但大多数渲染引擎都有一些通用的设计哲学，比如分层架构等等，这里暂且按下不表，后续的文章会做更详细的介绍。
- 碰撞和物理：碰撞和物理系统是紧密连接的，因为当碰撞发生时，碰撞几乎都是由物理积分和约束满足逻辑来解决的。如今很少有游戏公司会编写自己的物理引擎，取而代之的是第三方的物理SDK，例如：Havok，PhysX
- 动画：骨骼动画是如今最流行的动画方式，上图中展示了一个典型的骨骼动画系统。
-
工具层： 工具层指能直接和开发者交互的一系列开发工具。比如性能和调试工具，地图编辑器等等
-
游戏性基础系统：游戏性这一术语是指游戏内进行的活动、支配游戏世界的规则，玩家角色的能力，其他角色的能力，玩家的长短期目标等，游戏性系统是电子游戏乐趣的来源。
总结
今天的文章主要介绍了对游戏和游戏引擎的理解，以及运行时游戏引擎的架构，算是给本系列开了个头。希望能够有始有终完成这个系列。