【GDM37】ゲームAIにおける意思決定と地形表現～『LEFT ALIVE』を事例に紹介～

ゲームAIにおける意思決定と地形表現
～『LEFT ALIVE』を事例に紹介～
株式会社スクウェア・エニックス
プログラマー長谷川誠
© 2019 SQUARE ENIX CO., LTD. All Rights Reserved. 1

自己紹介
• 専門学校卒業後、2004年、フロム・ソフトウェア入社
• アーマード・コアシリーズなどのゲームプレイ要素（敵・AI・イベン
トなど）、マルチプレイ制御を主に担当
• 2015年、セガゲームス入社
• ファンタシースターオンライン２のエネミー、プレイヤークラス（サ
モナー）を担当
• 2016年から現職
• LEFT ALIVEのAI全般を担当

ゲーム解説用のトレーラーを再生したページです。
以下の動画と同じ内容です
https://www.youtube.com/watch?v=LR0NZzjhe7I

今回の話
1. 意思決定
2. CEDEC2019でこぼれた地形表現
毎週社内AIセミナーやってます

意思決定
『LEFT ALIVE』で採用したHTNの話

1. なんでHTNを採用した？
2. HTNの具体的な説明
3. 『LEFT ALIVE』のHTN実装
4. リプランニングについて
5. ドメインの実装
6. 失敗と教訓
7. まとめ
『LEFT ALIVE』の意思決定

6. 失敗と教訓
7. まとめ

なぜHTNを採用したのか
• 『LEFT ALIVE』は、
OROCHIエンジンを採用した
• OROCHIエンジンにAI機能は
あったが『LEFT ALIVE』の
企画内容の複雑さに
耐えられそうになかった
https://www.siliconstudio.co.jp/middleware/orochi/product/library/

なぜHTNを採用したのか
• タイトルの複雑さに耐えるAIアーキテクチャを自作する
• 候補としては、以下の４つ
• Behavior Tree
• 階層型ゴール思考
• HTN
• GOAP

アーキテクチャの比較
Behavior Tree 階層型ゴール指向 HTN GOAP
分類ビヘイビアベースゴールベースタスクベースゴールベース
主な採用事例 HALOシリーズ
Unreal Engine標準
CHROMEHOUNDS KILLZONE2～ F.E.A.R
Tomb Raider
局所的な対応 ◎ ◎ ○ △
ノード数多中小極小
複雑な環境に適応 △ ○ ◎ ◎
開発経験業務レベルはなしありなしなし
企画の細かい要望に耐えつつ
複雑な状態を扱えて
ノード数が爆発して扱いきれなくなるのを避けたい

Behavior Tree 階層型ゴール指向 HTN GOAP
分類ビヘイビアベースゴールベースタスクベースゴールベース
主な採用事例 HALOシリーズ
Unreal Engine標準
CHROMEHOUNDS KILLZONE2～ F.E.A.R
Tomb Raider
局所的な対応 ◎ ◎ ○ △
ノード数多中小極小
複雑な環境に適応 △ ○ ◎ ◎
開発経験業務レベルはなしありなしなし
アーキテクチャの比較
企画の細かい要望に耐えつつ
複雑な状態を扱えて
ノード数が爆発して扱いきれなくなるのを避けたい

HTN
階層型ゴール指向
抽象度：大
抽象度：小
• EQSで指定された位置へ移動
• N秒間トリガーを引く
など、
抽象度の小さい具体的な行動を扱う
• 敵を攻撃する
• 罠を解除する
• 撤退する
など、
抽象度の大きいタスクから、
小さいタスクへ分解

6. 失敗と教訓
7. まとめ

HTN
• Hierarchical Task Networkの略
• 階層型タスクネットワーク

2019年現在、HTNの情報増えてます
• バンダイナムコスタジオの長谷さんの資料が素晴らしいです
• 複数タイトルで使われた柔軟性の高いAIエンジン
https://cedil.cesa.or.jp/cedil_sessions/view/1287
• プレイヤーに反応するだけのAIはもう古い！ゲームAIへのプランニン
グ技術の導入
• BLUE PROTOCOLの個性豊かなキャラクターを動かす意思決定システ
ム
• WEBを検索すると、日本でここ数年、
HTNに関する記事が増えている（流れが来てる？？）

