セミナー

【CEDEC 2019】『BLUE PROTOCOL』に盛り込まれた画期的なAIによる意思決定システム！　個性的な敵キャラを生み出すために必要な一貫性と即応性

バンダイナムコスタジオ

バンダイナムコスタジオ

2019.10.03 11:51

9月4日～6日の期間、CEDEC 2019が、パシフィコ横浜で開催された。3日目にあたる6日、バンダイナムコスタジオによる講演「BLUE PROTOCOLの個性豊かなキャラクターを動かす意思決定システム」が行なわれた。

PC向けオンラインゲームタイトル『BLUE PROTOCOL』には、アニメの世界を彩る多種多様なキャラクターが登場する。それらのキャラクターに各々の個性に応じた行動をさせつつ、ゲームとして一定の遊びを担保するのは多くの困難が伴うという。また、オンラインゲームである本作はリリース後も定期的なアップデートにより多くのキャラクターが追加されていくので、工数の削減が重要なテーマとなる。本講演では、バンダイナムコスタジオで開発中の『BLUE PROTOCOL』を担当する長谷洋平氏が登壇し、本作においてこれらの課題に取り組んだAIの意思決定システムにまつわる紹介を行った。

▲登壇した長谷洋平氏。

▲会場で公開された『BLUE PROTOCOL』のPV。

『BLUE PROTOCOL』は、劇場アニメのようなグラフィックと、パーティ対パーティでのバトルが特徴的なオンラインアクションRPGであることが発表されている。

敵キャラクターも個性的なものが多数登場し、それらがリアルタイムで動きまわるため、行動パターンをしっかりと作り込む必要があった。そのうえで、パーティバトルが成立するような調整、コンテンツ追加に対応できる柔軟性、そして工数の削減と課題は多い。

▲『BLUE PROTOCOL』を制作するにあたって目標としている4点を挙げた。

▲本講演におけるアジェンダ。

長谷氏は、まずエージェントアーキテクチャに関する説明から始める。これは実際に使用しているアーキテクチャであり、バンダナムコスタジオで作成しているゲーム用AI「Munchikin」を使用している。

複雑な環境下でキャラクターを表現するためには「異なる時間スケールへの対応」が重要であると長谷氏は考えている。これを現実世界の人間に例え、「会社へ行く」という大きな目標を達成しようとする過程で、コンビニに立ち寄る、変わりそうな信号を見て走って渡る、飛び出してきた子供を避けるといった複数の目的を同時に遂行している。

そして、これはアクションゲームにおいても同じであり、目標に向けた一貫した行動を続けるなかで、攻撃を回避するといった状況に合わせた臨機応変な対応が必要となる。

しかし、単に状況に合わせた割り込み行動を設定していくだけでは、以前実行していたノードの情報を参照できずに、割り込み行動のあとに本来とは違う行動が選択される可能性が出てきてしまう。

これをひとつのシステムで扱おうとすると、先ほどの例のように行動に一貫性を持たせるのが難しくなる。そこで『BLUE PROTOCOL』開発陣が打ち立てた方針は、「異なる時間スケールごとにシステムを並列に動かす」ことと「各システムが決定した結果を後で調停する」という2点だ。

Brain部分に、一貫した目標を設定するメインロジックとなる「Long-term」、短期課題に対応するリアクションのための「Reactive」を設定。基本的にはReactiveが優先され、状況に応じてLong-termがReactiveを抑制する形にする。

具体的なメインロジックの構成は以下の通りとなっている。これらをさらにひとつずつ解説していく。

まずは「Utility System」の部分で、状況を判断して目標設定をする。ここでは、制限タグの設定に矛盾しないパターンのみ、複数の願望が同時に発生する形に設定する。

会場で公開された例となる動画では、主人公の横を通りすぎるノンアクティブモンスターが、主人公の方に顔を向けて注意しながらも、歩くのをやめずに通り過ぎていく様子が公開された。

「HTN Planning」では、前段階で目標として定められたタスクを分解し、目標達成に必要な行動を見つけ、その順序を組み立てる。ここでは、人が事前知識を使って計画を立てる思考に近いため、直感的な構築が可能であると長谷氏は言及している。

▲具体的な構成は、問題解決の手段を記述した「ドメイン」、自身の環境と状態を示した「ステート」、目標を示す「ゴール」の3つを設定し、「プランナ」に受け渡している。

▲「HTN Planning」の思考パターンを、長谷氏は旅行に例えながら説明している。

これらを踏まえながら、改めてドメイン、ステート、ゴールの流れをゲームに落とし込んで考えると、以下のスライドの下部のような流れとなる。

実際に戦闘を行なっている際の敵キャラクターの様子を写した動画も公開している。ミーンの素のように、自身は移動、攻撃をせずに新たな敵を召喚する敵のパターンも載せられている。

次に、同じ敵が距離によって行動を変える例を見せている。遠くからは急接近して攻撃する敵は、近距離にいる場合はバックステップで距離をとってから、攻撃行動に移っている。

▲敵のコンボ設定も、条件設定次第で複数の攻撃を使い分け、多様な動きを実現可能になる。

また、上記のコンボのようなプランを、ひとつひとつをBehavior Treeに変換することで実行させることも可能。

ここまでの話を踏まえながら、一度メインロジックの図に戻る。ここまでに出てきた図のイメージを用いたスライドを見せながら、リプランニングの流れについても解説している。

ここからは「Scripted Behavior」の話に移る。ワンモーションの再生のような単純なものであれば、プランニングを経由することなく、直接BT実行も可能であることはここで説明されている。

