यूनिटी 3 डी के लिए विजुअल लॉजिक एडिटर। भाग 1

परिचय

नमस्कार प्रिय पाठकों, आज के लेख में मैं यूनिटी 3 डी पर दृश्य विकास के रूप में अनुप्रयोगों के विकास में ऐसी घटना पर ध्यान देना चाहूंगा या, अधिक सटीक रूप से, कोड और तर्क के दृश्य प्रतिनिधित्व का उपयोग करके विकास। और, जारी रखने से पहले, मैं तुरंत स्पष्ट करना चाहता हूं, हम दृश्य प्रोग्रामिंग के बारे में बात नहीं कर रहे हैं, "बिल्कुल" शब्द से, एकता दुनिया में कोई ब्लूप्रिंट विविधताएं नहीं हैं और कोई सी # कोड पीढ़ी नहीं हैं। तो फिर क्या एक दृश्य तर्क संपादक द्वारा मतलब है? यदि आप इस प्रश्न के उत्तर में रुचि रखते हैं, तो बिल्ली के नीचे स्वागत करें।

श्रृंखला में लेख:
दृश्य तर्क संपादक भाग 2

विजुअल लॉजिक एडिटर क्या है

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

सिक्के के दूसरी तरफ, हम (प्रोग्रामर) ने घटकों के रूप में बहुत सारे कोड लिखे, वे दृश्य में विभिन्न वस्तुओं पर एक बड़ी सूची में लटकाते हैं। और इसलिए हम टीम का विस्तार कर रहे हैं, हमने एक नया प्रोग्रामर को काम पर रखा है, वह इसे छांटने के लिए मंच खोलता है और सवालों के झमेले में डूब जाता है: कौन किस कारण से, किस क्रम में, किस घटक से जुड़ा है और किस तरह से आदि, आप यथोचित रूप से कहते हैं: "और" प्रलेखन? ” दस्तावेज़ीकरण है (हालांकि एक तथ्य पर नहीं), लेकिन यहां नए लोगों के लिए टीम में शामिल होने की दहलीज के बारे में जितना संभव हो उतना कम है, और इस प्रक्रिया के लिए जितना संभव हो उतना कम समय है।

ऊपर वर्णित स्थितियों को कैसे हल करें? लेख के शीर्षक में उत्तर विजुअल लॉजिक एडिटर है। यह क्या है? यह एक ऐसा वातावरण है जो आपको तर्क के विभिन्न घटकों को नेत्रहीन रूप से संचालित करने और उनके रिश्तों ("नरम" संस्करण) में कॉन्फ़िगर करने की अनुमति देता है, साथ ही दृश्य से परोक्ष रूप से दृश्य की वस्तुओं में हेरफेर करता है। यदि आप इसे एक सरल तरीके से वर्णन करते हैं, तो यह बचपन से पसंद है क्यूब्स से विभिन्न डिजाइनों को इकट्ठा करने के लिए (केवल हमारे मामले में, क्यूब्स कसकर जुड़े नहीं हैं, नीचे को हटाकर, हमारा डिज़ाइन गिर नहीं जाएगा)।

इसलिए, हमने इस परिभाषा का पता लगा लिया है, लेकिन यह आखिर में हमें क्या देता है?

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

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

1. प्लेमेकर। हाँ यह एक FSM प्लगइन है, लेकिन फिर भी, यह आपको अपने कार्य लिखने की अनुमति देता है। यह इंटरफ़ेस के दृष्टिकोण से इतना सुविधाजनक नहीं है, लेकिन कुछ चीजों के लिए यह बहुत अच्छा है। हर्थस्टोन में इस्तेमाल किया गया बर्फ़ीला तूफ़ान व्यर्थ नहीं था।
2. व्यवहार डिजाइनर / मूनबेहोर , आदि। राज्य वृक्ष प्लगइन्स। यह ऊपर वर्णित के करीब था, लेकिन बहुत सारी सीमाएं हैं, आखिरकार, राज्य का पेड़ घटकों पर पूर्ण तर्क नहीं है।
3. ICODE। यह प्लेमेकर का एक एनालॉग है, जो वास्तव में, एक राज्य मशीन भी है।

