Unity — egy platform, amely már régóta létezik és folyamatosan fejlődik. Azonban, ha több projekten dolgozunk egyszerre, még mindig találkozhatunk nehézségekkel a közös forráskódok (.cs), könyvtárak (.dll) és egyéb eszközök (képek, hangok, modellek, prefabok) használatában. Ebben a cikkben elmondjuk tapasztalatainkat a Unity-hez kapcsolódó ilyen probléma natív megoldásával kapcsolatban.

Közös erőforrások terjesztési módszerei
Több módja is van a közös erőforrások felhasználásának különböző projektekhez, de mindegyik megközelítésnek megvannak a maga előnyei és hátrányai.
1. Duplicáció — „kézzel” másoljuk az erőforrásokat a projektek között.
Előnyök:
- Megfelel mindenféle erőforrás számára.
- Nincs probléma a függőségekkel.
- Nincs probléma az eszközök GUID-jaival.
Hátrányok:
- Óriási tárolók.
- Nincs lehetőség verziókezelésre.
- Nehézségek a közös erőforrások változásainak nyomon követésében.
- Nehézségek a közös erőforrások frissítésében.
2. — közös erőforrások terjesztése külső almódulokon keresztül.
Előnyök:
- Lehetőség van a forráskódokkal való munkára.
- Lehetőség van az eszközök terjesztésére.
- Nincs probléma a függőségekkel.
Hátrányok:
- Szükséges a Git használatának ismerete.
- A Git nem túl barátságos a bináris fájlokkal — be kell kapcsolni az LFS-t.
- Hozzáférés-vezérlés a tárolók számára.
- Nehézségek a verziók növelésénél és csökkentésénél.
- GUID ütközések lehetségesek, és a Unity nem reagál egyértelműen az ilyen helyzetekben.
3. NuGet — közös könyvtárak terjesztése NuGet-csomagokon keresztül.
Előnyök:
- Kényelmes munka az Unitytól független projektekkel.
- Kényelmes verziókezelés és függőségek kezelése.
Hátrányok:
- A Unity nem tud dolgozni a NuGet-csomagokkal „alapból” (GitHub-on megtalálható a NuGet Package Manager for Unity, amely ezt javítja, de vannak különbségek).
- Nehézségek a többi típusú eszköz terjesztésénél.
4. Unity Package Manager — közös erőforrások terjesztése a Unity natív megoldásán keresztül.
Előnyök:
- Natív felület a csomagok kezelésére.
- Védelem a .meta fájlok felülírásával szemben a GUID ütközések esetén.
- Lehetőség verziókezelésre.
- Lehetőség minden típusú erőforrás Unityhez való terjesztésére.
Hátrányok:
- Még mindig előfordulhatnak GUID ütközések.
- Nincs dokumentáció a megvalósításhoz.
Az utolsó módszernek több előnye van, mint hátránya. Azonban jelenleg nem túl népszerű a dokumentáció hiánya miatt, ezért részletesebben foglalkozunk vele.
Unity Package Manager
Az Unity Package Manager (a továbbiakban UPM) egy csomagkezelő eszköz. 2018.1-es verzióban került bevezetésre, és csak a Unity Technologies által fejlesztett csomagokhoz használták. Azonban a 2018.3-as verziótól kezdve lehetőség nyílt egyedi csomagok hozzáadására.

Az Unity Package Manager felülete
A csomagok nem kerülnek be a projekt forrásaiba (az Assets mappába). Egy külön mappában találhatók %projectFolder%/Library/PackageCache és semmilyen hatással sincsenek a projektre, az egyetlen említésük a forrásokban a packages/manifest.json.

