データドリブンとモジュール性に貫かれた『BLUE PROTOCOL』のAIフィロソフィー

2020年11月20日、DeNA主催のゲームクリエイター向け座談会「Game Developers Meeting」において、現在開発中のオンラインアクションRPG『BLUE PROTOCOL』に関する勉強会が行われました。この記事では、登壇したバンダイナムコスタジオのリードAIプログラマである長谷洋平氏の話をまとめることで同ゲームのAIフィロソフィーとその仕組みを明らかにします。

『BLUE PROTOCOL』の概要とAIアーキテクチャ

『BLUE PROTOCOL』とは、バンダイナムコスタジオが開発するPC向けオンラインアクションRPGです。同ゲームの最大の特徴は、「操作できる劇場アニメ」をコンセプトとした美麗なアニメーション描写にあります。また、パーティ同士のバトルも魅力のひとつとなっています。こうした同ゲームは2020年4月にクローズドβテスト、同年11月にはマッチング負荷テストを実施しました。

BLUE PROTOCOLは新規IPのため仕様変更が頻繁に生じ、今後さまざまなコンテンツが追加されることが予想されるため、同ゲームの設計方針として「データドリブン」と「モジュール性」が採用されました。

データドリブンとは、コンテンツがソースコードではなくデータにもとづいて駆動することを意味しています。この方針を採用することによって、仕様変更やコンテンツの追加に対して柔軟に対応できるようになります。またモジュール性とは、ゲームを構成するさまざまな部品を独立して開発したうえで、それらを組み合わせてコンテンツの内容を実現する、というものです。モジュール性を確保することによって、部品の再利用が容易になり開発費を抑制できるようになります。

BLUE PROTOCOLの敵キャラクター（開発上はエネミーと呼ばれる）とNPCを制御するAIの開発においても、以上の2つの設計方針が貫かれています。同AIは制御対象キャラクターと環境の相互作用を担当する「空間認識」、認識した情報にもとづいて行動を決定する「意思決定」、そして意思決定にしたがって身体を動かす「制御」の3つのモジュールから構成され、それぞれのモジュールが必要に応じて「記憶」モジュールと連動します（以下の画像参照）。以下では、各モジュールの解説を通して、それらが再利用される仕組みを明らかにします。

ビヘイビア・ツリーを流用したパーセプション・ツリー

AIキャラクターと環境の相互作用を担当する空間認識モジュールは、センサーシステム、パーセプション・ツリー、影響マップの3機能から構成されます。

センサーシステムは、キャラクターが環境から情報を取得する受動的な知覚に相当する機能です。他のキャラクターを視認したり、周囲の物音を聴いたりする時に動作しています。また、プレイヤーがダンジョンに侵入したのを検知したら、ボスキャラを起動するような環境センサーも制御しています。

パーセプション・ツリーは、攻撃対象の選択のような能動的な知覚を担当しています。この機能は、NPCを制御する手法としては古典的なビヘイビア・ツリーを流用することで動作しています（以下の画像参照）。この機能を編集するエディタもビヘイビア・ツリーを再利用して、ゲーム資源を節約しています。

パーセプション・ツリーでは「敵が攻撃範囲内に入ったら、攻撃対象として選択」のような処理を枝分かれするクエリーと呼ばれる分岐構造で定義していきます。BLUE PROTOCOLのAIにおいては、任意のクエリーの実行結果を後続のクエリーが引き継ぐ「多段階クエリー」、ひとつのフレームで処理しきれない場合には、処理を次のフレームに持ち越す「タイムスライス」も実装されています。

パーセプション・ツリーのパラメータは、他のモジュールから値を参照したり変更できたりする「外に出す」設計がなされています。この設計によって、例えば装備している武器のレンジに応じて、攻撃対象の選択が処理されます（下の画像参照）。

影響マップは、AIがゲーム空間の状態を認識して制御する機能です。この機能は、空間の構造を定義する「レイアウト」とその構造内部を反映する値を格納する箱にあたる「レイヤー」から構成されています（下の画像参照）。

BLUE PROTOCOLにおけるゲーム空間の管理には、レイアウトとして空間を格子構造として処理するグリッドが採用されています。レイアウトは、管理する空間の性質に応じて選択されるのが望ましく、キャラクターやプレイヤーのあいだの関係を管理する場合にはソーシャルグラフが最適なレイアウトとなります。

レイアウトとレイヤーの間の処理は、インデックス（処理対象を指定する番号のようなもの）を介して行われます。このインデックスを使えば、複数のレイヤーが格納する値にアクセスできます。さらに複数のレイヤーや計算式を組み合わせることによって、ゲーム空間に関するさまざまな情報を取得できます。

以上のような影響マップは、パーティどうしの戦闘における前線の特定、プレイヤーがよく通る場所の特定などに使われています。また、ゲーム空間にはモブNPCが存在できる量を定義する密度が定義されており、この密度とプレイヤーのクライアントPCのスペックを考慮しながら、モブNPCの出現や挙動が制御されているのです（下の画像参照）。

スキルを組み合わせて意思決定を表現

AIキャラクターの意思決定は、まず意思決定のコンテクストに応じて処理や出力が変わる「熟考」と一定の状況に対して特定の行動を起こす「反射行動」に分けられます。熟考は、行為の仕組みを論じる研究分野である行為論で提唱された「意図の理論」にもとづいて、目標の決定、手段の選択、行為の実行の3機能に細分化されます。

目標の決定において動作するモジュール「Utility System」は、選択可能な行動ごとに実行したい度合いである「欲求度」を計算し、欲求度のいちばん高い行動を目標として決定します。二番目以降の行動で並行可能なものがあれば、同時に処理します。この並行処理によって、「徘徊しながら注視する」のような行動が可能になります。