相手の行動に対し、回避やカウンターを実行するような思考に基づかない反射的な行動をリアクションとして扱う。反応するイベントと、対応するアクションをセットとして定義する。

こうしたリアクションは、複数のReactive Skillが並列で動いている状態になっている。意思決定層でこうしたアクションの案を出すだけで、実際に調停と実行を行なうのはアクション層としている。

▲リアクティブスキルの内容次第でメインロジックを止めるケースもある。

ダウンや状態異常といった、外部要因による状態変化は、身体（ここでは「アニメーションステートマシン」）からの通知をReactive Skillが受け取り、最高優先度でアクションのリクエストを行なう。そのためメインロジックは停止する。

また、キャラクターの振る舞いをより自然にするためであったり、ゲームのシステムの都合上で特定の文脈において反応してほしくないリアクションがでてくることがある。こうした場合は、メインロジックからそのリアクションの抑制や許可を設定する。

▲ここまでの内容を1枚の図式にまとめたスライド。

▲ここまでの話を総括すると、結果として行動の一貫性と即応性は両立可能であり、複数の目標を同時に設定できるということになる。

しかし、これだけのシステムが組み合わさっていると、複雑で管理が煩雑になるという懸念も生まれる。キャラクター1体の工数も当然増える。複雑な環境下で動くAIは、部分問題に特化させたシステムを組み合わせることで、個々を単純化させる方が効率的だと言及する。

そのうえで、工数は可能な限り減らすべきである、そうでないと今後の運営も含めて、量産体制が確立できないとしている。

『BLUE PROTOCOL』においては、「Utility System」と「Reactive Skill」でキャラクターとしての共通項を構成し、大きく変える必要がないもとしている。

対して、「HTN Planning」と「Behavior Tree」がキャラクターごとの個性となり、キャラクターごとに大きく異なる部分なので、コストが高くなりがちだという。

個性を出すには、キャラクターごとに専用のドメインが必要になる。とはいえ、キャラクターごとにドメインを作っていてはコストがかかりすぎてしまう。

その解決法として打ち出した方針は、ドメインをアクションごとにサブドメインとして分割、それらを組み合わせることでひとつのドメインを作成するという手法だ。このとき、サブドメインを共有可能にしておくことで、さらに工数の削減ができる。

キャラクターが行なう特定の行動を抜き出し「Tactical Skill」として実装する。これにより攻撃、移動、待機などのあらゆる行動がスキルとして実装される。

▲こうしたスキルをマージしてドメインを作成する。

▲スキルのマージポリシー。単なるロジック追加だけでなく、オーバーライドも可能なので、A+BとB+Aが必ずしも同じではないということになる。

▲ガード行動があるパターンとないパターンの比較。

▲ここまでをまとめたスライド。重要なのは、サブドメインとパラメータに分割し、スキルの組み合わせでキャラクターAIを作るようにしたことで、開発工数の大幅削減につながるという点。

しかし、これらを活用するためには「HTN Planning」に課題が生まれる。それは、目標を達成するプランが複数あるとき、品質を考慮せずに最初に見つかったプランを返してしまうこと。必要な情報をすべてドメインに埋め込む必要があり柔軟性が低くなる。

▲サブドメインを多くのキャラクターで共有すると、特定のキャラクター用の対応が、別のキャラクターの行動にまで影響を及ぼす。

そのため、そりキャラクターの個性を考慮するための「Preference-based HTN Planning」を導入し、同じドメインを共有しながら行動に変化をつける形をとった。

▲設けるべき制約の強さと種類をまとめたスライド。

トラジェクトリープリファレンスでは、条件の時間的な変化を参照する。ここでは、線形時相論理を基にしたオペレータを使用している。

敵キャラクターが攻撃アクションをとる際に、該当メソッドにプリコンディションプリファレンスを設定。その行動が今の状況に適しているのか評価する。このとき、評価の基準となるのは、ターゲットとの距離や角度、同一のアクションを使ってからの経過時間といった要素がある。

▲ターゲットまで移動せずにアクションをしてほしい場合に移動を制限したり、部位破壊のような状態変化による行動制限、状態異常による行動優先度の変化をも設定できる。

▲「Preference-based HTN Planning」に関するまとめ。

ここからはパーティバトルの実現のための手法を紹介しているが、これはあくまでも一つの要素であり、これがすべてではないという点に留意してほしい。

『BLUE PROTOCOL』では、複数のキャラクターを動かすにあたり、集団を指揮するAIが個々のAIを階層的に管理するようにし、AIにヒエラルキーを設けている。

戦闘におけるキャラクターの役割を意味するロールの設定では、状況に応じたロール変更を可能にしたいという要件があった。そのために定めた目標は「どんなキャラクターもロールの最低要件さえ満たしていればどんなロールにもなれる」システムとなった。

▲ロール専用の立ち回りやアクションは、前述したTactical Skillとして追加し、優先度の変更や抑制はプリファレンスで制御している。コーディネーター側で必要としているロールを割り当てるようにも設定されている。

▲ここまでの内容をまとめて図式化したスライド。

▲講演全体のまとめ。

▲副産物として、当初予定になかった敵キャラクターから、技の構成を変更したエネミーがひっそりと作られていたりと、キャラクターが多様化しやすい環境にはなっているようだ。

これで長谷氏による講演内容はすべてとなる。最後に、「プリファレンスはすごいということだけは覚えて帰ってください」と付け加えながら、本講演の幕を閉じた。