●概说

    谈游戏程序构成，不得不谈一下游戏的〝底层引擎〞，所谓底层引擎，可以看作为是一个为硬件平台建立的中介环境。为什麽称之为引擎，因为它具备了启动的力量，就像汽车的引擎概念一般，有了一个发动机，然後我们可以设计底盘、车架、内装外壳等等，一切配备完善了，汽车才终於构成。

    驾驶盘与车上所有的可使用物件，可以看作为游戏提供的介面功能，透过这些功能的操作，我们可以使用与享受这部汽车（游戏），大约就是这样的概念。

    一部汽车，可以更换发动机而获取更大的运转力量，那麽一款游戏呢？更换了引擎，原理上确实也是可以获得更好的表现，但实际上更换游戏引擎的目的，多半是因为跨了不同平台版本，或者做某些效能的提升，相对起来後者的发生机率较小。

    更换游戏引擎和更换汽车引擎的概念也差不多，一般总是要做一些『接口』上的修改。如果变动很大，有时还不如重写得快，例如从2D换成3D引擎，那变动有时是很难计算的。

 ●游戏引擎里都有什麽？

    游戏引擎里一般除了根据硬件平台所做的一切环境准备以外（例如与硬件、系统API沟通内存管理等），主要还是在显示上的功能，再则就是一些使用极为频繁的功能，例如音乐、逻辑、脚本解译等等，概念上就是把经常用到的东西放进引擎里，做一些接口供游戏上层呼叫使用。

    而尽管好像放了很多东西，实际上引擎本身尺寸一般还是蛮小的，而且多半加以封装，一般上层的使用者是看不到内部程序怎麽写的，仅知道函式的呼叫方式与规则。这一般是引擎作者对於自己知识产权的保护措施，另一方面，封装起来也比较不会被手贱的程序员乱改，产生一些预期外的错误。

    显示模组（模块）    

    每一个硬件平台对於画面显示的方式或者条件、限制不同，而每个引擎可能自身也有一些限制所在。显示模块负责图像、文字显示的功能，由它负责和硬件或者系统API沟通（例如DIRECT X），它本身一般也包含了（或者关连到引擎的）内存管理机制（模块），除了加速显示以外，也避免了上层使用者乱用内存，导致游戏死机的危险。

    除此之外，这其中可能还放置了一些常用图像特效运算的功能模块。

    硬件沟通

    前面提到的内存管理以及对应硬件介面的沟通，也需要一套机制来处理，在PC上，一般的硬件输入就是鼠标与键盘，这在Direct X中都提供了函式可以处理。而在其他硬件平台上，就必须更换相映的沟通方式，例如Wii  的感应手柄，自己就有一套输出入的机制与数据规则，上层游戏撰写者只要根据这规则向引擎沟通，就可以取得需要的资料，并且做出反应。在声音及其他硬件沟通也是一样的，一般是透过引擎来沟通。

    而并非所有平台都是透过引擎来和硬件沟通，有一些平台把一些显示、声音功能都做到芯片中，提供使用者直接呼叫。例如游戏机平台，为了加速运算与便利性，会把多数常用的图像功能放进GPU里，这也是为什麽次世代游戏机的速度总比PC快的原因之一。

    另一方面来说，游戏机的内存是有限的，不可能随时扩充，所以必须要有一套有效的管理规则。

例如GBA的芯片本身就提供很多种显示模式，游戏程序员只要直接修改RAM中特定位置的FLAG（旗标），直接就能改变显示模式，当中最特别的就属TILE模式，它自动作了显示内存的规划，并提供了图层功能，只要把图像资料放在规定的内存范围里，画面上就能直接显示出你要的位置与图层重叠（内存绝对位置MAPPING），而卷动画面，其实就是把内存中的资料搬过来移过去而已。

    脚本解译

    有些游戏引擎自带了一套脚本语言系统，有的则是使用现成脚本（例如第一篇文章提到的LUA之类）。不管後来脚本是以脚本语言写出来、或者是以编辑器实现，最终都会变成脚本文档（多数会经过特殊编码保密），再由引擎的脚本解译模块读取辨识与实现。

    这部分牵涉比较广，有时间另开一个题目来说。