Godot: सी # स्क्रिप्टिंग भाषा के रूप में

GDscript में और अधिक सुविधाएँ जोड़ना मेरी राय में स्क्रिप्टिंग तक पहुँचने का बेहतर तरीका होगा

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

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

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

अब एक स्क्रिप्टिंग भाषा एक इंजन का एक अभिन्न अंग है, इसलिए भाषा के दर्शन को इंजन के दर्शन में फिट होना चाहिए, या कम से कम इसका खंडन नहीं करना चाहिए।

तो गोडोट का दर्शन क्या है? आइए कुछ तथ्यों पर नजर डालते हैं:

• गोडोट की तुलना में हर दूसरा प्रमुख इंजन फूला हुआ है।
  गोडोट का डाउनलोड 20MB से छोटा है, संपूर्ण "इंस्टॉलेशन" एक निष्पादन योग्य है जिसका आकार 50MB से कम है। दूसरी ओर लंबरयार्ड का प्रारंभिक डाउनलोड आकार लगभग 5.5GB है, वर्तमान में इसका मेरा इंस्टॉलेशन फ़ोल्डर 15.3GB बड़ा है। इसका मुख्य कारण निर्भरता के संबंध में अमेज़ॅन का दर्शन है। उस प्रारंभिक डाउनलोड में 42 निर्भरताओं की 10.5GB निर्मित छवियां शामिल हैं, और यदि आपने अमेज़ॅन वेब सेवाओं के साथ काम किया है, तो आप जानते हैं कि एडब्ल्यूएस एसडीके उस पहलू में अलग नहीं है, इसलिए यह आवश्यकता या क्षमता की बात नहीं है, यह एक मामला है की पसंद। उदाहरण के लिए, जबकि लंबरयार्ड में बूस्ट और लुआ शामिल हैं, गोडोट में सबसे महत्वपूर्ण एसटीएल कंटेनरों के अपने संस्करण हैं और लुआ के बजाय जीडीस्क्रिप्ट का उपयोग करते हैं, जो आकार को नीचे रखता है, निर्भरता को हटाता है और कोड को बहुत अधिक पठनीय और सुलभ बनाता है।
• गोडोट का स्रोत कोड बहुत सुलभ है।
  यह बिल्ड सिस्टम (SCons) की पसंद से शुरू होता है जो एक बिल्ड भाषा के रूप में पायथन का उपयोग करता है। अधिकांश अन्य परियोजनाएं मालिकाना बिल्ड भाषाओं के साथ मौजूदा बिल्ड सिस्टम का उपयोग करती हैं या अपनी खुद की मालिकाना बिल्ड सिस्टम लिखती हैं, दोनों का बिल्ड कोड की पठनीयता पर नकारात्मक प्रभाव पड़ता है।
  उस पहलू में स्रोत कोड भी औसत से ऊपर है। मुझे यह पता लगाने में लगभग उतना ही समय लगा कि C++ में एक अवास्तविक ब्लूप्रिंट नोड कैसे लिखा जाता है क्योंकि मुझे गोडोट के लिए अपने पहले पुल अनुरोध के लिए कोड लिखने में समय लगा। इसका मतलब यह नहीं है कि अवास्तविक का सी++ कोड अपठनीय था, यह गोडोट जितना साफ नहीं है क्योंकि यह अधिक मैक्रोज़ का उपयोग करता है और उपयोगकर्ता को गोडोट की तुलना में अवास्तविक के डिफ़ॉल्ट प्रोजेक्ट कोड को अधिक समझने की आवश्यकता होती है।
• गोडोट KISS और OO सिद्धांतों को बढ़ावा देता है।
  इसे स्पष्ट करने के लिए आइए एकता में कुछ सरल वस्तुओं को देखें। एकता में आपका सामना करने वाली पहली अवधारणा GameObjects की संलग्न घटकों के साथ है। "इनहेरिटेंस पर रचना" जैसा कि अक्सर कहा जाता है (मैं माइकल जे। डिकेइज़र के फॉर्मूलेशन "कंटेनमेंट बनाम इनहेरिटेंस" को "सी ++ फॉर गेम डेवलपर्स" से पसंद करता हूं जो युद्ध रोने की तरह नहीं लगता है और विषय पर प्रतिबिंबित करने को बढ़ावा देता है) एक सफल पैटर्न है लचीलेपन के कारण यह प्रदान करता है। हालांकि यह लचीलापन एक कीमत पर आता है। यदि आपके गेम में सब कुछ गेमऑब्जेक्ट है, तो आपको वास्तव में "खिलाड़ी" का संदर्भ नहीं मिल सकता है, क्योंकि कोई खिलाड़ी नहीं है, केवल एक गेमऑब्जेक्ट है जिसमें खिलाड़ी घटक संलग्न हो सकता है या नहीं (या बल्कि वे कई घटक जो बनाते हैं खिलाड़ी ऊपर)।
  यूनिटी डेवलपर्स ने एक ही समस्या देखी, कभी-कभी आप केवल एक बटन बनाना चाहते हैं, बटन घटक के साथ गेमऑब्जेक्ट नहीं। तो उन्होंने जो किया वह यह है: उन्होंने आपको संपादक इंटरफ़ेस के माध्यम से "एक बटन" बनाने की अनुमति दी है जो वास्तव में एक बटन घटक के साथ एक गेमऑब्जेक्ट बनाता है। इसके अलावा उन्होंने गेमऑब्जेक्ट के सबसे महत्वपूर्ण सदस्यों को प्रत्येक घटक के माध्यम से रूट किया, ताकि अब आप एक बटन के संदर्भ का उपयोग कर सकें जैसे आप गेमऑब्जेक्ट के संदर्भ का उपयोग करेंगे। आप बटन से उसकी स्थिति पूछ सकते हैं, आप उसके घटकों की सूची के लिए पूछ सकते हैं - भले ही बटन वास्तव में एक घटक है, न कि वह वस्तु जिससे वह जुड़ा हुआ है।
  तो अब हमारे पास खेल की दुनिया का वर्णन करने के दो सबसे लोकप्रिय तरीकों का मिश्रण है - रचना आधारित और सादे वस्तुओं में। लेकिन जब आप शुरुआती परियोजनाओं (और यहां तक ​​​​कि कुछ उन्नत परियोजनाओं) को देखते हैं, तो आप पाएंगे कि एकता खेल की दुनिया की व्याख्या करने के तीसरे तरीके की भी सुविधा प्रदान करती है: प्रक्रियात्मक प्रोग्रामिंग।
  एकता में हर वस्तु हमेशा एक "दृश्य" का हिस्सा होती है। गोडोट के विपरीत यह शब्द खेल के शीर्ष स्तर के हिस्से का वर्णन करता है (अस्वीकरण: अब एकता के पास एक दृश्य प्रबंधक है जो दृश्यों के शीर्ष पर बैठता है, लेकिन मेरी बात अभी भी मान्य है), जिसका अर्थ है कि यदि कोई दुश्मन खिलाड़ी पर गोली मारना चाहता है तो वह बस कर सकता है खिलाड़ी के लिए इसका वर्तमान दृश्य खोजें और इसके साथ बातचीत करें। यह प्रक्रियात्मक प्रोग्रामिंग का मूल विचार है - आपके पास आदेशों का एक क्रम है जो स्वामित्व की परवाह किए बिना पर्यावरण की स्थिति को बदल देता है। बेशक तकनीकी रूप से यह अभी भी ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग है, लेकिन जैसा कि प्रत्येक ऑब्जेक्ट एक ही दृश्य का हिस्सा होने की उम्मीद कर सकता है, आप कोड लिखने में सक्षम हैं जो वैश्विक कोड की तरह व्यवहार करता है। उदाहरण के लिए यदि आप किसी ऑब्जेक्ट को इंस्टेंट करना चाहते हैं तो आपको केवल "इंस्टेंटिएट (टेम्पलेटऑब्जेक्ट)" को कॉल करना होगा और टेम्प्लेटऑब्जेक्ट की एक कॉपी को इंस्टेंट किया जाएगा और सीन में जोड़ा जाएगा। यह पूछने की कोई आवश्यकता नहीं है कि किस दृश्य में वस्तु को जोड़ा जाए क्योंकि हमेशा एक ही दृश्य होता है जिसका वर्तमान में सब कुछ हिस्सा है।
  इसलिए एकता रचना, वस्तु उन्मुख सोच और प्रक्रियात्मक प्रोग्रामिंग के मिश्रण को बढ़ावा देती है।

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

तो इससे स्क्रिप्टिंग भाषाओं के चुनाव में क्या फर्क पड़ता है?
सी # भाषाओं के लिए है जो इंजनों के लिए एकता है। सी # का दर्शन हमेशा यह रहा है कि अगर कुछ फीचर अच्छा होगा तो इसे भाषा में जोड़ा जाएगा। प्रत्येक संस्करण के साथ जोड़ी गई सुविधाओं की सूची देखें: https://en.wikipedia.org/wiki/C_Sharp_ (programming_language)#Features_added_in_versions
अब आप यह तर्क दे सकते हैं कि कोई विशेषता होना कोई बुरी बात नहीं है, है ना? आपको इसका इस्तेमाल करने की ज़रूरत नहीं है, अगर आपको यह पसंद नहीं है तो इसे छोड़ दें। दुर्भाग्य से यह किसी भाषा के लिए सही नहीं है। इंटरनेट के महत्व के साथ आज भाषाएं उपकरण नहीं हैं, वे संस्कृतियां हैं। देर-सबेर आपको मदद के लिए गूगल करना होगा, आप दूसरों द्वारा बनाए गए मॉड्यूल या वस्तुओं का उपयोग करेंगे, आप इंजन में समुदाय द्वारा निर्मित नई सुविधाओं का उपयोग करेंगे, और देर-सबेर आपको उन भाषा सुविधाओं का उपयोग करने की आवश्यकता होगी जिनका आपने कभी इरादा नहीं किया था उपयोग करने के लिए।
इसके अलावा, यदि आप एक टीम में काम कर रहे हैं, तो आप एक ऐसी भाषा का उपयोग करके सराहना करना सीखेंगे जो एक सामान्य कोडिंग शैली को बढ़ावा देती है और आपको समान कोड लिखने के दर्जनों तरीके प्रदान नहीं करती है।

अब आप सोच रहे होंगे कि क्या मेरे कहने का मतलब यह है कि कम विशेषताओं वाली भाषा हमेशा अधिक विशेषताओं वाली भाषा से बेहतर होती है। बेशक ऐसा नहीं है। आइए तुलना करें कि जावा ने समस्या को कैसे हल किया।
सी # आपको अप्रबंधित कोड लिखने की अनुमति देता है। बस उपयुक्त कीवर्ड का उपयोग करें और आप इसे ठीक उसी फ़ाइल में उपयोग कर सकते हैं। यह आपको LINQ का उपयोग करके कार्यात्मक कोड लिखने की अनुमति देता है, जो SQL कोड की तरह पढ़ता है और कार्यात्मक कोड की तरह व्यवहार करता है। पूरी तरह से समझने के लिए कि कौन सी एक फ़ाइल को प्रोग्रामिंग प्रतिमानों के बारे में बहुत कुछ जानने की आवश्यकता हो सकती है।
यदि आप जावा लिख ​​रहे हैं तो आप कार्यात्मक प्रोग्रामिंग का भी उपयोग कर सकते हैं, आपको बस इसे एक अलग फ़ाइल में लिखना होगा, एक अलग कंपाइलर का उपयोग करना होगा और इसे "प्रोग्रामिंग क्लोजर" कहना होगा। यदि आप ऑब्जेक्ट-ओरिएंटेड और फंकिटोनल प्रोग्रामिंग को संयोजित करना पसंद करते हैं, तो आप इसे "प्रोग्रामिंग स्काला" कह सकते हैं। महत्वपूर्ण हिस्सा यह है कि आप अभी भी JVM के लिए कोड लिख रहे हैं जो अन्य JVM भाषाओं के कोड के साथ आसानी से इंटरैक्ट कर सकता है।
.NET-भाषाओं में समान क्षमता होती है, इसका उपयोग C#-दर्शन में नहीं किया जाता है। वे सी # में एक या दो प्रोग्रामिंग प्रतिमानों से चिपके रहने और नए प्रतिमान जोड़ने के लिए एक नई भाषा बनाने का फैसला कर सकते थे, लेकिन इसके बजाय वे "एक भाषा उन सभी को जीतने के लिए" के साथ गए - जो पूरी तरह से ठीक है, यह बहुत अच्छा है एक ऐसी भाषा। आपको बस उस दर्शन और एक प्रोग्रामर के रूप में आपके पास मौजूद विकल्पों के बारे में पता होना चाहिए।

लंबी कहानी छोटी: हमारे पास सभी भाषाओं में से मुझे लगता है कि सी # गोडोट के लिए सबसे खराब फिट है। यह एकता के लिए एक स्वाभाविक फिट है, लेकिन अगर आपके पास वे सभी विकल्प हैं तो ऐसी भाषा क्यों चुनें जो एक इंजन में प्रतिमानों के मिश्रण-और-मिलान को बढ़ावा देती है जो स्वच्छ ओओ-सिद्धांतों और किस-प्रोग्रामिंग को अपने हर हिस्से में बढ़ावा देती है?

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

@पति

GDscript में और अधिक सुविधाएँ जोड़ना मेरी राय में स्क्रिप्टिंग तक पहुँचने का बेहतर तरीका होगा

यह निश्चित रूप से हो सकता है, मुझे नहीं लगता कि यह अन्य प्रस्तावों के साथ असंगत है।

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

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

@Warlaan अच्छा विश्लेषण। यदि आप मेरी पोस्ट पढ़ते हैं, तो मैं भी गोडोट के लिए एक अच्छा पिक होने के साथ सी # से असहमत था, इसलिए मैंने पहले से मौजूद सी ++ क्षमताओं का विस्तार करने का प्रस्ताव रखा ताकि इसे एक स्क्रिप्टिंग भाषा के रूप में उपयोग करना संभव हो सके, जीडीस्क्रिप्ट अधिकांश उपयोगकर्ताओं के लिए डिफ़ॉल्ट भाषा शेष है।

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

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

@कागज-पापा मैं समझ गया था कि हम एक ही तरफ हैं। जब मैंने लिखा "यदि आपको लगता है कि सी # एक अच्छा जोड़ होगा" तो मैं व्यक्तिगत रूप से नहीं "आप, अज्ञात पाठक" को संबोधित कर रहा था। ;-)
और हाँ, कोई भी नई स्क्रिप्टिंग भाषा GDScript से ध्यान हटा देगी। मुझे संदेह है कि समुदाय एक से अधिक भाषाओं का ध्यान रखेगा, देर-सबेर कुछ विशेषताएँ अनुपलब्ध होंगी या उनमें से किसी एक से तोड़ी जा सकती हैं, यहाँ तक कि यहाँ तक कि किसी एक भाषा को छोड़ भी दिया जा सकता है।

मैं यह भी मानता हूं कि यहां केवल वास्तविक मुद्दे सी ++ के संकलन समय और जीडीस्क्रिप्ट के प्रदर्शन हैं।
तर्क है कि लोग पहले से ही सी # जानते थे, यह सिर्फ सादा गलत इम्हो है। मैं लगभग 4 वर्षों से C# के साथ पेशेवर रूप से काम कर रहा हूं (मुख्य रूप से C++ और SQL के साथ काम कर रहा हूं) और एक चीज जो मैंने उस समय सीखी है, वह यह है कि मैं कभी भी यह नहीं कह पाऊंगा कि मैं वास्तव में उस भाषा को जानता हूं। आखिरकार सी # 6 और 7 के प्रस्तावों के साथ सुविधाओं की संख्या अभी भी बढ़ रही है।
इसलिए जब हम "सी # को जानने" के बारे में बात कर रहे हैं, तो हम वास्तव में सबसे बुनियादी सिंटैक्स को जान सकते हैं, जो कि सबसे खराब शुरुआत करने वाले को भी कुछ दिनों में फिर से सीखने में सक्षम होना चाहिए। मैंने हाल ही में गेम डिजाइनरों के एक वर्ग के लिए अलग-अलग गेम इंजनों पर एक व्याख्यान आयोजित किया था जो पहले विशेष रूप से एकता का उपयोग कर रहे थे और उनमें से किसी ने भी जीडीस्क्रिप्ट के सिंटैक्स पर बुरी तरह से टिप्पणी नहीं की थी, जबकि वास्तव में कई लोग जिन्होंने प्रोग्रामिंग को छोड़ दिया था, अब फिर से प्रेरित हैं।

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

बहुत से लोग जो सी # को "जानते हैं" इसकी कई विशेषताओं का उपयोग नहीं करते हैं जो इसे जावा से अलग बनाते हैं। बस एकता की असंख्य लिपियों पर एक नज़र डालें जो उपवर्गों से बहुत दूर नहीं जाती हैं।

अकेले इस कारण से, मुझे सी # के व्यावहारिक लाभों के बारे में अत्यधिक संदेह है। वे कई संदर्भों में अच्छे हैं, सिर्फ खेल विकास नहीं। इसके अलावा, C++ 1x पहले से ही उन चीजों में से कई (प्रकार के अनुमान, इटरेटर और कुछ बुनियादी कार्यात्मक उपकरण सहित) बिना किसी ओवरहेड के प्रदान करता है।

साथ ही, यह भी संभव है कि सीएलआर (या यहां तक ​​कि जेवीएम) द्वारा लाया गया ओवरहेड गोडोट को _बदतर_ प्रदर्शन कर सके, हालांकि मुझे जेवीएम के कचरा संग्रहकर्ता का उपयोग करने में कुछ फायदे दिखाई देते हैं (क्या कोई गोडोट के मेमोरी प्रबंधन के बारे में अधिक जानता है)?

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

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

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

