幻塔戦記グリフォンでのBehaviour Treeの試み

2014.01.29

Sindharta Tanuwijaya

(シンダルタ　タヌイジャヤ )

Behaviour Tree とは• AI のアルゴリズムの１つ– State Machine と目的が似ています

• 目的：ゲーム内のオブジェクトが考えて行動するようにする

• NPC 対戦チュートリアルに使ってみた

State Machineステート・マシン

State Machine の振り返り 1/2

• オブジェクトの行動を下記のもので表現する– State– State の遷移 (Event) で表現する

S0E1

S2S1 S3

E2

E3 E4

E5

S: StateE: Event

State Machine の振り返り 2/2

• 例：爆弾

周囲を探知 爆発

距離 < x消える

アニメーションが終われば

時間 < y

NPC 対戦チュートリアルにState Machine を使える？

NPC 対戦チュートリアルにState Machine を使える？　

• NPC 対戦の仕様：1. クリープ (NPC) が前進したときは慎重についていく2. ＡＩは保守的。あまり深く敵を追わない3. タワーを護衛する4. 敵が近ければ、攻撃する。優先度は：

• プレイヤー• クリープ (NPC)

5. HP が減れば、基地に戻る6. 場所に引っかかる場合の対応

• State の数：少なくとも６• 遷移の数：正確には不明だが、多い• 最初一部を State Machine で実装しが、 State Machine の欠点

をよく考えさせられた

State Machine の欠点　 1/2

• State の数が少なければ問題ないが、 Stateの数が増えれば、管理しないといけない遷移は膨大に増える。大雑把に：

?S: 3E: 3

S: 4E: 6

S: 5E: 10

S: 6E: 15

S: 7E: 21

State Machine の欠点　 2/2

• State とその遷移が１つのＡＩの構造になっているので、再利用性が低い– 例：攻撃する行動は別のＡＩで実行されてい

ましたが、簡単に使いまわすことができない

S0E1

S2S1

E2

E3

S0Ex

SySx

Ey

Ez

S: StateE: Event

State Machine の問題のまとめ• 問題点：

1. State の数が増えれば、管理しないといけない遷移は膨大に増える• バグが出やすい• デバッグは難しい

2. 再利用性が低い• 違うやり方で、 NPC 対戦のチュートリア

ルをやろうと考えた– Behaviour Tree

Behaviour Tree

Behaviour Tree: 入門• 構造： Tree• Tree のノードはステータスを持ってい

る：– READY: 初期値– SUCCESS: ノードの実行が成功した– FAILURE: ノードの実行が失敗した– RUNNING ：ノードの実行がまだ終わってい

ない• 代表的な Behaviour Tree のノードの種類：

– Action 　ノード– Selector ノード– Sequence ノード– Decorator 　ノード

Action ノード• 一番シンプル：実行するのみ• Tree の Leaf だけ。子は持てない• 例：一番近い敵への攻撃

A

Decorator ノード• ある条件のチェックを行う：

– 通ったら子を実行して、子が返すステータスを返す– 通らなかったら、 Failure を返す

• 子は１つだけ。• 例： HP<10 であれば、一番近い敵を攻撃する

– Ｄ： HP<10– Ａ：一番近い敵を攻撃する

A

D

Selector ノード• 成功する子が見つかるまで、子を１つ１つ実行する。

– 見つかったら、処理を止めて、 Success を返す。– 見つからなかったら、 Failure を返す

• 例：– 一番近い敵を攻撃する– 敵がいなかったら、クリープを付いていく– クリープがいなかったら、待機する

A

Sel

A A

Sequence ノード• 順番に子を実行するノード

– 子が成功したら、すぐ Running を返す。次のフレームの Update で次の子を実行する

– 子が失敗したら、すぐ Failure を返す– すべてのノードを実行し終わったら、 Success を返す

• 例：ある位置に移動して、着いたらしばらく待機する

A

Seq

A

Running

A

Seq

A

フレーム１ フレーム 2

A A

Ready

Tree の Update のルール• 毎フレームではなくてもよいが、定期的に

Update• RUNNING じゃないノードのステータスを

READY にしてから、 Root から Update する– 再帰的

例

Behaviour Tree の例• HP が 10 より大き

ければ、一番近い敵を攻撃する。最大距離：５ m

• 敵が見つからなかったら、一番前のタワーに移動して、待機する

5m 以内の敵を攻撃

Sel

一番前のタ

ワーに行く

待機

HP>10

