खेल घटक, खेल प्रबंधक और वस्तु गुण


15

मैं घटक आधारित इकाई डिजाइन के आसपास अपना सिर पाने की कोशिश कर रहा हूं।

मेरा पहला कदम विभिन्न घटकों को बनाना था जिन्हें किसी वस्तु में जोड़ा जा सकता था। प्रत्येक घटक प्रकार के लिए मेरे पास एक प्रबंधक था, जो हर घटक के अपडेट फ़ंक्शन को कॉल करेगा, जो कि कीबोर्ड राज्य आदि जैसी चीजों में आवश्यक हो।

अगली चीज जो मैंने की वह थी ऑब्जेक्ट को हटा देना, और बस एक आईडी के साथ प्रत्येक घटक है। तो एक वस्तु समान Ids वाले घटकों द्वारा परिभाषित की जाती है।

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

मेरा पहला विचार एक ObjectPropertyवर्ग था जो घटकों के गुणों के रूप में होने के बजाय, जो घटक क्वेरी कर सकता था। तो एक वस्तु की संख्या ObjectPropertyऔर होगी ObjectComponent। अवयवों में अद्यतन तर्क होगा जो गुणों के लिए ऑब्जेक्ट को प्रश्न करता है। प्रबंधक घटक के अद्यतन विधि को कॉल करने का प्रबंधन करेगा।

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

  1. इस (चल रहा है ObjectProperty, ObjectComponentऔर ComponentManagerवर्ग) से अधिक इंजीनियरिंग?
  2. एक अच्छा विकल्प क्या होगा?

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


@JonathanDickinson, @Den: मुझे लगता है, फिर मेरी समस्या यह है कि मैं आम गुणों को कहाँ संग्रहीत करूँ। उदा। एक वस्तु को एक मुद्रा के रूप में, जिसका उपयोग ए RenderingComponentऔर ए द्वारा किया जाता है PhysicsComponent। क्या मैं यह सोचकर कि संपत्ति कहां रखूं? क्या मुझे इसे या तो चिपका देना चाहिए, फिर अन्य क्वेरी के लिए आवश्यक संपत्ति वाले घटक के लिए एक वस्तु है?
जॉर्ज डकेट

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

1
मैं वास्तव में उस विचार को पसंद करता हूं - यह कोशिश करने लायक हो सकता है; लेकिन प्रत्येक व्यक्तिगत संपत्ति का वर्णन करने के लिए एक वस्तु होना वास्तव में महंगा है। आप कोशिश कर सकते हैं PhysicalStateInstance(एक प्रति वस्तु) एक GravityPhysicsShared(प्रति खेल) के साथ; हालाँकि, मुझे यह कहने के लिए लुभाया जाता है कि यह वास्तुविदों के अहसास में बँधा हुआ है, अपने आप को एक छेद में न बांधें (वास्तव में मैंने अपने पहले घटक प्रणाली के साथ जो किया था)। चुम्मा।
जोनाथन डिकिंसन

जवाबों:


6

आपके पहले प्रश्न का सरल उत्तर है हां, आप डिजाइन से अधिक इंजीनियरिंग कर रहे हैं। 'मैं कितनी दूर चीजों को तोड़ता हूं?' अगला चरण उठाए जाने पर प्रश्न बहुत सामान्य है और केंद्रीय वस्तु (जिसे आमतौर पर इकाई कहा जाता है) को हटा दिया जाता है।

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

