गेम ऑब्जेक्ट के प्रत्येक उदाहरण के लिए ड्राएबलजैमकंपोनेंट का उपयोग करने का विचार क्या है?

25

मैंने कई जगहों पर पढ़ा है कि ड्रॉएबलगेम कॉमपर्स को "स्तरों" या कुछ प्रकार के प्रबंधकों जैसे कि उन्हें उपयोग करने के बजाय, उदाहरण के लिए, वर्णों या टाइलों के लिए सहेजा जाना चाहिए (जैसे यह आदमी यहाँ कहता है )। लेकिन मुझे समझ नहीं आता कि ऐसा क्यों है। मैंने इस पोस्ट को पढ़ा और यह मेरे लिए बहुत मायने रखता है, लेकिन ये अल्पसंख्यक हैं।

मैं आमतौर पर इन जैसी चीजों पर बहुत ज्यादा ध्यान नहीं देता, लेकिन इस मामले में मैं जानना चाहता हूं कि स्पष्ट बहुमत क्यों मानता है कि यह रास्ता नहीं है। शायद मुझे कुछ याद आ रहा है।

xna game-component

— केंजी कीना
स्रोत

मैं उत्सुक हूं कि दो साल बाद आपने मेरे जवाब से "स्वीकृत" निशान क्यों हटा दिया ? आम तौर पर मैं वास्तव में परवाह नहीं है - लेकिन इस मामले में यह VeraShackle के कारण बनता है क्रुद्ध मेरा उत्तर की गलत बयानी बुलबुले के शीर्ष करने के लिए :(

— एंड्रयू रसेल

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

— केंजी किना

1

मैं अपने उत्तर को इस प्रकार संक्षेप में प्रस्तुत कर सकता हूं: " लॉक्स का उपयोग करना DrawableGameComponentआपको एक ही विधि हस्ताक्षर और एक विशिष्ट बनाए रखा डेटा मॉडल में लॉक करता है। ये आमतौर पर शुरुआत में गलत विकल्प होते हैं, और लॉक-इन महत्वपूर्ण रूप से कोड के विकास में बाधा डालते हैं। "लेकिन मैं आपको बता दूं कि यहाँ क्या हो रहा है ...

— एंड्रयू रसेल

1

DrawableGameComponentकोर XNA एपीआई का हिस्सा है (फिर से: ज्यादातर ऐतिहासिक कारणों से)। नौसिखिए प्रोग्रामर इसका उपयोग करते हैं क्योंकि यह "वहां" है और यह "काम करता है" और वे किसी भी बेहतर को नहीं जानते हैं। वे मेरे उत्तर को यह कहते हुए देखते हैं कि वे " गलत " हैं और - मानव मनोविज्ञान की प्रकृति के कारण - इसे अस्वीकार करते हैं और दूसरे "पक्ष" को उठाते हैं। जो VeraShackle के तर्कहीन गैर-उत्तर होने के लिए होता है; जो गति लेने के लिए हुआ, क्योंकि मैंने इसे तुरंत कॉल नहीं किया था (उन टिप्पणियों को देखें)। मुझे लगता है कि मेरा अंतिम खंडन पर्याप्त है।

— एंड्रयू रसेल

1

अगर किसी को मेरे उत्तर की वैधता पर सवाल उठने के आधार पर सवाल उठने में दिलचस्पी है: जबकि यह सच है कि (जीडीएसई पूर्वोन्नत नौसिखियों से प्रभावित हो रहा है) वेराशाकले का जवाब हाल के वर्षों में मेरे मुकाबले एक जोड़े को अधिक से अधिक अर्जित करने में कामयाब रहा है , मत भूलना मेरे पास हजारों और बड़े नेटवर्क हैं, मोटे तौर पर XNA पर। मैंने कई प्लेटफार्मों पर XNA API लागू किया है। और मैं XNA का उपयोग करके एक पेशेवर गेम डेवलपर हूं। मेरे उत्तर की वंशावली त्रुटिहीन है।

— एंड्रयू रसेल

22

"गेम कंपोनेंट्स" XNA 1.0 डिज़ाइन का बहुत शुरुआती हिस्सा थे। वे WinForms के लिए नियंत्रण की तरह काम करने वाले थे। यह विचार था कि आप GUI (गैर-विज़ुअल नियंत्रण जोड़ने के लिए बिट की तरह, आदि) और उन पर गुण सेट करके अपने गेम में उन्हें ड्रैग-एंड-ड्रॉप कर सकेंगे।

तो आप शायद एक कैमरा या एक ... एफपीएस काउंटर? ... या ... जैसे घटक हो सकते हैं?

आप समझ सकते हैं? दुर्भाग्य से यह विचार वास्तव में वास्तविक दुनिया के खेल के लिए काम नहीं करता है। एक खेल के लिए आपको जिस तरह के घटक चाहिए वे वास्तव में पुन: प्रयोज्य नहीं हैं। आपके पास "खिलाड़ी" घटक हो सकता है, लेकिन यह हर दूसरे खेल के "खिलाड़ी" घटक के लिए बहुत अलग होगा।

मुझे लगता है कि यह इस कारण से था, और समय की एक साधारण कमी के लिए, कि GUI को XNA 1.0 से पहले खींच लिया गया था।

लेकिन एपीआई अभी भी प्रयोग करने योग्य है ... यहाँ आपको इसका उपयोग क्यों नहीं करना चाहिए:

मूल रूप से यह एक गेम डेवलपर के रूप में लिखने और पढ़ने और डिबग करने और बनाए रखने में सबसे आसान है। अपने लोडिंग कोड में ऐसा कुछ करना:

player.DrawOrder = 100;
enemy.DrawOrder = 200;

यह करने की तुलना में बहुत कम स्पष्ट है:

virtual void Draw(GameTime gameTime)
{
    player.Draw();
    enemy.Draw();
}

खासकर जब एक वास्तविक दुनिया के खेल में, आप कुछ इस तरह से समाप्त कर सकते हैं:

GraphicsDevice.Viewport = cameraOne.Viewport;
player.Draw(cameraOne, spriteBatch);
enemy.Draw(cameraOne, spriteBatch);

GraphicsDevice.Viewport = cameraTwo.Viewport;
player.Draw(cameraTwo, spriteBatch);
enemy.Draw(cameraTwo, spriteBatch);

(निश्चित रूप से आप समान Servicesआर्किटेक्चर का उपयोग करके कैमरा और स्प्राइटबैच साझा कर सकते हैं । लेकिन यह एक ही कारण के लिए एक बुरा विचार भी है।)

यह वास्तुकला - या इसके अभाव - बहुत अधिक हल्का वजन और लचीला है!

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

यह घोषणात्मक बनाम अनिवार्य प्रोग्रामिंग के बीच अंतर की तरह है। यह पता चला है कि, खेल के विकास के लिए, अनिवार्य प्रोग्रामिंग कहीं अधिक बेहतर है।

— एंड्रयू रसेल
स्रोत

2

मैं इस धारणा के तहत था कि वे घटक-आधारित प्रोग्रामिंग के लिए थे , जो स्पष्ट रूप से गेम प्रोग्रामिंग के लिए व्यापक रूप से उपयोग किया जाता है।

— ब्लूराजा - डैनी पफ्लुघोटे

3

XNA गेम घटक कक्षाएं वास्तव में सीधे उस पैटर्न पर लागू नहीं होती हैं। यह पैटर्न सभी वस्तुओं को कई घटकों से बनाने के बारे में है। XNA कक्षाएं एक घटक-प्रति-ऑब्जेक्ट पर आधारित होती हैं। यदि वे आपके डिजाइन में पूरी तरह से फिट होते हैं, तो हर तरह से उनका उपयोग करें। लेकिन आपको उनके आसपास अपने डिजाइन का निर्माण नहीं करना चाहिए ! यहां भी मेरा जवाब देखें - जहां मैं उल्लेख करता हूं, उसके लिए बाहर देखो DrawableGameComponent।

— एंड्रयू रसेल

1

मैं सहमत हूं कि GameComponent / Service आर्किटेक्चर यह सब उपयोगी नहीं है और किसी गेम फ्रेमवर्क में Office-जैसी या वेब एप्लिकेशन अवधारणाओं की तरह लगता है। लेकिन मैं player.DrawOrder = 100;ड्रॉ ऑर्डर के लिए जरूरी से अधिक विधि का उपयोग करना पसंद करूंगा । मैं अभी एक फ्लिक्सल गेम खत्म कर रहा हूं, जो वस्तुओं को उस क्रम में खींचता है जिसमें आप उन्हें दृश्य में जोड़ते हैं। FlxGroup सिस्टम इसमें से कुछ को कम करता है, लेकिन कुछ प्रकार के Z-index सॉर्टिंग का निर्माण अच्छा होता।

— michael.bartnett

@ michael.bartnett ध्यान दें कि Flixel एक रिटेन-मोड API है, जबकि XNA (इसके अलावा, जाहिर है, गेम कंपोनेंट्स सिस्टम) एक तत्काल-मोड API है। यदि आप एक बनाए रखने वाले मोड एपीआई का उपयोग करते हैं, या अपना खुद का कार्यान्वयन करते हैं , तो फ्लाई पर ड्रा-ऑर्डर बदलने की क्षमता निश्चित रूप से महत्वपूर्ण है। वास्तव में, मक्खी पर ड्रॉ-ऑर्डर बदलने की आवश्यकता कुछ बनाए रखने के लिए एक अच्छा कारण है-मोड (एक विंडिंग सिस्टम का उदाहरण दिमाग में आता है)। लेकिन अगर आप तत्काल-मोड के रूप में कुछ लिख सकते हैं , यदि प्लेटफ़ॉर्म एपीआई (जैसे एक्सएनए) उस तरह से बनाया गया है, तो आईएमओ आपको चाहिए।

— एंड्रयू रसेल

आगे के संदर्भ के लिए gamedev.stackexchange.com/a/112664/56

— Kenji Kina

26

हममम। मुझे थोड़ा डर लगता है कि यहाँ संतुलन के लिए इसे चुनौती देता हूँ।

एंड्रयू के जवाब में 5 आरोप लग रहे हैं, इसलिए मैं कोशिश करूंगा और बदले में प्रत्येक से निपटूंगा:

1) घटक एक आउट-ऑफ-डेट और परित्यक्त डिज़ाइन हैं।

