MVC (मॉडल-व्यू-कंट्रोलर) गेम इंजन आर्किटेक्चर - हां या नहीं? [बन्द है]

Question

मैं एक महान पुस्तक पढ़ रहा हूं, गेम कोडिंग कम्प्लीट , और वह पुस्तक तीन प्रमुख परतों के साथ MVC (मॉडल-व्यू-कंट्रोलर) दृष्टिकोण का उपयोग करने की जोरदार सिफारिश करती है:

1. खेल अनुप्रयोग परत
2. खेल तर्क
3. खेल देखें

मेरे लिए, यह दृष्टिकोण मोबाइल कंप्यूटर गेम के लिए एक ओवरकिल की तरह दिखता है।

आपकी क्या राय है, कृपया क्या यह इस वास्तुकला को लागू करने के लायक है, भले ही यह मॉड्यूल के बीच आवश्यक अतिरिक्त संचार जोड़ता है? क्या यह डिज़ाइन इतनी CPU शक्ति का उपभोग कर सकता है, कि अंत में, परिणाम काफी धीमा होगा, अगर यह लागू नहीं किया गया था?

Comments

-1 और वोट बंद करने के लिए। खेलों में एमवीसी के बारे में कहने लायक सब कुछ gamedev.stackexchange.com/questions/3426/… पर कहा गया था , और अब तक जो कुछ भी हमें मिला है वह कचरा है।

@Joe Wreschnig यह बहुत कठोर है, लेकिन मुझे लगता है कि यह सच है ...

— Spooks

@ आचोस: वास्तव में, मैंने आपका उत्तर दिया, लेकिन हमें वास्तव में एक और उत्तर की आवश्यकता नहीं थी, "यदि वे मदद करते हैं तो पैटर्न का उपयोग न करें, यदि वे नहीं करते हैं।" या शायद हमने किया, लेकिन फिर भी वह वास्तव में दुखी है। मैं अभी भी नहीं जानता कि कचरे के अलावा "वंशानुक्रम जैसे रन-टाइम डिज़ाइन" जैसे अभिव्यक्तियों को कैसे संदर्भित किया जाए।

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

— अराजकता

Answer 1

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

मैं यह भी कहूंगा, हालांकि, यह ध्यान रखना कि एमवीसी, सभी डिज़ाइन पैटर्न की तरह, आपके जीवन को आसान बनाने के लिए मौजूद है । इसका मतलब है कि यदि किसी भी समय, MVC का उपयोग करते समय आपको क्या करना चाहिए और क्या नहीं करना चाहिए, इसके बारे में नियमों के कुछ सेट के भीतर रहना, इसे अनदेखा करें । दो चीजों में से एक होगा: 1) आप बाद में काट लेंगे, और फिर समझेंगे कि पहली जगह में इसे अलग तरीके से करना वास्तव में लंबे समय में आपके जीवन को आसान क्यों बना देगा, या 2) जो भी परिणाम हो।

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

Comments

प्रिय कैओस, मुझे आपका उत्तर सबसे ज्यादा पसंद है, इसलिए मैं इसे अपने प्रश्न के उत्तर के रूप में चिह्नित कर रहा हूं। MVC दृष्टिकोण कोड डिजाइन में अमूर्तता जोड़ता है। अमूर्त ususally कोड के अतिरिक्त चरणों को जोड़ता है, जिसे अधिक स्ट्रेफ़्फ़वर्डवर्ड डिज़ाइन के साथ टाला जा सकता है। जैसा कि मैंने सही ढंग से समझा, मुझे एमवीसी डिज़ाइन के परिणामस्वरूप अमूर्त जोड़ द्वारा शुरू की गई लागत की चिंता करने की आवश्यकता नहीं है।

— बंकई.तोरी

अच्छा जवाब, उस पर +1 .. थ्योरी सभी ठीक है और अच्छी है लेकिन यह गेम को शिप नहीं करने का कारण बन सकता है यदि आप इसे पूरा नहीं करते हैं।

— जेम्स

@ Bunkai.Satori: यह अमूर्तता जोड़ता है, और IMO यह उपयोगी अमूर्त है जो अपने तरीके से भुगतान करता है। मैं आपके अंतिम कथन से सहमत हूँ, इस स्पष्टीकरण के साथ कि वहाँ है एक लागत, और कहा कि मुझे नहीं लगता कि आप इसके बारे में चिंता करने की जरूरत है।

— अराजकता

Answer 2

कंपाइल-टाइम डिज़ाइन सीपीयू बिजली का उपभोग नहीं करते हैं, जब तक कि आपके पास अविश्वसनीय रूप से abysmal संकलक न हो। एक ऑब्जेक्ट ओरिएंटेड लैंग्वेज या एप्रोच एक प्रक्रियात्मक की तुलना में प्रदर्शन विशेषताओं में भिन्न नहीं है। आप MVC का उपयोग करने के लिए किसी भी अतिरिक्त ओवरहेड को आमंत्रित नहीं करेंगे। एक बार कोड के इनलाइन और ऑप्टिमाइज़ होने के बाद मोड्यूलिटी कम्पाइल-टाइम पर मौजूद होती है, कोई फर्क नहीं पड़ता।

कई आधुनिक गेम वास्तव में अलग-अलग थ्रेड्स पर मॉडल और विचार चलाते हैं और अधिकांश प्लेटफार्मों पर शानदार प्रदर्शन लाभ प्राप्त करते हैं।