इसलिए, यहां कुछ गाइड लाइन दी गई हैं, जिन्हें मैं एक घटक प्रणाली में विकसित करने की कोशिश करता हूं और अनुसरण करता हूं:

  • कोई चम्मच नहीं है।
    • यह वह कदम है जो आपने पहले ही केंद्रीय वस्तु से छुटकारा पाने के लिए उठाया है। यह एंटिटी ऑब्जेक्ट में क्या जाता है और क्या एक घटक में चला जाता है की पूरी बहस को हटा देता है क्योंकि अब आपके पास सभी घटक हैं।
  • घटक संरचना नहीं हैं
    • यदि आप किसी ऐसी चीज़ को तोड़ते हैं जहाँ यह केवल डेटा समाहित करता है तो यह कोई घटक नहीं है, यह केवल एक डेटा संरचना है।
    • एक घटक में एक विशिष्ट तरीके से बहुत विशिष्ट कार्य को पूरा करने के लिए आवश्यक सभी कार्यक्षमता होनी चाहिए।
    • IRenderable इंटरफ़ेस गेम में कुछ भी देखने के लिए सामान्य समाधान प्रदान करता है। CRenderableSprite और CRenderableModel उस इंटरफ़ेस का एक घटक कार्यान्वयन है जो क्रमशः 2D और 3D में रेंडर करने की बारीकियाँ प्रदान करता है।
    • IUseable एक ऐसी चीज़ के लिए इंटरफ़ेस है जिसके साथ एक खिलाड़ी बातचीत कर सकता है। CUseableItem वह घटक होगा जो या तो सक्रिय बंदूक को फायर करता है या चयनित पोशन को पीता है जबकि CUseableTrigger हो सकता है जहां एक खिलाड़ी बुर्ज में हॉप करने के लिए जाता है या ड्रॉब्रिज को छोड़ने के लिए लीवर फेंकता है।

इसलिए घटकों के दिशानिर्देशों के ढांचे नहीं होने के कारण, SizeComponent को बहुत दूर से तोड़ा गया है। इसमें केवल डेटा होता है और जो चीज के आकार को परिभाषित करता है वह अलग-अलग हो सकता है। उदाहरण के लिए, एक प्रतिपादन घटक में यह 1d स्केलर या 2 / 3D वेक्टर हो सकता है। भौतिकी घटक में यह वस्तु का बाउंडिंग वॉल्यूम हो सकता है। इन्वेंट्री आइटम में यह हो सकता है कि 2 डी ग्रिड पर कितना स्थान है।

कोशिश करो और सिद्धांत और व्यावहारिकता के बीच एक अच्छी रेखा खींचो।

उम्मीद है की यह मदद करेगा।


आइए यह मत भूलो कि कुछ प्लेटफार्मों पर, एक इंटरफ़ेस से फ़ंक्शन कॉल करना एक पैरेंट क्लास से एक कॉल करने की तुलना में अधिक है (चूंकि आपके उत्तर में इंटरफेस और कक्षाओं का उल्लेख शामिल है)
एडीबी

याद करने के लिए अच्छी बात है, लेकिन मैं भाषा अज्ञेय बने रहने की कोशिश कर रहा था और बस सामान्य डिजाइन के संदर्भ में उनका उपयोग कर रहा था।
जेम्स

"यदि आप किसी ऐसी चीज़ को तोड़ते हैं जहाँ यह सिर्फ डेटा समाहित करता है तो यह कोई घटक नहीं है, यह केवल एक डेटा संरचना है।" -- क्यों? "घटक" एक ऐसा सामान्य शब्द है जिसका अर्थ डेटा संरचना भी हो सकता है।
पॉल मंटा

@PaulManta हाँ यह एक सामान्य शब्द है, लेकिन इस सवाल और जवाब का पूरा बिंदु यह है कि लाइन कहाँ खींचनी है। मेरा जवाब, जैसा कि आपने उद्धृत किया है, सिर्फ एक ऐसा करने के लिए अंगूठे के नियम के लिए मेरा सुझाव है। हमेशा की तरह मैं वकालत करता हूं कि कभी भी सिद्धांत या डिजाइन के विचार को विकसित नहीं होने देना चाहिए, इसका मतलब उसकी सहायता करना है।
जेम्स

1
@James यह एक दिलचस्प चर्चा थी। :) chat.stackexchange.com/rooms/2175 मेरा सबसे बड़ा पकड़ यदि आपका कार्यान्वयन यह है कि घटकों को बहुत अधिक पता है कि अन्य घटकों में क्या दिलचस्पी है। मैं भविष्य में समय पर चर्चा जारी रखना चाहता हूं।
पॉल मेंटा

14

आपने पहले ही एक जवाब स्वीकार कर लिया था, लेकिन यहां एक सीबीएस में मेरा छुरा है। मैंने पाया कि एक सामान्य Componentवर्ग की कुछ सीमाएँ हैं, इसलिए मैं जीडीसी 2009 में रेडिकल एंटरटेनमेंट द्वारा वर्णित एक डिज़ाइन के साथ गया, जिसने घटकों को Attributesऔर में अलग करने का सुझाव दिया Behaviors। (" गेम ऑब्जेक्ट कंपोनेंट आर्किटेक्चर का सिद्धांत और अभ्यास ", मार्सिन चाडी)

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

