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

बहु घटकों के साथ एक वर्ग को MeshInstance जितना जटिल बना सकते हैं

वास्तव में किन घटकों के साथ?

संपादित करें: और जैसा कि आप जानते हैं, आपके द्वारा उद्धृत मुद्दों में से एक को लेखक के साथ बंद कर दिया गया था, "यह विचार वास्तव में और पूरी तरह से बेकार है और पूरी तरह से बकवास है।"

इसे प्रदर्शित करने के लिए मैं एक नकली वर्ग का उपयोग करूँगा जो कि एक MeshInstance, अगर गोडोट में बनाया गया है तो कैसा दिखेगा।
छद्म एकता, उर्फ ​​​​चाइल्ड नोड्स है:
गोडोट उपयोगकर्ता मल्टीस्क्रिप्ट के समकक्ष बनाने के लिए चाइल्ड नोड्स का उपयोग करते हैं।
छद्म अवास्तविक, उर्फ ​​​​नियंत्रक और मध्यवर्ती:
छद्म पांडा 3 डी, उर्फ ​​​​प्रीलोड (स्क्रिप्ट):
डब्ल्यूटीएफ स्क्रिप्ट:
हां, मुझे पता है कि गोडोट में मेश इंस्टेंस क्लास है।
यह प्रदर्शित करने वाला बिंदु यह है कि अभी डेवलपर्स द्वारा उपयोग किए जाने वाले अधिकांश वर्कफ़्लोज़ एक वर्ग को बहु घटकों के साथ MeshInstance जितना जटिल बना सकते हैं; सिवाय प्रत्येक कार्यप्रवाह गंभीर रूप से त्रुटिपूर्ण है।

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

यदि प्रश्न सरल है: "क्या गोडोट में एक ही परिणाम प्राप्त करने के कई तरीके हैं?", उत्तर हाँ है ...

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

यह वह जगह है जहां गोडोट है, डेवलपर्स अंधेरे में झूल रहे हैं, उम्मीद कर रहे हैं कि किसी तरह यह उन्हें कुछ बनाने की अनुमति देगा।

वास्तव में किन घटकों के साथ?

सामग्री और परिवर्तन जैसी चीजें, क्या इन्हें मूल उदाहरण का हिस्सा माना जाता है या नहीं?
यदि हम समान घटक बनाते हैं तो हम उन्हें नोड से कैसे जोड़ते हैं?

अन्य कार्यों के बारे में क्या, जैसे "लक्ष्य का पालन करें" या "लक्ष्य पर गोली मारो" इन्हें कक्षा में जोड़ा जाना चाहिए या किसी तरह संलग्न किया जाना चाहिए?
चूंकि गोडोट ने गोडोट के लिए कभी भी उचित शामिल या आयात फ़ंक्शन नहीं बनाया है, क्या इसका मतलब यह है कि इसे इस तरह इस्तेमाल करने के लिए कभी नहीं बनाया गया था?

हम जानते हैं कि हमारे पास सब कुछ नहीं हो सकता, तो सवाल यह है कि हमारे पास क्या है? काम करने के लिए डिजाइन कैसा था?

@MysteryGM ढीली और डिस्कनेक्ट की गई उपमाएँ मददगार नहीं हैं।

सामग्री और परिवर्तन जैसी चीज़ें

रूपांतरण एक स्थानिक संपत्ति है और सामग्री एक मेष संपत्ति है। MeshInstance को Spatial के ऊपर बनाया गया है, इसलिए इसे Spatial के सभी गुण विरासत में मिलते हैं। यह एक साधारण पदानुक्रम है जो मुझे समझ में आता है।

यदि हम समान घटक बनाते हैं तो हम उन्हें नोड से कैसे जोड़ते हैं?

जब गोडोट के पास पहले से ही है तो आप अपना खुद का मेश सिस्टम क्यों बनाएंगे?

अन्य कार्यों के बारे में क्या, जैसे "लक्ष्य का पालन करें" या "लक्ष्य पर गोली मारो"

कोड स्क्रिप्ट में जाता है। आप इसे नोड की मुख्य स्क्रिप्ट में रख सकते हैं या इसे एक बच्चे को एक स्क्रिप्ट के साथ दे सकते हैं यदि आपको लगता है कि इसे इस तरह से करना अधिक उपयोगी होगा।

जब गोडोट के पास पहले से ही है तो आप अपना खुद का मेश सिस्टम क्यों बनाएंगे?

क्योंकि खेल की वस्तुएं एक जाल की तरह ही जटिल होती हैं यदि अधिक ध्यान दें। याद रखें कि इंजन जहां गेम का हिस्सा मूल था, यह सिर्फ वह हिस्सा था जिसे फिर से इस्तेमाल किया गया था।

यदि गोडोट इंजन के अंदर प्रभावी ढंग से मेश क्लास नहीं बना सकता है, तो इसका उपयोग जटिल गेम बनाने के लिए नहीं किया जा सकता है। सभी खेलों को इंजन से कम जटिल होना होगा।
बदले में इसका मतलब है कि यह डेवलपर्स की एक पेशेवर टीम के लिए किसी काम का नहीं है। जब तक ऐसी कोई टीम केवल स्रोत कोड के साथ C++ का उपयोग नहीं करती है।

कोड स्क्रिप्ट में जाता है।

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

मैं जो जानना चाहता हूं वह यह है कि गोडोट मौसम के प्रभाव, बड़ा कोहरा और बड़े इलाकों जैसी जटिल प्रणालियों के साथ बड़े खेलों से कैसे निपटता है?

निम्नलिखित मुझसे, मेरी राय और अनुभव से संबंधित है, _YMMV_

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

एकता 4/5 को एक उदाहरण के रूप में लेते हुए (जिसके लिए मुझे वर्षों से जंजीर में बांधा गया था), इसमें _घटक_ इतने फूले हुए हैं कि इसकी तुलना किसी भी अन्य ईसीएस से नहीं की जा सकती है जिसका मैंने कभी उपयोग किया है। और ओह, आप एक http अनुरोध करना चाहते हैं? ज़रूर, अपनी दृश्य संरचना में एक नई वस्तु में एक नया घटक जोड़ें क्योंकि यह इन-सीन वस्तुओं और इसके घटकों के साथ http अनुरोधों को जोड़ने के लिए बहुत मायने रखता है। "सेव ए सीन विद नो चेंजेस ब्रेक्स ऑल यूयूआईडी" फीचर को सिर्फ हमारे गैर-तकनीकी डिजाइनरों के लिए वर्जन कंट्रोल का उपयोग करना कठिन बनाने के लिए गढ़ा गया था। मैं "डोंट डिस्ट्रॉय ऑन लोड" और प्रीफ़ैब्स पर भी शुरुआत नहीं करना चाहता।

वैसे भी अधिकांश चीजों के बीच तर्क क्या था? मैं कहूंगा कि यह शायद जैविक, पुनरावृत्त विकास है, और यहां और वहां कुछ हैकी कामकाज (गोडोट और शायद अन्य सभी गेम इंजनों में भी पाए जाते हैं)। मेरा मतलब है, यह इतना दुर्घटनाग्रस्त हो गया कि मेरे स्विफ्ट कीबोर्ड ने हर बार "_With_" टाइप करने पर "_यूनिटी क्रैशिंग_" शब्दों की भविष्यवाणी करना शुरू कर दिया। यह मेरे वर्कफ़्लो का एक प्रमुख हिस्सा था, क्रैश -> एक मिनट के लिए सभी संपत्तियों को दोबारा आयात करें, 30 के लिए काम करें, दोहराएं।

मैंने ईशनिंदा करने वाले मोनोबिहेवियर का इतना अधिक उपयोग देखा है, लेकिन मैं किसे दोष दूं? इंजन लोगों को पॉइंटलाइट ऑब्जेक्ट के अंदर _GameState_ "_component_" डालने की अनुमति देता है। क्या हमें इसे मना करना चाहिए? मैं कैसे तर्क दूं कि जब http संचार (या वस्तुतः किसी async कार्य) को एक की आवश्यकता हो तो गेम स्टेट डेटा एक दृश्य वस्तु के घटक के अंदर भी नहीं होना चाहिए?

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

मैंने वास्तव में प्रोटोटाइप और परीक्षण परियोजनाओं से अधिक के लिए अवास्तविक (या कोई अन्य प्रासंगिक गेम इंजन) का उपयोग नहीं किया है, उचित गहराई से तुलना नहीं कर सकता।

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

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

मैं जो जानना चाहता हूं वह यह है कि गोडोट मौसम के प्रभाव, बड़ा कोहरा और बड़े इलाकों जैसी जटिल प्रणालियों के साथ बड़े खेलों से कैसे निपटता है?

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

बड़ा कोहरा? मुझे लगता है कि मैंने इसे नए एफपीएस डेमो में देखा है।

बड़े इलाके? मेरे पास एक बार प्रक्रियात्मक इलाके के जाल के साथ एक परियोजना थी और यह मेरे दो साल पुराने लैपटॉप पर काफी सुचारू रूप से चल रहा था।

हालांकि ओपी में बात कर रहे 'बड़े मुद्दे' की बजाय ये कुछ कार्यक्षमताएं हैं।

मौसम के प्रभाव? एक कण नोड वाला एक दृश्य बनाएं...

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

बड़े इलाके?

अंतरिक्ष बड़ा। हमें दृश्यों को बिना ठंड के वेक्टर 3 (0,0,0) पर रीसेट करने के लिए किसी तरह की आवश्यकता है क्योंकि बहुत सारे नोड्स को हटाने की आवश्यकता है। भौतिकी और सब कुछ बड़ी झांकियों के साथ हिलता है।

इसमें घटक इतने फूले हुए हैं कि इसकी तुलना किसी भी अन्य ईसीएस से नहीं की जा सकती है जिसका मैंने कभी उपयोग किया है।

सहमत, घटक भयानक हो सकते हैं इसलिए यह हमें आश्चर्यचकित नहीं करेगा यदि गोडोट के मन में एक अलग रणनीति है। हालांकि हमें पता नहीं है कि गोडोट ने क्या रणनीति बनाई थी या अगर उसने किया भी।

गोडोट सीखने के 2 महीने ने केवल हमें छोटे गेम बनाने के बारे में सोचा है।
गोडोट का उपयोग करने के बारे में निर्णय लेने के लिए 14 दिन शेष हैं, मुझे उम्मीद है कि इंजन के डेवलपर्स यह बता सकते हैं कि बड़ी परियोजनाओं पर कैसे काम करना है।

आखिरी चीज जो हम करना चाहते हैं वह है इंजन डिजाइन के खिलाफ चढ़ाई करना जब हम खेल को विकसित करने का प्रयास करते हैं।

