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

直接模式（The C Approach）

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

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

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

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

繼承模式（Inheritage）

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

Entity

       Character

              Player

              Mob

       Missile

              Laser

              GuidedMissile

       Item

       …

Entity對象的邏輯大多也是直接包含在類里的。但也有人采用了數據對象和邏輯對象的分離，其好處是對相同的數據可以替換不同的邏輯。不過，個人比較懷疑這種分離是否值得，因為類的派生本身就是可以擁有不同的邏輯。

另外，Entity間的交互除了用標準的直接訪問方式外，經常使用消息模式。消息模式和Windows的消息模式類似，Entity間通過消息交互。雖說窗口編程畫了多年時間才擺脫了當年肥大的switch的消息處理模式，在Entity層使用消息模式還是有意義的，因為消息很容易廣播且可以直接在網絡上發(fā)送。執(zhí)著于OO的人會將消息寫成Command對象，但原理仍然是一樣的。

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

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

數據驅動（Data-Driven）

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

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

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

當有了數據驅動后，Entity的繼承樹就基本失去意義了，因為一個Entity是什么已經不是程序里決定的了，而是通過數據和腳本設計出來的。但數據和腳本又不是全部，一個Entity的核心內容和需要高效處理的部分，如碰撞檢測，還是要程序來完成。于是我們需要重新設計Entity類，困難的局面也就由此開始。

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

組件模式（Component-Based Entity）

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

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

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

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

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

此外，Entity的序列化存儲也變得比較復雜，經典的Excel導出csv的模式難以奏效，因為這里需要結構化的存儲，所以需要結構化的數據文件如XML來存儲，或者完全用腳本來包含所有數據和構造Entity。

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

混入模式（Mix-in）

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

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

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

功能性與復雜性（Functionality vs Complexity）

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

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