Unity — o platformă care există de mult timp și se dezvoltă constant. Cu toate acestea, atunci când lucrezi cu mai multe proiecte simultan, poți întâlni dificultăți în utilizarea resurselor comune (.cs), bibliotecilor (.dll) și altor active (imagini, sunete, modele, prefabricate). În acest articol, vom împărtăși experiența noastră cu o soluție nativă pentru această problemă în Unity.

Metode de distribuire a resurselor comune
Există mai multe modalități de a utiliza resurse comune pentru diferite proiecte, dar fiecare abordare are avantajele și dezavantajele sale.
1. Duplicare — duplicăm manual resursele între proiecte.
Pro:
- Se pot folosi pentru toate tipurile de resurse.
- Nu există probleme cu dependențele.
- Nu există probleme cu GUID-urile activelor.
Dezavantaje:
- Repositoare gigantic.
- Nu există posibilitatea de versionare.
- Dificultăți în urmărirea modificărilor în resursele comune.
- Dificultăți în actualizarea resurselor comune.
2. — distribuirea resurselor comune prin submodule externe.
Pro:
- Poți lucra cu sursele.
- Poți distribui active.
- Nu există probleme cu dependențele.
Dezavantaje:
- Necesară abilitatea de a lucra cu Git.
- Git nu funcționează foarte bine cu fișierele binare — va trebui să activezi LFS.
- Delimitarea accesului pentru repositoare.
- Dificultăți la creșterea și scăderea versiunii.
- Posibile coliziuni de GUID-uri și un comportament ambigu în ceea ce privește rezolvarea lor de către Unity.
3. NuGet — distribuirea bibliotecilor comune prin pachete NuGet.
Pro:
- Lucru convenabil cu proiecte independente de Unity.
- Versionare convenabilă și rezolvarea dependențelor.
Dezavantaje:
- Unity nu poate lucra cu pachete NuGet „din cutie” (poți găsi pe GitHub un Manager de Pachete NuGet pentru Unity, care rezolvă acest aspect, dar există unele nuanțe).
- Dificultăți la distribuirea altor tipuri de active.
4. Managerul de Pachete Unity — distribuirea resurselor comune printr-o soluție nativă pentru Unity.
Pro:
- Interfață nativă pentru lucrul cu pachete.
- Protecție împotriva suprascrierii fișierelor .meta ale pachetelor în cazul coliziunilor de GUID-uri.
- Posibilitatea de versionare.
- Posibilitatea de a distribui toate tipurile de resurse pentru Unity.
Dezavantaje:
- Încă pot apărea coliziuni de GUID-uri.
- Lipsa documentației pentru implementare.
Ultima metodă are mai multe avantaje decât dezavantaje. Cu toate acestea, în prezent nu este foarte populară din cauza lipsei documentației, iar noi ne vom concentra asupra ei în detaliu.
Unity Package Manager
Unity Package Manager (denumit în continuare UPM) este un instrument pentru gestionarea pachetelor. A fost adăugat în Unity 2018.1 și a fost folosit doar pentru pachetele dezvoltate de Unity Technologies. Totuși, începând cu versiunea 2018.3, a apărut posibilitatea de a adăuga pachete personalizate.

Interfața Unity Package Manager
Pachetele nu sunt incluse în sursele proiectului (directorul Assets). Ele se află într-un director separat. %projectFolder%/Library/PackageCache și nu afectează în niciun fel proiectul, singura mențiune despre ele în surse fiind în fișierul packages/manifest.json.

