Godot: गैर-प्रोग्रामर के लिए गेम डिज़ाइनर का उपयोग करना आसान है

किसी बिंदु पर दृश्य स्क्रिप्टिंग की योजना बनाई गई है

बुधवार, 14 जनवरी, 2015 को सुबह 6:20 बजे, RyanBram [email protected] ने लिखा:

हाय, गोडोट डेवलपर्स।

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

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

मेरा सुझाव है कि उपयोग में आसान गेम डिज़ाइनर/संपादक प्रदान करें
नए प्रोग्रामर के कार्य को आसान बनाने के लिए सहज ज्ञान युक्त GUI और पूर्वनिर्धारित वर्ग। अधिक
प्रोग्रामर का अर्थ है अधिक उपयोगकर्ता (क्योंकि गोडोट उपयोगकर्ता गेम प्रोग्रामर है)।

मैं एक गेम इंजन को जानता हूं जो इस काम को अच्छी तरह से करता है। यह रूबी से लिखा गया है,
मूल रूप से जापान से, और दुनिया भर में अंग्रेजी में अनुवादित। इसे आरपीजी कहा जाता है
मेकर वीएक्स ऐस
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace. इसके बावजूद
अपने नाम के आगे आरपीजी शब्द, यह गैर-आरपीजी बनाने के लिए पर्याप्त सक्षम है
इसके बिल्ट-इन रूबी गेम स्क्रिप्टिंग सिस्टम (आरजीएसएस) के साथ गेम।

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706f6f6f61636473

निम्नलिखित सूची आरपीजी निर्माता इंजन के साथ बनाए गए खेलों का उदाहरण है:

1. एलेफ (आरपीजी एडवेंचर) http://www.pioneervalleygames.com/
2. कोई मैनेटेस वादा नहीं किया (आर्केड) http://rpgmaker.net/games/5102/
3. रैगरोक्क - बेस्टियारियम (कार्ड गेम) http://rpgmaker.net/games/5808/
4. हमले के तहत पृथ्वी! (शूटर) http://rpgmaker.net/games/6561/
5. टेरा (विजुअल नॉवेल) http://rpgmaker.net/games/3956/
6. मन की यादें (एक्शन आरपीजी)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - द बिगिनिंग (डरावनी) http://rpgmaker.net/games/6493/

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

सादर, रयान

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220.

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

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

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

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

@SolarLune : जब आप a . के साथ मिलकर काम करते हैं तो विजुअल स्क्रिप्टिंग उपयोगी होती है
प्रोग्रामर, जो आपके साथ खेलने के लिए एक साथ रखने के लिए ब्लॉक बना सकता है। इस
अवास्तविक में दृष्टिकोण उपयोगी है। मुझे नहीं लगता कि इसे बदलना संभव है
प्रोग्रामिंग पूरी तरह से (जब तक कि आप एक मर्दवादी नहीं हैं), लेकिन यह काम कर सकता है
कुछ लोग गैर-प्रोग्रामर के लिए भी टेम्पलेट ब्लॉक बनाते हैं।

बुधवार, 14 जनवरी, 2015 को शाम 4:23 बजे, TheoXD [email protected] ने लिखा:

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

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -69974733।

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

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

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

किसी बिंदु पर दृश्य स्क्रिप्टिंग की योजना बनाई गई है

सरल और सकारात्मक प्रतिक्रिया के लिए धन्यवाद।

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

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

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

मैं ओकाम स्टूडियो के स्टीम की तरह होने के उस विचार के बारे में मुस्कुराया ... :))

1/14/2015 को 5:20 अपराह्न को, रयानब्राम ने लिखा:

हाय, गोडोट डेवलपर्स।

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

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

मेरा सुझाव है कि उपयोग में आसान गेम डिज़ाइनर/संपादक प्रदान करें
नए प्रोग्रामर के कार्य को आसान बनाने के लिए सहज ज्ञान युक्त GUI और पूर्वनिर्धारित वर्ग।
अधिक प्रोग्रामर का अर्थ है अधिक उपयोगकर्ता (क्योंकि गोडोट उपयोगकर्ता गेम प्रोग्रामर है)।

मैं एक गेम इंजन को जानता हूं जो इस काम को अच्छी तरह से करता है। यह रूबी से लिखा गया है,
मूल रूप से जापान से, और दुनिया भर में अंग्रेजी में अनुवादित। यह है
आरपीजी निर्माता वीएक्स ऐस कहा जाता है
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace.
अपने नाम के आगे आरपीजी शब्द के बावजूद, यह काफी सक्षम है
इसके अंतर्निर्मित रूबी गेम स्क्रिप्टिंग सिस्टम (आरजीएसएस) के साथ गैर-आरपीजी गेम बनाएं।

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706f6f6f61636473

निम्नलिखित सूची आरपीजी निर्माता इंजन के साथ बनाए गए खेलों का उदाहरण है:

1. एलेफ (आरपीजी एडवेंचर) http://www.pioneervalleygames.com/
2. कोई मैनेटेस वादा नहीं किया (आर्केड) http://rpgmaker.net/games/5102/
3. रैगरोक्क - बेस्टियारियम (कार्ड गेम) http://rpgmaker.net/games/5808/
4. हमले के तहत पृथ्वी! (शूटर) http://rpgmaker.net/games/6561/
5. टेरा (विजुअल नॉवेल) http://rpgmaker.net/games/3956/
6. मन की यादें (एक्शन आरपीजी)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - द बिगिनिंग (डरावनी) http://rpgmaker.net/games/6493/

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

सादर, रयान

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220.

असत्य में वास्तव में परियोजनाओं के लिए टेम्पलेट हैं चाहे आप करना चाहते हैं a
दृश्य स्क्रिप्टिंग या पूर्ण स्क्रिप्टिंग प्रकार का वर्कफ़्लो... और यहां तक ​​कि
दृश्य संपादन के लिए कोड के ब्लॉक दृश्य स्टूडियो के माध्यम से सुलभ हैं और be
अनुकूलित... :)

1/15/2015 को 3:44 पूर्वाह्न को, जुआन लिनिएत्स्की ने लिखा:

@SolarLune : जब आप a . के साथ मिलकर काम करते हैं तो विजुअल स्क्रिप्टिंग उपयोगी होती है
प्रोग्रामर, जो आपके साथ खेलने के लिए एक साथ रखने के लिए ब्लॉक बना सकता है।
इस
अवास्तविक में दृष्टिकोण उपयोगी है। मुझे नहीं लगता कि इसे बदलना संभव है
प्रोग्रामिंग पूरी तरह से (जब तक कि आप एक मर्दवादी नहीं हैं), लेकिन यह काम कर सकता है
कुछ लोग गैर-प्रोग्रामर के लिए भी टेम्पलेट ब्लॉक बनाते हैं।

बुधवार, 14 जनवरी, 2015 को शाम 4:23 बजे, TheoXD [email protected] ने लिखा:

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

@SolarLune https://github.com/SolarLune , गेम बनाना संभव है
गोडोट में और शीर्ष पर एक संपादक जोड़ें जो गेम को हर किसी के लिए संशोधित करने की अनुमति देता है
थोड़ा विवरण (ग्राफनोड्स और बाकी यूआई का उपयोग करके), और यहां तक ​​कि
करने की अनुमति
शीर्ष पर कुछ अतिरिक्त GDscript कोड लिखें, मुझे लगता है कि यह सबसे अच्छा है
पहुंचना,
एक पूर्ण गेम गेम (आरपीजी, एफपीएस, आरटीएस) को अलग से शिप करने के लिए और अनुमति दें
फेरबदल
इसके हर पहलू।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -69974733।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -69978224।

मैं ओकाम स्टूडियो के स्टीम की तरह होने के उस विचार के बारे में मुस्कुराया ... :))

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

असत्य में वास्तव में परियोजनाओं के लिए टेम्पलेट हैं चाहे आप करना चाहते हैं a
दृश्य स्क्रिप्टिंग या पूर्ण स्क्रिप्टिंग प्रकार का वर्कफ़्लो... और यहां तक ​​कि
दृश्य संपादन के लिए कोड के ब्लॉक दृश्य स्टूडियो के माध्यम से सुलभ हैं और be
अनुकूलित... :)

बढ़िया अगर यह गोडोट में उपलब्ध होगा।

सादर,
रयान

हाय रयान

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

गोडोट में विजुअल प्रोग्रामिंग, मुझे लगता है कि करना कुछ मुश्किल होगा (क्योंकि गोडोट 2 डी और 3 डी दोनों करता है इसलिए दायरा बहुत बड़ा है।)
इसके अलावा यह बहुत बाद में बनाया जाएगा जब इंजन के लिए सभी अंतर्निहित ब्लॉक जगह में होंगे।

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

हाय रयान

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

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

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

सादर,
रयान

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

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

बीजीई शायद यहां सबसे खराब उदाहरण है, क्योंकि यह लॉजिक ब्लॉक के साथ नोड आधारित दृष्टिकोण को संयोजित करने का प्रयास करता है। मैंने लिखा है कि यह बुरा क्यों है:
http://blenderartists.org/forum/showthread.php?323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

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

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

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

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

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

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

मैं थोड़ा अलग तरीका अपनाऊंगा। चूंकि गोडोट संपादक अपने आप संचालित होता है - शुद्ध जीडीस्क्रिप्ट में एक समान संपादक इंटरफ़ेस को फिर से बनाना आसान है।

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

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

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

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

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

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

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

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

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

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

मैं आपसे सहमत हूं कि इसे कलाकारों/डिजाइनरों के लिए डिजाइन किया जाना चाहिए।
लेकिन इस तर्क पर असहमत हैं कि शब्द = जटिलता।

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

