Unityパッケージマネージャー

Unity はかなり前から存在し、常に進化しているプラ​​ットフォームです。 ただし、同時に複数のプロジェクトで作業する場合、共通のソース (.cs)、ライブラリ (.dll)、およびその他のアセット (画像、サウンド、モデル、プレハブ) の使用で問題が発生する可能性があります。 この記事では、Unity のこのような問題に対するネイティブ ソリューションの経験について説明します。

共有リソースの配布方法

さまざまなプロジェクトで共有リソースを使用する方法は複数ありますが、それぞれのアプローチには長所と短所があります。

1. 複製 – プロジェクト間でリソースを「手作業で」複製します。

長所：

• あらゆる種類のリソースに適しています。
• 依存関係の問題はありません。
• アセットの GUID には問題はありません。

短所：

• 巨大なリポジトリ。
• バージョン管理の可能性はありません。
• 共有リソースへの変更を追跡するのが難しい。
• 共有リソースの更新が困難です。

2. Git サブモジュール — 外部サブモジュールを介した共有リソースの配布。

長所：

• ソースを操作できます。
• アセットを配布できます。
• 依存関係の問題はありません。

短所：

• Git の経験が必要です。
• Git はバイナリ ファイルにはあま​​り適していません。LFS に接続する必要があります。
• リポジトリのアクセス制御。
• バージョンのアップグレードとダウングレードが難しい。
• GUID の衝突が発生する可能性がありますが、Unity 側には衝突を解決するための明確な動作はありません。

3. NuGet - NuGet パッケージを介した共有ライブラリの配布。

長所：

• Unity に依存しないプロジェクトでの作業が便利になります。
• 便利なバージョン管理と依存関係の解決。

短所：

• Unity は、そのままでは NuGet パッケージを操作できません (GitHub で、これを修正する NuGet Package Manager for Unity を見つけることができますが、いくつかのニュアンスがあります)。
• 他の種類の資産を配布するのが難しい。

4. Unity Package Manager - Unity のネイティブ ソリューションを介した共有リソースの配布。

長所：

• パッケージを操作するためのネイティブ インターフェイス。
• GUID の競合によるパッケージ内の .meta ファイルの上書きに対する保護。
• バージョン管理の可能性。
• Unity のあらゆる種類のリソースを配布する機能。

短所：

• GUID の競合は依然として発生する可能性があります。
• 実装に関するドキュメントはありません。

後者の方法には、欠点よりも利点の方が多くあります。 ただし、ドキュメントが不足しているため、現在はあまり普及していないため、詳しく説明します。

Unityパッケージマネージャー

Unity Package Manager (UPM) はパッケージ管理ツールです。 これは Unity 2018.1 で追加され、Unity Technologies によって開発されたパッケージにのみ使用されていました。 ただし、バージョン 2018.3 以降、カスタム パッケージを追加できるようになりました。

Unity パッケージ マネージャー インターフェイス

パッケージはプロジェクト ソース (Assets ディレクトリ) には残りません。 それらは別のディレクトリにあります %projectFolder%/Library/PackageCache プロジェクトにはまったく影響しません。ソース コード内での唯一の言及はファイル内にあります。 packages/manifest.json.

プロジェクト ファイル システム内のパッケージ

パッケージソース

UPM はいくつかのパッケージ ソースを使用できます。

1. ファイルシステム。

長所：

• 実装のスピード。
• サードパーティのツールは必要ありません。

短所：

• バージョン管理が難しい。
• ファイル システムへの共有アクセスは、プロジェクトで作業する全員に必要です。

2. Git リポジトリ。

長所：

• 必要なのは Git リポジトリだけです。

短所：

• UPM ウィンドウからバージョンを切り替えることはできません。
• すべての Git リポジトリでは機能しません。

3.npmリポジトリ。

長所：

• UPM 機能を完全にサポートし、公式 Unity パッケージの配布に使用されます。

短所：

• 現在、「-preview」を除くパッケージのすべての文字列バージョンは無視されます。

以下では UPM + npm の実装について見ていきます。 このバンドルは、あらゆる種類のリソースを操作し、パッケージのバージョンを管理でき、ネイティブ UPM インターフェイスも完全にサポートしているため便利です。

npmリポジトリとして使用できます ヴェルダッチョ。 詳細があります ドキュメント実行するにはいくつかのコマンドが必要です。

環境設定

まずインストールする必要があります Node.jsの.

パッケージの作成

パッケージを作成するには、ファイルを配置する必要があります package.jsonをこのパッケージの内容が含まれるディレクトリに記述します。 次のことを行う必要があります。

パッケージを作成するプロジェクト ディレクトリに移動します。

npm init コマンドを実行し、ダイアログで必要な値を入力します。 名前には、com.plarium.somepackage など、逆ドメイン形式で名前を指定します。
パッケージ名を簡単に表示するには、displayName プロパティを package.json に追加して値を入力します。

