यूनिटी 3 डी में स्क्रिप्ट के बीच बातचीत के आयोजन के तरीके

प्रविष्टि

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

दृष्टिकोण 1. यूनिटी 3 डी संपादक के माध्यम से असाइनमेंट

मान लीजिए कि हमारे पास प्रोजेक्ट की दो स्क्रिप्ट हैं। पहली क्रेक खेल में स्कोरिंग स्कोर के लिए जिम्मेदार है, और दूसरा यूजर इंटरफेस के लिए, जो गेम स्क्रीन पर स्कोर किए गए अंकों की संख्या को प्रदर्शित करता है।
हम दोनों स्क्रिप्ट मैनेजरों को बुलाएँगे: स्कोर्समैनगर और हुडमैनगर।
फिर, स्क्रीन मेनू के लिए जिम्मेदार प्रबंधक, कमाई के बिंदुओं के लिए जिम्मेदार प्रबंधक से वर्तमान अंकों की संख्या कैसे प्राप्त कर सकता है?
यह माना जाता है कि दृश्य की पदानुक्रम में वस्तुओं (पदानुक्रम) में दो ऑब्जेक्ट होते हैं, जिनमें से एक को स्कोर्समैनेगर स्क्रिप्ट को असाइन किया जाता है, और दूसरा HUDManager स्क्रिप्ट है।
एक दृष्टिकोण में निम्नलिखित सिद्धांत शामिल हैं:
UIManager स्क्रिप्ट में, ScoresManager प्रकार के एक चर को परिभाषित करें:

public class HUDManager : MonoBehaviour { public ScoresManager ScoresManager; } 

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



इसके बाद, पदानुक्रम विंडो से, स्कोर्समैनेगर स्क्रिप्ट वाली ऑब्जेक्ट को उस क्षेत्र में खींचें जहां कोई भी लिखा नहीं है और इसे घोषित चर में असाइन करें:



उसके बाद, हमारे पास HUDManager कोड से ScoresManager स्क्रिप्ट का उपयोग करने का अवसर है, इस तरह से:

 public class HUDManager : MonoBehaviour { public ScoresManager ScoresManager; public void Update () { ShowScores(ScoresManager.Scores); } } 

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

दृष्टिकोण 2. सिंगलटन

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

उदाहरण

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

 public class ScoresManager : MonoBehaviour { public static ScoresManager Instance { get; private set; } public int Scores; } 

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

 public class ScoresManager : MonoBehaviour { public static ScoresManager Instance { get; private set; } public int Scores; public void Awake() { Instance = this; } } 

उसके बाद, आप अन्य स्क्रिप्ट्स से ScoresManager का उपयोग इस प्रकार कर सकते हैं:

 public class HUDManager : MonoBehaviour { public void Update () { ShowScores(ScoresManager.Instance.Scores); } } 

अब HUDManager को ScoresManager प्रकार के क्षेत्र का वर्णन करने और इसे Unity3D संपादक में असाइन करने की कोई आवश्यकता नहीं है, कोई भी "स्क्रिप्ट प्रबंधक" स्थैतिक इंस्टेंस संपत्ति के माध्यम से खुद को एक्सेस प्रदान कर सकता है, जिसे आवक फ़ंक्शन में आरंभीकृत किया जाएगा।

आकर्षण आते हैं

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

विपक्ष

- दृष्टिकोण केवल "स्क्रिप्ट प्रबंधकों" तक पहुंच प्रदान करता है जो एक प्रतिलिपि में मौजूद हैं।
- मजबूत कनेक्टिविटी।
अंतिम "माइनस" अधिक विस्तार से रहता है।
आइए हम एक ऐसा खेल विकसित करें जिसमें पात्र (इकाई) हों और ये पात्र मर (मर) सकते हैं।
कहीं एक कोड का टुकड़ा है जो यह देखने के लिए जांचता है कि क्या हमारा चरित्र मर चुका है:

 public class Unit : MonoBehaviour { public int LifePoints; public void TakeDamage(int damage) { LifePoints -= damage; if (LifePoints <= 0) Die(); } } 

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

 private void Die() { DeleteFromScene(); ScoresManager.Instance.OnUnitDied(this); LevelConditionManager.Instance.OnUnitDied(this); UnitsPanel.Instance.RemoveUnit(this); SoundsManager.Instance.PlayUnitDieSound(); EffectsManager.Instance.PlaySmallExplosion(); AchivementsManager.Instance.OnUnitDied(this); AnaliticsManager.Instance.SendUnitDiedEvent(this); } 