@MysteryGM मुझे वास्तव में समझ में नहीं आता कि आपको क्यों लगता है कि गोडोट बड़ी परियोजनाओं के लिए उपयोग करने योग्य नहीं है। इसका डिज़ाइन वास्तव में बड़ी परियोजनाओं के लिए उधार देता है क्योंकि आप सब कुछ अलग-अलग दृश्यों में विभाजित कर सकते हैं और काम का पुन: उपयोग करने के लिए ओओपी का उपयोग कर सकते हैं। यदि बड़ी परियोजना के लिए गोडोट का उपयोग करने में आपकी समस्या यह है कि आप नहीं जानते कि लक्ष्य कैसे प्राप्त किया जाए, तो बस गोडोट डिस्कॉर्ड्स सहायता चैनलों पर पूछें, आपको बहुत तत्काल प्रतिक्रिया मिलेगी।

भौतिकी और सब कुछ बड़ी झांकियों के साथ हिलता है।

देखें #288

हालांकि हमें पता नहीं है कि गोडोट ने क्या रणनीति बनाई थी या अगर उसने किया भी।

मैं समझता हूं कि यह पहली बार में विदेशी है, लेकिन मेरे लिए नोड + स्क्रिप्ट उपयोग यह बहुत सीधा है। मैं निश्चित रूप से यहां इस पाठ्यक्रम के शौक संस्करण (कम से कम) पर एक नज़र डालने की सलाह दूंगा: https://gumroad.com/gdquest
यह मेरे जैसे नोड स्क्रिप्ट संरचना का उपयोग करता है, और निश्चित रूप से आपको एक बेहतर अंतर्दृष्टि प्रदान कर सकता है कि वास्तव में इंजन से जुड़े लोग इसका उपयोग कैसे करते हैं; गोडोट डॉक्स में लेखक का प्रमुख योगदान है।

संपादित करें: वास्तव में, यदि आप पाठ्यक्रम नहीं चाहते हैं तो आप भंडार में स्रोत पर एक नज़र डाल सकते हैं https://github.com/GDquest/make-pro-2d-games-with-godot

गोडोट का उपयोग करने के बारे में निर्णय लेने के लिए 14 दिन शेष हैं, मुझे उम्मीद है कि इंजन के डेवलपर्स यह बता सकते हैं कि बड़ी परियोजनाओं पर कैसे काम करना है।

मुझे लगता है कि मैं इस पर थोड़ा उलझन में हूं कि इसका वास्तव में आपका क्या मतलब है। आपने पहले एक उदाहरण के रूप में हथौड़ा सादृश्य का उपयोग किया था, लेकिन यह एक त्रुटिपूर्ण सादृश्य है क्योंकि एक हथौड़ा आम तौर पर एक एकल-उपयोग वाला बुनियादी उपयोगितावादी उपकरण होता है, और इसकी क्षमता के कारण उपकरण का उपयोग किस लिए किया जाता है, इसकी एक आंतरिक समझ है।

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

मुझे लगता है कि परियोजना संरचना के उदाहरणों पर अधिक दस्तावेज़ीकरण के लिए एक तर्क दिया जा सकता है, लेकिन मुझे लगता है कि यह दस्तावेज़ीकरण में अधिक योगदान का मामला है।

दृश्यों को अलग करें और काम का पुन: उपयोग करने के लिए OOP का उपयोग करें।

जैसा कि मैंने पहले उल्लेख किया है, सिग्नल संलग्न होने के बाद वस्तुओं को इधर-उधर ले जाना एक दर्द है। खासतौर पर तब जब वे बिना किसी अपवाद या चेतावनी के काम करना बंद कर देते हैं।
किसी अन्य डेवलपर द्वारा इसका उल्लेख किए जाने के बाद, हमने तृतीय पक्ष रिफैक्टरिंग टूल के साथ जाने का निर्णय लिया; लेकिन फिर भी यह गोडोट की अनूठी समस्याओं का समाधान नहीं कर सकता है।
चीजों को नहीं हिलाने से यह समस्या होती है (हमारे "समस्या बोर्ड" से चित्र):

तो इसे ठीक करने के लिए हमने चाइल्ड नोड्स बनाए। लगभग 50 000 को छोड़कर यह समस्याएं पैदा करना शुरू कर देता है, यहां तक ​​​​कि वे सिर्फ नोड्स हैं।

हम यह जानना चाहते हैं कि हम इन समस्याओं से कैसे निपटते हैं, गोडोट ने इनसे निपटने की योजना कैसे बनाई; हमने ऊपर बताए गए हर वर्कफ़्लो का परीक्षण किया।

देखें #288

इसके लिए धन्यवाद, हम विश्व समन्वय को आराम करने के लिए इतने अभ्यस्त हैं, हमने कभी इसकी जाँच नहीं की।

मैं समझता हूं कि यह पहली बार में विदेशी है, लेकिन मेरे लिए नोड + स्क्रिप्ट उपयोग यह बहुत सीधा है।

समस्या यह नहीं है कि यह विदेशी है, समस्या यह है कि यह एक अलग समस्या का कारण बनती है। मुख्य रूप से यह कि अधिक बच्चों को जोड़ने से अंततः खेल पिछड़ जाता है या जब हम उन्हें उतारने का प्रयास करते हैं तो उसे जमा देता है।
तब भी जब वे सिर्फ Nodes.

आपको अपने खेल में 50,000 वस्तुओं की आवश्यकता क्यों है? निश्चित रूप से यह किसी भी इंजन से पिछड़ जाएगा।

आपको अपने खेल में 50,000 वस्तुओं की आवश्यकता क्यों है?

क्योंकि हम ऑब्जेक्ट्स में अतिरिक्त स्क्रिप्ट जोड़ने के लिए नोड्स का उपयोग करते हैं। क्योंकि गोडोट के यूआई उपकरण वास्तविक समय में चीजों को मापने के लिए कंटेनरों में कंटेनरों का उपयोग करते हैं...
हमारा सबसे छोटा UI 800 से अधिक ऑब्जेक्ट है। इनमें से अधिकांश कंटेनर।

हमारे पास 50 000 ऑब्जेक्ट हैं क्योंकि एक एकल दुश्मन एआई एक उद्देश्य के साथ +/- 8 नोड्स है और +/- 64 नोड्स जो केवल वहां हैं इसलिए हम उन्हें स्क्रिप्ट संलग्न कर सकते हैं।
क्योंकि प्रत्येक कार्य को उसके अपने कोड में विभाजित करके हम देख सकते हैं कि हमारी समस्याएं कहां हैं। क्योंकि खेल के किसी विशिष्ट भाग को शीघ्रता से खोजने का कोई अन्य तरीका नहीं है।

उस स्थिति में, ऐसा लगता है कि आपने उस क्षेत्र में सेंध लगाई है जहां कस्टम मॉड्यूल एक अच्छा विकल्प है।
http://docs.godotengine.org/hi/3.0/Development/cpp/custom_modules_in_cpp.html
आप वहां कस्टम नोड बना सकते हैं, और बहुत सारे नेस्टिंग से बच सकते हैं।

संपादित करें: हालांकि मैं तर्क दूंगा कि एक (सबसे छोटी?) यूआई के लिए 800 वस्तुएं खराब डिजाइन/वास्तुकला की ओर इशारा करती हैं।

मैं यह समझने में गंभीर रूप से विफल हूं कि आपके पास किसी एक वस्तु के लिए 64 स्क्रिप्ट के करीब कहीं भी कैसे हो सकता है। यह एक गोडोट समस्या (फिर से, किसी भी इंजन के पिछड़ने की संभावना) की तुलना में आपके प्रोजेक्ट की डिज़ाइन समस्या के अधिक लगता है। अपने कोड को कम स्क्रिप्ट में समेकित करें। प्रत्येक प्रकार की कार्यक्षमता के लिए एक स्क्रिप्ट न बनाएं, लेकिन इसके बजाय प्रत्येक प्रकार की वस्तु के लिए (यदि कोई "दुश्मन" नोड XYZ कर सकता है तो उस हिस्से को X और Y और Z कार्यक्षमता के लिए चाइल्ड नोड्स जोड़ने के बजाय शत्रु स्क्रिप्ट में जोड़ें) . यदि आपको ऐसा करने के लिए और अधिक उन्नत सुविधाओं की आवश्यकता है, तो शायद आप कस्टम विरासत और/या सी # इंटरफेस का उपयोग कर सकते हैं।

उस स्थिति में, ऐसा लगता है कि आपने उस क्षेत्र में सेंध लगाई है जहां कस्टम मॉड्यूल एक अच्छा विकल्प है।

देखें कि यह उन चीजों में से एक था जिसके बारे में हम सोच रहे हैं, क्योंकि हम सभी सी ++ जानते हैं यदि कस्टम मॉड्यूल की आवश्यकता है तो हम इसके बजाय सिर्फ गोडोट इंजन को संपादित करेंगे।
हम जानते हैं कि हम सुरक्षित रूप से #include का उपयोग कर सकते हैं जहां गोडोट प्रीलोड () संदिग्ध है; कोई हमें यह नहीं बता सकता कि यह कितना स्थिर है या इसमें कोई कमी है या नहीं।

मैं यह समझने में गंभीर रूप से विफल हूं कि आपके पास किसी एक वस्तु के लिए 64 स्क्रिप्ट के करीब कहीं भी कैसे हो सकता है।

सरल, प्रत्येक AI कम या ज्यादा 64 कार्य कर सकता है, छोटे कार्य भी नहीं।
उदाहरण के लिए एक स्क्रिप्ट स्क्वाडफ्लाइटपैटर्स है और यहां सभी 20 फ्लाइट फॉर्मेशन हैं, फिर स्क्वाडफ्लाइटपैटर्सकॉस्मेटिक है जो केवल उड़ान पैटर्न से संबंधित एनिमेशन, ध्वनि और कणों को हल करता है।

फिलहाल हमारा नियम मैकेनिक से यूजर फीडबैक को बांटना है।

यदि कोई "दुश्मन" नोड XYZ कर सकता है तो उस भाग को X और Y और Z कार्यक्षमता के लिए चाइल्ड नोड्स जोड़ने के बजाय शत्रु स्क्रिप्ट में जोड़ें

यदि आप छवियों और छद्म अवास्तविक, उर्फ ​​​​नियंत्रकों और मध्यवर्ती को देखते हैं।

क्योंकि हम सभी C++ जानते हैं यदि कस्टम मॉड्यूल की जरूरत है तो हम इसके बजाय सिर्फ गोडोट इंजन को संपादित करेंगे।

