1樓：a阿拉
哈哈 。，這個跟前端開發中的redux 叫好不叫座如出一轍啊，看來深刻體會了每種架構設計都有其自身設計的適用場景和運用範圍，比如redux , 適用於時間旅行、記錄/回放，集中式資料來源的場景，比如編輯器 （很抱歉，實在沒做過其他更適合的場景），ECS 適合有延遲的公網多人聯機網遊，（跟傳統開發模式比起來，單機遊戲這麼搞會降低開發效率）。
2樓：
在這個架構中，核心關注在資料（或者狀態）上。
1、System之間介面在Components上。不同System之間，必須通過Component（或者Message，應該是少數情況）交流。
2、對狀態的依賴和對狀態的修改都是顯示的。要新增狀態依賴或者輸出狀態，要在Tuple裡加上這個Component。
3、狀態的修改要少而且集中。狀態改變越少，依賴就越少，流程越清晰簡單。
4、System的Update順序很重要，但可以通過delay one frame等方式緩解。
這麼做的結果，是開發過程中，關注的狀態更少，狀態改變更少，狀態的依賴更清晰。
而System間不能呼叫，也減少了很多介面約定之類的事。
舉個例子，有個同學要在OW加乙個第三人稱相機的System
他只用關注
1、輸入的Component（Input, Movement, Collision等）
2、輸出CameraComponent
3、輸入是否在我的System之前填好，輸出是否會影響其他System
和其他架構比
1、OOP
可以避免陷入各種OOP的「哲學問題「上；假設更少，更靈活，對需求的修改友好；
2、和Unity類的Components結構比，狀態修改和依賴更清晰。
在Unity裡，乙個Update，可能會訪問到無數其他Components的狀態，這些訪問都是不自覺、沒有約束的。另外還可能在乙個Component的Update中修改其他系統的狀態。
另外，ESC的另一有點talk中沒提，就是Components資料可以連續儲存，有利於cache coherent。
要高效實現這一套（由Components組合定義entity），也有很多C++模版技巧可以使用。印象這些在某個CppCon裡有提及。
3樓：彗星塵
技術細節不太懂，從策劃角度來看，這很暴雪，先做乙個巨NB的工具，然後利用這個工具做個遊戲。
從介面和簡介上看，這個東西很像CE3的FlowGraph模組，以前用過，個人感覺架構設計清晰的話，從開發角度看比SCII編輯器好用得多，策劃可以直接實現自己的想法，從而把程式解放出來；缺點是，因為是給策劃用的，而大多數策劃並不具備結構化思維……所以如果前負責人沒有「結構」和「標準」這個概念，千萬別貿然接手，除非整體需求是推翻重來。
經典的軟體架構設計書籍有哪些？
ReggieDing 架構之美 讓最優秀的設計師和架構師來描述他們選擇的軟體架構，剝開架構的各層，展示他們如何讓軟體做到實現功能 可靠 易用 高效率 可維護 可移植和優雅。面向模式的軟體體系結構系列 好幾本說也可以去看看。設計原本 將對設計過程進行深入分析，揭示進行有效和優雅設計的方法。這些書都收錄...
「微服務」架構設計中如何把握「微」度，需要考慮哪幾方面因素？
kimmking 實際上服務劃分的本質是對系統進行架構設計，服務的劃分粒度沒有絕對的過大或過小之說，不同階段的側重點和思考的角度也不盡相同。創業初期的團隊，過分的追求微服務，為了 微 而微，反而會導致業務邏輯過於分散，技術架構過於複雜，團隊基礎設施搭建能力弱，進而導致忽略了快速迭代交付產品的重要性，...
如何評價當下的守望先鋒？
翟文雄 內測就開始玩了算是個守望老玩家了後來過了段時間都去吃雞了 3年沒怎麼碰了最近碰了碰。先說一點守望絕對算是乙個非常好的遊戲把傳統FPS 和moba結合在一起而且遊戲質量很高即有競技性也有娛樂性。在國內逐漸涼涼的原因我認為有幾下原因 1.外掛程式 2.吃雞以及一些其他fps遊戲湧入以及火爆3.守...