当サイトを閲覧いただきありがとうございます。
本記事では、Game Creator 2のモジュールのひとつである「Behavior」（AI制御）について詳しく解説します。
BehaviorはState Machine（FSM）／Behavior Tree／GOAP／Utility AIという4種類の業界標準AI手法を、同一Processorコンポーネント上で扱える統合AIモジュールです。
公式ドキュメント：Game Creator 2 Documentation
Behaviorとは
Processorコンポーネントに以下4種のGraphアセットのいずれかを割り当ててAIを駆動します。
- State Machine：有限状態機械。最も単純
- Behavior Tree：上→下、左→右の優先度ツリー。柔軟性と可読性
- GOAP：目的指向型計画。前提（Requisites）と効果（Effects）から自動でPlanを組む
- Utility AI：ニーズ指向。スコア最大の欲求タスクを選ぶ
導入
- Asset StoreからBehaviorモジュールを購入
Window > Package ManagerからインストールGame Creator > Install...の4サンプル：- State Machine：パトロール中の警備兵（最もシンプル）
- Behavior Tree：プレイヤーとのかくれんぼ
- GOAP：NPC同士が連携して焚き火の枝を集める
- Utility AI：ダンスクラブでダンス／飲酒／帰宅を欲求で選ぶ
- インストール先：
Assets/Plugins/GameCreator/Installs/Behavior.<手法名>/
ProcessorコンポーネントとGraph
Processor
AI実行の中心となるコンポーネントです。Character限定ではなく、任意GameObjectにアタッチ可能です。
- Graph：State Machine／Behavior Tree／Action Plan（GOAP）／Utility Boardのいずれかアセットを指定
- Loop：グラフが終了したら再実行するか
- Update：
- Every Frame（毎フレーム）
- Manual（スクリプト／Instructionで手動）
- Custom Interval（動的プロパティで秒数指定）
- Blackboardパラメータが自動で下部フィールドに展開される
Graphウィンドウの共通部品
- 上部左：フォーカス／グリッド表示切替
- 上部右：各種サブウィンドウの表示／非表示
- 下部：開いたグラフのパンくず（サブグラフを編集中に親に戻る）
ランタイムの制約
- Blackboardパラメータはランタイムで変更可能
- Graphアセット自体はPlayモード中に差し替え不可
Blackboard（パラメータ）
用途
「エージェントごとに違う値」をグラフにインターフェースするための変数空間です。巡回ルートや目標敵などに使います。
作成
GraphのBlackboardセクションに名前を入力 → Enter（または+ボタン）。型アイコンをクリックして型を選択（Game Object／Number／Booleanなど）します。
同期
パラメータを追加／編集した後は、そのグラフを使うProcessorをリフレッシュして再同期する必要があります。
パラメータの読み書き
Processor上に自動表示されるフィールドに値を設定します。各PropertyドロップダウンにBehavior/セクションが追加され、パラメータ値を参照／設定できます。
State Machine（FSM）
概念
同時に1つのStateのみActive。そのStateは連結された他Stateにのみ遷移可能です。
ノード種別
Enter（固定・1個）
初期Stateを決めるルートです。
Exit（任意）
グラフを「終了」扱いにします。サブグラフ化したときに「外側へ戻る」意味を持ちます。
State（メイン）
- Name：識別用（実行に影響なし）
- Conditions：このStateに入るときの条件（失敗なら遷移失敗）
- Check：
- Every Cycle：
On Update完了後に遷移チェック（推奨） - Every Frame：毎フレーム遷移チェック（軽いコスト増）
- Every Cycle：
- On Enter：遷移してきた瞬間
- On Exit：遷移で出ていく瞬間
- On Update：実行中繰返し実行される命令列（完走後もStateが継続なら再スタート）
初期化はOn Enter、後処理はOn Exitに置きます。On Updateは途中中断されうるため必ず完了する保証はありません。
Conditions（中継ノード）
複数Stateが同じ条件で同じ出口に集約するとき、条件を1箇所にまとめる用です。
Sub Graph
任意のGraph（State Machine以外でも可）をState扱いで実行します。
Elbows（整形用）
接続線の折れ曲がりノードです。機能はなく可読性のためだけです。
遷移の評価順
Stateノードを選ぶとInspectorにtransitionsの並び順が表示されます。上から順にConditionsを試し、最初に成功したものに遷移します。全部失敗なら現State継続です。
Behavior Tree
概念
Entryノードを根とする木構造です。上→下、左→右で評価されます。戻り値は3種：
- Success：成功
- Failure：失敗（エラーではなく「このパスは駄目」の意味）
- Running：実行中
Ready状態（未実行）もあります。ツリー全体がSuccess/Failureで終わるまで、すでにSuccessしたノードは再実行されません（状態が引き継がれる）。
ノード種別
Task（葉）
- Conditions：評価ごとに実行。Instructions実行中にfalseになればFailure
- Instructions実行中：Running、完了時：Success
Composite（分岐）
- Selector：左から順に実行、Successが出たら自分もSuccess（OR）。全部FailureならFailure
- Sequence：左から順に実行、Failureが出たら自分もFailure（AND）。全部SuccessならSuccess
- Parallel：全子を同時実行。成否判定は「All Successful」「Any Successful」等の選択可
- Random Sequence：Sequenceと同じだが、評価前に順序をランダム化
- Random Selector：Selectorと同じだが、評価前に順序をランダム化
Decorator（修飾）
子の結果を変換する中継ノードです：
- Fail：常にFailure
- Success：常にSuccess
- Running：常にRunning
- Invert：Failure ↔ Success反転、Runningは維持
- Repeat：指定回数まで子を実行（その間Running、最後に子の結果）
- While Fail：子がRunningまたはFailureの間Running、それ以外Failure
- While Success：子がRunningまたはSuccessの間Running、それ以外Failure
Sub Graph
別のBehavior Tree／State Machine／GOAPを実行するTaskライクなノードです。
子の並び順
Compositeの子ノード頭上に数字（1, 2, …）が出ます。左→右で自動計算されるので、ドラッグで並べ替えて優先順位を決めます。
GOAP（Goal Oriented Action Planning）
概念
エージェントは「Beliefs」（現在の世界観）を持ち、「Goal」（望むBelief集合）へ至る「Plan」（ノード列）をAIが自動構築します。
- Plan：実行順序付きのノード列
- Beliefs：現在のBelief集合（boolの集合）
- Requisites：ノード実行の前提（ON必須Belief）
- Effects：ノード実行後に書き換わるBelief
- Cost：ノードの実行コスト。Planの総Costが最小のものが採用される
例：be-in-hotel をGoalに設定、Node A（Requisite: be-in-restaurant → Effect: be-in-hotel）とNode B（Effect: be-in-restaurant）があれば、Planは B → A になります。
Thoughts（初期Belief）
Action PlanアセットのAdd Thoughtで、Plan計算開始時の初期Beliefを設定可能です。Visual ScriptingのConditionと紐付けてブール値を供給できます（例：プレイヤーが見えるか）。
ノード種別
Task
- Name：識別用
- Cost：計画選択の重み（値が小さいほど好まれる）
- Conditions：実行時に評価される実行可否（Beliefsとは別物）
- On Execute：Instructions。実行後、ノード完了とみなす
重要：ConditionsはPlan構築時には使われません。実行時にだけfalseで中断させる役目です。Planの前提にしたい値は**Beliefs（Requisites）**に入れます。
Sub Graph
Task相当ですが、別AI系グラフ（State Machine／Behavior Tree等）を実行します。
RequisitesとEffectsノード
Task／Sub Graphの左側にRequisites、右側にEffectsを繋ぎます。BeliefごとにTrue/Falseを指定します。
- Falseを置くことは「Beliefが存在しない」を意味する（既定値）
Goalの管理（ランタイム）
Add GoalInstructionでGoalを追加：Processor／Action Plan／Name（Belief名）／WeightRemove GoalInstructionで解除- 同時に複数Goalを持てる
- 各GoalのPlan総CostにWeightを乗算して最小のものを選ぶ
Weightによる優先化の例
- Stay-Alive（Cost 5）／Kill-Enemies（Cost 3）
- そのままだとKillが選ばれてしまう
- Stay-AliveのWeight=0.5にすれば総Cost=2.5となりStay-Aliveが優先
実行フロー
- 各Goalに対してPlanを1つ（最小Costのもの）構築
- すべてのPlanにWeightを掛けて比較
- 総Cost最小を選んで実行開始
- Conditionでabortされない限り最後まで実行
- Plan実行中は新Planは計算されない
Utility AI（Needs-Based AI）
概念
「欲求（Need）」ごとにScoreとCurveを持ち、毎回もっともScoreが高いNeedを選んで実行する方式です。The Sims系に向いています。
Utility Board
- 全ノードが「接続なしで並ぶ」グラフ
- 毎回全ノードのValueを取得 → Curveを適用 → 最大のNeedを実行
ノード種別
Task
- Name：識別用
- Score：Value（動的プロパティで供給）＋ Curve
- Conditions：実行可能かの判定。満たさなければ候補から除外
- On Execute：実行開始時
- On Exit：終了時（中断されても必ず呼ばれる。状態リセット用）
Sub Graph
Task同様ですが、別AIグラフへ委譲します。
Curve（需要曲線）
Valueの扱いをカスタマイズする関数です。代表4パターン：
- Linear：値そのまま
- Inverse Linear：反転（値が大きいほどScoreは小さい）
- Smooth Easing：徐々に急上昇
- Belly / Bell：中央が高く両端が低い（暇つぶし行動などに）
Valueの範囲
デフォルトは0〜1です。Utility BoardアセットのMinimum／Maximumで拡張可能です。Curveは常に0〜1で定義され、最終的にMin〜Maxにリマップされます。
選択と実行
- 全ノードのScoreを計算し、最大を実行
- 実行中のノードが完了するまで再選択しない。詰まらないよう、必要ならOn Execute内で早期終了するロジックを入れる
- Playモード中はノードに計算結果が表示されてデバッグできる
手法の選び方
| 手法 | 向いている用途 | 複雑度 |
|---|---|---|
| State Machine | 敵の2〜4状態程度の切替（パトロール→追跡→帰還） | 低 |
| Behavior Tree | 条件が多く優先度が明確なAI（ステルスゲームの敵） | 中 |
| GOAP | 協調・目標駆動（F.E.A.R.系、サバイバルシム） | 高 |
| Utility AI | シミュ系（Sims、生活RPG）／感情値駆動 | 中 |
Behavior Tree × Utility AIのようにハイブリッド構成も可能です（各Utility NeedをBehavior Treeのサブグラフに委譲）。GOAPのTaskもBehavior Tree等へ委譲できます。
Visual Scriptingリファレンス
Instructions（3）
Behavior（1）
| 命令 | 機能 | 主なパラメータ |
|---|---|---|
| Processor Update | Processorに1回分のイテレーションを手動実行させる | Processor |
Behavior > Action Plan（2）
| 命令 | 機能 | 主なパラメータ |
|---|---|---|
| Add Goal | GOAPのAction PlanにGoalを追加 | Processor／Action Plan／Name／Weight |
| Remove Goal | Goalを削除 | Processor／Action Plan／Name／Weight |
Conditions（1）
| 条件 | 判定 | 主なパラメータ |
|---|---|---|
| Is Processor Running | Processorが実行中か | Processor |
Events（2）
| イベント | 発火タイミング |
|---|---|
| On Processor Start | Processorが実行開始したとき |
| On Processor Finish | Processorが現在の実行を終えたとき |
Behaviorは主にグラフ内で完結する設計のため、コアのVisual Scriptingノード群と比べるとInstruction／Condition／Eventの数は少なめです。グラフ内のTask／StateノードにInstructionsを書くのが中心的な使い方になります。
Tipsと注意点
- 初期化はOn Enter／片付けはOn Exitが鉄則。On Updateは中断されうる
- StateのEvery Frameは重たい：本当に即応答が要るところだけ。多くはEvery Cycleで十分
- Behavior Treeのノード状態は引き継ぎ：Successしたノードは再評価しない。ループしたい場合はRepeatデコレータやRunning保持を活用
- GOAPのConditionsとBeliefsの違い：計画構築に関与するのはBeliefs（Requisites/Effects）、実行時の中断用がConditions。混同しない
- Thoughtsで初期値を与えておく：Plan計算の前提になる。Beliefが欠けているとPlanが組めない
- Utility AIは完了まで再選択しない：無限ループや長すぎるTaskは避け、Curveで切り替わる粒度に保つ
- Graphはランタイムで差替え不可：必要ならサブグラフで切替え設計
- Blackboard変更後はリフレッシュ：Processor側の表示が古いまま動作することがある
- Perceptionとの相性が抜群：Sight／HearingのAwarenessをConditionやBeliefに差し込むパターンが標準
- Breakpoint／Disabled表示（2.1.5以降）：ノード内の命令・条件にブレークポイントや無効化の視覚表示が出る
実践的な使い方 ― やりたいこと別の構成ガイド
「こういうAI挙動を実現したい」場合にどの手法・構成を使うか、パターン別にまとめます。
巡回→プレイヤー発見→追跡の基本AI（State Machine）
警備兵がエリアを巡回し、プレイヤーを視認したら追跡する。見失ったら巡回に戻るパターンです。
| 使うもの | 設定 |
|---|---|
| Graphタイプ | State Machine |
| State 1 | Patrol（On Updateで巡回ルートに沿って移動） |
| State 2 | Track Player（On Updateでプレイヤーに向かって移動） |
| 遷移条件 | Patrol → Track：「プレイヤーが視界内」（Perception連携） |
| 遷移条件 | Track → Patrol：「プレイヤーを見失った」 |
各エージェントに個別の巡回ルートを与える（Blackboard）
同じAIグラフを複数の警備兵で共有しつつ、巡回ルートだけ個別に設定するパターンです。
| 使うもの | 設定 |
|---|---|
| Blackboard | patrol-route（Game Object型）を定義 |
| Processor | 各NPCのProcessorコンポーネントに自分用の巡回ルートGameObjectをドラッグ＆ドロップ |
複数条件を優先度付きで評価するAI（Behavior Tree）
「攻撃可能か？」→「追跡可能か？」→「巡回する」のように左から右への優先度で行動を選択するパターンです。
| 使うもの | 設定 |
|---|---|
| Graphタイプ | Behavior Tree |
| ルート | Entry → Selector Composite |
| 子ノード（左＝最高優先度） | Task「攻撃」（Condition: 敵が近い） |
| 子ノード（中） | Task「追跡」（Condition: 敵が見える） |
| 子ノード（右＝最低優先度） | Task「巡回」（Conditionなし＝フォールバック） |
左ほど優先度が高く、条件を満たす最初のTaskが実行されます。
「全部成功しなければ失敗」の連続行動（Sequence）
「敵に近づく → 攻撃する → 離脱する」を順番に実行し、どこかで失敗したら全体を失敗にするパターンです。
| 使うもの | 設定 |
|---|---|
| Compositeタイプ | Sequence |
| 子ノード | Task群を左から右に並べる |
自動で計画を組み立てるAI（GOAP）
NPCが「焚き火を作る」という目標のために、必要な行動（枝を集める→火種を見つける→点火する）を自動で計画するパターンです。
| 使うもの | 設定 |
|---|---|
| Graphタイプ | Action Plan（GOAP） |
| Beliefs（初期知識） | has-wood = false、has-fire = false |
| Goal（目標） | Requisite: has-fire = true |
| Action 1（枝を集める） | Requisite: なし、Effect: has-wood = true |
| Action 2（点火する） | Requisite: has-wood = true、Effect: has-fire = true |
欲求ベースの自律NPC（Utility AI）
NPCが「空腹度」「疲労度」「社交欲」などのスコアに応じて、最もスコアの高い行動を自動選択するパターンです。
| 使うもの | 設定 |
|---|---|
| Graphタイプ | Utility Board |
| Need 1（食事） | Score Curveでパラメータ hunger が高いほどスコア上昇 |
| Need 2（睡眠） | Score Curveでパラメータ fatigue が高いほどスコア上昇 |
| Need 3（会話） | Score Curveでパラメータ social が高いほどスコア上昇 |
最大スコアのNeedが選択され、完了まで再選択はされません。
State Machineの中にBehavior Treeを埋め込む（サブグラフ）
大まかな状態遷移はFSMで管理し、各状態の中身は複雑なのでBTで実装するパターンです。
| 使うもの | 設定 |
|---|---|
| メインGraph | State Machine |
| Stateノード内 | Sub Graphノードを使い、Behavior Treeアセットを指定 |
逆にBTのタスクとしてState MachineやGOAPを呼ぶことも可能です。
AIの更新頻度を下げてパフォーマンスを改善する
多数のNPCがいるシーンでAI処理を軽くするパターンです。
| 使うもの | 設定 |
|---|---|
| ProcessorのUpdate | Custom Interval（例：0.5秒ごと）またはManual |
| State MachineのCheck | Every Cycle（毎フレームではなく周期ごと） |
Manualの場合は Processor Update 命令で任意タイミングに実行します。
関連する他モジュール
- Characters：Player／NPCを対象に制御
- Perception：視覚・聴覚・嗅覚のAwarenessを条件／Beliefに取り込む
- Stats：HPなどを見た判断（
Compare AttributeをStateのConditionsに） - Quests：特定Task達成でAIグラフをActivate／Goal追加
- Visual Scripting：各ノードのInstructionsはコアのVisual Scripting全Instructionを利用可
公式リンク
- Game Creator 2 公式ドキュメント
- Game Creator 2 — Unity Asset Store
- Behavior 2 | Game Creator 2 — Unity Asset Store
まとめ
本記事では、Game Creator 2の「Behavior」モジュールについて解説しました。
4種のAI手法（State Machine・Behavior Tree・GOAP・Utility AI）を同一フレームワークで利用でき、Sub Graphによるハイブリッド構成も可能です。ProcessorとBlackboardの仕組みにより、1つのAIグラフを複数エージェントで共有しつつ個別パラメータを差し込む運用が容易に行えます。
Visual ScriptingではInstruction 3種・Condition 1種・Event 2種が用意されていますが、主要なロジックはグラフ内のノードに直接書く設計です。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：Game Creator 2 完全ガイド（12/16）
