संस्थाओं या घटकों में राज्य परिवर्तन


9

मुझे कुछ परेशानी हो रही है कि मैं अपनी संस्थाओं में राज्य प्रबंधन से कैसे निपटूं।

मुझे गेम राज्य प्रबंधन से कोई समस्या नहीं है, जैसे कि ठहराव और मेनू, क्योंकि ये एक इकाई घटक प्रणाली के रूप में नियंत्रित नहीं किए जाते हैं; बस संस्थाओं / घटकों में राज्य के साथ।

एक उदाहरण के रूप में ऑर्क से मरना जरूरी है, मेरे पास मेरे मेनचैकर और ट्रैप इकाइयाँ हैं जिनमें केवल उनके घटक जैसे किComComponent, RenderComponent, PhysicsComponent हैं।

प्रत्येक अद्यतन पर इकाई अपने घटकों पर अद्यतन कॉल करेगी। मेरे पास विभिन्न इवेंट प्रकारों के लिए श्रोताओं के साथ एक सामान्य ईवेंट मैनजर भी है।

अब मुझे जाल लगाने में सक्षम होने की आवश्यकता है: पहले जाल और जाल की स्थिति का चयन करें और फिर जाल को रखें।

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

यह आमतौर पर घटक आधारित प्रणालियों में कैसे संभाला जाता है?

(यह उदाहरण विशिष्ट है, लेकिन संस्थाओं के राज्यों से निपटने के सामान्य तरीके का पता लगाने में मदद कर सकता है।)


