使用“组件”优化游戏架构

作者：吴紫鄂（zewu@live.cn）

 

Technorati 标签: Component, Game Framework

近日一直在思考如何将Game Framework设计的更加具有实用性和复用性。

搜索了一下Game Framework，出现的有用的信息非常的少，足见Game Framework的普及远不如Game Engine。一般来讲我们作为快速游戏开发，都会采用一个成熟的商业引擎作为我们的游戏基础，这样可以减少很大的开发成本，并且能够得到很好的技术支持。在拿到Game Engine之后我们会根据我们的游戏类型来对引擎做一些Facade封装，并且对引擎做一些扩展，做关键的就是要为游戏逻辑的开发提供一个良好的工作环境。基于这些原因，构架一个复用性强的Game Framework对于我们游戏艺术的量产起着至关重要的作用。

Game Framework的设计根据不同的游戏类型的可能有些不同，不如FPS和RPG两种不同的游戏类型肯定具有不同的需求，构建一个适用于所有的游戏类型的Game Framework似乎复杂度有点过高，但是针对于某一个类型去构架则会相对简单很多，同时尽可能的去探索适用于All Game Type的Game Framework。

《Game Programming Gem 6》中有一篇“基于组件的对象系统”，参考价值很大，看过之后深受启发。传统的面向对象编程认为一个正方形是一个特殊矩形，因此正方形应该作为矩形的一个子类。《设计模式解析》一书中讲到这并不是一种很好的设计思路，并且提出了“封装变化点”的设计观点，组件的概念大致就和“变化点”沾点亲戚。

举个例子来说明，一个游戏中存在的高级坦克具有很多功能，有些是其他的游戏对象也有的，有些功能是其本身所特有的。首先，Mesh是一个游戏中能看得见的，不同的游戏对象具有的Mesh不同，但是Mesh本身缺存在这很多的相同点，因此可以设计一个MeshComponent类作为可以Set到某个游戏对象的Mesh的封装类，MeshComponent具有一些Mesh共有的数据成员，和操作方法，它是具体的某个游戏对象的一个组件（Component）。同理可以抽象出来很多这样的组件（如BoundBoxComponent，ParticleComponent …………）。

一个基于组件的对象系统的设计大致思路：

1、对于每个游戏对象（Actor）都拥有一个Component的容器（一般用map），可以在任何需要的时刻添加和删除一个组件；

2、组件使用ID标示，便于索引，并且有些组件不能创建多个等等；

3、Component根据游戏类型的需求抽象出来一个基本的继承体系，一般够用原则就Ok啦，实际游戏逻辑实现时如果需要用到一个特殊的Component可以再扩展继承体系；

4、Component保存一个Owner的引用，可以方便的得到Owner的一些数据，和方便和Owner拥有的其他组件之间通信（这种方式增加了一些耦合度，要求使用时需要特殊注意一下）；

5、使用组件模板来简化组件的构造；

6、数据驱动组件对象创建，使用ＸＭＬ或者其他的数据提供方式构造组件。

构建一个基于组件的游戏对象系统，对于整个Game Framework来说会带来至少一下一些很直观想到的益处：1、对扩展开发，对修改关闭，我们可以使用很少的类来扩展出来我们不同的Component，但是对于游戏对象本身不需要做很多的继承体系；2、减少了类的继承体系，同时避免了类爆炸的问题。

对于一个Game Framework，基于组件的设计是一种很好的设计方式，可以为游戏逻辑提供一个方便的创建游戏对象机制，并且某个模块可以很清晰的取得自己关心Component数据，同时也是一种高可扩展性的解决方案。