這種編程思想很早前就已經提出,ECS分別是Entity,Component,System的縮寫. html
- Entity是實例,做爲承載組件的載體,也是框架中維護對象的實體. react
- Component只包含數據,具有這個組件便具備這個功能. git
- System做爲邏輯維護,維護對應的組件執行相關操做. github
ECS和傳統的OOP相比更看重的是組件,附加組件即具有功能. 編程
C#是面嚮對象語言,從語言層面上就支持面向對象的編程思想:集成封裝和多態. 服務器
按照ECS的思路,功能拆分紅組件,而後把這些細小的組件組合便組成了具有所需功能的對象.實際上Unity也是這種實現思路,可是它的組件式屬性和邏輯的合集. 框架
最近看了ECS編程思想,看了Entitas邏輯,寫了小Demo,感受: 編程思路/框架沒有最好只有更合適,可能A框架適合RPG遊戲,B框架更適合FPS遊戲. oop
【福利】阿里雲1888元優惠券紅包免費領取:https://promotion.aliyun.com/ntms/yunparter/invite.html?userCode=t9686fzw
性能
開發中常常會遇到控制時序的邏輯,好比某個Entity必須在另外一個Entity邏輯完成後再執行,固然能夠經過添加組件標識來控制時序執行,可是若是存在大量這種邏輯勢必會增長不少對應的組件做爲標識.阿里雲
一樣能夠添加Component做爲控制標識做爲過濾條件,A系統要在B系統結束以後,C系統啓動以前,D系統掛起時…開發到後期怎麼辦.(待機,前搖,蓄能,施法,表現,結束,)太多太多狀態一幀/分幀維護起來估計也會亂吧.
好比FPS遊戲,MOBA遊戲用ECS思想拆分合適,每一個玩家的角色功能對等(都是人物,都在移動,戰鬥)不一樣的角色的技能拆分單獨實現.
若是是大型RPG遊戲,每一個門派角色,大廳npc,商城商人,敵人角色的狀態動做各不相同,這種ECS固然能實現,每一個功能,拆分紅細小組件,建立對應System類維護,可是這樣歸根到底一個System通過遍歷篩選其實只維護了一個Entity上面的組件.由於角色功能獨有,之後這個組件也不會被其餘Entity組合使用.
不方便重構
數據分散到對應的組件,好比服務器下發一份最新數據,須要一一維護對應組件的屬性,數據收集也是如此.
客戶端拆分表現組件後,只包含純邏輯功能.
在不一樣的組件和系統中維護,沒必要像oop再拆分表現邏輯.
若是設計合理,能夠經過現有組件組合新的Entity.
1- 性能
數據在內存中線性存在,Entity複用.
基於ECS的框架有不少,Entitas即是其中一個.
官方的ECS也會在2018.1beta版本中推出.
根據wiki很容易就可以搭建起項目,運行起工程,可是有些也須要開發者注意,好比Component做爲標識仍是做爲數據存儲;Component生成代碼後改變類型或者刪除字段後的生成報錯,Group/Feature/Unit使用等等.
關於代碼生成,它提供兩個版本:
- 免費版
- 收費版
免費版根據反射生成代碼,須要無編譯錯誤下運行;收費版不須要,即便有代碼報錯也能夠生成代碼.。
本身擴展的代碼能夠分爲兩部分:
- Components
- 其餘代碼(System,Service…等其餘邏輯)
這樣作的好處是從新生成代碼時,方便的把這兩個目錄移除項目(或者StreamingAssets),生成基礎代碼,而後移回Component代碼,而後生成組件代碼,而後移回其餘代碼。
最簡單的輸出hello world
建立一個Component:
生成代碼後建立兩個system,一個用來建立entity並附加組件,另外一個用來輸出日誌:
上面的代碼已經實現了輸出功能,可是爲了方便管理上面的這兩個System,咱們添加一個RootSystems專門管理遊戲中的各類System:
全部的功能都實現了,在unity工程中添加一個入口方法掛載到場景中,Main.cs:
運行,正常輸出,由於輸出實現的是reactivesystem,當值發生變化時便會輸出.
今天untiy在beta版本中公佈了本身的ECS系統,Entity,ComponentData,ComponentSystem,隨着unity官方的引入,勢必會被推廣起來。
【福利】阿里雲1888元優惠券紅包免費領取:https://promotion.aliyun.com/ntms/yunparter/invite.html?userCode=t9686fzw