【CEDEC2020】オンラインゲーム『BLUE PROTOCOL』で敵AIにパーティを組ませる方法

オンラインゲームをプレイしたことがある人なら、誰しもパーティ内で役割分担しながら強大な敵キャラクターに立ち向かったことがあるでしょう。それではプレイヤーと同様にパーティを組んで、それぞれの役割を全うしながら戦術的に行動する敵キャラクターはどうでしょう。人工知能技術によって自律性を得たキャラクターAIが次に目指すのは、AI同士で集団を形成して意思疎通しながら合理的に行動する協調性です。

9月2日から9月4日までオンライン開催された国内最大のコンピュータエンターテインメント業界向け技術交流会「CEDEC 2020」にて、バンダイナムコスタジオの長谷洋平氏による「BLUE PROTOCOLのパーティバトルを支える集団制御AI」というセッションを取材しました。同セッションでは、広大なゲーム空間に分散する複数のキャラクターを集団として制御するためのAI技術を紹介しています。

『BLUE PROTOCOL』は、バンダイナムコスタジオが開発中のオンラインアクションRPGです。「プレイヤーパーティvsエネミーパーティ」による集団戦闘が最大の特徴で、すべての敵キャラクターがプレイヤー同様にパーティを組んでいるように振る舞います。これによりプレイヤーに敵キャラクターの意図を感じさせ、対人戦のような戦術的なバトルを演出しています。また、戦闘への途中参戦や途中離脱も自由で、その場に居合わせたプレイヤー同士のゆるい共闘も可能だということです。

このようなゲームデザインを実現するには、いかなる状況下でもパーティとして破綻しないように敵キャラクターを動かさなければいけません。また、複数のプレイヤーが同じ空間を共有するオンラインゲームでは、多人数でのプレイに対応できるだけの敵キャラクターの数が必要です。そのため、フィールド全体におけるマネジメント処理の負荷軽減という課題は避けられません。

どこからどこまでをパーティと捉えるか

『BLUE PROTOCOL』のAIは階層構造を成しています。最上部の「AI Director」がフィールドの状況分析やスポーニング制御といったコンテンツ全体の統括を担い、その下で「Faction Coordinator」が各勢力を管理します。ここではサブグループの作成やメンバーのアサインなどが行われます。次に「Combat Coordinator」が攻撃権管理やロールアサインといった役割を果たし、最後に「Character」が挙動を制御するという仕組みです。

広大な空間に分散しているプレイヤーたちはパーティを組んでいることもあれば、それぞれ野良で共闘している可能性もあります。つまり、それぞれの戦闘単位を表す明確な基準は存在しません。そのため「AI Director」は動的にプレイヤー集団を見つけて、同じ集団を狙っている敵同士でひとつのパーティを構成しようとします。

プレイヤー集団の分析には、階層的クラスタリングという手法が使われています。これはデータの類似度をもとにグルーピングする方法で、事前にクラスター数を決定する必要がないのが利点です。ほかの手法にくらべて計算量が増すのが欠点ですが、『BLUE PROTOCOL』では各フレームにおけるステップ数に上限を設けることで負荷を分散しているということでした。

敵キャラクターが感知したプレイヤーはターゲットリストに格納され、それぞれにクラスター情報が割り振られます。この時、基本的にプレイヤー側のクラスターひとつにつき、エネミー側のパーティがひとつ生成されます。ターゲット候補となるクラスターが複数ある場合は、距離や敵意といった変数から最適なアサイン先が決定されます。

パーティ形成の流れをまとめると、「AI Director」がフィールドの状況を分析して敵キャラクターをスポーンさせます。それぞれの敵キャラクターは所属勢力に応じた「Faction Coordinator」にアサインされ、ここで各々のコンテキスト情報をもとに「Combat Coordinator」が作成されます。なお、偵察行動といった戦闘以外のシチュエーションを想定したグループも、この段階で同様に作られるということです。

ログイン中のプレイヤー数やフィールドの状況によって、クラスター情報は常に更新されます。その都度、「Faction Coordinator」はすべての敵キャラクターを対象に再アサインをリクエストするため、クラスターの増減に応じて各グループの構成も変化していきます。例えば、戦闘中のプレイヤーが敵パーティの現在位置から離れるにつれて敵パーティが2つに分割されることもあれば、移動中にプレイヤーが攻撃した個別の敵キャラクターが現在交戦中の敵パーティに組み込まれることもあるというわけです。