यह करना बहुत आसान होना चाहिए (libdl के माध्यम से?) लेकिन जहां तक ​​​​मुझे समझ में आया कि यह क्रॉस-प्लेटफ़ॉर्म चिंताओं के कारण नहीं किया गया है।

इसके अलावा, जीडीस्क्रिप्ट को सी ++ में संकलित करने का विचार है, जैसा कि ENIGMA अपनी भाषा के साथ करता है। यह आसान नहीं है, लेकिन स्पष्ट रूप से सर्वश्रेष्ठ प्रदर्शन प्रदान करता है।

क्या कोई गोडोट के स्मृति प्रबंधन के बारे में अधिक जानता है?

डॉक्स से:

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

बस ध्यान दें...

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

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

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

बस एक सवाल, GDscript दुभाषिया आंतरिक रूप से कैसे काम करता है? पुरानी मूल भाषा की तरह रनटाइम पर प्रत्येक पंक्ति को पार्स करें या क्या यह पूरी स्क्रिप्ट को बाइटकोड टेबल में परिवर्तित करता है और फिर बाइटकोड चलाता है?

@RebelliousX

https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_compiler.cpp
https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_parser.cpp

मुझे नहीं लगता कि कोई भी गंभीर भाषा है जो अब बेसिक की तरह काम करती है! :)

नमस्ते!
यहाँ GDScript का इतिहास है:
/////////////////////////
इतिहास
प्रारंभ में, गोडोट को कई स्क्रिप्टिंग भाषाओं का समर्थन करने के लिए डिज़ाइन किया गया था (यह क्षमता आज भी मौजूद है)। हालाँकि, अभी केवल GDScript उपयोग में है। इसके पीछे थोड़ा इतिहास है।

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

शिप किए गए खेलों के लिए उपयोग की जाने वाली अंतिम तृतीय पक्ष स्क्रिप्टिंग भाषा गिलहरी थी, लेकिन इसे भी हटा दिया गया था। उस समय, यह स्पष्ट हो गया कि गोडोट एक अंतर्निहित स्क्रिप्टिंग भाषा का उपयोग करके अधिक बेहतर ढंग से काम करेगा, क्योंकि निम्नलिखित बाधाओं को पूरा किया गया था:

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

अंत में, GDScript को एक कस्टम समाधान के रूप में लिखा गया था। इसके लिए भाषा और दुभाषिया लुआ और गिलहरी के लिए बाध्यकारी कोड से छोटा और समान रूप से कार्यात्मक होने के रूप में समाप्त हो गया। समय के साथ, एक अंतर्निहित भाषा का होना एक बहुत बड़ा लाभ साबित हुआ है
////////////////////////

मेरी राय में, सी ++ सबसे अच्छा हो सकता है। कुछ समाधान हैं जैसे:
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
यहां तक ​​​​कि एंजेल स्क्रिप्ट भी आमतौर पर संकलित रनटाइम की तरह हो सकती है।
स्क्रिप्टिंग में, मुझे अजगर पसंद है क्योंकि मुझे हमेशा ऐसे समाधान पसंद हैं जो खेल और वैज्ञानिक सिमुलेशन को मिलाते हैं (पायथन में कई वैज्ञानिक पुस्तकालय हैं)। तो मैं शिकायत करता हूँ! एक अन्य मुद्दे में गोडोट की अपनी भौतिकी पुस्तकालय क्यों है: https://github.com/godotengine/godot/issues/4217
C# जैसी भाषाओं के बारे में कुछ समस्याएँ हैं: https://github.com/godotengine/godot/issues/2790

अच्छा खोज, @ alabd14313 - जो कि ज्यादातर मुद्दों को हल करेगा, जबकि GDScript को अकेला छोड़ देगा।

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

ऐसा लगता है कि लेखक अपनी सामग्री जानते हैं, क्योंकि इस पृष्ठ में उन्होंने अपने दृष्टिकोण के लिए सबसे अधिक विकल्प सूचीबद्ध किए हैं (जिसमें मैंने उल्लेख किया है, एलएलवीएम जेआईटी)।

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

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

@Warlaan इस यूआरएल को फेसबुक ग्रुप पर पोस्ट करने से क्या होगा? :)

कृपया शीर्षक को "सी ++ स्क्रिप्टिंग भाषा के रूप में" जैसे कुछ में बदलें।
C++17 में अधिक विशेषताएं हैं:
http://blog.mattnewport.com/why-c17-is-the-new-programming-language-for-games-i-want/
मैं गोडोट डेवलपर्स की प्रशंसा करता हूं और उनके कार्यों के लिए उन्हें धन्यवाद देता हूं। लेकिन मैं Box2D/LiquidFun/Bullet पुस्तकालयों पर विरोध करता हूं। इस तरह डेवलपर्स पाइपलाइन पर ध्यान केंद्रित कर सकते हैं, भौतिकी जैसे घटकों पर नहीं। सी ++ के साथ वे प्रदर्शन पर ध्यान केंद्रित कर सकते हैं, जीडीस्क्रिप्ट को बनाए रखने और अपडेट करने पर नहीं। सैद्धांतिक रूप से RCCPP टूल मोड जैसी कुछ नई सुविधाओं को बेहतर तरीके से लागू कर सकता है। शायद...

@reduz ने कुछ महीने पहले उल्लेख किया था कि वह दृश्य स्क्रिप्टिंग को लागू करना चाहते हैं, कुछ अवास्तविक ब्लूप्रिंट की तरह। RCCPP के साथ C++ (प्रोग्रामर के लिए) और विजुअलस्क्रिप्टिंग (स्तर के डिजाइनरों और कलाकारों के लिए) के बीच कार्यप्रवाह को इस प्रकार कार्यान्वित किया जा सकता है:
UE4 में C++ प्रोग्रामिंग का परिचय
सी++ और ब्लूप्रिंट
इसलिए एक समूह में, प्रोग्रामर कलाकारों के लिए नई ब्लूप्रिंट कक्षाएं विकसित कर सकते हैं और कलाकार सीधे कोडिंग के बजाय इनका उपयोग करते हैं।

@Warlaan IMHO ऐसा इसलिए है क्योंकि बहुत सी सी # बात उन लोगों द्वारा की गई थी जो चाहते हैं कि गोडोट एकता रिपॉफ हो, लेकिन सौभाग्य से यहां कई लोग महसूस करते हैं कि गोडोट अपनी चीज है और पहले से ही कई मामलों में एकता से आगे है और यह उचित नहीं होगा इसे उन्हीं मुद्दों से प्रभावित होने दें।

@ alabd14313 मैं शीर्षक बदल दूंगा लेकिन शायद एक अलग मुद्दा बनाना और इसे भावी पीढ़ी के लिए रखना बेहतर है ताकि जब कोई सी # का प्रस्ताव दे तो इसे जोड़ा जा सके (जैसा कि अक्सर होता है)।

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

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

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

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

और कृपया प्रवाह ग्राफ के बारे में बात न करें जैसे कि वे कोडिंग नहीं कर रहे थे। वे किसी भी अन्य प्रोग्रामिंग भाषा की तरह ही उतनी ही कोडिंग कर रहे हैं। वे टाइप नहीं कर रहे हैं, बस।

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

@Warlaan ठीक है, यह इस बात पर निर्भर करता है कि आप "प्रोग्रामिंग" को कैसे परिभाषित करते हैं। निश्चित रूप से दृश्य स्क्रिप्टिंग एल्गोरिदम को परिभाषित करने के समान है, इसलिए यह प्रोग्रामिंग से बहुत दूर नहीं है, लेकिन प्रोग्रामिंग अन्य चीजों के बारे में भी है।

हालाँकि, दृश्य प्रोग्रामिंग के कुछ अच्छे कार्यान्वयन हैं। PureData एक है और GDevelop भी है, एक बहुत अच्छा FLOSS गेम मेकिंग प्रोग्राम (शर्म की बात है कि यह अधिक लोकप्रिय नहीं है)। संक्षेप में, भले ही मैं इसे व्यक्तिगत रूप से पसंद नहीं करता (कुछ कारणों से आपने उल्लेख किया है), यह भी सच है कि हम दोनों प्रोग्राम कर सकते हैं, इसलिए हमारे लिए विज़ुअल प्रोग्रामिंग तुलनात्मक रूप से खराब परिणाम प्राप्त करने के लिए एक धीमी और बोझिल है।

फिर भी, मैं @reduz से सहमत

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

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

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

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

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

सी ++ की एक और उपयोगी विशेषता यह है कि यह स्थिर रूप से प्रकार है। "ऑटो" और "डिक्लेटाइप" सुविधाएं किसी वस्तु के प्रकार का पता लगा सकती हैं। संपादक और कोड पूरा करना आसान हो सकता है। आंतरिक कोड संपादक पर ध्यान केंद्रित करने के बजाय, हम किसी अन्य बाहरी IDE का उपयोग कर सकते हैं। अभी के लिए मुझे लगता है कि कोड पूरा करने में कोडलाइट और क्यूटीक्रिएटर की स्थिति बेहतर है। कोडब्लॉक में c++11 कीवर्ड के साथ कुछ समस्याएं हैं। इसके अलावा ग्रहण-सीडीटी का एक अच्छा कोड पूरा होना है। qtcreator के लिए एक प्लगइन एक अच्छा विचार है (जैसे अवास्तविक-दृश्य स्टूडियो और यूनिटी-मोनोडेवलप)। बाहरी आईडीई को गोडोट सेटिंग्स (जैसे / उपयोग / बिन / क्यूटीक्रिएटर) में सिस्टम पथ के साथ पहचाना जा सकता है, गोडोट के साथ संकलित और पैक करने की कोई आवश्यकता नहीं है (एकता पैकेज के विपरीत मोनोडेवलप बनाया गया है)।
cppcheck और valgrind जैसे अन्य टूल हैं जिनमें qtcreator में प्लगइन्स हैं।
यदि आप RCCPP क्या है इसका पूर्वावलोकन करना चाहते हैं:
डेमो

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

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

मेरे 3 सेंट। (उह ... यह 20 समाप्त हो गया, लेकिन रहने दो ...)

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

इसमें सभी आवश्यक टुकड़े हैं।

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

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

वास्तव में एक क्लिक के साथ कई प्लेटफार्मों पर तैनाती (वाईफाई/एडीबी, जीवन संपादन, डिबगिंग, ect पर एंड्रॉइड पर इन्हें तैनात करने का उल्लेख नहीं करना कला का एक उत्कृष्ट कृति है, नहीं ... यह और भी, यह एक जादू है!)

इसके अतिरिक्त ब्लेंडर ect जैसे आमतौर पर उपयोग किए जाने वाले टूल के साथ ये सभी परिचित।
(आयात सामान और यह बॉक्स से बाहर काम करता है, सब कुछ कहां और कैसे होना चाहिए)

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

इसमें लगभग सब कुछ है, और समय के साथ, मुझे विश्वास है कि यह सब कुछ होगा।
(मतलब, जो चीजें आज "अभी तक लागू नहीं हुई हैं" और किसी को इसे 'किसी तरह' या 'नंगे हाथ' करना है (पढ़ें: इसके लिए बाहरी उपकरण का उपयोग करें) जैसे। 3D रिग्ड को आसान तरीके से समायोजित करें (ब्लेंडर का उपयोग करना होगा) )

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

विजुअल स्क्रिप्टिंग?
उह। यह हमें कोडर्स को असामान्य तरीके से "थोड़ा" सोचने के तरीके को बदलने के लिए मजबूर कर सकता है, साथ ही मुझे विश्वास नहीं है कि यह सामान्य कोड के रूप में लचीला और पठनीय हो सकता है।
कल्पना कीजिए कि आप कोडिंग करते हैं और इस तरह की सरल एक पंक्ति है ( abc / def ) * ghi
फिर तेज़ तरीका, हमेशा की तरह (?) टाइपिंग को बचाने के लिए, आप कुछ का हिस्सा चिह्नित करते हैं, यहां पेस्ट करते हैं, वहां काटते हैं, फिर से पेस्ट करते हैं और 5 सेकंड में और कुछ कीप्रेस, "सरल" के साथ समाप्त होते हैं (क्योंकि आप जानते हैं कि यह क्या करता है) एक लाइनर जैसे ((((abc/def+((abc/def)_ghi^4))_ghi)+(abc/def_(100))_ghi)+abc)
यह आम बात है, शायद हम में से कई लोग इसे इस तरह से सुपर फास्ट तरीके से करते हैं।
अब इसे विजुअल तरीके से करने की कल्पना करें ...
यह पूरी स्क्रीन ले सकता है, बहुत सारे माउस काम कर सकता है, और यह उतना पठनीय नहीं लगेगा जितना चाहिए।
(बेशक, इस तरह के एक लाइनर भी एक साल बाद आसान नहीं लगते हैं, लेकिन टिप्पणियों के लिए यही है)

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

तो किसके लिए वास्तव में विजुअल स्क्रिप्टिंग होगी?
कोडर्स के जीवन को कठिन बनाने के लिए या शुरुआती लोगों के लिए "सरल गेम" के लिए गोडोट को स्तर-इंजन तक सीमित करने के लिए?

लोग, #1220 में Visual Scripting के बारे में एक लंबी चर्चा है। आइए कृपया यहां उन्हीं विषयों पर फिर से चर्चा न करें।

लोग, #1220 में Visual Scripting के बारे में एक लंबी चर्चा है। आइए कृपया यहां उन्हीं विषयों पर फिर से चर्चा न करें।

यहाँ अधिकांश पोस्ट इतने लंबे थे, शायद पढ़ते-पढ़ते मैं खुद को खो बैठा।
क्षमा करें: आराम से:

@RebelliousX यहां तक ​​​​कि RTTI के साथ, C ++ में अभी भी GDScript की तुलना में बेहतर प्रदर्शन होगा। हालांकि यह सच है कि टेम्प्लेट एक समस्या हो सकती है।

#3936 में @reduz द्वारा प्रस्तावित समाधान पहले से ही C++ में कोडिंग को काफी तुच्छ बना देगा - आप इसे अपने संपादक और पसंद के कंपाइलर के साथ करें और गोडोट के एपीआई के खिलाफ लिंक करें। यदि इसे लागू किया जाता है, भले ही C++ में स्क्रिप्टिंग अच्छी हो, यह C++ में कोड लिखने और फिर प्रदर्शन के संदर्भ में इसे GDScript से कॉल करने से बहुत अलग नहीं होगा। संक्षेप में, मुझे लगता है कि #3936 (जो एक सरल उपाय है) पर ध्यान केंद्रित करने से काफी सुधार होगा:

