UE5で敵AIを作っていると、
「動いているのに、なんかショボい」
と感じることがあります。
追いかけてくる。
攻撃もする。
待つこともできる。
回避っぽい動きもある。
それなのに、実際にゲームに入れてみると、
- 急に止まる
- 急に攻撃する
- 追ってきたのに棒立ちになる
- 攻撃後の動きが不自然
- Idle / Move / Attack / Wait がブツ切りに見える
- 行動を増やしているのに自然にならない
ということがあります。
このとき、最初に考えがちなのは、
「動きが足りないのかな？」
ということです。
もっと攻撃パターンを増やす。
もっと移動パターンを増やす。
もっと回避や待機を増やす。
もちろん、行動の種類を増やすこと自体は大事です。
ただ、敵AIがショボく見える原因は、単純に「動きが足りない」ことだけではありません。
むしろ、行動自体はあるのにショボく見えることがあります。
この記事では、UE5で敵AIを作るときに起きがちな、
「動いているのにショボい」
「行動を増やしても自然にならない」
「Behavior TreeやBlueprintが複雑になる」
という問題を、行動の意図と方針という視点から整理します。
※この記事の内容は、動画でも実機映像とBehavior Treeを使って解説しています。
敵AIがショボく見える原因は「動き不足」とは限らない
敵AIがショボく見えるとき、まず疑いたくなるのは行動の少なさです。
例えば、
- 攻撃が少ない
- 移動が単調
- 回避しない
- 待ち方が不自然
- 距離調整が弱い
こういった問題です。
もちろん、これらも敵AIを自然に見せるうえでは重要です。
ただし、それ以前に大事なことがあります。
それは、AIが今、何のためにその行動をしているのかです。
敵AIがショボく見える大きな原因は、行動の意図があいまいなことです。
つまり、
- なぜ移動したのか
- なぜ攻撃したのか
- なぜ待ったのか
- なぜ止まったのか
- なぜ距離を取ったのか
がつながって見えない。
この状態だと、行動自体は入っていても、動きがブツ切りに見えます。
行動名だけで考えると最初は分かりやすい
敵AIを作るとき、最初は行動名で整理することが多いと思います。
例えば、次のような形です。
- Idle
- Move
- Attack
- Wait
- Dodge
- Backstep
- Sprint
これは最初はとても分かりやすいです。
「待つ」
「移動する」
「攻撃する」
「回避する」
「走る」
というように、敵AIが何をするかを行動ごとに分けられるからです。
UE5のBehavior TreeやBlueprintでも、最初はこのような行動単位で考えると理解しやすいです。
まず動かすだけなら、この考え方でも十分です。
しかし、実際にゲームっぽくしようとすると、だんだん苦しくなってきます。
なぜなら、同じ行動名でも、その行動が持つ意味は1つではないからです。
同じMoveでも意味が違う
例えば、Move という行動があります。
一見すると、移動は移動です。
しかし、敵AIの意図として見ると、同じMoveでも意味は大きく変わります。
| 行動 | 意図 |
|---|---|
| Move | 距離を詰めたい |
| Move | 逃げたい |
| Move | 攻撃範囲に入りたい |
| Move | 横に回り込みたい |
| Move | 様子を見たい |
| Move | 距離をリセットしたい |
見た目としては、どれも「移動」です。
しかし、AIがやろうとしていることはまったく違います。
距離を詰めるためのMove。
逃げるためのMove。
攻撃範囲に入るためのMove。
様子を見るためのMove。
立て直すためのMove。
これらを全部 Move の中に押し込むと、後から条件分岐が増えていきます。
「これは攻めるためのMoveなのか」
「これは逃げるためのMoveなのか」
「これは距離調整のMoveなのか」
を、Moveの中で判定し続けることになります。
その結果、処理が複雑になります。
同じAttackでも意味が違う
Attack も同じです。
攻撃という行動は1つに見えます。
しかし、実際には攻撃にも複数の意味があります。
| 行動 | 意図 |
|---|---|
| Attack | ダメージを取りたい |
| Attack | 近づかせたくない |
| Attack | 回避させたい |
| Attack | 硬直を狩りたい |
| Attack | 主導権を取りたい |
| Attack | 距離を離すために振りたい |
同じAttackでも、
- ダメージを取るための攻撃
- 相手を近づかせないための攻撃
- 回避させるための攻撃
- 硬直を狩るための攻撃
- 主導権を取るための攻撃
では意味が違います。
ここを全部 Attack の中に入れると、攻撃処理の中に意図が混ざります。
その結果、あとから見たときに、
「なぜ今この攻撃をしたのか」
が分かりにくくなります。
行動の意味が混ざると、BTやBPが複雑になる
行動名だけでAIを作ると、最初は分かりやすいです。
しかし、ゲームっぽくしようとすると、次のような問題が出てきます。
- Moveの中に複数の意図が混ざる
- Attackの中に複数の意図が混ざる
- Waitの意味も増えていく
- 条件分岐が増える
- Behavior Treeが読みにくくなる
- Blueprintの処理が複雑になる
- 変な動きになったときに原因を追いにくい
例えば敵が急に止まったとします。
そのとき、
- 待っているのか
- 次の攻撃を選べていないのか
- 距離を見ているのか
- 見失ったのか
- 条件が噛み合っていないのか
- そもそも攻めるべき状態ではなかったのか
が分かりにくくなります。
つまり、敵AIがショボく見える理由は、単純に行動数が少ないからではありません。
行動の意味が整理されていないまま行動を増やすことで、処理も動きも不自然になりやすくなります。
行動ではなく「方針」でAIを見る
そこで重要になるのが、行動そのものではなく、行動の方針で整理することです。
僕のゲームでは、敵AIの方針をざっくり3つに分けています。
| 方針 | 目的 |
|---|---|
| BUILD | 中距離で攻撃を積む |
| PRESS | 近距離で大ダメージを狙う |
| RECOVER | 距離を取って立て直す |
日本語で言うと、
- 積む
- 詰める
- 立て直す
です。
それぞれの意味は次のようになります。
BUILD：中距離で攻撃を積む
BUILDは、中距離で攻撃を積み上げる状態です。
いきなり大きな攻撃を狙うのではなく、一定距離を維持しながら小さい攻撃を当てていく。
プレイヤーにプレッシャーをかけたり、Breakや有利状況を狙ったりするための方針です。
PRESS：近距離で大ダメージを狙う
PRESSは、チャンスができたときに距離を詰めて、大ダメージを狙う状態です。
例えば、プレイヤーにプレッシャーが溜まってきたときや、攻めるチャンスがあるときに、近距離へ入って近接攻撃を狙います。
RECOVER：距離を取って立て直す
RECOVERは、不利な状況から立て直すための状態です。
敵AI側の危険度が高まったときや、一度距離を取りたいときに、プレイヤーから離れて状況を整えます。
大事なのは「何をするか」より「何のためにするか」
ここで大事なのは、AIを行動名だけで分けないことです。
Moveするかどうか。
Attackするかどうか。
Waitするかどうか。
それだけではなく、
「何のためにMoveするのか」
「何のためにAttackするのか」
「何のためにWaitするのか」
を先に分けます。
同じMoveでも、
| 方針 | Moveの意味 |
|---|---|
| BUILD | 中距離を維持する |
| PRESS | 近距離に詰める |
| RECOVER | 距離を取る |
になります。
同じAttackでも、
| 方針 | Attackの意味 |
|---|---|
| BUILD | 小さい攻撃を積む |
| PRESS | 大ダメージを狙う |
| RECOVER | 近づかせないために振る |
になります。
つまり、行動そのものではなく、その行動がどの方針の中で使われているかを見る。
これによって、行動の意味がつながりやすくなります。
行動ベースと方針ベースの違い
AIの作り方を大きく分けると、行動ベースと方針ベースがあります。
行動ベース
行動ベースでは、AIを具体的な行動で分けます。
例えば、
- 攻撃
- 追跡開始
- 追跡終了
- 索敵
のような形です。
これは分かりやすいです。
今、攻撃している。
今、追跡している。
今、索敵している。
実行している処理が見えやすいからです。
ただし、敵が変な動きをしたときに、
「なぜその行動を選んだのか」
を追いにくくなります。
例えば、攻撃しなかった場合、
- 攻撃条件が悪いのか
- 追跡終了の判定が悪いのか
- 索敵状態に戻ってしまったのか
- そもそも攻めるべき状態ではなかったのか
が見えにくくなります。
方針ベース
一方で、方針ベースでは、AIが今何を達成したいのかで分けます。
例えば、
- BUILD：積む
- PRESS：詰める
- RECOVER：立て直す
です。
この分け方にすると、敵が変な動きをしたときに、まず現在の方針を見られます。
- 今はBUILDなのか
- PRESSに入るべきだったのか
- RECOVERに入っているのか
- 方針の切り替えが遅いのか
- 方針は正しいが、Taskの動きが悪いのか
という見方ができます。
方針ベースBTは魔法ではない
ここで注意したいのは、方針ベースにしたからといって、敵AIが一気に自然になるわけではないことです。
これは魔法ではありません。
方針ベースのBehavior Treeにした瞬間、AIが急に賢くなるわけではありません。
実際、作り途中の段階では、見た目だけ見ても、
「行動ベースより方針ベースの方が圧倒的に自然」
とは分かりにくいこともあります。
ただし、作っている側にとって大きな違いがあります。
それは、なぜその行動になったのかを追いやすくなることです。
敵が止まったときに、
- なぜ止まったのか
- 今の方針は何だったのか
- PRESSに入るべきだったのか
- RECOVERに入った理由は何か
- Serviceの切り替え条件が悪いのか
- Taskの移動処理が弱いのか
を分けて見られるようになります。
つまり、方針ベースBTの価値は、敵AIを一発で自然にすることではありません。
あとから直せるAIにすることです。
UE5ではService / Blackboard / Taskで整理する
UE5のBehavior Treeで整理する場合、僕は大きく次の3つで見ています。
| 要素 | 役割 |
|---|---|
| Service | 方針を切り替える |
| Blackboard | 現在の方針を保持する |
| Task | 方針に応じた行動を実行する |
Service：方針を切り替える
Serviceでは、キャラクターの状態や距離、状況に応じて、現在の方針を切り替えます。
例えば、
- 攻めるチャンスがあるならPRESS
- 中距離で攻撃を積むならBUILD
- 不利ならRECOVER
という判断です。
Blackboard：現在の方針を保持する
Blackboardには、現在の方針を保持します。
今このAIが、
- BUILDなのか
- PRESSなのか
- RECOVERなのか
を持たせます。
Task：方針に応じた行動を実行する
Taskでは、その方針に応じた具体的な行動を実行します。
つまり、いきなり行動を切り替えるのではなく、
- Serviceで方針を切り替える
- Blackboardに現在の方針を保持する
- Taskで方針に応じた行動を実行する
という流れです。
BTの追い方が変わる
この構造にしておくと、Behavior Treeの追い方が変わります。
例えば、
「チャンス時の詰め方がショボい」
という問題があったとします。
具体的には、
- 詰め始めが遅い
- チャンスを逃す
- 近接攻撃が当たらない
という状態です。
このとき、方針で整理しておくと、原因の仮説を立てやすくなります。
詰め始めが遅い場合
本当はPRESSに入るべきタイミングなのに、まだBUILDのままになっているかもしれません。
この場合、疑うべきなのはServiceでの状態切り替えです。
PRESSには入っているのに近づけない場合
方針としてはPRESSに入っている。
しかし、近づき方が弱い。
この場合、疑うべきなのは詰める際の移動Taskです。
近接攻撃が当たらない場合
PRESSに入り、近距離まで移動している。
それでも近接攻撃が当たらない。
この場合は、移動Taskの踏み込みや、攻撃範囲、攻撃タイミングを疑えます。
このように、
- 方針の切り替えが悪いのか
- 方針の中の行動が悪いのか
- 具体的な移動や攻撃の調整が悪いのか
を分けて見られるようになります。
これが、方針ベースで整理する一番大きな価値です。
自然な敵AIは「行動数」ではなく「意味のつながり」で作る
敵AIがショボく見える原因は、動きが足りないことだけではありません。
Idle、Move、Attack、Waitのような行動を増やしても、その行動が何のためのものなのかがあいまいだと、動きはブツ切りに見えます。
同じMoveでも、
- 距離を詰めたいMove
- 逃げたいMove
- 立て直したいMove
では意味が違います。
同じAttackでも、
- ダメージを取りたいAttack
- 近づかせたくないAttack
- 主導権を取りたいAttack
では意味が違います。
だから、敵AIを作るときは、行動を増やす前に、AIが今何を達成したいのかを分ける。
行動ではなく、方針で見る。
これが大事です。
ただし、方針ベースにしたからといって、敵AIが一気に自然になるわけではありません。
大事なのは、敵AIが変な動きをしたときに、
「なぜその行動になったのか」
を追える形にしておくことです。
自然な敵AIは、行動数だけではなく、行動の意味とつながりで作る。
敵AIを作っていて、
「動いているのにショボい」
「行動を増やしても自然にならない」
「Behavior Treeが複雑になって追いにくい」
と感じたら、まずはその行動が何のための行動なのかを整理してみるとよいと思います。
動画でも解説しています
この記事の内容は、動画でも実機映像とBehavior Treeを使って解説しています。
実際の動きやBTの見方を確認したい方は、こちらも参考にしてください。
コメント