アンリアル エンジン 4 のビヘイビアツリーの特徴

アンリアル エンジン 4 ビヘイビアツリーと一般的なビヘイビアツリーの違い

Windows
MacOS
Linux

このセクションは、既に ビヘイビアツリー 全般をよく理解しており、できるだけ早くアンリアル エンジン 4 の実装を行いたいユーザーのためのセクションです。従って、ビヘイビアツリーをまだ使ったことのない方は、説明が複雑に感じるかもしれません。

UE4 のビヘイビアツリーと「標準」のビヘイビアツリーの実装の大きな違いは、次の 3 点です。

UE4 のビヘイビアツリーはイベント駆動型

イベント駆動型 ビヘイビアツリーの場合、フレームごとの作業量が多くならないようにします。ビヘイビアツリーは、関連性のある変更の発生を常に確認するのではなく、ツリーの変更をトリガーする「イベント」を受動的にリッスンします。

アーキテクチャをイベント駆動にすると、パフォーマンスとデバッグが確実に改善されます。ただし、これらの改善を活用するためには、 UE4 のツリーとのその他の違いを理解し、自身のビヘイビアツリーを適切に構築する必要があります。

コードはティックごとにツリー全体をイタレートする必要がないので、パフォーマンスが格段に良くなります!概念としては、「もう終わった?」と常に問いかけ続ける代わりに、「終わったよ!」と促されるまで休憩することができます。

ビヘイビアを視覚的にデバッグするためにビヘイビアツリーの実行履歴を前方と後方に進む場合、履歴には関連する変更だけが表示され、無関係の変更は表示されないのが理想です。イベント駆動型の実装の場合、ツリー上で反復される無関係のステップをフィルターで外したり、前と同じビヘイビアを選択する必要がなくなります。これは、追加のイタレーションが発生する必要が全くないためです。その代わり、ツリーの実行位置あるいはブラックボード値への変更のみが重要であり、これらの違いは簡単に表示できます。

Conditionals Are Not Leaf ノード

標準モデルのビヘイビアツリーでは、条件式は Task リーフノードなので、成功または失敗を返す以外の事は行いません。一般的な条件式のタスクは正常に実行できますが、条件式用に UE4 のデコレーターシステムを使用することを強くお勧めします。

条件式をタスクではなくデコレーターにすると、かなり有利な点が幾つかあります。

まず、条件式をデコレーターにすると、ビヘイビアツリーの UI がより直感的で見やすくなります。条件式は制御対象のサブツリーのルートのため、条件式が一致しない場合、ツリーのどこが「遮断されている」のかすぐに分かります。また、リーフはすべてアクション タスクなので、ツリーから命令されている実際のアクションが見やすくなります。 一般的なモデルの場合、条件式はリーフの中にあるので、条件式のリーフとアクションのリーフを見分けるための時間が長くかかってしまいます。

decorator.png

ビヘイビアツリーに関するこのページでは、デコレータの Close EnoughBlackboard により、 Sequence ノードの子ノードの実行を妨げることができます。

条件式をデコレーターにするもう 1 つの利点は、ツリーの非常に重要なノードでこれらのデコレーターを (イベントを待機する) オブザーバーとして機能させることが簡単な点です。ツリーのイベント駆動の性質を大いに活用するために、この機能は非常に重要です。

Concurrent Behaviors の特別な処理

標準のビヘイビアツリーは、 Parallel Composite ノードを使って同時にビヘイビアを処理することが多いです。Parallel ノードは、すべての子ツリーで同時に実行を開始します。これらの子ツリーのいずれかが終了した場合の動作については、特別なルールで定義されています (望ましいビヘイビアに応じて)。

Parallel ノードは、必ずしも (ぴったり同時にタスクを実行する) マルチスレッドである必要はありません。概念的には、複数のタスクを一度に実行する方法です。同じスレッド上で実行し、シーケンスで開始する場合も多いです。同じフレームですべて発生するのでシーケンスは関係がありませんが、重要な場合も時々あります。

UE4 では、Services を呼び出して同じ種類のビヘイビアを完了させる Simple Parallel ノードと独自の特別なノードタイプを、複雑な Parallel ノードの代わりに使用しています。

Parallel ノードを使用しない理由

  1. Parallel ノードは、かなり単純なビヘイビアであっても、非常に複雑です。

    事実上 Parallel ノードは別のサブツリー群を同時に実行しますが、これらのサブツリーのどれか、またはすべてが失敗すると、いずれか、または全部を中止するか、(成功失敗に関係なく) 他のものが完了してから継続する場合があります。Parallel ビヘイビアは単純なケースでも複雑です。利用できるオプションをつけると非常に複雑になります。

  2. Parallel ノードだとパフォーマンスの最適化、特にイベント駆動型ツリーの作成が難しくなります。