npm は js 指向であるため、このファイルには、Unity が使用しない不要な main プロパティと script プロパティが含まれています。 パッケージの説明が乱雑にならないように、それらを削除することをお勧めします。 ファイルは次のようになります。

1. パッケージを作成するプロジェクト ディレクトリに移動します。
2. npm init コマンドを実行し、ダイアログで必要な値を入力します。 名前には、com.plarium.somepackage など、逆ドメイン形式で名前を指定します。
3. パッケージ名を簡単に表示するには、displayName プロパティを package.json に追加して値を入力します。
4. npm は js 指向であるため、このファイルには、Unity が使用しない不要な main プロパティと script プロパティが含まれています。 パッケージの説明が乱雑にならないように、それらを削除することをお勧めします。 ファイルは次のようになります。

   {
    "name": "com.plarium.somepackage",
    "displayName": "Some Package",
    "version": "1.0.0",
    "description": "Some Package Description",
    "keywords": [
      "Unity",
      "UPM"
    ],
    "author": "AUTHOR",
    "license": "UNLICENSED"
   }

5. Unity を開いて、package.json の .meta ファイルを生成します (Unity では、.meta ファイルのないアセットは表示されません。Unity のパッケージは読み取り専用で開かれます)。

荷物を送る

パッケージを送信するには、次のコマンドを実行する必要があります。 npm publish --registry *адрес до хранилища пакетов*.

Unity Package Manager を介したパッケージのインストールと更新

Unity プロジェクトにパッケージを追加するには、次のことを行う必要があります。

1. ファイルに追加 manifest.json パッケージのソースに関する情報。 これを行うには、プロパティを追加する必要があります scopedRegistries 特定のスコープが検索されるスコープとソース アドレスを示します。

   
   "scopedRegistries": [
      {
        "name": "Main",
        "url": "адрес до хранилища пакетов",
        "scopes": [
          "com.plarium"
        ]
      }
    ]
   

2. Unity に移動し、パッケージ マネージャー ウィンドウを開きます (カスタム パッケージでの作業は、組み込みパッケージでの作業と何ら変わりません)。
3. すべてのパッケージを選択します。
4. 必要なパッケージを見つけて追加します。

ソースの操作とデバッグ

ソースをプロジェクトに接続するには、以下を作成する必要があります。 アセンブリの定義 パッケージ用。

パッケージを使用しても、デバッグ オプションは制限されません。 ただし、Unity でパッケージを操作する場合、パッケージ内でエラーが発生した場合、コンソールでエラーをクリックしても IDE に移動することはできません。 これは、アセンブリ定義を使用するとスクリプトがライブラリに収集され、プロジェクトに組み込まれるため、Unity がスクリプトを別個のファイルとして認識しないためです。 プロジェクトのソースを操作する場合、クリックして IDE を使用できます。

接続されたパッケージを含むプロジェクト内のスクリプト:

作業ブレークポイントを使用してパッケージからスクリプトを作成します。

パッケージの緊急修正

プロジェクトに追加された Unity パッケージは読み取り専用ですが、パッケージ キャッシュ内で編集できます。 これを行うには、次のものが必要です。

1. パッケージキャッシュ内のパッケージに移動します。

   

2. 必要な変更を加えます。
3. ファイル内のバージョンを更新する package.json.
4. 荷物を送る npm publish --registry *адрес до хранилища пакетов*.
5. UPM インターフェイスを介して、パッケージのバージョンを修正されたバージョンに更新します。

パッケージのインポートの競合

パッケージをインポートするときに、次の GUID の競合が発生する可能性があります。

1. パッケージ - パッケージ。 パッケージをインポートするときに、既に追加されたパッケージに同じ GUID を持つアセットが含まれていることが判明した場合、インポートされたパッケージから一致する GUID を持つアセットはプロジェクトに追加されません。
2. パッケージはプロジェクトです。 パッケージをインポートするときに、一致する GUID を持つアセットがプロジェクトに含まれていることが判明した場合、パッケージのアセットはプロジェクトに追加されません。 ただし、それらに依存するアセットは、プロジェクトのアセットの使用を開始します。

プロジェクトからパッケージへのアセットの転送

Unity が開いているときにプロジェクトからパッケージにアセットを転送すると、その機能は保持され、依存アセット内のリンクはパッケージのアセットの使用を開始します。

それが重要だ: アセットをプロジェクトからパッケージにコピーすると、上のセクションで説明した「パッケージ - プロジェクト」の競合が発生します。

紛争に対する考えられる解決策

1. すべてのアセットをインポートするときに独自のアルゴリズムを使用して GUID を再割り当てし、衝突を排除します。
2. すべてのアセットを XNUMX つのプロジェクトに追加し、それらをパッケージに分割します。
3. すべてのアセットの GUID を含むデータベースを作成し、パッケージ送信時に検証を実行します。

まとめ

UPM は Unity で共有リソースを配布するための新しいソリューションであり、既存の方法に代わる価値のあるソリューションとなります。 この記事で説明されている推奨事項は実際の事例に基づいています。 ぜひお役立てください。

出所： habr.com