Arbor

迅速なご返信ありがとうございます。

なるほど！　確かにプログラム自体容量が重くはございませんし、最初に読み込んで実行するものですね。納得致しました。
また、FSMにおいても特別独自で処理を行う仕様は無いとの事で安心致しました。

ご見解と細かな情報メモもありがとうございます。
やはり組んだものが一目でわかる視認性の良さでArborを愛用させて頂いているので、可能なら一つにまとめたいところです。
大きな影響を与えるほどではないだろうという心強いお言葉も頂きましたので、ひとまず分割せずにつくり、
ご指摘通りどうしても負荷が増えてしまうようであればprefab化して分割する事も視野に入れておきます。

ありがとうございました！

ご利用ありがとうございます。

Arborにおけるデータの持ち方についてですね。

結論から申し上げますと、シーンかプレハブに全て保存されている状態ですので、ノードがアクティブになるかによらず全データ(NodeBehaviourなどのコンポーネントデータも含む)が読み込まれます。

FSMを一つにまとめるべきか分割すべきかはノードの総数や対象スペックとの兼ね合いから一概には言えないため、一般的には楽に実装できる方で検証してみてどうしても負荷が高いようなら改めるのが良いかと思います。

また個人的な見解ではありますが、消費メモリの観点からするとテクスチャや音楽データなどの大サイズデータに比べるとグラフ制御用のデータサイズは微々たるものである点、処理負荷の観点からすると実行しているコードの内容次第である点、これらから直接ノード数が負荷に大きな影響を与えるほどではないと考えております。
（もちろんUnityのコンポーネントである以上、処理負荷は0にはなりません）
（追記：ノード数が多いにしても当然限度はありますし、多すぎるとグラフが広くなりすぎて管理しずらいなどの懸念点も別途あります）

[b]以下UnityとArborのデータに関するメモ[/b]
[list]
[*][b]コンポーネント:[/b]
GameObjectに設定して処理を追加するデータ。GameObjectをシーンに配置(もしくは実行中にInstantiate)すれば設定しているコンポーネントは全てUnityのシリアライズシステムによって自動的に読み込まれる。
[*][b]Serializableクラス:[/b]
コンポーネントが持てるシリアライズ可能な内部データ。こちらもUnityのシリアライズシステムによって自動的に読み込まれる。
[*][b]NodeGraph:[/b]
ArborFSMなど。コンポーネント。各種ノードを複数持ち、再生状態を管理。
[*][b]ノード:[/b]
Stateノードなど。Serializableクラス。種類によってNodeBehaviourを1つ以上持ち、アクティブな時にNodeBehaviourの実行を制御。
[*][b]NodeBehaviour:[/b]
StateBehaviourなど。コンポーネント。ノードの挙動を実行する。
[*]このようにArborはUnityのコンポーネントシステム上で動作するように組んでいるため、内部データは全てGameObjectに関連付けられて保存されている。
[/list]

大量のデータベース（Listなど）を条件に分岐してArborによる処理へ繋ぐ仕様を作ろうと考えているのですが、
Arbor内で大量の条件分岐を用意して全ての分岐先を一つのFSMにおさめてしまうか、処理ごとにFSMを用意して外からアクセスさせるかで迷っています。

そこで仕様をお伺いしたいのですが、ひとつのFSM内で大量のノードを配置した場合、そこを通過しなくても（例えばノードの配置情報だけが全て最初に読み込まれるなどして）処理に影響する事はありますか？
それとも、どんなにたくさんのノードを配置しても通過しなかったノードは完全に無かったものとして扱われますか？

よろしくお願い致します。