手段の選択においては、行動計画を決定する処理「Preference-based HTN Planning」が実行されます。この処理は行動を細分化して処理順序を決定する「HTN Planning」と、行為主体（エージェント）の選好や前提条件を行動に反映させる「Preference-based Planning」を組み合わせたものです。

HTN Planningの動作原理を模式図として表すと、以下の図のようになります。例えば、「朝支度」という行動は、さらに「起きる」「着替える」「朝食」「家を出る」という行動に細分化されます。「朝食」がさらに「準備」と「食べる」に細分化できます。こうした細分化された行動のネットワークは、「ドメイン」と呼ばれます。ドメインにおいて分割を繰り返して分割不可能な行動を特定できると、これらの行動を順番に実行します。

HTN Planningで特定された一連の行動の実行に際して追加されるさまざまな条件が、Preference-based Planningにおけるプリファレンス（Preference：「選好」を意味する英単語）です。プリファレンスは条件付けの強さによって、可能な限り満たすことを命じる「ソフト制約」と必ず満たすことを命じる「ハード制約」に分類されます。

プリファレンスの内容に関しては、行動の前提条件を指定する「プリコンディションプリファレンス」、行動完了時の条件を指定する「ゴールプリファレンス」、行動全体を通した条件の時間的変化を指定する「トラジェクトリープリファレンス」（例えば「着替える」の後に「朝食」の実行を条件づける）があります。

AIキャラクターが実行可能な行動は、Preference-based HTN Planningによって処理される「タクティカルスキル」として定義されます。タクティカルスキルのなかには、多くのAIキャラクターに共通するような「攻撃」「移動」といった行動が含まれており、これらの行動は「スキル」と呼ばれます。スキルはHTN Planningにおけるサブドメインとして処理され、この処理にプリファレンスが適用されることによって、目標を達成する行動が決定されます。AIキャラクターの多様な行動は、サブドメインとプリファレンスの組み合わせによって実現するのです。

以上のようなタクティカルスキルは、例えば「戦闘時にはガードスキルを実行して、盾を構える」のように処理され、AIキャラクターの行動に反映されます（下の画像参照）。

タクティカルスキルが処理されることで行動を実行する方法が決定された後、ビヘイビア・ツリーに従って行動が実行されます。Preference-based HTN Planningとビヘイビア・ツリーで処理が分かれているのは、このふたつをひとつのモジュールとして処理しようとすると複雑になり過ぎてしまうからです。AIキャラクターの意思決定においても、処理を独立して開発した後に組み合わせて実行するモジュール性が貫かれているというわけなのです。

アニメーションにもとづいたキャラクター制御

AIキャラクターの行動をグラフィックに反映させるキャラクター制御においては、アニメーションにもとづいて制御する「アニメーション駆動」が採用されています。この駆動方式のメリットはソースコードで駆動するより自然な動きが実現でき、アニメーションの制作においても制約が少なるところです。この制御方式は、「操作できる劇場アニメ」を標榜するBLUE PROTOCOLに最適だと言えます。

しかし、アニメーション駆動にはデメリットもあります。ソースコード駆動の場合には攻撃範囲や速度をパラメータとして簡単かつ明示的に定義できるのですが、アニメーション駆動ではアニメーションの動きに合ったパラメータを算出してから設定しなければなりません。こうしたアニメーションに合ったパラメータの算出は、「アニメーションサンプリング」という方法を使って行われました。この方法は、事前にさまざまなアニメーションを実行して、その実行結果から再生時間や移動量のような各種データを自動収集するというものです。この方法によって、例えば「攻撃のヒット範囲とヒットするまでの時間から攻撃アクションをトリガーするタイミング」を判定したりします（以下の画像参照）。

アニメーション駆動には、アニメーションにおける運動量の変化を調整するのが難しいというデメリットもあります。例えば「ジャンプ攻撃をヒットさせる」というアニメーションは、さまざまなジャンプ距離に対応しなければなりません。しかし、ジャンプの飛距離ごとにいくつかのアニメーションを制作してブレンドするような方法では、制作コストが高くなってしまいます。

以上の難点は、「アニメーションワーピング」と呼ばれる方法によって解決しました。この方法は、AIキャラクターのモーションにおける位置や向きを1フレームごとに少しずつ調整することによって、運動量の違いを表現します。調整後のモーションが不自然に見える場合には、再生スピードも調整します。こうした調整が可能なのは、アニメーションサンプリングによって収集したデータがあるので調整値が容易に算出できるからです（下の画像参照）。

キャラクター制御の仕組みをまとめると、アニメーション駆動を採用したことによってアニメーターが自由なアニメーションを制作できるのと同時に、サンプリングにもとづいたアニメーションの調整も可能になった、と言えます（下の画像参照）。

以上のような「空間認識」「意思決定」「キャラクター制御」から構成されるBLUE PROTOCOLのAIには、その設計方針である「データドリブン」と「モジュール性」が反映されているのがわかるでしょう。具体的には、パーセプション・ツリーやPreference-based HTN Planningにはデータ自体に処理の仕組みが含まれている点に「データドリブン」が認められ、タクティカルスキルやアニメーションワーピングには基本的な部品の組み合わせから多様な表現を生成する「モジュール性」が表れています。

データドリブンとモジュール性がAIの細部にまで貫かれたBLUE PROTOCOLは仕様変更と追加コンテンツに柔軟に対応できるので、今後の開発を通してさらに魅力的なオンラインゲームになることでしょう。

Writer：吉本幸記