🥇Unity Package Manager

Unity è una piattaforma che esiste da molto tempo e continua a evolversi. Tuttavia, lavorando su più progetti contemporaneamente, è ancora possibile imbattersi in difficoltà nell'uso di fonti comuni (.cs), librerie (.dll) e altri asset (immagini, suoni, modelli, prefabbricati). In questo articolo parleremo della nostra esperienza nell'affrontare tale problema con una soluzione nativa per Unity.

Metodi di distribuzione delle risorse comuni

Esistono più di un modo per utilizzare risorse comuni per progetti diversi, ma ogni approccio ha i suoi pro e contro.

1. Duplicazione — duplicare ‘a mano’ le risorse tra i progetti.

Pro:

Adatto a tutti i tipi di risorse.
Nessun problema con le dipendenze.
Nessun problema con gli GUID degli asset.

Contro:

Repository enormi.
Nessuna possibilità di versioning.
Difficoltà nel monitorare le modifiche alle risorse comuni.
Difficoltà nell'aggiornare le risorse comuni.

2. Sottoggetti Git — distribuzione di risorse comuni tramite sottoggetti esterni.

Pro:

È possibile lavorare con il codice sorgente.
È possibile distribuire asset.
Nessun problema con le dipendenze.

Contro:

È necessaria una competenza nell’uso di Git.
Git non è molto amichevole con i file binari — sarà necessario attivare LFS.
Definizione degli accessi per i repository.
Difficoltà nell'aumentare o diminuire la versione.
Possibili collisioni di GUID e non c'è comportamento univoco da parte di Unity per risolverle.

3. NuGet — distribuzione di librerie comuni tramite pacchetti NuGet.

Pro:

Facile lavoro con progetti non dipendenti da Unity.
Comodo versioning e risoluzione delle dipendenze.

Contro:

Unity non gestisce i pacchetti NuGet 'di fabbrica' (su GitHub puoi trovare NuGet Package Manager per Unity, che risolve questo, ma ci sono delle particolarità).
Difficoltà nella distribuzione di altri tipi di asset.

4. Unity Package Manager — distribuzione di risorse comuni tramite una soluzione nativa per Unity.

Pro:

Interfaccia nativa per lavorare con i pacchetti.
Protezione contro la sovrascrittura dei file .meta nei pacchetti in caso di conflitti di GUID.
Possibilità di versioning.
Possibilità di distribuzione di tutti i tipi di risorse per Unity.

Contro:

Possono comunque verificarsi conflitti di GUID.
Nessuna documentazione per l'implementazione.

L'ultimo metodo ha più vantaggi che svantaggi. Tuttavia, attualmente non è molto popolare a causa della mancanza di documentazione, quindi ci soffermeremo su di esso in dettaglio.

Unity Package Manager

Unity Package Manager (di seguito UPM) è uno strumento per la gestione dei pacchetti. È stato introdotto in Unity 2018.1 ed è stato utilizzato solo per i pacchetti sviluppati da Unity Technologies. Tuttavia, a partire dalla versione 2018.3 è stata introdotta la possibilità di aggiungere pacchetti personalizzati.

Interfaccia di Unity Package Manager

I pacchetti non entrano nel codice sorgente del progetto (nella directory Assets). Si trovano in una directory separata %projectFolder%/Library/PackageCache e non influenzano in alcun modo il progetto, la loro unica menzione nel codice sorgente è nel file packages/manifest.json.

Pacchetti nel filesystem del progetto

Fonti dei pacchetti

UPM può utilizzare diverse fonti di pacchetti:

1. Filesystem.

Pro:

Velocità di implementazione.
Non richiede strumenti di terze parti.

Contro:

Complesso versionamento.
È necessario un accesso condiviso al filesystem per tutti coloro che lavorano al progetto.

2. Repository Git.

Pro:

È necessario solo un repository Git.

Contro:

Non è possibile passare tra le versioni tramite la finestra UPM.
Non funziona con tutti i repository Git.

3. Repository npm.

Pro:

Supporta pienamente le funzionalità UPM ed è utilizzato per la distribuzione dei pacchetti ufficiali di Unity.

Contro:

Attualmente ignora tutte le versioni stringa dei pacchetti, tranne «-preview».

Di seguito esamineremo l'implementazione di UPM + npm. Questa combinazione è comoda, in quanto consente di lavorare con qualsiasi tipo di risorsa e gestire le versioni dei pacchetti, oltre a supportare completamente l'interfaccia nativa di UPM.

Come repository npm può essere utilizzato Verdaccio. È disponibile una documentazione dettagliata documentazione, e per avviarlo sono necessarie letteralmente solo un paio di comandi.

Configurazione dell'ambiente

Per iniziare, è necessario installare node.js.

Creazione di un pacchetto

Per creare un pacchetto, è necessario posizionare un file package.json, che lo descriverà, nella directory contenente questo pacchetto. Occorre fare quanto segue:

Navigare nella directory del progetto che si desidera trasformare in pacchetto.

