खेल के विकास में कक्षा के डिजाइन के लिए सही वस्तु-उन्मुख दृष्टिकोण क्या है?

Question

मैं XNA का उपयोग करके विंडोज 7 फोन के लिए 2 डी स्प्राइट-आधारित गेम विकसित करने के बीच में हूं। इसके लिए उपलब्ध प्रशिक्षण और ट्यूटोरियल काफी मददगार हैं, लेकिन मुझे जो समस्या है, वह यह है कि उनमें से प्रत्येक अपने वर्ग के डिजाइन को अलग तरीके से अपनाता है, और कोड विशेष रूप से अच्छी तरह से नहीं है। परिणामस्वरूप, मेरे लिए यह कठिन हो गया है कि मैं एक विशेष वर्ग को कौन सी जिम्मेदारियाँ दे सकूँ।

उदाहरण के लिए, मेरे पास एक बेस स्प्राइट क्लास हो सकता है BaseSpriteजो जानता है कि कैसे खुद को ड्रा करना है, टकरावों की जांच करना है, आदि मैं तब एक AnimatedSpriteवर्ग हो सकता है जो जानता होगा कि इसकी स्प्राइट शीट, एक ExplodingSpriteक्लास और कैसे नेविगेट करें । इस तकनीक को विंडोज 7 फोन जम्पस्टार्ट सत्र 2 सामग्री में अंतरिक्ष आक्रमणकारियों उदाहरण में प्रदर्शित किया गया है ।

वैकल्पिक रूप से, मैं इसके बजाय एक GameScreenकक्षा में गेम की जिम्मेदारी को प्रस्तुत करने और चलाने का थोक रख सकता हूं ; वह वर्ग और उसके व्युत्पन्न वर्ग अपनी जिम्मेदारियों के संदर्भ में रूपों या वेब पृष्ठों की तरह अधिक व्यवहार करते हैं। स्प्राइट कक्षाएं बहुत कम तर्क के साथ अधिक सरल कंटेनर हैं।

यह विंडोज 7 फोन ट्रेनिंग किट के एलियन स्प्राइट गेम और अन्य गेम स्टेट मैनेजर उदाहरणों में उपयोग की जाने वाली तकनीक है ।

खेल के विकास में कक्षा के डिजाइन के लिए सही वस्तु-उन्मुख दृष्टिकोण क्या है?

Answer 1

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

घटक उन्मुख डिजाइन पर कुछ जानकारी के लिए यहां देखें ।

Comments

+1 आप जिस लेख से जुड़े थे वह शानदार था। मैं शुद्ध OO डिजाइन पर ध्यान केंद्रित कर रहा था, मैंने पूरी तरह से घटक / डेकोरेटर प्रकार के मॉडल की अनदेखी की।

— जोश ई

घटक पैटर्न वास्तव में "कम शुद्ध" OO :) नहीं है

— श्रेकेल

वास्तव में। ओओ को अक्सर विरासत के साथ बराबर किया जाता है। लेकिन विरासत केवल एक उपकरण OO प्रदान करता है, रचना एक और है।

— हैफैक्स

अभी तो। मुझे अपने शब्दों में अधिक सटीक होना चाहिए था; मेरा मतलब यह है कि मैंने OO डिजाइन पैटर्न / अन्य OO पहलुओं के बारे में सोचने के बजाय OO के वंशानुक्रम पक्ष पर ज्यादा ध्यान केंद्रित किया, जो मुझे वह हासिल करने में मदद कर सके जो मैं चाहता था।

— जोश ई।

जबकि एक कोमोपोसिशन आधारित दृष्टिकोण बहुत स्पष्ट है और अक्सर उपयोग किया जाता है, मुझे अभी तक रेंडरिंग घटक को पोर्टेबल रखने के लिए एक समाधान देखना है। कोई संकेत महान होगा।

— एंड्रियास

Answer 2

खेल में, घटक पैटर्न एक सामान्य समाधान है।

Comments

यह एक और शानदार लेख है - अच्छी तरह से पढ़ने लायक।

— जोश ई

बढ़िया, बढ़िया, बढ़िया लेख!

— केविन

Answer 3

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

मैं हालांकि आगे जाऊंगा, क्योंकि बेसस्प्राइट ऐसा लगता है जैसे कि यह एक मेगाक्लस बनने की प्रवृत्ति है। एकल उत्तरदायित्व सिद्धांत यह तय करता है कि टकराव, प्रतिपादन और नेविगेशन सभी को एक वर्ग पदानुक्रम में व्यक्तिगत प्रविष्टियों के बजाय, घटकों द्वारा नियंत्रित किया जाना चाहिए। इन सभी घटकों के धारण वर्ग को केवल उनके बीच की दुनिया की स्थिति को आगे बढ़ाने का काम करना चाहिए।

Answer 4

पिछले कुछ प्रोजेक्ट्स के लिए मैंने एमवीसी शैली के दृष्टिकोण की ओर अधिक झुकाव किया है।

पहले तो हमें यकीन नहीं था कि यह काम करेगा, लेकिन यह पूरी तरह से काम करता है।

आदर्श

डेटा ऑब्जेक्ट्स। सिर्फ शुद्ध डेटा। कोई व्यवहार नहीं, कोई प्रतिपादन नहीं।

डाटा प्रबंधक। बस डेटा ऑब्जेक्ट्स की "सूचियों" को संभालना। (पूलिंग का समर्थन करने के लिए भी बढ़ाया जा सकता है।)

राय

हम उन्हें रेंडरर कहते हैं। हर डेटा ऑब्जेक्ट प्रकार के लिए एक रेंडरर होता है। जब इसे प्रबंधक के साथ बुलाया जाता है तो यह उस सूची में सभी वस्तुओं को प्रस्तुत करेगा।

नियंत्रक

रेंडरर्स के रूप में भी, लेकिन व्यवहार को नियंत्रित करता है।

उदाहरण

शिपमैनगर के पास जहाजों की एक सूची है। शिपकंट्रोलर अपने राज्य के अनुसार जहाजों को स्थानांतरित करेगा। शिपरेंडर अपने राज्य के अनुसार जहाजों को प्रस्तुत करेगा।

क्यूं कर

इस तरह से दृश्य और तर्क सख्ती से अलग हो जाते हैं। यह एक नए प्लेटफॉर्म के लिए पोर्टिंग को बहुत आसान बनाता है। XxxManager के अंदर डेटा लेआउट का अनुकूलन भी बहुत आसान है।

Comments

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

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

— एंड्रियास