[原创]从思考游戏引擎的本质 谈 如何构建一个有着完善

liuzewei

第一篇里我们思考了一下游戏引擎的本质，属于概念上的范畴。这第二篇我们将思考一下具体引擎该如何架构，它跟游戏的逻辑如何衔接，它提供一种什么结构，可以让我们具体的游戏开发在逻辑上可以更清晰。整个过程中我们将与 操作系统 进行对比，并具体验证上一篇中所得出的结论。

这第二篇，让我们走得更远。整个思考过程，我们以室内游戏，室外两类游戏做为例子

一、室内游戏，以台球游戏为例

引擎部分：
一个台球房：调用引擎 new 一个 scene 对象，返回一个 pScene 指针（操作系统:新建一个APP返回pInstance）
一张台球桌：调用引擎 new 一个 entity 对象，返回一个 pEntity 指针（操作系统:新建一个窗口，返回hWnd）
16个球：调用引擎 new 16个 node，分别返回各 pNode 指针（操作系统：各种窗口元素，返回hXxx）

游戏部分：
一个台球房类：除自身逻辑代码外，有一个成员变量 pScene 存引擎返回的对应指针
一个台球桌类：除自身逻辑代码外，有一个成员变量 pEntity 存引擎返回的对应指针
一个球类：除自身逻辑代码（比如碰撞、反射等等）外，有一个成员变量 pNode 存引擎返回的对应指针

整个过程：
我们拿到一个游戏引擎，首先是运行它（对比：启动操作系统），然后我们向引擎申请 台球房、台球桌、球 对应的 scene、entity、node 这类引擎资源（对比：操作系统资源）。接着我们把申请到的引擎资源的 指针（对比：句柄）存到我们游戏部分里对应的三个类的成员变量里，从这以后我们就不必要再关注游戏引擎部分，我们只需要操作我们游戏部分的 三个类，操作这些类中我们自己写的逻辑代码，需要引擎功能时，我们直接操作对应的 那几个 指针 成员变量。

更多思考：引擎不应该关注更不应该实现 具体游戏的逻辑，游戏逻辑的概念非常宽泛，这个例中的 球与球 之间碰撞等物理计算也属于游戏的逻辑。现在很多游戏引擎里都内置有碰撞检测，我觉得这种封装是多余甚至且在概念上是错误的。游戏的所有逻辑都应该由游戏引擎使用者实现，给他们完全的自由空间。引擎能做的，就象操作系统一样，开辟引擎使用者需要的资源，并返回资源指针。这就是引擎要做的全部。

小结：整个此台球游戏开发采用面向对象的概念，它的主要部分是3个类，虽然引擎是基石框架，但引擎并没有跟我们的开发过程中产生混乱的交叉。自然而然的，我们开发过程中的思考重心落在了游戏本身上，而不是引擎。关键的是，这是有引擎的架构而决定的 自然而然 的结果，从而使我们的开发过程拥有最大的自由度，且具有很低思考复杂度的优点。


二、室外游戏，以一个3D RPG游戏为例

引擎部分：
一个室外场景：调用引擎 new 一个 scene 对象，返回一个 pScene 指针
N个NPC：调用引擎 new N个 entity 对象，返回他们的 pEntity 指针
主角：调用引擎 new 1个 node，返回其 pNode 指针

游戏部分：
一个室外场景类：除自身逻辑代码外，有一个成员变量 pScene 存引擎返回的对应指针
一个NPC类与其N个派生类：除自身逻辑代码外，有一个成员变量 pEntity 存引擎返回的对应指针
一个主角类：除自身逻辑代码外，有一个成员变量 pNode 存引擎返回的对应指针

过程、思考：同第一个游戏



总结

这篇帖子中关键的地方在于：
游戏引擎就象操作系统，开辟引擎使用者申请的资源并返回对应资源指针。

这篇帖子中最关键的地方在于：
引擎使用者将得到的指针 存在 其对应类 的一个成员变量中。

这篇帖子中最关键最关键的地方在于：
包含了 引擎资源指针成员量的 类即包含了整个游戏需要的全部。
既然是全部，我们整个开发过程就只要关注我们自己的这个几个类，而不是引擎。



好了，就写到这里吧````同样是即时的纪录自己的思考过程```````可能有许多错误。请大家发表自己的开发，看贴回帖，不然我就要失望了。哈哈。各位高手和前辈，见笑了：）

tonykee

引擎是高度可重用性的框架，一个平台，包含很多的工具，组件，以及算法的封装
当然不应该包含任何的游戏本身的逻辑上的东西，否这就不叫引擎，而叫应用示例了
我想这就是本质

zq1216

新学的孩子不要误导新手。。。你这个不是本质，是随便侃侃，帖子题目取错了，请修改一下，否则会误导人家，呵呵

xikema

本质就是：开发多个类似的游戏，如何做到写的代码行数最少。

funcman

Windows还提供了IE,MP啥的呢,所以引擎该不该包含涉及游戏逻辑的内容,仁者见仁,淫者见淫吧