यह पता चला है कि उनकी मृत्यु के बाद के चरित्र को उन सभी घटकों को भेजना चाहिए जो इस दुख की बात में रुचि रखते हैं, उन्हें इन घटकों के अस्तित्व के बारे में पता होना चाहिए और उन्हें पता होना चाहिए कि वे उसमें रुचि रखते हैं। क्या एक छोटी इकाई के लिए बहुत अधिक ज्ञान है?
चूंकि खेल, तार्किक रूप से, एक बहुत ही जुड़ा हुआ ढांचा है, तो अन्य घटकों में होने वाली घटनाएं तीसरे के लिए रुचि रखती हैं, यहां इकाई विशेष नहीं है।
इस तरह के आयोजनों के उदाहरण (बिना मतलब के):
- स्तर पास करने के लिए शर्त, स्कोर किए गए अंकों की संख्या पर निर्भर करता है, 1000 अंक बनाए - स्तर से गुजर गया (LevelConditionManager ScoresManager के साथ जुड़ा हुआ है)।
- जब हम 500 अंक एकत्र करते हैं, तो हम स्तर को पारित करने के एक महत्वपूर्ण चरण तक पहुँचते हैं, आपको एक मजेदार मेलोडी और विजुअल इफ़ेक्ट खेलने की आवश्यकता होती है (ScoresManager इफ़ेक्ट्समैन और साउंड्समैनेजर के साथ जुड़ा हुआ है)।
- जब चरित्र स्वास्थ्य को पुनर्स्थापित करता है, तो आपको चरित्र के पैनल में चरित्र के चित्र पर उपचार प्रभाव को चलाने की आवश्यकता होती है (UnitPanel प्रभाव प्रबंधक के साथ जुड़ा हुआ है)।
- और इतने पर।
इस तरह के कनेक्शनों के परिणामस्वरूप, हम निम्नलिखित के समान एक तस्वीर पर आते हैं, जहां हर कोई हर किसी के बारे में सब कुछ जानता है:



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

दृष्टिकोण 3. वर्ल्ड एथर (इवेंट एग्रीगेटर)

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

 public class UnitDiedEvent { private readonly List<Action<Unit>> _callbacks = new List<Action<Unit>>(); public void Subscribe(Action<Unit> callback) { _callbacks.Add(callback); } public void Publish(Unit unit) { foreach (Action<Unit> callback in _callbacks) callback(unit); } } 

इस ईवेंट को "EventAggregator" में जोड़ें:

 public class EventAggregator { public static UnitDiedEvent UnitDied; } 

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

 private void Die() { EventAggregator.UnitDied.Publish(this); } 

और इस घटना में रुचि रखने वाला कोई भी घटक इसका उत्तर इस प्रकार दे सकता है (उदाहरण के लिए, स्कोर किए गए अंकों की संख्या के लिए जिम्मेदार प्रबंधक):

 public class ScoresManager : MonoBehaviour { public int Scores; public void Awake() { EventAggregator.UnitDied.Subscribe(OnUnitDied); } private void OnUnitDied(Unit unit) { Scores += CalculateScores(unit); } } 

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



