Unity3D में भवन निर्माण को सरल बनाना

हाल ही में, मुझे एहसास हुआ कि तैयार परियोजनाओं की बढ़ती संख्या के साथ, अधिक से अधिक समय भवन निर्माण के लिए समर्पित होना होगा। यह कहना नहीं है कि एकता किसी तरह इस प्रक्रिया को बहुत जटिल करती है, लेकिन यह निश्चित रूप से इसे सरल नहीं बनाती है। खासकर जब प्रत्येक प्रोजेक्ट को कई प्लेटफार्मों और यहां तक ​​कि अलग-अलग कॉन्फ़िगरेशन में इकट्ठा किया जाता है। सिद्धांत रूप में, समस्या नई नहीं है और इसके कई अलग-अलग समाधान हैं। लेकिन कई कारणों से, मैं अपना स्वयं का प्लगइन लिखने पर बस गया।

यह कुछ इस तरह दिखता है:

और क्यों, क्यों, कहां से प्राप्त करें और इसका उपयोग कैसे करें, मैं नीचे बताऊंगा।

दर्द

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

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

बाद में, आपको पता चलेगा कि एक अलग कोरियाई संस्करण की योजना बनाई गई है, वहां सब कुछ अलग होना चाहिए, और आप यहाँ #ifdef के बिना नहीं कर सकते।

और फिर वे आपको बताते हैं कि गेम को मोबाइल प्लेटफॉर्म, प्लेस्टेशन, हिस्पैनिक और वॉशिंग मशीन पर लॉन्च करने की आवश्यकता है।

परिणामस्वरूप, समय के साथ प्रत्येक नए निर्माण की तैयारी इस के समान हो जाती है:

रीडिंग की जांच करें, बाईं ओर टॉगल स्विच चालू करें, दाएं तरफ लीवर चालू करें, लाल वाल्व को कस लें। भ्रमित मत करो और मत भूलना।

सबसे पहले, यह अभी भी कुछ भी नहीं हो सकता है, लेकिन यह जल्दी से थक जाता है। और एक या दो महीने में सभी जोड़तोड़ याद रखें।

आपके पास क्या विकल्प हैं?

इंटरनेट और लोक ज्ञान हमें निम्नलिखित प्रदान करते हैं:

• परियोजना स्तर पर एक समस्या का समाधान करें। इस दृष्टिकोण के कार्यान्वयन अलग-अलग हो सकते हैं: सामान्य कोड और संपत्ति के साथ अलग-अलग परियोजनाएं, एक गिट में सबमॉड्यूल, एक गिट में शाखाएं और इसी तरह।
  मैं इस पर गंभीरता से विचार नहीं कर सकता। आइकन को बदलने के लिए एक बगीचे को बाड़ लगाने के लिए, और फिर इसका समर्थन भी करें। काफी शौकिया। लेकिन उसने इसे अपनी आंखों से देखा, इसलिए वह मदद नहीं कर सका लेकिन इसका उल्लेख किया।
• बैश / बैट / अजगर / ... स्क्रिप्ट।
  पहले से ही गर्म। लेकिन इसके लिए अतिरिक्त ज्ञान की आवश्यकता होती है और इसे क्रॉस-प्लेटफॉर्म कहना मुश्किल है (अक्सर टीम का हिस्सा makos के तहत विकसित होता है, विंडोज के तहत हिस्सा)। फिर से, स्क्रिप्ट का समर्थन करने की आवश्यकता है, और यह हमेशा समय नहीं होता है।
• यूनिट में ही एडिटर स्क्रिप्ट।
  बहुत गर्म। हम परियोजना को इकाई के अंदर घुमाते हैं जैसा हम चाहते हैं। और यदि आप स्थैतिक विधि और BuildPipeline का उपयोग करते हैं, तो आप CI को कॉन्फ़िगर कर सकते हैं। एक नियम के रूप में, एकता और CI के लेख इस का वर्णन करते हैं। हालांकि, पिछले दृष्टिकोण की एक खामी यहां बनी हुई है: यह कोड है और इसे लिखा, जोड़ा और बनाए रखा जाना चाहिए। हमें कुछ समान की आवश्यकता है, लेकिन कोड में लाने के लिए प्रत्येक प्लेटफॉर्म और कॉन्फ़िगरेशन की आवश्यकता के बिना।