Eseguire il comando npm init e durante il dialogo inserire i valori necessari. Per il nome specificare un nome nel formato di dominio inverso, ad esempio com.plarium.somepackage.
Per un'agevole visualizzazione del nome del pacchetto — aggiungere la proprietà displayName in package.json e compilarla.

Poiché npm è orientato a js, nel file ci sono proprietà main e scripts non necessarie, che Unity non utilizza. È meglio rimuoverle per non appesantire la descrizione del pacchetto. Il file dovrebbe apparire circa così:

Navigare nella directory del progetto che si desidera trasformare in pacchetto.
Eseguire il comando npm init e durante il dialogo inserire i valori necessari. Per il nome specificare un nome nel formato di dominio inverso, ad esempio com.plarium.somepackage.
Per un'agevole visualizzazione del nome del pacchetto — aggiungere la proprietà displayName in package.json e compilarla.

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

Apri Unity e genera un file .meta per package.json (Unity non riconosce le risorse senza i file .meta, i pacchetti per Unity si aprono solo in modalità di sola lettura).

Invio del pacchetto

Per inviare il pacchetto è necessario eseguire il comando: npm publish --registry *indirizzo del repository dei pacchetti*.

Installazione e aggiornamento di pacchetti tramite Unity Package Manager

Per aggiungere un pacchetto a un progetto Unity, devi:

Modificare il file manifest.json con informazioni sulla sorgente dei pacchetti. Per fare ciò, devi aggiungere la proprietà scopedRegistries e specificare gli ambiti e l'indirizzo della sorgente da cui saranno cercati gli ambiti specifici.
```
"scopedRegistries": [
   {
     "name": "Main",
     "url": "indirizzo del repository dei pacchetti",
     "scopes": [
       "com.plarium"
     ]
   }
 ]
```
Accedi a Unity e apri la finestra del Package Manager (lavorare con pacchetti personalizzati non si differenzia dal lavorare con quelli integrati).
Seleziona Tutti i pacchetti.
Trova il pacchetto desiderato e aggiungilo.

Lavorare con i sorgenti e il debug

Per collegare i sorgenti al progetto, è necessario creare un Assembly Definition per il pacchetto.

L'uso dei pacchetti non limita le possibilità di debug. Tuttavia, mentre si lavora con i pacchetti in Unity, non è possibile passare all'IDE cliccando su un errore nella console se l'errore si è verificato nel pacchetto. Questo è dovuto al fatto che Unity non riconosce gli script come file separati, poiché quando si utilizza l'Assembly Definition vengono compilati in una libreria e collegati al progetto. Durante il lavoro con i sorgenti dal progetto, il passaggio all'IDE tramite clic è disponibile.

Script nel progetto con pacchetto collegato:

Script dal pacchetto con punto di interruzione funzionante:

Modifiche urgenti ai pacchetti

I pacchetti aggiunti al progetto Unity sono aperti solo in modalità di sola lettura, ma possono essere modificati nella cache dei pacchetti. Per fare ciò, è necessario:

Accedere al pacchetto nella cache dei pacchetti.
Apportare le modifiche necessarie.
Aggiornare la versione nel file package.json.
Inviare il pacchetto npm publish --registry *indirizzo del repository dei pacchetti*.
Aggiornare la versione del pacchetto alla versione corretta tramite l'interfaccia UPM.

Conflitti di importazione dei pacchetti

Durante l'importazione dei pacchetti possono verificarsi i seguenti conflitti di GUID:

Pacchetto – pacchetto. Se durante l'importazione di un pacchetto si scopre che nei pacchetti già aggiunti ci sono risorse con lo stesso GUID, le risorse con GUID corrispondenti del pacchetto importato non saranno aggiunte al progetto.
Il pacchetto è un progetto. Se durante l'importazione del pacchetto viene rilevato che nel progetto ci sono asset con GUID corrispondenti, gli asset del pacchetto non verranno aggiunti al progetto. Tuttavia, gli asset dipendenti inizieranno a utilizzare gli asset dal progetto.

Trasferimento di asset dal progetto al pacchetto

Se trasferisci un asset dal progetto al pacchetto con Unity aperto, la sua funzionalità verrà mantenuta e i collegamenti negli asset dipendenti inizieranno a utilizzare l'asset dal pacchetto.

Importante: durante la copia di un asset dal progetto al pacchetto si verificherà un conflitto "Pacchetto - progetto", come descritto nella sezione sopra.

Possibili soluzioni ai conflitti

Riassegnazione dei GUID secondo algoritmi propri durante l'importazione di tutti gli asset, per escludere colizioni.
Aggiunta di tutti gli asset in un unico progetto con successiva suddivisione in pacchetti.
Creazione di un database contenente i GUID di tutti gli asset e conduzione di validazione durante l'invio dei pacchetti.

Conclusione

UPM è una nuova soluzione per la distribuzione di risorse condivise su Unity, che può diventare una valida alternativa ai metodi esistenti. Le raccomandazioni descritte nell'articolo sono nate da casi reali. Speriamo che ti saranno utili.

Fonte: habr.com