यह कठिन है। मैं अपने विशेष अनुभवों (YMMV) पर आधारित कुछ सवालों से निपटने की कोशिश करूंगा:
घटकों को अन्य घटकों के डेटा का उपयोग करना चाहिए। जैसे रेंडर कंपोनेंट का ड्रा मेथड ट्रांसफॉर्म कंपोनेंट की पोजिशन तक पहुंचना चाहिए। यह कोड में निर्भरता बनाता है।
यहां युग्मन / निर्भरता की मात्रा और जटिलता (डिग्री नहीं) को कम मत समझो। आप इसके बीच अंतर को देख सकते हैं (और यह आरेख पहले से ही खिलौने जैसे स्तरों के लिए सरल रूप से सरल है, और वास्तविक दुनिया के उदाहरण में युग्मन ढीला करने के बीच में इंटरफेस होगा):
... और इस:
... या यह:
अवयव बहुरूपक हो सकते हैं जो आगे कुछ जटिलता का परिचय देते हैं। उदाहरण के लिए एक स्प्राइट रेंडर कंपोनेंट हो सकता है जो रेंडर कंपोनेंट के वर्चुअल ड्रॉ मेथड को ओवरराइड करता है।
इसलिए? एक व्यवहार्य और आभासी प्रेषण के समतुल्य (या शाब्दिक) सिस्टम के माध्यम से अपने अंतर्निहित स्थिति / डेटा को छिपाने के बजाय सिस्टम के माध्यम से मंगाया जा सकता है। बहुरूपता अभी भी बहुत ही व्यावहारिक और "शुद्ध 'ईसीएस कार्यान्वयन के साथ व्यवहार्य है जब अनुरूप व्यवहार्य या फ़ंक्शन पॉइंटर (एस) सिस्टम को आह्वान करने के लिए" डेटा "प्रकार में बदल जाता है।
चूंकि बहुरूपी व्यवहार (जैसे प्रतिपादन के लिए) को कहीं न कहीं लागू किया जाना है, यह सिर्फ सिस्टम में आउटसोर्स किया गया है। (जैसे स्प्राइट रेंडर सिस्टम एक स्प्राइट रेंडर नोड बनाता है जो रेंडर नोड को इनहेरिट करता है और इसे रेंडर इंजन में जोड़ता है)
इसलिए? मुझे उम्मीद है कि यह व्यंग्य के रूप में नहीं आ रहा है (मेरा इरादा नहीं है, हालांकि मुझे इसके बारे में अक्सर आरोप लगाया गया है, लेकिन मैं चाहता हूं कि मैं पाठ के माध्यम से भावनाओं को बेहतर ढंग से संवाद कर सकता हूं), लेकिन इस मामले में बहुरूपी व्यवहार "आउटसोर्सिंग" जरूरी नहीं है कि यह एक अतिरिक्त रूप से जरूरी नहीं है उत्पादकता की लागत।
सिस्टम के बीच संचार से बचना मुश्किल हो सकता है। उदाहरण के लिए, टकराव प्रणाली को बाउंडिंग बॉक्स की आवश्यकता हो सकती है, जो कि वहाँ जो भी ठोस रेंडर घटक है उससे गणना की जाती है।
यह उदाहरण मुझे विशेष रूप से अजीब लगता है। मुझे नहीं पता कि एक रेंडरर दृश्य में डेटा क्यों आउटपुट कर रहा होगा (मैं आमतौर पर रेंडरर्स को केवल इस संदर्भ में पढ़ता हूं), या रेंडरर को दोनों रेंडरर के लिए ऐसा करने के लिए कुछ अन्य सिस्टम के बजाय AABBs का पता लगाने के लिए और टक्कर / भौतिकी (मैं यहाँ "रेंडर घटक" नाम पर लटका दिया जा सकता है)। फिर भी मैं इस उदाहरण पर बहुत ज़्यादा नहीं पड़ना चाहता क्योंकि मुझे लगता है कि वह बिंदु नहीं है जिसे आप बनाने की कोशिश कर रहे हैं। अभी भी सिस्टम के बीच संचार (यहां तक कि केंद्रीय ईसीएस डेटाबेस को पढ़ने / लिखने के अप्रत्यक्ष रूप में सिस्टम के साथ सीधे दूसरों के द्वारा किए गए परिवर्तनों के आधार पर) अक्सर आवश्यक होने पर, अक्सर नहीं होना चाहिए। उस'
यदि सिस्टम के अपडेट फ़ंक्शंस को कॉल करने के क्रम को परिभाषित नहीं किया गया है, तो यह प्रीबल हो सकता है।
यह बिल्कुल परिभाषित किया जाना चाहिए। ईसीएस कोडबेस में हर संभव प्रणाली के सिस्टम प्रोसेसिंग मूल्यांकन क्रम को पुनर्व्यवस्थित करने के लिए अंत-सभी समाधान नहीं है और फ्रेम और एफपीएस के साथ काम करने वाले अंतिम उपयोगकर्ता को बिल्कुल उसी तरह के परिणाम मिलते हैं। यह चीजों में से एक है, जब एक ईसीएस डिजाइन करते हैं, कि मैं कम से कम दृढ़ता से सुझाव दूंगा, कुछ हद तक प्रत्याशित होना चाहिए (हालांकि बाद में इसे बदलने के लिए सांस लेने के कमरे को माफ करने के साथ, बशर्ते कि यह आदेश देने के सबसे महत्वपूर्ण पहलुओं को बदल नहीं रहा है सिस्टम मंगलाचरण / मूल्यांकन)।
हालांकि, पूरे फ्रेम को पुन: टीकमलेट करना हर फ्रेम महंगा है। इसलिए, सिस्टम में उन्हें अपडेट करने के लिए किए गए सभी परिवर्तनों पर नज़र रखने के लिए एक सूची की आवश्यकता होगी। ओओपी तरीके से इसे टाइल मैप घटक द्वारा समझाया जा सकता है। उदाहरण के लिए सेटटाइल () विधि वर्टेक्स ऐरे को अपडेट करेगी जब भी उसे बुलाया जाएगा।
मैं इसे काफी समझ नहीं पाया सिवाय इसके कि यह एक डेटा-उन्मुख चिंता है। और ऐसे प्रदर्शन नुकसान से बचने के लिए एक ईसीएस में डेटा का प्रतिनिधित्व और भंडारण के रूप में कोई नुकसान नहीं होते हैं, ऐसे प्रदर्शन नुकसान से बचने के लिए (ईसीएस के साथ सबसे बड़ी चीजें उन चीजों से संबंधित हैं जैसे कि विशेष घटक प्रकारों के उपलब्ध उदाहरणों के लिए क्वेरी करने वाली प्रणाली जो इनमें से एक है एक सामान्यीकृत ECS के अनुकूलन के सबसे चुनौतीपूर्ण पहलू)। तथ्य यह है कि तर्क और डेटा को एक "शुद्ध" ईसीएस में अलग किया जाता है, इसका मतलब यह नहीं है कि आपको अचानक उन चीजों को फिर से स्थापित करना होगा जिन्हें आप अन्यथा ओओपी प्रतिनिधित्व में कैश / मेमो कर सकते हैं। यह एक बहुत ही महत्वपूर्ण बात है जब तक कि मैं किसी चीज़ पर नज़र न रखूं, यह एक अप्रासंगिक / अप्रासंगिक बिंदु है।
"शुद्ध" ईसीएस के साथ आप अभी भी टाइल मैप घटक में इस डेटा को स्टोर कर सकते हैं। एकमात्र प्रमुख अंतर यह है कि इस शीर्ष सरणी को अपडेट करने के लिए तर्क कहीं न कहीं एक सिस्टम में चला जाएगा।
यदि आप एक अलग घटक बनाते हैं, तो आप इकाई से इस कैश के अमान्यकरण और निष्कासन को सरल बनाने के लिए ECS पर भी झुक सकते हैं TileMapCache। उस बिंदु पर जब कैश वांछित है, लेकिन एक TileMapघटक के साथ एक इकाई में उपलब्ध नहीं है , तो आप इसे गणना कर सकते हैं और इसे जोड़ सकते हैं। जब इसे अमान्य कर दिया जाता है या इसकी आवश्यकता नहीं होती है, तो आप विशेष रूप से ऐसे अमान्यकरण और निष्कासन के लिए अधिक कोड लिखने के बिना ईसीएस के माध्यम से इसे हटा सकते हैं।
घटकों के बीच निर्भरता अभी भी मौजूद है, हालांकि सिस्टम में दूर छिपा हुआ है
"शुद्ध" प्रतिनिधि में घटकों के बीच कोई निर्भरता नहीं है (मुझे नहीं लगता कि यह कहना सही है कि सिस्टम द्वारा निर्भरताएं यहां छिपाई जा रही हैं)। डेटा डेटा पर निर्भर नहीं करता है, इसलिए बोलने के लिए। तर्क पर निर्भर करता है तर्क। और एक "शुद्ध" ईसीएस तर्क को बढ़ावा देने के लिए एक तरह से लिखा जाता है ताकि डेटा और तर्क के निरपेक्ष न्यूनतम सबसेट पर निर्भर हो सके और तर्क (अक्सर कोई नहीं) एक प्रणाली को काम करने की आवश्यकता होती है, जो कई विकल्पों के विपरीत होती है जो अक्सर निर्भर करता है वास्तविक कार्य के लिए आवश्यकता से कहीं अधिक कार्यक्षमता। यदि आप शुद्ध ईसीएस का सही उपयोग कर रहे हैं, तो आपको सबसे पहले जिन चीजों की सराहना करनी चाहिए, उनमें से एक है डिकॉप्लिंग के फायदे, साथ ही साथ उन सभी चीजों पर सवाल उठाना जो आपने कभी ओप्स में सराहना करना सीखा था और विशेष रूप से जानकारी छिपाना।
डिकम्प्लिंग करके मेरा विशेष रूप से मतलब है कि आपके सिस्टम को काम करने की कितनी कम जानकारी चाहिए। आपकी गति प्रणाली को या तो कुछ और अधिक जटिल ( Particleया Characterसिस्टम के डेवलपर को भी आवश्यक नहीं है कि इस तरह के इकाई विचारों को भी सिस्टम में मौजूद होने की आवश्यकता है) के बारे में जानने की आवश्यकता न हो। यह सिर्फ एक स्थिति घटक की तरह नंगे न्यूनतम डेटा के बारे में जानने की जरूरत है जो किसी संरचना में कुछ तैरने जैसा सरल हो सकता है। यह कम जानकारी और कम बाहरी निर्भरता की तुलना में एक शुद्ध इंटरफ़ेस क्या IMotionइसके साथ ले जाने की प्रवृत्ति है। यह मुख्य रूप से इस न्यूनतम ज्ञान के कारण है कि प्रत्येक प्रणाली को काम करने की आवश्यकता होती है जो कि ईसीएस बनाता है ताकि सभी जगह पर कैस्केडिंग इंटरफ़ेस के टूटने का सामना किए बिना हिंडाइट में बहुत अप्रत्याशित डिजाइन परिवर्तनों को संभालने के लिए क्षमा कर सकें।
"अशुद्ध" दृष्टिकोण आपको सुझाव देता है कि कुछ हद तक लाभ कम हो जाता है क्योंकि अब तक आपके तर्क को सिस्टम में कड़ाई से स्थानीयकृत नहीं किया जाता है, जहां परिवर्तन कैस्केड टूटने का कारण नहीं बनते हैं। तर्क अब कई प्रणालियों द्वारा एक्सेस किए गए घटकों में कुछ हद तक केंद्रीकृत होगा, जिसे अब सभी विभिन्न प्रणालियों की इंटरफ़ेस आवश्यकताओं को पूरा करना होगा जो इसका उपयोग कर सकते हैं, और अब यह हर प्रणाली की तरह है, तो इसके बारे में ज्ञान (निर्भर) करने की आवश्यकता है जानकारी की तुलना में उस घटक के साथ काम करने की सख्त आवश्यकता है।
डेटा पर निर्भरता
ईसीएस के बारे में विवादास्पद चीजों में से एक यह है कि यह बदलने के लिए जाता है जो अन्यथा कच्चे डेटा के साथ अमूर्त इंटरफेस की निर्भरता हो सकती है, और इसे आमतौर पर युग्मन का कम वांछनीय और तंग रूप माना जाता है। लेकिन खेल जैसे डोमेन में जहां ईसीएस बहुत फायदेमंद हो सकता है, अक्सर डेटा प्रतिनिधित्व को डिज़ाइन करना आसान होता है और इसे स्थिर रखने की तुलना में यह डिज़ाइन करना है कि आप सिस्टम के कुछ केंद्रीय स्तर पर उस डेटा के साथ क्या कर सकते हैं। यही कारण है कि मैंने कुछ ऐसे अनुभवी दिग्गजों के बीच कोडबस में भी दर्द का अनुभव किया है, जो एक COM-शैली के शुद्ध इंटरफ़ेस दृष्टिकोण का अधिक उपयोग करते हैं जैसे कि चीजें IMotion।
डेवलपर्स ने इस केंद्रीय इंटरफ़ेस में फ़ंक्शंस को जोड़ने, हटाने या बदलने के लिए कारणों को खोजा, और प्रत्येक परिवर्तन को गंभीर और महंगा इसलिए बनाया गया क्योंकि यह हर एक वर्ग को तोड़ने के लिए IMotionइस्तेमाल करता था जो सिस्टम में हर एक जगह पर लागू होता था IMotion। इस बीच इतने सारे दर्दनाक और कैस्केडिंग परिवर्तनों के साथ पूरा समय, जिन वस्तुओं को लागू किया IMotionगया था, वे सभी सिर्फ 4x4 मैट्रिक्स की फ़्लोट्स का भंडारण कर रही थीं और पूरे इंटरफ़ेस को बस उन फ़्लोट्स को बदलने और एक्सेस करने के तरीके से संबंधित था; डेटा प्रतिनिधित्व शुरुआत से ही सभी तरह से स्थिर था, और अगर इस केंद्रीकृत इंटरफ़ेस से बहुत दर्द से बचा जा सकता था, तो अप्रत्याशित डिजाइन की जरूरतों के साथ बदलने की संभावना नहीं थी, पहली जगह में भी मौजूद नहीं था।
यह सभी वैश्विक चरों की तरह लगभग घृणित लग सकता है, लेकिन ईसीएस इस डेटा को सिस्टम के माध्यम से टाइप करके प्राप्त किए गए घटकों में स्पष्ट रूप से कैसे व्यवस्थित करता है, इस तरह से बनाता है, जबकि संकलक सूचना छिपाने, स्थानों पर पहुंच और उत्परिवर्तन जैसी किसी भी चीज को लागू नहीं कर सकते हैं। डेटा आमतौर पर बहुत स्पष्ट और स्पष्ट रूप से पर्याप्त हैं और अभी भी प्रभावी ढंग से आक्रमणकारियों को बनाए रखते हैं और भविष्यवाणी करते हैं कि किस प्रकार के परिवर्तन और साइड इफेक्ट्स एक सिस्टम से दूसरे पर जाते हैं (वास्तव में उन तरीकों से जो कुछ डोमेन में ओओपी की तुलना में सरल और अधिक अनुमानित हो सकते हैं कि कैसे प्रणाली एक सपाट प्रकार की पाइपलाइन में बदल जाती है)।
अंत में, मैं सवाल पूछना चाहता हूं कि मैं एक शुद्ध ईसीएस में एनीमेशन को कैसे संभालूंगा। वर्तमान में मैंने एक एनीमेशन को एक फ़नकार के रूप में परिभाषित किया है जो 0 और 1. के बीच कुछ प्रगति के आधार पर एक इकाई को हेरफेर करता है। एनीमेशन घटक में एनिमेटरों की एक सूची होती है जिसमें एनिमेशन की एक सूची होती है। अपने अद्यतन फ़ंक्शन में यह तब लागू होता है जो कुछ भी एनिमेशन वर्तमान में इकाई के लिए सक्रिय हैं।
हम सभी व्यावहारिक यहाँ हैं। यहां तक कि gamedev में आपको संभवतः परस्पर विरोधी विचार / उत्तर मिलेंगे। यहां तक कि शुद्धतम ईसीएस एक अपेक्षाकृत नई घटना है, अग्रणी क्षेत्र है, जिसके लिए लोगों ने जरूरी नहीं कि त्वचा बिल्लियों के लिए सबसे मजबूत राय तैयार की है। मेरी आंत प्रतिक्रिया एक एनीमेशन प्रणाली है जो इस तरह की एनीमेशन प्रगति को एनिमेटेड घटकों में प्रदर्शित करने के लिए रेंडरिंग सिस्टम को प्रदर्शित करने के लिए बढ़ाती है, लेकिन यह विशेष एप्लिकेशन और संदर्भ के लिए इतनी बारीकियों की अनदेखी कर रही है।
ECS के साथ, यह एक चांदी की गोली नहीं है और मैं अभी भी खुद को अंदर जाने और नई प्रणालियों को जोड़ने, कुछ को हटाने, नए घटकों को जोड़ने, एक मौजूदा प्रणाली को बदलने के लिए उस नए घटक प्रकार, इत्यादि के साथ खुद को नहीं पाता हूं। अभी भी पहली बार के आसपास सभी चीजें सही हैं। लेकिन मेरे मामले में अंतर यह है कि मैं कुछ भी केंद्रीय नहीं बदल रहा हूं जब मैं कुछ डिजाइन की जरूरतों को पूरा करने में विफल रहता हूं। मुझे कैस्केडिंग ब्रेकेज का रिपलिंग प्रभाव नहीं मिल रहा है, जिसके लिए मुझे पूरी जगह पर जाने और कुछ नई ज़रूरतों को संभालने के लिए इतना कोड बदलने की ज़रूरत है कि फसलों का विकास हो जाए, और यह काफी समय बचाने वाला है। मुझे अपने मस्तिष्क पर भी आसानी हो रही है क्योंकि जब मैं किसी विशेष प्रणाली के साथ बैठ जाता हूं, तो मुझे उस पर काम करने के लिए संबंधित घटकों (जो कि सिर्फ डेटा हैं) के अलावा कुछ और जानने / याद रखने की आवश्यकता नहीं है।