एकता पैकेज प्रबंधक

यूनिटी एक ऐसा मंच है जो काफी समय से मौजूद है और लगातार विकसित हो रहा है। हालाँकि, एक ही समय में कई परियोजनाओं के साथ इसमें काम करते समय, आपको अभी भी सामान्य स्रोतों (.cs), लाइब्रेरीज़ (.dll) और अन्य संपत्तियों (चित्र, ध्वनियाँ, मॉडल, प्रीफ़ैब्स) का उपयोग करने में कठिनाइयों का सामना करना पड़ सकता है। इस लेख में हम यूनिटी के लिए ऐसी समस्या के मूल समाधान के अपने अनुभव के बारे में बात करेंगे।

साझा संसाधन वितरण के तरीके

विभिन्न परियोजनाओं के लिए साझा संसाधनों का उपयोग करने के एक से अधिक तरीके हैं, लेकिन प्रत्येक दृष्टिकोण के अपने फायदे और नुकसान हैं।

1. दोहराव - हम "हाथ से" परियोजनाओं के बीच संसाधनों की नकल करते हैं।

पेशेवरों:

• सभी प्रकार के संसाधनों के लिए उपयुक्त.
• कोई निर्भरता समस्या नहीं.
• एसेट GUID के साथ कोई समस्या नहीं है.

विपक्ष:

• विशाल भंडार.
• वर्जनिंग की कोई संभावना नहीं है.
• साझा संसाधनों में परिवर्तनों को ट्रैक करने में कठिनाई।
• साझा संसाधनों को अद्यतन करने में कठिनाई.

2. गिट सबमॉड्यूल - बाहरी सबमॉड्यूल के माध्यम से साझा संसाधनों का वितरण।

पेशेवरों:

• आप सूत्रों के साथ काम कर सकते हैं.
• आप संपत्ति वितरित कर सकते हैं.
• कोई निर्भरता समस्या नहीं.

विपक्ष:

• गिट अनुभव आवश्यक है.
• Git बाइनरी फ़ाइलों के साथ बहुत अनुकूल नहीं है - आपको LFS को कनेक्ट करना होगा।
• रिपोजिटरी के लिए अभिगम नियंत्रण.
• संस्करणों को अपग्रेड और डाउनग्रेड करने में कठिनाई।
• GUID टकराव संभव हैं और उन्हें हल करने के लिए यूनिटी की ओर से कोई स्पष्ट व्यवहार नहीं है।

3. NuGet - NuGet पैकेज के माध्यम से साझा पुस्तकालयों का वितरण।

पेशेवरों:

• उन परियोजनाओं के साथ सुविधाजनक कार्य जो एकता पर निर्भर नहीं हैं।
• सुविधाजनक संस्करण और निर्भरता समाधान।

विपक्ष:

• यूनिटी बॉक्स से बाहर NuGet पैकेज के साथ काम नहीं कर सकती (GitHub पर आप Unity के लिए NuGet पैकेज मैनेजर पा सकते हैं, जो इसे ठीक करता है, लेकिन कुछ बारीकियाँ हैं)।
• अन्य प्रकार की परिसंपत्तियों के वितरण में कठिनाइयाँ।

4. यूनिटी पैकेज मैनेजर - यूनिटी के लिए मूल समाधान के माध्यम से साझा संसाधनों का वितरण।

पेशेवरों:

• पैकेजों के साथ काम करने के लिए मूल इंटरफ़ेस।
• GUID विरोधों के कारण पैकेजों में .meta फ़ाइलों को ओवरराइट करने से सुरक्षा।
• संस्करणीकरण की संभावना.
• एकता के लिए सभी प्रकार के संसाधनों को वितरित करने की क्षमता।

विपक्ष:

• GUID विरोध अभी भी हो सकता है.
• कार्यान्वयन के लिए कोई दस्तावेज नहीं है.