XNA से बहुत पहले घटकों के डिजाइन पैटर्न का विचार मौजूद था - संक्षेप में, यह केवल ऑब्जेक्ट बनाने के लिए एक निर्णय है, न कि ओवर-अर्चिंग गेम ऑब्जेक्ट, अपने स्वयं के अपडेट और ड्रा व्यवहार का घर। अपने घटक संग्रह में वस्तुओं के लिए, खेल इन विधियों (और कुछ के एक जोड़े) को उचित समय पर स्वचालित रूप से कॉल करेगा - महत्वपूर्ण रूप से गेम ऑब्जेक्ट को इस कोड में से किसी को भी 'जानना' नहीं है। यदि आप अलग-अलग खेलों (और इस प्रकार अलग-अलग गेम ऑब्जेक्ट्स) में अपनी गेम कक्षाओं का फिर से उपयोग करना चाहते हैं, तो वस्तुओं का यह डी-कपलिंग अभी भी fundementally एक अच्छा विचार है। AppHub से XNA4.0 के नवीनतम (पेशेवर रूप से निर्मित) डेमो पर एक त्वरित नज़र इस धारणा की पुष्टि करती है कि Microsoft अभी भी (मेरे विचार से काफी सही है) दृढ़ता से इस एक के पीछे है।