मुझे इंजन को बदलने की तुलना में मॉड्यूल बनाना बहुत आसान लगता है, क्योंकि यह इसके बजाय इसके ऊपर बनाता है।

फिर भी इतनी अधिक संख्या में इस स्केलिंग की कल्पना नहीं की जा सकती है, विशेष रूप से प्रति विजेट सैकड़ों या हजारों नोड्स के साथ यूआई।

ओपी में संदर्भित मुद्दों के जवाब में:

• 19486 :

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

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

• 7402: फिर से, स्क्रिप्ट कक्षाएं इस समस्या का समाधान हैं ("सरल समाधान" जिसके बारे में रेडुज ने सोचा था, यदि आप इस अंक से कुछ अंतिम टिप्पणियां देखते हैं)।

• 15996: मैं यह महसूस कर रहा था कि जो मैं चाहता था वह एक विशेषता प्रणाली थी (इससे पहले कि मैं समझ पाता कि लक्षण क्या थे) और फलस्वरूप यह महसूस करना कि मेरा प्रारंभिक प्रस्ताव कितना भयानक था क्योंकि यह दृश्यों और नोड्स के लक्षित डिजाइन को पूरी तरह से विकृत करता है और संपूर्ण को परिवर्तित करता है। एक रचना-आधारित विरासत प्रणाली में चीज़ - कुछ और जो एकता वास्तव में करती है, जो घृणित है (एकता में, आप किसी भी घटक से getComponent का उपयोग कर सकते हैं और यह गेमऑब्जेक्ट के मालिक होने पर भाई घटक प्राप्त करता है। घटक, व्यवहार में, एक हैं GameObject का विस्तार, उनकी निर्भरता को एक दूसरे पर धकेलना)।

• 8502 : मल्टीस्क्रिप्ट अलग-अलग स्क्रिप्टिंग भाषाओं को एक-दूसरे से इनहेरिट करने की अनुमति देने के लिए बस उपकरण हैं, जिस तरह से UE4 के ब्लूप्रिंट सीधे C ++ स्क्रिप्ट से प्राप्त हो सकते हैं (जो कि गोडोट में संभव नहीं होगा क्योंकि तुलना में GDScript एक नेटिवस्क्रिप्ट का विस्तार कर रहा है। विजुअलस्क्रिप्ट पहले स्थान पर विरासत का समर्थन नहीं करता है, इसलिए जीडीस्क्रिप्ट यहां अधिक उपयुक्त तुलना है)।

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

ओपी में उठाए गए कई मुद्दे किसी समस्या के समाधान के लिए कई संभावित तरीकों के इर्द-गिर्द घूमते हैं, जिनमें से प्रत्येक में विभिन्न अक्षमताएं हो सकती हैं। आम तौर पर, जब कुछ करने का एक विशेष तरीका होता है जो सबसे इष्टतम होगा, तो इंजन मुख्य सी ++ इंजन (स्क्रिप्ट या प्लगइन्स की कोई आवश्यकता नहीं) में अपना स्वयं का कार्यान्वयन प्रदान करता है और यह सुझाया गया उपयोग है।

यदि ऐसा वर्ग मौजूद है और लोग इसका उपयोग नहीं कर रहे हैं, तो यह एक संकेत है कि 1) वे यह देखने के लिए दस्तावेज़ीकरण की ठीक से जाँच नहीं कर रहे हैं कि क्या उनकी ज़रूरतें पहले से ही इंजन द्वारा पूरी की जा रही हैं/इंजन कैसे इसका उपयोग करने का सुझाव देता है या 2) इंजन/संगठन दस्तावेज़ीकरण को उपयोगकर्ताओं के लिए अत्यधिक दृश्यमान या सुलभ बनाने के लिए पर्याप्त अच्छा काम नहीं कर रहा है (क्योंकि उन्हें मौजूद संसाधन नहीं मिल रहे हैं)।