• प्रदर्शन (चूंकि सी ++ में भागों को लिखना बेहद आसान होगा)
• तीसरे पक्ष के पुस्तकालयों की उपलब्धता (चूंकि रैपर अधिक आसानी से वितरित किए जा सकते हैं, लेकिन #3943 जितनी आसानी से नहीं)
• यूजरबेस और योगदानकर्ता (कई सी ++ प्रोग्रामर गोडोट को अपनाएंगे)

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

मैं केवल कुछ बिंदुओं का उल्लेख करना चाहता हूं जो इस चर्चा में फंस गए हैं लेकिन अभी तक संबोधित नहीं किए गए हैं:

• हम में से कुछ मौजूदा सिस्टम (जीडीस्क्रिप्ट को एक स्क्रिप्टिंग भाषा के रूप में, सी ++ को बैकएंड भाषा के रूप में) में सुधार करने के बारे में बात कर रहे हैं, सी ++ विकास को सुविधाजनक बनाने और जीडीस्क्रिप्ट प्रदर्शन को बढ़ाकर। अन्य एक स्क्रिप्टिंग भाषा के रूप में C++ (या Java/C#/...) का उपयोग करने के बारे में बात कर रहे हैं। ऐसा लग सकता है कि तेजी से सी ++ विकास को सक्षम करने और इसे एक स्क्रिप्टिंग भाषा बनाने के बीच कोई वास्तविक अंतर नहीं है, लेकिन मैं खुशी से समझाऊंगा कि मैंने गेम डिज़ाइन की गुणवत्ता पर शक्तिशाली स्क्रिप्टिंग भाषाओं के नकारात्मक प्रभाव का अनुभव और अवलोकन कैसे किया है। और जब तक यह चर्चा का विषय नहीं बन जाता, तब तक मैं इसे मंचों पर या किसी अन्य जगह पर खुशी-खुशी करूँगा जहाँ यह इस धागे को हाईजैक नहीं करता है।
• @RebelliousX : जब आप "वेरिएबल नेमस्पेस", "बड़ी स्क्रिप्ट" और "फ़ंक्शंस के बीच चर साझा करना" के बारे में बात करते हैं तो ऐसा लगता है कि आपने जीडीस्क्रिप्ट (कोई अपराध नहीं) की वस्तु उन्मुख प्रकृति को पूरी तरह से समझ नहीं लिया है। प्रत्येक GDScript फ़ाइल एक वर्ग है, इसलिए (सदस्य) चरों के बीच नाम का टकराव ठीक उसी तरह होना चाहिए जैसा कि किसी अन्य वस्तु उन्मुख भाषा में होता है। आप स्क्रिप्ट के बीच चर साझा नहीं कर रहे हैं, आप कई फ़ंक्शन लिख रहे हैं जो शामिल वस्तु की स्थिति तक पहुंच सकते हैं।

@Warlaan पहले बिंदु के बारे में, मुझे लगता है कि आप यहां पोस्ट कर सकते हैं, क्योंकि यह विषय से संबंधित है।

@Warlaan कोई अपराध नहीं लिया। मुझे पता है कि जीडीस्क्रिप्ट स्वयं का एक वर्ग है और मुझे पता है कि चर सी ++ कक्षा में सामान्य सदस्य चर की तरह हैं, लेकिन ऐसा लगता है कि आपने मेरी बात को पूरी तरह से याद किया। आप इसे तब समझेंगे जब आपके पास कोड की 1000 से अधिक पंक्तियों वाली स्क्रिप्ट होगी। मैं जो चाहता हूं वह संदर्भ या पॉइंटर्स है, सदस्य चर के असंख्य बनाने के बजाय, बस उन्हें सदस्य कार्यों के बीच पास करें। ऐसे में यह ज्यादा सुरक्षित है।

मुझे सी # पसंद है, लेकिन मुझे पेशेवर और विपक्ष दिखाई देते हैं।

पेशेवरों:

• अच्छा टूलींग समर्थन (आइए इसका सामना करते हैं, क्या आप विजुअल स्टूडियो या मोनो डेवलपमेंट के बिना सी # में कोड करेंगे?)
• बड़े पैमाने पर परियोजनाओं के लिए उपयुक्त
• व्यापक रूप से उपयोग और परिपक्व, इंटरनेट पर बहुत सारे समर्थन सूत्र हैं।
• अच्छा प्रदर्शन, क्रॉस-प्लेटफ़ॉर्म होने के दौरान C++ और स्क्रिप्टिंग भाषाओं के बीच ट्रेडऑफ़
• C++ से जुड़ना अपेक्षाकृत आसान है

दोष:

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

इसमें से अधिकांश जावा पर भी लागू होता है।
शायद मैं अन्य बातें भूल गया क्योंकि यहाँ देर हो चुकी है।

ठीक है, फीचर-समृद्ध स्क्रिप्टिंग भाषाओं के संबंध में यह मेरा अनुभव है। "स्क्रिप्टिंग भाषा" की आपकी परिभाषा के आधार पर एक स्क्रिप्टिंग भाषा का पूर्ण अभाव। मैं इसे छोटा रखने की कोशिश करूंगा। ;-)

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

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

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

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

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

अब यह तथ्य कि गेम डिज़ाइन के छात्र इस तरह के विषयों में गोता लगाते हैं, मेरी बात का एक अस्पष्ट संकेत हो सकता है, लेकिन मुझे लगता है कि मैं एक बड़े F2P MMO डेवलपर में अपनी पहली नौकरी की स्थिति के बारे में बात करके इसे और भी बेहतर तरीके से समझा सकता हूँ। मैं जिस टीम में शामिल हुआ वह जर्मनी के सबसे अनुभवी गेम डेवलपर्स में से एक है। उनके विकास के प्रमुख 1995 से अपने स्वयं के इन-हाउस इंजन बना रहे हैं और भले ही उन्हें किसी अन्य कंपनी द्वारा खरीदा गया था, फिर भी वे उस समय के सबसे सफल डेवलपर्स में से एक थे।
जब तक मैं टीम में शामिल हुआ, वे इन-हाउस इंजन के तीसरे संस्करण का उपयोग कर रहे थे, जिसमें स्क्रिप्टिंग भाषा नहीं थी। उन्होंने पहले एक को लागू किया था, लेकिन इंजन के उस संस्करण में वे वापस लौट आए क्योंकि उनके पास कोई स्क्रिप्टिंग भाषा नहीं थी क्योंकि गेम डिज़ाइनरों द्वारा वितरित कोड गुणवत्ता के साथ समस्याएँ थीं। दूसरे शब्दों में चूंकि स्क्रिप्टिंग भाषा बहुत शक्तिशाली थी, इसलिए प्रोग्रामर और गेम डिजाइनरों के बीच की बाधा को उस बिंदु पर स्थानांतरित करने का निर्णय लिया गया था जहां गेम डिजाइनर केवल स्तरों को संपादित करेंगे और कॉन्फ़िगरेशन शीट्स में सेटिंग्स बदलेंगे, जबकि प्रोग्रामर ने सभी प्रोग्रामिंग की थी - पूर्वव्यापी I में ध्यान दिया कि यह लगभग वही स्थिति है जिसमें मेरे छात्र समाप्त होते हैं (और ऐसा लगता है कि कई पेशेवर स्टूडियो एकता के साथ काम कर रहे हैं)।
अब मैं क्यों परवाह करूं? अगर ऐसा बार-बार हो रहा है तो क्या यह साबित नहीं होता कि यह काम करने का एक सफल तरीका है? मेरा जवाब नहीं है, क्योंकि तकनीकी और गेम डिज़ाइन दोनों में समस्याएं थीं, जिन्हें आसानी से इस तथ्य से समझाया जा सकता है कि प्रोग्रामर और गेम डिजाइनरों के बीच संचार एक दिशा में कार्यों को लिखने और दूसरे में सेटिंग्स को उजागर करने के लिए कम हो गया था। गेम डिज़ाइनरों के दृष्टिकोण से सुविधाएँ ब्लैक बॉक्स बन गईं जिन्हें सक्षम और अक्षम किया जा सकता था, लेकिन टीम के उस तरफ कोई भी नहीं था जो चर्चा कर सकता था या यहां तक ​​​​कि प्रोटोटाइप विकल्पों पर भी चर्चा कर सकता था।
दूसरी ओर प्रोग्रामर्स को लगभग स्वाभाविक रूप से बैकएंड मानसिकता में धकेल दिया गया था। "त्वरित और गंदी" KISS मानसिकता चली गई थी, क्योंकि हममें से कोई भी यह भविष्यवाणी नहीं कर सकता था कि हमने जो सुविधाएँ बनाई हैं उनका उपयोग कैसे किया जाएगा। मुझे स्पष्ट रूप से याद है कि एक बार डेटाबेस कैसे टूट गया क्योंकि एक गेम डिजाइनर ने ईस्टर अंडे के शिकार को लागू किया था, जिससे इन्वेंट्री पहले की तुलना में बहुत बड़ी हो गई थी। यह आखिरी बार था जब मैंने यह मान लिया था कि किसी सुविधा की आवश्यकताएं शायद उसी के बारे में रहेंगी।

इसलिए मुझे लगता है कि गेम कोड के लिए परिभाषित क्षेत्र के रूप में एक कम-सुविधा वाली स्क्रिप्टिंग भाषा का होना अत्यंत महत्वपूर्ण है और मुझे क्यों लगता है कि इसके न होने से गेम डिज़ाइन पर बुरा प्रभाव पड़ता है।

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

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

वैसे मैं गोडोट में इतना शामिल होने का कारण यह है कि मैं इसे पहले सेमेस्टर के लिए अनिवार्य इंजन के रूप में स्थापित करने पर काम कर रहा हूं। इतना ही कि आप जानते हैं कि मैं सिर्फ बात नहीं कर रहा हूं बल्कि अपने परिणाम भी निकाल रहा हूं। ;-)

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

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

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

यह विषय C# (या Java) मॉड्यूल समर्थन जोड़ने के बारे में है, लेकिन मुझे कोई उदाहरण कोड नहीं दिख रहा है। चलो मक्खी पर कुछ कोशिश करते हैं :)

using GodotEngine;

// Inherit a node type
public class Spikeball : RigidBody2D {

    // Exported variables
    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

    // Notice the naming convention. Should Godot API follow languages or should languages follow Godot?

    void _Ready() {
        SetProcess(true);
        // Should we use the generic system?
        Connect("BodyEnter", this, "_OnBodyEnter")
        // Or use C# features?
        this.bodyEnterEvent += _OnBodyEnter;
    }

    void _Process(delta) {
        var sprite = (Sprite)GetNode("Sprite");
        sprite.SetRot(sprite.GetRot() + delta*rotationSpeed);
        // Or we can have properties
        sprite.rot = sprite.rot + delta*rotationSpeed;
    }

    public void _OnBodyEnter(PhysicsBody2D body) {
        // We cannot invent C# members on the fly, so we can do this if the other script is in C# too.
        // ScriptInstance GetScript();
        var health = body.GetScriptInstance() as IHaveHealth;
        if(health != null) {
            health.TakeDamage(damage);
        }
        // But what if the other is GDScript?

        // A generic approach would look like this, a bit like SendMessage in Unity3D
        // object Call(string funcname, object arg1, ...); // where object can be seen as Variant
        body.GetScriptInstance().Call("TakeDamage", damage);

        // Same thing if we want to get a script variable
        var category = (string)body.GetScriptInstance().Get("category")
        Console.Print(category);
    }

}

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

@Warlaan अपना अनुभव साझा करने के लिए धन्यवाद। अगर मुझे यह गलत लगता है तो मुझे सुधारें (यह एक लंबी पोस्ट थी), लेकिन क्या आप कह रहे हैं कि प्रोग्रामर के लिए कम सुविधाओं वाली भाषा की पेशकश करना बेहतर है, ताकि वे ओवरकोडिंग के बजाय अपने गेम को विकसित करने पर ध्यान केंद्रित कर सकें?

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

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

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

मुझे लगता है कि जो लोग सी # चाहते हैं वे गलत हैं, लेकिन मेरी राय में एक अच्छा समझौता यह होगा:

1) बेहतर प्रदर्शन (स्थिर टाइपिंग, शायद एक JIT)
2) तीसरे पक्ष के पुस्तकालयों के लिए बेहतर समर्थन (एफएफआई और आसान सी ++ एकीकरण के माध्यम से)

