游戏对象行为模型设计

ricyangliu

游戏对象的行为模型
首先这里作个说明，游戏对象暂时只指逻辑游戏世界中的事物对象，比如说一个人或者怪或者食物。作为游戏中的对象，我们可以发现，他们很多的行为实际上共同的，通过面向对象的分析，我们可以把这些行为（比如说move fly run等）做到相应的对象层次中去，这是通常的做法，这里我想说的是另外一个做法。
我们可以把这些所谓的跑，跳，飞等行为各自做成一个行为组件，且这些组件和跑跳飞需要的初始和属性数据是分离的，行为仅仅就是行为，不包含数据（尽量），只有一系列的接口。然后我们就可以给每个类型的对象创建一个行为表，分别是行为名称和行为对象一一映射，通过这样的方式我们可以动态加载游戏对象的行为，同时，这里的行为组件的替换也比较方便，只需要单独修改行为组件就OK了。而行为组件需要的数据的保存我还没有想的太清除，原则上讲一部分数据可以是该游戏对象的私有数据，游戏对象可以有一个或多个接口对组件和需要的数据建立一个绑定，当然，这里的私有数据必须是游戏对象的不可没的基本属性，否则这里的绑定就失去了意义。
采用这种方式，我对一个游戏对象加载一个”move”的行为，可以是2D场景下的MOVE，也可以是3D场景下的MOVE，真的是很灵活。
当然，这里的组件的定义标准并不是WINDOWS上面那么严格的定义（对于游戏开发团队，好像也没有必要那样做）。这里的组件库，可以是你自己的类库什么的。
应为只是初步设想，所以实现细节就没有做太多，如果觉得还可以的话我会把细节放上来。此外，我对服务器游戏世界的框架建设有一点点心得，下次再放上来献丑。
[em1]

谜の名侦探

不错的想法，对象层次是一种纵深方向的设计思路，
你这种想法是横向思维。

ricyangliu

谢谢！
我原本的设想是减少对象层次，但是这样必然造成很多重复的行为功能，所以有了这个想法。严格上讲，这种做法是《面向对象游戏开发》所推崇的一种做法，但个人感觉设计上的要求还是有点高。
在我现在业余进行的一个项目中，服务端游戏对象（还是指的是游戏中的实体，如怪之类的）的层次我只用了3层，是完全按照对象性质为标准来划分，也许有人会觉得3层是远远不够的，但我会尽快将我的设计思想放上，因为我有办法将很多按功能划分的层次通过一种合理和独立的模式来调整，就个人觉得，这将是一种很松散的结构，至于效率上我暂时没有考虑（臭美一下先），我的做法将避免很多层次问题带来的维护，修改上的复杂性。（工作上的项目，一个MMORPG游戏，即将完成，就是因为层次太多，修改和维护极其不爽，不过我不是主程序，并且也不可能从构架上修改。）

谜の名侦探

层次过多却是挺烦得，不过也有很多好处。
我以前做的一个东西，也考虑过这种方式，将功能独立成插件，不过在过程中遇到了很多困难。

ricyangliu

郁闷，这才是有趣和长远的东西啊，怎么大家都只对程序感兴趣呢，弄几个骨骼动画，blt几张图就可以做游戏了吗？？幼稚。

justlikethewind

哦……看不出这样的设计和listener相比有什么本质上的差别。楼主提示一下吧。

whb9633

仿佛现在很多游戏把行为设计归结为事件(Event)......,事件分为触发、执行、结束三过程....因为事件采用的是消息模型或类似于C#的面向对象事件模型，然后可能采用soap协议+xml进行传输....嘿嘿...楼主的设计还太嫩

ricyangliu

晕菜～～～
     我也不太明白楼上这位仁兄的意思，这里的行为，显然是指player,npc,monster之类的类式跑，跳，打，使用道具，飞行等等之类的行为，和传输消息没有任何关系，这只是在游戏服务器端的对游戏对象的描述，至于触发事件机制于其本质的行为动作描述有何关系？？而如果需要通知其他模块或者客户端该对象的行为结果则是通过消息机制来完成，包括服务器对象之间的消息传递以及服务器TO客户端之间的消息传递。我已经强调了，这是一种游戏对象的动作行为设计的方法，而楼上所理解的显然何我想描述的不太一样（也许是我说的有问题）。在我现在的公司所做的一个MMORPG中，就是因为这个方面做的不太好所以我才有这种想法。强烈建议楼上这位读读《面向对象的游戏设计》这本书中的“组件”部分，或者请你再说清除一些，否则我真的不明白我的设计错在哪和有哪个地方不适合。