在大部分的MMOG中，游戲?qū)ο蟮念愋投即笸‘悾饕形锲贰⑸铩⑼婕业取１热缭趙ow中，通過服務(wù)器發(fā)下來的GUID我們可以了解到，游戲中有9大類對象，包括物品(Item)、背包(Container)、生物(Unit)、玩家(Player)、游戲?qū)ο?GameObject)、動態(tài)對象(DynamicObject)、尸體(Corpse)等。

　　在mangos的實(shí)現(xiàn)中，對象使用類繼承的方式，由Object基類定義游戲?qū)ο蟮墓薪涌诩皩傩裕℅UID的生成及管理、構(gòu)造及更新UpdateData數(shù)據(jù)的虛接口、設(shè)置及獲取對象屬性集的方法等。然后分出了兩類派生對象，一是Item，另一是WorldObject。Item即物品對象，WorldObject顧名思義，為世界對象，即可添加到游戲世界場景中的對象，該對象類型定義了純虛接口，也就是不可被實(shí)例化，主要是在Object對象的基礎(chǔ)上又添加了坐標(biāo)設(shè)置或獲取的相關(guān)接口。

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

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

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

　　從我所了解的早期游戲?qū)崿F(xiàn)來看，大部分的游戲?qū)ο蠼Y(jié)構(gòu)都是采用的類似這種方式。可能與早期對面向?qū)ο蟮睦斫庥嘘P(guān)，當(dāng)面向?qū)ο蟮母拍顒偝鰜頃r(shí)，大家認(rèn)為繼承就是面向?qū)ο蟮娜浚蕴幪幗詫ο螅幪幗岳^承。

　　類實(shí)現(xiàn)的是一種封裝，雖然從云風(fēng)那里出來的棄C++而轉(zhuǎn)投C的聲音可能會影響一部分人，但是，使用什么語言本身就是個(gè)人喜好及團(tuán)隊(duì)整體情況決定的。我們所要的也是最終的實(shí)現(xiàn)結(jié)果，至于中間的步驟，完全看個(gè)人。還是用云風(fēng)的話說，這只是一種信仰問題，我依然采用我所熟悉的C++，下面的描述也是如此。

　　隨著面向?qū)ο蠹夹g(shù)的深入，以及泛型等概念的相繼提出，軟件程序結(jié)構(gòu)方面的趨勢也有了很大改變。C++大師們常說的話中有一句是這樣說的，盡是采用組合而不是繼承。游戲?qū)ο蟮膶?shí)現(xiàn)也有類似的轉(zhuǎn)變，趨向于以組合的方式來實(shí)現(xiàn)游戲?qū)ο箢愋停簿褪菍?shí)現(xiàn)一個(gè)通用的entity類型，然后以腳本定義的方式組合出不同的實(shí)際游戲?qū)ο箢愋汀?/p>

　　

         在游戲編程精粹四有三篇文章講到了實(shí)體以及實(shí)體管理的實(shí)現(xiàn)方案，其中一篇文章說到了實(shí)體管理系統(tǒng)的四大要素：定義實(shí)體怎樣溝通的實(shí)體消息，實(shí)現(xiàn)一實(shí)體類代碼和數(shù)據(jù)的實(shí)體代碼，維護(hù)已經(jīng)注冊在案的實(shí)體類列表，和用來創(chuàng)建、管理、發(fā)送消息的實(shí)體管理器。

　　關(guān)于實(shí)體消息的內(nèi)容之前討論事件機(jī)制的時(shí)候做過一點(diǎn)說明，其實(shí)這也就是按接口調(diào)用和按消息驅(qū)動的區(qū)別，現(xiàn)在mangos的做法是完全的接口調(diào)用，所以引擎內(nèi)部就沒有任何的實(shí)體消息。實(shí)體代碼實(shí)現(xiàn)和實(shí)體管理器是我們重點(diǎn)要討論的內(nèi)容。

　　另有一篇文章也提到了使用類繼續(xù)的方式實(shí)現(xiàn)游戲?qū)ο蟮膬纱髥栴}，一是它要求系統(tǒng)中的所有對象都必須從一個(gè)起點(diǎn)衍生而成，也就是說所有對象類在編譯的時(shí)候已經(jīng)確定，這可能是一個(gè)不受歡迎的限制，如果開發(fā)者決定添加新的對象類，則必須要對基類有所了解，方能支持新類。另一個(gè)問題在于所有的對象類都必須實(shí)現(xiàn)同樣的一些底層函數(shù)。