2) एंड्रयू 2 से अधिक पुन: प्रयोज्य गेम कक्षाओं के बारे में नहीं सोच सकता।

हाँ मैं। वास्तव में मैं भार के बारे में सोच सकता हूं! मैंने अभी-अभी अपने वर्तमान साझा काम की जाँच की है, और इसमें 80 से अधिक पुन: उपयोग योग्य घटक और सेवाएं शामिल हैं। आपको स्वाद देने के लिए, आप कर सकते हैं:

खेल राज्य / स्क्रीन प्रबंधक
ParticleEmitters
आकर्षित करने योग्य आदिम
एआई नियंत्रक
इनपुट नियंत्रक
एनीमेशन नियंत्रक
होर्डिंग
भौतिकी और टकराव प्रबंधक
कैमरा

किसी भी विशेष गेम विचार को इस सेट से कम से कम 5-10 चीजों की आवश्यकता होगी - गारंटी - और वे कोड की एक पंक्ति के साथ पूरी तरह से नए गेम में पूरी तरह कार्यात्मक हो सकते हैं।

3) स्पष्ट ड्रॉ कॉल के आदेश द्वारा ड्रॉ ऑर्डर को नियंत्रित करना घटक के ड्राऑर्डर प्रॉपर्टी का उपयोग करने के लिए बेहतर है।

