在游戲引擎中，Entity通常被翻譯成實(shí)體，也常用諸如GameObject、Actor、SimulationObject、Unit、Character等名字。相比于對圖像聲音引擎的熱情，Entity層多年來一直備受冷遇，但最近幾年隨著大型游戲的發(fā)展，Entity層設(shè)計的重要性已經(jīng)達(dá)到和圖像聲音的同等水平，而且已經(jīng)出現(xiàn)了多種通用型Entity架構(gòu)。當(dāng)然，這里伴隨著爭議和分歧。

直接模式（The C Approach）

這是最早、最簡單、也是任何人都能直接想到的模式。這種方式下一個Entity就是一個簡單的struct:

struct Mob
{
int level, hp, mp, attack, …;
};

這種情況下往往需要對不同類型的Entity定義不同的struct，比如Player、Mob、Item、Doodad等。Entity的數(shù)據(jù)庫可以直接使用現(xiàn)成的數(shù)據(jù)庫系統(tǒng)或者從數(shù)據(jù)文件讀取，比如csv文件。一般會選擇Excel編輯數(shù)據(jù)庫，然后導(dǎo)出csv。Excel的強(qiáng)大表格和統(tǒng)計計算功能是調(diào)節(jié)游戲數(shù)據(jù)平衡的得力工具。以致這種最古老而簡單的Entity模式以強(qiáng)大的生命力一直活到現(xiàn)在。

那么為什么Developers會要去探索其他方式呢？最大的問題是這種方式下各種Entity完全不同質(zhì)。比如Player、Mob、Doodad都有位置，都要做碰撞檢測，但他們卻是不同的類型，不能使用同一份代碼；Player和Mob都有hp和mp，也有基本相同的處理邏輯……當(dāng)然，這個可以用hack的方法解決：只要各個struct前若干個成員類型和順序完全相同，就可以將指針cast成統(tǒng)一的一個Entity類型來處理。不過，任何人都能想到更好的辦法，用類！

繼承模式（Inheritage）

這也是Entity、GameObject等這些名字的由來，他們就是基類。于是我們可以得到一顆繼承關(guān)系樹，例如：

Entity

       Character

              Player

              Mob

       Missile

              Laser

              GuidedMissile

       Item

       …

Entity對象的邏輯大多也是直接包含在類里的。但也有人采用了數(shù)據(jù)對象和邏輯對象的分離，其好處是對相同的數(shù)據(jù)可以替換不同的邏輯。不過，個人比較懷疑這種分離是否值得，因?yàn)轭惖呐缮旧砭褪强梢該碛胁煌倪壿嫛?/span>

另外，Entity間的交互除了用標(biāo)準(zhǔn)的直接訪問方式外，經(jīng)常使用消息模式。消息模式和Windows的消息模式類似，Entity間通過消息交互。雖說窗口編程畫了多年時間才擺脫了當(dāng)年肥大的switch的消息處理模式，在Entity層使用消息模式還是有意義的，因?yàn)橄⒑苋菀讖V播且可以直接在網(wǎng)絡(luò)上發(fā)送。執(zhí)著于OO的人會將消息寫成Command對象，但原理仍然是一樣的。

同時，聯(lián)網(wǎng)游戲出現(xiàn)，指針不能在不同的機(jī)器上標(biāo)識對象，我們必須用穩(wěn)定的ID來標(biāo)識對象，于是我們有了EntityManager來分配ID和管理對象集合，或者叫GameObjectManager、ObjectManager等。這在一段時期內(nèi)幾乎成了完美的方案。

隨著游戲內(nèi)容的豐富性的迅速膨脹，傳統(tǒng)的由程序員來實(shí)現(xiàn)游戲邏輯功能的模式也越來越力不從心。腳本語言的集成將大部分創(chuàng)意性工作從程序員的擔(dān)子上拿了下來，交還給游戲設(shè)計人員。為了給腳本提供足夠的控制權(quán)，Entity結(jié)構(gòu)上必須有充分的靈活性。

數(shù)據(jù)驅(qū)動（Data-Driven）