HTNって
超ざっくりいうと、
ネットワーク状のタスクを自動的に
目的に沿ったタスクのリストにする
です

Task
Task
Task
Task
Task
Task Task
Task
Task
Task
Task
Task

HTNの構成要素
• ワールドステート
• タスク
• プリミティブタスク
• プリコンディション
• オペレータ
• エフェクト
• コンパウンドタスク
• メソッド
• プリコンディション
• プラナー
ドメイン

ワールドステート
• その名の通り自分を含めた、世界の状態
ターゲットが見えているか？
= true or false
トラップがあるか？
= true or false
などなど
『LEFT ALIVE』では
１４３種類（多すぎ… ）

プリミティブタスク
お腹へっている
お腹いっぱい
食べる
プリコンディション
タスクを実行するための条件
エフェクト
タスクが実行できたときに、
ワールドステートへ与える影響
オペレータ
実際に行う行動
ご飯を食べる
実際に世界に影響を与える
行動を表す

コンパウンドタスク
ご飯を食べる
メソッド１
ご飯がある
食事する
ご飯を買いに行く
メソッド２
ご飯を食べる
お金持ってる
タスクが達成すべき結果に至る方法を
記述したメソッドを複数持つ
メソッド
自身が選ばれるための
コンディションと、
選ばれたときの
タスクのリストを持つ
どちらを選んでも、
このコンパウンドタスクがほしい
結果になるようにメソッドを作る

Task
Task
Task
Task
ドメイン
Task
Task Task
Task
Task
Task
Task
Task

プラナー
Task
Task
Task
Task
Task
Task Task
Task
Task
Task
Task
Task
ドメインをワールドステートを
参照・編集して、
タスクのリストにする機能

プランニングのアルゴリズム
プランスタックにルートタスクを積む
While スタックが空になるまで繰り返す
スタックからタスク候補を取り出す
if コンパウンドタスク場合
最適なメソッドを検索
if 最適なメソッドがある
メソッド内のタスクをプランスタックに積む
展開履歴をとっておく
else
展開に失敗したので、最後に展開した状態に戻す
else
if タスクのプリコンディションが真
タスクをプランリストに追加
プランニング中ワールドステートを変更
else
最後に展開した状態に戻す

食事する
ご飯を食べる
メソッド１
ご飯がある
ご飯を食べる
食べる
お腹いっぱい
ご飯がある
ご飯がある＝
ある or ない
お腹いっぱい＝
True or false
お金＝あるorない
ご飯を買う
メソッド２
食事する
ご飯なし
ご飯を買う
ご飯を買う
ご飯があるお金なし
お金がある
常に真

ご飯がある＝ある or ない
お腹いっぱい＝true or false
お金＝あるorない
プランスタック
プランリスト
プランニング中

食事する
ご飯ある
ルートタスク
初期状態

ご飯ある
食事する食事する
ご飯を食べる
メソッド１
ご飯がある
ご飯を買う
メソッド２
食事する
常に真

ご飯ある
食事する
ご飯を食べる
メソッド１
ご飯がある
ご飯を買う
メソッド２
食事する
常に真

ご飯ある
ご飯を食べる

ご飯ある
ご飯を食べる
ご飯を食べる
食べる
お腹いっぱい
ご飯がある
ご飯なし

ご飯なし
お腹いっぱい
食べる
プランスタックが空なので、
プランニング終了

ご飯なし
お金ある
食事する
ルートタスク
初期状態を
変更してみる

ご飯なし
お金あり
ご飯を食べる
メソッド１
ご飯がある
ご飯を買う
メソッド２
食事する
常に真

ご飯なし
お金あり
食事する
ご飯を食べる
メソッド１
ご飯がある
ご飯を買う
メソッド２
食事する
常に真

ご飯なし
お金あり
食事する
ご飯を買う

ご飯なし
お金あり
食事する
ご飯を買う
ご飯を買う
ご飯を買う
お金がある

ご飯あり
お金なし
食事する
ご飯を買う

ご飯あり
お金なし
食事する
ご飯を買う
食事する
ご飯を食べる
メソッド１
ご飯がある
ご飯を買う
メソッド２
食事する
常に真

ご飯あり
お金なし
ご飯を買う
食事する
ご飯を食べる
メソッド１
ご飯がある
ご飯を買う
メソッド２
食事する
常に真