इसे हल किया जाता है। हम यूआई और परियों के साथ अपना प्लगइन लिख रहे हैं।

हमें एक योजना चाहिए

पहले आपको यह तय करने की आवश्यकता है कि हम वास्तव में क्या प्राप्त करना चाहते हैं और क्यों।

1. प्रत्येक कॉन्फ़िगरेशन के लिए प्रोजेक्ट सेटिंग्स का संग्रहण (यहां आप स्वयं प्लगइन की शब्दावली में जा सकते हैं और उन्हें विकल्प कह सकते हैं)। विकल्पों की विरासत को लागू करना उचित है। उदाहरण के लिए, सभी स्टैंडअलोन बिल्ड के लिए, प्रोजेक्ट सेटिंग्स सामान्य होंगी, और एक दूसरे से विकल्प केवल प्रोजेक्ट के आइकन और नाम में भिन्न होंगे। इसे कॉपी-पेस्ट के बजाय विरासत द्वारा हल करना काफी तर्कसंगत है।
2. किसी विशेष अवतार में विविध क्या है और यह वर्तमान परियोजना सेटिंग्स से कैसे भिन्न होता है, इसका दृश्य प्रतिनिधित्व।
3. एक संग्रह में संयोजन विकल्प। एक बार में एक बटन या एक स्थिर विधि के साथ बिल्ड का एक सबसेट इकट्ठा करने में सक्षम होने के लिए।
4. आर्काइव में बिल्ड को पैक करना। यह एक वैकल्पिक आवश्यकता है। बिल्ड सर्वर के साथ मिलकर में प्लगइन का उपयोग करने के मामले में, इस आइटम को इसके किनारे पर लागू किया जा सकता है। लेकिन मैं हर चीज को सरल बनाने के लिए जीवन को सरल बनाना चाहता हूं, लेकिन हमेशा एक बिल्ड सर्वर नहीं होता है।
5. असेंबली के विभिन्न चरणों में फ़ाइलें ले जाना। उदाहरण के लिए, आपको कोडिंग करने से पहले कुछ परिसंपत्तियों (आइकन, स्प्लैश, दृश्य इत्यादि) को बदलने की आवश्यकता है (इस मामले में परिसंपत्तियों को बदलने के लिए प्रतिवर्ती होना चाहिए, बिल्ड का निर्माण परियोजना की वर्तमान स्थिति को नहीं बदलना चाहिए)। या समाप्त विंडोज बिल्ड का नाम बदलें {exe_name} _Data to (बहुत कष्टप्रद इकाई व्यवहार, इस हेरफेर के बिना आप निष्पादन योग्य का नाम नहीं बदल सकते हैं)। या, विंडोज में, फिर से, आवश्यक StreamingAssets की व्यवस्था करें। संग्रह को पैक करने से पहले आपको यह करने की आवश्यकता है। और फिर, उदाहरण के लिए, सभी अभिलेखागार को एक स्थान पर कहीं खींचें।
6. यूनिट परियोजनाओं में बहुत बड़ी मात्रा में सेटिंग्स हैं और हम बिल्कुल उन सभी के लिए अपना यूआई लिखना नहीं चाहते हैं। इसके अलावा, वह पहले से ही इकाई में है। इसलिए, हम हमेशा की तरह प्रोजेक्ट सेटिंग्स को बदल देंगे, और प्लग-इन में हम बस सेटिंग्स में बदलाव का पालन करते हैं और आवश्यक विकल्पों को सहेजते हैं।
7. मैं प्रत्येक विकल्प को एक अलग फ़ाइल में संग्रहीत करना चाहूंगा ताकि परियोजनाओं के बीच उन्हें खींचना संभव हो सके।
8. 5.6 संस्करण के बाद से एकता के साथ काम करना उचित है। बिल्ड के आसपास बहुत सारे उपद्रव के साथ कुछ विरासत परियोजनाएं हैं।

मिल जाना

हमारे प्लगइन का मुख्य हिस्सा परियोजना सेटिंग्स के साथ काम कर रहा है, साथ ही व्यक्तिगत सेटिंग्स विकल्पों को संग्रहीत और प्रसंस्करण करना है। इसलिए, हम इस पर ध्यान केंद्रित करेंगे।

