इकाई-घटक-सिस्टम इंजन में, मैं आश्रित संस्थाओं के समूहों के साथ कैसे व्यवहार करता हूं?


47

कुछ गेम डिज़ाइन पैटर्न पर जाने के बाद, मैंने अपने गेम इंजन के लिए इकाई-घटक-प्रणाली (ES सिस्टम) के साथ समझौता किया है। मैंने लेख पढ़ा है (मुख्य रूप से टी = मशीन ) और कुछ स्रोत कोड की समीक्षा करता हूं और मुझे लगता है कि मुझे आरंभ करने के लिए पर्याप्त मिला।

सिर्फ एक मूल विचार है जिसके साथ मैं संघर्ष कर रहा हूं। मैं उन संस्थाओं के समूहों के साथ कैसे व्यवहार करता हूं जो एक-दूसरे पर निर्भर हैं?

मुझे एक उदाहरण का उपयोग करने दें:

मान लें कि मैं एक मानक ओवरहेड शूटर बना रहा हूं ( जैमस्टाउन सोचें ) और मैं कई अलग-अलग लेकिन जुड़े हिस्सों के साथ "बॉस इकाई" का निर्माण करना चाहता हूं। ब्रेक डाउन कुछ इस तरह दिख सकता है:

  • जहाज का शरीर: आंदोलन, प्रतिपादन
  • तोप: स्थिति (जहाज के शरीर के सापेक्ष बंद), नायक पर नज़र रखने वाली आग, निष्क्रिय होने तक नुकसान उठाना
  • कोर: स्थिति (जहाज के शरीर के सापेक्ष बंद), नायक पर ट्रैकिंग \ फायर, अक्षम होने तक नुकसान उठाना, अक्षम करना (एर ... नष्ट करना) जहाज समूह में अन्य सभी संस्थाओं

मेरा लक्ष्य कुछ ऐसा होगा जिसे (और जोड़तोड़) एक अलग खेल तत्व के रूप में पहचाना जाएगा बिना सबसिस्टम को फिर से लिखने के बिना हर बार जब मैं एक नया कुलीन तत्व बनाना चाहता हूं।

मैं ES सिस्टम में इस तरह के डिज़ाइन को कैसे लागू कर सकता हूं?

  1. क्या मैं किसी प्रकार के अभिभावक-बाल अस्तित्व संबंध (संस्थाओं में बच्चे हो सकते हैं) को लागू कर सकता हूं? यह कार्यप्रणाली के विपरीत प्रतीत होता है कि एंटिटीज केवल खाली कंटेनर हैं और यह अधिक ओओपी महसूस करता है।
  2. क्या मैं उन्हें अलग-अलग संस्थाओं के रूप में कार्यान्वित कर सकता हूं, जिसमें कुछ प्रकार के कनेक्टिंग कंपोनेंट (BossComponent) और संबंधित सिस्टम (BossSubSystem) शामिल हैं? मैं मदद नहीं कर सकता, लेकिन लगता है कि यह लागू करना मुश्किल होगा क्योंकि कैसे संचार एक बड़ा भालू जाल लगता है।
  3. क्या मैं उन्हें एक इकाई के रूप में कार्यान्वित करता हूं, घटकों के एक संग्रह के साथ (शिपकंपोनेंट, कैनोनकंप्यूटर, कोरकंपोनेंट)? यह ईएस सिस्टम आशय का तरीका (यहां घटकों को बहुत भारी वजन संस्थाओं की तरह लगता है) को वीर करने लगता है, लेकिन मुझे यह पता है इसलिए मुझे लगा कि मैं इसे बाहर रखूंगा।
  4. क्या मैंने उन्हें किसी और चीज के रूप में लागू किया है जिसका मैंने उल्लेख किया है?

मुझे पता है कि इसे ओओपी में बहुत आसानी से लागू किया जा सकता है, लेकिन ओओपी के ऊपर मेरा चयन एक ऐसा है जिसके साथ मैं चिपके रहूंगा। अगर मुझे इस डिज़ाइन को लागू करने के लिए शुद्ध ES सिद्धांत के साथ तोड़ने की आवश्यकता है (जैसा कि मुझे पहले शुद्ध डिजाइन से समझौता नहीं करना पड़ा है), लेकिन मैं खराब डिज़ाइन के साथ शुरुआत करने के बजाय प्रदर्शन के कारण ऐसा करना पसंद करूंगा।

अतिरिक्त क्रेडिट के लिए, एक ही डिज़ाइन के बारे में सोचें लेकिन, "बॉस एंटिटीज़" में से प्रत्येक वास्तव में एक मुख्य बॉडी, मुख्य कोर और 3 "बॉस एंटिटीज़" से बना एक बड़ा "बिगबॉस इकाई" से जुड़ा था। यह मुझे कम से कम 3 आयामों (दादा-दादी-माता-पिता-बच्चे) के लिए एक समाधान देखने देगा ... जो मेरे लिए पर्याप्त से अधिक होना चाहिए।


2
यह बस एक इकाई से जुड़े अलग-अलग मेष घटक हैं, मालिक इकाई से जुड़े जहाज और तोप-जाल, न ही ओवर-एनीनियर। एक इकाई घटक प्रणाली Btw OOP है!
माईक सेमर

