Upgrade to Pro — share decks privately, control downloads, hide ads and more …

BLUE PROTOCOLのゲームAIフィロソフィー

BLUE PROTOCOLのゲームAIフィロソフィー

2020年11月20日に開催された「Game Developers Meeting Vol.42 Online」に登壇させていただいたときの資料です。
BLUE PROTOCOLのゲームAIシステムがどのような思想で作られているか、どのような設計や実装が行われているかについて解説いたしました。

Bandai Namco Studios Inc.
PRO

December 07, 2020
Tweet

More Decks by Bandai Namco Studios Inc.

Other Decks in Technology

Transcript

  1. BLUE PROTOCOLの
    ゲームAIフィロソフィー
    株式会社バンダイナムコスタジオ
    長谷 洋平

    View Slide

  2. 自己紹介
    • 2009年、株式会社バンダイナムコゲームス(当時)入社
    • エースコンバットシリーズ、鉄拳シリーズなどの開発に携わる
    • 現在はBLUE PROTOCOLのリードAIプログラマとして
    全体設計、コア実装、マネジメントなどを担当
    • 開発と並行し、最新の人工知能技術のリサーチも行う
    • 2015年~2020年のCEDECで計10件の登壇

    View Slide

  3. この講演について
    • BLUE PROTOCOLで使用しているAIシステムが
    どのような思想で設計・実装されているかを紹介します
    • システム面にフォーカスしているので
    ゲーム内容に関する話は少なくなっています
    • BLUE PROTOCOLに特化した内容ではないので
    幅広いゲームで参考にしていただけると思います
    • 時間の関係で技術の細部まで紹介できないところは
    最後に紹介する過去の講演資料をご覧ください

    View Slide

  4. アジェンダ
    1. イントロダクション
    • ゲームの紹介、設計方針
    2. テクノロジー
    • 空間認識、意思決定、キャラクター制御
    3. まとめ

    View Slide

  5. アジェンダ
    1. イントロダクション
    • ゲームの紹介、設計方針
    2. テクノロジー
    • 空間認識、意思決定、キャラクター制御
    3. まとめ

    View Slide

  6.  オンラインアクションRPG
     操作できる劇場アニメ
     パーティ vs パーティ のバトル
     2020年4月クローズドβテスト実施

    View Slide

  7. View Slide

  8. View Slide

  9. View Slide

  10. View Slide

  11. AIキャラクター
    エネミー
    味方NPC
    モブNPC

    View Slide

  12. コンテンツ
    フィールド
    闘技場
    ダンジョン
    レイド

    View Slide

  13. 設計方針
    課題
    • 新規IPのため仕様がコロコロ変わる
    • 運営型のオンラインゲームのため将来にわたって
    いろいろなコンテンツが追加される
    データドリブン モジュール性

    View Slide

  14. データドリブン
    コードベースの判定をなくしデータにより定義されるようにする
    開発フェーズや人員のスキルに応じて
    適宜振り分ける
    ビヘイビアツリーであっても一定以上の複雑さを超えると
    企画だけで1からAIの振る舞いを構築するのは困難
    ≠ 企画にすべて任せる
    仕様変更や追加に迅速に対応できる、イテレーションの高速化

    • エンジニア
    • AIデザイナ
    • オートメーション
    例:if (ゴブリンだったら) …, if (ダンジョンだったら) … はダメ!

    View Slide

  15. モジュール性
    責任範囲を明確にし、その責任範囲内で
    シンプルかつ再利用性の高い部品を作る
    2種類のモジュール
    • コアとなる技術レベルでのモジュール
    • データレベルでのモジュール
    部品を様々に組み合わせることで
    多くの仕様を可能な限り安く実現する

    View Slide

  16. ゲームAIエンジン
    描画や物理などのほかの要素技術と違い、ゲームの上に
    実装されているAIを汎用なエンジンとしてプラグイン化
    コア
    フレームワーク
    ゲーム
    AI
    ゲームAIエンジン
    ゲームエンジン

    View Slide

  17. キャラクターとAIの切り分け
    街中のモブNPCを含む全AIキャラクターが操作可能(開発用)

    View Slide

  18. アジェンダ
    1. イントロダクション
    • ゲームの紹介、設計方針
    2. テクノロジー
    • 空間認識、意思決定、キャラクター制御
    3. まとめ

    View Slide

  19. アーキテクチャ
    空間認識
    意思決定
    制御
    環境
    身体
    記憶

    View Slide

  20. アーキテクチャ
    空間認識
    意思決定
    制御
    環境
    身体
    記憶

    View Slide

  21. 空間認識
    センサーシステム(プッシュ型)
    • 環境からイベントを受け取り、それに反応する形で対象を認識する
    Perception Tree(プル型)
    • 自らが能動的に環境を調べて情報を取得する
    Influence Map(データストア)
    • 環境中に情報を格納して状況の分析を行う

    View Slide

  22. センサーシステム
    生物
    • 視覚
    • 聴覚
    • 痛覚
    • etc...
    ゲーム要件
    • ボリューム
    • etc...

    View Slide

  23. Perception Tree
    • 環境を評価するクエリーシステム
    • Behavior Tree の実装を流用して作成している
    • Behavior Tree のエディタをそのまま使用
    • 設定ファイルで、ノードのみ
    Perception Tree 用のものに変更

    View Slide

  24. Perception Tree
    ポイントだけでなくアクターも対象にできるので
    エネミーのターゲット評価も Perception Tree で実現している
    ポイントを生成
    生成したポイントを評価
    (フィルタリング、スコアリング)
    一番スコアが高い
    ポイントを選択

    View Slide

  25. Perception Tree
    クエリーの分岐
    • 自分や周りの状況をもとにクエリーの一部を変える
    • クエリーが失敗したときに別のクエリーを試す
    Behavior Tree を流用する利点 ①

    View Slide

  26. Perception Tree
    多段階クエリー
    • 最初に実行したクエリーの結果を後続のクエリーで使う
    Behavior Tree を流用する利点 ②
    ① ②

    View Slide

  27. Perception Tree
    複数フレームへの処理の分散(タイムスライス)
    • 各ノードは実行時に実際に行った処理量に応じてコストを返す
    • 1フレームでの実行できるコストの閾値を超えると
    そのフレームでの処理は中断して残りを次に持ち越す
    Behavior Tree を流用する利点 ③
    Cost 5 Cost 20 Cost 1
    フレーム1 フレーム2

    View Slide

  28. Perception Tree
    パラメーターを外に出す
    • パラメーター付きBTの機能を活用(Parameterized Behavior Tree)
    Behavior Tree を流用する利点 ④
    BTエディタ UE4

    View Slide

  29. Perception Tree
    パラメーターを外に出す
    • 渡されたパラメータはBTのローカルのBlackboardに入る
    Behavior Tree を流用する利点 ④
    ローカルBB
    パラメーター
    ノードのプロパティへマッピング

    View Slide

  30. Perception Tree
    パラメーターを外に出す
    • 同じクエリーに違うパラメーターを渡して
    近接職、遠距離職のレンジの違いを実現
    Behavior Tree を流用する利点 ④

    View Slide

  31. Influence Map
    グラフ構造のデータ上に値を格納・伝搬させることで
    環境に関する情報を計算、共有するための手法
    Perception Tree はクエリーを
    発行するたびに計算が走るが、
    Influence Map はデータを保持しているので
    大局的な分析や継続的な分析に向いている
    Perception Tree のクエリーから
    Influence Map を参照することも可能

    View Slide

  32. Influence Map
    レイアウト:グラフ構造
    構成
    ソーシャルグラフ
    グリッド ナビメッシュ
    レイヤー:値を格納しておく箱
    ざっくり言うと…
    任意のデータ型の配列(例:float[])

    View Slide

  33. Influence Map
    レイアウト

    View Slide

  34. Influence Map
    レイアウト

    View Slide

  35. Influence Map
    レイアウト

    View Slide

  36. Influence Map
    レイアウト
    ナビメッシュの情報をもとに
    セルのリンク情報を生成
    (セル同士のつながり)
    マップの構造を考慮した
    値の伝搬が可能に

    View Slide

  37. Influence Map
    • レイアウトのグラフ構造を探索してインデックスを取得
    • 同じインデックスを使用してセル情報(位置やリンク情報)と
    そのレイアウトから作ったレイヤーの値にアクセスできる
    問い合わせ
    レイアウト
    レイヤーA
    座標 インデックス
    レイヤーB
    レイヤーC

    View Slide

  38. Influence Map
    • 複数のレイヤーや計算式を組み合わせることで
    基本となるレイヤーを使いまわして様々な目的の情報を得る
    • 同じインデックスでアクセスできるので、最低限の
    オーバーヘッドで単一レイヤーと同じように情報を取得できる
    • 新規レイヤーは追加されないのでメモリの負荷もほとんどない
    複合レイヤー
    コードでの定義例
    auto CompLayer = IM_Mul(
    IM_Add(IM_Layer("FriendLayer"), IM_Inv(IM_Layer("EnemyLayer"))),
    IM_Op([&](auto& Pos) { return Clamp(1 - Distance(Pos, MyPos) / 1000, 0, 1); })
    );

    View Slide

  39. Influence Map
    大局分析
    前線

    View Slide

  40. Influence Map
    プレイヤーがよく通る場所はどこか?
    統計分析

    View Slide

  41. Influence Map
    モブNPCのスポーニング
    モブNPCが歩ける場所、
    たむろしている場所には
    密度が設定されている
    クライアントのマシンスペックや
    処理負荷に応じて
    街の密度感を維持したまま
    モブNPCの数のコントロールを
    できるようにするため

    View Slide

  42. Influence Map
    モブNPCのスポーニング
    密度マップ×負荷やスペックに応じたスケール
    設定された密度を
    満たすように生成する

    View Slide

  43. アーキテクチャ
    空間認識
    意思決定
    制御
    環境
    身体
    記憶

    View Slide

  44. 意思決定
    エネミー・味方NPC
    空間認識
    意思決定
    制御
    環境
    身体
    熟考
    反射行動

    View Slide

  45. 意思決定
    エネミー・味方NPC
    空間認識
    意思決定
    制御
    環境
    身体
    熟考
    反射行動
    何をする?
    どうする?
    行動に移す

    View Slide

  46. 何をする?
    Utility System
    注視
    戦闘
    徘徊
    現在の状況からそれぞれの行動をどれだけしたいか(欲求度)を計算し、一番高い行動を選ぶ
    二番目の行動も並行してできそうであれば並行して行う

    View Slide

  47. どうする?
    Preference-based HTN Planning
    Utility System で決まった欲求を満たすためにどういった行動をすればいいかを計画する
    キャラクターごとに行える行動は違うので計画した結果も別になる

    View Slide

  48. 行動に移す
    Behavior Tree
    Behavior Tree に書かれた行動手順通りにキャラクターを制御する

    View Slide

  49. BDIモデル
    「意図の理論」をベースとしたエージェントアーキテクチャ
    アルゴリズム
    1. 信念と欲求から達成すべき目標(願望)を決め、
    達成手段の候補を求める
    2. 達成手段の候補から実際に行う手段を熟考して決定
    3. 決定した手段を意図として実行する
    4. 外部からの知覚をもとに信念を更新する
    何をする?
    どうする?
    行動に移す

    View Slide

  50. ちなみに...
    何をする?
    どうする?
    命令を与える
    何をする?
    どうする?
    行動に移す
    複雑な行動は行わないので直接行動の実行につなぐ
    コーディネーター(集団制御用AI) モブNPC
    Utility System
    Preference-based
    HTN Planning
    Behavior Tree
    命令の付与に代わっているがアーキテクチャは一緒
    Behavior Tree
    Utility System

    View Slide

  51. データをどう作るか?
    何をする?
    どうする?
    行動に移す
    同じコンテンツならどのエネミーもほとんど共通
    エネミーごとに行えることは違う

    View Slide

  52. Preference-based HTN Planning
    HTN Planning
    • 行動による状態の変化を考慮した一連の行動を
    事前に計画するプランニング技術の一種
    • 抽象的なタスクをより具体的なタスクへ
    分割していくことで必要な行動とその順序を見つける
    Preference-based Planning
    • 個人の嗜好に基づいた計画を立てる技術
    • 好みを後から指定して計画を評価することができる
    HTN Planning + Preference-based Planning

    View Slide

  53. HTN Planning
    起きる
    朝食
    着替える
    家を出る
    準備 食べる
    ご飯を炊く パンを焼く
    朝支度
    ドメイン

    View Slide

  54. HTN Planning
    起きる
    朝食
    着替える
    家を出る
    準備 食べる
    ご飯を炊く パンを焼く
    朝支度 ステート
    パン:1枚
    現在の状態と
    プリコンディションを比較して
    分割していいかを判定する
    パンがある
    お米がある


    View Slide

  55. HTN Planning
    起きる
    朝食
    着替える
    家を出る
    準備 食べる
    ご飯を炊く パンを焼く
    朝支度 ステート
    パン:0枚
    パン -1枚
    これ以上分割できないタスクには
    タスクを実行することで
    状態がどう変わるかが設定されている

    View Slide

  56. HTN Planning
    目を覚ます パンを焼く
    朝支度

    キッチンに行く
    目覚ましを
    止める

    これ以上分割ができないところまで分割をし終えるとプランニング終了
    タスクを順番に実行していく

    View Slide

  57. HTN Planning
    エディタ
    複合タスク
    プリミティブタスク
    事前条件 事後条件 アクション

    View Slide

  58. プリファレンス
    • ドメインの外からプランに課す制約
    • 満たされたプリファレンスの数でプランを評価する
    • 同じドメイン(思考ルーチン)を再利用しつつ
    好みに応じた違うプランを作り出せる
    制約の強さ
    • ソフト制約:可能な限り満たしてほしい条件
    • ハード制約:必ず満たすべき条件

    View Slide

  59. プリファレンス
    プリコンディションプリファレンス
    タスクやメソッドの実行前の状態に対する制約
    朝食準備
    ご飯を炊く パンを焼く
    プリファレンス:お米 (パン) の所持数が多い
    ステート
    お米:10合、パン:1枚
    ご飯を炊く ステート
    お米:1合、パン:10枚
    パンを焼く

    View Slide

  60. プリファレンス
    ゴールプリファレンス
    プランが見つかった時の最終状態に対する制約
    プリファレンス:洗い物の数が少ない
    +4 (お茶碗、お箸、内釜、しゃもじ)
    ご飯を炊く
    パンを焼く
    食べる
    食べる +1 (お皿)

    View Slide

  61. プリファレンス
    トラジェクトリープリファレンス
    プラン全体を通した条件の時間的変化に対する制約
    例:常にAが満たされる、Aが満たされた後Bを満たす など
    起きる
    朝食
    着替える
    家を出る
    プリファレンス:SometimeAfter(着替える, 朝食)
    着替える 朝食 評価 朝食 着替える 評価

    View Slide

  62. タクティカルスキル
    • サブドメイン(+パラメータ)とプリファレンスのセット
    • 攻撃、移動、待機などのあらゆる行動が
    スキルとして実装される
    • 全スキルのサブドメインを組み合わせてドメインが作られる
    ドメイン

    View Slide

  63. タクティカルスキル
    例:攻撃アクション
    サブドメインの
    テンプレート
    ドメインへ渡す
    パラメータ
    攻撃の種類ごとに
    動きの詳細を記述した
    テンプレートを使いまわす
    その攻撃をどういう状況で
    使ってほしいかを
    プリファレンスで定義

    View Slide

  64. タクティカルスキル
    ガードスキルあり ガードスキルなし

    View Slide

  65. アーキテクチャ
    空間認識
    意思決定
    制御
    環境
    身体
    記憶

    View Slide

  66. キャラクター制御
    • コード駆動ではなくアニメーション駆動
    • 多くのアクションは一つのフルボディアニメーション
    メリット
    • 機械的でない、より自然な動きを実現できる
    • より少ない制約で自由にアニメーションを作れる
    • 通信による位置の補間を抑制できる

    View Slide

  67. キャラクター制御
    アニメーション駆動なので調整するのはもっぱらアニメーション
    イテレーション

    View Slide

  68. キャラクター制御
    課題
    • コード駆動であればプログラム上で使う
    パラメーターなどで自分の身体能力がわかるが、
    アニメーション駆動だと自分自身の能力がわからない
    • 例:いつ武器を振れば当たるのかわからない
    • AIが正しくキャラクターを動かせるようにするためには
    アニメーションにあったパラメータを設定しないといけないが、
    設定をミスると不具合の原因になる面倒な作業
    自動でデータを集めたい

    View Slide

  69. アニメーションサンプリング
    事前にモーションをいろいろ出してみて各種データを収集する
    収集データ
    • 再生時間
    • 移動量
    • メタデータ
    (攻撃範囲、時間、etc...)

    View Slide

  70. アニメーションサンプリング
    使用例
    回避アクションの移動量と時間から
    プレイヤーの攻撃を回避できるか判定
    攻撃のヒット範囲と
    ヒットするまでの時間から
    攻撃アクションをトリガーする
    タイミングを判定

    View Slide

  71. アニメーションサンプリング
    サンプリングデータに特定のアニメーションのデータが
    含まれるかを見れば、キャラクターが行えるアクションがわかる
    多くのキャラクターが共通して持つスキルについて
    個々に設定せずにアクションの有無から自動で設定
    使用例
    サンプリングデータを見て自動で
    スキルの有効・無効を切り替えられる

    View Slide

  72. アニメーションワーピング
    • アニメーション駆動であっても
    単純に再生するだけだと
    プレイヤーが狭いスポットに
    入らないと攻撃を当てられない
    • かといってアニメーションを
    いくつも作ってブレンドするのは
    コストが高い
    アニメーションの軌跡をプログラムで調整する

    View Slide

  73. アニメーションワーピング
    • 位置や向きの差分を毎フレーム少しずつ詰めていく
    • 不自然になる場合は再生スピードも調整
    サンプリングデータがあるので計算が容易
    アニメーション ワープ期間

    View Slide

  74. アニメーションワーピング
    目標やワープ期間は複数設定可能

    View Slide

  75. ジャンプ攻撃

    View Slide

  76. ジャンプ攻撃
    アニメーションワーピングによる
    補正も含めた攻撃を当てられる範囲
    ダメージコリジョンが出るまでの
    時間をもとにプレイヤー位置を予測
    青:サンプリングデータ

    View Slide

  77. ジャンプ攻撃
    プレイヤーの予測位置と
    ルートボーンからヒット範囲の
    中心までのオフセットから
    補正の目標位置・向きを決定
    青:サンプリングデータ

    View Slide

  78. キャラクター制御
    制御
    AI
    企画
    アニメーター
    サンプリング
    使用
    調整
    アニメーションとそれに付随するメタデータを調整するだけでAIは自動で正しく制御する!

    View Slide

  79. アジェンダ
    1. イントロダクション
    • ゲームの紹介、設計方針
    2. テクノロジー
    • 空間認識、意思決定、キャラクター制御
    3. まとめ

    View Slide

  80. まとめ
    最初から Behavior Tree をほかにも流用可能なように設計
    → 高機能な空間認識のシステムを安く作成できた
    スキルの組み合わせによるAIの定義
    → 多彩なバリエーションのキャラクターを効率的に量産できる
    アニメーションサンプリングによるデータの自動収集
    → アニメーションの調整だけできれいに動く

    View Slide

  81. 資料
    BLUE PROTOCOL 搭載技術の詳細は以下をご参照ください
    • Perception Tree ~Behavior Treeを応用したお手軽、柔軟な環境認識システム~, CEDEC2017
    (https://cedil.cesa.or.jp/cedil_sessions/view/1657)
    • 空を優雅に飛ぶキャラクターのための3次元パス検索とステアリング, CEDEC2018
    (https://cedil.cesa.or.jp/cedil_sessions/view/1833)
    • BLUE PROTOCOL の個性豊かなキャラクターを動かす意思決定システム, CEDEC2019
    (https://cedil.cesa.or.jp/cedil_sessions/view/2102)
    • BLUE PROTOCOL のパーティバトルを支える集団制御 AI, CEDEC2020
    (https://cedil.cesa.or.jp/cedil_sessions/view/2271)

    View Slide