जीडीस्क्रिप्ट के लिए। बाकी सी ++ में किया जा सकता है, जिसमें अन्य स्क्रिप्टिंग भाषाओं को लागू करने वाले मॉड्यूल लिखना शामिल है (जिसे प्रथम-पक्ष होने की आवश्यकता नहीं है - हर कोई सी # मॉड्यूल लिख सकता है, अगर वे चाहें)।

@Zylann मुझे समकक्ष सी ++ के बजाय उस कोड को लिखने में कोई फायदा नहीं दिखता है, ईमानदारी से, और सी ++ कोड का बेहतर प्रदर्शन होगा।

@ पेपर-पापर इस कोड को लिखने का लाभ जीडीस्क्रिप्ट जैसा ही है: आपको हर उस प्लेटफॉर्म के लिए इंजन को फिर से संकलित करने की आवश्यकता नहीं है जिसे आप निर्यात करना चाहते हैं, और ... ठीक है, आपको भाषा का विकल्प मिलता है (और प्रदर्शन है केवल एक बिंदु नहीं, जैसा कि मैंने पहले उल्लेख किया है)। मैं सहमत हूं कि वर्तमान में, GDScript का अनुभव बेहतर है, और शुद्ध प्रदर्शन के लिए C++ सबसे अच्छा विकल्प है। लेकिन, ऐसे लोग हैं जो सी ++ नहीं करना चाहते हैं, चाहे वह कुछ भी अच्छा हो।
मुझे व्यक्तिगत रूप से गोडोट+सी# में कोई दिलचस्पी नहीं है, बस यह मूल्यांकन करना है कि अगर आप इसे गोडोट में जोड़ते हैं तो क्या होगा। और यह इतना सीधा नहीं है :p

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

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

मुझे टाइपस्क्रिप्ट पसंद है, लेकिन मुझे ऐसी जटिलता जोड़ने की बात नहीं दिखती। अगर कोई ऐसा करता है, तो उन्हें TS के नए संस्करणों के अनुकूल होने के लिए इसे बनाए रखना होगा। साथ ही, TS JS का सुपरसेट है, तो क्या यह JS को GDScript में ट्रांसपाइल कर पाएगा? और फिर, हमारे पास ट्रांसपिलर में बग वाले कुछ लोग होंगे जो यह सोचेंगे कि यह इंजन में एक बग है।

मुझे अभी भी लगता है कि एक बेहतर विचार है कि एक स्थिर संस्करण जीडीस्क्रिप्ट हो जो जेआईटी पर अधिक आसानी से सहारा ले सके और फिर भी इंजन और वर्तमान जीडीस्क्रिप्ट के साथ निकटता से संबंधित हो।

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

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

@vnen

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

ओह, मैं 100% सहमत हूँ - वास्तव में मैंने #3936 में भी ऐसा ही विचार व्यक्त किया था। मैं इसे वहां फेंक रहा था क्योंकि हमने सी # के रनटाइम को एक कमी के रूप में उल्लेख किया था :)

मेरे लिए, @Zylann द्वारा वह उदाहरण C# मॉड्यूल प्यारा है, मैं अभी यूनिटी से स्विच करूंगा यदि वह उपलब्ध था - यह C ++ के उच्च प्रदर्शन या GDScript की 'आसानता' के बारे में नहीं है, यह आरामदायक होने के बारे में है।

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

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

डेवलपर्स को आराम से लिखने की अनुमति देने से क्या खो जाएगा? मुझे मोनो या लिंक की तरह फैंसी की अधिकता की आवश्यकता नहीं है, मैं बस अपना कोड लिखते समय सहज रहना चाहता हूं।
मैं GDScript के लिए C#-जैसे सिंटैक्स के लिए समझौता करूंगा, कम से कम घुंघराले कोष्ठक, अर्ध-कॉलन और स्पष्ट प्रकारों का उपयोग करने का विकल्प - मैं व्यक्तिगत रूप से निहित प्रकार नहीं खड़ा कर सकता, वे मुझे पागल कर देते हैं।
मुझे लगता है कि गेममेकर विभिन्न जनसांख्यिकी को समायोजित करने के लिए सिंटैक्स में बदलाव की अनुमति देता है।

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

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

@पिकल :

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

GDScript के बारे में बात सिंटैक्स (जो पाइथोनेस्क है) के बारे में ज्यादा नहीं है, लेकिन यह इंजन के साथ कितना एकीकृत है, इसके बारे में अधिक है। यह पांडित्यपूर्ण लग सकता है, लेकिन किसी अन्य सिस्टम में जाने पर सिंटैक्स कम से कम चिंता का विषय है। जो सबसे ज्यादा मायने रखता है वह है एपीआई। यहां तक ​​कि अगर हमने अभी सी# जोड़ा है, तो आप शायद नए प्रतिमान से असहज महसूस करेंगे, क्योंकि जिस तरह से आप इसे एकता में करते हैं, वैसे ही आप गोडोट में नहीं करते हैं।

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

यह कहना नहीं है कि सी # नहीं हो रहा है (हो सकता है कि यह संभव हो और इंजन के हित में हो), यह सिर्फ इतना है कि ये तर्क कई अन्य भाषाओं और इंजनों पर भी लागू होंगे।

@Pikl सबसे पहले C# के पक्ष में पहला तर्क देने के लिए धन्यवाद। अब मैं समझाता हूं कि मुझे क्यों लगता है कि आपकी राय अमान्य है। ;-पी

आइए Zylann द्वारा कोड उदाहरण की शुरुआत पर करीब से नज़र डालें:

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

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

आगे हमारे पास है
public class Spikeball : RigidBody2D {
GDScript में सब कुछ सार्वजनिक है तो इसका उल्लेख क्यों करें?
class Spikeball : RigidBody2D {
प्रत्येक GDScript फ़ाइल में स्क्रिप्ट के समान नाम वाला एक वर्ग होता है। यह सिर्फ अन्य भाषाओं की तरह एक कोडिंग सम्मेलन नहीं है, इसे इस तरह परिभाषित किया गया है, तो कक्षा के नाम को दोहराने का क्या मतलब है?
: RigidBody2D {
अब चूंकि : इस पंक्ति में एकमात्र अर्थपूर्ण "कीवर्ड" है, आइए इसे कुछ अधिक पठनीय के साथ बदलें।
extends RigidBody2D {
थोड़ा सा अनुभव वाला कोई भी कोडर कोड के विभिन्न क्षेत्रों को चिह्नित करने के लिए इंडेंटेशन का उपयोग करेगा। इसका मतलब है कि कक्षा के अंदर के कोड को आसपास के ब्रेसिज़ और इंडेंटेशन द्वारा पहचाना जा सकता है, यही वजह है कि पायथन के डेवलपर्स ने इंडेंटेशन को अनिवार्य बनाने और अब बेमानी ब्रेसिज़ से छुटकारा पाने का फैसला किया।
हमारे मामले में वर्ग स्तर पर इंडेंटेशन भी आवश्यक नहीं है क्योंकि प्रत्येक स्क्रिप्ट फ़ाइल को एक वर्ग के रूप में परिभाषित किया गया है (जब तक कि आप उपवर्गों का उपयोग नहीं कर रहे हैं जो इंडेंटेशन द्वारा चिह्नित हैं)।
extends RigidBody2D

आगे हमारे पास निर्यात लाइनें हैं।

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

[]-कैरेक्टर उन विशेषताओं को चिह्नित करते हैं जो एक ही नाम के वर्गों में परिभाषित हैं, जो एक ऐसा तंत्र है जो गोडोट में मौजूद नहीं है, इसलिए यह केवल इसके बजाय कीवर्ड का उपयोग करता है।

    export public float damage = 60f;
    export public float rotationSpeed = 2f;

फिर से, सब कुछ सार्वजनिक है:

    export float damage = 60f;
    export float rotationSpeed = 2f;

और आपको डेटा प्रकार निर्दिष्ट करने की आवश्यकता नहीं है।

    export var damage = 60f;
    export var rotationSpeed = 2f;

निर्यात एक अपवाद है क्योंकि निरीक्षक को यह जानना आवश्यक है कि आपको कौन सा विजेट दिखाना है, इसलिए प्रकार वास्तव में निर्यात कीवर्ड के लिए एक अतिरिक्त जानकारी है।

    export(float) var damage = 60f;
    export(float) var rotationSpeed = 2f;

तो इस C# कोड के बीच का अंतर

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

और यह जीडीस्क्रिप्ट कोड

extends RigidBody2D

export(float) var damage = 60f;
export(float) var rotationSpeed = 2f;

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

C++/C#/TorqueScript पृष्ठभूमि से आते हुए, मुझे यह कहना होगा कि गोडोट के प्रतिमान को अभ्यस्त होने में कुछ दिन लगते हैं, लेकिन एक बार इसकी सादगी "क्लिक" हो जाने के बाद, आप जितनी तेजी से टाइप कर सकते हैं, उतनी ही तेजी से आप विचार से निष्पादन की ओर बढ़ सकते हैं।

@वेनन :

यह सिर्फ इतना है कि ये तर्क कई अन्य भाषाओं और इंजनों पर भी लागू होंगे

काफी सही, मैं अपनी सांस नहीं रोक रहा हूं और न ही मुझे समायोजित होने की उम्मीद है - यह मेरा क्षेत्र नहीं है।

अभी हम एकता उपयोगकर्ताओं के लिए एक गोडोट गाइड बनाने की कोशिश कर रहे हैं

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

@वारलान :

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

यह सही समझ में आता है - यह पर्ल की विचारधारा के साथ एक स्क्रिप्ट टाइप करने के लिए आवश्यक कीस्ट्रोक्स की मात्रा को कम करने के साथ जाता है। लेकिन वास्तव में, मैं वास्तव में उस उदाहरण के लिए टाइप किए गए कीस्ट्रोक्स की मात्रा समान होगी - मैं वीएस के ऑटो को अधिकतम तक पूरा करता हूं और शायद ही कभी किसी भी कीवर्ड, प्रकार या चर नाम के लिए 3 से अधिक वर्ण टाइप करना पड़ता है, इससे पहले कि मैं स्पेस या ओपन दबाऊं इसे पूरा करने के लिए ब्रैकेट। और जहां तक ​​वास्तविक अतिरिक्त 'अनावश्यक' पात्रों की बात है, मैं उन्हें वहां रखना पसंद करता हूं, वह सिर्फ एक वाक्यात्मक चीनी वरीयता है।
गोडोट का स्वत: पूर्ण है लेकिन यह धीमा है, इसमें इतना समय लगता है कि मैंने अक्सर कोड की अपनी पूरी लाइन टाइप की है इससे पहले कि यह ज्यादातर समय दिखाई दे।

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

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

बाद में सोचा:
क्या गोडोट में केवल C++ का उपयोग करना संभव है? मैं ईमानदारी से सोचता हूं कि मैं सी ++ सीखना पसंद करूंगा और जीडीस्क्रिप्ट पर इसका इस्तेमाल करूंगा।

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

@StrToN ने फेसबुक ग्रुप में एक पोस्ट कर इस तरह की मदद मांगी। उससे संपर्क करें (मुझे यकीन नहीं है कि कोई और उस पर भी काम कर रहा है)।

@neikeq धन्यवाद, किया!

@ वारलान मैं आपकी कोड तुलना को समझता हूं, लेकिन मेरे लिए यह मुख्य रूप से साबित करता है कि सी # में और अधिक सुविधाएं हैं, और इस तरह, अधिक वर्बोज़ है।

आपको using की आवश्यकता है क्योंकि कई वर्गों के साथ नाम टकराव से बचने के लिए नामस्थान हैं (जो पहले से ही मेरे अपने गेम प्रोजेक्ट में होता है)।
आपको public की आवश्यकता है क्योंकि समय के साथ कोडर त्रुटियों को रोकने के लिए इनकैप्सुलेशन की धारणा है।
आपके पास [SomeClass] है क्योंकि हम विभिन्न परियोजना आवश्यकताओं के अनुरूप अंतर्निहित एनोटेशन का विस्तार कर सकते हैं और टूलिंग में सुधार कर सकते हैं।
जहां तक ​​ब्रेसिज़ का सवाल है... मुझे दायरे को परिभाषित करने के अलावा कोई फायदा नहीं दिख रहा है।

ये सुविधाएँ यहाँ एक कारण से हैं। उनमें से, मैं स्केलेबिलिटी कहूंगा। क्या आप GDScript में सभी कोडबेस के साथ एक विशाल क्रॉस-प्लेटफ़ॉर्म 3D गेम विकसित करेंगे? अच्छा, आप कर सकते हैं। लेकिन बहुत से उपयोगकर्ता सी ++, सी # या जावा पसंद करेंगे, क्योंकि मैंने सूचीबद्ध पेशेवरों की वजह से (और मैं पूरी तरह से भाषा के बारे में बोलता हूं, ढांचे के बारे में नहीं)।

लेकिन साथ ही, गोडोट के साथ विकसित होने के बारे में मुझे कोई "विशाल" गेम प्रोजेक्ट नहीं है, इसलिए इतने सारे उदाहरण नहीं हैं: पी
साथ ही, मुझे सी # में कुछ खराब विशेषताएं दिखाई देती हैं (चेतावनी: व्यक्तिगत राय आगे):

आपके पास स्थिर चर हो सकते हैं। यह गलत है, वैश्विक राज्यों/अकेले लोगों से इतनी त्रुटियां आती हैं। ऑटो-लोड के विपरीत, वे किसी भी दृश्य क्षेत्र के लिए बाध्य नहीं हैं।
आप if() कथन के कुछ समय () के अंत में अर्धविराम गलत टाइप कर सकते हैं, जिससे यह बेकार और खोजने में कठिन हो जाता है।
आप ओवरकोड कर सकते हैं। मैं मानता हूं कि, जब गलत तरीके से उपयोग किया जाता है, तो C# कोड बहुत जटिल हो सकता है जबकि दूसरा सरल कोड भी ऐसा ही करेगा। लेकिन यह लोगों/अनुभव पर निर्भर करता है।

ओह। मैंने preload() उल्लेख नहीं किया। यह इसे सी #/जावा में नहीं बना सकता है, जब तक कि आप कंपाइलर चाल पर भरोसा नहीं करते: पी

क्या किसी ने पहले से ही मोनो मॉड्यूल का प्रयोग करना शुरू कर दिया है?

मेरी सबसे विनम्र राय जोड़ने के लिए, एक सी # डेवलपर के रूप में, इसमें ...

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

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

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

एक समापन टिप्पणी के रूप में, जो मुझे पता है कि कुछ लोग गलत तरीके से लेंगे, मेरे पास यह कहना है:

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

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

नामस्थानों का अत्यधिक स्वागत होगा, मुझे आश्चर्य है कि वे पहले से ही GDScript में मौजूद नहीं हैं।

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

टाइप संकेत कोड को पूरी तरह से काम करने से रोकने के अंतर को बंद कर सकते हैं। मैंने एक बार लुआ का उपयोग करके एक परियोजना पर काम किया था, और वे इसे भी लेना चाहते थे। शोध ने मुझे यहां तक ​​पहुंचाया: https://github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48
यह वही है जो एक फ़ंक्शन पैरामीटर बन सकता है, यदि आप टाइप हिंटिंग xD में बहुत दूर गोता लगाते हैं
लेकिन मुझे लगता है कि एक ट्रेडऑफ होना चाहिए। बस देखें कि टाइपस्क्रिप्ट या हैक्स कैसे करते हैं (वे दोनों मिक्सिंग वेरिएंट और टाइप की अनुमति देते हैं)। साथ ही, गोडोट में टाइप हिंटिंग पहले से मौजूद है। यह केवल निर्यात() में उपयोग किया जाता है :)

क्या किसी ने पहले से ही मोनो मॉड्यूल का प्रयोग करना शुरू कर दिया है?
@Zylann

गोडोटशर्प देखें । भंडार में वर्तमान स्थिति अभी तक प्रयोग करने योग्य नहीं है। अपने स्थानीय रेपो में मैं 2d/प्लेटफ़ॉर्मर डेमो को C# में अनुवाद करने के लिए पर्याप्त सामान (केवल वेक्टर 2 और मैट्रिक्स 32 मूल प्रकारों के रूप में उपलब्ध हैं) को लागू करने में कामयाब रहा, सिवाय दुश्मनों और गोलियों के इंस्टेंसिंग को छोड़कर जो कि GDScript से किया जाता है क्योंकि संदर्भ अभी तक काम नहीं कर रहे हैं।
यह खिलाड़ी वर्ग का एक उदाहरण है: https://github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs

@Pikl

बाद में सोचा:
क्या गोडोट में केवल C++ का उपयोग करना संभव है? मैं ईमानदारी से सोचता हूं कि मैं सी ++ सीखना पसंद करूंगा और जीडीस्क्रिप्ट पर इसका इस्तेमाल करूंगा।

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

@Zylann Pikl ने GDScript के सिंटैक्स को C# से मिलता-जुलता बदलने के बारे में पूछा, ताकि यूनिटी डेवलपर्स के लिए इसे पढ़ना आसान हो जाए। मैं उसी पर टिप्पणी कर रहा था। हां, सी # में अधिक सुविधाएं हैं, यही एकमात्र कारण है कि मेरे द्वारा हटाए गए कीवर्ड और वर्ण पहले स्थान पर थे। और इसीलिए उन्हें केवल GDScript कोड रखने के लिए जोड़ना जो C# कोड की तरह दिखता है, केवल अनावश्यक नहीं है, यह गलत है, क्योंकि आप एक सिंटैक्स का उपयोग कर रहे होंगे जो कि भाषा सुविधाओं पर संकेत देता है जो GDScript में नहीं है।

@Pikl यह कीस्टोक की मात्रा के बारे में नहीं है, यह विकल्पों की मात्रा और अतिरिक्त वर्णों के निहित अर्थ के बारे में है। GDScript में कुछ ऐसी विशेषताएँ नहीं हैं जो अतिरिक्त खोजशब्दों को वैध ठहराएँ। उदाहरण के लिए प्रत्येक चर, वर्ग और फ़ंक्शन को "सार्वजनिक" कीवर्ड से पहले होना होगा, क्योंकि सी # का डिफ़ॉल्ट दृश्यता संशोधक सार्वजनिक नहीं है (नामस्थानों को छोड़कर - यह उपयोग के मामले के आधार पर बदलता है ... एक और स्थिति जहां माइक्रोसॉफ्ट ने फैसला किया कि KISS 80 के दशक का सिर्फ एक बैंड है) और चूंकि GDScript में सब कुछ सार्वजनिक है।

तो क्यों न इसकी सभी विशेषताओं के साथ C# जोड़ा जाए?
जैसा कि ज़िलान ने पहले ही उल्लेख किया है कि गोडोट में सी # जोड़ने के प्रभाव की भविष्यवाणी करना इतना आसान नहीं है। यदि आपने अभी तक नहीं किया है, तो मैं इसकी सराहना करता हूं यदि आप इस धागे में मेरी लंबी पोस्ट (https://github.com/godotengine/godot/issues/5081#issuecomment-225226235) पढ़ते हैं। एक डेवलपर के रूप में मैंने हमेशा अधिक शक्तिशाली भाषाओं के लिए कहा होगा। अपने खाली समय में मैं वर्तमान में कोटलिन को सिर्फ इसलिए देख रहा हूं क्योंकि पेपर-पापर ने पहली पोस्ट में इसका उल्लेख किया था।
लेकिन चूंकि मुझे गेम डेवलपर्स के परिणाम और व्यवहार पर प्रोग्रामिंग भाषाओं के प्रभाव को देखने का अवसर मिला है, इसलिए मैंने महसूस किया है कि एक शक्तिशाली भाषा के बजाय पर्याप्त भाषा को चुनना कितना महत्वपूर्ण है।
जैसा कि मैंने लिंक किए गए पोस्ट में समझाया है, मुझे यकीन है कि सी # का एकता समुदाय में संस्कृति पर ध्यान देने योग्य प्रभाव है जो प्रोग्रामर को ऐसे लोगों के रूप में देखता है जो

• संपत्ति की दुकान के लिए सामान लिखें
• ट्यूटोरियल लिखें
• बग का समाधान करें।

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

और यह सिर्फ मेरा पसंदीदा प्रतिवाद है, पहली पोस्ट में कई अन्य अच्छे थे। ;-)

JVM के साथ समस्या यह है कि यह बहुत भारी है। क्या किसी ने एवियन को देखा? यह जावा दुनिया के साथ कितना संगत है?

@neikeq इसका मतलब यह नहीं है कि इसका प्रदर्शन खराब है - AFAIK JVM का CLR से बेहतर प्रदर्शन है, और एक कचरा कलेक्टर भी खेल के विकास के लिए बेहतर अनुकूल है। यह अधिकांश कंप्यूटरों पर भी स्थापित है, भले ही वे विंडोज या मैक या जीएनयू/लिनक्स हों।

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

मैं कहूंगा कि दोनों के बीच, JVM स्पष्ट रूप से खेल के विकास के लिए बेहतर है (लेकिन मैं इसे और CLR दोनों से समान रूप से बचूंगा)।

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

लेकिन उन मामलों के लिए GDScript और C++ के अलावा एक अतिरिक्त विकल्प के रूप में हल्का जावा कार्यान्वयन होना, जहां आपको त्वरित बदलाव समय की आवश्यकता होती है और कोड गुणवत्ता (जैसे गेम जाम या नए बैकएंड विचारों का तेजी से प्रोटोटाइप) का त्याग कर सकते हैं, अच्छा होगा।

@neikeq एवियन को सी ++ परियोजनाओं के लिए जावा-स्क्रिप्टिंग प्रदान करने के लिए ध्यान में रखा गया है, इसलिए यह वास्तव में एक अच्छा उम्मीदवार है। यह बहुत छोटा हो सकता है (अगर मैं सही ढंग से याद करूं तो 100kb जैसा कुछ)। कुछ libGDX खेलों के बारे में सुना जो iOS पोर्ट जारी करने के लिए एवियन का उपयोग कर रहे थे... jMonkey इंजन iOS पर भी एवियन का उपयोग कर रहा है)। आम तौर पर एवियन पूरे पैकेजिंग के बिना आता है जो आम तौर पर जेवीएम जैसे सूर्य/ओरेकल कक्षाओं के साथ आता है। हालांकि मुझे नहीं लगता कि यह एक समस्या है क्योंकि 'मूल' जावा कक्षाएं खेलों के लिए बिल्कुल उपयुक्त नहीं हैं, यही कारण है कि libGDX जैसे पुस्तकालय वैक्टर, या डेटा संरचनाओं पर अपना कार्यान्वयन प्रदान करते हैं .. और अंत में मुझे लगता है कि हम करेंगे उन वर्गों को भी फिर से लागू करने की जरूरत है। (हालांकि मूल जावा कक्षाओं के विभिन्न हिस्सों को एम्बेड करना आसान है, लेकिन जितना अधिक हम शामिल करेंगे उतना बड़ा एवियन बन जाएगा)

@ पेपर-पापर मेरा मतलब आकार में भारी था, मान लीजिए कि इसे खेल के साथ बंडल किया जाएगा। लेकिन जैसा कि आपने कहा, यह अधिकांश कंप्यूटरों पर स्थापित है, और libGDX जैसे ढांचे की लोकप्रियता को देखते हुए, यह सबसे अच्छा विकल्प हो सकता है।
जीडीस्क्रिप्ट के विकल्प के रूप में सी ++ के साथ मेरी समस्या यह है कि इसका वाक्यविन्यास भयानक है। यह एक उत्पादकता हत्यारा है। यह इंजन और मॉड्यूल के विकास के लिए ठीक है, लेकिन मैं इसके साथ एक पूरा गेम नहीं लिखूंगा। ऐसा कहने के बाद, मैं #3936 के पक्ष में हूं और अवास्तविक जैसा कुछ करता हूं, लेकिन मैं इसे वैकल्पिक "स्क्रिप्टिंग" भाषा के रूप में नहीं देखूंगा।

@ kubecz3k क्या यह अन्य JVM भाषाओं का समर्थन करता है? उदाहरण: कोटलिन

@neikeq हाँ जहाँ तक मुझे पता है कि यह जावा बाइटकोड के साथ पूरी तरह से संगत है, इसलिए यह किसी भी jvm तैयार भाषा (कोटलिन, स्काला, jpython और इसी तरह) का समर्थन करता है।
मुझे लगता है कि हम एवियन गूगल समूह पर कुछ प्रश्न पूछ सकते हैं: https://groups.google.com/forum/#!forum/avian
ऐसा लगता है कि यह काफी सक्रिय है

C++ को वैकल्पिक स्क्रिप्टिंग भाषा के रूप में नहीं देखने के लिए +1। जैसा कि मैंने पहले कहा था कि यह एक अच्छी बात है कि गोडोट की एक भाषा स्क्रिप्टिंग के लिए अनुकूलित है और एक बैकएंड विकास के लिए है क्योंकि दोनों क्षेत्रों में "मेह" की तरह की एक भाषा होने का विरोध किया गया है।

यह कहना नहीं है कि गतिशील lib समर्थन और तेज़ सी ++ विकास कुछ ऐसा नहीं था जिसे मैं देखना पसंद करूंगा।

लेकिन एवियन के बारे में अति उत्साही न होने के लिए, यहां libGDX के मुख्य देव से ब्लॉग पोस्ट है जिसमें उन्होंने समझाया है कि क्यों libGDX ios पोर्ट के लिए एवियन का उपयोग नहीं कर रहा है। http://www.badlogicgames.com/wordpress/?p=3925 (एवियन भाग तक स्क्रॉल करें)
मैं एक जेवीएम प्रोग्रामर/हैकर नहीं हूं (लेकिन लेखक है - चूंकि वह रोबोवीएम पर भी काम कर रहा था (फिर भी एक और जेवीएम जिसे माइक्रोसॉफ्ट द्वारा खरीदा और बंद किया गया था)) इसलिए मुझे नहीं पता कि इसमें से कितना वास्तव में बदल जाएगा ऐसी स्थिति जिसमें एवियन का उपयोग केवल एक स्क्रिप्टिंग भाषा के रूप में किया जाता है (कोर इंजन को सशक्त नहीं)

आप में से अधिकांश शायद प्रोग्रामर हैं जिनके पास मेरे से अधिक अनुभव है, लेकिन मेरे 2 सेंट हैं। एक साल पहले, मैं सी # के लिए रूट करूंगा। लेकिन मैंने जीडीस्क्रिप्ट सिंटैक्स बहुत जल्दी सीख लिया। दिन के अंत में, आपको अभी भी एपीआई सीखने की जरूरत है और शायद यह सीखने में सबसे अधिक समय लेने वाली चीज है। तो हाँ, मुझे सी # की जरूरत नहीं है। @ वारलान ने सी # के खिलाफ कई अच्छे कारण निकाले। C# को लागू करने में भी काफी समय लगेगा। इसका मतलब और भी बग होगा। हाँ, हमारे पास एक महान समुदाय है जो कोड आधार में योगदान देता है लेकिन हमारे पास अभी भी केवल एक @reduz है, मुझे लगता है कि सी # को लागू करने के लिए आवश्यक समय को उन सुविधाओं में निवेश किया जाना चाहिए जिनकी हमें वास्तव में आवश्यकता है। कितने Godot डेवलपर GDScript से संतुष्ट हैं? हाँ, यह तेज़ हो सकता है, लेकिन मुझे इससे कोई अन्य समस्या नहीं है। मेरे पास दो के बजाय एक बहुत अच्छी स्क्रिप्टिंग भाषा होगी जो इतनी अच्छी नहीं है। एकता भी पुरानी मोनो से पिछड़ रही है।

मैं जो चाहता हूं वह जीडीस्क्रिप्ट में स्थिर टाइपिंग है। स्क्रिप्टिंग भाषा के रूप में C++ नहीं, C# नहीं। आइए GDScript पर ध्यान दें और इसे अभी से भी बेहतर बनाएं।

चूंकि जिस इंजन पर मैं 14 वर्षों तक विकास का नेतृत्व करता हूं, उसका उल्लेख विजुअल स्क्रिप्टिंग थ्रेड में किया गया था, मैंने सोचा कि मैं यहां अपने 2 सेंट जोड़ूंगा क्योंकि हम अपनी सी # जैसी भाषा में पूरी तरह से लिखा गया एक नया इंजन विकसित कर रहे थे।

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

मैं वास्तव में कल्पना नहीं कर सकता कि एकता के लिए मोनो के साथ सी ++ कोड का एक समूह विलय करना कितना निराशाजनक होना चाहिए - जो शायद बताता है कि यह क्यों पिछड़ रहा है जैसा कि @GlaDOSik ने बताया। यह निश्चित रूप से ऐसा कुछ नहीं था जिसे करने में हममें से किसी की दिलचस्पी थी।

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

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

"अगर यह सी ++ नहीं है, तो यह धीमा है" अक्सर मंत्र लगता है, लेकिन मैं कहूंगा कि अधिकांश _shipped_ गेम इन दिनों गेमप्ले कोड के लिए सी ++ के अलावा किसी अन्य चीज़ के साथ लिखे गए हैं। मैंने वास्तव में किसी को विशेष रूप से GDScript से प्रदर्शन समस्याओं के बाद किसी को नहीं देखा है, हालांकि मैं निश्चित रूप से उनसे सुनने के लिए उत्सुक हूं कि क्या धीमा था।

जहाँ तक GDScript से मेरे परिचय की बात है, यह कुछ इस प्रकार था:

• ओएमजी पायथन की तरह !? वह पागल है, सफेद जगह कोई फर्क नहीं पड़ता!
• हम्म, "लोअर_केस" शैली का प्रशंसक नहीं है (देखें कि आप सभी को खुश नहीं कर सकते)।
• ठीक है, यह वास्तव में थोड़े अच्छा और अच्छी तरह से सोचा है।
• हाँ, यह संपादक के साथ अच्छी तरह से एकीकृत है, मैं निश्चित रूप से गेमप्ले कोड और कुछ संपादक प्लगइन्स के लिए इसके साथ बहुत उत्पादक होने के बारे में देख सकता था!

ऐसा लगता है कि GDScript में बहुत प्रयास और समय लगाया गया है, और यह सही टूल की तरह लगता है। तो मैं वास्तव में सिर्फ उन लोगों को बधाई देना चाहता था जिन्होंने इसे बनाने पर काम किया!

@ ज़िफ्लिन अरे! यहां आपसे मिलकर खुशी हुई, शातिर पहले गेम इंजनों में से एक था जिसे हमने पेशेवर रूप से उपयोग किया था (हालांकि हमें इसे हैक करने और वास्तव में इसका उपयोग करने से अधिक इसके साथ समस्याओं को ठीक करने के लिए @ पंटो के साथ काम पर रखा गया था)।

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

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

हम वास्तव में इस पर बहुत हंस रहे थे और मजाक कर रहे थे, और खेल निर्माता (जो हमारे पीछे था और हमने उसे नोटिस नहीं किया) डर से कांप रहा था और कहा: "रुको क्या? अब जो कुछ बचा है वह खेल का पुर्तगाली में अनुवाद कर रहा है , यह एक मज़ाक है, मैंने ठीक कहा न?"

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

( @Ziflin से उद्धरण) मैंने वास्तव में किसी को विशेष रूप से GDScript से प्रदर्शन की समस्याओं के बाद नहीं देखा है, हालांकि मैं निश्चित रूप से उनसे सुनने के लिए उत्सुक हूं कि क्या धीमा था।

मैं व्यक्तिगत रूप से इस परियोजना में एक सीपीयू/जीडीस्क्रिप्ट बाधा तक पहुंच गया हूं: http://godotdevelopers.org/index.php?topic=15519.0

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

साथ ही, मुझे लगता है कि पिछले साल इस अन्य परियोजना के साथ मुझे उसी सीपीयू/जीडीस्क्रिप्ट बाधा का सामना करना पड़ा जो प्रत्येक बग (जानवरों) के लिए बुनियादी एआई के लिए जीडीस्क्रिप्ट का उपयोग कर रहा था: http://ludumdare.com/compo/ludum-dare-32/? क्रिया = पूर्वावलोकन और यूआईडी = 50893
जितना अधिक मैंने बग (जानवर) जोड़े, प्रदर्शन उतना ही कम था।

अगर कोई चाहे तो मैं इस पर अपना अनुभव साझा कर सकता हूं।

@SuperUserNameMan कृपया आगे बढ़ें, लेकिन मुझे लगता है कि यह दूसरा टिकट मैंने खोला है #5049 (जो विशेष रूप से GDScript प्रदर्शन के बारे में बोलता है) उसके लिए अधिक उपयुक्त है।

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

@SuperUserNameMan मैंने वास्तव में टाइप अनुमान के माध्यम से जेआईटी को लागू करने के बारे में अभी तक बहुत कुछ नहीं सोचा है, लेकिन इसके लिए वीएम को पहले स्थिर टाइपिंग का समर्थन करना चाहिए

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

@reduz हाहा, जाहिर है यह एक छोटी सी दुनिया है! और हाँ, दृश्य स्क्रिप्टिंग प्रकार नियंत्रण से बाहर हो गया (यह वास्तव में केवल ट्रिगर्स और घटना तर्क के छोटे बिट्स से निपटने के लिए था)। विसियस ने वास्तव में इस साल की शुरुआत में अपने दरवाजे बंद कर लिए थे, लेकिन वहां काम करने में बहुत मजा आया।

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

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

ऐसा करने से मौजूदा IDE (VC++, आदि और Godot संपादक) भी बने रहेंगे जिनका लोग उपयोग करते थे। हमने वास्तव में अपनी भाषा को डीबग करने के लिए वीसी ++ का उपयोग किया था और हमारे कंपाइलर ने .cpp फाइलों में #LINE निर्देश उत्पन्न किए ताकि आप मूल कोड के माध्यम से आसानी से कदम उठा सकें और ब्रेकपॉइंट सेट कर सकें। तो सिद्धांत रूप में आप संपादक में सामान्य जीडीस्क्रिप्ट के साथ प्रोटोटाइप और डीबग करने में सक्षम होंगे, लेकिन 'जीडीस्क्रिप्ट-> सी ++' सक्षम बिल्ड के दौरान आप अभी भी अपने सी ++ आईडीई/डीबगर का उपयोग कर सकते हैं और जीडीस्क्रिप्ट फाइलों में ब्रेकपॉइंट/डीबग सेट कर सकते हैं। हमारे लिए, जेनरेट की गई सी ++ फाइलें अस्थायी रूप से थीं और कोड जनरेशन समस्या होने पर हमने केवल उन्हें ही देखा था।

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

वास्तव में मुझे यह समझ में नहीं आया कि मुझे अपने प्रदर्शन के मुद्दों को इस धागे में पोस्ट नहीं करना चाहिए था। यहाँ अधिक उपयुक्त था: https://github.com/SuperUserNameMan/kart-zero/issues/1

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

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

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

@reduz आह कूल। तो मूल रूप से आप एक 'प्लगइन' डीएलएल लिखने में सक्षम होने के बारे में बात कर रहे हैं जो इसका खुलासा कर सकता है कि वह जीडीस्क्रिप्ट को क्या चाहता है? (या मैंने गलत समझा?)

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

क्या यह किसी ऐसे व्यक्ति के लिए काम करता है जो एक डीएल लिखना चाहता है जिसमें कई नए सी ++ नोड-व्युत्पन्न प्रकार हैं?

यह थोड़ा दुखद है कि नया सी ++ 'मॉड्यूल' समर्थन हालांकि डीएलएल के साथ कुछ मुद्दों को ठीक करने के लिए पर्याप्त प्रतीत होता है।

एक एम्बेड करने योग्य स्क्रिप्टिंग भाषा जैसे लुआ या रूबी का उपयोग क्यों न करें?

@jersten क्योंकि दस्तावेज़ पढ़ें - http://docs.godotengine.org/en/latest/reference/gdscript.html

@Ziflin हाँ, लेकिन आपको प्रतिबिंब के माध्यम से सी एपीआई का उपयोग करना होगा (हालांकि आप प्रतिबिंब के माध्यम से फ़ंक्शन पॉइंटर्स के लिए पूछ सकते हैं, इसलिए यह पर्याप्त तेज़ होना चाहिए ..) लक्ष्य ज्यादातर डीएलएल लोड करने का एक आसान तरीका होगा जो एबीआई समस्या से बचाता है, और जीडीस्क्रिप्ट को सी में संकलित करने और इसे .so के रूप में लोड करने का एक आसान तरीका भी होगा।

मैं यहाँ अपने 2 सेंट में चिप करने वाला हूँ जो कि लायक है। मैंने कभी सी # में कोड नहीं किया लेकिन केवल जावा में। जबकि मैं इसे इस्तेमाल करने और इसे पसंद करने के कारण व्यक्तिगत रूप से जावा को पसंद करूंगा, मैं वास्तव में जावा पर सी # का समर्थन करता हूं। सी # वह है जो एकता गेम देव उपयोग करते हैं, इसलिए इसे गोडोट को इस इंडी देव पारिस्थितिकी तंत्र का एक हिस्सा बना देगा। यदि आप JVM भाषा चाहते हैं तो जावा भी एक अच्छा विकल्प नहीं है। अन्य बेहतर भाषाएँ हैं जो JVM को संकलित करती हैं।

मुझे लगता है कि लोग वैसे भी इस बिंदु को याद कर रहे हैं। सी#/जावा!= स्क्रिप्टिंग भाषा। जीडीस्क्रिप्ट पर्याप्त है; सीखने में आसान, आदि।

जावा जैसी भाषा जोड़ना (किस उद्देश्य के लिए जेवीएम बनाना?! सिंटैक्स?! कार्य करने के लिए एक विशिष्ट संस्करण के साथ एक जेवीएम की आवश्यकता है?!?) या सी # (मोनो को लागू करें और इंजन को खराब करें; या अपना खुद का निर्माण करें?) इंजन को जहर देगा .

यदि GDScript में कोई समस्या है तो उसे इंगित किया जाना चाहिए; और फिर ठीक करने का प्रयास किया।

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

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

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

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

मुझे लगता है कि एक गलतफहमी है:

• वे GDScript देखते हैं और सोचते हैं कि GDScript C# के बराबर है; मौलिक बिंदु याद आ रहा है कि सी # एक स्क्रिप्टिंग भाषा नहीं है।
• उपरोक्त तथ्य के कारण, जब कोई "Java या C#" कहता है; वे वास्तव में जो मांग रहे हैं वह सी #/जावा में इंजन का पुनर्लेखन है या उन भाषाओं का समर्थन करने के लिए कुछ बाइंडिंग जोड़ना है (एलओएल नहीं)।

चूंकि मैं बाद वाला मान रहा हूं; सी #/जावा में डिबगिंग कई प्लेटफॉर्म पर एक दुःस्वप्न है; चूंकि वे दोनों भाषाएं प्लेटफॉर्म स्वतंत्र नहीं हैं (inb4 लगभग सभी ओएस पर रनटाइम हैं); यह "एक बार लिखें, हर जगह डीबग करें" में बदल जाता है (यही कारण है कि मोनोगेम को लिखे गए गेम पहले विंडोज़ पर आते हैं; और फिर अंततः लिनक्स/मैक क्योंकि देवों को उन प्लेटफार्मों के लिए डीबग करना पड़ता है)। यही कारण है कि JVM अपडेट एप्लिकेशन को तोड़ देता है।

उन भाषाओं के लिए समर्थन जोड़ने से इंजन में कोई मूल्य नहीं जुड़ता है।

यदि तर्क "मोर यूनिटी देव" है; फिर एकता देवों को संक्रमण में मदद करने के लिए दस्तावेज़ीकरण किया जाना चाहिए; वह लेआउट अंतर, आदि।

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

मैं आपसे सहमत हूं कि जीडीस्क्रिप्ट थोड़ा आपत्तिजनक है क्योंकि यह वस्तुतः एक अज्ञात भाषा है। लेकिन, जब मैंने पढ़ा कि लुआ और पायथन को क्यों हटाया गया और जीडीस्क्रिप्ट को जोड़ने के लाभों के बारे में मुझे कम चिंता थी।

एक और बात जो प्रासंगिक हो सकती है: एक और एमआईटी-लाइसेंस प्राप्त इंजन है जो पहले से ही सी # का समर्थन करता है और एकता, परमाणु गेम इंजन के समान है। मेरा सुझाव है कि सभी लोग जिन्हें एकता के जितना करीब हो सके, किसी चीज़ की सख्त ज़रूरत है, इसे आज़माएं।

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

यह सब कहा जा रहा है, यह सी # होना जरूरी नहीं है। जहां तक ​​मेरा संबंध है, कुछ और जो समान प्रभाव डालेगा, ठीक रहेगा, चाहे वह सांख्यिकीय रूप से टाइप किया गया संकलित/जेआईटी जीडीस्क्रिप्ट हो, या स्विफ्ट या कुछ और जैसा कुछ हो। C# 'विपणन उद्देश्यों' के लिए सर्वोत्तम हो सकता है; एक समान एपीआई के बिना भी, अन्य इंजन/ढांचे के देव शायद इसके साथ अधिक सहज होंगे। संशोधित GDScript को लागू करना आसान हो सकता है, और संभवत: इसे बहुत बेहतर तरीके से एकीकृत किया जाएगा।

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

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

मुझे इस तर्क पर एक टिप्पणी जोड़ने दें कि C# नए लोगों को लाएगा।
हम क्यों चाहते हैं कि अधिक लोग गोडोट का उपयोग करें? मैं पूरी तरह से समझता हूं कि ओपन सोर्स प्रोजेक्ट्स को एक ऐसे समुदाय की आवश्यकता होती है जो

• सुविधाएँ जोड़ता है
• बग को ठीक करता है
• पुन: प्रयोज्य संपत्ति बनाता है
• नई सुविधाओं के लिए सुझाव देता है
• वर्कफ़्लो के साथ बग या समस्याएं ढूंढता है
• ट्यूटोरियल लिखता है

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

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

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

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

संपादित करें: कुछ अनावश्यक रूप से कठोर भाषा को हटा दिया ;-)

@trollworkout कोई अपराध नहीं है, लेकिन आपने वास्तव में मेरी बात को नहीं समझा और मुझे लगता है कि आपने जो कहा, उसके बारे में आपने वास्तव में नहीं सोचा।

1. हां, लोग समय बर्बाद नहीं करना चाहते। GDScript के पूर्ण विनिर्देश: कुछ स्क्रीन। C# की व्याख्या करने वाली पुस्तकें: आमतौर पर कम से कम 500 पृष्ठ। मैंने जीडीस्क्रिप्ट सीखने में कुछ दिन बिताए हैं और मुझे पूरा यकीन है कि इसमें एक भी ऐसी विशेषता नहीं है जिसे मैं नहीं जानता। मैंने पेशेवर और अपने खाली समय में सी # के साथ वर्षों से काम किया है (विंडो फॉर्म, डब्ल्यूपीएफ, एक्सएनए और यूनिटी का उपयोग करके) और मुझे अभी भी कोड स्निपेट मिलते हैं जो उन सुविधाओं का उपयोग करते हैं जिन्हें मैंने पूरी तरह समझ नहीं लिया है। सी # के लिए पूछना क्योंकि यह समय की बर्बादी से कम था, वास्तव में इसका कोई मतलब नहीं है।
2. "शुरुआती लोगों को यह सीखना होगा कि वे जिस भी भाषा में कोड स्निपेट का उपयोग करते हैं, वे लिखे गए हैं" - बिंदु 1 देखें। यह धारणा कि आप कोड स्निपेट से C# सीख सकते हैं, सच्चाई से बहुत दूर है। इस तरह से आप जो चीजें सीख सकते हैं, वे इतनी बुनियादी हैं कि एक अलग भाषा को "सीखने" में कुछ दिनों से ज्यादा समय नहीं लगेगा। आपने स्वयं कहा था कि आपने GDScript इस तरह सीखा।
3. "सी# गोडोट को इस इंडी देव पारिस्थितिकी तंत्र का हिस्सा बना देगा"। और इसका क्या मतलब होना चाहिए?
   क्या आप C#-Godot में यूनिटी कोड स्निपेट का उपयोग कर सकते हैं? नहीं।
   क्या आप C#-Godot में एकता की संपत्ति का पुन: उपयोग कर सकते हैं? नहीं।
   क्या आप एकता ट्यूटोरियल पढ़ सकते हैं और उन्हें सी#-गोडोट पर शब्द दर शब्द लागू कर सकते हैं? नहीं।
   तो यह "इंडी देव पारिस्थितिकी तंत्र" क्या है जिसका आप जिक्र कर रहे हैं?

जैसा कि पेपर-पापर ने कहा था कि चुनने के लिए बहुत सारे इंजन और पुस्तकालय हैं।
क्या आप एकता की तरह एक घटक प्रणाली चाहते हैं? परमाणु गेम इंजन देखें।
क्या आप इंजन में C# का उपयोग करते रहना चाहते हैं लेकिन घटक प्रणाली को खत्म करना चाहते हैं? क्रायइंजिन/लुबेरयार्ड को देखें।
क्या आप C# का उपयोग करते रहना चाहते हैं लेकिन इंजन को छोड़ना चाहते हैं? मोनोगेम देखें।

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

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

आपके द्वारा उल्लिखित C++ के साथ आपके द्वारा बताए गए सभी मुद्दे मान्य हैं और इन्हें #3936 के माध्यम से ठीक किया जा सकता है। हम इस पर पहले भी कई बार चर्चा कर चुके हैं, लेकिन स्पष्टता के लिए यहाँ GDScript के साथ कुछ ऐसे मुद्दे हैं जिन्हें हम वस्तुनिष्ठ रूप से पहचान सकते हैं:

1. तृतीय-पक्ष पुस्तकालयों के लिए खराब समर्थन
2. घटिया प्रदर्शन

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

मैंने जल्दी से यह धागा पढ़ा, और देखा कि GDScript से C की कल्पना की गई थी।

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

TCC को GNU लेसर जनरल पब्लिक लाइसेंस के तहत वितरित किया जाता है।

(स्रोत)

यह संभवतः इसे गोडोट में शामिल करने के लिए अनुपयुक्त बनाता है। यह भी अब बनाए रखा नहीं लगता है।

@ वारलान मुझे ज्यादा सोचने की जरूरत नहीं है। इस बिंदु पर हम सभी ने एक ही बात लगभग 10 बार पहले ही कह दी है, मुझे लगता है कि हम बहुत अधिक जानते हैं कि क्या हम सभी खड़े थे। मेरे 2 सेंट और कुछ विचारों के अलावा मेरे पास योगदान करने के लिए और कुछ नहीं है क्योंकि मैं एक देव नहीं हूं और मैं इंजन को अंदर से अच्छी तरह से नहीं जानता। मैं उन्हें बोलने दूँगा जो बेहतर जानते हैं। मैं सिर्फ अपना समर्थन देना चाहता था और बस इतना ही।
विषय से परे:
लेकिन हाँ, बिंदु 2 के संबंध में, जिसके बारे में आपने बहुत हंगामा किया कि आपको अपनी टिप्पणी संपादित करनी पड़ी। तो आप कह रहे हैं कि आप उदाहरणों के आधार पर भाषा नहीं सीख सकते हैं? मुझे लगता है कि आप मानते हैं कि लोग इसे तब तक सीखने में असमर्थ हैं जब तक कि वे 500 पेज मैनुअल नहीं पढ़ते हैं, जिसे सी # आपके लिए जाना जाता है, इसे अस्वीकार करने का कारण 1 कहते हैं। वैसे मैं इस बात का जीता जागता सबूत हूं कि आप गलत हैं। आपको क्या लगता है कि मैंने GDScript कैसे सीखा? एपीआई और डेमो उदाहरणों के साथ और आसपास के प्रश्न पूछने के साथ। ध्यान रहे कि मेरे पास शुरू करने से पहले मेरे पास 0 पायथन ज्ञान था, इसलिए इसके बारे में सब कुछ बहुत ही विदेशी था। एक साइड नोट के रूप में मुझे आश्चर्य है कि कितने लोग libGDX मैनुअल खरीदते हैं बनाम कितने लोग वास्तव में Google "libGDX में एक्स कैसे करें" शायद एकता में संपत्ति की दुकान इतनी खराब क्यों है। और इसके साथ ही मैं कुछ समय के लिए कर रहा हूं क्योंकि मेरे पास कहने के लिए और कुछ नहीं है।

( @Calinou : बेलार्ड ने TCC के एक कांटे को BSD या MIT बनने की अनुमति दी। लेकिन पिछली बार जब मैंने जाँच की, तो कांटे के देव ने सोर्सकोड जारी नहीं किया था। तो, शायद बेलार्ड गोडोट समुदाय को TCC को भी त्यागने देना स्वीकार करेंगे?)

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

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

यदि उन्हें वैकल्पिक निर्भरता बना दिया जाता है, तो जिनके पास जीसीसी या क्लैंग स्थापित नहीं है (जो एक डेवलपर के लिए अजीब है जो वितरण के लिए एक गेम बनाने वाला है, लेकिन वैसे भी) जीडीस्क्रिप्ट दुभाषिया का उपयोग कर सकते हैं क्योंकि यह अभी है।

मैंने GDScripts के लिए JIT के रूप में TCC का उपयोग करने का सुझाव दिया। तो सबसे महत्वपूर्ण विशेषता संकलन गति थी। और मुझे लगता है कि परिणाम मौजूदा समाधान की तुलना में पहले से ही बहुत तेज हो सकते हैं।

अधिकांश लोग प्रदर्शन के लिए सी/सी++ चाहते हैं और लुआ/जावास्क्रिप्ट लिखने में आसान और तेज़ होने के लिए, तो दोनों दुनिया के सर्वश्रेष्ठ क्यों नहीं हैं?

निम - http://nim-lang.org/

सी की तरह कुशल, पायथन की तरह अभिव्यंजक और लिस्प की तरह लचीला

पेशेवरों:

• C, C++, Obj-C या JS में संकलित करता है ( http://nim-lang.org/docs/backends.html )
• (पायथन / पास्कल) जैसे ( https://learnxinyminutes.com/docs/nim/ )
• जीसी या मैनुअल ( http://nim-lang.org/docs/gc.html )
• गोडोट के अलावा कहीं और इस्तेमाल किया जा सकता है
• क्रॉस-प्लेटफ़ॉर्म (विंडोज़, लिनक्स, ओएसएक्स, मोबाइल)
• C कोड को Nim . में बदलने में मदद करता है
• सी libs का समर्थन करता है
• ट्वीकेबल कंपाइलर
• एमआईटी लाइसेंस प्राप्त
• खुला स्त्रोत
• प्रकार- सुरक्षित

दोष:

• देव के कंप्यूटर में C/C++ कंपाइलर की आवश्यकता है -> gcc , vcc , llvm_gcc , icc , clang या ucc _(वास्तव में मेरी राय में एक चोर नहीं है)_
• छोटा समुदाय
• अभी 1.0 नहीं

निम की TODO सूची छोटी है, यह 1.0 के करीब है:
https://github.com/nim-lang/Nim/blob/devel/todo.txt

जैसा कि पेपर-पापर ने कहा (देव के कंप्यूटर में एक कंपाइलर होने के बारे में):

वे ज्यादातर लोगों की मशीनों पर स्थापित होते हैं जो वैसे भी खेल का निर्माण करेंगे
https://github.com/godotengine/godot/issues/5081#issuecomment -227706106

https://hookrace.net/blog/what-is-special-about-nim/
https://hookrace.net/blog/what-makes-nim-practical/

https://github.com/nim-lang/Nim/wiki/Nim-for-C-programmers
https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

यह मेरा पसंदीदा समाधान नहीं है, लेकिन अगर आपको उस सड़क से नीचे जाना है तो मैं दृढ़ता से सुझाव देता हूं कि आप निम के बजाय हेक्स ( haxe.org ) का उपयोग करें।

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

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

सही काम के लिए सही उपकरण चुनना बहुत महत्वपूर्ण है। Haxe (या उस मामले के लिए C#) जैसी भाषाएं आपको एक ऐसी भाषा देने की कोशिश करती हैं जो सभी के लिए उपयुक्त हो, इसलिए अधिक बार आप "सिर्फ एक टूल" का उपयोग करके समाप्त नहीं होते हैं जो दुर्भाग्य से ऐसा दिखने के लिए होता है ।

थोड़ी देर के लिए गोडोट के साथ काम करने के बाद मैं अपने 2 सेंट जोड़ना चाहता हूं।
मैं जो देखना चाहता हूं (और सीमित सफलता के साथ भी देख रहा हूं) गोडोट में प्रथम श्रेणी की भाषा के रूप में सी ++ है।
C++ में कंप्यूटेशन-हैवी लॉजिक (टकराव समाधान, भौतिकी, परिवर्तन और AI) लिखना और GDScript (ट्रिगर, कंडीशन, एनिमेशन और साउंड) का उपयोग करके नोड्स को स्क्रिप्ट करना।

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

कोड फ़ाइलें बस बहुत लंबी हो जाती हैं और कोड संपादक में अन्य IDE में पाई जाने वाली बहुत सी उपयोगी सुविधाओं का अभाव होता है जैसे: दायरे, क्षेत्रों का ढहना, वर्तमान दायरे के प्रारंभ/अंत तक कूदना।

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

साथ ही, जीडीस्क्रिप्ट की प्रकृति को देखते हुए कोई फ़ंक्शन संदर्भ नहीं है और कोई टेम्पलेटिंग नहीं है।
यह शो-स्टॉपिंग कुछ भी नहीं है लेकिन यह बहुत कष्टप्रद है।

आई776; GDscript केवल साधारण गेम से अधिक के लिए अनुपयोगी है यदि आप _get_overlapping_bodies ()_ जैसे कार्यों के लिए विशेष रूप से चिपके रहने के बजाय अन्य सुविधाओं (जैसे नोड्स और कॉलबैक का उपयोग करना) को अनदेखा करने का निर्णय लेते हैं।

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

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

कोड फ़ाइलें बस बहुत लंबी हो जाती हैं

क्या आपका मतलब इस तरह की स्क्रिप्ट से है? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd
क्या आपको लगता है कि C# ऐसा होने से रोक सकता है? व्यक्तिगत रूप से मैं नहीं। वास्तव में यह टूलींग (हाँ, जब लोगों का मतलब सी # है, तो उनका अर्थ अक्सर वीएस परोक्ष रूप से होता है) और स्थिर टाइपिंग के कारण इन लंबी लिपियों में पहले से ही रिफैक्टर और त्रुटियों का पता लगाना आसान हो जाता है, हालांकि खेल के चलने तक नोड पथ त्रुटियां ज्ञानी नहीं होंगी। लेकिन इसके अलावा, अच्छा डिज़ाइन और नोड्स का उपयोग स्क्रिप्ट को बहुत सरल बना सकता है।

कोड संपादक में अन्य IDE में पाई जाने वाली बहुत सी उपयोगी विशेषताओं का अभाव है जैसे: दायरे का ढहना, क्षेत्र, वर्तमान दायरे के प्रारंभ/अंत तक कूदना।

इन्हें भविष्य में जोड़ा जा सकता है यदि आप इसके लिए कहते हैं, हालांकि आप बिना किसी समस्या के बाहरी संपादक का उपयोग कर सकते हैं (https://atom.io/packages/lang-gdscript), गोडोट में स्वत: पूर्णता सेवाएं भी हैं।

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

कोई वर्ग-दृश्य संबंध जागरूकता नहीं है

आपका क्या मतलब है? आप जानते हैं कि आप एक दृश्य की जड़ पर एक स्क्रिप्ट डाल सकते हैं, है ना? साथ ही C# संपादक अनुमान नहीं लगा सकते कि उस दृश्य में क्या है जहां उनका उपयोग किया जाता है, जबकि GDScript कर सकता है।

साथ ही, जीडीस्क्रिप्ट की प्रकृति को देखते हुए कोई फ़ंक्शन संदर्भ नहीं है और कोई टेम्पलेटिंग नहीं है।

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

GDScript में प्रक्रियात्मक भाषाओं की बहुत सारी मूलभूत सुविधाओं का भी अभाव है

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

क्या आपका मतलब इस तरह की स्क्रिप्ट से है? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

मेरा कहना है कि भले ही फ़ाइल लंबी हो, मैंने बहुत बुरा देखा है और कोड काफी प्रक्रियात्मक होने के बावजूद यह अभी भी काफी पठनीय है। अब मुझे अंत में पता चलता है कि GDScript के लिए एक साधारण सिंटैक्स बेहतर क्यों है: यह औसत गेम लॉजिक के लिए सबसे अच्छा है, जो ज्यादातर if s और फ़ंक्शन कॉल है।

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

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

क्या आप for भाग के बारे में कुछ और गहराई से जा सकते हैं और कुछ उदाहरण जो आप छद्म-जीडीस्क्रिप्ट में संदर्भित कर रहे हैं?

@ पेपर-पापर चीजें जीडीस्क्रिप्ट की कमी सी # से संबंधित नहीं है, लेकिन उदाहरण के लिए for i in range(-PI, PI) जीडीस्क्रिप्ट में काम नहीं करता है, साथ ही for i=0, i < size and stuff, ++i । मैं तीन-पंक्तियों-अगर लिखने के बजाय टर्नरी लिखना चाहता हूं। लेकिन जैसा कि मैंने कहा, इसके लिए पहले से ही ट्रैकर में समस्याएँ हैं और यह मुझे GDScript का उपयोग करने से नहीं रोकेगा: p

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

for i in range(-PI, PI)

यह मेरे सिर को अपनी धुरी पर तब तक घुमाता है जब तक कि यह शून्य से एक विभाजन तक नहीं पहुंच जाता और एन्ट्रापी को नष्ट करना शुरू कर देता है। मुझे उम्मीद है कि कोई भी भाषा इस तरह के अप्रत्याशित बयान को लागू नहीं करती है। वह क्या करता है? -पीआई और पीआई (यानी -3, -2, ..., 2, 3), या पीआई (यानी -पीआई और 0) के गुणकों के बीच पूर्णांकों पर पुनरावृति करें, या यह फ्लोट्स पर पुनरावृति करता है जैसे कुछ वूडू डिफ़ॉल्ट चरण 0.176 या ln(2) कि कुछ भाषा प्रोग्रामर को सबसे उपयुक्त लगा?

@ akien-mga उफ़ क्षमा करें। मुझे वास्तव में xD एक कदम तर्क जोड़ना चाहिए था लेकिन यह अभी भी काम नहीं करता है। यहाँ वह मुद्दा है जो मैंने इसके लिए बनाया है https://github.com/godotengine/godot/issues/4164

मैं मानता हूं कि गोडोट को टूलिंग की कमी खलती है। प्रमुख समस्या जीडीस्क्रिप्ट की डक-टाइपिंग प्रकृति है, जिससे यह जानना कठिन हो जाता है कि क्या है और इस प्रकार "संदर्भ खोजें" या "परिभाषा पर जाएं" जैसी कुछ क्रियाएं करना मुश्किल हो जाता है।

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

@vnen (एम) ईएलपीए में जीडीस्क्रिप्ट के लिए एक ईएमएसीएस मोड मेरी किताब में पहले से ही सही दिशा में एक कदम होगा :)

ओह हाँ, इन दो मुद्दों के बारे में लगभग भूल गए, जो काफी मज़ेदार थे, वास्तव में मुझे अभ्यास में धीमा कर दिया:

• तर्क किसी फ़ंक्शन के हस्ताक्षर का हिस्सा नहीं हैं। इसका मतलब है कि आप कार्यों को ओवरराइड नहीं कर सकते।
  व्यवहार में एक ही कक्षा में function doFoo(a,b,c,d) और function doFoo(a,b) होने के परिणामस्वरूप संकलन करने में विफलता होगी। मैंने उनका नाम बदलकर doFoo4(a,b,c,d) और doFoo2(a,b) कर दिया और स्क्रिप्ट फ़ाइलों के एक समूह को फिर से तैयार किया।
• चूंकि गणना के लिए कोई समर्थन नहीं है, सभी झंडे और रिटर्न कोड, आवश्यकता के अनुसार, ints हैं, इसलिए आपको उनका अनुमान लगाना होगा और कई अभी भी अनिर्दिष्ट हैं।

पीएस: जाहिर है कि कार्यों का शाब्दिक नाम doFoo नहीं था। ;)

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

@Zylann : ~ 1200 एलओसी ... pffft नहीं, मैं असली सौदे के बारे में बात कर रहा हूं ... प्रति फ़ाइल 20k + LOC। एक आरपीजी डेवलपर जो एकता का उपयोग करता है, जिसका नाम नहीं रहेगा (नहीं, मैं उनके लिए काम नहीं करता), नियमित रूप से 25k+ loc के साथ कक्षाएं होती हैं। फिर वे अपने सभी कार्यों को स्थिर बनाते हैं और सी # का उपयोग करते हैं जैसे कि यह सी थे: भयभीत:

ऑफ-विषय के लिए खेद है।

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

और इंजन में गेम-ब्रेकिंग परिवर्तनों का आसानी से पता लगाया जा सकता है और गोडोट जैसे लिबरे प्रोग्राम में वापस लाया जा सकता है, इसलिए उन्हें चिंता नहीं करनी चाहिए।

@ eye776 मैंने कभी भी फ़ंक्शन ओवरराइडिंग के साथ गतिशील भाषाएं नहीं देखीं। GDScript में डिफ़ॉल्ट पैरामीटर हैं, ताकि इसके बजाय इसका उपयोग किया जा सके।

साथ ही, एक फ़ाइल में 20K+ LOC करने वाला पागल कौन है? यहाँ समस्या उपकरण पर नहीं है... पूरे गोडोट स्रोत में एक भी फाइल नहीं है जो मुझे 10के एलओसी के साथ मिल सके।

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

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

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

@vnen सिर्फ मनोरंजन के लिए: godot/drivers/gles2/rasterizer_gles2.cpp 11K LOC है: p (यह मुझे मिला सबसे बड़ा है, लेकिन यह एक दुर्लभ अपवाद है)।

@vnen

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

गोडोट ने मुझे एक बार मार्च में वापस जला दिया (v 2.0.1)। मैं एक तीसरे व्यक्ति के कैमरे और चरित्र के साथ खिलवाड़ कर रहा था और गोडोट की अपनी भौतिकी को आंदोलन (खींचने और बलों) के लिए उपयोग करने की कोशिश की और इसे काम पर लाया।
अगले मामूली संस्करण (v 2.0.2) अपडेट ने मूल रूप से समान मूल्यों के लिए चरित्र की गति (2-3x तेज) को तोड़ दिया।
यह पता चला कि इसे केवल किनेमेटिक रखना और अपना खुद का "भौतिकी" करना बेहतर था।

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

वैसे भी, मैं वास्तव में, धागे को पटरी से उतारने के लिए वास्तव में क्षमा चाहता हूँ।

@ eye776 क्या आपने अपने खेल को तोड़ने के लिए 2.0.1 से 2.0.2 तक कमिटमेंट की जांच की? यह एक बग हो सकता था और इसकी रिपोर्टिंग से पूरे समुदाय को लाभ हो सकता था।

मोनो या कोरसीएलआर? और क्यों?

मोनो:

• एमआईटी लाइसेंस प्राप्त
• स्थिर
• छोड़े जाने की संभावना
• अच्छा दस्तावेज

कोरसीएलआर:

• एमआईटी लाइसेंस प्राप्त
• अभी भी 1.0 नहीं (वर्तमान में यह RC2 है)
• छोटा
• खराब दस्तावेज

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

गुरु, अगस्त 4, 2016 अपराह्न 1:45 बजे, ह्यूबर्ट जारोस नोटिफिकेशन @github.com
लिखा था:

मोनो या कोरसीएलआर? और क्यों?

मोनो:

• एमआईटी लाइसेंस प्राप्त
• स्थिर
• छोड़े जाने की संभावना
• अच्छा दस्तावेज

कोरसीएलआर:

• एमआईटी लाइसेंस प्राप्त
• अभी भी 1.0 नहीं (वर्तमान में यह RC2 है)
• छोटा
• खराब दस्तावेज

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

ऊपर बताए गए @reduz के अलावा, एपीआई एनकैप्सुलेटेड है, इसलिए जरूरत पड़ने पर बाद में इसे CoreCLR में बदलना मुश्किल नहीं है।

CoreCLR: अभी भी 1.0 नहीं (वर्तमान में यह RC2 है)

14 जून को यह 1.0 स्थिर पर पहुंच गया।

मोनो: परित्यक्त होने की संभावना

किस पर आधारित?

मोनो: अच्छा दस्तावेज

आह आह आह

किस पर आधारित?

Microsoft .NET के तीन स्टैक क्यों विकसित करेगा? यह संसाधन-वार अच्छा नहीं है। (.NET फ्रेमवर्क, मोनो, .NET कोर)

आह आह आह

मैंने सी ++/सी # इंटरऑप (हमें गोडोट के लिए क्या चाहिए) के बारे में दोनों दस्तावेज़ों की जांच की है और यह मोनो में बिल्कुल ठीक है। CoreCLR में मुझे उनके कुछ कोड को खोदना था और अपने ऐप को काम करने के लिए देवों से मदद माँगनी थी।

संदर्भ मार्गदर्शिका में बहुत सारे कार्य अनिर्दिष्ट, टूटे हुए लिंक हैं ...

सिद्धांत रूप में मैं यहाँ पूर्वाग्रह हूँ... लेकिन मुझे आशा है कि मेरे तर्क वस्तुनिष्ठ हैं...

• मुझे मोनो विकास में कोई गिरावट नहीं दिख रही है: https://github.com/mono/mono/graphs/contributors
• विंडोज़ पर मोनो के लिए विकास कभी भी उतना मजबूत नहीं था जितना आज है (थोड़े सबूत (बहुत सारे कामों को जोड़ने के बिना) https://github.com/mono/mono/pull/3231 मिगुएल कह रहा है "चूंकि अब हमारे पास असली रखरखाव है") बनाना पिछला बिंदु और भी स्पष्ट
• मोनो में एपीआई एम्बेड करना युद्ध परीक्षण है (न केवल एकता बल्कि कई अन्य निजी उपयोगकर्ता भी हैं)
• मोनो टुडे PS4, Android, Windows, iOS BITCODE (इसमें वर्षों का काम चला), AppleTV और कई अन्य प्लेटफॉर्म पर चलता है ...

तो इम्हो, यदि आप इसे निकट भविष्य में (3 वर्ष से कम) भविष्य में और अधिकांश गेमिंग प्लेटफॉर्म पर वितरित करना चाहते हैं ... मोनो के साथ जाएं।

नमस्ते,

कुछ टिप्पणियां:

• डेविड कार्लास द्वारा सूचीबद्ध प्लेटफार्मों के अलावा हम WebAssembly, XboxOne, UWP और Win64 मूल समर्थन भी जोड़ रहे हैं।
• साझा किया जा रहा नमूना या तो आभासी तरीकों (तेज प्रेषण) के साथ किया जा सकता है या सी # घटनाओं के साथ किया जा सकता है।
• C# ऐतिहासिक रूप से कई भाषा नवाचारों में सबसे आगे रहा है, किसी भी स्थान से अच्छे विचारों को आकर्षित करता है। इसने भाषा अनुसंधान से कई विचारों को लोकप्रिय बनाया है और बड़े पैमाने पर बाजार में लाया है और अब हम इसे मान लेते हैं, जैसे कि इटरेटर, नॉन-इरेज़ेड जेनरिक, लैम्ब्डा, एसिंक-प्रोग्रामिंग, प्रॉपर्टीज, प्लेटफॉर्म इनवोकेशन, लेकिन उन भाषाओं में से एक है जो हैं सार्वजनिक रूप से सबसे सक्रिय रूप से विकसित । उदाहरण के लिए, आगामी संस्करण मेरे पसंदीदा पैटर्न मिलान सहित कई नई सुविधाएँ जोड़ रहा है।
• सामान्य तौर पर, एकता आधुनिक C# का प्रदर्शन नहीं करती है क्योंकि वे पुराने रनटाइम का उपयोग कर रहे हैं। उम्मीद है कि यह जल्द ही बदल जाएगा। उस ने कहा, वर्तमान मोनो उन "एसिंक" प्रोग्रामिंग के बीच सभी नई सी # सुविधाओं का समर्थन करता है, जो गेम कोड के लिए आदर्श है, क्योंकि आप इसे रैखिक रूप से लिख सकते हैं, और संकलक स्वचालित रूप से आपके कोड को एक राज्य मशीन के रूप में फिर से लिखता है - जैसे कोरआउट या उन्नत एकता में प्रयुक्त "उपज" का संस्करण।
• सिंक्रोनाइज़ेशन संदर्भों का अर्थ है कि आप एसिंक्स कोड लिख सकते हैं जो एक विशिष्ट संदर्भ में निष्पादित होता है। उदाहरण के लिए, आपके पास गेम-बाउंड निष्पादन, या आईओ-बाध्य निष्पादन, या मुख्य बनाम पृष्ठभूमि थ्रेड बाध्य निष्पादन हो सकता है, यह सिस्टम का हिस्सा है।
• तैनाती करते समय, आपके पास एलएलवीएम के साथ या उसके बिना जेआईटी संकलन, या स्थिर संकलन (एओटी) का विकल्प होता है, इसलिए आप सी ++ जितना तेज़ हो सकते हैं, इस तथ्य को संशोधित करें कि सी # सरणी सीमा जांच करता है (उस ने कहा, यदि आप मूल का उपयोग करते हैं बफ़र्स, आपको सुरक्षा की कीमत पर अपना प्रदर्शन वापस मिलता है)
• पिछले कुछ वर्षों में, मोनो के मोबाइल पर मजबूत फोकस को देखते हुए, मोनो के जीसी को सर्वर के लिए नहीं, बल्कि इंटरेक्टिव वर्कलोड के लिए ट्यून किया गया है। हमारी नई जीसी छोटी नर्सरी के साथ पीढ़ीगत है जिसे बहुत जल्दी एकत्र किया जा सकता है और पूरे ढेर को स्कैन करने की आवश्यकता नहीं होती है।

क्यों माइक्रोसॉफ्ट कई सीएलआर विकसित कर रहा है (हमारे पास तीन हैं: जेआईटी वर्कलोड के लिए कोरसीएलआर; कोरआरटी ​​परिवार, यूडब्ल्यूपी में स्थिर संकलन के लिए; मोबाइल वर्कलोड के लिए मोनो) ऐसा इसलिए है क्योंकि वे सभी सर्वर थोड़ा अलग उद्देश्यों के लिए हैं। जहां संभव हो, आंतरिक अभिसरण कर रहे हैं, उदाहरण के लिए, मोनो ने अब लगभग 60% कोर कोड को कोड के साथ बदल दिया है जो सीधे शेष .NET के साथ साझा किया जाता है। यह पता लगाने की बात है कि कौन सा कार्यभार आपके लिए बेहतर है।

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

अच्छी खबर यह है कि एक वीएम को दूसरे के लिए स्वैप करना, या दोनों का समर्थन करना कुछ दिनों के काम का है, इसलिए आप खुद को एक विशिष्ट कार्यान्वयन में बंद नहीं कर रहे हैं।

@migueldeicaza स्वागत है! बहुत बढ़िया है कि आपने हमारी चर्चा में भाग लेने का फैसला किया और आप गोडोट में रुचि रखते हैं: +1: आशा है कि आप कुछ समय के लिए हमारे साथ रहेंगे :)

अच्छे ब्रेकडाउन के लिए धन्यवाद @migueldeicaza! मेरे पास आपके या अन्य मोनो डेवलपर्स के लिए दो त्वरित प्रश्न हैं।

1) विजुअल स्टूडियो के साथ विंडोज़ पर एम्बेडेड मोनो को डीबग करने के लिए वर्तमान सेटअप क्या है? एकता में उनका प्लगइन है, लेकिन मुझे प्लगइन्स के अलावा कुछ भी नहीं मिला है जो लिनक्स/ओएसएक्स मशीनों से जुड़ते हैं।

2) रनटाइम-रीकंपाइलिंग को संभालने का अनुशंसित तरीका क्या है (संकलन, अनलोडिंग और रीलोडिंग गेमप्ले या संपादक में टूल प्लगइन्स के लिए एक असेंबली कहें)? सी # (बहुत) दुर्भाग्य से एक असेंबली का खुलासा नहीं करता है। अनलोड() विधि और ऐपडोमेन और क्रॉस ऐपडोमेन मुद्दों से निपटना इस स्थिति के लिए अत्यधिक परेशान प्रतीत होता है।

संदर्भ के लिए, न केवल एकता मोनो का उपयोग करती है - https://github.com/xamarin/urho (C#/Urho3D इंजन के लिए मोनो बाइंडिंग) - वह एक MIT लाइसेंस पर है, इसलिए हम उनके समाधान को आसानी से देख सकते हैं।

मेरे दो सेंट:

सी # अन्य समान-स्तरीय भाषाओं की तुलना में गेम प्रोग्रामिंग के लिए कहीं बेहतर है क्योंकि यह कस्टम मान प्रकारों का समर्थन करता है। यह प्रदर्शन के लिए एक अत्यंत महत्वपूर्ण विशेषता है, जिसका जावा (और सामान्य रूप से JVM) का शाब्दिक रूप से _no_ विकल्प है।

आपको मिला:

• स्टैक-आवंटित गणित प्रकार, जो बिना किसी ढेर आवंटन के गणितीय संचालन और अस्थायी वस्तुओं का समर्थन करते हैं।
• अनुकूलित, कैश के अनुकूल निरंतर संग्रह।
• मूल्य प्रकारों का उपयोग करने वाले जेनरिक (आदिम प्रकारों सहित)

उसके ऊपर, C# में अन्य विशेषताएं हैं जो आपके जीवन को आसान बनाती हैं। मुझे सी # के स्थान पर जावा का उपयोग करने की कोई योग्यता नहीं दिखती है जब सी # बस जावा को _game_ प्रोग्रामिंग में महत्वपूर्ण हर चीज पर हरा देता है।

नमस्ते,
मैंने उपरोक्त सभी को नहीं पढ़ा है (बस बहुत ज्यादा :))
लेकिन मेरे पास कुछ छुट्टियों के दिन थे इसलिए मैंने गोडोट के लिए प्रोटोटाइप मॉड्यूल बनाया जो एमएसडॉटनेटहोस्ट के रूप में कार्य करता है, इसलिए मैं कुछ निष्कर्ष प्रदान कर सकता हूं, शायद वे सहायक हों। दुख की बात है कि मेरे हॉलीडे समाप्त हो गए और फिर से पैसे के लिए कोड करने के लिए ive :), लेकिन यह मजेदार है / था :)