क्या कोई रास्ता है जिससे आप पूछें, प्रिय पाठकों? मैंने केवल एक पाया, अपनी प्रणाली लिखी, जो मैंने किया, लेकिन इसके लिए रास्ता काफी लंबा और कांटेदार था।

जिस तरह से

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

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



उसके बाद, विचार को कुछ समय के लिए स्थगित कर दिया गया। निम्नलिखित परियोजनाएं मैंने पहले से ही शुद्ध कोड पर की थीं, लेकिन विचार अभी भी मेरे सिर में मंडरा रहा था। धीरे-धीरे, पिछली गलतियों को ध्यान में रखते हुए, अंतिम (जैसा कि मुझे लग रहा था) दृष्टि और आवश्यकताओं की सूची बनाई गई थी। और 2017 में, अगली फ्रीलांस परियोजना के पूरा होने के बाद, मैंने फैसला किया कि मैं इस प्लगइन पर काम करने में 6-7 महीने खर्च कर सकता हूं और इसे एसेट स्टोर में डालने की कोशिश कर सकता हूं (यह अभी भी झूठ है और इसे पैंथिया वीएस कहा जाता है)। इस तरह की जटिल परियोजना पर काम करने के अनुभव के दृष्टिकोण से, सब कुछ बहुत अच्छा था, वित्तीय पक्ष अफसोसजनक है, फिर भी कार्यक्रम करने और बेचने में सक्षम होने के कारण दो अलग-अलग चीजें हैं। यह नवंबर 2017 था, जिसके बाद मैंने अपनी प्रेरणा को थोड़ा खो दिया, तलाक ले लिया, अपना शहर बदल दिया, पूरी तरह से अपना जीवन बदल दिया, और समोवाद में नहीं पड़ने के लिए मैंने दृश्य तर्क संपादक के विषय पर एक अलग कोण को देखने का फैसला किया। परिणाम uViLEd था, जिसे मैंने मुफ्त में पोस्ट करने का फैसला किया। चूंकि मैंने एक पूर्णकालिक अनुबंध पर हस्ताक्षर किए, इसलिए मुझे सप्ताहांत और छुट्टियों पर इस पर काम करना पड़ा और इसने मुझे 2018 की शुरुआत और 2019 की शुरुआत में ले लिया। uViLEd Panthea VS का एक बड़ा पुनर्विचार है, जो रोसलिन कंपाइलर (C # 7+) के लिए कोड का पूर्ण रूप से फिर से निर्माण करता है, इसलिए सब कुछ Unity3d 2018.3 संस्करण से ही काम करता है।

नोट : Panthea VS ने कई परियोजनाएं शुरू कीं (Android और iOS, विशेष रूप से, लेव के ट्रक और कार), सिद्धांत रूप में, इसका उपयोग करने का अनुभव सफल रहा, लेकिन उस क्षण सामने आया कि यह एक संपादक को लिखने के लिए एक और चीज है, इसे सही तरीके से उपयोग करना सीखना है (कोई बात नहीं यह कितना अजीब लगता है) )।

uViLEd और इसका उपयोग कैसे करें

परिचय

तो, अंत में क्या हुआ, पहले हम तस्वीर को देखते हैं, और फिर जारी रखें (अधिक चित्र होंगे)।



विजुअल लॉजिक एडिटर किस पर आधारित है?



यहां:

