Menedżer pakietów Unity

Unity to platforma, która istnieje już od dłuższego czasu i stale się rozwija. Jednak pracując w nim z kilkoma projektami jednocześnie, nadal możesz napotkać trudności w korzystaniu ze wspólnych źródeł (.cs), bibliotek (.dll) i innych zasobów (obrazów, dźwięków, modeli, prefabrykatów). W tym artykule porozmawiamy o naszych doświadczeniach z natywnym rozwiązaniem takiego problemu dla Unity.

Metody dystrybucji zasobów współdzielonych

Istnieje więcej niż jeden sposób wykorzystania wspólnych zasobów w różnych projektach, ale każde podejście ma swoje zalety i wady.

1. Duplikacja – duplikujemy zasoby pomiędzy projektami „ręcznie”.

Plusy:

• Nadaje się do wszystkich rodzajów zasobów.
• Żadnych problemów z zależnościami.
• Nie ma problemów z identyfikatorami GUID zasobów.

Wady:

• Gigantyczne repozytoria.
• Nie ma możliwości wersjonowania.
• Trudności w śledzeniu zmian w udostępnionych zasobach.
• Trudności w aktualizowaniu udostępnionych zasobów.

2. Podmoduły Gita — dystrybucja współdzielonych zasobów poprzez zewnętrzne podmoduły.

Plusy:

• Można pracować ze źródłami.
• Możesz dystrybuować zasoby.
• Żadnych problemów z zależnościami.

Wady:

• Wymagane doświadczenie w Gicie.
• Git nie jest zbyt przyjazny dla plików binarnych - będziesz musiał podłączyć LFS.
• Kontrola dostępu do repozytoriów.
• Trudności z aktualizacją i degradacją wersji.
• Kolizje GUID są możliwe i nie ma jasnego zachowania ze strony Unity, aby je rozwiązać.

3. NuGet - dystrybucja bibliotek współdzielonych poprzez pakiety NuGet.

Plusy:

• Wygodna praca z projektami niezależnymi od Unity.
• Wygodne wersjonowanie i rozpoznawanie zależności.

Wady:

• Unity nie może współpracować z pakietami NuGet od razu po wyjęciu z pudełka (w GitHub można znaleźć Menedżera pakietów NuGet dla Unity, który rozwiązuje ten problem, ale są pewne niuanse).
• Trudności w dystrybucji innych rodzajów aktywów.

4. Menedżer pakietów Unity - dystrybucja współdzielonych zasobów poprzez natywne rozwiązanie dla Unity.

Plusy:

• Natywny interfejs do pracy z pakietami.
• Ochrona przed nadpisywaniem plików .meta w pakietach z powodu konfliktów GUID.
• Możliwość wersjonowania.
• Możliwość dystrybucji wszystkich typów zasobów dla Unity.

Wady:

• Nadal mogą występować konflikty identyfikatorów GUID.
• Nie ma dokumentacji wykonawczej.

Ta ostatnia metoda ma więcej zalet niż wad. Jednak obecnie nie jest on zbyt popularny ze względu na brak dokumentacji, dlatego omówimy go szczegółowo.

Menedżer pakietów Unity

Unity Package Manager (UPM) to narzędzie do zarządzania pakietami. Został dodany w Unity 2018.1 i był używany tylko w pakietach opracowanych przez Unity Technologies. Jednak począwszy od wersji 2018.3 stało się możliwe dodawanie niestandardowych pakietów.

Interfejs menedżera pakietów Unity

Pakiety nie trafiają do źródeł projektu (katalog Assets). Znajdują się one w osobnym katalogu %projectFolder%/Library/PackageCache i nie wpływają w żaden sposób na projekt, jedyna wzmianka o nich w kodzie źródłowym znajduje się w pliku packages/manifest.json.

Pakiety w systemie plików projektu

Źródła pakietów

Firma UPM może korzystać z kilku źródeł pakietów:

1. System plików.

Plusy:

• Szybkość realizacji.
• Nie wymaga narzędzi innych firm.

Wady:

• Trudność w wersjonowaniu.
• Wszyscy pracujący nad projektem muszą mieć wspólny dostęp do systemu plików.

2. Repozytorium Git.

Plusy:

• Wszystko czego potrzebujesz to repozytorium Git.

Wady:

• Nie można przełączać się między wersjami w oknie UPM.
• Nie działa ze wszystkimi repozytoriami Git.

3. repozytorium npm.

Plusy:

• W pełni obsługuje funkcjonalność UPM i służy do dystrybucji oficjalnych pakietów Unity.

Wady:

• Obecnie ignoruje wszystkie wersje łańcuchowe pakietów z wyjątkiem „-preview”.

Poniżej przyjrzymy się implementacji UPM + npm. Ten pakiet jest wygodny, ponieważ umożliwia pracę z dowolnym typem zasobów i zarządzanie wersjami pakietów, a także w pełni obsługuje natywny interfejs UPM.

Możesz go używać jako repozytorium npm Verdaccio. Jest szczegółowy dokumentacja, a do jego uruchomienia potrzeba tylko kilku poleceń.

Konfigurowanie środowiska

Najpierw musisz zainstalować node.js.

Tworzenie pakietu

Aby utworzyć paczkę należy umieścić plik package.json, który to opisze, do katalogu z zawartością tego pakietu. Musisz wykonać następujące czynności:

Przejdź do katalogu projektu, z którego chcemy utworzyć pakiet.