खैर, मैं मूल रूप से एंड्रयू के साथ इस एक पर सहमत हूं। लेकिन, यदि आप सभी घटक ड्रॉऑर्डर के गुणों को डिफ़ॉल्ट के रूप में छोड़ देते हैं, तो आप अभी भी उनके ड्रा ऑर्डर को उस क्रम से नियंत्रित कर सकते हैं जिसमें आप उन्हें संग्रह में जोड़ते हैं। यह वास्तव में 'दृश्यता' की दृष्टि से उनके मैनुअल ड्रॉ कॉल्स के स्पष्ट क्रम के समान है।

4) ऑब्जेक्ट के ड्रॉ के तरीकों का एक लोडिंग खुद को एक मौजूदा फ्रेमवर्क विधि द्वारा कॉल करने की तुलना में अधिक 'हल्का' है।

क्यूं कर? इसके अलावा, सभी में लेकिन आपके अपडेट लॉजिक और ड्रा कोड की परियोजनाओं का सबसे तुच्छ तरीका किसी भी मामले में प्रदर्शन के मामले में आपकी पद्धति को पूरी तरह से कॉल करना होगा।

5) अपने कोड को एक फाइल में रखना, डिबगिंग के दौरान अलग-अलग ऑब्जेक्ट की फाइल में होने से बेहतर है।

ठीक है, सबसे पहले, जब मैं विज़ुअल स्टूडियो में डिबगिंग कर रहा हूं, तो डिस्क पर फ़ाइलों के संदर्भ में एक ब्रेकपॉइंट का स्थान इन दिनों लगभग अदृश्य है - आईडीई बिना किसी नाटक के स्थान के साथ संबंधित है। लेकिन एक पल के लिए भी विचार करें कि आपको अपने स्काईबॉक्स ड्राइंग की समस्या है। क्या स्काईबॉक्स ड्रॉ पद्धति वास्तव में गेम ऑब्जेक्ट में स्काईबॉक्स ड्राइंग कोड (संभवतः बहुत लंबा) मास्टर ड्रा विधि का पता लगाने की तुलना में अधिक शानदार है ? नहीं, वास्तव में नहीं - वास्तव में मैं तर्क दूंगा कि यह बिल्कुल विपरीत है।

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

— VeraShackle
स्रोत

2