　　對于第二個(gè)問題，可以通過接口繼承的方式來避免基類的方法太多。在mangos的實(shí)現(xiàn)中就采用了類似的方法，從Object虛基類派生的Unit和WorldObject仍然還是不可實(shí)例化的類，這兩種對象定義了不同的屬性和方法，分來實(shí)現(xiàn)不同類型的對象。在游戲內(nèi)部可以根據(jù)對象的實(shí)際類型來Object指針向下轉(zhuǎn)型為Unit或WorldObject，以調(diào)用需要的接口。方法雖然不夠OO，也還能解決問題。但是第一個(gè)問題是始終無法避免的。

　　所以我們便有了通用實(shí)體這么一個(gè)概念，其主要方法是將原來基類的接口進(jìn)行分類，分到一個(gè)個(gè)不同的子類中，然后以對象組合的方式來生成我們所需要的實(shí)際游戲?qū)ο箢愋汀＿@個(gè)組合的過程可以通過腳本定義的方式，這樣便可以在運(yùn)行時(shí)生成為同的對象類型，也就解決了上面提到的第一個(gè)問題。

　　通用實(shí)體的實(shí)現(xiàn)方法在目前的游戲引擎及開源代碼中也可以看到影子。一個(gè)是BigWorld，從提供的資料來看，其引擎只提供了一個(gè)entity游戲?qū)ο螅缓笥捎螒騼?nèi)容實(shí)現(xiàn)者通過xml和python腳本來自由定義不同類型的entity類型，每種類型可有不同的property和不同的方法。這樣原來由基類定義的接口完全轉(zhuǎn)移到腳本定義，具有非常強(qiáng)的靈活性。

　　另外還有一個(gè)是CEL中的entity實(shí)現(xiàn)。按照CEL的描述，entity可以是游戲中的任意對象，包括玩家可交互的對象，如鑰匙、武器等，也可以包括不能直接交互的對象，如游戲世界，甚至任務(wù)鏈中的一部分等。entity本身并沒有任何特性，具體的功能實(shí)現(xiàn)需要靠附加property來完成。簡單來說，property才定義了entity可以做什么，至于該怎么做，那又是依靠behavior來定義。所以，最終在CEL中一個(gè)游戲?qū)ο笃鋵?shí)是由entity組合了多個(gè)property及多個(gè)behavior而生成的。

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

　　由引擎內(nèi)部提供可選擇的property與BigWorld所采用的完全自由定制property其實(shí)本質(zhì)上是相同的。在用BigWorld實(shí)現(xiàn)的游戲中，也不可能為每種游戲?qū)ο箢愋投纪耆珡念^定義property，基于代碼利用的原則，也會先定義一些小類，然后在entity類型定義時(shí)以自定義property的方式來包含這些小類。當(dāng)然，我沒有使用過BigWorld，上面的描述也只是基于游戲?qū)崿F(xiàn)的大原則所做出來的。

　　描述的依然有些抽象，我們可以用wow及mangos代碼來說明一下。mangos中為object定義了一個(gè)屬性集合，根據(jù)對象類型的不同，這個(gè)屬性集的大小及保存數(shù)據(jù)也會有差異，另外游戲?qū)ο髢?nèi)部含有處理不同游戲邏輯的系統(tǒng)，如RestSystem、FloodFilterSystem、VariousSystem等等，在player.h中以接口組的方式進(jìn)行定義。

　　如果要將這種結(jié)構(gòu)改為我們描述的通用entity系統(tǒng)，可以讓object只提供property注冊和刪除的接口，這里的property定義與CEL中的相同，放在mangos中也就是上面說的RestSystem、FloodFilterSystem、VariousSystem這些。然后也通過xml文件的方式定義我們所需要的游戲?qū)ο箢愋停鏿layer,creature,item等，不同的對象類型可以選擇加載不同的property，加載的原則是需要哪些功能就加載哪些property。

　　對象的定義按上面的方法完成后，對象的實(shí)現(xiàn)也需要做一些修改。以前客戶端的消息是直接交由player來處理，AI也是直接調(diào)用creature的接口來完成一些功能，現(xiàn)在通用的entity內(nèi)部已經(jīng)沒有任何可用的方法，所有的實(shí)現(xiàn)都轉(zhuǎn)到了property中，所以需要由各個(gè)property實(shí)現(xiàn)自己來注冊感興趣的事件及消息，entity實(shí)現(xiàn)一個(gè)消息的轉(zhuǎn)發(fā)，轉(zhuǎn)給對此感興趣的property來處理。其余的實(shí)現(xiàn)就沒有什么不同了。

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