समस्या 1 को ठीक करने के लिए केवल यही किया जाना है कि वे लोग अपनी समस्या को मुखर करें और किसी और के लिए उन्हें डॉक्स या प्रश्नोत्तर साइट पर पुनर्निर्देशित करें ताकि उन्हें अपना समाधान खोजने में मदद मिल सके। मैंने एक समस्या (#23043) बनाई है जो लोगों को सीधे संपादक से प्रश्नोत्तर साइट ब्राउज़ करने और उपयोग करने की अनुमति देती है जिससे समस्या 2 में बहुत मदद मिलनी चाहिए। लिंक में कारणों का वर्णन किया गया है।

(संपादित करें: यदि किसी समस्या को हल करने के कई तरीके हैं, और उनमें से एक तरीका किसी अन्य की तुलना में कहीं बेहतर है, और गोडोट ने अभी तक इसके लिए अपना मूल समाधान लागू नहीं किया है, तो यह एक नई सुविधा के रूप में सुझाव देने के लिए कुछ होगा इंजन के लिए। इस तरह से हमें सिम्पलेक्सनोइस सामान मिला, क्योंकि लोग जीडीस्क्रिप्ट / शेडर कोड, आदि में अपने स्वयं के सिम्पलेक्सनोइस एल्गोरिदम लिख रहे थे)।

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

ओपी में वर्कफ़्लो के आपके उदाहरणों के लिए ...

• एकता दृष्टिकोण, बाल नोड्स:

  चाइल्ड नोड्स का उपयोग करना समझ में आता है, यह मानते हुए कि कोई पेयरिंग लॉजिक लिखता है। यह आदर्श रूप से है जहां एक विशेषता प्रणाली उपयोगी होगी (ताकि कोई एक बार युग्मन तर्क लिख सके और आवश्यकतानुसार इसे हर जगह दोहरा सके)। मैं अक्सर घटकों को उन तरीकों से लिखता हूं जहां वे स्वचालित रूप से अपने माता-पिता के लिए "लक्ष्य" के रूप में स्वयं को सेट करते हैं, जब वे माता-पिता/अनपेरेंटेड होते हैं और प्रासंगिक सिग्नल ऑटो-कनेक्ट/डिस्कनेक्ट होते हैं। आप इसके लिए _notification(what) में NOTIFICATION_(UN)PARENTED नोटिफिकेशन का उपयोग कर सकते हैं।

• नियंत्रकों के साथ UE4 दृष्टिकोण:

  गोडोट 3.1 आपको स्क्रिप्ट के लिए स्क्रिप्ट कक्षाएं असाइन करने की अनुमति देता है, इसलिए अब उन्हें प्रीलोड करने की कोई आवश्यकता नहीं है। इस मामले में, गोडोट आपको नोड्स को टाइपनाम असाइन करने की अनुमति देता है, लेकिन यह स्क्रिप्ट के लिए विशिष्ट है, इसलिए आपको सावधान रहना होगा। दृश्यों को एक ही उपचार नहीं मिलता है, और शायद ऐसा नहीं होगा क्योंकि इसमें इंजन कोर में सामान का एक गुच्छा जोड़ना शामिल होगा (जो कोर देवों के बारे में बहुत ही मार्मिक हो सकते हैं)।

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

• प्रीलोड के साथ पांडा3डी दृष्टिकोण:

  मैं समझ सकता था कि इस दृष्टिकोण के साथ बहुत सारी समस्याएं हैं क्योंकि NodeRefs अभी तक एक चीज नहीं हैं, और इस समय संसाधन स्क्रिप्ट निर्यात करने में समस्याएं हैं जिन्हें मैं 3.2 के लिए ठीक करने की उम्मीद कर रहा हूं (हालांकि आप शायद स्वयं को ठीक कर सकते हैं आसानी से पर्याप्त, यह बहुत छोटा है)।

• डब्ल्यूटीएफ स्क्रिप्ट दृष्टिकोण:

  मैं वास्तव में उन सभी समस्याओं को नहीं समझता जो आपको यहां हो रही हैं, शायद इसलिए कि हमारे पास बहुत अधिक संदर्भ नहीं है।

  उदाहरण प्रणाली के साथ संघर्ष। क्योंकि इंस्टेंसेस नीचे की ओर बहते हैं जबकि सिग्नल बेस्ट अप वार्ड से जुड़ते हैं।

  आप वंशज में माता-पिता का सिग्नल ट्रिगर व्यवहार कब करना चाहेंगे? क्यों न केवल माता-पिता सीधे वंशज और उसकी विधि को प्राप्त करें और कॉल करें? माता-पिता को अपने बच्चे को देखने का कोई खतरा नहीं है। ऐसा लगता है कि एक सी ++ ऑब्जेक्ट अपनी संरचना या वर्ग सदस्य चर (?) तक पहुंचने में सक्षम नहीं होना चाहिए।

  छोटी-छोटी व्यर्थ की स्क्रिप्ट बस इधर-उधर भटकती रहती हैं। वे केवल एक संकेत भेजते हैं और एक मान को ट्रैक करते हैं।

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

  इतने सारे संकेतों के साथ किसी वस्तु को हिलाना कम से कम निराशाजनक है।

  किस तरह से? मैंने आम तौर पर पाया है कि मैं या तो दृश्य फ़ाइल में कनेक्शन को हार्डकोड कर रहा हूं या एल्गोरिदमिक रूप से नोड्स के लिए सिग्नल कनेक्ट और डिस्कनेक्ट कर रहा हूं यदि उन्हें चारों ओर ले जाने का इरादा है। इसने मेरे उद्देश्यों को पर्याप्त रूप से पूरा किया है, लेकिन अगर आपको विशिष्ट समस्याएं हैं, तो उन्हें साझा करने से दूसरों को आपकी मदद करने में मदद मिल सकती है।

  सिग्नल और समूह खेल के पूरे हिस्से को बिना किसी चेतावनी के विफल होने देते हैं।

  इस प्रकार अस्तित्व डिजाइन के माध्यम से किसी भी बूलियन के साथ समस्या है। विकल्प सभी ऑब्जेक्ट के माध्यम से लूप करना है, जांचें कि क्या वे मानदंडों से मेल खाते हैं, और फिर तर्क करते हैं कि वे मेल खाते हैं, और यदि वे मेल खाते हैं, लेकिन ठीक से नहीं, तो एक त्रुटि फेंक दें। संकेतों और समूहों के मामले में, सेट के भीतर हर चीज पर व्यवहार स्वचालित रूप से शुरू हो जाते हैं, इसलिए यदि चीजें सेट से बाहर हो जाती हैं, तो यह पता लगाने का कोई तरीका नहीं है कि निष्पादन के समय कोई समस्या हुई है। इस प्रकार की समस्याओं को खोजने का एकमात्र तरीका सेटअप प्रक्रियाओं के दौरान है जहां समूहों/सिग्नल को पहले स्थान पर व्यवस्थित किया जा रहा है।

वैसे भी, सामान के साथ मेरा सारा अनुभव यही था। यह हमें आपकी परियोजना के बारे में और यह जानने में बहुत मदद करेगा कि यह वास्तव में क्या कर रहा है ताकि हम आपके विशेष उपयोग-मामले के लिए सुझाव दे सकें।

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

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

स्क्रिप्ट कक्षाएं अंतिम समस्या का समाधान करती हैं।

लंबे उत्तर के लिए पहला धन्यवाद, यह बहुत कुछ है और स्पष्ट रूप से लिखने में कुछ समय लगा।
मुझे स्क्रिप्ट कक्षाओं के बारे में सुनकर प्रसन्नता हुई, हमने 3.1 का उपयोग नहीं किया; केवल FPS डेमो चलाने के लिए।

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

आप वंशज में माता-पिता का सिग्नल ट्रिगर व्यवहार कब करना चाहेंगे? क्यों न केवल माता-पिता सीधे वंशज और उसकी विधि को प्राप्त करें और कॉल करें?

मुझे ऐसा लग रहा है कि मुझे यह समझाना चाहिए। उस समय हमारे पास बहुत बड़ी स्क्रिप्ट थीं, जिनमें से प्रत्येक में मोटे तौर पर +/- 30 कार्य थे। इस कारण से हम पहले से ही बड़ी स्क्रिप्ट में अतिरिक्त सिग्नल फ़ंक्शंस जोड़ने से बचना चाहते थे।
नतीजा यह हुआ कि हमने बड़ी स्क्रिप्ट से काम को उतारने के लिए ढीली स्क्रिप्ट बनाई।

यह पहले से ही एक संकेत है कि परियोजना का डिज़ाइन अच्छा नहीं है।

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

मेरे साथ यहाँ समाप्त होता है, और मुझे लगता है कि अंतिम उत्तर ने बहुत कुछ संबोधित किया जिसके बारे में मैं सोच रहा था; मुझे कल दोबारा जांच करनी होगी क्योंकि यह यहाँ पर 2AM है।

"एक्स जैसी प्रणाली को डिजाइन करने का सबसे अच्छा तरीका क्या है" जो ... वास्तव में एक गिटहब मुद्दा नहीं है।

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

केवल अंतिम वर्कफ़्लो प्रकार ने काम किया, सिवाय इसके कि हमारा मुख्य प्रोग्रामर टेबल के खिलाफ अपना सिर पीट रहा था और किसी का गला घोंट रहा था।

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

मुख्य रूप से हमने गोडोट समुदाय द्वारा अनुशंसित बहुत सारे डिज़ाइनों की कोशिश की और कुछ ट्यूटोरियल से

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

@willnationsdev ने पहले जो कहा था, उसके बाद, खेल के पैमाने में मदद करने के लिए बैक-एंड कोड पर विचार करना उचित हो सकता है, दोनों प्रदर्शन-वार और संपादक में ही प्रबंधित करने के लिए कम कोड होना चाहिए। मैं इसके अलावा बहुत मदद नहीं कर सकता, क्योंकि यहां कई लोगों की तरह, मुझे बड़ी परियोजनाओं के साथ अनुभव नहीं है। आपको कामयाबी मिले!

नमस्ते, हमारे पास बस एक और सवाल है।

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

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

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

किसी भी चीज़ के 50,000 होने के साथ आप उस बिंदु को पार कर चुके हैं जहाँ गोडोट का सीनट्री-एंड-नोड्स ऑब्जेक्ट-आधारित रूपक उपयोगी है।

यह अन्य इंजनों से बहुत अलग नहीं है, एकता के साथ आप उनके गेम ऑब्जेक्ट्स, GC, या UE4 के साथ समान सीमा तक पहुंचेंगे, आपको ब्लूप्रिंट को दूर करने में समस्याएँ मिलेंगी - लेकिन सबसे ऊपर , किसी भी चीज़ की मात्रा होने का मतलब डिफ़ॉल्ट है दृश्य संपादक बस अब उपयोगी नहीं हैं, और प्रदान किए गए उपकरण टूटने लगते हैं या कम से कम खराब प्रदर्शन करते हैं।

सभी इंजनों में, समाधान काफी हद तक समान होता है: अपने स्वयं के समाधान बनाएं। वे क्या हैं यह आपके खेल, वास्तुकला और इंजन से अधिक विवरण पर निर्भर करता है।

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

एकता अपने नए ईसीएस बुनियादी ढांचे के साथ इसे आसान बनाती है। UE4 के बारे में निश्चित नहीं है। अंत में, इस उन्नत स्तर पर, आपको अधिकांश भारी भारोत्तोलन स्वयं करना होगा, हालांकि (या इसे आपके लिए करने के लिए किसी अनुभवी व्यक्ति को किराए पर लेना होगा)।

UE4 और Unity केवल तभी तक आसान होते हैं जब तक वे पुराने, अधिक स्थापित होते हैं, और इस प्रकार बड़ी संख्या में लोग ऐसी स्केलिंग समस्याओं में भाग लेते हैं, जिसका अर्थ है कि इसे हल करने के लिए अधिक ज्ञान (और किराए पर लेने योग्य प्रतिभा) उपलब्ध है।

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

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

यह काफी हद तक आपके खेल पर निर्भर करता है। किसी भी बड़े इंजन में इसका सीधा जवाब नहीं है।
क्या आपको एकता में गेमऑब्जेक्ट्स-सीन-आधारित दृष्टिकोण का उपयोग करना चाहिए? या हाइब्रिड ईसीएस? पूरी तरह से नया ईसीएस? आप किस रेंडर पाइपलाइन का उपयोग करते हैं?
क्या आप अपने UE4 प्रोजेक्ट में ब्लूप्रिंट या C++ के साथ जाएंगे?

सभी इंजन ढेर सारे विकल्प, ढेर सारे वर्कलो और ढेर सारी स्वतंत्रता प्रदान करते हैं, क्योंकि ऐसा कोई एक आकार नहीं है जो सभी समाधानों के अनुकूल हो।

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

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

मैं केवल ग्रौड से सहमत हो सकता हूं:

सभी समाधानों में ट्रेडऑफ़ हैं इसलिए "आधिकारिक" वर्कफ़्लो बनाने का कोई मतलब नहीं है।

@mhilbrunner यहाँ सिर्फ डेविल्स की वकालत कर रहा है, लेकिन एक बेहतर इंजन डिज़ाइन (जैसे वत्स में उचित ECS अधिकांश मामलों में जहाँ प्रदर्शन मायने रखता है) उन सीमाओं में से कई को लगभग किसी भी खेल की तुलना में काफी अधिक बनाता है जो वास्तव में कभी भी अनुभव होगा (इस तरह नया रस्ट एमेथिस्ट गेम इंजन उदाहरण के लिए ध्यान केंद्रित करने के लिए निर्माण कर रहा है)।

लेकिन हां, मैंने गोडोट (2) में एक ECS'ish चीज़ की है और इसने कार्यक्षमता और कार्यक्षमता के वितरण के मामले में सीनट्री इंस्टेंसिंग शैली की तुलना में बहुत बेहतर काम किया है। यह किया जा सकता है, बस थोड़ा दर्दनाक है क्योंकि गोडोट के पास इसके लिए कुछ उपयोगी आदिम नहीं हैं।

@OvermindDL1

मैं केवल अपने लिए बोल सकता हूं, अन्य गोडोट देव नहीं, और मुझे केवल यूई, यूनिटी और गोडोट के साथ अनुभव है, इसलिए मुझे रस्ट एमेथिस्ट के बारे में पता नहीं है।

यह किया जा सकता है, बस थोड़ा दर्दनाक है क्योंकि गोडोट के पास इसके लिए कुछ उपयोगी आदिम नहीं हैं।

इस बारे में चर्चा करने के बाद कि इस तरह के आदिम को जोड़ने का क्या अर्थ होगा/गोडोट ऐसे उपयोग के मामलों को बेहतर तरीके से कैसे समायोजित कर सकता है, मुझे लगता है कि यह बहुत मूल्यवान होगा। शायद इस मामले में नहीं :)

लेकिन हमें इस फीडबैक को किसी तरह इकट्ठा करना चाहिए।

और मैं मानता हूं कि इंजन के आधार पर अलग-अलग सीमाएं हैं, लेकिन फिर से, मैंने देखा है कि लोग एकता और UE4 में भी समान बाधाओं से टकराते हैं। हो सकता है बाद में, शायद वे अधिक थे - लेकिन अंत में, आपको किसी भी इंजन में आने वाली समस्याओं को हल करने में सक्षम होने की आवश्यकता होगी। :)

@MysteryGM क्या आप कह रहे हैं कि आप इमारत और पानी का प्रतिनिधित्व करने वाले नोड्स नहीं चाहते हैं, या आप उनसे जुड़ी स्क्रिप्ट नहीं चाहते हैं?

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

दोनों वस्तुओं में पहले से ही कोड होने के कारण, अब मैं क्या करूँ? मैं और नोड्स नहीं जोड़ सकता, और यह अभी भी स्पष्ट नहीं है कि क्या प्रीलोड एक संभावित समाधान है।

मेरा प्रश्न अगर मैं इसे ओओपी डिज़ाइन के रूप में वाक्यांशित करता हूं: दो स्क्रिप्ट एक दूसरे के इंटरफेस तक कैसे पहुंचती हैं?

समस्या यह है कि GDscript ऐसा नहीं लगता है कि उसके पास अन्य स्क्रिप्ट को सीधे एक्सेस करने का कोई तरीका है।
अगर मैं चाहता हूं कि आग लकड़ी को जलाए, तो मेरे पास या तो लकड़ी होनी चाहिए-> विस्तार-> आग या आग-> विस्तार-> लकड़ी।

@ मिस्ट्रीजीएम : एक टिप: सिग्नल। आग में एक सिग्नल बर्न (लक्ष्य) हो सकता है जहां लक्ष्य आपकी लकड़ी है।

दो स्क्रिप्ट एक दूसरे के इंटरफेस तक कैसे पहुंचती हैं?

$NodeWithScript.do_function() ?

_/मैं अभी भी डेविल्स एडवोकेट की भूमिका निभा रहा हूं, इसे गोडोट में 'क्या' किया जाना चाहिए, इसके किसी भी उपाय के रूप में न लें, सबसे अच्छा यह बाइकशेडिंग है_

मैं केवल अपने लिए बोल सकता हूं, अन्य गोडोट देव नहीं, और मुझे केवल यूई, यूनिटी और गोडोट के साथ अनुभव है, इसलिए मुझे रस्ट एमेथिस्ट के बारे में पता नहीं है।

