多くの野心的なデザイナーやプログラマーのように、私はエンティティ/コンポーネント システムの設計に出くわしました。そして、私は、他の多くの人と同じように、そのようなシステムを実装することを自分自身に任せました.
概念的には、エンティティはコンポーネントのバッグであり、一連のシステムによって処理されるデータのバッグにすぎません。したがって、Entity オブジェクトを使用してそれに関連付けられたすべてのコンポーネントを保持できることは論理的に思えますが、他の人の研究ではそうではありません。私の調査全体を通して、エンティティは単なる ID にすぎず、オブジェクト指向の考え方の罠に陥ることは何としてでも避けなければならないということは、ほぼ普遍的に理解されているようです。彼らは代わりにマネージャーにコンポーネントを格納することを提案していますが、そのような設計の利点には直接触れていません。
エンティティに保持されているコンポーネントとマネージャーに保持されているデザイン、コンポーネントの両方が同じ最終結果をもたらすことはありませんか? 誤解している/何かが足りない場合はお知らせください。
私は決してエンティティ コンポーネント システムの専門家ではありませんが、これは私が読んだ内容からのこのテーマに関する私の見解です。
コンポーネントに直接アクセスするべきではないと思います。その場合、コンポーネントは相互に依存し始め、後で 1 つのコンポーネントの動作を変更することにした場合、変更したいコンポーネントに依存している他のすべてのコンポーネントを修正する必要があります。
この問題を回避するには、コンポーネントが互いに何も認識しないようにする必要があります。それぞれに 1 つの仕事があり、その仕事だけに集中する必要があります。別のコンポーネントからのデータが必要な場合 (たとえば、位置データが必要な場合)、別のシステムにデータを要求するか、メッセージング システムを開発する必要があります。
もちろん、実際にコーディングを開始すると、このルールを 100% 順守することは困難ですが、アイデアは理解できます。
コンポーネントをエンティティに保存しないもう 1 つの理由は、速度です。コンポーネントがシステムに含まれている場合 (すべての類似コンポーネントが一緒に保管されている場合)、大量のコンポーネントを迅速に処理できます。再利用される可能性のあるデータをセットアップし、各コンポーネントをループして処理し、再利用されたデータを解放する機会があります。これだけでなく、各システムは個別のスレッドで実行できる可能性があります (必要があります)。これにより、複数のコアを簡単に活用できます。
繰り返しますが、実際には、これは常に 100% 正しいとは限りませんが、それが理論です。
要約すると、コンポーネントをエンティティではなくシステムに保持すると、コンポーネントに直接アクセスする誘惑が減り、システムでの一括更新が可能になります。ご不明な点がございましたら、お気軽にお問い合わせください。