ライブラリやアセットを開発するときに気にしてること
本記事は、Unity #3 Advent Calendar 2018 13日目の記事です。
個人で開発をしていると、再利用可能な部品を切り出して軽率にオープンソースとして公開することができて幸せですね。
今回は自分がプロジェクトからライブラリとして切り出すときに気を付けていることを述べていきたいと思います。
配布形式
ライブラリとして配布したいときは、アセットとしてエクスポートします。
metaファイルを除いた .cs ファイルをzipで固めてとかの配布は、辛くなるので避けた方が良いです。
シンプルなコードだけ共有したいなら、Gist や Pastebin のサービスを使うのも手です。
Directry
ライブラリ名の前に自分のブランドのディレクトリを入れるかは任意ですが、 本稿では「ブランド名/ライブラリ名」であっても一律に「パッケージ名」と呼称します。
よくあるサンプルプロジェクトのようにAsset直下に各フォルダを展開するのではなく、パッケージ名でフォルダを作ります。
AssetBundle用の「StreamingAssets」フォルダの下にも、ファイルの衝突を避けるために「パッケージ名」でフォルダを作るのがよいでしょう。
namespace
アセットとして部分的機能を配布する場合、名前空間は積極的に定義しましょう。
一度配布開始すると後々の変更は痛みを伴いますので、名前空間は配布前につけておきましょう。
聞いているかSteamVR
Resource or StreamingAssets
Resources フォルダは「パッケージ名」ディレクトリの下に配置しても大丈夫ですが、
StreamingAssetsフォルダは、Assets直下に、しかもプロジェクトあたり1つしか配置できません。
なので、名前資源は大事に、もし使う場合は、StreamingAssetsフォルダ内に「パッケージ名」でフォルダを作るのがよいでしょう。
ReadOnlyで良いバイナリファイルなどはResourcesに配置し、
バイナリでアクセスされるべき小さいファイル、sqliteのデータなどのように書き込みで変更される可能性があるファイルなどはStreamingAssetsに配置します。
対応バージョン
Unity5.xは新規プロジェクトで使われることはなくなったので、 これから作られるライブラリ については、Unity2017 LTS 以降のサポートで良いでしょう。
※Unity5.x のレガシープロジェクトで、 新しい外部ライブラリ を導入するケース…ないですね。
Scripting Runtime Version → API Compatibility Levelについては、 .NET 4.x以降に限定するか、非常に悩ましい問題です。 自身のプロジェクトのみで使う場合は、迷わず.NET 4.x以降に限定してしまうところですが、 他のプロジェクトにも広く使ってもらう場合、Unity2017 LTSのサポートが終了するまでは、2.x Subset に対応した形で公開すべきです。
再配布可能な外部ファイル・リソース
再配布可能 、かつ 枯れている 、 下位依存 のファイルは埋め込んでしまっても良いでしょう。
UniRxなどの更新が活発・上位依存なライブラリは、配布物に含んでしまうと、公開したものに古いバージョンが混入してしまい、ファイルの競合問題が発生するなどのトラブルのもとになります。なので埋め込まない方が良いです。
モデルを配布する際のシェーダーなどは下位依存といえるので埋め込んだ方が幸せです。
モデルをたくさんインポートした場合、プロジェクトの中に同じ Unityちゃんシェーダーが溢れる気もしますが、 metaファイルのハッシュが同じであれば同じファイルとみなされ、一つのファイルを参照する(複数インポートしない)ので、metaファイルを再生成しなければ安心です。
プロジェクトのディレクトリが混沌としそうですが、そこはアセット配布者が考えることではないです。
サンプルプロジェクトどうする問題
実際に使ってもらう、配布した機能を試してもらう場合、サンプルプロジェクトを開いてもらうのが手っ取り早いです。
AssetStoreで配布する場合、単一のアセットファイルしか配布できないので、サンプルプロジェクトを同梱せざるを得ません。
ファイルが増えようが容量が増えようが同梱してしまいましょう。
どうせドキュメントまでも同梱しないといけないのですから。
GitHubなどでオープンに配布する場合、サンプルプロジェクトを別のアセットファイルに分けることができます。
そうすることで、皆のプロジェクトに余計なファイルが含まれなくて済みます。
さいごに
プロジェクトに依存しない、再利用可能なパーツやロジックなどをオープンで公開すると、
開発者がより自分の実現したい課題に集中できる世界になるので、みんなどんどんライブラリとして切り出していきましょう。
企業のステークホルダの方へ。
もし、開発メンバーがライブラリを公開したい/切り出して売りたいといった要望が出た時には、認可してあげてください。
筆者も過去に所属していた企業で、ライブラリの公開/販売を認可されずにぐれました。