有關(guān)游戲?qū)ο髮?shí)現(xiàn)的描述，前面兩篇文章中說的不甚清楚，主要是一直都要引用網(wǎng)上能夠找到的資料來進(jìn)行描述，以避免與公司引起不必要的麻煩。所以語言有些拼湊的感覺，舉的例子也很不恰當(dāng)，今天正好看到了游戲編程精粹五和六上的兩篇文章，內(nèi)容都差不多，<<基于組件的對象管理>>和<<基于組件的游戲?qū)ο笙到y(tǒng)>>，說的也是我上兩篇文章想要描述的內(nèi)容，所以再補(bǔ)一篇，引用其中的部分文字進(jìn)行明確的說明。

　　傳統(tǒng)的游戲?qū)ο蠊芾硐到y(tǒng)采用繼承的方式來實(shí)現(xiàn)，例如，所有的子類都從CObject派生。大多數(shù)情況下，直接派生的也是抽象類，其中帶一些功能而另一些子類則不帶這些功能，比如可控制/不可控制，可動畫/不可動畫等。mangos的實(shí)現(xiàn)中基本就是這種情況，從Object直接派生的Unit和WorldObject都是不可直接實(shí)例化的類。

　　傳統(tǒng)方法的問題在于無法應(yīng)對需求的變化，如要求武器也有動畫效果時(shí)就無法處理了。如果硬要是這樣做，那隨著需求的嗇，很多的方法會被放到基類中，最終的結(jié)果是繼承樹變得越來越頭重腳輕，這樣的類會喪失它的內(nèi)聚性，因?yàn)樗鼈冊噲D為所有對象完成所有的事。

　　就是說到最后，基類會有一個(gè)很長的接口列表，而很多的游戲?qū)ο箢愋透静恍枰獙?shí)現(xiàn)其中的一些甚至大部分接口，但是按照這種結(jié)構(gòu)卻又必須去實(shí)現(xiàn)。以至于于實(shí)現(xiàn)一個(gè)非常龐大的對象，而且想要修改一點(diǎn)功能會導(dǎo)致系統(tǒng)的大調(diào)整。

　　我們希望的系統(tǒng)是可以將現(xiàn)有的功能組合到新的對象中，并且在將新的功能添加到現(xiàn)有的對象中時(shí)不需要重構(gòu)大量的代碼和調(diào)整繼承樹的結(jié)構(gòu)。

　　實(shí)現(xiàn)的方法就是從組件來創(chuàng)建一個(gè)對象。組件是一個(gè)包含所有相關(guān)數(shù)據(jù)成員和方法的類，它完成某個(gè)特定的任務(wù)。把幾個(gè)組件組合在一起就可以創(chuàng)建一個(gè)新的對象。如把Entity組件、Render組件和Collectable組件組合在一起生成了一個(gè)Spoon對象。Entity組件讓我們可以把對象放到游戲世界中，Render組件讓我們可以為對象指定一個(gè)模型進(jìn)行渲染，而Collectable組件讓我們可以拾取這個(gè)對象。

　　關(guān)于組件的實(shí)現(xiàn)，所有的組件都從一個(gè)基礎(chǔ)組件接口派生，可稱其為IComponent。每個(gè)組件也有自己的接口定義，并且這個(gè)接口也需要從IComponent派生，類似于這樣：IComponent -- ICmpRender -- CCmpRender M

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

　　組件之間的通信有兩種方法，一是用組件ID查詢到組件接口指針，然后調(diào)用接口方法；二是使用消息的方式，向?qū)ο笾兴薪M件發(fā)消息。在初始化的時(shí)候，每一個(gè)組件類型都會告訴對象管理器應(yīng)該接收什么樣的消息。

　　查詢接口的方法也就是直接的方法調(diào)用，只不過接口不是全部在基類中，所以必須先查詢到指定的組件然后才能調(diào)用其接口。消息的使用前面已經(jīng)說過多次，其實(shí)現(xiàn)方案也有過說明。

　　最后是關(guān)于游戲?qū)ο蠊δ艿臄U(kuò)展和游戲?qū)ο蟮亩x。需要擴(kuò)展功能也就是需要實(shí)現(xiàn)一個(gè)新的組件，或者修改現(xiàn)在組件。在大多數(shù)情況下，擴(kuò)展都不會引起結(jié)構(gòu)的很大調(diào)整，受影響的最多只是使用到該組件的部分代碼。

　　游戲?qū)ο蠖x可采用完全數(shù)據(jù)驅(qū)動的方式，使用xml或者腳本語言來定義對象類型，以及每個(gè)類型需要加載的組件。對象類型注冊到對象管理器后，由管理器提供創(chuàng)建指定類型的對象的方法。數(shù)據(jù)驅(qū)動的方式能夠讓策劃自由定義游戲?qū)ο箢愋停⑶译S時(shí)可自由創(chuàng)建新的對象類型。