Entities को समझना

अब हम cave में एक Entity के विचार को समझते हैं। Entities Cave दृश्य के अंदर मूलभूत वस्तुएं होती हैं।

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

इस पाठ में, आप सीखेंगे:

• नाम।
• IDs।
• सक्रिय स्थिति।
• अभिभावकता।
• फ़ोल्डर।
• पदानुक्रम क्रम।
• टैग और गुण।
• टेम्पलेट उदाहरण।

ये विवरण छोटे लग सकते हैं, लेकिन जब एक दृश्य कुछ वस्तुओं से बढ़कर एक वास्तविक स्तर में बदलता है, तो ये बड़ा फर्क डालते हैं।

Entity क्या है?

एक Entity दृश्य में एक वस्तु होती है।

एक Entity का प्रतिनिधित्व कर सकता है:

• एक दृश्य 3D वस्तु।
• एक अदृश्य सहायक।
• एक गेमप्ले ट्रिगर।
• एक UI तत्व।
• एक ध्वनि स्रोत।
• या केवल संगठन के लिए उपयोग किया जाने वाला फ़ोल्डर।

उदाहरण के लिए, एक क्रेट एक दृश्य Entity है। एक स्पॉन पॉइंट गेमप्ले के दौरान अदृश्य हो सकता है, लेकिन यह अभी भी एक Entity है क्योंकि यह दर्शाता है कि कुछ कब होना चाहिए।

Cave इस विचार को सरल रखता है: दृश्य Entities से बने होते हैं।

Entities घटक कंटेनर होते हैं

Entities अकेले बहुत कुछ नहीं करती हैं, उनके फीचर्स घटकों से आते हैं। उदाहरण के लिए:

यही कारण है कि Entities लचीली हैं। एक दरवाजा एक पूरी तरह से अलग हार्डकोडेड ऑब्जेक्ट प्रकार नहीं है। यह एक Entity है जो टुकड़ों से बनी है: इसे देखने के लिए एक मेष, खिलाड़ी को ब्लॉक करने के लिए टकराव, और इसे खोलने या बंद करने के लिए लॉजिक।

जब आप इसे समझ जाते हैं, तो वस्तुएं बनाना अधिक व्यावहारिक हो जाता है। आप यह पूछना बंद कर देते हैं "मुझे कौन सा ऑब्जेक्ट प्रकार चाहिए?" और पूछना आरंभ करते हैं "इस Entity को कौन से घटक चाहिए?"

Entity के नाम

हर Entity का एक नाम होता है। आप Scene Graph में इसके त्वरित संपादन मेन्यू से या Properties टैब से एक Entity का नाम बदल सकते हैं।

यह उल्लेख करना महत्वपूर्ण है कि नाम पहले मनुष्यों के लिए होते हैं:

• ये Scene Graph को स्कैन करना आसान बनाते हैं।
• ये डिबगिंग को सरल बनाते हैं।
• ये टीम के साथियों के साथ वस्तुओं के बारे में बात करना आसान बनाते हैं।
• ये आपको बाद में अपने दृश्य को समझने में मदद करते हैं।

Cave हर Entity नाम को अद्वितीय बनाने की आवश्यकता नहीं है। कई Entities एक ही नाम साझा कर सकते हैं, जो कि पत्थरों, सिक्कों, क्रेटों, या दुश्मनों जैसे दोहराए जाने वाले ऑब्जेक्ट्स के लिए उपयोगी होता है।

हालांकि, नाम को एकमात्र विश्वसनीय पहचानकर्ता के रूप में न मानें।

अच्छे नाम सरल और वर्णनात्मक होते हैं:

उद्देश्य नामों को भव्य बनाना नहीं है। उद्देश्य दृश्य को पठनीय बनाना है।

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

Entity IDs

Cave आंतरिक रूप से अद्वितीय IDs द्वारा Entities को ट्रैक करता है।

आपको आमतौर पर इन IDs को संपादित करने या चिंता करने की आवश्यकता नहीं होती है। ये केवल इसलिए मौजूद हैं ताकि इंजन विश्वसनीय रूप से Entities की पहचान कर सके, भले ही नाम दोहराए गए हों। दरअसल, अद्वितीय IDs अपरिवर्तनीय होते हैं, यानी कि आप इन्हें बदल नहीं सकते। इन्हें इंजन द्वारा स्वचालित रूप से असाइन किया जाता है।

