घटक-आधारित गेम आर्किटेक्चर में व्यवहार को कैसे लागू किया जाए?


21

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

कहो कि मेरे पास एक निम्नलिखित खिलाड़ी का चरित्र है जो स्थिर हो सकता है, दौड़ सकता है और तलवार झूल सकता है। एक खिलाड़ी को स्थिर और चलने वाले राज्य दोनों से स्विंग तलवार राज्य में स्थानांतरित किया जा सकता है, लेकिन फिर खिलाड़ी को खड़े या दौड़ने फिर से शुरू करने से पहले स्विंग को पूरा करना होगा। स्विंग के दौरान, खिलाड़ी घूम नहीं सकता।

जैसा कि मैंने देखा है, मेरे पास दो कार्यान्वयन दृष्टिकोण हैं:

  • सभी खिलाड़ी तर्क युक्त एक एआई-घटक बनाएं (या तो वास्तविक घटक से हटा दिया गया या प्लेयरएआईसीओम्पोनेंट के रूप में एम्बेडेड है)। मैं आसानी से खिलाड़ी इकाई बनाने के लिए अलग-अलग घटकों के बीच युग्मन बनाए बिना राज्य प्रतिबंधों को कैसे लागू कर सकता हूं। हालाँकि, AI- घटक को तोड़ा नहीं जा सकता। यदि मेरे पास है, उदाहरण के लिए, एक दुश्मन जो केवल खड़े हो सकते हैं और चारों ओर घूम सकते हैं या केवल घूम सकते हैं और कभी-कभी एक तलवार को स्विंग कर सकते हैं, मुझे नए एआई-घटक बनाने होंगे।
  • घटकों में व्यवहार को तोड़ना, प्रत्येक एक विशिष्ट राज्य की पहचान करना। फिर मुझे एक स्टैंडकॉमपॉइंट, वॉककंपोनेंट और स्विंगकॉमपॉइंट मिल जाता है। संक्रमण नियमों को लागू करने के लिए, मुझे प्रत्येक घटक को युगल करना होगा। स्विंग की अवधि के लिए SwingComponent को StandComponent और WalkComponent को अक्षम करना होगा। जब मेरे पास एक दुश्मन होता है जो केवल चारों ओर खड़ा होता है, तो कभी-कभी तलवार को झूलते हुए, मुझे यह सुनिश्चित करना होगा कि SwingComponent केवल WalkComponent को निष्क्रिय करता है यदि यह मौजूद है। यद्यपि यह बेहतर मिक्स-एंड-मैचिंग घटकों के लिए अनुमति देता है, यह एक निरंतरता दुःस्वप्न का कारण बन सकता है क्योंकि हर बार एक निर्भरता जुड़ने के बाद, मौजूदा घटकों को चरित्र पर निर्भरता स्थानों को नई आवश्यकताओं के साथ अच्छी तरह से खेलने के लिए अद्यतन किया जाना चाहिए।

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

इसे सभी में समेटना: क्या मुझे सभी एआई लॉजिक को एक घटक में रखना चाहिए या यूनिट वेरिएंट बनाने के लिए प्रत्येक लॉजिक स्टेट को अलग-अलग घटकों में तोड़ना चाहिए?

संपादित करें : मुझे संदेह है कि पहली और दूसरी स्थिति के साथ मेरा क्या मतलब था, इस बारे में कुछ भ्रम है। मैंने नीचे दिए गए चित्र में इसे समझाने की कोशिश की है।

घटक आरेख

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

सवाल यह है कि क्या घटक-आधारित इकाई में AI को संरचित करने के लिए ये केवल दो विकल्प हैं और यदि हां, तो अधिकतम लचीलापन क्या होगा?


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

2 एक व्यवहार्य विकल्प नहीं है।
कोयोट

जवाबों:


6

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

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

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

संपादित करें: वास्तव में, आपके स्थिर दुश्मनों के लिए, आंदोलन घटक को प्रतिबंधित करने के बजाय, बस उन्हें एक स्थिर एआई घटक दें जो उन्हें स्थानांतरित करने के लिए कभी नहीं चुनता है।