ご飯あり
お金なし
ご飯を買う
ご飯を食べる

ご飯あり
お金なし
ご飯を買う
ご飯を食べる
ご飯を食べる
食べる
お腹いっぱい
ご飯がある
ご飯なし

ご飯あり
お金なし
ご飯を買う
ご飯を食べる
食べる
お腹いっぱい
ご飯がある
ご飯なし

ご飯なし
お金なし
お腹いっぱい
ご飯を買う
食べる
プランスタックがからなので、

ご飯なし
お金なし
食事する
ルートタスク
初期状態を
変更してみる
（失敗するケース）

ご飯なし
お金なし
ご飯を食べる
メソッド１
ご飯がある
ご飯を買う
メソッド２
食事する
常に真

ご飯なし
お金なし
食事する
ご飯を食べる
メソッド１
ご飯がある
ご飯を買う
メソッド２
食事する
常に真

ご飯なし
お金なし
食事する
ご飯を買う

ご飯なし
お金なし
食事する
ご飯を買う
ご飯を買う
ご飯を買う
お金がある
プリコンディションで失敗した場合、
最後にコンパウンドタスクを
展開する前の状態に戻す

© 2019 SQUARE ENIX CO., LTD. All Rights Reserved.
ご飯なし
お金なし
食事する
最後にコンパウンドタスクを
展開する直前の状態に
もどす

ご飯なし
お金なし
ご飯を食べる
メソッド１
ご飯がある
ご飯を買う
メソッド２
食事する
失敗するのがわかっている
メソッドは
選択候補にしない

ご飯なし
お金なし
プランスタックが空なので、
ただし、プランリストも
空なのでプランニング失敗

プランの実行について
• 全順序タスク
• 半順序タスク

全順序タスク
お湯を
沸かす
カップラーメン
にお湯を注ぐ
３分
待つ
同時に処理出来ないタスク

半順序タスク
カレー
ルーを
作る
ご飯を
炊く
お皿に
もる
同時に処理できるタスク

HTNのプランニングまとめ
• HTNはワールドステートを「仮想的に」変更しながら、
将来に向かって一貫性のあるプランを立てる事ができる
• 逆にプランが立たない＝タスクは成功終了できない事が事前にわかる
• BTと違ってツリー形状ではないため、柔軟な組み方ができる
• 複数のコンパウンドタスクから、共通のプリミティブタスクを参照す
る事ができる
• コンパウンドタスクから自らへの参照で再帰に展開する事もできる
（再帰するタスクのプランニング時の無限ループには要注意）

6. 失敗と教訓
7. まとめ

『LEFT ALIVE』のHTN実装
• Game AI Pro 12 「Exploring HTN Planners through
Example」を参考に実装
• http://www.gameaipro.com/GameAIPro/GameAIPro_Chapter12_Exploring_HTN_Planners_through_Example.pdf
• すごくシンプルな実装
• 半順序タスクは扱わない
• タスクは引数を取らない
• プランの良し悪しはメソッドの並び順

『LEFT ALIVE』のHTN拡張
1. オペレータ並列実行
2. 成功コンディション
3. 成功タイムアウト/失敗タイムアウト
4. クールタイム
5. 優先実行時間

オペレータ並列実行
• 課題
• 半順序タスクを扱わないHTNだから「〇〇しながら××」ができない
• 射撃しながら移動
• シールドを構えながら移動
• 解決策
• プリミティブタスクに複数のオペレータを登録できるようにして、
同時にオペレータを実行する

成功コンディション
• 課題
• ほとんど同じプリミティブタスクのオペレータを共通の実装にしたい
• 例：１０ｍまで敵に近づく、見えるまで敵に近づく
• 解決策
• 成功終了する条件をプリミティブタスクに持たせる
成功コンディションの機能
オペレーターの機能
+ ０ｍまで近づく
敵との距離が１０ｍ以内
敵が見えている

成功タイムアウト/失敗タイムアウト
• 課題
• タイムアウト処理を個別のオペレータで実装するのが面倒くさい
• 旋回速度が遅くてなかなか正面に捉えられないから諦めて、次のアクションを実
行する（＝成功終了して次タスクへ）
• 近づいて殴りたいが、なかなか近づけないから殴るのをやめる（＝失敗終了）
• 解決策
• プリミティブタスクのデフォルトの機能として用意する