UE एक अभिनेता सीनट्री मॉडल का उपयोग करता है। एकता ने एक ईसी मॉडल का इस्तेमाल किया (हालांकि हाल ही में वे एक ईसीएस का निर्माण कर रहे हैं और पुराने ईसी मॉडल को हटा रहे हैं, यह अभी तक पूरा नहीं हुआ है लेकिन यह आशाजनक लग रहा है)। और गोडोट एक कंपोनेंट सीनट्री मॉडल का उपयोग करता है। ECS डेटा प्रवाह पैटर्न का एक सबसेट है (विशेषकर यह इसका एक सामान्यीकरण है)।

ईसीएस पर त्वरित सारांश:

• एक ' ई एनटीटी' सिर्फ एक पूर्णांक आईडी है, हालांकि अधिकांश इंजन एक पीढ़ी और इकाई सूचकांक को एक int32 (8 बिट पीढ़ी और 24 बिट इंडेक्स) या int64 (32 बिट्स प्रत्येक, int64 काफी अधिक सामान्य है क्योंकि ईसीएस वास्तव में आपको अनुमति देता है) संस्थाओं की इतनी महत्वपूर्ण मात्रा में स्केल करने के लिए)।

• ए ' सी ऑम्पोनेंट' सी/सी ++ शब्दावली में एक पीओडी संरचना है, इसमें बिल्कुल कार्यक्षमता नहीं होनी चाहिए। आम तौर पर यह तुच्छ रूप से यादगार होना चाहिए।

• एक घटक 'तालिका' घटकों के लिए भंडारण है, इसकी सबसे बुनियादी पर यह केवल एक आकार बदलने योग्य सरणी हो सकती है, लेकिन सामान्य तौर पर कुछ प्रकारों का उपयोग किया जाता है:

  • आकार बदलने योग्य सरणी: अक्सर उपयोग किया जाता है जब कोई घटक अत्यंत सामान्य होता है, जैसे स्थिति।
  • विरल सरणी: अक्सर उपयोग किया जाता है जब एक घटक एक समय में संस्थाओं के समूहों में उपयोग किया जाता है।
  • मैपिंग: शायद एक हैशेड मैप या ट्री मैप या तो प्रदर्शन विशेषताओं के आधार पर जो आप उम्मीद करते हैं, लेकिन आमतौर पर कम सामान्य घटकों के लिए उपयोग किया जाता है।
  • बिटसेट्स: पूरी तरह से परिभाषा के रूप में उपयोग किया जाता है कि क्या एक घटक किसी इकाई पर मौजूद है लेकिन कुछ भी स्टोर नहीं करता है, जिसे आम तौर पर ध्वज घटक के रूप में जाना जाता है।
  • ऑक्ट्री या कुछ अन्य सीनग्राफ (गोडोट का रेंडरर यहां फिट हो सकता है): दृश्य मानचित्रण जो एक घटक होने का दिखावा करता है।
  • आदि...: एक घटक के लिए अपेक्षित पहुंच और प्रदर्शन विशेषताओं के आधार पर कई अन्य प्रकार।

• ए ' एस सिस्टम' सबसे बुनियादी एक ऐसा कार्य है जो घटकों के एक संयुक्त सेट को लेता है, हालांकि अधिकांश पुस्तकालयों में यह एक गैर-आभासी वर्ग या मॉड्यूल है या तो, यह कुछ 'करने' के लिए घटकों के उस सम्मिलित सेट पर संचालित होता है, जिसमें घटकों में मूल्यों को बदलना, घटकों को जोड़ना या हटाना आदि शामिल हो सकते हैं... कुछ उदाहरण:

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

आंतरिक रूप से आप एक ईसीएस को एक डेटाबेस के रूप में सोच सकते हैं जहां आप डेटा के मैपिंग सेट करने के लिए सदस्यता ले सकते हैं, हालांकि अगर अच्छी तरह से बनाया गया है तो वे बहुत अच्छी तरह अनुकूलित हैं। इस ज्ञान के साथ कि कौन से सिस्टम को पहले चलना चाहिए और कौन से सिस्टम गैर-अतिव्यापी (पढ़ने या पढ़ने/लिखने पर निर्भर) पर काम करते हैं, तो आप कॉल को भी बहु-थ्रेड कर सकते हैं। (मैं नीलम का उपयोग करता रहता हूं और इसका ईसीएस विशिष्ट पुस्तकालय भाग specs कहा जाता है क्योंकि एक उदाहरण के रूप में मेरे पुराने सी ++ ईसीएस पुस्तकालय को पोर्ट करने से इसके निर्माण में मेरा हाथ था) स्पेक बुक 'क्यों' ईसीएस के बारे में बहुत कुछ बताता है, ' How', दक्षता, उपयोग, आदि... नीलम और भी अधिक विस्तार में जाता है, विशेष रूप से यह बताता है कि सामान्य गेम सिस्टम, रेंडरिंग आदि के साथ ECS का उपयोग कैसे किया जाना चाहिए...

यदि आप एक अच्छी तरह से लिखित सी ++ ईसीएस पुस्तकालय देखना चाहते हैं तो https://github.com/skypjack/entt देखें , जैसा कि मैंने देखा है कि सभी सी ++ ईसीएस पुस्तकालयों से मैंने नहीं बनाया है, यह सबसे अच्छा बनाया गया लगता है कुल मिलाकर (हालांकि चश्मा अभी भी मेरे सरल परीक्षणों में इसे बेहतर प्रदर्शन करता है, हालांकि बहुत अधिक नहीं, जो कि उन सभी चीज़ों के बारे में बेहतर प्रदर्शन पर विचार करने वाला प्रभावशाली है, जिनकी तुलना मैंने कभी भी महत्वपूर्ण मार्जिन से की है)।

ईसीएस का सामान्य 'उपयोग' यह है कि आपके पास एक 'इकाई' (सिर्फ एक पूर्णांक, कोई डेटा नहीं) है, और आपके पास टेबल्स का सेट है जो घटकों को इकाइयों और सिस्टम को वास्तव में काम करने के लिए मैप करता है। जीडीस्क्रिप्ट छद्म कोड में मैं इसे एक साधारण एपीआई होने की कल्पना करता हूं, हालांकि गोडोट दृश्यों में 'एकीकृत' करने के लिए एक अजीब सम्मेलन के साथ, क्योंकि दृश्यों को इसके साथ दिमाग में डिजाइन नहीं किया गया था।

# All of this would generally be wrapped up in one or more function calls for easy
# building.

# Create a new entity
var e = createEntity()

# Map it to some Components, starting with a godot scenetree component
# I'm using long names to be descriptive, but eh...
var eNode = scenetreeComponentTable.set(e, SomeNodeType())
# Generally things like the transformation matrix and so forth would be their own
# components, but since the godot scenetree already bakes all that in then just
# deal with it all via the node type, you definitely lose a little efficiency doing
# it this way though since nodes involve multiple virtual calls to access and
# the usual ECS patterns entirely get rid of virtual calls with potentially only
# the occasional indirect calls inside a table (maps, etc...)

# 8x4 inventory slots
inventoryComponentTable.set(e, 8, 4)
# 1 fuel slot, accepts items that have the "burn" tag
fuelStorageComponentTable.set(e, 1, "burn")
# Give this entity the furnace component that uses the "basicFurnaceRecipes" recipes
furnaceComponentTable(e, "basicFurnaceRecipes")
# Add other components

# All of the above component mappings could also be in, say, a JSON file, and
# loaded something as such:
componentTables.map(e, "res://entity_types/basicFurnace.json")
# Or maybe via a preloaded JSON object or so

# Once at startup:

# And you could make a system something like, I'll use a GDScript class for this:
val furnaceCookSystemHandler = systems.register(FurnaceCookSystem.new())
furnaceCookSystemHandler.staticTickRate(0.05) # 20 times a second exactly

# Where the `FurnaceCookSystem` could be something like:
class FurnaceCookSystem:
  def _entity_matchers():
    furnaceBurnMatcher =
      componentTables.matcher().
      write(inventoryComponentTable).
      write(fuelStorageComponentTable).
      writeEither(inventoryChangedComponentTable, furnaceCookingComponentTable)
      read(furnaceComponentTable)
    return [furnaceBurnMatcher]

  # Assume we have matching semantics here to destructure a list, I'm lazy...
  def _entities_process([furnaceBurnEntities], delta):
    # This function takes a list of entity sets in the same order as the matchers
    # returned above.
    while entity in furnaceBurnEntities:
      val furnace = furnaceComponentTable[entity] # or .get(entity) or whatever API
      val cooking = furnaceCookingComponentTable[entity]
      if cooking == null or cooking.cookTimeRemaining <= 0:
        if cooking != null:
          if inventoryComponentTable.put(item) == False: # No space, try later
            continue
        # Get next item that has a "burnable" tag, if any
        val item = inventoryComponentTable[entity].getAndRemoveFirstOf("burnable")
        if item == null:
          furnaceCookingComponentTable.remove(entity)
        else:
          cooking = furnaceCookingComponentTable.set(entity, item, furnace.cookTime * getCookTimeModifierOfItem(item))
      else:
        cooking.cookTimeRemaining -= delta

 # ... whatever other functions are useful to the system

# Then of course just with the right components on any entity it will just work
# 'as' a furnace.  You can have a whole variety of 'generic' systems that can be
# mixed and match with impunity.  If you want a random rock that can be a furnace
# then just add the proper components, or if you want an Ent that can both be
# chopped down like a tree for wood but will also attack the player then just add
# the proper components, etc.... etc....

@ मिस्ट्रीजीएम : एक टिप: सिग्नल। आग में एक सिग्नल बर्न (लक्ष्य) हो सकता है जहां लक्ष्य आपकी लकड़ी है।

क्षमा करें, मेरा मतलब स्क्रिप्ट से था उदाहरण नहीं। मैं चाहता हूं कि गोडोट पेड़ में नोड की आवश्यकता के बिना स्क्रिप्ट बातचीत करें।

क्षमा करें, मेरा मतलब स्क्रिप्ट से था उदाहरण नहीं। मैं चाहता हूं कि गोडोट पेड़ में नोड की आवश्यकता के बिना स्क्रिप्ट बातचीत करें।

हो सकता है कि मैं आपकी समस्या को गलत समझ रहा हूँ, लेकिन मुझे पूरा यकीन है कि आप पहले से ही GDScript में कक्षाएं बनाकर ऐसा कर सकते हैं। प्रवेश बिंदु के रूप में काम करने के लिए आपको अभी भी एक ऑटो लोड या नोड पर कम से कम एक स्क्रिप्ट की आवश्यकता होगी।

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