मैंने केवल इस पोस्ट पर ध्यान दिया, और मुझे एक मजबूत खंडन जारी करना चाहिए: मेरे पास पुन: प्रयोज्य वर्गों के साथ कोई मुद्दा नहीं है! (जिसमें ड्रा और अपडेट के तरीके आदि हो सकते हैं। मैं ड्रॉ / अपडेट ऑर्डर पर स्पष्ट नियंत्रण खो देने के कारण (जो आप # 3 में सहमत हूं ) के उपयोग के कारण विशिष्ट मुद्दा ले रहा हूं ( Drawable) GameComponentउनके इंटरफेस (जिसे आप संबोधित नहीं करते हैं)।

— एंड्रयू रसेल

1

आपका बिंदु # 4 मेरे हल्के शब्द का उपयोग प्रदर्शन के लिए करता है, जहां मैं वास्तव में स्पष्ट रूप से वास्तुशिल्प लचीलेपन का मतलब है। आपके शेष अंक # 1, # 2, और विशेष रूप से # 5 बेतुके पुआल-आदमी को खड़ा करते प्रतीत होते हैं कि मुझे लगता है कि ज्यादातर / सभी कोड आपके मुख्य गेम क्लास में भेज दिए जाने चाहिए! वास्तुकला पर मेरे कुछ और अधिक विस्तृत विचारों के लिए मेरा जवाब यहां पढ़ें ।

— एंड्रयू रसेल

5

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

— एंड्रयू रसेल

मुझे गलत समझा जा सकता है, लेकिन यह सवाल का जवाब कैसे देता है? क्या मुझे अपने स्प्राइट्स के लिए GameComponent का उपयोग करना चाहिए या नहीं?

— शानदार

आगे खंडन: gamedev.stackexchange.com/a/112664/56

— किना

4

मैं एंड्रयू से थोड़ा असहमत हूं, लेकिन मुझे भी लगता है कि हर चीज के लिए एक समय और जगह होती है। मैं Drawable(GameComponent)एक प्रेत या दुश्मन के रूप में सरल के लिए कुछ के लिए उपयोग नहीं होगा । हालांकि, मैं इसके लिए एक प्रयोग करेंगे SpriteManagerया EnemyManager।

एंड्रयू ने ड्रॉ और अपडेट ऑर्डर के बारे में जो कहा है, उस पर वापस जाते हुए, मुझे लगता है कि Sprite.DrawOrderकई स्प्राइट्स के लिए यह बहुत भ्रामक होगा। इसके अलावा, अपने अपेक्षाकृत आसान एक स्थापित करने के लिए DrawOrderऔर UpdateOrderप्रबंधकों हैं कि के लिए एक छोटी सी (या उचित) राशि (Drawable)GameComponents।

मुझे लगता है कि अगर वे वास्तव में उस कठोर और किसी ने उनका उपयोग नहीं किया तो Microsoft ने उनके साथ दूर किया होगा। लेकिन वे नहीं हैं क्योंकि वे भूमिका पूरी तरह से ठीक है, अगर भूमिका सही है। मैं खुद उन्हें विकसित करने के लिए उपयोग करता हूं Game.Servicesजो पृष्ठभूमि में अपडेट किए गए हैं।

— अमबल लिगथर्ट्ज़
स्रोत

2

मैं इसके बारे में भी सोच रहा था, और यह मेरे साथ हुआ: उदाहरण के लिए, आपके लिंक में उदाहरण चोरी करने के लिए, आरटीएस गेम में आप हर यूनिट को एक गेम घटक उदाहरण बना सकते हैं। ठीक है।

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

— Superbest
स्रोत

2

टिप्पणियों में, मैंने अपने उत्तर पुराने उत्तर का एक संक्षिप्त संस्करण पोस्ट किया:

DrawableGameComponentताले का उपयोग करके आप एक एकल विधि हस्ताक्षर और एक विशिष्ट बनाए रखा डेटा मॉडल बनाते हैं। ये आमतौर पर शुरू में गलत विकल्प होते हैं, और लॉक-इन महत्वपूर्ण रूप से कोड के विकास में बाधा डालते हैं।

यहाँ मैं यह बताने का प्रयास करूँगा कि मेरे वर्तमान प्रोजेक्ट से कुछ कोड पोस्ट करके ऐसा क्यों है।

खेल की दुनिया की स्थिति को बनाए रखने वाली जड़ वस्तु में एक Updateविधि है जो इस तरह दिखाई देती है:

void Update(UpdateContext updateContext, MultiInputState currentInput)

Updateखेल में नेटवर्क पर चल रहा है या नहीं, इसके आधार पर कई प्रवेश-बिंदु हैं। यह संभव है, उदाहरण के लिए, खेल राज्य को समय में एक पिछले बिंदु पर वापस ले जाने के लिए और फिर से सिम्युलेटेड।

कुछ अतिरिक्त अपडेट जैसी विधियां भी हैं, जैसे:

void PlayerJoin(int playerIndex, string playerName, UpdateContext updateContext)

खेल राज्य के भीतर अद्यतन किए जाने वाले अभिनेताओं की एक सूची है। लेकिन यह एक साधारण Updateकॉल से अधिक है । भौतिकी को संभालने के पहले और बाद में अतिरिक्त पास हैं। अभिनेताओं के स्थगित / नष्ट करने के साथ-साथ स्तर परिवर्तन के लिए कुछ फैंसी सामान भी हैं।

खेल राज्य के बाहर, एक यूआई प्रणाली है जिसे स्वतंत्र रूप से प्रबंधित करने की आवश्यकता है। लेकिन UI में कुछ स्क्रीन को नेटवर्क के संदर्भ में भी चलाने में सक्षम होना चाहिए।

ड्राइंग के लिए, खेल की प्रकृति के कारण, एक कस्टम सॉर्टिंग और पुलिंग प्रणाली है जो इन विधियों से इनपुट लेती है:

virtual void RegisterToDraw(SortedDrawList sortedDrawList, Definitions definitions)
virtual void RegisterShadow(ShadowCasterList shadowCasterList, Definitions definitions)

और फिर, एक बार यह पता लग जाए कि क्या खींचना है, स्वचालित रूप से कॉल करें:

virtual void Draw(DrawContext drawContext, int tag)

tagपैरामीटर की आवश्यकता है, क्योंकि कुछ अभिनेताओं अन्य अभिनेताओं पर पकड़ कर सकते हैं - और इसलिए जरूरत दोनों के ऊपर और नीचे रखे हुए अभिनेता आकर्षित करने के लिए सक्षम होने के लिए। छँटाई प्रणाली सुनिश्चित करती है कि यह सही क्रम में होता है।

ड्रॉ करने के लिए मेनू सिस्टम भी है। और खेल के चारों ओर, HUD के आसपास, UI को चित्रित करने के लिए एक पदानुक्रमित प्रणाली।

अब उन आवश्यकताओं की तुलना करें जो DrawableGameComponentप्रदान करती हैं:

public class DrawableGameComponent
{
    public virtual void Update(GameTime gameTime);
    public virtual void Draw(GameTime gameTime);
    public int UpdateOrder { get; set; }
    public int DrawOrder { get; set; }
}

DrawableGameComponentऊपर वर्णित प्रणाली का उपयोग करके सिस्टम से प्राप्त करने का कोई उचित तरीका नहीं है। (और मामूली जटिलता के एक खेल के लिए वे असामान्य आवश्यकताएं नहीं हैं)।

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

लोग आमतौर पर क्या करते हैं, अगर वे DrawableGameComponentमार्ग को शुरू करते हैं, तो क्या वे हैक पर निर्माण करना शुरू करते हैं:

तरीकों को जोड़ने के बजाय, वे अपने स्वयं के आधार प्रकार के लिए कुछ बदसूरत डाउन-कास्टिंग करते हैं (केवल सीधे उपयोग क्यों नहीं करते?)।
छँटाई और आह्वान Draw/ के लिए कोड को बदलने के बजाय Update, वे कुछ बहुत धीमी गति से आदेश संख्याओं को बदलने के लिए करते हैं।
और सभी के लिए सबसे खराब: तरीकों में मापदंडों को जोड़ने के बजाय, वे मेमोरी स्थानों में "पास" "पैरामीटर" शुरू करते हैं जो स्टैक नहीं हैं (इसके लिए उपयोग Servicesलोकप्रिय है)। यह जटिल है, त्रुटि-प्रवण, धीमा, नाजुक, शायद ही कभी थ्रेड-सेफ, और यदि आप नेटवर्किंग जोड़ते हैं, तो बाहरी उपकरण, और इसी तरह एक समस्या बनने की संभावना है।

यह कोड को फिर से उपयोग में कठिन बनाता है , क्योंकि अब आपकी निर्भरता "घटक" के अंदर छिपी हुई है, बजाय एपीआई सीमा पर प्रकाशित होने के।
या, वे लगभग देखते हैं कि यह सब कितना पागल है, और DrawableGameComponentइन समस्याओं के आसपास काम करने के लिए "प्रबंधक" करना शुरू करें । सिवाय उनके अभी भी "प्रबंधक" सीमाओं पर ये समस्याएं हैं।

वांछित क्रम में इन "प्रबंधकों" को आसानी से विधि कॉल की एक श्रृंखला के साथ बदला जा सकता है। और कुछ भी जटिल नहीं है।

बेशक, एक बार जब आप उन हैक्स को नियोजित करना शुरू करते हैं, तो यह उन हैक को पूर्ववत करने के लिए वास्तविक काम लेता है जब आपको एहसास होता है कि आपको क्या DrawableGameComponentप्रदान करता है। आप " लॉक इन " हो जाते हैं । और प्रलोभन को अक्सर हैक पर ढेर करना जारी रखना होता है - जो व्यवहार में आपको नीचे गिरा देगा और उन खेलों के प्रकारों को सीमित कर देगा जिन्हें आप अपेक्षाकृत सरल बना सकते हैं।

बहुत सारे लोग इस बिंदु तक पहुंचते हैं और एक आंत प्रतिक्रिया होती है - संभवतः क्योंकि वे उपयोग करते हैं DrawableGameComponentऔर "गलत" होने को स्वीकार नहीं करना चाहते हैं। इसलिए वे इस तथ्य पर ध्यान देते हैं कि इसे "काम" करना कम से कम संभव है।

बेशक इसे "काम" किया जा सकता है ! हम प्रोग्रामर हैं - असामान्य बाधाओं के तहत काम करना व्यावहारिक रूप से हमारा काम है। लेकिन यह संयम आवश्यक, उपयोगी या तर्कसंगत नहीं है ...

इसके बारे में विशेष रूप से भड़कीला है कि यह इस पूरे मामले को साइड-स्टेप करने के लिए आश्चर्यजनक रूप से तुच्छ है। यहाँ, मैं आपको कोड भी दूंगा:

public class Actor
{
    public virtual void Update(GameTime gameTime);
    public virtual void Draw(GameTime gameTime);
}

List<Actor> actors = new List<Actor>();

foreach(var actor in actors)
    actor.Update(gameTime);

foreach(var actor in actors)
    actor.Draw(gameTime);

(यह आसान के अनुसार छँटाई में जोड़ने के लिए DrawOrderऔर UpdateOrder। एक आसान तरीका दो सूचियों, और उपयोग को बनाए रखना है List<T>.Sort()। यह भी संभाल करने के लिए मामूली बात है Load/ UnloadContent।)

यह महत्वपूर्ण नहीं है कि वास्तव में वह कोड क्या है । यह महत्वपूर्ण है कि मैं इसे तुच्छ रूप से संशोधित कर सकता हूं ।

जब मुझे पता चलता है कि मुझे एक अलग समय प्रणाली की gameTimeआवश्यकता है, या मुझे अधिक मापदंडों (या UpdateContextइसमें लगभग 15 चीजों के साथ एक संपूर्ण ऑब्जेक्ट) की आवश्यकता है, या मुझे ड्राइंग के लिए पूरी तरह से अलग-अलग ऑर्डर-ऑफ-ऑपरेशन की आवश्यकता है, या मुझे कुछ अतिरिक्त तरीकों की आवश्यकता है अलग-अलग अपडेट पास के लिए, मैं अभी आगे जाकर ऐसा कर सकता हूं ।

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

वास्तव में केवल एक ही परिदृश्य है जहां यह उपयोग करने के लिए एक अच्छा विकल्प है DrawableGameComponent: और यदि आप शाब्दिक रूप से XNA के लिए ड्रैग-एंड-ड्रॉप-घटक-शैली मिडलवेयर बना रहे हैं और प्रकाशित कर रहे हैं । जो इसका मूल उद्देश्य था। जो - मैं जोड़ूंगा - कोई नहीं कर रहा है!

(इसी तरह, यह केवलServices कस्टम सामग्री प्रकार बनाते समय उपयोग करने के लिए वास्तव में समझ में आता हैContentManager ।)

— एंड्रयू रसेल
स्रोत

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

— ग्रू डे