नमस्ते, हैकरनून! आज मैं एकता विकास में ईसीएस (इकाई-घटक-प्रणाली) पर चर्चा करना जारी रखता हूं। , मैंने चर्चा की कि ईसीएस (एंटिटी-कंपोनेंट-सिस्टम) क्या है, ईसीएस की आवश्यकता क्यों है, ईसीएस के साथ कैसे काम करें, यूनिटी में ईसीएस के फायदे, और में ईसीएस के नुकसान। यूनिटी में ईसीएस (एंटिटी-कंपोनेंट-सिस्टम) पर गाइड में: भाग 1 यूनिटी इस भाग में, मैं शुरुआती लोगों की गलतियों और यूनिटी गेम में ईसीएस का उपयोग करने की अच्छी प्रथाओं पर ध्यान केंद्रित करूंगा। मैं यूनिटी/सी# के लिए फ्रेमवर्क को भी थोड़ा कवर करूंगा। यूनिटी गेम में ईसीएस का उपयोग करते समय शुरुआती की गलतियाँ इस अनुभाग में, मैं आपको उन त्रुटियों के बारे में बताऊंगा जो अधिक अनुभवी लोगों ने मेरे पुराने कोड में देखीं और जिन्होंने मुझे विकसित होने से रोका। मैं उन त्रुटियों को भी कवर करूंगा जो कई शुरुआती लोग करते हैं जब वे ईसीएस में महारत हासिल करना शुरू करते हैं। मुझे आशा है कि इससे आपको कुछ बगों से बचने में मदद मिलेगी। घटक वंशानुक्रम और इंटरफ़ेस घटकों को इनहेरिट करना और इंटरफ़ेस का उपयोग करना शुरुआती लोगों द्वारा की गई एक व्यापक गलती है। तो यह एकता विकास के लिए बुरा क्यों है? 4 कारण: डेटा के माध्यम से ईसीएस एब्स्ट्रैक्शन की तुलना में घटक स्तर पर एब्स्ट्रैक्शन बिल्कुल कोई लाभ नहीं देता है यह आपके लिए सीमाएँ बनाता है: आपको ऐसे घटकों का विस्तार करना और संबंधित तर्क को परिष्कृत करना कठिन होगा यह ऐसी स्थिति की ओर ले जाता है जब किसी घटक का अपना तर्क होता है, जो, जैसा कि हमें याद है, ईसीएस सिद्धांतों का उल्लंघन है, जो आपको नहीं करना चाहिए। इससे सिस्टम को इनहेरिट करने या प्रकार के आधार पर सभी प्रकार के स्विच केस बनाने की अनुचित आवश्यकता होती है। मैं तुरंत नोट करूंगा कि इनहेरिटिंग सिस्टम हमेशा एक अच्छा विचार नहीं है, लेकिन यह घटक इनहेरिटेंस के विपरीत, कुछ भी भयानक नहीं करता है। इसलिए यदि आप घटकों को विरासत में प्राप्त करना चाहते हैं, तो ऐसा न करें। इस बारे में दोबारा सोचें कि आप समस्या को दूसरे तरीके से कैसे हल कर सकते हैं। ईसीएस एब्स्ट्रैक्शन का ठीक से उपयोग करने में असमर्थता ईसीएस एब्स्ट्रैक्शन तब होता है जब आप सामान्य डेटा (जिसे ओओपी में विरासत में मिलना चाहिए) को एक अलग घटक में डालते हैं। आप बस अपने आवश्यक डेटा के साथ एक नया घटक जोड़कर और और के साथ इकाइयों को फ़िल्टर करके ऐसे घटक का "उत्तराधिकारी" बनाते हैं। सब कुछ प्राथमिक है. यदि आपके पास घटकों/इकाइयों के बीच कुछ सामान्य डेटा है, तो आप लगभग हमेशा उन्हें एक अलग घटक में रख सकते हैं। आप इसे जितनी जल्दी करेंगे, उतना बेहतर होगा। BaseComponent InheritorComponent तर्क को बदलने के लिए सिस्टम को सक्षम/अक्षम करना ईसीएस में, दुनिया और इसे संसाधित करने वाली प्रणालियाँ स्थिर हैं और हमेशा मौजूद रहती हैं, लेकिन संस्थाएँ और उनका डेटा बहुत गतिशील हैं। और यदि आपको कुछ तर्क को अक्षम करने की आवश्यकता है, तो सिस्टम को अक्षम करना सही समाधान नहीं है। अक्सर अन्य प्रणालियों तक पहुंच नहीं होती (और यह अच्छी बात है)। कुछ मार्कर घटक बनाना एक अधिक व्यावहारिक विकल्प है। यह कहेगा कि सिस्टम लॉजिक को मार्कर वाली इकाई के लिए काम नहीं करना चाहिए। कई नवागंतुक दावा करते हैं: "लेकिन अगर मेरे पास सिस्टम के लिए इकाइयां नहीं हैं, तो सिस्टम को काम क्यों करना चाहिए? क्या अनुकूलन के लिए इसे बंद करना बेहतर नहीं होगा?" नहीं, यह बेहतर नहीं है. यदि आप स्वीकार करते हैं कि कोई इकाई नहीं हो सकती है, तो यह जोड़ना आसान है सिस्टम की मुख्य विधि की शुरुआत तक। के पैमाने में, एक फ़ंक्शन को कॉल करना और दो इंट्स की तुलना करना समुद्र में एक बूंद है जो किसी भी तरह से आपके प्रदर्शन को प्रभावित नहीं करेगा। if (entities.Length < 1) return; यूनिटी गेम रनटाइम में सिस्टम को अक्षम करने का एकमात्र वैध मामला ए/बी परीक्षण और विशिष्ट सिस्टम का डिबगिंग/परीक्षण है। हालाँकि, अधिकांश फ्रेमवर्क कोड से नहीं बल्कि संपादक विंडो से ऐसा करने के लिए उपकरण प्रदान करते हैं। ईसीएस को पूर्ण बनाना यह याद रखना चाहिए कि ईसीएस अनुयायियों के लिए ओओपी निषिद्ध नहीं है: डी ईसीएस के साथ काम करते समय, आपको पूरी तरह से ईसीएस के प्रति आसक्त नहीं होना चाहिए और सब कुछ इसमें स्थानांतरित नहीं करना चाहिए क्योंकि यह प्रतिकूल हो सकता है। इसके अलावा, जैसा कि मैंने में उल्लेख किया है: सभी डेटा संरचनाएं ईसीएस पर अच्छी तरह से फिट नहीं होती हैं। इसलिए ऐसे मामलों में एक अलग OOP क्लास बनाना ही बेहतर है। ईसीएस के नुकसानों कुछ आगे बढ़ते हैं और प्रोजेक्ट के कुछ तत्वों (उदाहरण के लिए, यूआई) को ईसीएस के अनुसार नहीं, बल्कि किसी अन्य सुविधाजनक तरीके से थोड़ा अलग बनाते हैं और फिर किसी ब्रिज द्वारा ईसीएस से जुड़ते हैं। इसके अलावा, सभी अतिरिक्त तर्क (कॉन्फ़िगरेशन लोड करना, नेटवर्क के साथ सीधा काम करना, फ़ाइल में सहेजना) ओओपी बनाना और वांछित सिस्टम से सीधे इसके साथ काम करना आसान है। यूनिटी डेवलपर्स आपको सामान्य ज्ञान के आधार पर यह चुनना चाहिए कि क्या करना है। ईसीएस को विकास में मदद करनी चाहिए, बाधा नहीं डालनी चाहिए। मौजूदा कोड को बिना किसी बदलाव के ईसीएस में पोर्ट करने का प्रयास किया जा रहा है बहुत बार, शुरुआती लोग अपने मौजूदा कोड को शब्दशः ईसीएस में स्थानांतरित करने का प्रयास करते हैं। यह एक अच्छा विचार नहीं है क्योंकि ईसीएस का कोड लिखने का दृष्टिकोण पारंपरिक वास्तुशिल्प पैटर्न से भिन्न है। ऐसी पोर्टिंग का नतीजा आम तौर पर ईसीएस से गड़बड़ी और बहुत खराब अंतिम कोड होता है। यदि आपको पुराने कोड को ईसीएस में पोर्ट करने की आवश्यकता है, तो सबसे अच्छा विकल्प ईसीएस पर स्क्रैच से वही तर्क लिखना है। आपको बस अपने ज्ञान और मौजूदा कोड को एक मार्गदर्शक के रूप में उपयोग करना है। सिस्टम में डेलीगेट्स/कॉलबैक या प्रतिक्रियाशील तर्क का उपयोग करना ईसीएस में, सिस्टम से कुछ तर्क लेना और बाद में उपयोग के लिए इसे एक घटक में संग्रहीत करना या कुछ बदलावों पर तुरंत प्रतिक्रिया करना खतरनाक हो सकता है (उदाहरण के लिए, एक सिस्टम किसी अन्य सिस्टम में एक घटक जोड़ने पर प्रतिक्रिया करता है)। यह न केवल सिस्टम में अनावश्यक इंटरकनेक्टिविटी जोड़ता है (वे बाहरी कॉल पर अत्यधिक निर्भर हो जाते हैं)। यह यह तर्क जोड़कर हमारी सुंदर डेटा प्रोसेसिंग पाइपलाइन को भी तोड़ देता है कि कॉलिंग पर हमारा बहुत कम नियंत्रण है। फ़ाइलों को प्रकार के अनुसार फ़ोल्डरों में व्यवस्थित करना जब आप ईसीएस के साथ काम करना शुरू करते हैं, तो आप सबसे पहले प्रकार के अनुसार नई फ़ाइलें डालना चाहते हैं: घटक फ़ोल्डर में घटक और सिस्टम फ़ोल्डर में सिस्टम। लेकिन अनुभव के साथ, मुझे एहसास हुआ कि छँटाई का यह तरीका कुशल नहीं है। यह समझना आसान नहीं है कि कौन से घटक किस सिस्टम से संबंधित हैं। सबसे अच्छा विकल्प सुविधाओं के आधार पर क्रमबद्ध करना है जब किसी विशेष सुविधा से संबंधित सब कुछ एक फ़ोल्डर में हो (शायद घटकों/प्रणालियों के आंतरिक पदानुक्रम के साथ)। अर्थात्, स्वास्थ्य और क्षति से संबंधित सभी घटक और प्रणालियाँ स्वास्थ्य फ़ोल्डर में होंगी। इससे किसी को सिस्टम के बुनियादी डेटा संदर्भ को समझने के लिए फ़ोल्डर को देखने की अनुमति मिल जाएगी और प्रोजेक्ट को नेविगेट करना आसान हो जाएगा। यूनिटी गेम में ईसीएस का उपयोग करने के लिए सर्वोत्तम अभ्यास ऊपर, आपने शायद पढ़ा होगा कि ईसीएस पर यूनिटी गेम विकसित करते समय क्या नहीं करना चाहिए। अब आप क्या कर सकते हैं, इस पर उपयोगी प्रथाओं और युक्तियों के बारे में बात करते हैं। मार्कर घटकों के साथ संस्थाओं को टैग करना ईसीएस में टैग घटक जैसी कोई अवधारणा होती है। यह एक फ़ील्ड रहित घटक है जो केवल इकाई टैगिंग की भूमिका निभाता है। आप इसे किसी कक्षा में बूलियन ध्वज के रूप में सोच सकते हैं: यह या तो वहां है (सत्य) या वहां नहीं है (गलत)। उदाहरण के लिए, हमारे पास एक हजार इकाइयाँ हैं, जिनमें से एक को खिलाड़ी नियंत्रित करता है। आप इसे खाली घटक से चिह्नित कर सकते हैं। यह आपको फ़िल्टर में केवल प्लेयर इकाइयों को प्राप्त करने की अनुमति देगा और साथ ही यह समझने में भी मदद करेगा कि आप एक नियमित या प्लेयर-नियंत्रित यूनिट के साथ काम कर रहे हैं जब आप एक साथ सभी इकाइयों से गुजरते हैं। PlayerMarker उन स्थानों को छोटा करना जहां घटक बदलता है जितने कम स्थान पर कोई घटक बदलता है, उतना बेहतर होता है। सामान्य तौर पर, यह डोंट रिपीट योरसेल्फ (मैं हर किसी को इसकी अनुशंसा करता हूं) के लाभकारी सिद्धांत का पालन करने जैसा है। इसका अभ्यास करने के कई फायदे हैं: यह आपको अपने प्रोजेक्ट में डेटा बदलने की प्रक्रिया को बेहतर ढंग से समझने की अनुमति देता है और कुछ गलत होने पर डिबगिंग को सरल बनाता है डेटा परिवर्तनों के तर्क को अपडेट करते समय, आपको कम कोड अपडेट करने की आवश्यकता होगी, आदर्श रूप से केवल एक ही स्थान पर डेटा बग के तुरंत घटित होने की संभावना कम है उदाहरण के लिए, नुकसान वाले हर सिस्टम में हेल्थकंपोनेंट को बदलने के बजाय, एक डैमेजसिस्टम बनाना बेहतर होगा जिसका उद्देश्य हेल्थकंपोनेंट के साथ संस्थाओं को नुकसान पहुंचाना है। कंपोनेंट पोस्टफिक्स के बारे में भूल जाना कंपोनेंट पोस्टफ़िक्स शुरुआती लोगों के लिए बहुत उपयोगी है क्योंकि यह उन्हें याद दिलाता है कि "केवल डेटा यहाँ है"। लेकिन समय के साथ, याद दिलाने की आवश्यकता गायब हो जाती है, और सर्वव्यापी घटक के साथ कोड को समझना कठिन रहता है। इसलिए मैं सलाह देना चाहूंगा: आप कंपोनेंट पोस्टफ़िक्स के बारे में सुरक्षित रूप से भूल सकते हैं। शायद, IntelliSense में खोज के कुछ सरलीकरण के अलावा यह कुछ भी उपयोगी प्रदान नहीं करता है। यह सिर्फ एक टिप है और शायद स्वाद का मामला भी है, इसलिए यह आप पर निर्भर है कि आप इससे कैसे निपटते हैं :) उदाहरण के लिए, सिर्फ बन जाता है, और कोड थोड़ा अधिक पठनीय बन जाता है। इस मामले में अपरिवर्तित रहता है क्योंकि पोस्टफ़िक्स इस मामले में उपयोगी जानकारी रखता है, यह देखते हुए कि यह एक साधारण घटक नहीं है। HealthComponent Health entity.Has<Health>() PlayerMarker विलंबित प्रतिक्रियाशीलता और एकल-फ़्रेम घटक ईसीएस में प्रतिक्रियाशीलता हानिकारक हो सकती है। लेकिन जब प्रतिक्रियाशीलता की आवश्यकता हो तो क्या करें? उत्तर विलंबित प्रतिक्रिया है। विलंबित प्रतिक्रिया तब होती है जब आप घटना के समय सीधे तर्क को कॉल करने के बजाय, डेटा बनाते हैं कि घटना घटित हो चुकी है, और हर कोई घटना पर उसी समय प्रतिक्रिया करेगा जब वे चाहते हैं। मैं ओओपी में डर्टी फ़्लैग का एक सादृश्य बना सकता हूं, जहां कोई भी ईवेंट घोषित कर सकता है, लेकिन तर्क उस ईवेंट पर तब प्रतिक्रिया करेगा जब उसे उचित लगेगा। SetDirty(true) ईसीएस में, आप बस डेटा के साथ या उसके बिना एक घटक बनाते हैं (आप मौजूदा घटक में बस एक बूलियन ध्वज जोड़ सकते हैं) जिसे सिस्टम समय आने पर संसाधित करेगा। ऐसे घटकों का दुनिया में मौजूद होना असामान्य बात नहीं है, केवल एक फ्रेम के लिए सभी प्रणालियों को सचेत करना लेकिन अगले फ्रेम में तर्क को दोहराना नहीं। निष्कासन को या तो ईवेंट उत्पन्न करने वाले सिस्टम द्वारा या किसी अलग सिस्टम द्वारा नियंत्रित किया जा सकता है जो कि एक्स प्रकार के सभी घटकों को हटा देगा जहां आप चाहते हैं। उदाहरण के लिए, आपके पास एक है। यह बताने के लिए कि कितना नुकसान करना है, आप नुकसान की मात्रा के साथ घोषित करते हैं और इसे उस इकाई में जोड़ते हैं जिसे नुकसान उठाना चाहिए। और के साथ सभी इकाइयों के माध्यम से चलता है, इकाई को नुकसान पहुंचाता है, हटा देता है और एक बनाता है जो क्षतिग्रस्त इकाई के के बाद सभी सिस्टम को सूचित करता है। फ़्रेम के अंत में, व्यक्तिगत सिस्टम हटा देता है ताकि सिस्टम इस मार्कर को अगले फ्रेम में फिर से संसाधित न करें। DamageSystem MakeDamageComponent DamageSystem HealthComponent MakeDamageComponent MakeDamageComponent DamagedEntityMarker DamageSystem DamagedEntityMarker सिस्टम के लिए एपीआई के रूप में अनुरोध/घटनाएँ एकल-फ़्रेम घटकों के विचार को विकसित करते हुए, हम सिस्टम के लिए एक प्रकार की एपीआई को व्यक्त करने के लिए उनका उपयोग कर सकते हैं। हमें ईवेंट के बारे में सभी को सूचित करने के लिए बाहरी अनुरोधों के लिए अनुरोध घटकों और ईवेंट घटकों के बीच अंतर करना चाहिए। सिस्टम स्वयं दोनों घटकों के जीवनचक्र को नियंत्रित कर सकता है। नए ईवेंट लॉन्च करने से पहले ईवेंट को संसाधित करने और साफ़ करने के तुरंत बाद अनुरोधों को हटाना संभव है। यह आप पर निर्भर करता है कि उन्हें वास्तव में कैसे नाम दिया जाए और अनुरोध/ईवेंट पोस्टफ़िक्स जोड़ा जाए या नहीं। उदाहरण के लिए, आपके पास पिछले पैराग्राफ से है। आप घटक का उपयोग करके इसके लिए क्षति अनुरोध व्यक्त कर सकते हैं और अन्य सिस्टम को सूचित करने के लिए घटक का उपयोग कर सकते हैं। सिस्टम के अंदर तर्क इस प्रकार है: अंतिम फ्रेम से सभी साफ़ करें, एक अनुरोध के साथ सभी इकाइयों को नुकसान पहुंचाएं, अनुरोध हटाएं और घटक जोड़ें। DamageSystem MakeDamageRequest DamagedEntityEvent DamagedEntityEvent DamagedEntityEvent एक घटक के भीतर किसी अन्य इकाई का संदर्भ संग्रहीत करना आपके पास संभवतः एक प्रश्न है "ईसीएस में इकाइयों के बीच संबंध कैसे बनाएं? क्या इकाइयों को घटकों के साथ चिह्नित करना और फिर उन्हें लूप में खोजना आवश्यक है?" बिल्कुल नहीं। सब कुछ बहुत सरल और अधिक सामान्य है: हम केवल संदर्भ सहेजते हैं। अंतर केवल इतना है कि संदर्भ किसी अन्य इकाई के किसी घटक का नहीं है जिसमें हम रुचि रखते हैं, बल्कि इकाई का ही संदर्भ है। तो, आप घटक में इकाई के साथ एक फ़ील्ड जोड़ते हैं (या जिस भी तरीके से आपका ढांचा इकाइयों को संग्रहीत करता है)। इसका उपयोग करने से पहले, आप जांच लें कि इकाई जीवित है और उसमें वांछित घटक है। फिर आप इस घटक को प्राप्त करें और अपनी इच्छानुसार इसके साथ काम करें। उदाहरण के लिए, आप सीधे इकाई पर नहीं बना सकते हैं बल्कि लक्ष्य इकाई के संदर्भ में इसे एक अलग इकाई ईवेंट के रूप में चला सकते हैं। ऐसा करने के लिए, आप फ़ील्ड को में जोड़ें और पर फिर से काम करें। अब इसे सभी अनुरोधों से गुजरना चाहिए, जांचना चाहिए कि लक्ष्य एक के साथ एक जीवित इकाई है, प्राप्त करें और नुकसान करें। MakeDamageRequest Entity target MakeDamageRequest DamageSystem HealthComponent HealthComponent चलाना अब भी अलग दिखेगा। घटक को सीधे इकाई में जोड़ने के बजाय, आप के साथ एक नई इकाई बनाते हैं और निर्दिष्ट करते हैं। इस तरह, फ़िल्टरिंग सुविधा की कीमत पर, आप एक ही इकाई के लिए कई अलग-अलग क्षति की घटनाओं को ट्रिगर कर सकते हैं। MakeDamageRequest MakeDamageRequest target target दोहराव वाले तर्क को स्टेटिकयूटिल्स/एक्सटेंशन में ले जाना समय के साथ, आप यह देखना शुरू कर देते हैं कि आप विभिन्न प्रणालियों पर एक ही तर्क चला रहे हैं। आमतौर पर, यह एक संकेत है कि एक नई प्रणाली बनाने का समय आ गया है :D लेकिन ऐसा होता है कि दोहराया गया तर्क गौण होता है, एक या दो विशिष्ट घटकों/इकाइयों से संबंधित होता है, और इसका परिणाम विभिन्न उद्देश्यों के लिए उपयोग किया जाता है। मान लीजिए, किसी घटक में डेटा की एक विशेष व्याख्या। कुछ डेवलपर्स ऐसे अतिरिक्त तर्क को सीधे घटक में घोषित करने की अनुमति देते हैं (उदाहरण के लिए, गेटर्स के रूप में)। लेकिन ईसीएस के उल्लंघन से बचने के लिए, मैं एक और विकल्प सुझाता हूं: स्थिर उपयोगिताएं (या सी# में एक्सटेंशन) जिन्हें हम सिस्टम से कॉल करते हैं। उदाहरण के लिए, हमारे पास एक है। इसके अंदर एक टीम कलर स्थित होता है. यह जाँचना कि दो इकाइयाँ एक ही टीम से संबंधित हैं, कई प्रणालियों में आवश्यक हो सकती हैं। इसलिए हम एक स्थिर वर्ग और उसमें एक विधि बनाते हैं, जो दो संस्थाओं के लिए टीमों की तुलना करने के आवर्ती तर्क का वर्णन करता है। InTeamComponent TeamUtils IsInSameTeam(Entity, Entity) निष्पादन के क्षण तक सिस्टम को समूहीकृत करना जैसा कि आप पहले से ही जानते हैं, ईसीएस में सिस्टम को कॉल करने का क्रम महत्वपूर्ण है। इसलिए, सिस्टम को शीर्ष स्तर पर उस क्रम के अनुसार समूहित करना सुविधाजनक है जिसमें उन्हें एक फ्रेम में बुलाया जाता है। उदाहरण के लिए, एक फ्रेम में बुलाए जाने वाले पहले सिस्टम सभी इनपुट-संबंधित सिस्टम हो सकते हैं। वे उपयोगकर्ता इनपुट एकत्र करेंगे और इसे ईसीएस प्रारूप में तैयार करेंगे। दूसरी पंक्ति में गेम लॉजिक के साथ सिस्टम का एक समूह होगा, जो इनपुट डेटा की अपने तरीके से व्याख्या करेगा और ईसीएस दुनिया को अपडेट करेगा। और अंत में, हमारे पास रेंडरिंग के लिए जिम्मेदार सिस्टम का एक समूह हो सकता है या बस विभिन्न अतिरिक्त चीजें हो सकती हैं जिन्हें सभी गेम लॉजिक के बाद बुलाया जाना चाहिए। प्रमुख विशेषताओं को अलग-अलग असेंबली में अलग करना यह दृष्टिकोण सुविधाओं को एक-दूसरे से अलग करेगा और उनकी निर्भरता को नियंत्रित करेगा। एक आदर्श दुनिया में, उन्हें बिल्कुल भी ओवरलैप नहीं होना चाहिए। सुविधाओं के बीच का क्रम महत्वहीन होना चाहिए. एक कोर असेंबली भी होनी चाहिए जहां काम करने के लिए आवश्यक सभी सुविधाओं के घटक स्थित होने चाहिए। क्या मुझे ईसीएस में घटकों/प्रणालियों को छोटे टुकड़ों में विभाजित करना चाहिए? यह प्रश्न बहुत दिलचस्प है क्योंकि विभिन्न अनुभवों वाले यूनिटी डेवलपर्स की इस पर अलग-अलग राय है। लेकिन मैं आपकी ज़रूरतों को समझने में मदद करने के लिए दोनों उत्तरों को शामिल करने का प्रयास करूँगा। हां, घटकों को विभाजित करना हमेशा आवश्यक होता है ईसीएस संगठन में इस दृष्टिकोण को परमाणु कहा जा सकता है। इस दृष्टिकोण की सर्वोच्च डिग्री यह है कि प्रत्येक घटक में केवल एक क्षेत्र होता है। यह हमें प्रोजेक्ट के कॉम्बिनेटरिक्स के शिखर तक पहुंचने और ईसीएस एब्स्ट्रैक्शन के नाम पर रीफैक्टरिंग की आवश्यकता को खत्म करने की अनुमति देगा। हम अब "एक्स प्रॉपर्टी के साथ इकाइयों को कैसे संयोजित करें" के बारे में नहीं सोच सकते। ईसीएस में घटकों को हमेशा विभाजित करने के नुकसान: यदि आप प्रोजेक्ट संगठन पर उचित ध्यान नहीं देते हैं तो कक्षाओं और फ़ाइलों की संख्या बढ़ जाएगी, जिससे बड़ी परियोजनाओं पर भ्रम पैदा हो सकता है घटकों की संख्या (सामान्य तौर पर या प्रति इकाई) आपके ढांचे के प्रदर्शन को प्रभावित कर सकती है गुणों के समूह द्वारा यह समझना कठिन है कि एक इकाई क्या है (जिसे सामान्य नाम वाले मार्कर द्वारा हल किया जा सकता है) अब दूसरी राय पर चलते हैं। नहीं, आपको केवल आवश्यकता पड़ने पर ही घटकों को विभाजित करना चाहिए इस सिद्धांत को "समय से पहले विभाजित न हों" कहा जाता है। यह वह सिद्धांत है जिसका मैं व्यक्तिगत रूप से पालन करता हूं। जब आपको डेटा को विभाजित करने की आवश्यकता होती है, तो मीट्रिक सरल होती है: क्या इस डेटा का उपयोग इस घटक के अलावा कहीं और उपयोग करने की योजना बनाई गई है? यदि नहीं, तो इस पर समय बर्बाद करने का कोई कारण नहीं है। आप सिस्टम में तर्क को विभाजित करने के लिए एक समान दृष्टिकोण अपना सकते हैं। आवश्यकता पड़ने पर ही ईसीएस में घटकों को विभाजित करने के नुकसान: ईसीएस अमूर्तन पर अभी भी समय व्यतीत करना होगा संस्थाओं को डिज़ाइन करने की कम स्वतंत्रता अपना पक्ष चुनना आप पर निर्भर है :) यूनिटी/सी# के लिए फ्रेमवर्क यदि आप नौसिखिया हैं, तो मैं मान लूंगा कि आप सबसे पहले यूनिटी डॉट्स सीखने के बारे में सोच रहे हैं। लेकिन मैं आपको चेतावनी देना चाहता हूं. यूनिटी डॉट्स शुरुआती लोगों के लिए अच्छा विकल्प नहीं है क्योंकि यह बहुत बड़ा और जटिल है। इस पर उतने दस्तावेज़ और अनुभवी लोग नहीं हैं जितने हम चाहते हैं। इसके अलावा, यह पुराने यूनिटी कोड के साथ अच्छी तरह से संगत नहीं है (इस लेख को प्रकाशित करने के बाद यह सब बदल सकता है)। यदि आपको यूनिटी एडिटर पसंद है और आप पहले से ही घटकों को सीधे गेमऑब्जेक्ट्स पर लटकाने के आदी हैं, तो आपकी सबसे अच्छी पसंद है। यह सरल एपीआई, यूनिटी एडिटर में सख्त एकीकरण (यह यूनिटी के बाहर काम कर सकता है), और मोनोबिहेवियर के साथ सुविधाजनक काम प्रदान करता है। यह सरल और सुविधाजनक है. यूनिटी के साथ काम करने के लिए आपको जो कुछ भी चाहिए वह इसमें है। आप बस इसे इंस्टॉल करें और इसके साथ काम करें। इसका मुख्य नुकसान यह है कि यूनिटी में पूरी तरह से काम करने के लिए एक वेतनभोगी आवश्यकता होती है। मोरपेह ओडिन इंस्पेक्टर की एंटिटास और डॉट्स (यूनिटी ईसीएस): क्या आपको उनमें महारत हासिल करनी चाहिए? और अब यूनिटी/सी# फ्रेमवर्क की एक संक्षिप्त समीक्षा, जिनसे मैं व्यक्तिगत रूप से मिला हूं और मैंने क्या फायदे/नुकसान देखे हैं। यह ध्यान देने योग्य है कि इस लेख के प्रकाशन के बाद से नीचे वर्णित सभी चीजें बदल सकती हैं, इसलिए बेहतर होगा कि आप स्वयं रूपरेखाओं की जांच करें। एंटिटास यह यूनिटी/सी# के लिए सबसे पुराना ईसीएस फ्रेमवर्क है और अभी भी सबसे लोकप्रिय है। यह ईसीएस के साथ नौकरी पोस्टिंग में सबसे अधिक बार देखा जाता है। एंटिटास पेशेवर: यूनिटी संपादक में महान विश्वदर्शक धाराप्रवाह कोड शैली (कोड जनरेशन के लिए धन्यवाद) अच्छा दस्तावेज़ीकरण बहुत बड़ा समुदाय इस पर कई सफल परियोजनाएँ डेवलपर से अनिवार्य समर्थन (एसेटस्टोर को धन्यवाद) शुद्ध C# में यूनिटी के बाहर उपयोग किया जा सकता है एंटिटास विपक्ष: अन्य ईसीएस फ्रेमवर्क की तुलना में खराब प्रदर्शन (लेकिन फिर भी मोनोबिहेवियर से बेहतर) बहुत सारे आवंटन, जो जीसी को नकारात्मक रूप से प्रभावित करते हैं घटक संरचना में प्रत्येक परिवर्तन के लिए कोड जनरेशन की आवश्यकता होती है बड़ी परियोजनाओं पर, कोड जनरेशन के कारण एपीआई बहुत फूला हुआ हो जाता है जीथब संस्करण संकलन त्रुटियों पर कोड जनरेशन को कॉल करने की अनुमति नहीं देता है, जबकि एसेटस्टोर संस्करण ऐसा करता है आपको कम से कम बुनियादी स्तर पर इसमें महारत हासिल करनी चाहिए। डॉट्स (एकता ईसीएस) मुझे लगता है कि इसे किसी परिचय की आवश्यकता नहीं है। डॉट्स एक ढांचा नहीं है बल्कि एक पूर्ण विकसित मंच (प्रौद्योगिकी स्टैक) है जिसमें यूनिटी ईसीएस एक ढांचे के रूप में है। मैं बताना चाहूंगा कि निम्नलिखित कुछ हद तक पुराना अनुभव है। मैं मानता हूं कि एक अद्यतन डॉट्स नीचे वर्णित समस्याओं से छुटकारा दिला सकता है। डॉट्स (यूनिटी ईसीएस) पेशेवर: ईसीएस पर विकास के लिए एक पूर्ण मंच संपादक में सबसे सख्त संभव एकीकरण के साथ इंजन डेवलपर्स द्वारा निर्मित जॉब्स और बर्स्ट का समर्थन करता है जॉब्स और बर्स्ट के साथ, यह ईसीएस फ्रेमवर्क के बीच अधिकतम प्रदर्शन प्राप्त करता है। नेटकोड भविष्यवाणियों के साथ एक उत्कृष्ट नेटवर्क लाइब्रेरी है उपदृश्य तंत्र डॉट्स (यूनिटी ईसीएस) विपक्ष: कार्य प्रगति पर है, जिससे पुराने कोड परिवर्तन और ताजा बग को खत्म किया जा सकता है कमजोर दस्तावेज़ीकरण, जो अक्सर बदलावों के साथ तालमेल नहीं बिठा पाता, आपको स्रोत कोड पढ़ना होगा एनालॉग्स की तुलना में अधिक तकनीकी कोड लिखने की आवश्यकता होती है कोड को पढ़ना कठिन है और संक्षिप्त होने से बहुत दूर है बर्स्ट/जॉब्स के बिना ओपन-सोर्स समाधानों की तुलना में तेज़ काम नहीं करता (और कुछ मामलों में धीमा) पुराने यूनिटी कोड के साथ ठीक से फिट नहीं बैठता DOTS अनिवार्य रूप से एक रनटाइम है, और सभी पुरानी कार्यक्षमताओं को DOTS में पोर्ट नहीं किया गया है। इससे उपयोग की संभावनाएँ सीमित हो जाती हैं। एकता में ईसीएस पर निष्कर्ष जैसा कि आपने नुकसान की बड़ी सूची से देखा होगा, ईसीएस कोई चांदी की गोली नहीं है। इस वास्तुशिल्प समाधान के, किसी भी अन्य की तरह, इसके फायदे और नुकसान हैं जिन्हें आपको सहना होगा यदि आप इस वास्तुशिल्प पैटर्न का उपयोग करके विकास करना चुनते हैं। इसलिए अपनी परियोजनाओं में ईसीएस का उपयोग करना या न करना पूरी तरह आप पर निर्भर है। मैं दृढ़तापूर्वक अनुशंसा करता हूं कि आप यह समझने के लिए कम से कम ईसीएस पर एक छोटा प्रोजेक्ट करने का प्रयास करें कि आपको यह दृष्टिकोण पसंद है या नहीं। मैं यह भी सुझाव देता हूं कि आप इस पर एक नजर डालें, जहां ईसीएस से संबंधित कई सवालों के जवाब हैं। आपको रिपोर्ट के लिंक, विभिन्न भाषाओं के लिए रूपरेखाओं की एक सूची, साथ ही ईसीएस का उपयोग करने वाले गेम और प्रोग्राम के उदाहरण मिलेंगे। रिपॉजिटरी मेरे व्यक्तिगत दृष्टिकोण से, ईसीएस यूनिटी गेम बनाने के लिए एक बढ़िया विकल्प प्रतीत होता है। इस पर विकास, मेरे लिए व्यक्तिगत रूप से, एक खुशी है: आप एक गेम विकसित कर रहे हैं, यह पता लगाने की कोशिश नहीं कर रहे हैं कि बिना कुछ तोड़े पुराने सिस्टम में नए कोड को कैसे एकीकृत किया जाए। यह ध्यान में रखने योग्य है कि ईसीएस विकास की उपयोगिता ढांचे की पसंद से बहुत प्रभावित होती है, इसलिए विभिन्न विकल्पों को आज़माएं और सावधानी से चुनें। अपने अनुभव के आधार पर, मुझे लगता है कि ईसीएस (या इसकी भिन्नता) इंटरैक्टिव गेम विकास का भविष्य है। और सिर्फ इसलिए नहीं कि (और शायद एपिक भी) ने इसे अपने मुख्य फोकस के रूप में चुना है, बल्कि सिर्फ इसलिए कि ईसीएस के खेल विकास के संदर्भ में लाभप्रद लाभ हैं। यूनिटी टेक्नोलॉजीज और सामान्य तौर पर, यह एक व्यावहारिक दृष्टिकोण है जो शुरुआत में अजीब लगता है लेकिन लंबे समय में फायदेमंद होता है।
