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

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

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

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

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

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

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

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

　　描述的有些抽象，具體實(shí)現(xiàn)下一篇來(lái)仔細(xì)探討下。


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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