प्लेमेकर और अन्य नोड आधारित प्रणालियों के लिए बहुत अधिक सीखने की आवश्यकता होती है, क्योंकि एक नोड को दूसरे नोड से जोड़ने के लिए आपको पहले यह समझने की आवश्यकता होती है कि क्या आप दोनों को जोड़ सकते हैं। यह केवल शर्त नहीं -> क्रिया है। नोड्स अधिक जटिल हैं और दृश्य संकेतों की कमी है। आपने प्लेमेकर में आइकन कहाँ देखे ??
इसमें गलती करना बहुत आसान है। इसमें लॉजिक पढ़ना ज्यादा कठिन है।
https://www.scirra.com/tutorials/top
मैं यह भी तर्क दूंगा कि क्योंकि C2 एक बेहतर डिज़ाइन किया गया विज़ुअल प्रोग्रामिंग टूल है, इसमें प्लेमेकर की तुलना में सक्रिय उपयोगकर्ताओं का एक बहुत बड़ा समुदाय है - भले ही यह इस समय 2d गेम तक सीमित है। वेब पर बहुत अधिक संख्या में वीडियो ट्यूटोरियल (प्लेमेकर की तुलना में अधिक लोग समझते हैं कि इसका उपयोग कैसे करें), बहुत अधिक पूर्ण परियोजनाएं, एक स्वस्थ सक्रिय बाजार स्थान और मंच, और डेवलपर्स और उपयोगकर्ताओं के बीच सभी सक्रिय संचार। इसलिए डेवलपर्स जानते हैं कि कलाकार उपयोगकर्ता क्या चाहते हैं।

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

मैं तर्क दूंगा कि किसी भी नोड आधारित प्रणाली की तुलना में इसमें तर्क स्थापित करने में कम काम लगता है।

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

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

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

https://www.youtube.com/watch?v=QP3YywgRx5A
क्रेडिट में नाथन वार्डन मैं हूँ

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

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

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

तो, 2 और कारण हैं कि एक नोड आधारित प्रणाली कलाकारों को क्यों पसंद आएगी:

1) वे दृष्टि से कहीं अधिक आकर्षक लगते हैं।
2) यह उस डिजाइन प्रतिमान के भीतर फिट बैठता है जिसका वे पहले से उपयोग कर रहे हैं। IE छायांकन और सम्मिश्रण

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

क्या आप वाकई जानते हैं कि Construct2 क्या है? आप इसके नाम की स्पेलिंग भी सही नहीं कर रहे हैं।
इसे "कन्स्ट्रक्टर" नहीं कहा जाता है।

मैं पूरी तरह से असहमत हूं कि हमें नोड्स के साथ जाना चाहिए क्योंकि "यह पहली नज़र में कोड जैसा नहीं दिखना चाहिए।"

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

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

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

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

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

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

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

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

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

यहां एक सरल उदाहरण दिया गया है जो आपके पास एक ऐसे हथियार पर हो सकता है जो केवल फायरिंग को संभाल सके। ध्यान दें कि यह सरल होने के साथ-साथ शक्तिशाली भी है और यह कोड जैसा कुछ भी नहीं दिखता है:

एक अंतिम नोट पर, आप ब्लॉक आधारित स्क्रिप्टिंग या नोड आधारित स्क्रिप्टिंग दोनों को इंटरफ़ेस के दृष्टिकोण से बहुत अच्छा बना सकते हैं, इसलिए मैं उस बिंदु पर बहस करने में अपना समय बर्बाद नहीं करूंगा।

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

@ब्लरीमाइंड ,

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

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

मैं व्यक्तिगत रूप से नहीं देखता कि हमारे पास दोनों क्यों नहीं हो सकते हैं, लेकिन डेवलपर्स के पास पहले से ही ऐसा करने के लिए पर्याप्त है, ऐसा जल्द ही नहीं होगा। यही कारण है कि मैंने एक अलग दृष्टिकोण का प्रस्ताव रखा जो प्रोग्रामर के सहयोग से गैर-प्रोग्रामर द्वारा संचालित तेजी से विकसित होगा।

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

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

उन दोनों को एक कलाकार को दिखाएँ और उनसे पूछें कि कौन सा स्पष्ट है।

हमें एक अधिक विस्तृत नोड सेटअप भी दिखाएं :) C2 स्क्रीनशॉट पूरे गेम लॉजिक को दिखाता है। आपकी एक ही घटना है। क्या आप एक ही तर्क को नोड्स के साथ एक स्क्रीनशॉट में फिट कर सकते हैं? मुझे ऐसा नहीं लगता।

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

मैं प्रोग्रामर नहीं हूं। मुझे वास्तविक कोड लिखने का कोई अनुभव नहीं है। फिर भी मैं आसानी से निर्माण 2 के साथ एक गेम बना सकता हूं और मेरे लिए नोड्स का उपयोग करना कठिन होता है- जब एक पूर्ण गेम की बात आती है।

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

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

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

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

क्या आपका मतलब कुछ ऐसा था?

जैसा कि मैंने ऊपर कहा, मुझे वास्तव में ब्लॉक/कंस्ट्रक्ट/code.org विधि पसंद है क्योंकि यह प्रोग्रामिंग सिखाने के लिए वास्तव में अच्छी तरह से काम करती है। मुझे नहीं लगता कि यह उन लोगों के लिए उपयुक्त है जो प्रोग्रामिंग को एक आवश्यक बुराई के रूप में देखते हैं।

@blurymind
इसका कोई मतलब नहीं है क्योंकि आप इससे परिचित नहीं हैं। जब मैं ऊपर निर्माण छवि को देखता हूं तो मुझे समान रूप से कोई सुराग नहीं है कि क्या हो रहा है, इसलिए नहीं कि यह खराब है, बल्कि इसलिए कि मैं इससे अपरिचित हूं।

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

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

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

(यह एक और चीज है जिसे आप ब्लॉक के साथ नहीं कर सकते हैं, उन्हें सैमस के जहाज की तरह दिखाना है, हाहा)

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

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

वैसे भी, मैं वास्तव में चर्चा का आनंद लेता हूं लेकिन मरे हुए घोड़े को मारने का कोई मतलब नहीं है, हाहा :)

हाँ मुझे भी मज़ा आता है। कोई बुरी भावना नहीं :)

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

फिर से आप हमें तीसरे व्यक्ति की कहानियां दे रहे हैं जो वास्तव में साक्ष्य द्वारा समर्थित नहीं हैं। यार को यहाँ ले आओ और उसे हमें बताओ कि वह एक को दूसरे के लिए क्यों पसंद करता है :)
तब आपके पास एक मजबूत मामला होगा। मुझे थीसिस का समर्थन करने वाला कोई तार्किक रूप से समझदार बिंदु नहीं मिल रहा है कि नोड्स अब तक अधिक सरल हैं।

हाँ, यह पहली नज़र में कम डराने वाला लगता है क्योंकि यह बहुत सारी जानकारी छिपा रहा है। मेरे द्वारा पोस्ट किए गए स्क्रीनशॉट में जो दिखाया गया है, उसकी तुलना में आपके उदाहरण बहुत सरल हैं। यह भ्रामक है।
यहाँ एक वीडियो है जो C2 में एक प्लेटफ़ॉर्मर के लिए तर्क स्थापित करने के लिए हॉट दिखाता है।
https://www.youtube.com/watch?v=5RlSmkSbleI
पहला मिनट छोड़ें :P

आइए सेब की तुलना संतरे से न करें।
Code.org, Construct2 से एक मौलिक रूप से भिन्न दृष्टिकोण है - यह Stencyl की तरह अधिक दिखता है और इसमें नोड्स के नुकसान में से एक है: आपकी स्थितियां और क्रियाएं स्पष्ट रूप से अलग नहीं हैं - इसलिए यह पता लगाना कठिन है कि आप क्या संलग्न कर सकते हैं। अच्छी तरह से डिज़ाइन किए गए विज़ुअल प्रोग्रामिंग टूल (मल्टीमीडिया फ़्यूज़न, कंस्ट्रक्शन 2, गेमडेवलप) उपयोगकर्ता के लिए स्पष्ट रूप से क्रियाओं से सभी अलग-अलग स्थितियां हैं। इससे तर्क बनाना बहुत आसान हो जाता है क्योंकि वे आपके लिए उस सॉफ़्टवेयर द्वारा व्यवस्थित किए जाते हैं जो अनुमान लगा रहा है कि आपको क्या आवश्यकता हो सकती है और इसे सही समय पर आपको दिखा रहा है। यह आपको मूर्खतापूर्ण गलतियाँ करने से भी रोकता है।

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

@blurymind , आपका मामला अब तक Construct2 का उपयोग करने वाले उपयोगकर्ताओं की मात्रा द्वारा समर्थित है, जो आमतौर पर सॉफ़्टवेयर के व्यवसाय मॉडल का परिणाम है और वे मार्केटिंग में कितने अच्छे हैं। व्यक्तिगत वरीयता (आपके तार्किक तर्क) C2 वर्कफ़्लो को गोडोट में बाध्य करने के लिए पर्याप्त नहीं है। लेकिन हालांकि यह एक अच्छा संदर्भ है।

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

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

" @blurymind -- || -- और आप दोनों प्रोग्रामर बनना स्वीकार करते हैं।" - मैं खुद को केवल एक प्रोग्रामर नहीं मानता, कला भी आप जानते हैं। मैं अपने अनुभव का उपयोग चीजों को वस्तुनिष्ठ दृष्टिकोण से देखने के लिए करता हूं।

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

मेरे कुछ कार्यों के कुछ लिंक यहां दिए गए हैं (क्रेडिट में नाथन वार्डन की तलाश करें)

वर्ल्ड बिल्डर (लगभग आधे शॉट्स में शामिल)
https://www.youtube.com/watch?v=VzFpg271sm8

टेडी स्कार्स (अधिकांश शॉट्स में शामिल था)
https://www.youtube.com/watch?v=qCXIzS_iY0k

हॉलमार्क क्राउन सेंटर (सांता के साथ तीसरा शॉट)
https://www.youtube.com/watch?v=biqBq3_Whqk

यहाँ मेरी लुई की इमारत का एक रेंडर है। अगर आप वर्ल्ड बिल्डर देखते हैं तो आपको कुछ कलाकृतियां दिखाई देंगी जिन्हें मैंने काट कर फिल्म में डाला था।

और पेश है एक टर्मिनेटर 1 स्टाइल एचके टैंक का अधूरा रेंडर, जो स्टीफन किंग्स क्रिस्टीन को चकनाचूर करता है। उन दोनों मॉडलों को मैंने किया है, लेकिन मुझे नहीं लगता कि शॉट में और कुछ था।

