共有リソースの配布方法
異なるプロジェクトで共有リソースを使用する方法は複数ありますが、それぞれのアプローチには長所と短所があります。
1.複製-プロジェクト間でリソースを複製します。
長所：
- あらゆる種類のリソースに適しています。
- 依存関係の問題はありません。
- アセットGUIDに問題はありません。
短所：
- 巨大なリポジトリ。
- バージョン管理はできません。
- 共有リソースへの変更を追跡することの難しさ。
- 共有リソースの更新が困難。
2. Gitサブモジュール -外部サブモジュールを介した共有リソースの配布。
長所：
- ソースコードを使用できます。
- 資産を配布できます。
- 依存関係の問題はありません。
短所：
- Gitスキルが必要です。
- Gitはバイナリファイルにはあまり適していません。LFSに接続する必要があります。
- リポジトリのアクセス制御。
- アップグレードとダウングレードの難しさ。
- GUIDの衝突は可能であり、それらを解決するためのUnity側の明確な動作はありません。
3. NuGet-NuGetパッケージを介した共有ライブラリの配布。
長所：
- Unityに依存しないプロジェクトでの便利な作業。
- 便利なバージョン管理と依存関係の解決。
短所：
- Unityは、すぐにNuGetパッケージを操作する方法を知りません（GitHubでは、これを修正するUnity用のNuGet Package Managerを見つけることができますが、いくつかのニュアンスがあります）。
- 他の種類の資産の配布の難しさ。
4. Unity Package Manager-Unityのネイティブソリューションを介した共有リソースの配布。
長所：
- パッケージを操作するためのネイティブインターフェイス。
- GUIDが競合する場合のパッケージ内の.metaファイルの上書きに対する保護。
- バージョン管理の可能性。
- Unityのあらゆる種類のリソースを配布する機能。
短所：
- GUIDの競合が引き続き発生する可能性があります。
- 実装するドキュメントはありません。
後者の方法には、欠点よりも利点があります。 ただし、ドキュメントが不足しているため、現時点ではあまり人気がないため、詳細に説明します。
Unityパッケージマネージャー
Unity Package Manager（以降UPM）はパッケージ管理ツールです。 Unity 2018.1に追加され、Unity Technologiesが開発したパッケージにのみ使用されました。 ただし、バージョン2018.3以降、カスタムパッケージを追加できるようになりました。
Unity Package Managerインターフェイス
パッケージはプロジェクトソース（Assetsディレクトリ）に分類されません。 これらは別のディレクトリ
%projectFolder%/Library/PackageCache
あり、プロジェクトに影響を与えることはありません;ソースで言及しているのは
packages/manifest.json
ファイルのみです。
プロジェクトファイルシステムのパッケージ
パッケージソース
UPMはいくつかのパッケージソースを使用できます。
1.ファイルシステム。
長所：
- 実装の速度。
- サードパーティのツールは必要ありません。
短所：
- バージョン管理の複雑さ。
- プロジェクトで作業するすべての人にファイル共有が必要です。
2. Gitリポジトリ。
長所：
- Gitリポジトリのみが必要です。
短所：
- UPMウィンドウからバージョンを切り替えることはできません。
- すべてのGitリポジトリで機能するわけではありません。
3. npmリポジトリ。
長所：
- UPM機能を完全にサポートし、公式のUnityパッケージの配布に使用されます。
短所：
- 現在、「-preview」を除くパッケージのすべての文字列バージョンを無視します。
以下では、UPM + npmの実装を見ていきます。 このバンドルは、あらゆる種類のリソースを操作したり、パッケージバージョンを管理したり、ネイティブUPMインターフェイスを完全にサポートしたりできるため、便利です。
Verdaccioをnpmリポジトリとして使用できます。 それについての詳細なドキュメントがあり、起動するのに数個のコマンドが必要です。
環境設定
まず、 node.jsをインストールする必要があります。
パッケージ作成
パッケージを作成するには、このパッケージの内容を含むディレクトリに、それを記述する
package.json
ファイルを配置する必要があります。 以下を行う必要があります。
- パッケージを作成するプロジェクトディレクトリに移動します。
-
npm init
コマンドを実行し、ダイアログ中に必要な値を入力します。 nameには、逆ドメインの形式で名前を指定します（例：com.plarium.somepackage
。 - パッケージ名を簡単に表示するには、
displayName
プロパティをpackage.json
追加してデータを入力します。 - npmはjs指向なので、ファイルにはUnityが使用しない
main
とscripts
を必要としないプロパティが含まれています。 パッケージの説明を詰まらせないように、それらを削除することをお勧めします。 ファイルは次のようになります。
{ "name": "com.plarium.somepackage", "displayName": "Some Package", "version": "1.0.0", "description": "Some Package Description", "keywords": [ "Unity", "UPM" ], "author": "AUTHOR", "license": "UNLICENSED" }
- Unityを開き、package.jsonの.metaファイルを生成します（Unityは、.metaファイルのないアセット、Unityのパッケージは読み取り専用で表示されません）。
パッケージを送信しています
パッケージを送信するには、コマンド
npm publish --registry * *
ます。
Unity Package Managerを介したパッケージのインストールと更新
Unityプロジェクトにパッケージを追加するには、次のものが必要です。
-
manifest.json
ファイルにパッケージソース情報を追加します。 これを行うには、scopedRegistries
プロパティを追加し、特定のスコープが検索されるスコープとソースアドレスを指定します。
"scopedRegistries": [ { "name": "Main", "url": " ", "scopes": [ "com.plarium" ] } ]
- Unityに移動して、パッケージマネージャーウィンドウを開きます（カスタムパッケージの操作は、組み込みパッケージの操作と変わりません）。
- すべてのパッケージを選択します。
- 必要なパッケージを見つけて追加します。
ソースとデバッグの操作
ソースをプロジェクトに接続するには、パッケージのアセンブリ定義を作成する必要があります。
パッケージを使用しても、デバッグ機能は制限されません。 ただし、Unityでパッケージを操作する場合、パッケージでエラーが発生した場合、コンソールでエラーをクリックしてIDEに移動することはできません。 これは、アセンブリ定義を使用するときにスクリプトがライブラリに収集され、プロジェクトに接続されるため、Unityはスクリプトを個別のファイルとして認識しないためです。 プロジェクトのソースコードを操作する場合、クリックでIDEに移行できます。
パッケージが接続されたプロジェクト内のスクリプト：
ブレークポイントが機能するパッケージのスクリプト：
緊急パッチの修正
プロジェクトに追加されたUnityパッケージは読み取り専用ですが、パッケージキャッシュで編集できます。 これを行うには、以下を行う必要があります。
- パッケージキャッシュのパッケージに移動します。
- 必要な変更を加えます。
-
package.json
ファイルのバージョンを更新します。 - パッケージ
npm publish --registry * *
。 - UPMインターフェイスを使用して、パッケージバージョンを修正済みのバージョンに更新します。
パッケージのインポートの競合
パッケージをインポートすると、次のGUIDの競合が発生する可能性があります。
- パッケージ-パッケージ。 パッケージをインポートするときに、既に追加されたパッケージに同じGUIDのアセットがあるように見える場合、インポートされたパッケージから一致するGUIDのアセットはプロジェクトに追加されません。
- パッケージはプロジェクトです。 パッケージをインポートするときに、一致するGUIDを持つプロジェクトに資産があるように見える場合、パッケージの資産はプロジェクトに追加されません。 ただし、それらに依存するアセットは、プロジェクトのアセットの使用を開始します。
プロジェクトからパッケージへのアセットの転送
Unityを開いた状態でプロジェクトからパッケージにアセットを転送すると、その機能は保持され、依存アセットのリンクはパッケージのアセットを使用し始めます。
重要 ：アセットをプロジェクトからパッケージにコピーすると、上記のセクションで説明したように、競合する「パッケージ-プロジェクト」が発生します。
可能な競合解決策
- 衝突を避けるために、すべてのアセットをインポートするときに、独自のアルゴリズムに従ってGUIDを再割り当てします。
- すべてのアセットを1つのプロジェクトに追加し、その後にパッケージに分割します。
- すべての資産のGUIDを含むデータベースの作成、およびパケット送信時の検証。
おわりに
UPMは、共有リソースをUnityに配布するための新しいソリューションであり、既存の方法に代わる価値のある方法です。 この記事で説明されている推奨事項は、実際のケースに基づいて作成されました。 それらが役に立つことを願っています。