• अवयव - यह हमारा कोड है जो एक या दूसरे कार्यात्मक को लागू करता है, वास्तव में, मोनोबेहवियर का एक एनालॉग, केवल हमारे मामले में सभी घटकों को LogicComponent वर्ग से विरासत में मिला है, जो बदले में एक ScriptableObject है ।
• चर ऐसे विशेष ScriptableObjects हैं जो डेटा को स्टोर करने की अनुमति है (कोई भी, जिसमें कस्टम संरचनाएं और कक्षाएं, दृश्य वस्तुओं के संदर्भ, प्रीफ़ैब और संपत्ति शामिल हैं)। चर की आवश्यकता होती है यदि घटकों के बीच डेटा साझा करना आवश्यक है, अर्थात, प्रत्येक घटक वांछित प्रकार के एक चर का उल्लेख कर सकता है, और यह एक होगा।
• रिश्ते एक दृश्य के रूप में वर्णन करते हैं कि क्या घटक, कैसे और किस क्रम में एक दूसरे के तरीकों को कहते हैं। घटकों के बीच संबंध INPUT_POINT और OUTPUT_POINT के दो विशेष क्षेत्रों का उपयोग करके निर्धारित किए जाते हैं। एक लिंक हमेशा एक घटक के आउटपुट बिंदु के रूप में दूसरे घटक के इनपुट बिंदु के रूप में बनता है। ये कनेक्शन कठोर नहीं हैं, अर्थात, वे प्रोग्रामर को दिखाई नहीं देते हैं और वे कोड में भी नहीं हैं। वे मौजूद हैं, केवल संपादक में, और फिर जब दृश्य शुरू होता है, तो तर्क नियंत्रक स्वयं कोड को समझता है। ऐसा कैसे होता है हम एक अलग लेख में बात करेंगे।

डिब्बे में सब कुछ - घटक, चर और संबंध - तर्क बनाते हैं। सामान्य तौर पर, कुछ भी जटिल नहीं है, प्रोग्रामर घटकों और चर के कोड को लिखता है, और गेम डिजाइनर या अन्य (या शायद एक ही) प्रोग्रामर / डिवाइडर इन घटकों को संपादक में रखकर और कनेक्शन और पैरामीटर सेट करके तर्क बनाता है।

UViLEd की मुख्य विशेषताएं

• किसी बाहरी स्रोत (हार्ड डिस्क या सर्वर) से प्रारंभ करने सहित आस्थगित मोड में रनिंग लॉजिक (कंपोनेंट्स, वेरिएबल्स और रिलेशनशिप का एक सेट)
• घटकों के बीच संबंध स्थापित करना (कॉल ऑर्डर, सक्रियण और निष्क्रिय करना)
• घटकों और किसी अन्य कोड का आसान एकीकरण, जिसमें मोनोबेवियर वंशज शामिल हैं
• संपादक में घटकों की उपस्थिति को ओवरराइड करना (CustomPropertyDrawer के अनुरूप)
• Unity3d निरीक्षक के माध्यम से घटक सेटिंग्स को कॉन्फ़िगर करना
• आसानी से खींचें और ड्रॉप स्क्रिप्ट फ़ाइल के माध्यम से या निर्देशिका के माध्यम से तर्क में घटकों को जोड़ें
• तर्क संपादक में घटक घटकों
• संपादक में घटकों के प्रदर्शन को स्थापित करना (उलटा करना, कम करना, सक्रिय करना और निष्क्रिय करना)
• तर्क संपादक से सीधे घटक कोड संपादक खोलना
• डिबगिंग डेटा को सीधे तर्क संपादक में स्टार्टअप के दौरान प्रदर्शित करें
• दृश्य तर्क संपादक स्केलिंग
• यदि अचानक बड़ी संख्या में घटक तर्क में समाहित हो जाते हैं, तो चयन करते समय उन्हें ध्यान से खोजने की संभावना है (यह चर पर लागू होता है)
  