वर्तमान स्थिति है:
ओ) मॉड्यूल नोड घटनाओं को नेटकोड में उजागर करने के लिए नोड क्लास का विस्तार करता है
(init, tree_entered, तैयार, प्रक्रिया, निश्चित प्रक्रिया...)),
ओ) "नेट होस्ट/रैपर मॉड्यूल" किया गया (माइक्रोसॉफ्ट डॉटनेट होस्ट मेकेनिज्म का उपयोग करके)
यह एक गतिशील पुस्तकालय में समाहित है, इसलिए बाद में मोनो पर स्विच करना आसान होना चाहिए
ओ) डॉटनेट विधियों को बाध्य किया जाता है और कहा जाता है (init, tree_entered, तैयार, प्रक्रिया, निश्चित प्रक्रिया ....)
o) नोड वर्ग को लपेटा जाता है और netAssembly (प्रोटोटाइपिंग के लिए मैनुअल लिखित कोड) के लिए बाध्य किया जाता है।
ओ) गोडोट को कॉल (नेटकोड से) एक स्व-लिखित बाध्यकारी तंत्र के माध्यम से काम कर रहे हैं
(dll से godot-exe में) इसलिए exe को फ़ंक्शन निर्यात करने की आवश्यकता नहीं है।
o) msDotNet के उपयोग के कारण निकट भविष्य के लिए यह विंडोज़ से बंधा हुआ है।

