Mangos源碼分析（15）：遊戲對象的實現

狹義的遊戲對象是指遊戲世界中所能看到及可交互的對象，如玩家、怪物、物品等，我們這裏也主要討論這類對象在服務器上的組織及實現。

　　在大部分的MMOG中，遊戲對象的類型都大同小異，主要有物品、生物、玩家等。比如在wow中，通過服務器發下來的GUID我們可以瞭解到，遊戲中有9大類對象，包括物品(Item)、揹包(Container)、生物(Unit)、玩家(Player)、遊戲對象(GameObject)、動態對象(DynamicObject)、屍體(Corpse)等。

　　在mangos的實現中，對象使用類繼承的方式，由Object基類定義遊戲對象的公有接口及屬性，包括GUID的生成及管理、構造及更新UpdateData數據的虛接口、設置及獲取對象屬性集的方法等。然後分出了兩類派生對象，一是Item，另一是WorldObject。Item即物品對象，WorldObject顧名思義，爲世界對象，即可添加到遊戲世界場景中的對象，該對象類型定義了純虛接口，也就是不可被實例化，主要是在Object對象的基礎上又添加了座標設置或獲取的相關接口。

　　Item類型又派兵出了一類Bag對象，這是一種特殊的物品對象，其本身具有物品的所有屬性及方法，但又可作爲新的容器類型，並具有自己特有的屬性和方法，所以實現上採用了派生。mangos在實現時對Bag的類型定義做了點小技巧，Item的類型爲2，Bag的類型爲6，這樣在通過位的方式來表示類型時，Bag類型也就同時屬於Item類型了。雖然只是很小的一個技巧，但在很多地方卻帶來了極大的便利。

　　從WorldObject派生出的類型就有好幾種了，Unit、GameObject、DynamicObject和Corpse。Unit爲所有生物類型的基類，同WorldObject一樣，也不可被實例化。它定義了生物類型的公有屬性，如種族、職業、性別、生命、魔法等，另外還提供了相關的一些操作接口。遊戲中實際的生物對象類型爲Creature，從Unit派生，另外還有一類派生對象Player爲玩家對象。Player與Creature在實現上最大的區別是玩家的操作由客戶端發來的消息驅動，而Creature的控制是由自己定義的AI對象來驅動，另外Player內部還包括了很多的邏輯系統實現。

　　另外還有兩類特殊的Creature，Pet和Totem，其對象類型仍然還是生物類，只是實現上與會有些特殊的東西需要處理，所以在mangos中將其作爲獨立的派生類，只是實現上的一點處理。另外在GameObject中也實現有派生對象，最終的繼承關係圖比較簡單，就不麻煩地去畫圖了。

　　從我所瞭解的早期遊戲實現來看，大部分的遊戲對象結構都是採用的類似這種方式。可能與早期對面向對象的理解有關，當面向對象的概念剛出來時，大家認爲繼承就是面向對象的全部，所以處處皆對象，處處皆繼承。

　　類實現的是一種封裝，雖然從雲風那裏出來的棄C++而轉投C的聲音可能會影響一部分人，但是，使用什麼語言本身就是個人喜好及團隊整體情況決定的。我們所要的也是最終的實現結果，至於中間的步驟，完全看個人。還是用雲風的話說，這只是一種信仰問題，我依然採用我所熟悉的C++，下面的描述也是如此。

　　隨着面向對象技術的深入，以及泛型等概念的相繼提出，軟件程序結構方面的趨勢也有了很大改變。C++大師們常說的話中有一句是這樣說的，盡是採用組合而不是繼承。遊戲對象的實現也有類似的轉變，趨向於以組合的方式來實現遊戲對象類型，也就是實現一個通用的entity類型，然後以腳本定義的方式組合出不同的實際遊戲對象類型。

　　描述的有些抽象，具體實現下一篇來仔細探討下。

在遊戲編程精粹四有三篇文章講到了實體以及實體管理的實現方案，其中一篇文章說到了實體管理系統的四大要素：定義實體怎樣溝通的實體消息，實現一實體類代碼和數據的實體代碼，維護已經註冊在案的實體類列表，和用來創建、管理、發送消息的實體管理器。

　　關於實體消息的內容之前討論事件機制的時候做過一點說明，其實這也就是按接口調用和按消息驅動的區別，現在mangos的做法是完全的接口調用，所以引擎內部就沒有任何的實體消息。實體代碼實現和實體管理器是我們重點要討論的內容。

