コンポーネントベースのゲームアーキテクチャに動作を実装する方法

プレイヤーと敵のAIをゲームに実装し始めていますが、これをコンポーネントベースのゲームアーキテクチャに最適に実装する方法について混乱しています。

次のプレイヤーキャラクターがいて、静止したり、走ったり、剣を振ったりできるとします。プレイヤーは、静止状態とランニング状態の両方からスイングソード状態に移行できますが、プレイヤーが立ち上がったり走り回ったりする前にスイングを完了する必要があります。スイング中、プレーヤーは歩き回ることができません。

ご覧のとおり、2つの実装アプローチがあります。

• すべてのプレーヤーロジックを含む単一のAIコンポーネントを作成します（実際のコンポーネントから切り離されるか、PlayerAIComponentとして埋め込まれます）。プレーヤーエンティティを構成する個々のコンポーネント間の結合を作成せずに、状態制限を強制する方法を簡単に実行できます。ただし、AIコンポーネントは分割できません。たとえば、立ち上がって歩き回るだけの敵や、歩き回って剣を振り回すだけの敵がいる場合、新しいAIコンポーネントを作成する必要があります。
• 動作をコンポーネントに分割し、それぞれが特定の状態を識別します。次に、SandComponent、WalkComponent、SwingComponentを取得します。移行ルールを実施するには、各コンポーネントを結合する必要があります。SwingComponentは、スイングの間、StandComponentとWalkComponentを無効にする必要があります。たまに剣を振り回すだけの敵がいる場合、SwingComponentが存在する場合にのみWalkComponentを無効にする必要があります。これにより、より良いコンポーネントの組み合わせが可能になりますが、依存関係が追加されるたびに保守性の悪夢につながる可能性があります。既存のコンポーネントは、依存関係がキャラクターに課す新しい要件でうまく動作するように更新する必要があります。

理想的な状況は、エンジンやスクリプトコードの1行に触れることなく、コンポーネントをコンテナにドラッグすることで、デザイナーが新しい敵/プレイヤーを構築できることです。スクリプトのコーディングを回避できるかどうかはわかりませんが、できるだけシンプルに保ちたいと思います。

すべてをまとめる：すべてのAIロジックを1つのコンポーネントに分割するか、各ロジック状態を個別のコンポーネントに分割して、エンティティバリアントをより簡単に作成する必要がありますか？

編集：私は私が最初と2番目の状況で何を意味したかについていくつかの混乱があると思う。以下の図で説明しようとしました。

個々の状態とエンティティ間の関係に注意してください。最初の状況では、AIコンポーネントはエンティティに配置される前に事前に構築されます。デザイナーが選択できるのは、プログラマーが利用できるAIComponentsの異なるセットからのみです。2番目の状況には、他のコンポーネントと同じレベルの異なる状態があります。設計者は、プログラマーの干渉なしに、独自のAIでエンティティを作成できるようになりました。

問題は、これらがコンポーネントベースのエンティティでAIを構築するための2つのオプションであり、もしそうなら、最大の柔軟性を与えるものは何ですか？

今考えられないほどの可能性のある敵やプレイヤーを抱えるつもりなら、間違いなく解散するべきです。2番目のポイントで説明しているのは、基本的に状態パターンです。

Gregoryには、スタンドとウォークの状態コンポーネントを別々にすべきではないことに同意すると思います。これは、速度0の単なる移動コンポーネントです。一方、移動できないオブジェクトがある場合は、それを分割するか、速度0以外を持たない移動状態に何らかのブール制限を加える必要があります。 。

プレイヤーにとっては、完全に分離する必要はないと思います。入力コンポーネントを追加して、他のすべてのコンポーネントを引き続き使用できます。このコンポーネントは状態間の遷移を駆動しますが、敵の場合はデフォルトのAIによって制御されます。または、必要に応じて、敵のデザイナーが選択できるさまざまなAIサブクラスも制御します。

編集：実際には、動きのあるコンポーネントを制限するのではなく、静止している敵に対して、移動を選択しない静止したAIコンポーネントを与えるだけです。

少なくともPlayer AI（またはPlayer Controllerと呼ぶもの）を独自のコンポーネントとして保持します。ほとんどのゲームでは、プレーヤーはNPCとは根本的に異なるため、ヒットポイントなどの基本的な場合を除いて、1つから別のものに一般化することはできません。

NPCの場合、StandComponentとWalkComponentは同じものの側面として見えます。StandComponentなしでWalkComponentを使用する予定はありますか？疑わしい。同様に、RunComponentは、より高速でさまざまなアニメーションを持つWalkComponentになります。NPCMovementComponentと個別のNPCSwordFighterComponentを使用することで価値がわかりますが、それでも私にとっては過剰なエンジニアリングのように感じます。

最初に状態コンポーネントを作成し、次に遷移を処理する状態マシンを作成します。プレーヤーとAIにこれを使用できるように、十分に汎用的にします。これにより、AIが同じルールで再生され、AIの状態と比較してプレーヤーの状態の動作を変更するときにロジックを変更する必要がなくなります。

有限状態機械C ++

上記は、プレイヤーとAIが同様に使用できるc ++のステートマシンの具体例です。

必要なのは、キャラクター（プレイヤーとNPC）の動きを処理するコンポーネントです。AIコンポーネントまたはプレーヤーコンポーネントは、この移動コンポーネントにコマンドを送信し、アクションを開始できるかどうかを確認します。これにより、移動の制約が1つのコンポーネントにカプセル化されます。AIコードとプレーヤーコードは、スイングソードの実行方法を知る必要はありません。AIには、アイドル、攻撃、逃亡などの内部状態があります。