熱血傳奇服務端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的代碼:從繼承關系上來 應該從更新整理為以下關系


如果非得在服務端實現 人物的掛機功能。那么可以提取出一個公共接口。讓假人 和玩家 ,英雄 各自實現 其智能化的功能。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com