बाद वाली विधि के नुकसान से अधिक फायदे हैं। हालाँकि, दस्तावेज़ीकरण की कमी के कारण यह अब बहुत लोकप्रिय नहीं है, और इसलिए हम इस पर विस्तार से ध्यान देंगे।

एकता पैकेज प्रबंधक

यूनिटी पैकेज मैनेजर (यूपीएम) एक पैकेज प्रबंधन उपकरण है। इसे यूनिटी 2018.1 में जोड़ा गया था और इसका उपयोग केवल उन पैकेजों के लिए किया गया था जो यूनिटी टेक्नोलॉजीज द्वारा विकसित किए गए थे। हालाँकि, संस्करण 2018.3 से शुरू होकर, कस्टम पैकेज जोड़ना संभव हो गया।

यूनिटी पैकेज मैनेजर इंटरफ़ेस

पैकेज प्रोजेक्ट स्रोतों (संपत्ति निर्देशिका) में समाप्त नहीं होते हैं। वे एक अलग निर्देशिका में हैं %projectFolder%/Library/PackageCache और किसी भी तरह से परियोजना को प्रभावित नहीं करते हैं, स्रोत कोड में उनका एकमात्र उल्लेख फ़ाइल में है packages/manifest.json.

प्रोजेक्ट फ़ाइल सिस्टम में पैकेज

पैकेज स्रोत

यूपीएम कई पैकेज स्रोतों का उपयोग कर सकता है:

1. फ़ाइल सिस्टम.

पेशेवरों:

• कार्यान्वयन की गति.
• तीसरे पक्ष के टूल की आवश्यकता नहीं है.

विपक्ष:

• संस्करण बनाने में कठिनाई.
• प्रोजेक्ट के साथ काम करने वाले प्रत्येक व्यक्ति के लिए फ़ाइल सिस्टम तक साझा पहुंच आवश्यक है।

2. गिट भंडार।

पेशेवरों:

• आपको बस एक Git रिपॉजिटरी की आवश्यकता है।

विपक्ष:

• आप UPM विंडो के माध्यम से संस्करणों के बीच स्विच नहीं कर सकते।
• सभी Git रिपॉजिटरी के साथ काम नहीं करता.

3. एनपीएम रिपॉजिटरी।

पेशेवरों:

• पूरी तरह से यूपीएम कार्यक्षमता का समर्थन करता है और इसका उपयोग आधिकारिक यूनिटी पैकेज वितरित करने के लिए किया जाता है।

विपक्ष:

• वर्तमान में "-पूर्वावलोकन" को छोड़कर पैकेज के सभी स्ट्रिंग संस्करणों को अनदेखा करता है।

नीचे हम यूपीएम + एनपीएम कार्यान्वयन को देखेंगे। यह बंडल सुविधाजनक है क्योंकि यह आपको किसी भी प्रकार के संसाधनों के साथ काम करने और पैकेज संस्करणों को प्रबंधित करने की अनुमति देता है, और मूल यूपीएम इंटरफ़ेस का भी पूरी तरह से समर्थन करता है।

आप इसे एनपीएम रिपॉजिटरी के रूप में उपयोग कर सकते हैं वर्दाशियो. एक विस्तृत है प्रलेखन, और इसे चलाने के लिए बस कुछ कमांड की आवश्यकता होती है।

पर्यावरण सेटअप

सबसे पहले आपको इंस्टॉल करना होगा Node.js.

एक पैकेज बनाना

पैकेज बनाने के लिए, आपको फ़ाइल डालनी होगी package.json, जो इस पैकेज की सामग्री वाली निर्देशिका में इसका वर्णन करेगा। आपको निम्नलिखित कार्य करने होंगे:

उस प्रोजेक्ट निर्देशिका पर जाएँ जिसका हम पैकेज बनाना चाहते हैं।

