ET介紹—— 一切皆實體的設計

Flamesky發表於2023-05-19

一切皆實體

目前十分流行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標識這個元件的身份。為什麼需要這麼一個欄位呢？有以下幾個原因

  1. 物件池的存在，元件未必會釋放，而是回到物件池中。在非同步呼叫中，很可能這個元件已經被釋放了，然後又被重新利用了起來，這樣我們需要一種方式能區分之前的元件物件是否已經被釋放，例如下面這段程式碼：
        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

相關文章