置き換えボット
はじめに
AI にプレイヤーのキャラクターを制御させることが有用な場合があり、それが以下の2つの状況です。
- 進行中のマッチで切断されたプレイヤーを代替するため。これにより、プレイヤーがゲームに再接続しようとしている間、ボットがサポートすることで公平なマッチを作成するのに役立ちます。また、怒りでゲームを辞めたプレイヤーを補填することも可能です。
- ゲームセッションを開始するために必要な最小限のプレイヤー数に達していない場合に、部屋を偽のプレイヤーで満たすこと。これは、ゲームのリリースサイクルの初期段階でプレイヤーベースがまだ小さいときに特に重要です。
セットアップ
Quantum では、こうした機能のための AI ロジックが各クライアントのマシンでローカルに実行されます。つまり、「ボットの入力をシミュレートするマスタークライアント」の概念はありません。
AI を使用してゲームエンティティを制御することは簡単ですが、その実装はゲーム固有であることが多いです。もちろん、AI の実装自体の複雑さは非常にシンプルなものから非常に複雑なものまで様々です。
この作業を開始する最も簡単な方法は、あるエンティティが時折 AI に制御されているかどうかを示すことです。これは、次の方法で達成できます：
- 「フラグコンポーネント」を追加する。たとえば
component AI {}のように、必要に応じてエンティティに追加または削除します。これにより、システムはAIコンポーネントを持つすべてのエンティティを反復処理して制御ロジックを実行できます。 - コンポーネント内に Boolean を使用して AI 制御をオン/オフにする。たとえば
component MyCharacter { bool ControlledByAI; }のように。 - ボット SDK のエージェントコンポーネント（HFSM、BT など）やカスタムのものを含め、追加の AI 特有のコンポーネントを追加します。
では、いつこれを行うべきでしょうか？これは前述のユースケースに依存します。これらは次のセクションで詳しく説明していきます。
ゲームマッチ中にリアルプレイヤーを置き換える
これは PlayerConnectedSystem を有効化し、その後 ISignalOnPlayerConnected および ISignalOnPlayerDisconnected 信号に反応することで実現できます。このシステムとその関連する信号は、プレイヤーのドキュメント で説明されています。
プレイヤーが切断されたら、そのプレイヤーが制御していたエンティティを見つけ、前述のように AI を設定します。
プレイヤーが再接続する場合、そのプレイヤーが制御していたエンティティが存在するかを確認し、AI の設定を削除してプレイヤーが AI からの制御を取り戻すようにします。
上記のシステムは、動作するために PlayerInputFlags を使用していることが重要です。これは PlayerConnectedSystem に依存せずに使用することも可能です。詳細はプレイヤー入力フラグについてはこちらを参照してください。
ボットで部屋を埋める
この場合は、実際のプレイヤーは関与しません。言い換えれば、それは実際の人物によって制御されることを意図していないエンティティが作成されます。
プレイヤーが関与しないため、接続ロジックも必要ありません。カスタムゲームロジックがエンティティで部屋を埋めることができます。以下はその サンプルアルゴリズム/スニペット です：
- Quantum システム内でゲームが開始された後、プレイヤーが接続し、プレイヤーデータを送信するための時間を確保するために一定の間隔を待ちます。
- プレイヤーが到着したとき、
OnPlayerDataSetコールバックを使用して、ゲーム状態（例：フレームのグローバル変数に）に成功裏に接続しゲームに参加したプレイヤーの数を保存します。 - 一定の間隔が過ぎた後、この数をフレーム API から期待されるプレイヤー数から引き算します。以下のように：
int fillAmount = frame.PlayerCount - frame.Global->ConnectedPlayersCount; - この結果を使用して、ボットエンティティが作成される
forループを実行します：
C#
for(int i = 0; i < fillAmount; i++)
{
// ここで新しいエンティティを作成
// 前述のようにボットとして設定
}
上記のスニペットは非常にシンプルであり、ゲームの要件やゲームデザインに応じて調整する必要があります。たとえば、偽のプレイヤー情報やチームデータなど、ボットエンティティに特別な情報を割り当てるのが便利かもしれません。
作成するボットの選択
ゲームの種類によっては、既に知られているデータに基づいて新しいボットを作成するのが有用です。たとえば、まだ選択されていないキャラクターのためにボットを選択したり、異なる難易度のボットを選択したりします。
ヒント： RuntimeConfig アセットは、エンティティプロトタイプへのいくつかの参照（つまり、AssetRefEntityPrototype）を保持できるため、さまざまなキャラクターを参照して選択することができます。あるいは、さまざまな AI アセットを制御するための単一のタイプのキャラクターを持ち、参照を持つこともできます（例：難易度に基づく異なる状態機械）。
プレイヤーとボットのアーキテクチャ
キャラクターは Quantum システムによって制御されます。これらのシステムは通常、プレイヤーの入力を読み取り、キャラクターのゲーム状態を変更する方法を知っています。たとえば、キャラクターを移動させたり、回転させたり、攻撃をトリガーしたりします。
同じキャラクターを AI ロジックで制御することは、複数の方法で行うことができます。以下は通常うまく機能するコードアーキテクチャの例です：
- プレイヤーには自然に Input があり、
frame.GetPlayerInput(playerIndex)でポーリング可能で、これは型Inputの構造体へのポインタを返します。 - ボットもカスタムコンポーネント -
component Bot { Input Input }- に同じ構造体を持ち、AI ロジック自体は内部のデータを埋めるために使用することができます。 - 入力データをすべてのキャラクターシステムが実行される前に埋めます。この方法で、システムが入力を取得する方法を知っている場合、誰がそれを埋めているかに関係なく、追加の特別なチェックをシステム内で行う必要はありません。
- つまり、AI システムは (ほぼ) エンティティの状態に直接影響を与えることはなく、むしろ、意思決定ロジックに基づいて偽の入力を生成します。
このようなアーキテクチャを使用する利点は、以下の通りです：入力 | プレイヤーとボット | キャラクターの明確な分離を提供し、疎結合のシステムを実現します。
覚えておいてください：これは単なる提案です。このアーキテクチャは必ずしも強制ではなく、同じ結果は他の多くの方法で達成できます。
この戦略の視覚化は、Twin Stick Shooter Sample で使用されています。
注意: Twin Stick Shooter Sample は 高度な サンプルであるため、分析する前に Quantum の基本を理解しておく必要があります。
Bot SDK を使用した AI
プロジェクトの AI について考え始めた場合、Quantum の Bot SDK を確認したくなるかもしれません。Bot SDK は、状態機械、ビヘイビアツリー、その他一般的に使用されるソリューションの AI エージェントを作成するためのエディタツールと Quantum コードのセットです。
Bot SDK についての詳細は、こちら を参照してください。
Back to top