コンポーネントベースのシステムにおけるエンティティの状態の役割は？

最近では、コンポーネントベースのエンティティシステムが大流行しています。誰もが自分たちが進むべき道であることに同意しているようですが、そのようなシステムを確実に実装している人は誰もいません。エンティティの状態（左折、立っている、ジャンプなど）がCBSでどのような役割を果たしているのでしょうか。それらはコントローラーのように機能しますか（つまり、イベントを処理し、それらのイベントに基づいてエンティティーの属性を変更します）？

たとえば、状態がエンティティにクリップなしモードに入ることを要求する場合はどうでしょうか？それが入るときに、その状態は、エンティティのCollisionComponentをnullポインタまたは何かに設定する必要がありますか？（次に、終了時に、状態はエンティティのCollisionComponentを以前の状態に復元する必要があります。）

また、エンティティの状態を別の状態に変更するのは、現在の状態の仕事だと思いますよね？

コンポーネントベースのデザインでは、エンティティは基本的にコンポーネントコンテナー（おそらくメッセージがスローされる）であるという印象を受けました。この観点から見ると、各コンポーネントには少しの状態が格納されます。たとえば、ghost-behavior-componentsが無形モードに入る必要があると判断した場合は、物理コンポーネントにメッセージを送信して、クリップなしを有効にするよう指示します。おそらく、ゴーストモデルコンポーネントにアルファを起動するように指示するメッセージも送信します。

ステートマシンとコンポーネントは直交技術です。他のクラスに状態を含めることができるのと同じように、コンポーネントに状態を含めることができます。コンポーネントに監視させ（監視パターンを参照）、別のコンポーネントの状態を変更できます。ステートマシンには多くの用途があり、実装はユーザーのニーズによって異なります。

あなたが説明したキャラクターの状態（歩行、立っている、ジャンプ）については、さまざまなコンポーネントがすべて独自の状態マシンを維持する実装を見てきました...物理、アニメーション、コントロール、ai。コンポーネントには、他のどのコンポーネントが反応するか、どのコンポーネントが変更できるかについて明確な権限が必要です。

データのみの構造としてコンポーネントを設計します。ゲッターとセッターほど複雑なロジックはありません。コンポーネント間に依存関係を作成しないでください。依存関係を作成すると、エンティティシステムの利点のほとんどが失われます。

このアプローチの例（Tマシンビジョンに近い）は、https： //github.com/thelinuxlich/starwarrior_CSharpで確認できます。

そしてエンジン自体：https : //github.com/thelinuxlich/artemis_CSharp