OO的应用~~~对游戏中涉及到的人,事,物进行抽象和分类

邺剑云

不知道楼主用没用过RMXP。我觉得RMXP和你所说的差不多。

游戏中的地图元件，可变化图块元件设计2个，例如一个池子，那么就先做2个，一个有水的无法通行，一个无水的可以通行。 而改变这个地图元件，可以设置一个事件，事件的触发条件为调查池塘旁边的水闸，出发后执行更换地图元件，更换过程中可演示动画。还有如果森林的地图元件和树木的模型都有2种形式，一种是正常，一种是火灾，然后事件的触发条件为在森林中使用火把。

如果让游戏世界更丰富自然互动。可以利用这些事件条件来达成。 我通过RMXP实现了很多。

如果楼主，想实现某个功能，给我个具体项目，我给你试试/。

nwin9x2

RMXP听说过,看过一些示范的作品.RMXP的系统设计是很精良的,我很佩服它的作者们.
我认为,在设计一个网游项目时,逻辑世界就要设计成这样的效果.使得项目在维护期可以用纯资源来配置出丰富的变化.

123790178

支持楼主
网络游戏的设计就应该面向微观静态对象，完善细节，
面向宏观动态过程进行设计是延用单机游戏的设计思维习惯，应该改改了

6spring

典型的 “is a” 型继承，其实也可以考虑 “have a” 的架构方式。

nwin9x2

在游戏项目中,"is a"的关系往往用配数据的方式就可以配出来.例如:
#单匹的马:
其实相当于"只有一个座位/两个座位"的马车,就是说"座位"的数量不同了.此外,包围盒子,物理运动参数和美工资源有变化.
但要表达"has a"的关系,一般情况下都要写程序了(C++代码/脚本等等).
我认为,在复杂度有限的情况下,还是尽量用"is a".不得已时才动手去编个"has a".

卡特铁角

我是觉得继承关系"is a"和聚合关系的"has a"各有优势.

"is a"只要做得好,能在保证一定扩展性的基础上,让之后的编辑工作变得相对容易一些;但其可扩展性始终不如"has a"的方式.

"is a"的难度在于,对游戏主题所关注的事物特征的把握和分类,若这步考虑得不够周全合理,则会对系统的可扩展性造成很大的限制,又或浪费资源.

如果你们的策划有一定的程序基础,具备一定的脚本编写能力,采用"has a"的方式也未必不是一种好的选择.

madmonkey

昨天看电视看了个笑话,是关于MBA的

MBA里有个叫矩阵分析法.于是拿生活中的丈母娘选女婿做例子,老实为x坐标,能干为y坐标.

于是,老实又能干的为上上选,老实的保持关注,能干的可以培养,不老实又不能干的直接KICK OUT.

于是主持人冒了一句"真要这样过日子,人都得疯了."

6spring

其实主要是 "is a" 会使得整个架构无休止的加深。
在前期层次浅的时候，不觉得问题，但是随着时间推移，各种变动会使得树的层次无法控制，有时低节点需要一个变动，甚至不知道该到哪个层次去修改（MFC最被人诟病的就是这个），而且一个高层次节点变动，基本无法控制其造成的所有影响（比如说，高节点增加了一个属性，有子节点原本就有个同名属性，此时麻烦就出来了）。

nwin9x2

楼上的言重了.一个游戏项目可不会有MFC这么复杂.而且游戏项目的生命期很短,1~3年吧.到了时间就可以完全推倒重来了.

6spring

原来曾设想过一种全聚合方式来构成这种对象体系，不过有没有去具体设计

基本思路是 逻辑对象，全部看作容器，容器里放上某种属性对象，他就具有这种属性，移除某种属性对象，就失去该属性。

比如说
AddAttribute(Name,IBaseAttributeObj*);
DelAttribute(Name);
IBaseAttributeObj* GetAddAttribute(Name);

SetValue(Name,value);
GetValue(Name,value&);

这样，比如说交通工具，就是 添加 "移动控制"，"容纳其他对象"
大船，除了上面，再添加 "区域地图"