私は、エンティティ コンポーネント システムに情報を保存する方法について、相反するさまざまな提案を多数見てきました。多くの説明なしに、「純粋さ」やキャッシュの最適化を宣伝するものもあります。一般的な要約として:
コンポーネントを構造内に格納するエンティティのリスト (たとえば
unordered_map<type_info, IComponent*>
、C++ のようなもの)。システムは、現在アクティブなエンティティのうち、操作対象のコンポーネントを所有する独自のリストを追跡します。1 と同じですが、システムがすべてのエンティティをグローバルに反復し、それらに含まれるコンポーネントを確認します。
コンポーネントのタイプごとに個別のリストがあり、「エンティティ」の実際に保存されたリストはありません。システムは関連するコンポーネントを繰り返し処理し、接続する一意の ID を介して、同じエンティティに属する他の関連コンポーネントを何らかの方法で見つける必要があります。彼ら。このようにコンポーネントをリストに保持することは、おそらくキャッシュの局所性を改善するとしてサポートされています (ただし、特定のエンティティに関連するコンポーネントを見つけるためにいくつかの大きなリストを検索する必要があるため、方法はわかりません)。エンティティ」タイプは、おそらく「純粋な」ECS の兆候です。
各コンポーネント タイプには独自のグローバル コンテナ/リストがありますが、特定のエンティティに属するコンポーネントを追跡するエンティティ構造のリストがまだあります。システムは 1 または 2 のように動作します。
また、「システムごとに 1 つのコンポーネント タイプ」を支持する議論も見つけました。これにより、システム 3 のいくつかの課題が単純化されますが、全体としてはほとんど意味がありません。
だから私の質問は-異なる実装のすべてのノイズをカットすることです.これらのいずれかがECSを作成するための「理想的な」または「標準的な」方法ですか? これらの各設計の長所と短所、およびそれらのさまざまなバリエーションを分析するのはかなり困難です。私は通常、上記のリストの「1」のようにそれらを実装しました。これは便利であることが証明されていますが、必ずしも最適であるとは限りません。