Csomagok a projekt fájlrendszerében
Csomagforrások
Az UPM több csomagforrást is használhat:
1. Fájl rendszer.
Előnyök:
- A megvalósítás gyorsasága.
- Nem igényel külső eszközöket.
Hátrányok:
- A verziókezelés összetettsége.
- Szükséges a fájlrendszerhez való közös hozzáférés mindenkinek, aki a projekten dolgozik.
2. Git-repozitórium.
Előnyök:
- Csak Git-repozitóriumra van szükség.
Hátrányok:
- Nem lehet verziók között váltani az UPM ablakon keresztül.
- Nem működik minden Git-repozitóriummal.
3. npm-repozitórium.
Előnyök:
- Teljes mértékben támogatja az UPM funkcióit, és az Unity hivatalos csomagjainak terjesztésére használják.
Hátrányok:
- Jelenleg figyelmen kívül hagyja az összes csomag szöveges verzióját, kivéve a „-preview”-t.
Alább az UPM + npm megvalósítását tekintjük át. Ez a kombináció kényelmes, mivel lehetővé teszi bármilyen típusú erőforrással való munkát és a csomagverziók kezelését, valamint teljes mértékben támogatja az UPM natív felületét.
npm-repozitóriumként használható . Részletes útmutató található hozzá, és a futtatásához csak pár parancsra van szükség. A környezet beállítása
Első lépésként telepíteni kell
Csomag létrehozása .
Csomag létrehozásához el kell helyezni egy fájlt
, amely leírja majd a csomagot, a csomag tartalmát tartalmazó mappában. A következő lépéseket kell követni: package.jsonMenjen a projekt mappájába, amelyet csomaggá szeretne tenni.
Futtassa a npm init parancsot, és a párbeszéd során adja meg a szükséges értékeket. A name mezőbe a domain visszafelé írt neve formájában kell megadni, például com.plarium.somepackage.
A csomagnév kényelmes megjelenítése érdekében adja hozzá a displayName tulajdonságot a package.json fájlhoz és töltse ki azt.
Mivel az npm js-orientált, a fájlban vannak számunkra felesleges main és scripts tulajdonságok, amelyeket az Unity nem használ. Jobb azokat eltávolítani, hogy ne zavarják a csomag leírását. A fájlnak körülbelül így kell kinéznie:
Mivel az npm js-centrikus, a fájl tartalmaz olyan tulajdonságokat, mint a main és scripts, amelyeket a Unity nem használ. Jobb ezeket törölni, hogy ne szennyezzük a csomag leírását. A fájlnak körülbelül így kell kinéznie:
- Futtassa a npm init parancsot, és a párbeszéd során adja meg a szükséges értékeket. A name mezőbe a domain visszafelé írt neve formájában kell megadni, például com.plarium.somepackage.
- A csomagnév kényelmes megjelenítése érdekében adja hozzá a displayName tulajdonságot a package.json fájlhoz és töltse ki azt.
- Mivel az npm js-orientált, a fájlban vannak számunkra felesleges main és scripts tulajdonságok, amelyeket az Unity nem használ. Jobb azokat eltávolítani, hogy ne zavarják a csomag leírását. A fájlnak körülbelül így kell kinéznie:
- Mivel az npm js-centrikus, a fájl tartalmaz olyan tulajdonságokat, mint a main és scripts, amelyeket a Unity nem használ. Jobb ezeket törölni, hogy ne szennyezzük a csomag leírását. A fájlnak körülbelül így kell kinéznie:
{ "name": "com.plarium.somepackage", "displayName": "Some Package", "version": "1.0.0", "description": "Some Package Description", "keywords": [ "Unity", "UPM" ], "author": "AUTHOR", "license": "UNLICENSED" } - Nyissa meg a Unity-t, és generáljon .meta fájlt a package.json-hoz (a Unity nem látja az eszközöket .meta fájlok nélkül, a Unity számára készült csomagok csak olvashatók).
Csomag küldése
A csomag küldéséhez a következő parancsot kell végrehajtani: npm publish --registry *a csomagtároló címe*.
Csomagok telepítése és frissítése a Unity Package Manageren keresztül
A csomag hozzáadásához Unity-projekthez:
- Szerkessze a fájlt
manifest.jsona csomagforrás információját. Ehhez hozzá kell adnia a következő tulajdonságot:scopedRegistriesés meg kell adni a kiterjedéseket és a forrást, ahonnan az adott kiterjesztéseket keresni kell."scopedRegistries": [ { "name": "Main", "url": "a csomagtároló címe", "scopes": [ "com.plarium" ] } ] - Lépjen a Unity-be, és nyissa meg a csomagkezelő ablakot (a testreszabott csomagokkal való munka nem különbözik a beépített csomagokkal való munkától).
- Válassza az Összes csomagot.
- Keresse meg a szükséges csomagot, és adja hozzá.