और भी बहुत कुछ जिनका मैं नाम ले सकता हूं, लेकिन मुझे लगता है कि बात बन गई है। :)

वैसे वे अद्भुत चित्र हैं- लेकिन फिर से आप अपने आप को और अधिक अधिकार देने के लिए ऐसा कर रहे हैं। यह तार्किक रूप से इस विचार का समर्थन करने में मदद नहीं कर रहा है कि नोड्स इवेंट शीट से बेहतर हैं :)

यदि आप नोड्स के साथ जाते हैं, तो आप किसी भी अन्य गॉड लानत 3D गेम इंजन की तरह होंगे जो दृश्य प्रोग्रामिंग का उपयोग करता है।

मुझे लगता है कि कई कारणों से यह एक अच्छा विचार नहीं है।

-हाल ही में अवास्तविक ने अपने इंजन को मुक्त कर दिया - यह भी मल्टीप्लेटफार्म है। यह BGE/Godot की तुलना में बहुत अधिक परिपक्व इंजन है। तो जब आप दृश्य प्रोग्रामिंग के लिए उनके दृष्टिकोण की नकल करते हैं तो आप उनके साथ सीधे प्रतिस्पर्धा कर रहे हैं।

-नोड्स लॉजिक शीट की तुलना में कम स्क्रीन कुशल हैं। उन्हें पढ़ना/अनुसरण करना कठिन होता है।

-स्किर्रा ने घोषणा की कि कंस्ट्रक्शन 3 मल्टीप्लेटफॉर्म होगा - संपादक विंडोज़, लिनक्स और मैक पर काम करेगा।
हालांकि वे ओपन सोर्स नहीं हैं।
https://www.construct3.com/

इसने सिर्रा समुदाय में टिप्पणियों की लहर पैदा कर दी। बहुत सारे उपयोगकर्ता ऐसी कई चीज़ें चाहते हैं जो गोडोट बिना विज़ुअल प्रोग्रामिंग के पेश कर सकता है:
- बेहतर प्रदर्शन के लिए html5 कंटेनरों के बजाय मूल exe फ़ाइलें-
3डी गेम के विकास के लिए समर्थन, इसे प्रोग्राम करने के लिए निर्माण में इवेंट शीट शैली का उपयोग करना:
https://www.scirra.com/forum/construct-3_t90881

अगर वे C2 के अंदर 2D टूल की तरह एक सरल और समझने योग्य 3D संपादक बनाते हैं, तो मैं इसका पूरी तरह से उपयोग करूंगा

मैंने एकता, ब्लेंडर, टॉर्क 3 डी, यूडीके की कोशिश की, क्योंकि वे अधिक विज्ञापित हैं और तथाकथित प्रसिद्ध देवों में से अधिकांश का उपयोग करते हैं ... और वे समान समस्याएं साझा करते हैं: वे उपयोगकर्ता के अनुकूल नहीं हैं (बिल्कुल भी) और यदि आप पहले कभी एक 3D गेम निर्माण एपीआई का उपयोग नहीं किया ... ठीक है, आप 3Doomed हैं (बुरा मजाक ikno)

बात यह है कि, एक बार जब आप मूल को कवर कर लेते हैं और आपको जटिल 2D गेम बनाने की स्वतंत्रता देते हैं, तो निर्माण बहुत सहज होता है, यह आपको एक ही परिणाम करने के लिए विभिन्न रास्ते देता है (इस बात का उल्लेख नहीं है कि घटना प्रणाली मेरे लिए समझ में आती है); जो विवरण है कि इनमें से अधिकांश अन्य उपकरण इसे कवर करने या इसे खराब बनाने में विफल होते हैं

अगर वे एक ही प्रवाह के साथ एक 3D इंजन बनाते हैं और महसूस करते हैं कि मैं C2 का उपयोग कर रहा हूं; तो क्यों न इसे आजमाएं?

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

यदि आप नोड्स के बजाय इसके लिए जाते हैं, तो आप पहले इंजन होंगे जो उस प्रोग्रामिंग डिज़ाइन के साथ पूर्ण 3D गेम विकास का समर्थन करते हैं। आप अवास्तविक (मुक्त), एकता (मुफ्त संस्करण उपलब्ध) के साथ प्रतिस्पर्धा करने के बजाय एक नए उपयोगकर्ता आधार पर टैप कर रहे होंगे।

वैसे वे अद्भुत चित्र हैं- लेकिन फिर से आप अपने आप को और अधिक अधिकार देने के लिए ऐसा कर रहे हैं।

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

हाल ही में अवास्तविक ने अपने इंजन को मुक्त कर दिया - यह भी मल्टीप्लेटफार्म है। यह BGE/Godot की तुलना में बहुत अधिक परिपक्व इंजन है। तो जब आप दृश्य प्रोग्रामिंग के लिए उनके दृष्टिकोण की नकल करते हैं तो आप उनके साथ सीधे प्रतिस्पर्धा कर रहे हैं।

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

लॉजिक शीट की तुलना में नोड्स कम स्क्रीन कुशल हैं। उन्हें पढ़ना/अनुसरण करना कठिन होता है।

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

यदि आप नोड्स के बजाय इसके लिए जाते हैं, तो आप पहले इंजन होंगे जो उस प्रोग्रामिंग डिज़ाइन के साथ पूर्ण 3D गेम विकास का समर्थन करते हैं।

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

इस बारे में मेरा विचार यह है कि यह सब उस दृष्टिकोण पर निर्भर करता है जो होना चाहता है
हल किया।

गेम मेकर जैसे एक्शन ब्लॉक दिलचस्प हैं, लेकिन मुझे लगता है कि यह अधिक है
प्रोग्रामिंग के प्रतिस्थापन के लिए डिज़ाइन किया गया।

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

गोडोट वास्तुकला के कारण, इसे जोड़ना भी बहुत आसान होगा इसलिए मैं दूंगा
यह 1.2 . में एक शॉट है

मंगलवार, 3 मार्च, 2015 को शाम 4:37 बजे, नाथन नोटिफिकेशन @github.com ने लिखा:

वैसे वे अद्भुत चित्र हैं- लेकिन फिर से आप इसे देने के लिए कर रहे हैं
अपने आप को अधिक अधिकार।

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

हाल ही में अवास्तविक ने अपने इंजन को मुक्त कर दिया - यह भी मल्टीप्लेटफार्म है। यह है एक
BGE/Godot की तुलना में बहुत अधिक परिपक्व इंजन। तो आप उनके साथ प्रतिस्पर्धा कर रहे हैं
सीधे दृश्य प्रोग्रामिंग के लिए उनके दृष्टिकोण की नकल करते समय।

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

लॉजिक शीट की तुलना में नोड्स कम स्क्रीन कुशल हैं। वे कठिन हैं
पढ़ें/अनुसरण करें।

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

यदि आप नोड्स के बजाय इसके लिए जाते हैं, तो आप पहले इंजन होंगे जो
उस प्रोग्रामिंग डिज़ाइन के साथ पूर्ण 3D गेम विकास का समर्थन करता है।

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -77017857।

मैंने प्लेमेकर को एक अच्छी कोशिश दी और मुझे कहना होगा कि मुझे यह पसंद आया - असत्य के किस्मत/ब्लूप्रिंट से ज्यादा।

प्लेमेकर में नोड्स कंटेनरों की तरह होते हैं जिनमें आप क्रियाएं करते हैं। कुछ क्रियाएं एक ऐसी स्थिति की जाँच कर रही हैं जो दूसरे नोड को जन्म दे सकती है।

चूंकि आप नोड कंटेनर स्वयं बनाते हैं और उन्हें नाम दे सकते हैं, उनमें क्रियाओं को अनुमानित फैशन (ऊपर से नीचे) में निष्पादित किया जाता है - यह ऐसा कुछ है जिसके साथ मैं रह सकता हूं। :)

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

कृपया प्लेमेकर पर गौर करें और एक नोड आधारित प्रणाली को लागू करें जो असत्य के बजाय इसके समान हो।
इसका फायदा यह है कि हम कम नोड्स के साथ और अधिक कर सकते हैं, वे पढ़ने और डिबग करने में आसान हैं, और अधिक अनुमानित हैं।

यह कैसे काम करता है इसका एक परिचय यहां दिया गया है:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

यह बहुत लचीला है और उपयोगकर्ता को खेल की कार्यक्षमता को आसानी से जोड़ने और साझा करने की अनुमति देता है - पुन: उद्देश्य के लिए आसान।

आकर्षक चर्चा। बस नोड्स और C2 की इवेंट शीट के अलावा किसी अन्य प्रकार की दृश्य स्क्रिप्टिंग को इंगित करना चाहते हैं, लेकिन स्क्रिप्ट के ब्लॉक जो पहेली टुकड़ों की तरह एक साथ फिट होते हैं। 2d इंजन Stencyl में प्रयुक्त http://www.stencyl.com/

एमआईटी स्क्रैच पर आधारित http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(ब्लॉक)

और यूनिटी में मैं व्यक्तिगत रूप से ब्लॉक्स http://www.plyoung.com/blox/ का उपयोग करता हूं

मैं व्यक्तिगत रूप से स्क्रैच जैसी "विज़ुअल" प्रोग्रामिंग से आश्वस्त नहीं हूं। मैं
लगता है कि यह प्रोग्रामिंग की तरह ही काफी है।
जिस तरह से अवास्तविक यह करता है मुझे लगता है कि खेल/स्तर डिजाइनरों के अनुकूल है

शनिवार, मार्च 21, 2015 को रात 11:57 बजे todheil [email protected] ने लिखा:

आकर्षक चर्चा। बस दूसरे प्रकार/दृश्य के रूप को इंगित करना चाहते हैं
नोड्स के अलावा अन्य स्क्रिप्टिंग लेकिन स्क्रिप्ट के ब्लॉक जो एक साथ फिट होते हैं जैसे
पहेली के टुकड़े। 2d इंजन Stencyl में प्रयुक्त http://www.stencyl.com/
[छवि: स्टेंसिल_ब्लॉक्स]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
एमआईटी स्क्रैच पर आधारित
http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(ब्लॉक)
[छवि: स्क्रैच_उदाहरण]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
और यूनिटी में मैं व्यक्तिगत रूप से ब्लॉक्स http://www.plyoung.com/blox/ का उपयोग करता हूं
[छवि: hello_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -84508001।

_ओकेमस्टूडियो_

अच्छी बात। मेरे लिए ब्लॉक कोड लाइनों और प्रवाह चार्ट के बीच का मध्य मार्ग हैं।

मुझे विजुअल प्रोग्रामिंग का स्क्रैच/स्टेन्सिल तरीका पसंद नहीं है। इसका लेआउट है
निर्माण 2 ब्लॉक और यहां तक ​​​​कि नोड्स की तुलना में दृष्टि से कठिन है। यह है
सचमुच पहेली टुकड़े को एक साथ रखना और यह के मुद्दे से ग्रस्त है
यह पता लगाना कि कौन सा टुकड़ा कहाँ फिट बैठता है। वे डालने के लिए सीधे नहीं हैं
साथ में

रविवार 22 मार्च 2015 को सुबह 5:46 बजे todheil [email protected] ने लिखा:

अच्छी बात। मेरे लिए ब्लॉक कोड लाइनों और प्रवाह के बीच का मध्य मार्ग हैं
चार्ट।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -84511415।

ठीक है, मैं अब सब कुछ नहीं पढ़ूंगा, लेकिन इस विषय पर सिर्फ मेरे 2 सेंट।

घटना आधारित इंजन प्रोटोटाइप और छोटे गेम प्रोजेक्ट बनाने के लिए बनाए जाते हैं
गोडोट जैसे इंजन हर तरह के प्रोजेक्ट बनाने के लिए बनाए जाते हैं

तो वे दो अलग-अलग चीजें हैं जिनमें दो अलग-अलग एप्रोच हैं, वे दो हैं
अलग-अलग टोल

सच कहूं, तो मैं उनका अच्छी तरह से उपयोग नहीं कर सकता। (घटना आधारित टोल)

मेरे लिए बेहतर तरीका दो समानांतर टोल हैं।

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

मुझे विजुअल प्रोग्रामिंग का स्क्रैच/स्टेन्सिल तरीका पसंद नहीं है। इसका लेआउट है
निर्माण 2 ब्लॉक और यहां तक ​​​​कि नोड्स की तुलना में दृष्टि से कठिन है। यह है
सचमुच पहेली टुकड़े को एक साथ रखना और यह के मुद्दे से ग्रस्त है
यह पता लगाना कि कौन सा टुकड़ा कहाँ फिट बैठता है। वे डालने के लिए सीधे नहीं हैं
साथ में

रविवार 22 मार्च 2015 को सुबह 5:46 बजे todheil [email protected] ने लिखा:

अच्छी बात। मेरे लिए ब्लॉक कोड लाइनों और प्रवाह के बीच का मध्य मार्ग हैं
चार्ट।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -84511415।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -84575752।

डेविड एगुइआर डी एक्विनो पाइवा

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

2015-03-26 13:15 GMT-03:00 डेविड पाइवा [email protected] :

ठीक है, मैं अब सब कुछ नहीं पढ़ूंगा, लेकिन इस विषय पर सिर्फ मेरे 2 सेंट।

घटना आधारित इंजन प्रोटोटाइप और छोटे गेम प्रोजेक्ट बनाने के लिए बनाए जाते हैं
गोडोट जैसे इंजन हर तरह के प्रोजेक्ट बनाने के लिए बनाए जाते हैं

तो वे दो अलग-अलग चीजें हैं जिनमें दो अलग-अलग एप्रोच हैं, वे दो हैं
अलग-अलग टोल

सच कहूं, तो मैं उनका अच्छी तरह से उपयोग नहीं कर सकता।

मेरे लिए बेहतर तरीका दो समानांतर टोल हैं।

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

मुझे विजुअल प्रोग्रामिंग का स्क्रैच/स्टेन्सिल तरीका पसंद नहीं है। इसका लेआउट है

निर्माण 2 ब्लॉक और यहां तक ​​​​कि नोड्स की तुलना में दृष्टि से कठिन है। यह है
सचमुच पहेली टुकड़े को एक साथ रखना और यह के मुद्दे से ग्रस्त है
यह पता लगाना कि कौन सा टुकड़ा कहाँ फिट बैठता है। वे डालने के लिए सीधे नहीं हैं
साथ में

रविवार 22 मार्च 2015 को सुबह 5:46 बजे todheil [email protected]
लिखा था:

अच्छी बात। मेरे लिए ब्लॉक कोड लाइनों और प्रवाह के बीच का मध्य मार्ग हैं
चार्ट।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
< https://github.com/ocamstudio/godot/issues/1220#issuecomment -84511415
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -84575752।

डेविड एगुइअर डी एक्विनो पाइवा

डेविड एगुइअर डी एक्विनो पाइवा

हे लोगों! अच्छी चर्चा यहाँ है :) मैं कुछ जोड़ना चाहता हूँ।

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

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

इससे यह मेरे अगले विचार का अनुसरण करता है:

सबसे अच्छी और सबसे सहज दृश्य प्रोग्रामिंग भाषा जो मुझे कोड करने से पहले मिली थी, वह है स्क्रैच/स्टेन्सिल पहेली/ब्लॉक तरीका। यहाँ पर क्यों:

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

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

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

बीटीडब्ल्यू। मैं इस अवसर का लाभ उठाना चाहता हूं और सभी गोडोट रचनाकारों और योगदानकर्ताओं को धन्यवाद देता हूं। आपने बहुत अच्छा काम किया: +1:

बीटीडब्ल्यू2. मैं अपनी अंग्रेजी के लिए माफी चाहता हूँ। मैं अपना सर्वश्रेष्ठ कर रहा हूं लेकिन मैं अभी भी मूर्खतापूर्ण गलतियां कर रहा हूं: रोओ:

यह निर्माण 2 या ब्लॉक्स हो - या तो मेरे लिए उन नोड ग्राफ़ की तुलना में अच्छे हैं।

यदि सिस्टम केवल कार्यों के लिए कंटेनरों के रूप में नोड्स का उपयोग करता है (जैसा कि कहा गया है) - जिस तरह से यह Playmaker में है, तो मैं इसके साथ ठीक रहूंगा।

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

यदि आप दृश्य प्रोग्रामिंग के लिए नोड्स का उपयोग करते हैं - सबसे बड़ी चुनौती उपयोगकर्ता से संवाद करना होगा कि किस क्रम में ईवेंट निष्पादित किए जा रहे हैं। एकता में - प्लेमेकर और ब्लॉक्स दोनों बहुत सफाई से करते हैं।

प्लेमेकर में नोड कंटेनरों के अंदर क्रियाओं को ढेर करके (राज्य - इसमें क्रियाएं शामिल हैं)। ब्लॉक्स में - जहां आपके पास ऐसे राज्य हैं जिनमें फ़ंक्शन हैं।

वे एकता की अधिकांश विशेषताओं तक पूर्ण पहुँच प्रदान करते हैं। यह गैर प्रोग्रामर के लिए वास्तव में अच्छा है।
blox को आगे "प्लाईगेम" के रूप में विकसित किया गया है - एक और यूनिटी एडऑन जिसमें blox+ कुछ कस्टम मेड स्क्रिप्ट हैं जिन्हें blox एक संपूर्ण आरपीजी हैक और स्लैश स्टाइल गेम बनाने के लिए एक्सेस कर सकता है।

एकता में ब्लॉक्स स्क्रैच/स्टेन्सिल ब्लॉक के समान है। ऐसा लगता है कि यहाँ बहुत सारे लोग हैं जो प्रोग्रामिंग की उस शैली को पसंद करते हैं :)
https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k