@MysteryGM दृश्य में नोड के उपयोग के बिना एक-दूसरे के साथ बातचीत करने के लिए स्क्रिप्ट प्राप्त करने का मतलब है कि आपको स्क्रिप्ट संसाधन का लोडेड संस्करण कम से कम प्राप्त करना होगा। 3.0 में ऐसा करने का एकमात्र तरीका फ़ाइल पथ द्वारा preload / load स्क्रिप्ट है। 3.1 जीडीस्क्रिप्ट और नेटिवस्क्रिप्ट के लिए "स्क्रिप्ट क्लास" फीचर जोड़ता है जहां स्क्रिप्ट को दिए गए नाम विश्व स्तर पर पंजीकृत होते हैं। GDScript मैन्युअल रूप से उन वैश्विक पंजीकरणों को इंजन में भाषा में वैश्विक चर में परिवर्तित करता है।

फिर, यदि आपके पास Script संसाधन है, तो आप स्क्रिप्ट पर स्थिर विधियों को कॉल कर सकते हैं या .new() ScriptInstance करने के लिए .new() पर कॉल कर सकते हैं और फिर सदस्य फ़ंक्शन/एक्सेस सदस्य चर को कॉल कर सकते हैं। यदि Script वस्तु, संदर्भ, संसाधन, या अन्य गैर-नोड प्रकार प्राप्त कर रहा है, तो बस Script / ScriptInstance का एक उदाहरण बनाना आपको प्राप्त करने की आवश्यकता होगी स्थिर/गैर स्थैतिक सामग्री। यदि यह एक नोड है, तो यह उन चीजों को छोड़कर लागू होता है जिनके लिए सीनट्री एक्सेस की आवश्यकता होती है (जैसे get_node ) जिस स्थिति में आपको इसे पहले सीनट्री में जोड़ने के लिए add_child का उपयोग करना होगा।

उपरोक्त सभी गोडोट के साथ उपयोग की जाने वाली किसी भी स्क्रिप्टिंग भाषा पर लागू होते हैं (हालांकि, प्रीलोड कुछ निश्चित भाषाओं के लिए विशिष्ट ऑपरेशन है जो मुझे विश्वास है ...)

फ़ाइल पथ द्वारा स्क्रिप्ट। 3.1 GDScript के लिए "स्क्रिप्ट क्लास" फीचर जोड़ता है

3.1 कब आधिकारिक रूप से जारी किया जाएगा?

@MysteryGM जब मील का पत्थर प्रतिशत पूरा होना काफी अधिक होता है/जब मुख्य देवों ने प्रगति को काफी दूर तक आंका है, तो वे निर्माण को "स्थिर" मानते हैं।

मील का पत्थर: https://github.com/godotengine/godot/milestone/7

तुलना के लिए, 2.1 और 3.0 वर्तमान में 99% पूर्णता पर बैठे हैं। हालांकि यह निश्चित नहीं है कि जब वे लाइव हुए थे तब वे उस स्थिति में थे या नहीं।

मूल रूप से, उत्तर "जब यह तैयार हो" है।

प्रतिक्रियाओं के लिए धन्यवाद और हम आपका समय लेने के लिए क्षमा चाहते हैं।
ऐसा लगता है कि गोडोट उस समय हमारी आवश्यकताओं के अनुरूप नहीं है। हो सकता है कि भविष्य में हमें फिर से इंजन का उपयोग करने का मौका मिले।

अगर मैं चाहता हूं कि आग लकड़ी को जलाए, तो मेरे पास या तो लकड़ी होनी चाहिए-> विस्तार-> आग या आग-> विस्तार-> लकड़ी।

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

सी # में मैं कह सकता हूं कि Wood IBurnable $ लागू करता है जो Fire उपयोग करता है।

नमस्ते, निरंतर चिंता के लिए धन्यवाद और हम @willnationsdev समर्थन के लिए वास्तव में आभारी हैं। हमारा मानना ​​है कि निर्यात संसाधन समाधान के रूप में स्क्रिप्ट में काफी संभावनाएं हैं। जैसा कि #22660 में बताया गया है।

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

"गोडोट डेवलपर्स जीथब में हर मुद्दे को अपनी पोस्ट पर रखते हैं, हमेशा एक बग के लिए एक मुद्दा खोलते हैं , लेकिन अपने इंजन के लिए समान वर्कफ़्लो की अनुमति नहीं देते हैं।"
तथ्य यह है कि हमें एक स्क्रिप्ट बनानी है और हम इसे पदानुक्रम में जोड़ने के लिए मजबूर हैं।

"सिस्टम" स्क्रिप्ट जो आग और जंगल के बीच बातचीत को नियंत्रित करती है। वह प्रस्तुति घटकों पर केंद्रित है

हाँ, हम यही चाहते हैं, हम इसे GDscript में कैसे करते हैं?

सी # में मैं कह सकता हूं कि लकड़ी आईबर्नेबल लागू करती है जो आग का उपयोग करती है।

गोडोट के पास इंटरफेस के समान काम करने के लिए डक टाइपिंग है। हम जो चाहते हैं वह बर्निंग को एक अलग वर्ग बनाना है ताकि हम पदानुक्रम में नोड जोड़ने के लिए मजबूर किए बिना इसका पुन: उपयोग कर सकें।

हम जो चाहते हैं वह है आग, जलना, लकड़ी। हमें आग (लकड़ी+जलना) नहीं चाहिए।
इस वर्कफ़्लो का लाभ यह है कि हम बर्निंग को स्वयं डिबग कर सकते हैं, बिना जलने वाली प्रत्येक वस्तु को ठीक करने की आवश्यकता के।

सी # में हम सिर्फ बर्निंग को अपनी कक्षा के रूप में घोषित करेंगे। पब्लिक क्लास बर्निंग और हमारी समस्या का समाधान।
सी ++ में हम जलन और समस्या हल शामिल करेंगे।

हाँ, हम यही चाहते हैं, हम इसे GDscript में कैसे करते हैं?

@मिस्ट्रीजीएम

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

चीजों को तेज करने के लिए, कोई केवल उन वस्तुओं की जांच कर सकता है जो वास्तव में टकराई थीं (उदाहरण के लिए, टक्कर होने पर ऑब्जेक्ट से सिस्टम में signal भेजकर)।

स्क्रिप्ट क्रॉस-रेफ़रेंसिंग के लिए कुछ GDScript-विशिष्ट उदाहरण (संस्करण 3.0 के लिए):

यहां Enemy टाइप/इंटरफ़ेस के रूप में कार्य करता है, कोई भी is ऑपरेटर के साथ इसकी जांच कर सकता है:

# Cache the enemy class.
const Enemy = preload("enemy.gd")

# Use 'is' to check inheritance.
if (entity is Enemy):
    entity.apply_damage()

यहां runnerGame पथ/रूट/रनर के साथ एक _autoload_ दृश्य (उर्फ सिंगलटन) को इंगित करता है:

onready var runnerGame = get_node("/root/runner")
onready var runnerScript = preload("res://runner/runner.gd")

func _ready():
    runnerGame.setMode(runnerScript.SPAWN_TITLE)

यहां हम बटन के signal "दबाए गए" को हैंडलर से जोड़ते हैं (जो एक अलग ऑब्जेक्ट और स्क्रिप्ट में हो सकता है, हम उसी को संदर्भित करने के लिए self का उपयोग कर रहे हैं):

func _button_pressed(which):
    print("Button was pressed: ", which.get_name())

func _ready():
    for b in get_node("buttons").get_children():
        b.connect("pressed", self, "_button_pressed",[b])

यहां दस्तावेज़ भी देखें, कुछ और सुविधाएं उपलब्ध हैं: http://docs.godotengine.org/en/3.0/getting_started/scripting/gdscript/gdscript_basics.html#inheritance

यहां दस्तावेज़ भी देखें, कुछ और सुविधाएं उपलब्ध हैं:

विषय में आपके इनपुट के लिए धन्यवाद। विरासत के साथ समस्या यह है कि यह केवल तभी काम करता है जब हम कक्षाओं के सभी संबंधों को जानते हैं जब हम उन्हें लागू करते हैं।

यहाँ एक उदाहरण है:

चरण ए.
मेशइंस्टेंस + होमिंगस्क्रिप्ट = होमिंग मिसाइल ।
लेकिन अब अगर मुझे होमिंग लैंडमाइन चाहिए तो मुझे एक समस्या है।
(MeshInstance+ ProximityScript) = लैंडमाइन ।
(MeshInstance+ ProximityScript) + होमिंगस्क्रिप्ट = त्रुटि एक से अधिक स्क्रिप्ट
(MeshInstance+ ProximityScript) + (childNode + HomeingScript) = FAILED क्योंकि केवल अदृश्य नोड चलता है।
(MeshInstance+ ProximityScript) + (childNode + ExtendedHomingScript) = SUCCESS क्योंकि अब हम होमिंग क्लास का विस्तार करते हैं ताकि इसमें चाइल्ड नोड से नोड्स हो सकें। हमें होमिंग लैंडमाइन मिलता है।

सिवाय अब यह तर्क दिया जा सकता है कि होमिंग मिसाइल और लैंडमाइन दोनों को होमिंग क्लास से विस्तारित किया जाना चाहिए।

चरण बी।
होमिंग मिसाइल [होमिंग से]
होमिंग लैंडमाइन [होमिंग से] [+ ProximityScript] स्क्रिप्ट को अब कॉपी करके बारूदी सुरंग में चिपका दिया गया है।

बाद में उत्पादन में वही बात हमारे पास मौजूद अन्य लिपियों के साथ होती है।
चरण सी।
लैंडमाइन [निकटता से]
निकटता अलार्म [निकटता से] [+ अलार्मस्क्रिप्ट]
// होमिंग लैंडमाइन [निकटता से] [+ होमिंगस्क्रिप्ट] // अब हमारी लैंडमाइन भी यहां फिट हो सकती है।

इसलिए हमें StepB के लिए उचित वंशानुक्रम खोजने के लिए StepA से गुजरते रहना होगा। यह StepF आदि से आगे जाकर इस पैटर्न को दोहराता रहता है।

हमें StepA को लम्बा करने का एक तरीका मिला, हम केवल शीर्ष नोड में एक स्क्रिप्ट जोड़ने से बचते हैं, और हमेशा इसे एक स्थानिक या कुछ प्राथमिक नोड बनाते हैं।
(स्थानिक + MeshInstance+ निकटता स्क्रिप्ट) + होमिंगस्क्रिप्ट = होमिंगलैंडमाइन
सिवाय इसके कि यह वही समस्या है लेकिन अधिक महंगी पेरेंटस्पेशियल के साथ; चाइल्डनोड के बजाय।

