Unity Package Manager

Unity არის პლატფორმა, რომელიც საკმაოდ დიდი ხანია არსებობს და მუდმივად ვითარდება. თუმცა, მასში ერთდროულად რამდენიმე პროექტთან მუშაობისას, თქვენ მაინც შეიძლება შეხვდეთ სირთულეებს საერთო წყაროების (.cs), ბიბლიოთეკების (.dll) და სხვა აქტივების (გამოსახულებები, ხმები, მოდელები, პრეფაბების) გამოყენებაში. ამ სტატიაში ვისაუბრებთ ჩვენს გამოცდილებაზე Unity-ისთვის ასეთი პრობლემის მშობლიური გადაწყვეტის შესახებ.

რესურსების განაწილების საერთო მეთოდები

არსებობს ერთზე მეტი გზა სხვადასხვა პროექტებისთვის საერთო რესურსების გამოსაყენებლად, მაგრამ თითოეულ მიდგომას აქვს თავისი დადებითი და უარყოფითი მხარეები.

1. დუბლირება - ჩვენ პროექტებს შორის რესურსების დუბლირებას ვაკეთებთ „ხელით“.

დადებითი:

• შესაფერისია ყველა ტიპის რესურსისთვის.
• არანაირი დამოკიდებულების პრობლემა.
• აქტივების GUID-ებთან დაკავშირებით პრობლემები არ არის.

Cons:

• გიგანტური საცავი.
• ვერსიის გაკეთების შესაძლებლობა არ არსებობს.
• გაზიარებულ რესურსებში ცვლილებების თვალყურის დევნება უჭირს.
• გაზიარებული რესურსების განახლების სირთულე.

2. Git ქვემოდულები — საზიარო რესურსების განაწილება გარე ქვემოდულების მეშვეობით.

დადებითი:

• შეგიძლიათ იმუშაოთ წყაროებთან.
• შეგიძლიათ აქტივების განაწილება.
• არანაირი დამოკიდებულების პრობლემა.

Cons:

• საჭიროა Git-ის გამოცდილება.
• Git არ არის ძალიან მეგობრული ბინარული ფაილებით - მოგიწევთ LFS-ის დაკავშირება.
• წვდომის კონტროლი საცავებისთვის.
• ვერსიების განახლებისა და დაქვეითების სირთულე.
• GUID-ის შეჯახება შესაძლებელია და Unity-ის მხრიდან არ არსებობს მკაფიო ქცევა მათ მოსაგვარებლად.

3. NuGet - საერთო ბიბლიოთეკების განაწილება NuGet პაკეტების მეშვეობით.

დადებითი:

• მოსახერხებელი მუშაობა პროექტებთან, რომლებიც არ არის დამოკიდებული Unity-ზე.
• მოსახერხებელი ვერსია და დამოკიდებულების გარჩევადობა.

Cons:

• Unity ვერ იმუშავებს NuGet პაკეტებთან ერთად (GitHub-ზე შეგიძლიათ იპოვოთ NuGet Package Manager for Unity, რომელიც ასწორებს ამას, მაგრამ არის რამდენიმე ნიუანსი).
• სხვა სახის აქტივების განაწილების სირთულეები.

4. Unity Package Manager - გაზიარებული რესურსების განაწილება Unity-ის მშობლიური გადაწყვეტის მეშვეობით.

დადებითი:

• მშობლიური ინტერფეისი პაკეტებთან მუშაობისთვის.
• GUID კონფლიქტების გამო პაკეტებში .meta ფაილების გადაწერისგან დაცვა.
• ვერსიების შესაძლებლობა.
• Unity-სთვის ყველა სახის რესურსის განაწილების შესაძლებლობა.

Cons:

• GUID კონფლიქტები მაინც შეიძლება მოხდეს.
• განხორციელების დოკუმენტაცია არ არსებობს.

ამ უკანასკნელ მეთოდს უფრო მეტი უპირატესობა აქვს, ვიდრე უარყოფითი მხარეები. თუმცა დოკუმენტაციის უქონლობის გამო ახლა არც თუ ისე პოპულარულია და ამიტომ მასზე დეტალურად ვისაუბრებთ.

Unity Package Manager

Unity Package Manager (UPM) არის პაკეტის მართვის ინსტრუმენტი. იგი დაემატა Unity 2018.1-ში და გამოიყენებოდა მხოლოდ პაკეტებისთვის, რომლებიც შემუშავებული იყო Unity Technologies-ის მიერ. თუმცა, 2018.3 ვერსიიდან დაწყებული, შესაძლებელი გახდა პერსონალური პაკეტების დამატება.

Unity Package Manager ინტერფეისი

პაკეტები არ მთავრდება პროექტის წყაროებში (აქტივების დირექტორიაში). ისინი ცალკე დირექტორიაშია %projectFolder%/Library/PackageCache და არანაირად არ იმოქმედებს პროექტზე, მათი ერთადერთი ნახსენები საწყის კოდში არის ფაილში packages/manifest.json.

პაკეტები პროექტის ფაილურ სისტემაში

პაკეტის წყაროები

UPM-ს შეუძლია გამოიყენოს პაკეტის რამდენიმე წყარო:

1. ფაილური სისტემა.

დადებითი:

• განხორციელების სიჩქარე.
• არ საჭიროებს მესამე მხარის ინსტრუმენტებს.

Cons:

• სირთულე ვერსიაში.
• ფაილურ სისტემაზე ერთობლივი წვდომა საჭიროა ყველასთვის, ვინც მუშაობს პროექტთან.