• घटक और चर मानों के बीच सभी संचरित डेटा की ट्रैकिंग के साथ यूनिटी 3 डी संपादक में दृश्य लॉन्च मोड में चरण-दर-चरण डिबगिंग
• MonoBehaviour विधियों के लिए समर्थन और उनके कॉल का क्रम सेट करना। नोट : यहाँ हमारा तात्पर्य है कि SO में डिफ़ॉल्ट रूप से स्टार्ट, अपडेट आदि जैसी कोई विधियाँ नहीं हैं। इसलिए, उनका समर्थन स्वयं घटकों में जोड़ा गया है। उसी समय, ExecuteOrder विशेषता का उपयोग करके, आप उस क्रम को कॉन्फ़िगर कर सकते हैं जिसमें स्टार्ट, अपडेट और इसी तरह से कॉल किया जाता है।
• Coroutine, async / प्रतीक्षा और इंस्पेक्टर के लिए सभी Unity3d विशेषताएँ, साथ ही CustomPropertyDrawer के लिए समर्थन

संपादक के साथ काम करें

संपादक के साथ काम करना शुरू करने के लिए, आपको दृश्य को खोलना होगा, और उसके बाद ही संपादक को शुरू करना होगा।



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



हमने तर्क में कई घटक जोड़ दिए हैं, उन्हें समूहों में शामिल किया जा सकता है या एक दृश्य समूह में जोड़ा जा सकता है।



आइए हम और अधिक विस्तार से विचार करें कि हम एक दृश्य संपादक में घटक का प्रतिनिधित्व क्या करते हैं।



यहां:

• घटक का मेनू बटन, एक ड्रॉप-डाउन मेनू खोलता है जिसके साथ आप कर सकते हैं:
  
  • किसी घटक को सक्रिय या निष्क्रिय करना
  • घटक को छोटा करें (यह हेडर पर डबल-क्लिक करके भी किया जा सकता है)
  • इनवर्टर घटक (स्वैप इनपुट और आउटपुट पॉइंट)
  • घटक विकल्प क्षेत्र छिपाएँ या दिखाएँ
  • घटक के लिए कोड संपादक खोलें
• घटक मापदंडों का क्षेत्र वह स्थान है जहां घटक के प्रमुख मापदंडों के मूल्य प्रदर्शित किए जाते हैं, जिनमें से संरचना प्रोग्रामर पर निर्भर करती है

पैरामीटर (सार्वजनिक क्षेत्र या फ़ील्ड को SerializeField विशेषता के साथ कॉन्फ़िगर करने के लिए), आपको तर्क संपादक में घटक का चयन करने और यूनिटी 3 डी निरीक्षक खोलने की आवश्यकता है।



यहां:

• ऊपरी दाएं कोने में एक बटन है जो आपको हेडर के रंग को बदलने की अनुमति देता है, जो तर्क संपादक में प्रदर्शित होता है
• नाम - घटक उदाहरण का नाम सेट करने के लिए फ़ील्ड
• टिप्पणी - घटक उदाहरण पर एक टिप्पणी सेट करने के लिए एक क्षेत्र; यह तर्क संपादक में प्रदर्शित किया जाता है जब आप घटक पर होवर करते हैं
• घटक पैरामीटर - वह क्षेत्र जहां घटक पैरामीटर प्रदर्शित होते हैं (सार्वजनिक क्षेत्र और SerializeField के साथ चिह्नित क्षेत्र)
• परिवर्तनीय लिंक - चर के संदर्भ सेट करने के लिए एक क्षेत्र (उनके बारे में अधिक चर के साथ काम करने पर अनुभाग में चर्चा की जाएगी)।

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



माउस व्हील का उपयोग कर घटकों के दृश्य प्रतिनिधित्व को स्केल करने के लिए, सब कुछ काफी सरल है।

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







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

INPUT_POINT OUTPUT_POINT INPUT_POINT<T> OUTPUT_POINT<T> 

पहले दो वर्गों का उपयोग इनपुट और आउटपुट बिंदुओं के लिए किया जाता है जो मापदंडों को स्वीकार नहीं करते हैं, दूसरा, क्रमशः, इसके विपरीत। T किसी भी प्रकार का हो सकता है।

 public INPUT_POINT <float> InputFloatValue = new INPUT_POINT<float>(); public OUTPUT_POINT <float> OutputFloatValue = new OUTPUT_POINT<float>(); 

