RTS खेल इकाई संरचना

Question

मैं एक से अधिक बार MoveTo और Attack क्रियाओं जैसे सामानों को प्रोग्राम किए बिना बहुत सारी अलग-अलग इकाइयों को बनाने का एक तरीका चाहता हूं

जिस तरह से मैं इसे देखता हूं, 2 तरीके हैं जो मैं यह कर सकता हूं।

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

ऐसा करने का पहला तरीका सबसे सरल लगता है, लेकिन मैं बहुत सारे कोड को यूनिट्स के लिए अप्रयुक्त होने के कारण समाप्त कर दूंगा।

दूसरा तरीका भी काम कर सकता था। लेकिन अगर मैं दो अलग-अलग इकाइयाँ तय करता हूँ जो संसाधनों की कटाई कर सकती हैं, तो मेरे पास दो अलग-अलग वर्गों में एक ही कोड है, जो ऐसा करने का सही तरीका नहीं लगता है।

क्या यह इस समस्या का सही तरीका भी है?
AoE जैसे खेल में, हर इकाई में, जो मैं मानता हूं, वह किसी प्रकार की क्रिया / आदेशों की सूची है, मैं वास्तव में जानना चाहूंगा कि कुछ उसी के समान कैसे प्राप्त किया जाए, जहां मैं प्रत्येक क्रिया / आदेश को एक बार कोड कर सकता हूं, और फिर इसे उन सभी इकाइयों को दें जिन्हें एक्शन की आवश्यकता है।

अगर मैं स्पष्ट नहीं हूं (अत्यधिक प्रशंसनीय) या आप वास्तव में क्या देख रहे हैं, इसके बारे में अधिक जानकारी की आवश्यकता है, तो बस मुझे एक टिप्पणी में पूछें।

Answer 1

एक सामान्य दृष्टिकोण एक घटक-आधारित दृष्टिकोण है, जहां बेस-क्लास "यूनिट" सिर्फ सबसे बुनियादी पहलुओं को लागू करता है, जो सभी इकाइयों में समान हैं, जबकि प्रत्येक इकाई में कई घटक-ऑब्जेक्ट्स की एक सूची है जो कहते हैं कि यह क्या कर सकता है और यह कैसे करता है।

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

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

एकता ऐसी वास्तुकला में आपका समर्थन करती है, क्योंकि पूरा इंजन पहले से ही घटक-आधारित है। इसलिए इन जैसे गेम-लॉजिकल घटकों को स्क्रिप्ट के रूप में जोड़ा जा सकता है।

Comments

तो एकता में, क्या मैं तब अक्षम कर दूंगा और आवश्यकतानुसार घटकों को सक्षम करूंगा?

— डैनियल होल्स्ट

@DanielHolst नहीं, आप उन्हें जोड़ देंगे और आवश्यकतानुसार हटा देंगे। आप ऐसा कर सकते हैं एकता संपादक में या उपयोग करने वाले स्क्रैप के साथ gameObject.AddComponentऔर gameObject.RemoveComponent।

— फिलिप

आह ठीक है, लेकिन एक "चाल" कार्रवाई / आदेश के लिए कहें। जब ऑर्डर किया जाता है तो यूनिट को कैसे पता चलेगा? और मैं ऑर्डर कैसे पूरा करूंगा?

— डेनियल होल्स्ट

@DanielHolst मुझे लगता है कि आपने कुछ गलत समझा। Movingघटक का अर्थ है "इस इकाई आंदोलन के आम तौर पर सक्षम है"। घटक स्थायी रूप से इसके साथ जुड़ा हुआ है, भले ही इकाई चल रही हो या नहीं। इसका मतलब यह नहीं है कि यह आगे बढ़ रहा है अभी । यद्यपि आप इसे इस तरह से एक घटक जोड़कर भी कर सकते हैं MoveOrderऔर उस घटक को इकाई से खुद को हटा देते हैं जब आदेश पूरा या रद्द कर दिया जाता है।

— फिलिप

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

— फिलिप

Answer 2

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

Comments

क्या इसे लागू करना बेहद मुश्किल होगा?

— डैनियल होल्स्ट

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

— रॉस टेलर-टर्नर

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

— DMGregory

@DanielHolst जो "अत्यंत कठिन" की आपकी परिभाषा पर निर्भर करता है। मेरा जवाब इस बारे में अधिक विस्तार से जाना जाता है कि इसे कैसे लागू किया जा सकता है।

— फिलिप