नेट को शामिल करने के लिए मेरा रोडमैप होगा:

1. Microsoft .Net होस्टिंग तंत्र का उपयोग करके गोडोट के लिए मॉड्यूल (किया गया)
2. रैपिन गोडॉट क्लासेस
   (मेरी वर्तमान स्थिति: एक रैपर जनरेटर लिखना, जो गोडोट सी ++ कोड को पार करता है,
   पार्सिंग हो चुकी है, पीढ़ी चल रही है)
3. प्रोजेक्ट को प्रोटोटाइप स्थिति से बाहर निकालें (किनारों को पूरा करें, इसका परीक्षण करें ...)
4. विंडोज़ बॉन्ड से छुटकारा पाने के लिए मोनो होस्टिंग तंत्र लिखें
5. xamarin/monodev (एकता बनाम-प्लगइन की तरह) से छुटकारा पाने के लिए किसी भी तरह विजुअल स्टूडियो को मोनो डीबग करने में सक्षम बनाता है।
6. सैकड़ों नए godot .net डेवलपरों का मज़ा लें :)

कुछ सवाल:

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

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

कुछ अतिरिक्त विचार:

माइक्रोसॉफ्ट .नेट बनाम मोनो:

मुझे लगता है कि इससे कोई फर्क नहीं पड़ता कि आप मोनो या एमएसडॉटनेट का उपयोग करते हैं, क्योंकि ज्यादातर मामलों में डॉटनेट कोड दोनों पर अपरिवर्तित चलता है। दोनों का समर्थन करने का एकमात्र प्रयास उनमें से प्रत्येक के लिए "होस्ट" लिखना है (यह "GodotDotNet" का सबसे छोटा हिस्सा है)। मैंने प्रोटोटाइप के लिए msDotNet को चुना।
ठीक है, मोनो कई प्लैटफॉर्म एमएसडॉटनेट केवल विंडोज़ का समर्थन करता है, तो एमएसडॉटनेट का समर्थन/उपयोग क्यों करें?
उत्तर: उत्पादकता, डिबगिंग