यूनिट प्रोजेक्ट सेटिंग्स को प्रोजेक्ट रूट में सभी सेटिंग्स को संग्रहीत करता है। और पहली बात जब हम इनिशियलाइज़ करते हैं, तो हम इन सेटिंग्स को प्लगइन डायरेक्टरी में सेव करेंगे (वैसे, यह प्रोजेक्ट के रूट में BuildVariants है)। यह आवश्यक है ताकि हम बाद के सभी परिवर्तनों को ट्रैक कर सकें। अगला, हमें उन्हें किसी तरह स्टोर करने की आवश्यकता है। सबसे आसान होगा कि प्रत्येक विकल्प के लिए एक अलग स्थान पर केवल प्रोजेक्टसेटिंग कॉपी करें। और इसकी सक्रियता के समय, बस उन्हें पूरी तरह से बदल दें। विचार काफी काम कर रहा है और सबसे पहले मैंने इस पर विचार किया। लेकिन यह पूरी तरह से हमें वंशानुगत विकल्पों के अवसर से वंचित करता है। और अगर हम पहले से ही एक प्लगइन लिख रहे हैं, तो हम तुरंत इसे खूबसूरती से करेंगे। इसलिए हमें ProjectSettings की सामग्री को पढ़ना और लिखना सीखना होगा।

ऐसा करने के लिए, आपको यह समझने की आवश्यकता है कि वहां क्या संग्रहीत है। और सबसे साधारण संपत्ति वहाँ संग्रहीत की जाती है, जो क्रमबद्ध और नियमित रूप से deserialized हैं। इसका मतलब यह है कि हम उन्हें एसेट्सडाटबेस के माध्यम से पढ़ सकते हैं और सीरियलाइज्ड ऑबजेक्ट प्राप्त कर सकते हैं। यह पहले से ही कुछ है। क्योंकि हम सभी SerializedProperty के माध्यम से जा सकते हैं, मूल "स्नैपशॉट" के साथ उनके अंतर को ट्रैक कर सकते हैं और उन्हें एक संस्करण के रूप में सहेज सकते हैं। फिर, जब किसी वेरिएंट को असेम्बल या एक्टिवेट किया जाता है, तो हम पूरे इनहेरिटेंस चेन के साथ बदलाव इकट्ठा करते हैं, उन्हें "स्नैपशॉट" पर लागू करते हैं और उन्हें प्रोजेक्टसेटिंग में स्लिप करते हैं। देखा।

लेकिन SerializedProperty में कुछ अप्रिय विशेषताएं हैं: मानों को संचय करने का एक तरीका (ये सभी intValue, floatValue, isArray), उनकी तुलना करने के लिए एक सामान्य तंत्र की कमी (दो संबंधित वस्तुएं हैं, हम कैसे समझें कि क्या सभी SerializedProperty उनके समान मान हैं) और विरोधाभास (शायद) नहीं) सीरियल योग्य विशेषता की अनुपस्थिति (जिसका अर्थ है कि हमें बचाने के लिए कुछ आवरण की आवश्यकता होगी)। मैं यह नहीं कह सकता कि ये कुछ घातक दोष हैं। यह सब कई बार एक से अधिक संपादक लिपियों में किया गया है। लेकिन फिर भी मैं कुछ और अधिक सरल, समझने योग्य और सार्वभौमिक चाहता हूं।

या शायद हम अपने प्लगइन के उपयोग को थोड़ा सीमित करेंगे? इसे केवल परिसंपत्तियों के पाठ-आधारित क्रमांकन के साथ परियोजनाओं पर काम करने दें (क्या कोई अन्य व्यक्ति बाइनरी का उपयोग करता है?)। फिर सभी ProjectSettings को yaml दस्तावेजों के रूप में संग्रहीत किया जाएगा। आप यमलडॉटनेट लाइब्रेरी ले सकते हैं और सेटिंग्स को पार्स और सहेजने के लिए इसका उपयोग कर सकते हैं। उसी समय, अपने कॉन्फ़िगरेशन को यम में संग्रहीत करें। तो और भी स्पष्ट रूप से। आपको केवल यमल दस्तावेज़ों के संयोजन और उनके संयोजन के लिए कुछ एक्सटेंशन जोड़ने की आवश्यकता है।

