Arborは今年で10周年 ~振り返りと今後について~


Arborは今年2024年5月21日で1.0.0リリースからちょうど10年になります。

今回はこの10年間でのArborの開発を振り返ります。

Arborの振り返り

開発のきっかけ~Arbor1.0.0

当時はまだUnity4だった頃の話になります。
Unityで挙動制御のステートマシンが必要になったのが開発のきっかけです。

ステートマシンは、動作の状態の移り変わりを組むための仕組みです。
ステルスアクションゲームなどの敵の動作を考えてみましょう。
まず敵には「警戒」状態と「休憩」状態があるとします。
「警戒」はプレイヤーを索敵し、見つけたら追跡と攻撃を行う状態です。
プレイヤーが見つかっていないのであれば、一定時間経過後に「休憩」に遷移します。
「休憩」は休憩所に移動して仮眠する状態です。
一定時間経過するか、他の敵がプレイヤーを見つけた情報が共有されたら「警戒」に遷移します。
このような動作の状態と遷移の流れを組んだものをステートマシンと呼びます。

まずはコードベースのステートパターンで実装していましたが、各ステートにパラメータを設定する際にどこからパラメータを引っ張ってくるかが1つの課題でした。
敵の動作の例で言うと、休憩時間の長さなどの数値データです。

そこで行き着いた1つの答えが、ノードグラフエディタでした。

  • グラフにステートノードを配置
  • ステートノードにStateBehaviourを複数アタッチ
  • StateBehaviourスクリプトには挙動とパラメータを書く
  • 必要に応じて、遷移条件を判定して遷移用スロットの接続先ノードに遷移する処理も書く
  • StateBehaviourはMonoBehaviourと同じくエディタ上でパラメータを編集できるようにする
  • 遷移先はエディタでドラッグ&ドロップして繋ぐ
  • つまりステートの挙動とパラメータと遷移の設定場所がバラバラになることなく1つのスクリプトで完結する
  • グラフとして全体像が可視化されるためプレイテストもしやすくなる

Arbor1初期の見た目

このようにしてシンプルな構造のステートパターンを設定するためのノードグラフエディタを作成しました。
折角作ったのだからアセットストアで販売してみよう、ということでArbor1.0.0を2014年5月21日にリリースしたのが始まりです。

Arbor1

Arbor1ではステートマシンとしての整備を行ってきました。

  • 常駐ステートの追加
  • パラメータの一時保存用のParameterContainerの追加
  • 一般的によく使われるUnity APIを扱うためのStateBehaviourスクリプトの追加
  • などなど

あくまでステートパターンの延長線上で機能を充実させていきました。

Arbor2

Arbor2では、データフローが追加されます。
これはノード間の値の受け渡しと計算を行うための入出力スロットと演算ノードで構成されます。

例えば敵の索敵ステートから追跡ステートに遷移する際に、索敵ステートで見つけた対象オブジェクトを追跡ステートに受け渡すなどをグラフ内の設定で完結できるようになります。

データフロー

データフローの登場により、シンプルなステートパターンのためのエディタから、ビジュアルスクリプティング風のエディタとなっていきます。
ただし根本はステートパターンの補助エディタです。
スクリプトは依然書く必要があります。
「ノーコード」を実現したいわけではありません。

Arbor 2.0.0は2015年10月16日リリースでした。
当時はまだUnity5時代のことです。

Arbor2の更新で機能拡充やエディタのデザイン洗練を行い有限ステートマシンのエディタとしては一旦の完成系となります。

Unite 2017 Tokyoで紹介される

2017年5月8日~9日、Unite 2017 Tokyoが開催されました。
そこで行われた講演「Unityで出来る『見える開発』のススメ」にてArbor2の利用事例を紹介していただけました。

ここまで地道に開発を続けていただけでしたが、このような大舞台で紹介していただけたのは開発冥利に尽きます。

Arbor3

[CEDEC 2015]「FFXV」で導入されるゲームAIの仕組みが明らかに。ゲームエンジン「Luminous Studio」の先進的AIシステム

ゲームキャラに“命”を与える–AIをフル活用した「ファイナルファンタジーXV」

これらの記事を読んだことがきっかけで、Arborにビヘイビアツリーを導入することにしました。
それに合わせてグラフの階層化も実装します。

ビヘイビアツリーとは挙動制御を行うための仕組みです。
どのような挙動を行うかに着目し、挙動を行う条件と組み合わせて木構造を構築していきます。
挙動を制御するという点ではステートマシンと似ていますが、ステートマシンは遷移条件がステート同士に直接紐づいているのに対し、ビヘイビアツリーは挙動を行う側で実行するかどうかの条件判定を行う点が異なります。
「休憩中に交代の時間になったので警戒態勢に移る敵(逆に休憩中ならそもそも索敵すらしない)」などはステートマシンが得意としますが、「警戒中はどのような行動をしているかに関係なくプレイヤーを見つけたら追跡する敵」などはビヘイビアツリーの方が組みやすいです。
ステートマシンとビヘイビアツリーの両方を階層的に組み合わせることでより柔軟な挙動制御が構築できるようになります。

Arbor 3.0.0は2018年03月09日リリースでした。
当時はちょうどUnity2018がリリースされたあたりです。

