第一部分 游戏引擎技术简介第一部分所需所有图片 引擎概述
曾经有一段时期，游戏开发者关心的只是如何尽量多地开发出新的游戏并把它们推销给玩家。尽管那时的游戏大多简单粗糙，但每款游戏的平均开发周期也要达
到8到10个月以上，这一方面是由于技术的原因，另一方面则是因为几乎每款游戏都要从头编写代码，造成了大量的重复劳动。渐渐地，一些有经验的开发者摸索
出了一条偷懒的方法，他们借用上一款类似题材的游戏中的部分代码作为新游戏的基本框架，以节省开发时间和开发费用。于是就慢慢产生了游戏引擎。人对于游戏
引擎的概念是逐步深入理解的，这个过程类似于其他技术的进步过程——毕竟游戏引擎也是一个程序。这个理解所立足的就是对“封装性”的理解。实际上在引擎这
个概念下面更多的是每个人对引擎各自不同的理解：游戏引擎只是一个说法，至今为止没有一个公认的定义。
近几年一部分初学者所理解的引擎是“对底层功能的简单封装”，这个底层功能包括平台API、渲染API、音频API、流媒体API等，这样的引擎往往
是一种C语言时代的思路，其划分是来自于各个不同部分之间的“功能”关系，而非“逻辑”关系。经典概念包括：渲染核心、内存管理、骨骼动画、帧动画、文件
操作、物理库、网络库等等。这个在广为传诵的网文《游戏引擎剖析》（参考4）里面有最为明确的体系划分：
1、“渲染和构造3D世界，3D环境的光照和纹理”。渲染永远是引擎最具有技术含量的部分，就不说那动辄千百块钱的图形卡了，单是图形渲染相关技术的
进步速率，就已经足以让人瞠目结舌了。“什么是渲染器，为什么它又这么重要呢？好吧，如果没有它，你将什么也看不到。它让游戏场景可视化，让玩家/观众可
以看见场景，从而让玩家能够根据屏幕上所看到的东西作出适当的决断。”渲染所需的主要底层功能就是来支持OpenGL和DirectX的最新技术。由于这
些技术不断更改，导致渲染器的更新换代也相当明显。好在OGRE本身就是一个很巧妙的渲染器，它为我们隐藏了很多渲染器的复杂性，让我们可以用近乎自然语
言的方式来进行图形处理。
2、“内存使用，特效和API”。图形研究到高层次就不得不考虑到芯片的一些特性：例如显存和内存管理、Shader和其它重要的参数。这也是属于引
擎必须染指的内容。
3、“模型与动画，细节级别LOD”。游戏引擎应该支持常见的模型文件格式并很好地渲染他们，如果游戏引擎需要用到自己的数据格式，那么它需要为几个
主要的模型文件格式做导出插件，以满足美工的需要。
4、“物理，运动，效果”。物理系统可以让游戏尽可能地逼真。“作为游戏开发者来说，无论我们做什么，我们需要能够检测墙壁，检测地板，在世界中处理
和其他对象的碰撞。这些是现代游戏引擎的必备。”先进的物理系统如ODE，可以在保证效率的前提下精确处理物理和运动学理论和公式，其中甚至包括流体力
学。 5、“声音系统，音频APIs”。耳朵也是人的一个重要的感觉和信息获得器官，这一点应该很好理解。
6、“网络和连线游戏环境”。网络游戏必备。如今大多数真正有长久生命力的游戏都至少有一些连线成分。“最纯粹的单人游戏容易玩一次，也许两次，或者
甚至三次如果它是非常好的游戏，但一旦游戏结束，就被束之高阁了。如果你想要有任何长久生命力，那么多人连线游戏就是形势的核心所在。”
7、“脚本系统”。你可以把游戏脚本认为是电影脚本，它们两者实质上是相同的。 8、“人工智能和导航”。
当按照这个思路建立了自己的引擎后，我们的引擎只是一个功能引擎，它没有任何逻辑关系。包括场景、地图、物件、规则等一系列游戏逻辑所直接相关的东
西，它都没法直接提供。这个时候我们所具有的引擎大约是如同下图所示： 图1－1
基本的的底层引擎核心结构 一种可怕的平铺性的结构，互相之间没有关联或很少关联。也就是说，它基本什么逻辑都没有实现，每一个游戏你可以重用这些底层
功能，除此之外，你需要重新写所有逻辑，即便两个游戏在基本逻辑上基本相同。国外的游戏引擎已经可以让你脱离代码，只用脚本和编辑器就可以做游戏了（这种
开发手段叫做MOD），这种简单的平铺结构，没有纵深，根本无法架起这样一栋充斥了逻辑的大楼！ 高层引擎概述
我们拿2D地图来做一个例子，在这样的引擎思路下，地图只是诸多图元的拼接、Blt（发音Blit，位图位块传输）和互相遮挡。这个思路确实反映出来
了地图的本质，但是对于游戏逻辑来说，它太细了。因为游戏逻辑是不需要管你地图图元如何拼接、Blt和遮挡的。下图左就是针对这种设计思路的，而下图右则
是提供了高层引擎的设计思路。通过对比可以发现，右边的设计思路更符合OO的封装原则，而左边的主要是比较古老的过程式填鸭。 图1－2
左边是直接在应用程序里硬编码底层功能，右边是在应用程序和底层引擎之间建立一个抽象层，有这个抽象层划分和承担游戏的基本逻辑。在OO大行其道的今天，
你会用哪一种方法？ 而在这里我们理解的引擎除了功能元素之外，同时包括一些逻辑意义的部分，即部分开发者交流中所说的“游戏层引擎”或“高层引擎”，
为何会存在这部分引擎呢？答案是为了方便我们表达游戏的上层逻辑。底层游戏引擎所立足的都是平台API，是与API严格相关的。目的就是为了要让外界看不
见API，专心做外界的逻辑部分，但底层引擎只完成了一个目的就是通过封装API来完成一定功能，封装好的API是否就表明一定适应上层逻辑的要求呢？这
根本不可能，因为它不是为了这个目的而存在的，例如骨骼动画和上层逻辑有什么关系呢？因此人们又提出了高层引擎的概念。这就回答了刚刚的问题，骨骼动画是
应当包含在物件逻辑内部实现的，对外部应该是透明的。如果游戏逻辑需要细化到“谁谁谁，按照骨骼动作‘Walk2’来行走”，那就太麻烦了，这种情况下，
比较普遍的做法是我们由来实现一个物件，然后为其设置一种状态叫做STATE_WALK2，在物件自己的逻辑里面当发现物件是处于这种状态的时候就开始引
发“Walk2”动作，这样，最后的游戏逻辑只用简化到说“那个谁，向前方走一步”就可以了。实际的处理是，引擎层获取到了这个消息以后，向物件“谁”发
送一个TranslateState(“走”)的消息，而物件“谁”获得这个消息后，根据当前状态自动进行状态机的切换。对于逻辑的开发者来说，这一切都
是封装好的，透明的，他们只需要知道“当我说‘A向前走’，A就会向前走”就可以了，这样的引擎就不再简简单单是功能平铺的平房，而是具有一定逻辑保障的
大厦了。STATE_WALK2到Walk2的对应关系在不同游戏引擎里面可以通过不同方式实现，最初也是最简单的方法是硬编码（Hard-Code），
这种方法速度快，然而牺牲了程序的维护性，会给测试带来很大麻烦。现在，大部分的游戏引擎可以通过配置文件甚至是编辑器来解决此问题，以及与此类似的问
题，这种数据驱动的方式使编码逻辑更加简单，同时也使设计者和导演工作更加方便。
下图是我们使用一款外国引擎的编辑器时的场面，在这个编辑器里面，既有物件编辑器，也有场景编辑器，同时也包括脚本——这个编辑器里用它来实现我们所
说的规则——的编辑器： 图1-4
看着很像3DMax的一款游戏编辑器，中国目前大部分游戏工作室还没有自己的实力开发这种高度集成的编辑器 把话题引回来，对比前面我们得出的结论，做
一个游戏，实际上就是在做场景（地图＋物件）、规则系统、GUI系统和I/O控制系统。那么我们该怎么做呢？构建一个过于集中的，把所有功能都实现了的高
层系统，只会降低高层引擎的可适应性，因此属于高层引擎更多的是对它们提供支持，这些支持包括：基本数据结构和组织方式（例如物件链表及查询操作、特殊的
文件数据）、工具集等。通过这一层的存在，最高层逻辑只需要写：在场景中放置几只飞鸟，按照Sin函数路线飞行。至于飞鸟飞行中是怎么振翅，怎么偏航，这
是在物件系统的具体物件类——这里是飞鸟——里可以决定的。为了最终产品的逻辑需要，我们迫不及待的需要一个“高层游戏引擎”，这是源自于一个很重要的思
想，同时也是软件工程的基础思想：“软件产生于需求”。底层引擎层次的划分完全来自于平台和API的限制，因为毕竟我们要做的游戏必须跟某一个平台相关。
而高层次的引擎结构则是跟需要达到的目的严格相关的，因为这是它的存在动机。
实际上现在大部分引擎都是或多或少地包括了高层引擎部分的，然而高层引擎的划分却并不容易，大部分引擎所面向的还是FPS这种游戏类型，做一款普遍适
应的引擎是难上加难，因为不同游戏所需要的高层不一样。
我们这篇文章的基本目的，就是试验当拥有一个现有的底层引擎的时候，如何构建一个高层引擎，以及如何让这个高层引擎具有更强的适应性。
现在我们具有的引擎构造大抵如下： 图1－4 按照现在的划分诞生的高层引擎层的基本框架