Uruchom komendę npm init i w oknie dialogowym wprowadź wymagane wartości. W polu nazwa podaj nazwę w odwrotnym formacie domeny, na przykład com.plarium.somepackage.
Aby wygodnie wyświetlić nazwę pakietu, dodaj właściwość displayName do package.json i wypełnij ją.

Ponieważ npm jest zorientowany na js, plik zawiera właściwości main i scripts, których nie potrzebujemy, których Unity nie używa. Lepiej je usunąć, aby nie zaśmiecać opisu pakietu. Plik powinien wyglądać mniej więcej tak:

1. Przejdź do katalogu projektu, z którego chcemy utworzyć pakiet.
2. Uruchom komendę npm init i w oknie dialogowym wprowadź wymagane wartości. W polu nazwa podaj nazwę w odwrotnym formacie domeny, na przykład com.plarium.somepackage.
3. Aby wygodnie wyświetlić nazwę pakietu, dodaj właściwość displayName do package.json i wypełnij ją.
4. Ponieważ npm jest zorientowany na js, plik zawiera właściwości main i scripts, których nie potrzebujemy, których Unity nie używa. Lepiej je usunąć, aby nie zaśmiecać opisu pakietu. Plik powinien wyglądać mniej więcej tak:

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

5. Otwórz Unity i wygeneruj plik .meta dla package.json (Unity nie widzi zasobów bez plików .meta, pakiety dla Unity są otwierane tylko do odczytu).

Wysyłanie paczki

Aby wysłać paczkę należy uruchomić komendę: npm publish --registry *адрес до хранилища пакетов*.

Instalowanie i aktualizowanie pakietów za pomocą Menedżera pakietów Unity

Aby dodać pakiet do projektu Unity, potrzebujesz:

1. Dodaj do pliku manifest.json informacje o źródle pakietów. Aby to zrobić, musisz dodać właściwość scopedRegistries oraz wskazać zakresy i adres źródłowy, w którym będą przeszukiwane określone zakresy.

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

2. Przejdź do Unity i otwórz okno Menedżera pakietów (praca z pakietami niestandardowymi nie różni się od pracy z pakietami wbudowanymi).
3. Wybierz Wszystkie pakiety.
4. Znajdź potrzebny pakiet i dodaj go.

Praca ze źródłami i debugowanie

Aby źródła można było podłączyć do projektu należy je utworzyć Definicja zespołu za paczkę.

Korzystanie z pakietów nie ogranicza opcji debugowania. Jednak podczas pracy z pakietami w Unity nie można przejść do IDE klikając na błąd w konsoli, jeśli błąd wystąpił w pakiecie. Dzieje się tak dlatego, że Unity nie postrzega skryptów jako oddzielnych plików, ponieważ podczas korzystania z definicji zestawu są one gromadzone w bibliotece i włączane do projektu. Podczas pracy ze źródłami z projektu dostępne jest kliknięcie do IDE.

Skrypt w projekcie z podłączonym pakietem:

Skrypt z pakietu z działającym punktem przerwania:

Pilne poprawki do pakietów

Pakiety Unity dodane do projektu są tylko do odczytu, ale można je edytować w pamięci podręcznej pakietów. Aby to zrobić, potrzebujesz:

1. Przejdź do pakietu w pamięci podręcznej pakietów.

   

2. Wprowadź niezbędne zmiany.
3. Zaktualizuj wersję w pliku package.json.
4. Wyślij paczkę npm publish --registry *адрес до хранилища пакетов*.
5. Zaktualizuj wersję pakietu do poprawionej poprzez interfejs UPM.

Konflikty importu pakietów

Podczas importowania pakietów mogą wystąpić następujące konflikty identyfikatorów GUID:

1. Pakiet - pakiet. Jeśli podczas importowania pakietu okaże się, że już dodane pakiety zawierają zasoby o tym samym identyfikatorze GUID, zasoby o pasujących identyfikatorach GUID z zaimportowanego pakietu nie zostaną dodane do projektu.
2. Pakiet to projekt. Jeżeli podczas importu pakietu okaże się, że projekt zawiera zasoby o pasujących identyfikatorach GUID, wówczas zasoby z pakietu nie zostaną dodane do projektu. Jednak zasoby od nich zależne zaczną korzystać z zasobów projektu.

Przenoszenie zasobów z projektu do pakietu

Jeśli przeniesiesz zasób z projektu do pakietu, gdy Unity jest otwarty, jego funkcjonalność zostanie zachowana, a łącza w zasobach zależnych zaczną korzystać z zasobu z pakietu.

To jest ważne: Podczas kopiowania zasobu z projektu do pakietu wystąpi konflikt „Pakiet - Projekt” opisany w powyższej sekcji.

Możliwe rozwiązania konfliktów

1. Ponowne przypisywanie identyfikatorów GUID przy użyciu naszych własnych algorytmów podczas importowania wszystkich zasobów w celu wyeliminowania kolizji.
2. Dodanie wszystkich zasobów do jednego projektu, a następnie podzielenie ich na pakiety.
3. Tworzenie bazy danych zawierającej identyfikatory GUID wszystkich aktywów oraz przeprowadzanie walidacji podczas wysyłania paczek.

wniosek

UPM to nowe rozwiązanie do dystrybucji współdzielonych zasobów w Unity, które może być godną alternatywą dla dotychczasowych metod. Zalecenia opisane w artykule zostały oparte na rzeczywistych przypadkach. Mamy nadzieję, że uznasz je za przydatne.

Źródło: www.habr.com