BLUE PROTOCOLのパーティバトルを支える集団制御AI

CEDEC2020のセッションの講演資料です。
BLUE PROTOCOLで実装されているAIの中でも集団の制御にかかわる部分にフォーカスを当てて紹介します。多くのプレイヤーが同じ空間を共有し様々な場所で同時多発的に起こる戦闘の中から同じ戦闘単位を動的に分類する手法や集団としての戦略を立案する手法を解説いたします。

1. BLUE PROTOCOLの パーティバトルを支える 集団制御AI 株式会社バンダイナムコスタジオ 長谷 洋平
3.  オンラインアクションRPG  操作できる劇場アニメ  パーティ vs パーティ のバトル  2020年4月クローズドβテスト実施
7. パーティ vs パーティ プレイヤーパーティ vs エネミーパーティ • エネミーもパーティを組んでいるように振る舞う 対人戦のような戦術的なバトル • エネミーの意図が感じられる アドリブ感 • プレイヤー同士のゆるい共闘 • 新鮮な体験の提供
8. 課題１ • 多くの種類の敵キャラクターが登場 （人、亜人、野生動物、機械、etc...） • プレイヤーのクラスも多彩 • バトルへの途中参戦、途中離脱も自由 ゲームデザイン面 どのような状況でもパーティとして 破綻なく動かさないといけない
9. 課題２ • 複数のプレイヤーが同じ空間を共有している → 一人のプレイヤーにフォーカスできない • 多人数でのプレイに耐えられる数の 敵キャラクターを出さないといけない オンラインゲームならではの課題 フィールド全体でのマネジメント 処理負荷の軽減
10. 課題まとめ • パーティ vs パーティの実現 • プレイヤーパーティ vs エネミーパーティ • 対人戦のような戦術的なバトル • アドリブ感 • あらゆるシチュエーションで動作する堅牢性 • 大規模マネジメントを低負荷で行う ※本セッションで紹介する事例はクローズドβテスト時点のものです
11. アジェンダ 1. 戦闘グループへの分割 2. キャラクターAI 3. 戦術の決定 4. コミュニケーション 5. まとめ
12. アジェンダ 1. 戦闘グループへの分割 2. キャラクターAI 3. 戦術の決定 4. コミュニケーション 5. まとめ
13. AIヒエラルキー AI Director Faction Coordinator Combat Coordinator Character … キャラクターを制御する コンテンツ全体を管理する （フィールド全体の状況分析、スポーニング制御 など） 各勢力を管理する （サブグループの作成、メンバーアサイン など） 一つの戦闘単位を管理する （攻撃権管理、ロールアサイン など）
14. AIヒエラルキー AI Director Faction Coordinator Combat Coordinator Character … キャラクターを制御する コンテンツ全体を管理する （フィールド全体の状況分析、スポーニング制御 など） 各勢力を管理する （サブグループの作成、メンバーアサイン など） 一つの戦闘単位を管理する （攻撃権管理、ロールアサイン など） パーティ どうやって見つけるか？
15. 広い空間に多くのプレイヤーがいる → パーティで別行動してることもあれば 野良で共闘していることもある
16. 明示的にパーティを組んで 配置されているわけではない 別の戦闘として扱ってほしい
17. 問題 一つの戦闘単位を表す明確な基準がない 方針 プレイヤー同士のゆるい共闘 敵は明示的にパーティを組んでいるわけではない 動的にプレイヤーの集団を見つける 同じプレイヤー集団を狙っている敵同士でパーティを作る
18. プレイヤー集団の分析 階層的クラスタリングを使用 データを類似度をもとに グルーピングする手法 利点： 欠点： 事前にクラスター数を 決めておく必要がない ほかの手法に比べ 計算量が少し多い １フレームでのステップ数に上限を設けて負荷を分散
19. プレイヤー集団の分析 バイアスなし バイアスあり メイン ：位置 バイアス：同じパーティか、etc... 変数 パーティ パーティ
21. パーティ形成 ターゲットリスト ターゲット クラスター プレイヤーA 1 プレイヤーC 2 プレイヤーD 2 ... キャラクターが持つ ターゲットのリスト から対象クラスター がわかる
22. パーティ形成 • 基本的にはプレイヤー側のクラスター１つにつき エネミー側のパーティが１つ作られる • 候補クラスターそれぞれの効用を計算しアサイン先を決める パーティアサイン Combat Coordinator （クラスター１） Combat Coordinator （クラスター２） ✓ ✕ 1.0 0.9 … • 状況（戦闘、巡回、…） • ターゲットリスト • 距離 • 敵意 • グループ コンテキスト情報
23. パーティ形成 キャラクタースポーン時 AI Director Faction Coordinator Character 適切なFaction Coordinatorにアサイン 所属勢力
24. パーティ形成 キャラクタースポーン時 AI Director Faction Coordinator Combat Coordinator Character 作成 必要なグループを作成しアサイン クラスター情報 コンテキスト情報 戦闘以外のシチュエーション用のグループもある （例：Patrol Group）
25. パーティ形成 クラスター更新時 AI Director Faction Coordinator Combat Coordinator Character 再アサインをリクエスト（全メンバー対象） クラスターは増減するので 必要に応じてグループを新規に作る クラスター情報
26. パーティ形成 コンテキスト変更時 AI Director Faction Coordinator Combat Coordinator Character 再アサインをリクエスト （対象キャラのみ） Patrol Group
28. アジェンダ 1. 戦闘グループへの分割 2. キャラクターAI 3. 戦術の決定 4. コミュニケーション 5. まとめ
29. AIヒエラルキー AI Director Faction Coordinator Combat Coordinator Character … キャラクターを制御する コンテンツ全体を管理する （フィールド全体の状況分析、スポーニング制御 など） 各勢力を管理する （サブグループの作成、メンバーアサイン など） 一つの戦闘単位を管理する （攻撃権管理、ロールアサイン など） パーティ Character （CEDEC2019のセッションから抜粋）
30. エージェントアーキテクチャ キャラクターAI Perception Brain Action 環境 身体 Perception Tree ～Behavior Treeを応用したお手軽、柔軟な環境認識システム～, CEDEC2017 自分の周りの空間の情報を収集する （センサー、クエリー）
31. エージェントアーキテクチャ キャラクターAI Perception Brain Action 環境 身体 自分の周りの空間の情報を収集する （センサー、クエリー） 集めた情報をもとに次に何をするか決定する 進む方向の計算やアニメーションの制御を行う
32. エージェントアーキテクチャ キャラクターAI Perception Brain Action 環境 身体 Utility System HTN Planning Behavior Tree 空間認識、身体情報 移動先、アクション 何をすべきか どのようにすべきか 具体的な方法
33. エージェントアーキテクチャ キャラクターAI Utility System HTN Planning Behavior Tree 現在の状況から達成すべき目標を決定する （例：戦う、巡回する、逃げる）
34. エージェントアーキテクチャ キャラクターAI Utility System HTN Planning Behavior Tree 目標を達成するための行動の計画を立てる （同じ目標でもキャラクターごとにアプローチが異なる）
35. Preference-based HTN Planning HTN Planning • 行動による状態の変化を考慮した一連の行動を 事前に計画するプランニング技術の一種 • 抽象的なタスクをより具体的なタスクへ 分割していくことで必要な行動とその順序を見つける Preference-based Planning • 個人の嗜好に基づいた計画を立てる技術 • 好みを後から指定して計画を評価することができる HTN Planning + Preference-based Planning
36. HTN Planning 起きる 朝食 着替える 家を出る 準備 食べる ご飯を炊く パンを焼く 朝支度 ドメイン
37. HTN Planning 起きる 朝食 着替える 家を出る 準備 食べる ご飯を炊く パンを焼く 朝支度 ステート パン：1枚 現在の状態と プリコンディションを比較して 分割していいかを判定する パンがある お米がある ✓ ✕
38. HTN Planning 起きる 朝食 着替える 家を出る 準備 食べる ご飯を炊く パンを焼く 朝支度 ステート パン：0枚 パン -1枚 これ以上分割できないタスクには タスクを実行することで 状態がどう変わるかが設定されている
39. HTN Planning 目を覚ます パンを焼く 朝支度 … キッチンに行く 目覚ましを 止める … これ以上分割ができないところまで分割をし終えるとプランニング終了 タスクを順番に実行していく
40. HTN Planning エディタ 複合タスク プリミティブタスク 事前条件 事後条件 アクション
41. プリファレンス • ドメインの外からプランに課す制約 • 満たされたプリファレンスの数でプランを評価する • 同じドメイン（思考ルーチン）を再利用しつつ 好みに応じた違うプランを作り出せる 制約の強さ • ソフト制約：可能な限り満たしてほしい条件 • ハード制約：必ず満たすべき条件
42. プリファレンス プリコンディションプリファレンス タスクやメソッドの実行前の状態に対する制約 朝食準備 ご飯を炊く パンを焼く プリファレンス：お米 (パン) の所持数が多い ステート お米：10合、パン：1枚 ご飯を炊く ステート お米：1合、パン：10枚 パンを焼く
43. プリファレンス ゴールプリファレンス プランが見つかった時の最終状態に対する制約 プリファレンス：洗い物の数が少ない +4 (お茶碗、お箸、内釜、しゃもじ) ご飯を炊く パンを焼く 食べる 食べる +1 (お皿)
44. プリファレンス トラジェクトリープリファレンス プラン全体を通した条件の時間的変化に対する制約 例：常にAが満たされる、Aが満たされた後Bを満たす など 起きる 朝食 着替える 家を出る プリファレンス：SometimeAfter(着替える, 朝食) 着替える 朝食 評価 朝食 着替える 評価
45. タクティカルスキル • サブドメイン（＋パラメータ）とプリファレンスのセット • 攻撃、移動、待機などのあらゆる行動が スキルとして実装される • 全スキルのサブドメインを組み合わせてドメインが作られる ドメイン
46. タクティカルスキル 例：攻撃アクション サブドメインの テンプレート ドメインへ渡す パラメータ 攻撃の種類ごとに 動きの詳細を記述した テンプレートを使いまわす その攻撃をどういう状況で 使ってほしいかを プリファレンスで定義
47. タクティカルスキル ガードスキルあり ガードスキルなし
48. ロール • 戦闘におけるキャラクターの役割を定義したもの • サポーターは後ろからバフをかける • ディフェンダーがヒーラーを守る • ロールにはタクティカルスキルが設定されており 専用の立ち回りや行動の優先度を変化させている • すべてのキャラクターには何かしらのロールが アサインされ戦闘での役割分担が行われる
49. キャラクターAIまとめ • HTNプランニングを使用して 状況に応じた最適な行動を計画し動いている • プリファレンスを使うことで ドメインを変更せずに細かな変化を付けられる • タクティカルスキルの組み合わせにより 様々なキャラクターの動きが作られている 詳しくは… BLUE PROTOCOLの個性豊かなキャラクターを動かす意思決定システム, CEDEC2019
50. アジェンダ 1. 戦闘グループへの分割 2. キャラクターAI 3. 戦術の決定 4. コミュニケーション 5. まとめ
51. なぜ必要なのか ロールの仕組みで役割分担はできている アタッカー 攻撃役 ヒーラー 回復役 ディフェンダー ヒーラーを守る
52. なぜ必要なのか 同じキャラクターへの行動がかぶってしまう 問題１ • 複数人で同時に回復を行う • 複数のディフェンダーが 一人のヒーラーを守る
53. なぜ必要なのか 各個人がバラバラで動き、全体でのまとまりがない 問題２
54. なぜ必要なのか ロールが偏ることで面倒くさいだけの面白みのない戦闘になる 問題３ • ヒーラー同士が お互いに回復し続ける • 残ったヒーラーが 逃げ続ける
55. 役割 Combat Coordinator ✕ 情報 命令、情報 キャラクター間での命令はない
56. エージェントアーキテクチャ コーディネーター Perception Brain Action 環境 メンバー 自らの戦略立案に必要な情報と メンバーが共通して使う情報を集める（クエリー）
57. Influence Map
58. Influence Map
59. Influence Map
60. Influence Map … clamp(0, 1) x -1
61. Influence Map 前線
62. エージェントアーキテクチャ コーディネーター Perception Brain Action 環境 メンバー 自らの戦略立案に必要な情報と メンバーが共通して使う情報を集める（クエリー） メンバーそれぞれに どのように動いてもらうかを決定する メンバーに命令を出す
63. エージェントアーキテクチャ コーディネーター Perception Brain Action 環境 メンバー Utility System HTN Planning Behavior Tree 空間認識 メンバーから集めた情報 命令 何をすべきか どのようにすべきか 具体的な方法 戦略 戦術 命令
64. 戦略 環境やメンバーの情報からその戦略がどの程度適切かを計算する メンバーの情報 上位層の情報 スコア
65. 戦略 一番スコアが高い(＝適している)戦略を選択する 戦略A メンバーの情報 上位層の情報 0.6 戦略B 戦略C 0.8 0.3
66. 戦略 例：けん制する ／ 取り囲む • プレイヤーが遠くにいるうちは様子見してけん制攻撃してほしい • プレイヤーが近くに来たら周りを取り囲んで攻撃してほしい プレイヤー集団とエネミーパーティとの距離 プレイヤー集団のサイズ < エネミーパーティのサイズ and プレイヤー集団の内包率
68. 戦略 • 選択された戦略に設定されたタスクが プランナに渡され戦術をプランニングする • プランニングの前に戦略ごとの前処理が行われる 前処理 • 戦術のプランニングに必要な変数の計算 （攻撃権の数など） • 各メンバーへのロールのアサイン Utility System HTN Planning タスク
69. ロールアサイン 目的 遊びを担保するために極端に偏ったロールの編成をなくす ヒーラーだけのパーティだと… • プレイヤーが攻撃をしに行っても逃げられる • やっとダメージを与えてもほかのヒーラーに回復されてしまう ヒーラーの一部を攻撃役（アタッカー）に回して ほかのヒーラーは彼らをサポートするようにする
70. ロールアサイン • コーディネーター側で必要としているロールから割り当てていく • 割り当てられるキャラクターがいない場合はスキップ 詳しくは… BLUE PROTOCOLの個性豊かなキャラクターを動かす意思決定システム, CEDEC2019 優先度 数 アタッカー 1.0 2 ディフェンダー 0.8 1 フリー 0.0 ∞ アタッカー ディフェンダー ヒーラー メンバーA 0.1 0.0 1.0 メンバーB 0.5 1.0 0.0 メンバーC 0.1 0.0 1.0 コーディネーター：必要ロール キャラクター：希望ロール ✕
71. 戦術 戦術とは 限られたリソースを効率的に使用して 最も高い効果を得るための割り当てを考える プランニングを使う利点 • リソースの変化をシミュレートできる • 多くの選択肢の中から最も良いものを 効率的に探索することができる リソース：攻撃権、メンバーなど
72. 戦術 • とれる行動（一人～複数人）ごとにタスクが分かれている • 全員をアサインし終えるとプランニング終了 アサイン 攻撃 防衛 範囲バフ 攻撃命令 アサイン
73. 戦術 攻撃命令(A, A) 行為者 対象 評価値 エネミーA プレイヤーA 0.5 エネミーA プレイヤーB 0.7 エネミーB プレイヤーB 0.6 ... 攻撃命令(A, B) 攻撃命令(B, B) プリコンディション：攻撃権 > 0, !assigned(a) エフェクト ：攻撃権 -1, assigned(a) プリファレンス ：評価値 攻撃命令(a, b) 攻撃命令 アサイン
74. 戦術 攻撃：0.5 攻撃：0.8 防衛：1.0 プランナが総合的に考えて アサインしてくれる
75. 戦術 • 一つ一つの戦術はタクティカルスキルとして実装されている • 攻撃や待機などの基本戦術はコーディネーターが持っている • 対象を守るなどの特殊な戦術はメンバーから提供してもらう アサイン 攻撃 防衛 範囲バフ タクティカルスキル タクティカルスキル タクティカルスキル
76. 戦術 Combat Coordinator 戦術候補 命令 メンバーが取れる戦術に関する ドメインしか有効じゃないので プランニングの効率がいい
77. 命令の発行 • プリミティブタスクに関連付けられた ビヘイビアツリーから命令を発行 • 複数人への命令 • 命令のシーケンス（AをやってからBをしろ） • 戦術プランニングの結果は行動のシーケンスではなく アサイン情報なので命令の遂行は待たずにリクエストだけして プランはすぐに終わらせる
78. 命令とは 命令 • タクティカルスキルのリスト • パラメータ 命令の実行 • キャラクターは命令を受け取ると タクティカルスキルを自分のドメインに組み込み、 パラメータをブラックボードに格納する • あとは通常通りプランニングを行い行動する （≠プランニングのゴール） （例）攻撃対象：プレイヤーA
79. 命令とは 例：攻撃命令 攻撃命令のサブドメイン キャラクター側 戦闘 命令を受ける前 命令実行 待機 格闘攻撃A 遠隔攻撃A 攻撃 格闘攻撃B
80. 命令とは 例：攻撃命令 攻撃命令のサブドメイン キャラクター側 戦闘 命令を受けた後 命令実行 待機 格闘攻撃A 遠隔攻撃A 攻撃 格闘攻撃B
81. 命令とは なぜタクティカルスキル？ • 命令を無視できる • 状態異常など Utility System HTN Planning Behavior Tree 命令 ✕
82. 命令とは なぜタクティカルスキル？ • 命令を無視できる • 状態異常など • 特殊な命令が必要なときに 対応しやすい Utility System HTN Planning Behavior Tree タクティカルスキル
83. 命令とは なぜタクティカルスキル？ • 命令を無視できる • 状態異常など • 特殊な命令が必要なときに 対応しやすい • ドメインは再利用しつつ プリファレンスで 行動に変化を付けられる 近接攻撃命令
85. 命令とは 近接攻撃命令 プリファレンスで近接攻撃のみを許可している 遠隔攻撃（ThrowStone）はプランニング中に失敗している
86. アジェンダ 1. 戦闘グループへの分割 2. キャラクターAI 3. 戦術の決定 4. コミュニケーション 5. まとめ
87. コミュニケーション 集団を動かすにはコミュニケーションが重要 • リクエスト（例：救援要請） • 情報の伝達（例：ターゲットリスト） 課題 • リクエストのパラメータや伝達される情報は 複数の値を持つことが多い • 多くのメッセージ、様々な種類のキャラクターが かかわり複雑になりがち （例：特定の種類のキャラクターしか対象にならないリクエスト）
88. コミュニケーション コミュニケーション手段 • ブラックボード （キャラクターからコーディネーター） • メッセージング （双方向） • タプルスペース Combat Coordinator Character Character Blackboard Blackboard Blackboard
89. タプルスペース • 主に分散コンピューティングで プロセス間通信に使用されている • 値の組（タプル）を格納したブラックボードの一種 • 一部の要素の値のみを指定したテンプレートを使用して タプルスペースの検索やタプル追加時の通知を受け取れる
90. タプルスペース write ： タプルを書き込む read ： テンプレートに一致するタプルを読みだす take ： テンプレートに一致するタプルを取り出す notify ： テンプレートに一致するタプルが追加されたときに通知を受け取る TupleSpace ts; ts.write(tuple("message1", 0)); ts.write(tuple("message2", 10)); ts.read(tuple("message1", *)); // message1が返る ts.take(tuple(*, >= 10)); // message2が返り、message2は削除される 例
91. タプルスペース 利点 • データストアと通信を兼ねている • 複数の値の組を扱うことができる • タプルの取得時などに条件を指定して フィルタリングすることができる • 実装がシンプルで容易
92. 救援要請を受けた回復 救援要請を受けられるキャラはタプルスペースで要請を監視する notify HealReq(*, *) Combat Coordinator タプルスペース notify HealReq(*, *)
93. 救援要請を受けた回復 助けてほしいキャラはタプルスペースに要請のタプルを追加する 助けて write HealReq(エネミーA, 0.4) Combat Coordinator タプルスペース HealReq(エネミーA, 0.4) HealReq(エネミーA, 0.4)
94. 救援要請を受けた回復 ヒーラーは距離などをもとに評価してタプルスペースに書き込む Combat Coordinator タプルスペース write HealAct(エネミーC, エネミーA, 0.3) write HealAct(エネミーB, エネミーA, 0.8) 行為者 対象 評価値 エネミーB エネミーA 0.8 エネミーC エネミーA 0.3 ...
95. 救援要請を受けた回復 回復命令(A, B) 回復命令(C, B) プリコンディション：!assigned(a) エフェクト ：assigned(a) プリファレンス ：評価値 回復命令(a, b) 回復 アサイン 行為者 対象 評価値 エネミーB エネミーA 0.8 エネミーC エネミーA 0.3 ...
96. コミュニケーションフロー 1. 通知を受けたい人は事前にタプルスペースに登録しておく 2. タプルスペースにメッセージを投げる 3. 必要な人に通知がいく 4. 処理した結果をタプルスペースに戻す 5. 集まった情報をもとにコーディネーターがプランニング
97. 範囲バフ 仕様 • 詠唱者の周りにバフエリアが発生する • バフエリアに入っている間だけ 強化を受けられる • 範囲バフの行動に参加できる 最大人数は決まっている • 強化を受けたのに 何もできないは困るので 遠距離攻撃ができる人だけ対象
98. 範囲バフ 事前準備 範囲バフの戦術 notify AreaBuffReq(*, 攻撃能力) Combat Coordinator notify AreaBuffReq(自分, *)
99. 範囲バフ 戦術決定 AreaBuffAct(詠唱者, 評価値) 遠距離攻撃の条件を満たす人に通知 AreaBuffRcv(詠唱者, 参加者, 評価値) Combat Coordinator プランニング AreaBuffReq(詠唱者, 遠距離攻撃可) 詠唱者に通知
100. アジェンダ 1. 戦闘グループへの分割 2. キャラクターAI 3. 戦術の決定 4. コミュニケーション 5. まとめ
101. パーティ vs パーティ プレイヤーパーティ vs エネミーパーティ • エネミーもパーティを組んでいるように振る舞う 対人戦のような戦術的なバトル • エネミーの意図が感じられる アドリブ感 • プレイヤー同士のゆるい共闘 • 新鮮な体験の提供
102. 課題１ • 多くの種類の敵キャラクターが登場 （人、亜人、野生動物、機械、etc...） • プレイヤーのクラスも多彩 • バトルへの途中参戦、途中離脱も自由 ゲームデザイン面 どのような状況でもパーティとして 破綻なく動かさないといけない
103. 課題２ • 複数のプレイヤーが同じ空間を共有している → 一人のプレイヤーにフォーカスできない • 多人数でのプレイに耐えられる数の 敵キャラクターを出さないといけない オンラインゲームならではの課題 フィールド全体でのマネジメント 処理負荷の軽減
104. まとめ 階層的クラスタリング 複数のプレイヤーが同じ空間でゆるく共闘していても 動的に戦闘単位を分類することができた コーディネーターによる戦闘の管理 パーティとして意図を持ったまとまりのある 振る舞いをとらせることができるようになった
105. まとめ プランニングによる戦術決定 どのようなパーティ構成であっても 適切な戦術を効率的に見つけられるようになった タプルスペースを使ったコミュニケーション 多くのキャラがかかわる複雑なコミュニケーションも シンプルな仕組みで実現できるようになった