プリミティブタスクのクールタイム
• 課題
• 強力なボスの攻撃を連発しないようにしたい
• 牽制用グレネードを投げすぎない
• 解決案
• プリミティブタスクを実行したら、クールタイムを設定
• クールダウン中の場合、プリコンディションでfalseになった扱いに

優先実行時間
• 課題
• ボスのガトリング攻撃は、比較的長めのモーションを再生して
攻撃姿勢になるので、極端な状態変化が無い限り実行しつづけたい
• 解決策
• 新しいプランを計算しない時間をプリミティブタスクに設定
• その時間が過ぎるまではプランを置き換えない

6. 失敗と教訓
7. まとめ

リプランニング
• ゲームの状態は変化し続けるので、
プランは立てた瞬間から腐っていく
• あるプランの実行中、裏側で常に優先度の高い、
より状況に対応した、次のプラン候補を検索する
• リプランニング周期：
• 個別エージェント＝0.5sec
• 部隊＝2.0sec

Task
Task
Task
Task
Task
Task
Task
実行中プラン次プラン候補
優先度が高いプランが
出来たら置き換え

プランの優先度
• コンパウンドタスク内のメソッドの番号が若いほうが
優先度が高い扱いとする
• Game AI Pro 12.8 で紹介されいている方法
• コンパウンドタスクを展開するときに、
メソッドの番号をとっておいて、それを優先度比較用とする
• Method Traversal Record(=MTR)

Root
Method1 Method2
SubTask
Method1 Method2
パターン１
Root:Method1 > SubTask:Method1
パターン2
Root:Method1 > SubTask:Method2
パターン3
Root:Method2
優先度の順番は、
１＞２＞３
は、プリミティブタスクへの参照

優先度の高いプランへの置き換え
• 実行中のプランを入れ替えるとき、そのまま入れ替える場合と、
現在実行中のプランとうまくマージする必要がある場合がある
ラーメンを作る
フォークで
食べる
ラーメンを作る
箸で
食べる
実行中
優先度：低
優先度：高

優先度の高いプランの置き換え
• プランの置き換え時に現在実行中のタスクより上位のメソッド
で分岐している場合は、現プランをすべて破棄して、新しいプ
ランに置き換え
• そもそもやろうとしている事が変わっている
• 下位のメソッドで分岐している場合、現在実行中のタスクはそ
のまま実行し、未実行タスク部分だけを置き換える

食事する
ラーメンを
調理する
食べる
ケーキを
買う
食べる
食べる
箸で
食べる
フォーク
で食べる
実行中プラン
MTR：2, 2
ケーキを
買う
フォーク
で食べる
実行中

食事する
ラーメンを
調理する
食べる
ケーキを
買う
食べる
食べる
箸で
食べる
フォーク
で食べる
実行中プラン
MTR：2, 2
ケーキを
買う
フォーク
で食べる
プラン候補
MTR：1, 1
ラーメンを
調理する
箸で
食べる
ここで分岐
全部のプランを入れ替える

食事する
ラーメンを
調理する
食べる
ケーキを
買う
食べる
食べる
箸で
食べる
フォーク
で食べる
実行中プラン
MTR：1, 2
ラーメンを
調理する
フォーク
で食べる
実行中

食事する
ラーメンを
調理する
食べる
ケーキを
買う
食べる
食べる
箸で
食べる
フォーク
で食べる
実行中プラン
MTR：1, 2
ラーメンを
調理する
フォーク
で食べる
プラン候補
MTR：1, 1
ラーメンを
調理する
箸で
食べる
実行中タスクは
そのまま
未実行は入れ替え

優先度の高いプランの置き換え
• なんで必要？
ラーメンを調理するラーメンを調理する
実行済み
• タスクの中断処理
• 中間の状態を保存
• 中間の状態から復帰
全てのプリミティブタスクで対応するのは大変
旧プラン新プラン

強制的なプランの置き換え
• 状況が大きく変わった時は、現在実行中のプランに関係なく、
新しいプランに置き換える
• 非戦闘状態から戦闘状態に変わった
• ターゲットが変わった
• 罠を発見した
• 部隊からの指示が変わった
• HTNの外側でルールを記述しておいて、それが発火したら、
現在のプランを捨てる
• 捨てるから、現在プランとのマージ処理が走らずに適用される

