Visual Scripting 覚書

Log
2022-03-12

2024/2/7更新
2023/11/29更新

1年以上Visual Scriptingを使ったと思うので、使い方も踏まえて書いていく。

  • 追加方法
  • アセット
  • Variable
  • Subgraph
  • C#との連携
  • Coroutine
  • Input System
  • Button
  • Animator
  • Post Process
  • DOTween
  • 見栄えノード

目次機能は存在しないので字面だけで。
なお、Post Processについてわかったことは、Visual ScriptingでPost Processをいじる方法はよくわからんということだけ。

追加方法

デフォルトでは入っていないので、Package Managerからインポートする。

「State Machine」と「Script Machine」の2つに加え、「Variable」なるものが存在する。

Script Machine

これが基本。
普通のC#のVisual Scripting版だと思っていい。

State Machine

State Machineは状態遷移専用のシステムが搭載されている。
状態によって挙動を変える場合はこっちを使う。
大は小を兼ねるという観点で言うと、State Machineが大の方。

「On Enter State」や「On Exit State」といった専用のノードもある。
「On Enter」や「On Exit」ではなく、遷移中のGraphに同じ処理を入れてもそう変わらない。
どっちでもいいなら遷移中の方に入れた方がスッキリする。

状態遷移は基本的に「On Collision Enter」などのイベント関数の他、「Trigger Custom Event」で自由に切り替えられる。

なお、Script MachinとState Machine両方に言えることだが、ノードを増やしまくるとかなり重くなる。
Editor全体が重くなって作業効率が激落ちするので、分けられるなら極力分けた方がいい。
正直ここのところはVisual Scriptingの開発に頑張って欲しい。

EmbedとGraph

EmbedとGraphはスクリプト単体で保存するか、オブジェクトに独自に付随するものかという違い。
Embedだとオブジェクトに限定するもの、Graphだと他のオブジェクトで共通して使いまわせるものになる。

ちなみにEmbedだと「Hierarchyのオブジェクトを直接グラフにぶち込める」というメリットがある。
また、EmbedとGraphに共通して、「ProjectoウィンドウのPrefabなんかは直接ぶち込むことが可能」である。
わざわざVariableを作成する必要はない。

ただ、Embedの場合はスクリプトとして保存されているわけではないので、ミスってオブジェクトごと消したままUnityを落としたりするとグラフが全て吹っ飛ぶことになる。気を付けたい。

ちなみに、EmbedのGraphを付けたオブジェクトをPrefabにすることもできる。
その場合、Graphの編集はPrefabからしか操作できない。

Variables

Script MachineやState Machineを作ると勝手についてくる。
なお、Variables単体でアタッチすることも可能。
逆は不可。

名前を入力した後、型を選ぶ。
Listで入れることも可能。
「List of ◯◯」という名前の型が大量にあると思う。

どの範囲で使用するかによってVariableを作る場所が違う。
Inspectorから入力できるものは「Object Variable」という種類。

Node

Script Graphの編集は「Edit Graph」から。

右クリックから欲しい関数やらコンポーネントやらを探して貼り付けるもの。

説明のTargetやValueの種類を見れば、なんとなく探しているものかどうかわかる。

見つからなかったらProject SettingsのVisual Scriptingからノードを追加する。

「Type Option」で見つからなかった場合は、「Node Library」の方から探す必要がある。
「Node Library」に追加した後、「Type Option」で目当ての物を追加する。
追加できたら「Regenerate Node」を押してProject Settingsを閉じる。
間違って「Reset to Defaults」の方を押さないように注意。

「Text Mesh Pro」や「Post Process」など、デフォルトで入っていないものに関しては大体入っていないと思っていい。

自分で書いたスクリプトはpublicにすることで関数や変数をVisual Scriptingに持ってこれる。
スクリプトを書いたらRegenerate Nodeする。
でないと反映されない。

関数の中身だけ書き換えた時はRegenerateしなくていい。

アセット

詳細に入る前に入れておきたいアセットの紹介をしておく。

Node finder for unity visual sctipring

