「Unity Screen Navigator」リリースに寄せて - OSSにした理由や設計意図

Unity uGUI

Unity用の画面遷移OSSライブラリ「Unity Screen Navigator」リリースしました。
使い方はREADMEに全部書いてしまったので、本記事ではOSSにした理由や設計意図について簡単にまとめます。

はじめに

昨日、Unity用の画面遷移OSSライブラリ「Unity Screen Navigator」をリリースしました。

f:id:halya_11:20211027174149g:plain
デモ

おかげさまで多くの方々に拡散していただいて、思った以上の反響をいただいております。ありがとうございます。

GitHubのStarもいただけると海外まで広がりそうなので是非お願いしますm(_ _ )m

github.com

書くべきことは全てドキュメントに書いてしまったのでブログは書かなくていいかなと思っていたのですが、
せっかくなのでOSSとして公開する理由や設計周りの話を中心に書こうと思います。

また多分に個人の意見が入りますのでご留意ください。

Unity Screen Navigatorとは？

Unity Screen NavigatorはUnityで画面遷移、画面遷移アニメーション、遷移履歴のスタック、画面のライフサイクルマネジメントを行うためのライブラリです。
概要については以下の一連のTweetを見ていただくのが手っ取り早いと思います。

もう少し詳しく知りたい方はGitHubのREADMEを参照してください（日本語版があります）。

github.com

なぜOSSで公開するのか

さて僕はささやかながらいくつかのライブラリをOSSとして公開しています。

OSS活動を行なっている理由としては技術力向上やキャリア形成の観点もありますが、
それ以上に、汎用的で同じようなものを各会社・個人が作っている状況に疑問を感じているという点があります。

もちろん、競争優位たり得る希少なノウハウや技術は公開するべきではありませんが、
普遍的で汎用的なものはもっとどんどん公開しちゃっていいのではないでしょうか。

それにより他社・他者は工数削減という恩恵を受けますが、それだけのことです。
そんな小さなことに気を揉むより、より面白く付加価値の高いゲームを作れることを競争力と呼びたいという気持ちがあります。
またこれ以上は長くなるので詳細割愛しますが、OSS活動は個人にも企業にも多くのメリットがあると思っています。

なぜ画面遷移ライブラリなのか

さてではなぜ画面遷移ライブラリを作ったのかというと、きっかけは自分が使いたかったからです。
僕は既にあるものはなるべく使いたい人間なので、画面遷移ライブラリもきっといい感じのがあるだろうと探していました。
ところが有料のものを含めて、思った以上に画面遷移に関わるライブラリは世の中に出回っていませんでした。

前提となる仕様が多様すぎて、それらを全てカバーするような汎用ライブラリが作りづらいというのが大きな理由だと思います。
またそこまで複雑な画面遷移をするのはアジア系のモバイルゲームに多い印象なので、需要も偏っていそうです。
同様の理由で、汎用エンジンであるUnityとしてこの辺りの機能が追加されることも期待できないのではないかと思いました。

そんなわけで自分で作ることにしたのですが、仕様を自由に決められるのが自作のいいところです。
ある程度前提条件となる仕様を制約してしまえば、その範囲内においては汎用的と言えるライブラリができると考えました。
また、それで世の中的にも十分価値のあるものになると思ったので、OSS化を前提に開発することにしました。

画面遷移のルールを決めてドキュメント化する意義

前提条件となる仕様を制約することは、ライブラリの仕様がそのまま画面遷移のルールになるというメリットもあります。

例えば、画面遷移がUIデザイナーにより決められ、今まさにエンジニアが実装しようとしているプロジェクトを考えます。
ここで画面遷移のルールが設けられていない場合、エンジニアは将来の仕様変更も考えて、受け取った仕様よりも汎用的な設計をする必要があります。
しかしそれでもなおその想定を超えた仕様変更があるのはよくある話です。

ここで明確なルールが設けられていれば、UIデザイナーもエンジニアもその中で作ればいいだけです。
またそれが汎用的なルールとして複数のプロジェクトに展開されていれば、
デザイナーがプロジェクトを移動したときに一からルールを決めたり把握する必要がなくなります。

また、ルールが決まっていても伝わる形で見える化されていなければ意味がありません。
ドキュメントの整っていない社内ライブラリは実は結構多いのではないでしょうか。
ドキュメントを整えて伝えることで初めて、そのルールの上でどう工夫して実装するかという建設的な議論が可能になります。

このように画面遷移のルールを決めてドキュメント化することは開発プロセスに多大な恩恵をもたらすと考えています。

画面遷移ライブラリと抽象度

さて実装を進める上で、ライブラリをどこまで汎用的、抽象的な実装にするかは悩みました。

画面遷移ライブラリというのは究極的に汎用化しようと思えば「画面のある部分に表示される何かをどうにかして切り替える機能」になります。
「何か」はPrefabかもしれないしSceneかもしれないし、UIElementsやそれ以外の何かかもしれません。
「どうにかして」の部分は、色や形のアニメーションだけにとどまらず、マテリアルアニメーションやポストエフェクトで白飛びさせて切り替えることも考えられます。

そのような「画面のある部分に表示される何かをどうにかして切り替える機能」を低レイヤー実装としてその上に色々乗せていくこともできますが、
わかりづらくなるしそもそも僕が要らないのでやめました。

結果、uGUI用のライブラリとし、基本的にPrefabに対応、Sceneは拡張すれば使える程度の設計にしました。
また、マテリアルアニメーションやポストエフェクトなどの特殊な遷移表現については考えないことにしました。
結果、8割方の仕様には対応できるくらいの抽象度に落ち着いたのではないかと思います。8割という数字は適当ですが。

ワークフローの分離へのこだわり

また、こだわった点として、ワークフローの分離があります。

個人的に、エンジニアがいわゆるTweenライブラリでアニメーションをつけるワークフローは好きではありません。
プロのUIデザイナーやアニメーターと仕事をすると、彼らのアウトプットのクオリティとこだわりに驚かされるのと同時に、
我々エンジニアが生半可な知識とスキルでその領域に踏み込むべきではないと強く思わされます。

また、UIデザイナーやアニメーターがエンジニアに指示を出してエンジニアが実装を行うというワークフローも無駄が多いし、お互いにとってストレスがかかります。
いいものを作る上ではコミュニケーションも大事ですが、不要なコミュニケーションを排除するワークフローを構築することも同様に重要です。

もちろんエンジニアがアニメーションをつけるべきケースはありますが、できる限りワークフローは分離するべきです。
そのためこの辺りのワークフローはしっかりと分離できる仕様にしました。

プルリクも歓迎です！

画面遷移ライブラリはその特性上、リリースしたらいろんなご意見が出てきそうだなと思っていました。
今回は上述の通り仕様を絞ったので、このライブラリで充足できない仕様もあるし、正解があるものだとも思っていません。
また、事前に画面遷移のルールを制約するような作り方じゃいいものは作れないという人もいるかもしれません。

そのような議論は具体的なソースコードを通じてできるとより良い業界になるのかなと思っております。
他の画面遷移ライブラリも出てくるといいなと思いますし、Unity Screen Navigatorへのプルリクもいつでも歓迎です。

リポジトリ

github.com