シーン管理と画面遷移を1本のツリーに統合。サムザップ、内製のUnity向け画面遷移フレームワーク「Spica.Navigation」の設計をブログで解説

サムザップは2026年11月6日（金）、『シーン管理と画面遷移を統合するUnityナビゲーション基盤の設計と実装』と題した記事を、同社の技術ブログにて公開しました。

同社のクライアントエンジニアが、内製のUnity向けアプリケーション基盤「Spica」に含まれる画面遷移フレームワーク「Spica.Navigation」について、設計判断と内部実装をコードとともに解説しています。

（画像はブログ記事より引用）

「Spica」は、サムザップがプロジェクトをまたいで再利用できるよう、共通の機能をUnityのパッケージとして整備したもの。「Spica.Navigation」はその中に含まれるパッケージのひとつであり、シーン管理と画面遷移を統合したフレームワークです。

Spica.Navigationの開発経緯として、同社は記事中で、ゲームの画面遷移は新規プロジェクトのたびに作り直されがちで、品質や作法がプロジェクトごとにばらついていたと振り返っています。

その原因のひとつとして、シーン管理と画面遷移が別々の仕組みとして実装されることが挙げられました。そこでSpica.Navigationは、シーン単位の「Session」と画面単位の「Screen」を同じ種類のノードとして扱い、アプリ全体に常駐する「Root」の下に1本のツリーとして並べる設計へ。ライフサイクルも、SessionとScreenで1種類に統一しています。

遷移のときは、現在のノードと遷移先のノードに共通する祖先をツリーから求めます。閉じるのは現在のノードから共通祖先の直下までのノードのみ、開くのは共通祖先の直下から遷移先のノードだけです。同じSessionの中で別のScreenへ移るときは、共通の祖先がそのSessionなのでシーンには触れません。Sessionをまたぐときだけ、シーンごと入れ替わります。ノードの種類を見て分岐するコードはなく、何を閉じて何を開くかはツリーの構造で決まります。

遷移にかかわる処理は、それぞれ独立した部品に分けられ、組み合わせで振る舞いを変えられます。どこへ遷移できるかや、戻る操作での戻り先を決める「ルーター」、遷移中に画面を覆うフェードなどの演出も、独立した部品として差し替えられます。

ノードの構成と遷移先のつながりは、コードで手書きせず、GraphView（※）で構築されたグラフエディタ「Navigation Graph」で定義します。
※　Unity内でノードベースのエディタを作成できる機能

グラフエディタ「Navigation Graph」。Play Mode中は、現在の画面にあたるノードが水色の枠でハイライトされる（画像はブログ記事より引用）

詳細はブログ記事をご確認ください。