热血传奇服务端FIR0918源码服务端Actor继承关系以及注解

首先要声明一下，Fir0918服务端方面个人感觉实在是渣 代码各种乱入，写此博客只是记录自己学习的点滴。并不是来告诉大家fir的代码有多好。



TBaseObject 只有四个成员 对象所在地图的X,Y以及对象类型objType(玩家 英雄 NPC  事件 等等)。以及对象创建的时间使用GetTickCount。成员函数也只有一个构造函数。

TActorObject: TActorObject .从代码上看来是作为Actor超类 。但是此类内部实际耦合了太多Player的成员 比如 Socket 句柄 ，衣服样子 以及所属行会等等。而从结构上来看

TActorObject 只是作为一个抽象类来泛化人物 怪物 以及NPC的 具体功能。而此类却耦合太多的人物操作。所以这里并没有设计好。需要解耦。关于属性问题：其内部有三个关于属性的结构体成员：

    {人物属性}

    m_Abil: TAbility;  //人物临时属性。此结构体用来计算人物所在等级应具有的基本属性。之后再计算入m_wAbil内

    m_WAbil: TAbility; //人物主要属性。此结构体是人物的主要属性值记录。攻击伤害是以此结构体作为数据来计算。

    m_AddAbil: TAddAbility;//人物附加属性。此结构体 类似与TAbilty 。有不少重复的字段是一样的。其作用是计算人物身上穿戴装备的属性值。然后和m_Abil相加 赋值给    m_wAbil 。

TAnimalObject : 此类实现了Actor的搜寻 和攻击 以及 随机的走动方法。以及处理Socket消息的小实现。个人认为 此类功能应该在TActorObject内实现。再此多一层继承关系是没必要的。

TMonster :  此类作为怪物类的基类 实现了攻击目标 和基本逻辑处理(Run函数) 子类怪物继承自其要实现新的功能基本 是在Run内进行重写。

TAIObject : 此类 实现了自动控制的一些功能 但并未完全实现。从设计角度来看 此类是为英雄以及假人实现做抽象的。但是个人认为此类应该继承自TPlayObject  而不是让TPlayObject 继承自TAIObject 毕竟 玩家是不需要自动控制的吧。或许需要挂机的功能?

TNormalNPC: 此类实现了各种脚本功能的支持 #IF #ACT 条件的支持！其实有点不太理解 为什么此类需要从TAnimalObject继承。 而卫士类TSuperGuard继承自TNormalNpc 却只实现了攻击玩家这种方法。对于TNormalNPC实现的脚本功能卫士是使用不上的。

TAIPlayObject : 假人的实现。

THeroObject : 英雄的实现。

思考分析：从继承关系上来看TAnimalObject 不应该出现 此类应该集合在Actor类内。而TSuperGuard 也不应继承自TNormalNPC。 而且FIR的源代码内 Actor 也包含了TPlayObject 和 THeroObject的代码：从继承关系上来 应该从更新整理为以下关系



如果非得在服务端实现 人物的挂机功能。那么可以提取出一个公共接口。让假人 和玩家 ，英雄 各自实现 其智能化的功能。