लिंक की एक श्रृंखला को कॉल करने के लिए, आपको एक्सक्यूट फ़ंक्शन का उपयोग करना होगा।

 OutputFloatValue.Execute(5f); 

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

 InputFloatValue.Handler = value => Debug.Log(value); 

और अंत में, मैं कनेक्शन के बारे में एक महत्वपूर्ण बिंदु का उल्लेख करना चाहता हूं। यदि एक बिंदु से कई लिंक हैं, तो संपादक में उनके कॉल के क्रम को समायोजित करना संभव है।

चरों के साथ काम करना

जैसा कि पहले उल्लेख किया गया है, चर विशेष ऑब्जेक्ट हैं जो आपको घटकों के बीच डेटा को लिंक के माध्यम से साझा करने की अनुमति देते हैं। घटक की तरह चर, प्रोग्रामर द्वारा बनाए जाते हैं।

 [ComponentDefinition(Name = "Float", Path = "uViLEd Components/Base/Variable/Base", Tooltip = "Variable for a floating-point number", Color = VLEColor.Cyan)] public class VariableFloat : Variable<float> { } 

जैसा कि आप देख सकते हैं, चर के लिए आधार वर्ग सामान्य वर्ग चर है, जहां T एक प्रकार का डेटा है जो चर में संलग्न है, T किसी भी प्रकार का हो सकता है जिसे क्रमबद्ध किया जा सकता है।

संपादक में, चर इस प्रकार प्रदर्शित होते हैं:



चर मानों के प्रदर्शन को बदलने के लिए, टाइप T में स्ट्रिंग विधि को फिर से परिभाषित करें।

 public struct CustomData { public readonly int Value01; public readonly int Value02; public CustomData (int value01, int value02) { Value01= value01; Value02= value02; } public override string ToString() { var stringBuilder = new StringBuilder(); stringBuilder.AppendLine("Value01 = {0}".Fmt(Value01)); stringBuilder.Append("Value02 = {0}".Fmt(Value02)); return stringBuilder.ToString(); } } 

इस प्रकार, इस प्रकार का एक चर दिखेगा:

 public class VariableCustomData : Variable<CustomData> { } 

किसी घटक में एक चर के संदर्भ को जोड़ने के लिए, आपको एक विशेष वर्ग का उपयोग करना चाहिए।

 public VARIABLE_LINK<CustomData> CustomVariableLink = new VARIABLE_LINK<CustomData>(); 

उसके बाद, लिंक को निरीक्षक में सेट किया जा सकता है, और ड्रॉप-डाउन मेनू में केवल CustomData प्रकार के चर दिखाए जाएंगे, जो उनके साथ काम करना बहुत सरल करता है।

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

 CustomVariableLink.AddSetEventHandler(CustomDataSet); CustomVariableLink.AddChangedEventHandler(CustomDataChanged); 

यह ध्यान में रखना चाहिए कि बराबरी की स्थिति से परिवर्तन काम करता है, इसलिए, यदि संरचनाओं और कक्षाओं का उपयोग किया जाता है, तो सही संचालन सुनिश्चित करने के लिए इस पद्धति को फिर से परिभाषित किया जाना चाहिए।

एकता वस्तुओं के साथ काम करना

