एक इकाई घटक प्रणाली में "बूँद-सिस्टम" से कैसे बचें?


10

वर्तमान में मैं निम्नलिखित समस्या का सामना कर रहा हूँ:

मैं एक इकाई घटक प्रणाली (ईसीएस) का उपयोग करके एक पोंग क्लोन लिखने की कोशिश कर रहा हूं । मैंने अपने आप से "रूपरेखा" लिखी। तो एक वर्ग है जो सभी घटकों के साथ संस्थाओं का प्रबंधन करता है। फिर स्वयं घटक वर्ग हैं। और अंत में मेरे सिस्टम हैं जो बस उन सभी संस्थाओं को प्राप्त करते हैं जिनके पास घटक हैं जो सिस्टम को चाहिए।

इसलिए उदाहरण के लिए मेरी आंदोलन प्रणाली उन सभी संस्थाओं की तलाश करती है जिनमें एक स्थिति घटक और एक आंदोलन घटक होता है। स्थिति घटक बस स्थिति रखता है और गति घटक गति रखता है।

लेकिन वास्तविक समस्या मेरी टक्कर प्रणाली है। यह वर्ग तार्किक बूँद की तरह है। इस वर्ग में मेरे पास इतने विशेष मामले हैं।

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

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

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

क्या मैं बहुत जटिल सोच रहा हूँ? मुझे इस समस्या से कैसे निपटना चाहिए?

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

लेकिन यह मेरे लिए एक उचित समाधान नहीं लगता है, क्योंकि उदाहरण के लिए:

  1. मेरे आंदोलन के बाद के टकराव की प्रणाली को उन संस्थाओं की आवश्यकता होगी जिनके पास एक स्थिति घटक, एक आंदोलन घटक और टक्कर घटक है। फिर यह इकाई की गति को शून्य पर सेट कर देगा।
  2. भौतिकी के बाद के टकराव की प्रणाली को उन संस्थाओं की आवश्यकता होगी जिनके पास एक स्थिति घटक, एक आंदोलन घटक, एक टक्कर घटक और एक भौतिकी घटक है। फिर यह गति वेक्टर को प्रतिबिंबित करेगा।

समस्या स्पष्ट है: आंदोलन के बाद के टकराव को उन संस्थाओं की आवश्यकता है जो भौतिकी के बाद की टक्कर प्रणाली में संस्थाओं का एक सबसेट हैं। तो दो पोस्ट-टक्कर सिस्टम एक ही डेटा पर काम करेंगे, प्रभाव: हालांकि एक इकाई में एक भौतिकी घटक है, टक्कर के बाद इसकी गति शून्य होगी।

एक इकाई घटक प्रणाली में सामान्य रूप से इन समस्याओं को कैसे हल किया जाता है? क्या वे समस्याएं सामान्य हैं या मैं कुछ गलत कर रहा हूं? यदि हाँ, तो इसके बजाय क्या और कैसे किया जाना चाहिए?

जवाबों:


11

हां, आप बहुत जटिल सोच रहे हैं।

ऐसा लगता है कि आपकी बहुत सी समस्याओं को एक संदेश प्रणाली और कुछ अतिरिक्त विशेषताओं के साथ हल किया जा सकता है जो आपको कुछ फिल्टर निर्दिष्ट करने की अनुमति देते हैं , और अंत में संस्थाओं / घटकों के साथ इतने सख्त होने की चिंता नहीं करते हैं।

मैसेजिंग से आपको कुछ पहलुओं जैसे ट्रिगरिंग कण, पावरअप और इतने पर मदद मिलेगी। उदाहरण के लिए, आपके पास एक विश्व ऑब्जेक्ट हो सकता है जो कण घटनाओं की सदस्यता लेता है और घटना में वर्णित स्थिति में कण बनाता है।

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

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


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

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

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

12

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

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

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

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