मैं क्षमा चाहता हूं कि यह कब तक है।

@मिस्ट्रीजीएम

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

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

• सी++
  
  
  
  • क्लास बर्निंग {};
  
  
  • "बर्निंग.एच" शामिल करें;
  
  
  • जलन :: लागू (लकड़ी, आग);
  
  
  • बर्निंग * बी = बर्निंग :: get_singleton (); बी-> लागू करें (लकड़ी, आग);
  
  
• सी # (स्टाइल परिवर्तन के लिए संपादित)
  
  
  
  • पब्लिक क्लास बर्निंग {}
  
  
  • खेल का उपयोग करना। जलना;
  
  
  • जलना। लागू करें (लकड़ी, आग);
  
  
  • जलना ख = जलना। उदाहरण; बी.लागू करें (लकड़ी, आग);
  
  
• जीडीस्क्रिप्ट (3.1)
  
  
  
  • संसाधन बढ़ाता है # burning.gd
  
  
  • कास्ट बर्निंग = प्रीलोड ("res://burning.gd")
    
    
    
    
    
    • 3.0 में, आपके सभी सामान्य रूप से उपयोग की जाने वाली उत्तेजनाओं के लिए स्थिरांक लोड करने के लिए एक सामान्य स्क्रिप्ट का उपयोग कर सकता है।
      
      
      संदर्भ बढ़ाता है
      
      
      कास्ट बर्निंग = प्रीलोड ("res://burning.gd")
      
      
      कास्ट वेटिंग = प्रीलोड ("res://wetting.gd")
      
      
      संदर्भ बढ़ाता है
      
      
      कॉन्स्ट स्टिमुली = प्रीलोड ("res://stimuli.gd")
      
      
      # स्टिमुली का उपयोग करें। जलन या उत्तेजना। गीला करना
    
    
    
    • 3.1 में, केवल स्क्रिप्ट कक्षाओं का उपयोग कर सकते हैं। जलने और गीला करने के लिए किसी "समावेश" की आवश्यकता नहीं है क्योंकि वे वैश्विक हैं।
      
      
      इसके अलावा, यदि वैश्विक उपयोग के विपरीत, "स्टिमुली" को समान निरंतर घोषणाओं के साथ स्क्रिप्ट क्लास बना सकता है, ताकि यह हमेशा छद्म नामस्थान के रूप में उपलब्ध हो।
    
    
    
  
  
  • जलना। लागू करें (लकड़ी, आग)
  
  
  • वर बी = Burning.new ()
    
    बी.लागू करें (लकड़ी, आग)
  
  

यूनिटी/स्क्रिप्टेबलऑब्जेक्ट दृष्टिकोण के लिए, एक ही उद्देश्य के लिए गोडोट की संसाधन स्क्रिप्ट का उपयोग कर सकते हैं।

• सेटिंग्स को इंस्पेक्टर में कॉन्फ़िगर किया जा सकता है।
• फीचर के "बिल्ड्स" को एक फाइल में सेव किया जा सकता है ताकि कुछ सेटिंग्स को जरूरत के मुताबिक आसानी से बदला जा सके, यहां तक ​​कि रनटाइम पर भी।
• संपादक स्वचालित रूप से दृश्य घोषणा का उपयोग करके नोड पर संसाधन का एक उदाहरण बनाता है, इसलिए कोई मैन्युअल अद्यतन आवश्यक नहीं है। ऐसे संसाधनों की एक सरणी यथोचित रूप से अच्छी तरह से काम कर सकती है, हालांकि, सरणी प्रकार संकेत प्रणाली 3.1 (उम्मीद से 3.2 तक) में टूटी हुई है, आपको इंस्पेक्टर सामग्री को ठीक से उत्पन्न करने के लिए एक EditorInspectorPlugin लिखना होगा (जो वास्तव में मैं काम कर रहा हूं) मेरे गोडोट -नेक्स्ट रिपोजिटरी के फाइलसिस्टम इटैमलिस्ट (चेतावनी, यह एक प्रारंभिक डब्ल्यूआईपी है) में फाइलों/निर्देशिकाओं के सरणी के लिए मेरे गोडोट-बिल्डर रिपोजिटरी में उपयोग किया जाना है।

"सिस्टम" स्क्रिप्ट जो आग और जंगल के बीच बातचीत को नियंत्रित करती है। वह प्रस्तुति घटकों पर केंद्रित है

हाँ, हम यही चाहते हैं, हम इसे GDscript में कैसे करते हैं?

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

मेरे पास वास्तव में एक पुराने डब्ल्यूआईपी प्लगइन, गोडोट-कौशल का एक बड़ा रिफैक्टरिंग है, जो मैं करना चाहता हूं, मेरा मानना ​​​​है कि इसमें और बहुत कुछ शामिल है। कृपया विषय पर (क्षमा करें, लंबा) reddit धागा पढ़ें। इसमें एक समान सामान्य और पुन: प्रयोज्य अंतःक्रियाशीलता प्रणाली को लागू करने के लिए एक सर्वर आर्किटेक्चर (गोडोट के अंतर्निहित आर्किटेक्चर के समान) में समन्वित मल्टीथ्रेडिंग का उपयोग करने की व्यवहार्यता की जांच करना शामिल है।

btw, यदि आप कभी भी इस विषय पर वास्तविक समय में चैट करना चाहते हैं, तो बेझिझक मुझे Reddit/Discord/Twitter पर अपराह्न करें जहां मैं उसी उपयोगकर्ता नाम का उपयोग करता हूं।

@मिस्ट्रीजीएम

मेशइंस्टेंस+ होमिंगस्क्रिप्ट = _होमिंगमिसाइल_.
लेकिन अब अगर मुझे होमिंग लैंडमाइन चाहिए तो मुझे एक समस्या है।
(MeshInstance+ ProximityScript) = _Landmine_.
(MeshInstance+ ProximityScript) + होमिंगस्क्रिप्ट = त्रुटि एक से अधिक स्क्रिप्ट
(MeshInstance+ ProximityScript) + (childNode + HomeingScript) = FAILED क्योंकि केवल अदृश्य नोड चलता है।
(MeshInstance+ ProximityScript) + (childNode + ExtendedHomingScript) = SUCCESS क्योंकि अब हम होमिंग क्लास का विस्तार करते हैं ताकि इसमें चाइल्ड नोड से नोड्स हो सकें। हमें _होमिंग लैंडमाइन_ मिलता है।

सिवाय अब यह तर्क दिया जा सकता है कि होमिंग मिसाइल और लैंडमाइन दोनों को होमिंग क्लास से विस्तारित किया जाना चाहिए।

मुझे विश्वास है कि मैं यहाँ कुछ याद कर रहा हूँ। अफैक, "घटक व्यवहार" नोड बनाने का उचित तरीका वह है जो स्वयं को नहीं बदलता है, बल्कि सीधे "लक्ष्य" नोड को संशोधित करता है जहां डिफ़ॉल्ट लक्ष्य माता-पिता होता है। अगर मैं गलत नहीं हूं, तो यह उस मुद्दे को पूरी तरह से रोकता है जिसका आप सामना कर रहे हैं।

extends Node
var src_target
export(NodePath) onready var dst_target = get_node(dst_target) if dst_target else null
func _notification(p_what):
    match p_what:
        NOTIFICATION_PARENTED:
           src_target = get_parent()
        NOTIFICATION_UNPARENTED:
           src_target = null
func _physics_process():
    # if necessary, can manually assign src_target elsewhere to be NOT a parent
    if src_target and src_target is KinematicBody2D:
        src_target.move_and_slide(...) # do logic to get parameters that move towards dst_target

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

कुछ सुधार:

 - C#
-   - public class Burning {};
+   - public class Burning {}
    - using Game.Burning;
    - Burning.apply(wood, fire); // is it :: here? I forget...
-   - Burning b = Burning::GetSingleton(); b.apply(wood, fire);
+   - Burning b = Burning.GetSingleton(); b.apply(wood, fire);

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

@neikeq धन्यवाद। मैं सी #, लॉल के साथ अभ्यास से बहुत बाहर हूं।

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

शायद इसके बजाय हम बेयरबोन Node नोड के प्रदर्शन में सुधार कर सकते हैं ताकि यह ऑब्जेक्ट "घटकों" के लिए ओवरहेड पेश न करे जो पूरी तरह से स्क्रिप्ट रखते हैं। या शायद एक अलग सरल "केवल-होल्ड-स्क्रिप्ट" नोड भी।

@aaronfranke

जहां तक ​​"वैश्विक लिपियों" के दृष्टिकोण का सवाल है, मैं इसके बहुत खिलाफ हूं। यह देवों को अपने खेल को खराब तरीके से कोड करने के लिए प्रोत्साहित करेगा। पिछले नंगे सी ++ और जावा गेम देवों का एक सामान्य प्रश्न, जब वे एकता/अवास्तविक/गोडोट/आदि का प्रयास करते हैं, तो "मुख्य गेम लूप कहां है जिसमें मैं अपना कोड लिख सकता हूं?"।

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

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

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

शायद इसके बजाय हम बेयरबोन नोड नोड के प्रदर्शन में सुधार कर सकते हैं ताकि यह ऑब्जेक्ट "घटकों" के लिए ओवरहेड पेश न करे जो पूरी तरह से स्क्रिप्ट रखते हैं।

किस तरह से? इसे पारदर्शी रूप से करने का एकमात्र तरीका एक मल्टीस्क्रिप्ट सिस्टम को लागू करना होगा और उस प्रतिमान के साथ आने वाली समस्याओं की एक पूरी मेजबानी है। उस समस्या को हल करने का प्रयास करते समय मैं केवल एक अन्य विकल्प के साथ आ सकता था, वह था जीडीस्क्रिप्ट विशेषता प्रणाली जिसे मैंने # 23101 में सुझाया था जो मल्टीस्क्रिप्ट मुद्दों को एक भाषा तक सीमित रखता है, लेकिन और भी गंभीर समस्याओं के अपने स्वयं के मेजबान के साथ आता है।

या शायद एक अलग सरल "केवल-होल्ड-स्क्रिप्ट" नोड भी।

एक बार जब हम 3.2 में सरणी प्रकार संकेत प्रणाली को ठीक कर लेते हैं, तो हम इसे बस के साथ करने में सक्षम होंगे ...

extends Node
export(Array, Script) behaviors = []