npm init कमांड चलाएँ और संवाद के दौरान आवश्यक मान दर्ज करें। नाम के लिए, रिवर्स डोमेन प्रारूप में नाम निर्दिष्ट करें, उदाहरण के लिए com.plarium.somepackage।
पैकेज नाम को आसानी से प्रदर्शित करने के लिए, package.json में डिस्प्लेनेम प्रॉपर्टी जोड़ें और इसे भरें।

चूंकि एनपीएम जेएस-उन्मुख है, फ़ाइल में मुख्य और स्क्रिप्ट गुण शामिल हैं जिनकी हमें आवश्यकता नहीं है, जिनका यूनिटी उपयोग नहीं करती है। पैकेज विवरण को अव्यवस्थित न करने के लिए उन्हें हटा देना बेहतर है। फ़ाइल कुछ इस तरह दिखनी चाहिए:

1. उस प्रोजेक्ट निर्देशिका पर जाएँ जिसका हम पैकेज बनाना चाहते हैं।
2. npm init कमांड चलाएँ और संवाद के दौरान आवश्यक मान दर्ज करें। नाम के लिए, रिवर्स डोमेन प्रारूप में नाम निर्दिष्ट करें, उदाहरण के लिए com.plarium.somepackage।
3. पैकेज नाम को आसानी से प्रदर्शित करने के लिए, package.json में डिस्प्लेनेम प्रॉपर्टी जोड़ें और इसे भरें।
4. चूंकि एनपीएम जेएस-उन्मुख है, फ़ाइल में मुख्य और स्क्रिप्ट गुण शामिल हैं जिनकी हमें आवश्यकता नहीं है, जिनका यूनिटी उपयोग नहीं करती है। पैकेज विवरण को अव्यवस्थित न करने के लिए उन्हें हटा देना बेहतर है। फ़ाइल कुछ इस तरह दिखनी चाहिए:

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

5. यूनिटी खोलें और package.json के लिए एक .meta फ़ाइल जेनरेट करें (यूनिटी .meta फ़ाइलों के बिना संपत्ति नहीं देखती है, यूनिटी के लिए पैकेज केवल पढ़ने के लिए खोले जाते हैं)।

एक पैकेज भेजा जा रहा है

पैकेज भेजने के लिए आपको कमांड चलाने की आवश्यकता है: npm publish --registry *адрес до хранилища пакетов*.

यूनिटी पैकेज मैनेजर के माध्यम से पैकेजों को स्थापित और अद्यतन करना

यूनिटी प्रोजेक्ट में एक पैकेज जोड़ने के लिए, आपको चाहिए:

1. फ़ाइल में जोड़ें manifest.json पैकेजों के स्रोत के बारे में जानकारी. ऐसा करने के लिए आपको संपत्ति जोड़नी होगी scopedRegistries और उन क्षेत्रों और स्रोत पते को इंगित करें जहां विशिष्ट क्षेत्रों की खोज की जाएगी।

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

2. यूनिटी पर जाएं और पैकेज मैनेजर विंडो खोलें (कस्टम पैकेज के साथ काम करना बिल्ट-इन पैकेज के साथ काम करने से अलग नहीं है)।
3. सभी पैकेज चुनें.
4. आपको जिस पैकेज की आवश्यकता है उसे ढूंढें और उसे जोड़ें।

स्रोतों और डिबगिंग के साथ कार्य करना

स्रोतों को प्रोजेक्ट से जोड़ने के लिए, आपको बनाने की आवश्यकता है विधानसभा परिभाषा पैकेज के लिए.

पैकेजों का उपयोग आपके डिबगिंग विकल्पों को सीमित नहीं करता है। हालाँकि, यूनिटी में पैकेज के साथ काम करते समय, यदि पैकेज में त्रुटि हुई तो आप कंसोल में त्रुटि पर क्लिक करके आईडीई पर नहीं जा सकते। यह इस तथ्य के कारण है कि यूनिटी स्क्रिप्ट को अलग फ़ाइलों के रूप में नहीं देखती है, क्योंकि असेंबली परिभाषा का उपयोग करते समय उन्हें लाइब्रेरी में एकत्र किया जाता है और प्रोजेक्ट में शामिल किया जाता है। किसी प्रोजेक्ट के स्रोतों के साथ काम करते समय, आईडीई पर क्लिक करना उपलब्ध होता है।