2
हां - उन टी-मशीन लेखों का सबसे खराब सा गलत अर्थ है कि यह किसी भी तरह वस्तु-उन्मुख नहीं है। संस्थाओं के लिए अधिकांश घटक प्रणालियां पूरी तरह से ऑब्जेक्ट ओरिएंटेड हैं, न कि विरासत आधारित।
काइलोटन

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

@MaikSemder मैंने अपनी टिप्पणियों को साफ किया और उन्हें चैट
माइकलहाउस

1
बस इसलिए मैं @MaikSemder को समझता हूं, ES सिस्टम में आपका संदर्भ, एक इकाई में एक ही प्रकार के कई घटक हो सकते हैं और उन घटकों के लिए जिम्मेदार सबसिस्टम को उस तथ्य से निपटना होगा? तो एक इकाई में कई रेंडर घटक हो सकते हैं और उन घटकों के डेटा और सबसिस्टम यह निर्धारित करेंगे कि उन्हें प्रत्येक ठीक से कैसे प्रस्तुत किया जाए? यह कम संस्थाओं, संभवतः कम घटकों के लिए ले जाएगा लेकिन थोड़ा गहरा उपतंत्र तर्क, सही?
जॉन डेनियल 19

जवाबों:


41

यदि मैं इस स्थिति में होता, तो मैं बॉस के प्रत्येक हिस्से को एक अलग इकाई के रूप में बनाता। इन "उप-संस्थाओं" में कुछ प्रकार AttachmentPointया ParentEntityघटक शामिल होंगे। इस घटक में मूल इकाई का संदर्भ और माता-पिता की स्थिति से एक ऑफसेट शामिल होगा। स्थिति को अपडेट करते समय, वे मूल स्थिति की जांच करते हैं और अपनी स्थिति उत्पन्न करने के लिए ऑफसेट को लागू करते हैं। इसके अतिरिक्त, यह सुनिश्चित करने के लिए चेक बना सकता है कि मूल इकाई अभी भी मौजूद है। इसके अलावा, आपके पास एक SubEntityघटक हो सकता है जो मूल संस्था के लिए उप संस्थाओं के अस्तित्व को ट्रैक करता है। यह आपको चीजों को करने की अनुमति देता है जैसे केवल ढाल के साथ हथियार नष्ट होने पर बॉस के मूल को कमजोर बनाते हैं।

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

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

मैं इस विषय पर एक और चर्चा पाया यहाँ । जिसमें उपयोगकर्ता एक ही इकाई के एक ही प्रकार के कई घटकों को जोड़ने पर चर्चा कर रहे हैं (जो मुझे बुरा लगता है)। यह एक उपयोगी बातचीत की तरह लगता है, हालांकि मैंने पूरी चर्चा नहीं पढ़ी है।


यहाँ अच्छी जानकारी के बहुत सारे। आपने समाधान को अच्छी तरह से समझाया, मुझे एक उदाहरण दिया और शायद 1 या 2 और सवालों के जवाब दिए जिन्हें मुझे बाद में वापस आना पड़ा। लिंक की गई चर्चा भी पेचीदा लगती है, खासकर जब मैं कठिन कार्यान्वयन में जाना शुरू करता हूं। धन्यवाद @ बाइट 56!
जॉन डेनियल

कोई बात नहीं जॉन! बेशक एक ईसी प्रणाली को लागू करने के लिए कई अलग-अलग तरीके हैं। प्रणाली मैं इस उत्तर के लिए मन में था एक मैं में वर्णित है इस सवाल का जवाब । अपने खेल के साथ गुड लक!
MichaelHouse

आपका दृष्टिकोण सबसे अधिक लचीला है और यह एक सामान्य गेम इंजन में उपयोग करने के लिए ध्वनि है।
कोयोट

7

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

रेंडरिंग सिस्टम (या जो भी हो) घटकों के साथ संस्थाओं को पकड़ लेता है: स्थिति, संलग्न, आदि और उचित पदानुक्रम बनाता है।


यह सर्वसम्मति से उत्तर लगता है। अगली बार मैं लोगों को चबाने के लिए अधिक कार्यान्वयन विवरण दूंगा। धन्यवाद @PSpeed!
जॉन डेनियल

4

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

जाहिर है किसी भी घटक जो स्थिति आदि पर निर्भर करते हैं, उन्हें इकाई को ठीक से लगाने के लिए इसके साथ काम करना होगा। इसे कैसे लागू किया जाए यह इस बात पर निर्भर करेगा कि आप वर्तमान में स्थिति को कैसे लागू करते हैं।

वैसे, कोई "शुद्ध ईएस सिद्धांत" नहीं है - घटकों से बाहर संस्थाओं को बनाना एक लोकप्रिय दृष्टिकोण है, लेकिन सटीक विधि किसी भी तरह से मानक मानक नहीं है।


हाँ, मुझे किसी भी डिज़ाइन चर्चा में "शुद्ध" शब्द का उपयोग नहीं करना सीखना चाहिए ... ऐसी कोई बात नहीं है। ConpositeComponent मार्ग यहां सर्वसम्मति लगता है। धन्यवाद @ कियलोतन!
जॉन डेनियल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.