आशा है कि गोडोट देव इसे आजमाएंगे।
स्क्रैच बीटीडब्ल्यू (https://scratch.mit.edu/) तकनीक खुला स्रोत है! और अन्य लोग इसे अपनाते रहे हैं - केवल स्टेंसिल ही नहीं। Google को भी इसमें बहुत दिलचस्पी रही है:
https://developers.google.com/blockly/

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

http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

आईकैनस्क्रिप्ट के डेवलपर्स में से एक ने अपनी वीएस संपत्ति के बारे में यह कहा:

iCS2 की तकनीकी प्रगति ने इसे केवल एकता के उत्पाद से अलग कर दिया है जिससे बाजार के अवसरों में उल्लेखनीय वृद्धि हुई है। अंतिम दृष्टि यह है कि iCS2 एक विकास सहायता होगी जिसका उपयोग अन्य गेम इंजनों के साथ-साथ मानक विंडोज/ओएसएक्स/आईओएस/एंड्रॉइड अनुप्रयोगों के लिए स्क्रिप्ट बनाने के लिए किया जा सकता है।
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post-2124402

एक नोड मेस iCanScript क्या है!

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

शनिवार 23 मई 2015 को शाम 4:24 बजे todheil [email protected] ने लिखा:

आईकैनस्क्रिप्ट के डेवलपर्स में से एक ने अपनी वीएस संपत्ति के बारे में यह कहा:

iCS2 की तकनीकी प्रगति इसे केवल एकता से अलग करती है
उत्पाद महत्वपूर्ण रूप से> बाजार के अवसरों में वृद्धि। अंत दृष्टि
क्या यह है कि iCS2 एक विकास सहायता होगी जिसका >स्क्रिप्ट बनाने के लिए उपयोग किया जा सकता है
अन्य गेम इंजनों के साथ-साथ मानक >Windows/OSX/iOS/Android . के लिए
अनुप्रयोग।

http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post-2124402

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment-104895405 ।

मुझे लगता है कि निर्माण 2 की घटना पत्रक वास्तव में समझने और प्रोग्राम करने में आसान है।

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

मैंने स्कूल में प्रोग्रामिंग की है और मैं कोड को आसानी से पढ़ और समझ सकता हूं लेकिन इसे लिखने में समय लगता है। मैं अजगर सीखने की भी कोशिश कर रहा हूं जो आसान है लेकिन इसके साथ कुछ बनाने में अभी भी महीनों लगेंगे।

निर्माण 2 का दृष्टिकोण सरल लगता है। मेरे लिए ऐसा लगता है:

1 घटना: कार्रवाई;

2 घटना: कार्रवाई;
: कार्य;

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

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

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

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

गोडोट के साथ बढ़िया काम इस पर शानदार गेम बनाने की उम्मीद कर रहा है।

निर्माण के दृष्टिकोण के साथ मेरी समस्या यह है कि यह प्रोग्रामिंग की तरह लगता है, it
इतना अलग नहीं लगता
टीम के दृष्टिकोण से, मुझे अवास्तविक का खाका दृष्टिकोण अधिक पसंद है क्योंकि
यह उन डिजाइनरों के लिए अधिक अनुकूल है जिन्हें प्रोग्रामिंग के बारे में कोई जानकारी नहीं है

24 मई 2015 को सुबह 3:58 बजे, whoisda [email protected] ने लिखा:

मुझे लगता है कि निर्माण 2 की घटना पत्रक को समझना वास्तव में आसान है और
में कार्यक्रम।

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

मैंने स्कूल में प्रोग्रामिंग की है और मैं कोड को आसानी से पढ़ और समझ सकता हूं
लेकिन इसे लिखने में समय लगता है। मैं अजगर सीखने की भी कोशिश कर रहा हूं जो आसान है
लेकिन इसके साथ कुछ बनाने में अभी भी महीनों लगेंगे।

निर्माण 2 का दृष्टिकोण सरल लगता है। मेरे लिए ऐसा लगता है:

1 घटना: कार्रवाई;

2 घटना: कार्रवाई;
: कार्य;

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

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

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

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

गोडोट के साथ बढ़िया काम इस पर शानदार गेम बनाने की उम्मीद कर रहा है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -104985159।

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

यह दृश्य प्रोग्रामिंग की एक शैली में दूसरे पर बनाए गए खेलों की विविधता को देखने लायक भी है।

अवास्तविक में वास्तव में किस्मत में बड़ी संख्या में परियोजनाएं होती हैं - लेकिन यह निर्माण 2 की तुलना में बहुत पुराना इंजन है और उनमें से बहुत से पहले व्यक्ति निशानेबाज हैं

24 मई 2015 को सुबह 10:15 बजे, जुआन लिनिएत्स्की नोटिफिकेशन @github.com
लिखा था:

निर्माण के दृष्टिकोण के साथ मेरी समस्या यह है कि यह प्रोग्रामिंग की तरह लगता है, it
इतना अलग नहीं लगता
टीम के दृष्टिकोण से, मुझे अवास्तविक का खाका दृष्टिकोण अधिक पसंद है क्योंकि
यह उन डिजाइनरों के लिए अधिक अनुकूल है जिन्हें प्रोग्रामिंग के बारे में कोई जानकारी नहीं है

24 मई 2015 को सुबह 3:58 बजे, whoisda [email protected] ने लिखा:

मुझे लगता है कि निर्माण 2 की घटना पत्रक को समझना वास्तव में आसान है और
में कार्यक्रम।

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

मैंने स्कूल में प्रोग्रामिंग की है और मैं कोड को आसानी से पढ़ और समझ सकता हूं
लेकिन इसे लिखने में समय लगता है। मैं भी अजगर सीखने की कोशिश कर रहा हूँ जो है
आसान
लेकिन इसके साथ कुछ बनाने में अभी भी महीनों लगेंगे।

निर्माण 2 का दृष्टिकोण सरल लगता है। मेरे लिए ऐसा लगता है:

1 घटना: कार्रवाई;

2 घटना: कार्रवाई;
: कार्य;

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

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

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

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

गोडोट के साथ बढ़िया काम इस पर शानदार गेम बनाने की उम्मीद कर रहा है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
< https://github.com/ocamstudio/godot/issues/1220#issuecomment -104985159
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -104985669।

प्रोग्रामिंग के लिए कंस्ट्रक्ट 2 का दृष्टिकोण बहुत समान है
Clickteam फ्यूजन, जिसके कई यूजर्स भी हैं। इसमें आसानी a . से आती है
चीजों की संख्या, भले ही यह प्रोग्रामिंग के समान हो:

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

शायद इसका सबसे अच्छा पहलू यह है कि यह गैर-प्रोग्रामर को के बारे में सिखाता है
एक नई प्रोग्रामिंग सीखने के सीखने की अवस्था के बिना प्रोग्रामिंग सिद्धांत
भाषा: हिन्दी।

24 मई 2015 को सुबह 10:17 बजे, Todor Imreorov [email protected] पर
लिखा था:

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

24 मई 2015 को सुबह 10:15 बजे, जुआन लिनिएत्स्की < सूचनाएं @github.com

लिखा था:

निर्माण के दृष्टिकोण के साथ मेरी समस्या यह है कि यह प्रोग्रामिंग की तरह लगता है, it
इतना अलग नहीं लगता
टीम के दृष्टिकोण से, मुझे अवास्तविक का खाका दृष्टिकोण अधिक पसंद है क्योंकि
यह उन डिजाइनरों के लिए अधिक अनुकूल है जिन्हें प्रोग्रामिंग के बारे में कोई जानकारी नहीं है

24 मई 2015 को सुबह 3:58 बजे, whoisda [email protected]
लिखा था:

मुझे लगता है कि निर्माण 2 की घटना पत्रक को समझना वास्तव में आसान है और
में कार्यक्रम।

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

मैंने स्कूल में प्रोग्रामिंग की है और मैं कोड पढ़ और समझ सकता हूँ
सरलता
लेकिन इसे लिखने में समय लगता है। मैं भी अजगर सीखने की कोशिश कर रहा हूँ जो है
आसान
लेकिन इसके साथ कुछ बनाने में अभी भी महीनों लगेंगे।

निर्माण 2 का दृष्टिकोण सरल लगता है। मेरे लिए ऐसा लगता है:

1 घटना: कार्रवाई;

2 घटना: कार्रवाई;
: कार्य;

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

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

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

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

गोडोट के साथ बढ़िया काम इस पर शानदार गेम बनाने की उम्मीद कर रहा है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
< https://github.com/ocamstudio/godot/issues/1220#issuecomment -104985159
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -104985669।

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

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

इसके अलावा, यदि संभव हो तो कोड ब्लॉक/नोड्स को आसानी से खोजने के लिए एक खोज सुविधा बनाएं।

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

24 मई 2015 को सुबह 10:33 बजे, whoisda [email protected] ने लिखा:

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

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

इसके अलावा, यदि संभव हो तो कोड ब्लॉक/नोड्स खोजने के लिए एक खोज सुविधा बनाएं
सरलता।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -104988595।

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

मैं आपको इस वीडियो के साथ छोड़ दूँगा:
https://www.youtube.com/watch?v=3Zq1yo0lxOU
इसमें 167 गेम क्लिकटीम फ्यूजन के साथ बनाए गए हैं - उन लोगों द्वारा जिनके पास नहीं है
प्रोग्रामिंग अनुभव।

फ्यूजन में बने सफल किकस्टार्टर गेम्स को भी देखें।
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia/description
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game/description
https://www.kickstarter.com/projects/2064021040/tiny-trek

मुझे फ्रेडी के फाइव नाइट्स का भी उल्लेख करना चाहिए (क्लिकटीम फ्यूजन में निर्मित):
http://en.wikipedia.org/wiki/Five_Nights_at_Freddy%27s_%28video_game%29
वह गेम बेस्ट सेलर है। यहां आपके लिए कुछ आंकड़े दिए गए हैं:
https://thinkgaming.com/app-sales-data/8779/five-nights-at-freddys/

एक दृश्य प्रोग्रामिंग ढांचे का विचार एक प्रोग्रामर की आवश्यकता के बिना एक गेम बनाने के लिए एक कलाकार को सशक्त बनाना होना चाहिए - इस प्रक्रिया में प्रोग्रामिंग के बारे में थोड़ा सीखें।

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

24 मई 2015 को सुबह 10:42 बजे, Todor Imreorov [email protected] पर रविवार को
लिखा था:

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

रविवार, 24 मई 2015 को सुबह 10:33 बजे, whoisda [email protected]
लिखा था:

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

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

इसके अलावा, यदि संभव हो तो कोड ब्लॉक/नोड्स खोजने के लिए एक खोज सुविधा बनाएं
सरलता।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -104988595।

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

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

हो सकता है कि कुछ रास्तों को साफ़ करने और कुछ संख्याओं को देखने के लिए किसी उपयोगिता डिज़ाइनर से सलाह लें।

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

मुझे एक ऐसी प्रणाली को देखकर खुशी होगी जो मुझे बिना इंजन बदले और भाषाएं सीखने के बिना अद्भुत गेम बनाने में मदद करेगी।

चीयर्स।

मैं नोड्स को बुरा नहीं मानता अगर वे प्लेमेकर की तरह किए जाते हैं - as
कार्रवाई कंटेनर (राज्य)।
वहां के नोड्स वास्तव में क्रियाओं या शर्तों को सेट करने के लिए उपयोग नहीं किए जाते हैं।

यदि आप उन्हें "iCanScript" की तरह बनाते हैं, तो आपके पास पूरी तरह गड़बड़ है।

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

24 मई, 2015 को सुबह 11:20 बजे, whoisda [email protected] ने लिखा:

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

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

हो सकता है कि कुछ रास्तों को साफ़ करने और कुछ को देखने के लिए किसी उपयोगिता डिज़ाइनर से सलाह लें
संख्याएं।

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

मुझे एक ऐसी प्रणाली को देखकर खुशी होगी जो मुझे अद्भुत गेम बनाने में मदद करेगी
बिना इंजन बदले और कभी भी भाषाएं नहीं सीखे'।

चीयर्स।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -104990083।

मैं गोडोट के लिए/में कुछ नया करने के संबंध में @whoisda को वोट देता हूं। हालाँकि ऐसा लगता है कि तीन विज़ुअल स्क्रिप्टिंग स्कूल हैं: 1) नोड्स, 2) इवेंट शीट, 3) ब्लॉक। इन तीन नोड्स में से ऐसा लगता है कि 3डी वातावरण में क्षेत्र का नेतृत्व कर रहे हैं। जिसके बारे में बोलते हुए मैंने संरचनाओं का उपयोग करके 3D में एक रैखिक (पाठ, ब्लॉक, घटना पत्रक), या क्षैतिज (नोड्स) प्रारूप और प्रोग्राम से स्क्रिप्टिंग/प्रोग्रामिंग ब्रेक का सुझाव देने वाला एक विचार पढ़ा है। सुनिश्चित नहीं है कि यह कैसे काम करेगा लेकिन आकर्षक लगता है।

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

