यूनिटी 3 डी इंजन डिजाइन (गेम ऑब्जेक्ट / ट्रांसफॉर्म घटक) के पीछे कारण


14

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


मेरे लिए यह ऐसा लगता है जैसे वास्तुकला विरासत। हो सकता है कि यह रूपांतर घटक एक नियमित, वैकल्पिक, घटक हुआ करता था, इसलिए आप कार्टेशियन स्थान के ऑब्जेक्ट "आउट" कर सकते थे। तब कुछ कार्यान्वयन में बाधा (एक अनुकूलन?) की आवश्यकता थी कि यह घटक हमेशा मौजूद था, और यह इस तरह से बना रहा। लेकिन यह सिर्फ एक तर्क है, यह एकता के एक इंजीनियर को उस सवाल का जवाब देने के लिए ले जाएगा।
लॉरेंट कौविदो

जवाबों:


11

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

अधिक आम तौर पर, यह प्रश्न पूछता है कि "यदि X और Y के बीच 1 से 1 संबंध है, तो Y, X या वाइस का हिस्सा क्यों नहीं है?" और सामान्य उत्तर यह है कि सॉफ्टवेयर छोटे आत्म-निहित भागों में टूट जाने पर विकसित होने और बनाए रखने में आसान होता है, भले ही 2 भाग हमेशा एक साथ मिलकर काम करते हों।


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

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

1

एकता में रूपांतरण एक अनिवार्य घटक है।

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


1
प्रश्न यह नहीं है कि घटक आधारित डिज़ाइन क्या है। इसके बारे में क्यों "परिणत" एक घटक के रूप में अच्छी तरह से नहीं कर रहा है
bummzack

1
लेकिन ट्रांसफॉर्म एकता में एक घटक है! docs.unity3d.com/Documentation/ScriptReference/Transform.html । परिवर्तन के बारे में केवल अजीब बात यह है कि यह GameObject के लिए एक अनिवार्य घटक है।
मॉर्टनोबेल

वैसे मुझे लगता है कि सवाल यह है कि आप इसे क्यों नहीं हटा सकते? यदि वह शब्द से परिचित नहीं था, तो ओपी ने अपने प्रश्न "घटक-आधारित" को टैग नहीं किया होगा।
बुमज़ैक

आपने सही कहा - धन्यवाद। मैंने प्रश्न का बेहतर उत्तर देने के लिए उत्तर को अपडेट किया है।
मॉर्टनोबेल

3
सवाल यह है कि डेटा को बदलना एक अलग घटक क्यों है (जैसा कि GameObject के अंदर सादे डेटा के विपरीत, नाम, परत के मुखौटे, टैग)। मैंने अपनी पोस्ट के नवीनतम संशोधन में इसे और अधिक स्पष्ट करने की कोशिश की।
स्नेक 5

0

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

आर्किटेक्चर में हमेशा ट्रेडऑफ रहेगा। TransformComponentस्थिर होने (यानी गतिशील नहीं) होने से, एकता के डेवलपर्स इस धारणा के तहत कोड लिख सकते हैं। मुझे लगता है कि यह हमारी तरफ से बहुत अधिक असुविधा के बिना चीजों को उनकी तरफ से आसान बना देता है। यह एक वस्तु उन्मुख प्रतिमान है, जहां के लिए समान है GameObjectहोगा extendकुछ abstract class, Transformable

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