私の現在のプロジェクトでは、コンポーネント/エンティティベースのシステムを実装しました。基本的に、このかなり未定義の領域にあるベストプラクティスのほとんどに従っています。
だから私は（少し拡張された）エンティティを取得しました。これは基本的にintID、人間が読める名前、std::mapコンポーネントのa 、およびlong存在するコンポーネントを示すために使用される「タイプインジケーター」です（私はenumすべてのコンポーネントに対して2の累乗を持っています）タイプと、コンポーネントがエンティティに追加されるときはいつでも、ビット単位の演算によってその長さを自動的に変更し、比較しますます。この回答を）。
次に、Componentsもあります。これもかなり単純です。コンポーネントタイプとしてのintID enum、親エンティティポインター、およびstd::mapこのコンポーネントが保持するすべてのプロパティのa です。
最後に、実際のロジック処理を処理するいくつかのシステム/マネージャー。彼らは最初に、現在処理されているエンティティに一致するlong「タイプインジケーター」があるかどうかをチェックします=そのシステムに必要なすべてのコンポーネントが存在します。次に、必要に応じていくつかのプロパティにアクセスし、それぞれのコンポーネントの関数を直接呼び出すか、メッセージディスパッチャを介してメッセージを送信します。
結論：ここまでは、かなり標準的なイベント駆動型のコンポーネント/エンティティベースのシステムとデータ駆動型のアプローチを組み合わせたものです（比較すると、コンポーネントにはハードコードされたデータ変数がなく、（一部の）コンポーネントとして一般的なマップがありますコンポーネントの/ archetypesは後で、実際のコンポーネントコードの一部ではない追加データを追加するオプションを使用してファイルから読み取られます。
次に、そのプロジェクトに（AiGameDev BTSKに基づく）動作ツリーも導入したいと思いますが、それらを既存のコンポーネントにリンクする必要があるかどうか、どのようにリンクするべきか、またはそれらのデザインを一般的に統合する方法はわかりません。
いくつかの関連するアイデア/ポイント/質問が頭に浮かびます：
私のBTはファイルから（再び）読み込まれます。現在
BT Action、ツリー内のとアプリケーションの実際のコーディングとの間の接続を最適にする方法を確認するのに苦労しています。BTファイルで使用されるアクション名と実際のロジック実装への関数ポインターとの間に何らかのマップを作成する必要がありますか？それを解決するための通常のアプローチは何ですか？私はすべての異なる
Entityタイプ（つまり、ゲームロジックとAIに関連するコンポーネントの組み合わせのそれぞれについて、何度も言及した長い「タイプインジケーター」で示されるように）に対してBTを作成する必要があると思います。結果として、BT Actionアクションごとに多くのコンポーネントが関与する可能性が最も高いため、コンポーネントに実装を配置することは意味がありませんか？それで、
BT Actionロジックは複数の個別のシステムに配置する必要がありますか（アイデア＃1からのマップが指し示すメソッドに）。次に、システムは私のlong「タイプインジケーター」ごとにEntity、BTが現在チェックされており、特定のアクション（=システム内のメソッド）の実行が実際に許可されている（=必要なコンポーネントがある）かどうかをチェックします。しかし、そうでない場合（たとえば、BT作成者が特定の状況を見落とし、実行時に必要なコンポーネントがエンティティにアタッチされなくなる可能性があるため）、何も起こりません。
質問：
- そのような統合のための実証済みの概念はありますか？
- 上記の3つの点についてどう思いますか？
- コンポーネント/エンティティベースのデザイン全般に関して、他に思い浮かぶことはありますか？