कुछ प्रोग्रामिंग डिज़ाइन पैटर्न क्या हैं जो खेल के विकास में उपयोगी हैं? [बन्द है]


129

मेरे पास डिज़ाइन पैटर्न पर कुछ किताबें हैं, और मैंने कुछ लेख पढ़े हैं, लेकिन यह सहज रूप से समझ नहीं पा रहा है कि कौन से प्रोग्रामिंग डिज़ाइन पैटर्न गेम के विकास में उपयोगी होंगे।

उदाहरण के लिए, मेरे पास डिज़ाइन पैटर्न के साथ एक्शनस्क्रिप्ट 3 नामक एक पुस्तक है जो कई डिज़ाइन पैटर्न जैसे कि मॉडल व्यू कंट्रोलर, सिंगलटन, फैक्टरी, कमांड, आदि का विवरण देती है।

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

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

धन्यवाद!


"शायद अन्य, अधिक गेम-प्रोग्रामिंग-विशिष्ट डिज़ाइन पैटर्न हैं जिनके बारे में मुझे पता भी नहीं है?" - नहीं, ये पैटर्न सामान्य हैं, और आपके द्वारा उपयोग की जा रही भाषा की क्षमताओं को बढ़ाने के लिए अधिक लागू होते हैं। उन्हें आपके आवेदन के विषय से कोई लेना देना नहीं है।
काइलोटन

3
@ किलोटन यह मेरे सीमित दृष्टिकोण से लगता है कि चूंकि प्रत्येक डिज़ाइन पैटर्न किसी विशेष समस्या को प्रभावी तरीके से संबोधित करने के लिए होता है, इसलिए उनकी प्रकृति के अनुसार कुछ डिज़ाइन पैटर्न दूसरों की तुलना में अधिक उपयोगी होंगे जो एक विशिष्ट समस्या सेट दिया जाता है, अर्थात् इस मामले में, वे समस्याएँ खेल के विकास के लिए अद्वितीय हैं। निश्चित रूप से कुछ दिशानिर्देश हैं, या आपके अनुभव, विशेष रूप से डिजाइन पैटर्न के आधार पर हैं जो आप खुद को दूसरों की तुलना में अधिक बार उपयोग करते हुए पाते हैं?
jcurrie33

इससे पहले कि किसी को भी बंद हो जाता है और 1000 विभिन्न डिजाइन पैटर्न सीखता है, कृपया इसे पढ़ें यह और इस
BlueRaja - डैनी Pflughoeft

@ BlueRaja-DannyPflughoeft Secon लिंक अमान्य है। क्या आप इसे फिर से भेज सकते हैं
Emadpres

जवाबों:


163