यह याद रखें:

यदि दो दुश्मनों का नाम Dushman है, तो Cave उन्हें पीछे के दृश्य में अलग-अलग पहचान सकता है।

Entity सक्रिय स्थिति

Entities सक्रिय या निष्क्रिय हो सकती हैं।

Scene Graph और Properties टैब में, इसे एक आंख-शैली सक्रिय नियंत्रण के साथ प्रदर्शित किया जाता है।

Entity और इसके घटकों के आधार पर, अक्षम करना असर डाल सकता है:

• रेंडरिंग।
• भौतिक।
• लॉजिक।
• रनटाइम अपडेट।
• घटक व्यवहार।

एक निष्क्रिय Entity का कोई घटक अपडेट नहीं किया जाएगा, और जैसे ही आप एक Entity को निष्क्रिय करते हैं, यह घटक के अंत विधि को कॉल करेगा, और जब आप इसे फिर से सक्रिय करते हैं, तो यह घटक की प्रारंभ विधि को कॉल करेगा।

आप इसे सुरक्षित रूप से मान सकते हैं कि एक निष्क्रिय Entity दृश्य की भौतिक गणनाओं, लॉजिक, ट्रिगर्स, आदि में भाग नहीं लेगी। जब तक आप दृश्य से उन Entities को मैन्युअल रूप से क्वेरी नहीं करते हैं और इस तथ्य की अनदेखी नहीं करते हैं कि वे निष्क्रिय हैं।

व्यावहारिक विचार सरल है: निष्क्रिय का मतलब "यहां रखा गया है, लेकिन वर्तमान में भाग नहीं ले रहा"।

निष्क्रिय करना बनाम हटाना

निष्क्रिय करना और हटाना एक समान नहीं है।

एक Entity को तब निष्क्रिय करें जब आप सुनिश्चित नहीं हैं कि इसे बाद में फिर से चाहते हैं। जब आप सुनिश्चित हों कि इसे हटाया जाना चाहिए, एक Entity को हटा दें।

परीक्षण के लिए, निष्क्रिय करना अक्सर सुरक्षित होता है। यदि एक दुश्मन मुठभेड़ बहुत कठिन महसूस करता है, तो पहले कुछ दुश्मनों को निष्क्रिय करें और स्तर का परीक्षण करें। यदि बदलाव सही लगता है, तो आप बाद में दृश्य को साफ कर सकते हैं।

Entities की अभिभावकता

Entities को अन्य Entities में अभिभावक किया जा सकता है।

जब एक Entity का एक अभिभावक होता है, तो यह उस अभिभावक की पदानुक्रम का हिस्सा बन जाता है। यदि आप अभिभावक को स्थानांतरित करते हैं, तो बच्चे उसी के साथ चलते हैं।

अभिभावकता उपयोगी है:

• एक चरित्र से जुड़ा एक तलवार।
• एक टॉर्च से जुड़ा एक प्रकाश।
• एक वाहन से जुड़ा कैमरा।
• एक फ़ोल्डर के तहत व्यवस्थित वस्तुओं का समूह।
• एक अभिभावक पैनल के तहत समूहबद्ध UI तत्व।

अभिभावकता ट्रांसफॉर्म पर भी असर डालती है। एक बाल Entity का ट्रांसफॉर्म अभिभावक पदानुक्रम के सापेक्ष मूल्यांकित होता है।

यह संबंधित वस्तुओं को एक साथ रखने के लिए सबसे आसान तरीकों में से एक है।

फ़ोल्डर Entities

फ़ोल्डर Entities संगठन के लिए उपयोग की जाती हैं। ये विशेष रूप से सहायक होती हैं जब आपका दृश्य कई वस्तुओं को शामिल करना शुरू करता है।

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

सामान्य फ़ोल्डर समूहों में शामिल हैं:

• वातावरण।
• गेमप्ले ट्रिगर्स।
• दुश्मन।
• प्रॉप्स।
• प्रकाश।
• UI।
• ऑडियो।
• डिबग हेल्पर्स।

फ़ोल्डर्स न केवल साफ़-सुथरे होते हैं। एक साफ़ दृश्य ग्राफ़ आपको तेजी से काम करने में मदद करता है क्योंकि आप आवश्यक वस्तु को बिना सैकड़ों ढीली Entities के माध्यम से खोजे खोज सकते हैं।