मुझे एक और व्याख्या पसंद है: कल्पना कीजिए कि "EventAggregator" आयत सभी दिशाओं में फैला हुआ है और दुनिया के सीमाओं में तब्दील होते हुए अन्य सभी आयतों को अपने अंदर कैद कर लिया है। मेरे सिर में, इस आरेख में, EventAggregator पूरी तरह से अनुपस्थित है। "EventAggregator" सिर्फ एक गेम की दुनिया है, एक तरह का "गेम ब्रॉडकास्ट", जहाँ गेम के विभिन्न भाग “हे लोगों” चिल्लाते हैं! इस तरह की एक इकाई की मृत्यु हो गई है! ”और हर कोई प्रसारण को सुन रहा है, और यदि कोई भी सुनाई गई घटना उन्हें रुचती है, तो वे इस पर प्रतिक्रिया करेंगे। इस प्रकार, कोई कनेक्शन नहीं हैं, प्रत्येक घटक स्वतंत्र है।
यदि मैं एक घटक हूं और किसी घटना के प्रकाशन के लिए जिम्मेदार हूं, तो मैं यह कहते हुए हवा में चिल्लाता हूं कि यह एक मर गया, यह एक स्तर मिला, शेल ने टैंक को मारा। और मुझे परवाह नहीं है अगर किसी को इसकी परवाह है। शायद अब कोई भी इस घटना को नहीं सुन रहा है, या शायद सौ अन्य वस्तुओं को इसकी सदस्यता दी गई है। मैं, घटना के लेखक के रूप में, एक ग्राम के बारे में परवाह नहीं करता, मैं उनके बारे में कुछ नहीं जानता और जानना नहीं चाहता।
यह दृष्टिकोण पुराने को बदले बिना नई कार्यक्षमता का परिचय देना आसान बनाता है। मान लीजिए कि हमने तैयार गेम में एक उपलब्धि प्रणाली जोड़ने का फैसला किया। हम उपलब्धि प्रणाली का एक नया घटक बनाते हैं और हमारे लिए ब्याज की सभी घटनाओं की सदस्यता लेते हैं। कोई अन्य कोड नहीं बदलता है। आपको अन्य घटकों के माध्यम से नहीं जाना है और उनसे उपलब्धि प्रणाली को कॉल करें और उसे बताएं कि वे कहते हैं और कृपया मेरी घटना को गिनें। इसके अलावा, दुनिया में घटनाओं को प्रकाशित करने वाले सभी उपलब्धि प्रणाली के बारे में कुछ भी नहीं जानते हैं, यहां तक ​​कि इसके अस्तित्व के तथ्य भी।

टिप्पणी

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

आकर्षण आते हैं

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

विपक्ष

- आपको लगातार नई घटनाओं का वर्णन करने और उन्हें दुनिया में जोड़ने की आवश्यकता है।
- कार्यात्मक परमाणुता का उल्लंघन।

अंतिम शून्य से अधिक विस्तार से विचार करें

कल्पना कीजिए कि हमारे पास एक ऑब्जेक्ट ऑब्जेक्ट है जिसमें मेथड विधि कहा जाता है। मेथड मेथड में तीन स्टेप होते हैं और अपने अंदर तीन अन्य मेथड होते हैं जो इन स्टेप्स को क्रमिक रूप से निष्पादित करते हैं (मेथडए 1, मेथडेज 2 और मेथड 3)। दूसरी विधि मे MethodA2, एक घटना प्रकाशित होती है। और यहाँ निम्न होता है: जो कोई भी इस घटना के लिए सदस्यता लेता है, वह अपने स्वयं के कुछ प्रकार के तर्क का प्रदर्शन करते हुए, इसे संसाधित करना शुरू कर देगा। इस तर्क में, अन्य घटनाओं का प्रकाशन भी हो सकता है, जिसके प्रसंस्करण से नई घटनाओं का प्रकाशन भी हो सकता है। कुछ मामलों में प्रकाशनों और प्रतिक्रियाओं का पेड़ बहुत बढ़ सकता है। इस तरह की लंबी श्रृंखलाएं डिबग करना बेहद मुश्किल है।
लेकिन सबसे खराब समस्या यहाँ हो सकती है जब श्रृंखला की शाखाओं में से एक "ऑब्जेक्ट" पर वापस जाती है और किसी अन्य मेथडब विधि को कॉल करके घटना को संसाधित करना शुरू कर देती है। यह पता चला है कि मेथोड विधि ने अभी तक सभी चरणों को पूरा नहीं किया है, क्योंकि यह दूसरे चरण में बाधित था, और अब इसमें एक अमान्य स्थिति है (चरण 1 और 2 में हमने ऑब्जेक्ट की स्थिति को बदल दिया है, लेकिन चरण 3 से अंतिम परिवर्तन अभी तक नहीं हुआ है किया गया) और एक ही समय में "MethodB" को एक ही ऑब्जेक्ट में निष्पादित किया जाना शुरू होता है, जिसमें यह अमान्य स्थिति है। ऐसी स्थितियां त्रुटियों को जन्म देती हैं, इसे पकड़ना बहुत मुश्किल है, वे इस तथ्य को जन्म देते हैं कि कॉलिंग विधियों और प्रकाशन की घटनाओं के क्रम को नियंत्रित करना आवश्यक है, जब तर्क को ऐसा करने की आवश्यकता नहीं है और अतिरिक्त जटिलता का परिचय देना है जिससे हम बचना चाहेंगे।

निर्णय

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

निष्कर्ष

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