एमएसडॉटनेट:
विशेष रूप से डॉटनेट मॉड्यूल को लिखते/प्रोटोटाइप करते समय मुझे तेज़ संकलन और डीबगथ्रू चाहिए/चाहते हैं, इसका मतलब है कि आपके डीबगर को सी ++ से नेटकोड में कूदना चाहिए और इसके विपरीत।
मैं विजुअलस्टूडियो चुनता हूं, क्योंकि यह दोनों को डीबग कर सकता है। लेकिन केवल तभी जब आप msDotNet का उपयोग करते हैं।
ऐसा करने से आप नेटकोड का एक टुकड़ा बदलते हैं, रन हिट करते हैं और 1sek में! इसका संकलित और चल रहा है !!! गोडोट में डिबग करने की संभावना सहित। (यदि आपने गोडोट में कुछ नहीं बदला है, तो आपको आमतौर पर 30sek से 1 मिनट तक इंतजार करना होगा ... अरे आप धीमे स्कैन्स! :))

मोनो:
मोनो अंतिम लक्ष्य होना चाहिए, इसके बारे में कोई चर्चा नहीं है (प्लेटफ़ॉर्म स्वतंत्रता), लेकिन:
यदि कोई मोनो का उपयोग करता है, तो जब मैं डिबगिंग की बात करता हूं तो आपको एक बड़ी समस्या होती है: मोनो का अपना डिबगिंग तंत्र होता है!
मेरे लिए यह उत्पादकता के लिए एक बड़ी हिट है, क्योंकि जब तक आप विजुअलस्टूडियो के लिए एक मोनोडेबग-प्लगइन नहीं लिखते (एकता ने ऐसा किया) आप विजुअल स्टूडियो में मोनो होस्टेड नेटकोड को डीबग नहीं कर सकते हैं और सी ++ कोड में डीबग नहीं कर सकते हैं (हैक समाधान हैं लेकिन ...)
मैंने एक मोनो आधारित समाधान स्थापित करने की कोशिश की, लेकिन मैं समानांतर, विजुअलस्टूडियो (सी ++ के लिए) और xamarin/monodev (नेटकोड) दोनों का उपयोग करने में समाप्त हुआ।