http://www.pdf-archive.com/2012/01/08/entity-component-system/preview/page/1

यहाँ दस्तावेज़ से एक अंश है:

एट्रिब्यूट्स एंड बिहेवियर इन शॉर्ट

Attributesडेटा की एक श्रेणी और उनके पास किसी भी तर्क को सीमित करने का प्रबंधन करें। उदाहरण के लिए, Healthयह सुनिश्चित कर सकते हैं कि इसका वर्तमान मूल्य इसके अधिकतम मूल्य से अधिक नहीं है, और यह तब भी अन्य घटकों को सूचित कर सकता है जब वर्तमान मूल्य एक निश्चित महत्वपूर्ण स्तर से नीचे चला जाता है, लेकिन इसमें कोई अधिक जटिल तर्क नहीं है। Attributesकोई दूसरे पर निर्भर हैं Attributesया Behaviors

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


संपादित करें: और यहां एक संबंध आरेख है जो दिखाता है कि घटक एक दूसरे के साथ कैसे संवाद करते हैं:

विशेषताएँ और व्यवहार के बीच संचार आरेख

एक कार्यान्वयन विवरण: इकाई-स्तर EventManagerकेवल तभी बनाया जाता है जब इसका उपयोग किया जाता है। Entityवर्ग सिर्फ एक के लिए सूचक को संग्रहीत करता है EventManagerकि आरंभ नहीं हो जाता है, तो केवल कुछ घटक अनुरोध यह।


संपादित करें: एक अन्य प्रश्न पर मैंने इस पर एक समान उत्तर दिया। आप इसे यहाँ, शायद, सिस्टम की बेहतर व्याख्या के लिए पा सकते हैं:
amed /gamedev//a/23759/6188


2

यह वास्तव में उन गुणों पर निर्भर करता है जिनकी आपको आवश्यकता होती है और जहाँ आपको उनकी आवश्यकता होती है। आपके पास जितनी मेमोरी होगी और प्रोसेसिंग पावर / टाइप आप उपयोग करेंगे। मैंने देखा है और निम्नलिखित करने की कोशिश कर रहा हूं:

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

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

कोई सही सिस्टम नहीं हैं। और कुछ गेम एक सरल सिस्टम के साथ बेहतर होंगे जबकि अन्य को पूरे सिस्टम में अधिक जटिल सिंक्रनाइज़ेशन की आवश्यकता होगी।

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

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

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


जब यह आपके आकार के घटक की बात आती है तो इसे संभवतः आपके स्थिति घटक के भीतर बांधा जा सकता है:

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

आकार के बजाय आप एक आकार संशोधक का उपयोग भी कर सकते हैं, यह हाथ में आ सकता है।

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


2
BTW +1 या -1 क्योंकि मेरे वर्तमान प्रतिनिधि 666 के बाद से है ... यह डरावना है।
कोयोट

1

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

C ++ या C # में आमतौर पर इसका मतलब है कि आपके पास इकाई पर एक टेम्पलेट विधि होगी T GetComponent<T>()। और एक बार आपके पास वह संदर्भ हो जाता है, तो आपको पता होता है कि यह कौन सा सदस्य डेटा रखता है, इसलिए इसे सीधे एक्सेस करें।

Lua या Python जैसी किसी चीज़ में आपके पास एक स्पष्ट प्रकार की वस्तु नहीं है, और शायद कोई परवाह भी नहीं करता है। लेकिन फिर से, आप केवल सदस्य चर का उपयोग कर सकते हैं और किसी भी अपवाद का सामना कर सकते हैं जो कि कुछ ऐसा नहीं है जो उस तक पहुंचने का प्रयास करता है।

ऑब्जेक्ट प्रॉपर्टी के लिए क्वेरी स्पष्ट रूप से उस काम की नकल करने जैसी लगती है जो भाषा आपके लिए कर सकती है, या तो स्टेटिक-टाइप की गई भाषाओं के लिए संकलन समय पर या डायनामिक टाइप किए गए लोगों के लिए रन टाइम।


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

