エンティティシステム - マネージャとエンティティの間にコンポーネントを格納する

Question

多くの意欲的なデザイナーやプログラマーと同様に、主題に関するさまざまな優れた記事やいくつかの実用的な実装も含めて、エンティティ/コンポーネントシステムの設計を見つけました。そして私は、他の多くの人たちと同じように、そのようなシステムを実装するために自分自身でそれを取ってきました。

概念的に、エンティティはコンポーネントの袋であり、一連のシステムによって処理されるデータの袋にすぎません。 Entityオブジェクトを使用してそれに関連するすべてのコンポーネントを保持することができますが、他の作業はそうではないと言うことは論理的です。私の研究全般にわたって、エンティティはID以上のものであり、オブジェクト指向の思考の罠に陥るのを避けなければならないということは、ほぼ普遍的に理解されているようです。彼らは、そのような設計の利点に直接対処することなく、代わりにマネージャにコンポーネントを格納することを提案している。

エンティティに保持されているコンポーネントとマネージャで保有されているコンポーネントが同じ結果になるのはどちらの設計でもありませんか？私が誤解している/何かを見逃している場合は、私に知らせてください。

Answer 1

私はEntity Component Systemsのエキスパートではありませんが、ここで私が読んだものからの私の見解です。

コンポーネントに直接アクセスしないでください。そうした場合、コンポーネントは互いに依存し始め、後で、コンポーネントの動作の仕方を変更することを決定したら、今変更したいコンポーネントに依存する他のコンポーネントをすべて修正する必要があります。

この問題を回避するには、コンポーネントはお互いを知るべきではありません。彼らはそれぞれ1つの仕事しか持っておらず、その仕事に集中すべきです。別のコンポーネントからデータが必要な場合（たとえば、位置データが必要な場合）、別のシステムにデータを要求するか、メッセージングシステムを開発する必要があります。

もちろん、実際にコーディングを始めると、このルールに100％従うのは難しいですが、あなたはそのアイデアを得ることができます。

エンティティにコンポーネントを格納しないようにするもう一つの理由は、高速化のためです。システムにコンポーネントが含まれている場合（同様のコンポーネントがすべて一緒に格納されている場合）、大量のコンポーネントを素早く処理できます。再利用可能なデータをセットアップし、各コンポーネントをループスルーして処理し、再利用されたデータを解放することができます。これだけでなく、各システムは別々のスレッドで実行できる必要があります（複数のコアを簡単に利用できるようにする）。

実際には、これは必ずしも100％真実ではありませんが、それがその理論です。要約すると、エンティティではなくシステムにコンポーネントを保持することは、コンポーネントに直接アクセスする誘惑を低減し、システムで一括更新を可能にする。私はこれが助けてくれることを願っています。ご不明な点がございましたら、お知らせください。