一切皆實體 目前十分流行ECS設計，主要是守望先鋒的成功，引爆了這種技術。守望先鋒採用了狀態幀這種網路技術，客戶端會進行預測，預測不准需要進行回滾，由於組件式的設計，回滾可以只回滾某些組件即可。ECS最重要的設計是邏輯跟數據的完全分離。即EC是純數據，System實際上就是邏輯，由數據驅動邏輯。數據 ...
一切皆實體
目前十分流行ECS設計，主要是守望先鋒的成功，引爆了這種技術。守望先鋒採用了狀態幀這種網路技術，客戶端會進行預測，預測不准需要進行回滾，由於組件式的設計，回滾可以只回滾某些組件即可。ECS最重要的設計是邏輯跟數據的完全分離。即EC是純數據，System實際上就是邏輯，由數據驅動邏輯。數據驅動邏輯是什麼意思呢？很簡單通過Update檢測數據變化，通過事件機制來訂閱數據變化，這就是所謂的數據驅動了。其它的特點例如緩存命中，在編寫邏輯上來說並不太重要，現代游戲都用腳本，連腳本的性能都能容忍怎麼會在乎緩存命中那點性能提升？ET在設計的時候吸收了這些想法，但是並不完全照搬，目前的設計是我經過長期的思考跟重構得來的，還是有些自己特色。
傳統的ECS寫邏輯作者看來存在不少缺陷，比如為了復用，數據必然要拆成非常小的顆粒，會導致組件非常非常多。但是游戲是多人合作開發的，每個人基本上只熟悉自己的模塊，最後可能造成組件大量冗餘。還有個問題，常見的ECS是扁平式的，Entity跟Component只有一層。組件一多，開發功能可能不知道該使用哪些Component。好比一家公司，最大的是老闆，老闆手下帶幾百個人，老闆不可能認識所有的人，完成一項任務，老闆沒法挑出自己需要的人。合理的做法是老闆手下應該有幾個經理，每個經理手下應該有幾個主管，每個主管管理幾個工人，這樣形成樹狀的管理結構才會容易管理。這類似ET的做法，Entity可以管理Component，Component管理Entity，甚至Component還可以掛載Component。例如：人由頭，身體，手，腳組成，而頭又由眼睛，耳朵，鼻子，嘴巴組成。
Head head = human.AddComponent<Head>(); head.AddComponent<Eye>(); head.AddComponent<Mouse>(); head.AddComponent<Nose>(); head.AddComponent<Ear>(); human.AddComponent<Body>(); human.AddComponent<Hand>(); human.AddComponent<Leg>();
ET中，所有數據都是Entity，包括Entity，Entity既可以當成組件使用，也可以當做其它Entity的孩子。通用的數據放在Entity身上作為成員，不太通用的數據可以作為組件掛在Entity身上。比如物品的設計，所有物品都有配置id，數量，等級的欄位，這些欄位沒有必要做成組件，放在Entity身上使用會更加方便。
class Item: Entity { // 道具的配置Id public int ConfigId { get; set; } // 道具的數量 public int Count { get; set; } // 道具的等級 public int Level { get; set; } }
ET的這種設計數據是一種樹狀的結構，非常有層次，能夠非常輕鬆的理解整個游戲的架構。頂層Game.Scene，不同模塊的數據都掛載在Game.Scene上面，每個模塊自身下麵又可以掛載很多數據。每開發一個新功能不用思考太多，類該怎麼設計，數據放在什麼地方，掛載這裡會不會導致冗餘等等。比如我玩家需要做一個道具系統，設計一個ItemsComponent掛在Player身上即可，需要技能開發一個SpellComponent掛在Player身上。全服需要做一個活動，搞個活動組件掛在Game.Scene上面。這種設計任務分派會很簡單，十分的模塊化。
組件的一些細節
1.組件的創建
組件的創建不要自己去new，應該統一使用ComponentFactory創建。ComponentFactory提供了三組方法用來創建組件Create，CreateWithParent，CreateWithId。Create是最簡單的創建方式，它做了幾個處理
a. 根據組件類型構造一個組件
b. 將組件加入事件系統，並且拋出一個AwakeSystem
c. 是否啟用對象池
CreateWithParent在Create的基礎上提供了一個Parent對象，設置到Component.Parent欄位上。CreateWithId是用來創建ComponentWithId或者其子類的，在Create的基礎上可以自己設置一個Id, Component在創建的時候可以選擇是否使用對象池。三類工廠方法都帶有一個fromPool的參數，預設是true。
2.組件的釋放
Component都繼承了一個IDisposable介面，需要註意，Component有非托管資源，刪除一個Component必須調用該介面。該介面做瞭如下的操作
a. 拋出Destroy System
b. 如果組件是使用對象池創建的，那麼在這裡會放回對象池
c. 從全局事件系統(EventSystem)中刪除該組件，並且將InstanceId設為0
如果組件掛載Entity身上，那麼Entity調用Dispose的時候會自動調用身上所有Component的Dispose方法。
3.InstanceId的作用
任何Component都帶有一個InstanceId欄位，這個欄位會在組件構造，或者組件從對象池取出的時候重新設置，這個InstanceId標識這個組件的身份。為什麼需要這麼一個欄位呢？有以下幾個原因
- 對象池的存在，組件未必會釋放，而是回到對象池中。在非同步調用中，很可能這個組件已經被釋放了，然後又被重新利用了起來，這樣我們需要一種方式能區分之前的組件對象是否已經被釋放，例如下麵這段代碼：
public static async ETVoid UpdateAsync(this ActorLocationSender self) { try { long instanceId = self.InstanceId; while (true) { if (self.InstanceId != instanceId) { return; } ActorTask actorTask = await self.GetAsync(); if (self.InstanceId != instanceId) { return; } if (actorTask.ActorRequest == null) { return; } await self.RunTask(actorTask); } } catch (Exception e) { Log.Error(e); } }
while (true)中是段非同步方法，await self.GetAsync()之後很可能ActorLocationSender對象已經被釋放了，甚至有可能這個對象又被其它邏輯從對象池中再次利用了起來。我們這時候可以通過InstanceId的變化來判斷這個對象是否已經被釋放掉。
2. InstanceId是全局唯一的，並且帶有位置信息，可以通過InstanceId來找到對象的位置，將消息發給對象。這個設計將會Actor消息中利用到。這裡暫時就不講了。
ET開源地址地址：egametang/ET: Unity3D Client And C# Server Framework (github.com) qq群：474643097