निष्कर्ष:
प्रोटोटाइप स्थिति: msDotNet
लेटरन: मोनो, उन उपयोगकर्ताओं के लिए जो गोडोट/सी++ और प्लेटफॉर्म स्वतंत्रता में डिबग करने में रुचि नहीं रखते हैं
उसके बाद: मोनो डीबग करने के लिए एक बनाम-प्लगइन बनाएं

सी # बनाम जावा:
उत्तर स्पष्ट है सी #! जावा स्क्रिप्किड्स के लिए है! (ओह सी ++ कोडर सी # देवों के बारे में क्या सोचते हैं :))
नहीं, यह मजाक था :)
मैं चर्चा को नहीं समझता... जब .net प्रणाली लागू की जाती है तो आप प्रत्येक भाषा का उपयोग कर सकते हैं जो डॉटनेट का समर्थन करती है जिसमें दोनों भाषाएं और भी बहुत कुछ शामिल हैं।
जावा सिस्टम समर्थित होने पर ऐसा नहीं है ...

@ ज़िफ्लिन :
प्रश्न 1:
क्या वह खोज भी थी ... केवल monoRemotedebugger (नहीं) समाधान एटीएम है :(
मेरी सिफारिश है, जैसा कि ऊपर बताया गया है: प्रोटोटाइप के लिए माइक्रोसॉफ्ट डॉटनेट होस्टिंग का उपयोग करें
फिर कुछ बाद के बिंदु पर मोनो पर स्विच करें।
विकल्प:
अपने हैक किए गए मोड में xamarin शुरू करें, इसे लोकलहोस्ट को सुनने दें, ब्रेकपॉइंट सेट करें, फिर अपने प्रोजेक्ट को बनाम ive में शुरू करें, इसका परीक्षण किया, यह काम करता है, लेकिन ...
मेरे लिए इसका कोई समाधान नहीं है! मैं एक "1 सेकंड में हिट रन और डिबग" चाहता हूं - तंत्रवाद और यह 1 क्लिक के साथ!
मेरे पास अपने खाली समय में ज्यादा समय नहीं है, इसलिए उत्पादकता मेरा मुख्य लक्ष्य है।

प्रश्न 2:
मोनो को अभी तक अच्छी तरह से नहीं जानता है, लेकिन मुझे लगता है कि आपको सी ++ में इसे करना है, मोनो होस्टिंग लागू करें, इसे सी ++ में "बाहर" से प्रबंधित करें।

@CharlesWoodhill आधिकारिक C# -बाइंडिंग पहले से ही WIP हैं और इसे यहां https://github.com/neikeq/GodotSharp/ पर देखा जा सकता है।

कूल टीएनएक्स, तो मुझे पता है कि मैं अपने अगले कुछ हॉलीडे कैसे बिताता हूं;)

नमस्ते, मैं अभी GodotSharp पर आया हूं लेकिन यह गिर गया।

यह गिरा दिया।

आईआरसी पर मैंने जो आधिकारिक संस्करण सुना है वह कुछ इस प्रकार था:

@neikeq अधूरे कोड को आगे बढ़ाना पसंद नहीं करता है, इसलिए वह अपनी स्थानीय शाखा में काम करता है

खैर, यह जानकर अच्छा लगा, मैं अपना खुद का मॉड्यूल करने वाला था, लेकिन मुझे लगता है कि मैं गोडोट 2.2 या 3.0 के लिए भी हो सकता हूं

कोई 2.2 रिलीज़ नहीं होगी, गोडोट देवों ने सभी 2.2 सुविधाओं को 3.0 में स्थानांतरित कर दिया।

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

मेरी मुख्य चिंता यह है कि अतिरिक्त सी # समर्थन के साथ जीडीस्क्रिप्ट को पीछे छोड़ दिया जाएगा या एकता डेवलपर्स की बाढ़ के बाद कम विकास दिखाई देगा। सी # एक अच्छी भाषा है लेकिन मेरी निजी पसंदीदा नहीं है

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

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

@zaywolfe अन्य उपयोगकर्ताओं द्वारा आपकी चिंता कई बार व्यक्त की गई है। आपको किसी बात की चिंता करने की आवश्यकता नहीं है। गोडोट में जीडीस्क्रिप्ट मुख्य भाषा बनी रहेगी।

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

इसके अलावा, मैं यह उल्लेख करना चाहूंगा कि कभी-कभी मैं कुछ सरल सॉफ्टवेयर प्रोटोटाइप के लिए भी गोडोट का उपयोग करता हूं। इस प्रकार, एक गहन रूप से एकीकृत प्रोग्रामिंग भाषा संभवतः इंजन के भीतर सॉफ्टवेयर विकास के लिए दरवाजे खोल देगी। यह वास्तव में एक यूनिटी किलर होगा। (यदि, निश्चित रूप से, जावा या सी ++ चुना गया था)

आपकी कड़ी मेहनत के लिए वफादार डेवलपर्स का धन्यवाद, मैं आप सभी की ओर देखता हूं, और मैं भविष्य में अपडेट की गई रिलीज की प्रतीक्षा करता हूं!

@VenHayz मुझे नहीं पता कि आप गोडोट दस्तावेज़ पढ़ते हैं, लेकिन आप गोडोट के पहले संस्करण के बाद से पहले से ही सी ++ में अपने गेम लिख सकते हैं - http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

Microsoft .net कोर का उपयोग करने के बारे में क्या? यह क्रॉस प्लेटफॉर्म और प्रदर्शन केंद्रित है, साथ ही यह खुला स्रोत भी है और सक्रिय रूप से विकसित हो रहा है

नमस्ते बस एक यादृच्छिक आदमी गुजर रहा है

मैं आपको बताना चाहता हूं कि मैं गोडोट का उपयोग नहीं कर रहा हूं क्योंकि मुझे आपके द्वारा उपयोग की जाने वाली स्क्रिप्ट भाषा पसंद नहीं है

यदि आप जावा या सी # जोड़ते हैं, तो मैं आपकी घोषणा के ठीक बाद गोडोट स्थापित और उपयोग करूंगा :)

@RUSshy अलविदा, यह आपका नुकसान है, गोडोट बहुत बढ़िया है, जीडीस्क्रिप्ट बहुत अच्छा है, यदि आप एक वास्तविक प्रोग्रामर हैं, तो आपको किसी भी परियोजना को शुरू करने के लिए पर्याप्त से अधिक जानने में सचमुच दो घंटे लगेंगे। असली प्रोग्रामर को कई भाषाओं में महारत हासिल करनी चाहिए, आप अपने जावा/सी # से चिपके रह सकते हैं और हमेशा के लिए शौकिया के रूप में गुजरने वाले "यादृच्छिक" लड़के बन सकते हैं। मैं कठोर होने की कोशिश नहीं कर रहा हूं, सिर्फ तथ्य बता रहा हूं। यदि आपको इस इंजन के बारे में कुछ पसंद नहीं है, तो कुछ कोड के साथ योगदान दें, यह अधिकांश अन्य इंजनों के विपरीत मुफ़्त है।

मार्केटिंग के देवता C# के पक्षधर हैं। :हंसना:

@RebelliousX जावा या सी # चुनने का मतलब है कि आपके पास उपयोग करने के लिए लाइब्रेरी का लोड होगा

अपने आप को घर पर बनी स्क्रिप्ट भाषा तक सीमित रखना बेकार है, आपका नया ज्ञान कहीं और लागू नहीं होगा, और आप बहुत सारे पुस्तकालय नहीं खोज पाएंगे, या अपने ज्ञान या मौजूदा शिक्षण संसाधनों का पुन: उपयोग नहीं कर पाएंगे।

पसंद पागल है आजकल दिमाग बंद मत करो

@RUSshy क्या तुम मुझसे मजाक कर रहे हो? मैंने (और कई अन्य) ने सी # पर जीडीस्क्रिप्ट के लाभों के बारे में स्पष्टीकरण के पृष्ठ सचमुच लिखे हैं और आपको लगता है कि आप पहले कुछ भी पढ़े बिना चर्चा को एक छोटे पैराग्राफ के साथ हल कर सकते हैं?

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

सच में, कुछ लोगों की दुस्साहस...

विभिन्न स्थानों पर कई बार कहा गया है कि C# इंटीग्रेशन मॉड्यूल पर काम चल रहा है। यह उतनी ही तेजी से जाता है, जितना लोगों को इसे करने में समय लगता है। इसे तेज़ बनाने का एकमात्र तरीका उस एकीकरण में योगदान करना है :)

@Warlaan दूसरे बिंदु के बारे में: यदि आपने पहले सी # में कोड का भार लिखा है, तो आप इसे तब तक पुन: उपयोग नहीं कर सकते जब तक कि आप इसे पोर्ट नहीं करते। इसका उपयोग करने में सक्षम होने के लिए आपको पुस्तकालय के कोड को समझने की भी आवश्यकता नहीं है। मुद्दा यह है कि, अगर आपको पहले सी # में कुछ चाहिए (एक फ़ाइल या पुस्तकालयों का एक सेट, संभावित रूप से बंद स्रोत), तो आपको या तो इसे पोर्ट करना होगा, सी # रनटाइम एम्बेड करना होगा या सी कार्यान्वयन ढूंढना होगा। यह असंभव नहीं है, लेकिन समय लेने वाला है।
इसका मतलब यह नहीं है कि गोडोट मौजूदा कामों के भार का उपयोग नहीं कर सकता है ... सी/सी ++ में उनमें से बहुत से भी हैं।

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

स्क्रिप्टिंग के मामले में गोडोट का भविष्य पहले से ही स्पष्ट है:

• जीडीस्क्रिप्ट मुख्य भाषा के रूप में रहेगा और इसे अनुकूलित करने के लिए योजनाएं या विचार हैं (लेकिन यह उस पर चर्चा करने के लिए सही जगह नहीं है)।
• 3.0 से, C# को स्क्रिप्टिंग विकल्प के रूप में समर्थित किया जाएगा। हम मोनो रनटाइम के कारण होने वाले अतिरिक्त आकार को उन लोगों पर थोपने से बचने के लिए अलग-अलग बायनेरिज़ प्रदान करेंगे जो इसका उपयोग नहीं करेंगे।
• DLScript भी काम पर है। यह लोगों को स्क्रिप्टिंग के लिए साझा पुस्तकालयों का उपयोग करने की अनुमति देगा। इन पुस्तकालयों को सी लिंकेज और साझा पुस्तकालयों का समर्थन करने वाली किसी भी भाषा में लिखा जा सकता है (रस्ट और डी जैसी भाषाओं की अपेक्षा करें)। यह अभी तक स्पष्ट नहीं है कि क्या यह 3.0 के लिए तैयार होगा (जब तक कि मैं पुराना न हो जाऊं)।
• मत भूलो कि 3.0 में भी विजुअल स्क्रिप्टिंग होगी!

अगर कोई कुछ और योगदान देने की योजना बना रहा है, तो उस पर चर्चा करने के लिए यह सही जगह नहीं होगी।

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

माना।

कृपया सी # एकीकरण स्रोत कोड के लिए लिंक प्रदान कर सकते हैं?

https://github.com/neikeq/GodotSharp

GodotSharp एकीकरण कितना कार्यात्मक है? परीक्षण के लिए उपयोग करने के लिए तैयार है?
गोडोट मास्टर से सोर्स बिल्ड के साथ इस्तेमाल किया जा सकता है?

@nictaylr यह वर्तमान में मास्टर के साथ नहीं बन रहा है। यदि आप इसका परीक्षण करना चाहते हैं तो आपको 2.2-विरासत का उपयोग करने की आवश्यकता है। यह उस संस्करण के साथ बहुत अच्छी तरह से काम कर रहा है

मैं इसे अप्रैल में 3.0 अल्फा के लिए तैयार करने के लिए काम कर रहा हूं।

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

वैसे भी, बस एक त्वरित सुझाव या शायद विचारों के लिए।

@VenHayz मैं ऐसे मॉड्यूल पर काम कर रहा हूं जो स्क्रिप्ट के लिए साझा पुस्तकालयों के उपयोग को सक्षम बनाता है । मैंने सी ++ को इसके साथ उपयोग करने में आसान बनाने के लिए पहले से ही कुछ प्रयास किए हैं। आप उन पुस्तकालयों को भी बनाने के लिए डी का उपयोग कर सकते हैं। यदि आप डी बाइंडिंग बनाने में रुचि रखते हैं तो मुझे आईआरसी या डिस्कॉर्ड पर हिट करें।

@karroffel यह वास्तव में अच्छा है। मुझे पुस्तकालयों और एपीआई ("बाइंडिंग" के आपके उल्लेख का संदर्भ) लिखने का कोई अनुभव नहीं है, हालांकि, मैं शायद एक दिन के लिए इसमें शोध कर सकता हूं और इसे कर सकता हूं; मैं गर्व से एक त्वरित शिक्षार्थी हूँ। यदि आप बुरा न मानें तो मैं डिस्कॉर्ड पर आपसे संपर्क करना चाहूंगा? मेरी कलह: _hasCat#3941

@VenHayz मैं आपको नहीं जोड़ सकता, आप दूसरों को आपको जोड़ने की अनुमति नहीं दे रहे हैं। Karroffel#8409 या गोडोट सर्वर से जुड़ें

@neikeq क्या आपका GodotSharp कोडबेस को रेपो करता है जिसका उपयोग गोडोट 3.0 में सी # समर्थन के लिए किया जा रहा है? सिर्फ इसलिए पूछ रहा हूं क्योंकि मैं इस बात का अंदाजा लगाने की कोशिश कर रहा हूं कि कौन सी सुविधाएँ उपलब्ध होंगी और यदि ऐसा है तो मैं उस कोडबेस के बारे में बताऊंगा। धन्यवाद!

मैं गोडोशार्प दिखता हूं, पुराना हो गया है? नयी विशेषता ? या विकास निर्माण में उपयोग करने के लिए तैयार है?

मैं अपने लिए सॉरस से गोडोसर्प कैसे संकलित कर सकता हूं?

@nictaylr आपको 2.2-विरासत शाखा को विकसित निर्माण के रूप में उपयोग करने की आवश्यकता होगी।

मुझे लगता है कि मैंने यह पता लगाने के लिए पर्याप्त पढ़ा कि किसी और ने इसका उल्लेख किया है या नहीं।

मैं व्यक्तिगत रूप से अभी तक एक और भाषा सीखना नहीं चाहता हूं जिसका मैं कहीं और उपयोग नहीं कर सकता। मैं बहुत सारी 3D प्रोग्रामिंग करने की योजना नहीं बना रहा हूं, बस कुछ चीजें इधर-उधर।

हां, इसके खिलाफ बहुत सारे प्रतिवाद हैं लेकिन ... यह एक ओपन-सोर्स प्रोजेक्ट है। नई प्रोग्रामिंग भाषा में योगदान देने वाले किसी व्यक्ति से घृणा करने की कोई आवश्यकता नहीं है।

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

जीडीस्क्रिप्ट के बजाय सी # के लिए भी पूछना क्योंकि "आप सीखना नहीं चाहते" वास्तव में एक बेवकूफ तर्क है। खेल विकास में मुझे पता है कि सभी भाषाओं में से जीडीस्क्रिप्ट में कम से कम सुविधाएं हैं और सी # में अब तक सबसे ज्यादा है। यदि आप सीखना नहीं चाहते हैं तो आपको GDscript के लिए आभारी होना चाहिए।

मैं वास्तव में इस चर्चा को बार-बार गर्म नहीं करना चाहता, इसलिए कृपया यदि कोई इस सूत्र पर टिप्पणी करना चाहता है तो कृपया इसे ऊपर से पढ़ें।

जीडीस्क्रिप्ट के बजाय सी # के लिए भी पूछना क्योंकि "आप सीखना नहीं चाहते" वास्तव में एक बेवकूफ तर्क है।

मुझे सी # सीखने में कोई फर्क नहीं पड़ता क्योंकि मैं इसे कहीं और इस्तेमाल करने में सक्षम हो सकता हूं।

बस धागे को बंद करो, यह मतलबी हो रहा है।

यह सच है कि इस धागे ने अपना उद्देश्य पूरा कर लिया है, आइए इसे लॉक करें।