गेम इंजन में घटना-संचालित संचार: हाँ या नहीं?

Question

मैं गेम कोडिंग कम्प्लीट पढ़ रहा हूं और लेखक गेम ऑब्जेक्ट्स और मॉड्यूल के बीच इवेंट ड्रिवेन कम्युनिकेशन की सिफारिश करता है ।

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

क्या यह एक सिद्ध और अनुशंसित दृष्टिकोण है? मुझे यह कैसे तय करना चाहिए कि क्या इसका उपयोग करना है?

Comments

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

— बंकई.टोरि

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

— जेम्स

आप इस उत्तर की जाँच c ++ 11: stackoverflow.com/a/22703242/2929762

— user2826084

libuvहाल ही में एक सफल इवेंट लाइब्रेरी के रूप में उभरा है। (यह सी। नोड में है। इसका सबसे प्रसिद्ध उपयोग केस है।)

— अंको

Answer 1

यह एक पूर्ण उत्तर के लिए मेरी टिप्पणी का विस्तार है , जैसा कि सुझाव दिया गया है।

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

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

संपादित करें : आप कैसे जानते हैं कि किन वस्तुओं को संदेश मिलना चाहिए, इस पर एक टिप्पणी प्रश्न को संबोधित करने के लिए : वस्तुओं को Requestघटनाओं के बारे में सूचित किया जाना चाहिए । आपके EventMessagingSystem(ईएमएस) Register(int iEventId, IEventMessagingSystem * pOjbect, (EMSCallback)fpMethodToUseForACallback)को एक मिलान Unregister( iEventIdऑब्जेक्ट पॉइंटर और कॉलबैक से बाहर के लिए एक अद्वितीय प्रविष्टि बनाने ) की आवश्यकता होगी । इस तरह, जब कोई वस्तु किसी संदेश के बारे में जानना चाहती है तो वह Register()सिस्टम के साथ हो सकती है। जब इसे अब घटनाओं के बारे में जानने की जरूरत नहीं है, तो यह हो सकता हैUnregister()। स्पष्ट रूप से, आप इन कॉलबैक पंजीकरण वस्तुओं का एक पूल और सूचियों से उन्हें जोड़ने / हटाने का एक प्रभावी तरीका चाहते हैं। (मैंने आमतौर पर स्व-आदेश देने वाले सरणियों का उपयोग किया है; यह कहने का एक फैंसी तरीका है कि वे अप्रयुक्त वस्तुओं और सरणियों के पूल स्टैक के बीच अपने आवंटन को ट्रैक करते हैं जो ज़रूरत पड़ने पर अपने आकार को स्थानांतरित करते हैं)।

EDIT : अपडेट लूप और इवेंट मैसेजिंग सिस्टम के साथ पूरी तरह से काम करने वाले गेम के लिए, आप मेरा एक पुराना स्कूल प्रोजेक्ट देखना चाहते हैं । ऊपर लिंक स्टैक अतिप्रवाह पोस्ट भी इसे संदर्भित करता है।

Comments

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

— बंकई। कटोरी

जिस तरह से मेरे उपरोक्त उत्तर कार्यों में सिस्टम जुड़ा हुआ है, वह यह है कि ऑब्जेक्ट केवल उन संदेशों के बारे में सुनने के लिए रजिस्टर करते हैं जो हम चाहते हैं .. हम इसका उपयोग वीडियो गेम में अपने लाभ के लिए करेंगे जहां एक स्तर में 100-200 ऑब्जेक्ट हो सकते हैं, लेकिन आप केवल 'सक्रिय' उन खिलाड़ियों के साथ सीधे बातचीत कर सकते हैं, जो लगभग 10 या उससे कम सुनने की संख्या रखते हैं। इस प्रकार की सभी व्यवस्थाओं में 'क्या हम अभी तक' की तुलना में 'स्मार्ट' हैं? मतदान प्रणाली, और जहां तक ​​संचार का संबंध है, कम से कम एक इंजन के ओवरहेड को कम करना चाहिए।

— जेम्स