अब कुछ सुझावों के साथ, कम फ्लिपेंट प्रतिक्रिया के लिए। कार्यान्वयन अनुशंसाओं के रूप में मत लो, संभव उपयोग के उदाहरण के रूप में और अधिक।

  • बिल्डर: डेटा के आधार पर एक समय में एक घटक-आधारित इकाई स्थापित करें
  • फैक्टरी विधि: एक फाइल से पढ़े गए स्ट्रिंग के आधार पर एनपीसी या जीयूआई विजेट बनाएं
  • प्रोटोटाइप: प्रारंभिक गुणों के साथ एक जेनेरिक 'एल्फ' चरित्र को स्टोर करें और इसे क्लोन करके एल्फ इंस्टेंस बनाएं।
  • सिंगलटन: इस स्थान को जानबूझकर खाली छोड़ दिया गया।
  • एडॉप्टर: एक वैकल्पिक 3 पार्टी लाइब्रेरी को अपनी मौजूदा कोड की तरह दिखने वाली परत में लपेट कर शामिल करें। DLL के साथ बहुत उपयोगी है।
  • समग्र: रेंडर करने योग्य वस्तुओं का एक दृश्य ग्राफ बनाएं, या एक विजेट को एक विजेट के पेड़ से बाहर करें
  • मुखौटा: अपने जीवन को बाद में आसान बनाने के लिए एक सरल इंटरफ़ेस प्रदान करके जटिल 3 पार्टी पुस्तकालयों को सरल बनाएं।
  • फ्लाईवेट: एनपीसी के साझा पहलुओं (जैसे मॉडल, बनावट, एनिमेशन) को अलग-अलग पहलुओं (जैसे स्थिति, स्वास्थ्य) से अलग पारदर्शी तरीके से संग्रहीत करें।
  • प्रॉक्सी: एक क्लाइंट पर छोटी कक्षाएं बनाएं जो एक सर्वर पर बड़े, अधिक जटिल कक्षाओं का प्रतिनिधित्व करते हैं, और नेटवर्क के माध्यम से आगे अनुरोध करते हैं।
  • जिम्मेदारी की श्रृंखला: हैंडलर्स की एक श्रृंखला के रूप में इनपुट संभाल, उदा। वैश्विक कुंजी (उदाहरण के लिए स्क्रीन शॉट्स के लिए), फिर GUI (उदा। यदि टेक्स्ट बॉक्स केंद्रित है या मेनू ऊपर है), तो खेल (उदाहरण के लिए एक चरित्र को स्थानांतरित करने के लिए)।
  • कमांड: गेम की कार्यक्षमता को कमांड के रूप में एनकैप्सुलेट करें, जिसे गेम को टेस्ट करने में मदद करने के लिए कंसोल, स्टोर और रिप्ले, या यहां तक ​​कि स्क्रिप्टेड में टाइप किया जा सकता है।
  • मध्यस्थ: खेल संस्थाओं को एक छोटे मध्यस्थ वर्ग के रूप में कार्यान्वित करें जो विभिन्न घटकों पर काम करता है (उदाहरण के लिए AI घटक को डेटा पास करने के लिए स्वास्थ्य घटक से पढ़ना)।
  • पर्यवेक्षक: एक चरित्र का रेंडर करने योग्य प्रतिनिधित्व तार्किक प्रस्तुति से घटनाओं को सुनता है, ताकि दृश्य तर्क को बदलने के लिए जब गेम लॉजिक के बिना आवश्यक हो तो कोडिंग कोड के बारे में कुछ भी जानने की आवश्यकता न हो
  • राज्य: NPC AI को कई राज्यों में से एक के रूप में संग्रहीत करें, जैसे। हमला करना, भटकना, भागना। प्रत्येक की अपनी अपडेट () विधि और जो भी अन्य डेटा की आवश्यकता हो सकती है (जैसे। वह किस चरित्र पर हमला कर रहा है या वहां से भाग रहा है, जिस क्षेत्र में वह भटक रहा है, आदि)
  • रणनीति: अपने ए * खोज के लिए अलग-अलग उत्तराधिकारियों के बीच स्विच करें, इस बात पर निर्भर करता है कि आप किस इलाके में हैं, या शायद एक ही ए * ढांचे का उपयोग करने के लिए दोनों पथफाइंडिंग और अधिक सामान्य नियोजन
  • टेम्पलेट विधि: प्रत्येक कदम को संभालने के लिए विभिन्न हुक कार्यों के साथ एक सामान्य 'मुकाबला' दिनचर्या सेट करें, जैसे। डिक्री बारूद, हिट मौका की गणना, हिट या मिस को हल करें, क्षति की गणना करें, और प्रत्येक प्रकार के हमले कौशल अपने तरीके से तरीकों को लागू करेंगे।

कुछ पैटर्न प्रेरणा की कमी के कारण छोड़ दिए गए।



रणनीति पैटर्न के लिए +1। मैंने इसे ऊपर बताए गए सटीक उद्देश्य के लिए उपयोग किया है (अलग-अलग A * heuristics में प्लगिंग)।
माइक स्ट्रोबेल

1
इस उत्तर के लिए धन्यवाद, सामान्य "सिंगलटन" मैं हर जगह सुनने की तुलना में डिज़ाइन पैटर्न की तरह ध्वनि करता हूं ...
जोकून

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

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

59