संपादक विंडो के साथ थोड़ा उपद्रव करें (मैं भी वर्णन नहीं करना चाहता, मुझे उम्मीद है कि यूआईईएल के साथ रहना आसान और अधिक मजेदार हो जाएगा), एक ढेर में सब कुछ इकट्ठा किया जाता है।

परिणाम

यह दिखाने का समय है कि मैंने क्या किया । आपने पहले से ही प्लग-इन ऑपरेशन के मुख्य तंत्र के साथ खुद को परिचित किया है, इसलिए, यह कुछ विशेषताओं के बारे में अधिक थीसिस है:

• नाम के बाईं ओर चेकमार्क का उपयोग करके चयनित संग्रह में विकल्प जोड़े जाते हैं।
• एक्सटेंशन के साथ बिल्ड पाथ निर्दिष्ट होना चाहिए। मुझे सभी संभावित बिल्डटार्ग के लिए एक्सटेंशन की पूरी सूची नहीं मिली, इसलिए मैंने इसे अभी तक छोड़ दिया।
• चलती फ़ाइलों को सेटिंग्स के रूप में उसी तरह विरासत में मिला है।
• लागू नहीं अलग सरणियों। इसलिए, यदि लीगेसी संस्करण में आपने दृश्य सूची में कुछ बदल दिया है, तो पूरी सूची को पूरी तरह से बदल दिया जाएगा। अच्छे को अंतिम रूप देने की आवश्यकता होगी।
• वास्तविक परियोजना सेटिंग्स भिन्न होती हैं चयनित विकल्प और वर्तमान परियोजना सेटिंग्स के बीच सभी अंतरों की एक सूची है। इसके अलावा, यदि सक्रिय विकल्प का चयन किया जाता है, तो वर्तमान सेटिंग्स में परिवर्तन पूर्ववत किया जा सकता है।
• वैरिएंट सेटिंग्स, तदनुसार, माता-पिता के परिवर्तनों को छोड़कर, चयनित विकल्प में व्यक्तिगत परिवर्तन हैं।
• जब विकल्प सक्रिय हो जाता है, तो परियोजना सेटिंग्स में सभी सहेजे गए परिवर्तन खो जाएंगे।
• यदि प्रोजेक्ट सेटिंग्स में बिना सहेजे गए परिवर्तन हैं, तो प्लगइन के माध्यम से बिल्ड बनाने का कोई भी प्रयास निष्पादन के साथ समाप्त हो जाएगा। क्योंकि ऊपर देखें, और जैसा कि हम याद करते हैं, बिल्ड का निर्माण परियोजना की वर्तमान स्थिति को नहीं बदलना चाहिए।
• प्लगइन का उपयोग बिल्ड सर्वर के साथ किया जा सकता है। ऐसा करने के लिए, वहाँ स्टैटिक्स के तरीके हैं: BuildVariants.Controller.BuildController.BuildAll, BuildVariants.Controller.BuildController.BuildCollection और BuildVariants.Controller.BuildController.BuildVariant (-variant पैरामीटर में नामित संस्करण) (-collection पैरामीटर में संग्रह के नाम के साथ)। यह कुछ इस तरह दिखेगा:
  $unity_path -batchmode -projectPath $project_path -quit -logfile -executeMethod BuildVariants.Controller.BuildController.BuildCollection -collection standalone
• संग्रह के लिए, प्लगइन के पास डॉटनेटज़िप लाइब्रेरी के रूप में एक और निर्भरता है।
• प्लगइन एक छोटे से काम कर रहे लोरी की स्थितियों में लिखा गया था, इसलिए अभी भी इसे भयंकर लड़ाई में परीक्षण करने और इसे गुस्सा करने का अवसर नहीं है। कीड़े हो सकते हैं, शायद खराब और अप्रिय भी।

भविष्य की योजना

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

इसलिए, मुझे किसी भी सुझाव, टिप्पणी, प्रश्न और बग रिपोर्ट की खुशी होगी। आसान आप के लिए बनाता है!