キャラクターの思考をどう制御するか

「Character」のエージェントアーキテクチャは、センサーやクエリーで周囲の空間の情報を集める「Perception」、それらの情報をもとに次の行動を決定する「Brain」、進行方向の計算やアニメーションの制御を担う「Action」で構成されています。このうち「Brain」は、さらに「Utility System」「HTN Planning」「Behavior Tree」で構成され、それぞれが「何をすべきか」「どのようにすべきか」「具体的な方法」を決定しています。

HTNは階層型タスクネットワークの略で、「HTN Planning」は行動による状態の変化を考慮した上で、一連の行動を事前に計画する技術です。抽象的なタスクをより具体的なタスクへ分割することで、必要な行動とその順序を見つけるために使われます。たとえば、「朝支度」というタスクは、まず「起きる」「着替える」「朝食」「家を出る」というサブタスクへ分解され、さらに「朝食」は「準備」「食べる」といった具合に細分化されます。それ以上分割できない最下層のタスクには、実行による状態変化が設定されています。

これら階層型の思考ルーチンは「ドメイン」と呼ばれ、ドメインの外側から計画に制約を課すのが「プリファレンス」です。これには必ず満たすべき条件を意味する「ハード制約」と、可能な限り満たしてほしい条件を意味する「ソフト制約」があり、それぞれの計画はプリファレンスが満たされた数によって評価されます。このように、好みに基づいた計画を立てる技術を「Preference-based Planning」といいます。同一のドメインを再利用しつつ、好みに応じて異なるプランを作成できるのが特徴です。

プリファレンスにも、「プリコンディションプリファレンス」「ゴールプリファレンス」「トラジェクトリープリファレンス」といった複数の種類があります。「プリコンディションプリファレンス」は、タスク実行前の状態に対する制約を指します。たとえば、朝食の「準備」というタスクが「ご飯を炊く」と「パンを焼く」という2通りのタスクに分割された場合、お米とパンの所持数によって実行タスクを決定するようなケースで使われます。

「ゴールプリファレンス」は、プラン形成時の最終状態に対する制約です。朝食の準備を例に挙げると、ご飯もしくはパンを食べた後に生じる洗い物の数によって「ご飯を炊く」か「パンを焼く」か決定するような状況で用いられます。「トラジェクトリープリファレンス」は、プラン全体における条件の時間的な変化に対する制約を意味します。たとえば、「起きる」というタスクの次に「着替える」と「朝食」のどちらを優先するかを指定したい時に有効です。

『BLUE PROTOCOL』では、「HTN Planning」のサブドメインとプリファレンスのセットを「タクティカルスキル」と定義しています。ここには攻撃や移動、待機といったあらゆる行動がスキルとして実装されています。これらのサブドメインを組み合わせることで、キャラクターの思考ルーチンが形成されているというわけです。例えば攻撃アクションなら、「近接攻撃」や「間接攻撃」といった詳細な攻撃方法をサブドメインのテンプレートとして定義しておき、それらをどういう状況で使ってほしいかという条件をプリファレンスで指定するという仕組みです。

最適な戦略と戦術はいかに導き出されるか

「パーティvsパーティ」の戦術的なバトルを実現するためには、キャラクターの役割分担が欠かせません。『BLUE PROTOCOL』では、すべてのキャラクターにアタッカーやヒーラー、ディフェンダーといったロールがアサインされており、ロールに応じたタクティカルスキルによって行動の優先度が変化します。しかし、これだけでは常にパーティとして理にかなった行動を取ってくれるとは限りません。

各キャラクターがバラバラに動いてしまうとパーティとしてまとまりがないばかりか、複数のヒーラーが同じ対象を回復したり、複数のディフェンダーが1体のヒーラーを守ったりと、行動が重複してしまう可能性もあります。また、ロールが偏った場合、ヒーラー同士が互いを回復し続けるようなループに陥ってしまったり、1体だけ生き残ったヒーラーがひたすら逃げ続けたりと、何の面白みもない戦闘になってしまうかもしれません。