Graph内のNodeを検索できるアセット。
自分のUnityのバージョンは2022.3.3f1のURPだが、とりあえず使えている。

CustomEventの名前なんかも検索できるので、複雑になってきた頃にあると助かる。

正直Unityがデフォルトで入れておいて欲しい……

Variable

Visual Scriptingでは変数をVariableなんたらみたいな感じに宣言する。
「Flow」「Graph」「Object」「Scene」「Application」「Saved」

ObjectとSceneのみInspectorから追加する。

なお、Sceneの方は「VisualScripting SceneVariables」というものがHierarchyにいつの間にやら追加されていると思う。

Flowは「Set Flow Variable」でノードとして直に書き込む。

他はVisual ScriptingウィンドウのBlackboardから追加。
左上の<x>がBlackboardだが、初見でわからないだろこれ。

なお、私個人としては「Flow」と「Graph」以外のVariableの使用はあまりお勧めしない。
単純に、クッソ見づらいから。
冷静に考えて「Name」「Type」「Value」で3行も使うのは異常である。

また、Variable全てに対して言えることだが、検索機能が存在しないので、名前を変えようと思った時にめちゃくちゃ面倒くさいことになる。
色々変更していくうちに、どのVariableを使っていて、どのVariableを使っているのか分からないなんてことになったりもする。

さらに、これも全Variableに言えることだが、エラーが起きるタイミングまで一切ミスが分からないという弱点がある。
単純なスペルミスさえわからない。

なので、言ってしまうと最早Variablesは使わない方がいいかもしれない。
それでも毎回C#を変更してノードを再構築するのも面倒なので、結局FlowやGraph辺りは使うことになる。
私は変数だけ登録するC#を作って運用している。

Flow

Updateでリセットされる。

また、ループ内部で「Set Variable」を置いてもループ外から拾える。

Graph

Script Graphに付随する変数。
C#で普通に書く変数だと思っていい。
同じScript Graphを持つオブジェクトで初期値を共有できる。

当たり前だが、Subgraph内部渡すためにはそれ用のInput値が必要。
何となく直観に反するのでたまに間違える。

Object

Inspectorから入力できる変数だと思っていい。
オブジェクト毎に別の値を入力できる。

当たり前だがこっちはSubgraph内で直接使える。
だが、他のオブジェクトで同じSubgraphを使いたくなったときにエラーを引き起こす可能性が出てくる。

また、他オブジェクトのグラフからもアクセスできる。
大変使い勝手がいいように見えるが、それによって無い変数を使ってしまう可能性が劇的に高まるので、できるだけ使いたくない。（あと邪魔くさい）

Scene

シーン内で共有する変数。
シーンの追加をしたりしてScene Variablesのあるオブジェクトが2つになったとしても、元々同じシーンにあったScene Variableにしかアクセスできない。

普通にそれ用のC#を作った方が見栄えも兼ねて良いと思う。

Application

シーンを跨いで使える変数。
どこからでも取得/変更可能。

Scene Variableと同様、C#作った方がいいと思う。

Saved

ゲームを閉じても記録されるものらしい。
使ったことないので説明できず。

Subgraph

何度も使う関数はSubgraphにする。
Convertすることで共通スクリプトとして使うことができる。

Subgraph内のEnterやExitに入出力を書くことができる。

Enter側は「Has default value」にチェックを入れることで、IntやStringなどをSubgraphのノードに直接書き込めるようになる。
また、Hide Lavelにチェックを入れることで名称を非表示にできるので、少しスッキリする。

とても便利。

Exit側は分岐の結果を分けることもできる。

これも結構便利。

なお、汎用的なSubgraphでObject以上のVariableを使うと大変なことになりかねないので注意。

C#との連携

C#側の変数や関数はpublicにしてRegenerate Nodeすることでグラフに持ってくることができる。

また、C#側からVisual Scriptingの関数（Custom Event）を実行することも可能。

using Unity.VisualScripting;

