YUIMgr製作の背景

YUIMgrは以下のケースを想定し、StaticLibraryとして製作を開始しました。
私自身の考えに基づく内容ですが、下記のケースが当てはまる方々には
特にオススメしますYUIMgr

1つのアプリでUI画面が沢山

 こういったケースではEditor上でUIのレイアウトを行う事を避けたかったです。
Editor上で行う場合、デザイン出来る方と人数分のUnityライセンスが必要になります。
似ているUIの変更があった場合に全UIを手作業で修正する事も避けられません。

 画面の数が100程度になってくると、画面ABCDEの5つで共通で表示される部分が
出てくると想定されます。ただしA〜Eでちょっとづつだけ表示する内容が違ったりした場合…
大元を呼び出した後でスクリプトで何を表示するかを分岐する事になるかと思いました。

アプリ毎に実装するのは時間ロス

 こういった対応が一回だけならば良いですが、アプリ毎に必ず発生します。
スクリプトのコピー程度で済めばいいですが、prefab等が絡んでくるとカスタムパッケージにして
毎回新規プロジェクトにインポートするのが最も楽で最も早いという結論になりました。

 カスタムパッケージにすると、属プロジェクト性を排除して、どのようなプロジェクトでも
必ず利用できるようにしないといけません。そういった物を自宅でポチポチと作っていました。

 ここまで作成した段階で、「あれ、これスクリプトだけどアセットストア提出できるんじゃないか」
と思ったのがきっかけです。




YUIMgrの設計方針

YUIMgrは以下の設計方針に基づいて制作しました。

Pluginは利用しない

 中でどのような処理が行われているかわからない状況を避け、自由に改変できるようにしています。 あまりローレベルな処理はOSの更新等で問題が出る可能性があるため全て標準の処理で実装しました。 リリースの直前程、ライブラリレベルの応急処置が必要になると想定しています。

継承可能なスクリプト

 ほぼ全てのクラスメンバ、関数をprotectedで構成し、また必要な物はvirtual関数としています。
動作をカスタマイズしたいクラスについては継承クラスを定義する事でプロジェクトに適した運用をする想定です。

関連分野は含める

 リソースの非同期ロード、画面暗転、Tween等
UI分野も含めて必ず使う機能なので合わせてパッケージに入れています。

プラットフォーム依存なし

 全て標準スクリプトで構成しているため、原則プラットフォーム依存はありません。

リリース向け

 仮組みのUIがそのままリリースという事も多々あります。
デバッグGUI向けではなく、そのままリリースできる物を想定して制作しました。