यदि यह फिट बैठता है, तो एक मौजूदा एक को चुनें या संपत्ति को एक नए घटक में शामिल करें यदि यह नहीं करता है। उदाहरण के लिए एकता में एक 'ट्रांसफ़ॉर्म' घटक होता है, जो सिर्फ स्थिति है, और अगर किसी चीज़ को ऑब्जेक्ट की स्थिति को बदलने की आवश्यकता है, तो वे इसे उस घटक के माध्यम से करते हैं।
काइलोटन

1

"मुझे लगता है, तब मेरी समस्या यह है कि मैं आम संपत्तियों को कहां संग्रहीत करता हूं। उदाहरण के लिए, एक वस्तु के रूप में एक वस्तु, जिसका उपयोग RenderingComponent और PhysicsComponent द्वारा किया जाता है। क्या मैं यह सोच रहा हूं कि संपत्ति कहां रखी जाए? क्या मुझे सिर्फ छड़ी करनी चाहिए? या तो, फिर अन्य क्वेरी के पास उस घटक के लिए एक वस्तु है जिसके पास आवश्यक संपत्ति है? "

बात यह है कि RenderingComponent स्थिति का उपयोग करता है , लेकिन PhysicsComponent इसे प्रदान करता है। आपको बस प्रत्येक उपयोगकर्ता घटक को बताने के लिए एक तरीका चाहिए जो प्रदाता का उपयोग करें। आदर्श रूप से अज्ञेय तरीके से, अन्यथा एक निर्भरता होगी।

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

कोई सामान्य नियम नहीं है। विशिष्ट संपत्ति पर निर्भर करता है (ऊपर देखें)।

एक बदसूरत लेकिन घटक-आधारित वास्तुकला के साथ एक गेम बनाएं और फिर इसे रिफ्लेक्टर करें।


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

मेरी वास्तव में ऐसी ही स्थिति थी :)। मेरे पास एक PhysicsBodyComponent और एक SimpleSpatialComponent है। दोनों ही स्थिति, कोण और आकार प्रदान करते हैं। लेकिन पहले एक भौतिकी सिमुलेशन में भाग लेता है और इसमें अतिरिक्त प्रासंगिक गुण होते हैं, और दूसरा केवल उस स्थानिक डेटा को रखता है। यदि आपके पास अपना स्वयं का भौतिक इंजन है, तो आप पूर्व को उत्तरार्द्ध से भी प्राप्त कर सकते हैं।
डेन

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

1

आपका पेट आपको लगता है कि होने बता रही है ThingProperty, ThingComponentऔर ThingManagerहर के लिए Thingघटक एक के प्रकार के छोटे से overkill। मुझे लगता है कि यह सही है।

लेकिन, आपको संबंधित घटकों का ट्रैक रखने के लिए किसी तरह की आवश्यकता है कि सिस्टम उनका क्या उपयोग करता है, वे किस इकाई से संबंधित हैं, आदि।

TransformPropertyएक बहुत आम होने वाला है। लेकिन इसका प्रभारी कौन है, रेंडरिंग सिस्टम? भौतिकी प्रणाली? साउंड सिस्टम? एक Transformघटक को खुद को अपडेट करने की आवश्यकता क्यों होगी ?

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

आर्टेमिस के बारे में पढ़ें: http://piemaster.net/2011/07/entity-component-artemis/

इसके कोड को देखें और आप देखेंगे कि यह सिस्टम के आसपास आधारित है जो उनकी निर्भरता को सूचियों के रूप में घोषित करता है ComponentTypes। आप अपनी प्रत्येक Systemकक्षा को लिखते हैं और कंस्ट्रक्टर / इनिट विधि में यह घोषित करते हैं कि वह प्रणाली किस प्रकार पर निर्भर करती है।

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

फिर आपके लूप के अद्यतन चरण के दौरान, आपके Systemपास अब यह सूची है कि किन संस्थाओं को अद्यतन करना है। अब आप घटकों के विवरण का स्तर हो सकता है ताकि आप एक से बाहर पागल प्रणाली, निर्माण संस्थाओं वसीयत कर सकते हैं ModelComponent, TransformComponent, FliesLikeSupermanComponent, और SocketInfoComponent, और कुछ मेकअप की तरह अजीब एक उड़न तश्तरी कि ग्राहकों के बीच मक्खियों एक मल्टीप्लेयर खेल से जुड़ा है। ठीक है, शायद ऐसा नहीं है, लेकिन विचार यह है कि यह चीजों को अपघटित और लचीला रखता है।

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

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