मैंने उस विषय पर एक पुस्तक लिखी: गेम प्रोग्रामिंग पैटर्न । जो अध्याय हैं, वे आपके लिए उपयोगी हो सकते हैं।


2
+1 मैं उम्मीद कर रहा था कि कोई इससे जुड़ा था और मैं देखता हूं कि लेखक के पास है! घटक पैटर्न विवरण बहुत उपयोगी था, और मुझे यह पसंद है कि आप प्रदर्शित करने के लिए पूर्ण कोड उदाहरणों का उपयोग करने का प्रयास करें।
19x:54 पर कोडेक्सआर्कनम

2
हाँ - मुझे याद है कुछ साल पहले आपका लिंक पढ़ना। आप उन लेखों को समाप्त करें!
onedayitwillmake

2
अब पुस्तक समाप्त हो गई है :)
दुसान

1
एक अद्भुत संसाधन जिसने मुझे खेलों के लिए प्रोग्रामिंग में अपने मौजूदा प्रोग्रामिंग ज्ञान का अनुवाद करने में मदद की। इसे लिखने के लिए धन्यवाद!

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

19

एक बात ब्रैंडन ईच को काम में कोडर्स में लाने का अच्छा अर्थ था कि पैटर्न हैक और वर्कअराउंड हैं: [पैटर्न] भाषा में किसी प्रकार का दोष दिखाते हैं। ये पैटर्न मुक्त नहीं हैं। कोई मुफ्त भोजन नहीं है। इसलिए हमें उस भाषा में विकास की तलाश करनी चाहिए जो सही बिट्स को जोड़ती है।

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

अच्छा (गेम) कोड पैटर्न का उपयोग कर सकता है, या यह नहीं हो सकता है। यदि यह पैटर्न का उपयोग करता है, तो ठीक है - वे एक उच्च, भाषा-स्वतंत्र स्तर पर अन्य प्रोग्रामर को कोड संरचना समझाने के लिए एक महान संचार उपकरण हैं। यदि आपको लगता है कि पैटर्न का उपयोग किए बिना कोड बेहतर है, तो अपने आप को इस पर मत मारो - यह शायद है।


4
हां, मूल पुस्तक में (लेकिन अक्सर अनदेखी की गई) चीजों में से एक स्पष्ट है कि अगर इसे C ++ / Smalltalk के बजाय C के लिए लिखा गया था, तो हो सकता है कि उन्होंने "Inheritance" पैटर्न शामिल किया हो, और उसी टोकन से, कुछ भाषाएँ पहले से निर्मित कुछ
गो

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

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

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

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

7

बेशक, जैसा कि दूसरों ने कहा है, सभी पैटर्न सही परिस्थितियों में उपयोगी होते हैं, और उनका उपयोग करने का तरीका सीखने का हिस्सा है कि उनका उपयोग कब करना है। हालांकि, डैनियल सांचेज़-क्रेस्पो डलमऊ द्वारा गेम प्रोग्रामिंग में उत्कृष्ट पुस्तक कोर तकनीक और एल्गोरिदम , छह प्रोग्रामिंग पैटर्न और छह प्रयोज्य पैटर्न को सूचीबद्ध करते हैं, जो खेल प्रोग्रामिंग में विशेष रूप से उपयोगी हैं।

प्रोग्रामिंग:

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

प्रयोज्य:

  • ढाल: नाटकीय क्रियाओं के आकस्मिक सक्रियण से बचाता है।
  • राज्य: दुनिया के दृश्य संकेत / UI स्थिति।
  • स्वचालित मोड रद्द करना: खेल को अधिक तीव्रता से काम करता है।
  • चुंबकत्व: ऑटोइमिंग और आसान इकाई चयन।
  • ध्यान दें: विचलित यूआई तत्वों को खत्म करना।
  • प्रगति: विश्वविद्यालय रूप से उपयोगी।

बेशक, पुस्तक इनमें से प्रत्येक पर अधिक विस्तार से जाती है।


इनपुट के लिए धन्यवाद! मैं उस पुस्तक के बारे में नहीं जानता था, लेकिन आपके पोस्ट के परिणामस्वरूप अब इस पर गौर करूंगा। एक बार फिर धन्यवाद!
jcurrie33 15