क्या राज्य का पैटर्न पहली स्थिति नहीं है? यह एक एकल AIComponent में एक राज्य मशीन को लागू करता है जिसमें विभिन्न राज्य ऑब्जेक्ट होते हैं। दूसरे विकल्प के साथ मेरा मतलब यह था कि WalkComponent और SwingComponent उसी प्रकार के हैं, जैसे कि, RenderComponent और PhysicsComponent।
भूत

@ghostonline जहाँ तक विचार जाता है, की तरह। कार्यान्वयन में, वास्तव में नहीं। दूसरे आरेख की तरह, AIComponent अलग होगा। इसमें अन्य घटक नहीं होंगे। आपकी दूसरी स्थिति के लिए अधिक महत्वपूर्ण सवाल यह है कि अगर डिजाइनर सिर्फ एक प्रोग्रामर के बिना घटकों का चयन करता है, तो एंटिटी को राज्य बदलने के लिए कैसे पता चलता है? विभिन्न राज्य अलग-अलग राज्य संक्रमण करते हैं - किसी को अभी भी उन को निर्दिष्ट करने की आवश्यकता है।
Tesserex

क्या आपका मतलब है कि आरेख 2 में इकाई के लिए एक AIComponent जोड़ना, जो स्टैंड / वॉक / स्विंग-कंपोनेंट को नियंत्रित करेगा? मेरा विचार था कि घटक कुछ शर्तों पर ब्लॉक या सक्रियण संकेत भेजते हैं। उदाहरण के लिए, SwingComponent जेनेरिक सिग्नलों का उत्सर्जन करेगा, उदाहरण के लिए "बाउंड_फेट" सिग्नल शुरू होने पर और स्विंग को खत्म करने पर "रिलीज_फेट"। WalkComponent इन संकेतों के आधार पर स्वयं को अक्षम और सक्षम करेगा। क्योंकि 'स्टेट ट्रांज़िशन' घटकों में खुद ही समाविष्ट हो जाते हैं, इसलिए डिज़ाइनर को घटकों को एक साथ रखने वाले प्रोग्रामर की आवश्यकता नहीं होगी।
भूत

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

2

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

एनपीसी के लिए, मैं एक ही चीज़ के पहलुओं के रूप में स्टैंडकंपोनेंट और वॉककंपोनेंट देखता हूं। क्या आप कभी भी एक स्टैंडकॉम के बिना वॉककंपनी करने जा रहे हैं? मुझे शक है। इसी तरह, एक RunComponent सिर्फ एक उच्च गति और विभिन्न एनिमेशन के साथ एक WalkComponent होगा। मैं एक NPCMovementComponent और एक अलग NPCSwordFighterComponent होने में मूल्य देख सकता हूं, लेकिन यहां तक ​​कि मुझे ओवरगेंरिंग की तरह लगता है।


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

सच। मैं यह मान रहा हूँ कि सभी गतिशील वस्तुओं में एक PhysicsComponent या MovementComponent है जो उनकी गति को संभालता है, और यह है कि PlayerController और AIController उस आंदोलन को संभालने के लिए उपयोग करेगा। आंदोलन निश्चित रूप से एक अलग घटक होना चाहिए, क्योंकि ऐसी चीजें हो सकती हैं जिन्हें स्थानांतरित करने की आवश्यकता होती है जिसमें एआई नहीं होता है या सबसे सरल संभव एआई (क्रेट या जंक जैसे गूढ़ भौतिकी ऑब्जेक्ट) होते हैं।
ग्रेगरी एवरी-वियर

2

पहले मैं एक स्टेट कंपोनेंट बनाऊंगा और फिर ट्रांज़िशन को संभालने के लिए एक स्टेट मशीन बनाऊंगा। इसे पर्याप्त सामान्य बनाएं कि आप इसका उपयोग अपने खिलाड़ियों और अपने AI के लिए कर सकें। यह सुनिश्चित करेगा कि AI समान नियमों से खेलता है और आपको अपने तर्क को बदलने की ज़रूरत नहीं है जब आप बदलते हैं कि खिलाड़ी AI राज्यों की तुलना में कैसे काम करते हैं।

परिमित स्टेट मशीन C ++

उपर्युक्त में c ++ में एक स्टेट मशीन का एक ठोस उदाहरण है जो कि खिलाड़ियों और AI समान द्वारा उपयोग किया जा सकता है।


1

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


1
TYPO: "यह प्राप्त करेगा ..." AI घटक से क्या ?
प्यूप
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.