プリミティブタスク実行の失敗時
• プリミティブタスクの実行が失敗したとき、全てのタスクをプ
ランし直すのは、負荷が高いし、コンテキストが維持しづらい
ラーメンを作る箸で食べる
箸を床に落としちゃった！
実行済み

プリミティブタスク実行の失敗時
• プリミティブタスクを実行中失敗した場合、そのタスクを含ん
だメソッドを選択対象外として、そのメソッドを含んだコンパ
ウンドタスクをルートタスクとして、部分プランニングを実行
する
• 部分プランニングが失敗した場合、更に上位のコンパウンドタ
スクをルートタスクとして、部分プランニングを実行する
• ２階層上位で失敗した場合は、ルートタスクから全体をリプラ
ンニングする

食事する
ラーメンを
調理する
食べる
ケーキを
買う
食べる
食べる
箸で
食べる
フォーク
で食べる
ラーメンを
調理する
箸で
食べる
失敗

食事する
ラーメンを
調理する
食べる
ケーキを
買う
食べる
食べる
箸で
食べる
フォーク
で食べる
ラーメンを
調理する
箸で
食べる
ここをルートタスクとして、
部分的にプランし直す

食事する
ラーメンを
調理する
食べる
ケーキを
買う
食べる
食べる
箸で
食べる
フォーク
で食べる
ラーメンを
調理する
フォークで
食べる
置き換え

プリミティブタスクの失敗履歴
• 失敗したタスクを参照するメソッドの履歴を保持し、
連続して失敗したメソッドが選択されないようにしている
• 失敗履歴は置き換えたプランが正常終了するまで保持し続ける
• とりあえずこの方法でうまく行っている様に見える

プランニングの負荷軽減策
• コンティニューメソッド
• KILLZONE 2 で紹介されていた機能
• プラン作成時の条件が成立している時は、プランを繰り返し実行する
• コンティニューメソッド実行中は、周期的なプランニングを行わない
• プランニングの計算コストを下げられる

B C D
E F
Root
Task1 Task2
Task3
A
E
プラン１
MTR:1,1,1
A
E
プラン１
MTR:1,1,1
A
コンティニューメソッドを含んだプラン
プラン終了時、メソッド・
プリミティブタスクのプリ
コンディションが成立して
いたら、同じプランを作成

その他の工夫
• ランダムメソッド
• コンパウンドタスク内のメソッドを、
プリコンディションによる評価ではなく、一定の割合で選択する
• 内部的にはコンティニューメソッドの扱い
• ランダムで選択されるのでMTRでの比較を行うと、
意図しないプラン切り替わりが発生するため

6. 失敗と教訓
7. まとめ

ドメインの種類
基本形兵士ヴァンツァードローン戦車ヘリ部隊
派生型スナイパー
固定砲台兵
エリート
ボス１
ボス２
ボス１
ボス２
巡回
飛行携帯
地上携帯
イベント用イベント用ドローン部隊
スナイパー部隊
ヴァンツァー部隊
• 基本形のドメインのタスクと同名のタスクを派生で記述すると、
オーバライドできるようにした
• ほぼ同じドメインで、一部だけ違う時、コピペせずに済む
全部で２７種類

通常兵
スナイパー兵
C++の継承
みたいな感じ

ドメイン内のタスク数
種類コンパウンドタスクプリミティブタスク合計
通常兵士 106 198 304
ヴァンツァー 37 75 112
ドローン 24 41 65
部隊 11 25 36
正直、多いと思います
なんでこうなったかは、後ほど…

ドメインをLuaスクリプトで実装
• Luaスクリプトのテーブルを使って実装
• Luaスクリプトはロード時に実行するだけで、
内部処理用に変換し、プランニング時にlua_pcallは呼ばない
• スクリプトはランタイムでリロードできるようにして、
イテレーションを楽に
• なんでLua？
• すでにLuaが実行できる環境があって、比較的に使い慣れていて、
可変長のテーブルが扱えれば、何でも良かったから