現(xiàn)在有句很流行的話，“唯一不變的是變化。（The only constant is change.）”數(shù)據(jù)驅(qū)動使得變化對引擎的影響最小化。數(shù)據(jù)驅(qū)動不能算是一種獨(dú)立的Entity模式，不如說它是一種設(shè)計思想，其目的就是將內(nèi)容制作和游戲引擎的制作分離開來。與上面所說的填充Entity屬性數(shù)據(jù)庫的不同之處在于，它還要能通過數(shù)據(jù)來設(shè)計游戲邏輯。

游戲設(shè)計人員需要的一項(xiàng)最基本功能就是自定義人物屬性，所以與其在類里寫死屬性成員，不如使用屬性表（Attributes/Properties）。通常使用一個哈希表（Hashtable），或者std::map，或者Dictionary，或者就是個數(shù)組，隨個人喜好，其實(shí)就是要一個key-value的映射表。然后為腳本和編輯器提供對屬性表的操作。

動態(tài)的邏輯主要就靠腳本了，必須為腳本提供足夠的事件和方法。個人推薦用Lua腳本，因?yàn)樗窃谟螒蝾I(lǐng)域內(nèi)用得最多的通用腳本語言，其引擎很小、速度很快、易于集成，盡管語法過于松散。不要迷信宣傳去用龐大、極慢、難于集成的Python。為腳本提供事件，其實(shí)也就是調(diào)用腳本里的函數(shù)，這里如果使用了前面所述的消息模式，那么就只要調(diào)用一個腳本方法，傳遞不同的消息參數(shù)就行了。當(dāng)然也有人覺得這樣很丑陋而更愿意為不同的事件注冊不同的函數(shù)。

當(dāng)有了數(shù)據(jù)驅(qū)動后，Entity的繼承樹就基本失去意義了，因?yàn)橐粋€Entity是什么已經(jīng)不是程序里決定的了，而是通過數(shù)據(jù)和腳本設(shè)計出來的。但數(shù)據(jù)和腳本又不是全部，一個Entity的核心內(nèi)容和需要高效處理的部分，如碰撞檢測，還是要程序來完成。于是我們需要重新設(shè)計Entity類，困難的局面也就由此開始。

一個直觀的想法是一個統(tǒng)一且唯一的Entity類，它包含了所有的基本功能，如顯示、碰撞檢測、運(yùn)動、背包等，然后由數(shù)據(jù)決定哪些組件被啟用。比如一個玩家角色可能會啟用絕大部分組件，而一顆樹只啟用顯示和碰撞檢測組件。但也伴隨著缺點(diǎn)：一、這個類太大了；二、對于樹木等一些簡單的Entity也要浪費(fèi)其他組件的私有數(shù)據(jù)所占的內(nèi)存。那么一個簡單的折中是部分使用繼承、部分使用數(shù)據(jù)定制。例如Entity只提供最基本的組件，再派生出CharactorEntity提供足夠人物角色使用的組件。

組件模式（Component-Based Entity）

提到組件，那么很自然的就過渡到組件模式，就是把顯示、運(yùn)動、攻擊、背包、隊(duì)伍、聲音等基本功能都做成獨(dú)立的組件，由數(shù)據(jù)來決定向Entity里添加哪些組件。由此可以得到另外一個擴(kuò)展，就是既然可以有引擎內(nèi)置的組件，那就也可以有腳本制作的組件，實(shí)現(xiàn)腳本模塊的復(fù)用。這種模式在GDC2002正式提出，到現(xiàn)在主流的引擎都有這種設(shè)計。

這種模式在理論上很完美，但實(shí)踐上還是有不少疑問。最常見的問題就是組件間的依賴關(guān)系。理想情況下，各個組件是完全獨(dú)立的，但實(shí)踐中必然有所依賴。比如運(yùn)動速度、攻擊強(qiáng)度等和角色的基本屬性有關(guān)，運(yùn)動組件需要角色的包圍盒來測試是否碰撞，AI組件需要分析角色當(dāng)前狀態(tài)和發(fā)出運(yùn)動、攻擊命令，角色動作狀態(tài)變化時改變顯示組件屬性，攻擊組件需要訪問隊(duì)伍信息組件以禁止攻擊隊(duì)友等等。處理這種依賴關(guān)系主要要解決兩個問題：

