VisualScripting

VisualScriptingはUnity公式が提供しているノードベースのノーコードツールです。 Unity2018からBoltとしてAssetStoreで有料販売されていましたが、 Unity社が買い取りUnity2021からはVisualScriptingとして統合されています。

unity.com

ぷにまるずで使われているVisualScripting

ぷにまるずのインゲームでは以下のものがVisualScriptingで実装されています。

UI演出
- 開始/終了時演出、ストックが減ったとき、コンボ表示など
キャラクターアニメーション
- 移動、ショットなど
エフェクト
- ヒット、撃破など
カメラ演出
- ゲーム開始時のパン、撃破時のズームなど
ステージ演出
- ステージのコンポーネント動作など
チュートリアルの制御
- 移動場所やショット方向の判定、Tipsの表示、UIの押下可否など

ぷにまるずでは、VisualScriptingを主に演出やアニメーションの制御に使用しており、ゲームの基盤ロジックはC#で実装されています。例外としてチュートリアルではロジックの制御も行われますが、VisualScriptingだけで実現しています。

これらの処理はVisualScriptingを使えるデザイナーによって実装されており、エンジニアが直接触る必要はありません。エンジニアがやることは以下の2点です。

VisualScriptingに必要なデータを参照できる形式で渡す。
VisualScriptingのイベントを発火する。

構成

ぷにまるずではVisualScriptingを利用するため、下図のような構成になっています。

InGameLifetimeScope
- VContainerを導入しており、LifetimeScopeに寿命管理を一任している。
AnimationEventBridge
- VisualScripting Targetを参照する橋渡し役。
- キャラクターなどを伴わない演出はこれ経由で発火する。
VisualScriptingTarget
- これにアタッチされているStateMachineから様々な処理が行われる。
- 自身はSceneVariablesに設定されており、他のStateMachineから参照できる。
- 演出に必要なデータをVariablesに設定しておく。
キャラクターなど
- キャラクターにもStateMachineが設定されている。
- 主にキャラクターのアニメーションを制御している。

橋渡し

ぷにまるずのコード上には以下のように各種イベント名を定数で定義しています。

public static class VsEventMessages
{
    /// <summary>
    /// 初期化終了して、ゲーム開始の演出
    /// </summary>
    public const string OnGameEntry = "OnGameEntry";

    /// <summary>
    /// ゲーム開始
    /// </summary>
    public const string OnGameStart = "OnGameStart";

    /// <summary>
    /// ターン開始
    /// </summary>
    public const string OnTurnStart = "OnTurnStart";

    // 以下同様に記述
}

呼び出したいときは以下のように CustomEvent.Trigger 関数を呼び出します。

CustomEvent.Trigger(visualScriptingTarget, VsEventMessages.OnGameEntry);

VisualScriptingにもイベント名を参照して同名のCustomEventを作成しておくと、イベントが紐付けられます。

この先はデザイナーに自由にいじって貰えるようになっており、エンジニアが触らなくとも演出をつけることができます。

また、ぷにまるずで動いているものは前後の処理が複雑になっており、動かしたイベントの終了待ちやタイムアウトの検知、リアルタイム通信での複数回呼び出しの抑制のためTickを用いたキューイングをするなどの工夫をしています。

メリット

エンジニアはエントリーポイントとしてイベント名や必要な変数を渡しておけば演出に気をかけることなく開発ができるようになり、内部処理・リアルタイム通信・マッチング・アウトゲーム・最適化など他の重い部分に工数を割くことができました。これにより、ぷにまるずの短期間でのリリースが実現しました。

また変数によってデザイナー側で演出を変えることができるため、デザイナーが実現できることにも幅が出ました。チュートリアル制御などは最たるもので、これをエンジニアが対応せずに済むのは革命的でした。デザイナードリブンでかなりゴリゴリと開発が進むようになり、開発中の最新版をpullする度に見た目がブラッシュアップされていました。

デメリット

デザイナーが開発していくことになりレビューもしづらいため、エンジニアから見るとかなりブラックボックス化します。バグの発生原因の切り出しなど、どこからがVisualScriptingの領域なのかを把握する必要があります。イベント名でエントリーポイントをルール付けているのはその対策であり、原因究明は比較的しやすくなっていると思います。

モバイルWebGLという制限の多い環境だったこともあり、パフォーマンス面にも気を払う必要がありました。 VisualScriptingは内部的にはjsonであり、デシリアライズのタイミングでGC Allocが発生したり、jsonそのものの容量も無視できません。そのため、VisualScriptingの最適化が発生し、エンジニアもVisualScriptingを少なからず把握する必要がありました。具体的には、以下のような最適化を行いました。