--罠を破壊タスク
DestroyTrap = {
--メイン射撃武器で攻撃するので、弾がなければリロード。
method10 = {
precondition = function()
hnot(hbitand(WS_WEAPON_BIT_PRIMARY, AI_WEP_SLOT_BIT__LOADED))
end,
subtask = {
"ReloadForShootTrap",
"DestroyTrap",
},
},
method20 = {
subtask = {
"ShootTrap",
},
},
}
コンパウンドタスクの記述例
最初に評価される
メソッド
「メイン武器がロード
済み」ではない
リロードしてから、罠破
壊タスクをもう一度評価
２番目に評価されるメソッド
罠を射撃

--パンチできる距離まで近づく
ApproachPunchRange = {
operator = {
success_condition = function()
hbitand(WS_MELEEMAN_STAT_BIT, AI_MELEEMAN_BIT__IN_PUNCH_RANGE)
end,
operation = OpApproachTarget(AI_LOCATION_KIND__TARGET, AI_MOVE_SPEED__SPRINT, 10),
asyncop1 = OpKeepHeadingAt(AI_LOCATION_KIND__TARGET),
expect_effect = function ()
wsbitor(WS_MELEEMAN_STAT_BIT, AI_MELEEMAN_BIT__IN_PUNCH_RANGE)
end,
}
}
プリミティブタスクの記述例
パンチできる距離まで近づ
いたら成功終了
主オペレータ
「ターゲット位置まで移動」
並列オペレータ
「ターゲット方向を向き続ける」
「パンチの間合いに
入っている」状態設定

『LEFT ALIVE』のオペレータ実装
• 実際に世界に影響を与えるオペレータ
• エージェント用：約160種類
• 部隊用：25種類
• C++ で実装
• 階層型ゴール指向
• EQSの計算結果位置へ移動
• 装備している武器をエクセルの指定時間射撃
• メイン武器をリロードする
• 初期位置付近の巡回ルートを巡回
• 指定位置へ旋回
• 指定方向へヴァンツァーステップ移動
• カバーに入る
• 所持している携帯ドローンを放つ
• 避難用シェルターへ入る
• 止血する
などなど

6. 失敗と教訓
7. まとめ

『LEFT ALIVE』の失敗と教訓
• HTNを採用してみて、うまく行かなかった事の紹介です
• HTNは全く銀の弾丸ではないです…

HTN用ツールがない
• ドメインはLuaで実装
• シンタックスエラーとかは、ビルド時・実行時に拾えるけど…
• デバッグは基本的にログと、実行中MTRのデバッグ表示
採用されたタスクとメソッド
実行中のプリミティブタスクの
デバッグ表示

HTN用ツールがない
• どういう理由でプランが採用されたかが追いづらい
• 採用されなかったメソッドの「採用されない理由」が追いかけづらい
• ログも追いやすいものではない
BT以上のツールサポートが無いと厳しい
ドメインからプランが生成される過程がグラフィカルに、進めたり戻
したり出来て確認できるのが理想的

ドメインを書ける人が居ない
• 結局、プログラマしか書いていない
• システムが最初からは安定動作していない
• 改修する度、ちょこちょこドメイン自体の書き換えを行っていた
• おまかせ出来ない状況が続いた
• お願いしようとしていた人のキャパがほか作業でいっぱいに
• BTならUnreal Engineのおかげでデファクトになっているので、
最悪、人を追加（＝お金で解決）できる可能性もあったかも？
BTとのハイブリッドシステムなら、人員配置を柔軟にできる

HTN自体をシンプルにしすぎた
• 実装の参考にした Game AI ProのHTNは、
引数を取らないため非常にシンプル
• シンプルが故に複雑さを吸収するのはドメイン
• 「ある位置に向かう」プリミティブタスクで、移動速度だけを
変えたいとき、オペレータに渡す引数だけが違うほとんど同じ
プリミティブタスクを複数用意する必要がある
• ドメインのプリミティブタスク数が増えた理由がここにある
タスクに引数を渡せるシステムは必須
引数を渡せると劇的にタスク数を減らせる

HTNだけで頑張ろうとしすぎた
• 『LEFT ALIVE』の個別AI/部隊AIの意思決定の最上位から
最下層の手前までHTNで対応した
HTN
階層型
ゴール指向
（オペレータ処理層）
警戒状態
ステート
マシン
参照