ईवेंट संचालित सिस्टम से जुड़ी एक बात है जो मुझे भ्रमित करती है: पारंपरिक प्रणाली के तहत जहां हर वस्तु में तरीकों का पूर्वनिर्धारित सेट होता है (OnUpdate (), OnMove (), OnAI (), OnCollisionCheck () ... नियमित रूप से कहा जाता है, प्रत्येक ऑब्जेक्ट है अपने राज्य की जाँच और प्रबंधन के लिए प्रतिक्रियाशील। इवेंट संचालित सिस्टम के तहत, प्रत्येक ऑब्जेक्ट की कुछ मास्टर सिस्टम चेसिंग स्थिति होनी चाहिए, और फिर उन लोगों को संदेश भेजना चाहिए जहां कुछ घटना का पता चला था। मेरे लिए, यह संभव ऑब्जेक्ट राज्यों को मानकीकृत करता है, और अद्वितीय ऑब्जेक्ट व्यवहार बनाने के लिए स्वतंत्रता को सीमित करता है। क्या यह सच है?

— बंकई.टोरि

प्रेक्षक पैटर्न मतदान के लिए विशिष्ट विकल्प है। en.wikipedia.org/wiki/Observer_pattern

— Ricket

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

— जेम्स

Answer 2

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

और यह ठीक है, क्योंकि जब आप कर लेते हैं तो आपके पास वास्तव में एक गेम होगा, और एक गेम एक संदेश-गुजरने वाली प्रणाली की तुलना में अच्छा है।

Comments

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

— बंकई.सटोरि

यही कारण है कि प्रणाली मौजूद है। बहुत से लोगों ने सिर्फ वही किया है जो आपने कहा है, दुःस्वप्न का गवाह है, और कहा कि बेहतर तरीका होना चाहिए। आप या तो अपनी गलतियों को दोहरा सकते हैं या उनसे सीख सकते हैं और शायद इसे और अधिक आगे बढ़ा सकते हैं।

— 1944 में user441521

Answer 3

एक बेहतर सवाल यह है कि क्या विकल्प हैं? भौतिकी, एआई, आदि के लिए ठीक से विभाजित मॉड्यूल के साथ इस तरह की एक जटिल प्रणाली में, आप इन प्रणालियों को और कैसे व्यवस्थित कर सकते हैं?

संदेश पास करना इस समस्या का "सबसे अच्छा" समाधान प्रतीत होता है। मैं अभी विकल्पों के बारे में नहीं सोच सकता। लेकिन व्यवहार में संदेश के कई उदाहरण हैं। वास्तव में, ऑपरेटिंग सिस्टम अपने कई कार्यों के लिए संदेश पासिंग का उपयोग करते हैं। से विकिपीडिया :

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

(इंटरप्रोसेस संचार ऑपरेटिंग सिस्टम पर्यावरण के भीतर प्रक्रियाओं (यानी कार्यक्रमों के चल रहे उदाहरण) के बीच संचार है)

तो अगर यह एक ऑपरेटिंग सिस्टम के लिए पर्याप्त है, तो यह शायद एक गेम के लिए काफी अच्छा है, है ना? वहाँ के रूप में अच्छी तरह से अन्य लाभ कर रहे हैं, लेकिन मैं संदेश पासिंग पर विकिपीडिया लेख की व्याख्या कर दूँगा ।

मैंने स्टैक ओवरफ्लो पर एक सवाल भी पूछा, "प्रोग्राम के भीतर संदेश भेजने के लिए डेटा संरचनाएं?" , जिसे आप पढ़ना चाहते हैं।

Comments

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

— बंकई.तोरी

मुझे इस प्रश्न को कुछ समय के लिए खुला रखने दें। मैं इसे बंद करने से पहले अधिक राय इकट्ठा करना चाहूंगा।

— 1930 को बंकई.टोरि

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

— Ricket

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

— बंकई.टोरि

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

— deft_code

Answer 4

संदेश आम तौर पर तब काम करते हैं जब:

1. यदि संदेश प्राप्त होता है तो संदेश भेजने की कोई परवाह नहीं है।
2. प्रेषक को रिसीवर से तत्काल प्रतिक्रिया प्राप्त करने की आवश्यकता नहीं है।
3. एक प्रेषक को सुनने के लिए कई रिसीवर हो सकते हैं।
4. संदेश बार-बार या अप्रत्याशित रूप से भेजे जाएंगे। (दूसरे शब्दों में, यदि प्रत्येक ऑब्जेक्ट को हर एक फ्रेम में "अपडेट" संदेश प्राप्त करने की आवश्यकता होती है, तो संदेश वास्तव में आपको अधिक नहीं खरीद रहे हैं।)

आपकी आवश्यकताएं उस सूची से अधिक मेल खाती हैं, एक बेहतर संदेश होगा। बहुत सामान्य स्तर पर, वे बहुत अच्छे हैं। वे सीपीयू चक्रों को बर्बाद न करने का एक अच्छा काम करते हैं, ताकि मतदान या अन्य वैश्विक समाधानों के विपरीत कुछ भी न करें। वे एक कोडबेस के डिकॉउलिंग भागों में शानदार हैं, जो हमेशा मददगार होता है।

Answer 5

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

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

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

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

Comments

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

— Bunkai.Satori

Answer 6

वैसे, मुझे पता है कि यह पोस्ट काफी पुरानी है, लेकिन मैं विरोध नहीं कर सका।

मैंने हाल ही में एक गेम इंजन बनाया है। यह प्रतिपादन और भौतिकी के लिए 3 डी पार्टी पुस्तकालयों का उपयोग करता है, लेकिन मैंने मुख्य भाग लिखा, जो संस्थाओं और गेम लॉजिक को परिभाषित और संसाधित करता है।

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

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

आदिम संदेश प्रणाली के बावजूद, मैं कहूंगा कि यह प्रणाली काफी हद तक "अपडेट लूप आधारित" है।

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

लेकिन, मुझे यह भी लगता है कि मेरी तरह एक शुद्ध "अपडेट लूप आधारित" प्रणाली में भी कुछ समस्याएं हैं।

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

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

Comments

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

— user441521

Answer 7

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

घटनाओं का एक और बड़ा लाभ यह है कि उन्हें आसानी से एक नेटवर्क या अन्य टेक्स्ट चैनल पर स्ट्रीम किया जाता है। आप उन्हें बाद में प्लेबैक के लिए रिकॉर्ड कर सकते हैं। संभावनाएं अनंत हैं।

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

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

अधिक विवरण और यहां एक कार्यान्वयन ।

Comments

महान अंक, हालांकि एक तरफा। मुझे हमेशा सामान्यता पर संदेह है: क्या घटनाओं के लिए विरोधी -मामले हैं?

— अंको

विरोधी उपयोग बिंदु: जब आप बिल्कुल सीधे प्रतिक्रिया होनी चाहिए। जब आप किसी घटना पर जो करना चाहते हैं, उसे हमेशा सीधे और उसी धागे में अंजाम दिया जाता है। जब पूरी तरह से बाहर की देरी नहीं होती है तो कॉल पूरा होने में देरी हो सकती है। जब आपके पास केवल रैखिक निर्भरताएं होती हैं। जब आप शायद ही कभी एक साथ कई काम करते हैं। यदि आप node.js को देखते हैं, तो सभी io कॉल घटना आधारित हैं। Node.js एक जगह है जहाँ घटनाओं को 100% सही ढंग से लागू किया गया है।

— user2826084

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

— 1944 पर user441521

Answer 8

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

• गेम इंजन बड़ी मात्रा में डेटा से निपटते हैं।
• खेलों को तेज होना चाहिए (20-30 एफपीएस न्यूनतम होना चाहिए)।
• अक्सर यह जानना आवश्यक है कि क्या कुछ किया गया है या कब किया जाएगा।

आम गेम डेवलपर के दृष्टिकोण के साथ "यह यथासंभव कुशल होना चाहिए" इस तरह के मैसेजिंग सिस्टम इस तरह से आम नहीं हैं।

हालाँकि, मैं इस बात से सहमत हूँ कि आपको बस आगे बढ़कर प्रयास करना चाहिए। ऐसी प्रणाली के साथ निश्चित रूप से बहुत सारे फायदे हैं और कंप्यूटिंग शक्ति आज सस्ते में उपलब्ध है।

Comments

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

— user441521

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

— इयान यंग