UViLEd प्रणाली की प्रकृति के कारण, Unity ऑब्जेक्ट्स से सीधे लिंक का उपयोग इसमें नहीं किया जा सकता है, क्योंकि लॉजिक लोड करते समय उन्हें पुनर्स्थापित नहीं किया जा सकता है। इस समस्या को हल करने के लिए, एक विशेष VLObject शेल बनाया गया था, जो आपको ऐसे लिंक बनाने, साथ ही उन्हें बचाने और लोड करने की अनुमति देता है। अन्य बातों के अलावा, इस शेल में एक विशेष संपत्ति संपादक है जो आपको दृश्य में किसी भी ऑब्जेक्ट से घटकों को प्राप्त करने की अनुमति देता है (यदि नीचे आंकड़ा देखें) यदि आप उन्हें एक्सेस करना चाहते हैं। Vlobject के साथ , आप न केवल वस्तुओं और उनके घटकों को दृश्य के लिए लिंक स्टोर कर सकते हैं, बल्कि प्रीफ़ैब और संसाधन फ़ाइलों, जैसे कि बनावट, ध्वनियां आदि के लिए भी स्टोर कर सकते हैं।



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

यह भी संभव है कि VLObject में स्थापित की गई एकता ऑब्जेक्ट के प्रकार को प्रतिबंधित करें। यह केवल एकता निरीक्षक को प्रभावित करता है और उनके साथ काम करने की सुविधा के लिए उपयोग किया जाता है।

 [SerializeField] [TypeConstraint(typeof(Button))] private VLObject _button; 

एक तर्क घटक बनाना

लॉजिक घटक बनाने के लिए, प्रोग्रामर के लिए प्रोजेक्ट में एक साधारण C # स्क्रिप्ट फ़ाइल जोड़ना आवश्यक है (आप प्रोजेक्ट टैब में एक विशेष मेनू के माध्यम से तुरंत एक घटक या एक चर भी बना सकते हैं) और इसमें कोड को निम्न में बदल सकते हैं:

 [ComponentDefinition(Name = "MyComponent", Path = "MyFolder/MySubfolder", Tooltip = "this my logic component", Color = VSEColor.Green)] public class MyLogicComponent : LogicComponent { } 

जैसा कि पहले उल्लेख किया गया है, ComponentDefinition एक विशेषता है जो आपको स्वचालित रूप से घटकों की एक सूची बनाने की अनुमति देता है, यहां यह ध्यान दिया जाना चाहिए कि रंग (हेडर का रंग) स्ट्रिंग में एक एचईएक्स प्रारूप के रूप में सेट है।

LogicComponent सभी घटकों का आधार वर्ग है, जो बदले में ScripatableObject का वंशज है।

निम्नलिखित एक घटक का एक सरल उदाहरण है जो टाइप बूल के एक आने वाले मूल्य से शाखा करता है:

 public class IfBool : LogicComponent { public INPUT_POINT<bool> ValueToBeChecked = new INPUT_POINT<bool>(); public OUTPUT_POINT True = new OUTPUT_POINT(); public OUTPUT_POINT False = new OUTPUT_POINT(); public override void Constructor() { ValueToBeChecked.Handler = ValueToBeCheckedHandler; } private void ValueToBeCheckedHandler(bool value) { if(value) { True.Execute(); }else { False.Execute(); } } } 

इसलिए, जैसा कि आप कोड से देख सकते हैं, हमने घटक का इनपुट बिंदु बनाया, जो टाइप बूल और दो आउटपुट बिंदुओं का एक मूल्य लेता है, जो कि हमें किस मूल्य के आधार पर कहा जाता है।

शायद अब आपके पास एक सवाल है कि यह किस प्रकार का कंस्ट्रक्टर है ? मैं समझाता हूं। डिफ़ॉल्ट रूप से, ScriptableObject प्रारंभ , अद्यतन , आदि जैसी विधियों का समर्थन नहीं करता है, लेकिन यह सजग , OnEnable , OnDisable और OnDestroy विधियों का समर्थन करता है । तो सजग ( OnEnable की तरह), अगर ScriptableObject CreateInstance मेथड के माध्यम से बनाया जाता है, तो इसे हमेशा कहा जाता है, और यह वास्तव में, समस्या है। इस तथ्य के कारण कि ऑब्जेक्ट को संपादक मोड में क्रमांकन के लिए स्मृति में बनाया गया है, इस समय घटक कोड को काम करने से बाहर करना आवश्यक था, इसलिए अवाके एनालॉग को कंस्ट्रक्टर विधि के रूप में जोड़ा गया था, वही जब संपादक में किसी ऑब्जेक्ट को हटाने पर ऑनडबल और ऑनडेस्ट्रो विधियों पर लागू होता है। यदि आपको एक घटक को हटाने की प्रक्रिया को सही ढंग से करने की आवश्यकता है (उदाहरण के लिए, किसी दृश्य को उतारने पर), तो आपको आईडीसोफाइल इंटरफ़ेस का उपयोग करना होगा।

