गेम डिज़ाइन में प्रति-फ़्रेम फ़ंक्शन कॉल बनाम इवेंट ड्रिविंग मैसेजिंग

Question

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

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

इवेंट ड्रिवेन गेम आर्किटेक्चर का अच्छी तरह से वर्णन किया गया है: माइक मैकशाफ्ट्री द्वारा पूरा किया गया गेम कोडिंग ।

क्या मैं निम्नलिखित प्रश्नों के लिए मदद माँग सकता हूँ:

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

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

---

उदाहरण: इस सवाल से यहां थोड़ा विवाद हुआ, इसलिए मैं आपको उदाहरण पेश करता हूं: एमवीसी के अनुसार, गेम इंजन तीन मुख्य भागों में विभाजित है:

1. अनुप्रयोग परत (हार्डवेयर और OS संचार)
2. खेल तर्क
3. खेल देखें

एक रेसिंग गेम में, गेम व्यू स्क्रीन को जितनी जल्दी हो सके, कम से कम 30fps के रूप में प्रस्तुत करने के लिए जिम्मेदार है। गेम व्यू प्लेयर के इनपुट के लिए भी सुनता है। अब यह होता है:

• खिलाड़ी ने 80% तक ईंधन पेडल दबाया
• GameView एक संदेश "कार 2 ईंधन पेडल को 80% तक दबाया" बनाता है और इसे गेम लॉजिक में भेजता है।
• गेम लॉजिक संदेश प्राप्त करता है, मूल्यांकन करता है, नई कार की स्थिति और व्यवहार की गणना करता है और गेम व्यू के लिए निम्न संदेश बनाता है: "ड्रा कार 2 ईंधन पेडल दबाया 80%", "कार 2 ध्वनि त्वरण", "कार 2 निर्देशांक X, Y: ।। ।
• GameView संदेशों को प्राप्त करता है और तदनुसार उन्हें संसाधित करता है

Comments

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

— nkint

हाय Nkint, आपकी टिप्पणी के लिए धन्यवाद। मैं मूल रूप से ईवेंट संचालित संचार बनाम कॉल की तुलना आभासी कार्यों से करना चाहता था। मैं अपने प्रश्न को थोड़ा संशोधित करूंगा। : Btw, इस लिंक पर खेल desing पैटर्न युक्त पर एक नज़र डालें gameprogrammingpatterns.com ।

— Bunkai.Satori

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

— तेतराद

इसके अलावा, कार्यान्वयन के विवरण के लिए दक्षता अत्यधिक बंधी होने वाली है। मुझे नहीं लगता कि "कौन सा अधिक कुशल है" एक ऐसा प्रश्न है जिसका उत्तर इसके वर्तमान रूप में दिया जा सकता है।

— तेतराद

गेम ऑब्जेक्ट्स को टिक करने की आवश्यकता है। गेम ऑब्जेक्ट्स को एक-दूसरे के साथ संवाद करने की आवश्यकता होती है। उन दोनों चीजों को होने की जरूरत है। पहले आप मैसेजिंग के साथ नहीं करते हैं क्योंकि यह बेमानी है (आपके पास शायद सभी वस्तुओं की एक सूची है, बस updateउन पर कॉल करें)। दूसरा आप विभिन्न कारणों से संदेश के साथ कर सकते हैं।

— तेतड़

Answer 1

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

दोनों दृष्टिकोणों के फायदे और नुकसान क्या हैं?

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

एक दूसरे पर बेहतर कहां है?

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

क्या ईवेंट संचालित गेम डिज़ाइन सभी क्षेत्रों में सार्वभौमिक और बेहतर है? इसलिए मोबाइल प्लेटफॉर्म में भी इसका उपयोग करने की सिफारिश की जाती है?

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

कौन सा अधिक कुशल है और जिसे विकसित करना अधिक कठिन है?

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

Comments

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

— बंकई.टोरि

मैं असहमत हूं। यदि समग्र ऑब्जेक्ट डिज़ाइन अच्छी तरह से समझाया गया है, तो यह किसी भी तरह के ढांचे में उपयोग किए जाने के लिए पर्याप्त लचीला होना चाहिए। मैं बहुत कम काम के साथ बड़ी परियोजनाओं में संचार विधियों को स्वैप करने में सक्षम रहा हूं क्योंकि प्रत्येक टुकड़ा अच्छी तरह से समझाया गया था।

