今天读的是第一章第二和第三小节，什么是游戏，什么是游戏引擎。

什么是游戏

在学术上，游戏理论(game theory)就是 多主体通过选择策略和手段，让他们在一个定义明确的游戏规则框架中获取最大化收益的过程。对于基于主机或电脑的娱乐，游戏通常就是 在3D虚拟世界中扮演仿生机器人、动物或载具作为主角，让玩家控制（或者是2D经典，例如街机游戏什么的）。

作为软实时模拟的电子游戏

大多数2D/3D的电子游戏(Video game)都是计算机科学家说的“软实时交互的基于主体的(agent-based)计算机模拟行为”，接下来让我们看看这句话是什么意思。

在大多数电子游戏中，一些真实/虚拟世界的子集被数学建模，从而能被计算机操控。这个模型通常是（想象的）现实的一种简化与近似，因为肯定不可能会包含现实世界中所有的原子。因此，这种建模是对真实/想象世界的模拟。近似(Approximation)和简化(Simplification)是游戏开发者的两个最强大工具，当它们被巧妙使用时，甚至一个极简的模型都能被误认为是现实。

基于主体的模拟就是许多被称为“主体”的独立个体进行交互，这和大多数3D电脑游戏的描述很相配，这些主体在游戏中就是载具、角色、火球等对象。给予这些对象行为不难，因为现在大多数游戏都是由面向对象的编程语言实现而成。

所有可交互的电子游戏都是时序模拟(Temporal simulations)，意思是虚拟世界的模型是动态的，游戏世界会随着游戏事件或剧情发展而改变状态。因为电子游戏是可交互的时序模拟，它必须对无法预测的玩家输入做出响应。因此，大多数电子游戏都是实时可交互模拟。回合制游戏除外，但这类游戏也有实时响应的GUI，也算是吧。

每个实时系统的核心概念都是 时限(Deadline)。对于电子游戏来说，一个典型例子就是帧率要求至少24FPS，才能提供较为流畅的画面（一般为30或60FPS）。当然，除了帧率限制，电子游戏还有其他时限：稳定的物理模拟可能要每秒更新120次；一个角色的AI可能要每秒在想他接下来要干什么，以免做出蠢事；音像库可能需要每1/60秒进行缓存填充，防止冲突。

“软”实时系统就是缺少一些时限也不会使系统崩溃。例如电子游戏的帧率很低也不影响玩家操作（三帧电竞.jpg）。而 “硬”实时系统则不允许任何时限缺少/出错，这样会导致系统出现严重错误。例如直升机的航电系统、核电站的控制棒系统就是硬实时系统。

数学模型则分为分析(Analytic)模型和数值(Numerical)模型两大类：

• 分析模型：例如要分析刚体在重力加速度影响下的掉落，可用公式 \[ \nonumber y(t)=\frac{1}{2}gt^2+v_0t+y_0 \] 来分析。当然，许多数学问题还是没有解析解的，要给无法预测用户输入的电子游戏进行公式建模也是不可能的。

• 数值模型：例如要分析上边的刚体掉落，还可用数值方法分析 \[ \nonumber y(t+\Delta t)=F(y(t),\dot{y}(t),\ddot{y}(t),\ldots) \] 刚体在未来时间\((t+\Delta t)\)的高度可以被由物体当前时间\(t\)的高度、和它一阶、二阶乃至n阶倒数的组合推出。可通过重复循环的方式计算数值模型，而这也和游戏运行的方式——“游戏循环(game loop)”相似。

什么是游戏引擎

在1990年代中期，id Software 发行的FPS游戏 Doom 爆火，它背后的设计理念催生了“游戏引擎”这一概念。Doom的架构设计得很合理，包括核心软件组件（如3D图形渲染系统、碰撞检测系统和声音系统），美术素材，游戏世界和规则。这样的设计理念让其他游戏开发者得以参考，也催生了模组社区(mod community)的发展。在1990年代末期，像 Quake Ⅲ Arena 和 Unreal 那样的游戏使用了 “可复用” 和 “模组化” 思想。游戏引擎可通过脚本语言（例如 id公司的Quake C）高度自定义，而且引擎的授权使用也为引擎开发者们带来了可观收入。

游戏和游戏引擎之间的区分是模糊的。一些引擎将游戏和它本身明显区分开，而其他引擎则没有试过与游戏分离。没有工作室给游戏和游戏引擎完美分离。

可以说基于数据驱动的架构让游戏引擎和游戏软件区分开来。有的游戏有硬编码的逻辑/规则，或者编写了可以渲染特定游戏对象的代码，重用这个软件去做一个新游戏很难。因此，游戏引擎最好是可拓展的，可复用的。

下图是游戏引擎可复用性的发展史：

有些人设想游戏引擎可以像视频播放器那样，可以游玩各种各样的游戏。然而，该设想不可能被实现。大多数游戏引擎都是针对一个在特定平台运行的特定游戏进行特化的。并且对于大多数更通用的多平台游戏引擎来说，它们也只能构建某种特定类型的游戏（FPS，赛车等）。因此，如果一个游戏引擎/中间件更通用，那么它对于某特定游戏/平台的优化就越少。

出现这种现象是因为在设计软件的任何效率相关部分都需要做一定的取舍(trade off)，并且这些取舍都基于软件在目标平台上如何使用而假设的。例如，有个专门用于渲染室内环境的渲染引擎，可能不太擅长渲染大户外场景。这个室内渲染引擎可能使用二叉空间分割树(BSP)或其他系统以确保被遮挡的物体/离相机过近的物体没有被渲染。而户外渲染引擎可能有不怎么精确或根本没有检测遮挡，而是可能用LOD(level-of-detail)技术以确保远处渲染的物体不怎么精细，而离相机较近的物体使用高分辨率渲染。

随着硬件、渲染算法、数据结构等的发展，为不同类型特化的游戏引擎间界限开始消失。例如，现在可能用FPS游戏引擎去设计一个策略类型的游戏了。当然，还是最好让特定平台/类型的游戏交给针对它而特化的游戏引擎制作。