घटक आधारित डिजाइन में इनपुट हैंडलिंग

Question

मुझे पता है कि यह प्रश्न कई बार पूछा गया है, लेकिन मुझे अभी भी यकीन नहीं है कि घटक आधारित इंजन में इनपुट हैंडलिंग को कैसे लागू किया जाए।

मेरे द्वारा उपयोग किया जाने वाला घटक आधारित डिजाइन टी = मशीन की ब्लॉग श्रृंखला और आर्टेमिस पर आधारित था जिसमें एंटिटीज सिर्फ आईडी हैं।

इनपुट हैंडलिंग को लागू करने में मेरे पास तीन मुख्य विचार हैं:

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

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

नोट: एक अतिरिक्त आवश्यकता जिसे मैं पूरा करने के लिए कार्यान्वयन चाहूंगा वह यह है कि मैं एक ही समय में एक कैमरा इकाई और खिलाड़ी को स्थानांतरित करने के लिए कई संस्थाओं के लिए एक ही इनपुट पास कर पाऊंगा।

Comments

आमतौर पर (जब कैमरा खिलाड़ी का अनुसरण करता है) आप कैमरे में इनपुट प्राप्त नहीं करना चाहते हैं, इसके बजाय आप कैमरा प्लेयर की स्थिति की जाँच करें और उसका पालन करें।

— ल्यूक बी।

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

— ग्रिवरहार्ट

@ ल्यूक बी .: इसे कुछ विचार देने के बाद, मैं देखता हूं कि आप कैमरे को एक अलग वर्ग के रूप में भी बना सकते हैं, एक पॉइंटर का पालन करने के लिए एक इकाई ले रहे हैं।

— ग्रिवरहार्ट

Answer 1

मुझे लगता है कि, बस एक घटक प्रणाली में सामग्री के बारे में मेरे जवाब की तरह , आप एक समस्या में चल रहे हैं जहाँ आप एक "घटक" में सब कुछ चमकाने की कोशिश कर रहे हैं। आपको ऐसा करने की आवश्यकता नहीं है और ऐसा करने में आप संभवतः गोल छेद में चौकोर खूंटे का एक गुच्छा फिट करने का प्रयास करके वास्तव में बोझिल इंटरफ़ेस बना रहे हैं।

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

मैं जरूरी नहीं कि कैमरा इकाई और खिलाड़ी इकाई दोनों को "आगे बढ़ना" (et cetera) संदेश का जवाब देते हुए कैमरा-निम्नलिखित व्यवहार को लागू करने का सुझाव देना चाहिए। यह दो वस्तुओं के बीच एक अत्यंत कठोर संबंध बनाता है जो संभवतः खिलाड़ी को अच्छा नहीं लगेगा, और यह कैमरे को खिलाड़ी की परिक्रमा करने जैसी चीजों को संभालने के लिए थोड़ा पेचीदा बनाता है जब खिलाड़ी बाएं या दाएं घूमता है: आपके पास एक इकाई है यह मानकर "घुमाया गया" छोड़ दिया जाता है कि यह खिलाड़ी को दिया गया है, लेकिन इसका अर्थ है कि यह सही ढंग से जवाब नहीं दे सकता है यदि यह कभी भी बिना शर्त के था ... जब तक कि आप उस अवधारणा को किसी राज्य के रूप में पेश नहीं कर सकते जब तक आप जाँच नहीं कर सकते। और यदि आप ऐसा करने जा रहे हैं, तो आप दो भौतिक वस्तुओं को एक साथ स्लेव करने के लिए एक उचित प्रणाली को लागू कर सकते हैं, उपयुक्त लोच ट्विस्टेबल्स और इतने पर पूरा कर सकते हैं।

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

Comments

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

— ग्रिवरहार्ट

Answer 2

मेरा अनुभव पक्षपाती हो सकता है लेकिन बहु मंच परियोजनाओं में इनपुट डिवाइस सीधे इकाई प्रणाली के संपर्क में नहीं आते हैं।

इनपुट डिवाइसेस को एक निचले स्तर के सिस्टम द्वारा नियंत्रित किया जाता है, जो कीज, बटन, एक्सिस, माउस, टच सरफेस, एक्सेलेरोमीटर से घटनाओं को प्राप्त करता है ...

इन घटनाओं को फिर संदर्भ आश्रित आशय जनरेटर की एक परत के माध्यम से भेजा जाता है।

प्रत्येक जनरेटर घटकों, संस्थाओं और प्रणालियों से बदलाव के लिए रजिस्टर करता है जो इसके कार्यों के लिए प्रासंगिक हैं।

ये जनरेटर तब इरादे सिस्टम को रूट करने के लिए संदेश / इरादे भेजते हैं जहां संस्थाओं का एक घटक होता है या सीधे सही घटकों के लिए होता है।

इस तरह आप बस "हमेशा" पर एक ही इनपुट यानी JUMP_INTENT (1), JUMP_INTENT (0), AIM_INTENT (1) होने पर भरोसा कर सकते हैं ...

और "सभी" गंदे मंच पर निर्भर इनपुट कार्य आपकी इकाई प्रणाली के बाहर रहता है।

---

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

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

Comments

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

— ग्रिहेयरहार्ट

Answer 3

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

Action jump = () =>
{
    entities["player"].Transform.Velocity.Y += 5;
};

एक और उदाहरण, ओपी से:

Action moveRight = () =>
{
    foreach (var entity in entities.Tagged("player", "camera"))
        entity.Transform.Position.X += 5;
};