ここから約6年、FSMとBT両対応のエディタとして機能拡充していきます。
またUnityのバージョン更新に合わせて、一部UI Tookit対応など内部実装も入れ替えていきます。

ドキュメント整備にも力を入れました。
良い機会なので、内部利用のために開発したドキュメント生成機能も紹介します。

それまでもドキュメントはありましたが、マニュアルとInspectorリファレンスとスクリプトリファレンスとでそれぞれ別々のツールを用いていたため、個別対応での更新コストが大きくなっていました。
そこで、ドキュメントを統一することを決めました。
静的ドキュメントツールはHugoを採用しました。
マニュアルは手書きで事前にマークダウンを記述しておきます。
各リファレンスは、C#のドキュメントコメント(/// <summary>概要</summary>のようなコメント)からHugo用のマークダウンファイルを出力するUnityエディタ拡張を作り自動生成にするようにしました。
スクリプトの追加や変更を行ったあとはドキュメントコメントをコードに書いておけば、あとはボタン1クリックで画像撮影とリファレンス生成が行われます。
あとは必要に応じてマニュアルを更新してHugoで出力すれば完了です。
これでドキュメント更新の手間が減り、機能開発に専念できるようになりました。

Arbor Documentation

これにてステートマシンだけでなくビヘイビアツリーにも対応した「挙動制御系エディタ拡張アセット」としては一旦の完成系となります。

第2回Unity Asset Contestにて最優秀賞&Unity賞受賞

2020年8月当時、ユニティ・テクノロジーズ・ジャパン合同会社さま、株式会社マイスター・ギルドさま、株式会社パノラプロさまの3社によりアセット開発のコンテスト「第2回 Unity Asset Contest Powered by Unity, AssetPark, PANORA」が開催されました。

集え、新時代を切り拓くアセット作者たち!アセット開発のコンテスト「第2回 Unity Asset Contest」開催

Arbor3も応募したところ、なんと最優秀賞とUnity賞のダブル受賞となりました。
このような形で認めていただき大変光栄です。

コンテスト公式サイト (2024年4月現在、ページが正常表示されなくなってるようです)

またUnity JapanさまのUnityステーションにて紹介していただけました。

売上的な話

2024年3月末現在の売り上げ総額としては以下の通りです。

  • Arbor1: $924.80
  • Arbor2: $8642.00
  • Arbor3: $50454.90
    • 別途バンドルセールで$3006.89(こちらは入金額)

月別では以下の通り(バンドルセールを除く)

バンドルセールを除いた月別過去最高売り上げは2019年5月の$3316でした。
Arbor3だけで見ると月平均$690程という感じです。
直近1年間では月平均$300程の売り上げがあります。
円安など情勢の影響か、ここ1年の売り上げは低迷気味で以前より半減している感じです。

アセットストアの手数料がありますので実際は70%が入金されます。
また円送金でさらに為替レートの影響を受けます。
当然所得税がかかりますし、サーバー代などの出費もあります。
アセット販売だけで生活できるかというと状況としては厳しいばかりです。

ただ、こうして長く続けていられるのもArborを選んで利用していただいている方あってこそです。
改めてArborをご利用していただきありがとうございます。
PC周辺機器、机や椅子の買い替えなどの開発環境整備に重宝しております。

(もちろん、どうせならより爆発的に売れるなら売れてほしいのが正直な思い……)

今後について

ここまでで機能面としては一通り完成いたしました。
新機能開発はここで一旦終了となり今後はサポートが主になっていきます。

サポートについて

サポートは引き続き継続して行っていきます。
主なサポート内容は以下の通りです。

  • Unity最新版リリースによる変更対応
  • 不具合修正
  • 質問や軽微な要望対応などのユーザーサポート

もしUnity側が破壊的変更を行い容易に対応できなくなったらその時にまた今後について考えます。

新アセット「Logic Toolkit」について

これからはArborの開発経験を活かし基本理念を踏襲しつつ最新Unity用に一新したアセットを主に開発していこうと思います。

名前は「Logic Toolkit」にしました。

クリックでLogic Toolkit公式サイトを開く

Logic Toolkitの主な特徴は以下の通りです。

  • ノードグラフ型ビジュアルスクリプティングアセット
  • 「タスク」の実行の流れを構築し「見える化」することに特化
  • ステートやビヘイビアツリーはタスクの1種とみなしたノードとして実装(1グラフ内に混在可能)
  • SerializeReferenceによりUnityコンポーネントに依存しない多態性とグラフ共有を実現。
  • 関数のように扱えるグラフによる階層化に対応
  • ノーコードの実現 : API(C#のメンバー)アクセスを行うノードコンポーネント用スクリプトをRoslyn Source Generatorで生成
  • Unity2023.2以降対応(実質Unity6向け)

2024年中の正式リリースを目指し鋭意開発中です。

また先行試用版もありますので、ご興味のある方はぜひ一度お試しください。
以前Xにもポストしましたがそれ以降も告知なしに更新しているので改めてDLしてみてください。
感想などもいただけると嬉しいです。

最後に

Arbor 1.0.0リリースから約10年間、些細なきっかけで始めたアセット開発ですが非常に多くの方に長くご愛用いただき大変ありがとうございます。

今後ともArborとケットシーウェアをよろしくお願いいたします。