अंततः, MVC एक अच्छा डिज़ाइन है जो आपको मुफ्त में रखरखाव और कम बग आदि में वृद्धि करता है । इसका उपयोग न करने का कोई कारण नहीं है। यह पूछने की तरह है कि आपको forहाथ से लिखे हुए gotoएस के बजाय लूप का उपयोग क्यों करना चाहिए । जब तक आपके मन में एक बेहतर डिजाइन है, यह निश्चित रूप से नरक से बेहतर है।

संपादित करें: कम्पाइल-टाइम डिज़ाइन सीपीयू बिजली की खपत नहीं करते हैं। विरासत की तरह रन-टाइम डिजाइन स्पष्ट रूप से करते हैं।

Comments

-1। MVC एक डिज़ाइन-टाइम निर्णय है। वंशानुक्रम एक डिज़ाइन-टाइम निर्णय है। दोनों संकलन-समय और रन-टाइम से पहले होते हैं। दोनों का प्रदर्शन पर बड़ा प्रभाव है। इनलाइनिंग हमेशा कोड को तेज नहीं बनाती है। आपका थ्रेडिंग प्रस्ताव अविश्वसनीय रूप से भोला है। कुछ भी मुफ़्त नहीं है।

आपके जवाब के लिए धन्यवाद डेडएमजी। मूल रूप से, मेरा मतलब है कि अमूर्तता के हर स्तर के साथ, कोड को चंचल हो जाता है, क्योंकि अधिक से अधिक मध्यवर्ती कदम जोड़े जाते हैं। एमवीसी अधिक अमूर्त डिज़ाइन है, जो एक ही कार्य को प्राप्त करने के लिए अधिक चरणों में परिणाम देगा। यह गति, imo पर प्रभाव होगा।

— बंकई। कटोरी २५'११ को ११:१३

Answer 3

कोड की स्पष्टता और कार्यक्रम की तकनीकी आवश्यकताओं (गति, स्मृति, आदि) के बीच लगभग हमेशा एक व्यापार होता है। ऑब्जेक्ट-ओरिएंटेड भाषाओं में प्रक्रियात्मक भाषाओं की तुलना में एक ओवरहेड है, लेकिन उन्हें प्रक्रियात्मक भाषाओं पर कई फायदे दिखाए गए हैं, विशेष रूप से कोड (बग्स, आदि) के दीर्घकालिक रखरखाव और अक्सर विकास की गति के रूप में अच्छी तरह से।

इसीलिए, यह ध्यान में रखते हुए, मैं प्रस्ताव करता हूं कि एमवीसी आपके लिए गेम प्रोग्रामर के रूप में लागू होने के लायक है । आपका कोड बेहतर ऑब्जेक्ट-ओरिएंटेड सिद्धांतों का पालन करेगा, विशेष रूप से एनकैप्सुलेशन , और आपको संभवतः इसे बनाए रखने में बहुत आसान समय होगा (बग्स को ठीक करना या नई सुविधाओं को जोड़ना)।

दूसरी ओर, वास्तव में एक गेम खत्म करना सुनिश्चित करें और "इंजन" पर काम करने में इतना समय न दें कि यह कभी भी पूरा न हो।

अधिक जानकारी के लिए, कृपया प्रश्न पढ़ें "क्यों MVC और TDD खेल वास्तुकला में अधिक नियोजित नहीं हैं?" और मेरा बहुत लंबा जवाब।

Comments

OO भाषाएँ प्रक्रियात्मक भाषाओं की तुलना में धीमी नहीं हैं। यदि आप C ++ में कुछ कोड लिखते हैं जो बिट-शिफ्टिंग करता है, तो यह C. की तुलना में कोई धीमा नहीं होगा। किसी भाषा या प्रोग्राम को प्रक्रियात्मक की तुलना में धीमा नहीं किया जाता है, क्योंकि यह ऑब्जेक्ट ओरिएंटेड है। कार्यक्रम केवल प्रदर्शन अवरोधकों को प्रदर्शित करते हैं क्योंकि वे खराब लिखे गए हैं । नतीजतन, मुझे आपके जवाब को कम करने की आवश्यकता महसूस होती है।

— डेडएमजी

हाय रिक, योरू स्पष्टीकरण के लिए धन्यवाद। यह बहुत तार्किक लगता है। डेडएमजी, ठीक है, एक तरफ आप सही हैं, दूसरी तरफ, मुझे लगता है कि ओओ दृष्टिकोण प्रक्रियात्मक भाषा की तुलना में संकलित कोड में अधिक जानकारी जोड़ता है। OO संबंधित कोड का यह अतिरिक्त बिट्स परिणामी कोड को धीमा बनाता है। क्या आप सहमत हैं?

— बंकई.टोरि १५

वाह अब ... निश्चित रूप से सी ++ में एक सरल रेखा सी की तरह a++ही सटीक होगी a++(जहां aएक आदिम प्रकार है, आदि)। लेकिन एक साधारण फ़ंक्शन के साथ एक साधारण C ++ वर्ग पर विचार करें जो कुछ करता है, वह आभासी फ़ंक्शन एक साधारण सी फ़ंक्शन के साथ एक भारी ओवरहेड को सम्मिलित करता है, भले ही आंतरिक कोड समान हो। ऑब्जेक्ट ओरिएंटेड भाषाओं में एक ओवरहेड होता है । स्पष्ट रूप से "गति" कहने के लिए क्षमा करें। यदि अतिरिक्त मेमोरी आबंटन और इस तरह एक धीमी कार्यक्रम में परिणाम नहीं है तो आप बिल्कुल सही हैं।

— Ricket

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

— काइलोटन