Entity पदानुक्रम क्रम

Scene Graph में Entities का क्रम संगठन के लिए महत्वपूर्ण होता है, और कुछ मामलों में यह यह भी मायने रख सकता है कि चीजें कैसे संसाधित या प्रदर्शित की जाती हैं।

यदि आप एक फ़ोल्डर खोलते हैं और नीचे दी गई संरचना देखते हैं, तो यह स्कैन करने में कठिन होती है:

क्रेट
खिलाड़ी
रोशनी
दुश्मन
कैमरा
पत्थर
ट्रिगर

लेकिन यह आसान है:

खिलाड़ी
कैमरा
रोशनी
दुश्मन
पर्यावरण
गेमप्ले ट्रिगर्स

उद्देश्य पदानुक्रम को भव्य बनाना नहीं है, बल्कि इसे उपयोगी बनाना है।

यदि आप एक सप्ताह दूर रहने के बाद दृश्य खोल सकते हैं और तुरंत समझ सकते हैं कि महत्वपूर्ण वस्तुएं कहाँ हैं, तो आपका पदानुक्रम अपना काम कर रहा है।

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

Entity गुण और टैग

Entities कस्टम गुण और टैग स्टोर कर सकती हैं।

उदाहरण के लिए, एक दुश्मन के पास हो सकता है:

• एक Damageable टैग।
• एक health गुण।
• एक team गुण।
• एक patrolRadius गुण।

स्क्रिप्ट और लॉजिक इस डेटा का उपयोग निर्णय लेने के लिए कर सकती हैं।

एक डैमेज सिस्टम ऐसी Entities की तलाश कर सकता है जिनके पास Damageable टैग हो। एक दुश्मन स्क्रिप्ट patrolRadius को पढ़ सकता है ताकि यह तय कर सके कि दुश्मन कितनी दूर घूम सकता है।

गुण और टैग आपको एक Entity को गेमप्ले का अर्थ जोड़ने की अनुमति देते हैं बिना हर छोटे डेटा के टुकड़े के लिए विशेष घटक की आवश्यकता के।

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

Entity टेम्पलेट पूर्वावलोकन

कुछ Entities Entity टेम्पलेट के उदाहरण होती हैं। उदाहरण के लिए, जो खिलाड़ी आप नए Cave प्रोजेक्ट में पाएंगे, वह यहाँ इस टेम्पलेट का एक उदाहरण है:

टेम्पलेट उदाहरणों को दृश्य ग्राफ़ में अलग दिखाया जाता है, Cave के टेम्पलेट रंग का उपयोग करके। इससे आपको यह पहचानने में मदद मिलती है कि Entity एक पुन: प्रयोज्य टेम्पलेट संपत्ति से आती है।

जब एक Entity एक टेम्पलेट उदाहरण होती है:

• इसके आंतरिक बच्चे टेम्पलेट से संबंधित होते हैं।
• रखी गई उदाहरण दृश्य से संबंधित होती है।
• टेम्पलेट संरचना को टेम्पलेट एसेट को खोलकर संपादित किया जा सकता है।
• स्थानीय मानों को संपत्तियों के रूप में प्रदर्शित होने पर अभी भी समायोजित किया जा सकता है।

अगला पाठ इकाई टेम्पलेट्स के बारे में अधिक विवरण बताता है।

इकाई मानसिक मॉडल

इकाई के बारे में सोचें जैसे एक छोटा कंटेनर:

• नाम आपको इसे समझने में मदद करता है।
• आईडी Cave को इसे ट्रैक करने में मदद करती है।
• सक्रिय स्थिति यह नियंत्रित करती है कि क्या यह भाग लेती है।
• पैरेंट यह नियंत्रित करता है कि यह कहाँ संबंधित है।
• घटक यह परिभाषित करते हैं कि यह क्या करता है।
• संपत्तियाँ और टैग अतिरिक्त गेमप्ले डेटा को वर्णित करते हैं।

यही Cave में दृश्य निर्माण का मूल है।

जब इकाइयाँ समझ में आने लगती हैं, तो दृश्य ग्राफ केवल वस्तुओं की सूची से कहीं अधिक बन जाता है। यह आपके खेल की दुनिया की संरचना बन जाता है।