कस्टम भौतिकी इंजन के लिए याद रखें कि आपको अपने घटकों पर डेटा रखने की अनुमति है। हो सकता है कि एक सामान्य पोंग भौतिकी घटक में डेटा हो, जो यह बताता हो कि यह किस अक्ष पर आगे बढ़ सकता है (जैसे, vec2(0,1)पैडल के लिए गुणक के रूप में जो केवल Y अक्ष पर आगे बढ़ सकता है और vec2(1,1)गेंद के लिए यह संकेत दे सकता है कि वह हालांकि आगे बढ़ सकता है), एक ध्वज या फ्लोटिंग बाउंसनेस ( गेंद आमतौर पर 1.0और पैडल पर होगी0.0), त्वरण विशेषताओं, वेग, और इतने पर। उच्च-संबंधित डेटा के प्रत्येक टुकड़े के लिए इसे एक bazillion अलग-अलग सूक्ष्म-घटकों में विभाजित करने की कोशिश कर रहा है जो कि ECS मूल रूप से करने के लिए था। उन चीजों को रखें जो एक ही घटक में एक साथ उपयोग किए जाते हैं जहां संभव हो और केवल उन्हें विभाजित करें जब प्रत्येक गेम ऑब्जेक्ट उस डेटा का उपयोग कैसे करता है, इसमें एक बड़ा अंतर है। ऐसा तर्क है कि पोंग के लिए गेंद और पैडल के बीच भौतिकी अलग घटक होने के लिए पर्याप्त है, लेकिन एक बड़े खेल के लिए, 20 घटक बनाने की कोशिश करने के लिए बहुत कम कारण है जो 1-3 में ठीक काम करता है।

याद रखें, यदि / जब आपके ईसीएस का संस्करण रास्ते में हो जाता है, तो वह करें जो आपको वास्तव में अपना खेल बनाने की आवश्यकता है और एक डिजाइन पैटर्न / वास्तुकला के लिए कुत्ते के पालन को भूल जाएं।


1
वास्तव में धन्यवाद! मुझे पता है, कि एक ईसीएस पोंग जैसे छोटे खेल के लिए बहुत अच्छा नहीं है। लेकिन मैंने इसे सिर्फ यह देखने के लिए इस्तेमाल किया कि वास्तव में ऐसा कैसे लागू होता है और यह कैसे काम करता है। मैंने घटकों को इतना छोटा बना दिया, क्योंकि यही वह था जो मैंने ज्यादातर कुछ लेखों में पढ़ा था। कई घटकों और प्रत्येक घटक के लिए केवल प्राथमिक डेटा होता है। तो, क्या मैं आपको सही समझता हूं, कि आप विरासत और ईसीएस के बीच मिश्रण का उपयोग करने का सुझाव देते हैं? जैसा कि आप कहते हैं "गेंद और पैडल अलग-अलग घटक होने के लिए पर्याप्त अलग हैं"। इसलिए उदाहरण के लिए मैं उन्हें एक मूवमेंट / पोजिशन घटक (शायद एक घटक के रूप में) देता
हूं

1
जो कुछ भी काम करता है। खेल बनाने पर ध्यान दें। मेरा शाब्दिक रूप से बस एक घटक होगा जिसे बुलाया जाता Ballहै जिसमें गेंद के लिए सभी तर्क होते हैं जैसे कि आंदोलन, उछलते हुए, आदि और एक Paddleघटक जो इनपुट लेता है, लेकिन वह मैं ही हूं। जो कुछ भी आपके लिए सबसे अधिक समझ में आता है और आपके रास्ते से हट जाता है और आपको खेल को चीजों को करने का "सही तरीका" है।
सीन मिडिलिच्ड

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

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

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

-2

मेरी राय में *), अवयवों के साथ आपकी सबसे बड़ी समस्या यह है: घटक यहाँ नहीं हैं कि किसी और को क्या करना है। घटक डीओ चीजों के लिए यहां हैं। आपके पास किसी चीज़ की स्मृति को रखने के लिए सिर्फ एक घटक नहीं है और फिर अन्य घटक इस पर काम करते हैं। आप उन घटकों को चाहते हैं जो उन्हें मिले डेटा के साथ करते हैं।

यदि आप स्वयं को अन्य घटकों की उपस्थिति के लिए परीक्षण करते हुए देखते हैं (और फिर वहां कार्य करते हैं), तो यह एक स्पष्ट संकेत है, कि दोनों में से कोई एक चीज सत्य है:

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

वैसे, ये सभी प्रकार की प्रणालियों पर लागू होता है, न केवल इकाई / घटक प्रणाली, बल्कि सरल "GameObject" या पुस्तकालय कार्यों के साथ क्लासिक विरासत के लिए भी।

*) वास्तव में केवल मेराWhats Da Real Component Systemz (TM) के बारे में राय अलग-अलग है

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.