— एलिक रॉबर्टसन

Answer 2

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

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

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

नीचे पंक्ति: कोई बेहतर दृष्टिकोण नहीं है, न ही वे अनन्य हैं।

Comments

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

— Bunkai.Satori

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

— बंमज़ैक

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

— Bunkai.Satori

मूल प्रश्न से नीचे टेट्रड की टिप्पणियों को दर्शाने वाले उत्तर के लिए अप-वोट किया गया। @ Bunkai.Satori 'खेल की दुनिया में केवल एक बार जाँच की जाती है' अपडेट लूप है, जो कुछ भी अद्यतन करने की आवश्यकता है वह इसे प्राप्त करता है। ईवेंट मैसेज का अर्थ होता है कि शायद ही कभी इंजन में काम किया गया हो (प्लेयरडीड, मॉन्सटराइड, इत्यादि) जो कि अपडेट () लूप के हर फ्रेम की जाँच करना एक बेकार बात होगी, लेकिन वे इसके द्वारा उत्पन्न होने की सबसे अधिक संभावना है। अपडेट () लूप ही।

— जेम्स

यदि आपको दूसरा संस्करण मिला है, तो कन्ट्रोलिंग द मेन लूप नाम के अध्याय को देखें। इसे तीसरे संस्करण में समान नाम दिया जाना चाहिए। जो वास्तव में आपके प्रश्न का उत्तर देना चाहिए।

— राय डे

Answer 3

यह बुमज़ैक के उत्तर के लिए एक टिप्पणी के रूप में शुरू हुआ, लेकिन लंबे समय तक मिला।

जब तक आप वास्तव में इसे अतुल्यकालिक (एक नए धागे पर प्रेषण घटनाएँ) नहीं बनाते हैं, तब तक आपकी वस्तुएं अभी भी ज्ञापन को समकालिक रूप से प्राप्त कर रही हैं। मान लें कि आपके ईवेंट डिस्पैचर एक सेल में लिंक की गई सूची के साथ एक मूल हैश तालिका का उपयोग करता है, तो ऑर्डर उस क्रम में होगा जिसमें वस्तुओं को उस सेल में एड किया गया था।

इसके अलावा, जब तक आप किसी कारण से फ़ंक्शन पॉइंटर्स का उपयोग करने का निर्णय नहीं लेते हैं, तब भी आप वर्चुअल फ़ंक्शन कॉल का उपयोग कर रहे हैं क्योंकि प्रत्येक ऑब्जेक्ट को एक संदेश प्राप्त करना IEventListener (या जो भी आप इसे कहते हैं) को लागू करना चाहिए। घटनाएँ एक उच्च स्तरीय अमूर्तता है जिसे आप बहुरूपता का उपयोग करके बनाते हैं।

उन घटनाओं का उपयोग करें, जहाँ आप गेम में होने वाली विभिन्न प्रणालियों को सिंक्रनाइज़ करने के लिए या जहाँ विभिन्न ऑब्जेक्ट्स और सिस्टम की प्रतिक्रिया के लिए विभिन्न इन-गेम में होने वाली विधियों की लॉन्ड्री सूची को कॉल करते हैं, ऐसा कहा गया है कि स्पष्ट रूप से परिभाषित नहीं किया जा सकता है या आप चाहते हैं भविष्य में होने वाली घटनाओं के लिए और प्रतिक्रियाएँ जोड़ना।

वे एक महान उपकरण हैं, लेकिन बुमज़ैक ने कहा, यह मत मानो कि बहुरूपता और घटनाएँ एक ही समस्या को हल करती हैं।

Comments