2
कीबोर्ड रीडर के लिए सिंगलटन वास्तव में ऐसी स्थिति है, जहां मुझे पूछना है - क्या आप वास्तव में इसे केवल अपने मुख्य कार्य में वैश्विक संकेतक सेट नहीं कर सकते हैं? क्या आपने कभी गलती से दो कीबोर्ड पाठकों को तत्काल दिया है?

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

7

एंटिटी सिस्टम एक अच्छा प्रकार का पैटर्न है। यह बिल्कुल एक डिज़ाइन पैटर्न नहीं है क्योंकि यह ज़ोर से OOP नहीं है। हालाँकि आप इसे OOP के साथ मिला सकते हैं।

कुछ अच्छे लिंक (परिचय के लिए ऊपर से शुरू):


3
"यह बिल्कुल एक डिज़ाइन पैटर्न नहीं है क्योंकि यह सख्ती से नहीं है [sic] OOP।" डिज़ाइन पैटर्न का OOP से कोई लेना-देना नहीं है; अगर कुछ भी है, तो OOP खुद एक डिज़ाइन पैटर्न है। डिजाइन पैटर्न न केवल ओओपी के बाहर, बल्कि पूरी तरह से सॉफ्टवेयर विकास के बाहर दिखाई देते हैं।

वहाँ OOP design patternsआम तौर पर वर्गों / वस्तुओं के बीच संबंधों और बातचीत दिखाते हैं। और कई अन्य डिज़ाइन पैटर्न हैं। ओओपी अवधारणाओं का एक समूह है, न कि वास्तव में एक पैटर्न। Design patternएक अवधारणा भी है।
टॉपर

6
सिमेंटिक के बारे में बात करने के बजाय, क्या आपको मेरे द्वारा दी गई प्रतिक्रिया की उपयोगिता का मूल्यांकन नहीं करना चाहिए?
9

6

उन सभी को। सिवाय सिंगलटन के। [/ ओछापन]


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

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

@ jcurrie33: क्षमा करें, मैं पहले एकल पर एक खुदाई होने का विरोध नहीं कर सका। ;)
काइलोतन

6

वास्तव में पैटर्न के बारे में नहीं, बल्कि उनके पीछे मूल सिद्धांतों के बारे में। में "डिजाइन पैटर्न: पुन: प्रयोज्य वस्तु उन्मुख सॉफ्टवेयर के तत्वों" (1995) ,:, गिरोह के चार (गामा, एरिक रिचर्ड पतवार, राल्फ जॉनसन, और जॉन व्लिसाइडेस) वस्तु उन्मुख डिजाइन के लिए केवल दो सिद्धांतों की सिफारिश की (1) कार्यक्रम के लिए एक इंटरफेस और एक कार्यान्वयन के लिए नहीं और (2) वर्ग विरासत पर वस्तु संरचना।

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


गेम डिज़ाइन में उपयोग किए जाने वाले घटक एक स्टेटफुल स्ट्रेटेजी पैटर्न की तरह हैं - जो स्वाभाविक रूप से C / C ++ / Java / C # के बाहर क्लोज़र के रूप में व्यक्त किए जाते हैं, और उनके अंदर घटक ऑब्जेक्ट के रूप में। डेकोरेटर पैटर्न एक प्रॉक्सी की तरह अधिक है; इसका स्वामित्व और डेटा प्रवाह उन लोगों के विपरीत है जिनका सामान्य रूप से मतलब है जब हम खेलों में घटक प्रणालियों के बारे में बात करते हैं।

अवयवों को एक दूसरे से बात करने की भी ज़रूरत है, जो मध्यस्थ, पर्यवेक्षक और संगीतकार जैसे पैटर्न में लाते हैं। "कंपोनेंट-बेस्ड गेम" एक समग्र डिजाइन पैटर्न है।
19x पर कोडेक्सअर्नम