Pachetele în sistemul de fișiere al proiectului
Sursele pachetelor
UPM poate folosi mai multe surse de pachete:
1. Sistemul de fișiere.
Pro:
- Viteză de implementare.
- Nu necesită instrumente externe.
Dezavantaje:
- Complexitatea versiilor.
- Este necesar acces comun la sistemul de fișiere pentru toți cei care lucrează la proiect.
2. Repositoriu Git.
Pro:
- Este necesar doar un repozitoriu Git.
Dezavantaje:
- Nu se pot comuta versiunile prin fereastra UPM.
- Nu funcționează cu toate resursele Git.
3. Repositoriu npm.
Pro:
- Suportă complet funcționalitatea UPM și este folosit pentru distribuirea pachetelor oficiale Unity.
Dezavantaje:
- În prezent, ignoră toate versiunile string ale pachetelor, cu excepția „-preview”.
Mai jos vom examina implementarea UPM + npm. Această combinație este convenabilă deoarece permite lucrul cu orice tip de resurse și gestionarea versiunilor pachetelor, precum și suportul complet pentru interfața nativă UPM.
Ca repozitoriu npm poate fi folosit . Există o documentație detaliată pentru acesta, iar pentru a-l rula sunt necesare literalmente câteva comenzi. Configurarea mediului
Pentru început, trebuie să instalați
Crearea pachetului .
Pentru a crea un pachet, trebuie să plasați fișierul
, care va descrie pachetul, în directorul conținând materialele acestui pachet. Urmați pașii următori: package.jsonAccesați directorul proiectului pe care doriți să-l faceți pachet.
Rulați comanda npm init și, în timpul dialogului, introduceți valorile necesare. Pentru name, specificați un nume în formatul domeniului inversat, de exemplu, com.plarium.somepackage.
Pentru o afișare mai convenabilă a numelui pachetului, adăugați proprietatea displayName în package.json și completați-o.
Deoarece npm este orientat spre js, fișierul conține proprietățile main și scripts care nu ne sunt necesare și care nu sunt folosite de Unity. Este mai bine să le ștergem pentru a nu aglomera descrierea pachetului. Fișierul ar trebui să arate aproximativ astfel:
Deoarece npm este orientat pe js, fișierul conține proprietăți inutile pentru noi, cum ar fi main și scripts, pe care Unity nu le utilizează. Cel mai bine este să le eliminăm pentru a nu aglomera descrierea pachetului. Fișierul ar trebui să arate cam așa:
- Rulați comanda npm init și, în timpul dialogului, introduceți valorile necesare. Pentru name, specificați un nume în formatul domeniului inversat, de exemplu, com.plarium.somepackage.
- Pentru o afișare mai convenabilă a numelui pachetului, adăugați proprietatea displayName în package.json și completați-o.
- Deoarece npm este orientat spre js, fișierul conține proprietățile main și scripts care nu ne sunt necesare și care nu sunt folosite de Unity. Este mai bine să le ștergem pentru a nu aglomera descrierea pachetului. Fișierul ar trebui să arate aproximativ astfel:
- Deoarece npm este orientat pe js, fișierul conține proprietăți inutile pentru noi, cum ar fi main și scripts, pe care Unity nu le utilizează. Cel mai bine este să le eliminăm pentru a nu aglomera descrierea pachetului. Fișierul ar trebui să arate cam așa:
{ "name": "com.plarium.somepackage", "displayName": "Some Package", "version": "1.0.0", "description": "Some Package Description", "keywords": [ "Unity", "UPM" ], "author": "AUTHOR", "license": "UNLICENSED" } - Deschide Unity și generează un fișier .meta pentru package.json (Unity nu vede activele fără fișiere .meta, pachetele pentru Unity se deschid doar în mod read-only).
Trimiterea pachetului
Pentru a trimite pachetul, trebuie să executați comanda: npm publish --registry *adresa către depozitul de pachete*.
Instalarea și actualizarea pachetelor prin Unity Package Manager
Pentru a adăuga un pachet în proiectul Unity, trebuie:
- Să adăugați în fișier
manifest.jsoninformațiile despre sursele pachetelor. Pentru aceasta, este necesar să se adauge proprietateascopedRegistriesși să specificați scope-urile și adresa sursei, unde se vor căuta anume scope-uri."scopedRegistries": [ { "name": "Main", "url": "adresa către depozitul de pachete", "scopes": [ "com.plarium" ] } ] - Accesați Unity și deschideți fereastra Package Manager-ului (lucrul cu pachetele personalizate nu diferă de lucrul cu cele încorporate).
- Selectați Toate Pachetele.
- Găsiți pachetul dorit și adăugați-l.

Lucrul cu sursele și depanarea
Pentru ca sursele să fie conectate la proiect, trebuie să creați pentru pachet.
Utilizarea pachetelor nu limitează opțiunile pentru depanare. Totuși, când lucrați cu pachetele în Unity, nu se poate accesa IDE-ul prin clic pe o eroare în consolă, dacă eroarea a apărut în pachet. Aceasta se datorează faptului că Unity nu vede scripturile ca fișiere separate, deoarece atunci când se utilizează Assembly Definition, acestea sunt compilate într-o bibliotecă și adăugate proiectului. Când lucrați cu sursele din proiect, accesul la IDE prin clic este disponibil.
Script în proiect cu pachet conectat:

Script din pachet cu punct de întrerupere activ:

Modificări urgente în pachete
Pachetele Unity adăugate în proiect sunt deschise doar în mod read-only, dar pot fi editate în cache-ul pachetelor. Pentru aceasta, este necesar:
- Să accesați pachetul în cache-ul pachetelor.

- Să faceți modificările necesare.
- Să actualizați versiunea în fișier
package.json. - Să trimiteți pachetul
npm publish --registry *adresa către depozitul de pachete*. - Să actualizați versiunea pachetului la versiunea corectată prin interfața UPM.
Conflicte la importul pachetelor
La importul pachetelor, pot apărea următoarele conflicte de GUID-uri:
- Pachet - pachet. Dacă la importul unui pachet se constată că există active cu același GUID în pachetele deja adăugate, activele cu GUID-uri duplicate din pachetul importat nu vor fi adăugate în proiect.
- Pachetul este un proiect. Dacă, în timpul importului pachetului, se constată că există asset-uri în proiect cu GUID-uri coincidente, atunci asset-urile din pachet nu vor fi adăugate în proiect. Cu toate acestea, asset-urile de care depind vor începe să utilizeze asset-urile din proiect.
Transferul asset-urilor din proiect în pachet
Dacă transferi un asset din proiect în pachet când Unity este deschis, funcționalitatea sa va fi păstrată, iar link-urile din asset-urile dependente vor începe să folosească asset-ul din pachet.
Este important: la copierea asset-ului din proiect în pachet va apărea un conflict „Pachet – proiect”, așa cum este descris în secțiunea de mai sus.
Posibile soluții pentru conflicte
- Reatribuirea GUID-urilor prin algoritmi proprii în timpul importului tuturor asset-urilor, pentru a exclude coliziunile.
- Adăugarea tuturor asset-urilor într-un singur proiect, cu separarea ulterioară în pachete.
- Crearea unei baze de date care să conțină GUID-urile tuturor asset-urilor și efectuarea validării în timpul trimiterii pachetelor.
Concluzie
UPM este o nouă soluție pentru distribuirea resurselor comune în Unity, care ar putea deveni o alternativă demnă pentru metodele existente. Recomandările descrise în articol s-au bazat pe cazuri reale. Sperăm să vă fie utile.
Sursa: habr.com