राज्य मशीन बनाने के लिए नोड्स।
प्रत्येक नोड (राज्य) के अंदर क्रियाओं को बनाने के लिए ब्लॉक या ईवेंट शीट।

24 मई 2015 को दोपहर 1:56 बजे, todheil [email protected] ने लिखा:

मैं कुछ के संबंध में @whoisda https://github.com/whoisda को वोट देता हूं
गोडोट के लिए/में नवप्रवर्तन किया जा रहा है। हालांकि तीन दृश्य प्रतीत होते हैं
स्क्रिप्टिंग स्कूल: 1) नोड्स, 2) इवेंट शीट्स, 3) ब्लॉक। इन तीनों में से
ऐसा लगता है कि नोड्स 3डी वातावरण में क्षेत्र का नेतृत्व कर रहे हैं। बाते कर रहे हैं जिससे कि
मैंने कहीं एक विचार पढ़ा है जो स्क्रिप्टिंग/प्रोग्रामिंग ब्रेक आउट का सुझाव देता है
रैखिक (पाठ, ब्लॉक, घटना पत्रक), या क्षैतिज (नोड्स) प्रारूप और
संरचनाओं का उपयोग करके 3 डी में कार्यक्रम। सुनिश्चित नहीं है कि यह कैसे काम करेगा लेकिन लगता है
चित्ताकर्षक।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -105001411।

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

प्लेमेकर में यह उस तरह का है - लोगों को यह बहुत पसंद आने लगता है।
यहाँ बहुत सारे लोग स्टैंसिल भी पसंद करते हैं - तकनीक है
ओपन सोर्स और स्क्रैच जीथब वेबसाइट पर उपलब्ध है। मैंने इसे में साझा किया है
पिछला पद।

मैं व्यक्तिगत रूप से दृश्य प्रोग्रामिंग में कोई भी पहला कदम देखना पसंद करूंगा
दिशा। भले ही डेवलपर एक राज्य मशीन बनाता है जो gd . के साथ काम करता है
स्क्रिप्ट - यह एक अद्भुत शुरुआत होगी, यहां तक ​​कि उन्नत प्रोग्रामर भी
सरहाना करूँगा।

फिर शायद उसके बाद हमारे पास स्टेंसिल जैसा कुछ दृश्य हो सकता है या
निर्माण 2 - वह कोड की तरह है - लेकिन कोड की तुलना में बहुत आसान है - अंदर
राज्यों।

तो वास्तव में ये दो फीचर अनुरोध हैं!

• एक राज्य मशीन के लिए (नोड्स)
• एक अन्य दृश्य स्क्रिप्टिंग ढांचे के लिए जो सीखने की जगह लेता है gdscript
  ड्रैग एंड ड्रॉप कोडिंग के साथ। लेकिन सीखने की दिशा में भी एक अच्छा कदम है
  जीडीस्क्रिप्ट

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

मंगलवार, 26 मई, 2015 को पूर्वाह्न 11:43 बजे, whoisda [email protected] ने लिखा:

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -105446984।

मैं जल्द ही styencyl की जाँच करूँगा क्योंकि मैं इससे परिचित नहीं हूँ।
इस बिंदु पर मैंने जो कुछ भी देखा/पढ़ा है, मैं उसे इकट्ठा कर सकता हूं:

1) ब्लूप्रिंट: गेम/स्तर के डिजाइनरों के लिए बहुत अच्छा है, लेकिन इतना अच्छा नहीं है
दृश्य प्रोग्रामिंग
2) स्टेंसिल: दृश्य प्रोग्रामिंग के लिए बहुत बेहतर है, लेकिन इसके लिए अनुपयोगी है
खेल/स्तर डिजाइनर

मेरा खेल बनाने का अनुभव हमेशा टीमों पर था, इसलिए मैं 1 को देख सकता हूं) के रूप में
बहुत उपयोगी है, लेकिन यह मुझे पक्षपाती भी बनाता है। क्या इतने लोग हैं
Stencyl की तरह दृश्य प्रोग्रामिंग में रुचि रखते हैं?

मंगलवार, 26 मई, 2015 को सुबह 6:10 बजे, टोडर इमरेरोव नोटिफिकेशन @github.com
लिखा था:

प्लेमेकर में यह उस तरह का है - लोगों को यह बहुत पसंद आने लगता है।
यहाँ बहुत सारे लोग स्टैंसिल भी पसंद करते हैं - तकनीक है
ओपन सोर्स और स्क्रैच जीथब वेबसाइट पर उपलब्ध है। मैंने इसे में साझा किया है
पिछला पद।

मैं व्यक्तिगत रूप से दृश्य प्रोग्रामिंग में कोई भी पहला कदम देखना पसंद करूंगा
दिशा। भले ही डेवलपर एक राज्य मशीन बनाता है जो gd . के साथ काम करता है
स्क्रिप्ट - यह एक अद्भुत शुरुआत होगी, यहां तक ​​कि उन्नत प्रोग्रामर भी
सरहाना करूँगा।

फिर शायद उसके बाद हमारे पास स्टेंसिल जैसा कुछ दृश्य हो सकता है या
निर्माण 2 - वह कोड की तरह है - लेकिन कोड की तुलना में बहुत आसान है - अंदर
राज्यों।

तो वास्तव में ये दो फीचर अनुरोध हैं!

• एक राज्य मशीन के लिए (नोड्स)
• एक अन्य दृश्य स्क्रिप्टिंग ढांचे के लिए जो सीखने की जगह लेता है gdscript
  ड्रैग एंड ड्रॉप कोडिंग के साथ। लेकिन सीखने की दिशा में भी एक अच्छा कदम है
  जीडीस्क्रिप्ट

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

मंगलवार, 26 मई, 2015 को पूर्वाह्न 11:43 बजे, whoisda [email protected]
लिखा था:

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
< https://github.com/ocamstudio/godot/issues/1220#issuecomment -105446984
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -105458142।

http://www.emanueleferonato.com/wp-content/uploads/2011/12/stencyl05.png

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

यदि आप दृश्य प्रोग्रामिंग की बात करते हैं, तो गोडोट के पास पहले से जो है वह बहुत बेहतर है - शेडर ग्राफ़ या एनीमेशन ग्राफ़: दृश्य नोड्स में लिपटे कोड।
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg - विजुअल नोड-आधारित प्रोग्रामिंग का एक और उदाहरण (सिडफक्स हौडिनी, या एक्सएसआई)। यह परिपक्व है और बच्चों के खिलौने की तरह नहीं दिखता है, यह मुझे गोडोट नोड्स की भी याद दिलाता है।

मुझे निर्माण 2 दृष्टिकोण पसंद आया, लेकिन खरोंच में और अधिक देखने के बाद - यह कई कारणों से बेहतर विकल्प की तरह लगता है:

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

स्टेंसिल डेवलपर्स ने ओपन सोर्स "स्क्रैच" तकनीक को अपनाया। यह उनका डिजाइन नहीं है।
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_ (programming_language)
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

गैर-प्रोग्रामर पर लक्षित अन्य गेम इंजनों द्वारा उपयोग किए जा रहे स्क्रैच के उदाहरण:

• स्टेंसिल (सबसे लोकप्रिय एक) http://www.stencyl.com/
  