सामान्य तौर पर, जैसा कि आप देख सकते हैं, घटकों को बनाने में कुछ भी मुश्किल नहीं है। यह एक नियमित वर्ग है, जिसमें कोई भी कोड हो सकता है जिसे आप चाहते हैं। विशेष स्थिति में, घटकों में इनपुट और आउटपुट पॉइंट बिल्कुल नहीं हो सकते हैं, लेकिन वैश्विक संदेशों का उपयोग करके संवाद करते हैं। वैसे, इसके लिए, uViLEd में एक GlobalEvent क्लास है - यह डेटा टाइप्स पर आधारित एक संदेश प्रणाली है (इसके बारे में मेरे लेख में पाया जा सकता है)।

आखिरी चीज जिसका मैं उल्लेख करना चाहूंगा, वह घटक के इनपुट और आउटपुट बिंदुओं को घटक के मापदंडों के आधार पर कॉन्फ़िगर करने की क्षमता है।



ऐसा करने के लिए, घटक कोड में, यह IInputPointParse और IOutputPointParse इंटरफेस में से एक या दोनों को लागू करने के लिए पर्याप्त है। नीचे स्विच ब्रांच घटकों के लिए अमूर्त जेनेरिक क्लास कोड का एक उदाहरण है, स्विचवैल्यूज पैरामीटर के आधार पर, आउटपुट पॉइंट स्वचालित रूप से यहां बनाए जाते हैं।

तर्क डिबगिंग

UViLEd डिबगिंग तर्क के लिए कई तंत्र प्रदान करता है:

1. आंतरिक चर और उनके मूल्यों को दृश्य लॉन्च मोड में तर्क संपादक में प्रदर्शित करने की क्षमता। ऐसा करने के लिए, ViewInDebugMode विशेषता का उपयोग करें
2. दृश्य लॉन्च मोड में तर्क चर के मूल्यों को देखने की क्षमता
3. घटकों के बीच कॉल के चरण-दर-चरण डिबगिंग की संभावना और उनके बीच स्थानांतरित किए गए डेटा को देखना

UViLEd में अंतिम आइटम के लिए एक विशेष मोड है, जो दृश्य शुरू होने पर चालू होता है।



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

निष्कर्ष

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

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

आगे क्या?

यह तर्क uViLEd के दृश्य संपादक के बारे में लेखों की एक श्रृंखला का पहला भाग था, तब इसके बारे में कुछ अंश होंगे:

1. प्रणाली का मूल : तर्क कैसे लोड किया जाता है, क्यों ScriptableObject का चयन किया जाता है, एपीआई की व्यवस्था कैसे की जाती है, जो आपको करने की अनुमति देता है, आदि, क्या कठिनाइयाँ उत्पन्न हुई और कैसे सब कुछ हल हो गया।
2. संपादक : इसका विकास कैसे हुआ, इसका निर्माण कैसे हुआ, क्या समस्याएँ हैं और क्या समाधान हैं, इत्यादि बातें, जो कि अब मैं रीमेक करूँगा।

टिप्पणियों में लिखें यदि आपके पास कोई विशिष्ट प्रश्न हैं जो आप मुझे बाद के लेखों में शामिल करना चाहेंगे।

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

दृश्य तर्क संपादक भाग 2

UVILEd दृश्य तर्क संपादक
ग्लोबल मैसेजिंग आर्टिकल