こうした状況を回避するために一翼を担っているのが「Combat Coordinator」です。前述した「Character」と同様に、「Combat Coordinator」も「Perception」「Brain」「Action」のエージェントアーキテクチャによって構成されています。一方、物理的な身体があるわけではないのでセンサーはなく、クエリーのみを用いて戦略立案に必要な情報や、パーティメンバーの共有情報を収集します。なお、戦闘における大局的な判断には、マップ全体のナビゲーションメッシュから行動の影響度を計算する「Influence Map」が使用されています。

「Combat Coordinator」における「Brain」の部分では、「Utility System」が戦略を立案し、「HTN Planning」が戦術を決定、そして「Behavior Tree」が命令を下します。「Utility System」は環境やメンバーの情報から算出したスコアを比較することで、変化していく状況に応じた最善の戦略を決定します。

たとえば、「牽制する」という戦略はプレイヤー集団とエネミーパーティの距離によってスコアが決定されます。また、「取り囲む」という戦略は、エネミーパーティのサイズがプレイヤー集団を上回っていることを条件に、プレイヤー集団に対するクラスタリングの内包率によってスコアが算出されます。このスコアが更新されるたび、パーティはより効果的な戦略へ切り替えて行動できるというわけです。

戦略の決定時には、戦略ごとに設定されているタスクが「Utility System」から「HTN Planning」へ渡されます。ここでメンバーへのロールアサインやプランニングに必要な変数の計算をとおして、パーティメンバーの戦術が構築されます。ロールアサインでは、ヒーラーしかいないような極端に偏ったパーティ編成を避けるために、コーディネーターが必要としているロールが優先的に割り当てられます。なお、キャラクターにはあらかじめ希望ロールが設定されており、必要ロールと希望ロールがマッチするようにアサインされます。

ここでの戦術とは、メンバーや攻撃権といった限られたリソースの運用効率を最大化するための割り当て方を指しています。「HTN Planning」を使うことでリソースの変化をシミュレートできるほか、プリファレンスを用いたアルゴリズムによって最善の選択肢を効率的に探索できるという利点もあります。この時、「攻撃」「防衛」「範囲バフ」といった各戦術はタクティカルスキルとして実装されており、そこから各メンバーが戦術の候補をあげます。これをもとに「Combat Coordinator」がプランニングして命令を下すという流れです。

どうやってAI同士で効率的に意思疎通するか

このように集団行動を前提に複数のキャラクターを動かすには、キャラクターとコーディネーターの間、あるいはキャラクター同士の間におけるコミュニケーション手段が重要になってきます。前者ならターゲットリストの伝達、後者ならヒーラーへの救援要請などが例に挙げられます。こうした伝達情報やリクエストのパラメータは複数の値を持つことが多く、その内容しだいでは複雑になりがちです。

『BLUE PROTOCOL』では、キャラクターからコーディネーターへの情報伝達に用いる「ブラックボード」と、双方向のコミュニケーションに使用される「メッセージング」に加えて、新たに「タプルスペース」を導入しているそうです。タプルスペースとは、 主に分散コンピューティングのプロセス間通信に使われる処理方式で、タプルという値の組を格納したブラックボードの一種です。データストアと通信を兼ねており、複数の値の組を扱えるという利点があります。タプル取得時には、条件を指定したフィルタリングも可能です。

ピンチに陥ったキャラクターがヒーラーに助けを求める際は、まず「Combat Coordinator」内のタプルスペースに救援要請のタプルを追加します。するとタプルスペースから通知を受け取ったヒーラーは、救援要請を出したキャラクターとの距離などをもとに算出した評価値をタプルスペースへ返します。これらの情報をもとにコーディネーターがプランニングし、救援要請に向かうキャラクターに命令を実行するという仕組みです。

バンダイナムコスタジオは「CEDEC 2019 」にて、「BLUE PROTOCOLの個性豊かなキャラクターを動かす意思決定システム」というセッションを発表しており、その際はキャラクターAIのエージェントアーキテクチャにフォーカスしていました。今回のセッションは、階層的クラスタリングとコーディネーターによる戦闘管理によって、それらキャラクターAIにパーティとして意図を持った振る舞いを追求するものでした。『BLUE PROTOCOL』は2020年4月にクローズドベータテストが実施されており、集団制御AIの実用例としてすでに一定の成功を収めているといえるでしょう。

Writer：Ritsuko Kawai / 河合律子