實體組件系統框架的最佳數據結構

Question

我一直在閱讀很多關於實體框架的知識，現在我想在我的遊戲中實現它。實體框架基於使遊戲實體成爲組件的簡單容器，其中組件包含實體的特定特徵（以及描述該特徵的所有變量/訪問器）。 然後通過創建系統模塊化遊戲邏輯。每個系統實現並運行遊戲邏輯的某個方面（例如，碰撞，渲染，動畫）。每個系統必須能夠訪問具有特定組件的每個實體（例如，RenderSystem必須獲得只有具有PositionComponent和AnimationComponent的實體）。

我的問題是關於實現這種功能的最佳數據結構。

我目前的想法是創建List of Entity的Vector（帶有N個單元格，其中N是可能的組件數量）。因此，無論何時創建（實例化和添加某些組件）實體，我都會從每個列表中爲它包含的每個組件引用此實體。 「殺死」一個實體需要刪除每個列表中的每個引用。問題在於查詢哪些實體必須由某個系統處理，因爲搜索關鍵將是組件的一個組合而不是單個組件，從而增加了操作的開銷（許多搜索和比較必須是完成）。

我的想法很好嗎？有沒有更好的數據結構可以使用？請注意，遊戲中的所有內容都應該是一個實體，在單個關卡上總結數千個Entites（我可能會使用一些空間分區）。

Answer 1

他們是共用一個ID兩種方式做這件事的，

純粹的面向數據的系統，會導致你不能有一個實體類，但只是部分。在這種情況下，每個系統的矢量或散列圖不會成爲問題，因爲這些數據結構中的搜索速度很快。如果您需要每個實體的每個系統有多個組件，則可以將組件集合到適用於每個系統的一個數據結構中。

問題是純粹的面向數據的系統可能比更實用的方法更不可用，在這種方法中，您保留前面描述的系統的所有功能，但是您保留一個實體類來保存對其組件的引用（或聚合組件結構）的每個系統。處理一個實體（刪除或檢查它）變得容易得多，因爲你仍然有一個地方可以在一個地方找到關於實體的所有信息，即它是由什麼構成的，而不是它所處的狀態，而不是查詢每個系統。

就你而言，最好的辦法就是嘗試......以兩種方式實現粗糙的引擎是非常容易和快速的，一旦你用這兩種方式來玩，你就可以決定哪一個套房你更好。

Answer 2

This article是有價值的，只要它爲數據結構建議4次迭代，但沒有人在我看來是一個好的解決方案。但我建議閱讀它，因爲有詳細的問題分析，在內存和其他優質材料方面有很好的估計。