CustomEvent.(Trigger(gameObject, "onTrigger", arg1, arg2);

VariableをC#から取得する方法はわかりませんでした。

Callback

CallbackをVisual Scriptingで実装する方法は今のところない。
なので、C#を経由して実行することになる。

Visual ScriptingからC#関数を実行
→C#からCallbackを含んだ処理を実行
→C#でCallbackからVisual ScriptingのCustom Eventを実行

という流れになる。

最初にこれを実行。

public void sceneLoad(string name, LoadSceneMode mode)//これがグラフから実行される
{
    StartCoroutine(Load(name, mode));
}

IEnumerator Load(string name, LoadSceneMode mode)//ここでコールバックを含んだ処理を実行
{
    SceneManager.sceneLoaded += OnSceneLoaded;
    //省略

void OnSceneLoaded(Scene scene, LoadSceneMode mode)//コールバックでこれが実行される
{
    CustomEvent.Trigger(gameObject, "onSceneLoaded");//グラフに戻る
}

で、ここに行きつく。

Coroutine

トリガー部分にチェックを入れることで、Coroutineとして動作させることができる。
「Wait」系のノードなどでは必須。

一方「Wait For Flow」なんかはCoroutineじゃなくてもいい。
ただその場合、どこか一か所でもCoroutineが外れていると、それ以降はCoroutineが外れているものとして扱われる。
つまり、以下のような場合だとエラーになる。

Subgraphにトリガーが入っていたりすると事故りやすい。

ちなみにCroutineの止め方は知らない。
特に「Wait」系なんかは他のスクリプトとの兼ね合いで変な動作を引き起こしやすいので注意。

Input System

Input SystemもVisual Scripting同様比較的最近登場したもの。
割とVisual Scriptingと相性がいいので使いたい。
「On Input System」で使える。
使うときはこんな感じ。

InputActionはHierarchyのInputActionに繋がっている。
黄色いのはInputActionの初期値を設定してないから。

Button

Buttonは「Unity Event」から。

Button側は「ScriptMachine.TriggerUnityEvent」を指定して同じ名前を入力すればいける。

また、Event Triggerを追加すれば他の動作にも対応できる。

Animator

Animation EventでVisual Scriptingを実行する場合に設定する時の関数は「Trigger Animation Event（Animation Event）」というものになる。

Visual Scriptin側は「Animetion Event」というノードが実行される。
ちなみに、Animation Eventを先に追加しておかないとTrigger Animation Event（Animation Event）が出て来ない。

Animation EventのノードはAnimatorが付いているオブジェクトに入れる必要がある。
Animation Eventのノードは一つしか置けないので、複数設定している場合には別の方法で実行先を分ける必要がある

Post Process

Post ProcessのパラメーターをVisual Scriptingだけでいじる方法はわからなかったので、基本的にはC#で関数を作ってグラフから実行するのが良いと思われる。

DOTween

Sequenceに関してはこんな感じ。

なお、Callbackを実装することはできないので、その辺に関してはC#を経由する必要がある。

また、IDとTargetを指定すれば実行中の動作を中止できるが、面倒なので以下のようなSubgraphを作ってしまうのが楽。
楽だが、多分Sequenceには対応できていない。解決策を模索中。

全体として、簡単な動きはVisual Scriptingに直書きして、複雑なものはC#に関数を作ってVisual Scriptingから実行するのがよさそう。

見栄えノード

Sequence

横に伸びすぎた場合は「Sequence」を使うことで縦に戻すことができる。
Sequenceの若い番号から進んでいき、続きがなくなるとSequenceの次番号に進む。

処理内容に区切りがついた時などにも使う。

if/Switch

if文よりもSwitch文を使った方がスッキリする。

「Switch on integer」や「Switch on String」はスペースの効率化に役立つ。
特にSwitch on integerは使う数字が1しかなかろうがifより小さくなるので使いがち。

他

計算系なら「Add Generic」より「Add Scalar」の方がノードが1つ減ったり、Vector3の計算でも「Subtract Vector3」を使うことで「Create Vector3」をする手間が省けたりする。
「For Loop」ではなく「For Each Loop」を使えば大きさを調べる必要もなくなる。

計算ばかりになる場合はC#で関数を書き、どれを実行するかはVisual Scriptingで決めるという方法もある。

コメント

タイトルとURLをコピーしました