खेलों: प्रदर्शन के लिए कौन जिम्मेदार है?

Question

क्या संस्थाएं खुद को आकर्षित करने के बारे में जानती हैं? मैंने इस दृष्टिकोण का उपयोग किया है: यह आसान है और यह काम करता है, लेकिन एमवीसी-पैटर्न सीखने के बाद मुझे इस बारे में असहज महसूस होता है। जब मॉडल में सभी डिस्प्ले तर्क दफन किया जाता है तो कला शैली को बदलना मुश्किल होता है।

कोई एक व्यू क्लास पेश कर सकता है, जो स्तर को तर्क के रूप में लेता है और इसे खींचता है, लेकिन इसका मतलब यह होगा कि इसे इकाई प्रकारों की पहचान करना होगा और "स्विच" -स्टेटमेंट पेश करना होगा, जिसे मैंने सीखा है।

किसी को ड्राइंग के लिए कोड कहां रखा जाना चाहिए, जिस तरह से एक्स्टेंसिबल, बदलने में आसान, साफ और सूखा हो?

Answer 1

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

वास्तविक रणनीति ड्राइंग संचालन के लिए प्रॉक्सी के रूप में आपके गेम संसाधनों का उपयोग करना एक रणनीति है जो आप कर सकते हैं। उदाहरण के लिए एक दुश्मन इकाई किसी संसाधन ऑब्जेक्ट के माध्यम से सभी प्रतिपादन को रोक सकती है जो जाल का प्रतिनिधित्व करती है; इसी तरह बनावट/त्वचा और प्रभाव के लिए।

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

Answer 2

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

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

Answer 3

आमतौर पर मैं इस समस्या को विरासत के साथ हल करता हूं।

उदाहरण के लिए, एक परियोजना पर मैं इस समय काम कर रहा हूं कि मैं प्रतिपादन के लिए मैन्युअल परीक्षण के साथ गेम तर्क लिखने के लिए टेस्ट-ड्राइव डेवलपमेंट का उपयोग कर रहा हूं। सी # में नीचे यह उदाहरण किसी न किसी विचार को दिखाता है।

class GameObjecet { 
    // Logic, nicely unit tested. 
} 

class DrawableGameObject : GameObject { 
    // Drawing logic - manual testing 
} 

यह आमतौर पर मुझे सबसे अच्छा समाधान मिला है। यह कोड को परीक्षण करने की अनुमति देता है, जबकि ड्राइंग, और मॉडल लोडिंग इत्यादि जैसे प्रस्तुति कोड के साथ खेल तर्क को छेड़छाड़ नहीं करता है ...

Answer 4

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

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

जब आप अधिक जटिल संस्थाओं में जाते हैं, तो आपको अपने दृष्टिकोण पर पुनर्विचार करना होगा। आम तौर पर, आप उबर लूप रखने के आग्रह का विरोध करना चाहते हैं जो प्रत्येक इकाई पर पुनरावृत्त हो और कुछ अपडेट/रेंडर/जो भी कार्य करता है उसे कॉल करें। यह बिल्कुल स्केल नहीं करता है, जब तक कि प्रत्येक अद्यतन, प्रस्तुत न करें, या जो भी पदानुक्रम बिल्कुल समान नहीं है। जो ज्यामिति युद्धों जैसे गेम के लिए ठीक है, लेकिन इससे कहीं अधिक जटिल नहीं है।

आप जो करना चाहते हैं उसे सबसे सामान्य इकाई संग्रह एक विशिष्ट विशिष्ट ट्रैवर्सल निकालने के लिए दिया जाता है। उदाहरण के लिए, यदि आप दृश्य प्रस्तुत करना चाहते हैं तो आपके पास इकाई संग्रह से सभी प्रस्तुत करने योग्य इकाइयों को निकालने का तरीका होना चाहिए और फिर उन सभी को कुछ मनमानी बैच करने योग्य क्रम में प्रस्तुत करना चाहिए। एक ही भौतिक विज्ञान, टक्कर, ऐ, आदि

कुछ उपयोगी लिंक के लिए चला जाता है:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

मैं अत्यधिक दोनों की सलाह देते हैं; पहला घटक इकाइयों के निर्माण के लिए डिजाइन तर्क में जाता है, यानी, घटक, भौतिकी घटक, एआई घटक प्रस्तुत करना। दूसरा विभिन्न गेम इकाई दृष्टिकोणों की प्रदर्शन विशेषताओं में जाता है।