<!--[if !supportLists]-->一、              <!--[endif]-->誰依賴誰。比如是敏捷屬性改變而去修改移動速度，還是運(yùn)動組件讀取敏捷屬性來計算移動速度。如果要游戲設(shè)計人員自由定義基本屬性的話，就要選擇前者，因?yàn)榛緦傩越M件會是腳本組件。

<!--[if !supportLists]-->二、              <!--[endif]-->如何取得另一組件的指針/引用。常見的方法是給每個組件類型一個唯一ID，然后用該ID在Entity上查詢注冊了的組件，如果找到返回其指針/引用，否則返回null。當(dāng)然，每次訪問都做這個查詢會很浪費(fèi)CPU，如果Entity的組件不會在運(yùn)行時動態(tài)添加刪除的話（除非在編輯器里，否則很少有人會這么做），可以在Entity初始化后讓每個組件緩存它所要用的其他組件指針。那么當(dāng)所依賴的組件不存在怎么辦，一般情況下都是無聲地忽略。

當(dāng)Entity由很多組件組成后，交互的消息需要發(fā)給每一個組件。這里又一次體現(xiàn)出消息機(jī)制的優(yōu)勢，你不需要在Entity里為每一個事件函數(shù)寫一個loop來調(diào)用組件的相應(yīng)事件函數(shù)。但這里也出現(xiàn)了一個問題，消息到達(dá)各個組件的順序。很多時候這個順序不會有什么影響，但個別時候不同的順序會導(dǎo)致完全不同的邏輯發(fā)展方向。

此外，Entity的序列化存儲也變得比較復(fù)雜，經(jīng)典的Excel導(dǎo)出csv的模式難以奏效，因?yàn)檫@里需要結(jié)構(gòu)化的存儲，所以需要結(jié)構(gòu)化的數(shù)據(jù)文件如XML來存儲，或者完全用腳本來包含所有數(shù)據(jù)和構(gòu)造Entity。

據(jù)個人經(jīng)驗(yàn)，使用數(shù)據(jù)驅(qū)動的繼承模式時很是向往組件模式，感覺上它一個非常自然的擴(kuò)展方向，但顧忌其引入的額外的復(fù)雜性，尤其是需要游戲設(shè)計人員具有一定的編程能力，所以一直不敢全盤接過使用。但退一步，在引擎里仍然使用組件思想，但Entity的組件構(gòu)成在編譯時固定，可以達(dá)到某種妥協(xié)，這和采用繼承與數(shù)據(jù)驅(qū)動的折中類似。

混入模式（Mix-in）

這是又一種常見的折中模式，即使用C++的多重繼承，將各個組件類混入一個Entity類。如：

class Mob: public GameObject, public Renderable, public Movable, public Attackable
{
…
}

這種方法因其簡單而且非常符合多重繼承設(shè)計思想而被很多引擎采用。當(dāng)然缺點(diǎn)也是只能在支持多重繼承的語言里使用，而且當(dāng)組件很豐富時，dynamic_cast就變成一個代價高昂的操作。

功能性與復(fù)雜性（Functionality vs Complexity）

編程領(lǐng)域最古老的原則之一就是要“簡單快速”。但隨著問題的復(fù)雜化，程序也隨之變得越來越復(fù)雜。好的方法應(yīng)該能有效的降低或隱藏復(fù)雜性。但是，沒有不帶副作用的藥（No silver bullet.），在取得更強(qiáng)大的功能的同時總會帶來額外的復(fù)雜性。我們需要做出權(quán)衡，在必要時犧牲一些功能，也就是要估算性價比。

一般游戲內(nèi)容制作人員不會或不太會編程，編程人員也不善于游戲的內(nèi)容創(chuàng)造和數(shù)值平衡，過于復(fù)雜的系統(tǒng)會導(dǎo)致需要兩面兼顧的人才，會大大增加做出一款游戲的難度。