1
क्या आप इनपुट घटनाओं के आधार पर संस्थाओं के घटकों को जोड़ और हटा सकते हैं? राज्यों के बदलने पर शायद आप ट्रैप के घटकों को बदल सकते हैं। उदाहरण के लिए, जाल लगाते समय इसमें FollowComponent और RenderEffectComponnent होगा। जब यह रखा जाता है, तो आप दोनों घटकों को हटा दें और CollisionComponent जोड़ें। (संपादित करें: मार्टिन
सोज्का

हां, मैं कर सकता हूं, हर इनपुट को "HumanView" से खेल की घटनाओं में अनुवादित किया जाता है, जो कि उनमें से अधिकांश, मेरे गेमलॉजिक क्लास द्वारा पहले संसाधित होते हैं, जो उदाहरण के लिए जांच करेगा कि क्या मेनचैकर में जाल लगाने के लिए पर्याप्त पैसा है, कैसे उसके बाद होता है कि मैं क्या करने की कोशिश कर रहा हूँ।
ग्रिफिनहार्ट

जवाबों:


6

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

अपने उदाहरण के लिए, आप पहले एक BuildControllerComponent( एक निर्माण चरण में खिलाड़ी नियंत्रण की प्रतिक्रिया को नियंत्रित करने के साथ) जाल बना सकते हैं , ए PositionComponentऔर ए RenderComponent। अंतिम में एक डेटा फ़ील्ड है जो उपयोग किए गए पिक्सेल shader (s) को नियंत्रित करता है, और उनमें से एक ट्रैप-टू-बी-बिल्ड को "भूतिया" रूप देता है। आप देखेंगे कि अभी तक कोई भौतिक घटक निर्दिष्ट नहीं हैं।

जाल रखने पर, घटकों का आदान-प्रदान होता है। BuildControllerComponentअब कोई आवश्यकता नहीं है, इसलिए यह निकाल दिया जाएगा। RenderComponentके shaders जाल से अपनी सामान्य मानक दृश्य के साथ बदल जाते हैं। अंत में, PhysicsComponentसाथ ही साथ काम करने के लिए जाल के लिए जो कुछ भी आवश्यक है, उसे इकाई में जोड़ा जाता है।

वंशानुक्रम-आधारित दृष्टिकोण में, यह एक ActiveTrapEntityवर्ग के लिए एक निर्माणकर्ता होने के बराबर है जो एक BuildTimeTrapEntityवर्ग को अपने तर्कों के रूप में लेता है , दूसरा इसे बनाने के दौरान जाल को प्रस्तुत करने के लिए इस्तेमाल किया जा रहा है, पहले एक जाल के लिए इस्तेमाल होने के बाद यह जगह में है ।


यह चतुर है।
साइफर

1
यह एक इकाई के राज्य को लागू करने के लिए अच्छी रणनीति है । यह प्रत्येक इकाई की स्थिति को ट्रैक करने के तरीके के मुद्दे को संबोधित नहीं करता है। आपको कैसे पता चलेगा कि वर्तमान में कौन सा राज्य किस इकाई में है?
MichaelHouse

@MartinSojka यह प्रश्न पूछने के बाद मैं जो सोच रहा था, उसके निकट आता है। मैं एक BuildTrapProcess (GameLogic में कुछ अद्यतन किया गया है) को जोड़ने पर विचार कर रहा था जो एक जाल के निर्माण के लिए आवश्यक राज्य परिवर्तनों को प्राप्त करने के लिए बदलते घटकों के रनटाइम पहलू का प्रबंधन करेगा। जब जाल बनाने के लिए बटन दबाया जाता है तो गेम लॉजिक प्रोसेस बनाकर उसे स्टार्ट कर देगा। इस दृष्टिकोण पर कोई विचार?
ग्रिफिनहार्ट

@ बाइट 56: सामान्य तौर पर, आप संबंधित घटकों और इसके मूल्यों को क्वेरी कर सकते हैं। व्यवहार में, आपको अक्सर पूरे राज्य के प्रासंगिक उपसमूह को जानने की आवश्यकता होती है, उदाहरण के लिए "क्या यह इकाई है BuildControllerComponent?" या "इस इकाई की स्थिति क्या है जैसा कि इसमें दर्ज किया गया है PositionComponent, अगर इसमें कोई है?" - आप जिन लोगों की रुचि रखते हैं और वैकल्पिक रूप से (कुछ) उनके मानों की क्वेरी कर रहे हैं, उनके लिए घटक सूची की जाँच करके।
मार्टिन सोज्का

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

5

मुझे उनके घटकों पर अपडेट कॉल करने वाली संस्थाओं का विचार पसंद नहीं है (सिस्टम को काम करना चाहिए), और यह एक दूसरे से अनजान घटकों को रखने के साथ मुद्दों का नेतृत्व करने वाला है।

आप "राज्य" नामक एक अतिरिक्त घटक जोड़ सकते हैं। यह आपके रेंडर और टक्कर सिस्टम द्वारा एक्सेस किया जाएगा। राज्य घटक सिर्फ एक ध्वज है जिसमें कई राज्य उपलब्ध हैं। स्थिति के लिए आप का वर्णन राज्यों होगा Playऔर Build। जब रेंडर सिस्टम यह देखता है कि राज्य वह Buildहै जो ऑब्जेक्ट को पारभासी बना देगा। जब टक्कर सिस्टम देखता हैBuild राज्य को , तो यह खिलाड़ी के साथ टकराव की प्रक्रिया नहीं करेगा।

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


आप जो कह रहे हैं वह परस्पर विरोधी है, पहले उन्हें अनजान होना चाहिए (जो मैं सहमत हूं) फिर आप एक घटक का पालन करते हैं जो दूसरों द्वारा एक्सेस किया जाता है। क्या आप स्पष्ट कर सकते हो? मैं ईवेंट सिस्टम द्वारा अपघटित घटकों को रख रहा हूं।
ग्रिफिनहार्ट

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

मुझे लगता है StateComponentकि एक के विचार कई प्रणालियों द्वारा सेवन किया जा सकता है।
साइपर

1
यह पतन के लिए तर्क प्रदान करने के लिए विनम्र है। धन्यवाद।
MichaelHouse

2
एक अलग नोट पर, पूछने वाले के दृष्टिकोण पर आपकी आपत्ति इस धारणा पर आधारित है कि सभी घटक आधारित डिज़ाइन को अलग-अलग सिस्टम (जैसे एक इकाई सिस्टम डिज़ाइन) से घटकों को अपडेट करना होगा। यह ऐसा करने का एक तरीका है, लेकिन निश्चित रूप से केवल एक ही नहीं है, और ऐसे गेम के लिए इस तरह के दृष्टिकोण को अस्वीकार करने का कोई कारण नहीं है जिसे कैश-ऑप्टिमाइज़िंग घटक अपडेट लूप की कोई आवश्यकता नहीं है।
शॉन मिडिलडविच
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.