गेम सबसिस्टम में गेम ऑब्जेक्ट अवयव रजिस्टर करें? (घटक-आधारित गेम ऑब्जेक्ट डिज़ाइन)

Question

मैं एक घटक-आधारित गेम ऑब्जेक्ट सिस्टम बना रहा हूं । कुछ सुझाव:

1. GameObjectबस की एक सूची है Components।
2. हैं GameSubsystems। उदाहरण के लिए, प्रतिपादन, भौतिकी आदि। प्रत्येक GameSubsystemमें कुछ के संकेत होते हैं Components। GameSubsystemएक बहुत शक्तिशाली और लचीला अमूर्त है: यह खेल की दुनिया के किसी भी स्लाइस (या पहलू) का प्रतिनिधित्व करता है।

(जब बनाया और रचा जाता है) Componentsमें पंजीकरण की एक तंत्र में आवश्यकता है । कर रहे हैं 4 दृष्टिकोण :GameSubsystemsGameObject

---

• 1: जिम्मेदारी पैटर्न की श्रृंखला । हर Componentको हर अर्पित है GameSubsystem। GameSubsystemनिर्णय लेना है कि Componentsकिसको पंजीकृत करना है (और उन्हें कैसे व्यवस्थित करना है)। उदाहरण के लिए, GameSubsystemRender रेंडर करने योग्य घटकों को पंजीकृत कर सकता है।

समर्थक। Componentsजानते हैं कि उनका उपयोग कैसे किया जाता है। कम युग्मन। A. हम नया जोड़ सकते हैं GameSubsystem। उदाहरण के लिए, चलिए GameSubsystemTield को जोड़ते हैं जो सभी ComponentTitle को पंजीकृत करता है और गारंटी देता है कि प्रत्येक शीर्षक अद्वितीय है और शीर्षक द्वारा ऑब्जेक्ट्स को क्वेरिंग करने के लिए इंटरफ़ेस प्रदान करता है। बेशक, ComponentTitle को इस मामले में फिर से लिखना या विरासत में नहीं मिलना चाहिए। B. हम मौजूदा का पुनर्गठन कर सकते हैं GameSubsystems। उदाहरण के लिए, GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter को GameSubsystemSpatial में विलय किया जा सकता है (सभी ऑडियो, एममिटेर Componentsको एक ही श्रेणी में प्रस्तुत करने और अभिभावक-सापेक्ष परिवर्तनों का उपयोग करने के लिए)।

चोर। हर-हर चेक। बहुत अपर्याप्त है।

चोर। Subsystemsके बारे में पता है Components।

---

• 2: प्रत्येक विशिष्ट प्रकार की Subsystemखोज Componentsकरता है।

समर्थक। में बेहतर प्रदर्शन Approach 1।

चोर। Subsystemsअभी भी जानते हैं Components।

---

• 3: Componentखुद को रजिस्टर करता है GameSubsystem(s)। हम संकलन-समय पर जानते हैं कि GameSubsystemRenderer है, तो चलिए ComponentImageRender को GameSubsystemRenderer :: रजिस्टर (ComponentRenderBase *) जैसा कुछ कहेंगे।

समर्थक। प्रदर्शन। में कोई अनावश्यक जाँच नहीं Approach 1।

चोर। Componentsबुरी तरह से साथ युग्मित हैं GameSubsystems।

---

• 4: मध्यस्थ पैटर्न। GameState(जिसमें सम्‍मिलित है GameSubsystems) registerComponent (घटक *) को लागू कर सकता है।

समर्थक। Componentsऔर GameSubystemsएक दूसरे के बारे में कुछ नहीं जानते।

चोर। C ++ में यह बदसूरत और धीमी टाइपिड-स्विच की तरह दिखेगा।

---

प्रश्न: कौन सा दृष्टिकोण बेहतर है और ज्यादातर घटक-आधारित डिज़ाइन में उपयोग किया जाता है? अभ्यास क्या कहता है? के कार्यान्वयन के बारे में कोई सुझाव Approach 4?

धन्यवाद।

Comments

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

— करूंगा

@GamingHorror, पंजीयन Componentsमें GameObjectsमेरे सवाल के दायरे से बाहर है। घटक-आधारित दृष्टिकोण के बारे में लेख पढ़ें या यदि आप इसमें रुचि रखते हैं तो इस साइट पर अपना प्रश्न पूछें। आप जो सोचते हैं, GameSubsystemवह पूरी तरह से गलत है।

— टॉपर

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

— LearnCocos2D

हां, "घटक-आधारित गेम ऑब्जेक्ट" और "घटक-उन्मुख प्रोग्रामिंग" अलग-अलग शब्द हैं, यह भ्रामक हो सकता है। पक्षपाती मत बनो, बेहतर हो "द्विपक्षीय": scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.ppt

— टॉपर

Answer 1

दरवाजा संख्या 3 ... घटक GameSubsystem (s) में खुद को पंजीकृत करता है

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

युग्मन वास्तव में इस मामले में एक बुरी बात नहीं है।

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

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

Comments

अच्छी बात है। लेकिन GameSubsystems के बारे में कैसे घटक जानते हैं? क्या सब सबसिस्टम सिंगलटन हैं? यह बदसूरत नहीं है? ... मैं निर्भरता इंजेक्शन की तरह एक और समाधान के बारे में सोच रहा हूं ... लेकिन कब और कौन प्रत्येक घटक के लिए सबसिस्टम उदाहरण देता है?

— दानी

@ डैनी कंपोनेंट्स को सीधे सबसिस्टम इंस्टेंस तक पहुंचने की जरूरत नहीं है, उन्हें बस एक मैसेज भेजना होगा ताकि रजिस्ट्रेशन हो सके, उन्हें यह जानने की जरूरत नहीं है कि सबसिस्टम क्या है (लेकिन वे सबसे अधिक संभावना है) और क्यों क्या वे एकल होंगे? यह एक आवश्यकता नहीं है, भले ही ज्यादातर मामलों में आपको प्रत्येक सबसिस्टम के लिए केवल एक सबसिस्टम इंस्टेंस की आवश्यकता होगी।

— पाब्लो एरियल

@ पाब्लो - सहमत।

— रिक