हाय Bearcdp, आपके उत्तर के लिए धन्यवाद। यह मुझे समझ में आता है। मेरे दिमाग में एक बात है, जो ईवेंट संदेशों के लिए वोट करता है: कहते हैं, दृश्य में 200 ओजेक्ट हैं। यदि आप सभी ऑब्जेक्ट्स पर प्रति-फ्रेम फ़ंक्शन कॉल का उपयोग करते हैं, तो आपको प्रत्येक फ़्रेम में कॉलिशन के लिए सभी 200 ऑब्जेक्ट्स की जांच करनी होगी (उदाहरण के लिए कॉल अंतराल को प्रबंधित किया जा सकता है।) ईवेंट मैसेजिंग के साथ, गेमवर्ल्ड की केवल एक बार जांच की जाती है। यदि 5 टकराव होते हैं, तो टक्कर की घटना के बारे में संदेशों द्वारा केवल 5 वस्तुओं को अधिसूचित किया जाता है, बजाय प्रति-कॉल कॉल के साथ 200 टकराव का पता लगाने के परीक्षण। आप की राय क्या है?

— बंकई.टोरि

Gameworld की जाँच करें ?? इसका क्या मतलब है? इसका मतलब 5 को अलग करने के लिए उसी 200 चेक को चलाना होगा जिसके बारे में संदेश भेजने की आवश्यकता है। वर्चुअल फ़ंक्शन कॉन्सेप्ट के साथ, गेमवर्ल्ड को केवल एक बार भी चेक किया जा रहा है (प्रत्येक ऑब्जेक्ट का फ़ंक्शन बदले में), और उसके बाद केवल 5 पर चलता है, जो राज्य परिवर्तनों की आवश्यकता है ... एक मैसेजिंग सिस्टम के ओवरहेड के बिना।

— स्टीव एच।

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

— michael.bartnett

हाय स्टीव और दाढ़ी, आपकी टिप्पणी के लिए धन्यवाद। आपने जो लिखा है वह समझ में आता है। ऐसा लगता है कि ईवेंट मैसेजिंग सिस्टम के कई संभावित कार्यान्वयन हो सकते हैं। प्रति फ्रेम वर्चुअल फ़ंक्शन कॉन्सेप्ट का शुद्ध प्रतिस्थापन हो सकता है, जैसा कि ऊपर बताई गई पुस्तक कहती है। हालाँकि, मैसेजिंग सिस्टम प्रति-फ्रेम वर्चुअल फंक्शन कॉन्सेप्ट के साथ-साथ, जैसा कि आप कह सकते हैं, साथ कर सकते हैं।

— बंकई.टोरि

फ़ंक्शन पॉइंटर्स के संदर्भ में आप "किसी कारण से" क्यों कहते हैं? यह बहुत ज्यादा है कि मैंने एक घटना प्रणाली को कैसे लागू किया है जो मैंने एक बार खरोंच से लिखा है (मैं उन भाषाओं में काम करता हूं जिनके पास प्रथम श्रेणी के कार्य हैं लेकिन एक ही विचार है; फ़ंक्शन को इवेंट हब ऑब्जेक्ट पर पास करें और वह ऑब्जेक्ट मैप श्रोता कार्यों को मैप करता है। घटनाएँ) इसलिए मुझे आश्चर्य हो रहा है कि क्या उस दृष्टिकोण का कोई नुकसान है।

— झॉकिंग

Answer 4

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

हालाँकि, मैं अपने ऑब्जेक्ट प्रबंधन ऑब्जेक्ट, या मेरे उपयोगकर्ता इनपुट ऑब्जेक्ट, या ऐसा कुछ भी करने के लिए हर फ़्रेम को कॉल नहीं करता। फ्रेम पर हर वस्तु के लिए बड़े पैमाने पर आभासी कॉल एक भयानक विचार है।

किसी विशेष वस्तु के लिए उपयोग किया जाने वाला डिज़ाइन उन वस्तुओं की जरूरतों पर आधारित होना चाहिए, न कि सिस्टम के लिए कुछ विचारधारा पर आधारित होना चाहिए ।

मेरे पहले वाक्य पर अधिक स्पष्ट होने का संपादन किया।

Comments

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

— Bunkai.Satori

@ बंकई: तो आपके पास कुछ डिज़ाइन हैं जो ईवेंट-चालित हैं और कुछ डिज़ाइन जिन्हें प्रत्येक फ़्रेम कहा जाता है। वह बहुत ज्यादा मेरे जवाब से सहमत है।

— डेडएमजैन

मुझे आपके साथ समझने में खुशी हो रही है, क्योंकि यह सवाल आज यहां थोड़ा विवादास्पद था। :-)

— Bunkai.Satori