@CodexArcanum, ऑब्जर्वर, निश्चित रूप से, लेकिन हमेशा मध्यस्थ नहीं (जिम्मेदारियों की श्रृंखला इसके बजाय हो सकती है)। यह केवल तभी संगीतकार है जब GameObject (GameObjectComponent से बना) GameObjectComponent है (खुद नहीं)।
23

6

दिलचस्प आवर्ती टेम्पलेट पैटर्न आभासी तरीकों और प्रदर्शन दंड कि आभासी समारोह कॉल से आ सकता है से बचने के लिए वास्तव में उपयोगी हो सकता है।

यह उपयुक्त पैटर्न हो सकता है जब आपको वास्तव में बेस क्लास प्रकार के एक कंटेनर की आवश्यकता नहीं होती है, जिसमें आपके पास इंटरफ़ेस है, लेकिन आप इसी तरह के नाम और व्यवहार के इंटरफेस चाहते हैं।

उदाहरण के लिए, आप कई प्लेटफार्मों या इंजनों (dx बनाम opengl) के लिए कक्षाओं का संकलन करते समय इसका उपयोग कर सकते हैं जहां संकलन का प्रकार संकलन समय पर जाना जाता है।


मैं हमेशा नफरत करता था कि ओएस अमूर्त परत आभासी थी। ऐसा नहीं है कि आपको कभी भी दो ओएस एबट्रैक्शन परतों की आवश्यकता होगी। CRTP का उपयोग करने के लिए बेहतर है।
deft_code

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

4

एक डिज़ाइन पैटर्न जो मैं कई वर्षों के दौरान विकसित हुआ, और जो मेरे लिए शानदार रूप से उपयोगी रहा है, कुछ ऐसा है जिसे मैं "ब्रोकर्ड परिभाषा सेट" के रूप में संदर्भित करता हूं; इसे GOF शब्दों में संक्षेप में कैसे विवादास्पद प्रतीत होता है, लेकिन मैंने StackOverflow पर इसके बारे में लिखा यह प्रश्न इसके बारे में कुछ विस्तार से बताता है।

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


मैं यह नहीं देखता कि यह कैसे एक सिंगलटन है और जब फ्लाईवेट पैटर्न की चर्चा करते हुए "रजिस्ट्री" शब्द बेमानी है। यह सिर्फ फ्लाईवेट है।

SO थ्रेड से मेरी समझ यह थी कि लोगों ने सिंग्लटन की पहचान इसके वर्गों के रूप में स्थापित होने के कारण की थी। जहां तक ​​रजिस्ट्री जाती है, मैं यह नहीं देखता कि इसे कैसे बदला जा सकता है जब इसे फैक्ट्री से बदला या जोड़ा जा सकता है।
अराजकता

-1, हद तक पैटर्न के बारे में जल्दी से संवाद कर रहे हैं, यह शायद मैंने देखा सबसे बड़ी विफलता है। मैं वास्तव में इस विवरण को गंभीरता से नहीं ले सकता।

यीशु, मुझे आपके लिए पर्याप्त कुकी-कटर न होने के लिए क्षमा करें। क्या आप "एंटिटी सिस्टम" के जवाब को भी वोट करने जा रहे हैं क्योंकि यह GOF शब्दों में तुरंत संक्षिप्त नहीं है?
अराजक

1
"कुकी-कटर" या कम से कम अर्थ स्पष्टता की कुछ मात्रा, वास्तव में उपयोगी होने के लिए क्या पैटर्न होना चाहिए। "फ्लाईवेट" और "सिंगलटन" जैसी शर्तें, जैसा कि वे आमतौर पर समझा जाता है, पारस्परिक रूप से अनन्य हैं। पहला कई उदाहरणों के बीच डेटा को स्वचालित रूप से साझा करने के बारे में है; दूसरा बिल्कुल एक उदाहरण है। मैं यह नहीं कह रहा हूं कि आपकी डिजाइन पसंद बेकार या बुरी है, लेकिन "पर्याप्त रूप से बंद" पैटर्न नाम को एक साथ समेटना हर किसी को अधिक भ्रमित करता है। (कृपया व्यक्तिगत रूप से CW पर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.