　　另有一篇文章也提到了使用類繼續的方式實現遊戲對象的兩大問題，一是它要求系統中的所有對象都必須從一個起點衍生而成，也就是說所有對象類在編譯的時候已經確定，這可能是一個不受歡迎的限制，如果開發者決定添加新的對象類，則必須要對基類有所瞭解，方能支持新類。另一個問題在於所有的對象類都必須實現同樣的一些底層函數。

　　對於第二個問題，可以通過接口繼承的方式來避免基類的方法太多。在mangos的實現中就採用了類似的方法，從Object虛基類派生的Unit和WorldObject仍然還是不可實例化的類，這兩種對象定義了不同的屬性和方法，分來實現不同類型的對象。在遊戲內部可以根據對象的實際類型來Object指針向下轉型爲Unit或WorldObject，以調用需要的接口。方法雖然不夠OO，也還能解決問題。但是第一個問題是始終無法避免的。

　　所以我們便有了通用實體這麼一個概念，其主要方法是將原來基類的接口進行分類，分到一個個不同的子類中，然後以對象組合的方式來生成我們所需要的實際遊戲對象類型。這個組合的過程可以通過腳本定義的方式，這樣便可以在運行時生成爲同的對象類型，也就解決了上面提到的第一個問題。

　　通用實體的實現方法在目前的遊戲引擎及開源代碼中也可以看到影子。一個是BigWorld，從提供的資料來看，其引擎只提供了一個entity遊戲對象，然後由遊戲內容實現者通過xml和python腳本來自由定義不同類型的entity類型，每種類型可有不同的property和不同的方法。這樣原來由基類定義的接口完全轉移到腳本定義，具有非常強的靈活性。

　　另外還有一個是CEL中的entity實現。按照CEL的描述，entity可以是遊戲中的任意對象，包括玩家可交互的對象，如鑰匙、武器等，也可以包括不能直接交互的對象，如遊戲世界，甚至任務鏈中的一部分等。entity本身並沒有任何特性，具體的功能實現需要靠附加property來完成。簡單來說，property才定義了entity可以做什麼，至於該怎麼做，那又是依靠behavior來定義。所以，最終在CEL中一個遊戲對象其實是由entity組合了多個property及多個behavior而生成的。

　　但是CEL中的property與BigWorld中的property意義不大一樣，在CEL中可定義的property其實是引擎內部要先提供的，比如其示例中所舉的pcobject.mesh、pcmove.linear、pctools.inventory等，而BigWorld中的property是完全的自由定製。從這個角度來講，其實可以把CEL中的property看作是遊戲的邏輯系統，也就是我們上面所描述的，接口分類後所定義的子類。

　　由引擎內部提供可選擇的property與BigWorld所採用的完全自由定製property其實本質上是相同的。在用BigWorld實現的遊戲中，也不可能爲每種遊戲對象類型都完全從頭定義property，基於代碼利用的原則，也會先定義一些小類，然後在entity類型定義時以自定義property的方式來包含這些小類。當然，我沒有使用過BigWorld，上面的描述也只是基於遊戲實現的大原則所做出來的。

　　描述的依然有些抽象，我們可以用wow及mangos代碼來說明一下。mangos中爲object定義了一個屬性集合，根據對象類型的不同，這個屬性集的大小及保存數據也會有差異，另外遊戲對象內部含有處理不同遊戲邏輯的系統，如RestSystem、FloodFilterSystem、VariousSystem等等，在player.h中以接口組的方式進行定義。

　　如果要將這種結構改爲我們描述的通用entity系統，可以讓object只提供property註冊和刪除的接口，這裏的property定義與CEL中的相同，放在mangos中也就是上面說的RestSystem、FloodFilterSystem、VariousSystem這些。然後也通過xml文件的方式定義我們所需要的遊戲對象類型，如player,creature,item等，不同的對象類型可以選擇加載不同的property，加載的原則是需要哪些功能就加載哪些property。

　　對象的定義按上面的方法完成後，對象的實現也需要做一些修改。以前客戶端的消息是直接交由player來處理，AI也是直接調用creature的接口來完成一些功能，現在通用的entity內部已經沒有任何可用的方法，所有的實現都轉到了property中，所以需要由各個property實現自己來註冊感興趣的事件及消息，entity實現一個消息的轉發，轉給對此感興趣的property來處理。其餘的實現就沒有什麼不同了。