Seq

Ready

HP 最大で、敵も近くにいる場合

5m 以内の敵を攻撃

Sel

一番前のタ

ワーに行く

待機

HP>10

Seq

5m 以内の敵を攻撃

Sel

一番前のタ

ワーに行く

待機

HP>10

Seq

Ready

RunningSuccess

Failure

HP 最大で、敵も近くにいない場合

5m 以内の敵を攻撃

Sel

一番前のタ

ワーに行く

待機

HP>10

Seq

5m 以内の敵を攻撃

Sel

一番前のタ

ワーに行く

待機

HP>10

Seq

Ready

RunningSuccess

Failure

まだタワーついていなかったら、そのまま行く

5m 以内の敵を攻撃

Sel

一番前のタ

ワーに行く

待機

HP>10

Seq

Ready

RunningSuccess

Failure

タワーについたら、待機

5m 以内の敵を攻撃

Sel

一番前のタ

ワーに行く

待機

HP>10

Seq

Ready

RunningSuccess

Failure

全体の流れ• Update のルール– 毎フレームではなくてもよいが、定期的

Update – RUNNING じゃないノードのステータスを

READY にしてから、 Root から Update する• 再帰的

• ずっと繰り返す

NPC 対戦チュートリアルのBehaviour Tree 1/2

• NPC 対戦の仕様：1. クリープ (NPC) が前進したときは慎重につい

ていく2. ＡＩは保守的。あまり深く敵を追わない3. タワーを護衛する4. 敵が近ければ、攻撃する。優先度は：

• プレイヤー• クリープ (NPC)

5. HP が減れば、基地に戻る6. 場所に引っかかる場合の対応

NPC 対戦チュートリアルのBehaviour Tree 2/2

Sel

基地へ行く 回復

HP>10 Seq

タワーからの距離 <5

引っかかる場合の

対応

Sel

Seq

Sel

プレイヤーを攻

撃

クリープを攻撃

クリープを付いて

いく

プレイヤーを攻

撃クリープ

を攻撃タワーを

護衛

タワーへ行く

Sel

Behaviour Tree を可視化するツールも

作ってみました

ツール• 可視化するツールがないと、デバッグが難しい• Unity Editor 上で動く• 選択されているオブジェクトが特別なコンポネ

ントを持っているかどうかを探知して、自動的に表示・非表示する

• 形： Tree• 色：ステータスを表現• デバッグ情報も表示• リアルタイム

キャプチャした動画

Behaviour Treeメリット・デメリット

メリット• Behaviour Tree のルールによって、ＡＩが複雑になっていても管理しやすい

• 全体的に可視化できる– デバッグは比較的に楽

• ノードがモジュラー– 再利用性は高い–同じノードを使いまわして、違うＡＩを作る

ことが楽。例：アグレッシブなＡＩ

欠点• すべてのノードに訪れる可能性があるので、

State Machine より CPU の負担がかかる可能性がある

• すべての行動がノードで表現されているので、簡単な行動を作りたくても、ノードを作る必要がある– 例： NPC の向きを固定にする

欠点の対応• CPU の負担：– Behaviour Tree の Update を毎フレーム実行し

ない• ノードを必ず作る：– State Machine と Behaviour Tree の組み合わせ

S0 E1

S1

E2

E3A

Sel

A A

まとめ

まとめ• 作りたいＡＩが複雑であれば、 Behaviour Tree を使ったほうがよい。– 最初的には Behaviour Tree のフレームワークを開発するコスト

が発生しますが、長期的に見ると開発コストが下がるし、生産性もあがる• フレームワークの開発は１回だけで、使いまわすことができる。• デバッグが楽• 再利用性

– 複雑の定義：ステートの数がおよそ４つ以上。ボス戦に向いている

• ＡＩが複雑でなければ、 State Machine でもよい– 再利用性を高めたければ、 State Machine と Behaviour Tree の組み合わせを作ることもできる

おまけ• Tree の構造を表示するのは意外と少々難しかった

– Y座標は簡単– X座標は少々難しい

• ある行動を１つのノードにするか、何かに組み合わせで、同じ行動を表現するかを少々悩んだことがある。例：プレイヤーとタワーを攻撃する1. 同じ Action ノードにする2. 別々にする

• Behaviour Tree の作成はコードで手で書いた。それを作る・編集ツールがあれば、さらに生産性があがる。– ランタイムで編集して、その編集をすぐ反映できる

以上ご清聴ありがとうございます。