ルート
イベント上書き
アクション
パニック中
パニック挙動
グレネード
被ダメ範囲内
グレネード避け
アクション
撤退すべき
撤退する
待機
戦闘ターゲット
が居る
戦闘する
罠発見かつ
非戦闘状態
罠解除
失敗リプランニング以外は
必ずここから展開をする
部隊指示
ある
部隊指示に
対応する
ほとんど、プリコンディ
ション付きメソッドで、
サブタスクが一つ

ルート
アクション
パニック中
パニック挙動
グレネード
被ダメ範囲内
グレネード避け
アクション
撤退すべき
撤退する
待機
戦闘ターゲット
が居る
戦闘する
罠発見かつ
非戦闘状態
罠解除
部隊指示
ある
部隊指示に
対応する
BTのPriorityノードと
同じ
＝デコレータ

• 『LEFT ALIVE』のドメインの上位部分は、HTNである必要が
ない構成になっている
• BTで同じものを作れる
• BTの方が動作が軽い
• 無駄なコンパウンドタスクの展開が増える
• プランニング時の処理負荷が高くなる
• 必要ないワールドステートの値が増える
• 管理する変数が増える
• プランニング時の処理負荷が高くなる

• 『LEFT ALIVE』のドメインの上位部分は、HTNである必要が
ない構成になっている
• 上位部分はやるべきタスクではなく、「願望」の選択になっている
• 願望が変われば、やるべきことはぜんぜん違う
やはり、BT or Utility＞HTN＞BTが至高

タスクの分解保留機能を入れてない
• 直ぐに実行できるプリミティブタスクが有る場合、
さっさとそれを実行して、続くコンパウンドタスクの分解を
後回しにする機能
• Game AI PRO 12.10 で紹介されている
• バンダイナムコスタジオ長谷さんもCEDEC2016の講演「環境の変化へ
の対応」の項で言及
• この機能があれば、プランの入れ替え頻度が下がる
• 後に実行するタスクを曖昧なままにできるから

タスクの分解保留機能を入れてない
• 最初の実装に問題があった
• プラナーの出力を「オペレータのリスト」にしてしまった
• プラン作成の途中の状態を持つ場所を用意していなかった
オペレータ
オペレータ
オペレータ
プリミティブ
コンパウンド
プリミティブ
プリミティブ
プリミティブ
ここまで実行したら直後の
コンパウンドをプラナーへ入れて
展開＆リストへ追加
失敗理想形

6. 失敗と教訓
7. まとめ

意思決定のまとめ
• HTNは一貫性のあるプランを立てることができる
• ただし、HTNは採用するにあたって高いハードルが有る
• 特にツールなどの環境面の整備
• HTNのドメインを書ける人が少ない&教育コスト高い
• とはいえ、使い所を間違えなければ力強いツールである
• 特にゲームデザインと噛み合えば、他のアーキテクチャでは出来ない
（もしくは困難な）AIを組むことも可能

Overcooked
• 料理を作って出すゲーム
• 左上に出てくる注文に対応する料理を、
• 食材を取り出す
• 食材を加工する（包丁で切るなど）
• 食材を調理する（煮たり炒めたり）
• 皿にもる
• 所定の提供カウンターに出す
• 皿の数は少ないので、使用済みの皿を
洗って準備する必要がある
• ときどき、火災が発生するので消化器
で消化する
https://www.playstation.com/en-us/games/overcooked-2-ps4/

HTNに向いていると思うゲームデザイン
• タスクを達成するためのサブタスクに複雑な依存関係がある
• 順番が固定のタスクならBTでも良い
• ワールドステートが離散的に表現されている
• オペレータを実行したときに明確にステートが遷移する
• プランが外乱によって壊れづらい
• プランを立てても壊されてしまう場合、長いプランを立てても意味が
ない

CEDEC2019でこぼれた
地形表現

『LEFT ALIVE』の地形表現
• CEDEC2019のセッション資料は、CEDiLにあります
• 『LEFT ALIVE』における地形表現とナビゲーションAI
• 紹介しきれなかった内容を話します
• 複数階あるビルの「階」の認識
• ある上位層ノードからどの上位層ノードを攻撃できるかリスト
• プレイヤーが立てこもっている建物の出入口の屋外の上位層ノードリ
スト（出待ち制御）

このような地形があったとして…
地面
障害物