कोई भी अब डिक्शनरी (नाम से स्क्रिप्ट तक पहुंचने के लिए) और 3.1 से एक EditorInspectorPlugin का उपयोग करके एक कस्टम UI को परिभाषित करने के लिए सुविधा को लागू कर सकता है जब उन नोड्स को इंस्पेक्टर में खोला जाता है (एक निर्यात-एरे-ऑफ-स्क्रिप्ट UI बनाएं, लेकिन है यह स्क्रिप्ट को एक कुंजी के साथ जोड़ता है जो फ़ाइल नाम अंडर-द-हुड से मेल खाता है)।

संसाधन बढ़ाता है # burning.gd

आह, मुझे लगता है कि मुझे हमारी समस्या मिल गई है। हमारा कोई भी प्रीलोड प्रयास संसाधन से विस्तारित नहीं हो रहा था। मुझे नहीं लगता कि हम में से कोई भी जानता था कि हम कस्टम संसाधन बना सकते हैं।

मैं यह भी बताना चाहता हूं कि कोई भी व्यक्ति जिसने हमारे साथ अपने खेल साझा किए या जिसने उनके कार्यप्रवाह का वर्णन किया, वह संसाधन से विस्तार नहीं कर रहा था।
लगभग सभी लोग Node. यह नहीं पता कि इससे कितना फर्क पड़ता है, परीक्षण चलाने की आवश्यकता होगी।

FileSystemItemList (चेतावनी, यह एक प्रारंभिक WIP है)

निश्चित रूप से इसे एक नज़र डालना होगा।

@मिस्ट्रीजीएम

मुझे नहीं लगता कि हम में से कोई भी जानता था कि हम कस्टम संसाधन बना सकते हैं।

हां! मैंने अभी हाल ही में दस्तावेज़ों में एक अनुभाग जोड़ा है जो प्रक्रिया की रूपरेखा तैयार करता है। :-डी

आप ऑब्जेक्ट, संदर्भ, संसाधन, और, ज़ाहिर है, नोड (या इनमें से किसी भी वर्ग के व्युत्पन्न) सहित किसी भी इंजन प्रकार को स्क्रिप्ट के साथ बढ़ा सकते हैं। केवल वही चीज़ें जिन्हें विस्तारित नहीं किया जा सकता है, वे हैं इंजन और संपादक सिंगलटन (जैसे OS, इंजन, या EditorFileSystem)।

विषय में आपके इनपुट के लिए धन्यवाद। विरासत के साथ समस्या यह है कि यह केवल तभी काम करता है जब हम कक्षाओं के सभी संबंधों को जानते हैं जब हम उन्हें लागू करते हैं।

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

ठीक है, हमारे पास नई पद्धति का परीक्षण करने के लिए कुछ समय है और यह पूरी तरह से काम करने के लिए है। हम जहां पहले से ही स्क्रिप्ट के साथ सैकड़ों नोड्स को बदलने में सक्षम हैं; प्रदर्शन में बहुत सुधार।

यह ध्यान में रखते हुए कि संसाधन प्रीलोडिंग स्क्रिप्ट्स को शामिल करने की समस्या को हल करता है। GDscript में संसाधन चर निर्यात करके एकता के मल्टीस्क्रिप्ट और ScriptableObject दोनों के विकल्प के रूप में भी इस्तेमाल किया जा सकता है।
इस तथ्य के साथ कि संसाधनों को अधिक विस्तार से समझाने के लिए दस्तावेज़ों को अद्यतन किया गया है।
उल्लेख नहीं है कि गोडोट 3.1 में स्क्रिप्ट कक्षाएं भी होंगी जो और भी अधिक वर्कफ़्लो की अनुमति देंगी।

मुझे लगता है कि इस मुद्दे का मूल लक्ष्य हल हो गया है, और अब इस मुद्दे को बंद किया जा सकता है?

मैं फिर से चर्चा में भाग लेने के लिए सभी को धन्यवाद कहना चाहता हूं, और विशेष रूप से @willnationsdev को धन्यवाद, जिन्होंने गोडोट इंजन में बड़ी मात्रा में अंतर्दृष्टि प्रदान की।

@MysteryGM मुझे लगता है कि इस धागे की शुरुआत और इस धागे के अंत में आपके विचार ब्लॉग या गोडोट-डॉक्स ड्राफ्ट में लिखने के लिए अच्छे हो सकते हैं। मुझे लगता है कि जटिल स्क्रिप्टिंग संगठन को प्राप्त करने का प्रयास करते समय अधिकांश शुरुआती उपयोगकर्ता अक्सर प्रदर्शन गलतियां करते हैं, हमें सीखने के मामले में "पहले" बनाम "बाद" के अच्छे लेखन की आवश्यकता होती है। शुरुआती ट्यूटोरियल में हम जो पाठ और पैटर्न सीखते हैं, वे बड़े पैमाने के खेलों में अच्छी तरह से अनुवाद नहीं करेंगे, जिसका मेरे लिए सीधा मतलब है कि हमें बड़े पैमाने के पाठों पर अधिक ब्लॉग/सलाह की आवश्यकता है।

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

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

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

@pgruenbacher @MysteryGM जबकि गोडोट के साथ पहले/बाद के अनुभव की एक ही नस में नहीं, इस मुद्दे और कुछ संबंधित पुनरावर्ती प्रश्नों ने मुझे गोडोट-डॉक्स के लिए एक दृश्य/स्क्रिप्ट डिज़ाइन सर्वोत्तम अभ्यास आलेख पर काम करना शुरू करने के लिए प्रेरित किया है। मेरे कांटे पर एक शाखा है, लेकिन यह बहुत जल्दी WIP एटीएम है।

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

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

बुधवार, 14 नवंबर, 2018 को, हारून-फ्लेशर नोटिफिकेशन @github.com
लिखा था:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/23052#issuecomment-438871197 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ADLZ9pw2-G0kE19meyi7iSkceAldfAMjks5uvLb4gaJpZM4XelSe
.

@ हारून-फ्लेशर

... अगर हम सही इंजन चुनते हैं तो मुझे दूसरा अनुमान लगाना चाहिए

यदि आप अभी जिस इंजन का उपयोग कर रहे हैं वह आपके लिए काम कर रहा है, भले ही आपको कुछ काम-काज करना पड़े, तो परेशान होने की कोई बात नहीं है। आपको कुछ खिलाड़ी (या अन्य देव) आपकी क्षमता/पवित्रता पर सवाल उठा सकते हैं, लेकिन यह सिर्फ खेल के विकास की वास्तविकता है। स्पष्ट अधिकार के साथ बात करने वाले बहुत से भावुक लोग (अक्सर अपने वास्तविक कौशल स्तर से ऊपर)।

आप ही हैं जो आपकी समस्याओं को जानते हैं, और आप ही हैं जिन्हें काम करना है। जो कुछ भी आपको और 10% -20% उत्पादकता खरीद सकता था, उससे लकवाग्रस्त होने से बचें। इसे अगले गेम के लिए सेव कर लें। या नहीं, क्योंकि आप पहले से ही उन उपकरणों को सीखने में एक टन का निवेश कर चुके हैं जिन्हें आप पहले से जानते हैं। आपकी पंसद :)

मुझे नहीं पता, मुझे यह महसूस होता है कि गोडोट डेवलपर्स नहीं जानते कि वे क्या कर रहे हैं।

पहली बार गोडोट 3.0.6 स्थिर का उपयोग करने पर, मुझे एक बदसूरत, बेकार "प्रोजेक्ट मैनेजर" के साथ प्रस्तुत किया जाता है। जब मैं यह भी पता लगा सकता हूं कि यह कैसे काम करता है (और यह बिल्कुल भी सहज नहीं है), ऐप हर बार क्रैश हो जाता है जब मैं एसेट लाइब्रेरी से एक उदाहरण प्रोग्राम डाउनलोड करने का प्रयास करता हूं। कभी-कभी, ऐप प्रतिक्रिया देना बंद कर देता है। कभी-कभी, ऐप रहस्यमयी "हालत !कनेक्टेड इज ट्रू" त्रुटियाँ फेंकता है। कभी-कभी, डाउनलोड स्टाल। और हर बार, एक 100MB फ़ाइल को अधिकतर डाउनलोड करने में लगभग 10 मिनट का समय लगता है, जबकि मैं 10GB अन्य जगहों पर उतने ही समय में डाउनलोड कर सकता हूँ। "पुन: प्रयास करें" संपूर्ण डाउनलोड को प्रारंभ से प्रारंभ करता है।

मुझे लगता है कि यहां "स्थिर" का अर्थ है "हर बार मज़बूती से खराब हो जाएगा।"

एक जबरदस्त पहली छाप के बारे में बात करें।

@dejayc यह अजीब है। विंडोज़ 10 या मेरे लिनक्स मिंट डिवाइस पर मुझे प्रोजेक्ट मैनेजर के साथ कभी भी (3.0.6 स्थिर या यहां तक ​​​​कि मास्टर शाखा के साथ) कोई समस्या नहीं है। मैं आपको यहां अपनी समस्याओं के बारे में एक नया मुद्दा बनाने की सलाह दूंगा (क्योंकि यह वास्तव में ऐसे विषय के लिए सही मुद्दा नहीं है), और उम्मीद है कि कोई बेहतर सहायता प्रदान कर सकता है।

@dejayc
अगर हम सभी पैट्रियन को दान करते हैं, तो गोडोट परियोजना पूर्णकालिक प्रयोज्य व्यक्ति को काम पर रखने में सक्षम होगी।

जबकि मैं आपसे छोटी-छोटी बातों से सहमत हूं, सोशल मीडिया में मार्केटिंग पोस्ट के आधार पर इंजनों का चयन किया जाना चाहिए, विशेष परियोजना के लिए उनकी कमियां कितनी महत्वपूर्ण हैं। और दुख की बात है कि उन सभी में _a बहुत_ कमियां हैं, जो UI के सतही स्तर से अधिक गहरी हैं...

उस ने कहा, मैंने प्रोजेक्ट मैनेजर के बारे में एक सुझाव मुद्दा खोला, कुछ खाली समय दिया, मैं इस क्षेत्र में कुछ सुधारों पर काम करने जा रहा हूं।

मैंने एकता और गोडोट दोनों के साथ काम किया है और गोडोट में सामान्य वर्कफ़्लो और संरचना को बहुत बेहतर और सहज पाया है (विशेष रूप से एकता से दृश्य/प्रीफ़ैब के बजाय दृश्य मॉडल, बहु-घटकों के बजाय "एकल-स्क्रिप्ट" मॉडल, गति जब इंजन को डाउनलोड/शुरू करना और निर्यात करना और पूरी तरह से ऑफ़लाइन काम करने की क्षमता)।

उन दोनों में बहुत सारे सकारात्मक कार्यप्रवाह और मॉडल हैं और यह जानना कभी भी आसान नहीं होता है कि आपके लिए कौन सा बेहतर है।