• क्राफ्टस्टूडियो ( http://craftstud.io/ )
  
• गूगल ब्लॉकली ( https://developers.google.com/blockly/ )
• गोडोट के सबसे करीब एकता की "ब्लॉक्स" दृश्य प्रोग्रामिंग संपत्ति है:
  
  https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k
  लुआ के बजाय, यह सी # उत्पन्न करता है।
  इसका पूरा दस्तावेज यहां है:
  http://www.plyoung.com/blox/
  और यहां बेचा जाता है: https://www.assetstore.unity3d.com/en/#!/content/12859

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

मैं @reduz से उनकी बातों पर सहमत हूं कि एक स्तर के डिजाइन में अच्छा है और दूसरा दृश्य स्क्रिप्टिंग में और अब एक के ऊपर एक का उपयोग करने के लिए बहस नहीं कर रहा है।

दोनों का उपयोग करना सबसे अच्छा तरीका लगता है। यदि यूनिटी ब्लॉक्स नहीं है, भले ही आप प्लेमेकर को देखें, तो आप देखेंगे कि नोड्स वास्तव में कंटेनर हैं- जहां क्रियाओं को ढेर किया जा सकता है - स्टैंसिल के समान ही। आप उन्हें एक सूची से खींचें और छोड़ें!

"लेकिन यह गैर प्रोग्रामर को सिखाने का सबसे अच्छा तरीका है कि कैसे कोड लिखना है या बस उन्हें जादुई शब्दों को जाने बिना प्रोग्राम करने के लिए सशक्त बनाना है"

तब मुझे समझ नहीं आता कि यह टारगेटिंग ऑडियंस क्या है। क्या गोडोट का लक्ष्य बाजार में बड़े लड़कों (अवास्तविक इंजन, एकता, आदि) के साथ प्रतिस्पर्धा करना है या बच्चों को स्क्रैच डू ​​(https://scratch.mit.edu/) जैसे प्रोग्रामिंग/गेम बनाना सिखाना है?

मुझे पता है कि नोड्स क्या हैं (इनपुट -> पैराम के साथ फ़ंक्शन -> आउटपुट), मैं प्रस्तुति से असहमत हूं।

स्टैंसिल और प्लेमेकर बच्चों को कोड कैसे सिखाते हैं, यह सिखाने में बहुत अच्छे हो सकते हैं, लेकिन गैर-प्रोग्रामर (स्टूडियो और इंडी दोनों) द्वारा उनका सफलतापूर्वक उपयोग विभिन्न प्लेटफार्मों पर बेचे जाने वाले सफल गेम बनाने के लिए किया गया है।
अगर आप यूनिटी को बड़े लड़कों की श्रेणी में रखते हैं, तो आपको पता होना चाहिए कि बड़े लड़के भी विजुअल प्रोग्रामिंग करते हैं।
http://www.hutonggames.com/showcase.html

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

@blurymind
मैं दृश्य प्रोग्रामिंग के खिलाफ _not_ बहस करता हूं। मैं कहूंगा कि गोडोट के पास पहले से ही इसकी आवश्यकता है (ShaderGraphs): समान दृश्य दृष्टिकोण को राज्य-मशीन तर्क प्रोग्रामिंग, या सामान्य प्रोग्रामिंग तक बढ़ाया जा सकता है। मैं जिस चीज के खिलाफ तर्क देता हूं वह एक और दृश्य प्रतिमान (~ खरोंच) को अपनाने के खिलाफ है जो बच्चों को डराता नहीं है।

जैसा कि पहले उल्लेख किया गया है कि यह सिर्फ बच्चों के लिए नहीं है। लेकिन अगर बच्चे भी इसे समझ सकते हैं और इसका इस्तेमाल कर सकते हैं - तो मुझे लगता है कि यह अच्छी बात है। शर्म की बात नहीं है।

सबसे बड़ी बात जो मैं यहाँ कहना चाहता हूँ वह यह है कि:

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

आप जो समाप्त करते हैं वह एक बहुत ही साफ और कुशल नोड सेट अप है!

मेरा सुझाव है कि गोडोट देव नाटककार को भी आजमाएं।
इवेंट स्टैक को स्टैंसिल लॉजिक के साथ बदलने से गोडोट का दृष्टिकोण और अधिक लचीला/शक्तिशाली हो जाएगा!

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

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

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

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

• प्लेमेकर में स्टेट मशीन की तरह इस्तेमाल होने वाले नोड्स! प्रोग्रामर प्रत्येक नोड को नाम दे सकते हैं और उसमें gdscripts संलग्न कर सकते हैं - उनके द्वारा सेट किए गए इनपुट और आउटपुट के साथ। तो यह बच्चों के लिए बिल्कुल नहीं है। वास्तव में, यह प्रोग्रामर के लिए बहुत अधिक लचीला दृष्टिकोण है जो बहुत कम गन्दा है।
• GDscript जनरेट करने के वैकल्पिक तरीके के रूप में ड्रैग एंड ड्रॉप इवेंट शीट या ब्लॉक इंटरफ़ेस। इसलिए नोड से संलग्न करने के लिए GdScript लिखने के बजाय, गैर-प्रोग्रामर केवल गोडोट में सभी उपलब्ध घटनाओं की सूची से क्रियाओं को ढेर कर सकते हैं - बहुत कुछ Playmaker की तरह। इसे एक कदम आगे ले जाने और नया करने के लिए - केवल क्रियाओं को ढेर करने के बजाय, स्टैंसिल जैसे ब्लॉक का उपयोग करना और भी बेहतर होगा।

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

@blurymind
मुझे यह ज्यादा अच्छा लगता है। इसके अलावा यह शेडर नोड-ग्राफ बनाम शेडर-टेक्स्ट के अनुरूप है जो पहले से ही गोडोट में है।

साइडएफएक्स हौदिनी में वीईएक्स (https://goo.gl/TMWNKk) ("वेक्टर एक्सप्रेशन" एक सी-जैसी भाषा है जो वेक्टर बीजगणित के लिए है) नामक कुछ है। यह कुछ हद तक gdScript का समानार्थी है। इसके अलावा इसमें "वीओपी" (http://goo.gl/Qpn2OE) (वीएक्स ऑपरेटर्स) नामक कुछ भी है - अनिवार्य रूप से वीईएक्स के सबसेट के दृश्य रैपर, जो ऊपर संदर्भित लीडवर्क्स नोड-ग्राफ छवि के समान दिखता है। वास्तव में, यदि आवश्यक हो तो वीओपी को टेक्स्ट-स्क्रिप्ट में बदला जा सकता है (लेकिन दूसरी तरफ नहीं)।

2 का सह-अस्तित्व काफी स्वाभाविक है और यह गैर-प्रोग्रामर को भी बहुत गन्दा और अक्षम कोड बनाने की अनुमति देता है;)

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

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

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

मेरी राय में नोड्स और ग्राफ दृष्टिकोण अधिक दिलचस्प है क्योंकि यह है
चीजों को करने का निचला स्तर और अधिक लचीला तरीका।

मंगलवार, 26 मई, 2015 पूर्वाह्न 11:29 बजे, व्लादिमीर लोपाटिन < सूचनाएं @github.com

लिखा था:

@blurymind https://github.com/blurymind
मुझे यह ज्यादा अच्छा लगता है। इसके अलावा यह शेडर नोड-ग्राफ बनाम . के अनुरूप है
शैडर-पाठ जो पहले से ही गोडोट में है।

साइडएफएक्स हौदिनी में कुछ ठंडा वीईएक्स है (https://goo.gl/TMWNKk) ("वेक्टर
अभिव्यक्ति" एक सी-जैसी भाषा है जो वेक्टर बीजगणित के लिए है। यह है
कुछ हद तक जीडीस्क्रिप्ट का समानार्थी। इसके अलावा इसमें "VOPs" नाम की कोई चीज़ होती है (
http://goo.gl/Qpn2OE) (Vex ऑपरेटर्स) - अनिवार्य रूप से a . के विज़ुअल रैपर
वीईएक्स का सबसेट, जो लीडवर्क्स नोड-ग्राफ के समान दिखता है जो आप
ऊपर संदर्भित। वास्तव में, यदि आवश्यक हो तो वीओपी को स्क्रिप्ट में बदला जा सकता है
(लेकिन दूसरी तरफ नहीं)।

2 का सह-अस्तित्व काफी स्वाभाविक है और यह अनुमति देता है, यहां तक ​​कि
गैर-प्रोग्रामर, बहुत गन्दा और अक्षम कोड बनाने के लिए;)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment-105543845 ।

प्लेमेकर में एक्शन स्टैकिंग और यूनिटी में ब्लॉक्स के बारे में क्या? एकता बहुत सरल इंजन नहीं है।

मुझे लगता है कि स्टेंसिल बहुत अच्छा उदाहरण नहीं है। यूनिटी एसेट स्टोर में उदाहरण देखना बेहतर है।

मैंने प्लेमेकर को समझने की कोशिश की लेकिन असफल रहा, इसे कैसे काम करना चाहिए?

मंगलवार, 26 मई, 2015 को दोपहर 12:16 बजे, टोडर इमरेरोव नोटिफिकेशन @github.com
लिखा था:

प्लेमेकर में एक्शन स्टैकिंग और यूनिटी में ब्लॉक्स के बारे में क्या? एकता नहीं है
बहुत ही सरल इंजन।

मुझे लगता है कि स्टेंसिल बहुत अच्छा उदाहरण नहीं है। तलाश करना बेहतर है
एकता संपत्ति की दुकान में उदाहरण।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -105561760।

प्लेमेकर के ट्यूटोरियल की जाँच की, लेकिन ऐसा लगता है कि यह स्टैंसिल के समान है
यह अर्थ है कि यह एक अरब पूर्वनिर्धारित व्यवहार के साथ आता है

मंगलवार, 26 मई, 2015 को दोपहर 12:19 बजे, जुआन लिनिएत्स्की नोटिफिकेशन @github.com
लिखा था:

मैंने प्लेमेकर को समझने की कोशिश की लेकिन असफल रहा, इसे कैसे काम करना चाहिए?

मंगलवार, 26 मई, 2015 को दोपहर 12:16 बजे, टोडर इमरेरोव < नोटिफिकेशन @github.com

लिखा था:

प्लेमेकर में एक्शन स्टैकिंग और यूनिटी में ब्लॉक्स के बारे में क्या? एकता नहीं है
बहुत ही सरल इंजन।

मुझे लगता है कि स्टेंसिल बहुत अच्छा उदाहरण नहीं है। तलाश करना बेहतर है
एकता संपत्ति की दुकान में उदाहरण।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
< https://github.com/ocamstudio/godot/issues/1220#issuecomment -105561760
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -105563777।

_ओकेमस्टूडियो_

यूनिटी में U4 ब्लूप्रिंट के सबसे करीब यूस्क्रिप्ट है:
https://www.assetstore.unity3d.com/hi/#!/content/1808

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

@reduz @okamstudio यहां प्लेमेकर पर एक प्लेलिस्ट है:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
मुझे लगता है कि आपको वास्तव में इसे थोड़ा सा इस्तेमाल करना चाहिए। आप पूर्वनिर्धारित व्यवहार और स्क्रिप्ट कर सकते हैं, लेकिन प्लेमेकर आपको इंजन की मुख्य विशेषताओं तक पहुंचने और इस तरह के व्यवहार को खरोंच से करने की अनुमति भी देता है।

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

मुझे लगता है कि अंत में आपको एक उचित गेम और इस विचार को बनाने के लिए एक प्रोग्रामर की आवश्यकता है
यह बहुत अच्छा है कि गेम डिज़ाइनर गेम को स्वयं बनाते हैं लेकिन मुझे लगता है कि यह बहुत है
काम का जो कई मामलों में काम नहीं आता है। लेकिन अगर हमारे पास अधिक है
संपादक के लिए सुविधा यह स्वयं प्लेटफ़ॉर्मर डिज़ाइनर की तरह है जो कोई और है
यूआई को आसान बनाने के लिए किसी अन्य मुद्दे या अन्य उपयोगी चीजों में उल्लेख किया गया है
मित्रवत।
26 मई 2015 को शाम 7:52 बजे, "ओकेम स्टूडियो" नोटिफिकेशन @github.com ने लिखा:

प्लेमेकर के ट्यूटोरियल की जाँच की, लेकिन ऐसा लगता है कि यह स्टैंसिल के समान है
यह अर्थ है कि यह एक अरब पूर्वनिर्धारित व्यवहार के साथ आता है

मंगलवार, 26 मई, 2015 दोपहर 12:19 बजे, जुआन लिनिएत्स्की < सूचनाएं @github.com

लिखा था:

मैंने प्लेमेकर को समझने की कोशिश की लेकिन असफल रहा, इसे कैसे काम करना चाहिए?

मंगलवार, 26 मई, 2015 दोपहर 12:16 बजे, टोडर इमरेरोव <
सूचनाएं@github.com

लिखा था:

प्लेमेकर में एक्शन स्टैकिंग और यूनिटी में ब्लॉक्स के बारे में क्या? एकता है
नहीं एक
बहुत ही सरल इंजन।

मुझे लगता है कि स्टेंसिल बहुत अच्छा उदाहरण नहीं है। तलाश करना बेहतर है
एकता संपत्ति की दुकान में उदाहरण।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/ocamstudio/godot/issues/1220#issuecomment -105561760
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
< https://github.com/ocamstudio/godot/issues/1220#issuecomment -105563777
.

_ओकेमस्टूडियो_

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -105565084।

यहां यूस्क्रिप्ट के लिए यूनिटी एसेट स्टोर पर एक समीक्षा है:

अच्छा उपकरण है, लेकिन यह सीखना कठिन है कि क्या कोई गैर-प्रोग्रामर... फ़ोरम पर सहायता अनुरोधों की प्रतिक्रियाएँ बहुत धीमी हैं या बिल्कुल भी मौजूद नहीं हैं..

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

@adolson यह एक बहुत वांछित विशेषता होगी :)

यह किया जा सकता है, और दृश्य शेडर संपादक के साथ भी किया जा सकता है
(जो वास्तव में, शेडर कोड उत्पन्न करता है)
लेकिन मुझे लगता है कि जेनरेट किया गया शेडर कोड उतना पठनीय नहीं होगा जितना आप कर सकते हैं
उम्मीद: पी

मंगलवार, 26 मई, 2015 को शाम 6:33 बजे, नाथन नोटिफिकेशन @github.com ने लिखा:

@adolson https://github.com/adolson यह बहुत वांछित होगा
विशेषता :)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ocamstudio/godot/issues/1220#issuecomment -105670945।

@reduz कुछ मेटाडेटा अपेक्षित है।
यहाँ VOPs -> VEX रूपांतरण से रूपांतरण का एक उदाहरण दिया गया है, जैसा कि ऊपर बताया गया है:
:
और यहाँ कोड की पूरी सूची है , जो अन्यथा, शुद्ध VEX में इस तरह दिखता है:
@P += वेक्टर ({0,1,0}); // स्थिति लें और वेक्टर जोड़ें (0,1,0)

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

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

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

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

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

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

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

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

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

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

गुरु, अप्रैल 14, 2016 को सुबह 8:33 बजे, रेमी वर्शेल्डे नोटिफिकेशन @github.com
लिखा था:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/1220#issuecomment -209770726

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

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

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

गुरु, 14 अप्रैल, 2016 को सुबह 9:09 बजे, हारून एम नोटिफिकेशन @github.com ने लिखा:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

स्लैपिन, तुम सही हो। लेकिन आप भूल जाते हैं कि दृश्य प्रोग्रामिंग या प्रोग्रामिंग ब्लॉकों की विफलता दर बहुत कम होती है। यह सीमाओं के कारण है।
यह मूल रूप से वही है जब आप बहुत सीमित स्क्रिप्टिंग भाषा लेते हैं। आप बहुत सारी गलतियाँ नहीं कर सकते।

मुझे लगता है कि इसे हासिल करने का लक्ष्य होना चाहिए, न कि यह सवाल कि क्या विजुअल- या टेक्स्ट-स्क्रिप्टिंग!

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

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

मैं यह नहीं कहूंगा कि यह व्यर्थ है, लेकिन मैं कहूंगा कि हम 2 . के बारे में बात कर रहे हैं
पूरी तरह से अलग उत्पाद।

यदि आप एक स्टूडियो चला रहे हैं, और आप 20-80 लोगों के साथ गेम बना रहे हैं,
आप हर महीने उत्पादन लागत में 6 आंकड़े खर्च कर रहे हैं, और आपको एक की जरूरत है
अपने गेम बनाने के लिए इंजन, आप एक निश्चित उत्पाद चाहते हैं। ऐसे में आप
विज़ुअल स्क्रिप्टिंग टूल की बिल्कुल भी परवाह न करें, आप दूसरों की परवाह करते हैं
चीजें, जैसे कि आपकी टीम इंजन के उपकरणों के साथ कितनी उत्पादक होगी
(चूंकि अगर वे एक महीने के लिए समय से अधिक हो जाते हैं, तो आप ~ $ 100k से बाहर हो जाते हैं)। वे
टीमों में प्रोग्रामर होते हैं, और वे बहुत अधिक उत्पादक लेखन कोड होंगे
कुछ दृश्य उपकरण का उपयोग करने के बजाय (उस के उदाहरण के लिए शातिर इंजन देखें)

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

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

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

14 अप्रैल 2016 को 03:26 बजे, सर्गेई लैपिन नोटिफिकेशन @github.com ने लिखा:

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

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

गुरु, 14 अप्रैल, 2016 को सुबह 9:09 बजे, हारून एम नोटिफिकेशन @github.com ने लिखा:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
< https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/1220#issuecomment -209779422

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

बहुत बढ़िया सूत्र, ढेर सारी राय

मेरा सरल है। आप बिल्कुल ठीक हैं!

इनमें से कोई भी विचार gdscript के लिए एक बढ़िया अतिरिक्त होगा

मैं उनके प्रकट होने पर उन्हें आज़माने के लिए उत्सुक हूँ।

मुझे लगता है कि जीडीस्क्रिप्ट कुछ प्यार के साथ और अधिक उपयोगकर्ता के अनुकूल होने के लिए भी कर सकता है।

कुछ नोड्स पूरी तरह से प्रलेखित नहीं हैं। बहुत कुछ का कोई विवरण नहीं है।
विकास को सरल बनाने के लिए गोडोट कुछ सहायक कार्यों का उपयोग कर सकता है। गेममेकर जीएमएल एक अच्छा उदाहरण है:
https://twitter.com/uheartbeast/status/724326557108461568

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

सोम, अप्रैल 25, 2016 को सुबह 9:35 बजे, टोडर इमरेरोव नोटिफिकेशन @github.com
लिखा था:

मुझे लगता है कि जीडीस्क्रिप्ट कुछ प्यार के साथ और अधिक उपयोगकर्ता के अनुकूल होने के लिए भी कर सकता है।

कुछ नोड्स पूरी तरह से प्रलेखित नहीं हैं। बहुत कुछ का कोई विवरण नहीं है।
विकास को सरल बनाने के लिए गोडोट कुछ सहायक कार्यों का उपयोग कर सकता है।
गेममेकर जीएमएल एक अच्छा उदाहरण है:
https://twitter.com/uheartbeast/status/724326557108461568

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/1220#issuecomment -214163012

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

दृश्य स्क्रिप्टिंग के बारे में मेरे 2 सेंट जोड़ने के लिए और मुझे यह विचार क्यों पसंद नहीं है:

मुझे लगता है कि कोड प्रबंधन और दक्षता के मामले में किसी भी gdscript फ़ाइल में नोड्स को जोड़ने की क्षमता कहीं बेहतर है।

उदाहरण के लिए, दृश्य स्क्रिप्टिंग के साथ (या C2 के समान ईवेंट शीट का उपयोग करके), यदि आपके पास 1000 से अधिक फ़ंक्शन हैं तो क्या होगा? यह सब कुछ के माध्यम से नेविगेट करने के लिए मेरा मानना ​​​​है कि यह बहुत खराब कर देगा। मैं अपने एचटीएमएल 5 एक्शन आरपीजी गेम को अभी गोडोट में पोर्ट कर रहा हूं (जो 10k + लाइन ऑफ कोड और 500 से ज्यादा फंक्शन्स से अधिक है)। _(इसमें मूल रूप से हर एक फीचर पाथ ऑफ एक्साइल है, एनिमेशन को छोड़कर और मल्टीप्लेयर है)_

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

संपादित करें: जैसा कि कुछ अन्य लोगों ने कहा है, शायद मुझे लगता है कि छोटी परियोजनाओं के लिए ... लेकिन कुछ भी बड़ा मैं इसे उपयोगी नहीं देख सकता

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

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

दृश्य स्क्रिप्टिंग कोड को vonstruct2 में व्यवस्थित करने के लिए, आप इसे ऐसे समूहों में रखते हैं जिन्हें संक्षिप्त किया जा सकता है। यह कुछ ऐसा है जो gdscript भी नहीं कर सकता- आप कोड के ब्लॉक को ध्वस्त नहीं कर सकते। तो कुछ मायनों में इवेंट शीट में गोडॉट्स जीडीस्क्रिप्ट संपादक पर फायदे हैं।

@reduz मैं शुद्ध डेटा देख रहा था और जिस तरह से वे करते हैं वह बहुत आसान है। अच्छा इसे देखें

जैसा कि आप देख सकते हैं कि "बैंग" टाइप करना जेनेरिक ऑब्जेक्ट को बैंग ऑब्जेक्ट में बदल देता है।

क्या होगा यदि दृश्य स्क्रिप्टिंग केवल जीडी स्क्रिप्ट का विस्तार बन सकती है। बस एक सामान्य नोड रखें और पूर्व के लिए वेक्टर 2 टाइप करें और यह वेक्टर 2 ऑब्जेक्ट बन जाएगा। तो अनिवार्य रूप से प्रत्येक वर्ग/वस्तु भी एक नोड है।

कार्यों को चलाने के लिए मैं सोच रहा हूं कि आप एक और नोड प्राप्त कर सकते हैं जो एक वस्तु नहीं है बल्कि एक प्रक्रिया नोड है और आप वेक्टर2.डॉट की तरह कुछ टाइप करेंगे और नोड 2 इनपुट और 1 आउटपुट के साथ डॉट नोड में बदल जाएगा।

किसी बिंदु पर दृश्य स्क्रिप्टिंग की योजना बनाई गई है

आपने निराश नहीं किया :) <3

चूंकि पहले से ही विजुअलस्क्रिप्टिंग है, क्या इस मुद्दे को बंद कर देना चाहिए?

हां।

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

2015 के एक बयान के विषय से हटकर उत्तर दें, आइए :)