高层游戏引擎——基于OGRE所实现的高层游戏引擎框架(6)收藏

零件组装：具体游戏层的构建过程

框架搭完后需要一个具体的东西来证明我们的框架是否达到了预期目标。综上，我们对这个框架的要求是：

1、 利用框架开发的开发者不必要关注框架的底层细节，不必要关注OGRE，只需要关注各个组分之间的逻辑关系和存在方式。即满足框架良好的封装性。
2、 上层逻辑允且只允许与框架打交道。同时，框架中可以包含OGRE中无法绕开的重要组分。
3、 如果是框架没有完成的功能，应该可以通过对框架的临时扩展很好的完成任务。如果实在需要修改框架结构，接口也应该尽量避免改动。即满足接口安全。

　　这里有一点例外，就是所未完成的功能是OGRE未实现的功能，因为这个情况需要交给OGRE的维护人员去扩展OGRE库或我们自己来扩展OGRE库。除此之外，如果我们的测试没有完成既定目标，我可以认为自己失败了。

先看看我们的需求：
1、建立一个室外场景。即我们有一个地图体系。
2、有一个Player。即我们有一个物件系统和起码一个物件。
3、有若干怪物，怪物具有一定的智能，这个智能我们将用挂接在怪物身上的脚本来处理。即我们可以为怪物挂接怪物规则体系。
4、当Player杀死所有怪物的时候，游戏成功结束，否则当Player被杀死的时候游戏失败结束。即我们为世界挂接世界规则体系。

　　首先我们建立Application类，其主要功能是管理应用程序运行时的所有重要组件的初始化和删除工作。所有的Singleton单件都会在Application最开始的时候创建并分配堆内存，并在Application结束的时候销毁。这个Application就类似于Ogre的总管Root。而后是一些游戏层物件的准备工作，例如Player类、怪物类等等，并将这些类和类工厂注册到ObjectManager物件管理器里面去。这些工作都是立足于扩展的，不会修改原有的代码。Player类重点在于对键盘和鼠标的控制作出响应，使摄像机等随这些控制运动，而Monster则重点在于实现一些基本的AI逻辑，例如“搜索”、“索敌”、“攻击”，以供状态机或者脚本的需要。

　　在Application初始化的时候，我们在Scene创建时为其载入Scene.cfg场景配置文件，这个文件里包括了Terrain.cfg地形配置文件和object.cfg物件配置文件，以及一些其它与场景相关的内容，例如雾和Light等。Terrain.cfg就是Ogre的地形配置文件，而Object.cfg则确定了每一个物件所挂接的规则体系。这些规则体系的关键就是作为物件成员的脚本文件。

下面是一个标准的脚本文件：

ObjectNumber=1

#Object-1

ObjectType=7

ObjectPositionX=220

ObjectPositionY=220

ObjectPositionZ=220

ObjectScript=Insanity.AI

这里的ObjectScript=Insanity.ai就是为物件挂接了“疯狂”规则体系（AI）。

通过更改Terrain.cfg和Scene.cfg我们创建出来了一个室外场景，然后通过更改object.cfg为场景添加一个Player和几个怪物，并为每一个怪物挂一套AI规则。这样前三步就满足了。

那么世界的规则体系应该挂接到哪里呢？挂接到Scene里吗？

　　很多人是这么做的，而且这样做很简单，但是我并不决定采用这种方法。因为Scene的功能很明确，就是“管理”物件和地形，Scene应该厚厚道道地作一个管理员，而不是游戏逻辑的参与者。因此我决定采用另一种方法：就是物件系统所提供的触发器。

　　触发器的思路来自于一句论述：“肉眼所看不见的客观实在。”就是说，不能用肉体感知的，但是却在暗地里起作用的客观规律。对于我们程序员而言， 触发器说白了就是表面上不可感知，在合适的时候检测当前的条件，当满足条件的时候按照预先的设定反馈给系统的特殊物件。 使用触发器的另一个原因是在原来的作品中曾经使用过它，触发器所体现出来的的移植性和模块化比直接挂在场景上要好一些，而且性能影响并不多。

　　从唯理的论调中离开，回到我们的实践中。由于触发器属于物件系统，因此它每一帧都会检测自己内部的条件情况，并根据条件产生出相应的结果。我们这里的条件有两个，一个是if( Player杀死了所有的Monster )，结果就是“游戏成功结束”，另一个是if( Player的生命值低于0 )，结果就是“游戏失败”。这两个条件我们通过物件脚本系统挂接到触发器上，这样触发器每一帧都会来检测自己是否满足条件，当满足条件的时候：“BANG！”

　　当把触发器加上并注册到物件系统里面后，我们需求的第4点也就满足了，最后的工作就是不断测试和调试了。当一切无误的时候，就可以让它与大家见面了。