ナビメッシュ
ウェイポイントとグラフ
カバー
上位層グラフ
このような地形表現を用意しました

ゲームデザイン的な要望
• プレイヤーがビルの三階にいるとき、スポーンした敵は走って
きてほしい
• 戦闘時に敵をいい感じにバラけさせたい
• 立てこもったプレイヤーを待ち伏せさせたい

ビルの三階にいるときは走ってきて
プレイヤー
敵兵スポーン位置

ビルの三階にいるときは走ってきて
• 課題
• あるイベントで敵兵がスポーンしてプレイヤーを捜索しながら
移動してくるが、一階にいるときと三階にいるときで、
到達時間が違いすぎる
• 三階で待ち構えているときは、もたもたしている印象が強い
• 解決案
• 同じ階までは素早く移動して、そこから警戒移動するように
「階」の認識が必要

「階」を作る
• 階は
• はしご
• 低カバー乗り越え
• 階段（＝斜面）
• 窓
• で閉じた領域

プレイヤー
斜面領域

プレイヤー
プレイヤーがいる「階」の領域

戦闘時に敵をいい感じにバラけさせたい
• 課題
• プレイヤーとの戦闘が始まったときに、
すでに近い場所に複数の敵が居て、攻撃権が割り振られない
手持ち無沙汰の兵士を適当な場所に移動させたい
• 解決案
• ある位置を攻撃できる位置を、それぞれ地形に埋め込んでおく
• プレイヤーがいる位置からリストを取り出して、
空いている適当な位置へ移動する
実装済みだけど
ゲームでは未使用

34ポイントから攻撃できる

４つの領域から
攻撃できる
本来攻撃出来ない位置だけど、
高い精度が不要なら、これで十分

プレイヤー

応用：徐々に捜索範囲を近づけたい
• 課題
• プレイヤーを捜索する部隊が、いきなりプレイヤーの付近を捜索する
のではなく、ギリギリ見えている範囲から徐々に捜索範囲をプレイ
ヤーに近づけてくる
• プレイヤーには逃げるべき認識とチャンスを与えつつ、プレッシャーを与える
• 解決策
• 射撃領域の中で一番遠いところから順番に捜索していくようにする
• 一つの捜索が済んだら、一個近いところを捜索する

プレイヤー
敵の捜索範囲

プレイヤーを待ち伏せしたい
• 課題
• プレイヤーが屋内にいるときに、むやみやたらに突入したりせず、
包囲している感じを出したい
• 出入り口の一箇所だけわざと敵を配置しないで、
プレイヤーを誘導したい
• 解決案
• ウェイポイントの接続で屋内から屋外へつながる場所の
屋外側を取り出して、屋外へ面する場所へ敵を向かわせる

屋内ポイント
屋外ポイント

プレイヤーが居る建物
プレイヤーが
居る建物から
出る所

地形認識のまとめ
• やっぱり上位層ノードは重宝します
• 精度を諦める代わりに応用の幅が広がる
• 「階」の様に意味をもたせると、
AIがより柔軟に判断できる材料が増えます
• 「部屋」の概念を入れる事ができなかったのが心残り

ご清聴
ありがとうございました

HALOはMicrosoft Corporationの商標または登録商標です。
UNREAL ENGINEはエピック・ゲームズ・インコーポレーテッドの商標または登録商標です。
CHROMEHOUNDSは株式会社フロム・ソフトウェアの商標または登録商標です。
KILLZONEはソニーインタラクティブエンタテインメントヨーロッパリミテッドの商標または登録商標です。
バンダイナムコスタジオは株式会社バンダイナムコホールディングスの商標または登録商標です。
CEDECは一般社団法人コンピュータエンターテインメント協会の商標または登録商標です。
その他掲載されている会社名、商品名は、各社の商標または登録商標です。

【GDM37】ゲームAIにおける意思決定と地形表現～『LEFT ALIVE』を事例に紹介～

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 【GDM37】ゲームAIにおける意思決定と地形表現～『LEFT ALIVE』を事例に紹介～

Similar a 【GDM37】ゲームAIにおける意思決定と地形表現～『LEFT ALIVE』を事例に紹介～ (8)

Último

Último (8)

【GDM37】ゲームAIにおける意思決定と地形表現～『LEFT ALIVE』を事例に紹介～