在大部分的MMOG中,游戏对象的类型都大同异Q主要有物品、生物、玩家等。比如在wow中,通过服务器发下来的GUID我们可以了解刎ͼ游戏中有9大类对象Q包括物?Item)、背?Container)、生?Unit)、玩?Player)、游戏对?GameObject)、动态对?DynamicObject)、尸?Corpse){?/p>
在mangos的实CQ对象用类l承的方式,由Object基类定义游戏对象的公有接口及属性,包括GUID的生成及理、构造及更新UpdateData数据的虚接口、设|及获取对象属性集的方法等。然后分Z两类z对象Q一是ItemQ另一是WorldObject。Item即物品对象,WorldObject思义Qؓ世界对象Q即可添加到游戏世界场景中的对象Q该对象cd定义了纯虚接口,也就是不可被实例化,主要是在Object对象的基上又d了坐标设|或获取的相x口?/p>
Itemcd又派兵出了一cBag对象Q这是一U特D的物品对象Q其本nh物品的所有属性及ҎQ但又可作ؓ新的容器cdQƈh自己Ҏ的属性和ҎQ所以实C采用了派生。mangos在实现时对Bag的类型定义做了点技巧,Item的类型ؓ2QBag的类型ؓ6Q这样在通过位的方式来表C类型时QBagcd也就同时属于Itemcd了。虽然只是很的一个技巧,但在很多地方却带来了极大的便利?/p>
从WorldObjectz出的cd有好几U了QUnit、GameObject、DynamicObject和Corpse。Unit为所有生物类型的基类Q同WorldObject一P也不可被实例化。它定义了生物类型的公有属性,如种族、职业、性别、生命、魔法等Q另外还提供了相关的一些操作接口。游戏中实际的生物对象类型ؓCreatureQ从UnitzQ另外还有一cL生对象Player为玩家对象。Player与Creature在实C最大的区别是玩家的操作由客L发来的消息驱动,而Creature的控制是p己定义的AI对象来驱动,另外Player内部q包括了很多的逻辑pȝ实现?/p>
另外q有两类Ҏ的CreatureQPet和TotemQ其对象cd仍然q是生物c,只是实现上与会有些特D的东西需要处理,所以在mangos中将其作为独立的zc,只是实现上的一点处理。另外在GameObject中也实现有派生对象,最l的l承关系图比较简单,׃ȝ地去d了?/p>
从我所了解的早期游戏实现来看,大部分的游戏对象l构都是采用的类DU方式。可能与早期寚w向对象的理解有关Q当面向对象的概念刚出来Ӟ大家认ؓl承是面向对象的全部,所以处处皆对象Q处处皆l承?/p>
cd现的是一U封装,虽然从云风那里出来的弃C++而{投C的声韛_能会影响一部分人,但是Q用什么语a本n是个h喜好及团队整体情况决定的。我们所要的也是最l的实现l果Q至于中间的步骤Q完全看个h。还是用云风的话_q只是一U信仰问题,我依焉用我所熟悉的C++Q下面的描述也是如此?/p>
随着面向对象技术的深入Q以及泛型等概念的相l提出,软gE序l构斚w的趋势也有了很大改变。C++大师们常说的话中有一句是q样说的Q尽是采用组合而不是ѝ游戏对象的实现也有cM的{变,向于以l合的方式来实现游戏对象cdQ也是实现一个通用的entitycdQ然后以脚本定义的方式组合出不同的实际游戏对象类型?/p>
描述的有些抽象,具体实现下一来仔细探讨下?br>
在游戏编E精_四有三文章讲C实体以及实体理的实现方案,其中一文章说C实体理pȝ的四大要素:定义实体怎样沟通的实体消息Q实C实体cM码和数据的实体代码,l护已经注册在案的实体类列表Q和用来创徏、管理、发送消息的实体理器?/p>
关于实体消息的内容之前讨Z件机制的时候做q一点说明,其实q也是按接口调用和按消息驱动的区别Q现在mangos的做法是完全的接口调用,所以引擎内部就没有M的实体消息。实体代码实现和实体理器是我们重点要讨论的内容?/p>
另有一文章也提到了用类l箋的方式实现游戏对象的两大问题Q一是它要求pȝ中的所有对象都必须从一个v点衍生而成Q也是说所有对象类在编译的时候已l确定,q可能是一个不受欢q的限制Q如果开发者决定添加新的对象类Q则必须要对基类有所了解Q方能支持新cR另一个问题在于所有的对象c都必须实现同样的一些底层函数?/p>
对于W二个问题,可以通过接口l承的方式来避免基类的方法太多。在mangos的实C采用了cM的方法,从Object虚基cL生的Unit和WorldObject仍然q是不可实例化的c,q两U对象定义了不同的属性和ҎQ分来实C同类型的对象。在游戏内部可以Ҏ对象的实际类型来Object指针向下转型为Unit或WorldObjectQ以调用需要的接口。方法虽然不够OOQ也q能解决问题。但是第一个问题是始终无法避免的?/p>
所以我们便有了通用实体q么一个概念,其主要方法是原来基cȝ接口q行分类Q分C个个不同的子cMQ然后以对象l合的方式来生成我们所需要的实际游戏对象cd。这个组合的q程可以通过脚本定义的方式,q样便可以在q行时生成ؓ同的对象cdQ也p决了上面提到的第一个问题?/p>
通用实体的实现方法在目前的游戏引擎及开源代码中也可以看到媄子。一个是BigWorldQ从提供的资料来看,其引擎只提供了一个entity游戏对象Q然后由游戏内容实现者通过xml和python脚本来自由定义不同类型的entitycdQ每U类型可有不同的property和不同的Ҏ。这样原来由基类定义的接口完全{Ud脚本定义Q具有非常强的灵zL?/p>
另外q有一个是CEL中的entity实现。按照CEL的描qͼentity可以是游戏中的Q意对象,包括玩家可交互的对象Q如钥匙、武器等Q也可以包括不能直接交互的对象,如游戏世界,甚至d链中的一部分{。entity本nq没有Q何特性,具体的功能实现需要靠附加property来完成。简单来_property才定义了entity可以做什么,至于该怎么做,那又是依靠behavior来定义。所以,最l在CEL中一个游戏对象其实是由entityl合了多个property及多个behavior而生成的?/p>
但是CEL中的property与BigWorld中的property意义不大一P在CEL中可定义的property其实是引擎内部要先提供的Q比如其CZ中所丄pcobject.mesh、pcmove.linear、pctools.inventory{,而BigWorld中的property是完全的自由定制。从q个角度来讲Q其实可以把CEL中的property看作是游戏的逻辑pȝQ也是我们上面所描述的,接口分类后所定义的子cR?/p>
由引擎内部提供可选择的property与BigWorld所采用的完全自由定制property其实本质上是相同的。在用BigWorld实现的游戏中Q也不可能ؓ每种游戏对象cd都完全从头定义propertyQ基于代码利用的原则Q也会先定义一些小c,然后在entitycd定义时以自定义property的方式来包含q些类。当Ӟ我没有用过BigWorldQ上面的描述也只是基于游戏实现的大原则所做出来的?/p>
描述的依然有些抽象,我们可以用wow及mangos代码来说明一下。mangos中ؓobject定义了一个属性集合,Ҏ对象cd的不同,q个属性集的大及保存数据也会有差异,另外游戏对象内部含有处理不同游戏逻辑的系l,如RestSystem、FloodFilterSystem、VariousSystem{等Q在player.h中以接口l的方式q行定义?/p>
如果要将q种l构改ؓ我们描述的通用entitypȝQ可以让object只提供property注册和删除的接口Q这里的property定义与CEL中的相同Q放在mangos中也是上面说的RestSystem、FloodFilterSystem、VariousSystemq些。然后也通过xml文g的方式定义我们所需要的游戏对象cdQ如player,creature,item{,不同的对象类型可以选择加蝲不同的propertyQ加载的原则是需要哪些功能就加蝲哪些property?/p>
对象的定义按上面的方法完成后Q对象的实现也需要做一些修攏V以前客L的消息是直接交由player来处理,AI也是直接调用creature的接口来完成一些功能,现在通用的entity内部已经没有M可用的方法,所有的实现都{Cproperty中,所以需要由各个property实现自己来注册感兴趣的事件及消息Qentity实现一个消息的转发Q{l对此感兴趣的property来处理。其余的实现没有什么不同了?/p>
当然Q我们再做一Ҏ展,让property不光由引擎来提供Q用脚本本n也能定义propertyQƈ且可以通过xml来注册这些propertyQ这样便实现了与BigWorld一L完全自由Ҏ。这其实也就是将很多用C++实现的功能{Ud了python中,q种做法可作为参考,但不一定对所有h合适,臛_在我看来Q这L实现也基本只能由E序员来做,所以让E序员选择自己最擅长的语a可能会更易于开发和调试?/p>
有关游戏对象实现的描qͼ前面两篇文章中说的不甚清楚,主要是一直都要引用网上能够找到的资料来进行描qͼ以避免与公司引v不必要的ȝ。所以语a有些拼凑的感觉,丄例子也很不恰当,今天正好看到了游戏编E精_五和六上的两篇文章Q内定w差不多,<<Zlg的对象管?gt;>?lt;<Zlg的游戏对象系l?gt;>Q说的也是我上两文章想要描q的内容Q所以再补一,引用其中的部分文字进行明的说明?/p>
传统的游戏对象管理系l采用承的方式来实玎ͼ例如Q所有的子类都从CObjectz。大多数情况下,直接z的也是抽象类Q其中带一些功能而另一些子cd不带q些功能Q比如可控制/不可控制Q可动画/不可动画{。mangos的实C基本是q种情况Q从Object直接z的Unit和WorldObject都是不可直接实例化的cR?/p>
传统Ҏ的问题在于无法应寚w求的变化Q如要求武器也有动画效果时就无法处理了。如果硬要是q样做,那随着需求的啬,很多的方法会被放到基cMQ最l的l果是承树变得来头重脚轻,q样的类会失它的内聚性,因ؓ它们试图为所有对象完成所有的事?/p>
是说到最后,基类会有一个很长的接口列表Q而很多的游戏对象cdҎ不需要实现其中的一些甚臛_部分接口Q但是按照这U结构却又必d实现。以至于于实C个非常庞大的对象Q而且惌修改一点功能会Dpȝ的大调整?/p>
我们希望的系l是可以现有的功能l合到新的对象中Qƈ且在新的功能添加到现有的对象中时不需要重构大量的代码和调整承树的结构?/p>
实现的方法就是从lg来创Z个对象。组件是一个包含所有相x据成员和Ҏ的类Q它完成某个特定的Q务。把几个lgl合在一起就可以创徏一个新的对象。如把Entitylg、Renderlg和Collectablelgl合在一L成了一个Spoon对象。Entitylg让我们可以把对象攑ֈ游戏世界中,Renderlg让我们可以ؓ对象指定一个模型进行渲染,而Collectablelg让我们可以拾取这个对象?/p>
关于lg的实玎ͼ所有的lg都从一个基lg接口zQ可U其为IComponent。每个组件也有自q接口定义Qƈ且这个接口也需要从IComponentzQ类gq样QIComponent -- ICmpRender -- CCmpRender
q里的每个组件也是我在上一中所说的由引擎提供的属性,或者说在BigWorld中自己实现然后定义的属性,或者用mangos中的定义Q就是一个个的SystemQ虽然mangosq没有将其完全做成组Ӟ但是通过其代码注释可以看刎ͼ接口也是按功能组q行了分c,如果要拆分成lg也是比较方便的?/p>
lg之间的通信有两U方法,一是用lgID查询到组件接口指针,然后调用接口ҎQ二是用消息的方式Q向对象中所有组件发消息。在初始化的时候,每一个组件类型都会告诉对象管理器应该接收什么样的消息?/p>
查询接口的方法也是直接的方法调用,只不q接口不是全部在基类中,所以必d查询到指定的lg然后才能调用其接口。消息的使用前面已经说过多次Q其实现Ҏ也有q说明?/p>
最后是关于游戏对象功能的扩展和游戏对象的定义。需要扩展功能也是需要实C个新的组Ӟ或者修改现在组件。在大多数情况下Q扩展都不会引vl构的很大调_受媄响的最多只是用到该组件的部分代码?/p>
游戏对象定义可采用完全数据驱动的方式Q用xml或者脚本语a来定义对象类型,以及每个cd需要加载的lg。对象类型注册到对象理器后Q由理器提供创建指定类型的对象的方法。数据驱动的方式能够让策划自由定义游戏对象类型,q且随时可自由创建新的对象类型?/p>