2. Git საცავი.

დადებითი:

• ყველაფერი რაც თქვენ გჭირდებათ არის Git საცავი.

Cons:

• თქვენ არ შეგიძლიათ გადართოთ ვერსიებს შორის UPM ფანჯრის მეშვეობით.
• არ მუშაობს ყველა Git საცავთან.

3. npm საცავი.

დადებითი:

• სრულად უჭერს მხარს UPM ფუნქციონირებას და გამოიყენება ოფიციალური Unity პაკეტების გასავრცელებლად.

Cons:

• ამჟამად უგულებელყოფს პაკეტების ყველა სტრიქონულ ვერსიას, გარდა "-preview".

ქვემოთ განვიხილავთ UPM + npm განხორციელებას. ეს პაკეტი მოსახერხებელია, რადგან ის საშუალებას გაძლევთ იმუშაოთ ნებისმიერი ტიპის რესურსთან და მართოთ პაკეტის ვერსიები, ასევე სრულად უჭერს მხარს მშობლიურ UPM ინტერფეისს.

შეგიძლიათ გამოიყენოთ როგორც npm საცავი ვერდაჩიო. არსებობს დეტალური დოკუმენტაციადა მის გასაშვებად საჭიროა მხოლოდ რამდენიმე ბრძანება.

გარემოს დაყენება

ჯერ უნდა დააინსტალიროთ node.js.

პაკეტის შექმნა

პაკეტის შესაქმნელად, თქვენ უნდა მოათავსოთ ფაილი package.json, რომელიც აღწერს მას, დირექტორიაში ამ პაკეტის შინაარსით. თქვენ უნდა გააკეთოთ შემდეგი:

გადადით პროექტის დირექტორიაში, რომლის პაკეტიც გვინდა.

გაუშვით npm init ბრძანება და შეიყვანეთ საჭირო მნიშვნელობები დიალოგში. სახელისთვის მიუთითეთ სახელი საპირისპირო დომენის ფორმატში, მაგალითად com.plarium.somepackage.
პაკეტის სახელის მოსახერხებლად საჩვენებლად, დაამატეთ displayName თვისება package.json-ში და შეავსეთ იგი.

ვინაიდან npm არის js-ზე ორიენტირებული, ფაილი შეიცავს ძირითად და სკრიპტების თვისებებს, რომლებიც ჩვენ არ გვჭირდება, რომლებსაც Unity არ იყენებს. უმჯობესია ამოიღოთ ისინი ისე, რომ არ მოხდეს პაკეტის აღწერა. ფაილი ასე უნდა გამოიყურებოდეს:

1. გადადით პროექტის დირექტორიაში, რომლის პაკეტიც გვინდა.
2. გაუშვით npm init ბრძანება და შეიყვანეთ საჭირო მნიშვნელობები დიალოგში. სახელისთვის მიუთითეთ სახელი საპირისპირო დომენის ფორმატში, მაგალითად com.plarium.somepackage.
3. პაკეტის სახელის მოსახერხებლად საჩვენებლად, დაამატეთ displayName თვისება package.json-ში და შეავსეთ იგი.
4. ვინაიდან npm არის js-ზე ორიენტირებული, ფაილი შეიცავს ძირითად და სკრიპტების თვისებებს, რომლებიც ჩვენ არ გვჭირდება, რომლებსაც Unity არ იყენებს. უმჯობესია ამოიღოთ ისინი ისე, რომ არ მოხდეს პაკეტის აღწერა. ფაილი ასე უნდა გამოიყურებოდეს:

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

5. გახსენით Unity და შექმენით .meta ფაილი package.json-ისთვის (Unity ვერ ხედავს აქტივებს .meta ფაილების გარეშე, პაკეტები Unity-სთვის იხსნება მხოლოდ წაკითხვად).

პაკეტის გაგზავნა

პაკეტის გასაგზავნად, თქვენ უნდა შეასრულოთ ბრძანება: npm publish --registry *адрес до хранилища пакетов*.

პაკეტების ინსტალაცია და განახლება Unity Package Manager-ის მეშვეობით

Unity პროექტში პაკეტის დასამატებლად გჭირდებათ:

1. ფაილში დამატება manifest.json ინფორმაცია პაკეტების წყაროს შესახებ. ამისათვის თქვენ უნდა დაამატოთ ქონება scopedRegistries და მიუთითეთ სფეროები და წყაროს მისამართი, სადაც მოხდება კონკრეტული სკოპების ძიება.

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

2. გადადით Unity-ზე და გახსენით Package Manager-ის ფანჯარა (მორგებულ პაკეტებთან მუშაობა არაფრით განსხვავდება ჩაშენებული პაკეტებით მუშაობისგან).
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. ყველა აქტივის დამატება ერთ პროექტში და შემდეგ მათი დაყოფა პაკეტებად.
3. მონაცემთა ბაზის შექმნა, რომელიც შეიცავს ყველა აქტივის GUID-ებს და ვალიდაციის ჩატარებას პაკეტების გაგზავნისას.

დასკვნა

UPM არის ახალი გადაწყვეტა Unity-ში საერთო რესურსების განაწილებისთვის, რომელიც შეიძლება იყოს არსებული მეთოდების ღირსეული ალტერნატივა. სტატიაში აღწერილი რეკომენდაციები ეფუძნებოდა რეალურ შემთხვევებს. ვიმედოვნებთ, რომ ისინი სასარგებლო იქნებით.

წყარო: www.habr.com