कनेक्टेड पैकेज वाले प्रोजेक्ट में स्क्रिप्ट:

कार्यशील ब्रेकप्वाइंट के साथ पैकेज से स्क्रिप्ट:

पैकेजों में तत्काल सुधार

किसी प्रोजेक्ट में जोड़े गए यूनिटी पैकेज केवल पढ़ने के लिए होते हैं, लेकिन पैकेज कैश में संपादित किए जा सकते हैं। ऐसा करने के लिए आपको चाहिए:

1. पैकेज कैश में पैकेज पर जाएं।

   

2. आवश्यक परिवर्तन करें.
3. फ़ाइल में संस्करण अद्यतन करें package.json.
4. पैकेज भेजें npm publish --registry *адрес до хранилища пакетов*.
5. यूपीएम इंटरफ़ेस के माध्यम से पैकेज संस्करण को सही संस्करण में अपडेट करें।

पैकेज आयात विवाद

पैकेज आयात करते समय निम्नलिखित GUID विरोध उत्पन्न हो सकते हैं:

1. पैकेज - पैकेज. यदि, किसी पैकेज को आयात करते समय, यह पता चलता है कि पहले से जोड़े गए पैकेजों में समान GUID वाली संपत्तियां हैं, तो आयातित पैकेज से मेल खाने वाली GUID वाली संपत्तियां प्रोजेक्ट में नहीं जोड़ी जाएंगी।
2. पैकेज एक प्रोजेक्ट है. यदि, किसी पैकेज को आयात करते समय, यह पता चलता है कि प्रोजेक्ट में मेल खाने वाले GUID वाली संपत्तियां हैं, तो पैकेज की संपत्तियां प्रोजेक्ट में नहीं जोड़ी जाएंगी। हालाँकि, जो परिसंपत्तियाँ उन पर निर्भर हैं वे परियोजना से परिसंपत्तियों का उपयोग करना शुरू कर देंगी।

किसी प्रोजेक्ट से पैकेज में संपत्ति स्थानांतरित करना

यदि आप यूनिटी के खुले रहने के दौरान किसी प्रोजेक्ट से किसी परिसंपत्ति को पैकेज में स्थानांतरित करते हैं, तो इसकी कार्यक्षमता संरक्षित रहेगी, और आश्रित परिसंपत्तियों के लिंक पैकेज से परिसंपत्ति का उपयोग करना शुरू कर देंगे।

यह महत्वपूर्ण है: किसी परिसंपत्ति को किसी प्रोजेक्ट से पैकेज में कॉपी करते समय, उपरोक्त अनुभाग में वर्णित "पैकेज - प्रोजेक्ट" विरोध उत्पन्न होगा।

संघर्षों के संभावित समाधान

1. टकराव को खत्म करने के लिए सभी परिसंपत्तियों को आयात करते समय हमारे अपने एल्गोरिदम का उपयोग करके GUID को पुन: असाइन करना।
2. सभी परिसंपत्तियों को एक प्रोजेक्ट में जोड़ना और फिर उन्हें पैकेजों में विभाजित करना।
3. सभी परिसंपत्तियों के GUID युक्त एक डेटाबेस बनाना और पैकेज भेजते समय सत्यापन करना।

निष्कर्ष

यूपीएम यूनिटी में साझा संसाधनों को वितरित करने के लिए एक नया समाधान है, जो मौजूदा तरीकों का एक योग्य विकल्प हो सकता है। लेख में वर्णित अनुशंसाएँ वास्तविक मामलों पर आधारित थीं। हमें उम्मीद है कि आप उन्हें उपयोगी पायेंगे।

स्रोत: www.habr.com