यदि मुझे गलत नहीं है, तो आप मूल रूप से मॉडल-व्यू-कंट्रोलर प्रतिमान में एक गेम को विभाजित करने के लिए कह रहे हैं।
बस शब्दों में कहें, मॉडल आपके गेम की स्थिति है। ओ-ओ शर्तों में, आप मॉडल के बारे में सोच सकते हैं कि आपके गेम में सभी ऑब्जेक्ट्स हैं।
नियंत्रक उन नियमों का सेट है जो आपके गेम के राज्य (इस मामले में, आपके सभी गेम ऑब्जेक्ट्स) पर प्रत्येक अपडेट चक्र में लागू होते हैं। इसे आपके सभी ऑब्जेक्ट्स में अपडेट() नामक विधि के रूप में कार्यान्वित किया जा सकता है, या यह आपके गेम लूप में एक फ़ंक्शन हो सकता है जो व्यवस्थित रूप से उन सभी ऑब्जेक्ट्स के माध्यम से जाता है जिन्हें अद्यतन करने की आवश्यकता होती है और, ठीक है, उन्हें अपडेट किया जाता है। आप कंट्रोलर को गेम लूप के रूप में भी सोच सकते हैं। यह सबकुछ अपडेट करने के लिए कहता है, और उसके बाद स्क्रीन पर खींचता है और दोहराता है, जब तक कि कुछ शर्तों को पूरा नहीं किया जाता है, तो यह प्रोग्राम को कुछ और करने के लिए कहता है। इस तरह, आपके पास लगभग दो नेस्टेड एमवीसी संरचनाएं होती हैं। एक मेनू के माध्यम से कार्यक्रम के प्रवाह को नियंत्रित करता है, और एक खेल के लिए समर्पित है।
व्यू सिर्फ आपके गेम का आलेखीय प्रतिनिधित्व है। यह एक स्क्रीन पर पाठ के रूप में सरल हो सकता है, लेकिन आपके मामले में यह 2 डी ग्राफिक्स है। इसे लागू करने के लिए, आप प्रत्येक ऑब्जेक्ट में अपने ग्राफिकल स्थिति, या तो सीधे, या encapsulation द्वारा हो सकता है। दृश्य उनके ग्राफिकल स्थिति के लिए सभी ऑब्जेक्ट्स से पूछताछ से थोड़ा अधिक करेगा, और उसके बाद स्क्रीन पर इसे घुमाएगा। दोबारा, इसे प्रति-ऑब्जेक्ट आधार पर लागू किया जा सकता है, जैसे ड्रॉ(), या किसी अन्य व्यवस्थित फ़ंक्शन जिसे गेम लूप से सीधे कहा जाता है। एक सामान्य अभ्यास 'स्पिटिट' नामक ऑब्जेक्ट बनाना या ग्राफिकल जानकारी को पकड़ने के समान कुछ बनाना है, और खींचे गए प्रत्येक गेम ऑब्जेक्ट में व्यक्तिगत उदाहरण है। यह भी ध्यान रखें कि दृश्य को स्वयं के लिए एक वस्तु नहीं होना चाहिए। गेम लूप में बुलाया जाने वाला एक मात्र फ़ंक्शन पर्याप्त होगा, हालांकि कभी-कभी ऐसी जानकारी संग्रहीत करने के लिए आवश्यक होता है जो दृश्य के ऑपरेशन (विंडो आकार की तरह) को सीधे प्रभावित करता है, जिस स्थिति में दृश्य एक वस्तु हो सकता है। नियंत्रक के लिए भी यही है।
यह भी ध्यान रखें कि जीवन को सरल बनाने के लिए इन डिवीजनों को और भी विभाजित किया जा सकता है। उदाहरण के लिए: नियंत्रक को एआई प्रसंस्करण, आंदोलनों को अद्यतन करने और टकराव की जांच में विभाजित किया जा सकता है। व्यू को गेम ऑब्जेक्ट डिस्प्ले और एचयूडी में अलग किया जा सकता है, और मॉडल सभी ऑब्जेक्ट्स + गेम ऑब्जेक्ट्स से स्वतंत्र सभी राज्य हो सकता है (जैसे संकल्प के लिए गेम सेटिंग्स, विंडो आकार, कुंजी कॉन्फ़िगरेशन और ऐसे)।
मुझे पता है कि यह थोड़ा अधिक हो सकता है, और शायद इसकी अतिरिक्त जानकारी है, लेकिन उम्मीद है कि यह आपके प्रश्न का उत्तर देगी और आपको कहां से शुरू करना है, इस बारे में विचार देता है।
शायद आपको [यह आलेख] मिलेगा (http://www.gamasutra.com/view/feature/130693/the_guerrilla_guide_to_game_code.php) सहायक .. अगर आपने इसे पहले से नहीं पढ़ा है। –
@ tereško तो मूल रूप से ScaryMonsterEnemyView ScaryMonsterEnemyModel पकड़ेगा? यह मुझे लगता है कि समझ में आता है .. – tobes
एमवीसी में दृश्य मॉडल पकड़ नहीं है। दृश्य केवल मॉडल परत से डेटा प्राप्त करता है। इसे या तो मॉडल परत (शास्त्रीय एमवीसी) या दृश्य (मॉडल 2 एमवीसी) द्वारा अनुरोध किया जाता है। –