Források kezelése és hibakeresés
Ahhoz, hogy a források csatlakozzanak a projekthez, létre kell hozni egy a csomaghoz.
A csomagok használata nem korlátozza a hibakeresési lehetőségeket. Azonban a Unity csomagokkal való munka közben nem lehet IDE-be lépni, ha a hiba a csomagban történt. Ennek az az oka, hogy a Unity nem látja a szkripteket külön fájlokként, mivel az Assembly Definition használatával a szkriptek egy könyvtárba kerülnek, és a projekthez csatlakoznak. A forrásokkal végzett munkánál IDE-be léphetünk a kattintással.
A csomaghoz csatlakoztatott projekt szkriptje:

A csomagból származó szkript működő törésponttal:

Sürgős javítások végrehajtása a csomagokban
A projektbe hozzáadott Unity csomagok csak olvashatók, de a csomagok cache-ében szerkeszthetők. Ehhez a következőre van szükség:
- Lépjen a csomaghoz a csomagok cache-ében.

- Végezze el a szükséges módosításokat.
- Frissítse a verziót a fájlban
package.json. - Küldje el a csomagot
npm publish --registry *a csomagtároló címe*. - Frissítse a csomag verzióját kijavított állapotra az UPM felületen.
Csomagok importálási konfliktusai
Csomagok importálásakor a következő GUID ütközések fordulhatnak elő:
- Csomag — csomag. Ha a csomag importálása során kiderül, hogy a már hozzáadott csomagok között vannak ilyen GUID-del rendelkező eszközök, az importált csomagból a megegyező GUID-del rendelkező eszközök nem kerülnek hozzáadásra a projekthez.
- A csomag egy projekt. Ha a csomag importálása során kiderül, hogy a projektben vannak egyező GUID-jú eszközök, akkor a csomag eszközei nem fognak hozzáadódni a projekthez. Azonban azok az eszközök, amelyek függnek tőlük, elkezdik használni a projektben található eszközöket.
Eszközök átvitele a projektből a csomagba
Ha eszközt viszünk át a projektből a csomagba nyitott Unity-ben, akkor annak funkciói megmaradnak, a függő eszközök pedig a csomagból származó eszközöket fogják használni.
Fontos: amikor eszközt másolunk a projektből a csomagba, konfliktus lép fel a "Csomag - Projekt" (Package - Project), amelyet a fenti szakaszban írtunk le.
Lehetséges konfliktusmegoldások
- A GUID-ok saját algoritmusokkal történő újraallokálása az összes eszköz importálásakor, hogy elkerüljük a ütközéseket.
- Minden eszköz egy projekthez való hozzáadása, majd azok csomagokra bontása.
- Olyan adatbázis létrehozása, amely tartalmazza az összes eszköz GUID-ját, és érvényesítés végrehajtása a csomagok benyújtásakor.
Zárás
UPM - az új megoldás a közös erőforrások elosztására a Unity-ben, amely méltó alternatíva lehet a meglévő módszerekkel szemben. A cikkben leírt ajánlások valós esetek alapján születtek. Reméljük, hasznosak lesznek az Ön számára.
Forrás: habr.com