　　當然，我們再做一點擴展，讓property不光由引擎來提供，用腳本本身也能定義property，並且可以通過xml來註冊這些property，這樣便實現了與BigWorld一樣的完全自由特性。這其實也就是將很多用C++實現的功能轉移到了python中，這種做法可作爲參考，但不一定對所有人合適，至少在我看來，這樣的實現也基本只能由程序員來做，所以讓程序員選擇自己最擅長的語言可能會更易於開發和調試。

有關遊戲對象實現的描述，前面兩篇文章中說的不甚清楚，主要是一直都要引用網上能夠找到的資料來進行描述，以避免與公司引起不必要的麻煩。所以語言有些拼湊的感覺，舉的例子也很不恰當，今天正好看到了遊戲編程精粹五和六上的兩篇文章，內容都差不多，<<基於組件的對象管理>>和<<基於組件的遊戲對象系統>>，說的也是我上兩篇文章想要描述的內容，所以再補一篇，引用其中的部分文字進行明確的說明。



　　傳統的遊戲對象管理系統採用繼承的方式來實現，例如，所有的子類都從CObject派生。大多數情況下，直接派生的也是抽象類，其中帶一些功能而另一些子類則不帶這些功能，比如可控制/不可控制，可動畫/不可動畫等。mangos的實現中基本就是這種情況，從Object直接派生的Unit和WorldObject都是不可直接實例化的類。

　　傳統方法的問題在於無法應對需求的變化，如要求武器也有動畫效果時就無法處理了。如果硬要是這樣做，那隨着需求的嗇，很多的方法會被放到基類中，最終的結果是繼承樹變得越來越頭重腳輕，這樣的類會喪失它的內聚性，因爲它們試圖爲所有對象完成所有的事。

　　就是說到最後，基類會有一個很長的接口列表，而很多的遊戲對象類型根本不需要實現其中的一些甚至大部分接口，但是按照這種結構卻又必須去實現。以至於於實現一個非常龐大的對象，而且想要修改一點功能會導致系統的大調整。

　　我們希望的系統是可以將現有的功能組合到新的對象中，並且在將新的功能添加到現有的對象中時不需要重構大量的代碼和調整繼承樹的結構。

　　實現的方法就是從組件來創建一個對象。組件是一個包含所有相關數據成員和方法的類，它完成某個特定的任務。把幾個組件組合在一起就可以創建一個新的對象。如把Entity組件、Render組件和Collectable組件組合在一起生成了一個Spoon對象。Entity組件讓我們可以把對象放到遊戲世界中，Render組件讓我們可以爲對象指定一個模型進行渲染，而Collectable組件讓我們可以拾取這個對象。

　　關於組件的實現，所有的組件都從一個基礎組件接口派生，可稱其爲IComponent。每個組件也有自己的接口定義，並且這個接口也需要從IComponent派生，類似於這樣：IComponent -- ICmpRender -- CCmpRender

　　這裏的每個組件也就是我在上一篇中所說的由引擎提供的屬性，或者說在BigWorld中自己實現然後定義的屬性，或者使用mangos中的定義，就是一個個的System，雖然mangos並沒有將其完全做成組件，但是通過其代碼註釋可以看到，接口也是按功能組進行了分類，如果要拆分成組件也是比較方便的。

　　組件之間的通信有兩種方法，一是用組件ID查詢到組件接口指針，然後調用接口方法；二是使用消息的方式，向對象中所有組件發消息。在初始化的時候，每一個組件類型都會告訴對象管理器應該接收什麼樣的消息。

　　查詢接口的方法也就是直接的方法調用，只不過接口不是全部在基類中，所以必須先查詢到指定的組件然後才能調用其接口。消息的使用前面已經說過多次，其實現方案也有過說明。

　　最後是關於遊戲對象功能的擴展和遊戲對象的定義。需要擴展功能也就是需要實現一個新的組件，或者修改現在組件。在大多數情況下，擴展都不會引起結構的很大調整，受影響的最多隻是使用到該組件的部分代碼。

　　遊戲對象定義可採用完全數據驅動的方式，使用xml或者腳本語言來定義對象類型，以及每個類型需要加載的組件。對象類型註冊到對象管理器後，由管理器提供創建指定類型的對象的方法。數據驅動的方式能夠讓策劃自由定義遊戲對象類型，並且隨時可自由創建新的對象類型。