एक 2D खेल में एक वस्तु ही प्रस्तुत करना चाहिए?

16

मैं एक 2D स्ट्रीट फाइटर जैसा गेम बना रहा हूं जो टाइल आधारित नहीं है। आमतौर पर लोग सलाह देते हैं कि संस्थाओं को एक रेंडरर को दिया जाना चाहिए जो उन्हें सौंपता है, न कि वे खुद को रेंडर करते हैं, लेकिन ऐसा लगता है कि इसका उलटा बेहतर है,

एक दूसरे पर बेहतर क्यों है?

धन्यवाद

c++ rendering

— jmasterx
स्रोत

आपको क्यों लगता है कि उलटा बेहतर है?

1

@Martin क्योंकि ऑब्जेक्ट किसी भी रास्ते का उपयोग करने के लिए बिटमैप को संकेत देगा, इसलिए केवल ऑब्जेक्ट क्यों नहीं-> रेंडर ();

— jmasterx

11

कुछ विचार:

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

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

और मुझे नहीं पता कि यह 3 डी पर लागू होता है (जहां मेष की धारणा है, और आपके द्वारा उपयोग किए जाने वाले निर्देशांक चर शायद आपके 3 डी एपीआई से बंधे होंगे; जबकि x, y, h, w किसी भी 2D का बहुत अधिक स्वतंत्र है) एपीआई)।

इससे मदद मिलती है।

— phtrivier
स्रोत

11

आप चाहते हैं कि रेंडरिंग सिस्टम इस बात पर नियंत्रण रखे कि कब क्या हो जाए। यदि इसके बजाय स्प्राइट्स आपको बहुत सारे दक्षता लाभ और लचीलेपन पर ढीले करने के नियंत्रण में हैं। मेरी राय है कि क्लीनर कोड में नियंत्रण परिणामों में रेंडर सिस्टम है।

केंद्रीकृत प्रतिपादन के कुछ लाभ:

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

जिस तरह से मैं अपने गेम में इसे लागू करता हूं, उसमें गेम ऑब्जेक्ट्स को उन स्प्रिट्स को पंजीकृत करना है जो वे रेंडर सिस्टम के साथ खींचना चाहते हैं। जब ऑब्जेक्ट नहीं रह जाता है, तो ऑब्जेक्ट को खींचा गया यह स्प्राइट को अनइंस्टॉल करता है, या इसे निष्क्रिय करता है।

वो सब कहा। यदि यह आसान है कि आपके खेल की वस्तुओं को हर तरह से खुद को प्रस्तुत करना है तो इस तरह से करें। प्रगति करना और एक परिपूर्ण वास्तुकला के लिए कुछ / कुछ प्राप्त करना महत्वपूर्ण है।

— deft_code
स्रोत

Z- ऑर्डर करने के बारे में अगर ऑब्जेक्ट खुद को नहीं खींच सकते हैं तो एक सिस्टम उनके ड्राइंग विधि को कॉल करने के आदेश के बारे में निर्णय लेता है? मेरा मतलब है कि केंद्रीकृत बनाम गैर केंद्रीकृत z- आदेश के बारे में कोई फर्क नहीं पड़ता।

— गोरिल्लाएप

3

अस्वीकरण: आपका प्रश्न बहुत विस्तार नहीं देता है इसलिए मैं एक सामान्य सिद्धांत के साथ जवाब दे रहा हूं। कृपया मुझे क्षमा करें यदि मैंने आपके उपयोग को गलत समझा या 'रेंडर' किया।

मैं आम तौर पर एक दृश्य में विभिन्न अभिनेताओं को प्रस्तुत करने के लिए दृश्य स्तर के गुणों और व्यक्तिगत 'अभिनेता वस्तुओं के बाहर के तरीकों के तरीके के रूप में प्रस्तुत करता हूं।' दृश्य में वस्तुओं में केवल आंतरिक तरीके और गुण होने चाहिए; उन्हें केवल इस बारे में पता होना चाहिए कि वे स्वयं क्या हैं और वे क्या करते हैं। संभवतः, वे खेल में अन्य वस्तुओं के साथ-साथ उपयोगकर्ता इनपुट से प्रभावित होंगे। यह प्रभावित करेगा कि वे स्क्रीन पर कैसे / प्रदान किए गए हैं। उदाहरण के लिए, एक 'डायरेक्टर ऑब्जेक्ट', कूदने के लिए 'डब्ल्यू' की-बोर्ड का अनुवाद कर सकता है, फिर अभिनेता ऑब्जेक्ट .jump () को बताएं। इस तरह के निर्देशक स्तर के तर्क अभिनेताओं को दृश्य में पूरी तरह से प्रवेश करने या बाहर निकलने के लिए भी कह सकते हैं।

चीयर्स, डेविड

लेकिन इस लिहाज से निर्देशक सिर्फ एक्टन-> सेटविजिबल (गलत) नहीं कह सकते थे; ?

— jmasterx

यहां तक कि सेटविजियल (झूठे) मामले में, यह एक बाहरी इकाई है जो अभिनेता के दृश्यमान चर की जांच करके और इसे केवल सही होने पर प्रदान करता है।

— नव

बस एक अभिनेता को अदृश्य बनाने से यह दृश्य से दूर नहीं होता है। यह भी टकराव आदि में भाग लेने वाले को रोकना चाहिए

— finnw

3

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

3

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

— DeadMG
स्रोत

1

+1 दिलचस्प। मैंने ग्राफिक्स के लिए विज़िटर पैटर्न का उपयोग करते समय ध्वनि के लिए इस दृष्टिकोण का उपयोग किया है । मैंने सोचा कि यह ध्वनि के लिए अधिक समझ में आता है क्योंकि ग्राफिक्स और एआई एक ही घड़ी पर चल रहे हैं, ऑडियो मिक्सर दूसरे पर चल रहा है, इसलिए एक घटना मॉडल आसान है। यह भी महत्वपूर्ण नहीं है अगर एक आंदोलन घटना (जो किसी ऑडियो चैनल के पैन / रीवरब को बदलने का कारण बनती है) कुछ मिलीसेकंड देर से पहुंचती है लेकिन अगर कोई स्प्राइट गलत अवस्था में खींची जाती है तो यह महत्वपूर्ण है।

— फाइनव

2

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

यह निर्भर करता है कि जब आप रेंडर () कहते हैं तो आपकी वस्तुएं वास्तव में क्या कर रही हैं। जब तक वे सिर्फ आपके ग्राफिक्स इंजन के चारों ओर विधि कॉल लपेटते हैं, यह पूरी तरह से ठीक है, क्योंकि लॉज <-> ग्राफिक्स अंतर अभी भी दिया जाएगा।

उदाहरण के लिए, यदि आपके रेंडर () विधियां मूल रूप से सुविधा-विधियां हैं और कुछ इस तरह दिखती हैं:

void MyClass::render(const Graphics &g)
{
    g.draw(this);
}

या

void MyClass::render()
{
   mySprite->render();
}

या

void MyClass::render()
{
    mySprite->UseShader(thatshader);
    mySprite->render();
}

या उसके करीब, मुझे नहीं लगता कि यह कोई समस्या है।

— TravisG
स्रोत