Parallel ノードの代わりに UE4 で使用されるもの

通常は Parallel ノードが持つ機能を提供するノードは 3 種類あります。

Simple Parallel ノード

Simple Parallel ノードは、 2 つしか子ノードを持つことができません。 1 つはシングルタスク ノード (オプションでデコレーター) でなければならず、もう 1 つは完全にサブツリーとなれます。

Simple Parallel ノードは、「A をしている間に B もするノード」と考えてみてください。例えば、「敵を攻撃しながら、敵に向かって前進する」ことです。基本的に、 A が主タスクになり、 B は A の完了を待ちながら実行される補助的あるいはフィラータスクです。

補助的な「ながら」タスク (Task B) の処理方法には何通りかオプションがありますが、このノードは一般的な Parallel ノードに比べて概念的には比較的単純です。単純ではありますが、 Parallel ノードが提供する一般的な使用方法のほとんどをサポートしています。

Simple Parallel ノードでは、簡単な UE 4 のイベント駆動の最適化を使用できます。Full Parallel ノードでは、最適化がぐんと複雑になります。

Services

Service は Composite ノード (Selector 、 Sequence 、 Simple Parallel) と関連づいた特別なノードで、毎 X 秒ごとにコールバックを登録し、定期的に発生する必要のある様々な更新を実行します。

例えば、ポーンは現在の敵に向かってビヘイビアツリーの中で普通に動作を続けながら、 AI ポーンにとってベストな敵を判断するために Service を使用できます。

実行が Service が関連づいている Composite ノードから開始するサブツリーにある限り、 Service はアクティブです。

Decorator "Observer Aborts" プロパティ

標準的な Parallel ノードの一般的な使用方法の 1 つは、常に状況を確認し、要求する状態が終了した場合にタスクが中断できるようにすることです。例えば、 "Shake Rear End" 、 "Pounce" などのシーケンスを実行する猫を飼っていたとしたら、もしネズミがネズミの穴に逃げたら、即座に諦めたくなると思います。Parallel ノードを使うと、ネズミに飛びかかることができるか子ノードが確認し、別の子ノードがシーケンスを実行します。イベント駆動型の UE4 のビヘイビアツリーでは、条件式デコレーターに値を「監視」させて、必要に応じて中断します。(このサンプルでは、シーケンスそのものの上に [Observer Aborts (オブザーバーを中止)] 設定が [Self (セルフ)] に設定されている Mouse Can Be Pounced On? デコレーターがあるだけです。)

UE4 式の Concurrent Behaviors 実装方法の利点

明確さ

Services と Simple Parallel ノードを使用すると、分かりやすい単純なツリーが作成されます。

デバッグのしやすさ

明確なグラフほどデバッグが簡単になります。また、「同時に」実行するパスが少ない事は、グラフで実際に起こっていることを監視しやすくなります。

最適化のしやすさ

イベント駆動型のグラフの場合、多くのサブツリーを同時に実行していなければ最適化が簡単です。

FAQ

「Parallell ノードで可能なことが、 UE4 で本当に全部できるのですか?」

  • UE4 が提供するノードと最新のインターフェースで、必要とされることはすべて可能だと信じています。確かに、上記は最も一般的なケースを処理するノードです。処理できない、あるいは理想以下となるエッジケースを見つけた場合は、それらに対して修正を行います。

「UE4 のビヘイビアツリーと標準的なビヘイビアツリーの違いは、これがすべてですか?」

  • 「標準的」という言葉を用いたのには理由があります。厳密には「標準的」なものなど存在しないので、 UE4 の実装にはユーザーの方々が慣れている実装とは違う点があります。通常とは異なる実装に慣れている場合は、別の部分で重大な相違点があるかわりに、気にすることのないレベルの相違点が多いかもしれません。自身のツリーをビルドする際に関連する最も重要な相違点のヒントをつかむために、本ページの説明が役立てれば幸いです。特殊なノードの種類の詳細については、それぞれのノードのセクションをご一読ください。

新しい Unreal Engine 4 ドキュメントサイトへようこそ!

あなたの声を私たちに伝えるフィードバックシステムを含め、様々な新機能について開発をおこなっています。まだ広く使える状態にはなっていないので、準備ができるまでは、ドキュメントフィードバックフォーラムで、このページについて、もしくは遭遇した問題について教えていただけると助かります。

新しいシステムが稼働した際にお知らせします。

フィードバックを送信