Godot: سهل الاستخدام مصمم لعبة لغير المبرمجين

يتم تخطيط البرمجة النصية المرئية في مرحلة ما

يوم الأربعاء 14 كانون الثاني (يناير) 2015 الساعة 6:20 صباحًا ، كتب RyanBram [email protected] :

مرحبًا ، مطورو Godot.

بادئ ذي بدء ، أود أن أشكركم جميعًا على إنشاء محرك ألعاب رائع
مع رخصة متساهلة جدا. سيساعد مجهودك العديد من المطورين و
الطلاب بميزانية محدودة لتحقيق حلمهم.

مع الوضع الحالي لـ Godot ، سيكون للألعاب مفتوحة المصدر مستقبل أكثر إشراقًا.
لسوء الحظ ، تم تصميم معظم محركات الألعاب المفتوحة المصدر مع برامج متقدمة
مستخدم في الاعتبار مع القليل من المعرفة حول البرمجة. ما زالت لا تستطيع الوصول
صانع لعبة مبتدئ.

اقتراحي هو توفير مصمم / محرر لعبة سهل الاستخدام
واجهة المستخدم الرسومية البديهية والفئة المحددة مسبقًا لتسهيل مهمة المبرمج الجديد. أكثر
المبرمج يعني المزيد من المستخدمين (لأن مستخدم Godot هو مبرمجي الألعاب).

أعرف محركًا واحدًا للعبة يقوم بهذه المهمة جيدًا. هو مكتوب من روبي ،
أصله من اليابان ، ومُترجم إلى الإنجليزية في جميع أنحاء العالم. يطلق عليه RPG
صانع VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace. بالرغم من
كلمة آر بي جي أمام اسمها ، فهي قادرة على إنشاء غير آر بي جي
لعبة مع نظام البرمجة النصية للعبة Ruby (RGSS) المدمج.

https://camo.githubusercontent.com

القائمة التالية هي مثال على الألعاب التي تم إنشاؤها باستخدام محرك RPG Maker:

1. ألف (مغامرة آر بي جي) http://www.pioneervalleygames.com/
2. عدم وعد خراف البحر (أركيد) http://rpgmaker.net/games/5102/
3. راغاروك - بيستياريوم (لعبة بطاقات) http://rpgmaker.net/games/5808/
4. الأرض تحت الهجوم! (مطلق النار) http://rpgmaker.net/games/6561/
5. تيرا (VisualNovel) http://rpgmaker.net/games/3956/
6. ذكريات مانا (أكشن آر بي جي)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. ميهوس - البداية (الرعب) http://rpgmaker.net/games/6493/

أتمنى أن يصبح محرك Godot مشهورًا مثل RPG Maker ، لأنه يحتوي على الكثير
ميزات أكثر من RPG Maker. يحتاج مبرمج مبتدئ فقط إلى وسيلة سهلة للاستخدام
واجهه المستخدم. إذا كان هذا ناجحًا ، فقد يصبح استوديو Okam التالي GOG أو Steam
التي تنشر آلاف الألعاب التي أنشأها مطورو إندي.

مع تحياتي ، ريان

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220.

RyanBram - لا أحاول التصويت على الفكرة ، على الإطلاق ، هنا - ربما قد تكون مفيدة في المستقبل ، لكنني لست متأكدًا من أن البرمجة النصية المرئية هي وسيلة فعالة للبرمجة النصية. لا أستطيع الجزم بذلك ، لكنني أتخيل أن الألعاب الأكثر تعقيدًا التي نشرتها على الأرجح تمت كتابتها في نص ، وليس بصريًا. يبدو أن البرمجة النصية المرئية هي شيء يستخدمه المستخدمون الجدد بالتأكيد ، لكن هذا يؤخرهم في تعلم الأدوات الفعلية التي سيحتاجون إليها لإكمال مشاريعهم بشكل صحيح. لكن يمكن أن يجعل المحرك أكثر سهولة ، لذلك لا أعرف.

يجب أن يكون من الممكن أيضًا للمستخدمين إنشاء نظام برمجة مرئي في Godot باستخدام GDScript بدلاً من شيء يحتاج إلى تضمينه في المحرك ، أليس كذلك؟ لست متأكدًا من ذلك ، رغم ذلك.

يبدو أن صانع ألعاب تقمص الأدوار يتخذ نهج "التعديل" ، وإذا كان Godot سيبدو مثل صانع ألعاب تقمص الأدوار - فإن الأشخاص الذين لديهم نوايا لصنع أنواع مختلفة من الألعاب سوف يبتعدون. لذا فإن ما تقترحه أساسًا هو جعل godot يبدو مثل GameMaker (وهو أمر مفهوم ، يرغب العديد من الأشخاص في إنشاء ألعاب ولكن لا يعرفون البرمجة) ولكن هناك قيود :)
ما سيحدث على الأرجح هو أن Godot سيحصل على محرر الرسم البياني للسلوك العقدي ، على غرار ما يمتلكه Leadwerks و BGE. يعمل هذا بشكل جيد مع عناصر واجهة المستخدم الرسومية ، والباقي يتطلب بعض البحث وأطنانًا من تعليقات المجتمع ، لجعله سهلاً وقويًا قدر الإمكان.

SolarLune ، من الممكن بناء لعبة في Godot وإضافة محرر في الأعلى يسمح بتعديل اللعبة على كل التفاصيل الصغيرة (باستخدام GraphNodes وباقي واجهة المستخدم ، متعة كبيرة للعب بها) ، بل سيسمح لك بكتابة بعض كود GDscript إضافي في الأعلى ، أعتقد أن هذا هو أفضل نهج ، لشحن لعبة لعبة كاملة (RPG ، FPS ، RTS) بشكل منفصل والسماح بتعديل كل جانب من جوانبها. بناة صنعوا في Godot.

SolarLune : البرمجة النصية المرئية مفيدة عندما تعمل مع ملف
مبرمج ، يمكنه إنشاء كتلة لتلعب بها. هذه
النهج في Unreal مفيد. لا أعتقد أنه من الممكن استبداله
البرمجة بالكامل (إلا إذا كنت مازوشيًا) ، لكنها قد تعمل من أجلها
يقوم بعض الأشخاص بعمل قوالب قوالب لغير المبرمجين أيضًا.

يوم الأربعاء 14 يناير 2015 الساعة 4:23 مساءً ، كتب TheoXD [email protected] :

يبدو أن صانع ألعاب تقمص الأدوار يتخذ نهج "التعديل" ، وإذا شاء جودو
تبدو أشبه بصانع ألعاب تقمص الأدوار - الأشخاص الذين لديهم نوايا مختلفة
نوع من الألعاب سوف يبتعد. إذن ما تقترحه هو في الأساس
اجعل godot يبدو مثل GameMaker (وهو أمر مفهوم ، كثير من الناس
تريد أن تصنع ألعابًا ولكن لا تعرف البرمجة) ولكن هناك حد :)
ما سيحدث على الأرجح هو أن جودو سيحصل على رسم بياني للسلوك العقدي
محرر ، مشابه لما يمتلكه ليدويركس و بي جي إي. هذا يعمل بشكل جيد مع
عناصر واجهة المستخدم الرسومية ، فإن الباقي يتطلب بعض البحث وأطنانًا من المجتمع
التعليقات ، لجعلها سهلة وقوية قدر الإمكان.

SolarLune https://github.com/SolarLune ، من الممكن بناء لعبة
في Godot وأضف محررًا في الأعلى يسمح بتعديل اللعبة في كل مكان
القليل من التفاصيل (باستخدام GraphNodes وبقية واجهة المستخدم) ، بل سيسمح بذلك
اكتب بعض كود GDscript الإضافي في الأعلى ، وأعتقد أن هذا هو أفضل نهج ،
لشحن لعبة كاملة (RPG ، FPS ، RTS) بشكل منفصل والسماح بالتعديل
كل جانب من جوانبها.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

حسنًا ، مما أعرفه ، لدى Godot بالفعل رمز واجهة مستخدم قائم على العقدة (لشجرة الرسوم المتحركة والآن محرر التظليل المرئي) والذي يمكن استخدامه في المستقبل لإنشاء نوع شجرة "منطق".

ومع ذلك ، يجب على المرء أن يلاحظ أن GDscript سيظل هو الطريق للذهاب إذا كنت تريد أقصى قدر من المرونة وجعل العقد المنطقية مفيدة سيتطلب عقدة نصية لتنفيذ GDscript (للأشياء الأكثر تعقيدًا والأكثر تقدمًا).

لا يمكن لـ UE4 في الوقت الحالي القيام بكل شيء في Blueprints دون تعقيد مجنون ، ويتوقع GameMaker منك استخدام GML لتحقيق أقصى قدر من المرونة (من خلال استخدام كتل التعليمات البرمجية) ، ويتطلب BGE البرمجة النصية في Python للحصول على أقصى قدر من الطاقة (من خلال استخدام قوالب التعليمات البرمجية). لا يمكن استبعاد فائدة التحرير المرئي للنماذج الأولية السريعة والمواقف المنطقية الأقل تعقيدًا ، لكنه غالبًا لا يستطيع فعل كل ما يمكن فعله في الكود.

يتم تخطيط البرمجة النصية المرئية في مرحلة ما

شكرا على الرد البسيط والإيجابي.

الجميع ، شكرا للتعليق على هذا الاقتراح. أعتقد أن المحرر السهل والمرئي لا يقدر أبدًا على استبدال الترميز يدويًا. أقترح أن تكون هذه الميزة مكملة للترميز العادي وليس لاستبدال موقعها.

في RPG Maker VX Ace ، يتم ترميز معظم الميزات المتقدمة يدويًا. عادةً ما يوفر المبرمجون المتقدمون نصًا متقدمًا للتعديل يمكن تعديل القيمة في محرر واجهة المستخدم الرسومية بواسطة مستخدم عادي (اسم الشخصية ، المهارة ، الصورة ، العفريت ، إلخ). يتيح نظام البرمجة النصية للعبة Ruby إمكانية ترقيع القرود. هذا هو السبب في أن معظم البرامج النصية التي يوفرها المستخدم المتقدم لن تحل محل الفئة الأصلية المحددة مسبقًا بواسطة مطوري RPG Maker لتجنب مشكلات التوافق.

للمقارنة:
لا تنوي مشاريع KDE و GNOME أبدًا استبدال أوامر Shell القوية في Linux ، وبدلاً من ذلك تحاول المشاريع فقط سد الفجوة بين سهولة الاستخدام وقوة Linux.

ابتسمت لفكرة أن يكون استوديو Okam مثل Steam ... :))

في 1/14/2015 5:20 مساءً ، كتب RyanBram:

مرحبًا ، مطورو Godot.

بادئ ذي بدء ، أود أن أشكركم جميعًا على إنشاء لعبة رائعة
محرك برخصة متساهلة للغاية. مجهودك سيساعد الكثيرين
المطورين والطلاب بميزانية محدودة لتحقيق حلمهم.

مع الوضع الحالي لـ Godot ، ستكون الألعاب مفتوحة المصدر أكثر إشراقًا
مستقبل. لسوء الحظ ، تم تصميم معظم البرامج مفتوحة المصدر لمحرك اللعبة
مع وضع المستخدم المتقدم في الاعتبار مع القليل من المعرفة حول البرمجة. هو - هي
لا يزال يتعذر الوصول إلى صانع ألعاب مبتدئ.

اقتراحي هو توفير مصمم / محرر لعبة سهل الاستخدام
واجهة المستخدم الرسومية البديهية والفئة المحددة مسبقًا لتسهيل مهمة المبرمج الجديد.
المزيد من المبرمجين يعني مستخدم أكثر (لأن مستخدم Godot هو مبرمج ألعاب).

أعرف محركًا واحدًا للعبة يقوم بهذه المهمة جيدًا. هو مكتوب من روبي ،
أصله من اليابان ، ومُترجم إلى الإنجليزية في جميع أنحاء العالم. أنه
يسمى RPG Maker VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace.
على الرغم من كلمة RPG الموجودة أمام اسمها ، إلا أنها قادرة على ذلك
قم بإنشاء لعبة غير RPG باستخدام نظام البرمجة النصية لألعاب Ruby (RGSS) المدمج.

https://camo.githubusercontent.com

القائمة التالية هي مثال على الألعاب التي تم إنشاؤها باستخدام محرك RPG Maker:

1. ألف (مغامرة آر بي جي) http://www.pioneervalleygames.com/
2. عدم وعد خراف البحر (أركيد) http://rpgmaker.net/games/5102/
3. راغاروك - بيستياريوم (لعبة بطاقات) http://rpgmaker.net/games/5808/
4. الأرض تحت الهجوم! (مطلق النار) http://rpgmaker.net/games/6561/
5. تيرا (VisualNovel) http://rpgmaker.net/games/3956/
6. ذكريات مانا (أكشن آر بي جي)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. ميهوس - البداية (الرعب) http://rpgmaker.net/games/6493/

أتمنى أن يصبح محرك Godot مشهورًا مثل RPG Maker ، لأنه كذلك
ميزات أكثر بكثير من RPG Maker. يحتاج المبرمج المبتدئ فقط إلى ملف
واجهة سهلة الاستخدام. إذا كان ناجحًا ، فقد يصبح استوديو Okam التالي
GOG أو Steam التي تنشر آلاف الألعاب التي أنشأها مطورو مستقلون.

مع تحياتي ، ريان

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220.

يحتوي Unreal في الواقع على قوالب لمشاريع سواء كنت تريد القيام بامتداد
البرمجة النصية المرئية أو نوع البرمجة النصية الكامل لسير العمل ... وحتى
يمكن الوصول إلى كتل من التعليمات البرمجية للتحرير المرئي عبر الاستوديو المرئي ويكون
حسب الطلب... :)

في 15/1/2015 3:44 صباحًا ، كتب خوان لينيتسكي:

SolarLune : البرمجة النصية المرئية مفيدة عندما تعمل مع ملف
مبرمج ، يمكنه إنشاء كتلة لتلعب بها.
هذه
النهج في Unreal مفيد. لا أعتقد أنه من الممكن استبداله
البرمجة بالكامل (إلا إذا كنت مازوشيًا) ، لكنها قد تعمل من أجلها
يقوم بعض الأشخاص بعمل قوالب قوالب لغير المبرمجين أيضًا.

يوم الأربعاء 14 يناير 2015 الساعة 4:23 مساءً ، كتب TheoXD [email protected] :

يبدو أن صانع ألعاب تقمص الأدوار يتخذ نهج "التعديل" ، وإذا شاء جودو
تبدو أشبه بصانع ألعاب تقمص الأدوار - الأشخاص الذين لديهم نوايا مختلفة
نوع من الألعاب سوف يبتعد. إذن ما تقترحه هو في الأساس
اجعل godot يبدو مثل GameMaker (وهو أمر مفهوم ، كثير
اشخاص
تريد أن تصنع ألعابًا ولكن لا تعرف البرمجة) ولكن هناك حد :)
ما سيحدث على الأرجح هو أن جودو سيحصل على رسم بياني للسلوك العقدي
محرر ، مشابه لما يمتلكه ليدويركس و بي جي إي. هذا يعمل بشكل جيد جدا
مع
عناصر واجهة المستخدم الرسومية ، فإن الباقي يتطلب بعض البحث وأطنانًا من
تواصل اجتماعي
التعليقات ، لجعلها سهلة وقوية قدر الإمكان.

SolarLune https://github.com/SolarLune ، من الممكن بناء لعبة
في Godot وأضف محررًا في الأعلى يسمح بتعديل اللعبة في كل مكان
القليل من التفاصيل (باستخدام GraphNodes وبقية واجهة المستخدم) ، وحتى
السماح ل
اكتب بعض كود GDscript الإضافي في الأعلى ، أعتقد أن هذا هو الأفضل
يقترب،
لشحن لعبة كاملة (RPG ، FPS ، RTS) بشكل منفصل والسماح
التغيير والتبديل
كل جانب من جوانبها.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69978224.

ابتسمت لفكرة أن يكون استوديو Okam مثل Steam ... :))

كما ابتسمت بطريقة إيجابية.
لأنه سيكون أمرًا رائعًا بالنسبة لي كلاعب إذا كانت هناك شركة كبيرة مثل Steam بها العديد من كتالوج الألعاب ، والمفتوحة ، ومجانية DRM ، التي أنشأها الآلاف من مطوري الألعاب الرائعين.

يحتوي Unreal في الواقع على قوالب لمشاريع سواء كنت تريد القيام بامتداد
البرمجة النصية المرئية أو نوع البرمجة النصية الكامل لسير العمل ... وحتى
يمكن الوصول إلى كتل من التعليمات البرمجية للتحرير المرئي عبر الاستوديو المرئي ويكون
حسب الطلب... :)

رائع إذا كان متاحًا في Godot.

يعتبر،
ريان

اهلا ريان

هل قمت بفحص Construct 2؟ إنه أحد مصممي الألعاب المرئية المفضل وسهل الاستخدام للغاية.

أعتقد أن البرمجة المرئية في Godot سيكون من الصعب القيام بها إلى حد ما (كما يفعل Godot كلاً من 2D و 3 D لذا فإن النطاق أكبر بكثير.)
ومن المحتمل أيضًا أن يتم بناؤه في وقت لاحق عندما تكون جميع الكتل الأساسية للمحرك في مكانها.

أعلم أن لدى reduz خارطة طريق خاصة به لهذا ولكن آمل ألا يعطي الأولوية لهذا الأمر على تحديثات المحرر / المحرك الأخرى. أفضل استخدام برنامج Godot من قبل مبرمجين مبتدئين أو شبه محترفين بدلاً من غير المبرمجين. لكن هذا أنا فقط.

اهلا ريان

هل قمت بفحص Construct 2؟ إنه أحد مصممي الألعاب المرئية المفضل وسهل الاستخدام للغاية.

حاولت Construct 2. إنه لطيف ورائع. تتقاطع الألعاب الناتجة أيضًا مع النظام الأساسي ، لذا فهي ميزة كبيرة. لسوء الحظ ، ما زلت لا أستطيع العثور على أي برنامج تعليمي لإنشاء ألعاب RPG بسهولة. في الوقت الحالي ، قد أبقى مع RPG Maker VX Ace وأحاول نقل لعبتي إلى العديد من الأنظمة الأساسية (بما في ذلك Android) بمساعدة MKXP Project .

شكرا للمشاركة. إنني أتطلع إلى البرمجة المرئية في Godot.

مع أطيب التحيات،
ريان

لنهج البرمجة النصية المرئية - يمكنك تدوين ملاحظات من gdevelop ودمج الوسائط المتعددة وإنشاء 2. تعتمد هذه المحركات بنسبة 100٪ على البرمجة النصية المرئية. ما زلت بحاجة إلى تعلم بعض بناء الجملة حيث تكون هناك حاجة إلى التعبيرات ، لكن محرر التعبير يجعل من السهل للغاية العثور على الأوامر الصحيحة. تمنحك هذه المحركات الثلاثة الحرية في إنشاء أي نوع من الألعاب باستخدام البرمجة النصية المرئية - على عكس صانع الألعاب وصانع ألعاب تقمص الأدوار.

صانع ألعاب تقمص الأدوار ليس مثالًا جيدًا حقًا ، لأنه محدود للغاية.
البرمجة النصية القائمة على العقدة غير كافية للغاية من حيث استخدام الفضاء - سوف تقوم بالتجول والتكبير والتصغير من خلال رسم بياني للعقدة العملاقة. قارن ذلك بالبناء 2 ، حيث يتم وضع كل شيء بطريقة واضحة ومحكم وسهل القراءة - وحصلت على فائز.

ربما يكون BGE هو أسوأ مثال هنا ، لأنه يحاول الجمع بين نهج قائم على العقدة مع الكتل المنطقية. كتبت عن سبب كون هذا أمرًا سيئًا:
http://blenderartists.org/forum/showthread.php؟323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

إذا كنت تقوم بعمل نصوص برمجية ، من فضلك لا تقم بتثبيتها باستخدام محرر عام قائم على العقدة. إذا كنت تريد المزيد من الأشخاص غير المبرمجين لاستخدام محركك ، فافعل شيئًا بتصميم أفضل - مثل الإنشاء 2 أو اندماج الوسائط المتعددة.

أود أن أرى شيئًا كهذا مطبقًا _ فقط_ كطريقة ثانوية للبرمجة. البرمجة النصية المرئية ، على عكس الكود ، تبطئ الإنتاجية بمقدار كبير جدًا. كما أنه يميل إلى جعل تصحيح الأخطاء وإعادة البناء أكثر صعوبة. الجانب الإيجابي الوحيد الذي يمكنني التفكير فيه (إلى جانب جاذبيته لغير المبرمجين) هو أن البرمجة النصية المرئية تميل إلى أن تكون أداة تعليمية رائعة إذا كانت قادرة على إنشاء ، أو على الأقل إظهار ، كود GDScript الفعلي (IE. code. org). لا أعتقد أنه سيكون بحاجة للذهاب في الاتجاه الآخر (IE. GDScript to Visual). أعتقد أن هذه ستكون طريقة رائعة للمدارس لتبني Godot في فصولها.

فيما يلي اختلافان رئيسيان بين الكود والبرمجة النصية المرئية التي أعتقد أنها الأكثر أهمية بقدر ما يمكن الوصول إليها. يأتي هذا من شخص لا يلمس البرمجة النصية المرئية بعمود 10 أقدام ، لكنني أفهم أنه يروق لبعض الأشخاص :)

الكود: تميل الشفرة إلى أن يكون لها قواعد نحوية محددة يجب اتباعها. أعتقد أن هذا يميل إلى أن يكون الشيء الرئيسي الذي يوقف عمل غير المبرمجين. بمعنى آخر. في GDScript ، يكون لديك نقطتان في نهاية إعلان الوظيفة ، إذا ، من أجل ، أثناء التكرارات وما إلى ذلك. يجب وضع مسافة بادئة بشكل صحيح. يجب عليك استخدام كلمة var عند التصريح عن متغير مثل "var myInteger = 1". بالنسبة لمعظم اللغات ، تميل إلى أن يكون هناك حوالي 3 أو 4 قواعد نحوية أساسية تميل إلى الحاجة إلى اتباعها وفي رأيي ليس من الصعب تعلمها. بعد كتابة عدد قليل من النصوص الصغيرة يمكن للفنان أن يتعلمها. أقول هذا لأنني أعمل مع فنانين موهوبين للغاية عملوا في جميع ألعاب Age of Empires الثلاثة مع Ensemble Studios. كتب أحدهما قدرًا كبيرًا من التعليمات البرمجية في UnityScript والآخر كتب الآن عددًا كبيرًا من التعليمات البرمجية في C #.

مرئي: تميل إلى الحصول على قائمة منسدلة للطريقة ، والمتغير ، والبيان ، وما إلى ذلك. ومع ذلك ، لا يزال يتعين عليك معرفة الوظائف ، والخصائص ، وما إلى ذلك التي تبحث عنها وماذا تفعل ، وحتى في بعض الأحيان كيف تعمل. لا يزال عليك حل المشكلة. لا يزال يتعين عليك استخدام المتغيرات وتتبع ما يفعلونه خلال البرنامج النصي الخاص بك. لا يزال بإمكانك الحصول على أخطاء منطقية بنفس سهولة كتابة التعليمات البرمجية.

أعتقد أن القدرة على كتابة الكود في الواقع طريقة أفضل بكثير للانتقال من وجهة نظر الإنتاجية. ومع ذلك ، لن يجعلك أي منهما مبرمجًا أفضل / أسوأ. أعتقد أن البرمجة النصية المرئية هي أداة تعليمية جيدة حقًا ، ولكن إذا كنت لا تعرف (أو تريد أن تتعلم) كيفية هيكلة الأشياء بشكل صحيح وخاصة كيفية حل المشكلات ، فلن تساعدك البرمجة النصية المرئية قليلاً.

سوف أتبع نهجًا مختلفًا قليلاً. نظرًا لأن محرر godot يعتمد على نفسه - فمن السهل إعادة إنشاء واجهة محرر مماثلة في GDscript خالص.

لذا فإن اقتراحي هو إنشاء مُنشئ مكتوب بالكامل في godot وشحنه بشكل منفصل. سيسمح هذا للمبرمجين وغير المبرمجين بالعمل في نفس المشروع أثناء استخدام أدوات مختلفة. المشكلة الوحيدة هي أن غير المبرمجين سيتعين عليهم أحيانًا التعامل مع كلتا الأداتين في نفس الوقت ، ولكن مهلا ، لقد رأيت محرر xD Gridmap أسوأ ، محرر تظليل ، محرر رسوم متحركة ، محرر كود - يمكن إعادة إنشائه ، بينما مستورد collada ، محدب مولد ، مصدرين - ليس بهذه السهولة. لا يزال يبدو وكأنه إعادة اختراع العجلة ، ولكن يمكن تبسيط الكثير من الأشياء.

يمكن اعتماد نواة المُنشئ على أي نوع من الألعاب (FPS ، RTS ، GPS ....) مع محتوى وأشياء قابلة للتنزيل ، وإذا كان المجتمع يتم صيانته - فسيكون من الأسهل المساهمة ، لأن كل شيء هو GDscript
من غير المحتمل أن تكون هناك برمجة نصية مرئية في godot في أي وقت قريب ، لكن هذا لا يمنع الآخرين من إنشاء مُنشئ فوقه. لقد رأيت شخصًا ما أخذ Blender 2.5 وصنع أداة للتصميم الداخلي.

أعتقد أن وجود عدة محررين قد يؤدي إلى تشظي تطور جودو. يجب أن يكون هناك مشروع مركزي واحد مصمم جيدًا لأداة البرمجة النصية المرئية التي يتم إنشاؤها فوق gdscript.

لا تكن كسولاً وقم بأبحاثك. انظر إلى محركات البرمجة النصية المرئية البحتة الأخرى. قارن قاعدة المستخدمين الخاصة بهم (مدى شعبيتها) ، قارن بين مدى مرونتها - أنواع الألعاب التي صنعت معهم - سواء كان ذلك على كيك ستارتر أو ستيم أو منصات أخرى.
انظر إلى نهج التصميم الخاص بهم.

ثم صممه على الورق. لا تقم فقط بنسخ نهج العقدة. إن استخدام العقد للتظليل أمر جيد ، ولكن عندما يتعلق الأمر بالمنطق ، ينتهي بك الأمر مع جحيم واحد من الفوضى للتمرير ومحاولة اكتشاف ذلك.

صدقني ، لقد جربت كل شيء. صانع ألعاب Unity ، و Unreal's Kismet ، و rpg maker ، و stencyl ، إلخ.
يأتي Construct2 على القمة ، جنبًا إلى جنب مع اندماج الوسائط المتعددة. هذه هي الأكثر شيوعًا ، مع النهج الأكثر مرونة. وكلاهما لديه متجر أصول.
إنها مرنة للغاية وإذا نظرت إلى الألعاب المصممة بها - فهناك مجموعة كبيرة ومتنوعة من الأنواع.

إذا كنت أكثر ذكاءً بشأن هذا الأمر ، فيمكنك التعاون مع Gdevelop- مشروع آخر مفتوح المصدر يحتوي بالفعل على محرر نصوص مرئي يصنع ألعاب html5.
انظر إلى تصميمه وشفرته المصدرية ..

إذا أردنا التصويت على هذا الموضوع ، فأنا متأكد تمامًا من أنه سيكون المكان الخطأ تمامًا لأن المبرمجين سيظهرون للتصويت بشكل أساسي.

يجب تصميم نظام البرمجة المرئية للفنانين وليس للمبرمجين. بقدر ما يمكنني الشكوى من كرهتي المطلقة لأشياء مثل PlayMaker on Unity ، فإن الحقيقة هي أن الفنانين يحبونها. هذا هو السبب في أنه يحتوي على ما يقرب من 2000 مراجعة وهو 5 نجوم. إذا كان التصويت هو الحصول على شيء يشبه البرمجة النصية لـ Construct 2 ، فإن تصويتي هو عدم وجود نصوص مرئية على الإطلاق لأنني لا أعتقد أنها ستكون ذات فائدة حقيقية منذ أ) يمكن للمبرمجين البرمجة مباشرة في GDScript و B) العديد من الفنانين سيتم إيقاف تشغيله على الفور من خلاله وانتقل إلى مكان آخر. أعلم ، لأن صديقي الفنانين ، اللذين يستطيع كل منهما البرمجة ، كانا يبحثان في Construct 2 ويستمتعان بواجهة البرمجة التي يمتلكها نظرًا لأنه يشبه كتابة الكود.

يجب أن تكون لغة البرمجة النصية المرئية مرئية للغاية ، وليس كلمات كثيرة. لا ينبغي أن يبدو مثل الكود للوهلة الأولى. يجب أن تكون مصممة خصيصًا "للأشخاص المرئيين" ، وإلا فلا فائدة من جعلها في المقام الأول. الفنانون معتادون على الرسوم البيانية للعقدة ويميلون إلى الإعجاب بها لأنها تمنحك إحساسًا مرئيًا بما يفعله برنامجك. مرة أخرى ، لا أحب الرسوم البيانية للعقدة بنفسي لأنني لا أستطيع تحملها ، لكنني مبرمج وصوتي لا ينبغي أن يحسب في هذا المجال.

أتفق معك في أنه ينبغي تصميمه للفنانين / المصممين.
لكن لا توافق على المنطق القائل بأن الكلمات = التعقيد.

إذا جلست شخصًا ما لتعليمهم استخدام أحدهما - فسيظهر البناء 2 على أنه الأسهل من الاثنين. لماذا ا؟
لأنه أوضح من العقد. أكثر وضوحا. لديك شروط وأفعال. تضع الأول في الجانب الأيسر والآخر على الجانب الأيمن.
لإضافة أي من الاثنين ، ليس عليك معرفة الأوامر. كلهم مدرجون هناك لإضافتهم - واضح ليوم واحد. يأتي كل منها مع رمز - وهو تلميح مرئي.

تتطلب أنظمة Playmaker والأنظمة الأخرى القائمة على العقد مزيدًا من التعلم ، لأن ربط عقدة بعقدة أخرى يتطلب منك أولاً فهم ما إذا كان بإمكانك توصيل الاثنين. انها ليست مجرد شرط -> العمل. العقد طريقة أكثر تعقيدًا وتفتقر إلى التلميحات المرئية. أين رأيت الأيقونات في صانع الألعاب ؟؟
من الأسهل بكثير أن نخطئ فيه. من الصعب قراءة المنطق فيه.
https://www.scirra.com/tutorials/top
أود أن أزعم أيضًا أنه نظرًا لأن C2 هي أداة برمجة مرئية مصممة بشكل أفضل ، فإن لديها مجتمع مستخدمين نشطين أكبر بكثير من مجتمع صانع الألعاب - على الرغم من أنها تقتصر على الألعاب ثنائية الأبعاد في الوقت الحالي. عدد أكبر بكثير من دروس الفيديو على الويب (يتعرف المزيد من الأشخاص على كيفية استخدامها أكثر من صانع الألعاب) ، والمزيد من المشاريع المكتملة ، والسوق النشط الصحي والمنتدى ، والأهم من ذلك كله التواصل النشط بين المطورين والمستخدمين. حتى يعرف المطورون ما يريده المستخدمون الفنانون.

يمكن لمستخدمي Construct ببساطة التقاط لقطة شاشة لورقة الأحداث الخاصة بهم ومن الواضح أنها فعلت ذلك يومًا ما. اذهب إلى المنتديات انظر بنفسك. أود أن أزعم أن لديها مستخدمين أكثر بكثير من صانع الألعاب.

أود أن أزعم أن إعداد المنطق فيه يتطلب عملاً أقل مما يتطلبه أي نظام قائم على العقدة.

أستطيع أن أرى أنك تحبهم ، لكن من فضلك على الأقل حاول بناء 2 قبل التصريح بأنه محرك مبرمج.
انظر إلى المنتدى وقاعدة المستخدمين الخاصة بهم. لديها ممثل جيد إن لم يكن أكثر من صانع الألعاب. لقد تمكنت من الحصول على هذا الممثل الجيد من خلال تصميمها جيدًا - بمفردها - وليس من خلال كونها مكونًا إضافيًا لمحرك ناجح بالفعل. إنها أداة برمجة بصرية خالصة يمكن لأي فنان استخدامها. أنا فنان وجربت صانع الألعاب - إنه أصعب من البناء 2. انتقل إلى منتدى C2 وحاول إقناعهم بأن استخدام صانع الألعاب أسهل - للضحك فقط. :د
ألست أنت نفسك مبرمجا؟ لقد ساهمت في مشاريع جيثب أكثر مني. لا يعني ذلك أنه لا ينبغي عليك الإدلاء ببيان يسهل تعلمه؟

أفهم نقاطك من وجهة نظر المبرمج. إذا كان علي الاختيار بين الاثنين ، فسأختار نموذج Construct أيضًا. ومع ذلك ، كما قلت ، هذا هو أسوأ مكان لاتخاذ هذا القرار لأنه ربما يكون معظم الأشخاص الذين يقرؤون قوائم بريد GitHub ، إن لم يكن جميعهم ، من المبرمجين.

قضيت مسيرتي المهنية حول الفنانين أكثر مما أمضيته حول المبرمجين. بينما كنت أفعل كليهما بانتظام على مدار الـ 18 عامًا الماضية (وكنت متحمسًا لكليهما) كنت فنانًا محترفًا قبل أن أكون محترفًا مبرمجًا. لا يهمني حتى أنني حصلت على شهادة ، شهادتي في الرسوم المتحركة الرقمية والتأثيرات المرئية. على حد علمي ، لا تزال الإعلانات التجارية التي عملت عليها تعمل بعد عدة سنوات في مدينة كانساس. لقد عملت على لقطات لهولمارك ، وسبرينت ، وراديو شاك ، وهوندا ، وعدد قليل آخر من المحتمل أن أنساهم. كما استمتعت كثيرًا بالعمل على عدد قليل من اللقطات في "World Builder" مع Bruce Branit.

https://www.youtube.com/watch؟v=QP3YywgRx5A
ناثان واردن في الاعتمادات هو لي

أنا لا أقول هذا للتفاخر ، أنا أقول هذا لتوضيح نقطة. قد أكون مخطئًا ، لكن بصفتي فنانًا أمضى الكثير من الوقت مع الفنانين ، أعتقد أنني أعرف ما يحبه الفنانون. إنهم لا يميلون إلى الإعجاب بأشياء مثل Constructor كثيرًا. إنهم يميلون إلى الشعور بالخوف ويختارون تطبيقًا مختلفًا تمامًا. الفنانين بشكل عام لديهم minset مختلف جدا عن المبرمجين. يبدو الأمر كما لو كنت أتحدث مع صديقي إريك حول الأشياء التقنية التي أحاول تعليمها ، تخرج هذه الكلمات من فمه كثيرًا ، "نيت ، أنا شخص مرئي جدًا ، إذا لم تتمكن من إظهارها لي بصريًا ، ربما تتحدث أيضًا إلى الحائط ".

هناك سبب يجعل الفنانين يستمتعون بأشياء مثل الرسوم البيانية التظليل القائمة على العقدة بدلاً من أنظمة التظليل الخطي. يمكنهم تصور ما يحدث. لا أعتقد أنني سمعت يومًا فنانًا يشكو من عدم وجود نظام تظليل خطي في تطبيقه المفضل ثلاثي الأبعاد ، لكنهم يشتكون بانتظام عندما لا يكون لديهم نظام تظليل قائم على العقدة.

هناك سبب يجعل الفنانين يفضلون تطبيقات مثل Fusion على After Effects. في كل حالة تقريبًا ، سيختارون شيئًا يعتمد على العقدة الخطية لأنها أكثر وضوحًا.

إذن ، هناك سببان آخران يدفعان النظام القائم على العقدة إلى جذب الفنانين:

1) تبدو بصريًا أكثر جاذبية.
2) يتناسب مع نموذج التصميم الذي اعتادوا عليه بالفعل. IE التظليل والتركيب

هذا حقًا ما يأتي إليه الأمر. إذا كان الفنان سيأخذ نظرة واحدة ويمرر إلى محرك اللعبة التالي لأن الآخر لديه برمجة قائمة على العقدة ، فلا ينبغي أن يكون لدى Godot نصوص مرئية على الإطلاق ، لأنه ربما لن يكون هناك أكثر من حفنة صغيرة من الناس من سيستخدمها وهذا يعني فقط المزيد من صيانة الكود من تلك النقطة فصاعدًا.

هل أنت متأكد من أن لديك أي فكرة عن Construct2؟ أنت حتى لا تهجئ اسمها بشكل صحيح.
لا يطلق عليه "المنشئ".

أنا لا أوافق تمامًا على أنه يجب علينا استخدام العقد لأنه "لا ينبغي أن يبدو مثل الكود للوهلة الأولى."

إن مدى وضوحها أكثر أهمية من مظهرها. وضوح ما يفعله المنطق أكثر أهمية من مظهر المحرر للوهلة الأولى. لا يبدو Construct2 مثل الكود - النص مكتوب بلغة إنجليزية بسيطة ومن الواضح ما يفعله الإجراء أو الشرط. يميل الأشخاص الذين يستخدمون C2 إلى أن يكونوا في الغالب أشخاصًا مرئيون أيضًا.

ستفوز ورقة الحدث دائمًا على العقد - ومع ذلك تحاول أن تجعلها تبدو. يمكن أن يحزم المزيد من المعلومات على الشاشة مع قدر أقل من التنقل - إنه أكثر وضوحًا ما يفعله المنطق. والعثور على الإشارات المرئية (الأيقونات) أسهل بكثير بواسطة عين الفنان.
لا تحتوي العقد على أيقونات ويوجد قيود كبيرة على النص.
لذلك في كثير من الحالات ، لا تصف العقدة ما تفعله بوضوح ، بسبب محدودية حجمها - مما يجبر التصميم على استخدام مصطلحات غامضة بدلاً من اللغة الإنجليزية البسيطة.

نقطة اخرى:
تتم قراءة ورقة الأحداث وتنفيذها من أعلى إلى أسفل. هذا واضح ويمكن التنبؤ به.
مع شبكة العقدة ، ستنتقل عيناك في كل مكان ، وتنقسم إلى فروع. يصبح الطريق أكثر تعقيدا.

يجب ألا تحمل قصص رأي الشخص الثالث في اللمحات الأولى وليس تجربة المستخدم الفعلية أي وزن هنا. أنا أيضًا شخص مرئي للغاية ، لكنني شخص استخدم بالفعل العديد من محركات البرمجة النصية المرئية. إنه لألم مطلق في الرقبة أن ترى الناس يتجادلون دون استخدام المحركات الفعلية لفترة - بمشروع صغير على سبيل المثال.

أحث المصممين / المطورين / الأشخاص البصريين من Godot على تجربة هذه المحركات فعليًا في مشروع صغير الحجم ثم الوصول إلى الاستنتاجات. كفى من قصص الطرف الثالث هذه. نحن بحاجة إلى البحث العملي والحالة المعلنة منطقيًا لماذا يكون أحدهما أفضل من الآخر. صدق أو لا تصدق ، يتمتع المرئيون ببعض الحس السليم أيضًا.

خارج الموضوع:
في مثال Fusion مقابل Aftereffects - يفضل الأشخاص نهجًا قائمًا على العقدة للتركيب ، لأن استخدام الطبقات يمكن أن يكون مرهقًا للغاية في مشهد معقد حيث يمكن تكرار نفس التأثير على العديد من الطبقات. باستخدام العقد ، يمكنك الحصول على مزيد من المرونة من حيث التركيب وربط تأثير واحد فقط بالعديد من الطبقات. لكن العقد أكثر تعقيدًا من الطبقات.

أتفق معك في جميع النقاط تقريبًا ، لكن هذه النقاط لا تزال من منظور المبرمج. إذا اضطررت إلى استخدام نظام البرمجة النصية المرئي طوال اليوم ، فسأختار النظام الذي يشبه إلى حد كبير الكود العادي. لهذا السبب أنا من أشد المعجبين بتعليم الأطفال الذين يرغبون في تعلم كيفية البرمجة باستخدام code.org. أنا حقًا معجب كبير بالأسلوب. من الجيد تعليم الأشخاص الذين "يريدون" برمجة كيفية البرمجة.

ونعم ، قلت بناء خاطئ ، آسف. لا لم أستخدمه شخصيًا. لكن ، لا يهم لأن نموذج البرمجة النصية الذي يستخدمه ليس مفهومًا جديدًا بأي شكل من الأشكال ، لذا فإن حجتي لا تتعلق حتى بالبناء نفسه. يتعلق الأمر بنمط البرمجة هذا من حيث صلته بالفنانين وليس المبرمجين.

في النظام القائم على العقدة ، يمكن أن يكون لديك العديد من الشروط والأحداث والوظائف الموجودة داخل كل عقدة. يمكنك بعد ذلك تسمية العقدة بشيء مثل الإدخال ، على سبيل المثال. سيحتوي داخلها على جميع مدخلات عصا التحكم وسيخبرها المستخدم بالحدث الذي يجب استخدامه. بمعنى آخر. سيحددون حدثًا مثل "حريق". قد يتسبب هذا الحدث في الانتقال إلى أي عقدة قاموا بتوصيلها بها.

إليك مثال بسيط يمكن أن يكون لديك على سلاح يمكنه ببساطة التعامل مع إطلاق النار. لاحظ أنه على الرغم من بساطته ، إلا أنه قوي أيضًا ولا يشبه الكود:

في ملاحظة أخيرة ، يمكنك جعل البرمجة النصية القائمة على الكتلة أو البرمجة النصية القائمة على العقدة تبدو جيدة جدًا من وجهة نظر الواجهة ، لذلك لن أضيع وقتي في مناقشة هذه النقطة.

ومع ذلك ، عندما قلت "لا ينبغي أن يبدو مثل الرمز للوهلة الأولى." يهتم العديد من الفنانين بما سيبحثون عنه طوال اليوم كل يوم لفترة غير محددة من الوقت. سيرفضون تطبيقًا كاملاً إذا كان لا يبدو جذابًا أو إذا بدا مخيفًا. أود أن أقول أن المبنى القائم على الكتلة يبدو مخيفًا ومربكًا لفنان نموذجي. يبدو أنه شيء بالنسبة للمبرمجين ، وهو كذلك.

@ blurymind ،

عُقد الرسم البياني أتت بالفعل من UML المفاهيمي. أنت تقوم بعمل تمثيل رسومي للرمز بطريقة يمكن للجمهور غير البرمجة (مديري المشاريع ، والمستهلكين ، والفنانين) فهمها. هذا ما تستخدمه UE4 / Unity. هذا شيء يدركه الجميع في الصناعة. عادة ما يتخذ المنشئون نهجًا مختلفًا ، ومدى جودة هذا النهج - لا يتم تحديده من خلال عدد المستخدمين الذين يستخدمونه.

يوجد دائمًا منحنى تعليمي في كل مكان ، ولا يعد Construct2 استثناءً. لكن دعونا لا نجبر عناصر C2 على Godot دون دعم الحجج. ستصبح ورقة الأحداث أطول مع الألعاب الأكثر تعقيدًا ، وينتهي الأمر بإهدار مساحة أكبر من عقد الرسم البياني. فقط الزر "إضافة إجراء" له صف خاص به. إنها في الأساس الطريقة التي يفسر بها المبرمج كتلة من التعليمات البرمجية. لذا فهي ليست بهذا السوء.

أنا شخصياً لا أفهم لماذا لا يمكننا الحصول على كليهما ، لكن المطورين لديهم بالفعل ما يكفي للقيام بذلك ، ولن يحدث ذلك في أي وقت قريب. لهذا السبب اقترحت نهجًا مختلفًا سيتطور بشكل أسرع ، مدفوعًا إلى حد كبير من قبل غير المبرمجين بالتعاون مع المبرمجين.

إليك أفضل مثال لتوضيح أنه يمكنك الحصول على أكثر من حدث واحد لكل عقدة. لاحظ أيضًا أن كل عقدة (أو حالة) غير محظورة ، لذلك ستسمح للرسوم البيانية للعقد الأخرى بالعمل بشكل متزامن:

لكن انظر ، بمجرد النظر إلى لقطة الشاشة الخاصة بك ، ليس لدي أي فكرة عما يفعله هذا المنطق. ما هو الجحيم "النار الابتدائية" و "ثانوية النار" ؟؟
الآن قم بالتمرير لأعلى إلى لقطة الشاشة التي قمت بنشرها من build2.
في الإنشاء 2 ، سيقرأ الشرط الموجود على اليسار "على" R "مضغوط" أو أي شيء يكون باللغة الإنجليزية البسيطة - مع رمز لوحة المفاتيح بجواره!

أظهرهم للفنان واسألهم أيهما أوضح.

أظهر لنا أيضًا إعدادًا أكثر تفصيلاً للعقدة :) تعرض لقطة شاشة C2 منطق اللعبة بالكامل. لك حدث واحد فقط. هل يمكنك تطبيق نفس المنطق في لقطة شاشة واحدة مع العقد؟ لا أعتقد ذلك.

انظر مثال العقدة التي تحجب المعلومات.
يجب عليك تحديد عقدة لمعرفة ما يتم تعيينه بداخلها.
إنها تستخدم مصطلحات مبرمج غامضة بدلاً من لغة بشرية ("إرسال حدث" ، "نتائج تخزين" ما بحق الجحيم؟).
يعرض Construct2 كل شيء في مكان واحد ويمكن فهمه لغير المبرمجين. الهدف من البرمجة المرئية هو التخلص من الحاجة إلى تعلم المصطلحات.

انا لست مبرمج ليس لدي أي خبرة في كتابة الكود الفعلي. ومع ذلك ، يمكنني صنع لعبة باستخدام build2 بسهولة ، وبالنسبة لي فإن استخدام العقد يعد أمرًا صعبًا - عندما يتعلق الأمر بلعبة كاملة.

أفهم أن الجميع سيصوتون دائمًا لما يعرفون بالفعل كيف يفعلون جيدًا. ولكن كما اعترفت ، فأنت مبرمج ولم تستخدم C2 بالفعل. وأحتفظ ببيان أنني فنان ليس لدي أي خبرة في الترميز - وقد استخدم كل من العقد وطريقة C2.

أقدم لكم الحجج المنطقية الجيدة حول سبب استخدام أحدهما على الآخر.
أنت تعطيني عبارات مثل "العقد أكثر وضوحًا" و "عقد الاستخدامات غير الواقعية". هذه تصريحات عنيدة. وكلاكما تعترف بأنكما مبرمجان.

إن إخباري بأنني لا أدعم حججي هو مجرد تأكيد على عدم رغبتك في النظر في بناء 2 أو اعتبار تصميمه بديلاً للعقد. إنه لأمر محزن أن أقنعك بخلاف ذلك مضيعة للوقت.

تضمين التغريدة
أنا أتفق معك تمامًا إذا كنت أقرأ لك بشكل صحيح. سيكون من الجيد أن يكون لديك كلاهما كمكوِّن إضافي / وحدة منفصلة. لذلك ، سيكون تحته GDScript فعليًا ، لكن يمكنك تخيله باستخدام ما تريد. أعتقد أن هذا ممكن. قد يحتاج النهج القائم على العقدة إلى بعض العلامات مثل التعليقات الخاصة لفصل العقد (IE. #node name = "Input" و #endnode) ، ولكن ليس بهذا الحجم الكبير من الصفقة لأنه سيكون تلقائيًا إذا بدأت بالرسم البياني للعقدة. أعتقد أن نهج الكتلة سيكون مستقيمًا للأمام.

هل شيء من هذا القبيل ما قصدته؟

كما قلت أعلاه ، أنا حقًا أحب طريقة block / Construct / code.org لأنها تعمل جيدًا لتدريس البرمجة. أنا فقط لا أعتقد أنها مناسبة للأشخاص الذين يرون في البرمجة شرًا ضروريًا.

تضمين التغريدة
السبب وراء عدم منطقيته هو أنك لست على دراية به. عندما ألقي نظرة على صورة Construct أعلاه ، ليس لدي أدنى فكرة عما يحدث ، ليس لأنها سيئة ، ولكن لأنني لست على دراية بها.

بقدر ما لا تكون قادرًا على رؤية ما يوجد أسفل العقدة حتى تضغط عليها ، بمجرد إعداد عقدة ، لا توجد فائدة حقيقية من غربلة ما تعرفه بالفعل. أعلم بالفعل أني قمت بالنقر بزر الماوس الأيمن والأيسر وأنهما يطلقان الذخيرة الأساسية والثانوية. أنا أعرف بالفعل ما تفعله عقد النار الأولية والثانوية. لم يتغير منذ أن قمت به ، فلماذا يجب أن أرى التفاصيل في كل مرة أنظر فيها؟ لذا ، فإن المنطق الأساسي الآن هو مجرد فوضى. هذا سبب آخر يجعل العقد أكثر ملاءمة للفنانين وغير المبرمجين. يمكنهم تقسيم منطقهم المحدد إلى أجزاء أكثر عمومية. إنه يجعله حتى يتمكنوا من الحصول على عرض كبير للصورة والقلق بشأن التفاصيل فقط عندما يحتاجون إلى ذلك تمامًا.

إنني أتطلع إلى مشروع فعلي للعبة جوال منشورة فعليًا في الوقت الحالي ، ويتكون كل رسم بياني للعقدة تقريبًا من 2 إلى 4 عقد على الأكثر ، لذلك من الصعب أن أعرض عليك إعدادًا أكثر تفصيلاً عندما لا تحتاج عادةً إلى إعداد تفصيلي.

إذا كنت تريد التفصيل ، فهذا من نفس التطبيق الذي كتبه شخص غير مبرمج تقريبًا كما يأتي. يعد هذا أحد أكثر الرسوم البيانية تعقيدًا في اللعبة. يتحكم في حركة اللاعب الرئيسي:

(هذا شيء آخر لا يمكنك فعله مع الكتل هو جعلها تبدو مثل سفينة ساموس ، هاها)

بدون أي مطالبة ، قمت فقط بوضع صورة Construct2 الخاصة بك على شاشة واحدة ووضعت الرسم البياني للعقدة أعلاه على الأخرى وسألت زوجتي (التي هي بالتأكيد ليست مبرمجة) ، "أيهما تريد استخدامه إذا كان عليك استخدامه كل يوم؟ "، وأشارت إلى الرسم البياني للعقدة وقالت ،" هذا ". أعلم أن هذا ليس نهائيًا ، لكن حقيقة أنه أقل تخويفًا تعني أن لدي فرصة أكبر بكثير حتى أبدأ في جعلها تتعلمها. إذا بدا الأمر مخيفًا ، فقد تغلق دماغها قبل أن أجعلها تجلس لتعلم الأساسيات.

بدون دفعه نحو أحدهما أو الآخر ، سألت أيضًا صديقي الفنان أمس (نفس الشخص الذي عمل في جميع ألعاب Age of Empires الثلاثة) ، والذي يعمل في صناعة الألعاب منذ ما يقرب من 20 عامًا حتى الآن ، (والذي استخدم Construct2) ما يعتقد أن الفنانين الآخرين يفضلونه وقال أيضًا الرسم البياني للعقدة.

على أي حال ، أنا أستمتع حقًا بالمناقشة ولكن لا معنى لهزيمة حصان ميت ، هاها :)

نعم أنا أستمتع به أيضًا. لا مشاعر سيئة :)

رهيبة ساموس السفينة راجع للشغل. كلما زاد عدد الصور التي تنشرها ، زاد دعمك لحالتي ، حيث يصعب متابعة العقد بصريًا نظرًا لأنها يمكن أن تنقسم إلى فروع وتذهب في اتجاهات مجنونة.
بالنسبة لي ، فإن التعقيد الإضافي المتمثل في الاضطرار إلى اتباع الخطوط والسهام بين الكتل كان دائمًا يبدو وكأنه عمل إضافي. أعتقد أنني يجب أن أعطي العقد مرة أخرى تجربة واحدة من هذه الأيام. إذا كان هذا حيث سيتجه جودو.

مرة أخرى ، أنت تقدم لنا قصصًا بضمير الغائب لا تدعمها الأدلة حقًا. احصل على المتأنق هنا واجعله يخبرنا لماذا يفضل واحدًا على الآخر :)
ثم سيكون لديك حالة أقوى. لا أحصل على أي نقاط منطقية منطقية تدعم الأطروحة القائلة بأن العقد أكثر وضوحًا حتى الآن.

نعم ، يبدو الأمر أقل ترويعًا للوهلة الأولى لأنه يخفي الكثير من المعلومات. الأمثلة الخاصة بك أبسط بكثير مما هو موضح في لقطة الشاشة التي نشرتها. هذا مضلل.
إليك مقطع فيديو يظهر ساخنًا لإعداد منطق لمنصة في C2.
https://www.youtube.com/watch؟v=5RlSmkSbleI
تخطي الدقيقة الأولى: ص

دعونا لا نقارن التفاح بالبرتقال.
Code.org هو نهج مختلف جذريًا عن Construct2 - يبدو أشبه بـ Stencyl وله أحد عيوب العقد: شروطك وأفعالك ليست مفصولة بوضوح - لذلك من الصعب معرفة ما يمكنك إرفاقه بما. أدوات البرمجة المرئية المصممة جيدًا (دمج الوسائط المتعددة ، الإنشاء 2 ، تطوير الألعاب) كلها شروط منفصلة عن الإجراءات بوضوح للمستخدم. هذا يجعل بناء المنطق أسهل بكثير حيث يتم تنظيمها من أجلك بواسطة البرنامج الذي يخمن ما قد تحتاجه ويعرضه لك في الوقت المناسب. كما أنه يمنعك من ارتكاب أخطاء سخيفة.

مع العقد / stencyl / code.org ، عليك معرفة القطعة التي تعتبر شرطًا ، وهو إجراء. يتطلب الأمر مزيدًا من التفكير لإعداد ظروفك بالطريقة الصحيحة. ما نوع المعلومات التي تخرج من العقدة؟ يستغرق الأمر عددًا أكبر من العقد لإعداد حالة ما في بعض الأحيان - وتعلم كيفية ربطها أكثر.
تعال ، قم ببحثك واستخدم الأدوات الأخرى قليلاً. إن رؤية كل العناصر التي لا تحتوي على عقدة على أنها أكثر من نفس الشيء لا يساعد.

blurymind ، حالتك مدعومة حتى الآن بعدد المستخدمين الذين يستخدمون Construct2 ، والذي عادة ما يكون نتيجة لنموذج العمل الخاص بالبرنامج ومدى جودته في التسويق. التفضيل الشخصي (حججك المنطقية) لا يكفي لإجبار سير عمل C2 على Godot. لكنها إشارة جيدة بالرغم من ذلك.

إذا كنت تريد أن تُظهر لشخص ما كيف ترغب في بناء لعبتك (علاقة الكائن بالكائن) على الورق أو السبورة ، كيف ستظهر ذلك؟ عن طريق كتابة شجرة الحدث؟ لا ، يمكنك رسم عرض مفاهيمي باستخدام العقد والخطوط ، ثم التفكير فيها كفئات ، وإضافة وظائف ، وأعضاء ..
أوافق على أن جدول الأحداث يشبه إلى حد كبير رمز ، يتم تفسيره من قبل مبرمج فقط ، ويمكن أن يجعل المستخدمين يرغبون في تعلم البرمجة الفعلية أثناء تقدمهم. لقد لاحظت أنه يحتوي على بعض المصطلحات ومنحنى التعلم أيضًا ، لا يمكنك إنكار ذلك. لكن التعرف على الأشكال وتجميع الكائنات هو في الواقع شيء حقيقي. أنا أدرس دورة تدريبية حول تصور البيانات ، وإلى جانب كيف يمكن أن تصبح مملة - إنها في الواقع تقدم نقاطًا جيدة.

بقدر ما أرغب في رؤية هذه المشكلة تسجل أكثر من 100 تعليق ، لن يقرأها المطورون جميعًا ، وأفضل شيء يمكن أن يفعله كل منا هو عمل ملف PDF مع المقترحات ومشاركتها في القائمة البريدية. لا أفهم لماذا لا يمكننا الحصول على مستويات مختلفة من التجريد ، وعقد الرسم البياني في المستوى الأعلى ، والتي يمكن تمثيلها في شكل شجرة حدث. إذا نجح هذا فلن تكون هناك حاجة لتقديم تنازلات.

" blurymind - || - وأنتما تقران بأنهما مبرمجان." - أنا لا أعتبر نفسي مجرد مبرمج ، هل تعلم أن الفن أيضًا. أستخدم خبرتي للنظر إلى الأشياء من وجهة نظر موضوعية.

لست متأكدًا مما إذا كان قد فاتني ، لكنني لست مجرد مبرمج أيضًا ، بل فنانًا محترفًا أيضًا. أعتقد أن معظم المبرمجين سيستفيدون حقًا من خلال القفز إلى الفن لفترة من الوقت. إنه يجعل برمجة أشياء معينة أكثر منطقية ويساعد أيضًا على سد التنافس بين المبرمج / الفنان ، هاها :) أعلم أن هذا أكثر مثالية ، وليس عمليًا كثيرًا لمعظم الناس.

فيما يلي بعض الروابط لبعض أعمالي (ابحث عن Nathan Warden في الاعتمادات)

World Builder (شارك في حوالي نصف اللقطات)
https://www.youtube.com/watch؟v=VzFpg271sm8

تيدي سكيرز (شارك في معظم اللقطات)
https://www.youtube.com/watch؟v=qCXIzS_iY0k

مركز هولمارك كراون (اللقطة الثالثة مع سانتا)
https://www.youtube.com/watch؟v=biqBq3_Whqk

هذا عرض لمبنى Louie الخاص بي. إذا شاهدت World Builder ، فسترى بعض الأعمال الفنية التي قمت بنزعها منها ووضعها في الفيلم.

وإليك عرض غير مكتمل لدبابة هونج كونج بأسلوب Terminator 1 الذي سحق كريستين لستيفن كينج. تم تصميم كلا النموذجين بواسطتي ، لكنني لا أعتقد أن أي شيء آخر في اللقطة كان كذلك.

وغيرها الكثير التي يمكنني تسميتها ، لكنني أعتقد أن النقطة قد تم توضيحها. :)

حسنًا ، هذه صور ثابتة مذهلة - ولكنك تقوم بذلك مرة أخرى لمنح نفسك المزيد من السلطة. هذا لا يساعد في الدعم المنطقي لفكرة أن العقد أفضل من ورقة الأحداث :)

إذا ذهبت مع العقد ، فستكون مثل أي محرك لعبة ثلاثي الأبعاد آخر يستخدم البرمجة المرئية.

أعتقد أن هذه ليست فكرة رائعة لعدد من الأسباب.

- جعلت Unreal محركها مجانيًا مؤخرًا - وهي أيضًا متعددة المنصات. إنه محرك أكثر نضجًا من BGE / Godot. لذا فأنت تنافسهم مباشرة عند نسخ أسلوبهم في البرمجة المرئية.

-العقد هي طريقة أقل كفاءة للشاشة من ورقة المنطق. من الصعب قراءتها / متابعتها.

أعلن -Scirra أن build3 سيكون متعدد المنصات - سيعمل المحرر على windows و linux و mac.
ومع ذلك فهي ليست مفتوحة المصدر.
https://www.construct3.com/

أدى هذا إلى ظهور موجة من التعليقات في مجتمع scirra. يريد الكثير من المستخدمين عددًا من الأشياء التي يمكن أن يقدمها برنامج godot بدون البرمجة المرئية:
- ملفات exe الأصلية بدلاً من حاويات html5 - للحصول على أداء أفضل
- دعم تطوير الألعاب ثلاثية الأبعاد ، باستخدام نمط ورقة الأحداث في الإنشاء لبرمجتها:
https://www.scirra.com/forum/construct-3_t90881

إذا قاموا بإنشاء محرر ثلاثي الأبعاد بسيط ومفهوم مثل الأداة ثنائية الأبعاد داخل C2 ، فسأستخدمه تمامًا

لقد جربت الوحدة ، الخلاط ، عزم الدوران ثلاثي الأبعاد ، UDK ، لأنها الأكثر إعلانًا والأكثر استخدامًا لما يسمى بالمطورين المشهورين ... وهم يتشاركون في نفس المشكلات: فهي ليست سهلة الاستخدام (على الإطلاق) وإذا كنت لم تستخدم مطلقًا واجهة برمجة تطبيقات لإنشاء لعبة ثلاثية الأبعاد من قبل ... حسنًا ، أنت ثلاثي الأبعاد (مزحة سيئة ikno)

الشيء هو أن البناء سهل للغاية بمجرد تغطية الأساسيات وإعطائك الحرية في صنع ألعاب ثنائية الأبعاد معقدة ، فهو يمنحك مسارات مختلفة للقيام بنفس النتيجة (ناهيك عن أن نظام الأحداث يجعلني أحسس) ؛ وهي التفاصيل التي تفشل معظم هذه الأدوات الأخرى في تغطيتها أو جعلها سيئة

إذا قاموا بعمل محرك ثلاثي الأبعاد بنفس التدفق والشعور باستخدام C2 ؛ ثم لماذا لا تجربها؟

لديهم قاعدة مستخدم ضخمة في الوقت الحالي (تحب نمط ورقة الأحداث للبرمجة المرئية ، لكنها تريد هذه الميزات) وبعضها جاهز للانتقال إلى محرك آخر. هناك إمكانات كبيرة هنا بالنسبة إلى Godot للحصول على الكثير من المطورين المستقلين الجدد - أولئك الذين يفضلون هذا على العقد - تلك التي لا تستخدم محرك Unreal - والتي أصبحت الآن مجانية وأكثر نضجًا من godot.

إذا اخترت ذلك بدلاً من العقد ، فستكون المحرك الأول الذي يدعم تطوير الألعاب ثلاثية الأبعاد بالكامل مع تصميم البرمجة هذا. سوف تنقر على قاعدة مستخدم جديدة ، بدلاً من التنافس مع Unreal (مجاني) ، Unity (يتوفر إصدار مجاني)

حسنًا ، هذه صور ثابتة مذهلة - ولكنك تقوم بذلك مرة أخرى لمنح نفسك المزيد من السلطة.

الصور الثابتة والروابط ليست دليلاً على سلطتي ولكن على الأشخاص الذين عملت معهم وأنني لا أقوم باختلاقها فقط :) وهذا يشمل بعض أصدقائي الجيدين الذين عملوا في بعض الأفلام التي ربما سمعت عنها Avatar و King Kong و Serenity وعروض مثل Lost و Revolution وغيرها ... وبعض أصدقائي الآخرين الذين عملوا في صناعة الألعاب لأكثر من 15 عامًا. وكلها تفضل سير عمل قائم على العقدة على سير عمل خطي قائم على الورقة. ربما يمكنني الحصول على اقتباس من 3-4 منهم يخبرك أنهم يفضلون الرسوم البيانية للعقدة على أوراق المنطق إذا كنت ترغب في ذلك؟

جعلت Unreal محركها مجانيًا مؤخرًا - إنها أيضًا متعددة المنصات. إنه محرك أكثر نضجًا من BGE / Godot. لذا فأنت تنافسهم مباشرة عند نسخ أسلوبهم في البرمجة المرئية.

سير عمل البرمجة النصية المرئية هو آخر شيء سوف يبحث عنه الناس عند مقارنة Godot بتلك المحركات. أول شيء سيلاحظونه هو أن Unreal يدعم DirectX 12 و OpenGL 4 وأن العروض التوضيحية والأمثلة الخاصة بهم تبدو مذهلة ، ثم سيبدأون في النظر إلى الأشياء الأخرى. الشيء الرئيسي الذي يمتلكه Godot على تلك الشركات هو أنه برنامج FLOSS وأن أي شخص يستخدمه هو أيضًا مالك كامل للبرنامج.

العقد هي طريقة أقل كفاءة للشاشة من ورقة المنطق. من الصعب قراءتها / متابعتها.

في حين أنه من الواضح من خلال تصريحك أنك لم تستخدم إعدادًا جيدًا قائمًا على العقدة ، إذا كنت قلقًا بشأن أشياء مثل كفاءة الشاشة ، فلا يجب عليك استخدام البرمجة النصية المرئية على أي حال ، يجب أن تستخدم البرمجة النصية الحقيقية المتوفرة بالفعل :) أؤكد لك أن أي شيء يمكن أن تقدمه البرمجة النصية المرئية لك فيما يتعلق بمساحة الشاشة ، يمكن للبرمجة النصية العادية أن تفعل ذلك أيضًا ، مثل انهيار مناطق التعليمات البرمجية.

إذا اخترت ذلك بدلاً من العقد ، فستكون المحرك الأول الذي يدعم تطوير الألعاب ثلاثية الأبعاد بالكامل مع تصميم البرمجة هذا.

هناك سبب يجعل محركات مثل Unreal التي تنفق الكثير من الوقت والمال والبحث في احتياجات عملائها لا تتعامل مع هذا النوع من البرمجة النصية المرئية وتختار العقد بدلاً من ذلك.

رأيي في هذا هو أن كل هذا يتوقف على النهج الذي يعتزم أن يكون
تم حلها.

تعد كتل الحركة مثل Game Maker مثيرة للاهتمام ، لكنني أعتقد أنها أكثر من ذلك
مصممة لاستبدال البرمجة.

نهج Unreal يشبه إلى حد كبير مكمل للبرمجة
يمكن للمصممين العمل في اللعبة بأنفسهم وأخذ العمل بعيدًا عن
مبرمج. هذا مفيد أكثر في الفرق (الفنانين ومصممي الألعاب
يمكن استخدامه بشكل جيد) وهو بالتأكيد الأسلوب الذي أود أن أضيف إليه
جودو لأن هذا.

بسبب هندسة Godot ، سيكون من السهل جدًا إضافة ذلك ، لذا سأعطي
إنها لقطة في 1.2

في الثلاثاء ، 3 مارس 2015 الساعة 4:37 مساءً ، كتب Nathan [email protected] :

حسنًا ، هذه صور ثابتة مذهلة - ولكن مرة أخرى أنت تفعل هذا لتقديمها
المزيد من السلطة لنفسك.

اللقطات والروابط ليست دليلاً على سلطتي بل على الأشخاص الذين أملكهم
عملت مع وأنا لا أختلقها فقط :) وهذا يشمل بعض من بلدي
أصدقاء حميمون عملوا في بعض الأفلام التي ربما سمعت عنها
Avatar ، King Kong ، Serenity ، وعروض مثل Lost ، Revolution ، إلخ ... و
بعض أصدقائي الآخرين الذين عملوا في صناعة الألعاب لأكثر من 15 عامًا
سنين. وكلها تفضل سير عمل قائم على العقدة على ورقة خطية
سير العمل. ربما يمكنني الحصول على اقتباس من 3-4 منهم يخبروك بذلك
يفضلون الرسوم البيانية للعقدة على أوراق المنطق إذا كنت ترغب في ذلك؟

جعلت Unreal محركها مجانيًا مؤخرًا - إنها أيضًا متعددة المنصات. إنها
محرك أكثر نضجًا من BGE / Godot. إذن أنت تنافسهم
مباشرة عند نسخ نهجهم في البرمجة المرئية.

سير عمل البرمجة النصية المرئية هو آخر شيء سيكون عليه الأشخاص
النظر عند مقارنة Godot بتلك المحركات. أول شيء سوف يفعلونه
لاحظ أن Unreal يدعم DirectX 12 و OpenGL 4 وأن عروضهم التوضيحية
والأمثلة تبدو مذهلة ، ثم سيبدأون في النظر إلى الأشياء الأخرى.
الشيء الرئيسي الذي يمتلكه Godot على تلك الشركات هو أنها FLOSS
البرنامج وأن أي شخص يستخدمه يكون أيضًا مالكًا كاملاً لـ
البرمجيات.

العقد هي طريقة أقل كفاءة للشاشة من ورقة المنطق. هم أصعب
قراءة / متابعة.

بينما يتضح من تصريحك أنك لم تستخدم عقدة جيدة
على أساس الإعداد ، إذا كنت قلقًا بشأن أشياء مثل كفاءة الشاشة ، فأنت بذلك
لا ينبغي أن تستخدم البرمجة النصية المرئية على أي حال ، يجب أن تستخدم الحقيقي
البرمجة النصية المتوفرة بالفعل :) أنا أضمن لك أي شيء
يمكن أن تقدم لك البرمجة النصية المرئية من حيث البرمجة النصية العادية لمساحة الشاشة
يمكن أن تفعل ذلك أيضًا ، مثل انهيار مناطق التعليمات البرمجية.

إذا ذهبت إليه بدلاً من العقد ، فستكون المحرك الأول الذي
يدعم تطوير لعبة ثلاثية الأبعاد بالكامل مع تصميم البرمجة هذا.

هناك سبب يجعل محركات مثل Unreal تنفق الكثير من الوقت والمال
والبحث في احتياجات عملائهم لا يتماشى مع هذا الشكل من
البرمجة النصية المرئية واختيار العقد بدلاً من ذلك.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -77017857.

لقد أعطيت Playmaker تجربة جيدة ويجب أن أقول إنني أحببتها - أكثر من مخططات kismet / المخططات غير الواقعية.

في عقد صانع الألعاب تشبه نوعًا ما الحاويات التي تضع فيها الإجراءات. بعض الإجراءات هي التحقق من حالة يمكن أن تؤدي إلى عقدة أخرى.

نظرًا لأنك تصنع حاويات العقدة بنفسك ويمكنك تسميتها ، يتم تنفيذ الإجراءات فيها بطريقة يمكن التنبؤ بها (من أعلى إلى أسفل) - إنه شيء يمكنني العيش معه. :)

كما أن الإجراءات التي تضعها داخل العقدة هي في الواقع نصوص وحدة قياسية ذات مدخلات مرئية. لذلك سيتمكن الأشخاص من كتابة البرامج النصية الخاصة بهم وإضافتها كإجراءات مخصصة.

يرجى النظر في صانع الألعاب وتنفيذ نظام قائم على العقدة يكون أقرب إلى ذلك ، وليس غير واقعي.
إنها ميزة بالطبع أنه يمكننا القيام بالمزيد مع عدد أقل من العقد ، فهي أسهل في القراءة وتصحيح الأخطاء ، ويمكن التنبؤ بها بشكل أكبر.

فيما يلي مقدمة لكيفية عملها:
https://www.youtube.com/watch؟v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

إنه مرن للغاية ويسمح للمستخدم بإضافة ومشاركة وظائف اللعبة بسهولة - من السهل إعادة الغرض.

مناقشة رائعة. فقط أريد أن أشير إلى نوع / شكل آخر من البرمجة النصية المرئية بخلاف العقد وورقة أحداث C2 ولكن كتل نصية تتلاءم معًا مثل قطع الألغاز. تستخدم في محرك 2d Stencyl http://www.stencyl.com/

بناءً على MIT Scratch http://wiki.scratch.mit.edu/wiki/Wait_Until_ () _ (block)

وفي الوحدة التي أستخدمها شخصيًا ، Blox http://www.plyoung.com/blox/

أنا شخصياً لست مقتنعًا بالبرمجة "المرئية" الشبيهة بالخدش. أنا
أعتقد أنه يشبه إلى حد كبير البرمجة.
أعتقد أن الطريقة التي يقوم بها Unreal بهذا الأمر مناسبة لمصممي الألعاب / المستوى

في يوم السبت 21 مارس 2015 الساعة 11:57 مساءً ، كتب todheil [email protected] :

مناقشة رائعة. فقط أريد أن أشير إلى نوع / شكل آخر من الأشكال المرئية
البرمجة النصية بخلاف العقد ولكن كتل نصية تتلاءم معًا مثل
قطع اللغز. تستخدم في محرك 2d Stencyl http://www.stencyl.com/
[صورة: stencyl_blocks]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
على أساس MIT سكراتش
http://wiki.scratch.mit.edu/wiki/Wait_Until_ () _ (block)
[صورة: scratch_example]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
وفي الوحدة التي أستخدمها شخصيًا ، Blox http://www.plyoung.com/blox/
[صورة: hello_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84508001.

_OkamStudio_

نقطة جيدة. بالنسبة لي ، الكتل هي الوسيط بين خطوط الشفرة والمخططات الانسيابية.

أنا لا أحب طريقة الصفر / stencyl للبرمجة المرئية. تخطيطه هو
من الصعب بصريًا المتابعة من build2 كتل وحتى عقد. أنه
حرفيًا تجميع قطعة اللغز وهي تعاني من مشكلة
معرفة أي قطعة تناسبها وأين. ليس من السهل وضعها
سويا

في الأحد ، 22 مارس 2015 الساعة 5:46 صباحًا ، كتب todheil [email protected] :

نقطة جيدة. بالنسبة لي ، الكتل هي الوسيط بين خطوط الشفرة والتدفق
الرسوم البيانية.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

حسنًا ، لن أقرأ كل شيء الآن ، ولكن فقط سنتان عن هذا الموضوع.

يتم إنشاء المحركات القائمة على الأحداث لعمل نماذج أولية ومشاريع ألعاب صغيرة
يتم إنشاء محركات مثل godot للقيام بجميع أنواع المشاريع

إذن فهما شيئان مختلفان لهما طريقتان مختلفتان ، فهما شيئان
رسوم مختلفة

لأكون صادقًا ، لا يمكنني استخدامها جيدًا. (رسوم على أساس الحدث)

بالنسبة لي النهج الأفضل هو رسمان متوازيان.

2016-06-22 6:49 GMT-03: 00 تودور إيمريوروف [email protected] :

أنا لا أحب طريقة الصفر / stencyl للبرمجة المرئية. تخطيطه هو
من الصعب بصريًا المتابعة من build2 كتل وحتى عقد. أنه
حرفيًا تجميع قطعة اللغز وهي تعاني من مشكلة
معرفة أي قطعة تناسبها وأين. ليس من السهل وضعها
سويا

في الأحد ، 22 مارس 2015 الساعة 5:46 صباحًا ، كتب todheil [email protected] :

نقطة جيدة. بالنسبة لي ، الكتل هي الوسيط بين خطوط الشفرة والتدفق
الرسوم البيانية.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

ديفيد أغيار دي أكينو بايفا

الشيء الوحيد الذي قد يكون مفيدًا هو نظام "السلوك" للوحدة ،
إنه في الأساس نصوص يصنع شيئًا ما ، لذا فإن هذا في godot
الترجمة على أنها إمكانية إضافة أكثر من نص برمجي لكل عقدة.
بالطبع ، يمكنني إنشاء عقدة واستنساخها فقط ، لكن البرنامج النصي سيكون
مورد ثم سيتم تحميله فقط إلى عقدة وإضافة سلوك (لـ
مثال ، نص سريع)
في المحرر يمكننا أن نرى عمليات التصدير مصنفة تحت اسم البرنامج النصي.

2016-06-26 13:15 GMT-03: 00 ديفيد بايفا [email protected] :

حسنًا ، لن أقرأ كل شيء الآن ، ولكن فقط سنتان عن هذا الموضوع.

يتم إنشاء المحركات القائمة على الأحداث لعمل نماذج أولية ومشاريع ألعاب صغيرة
يتم إنشاء محركات مثل godot للقيام بجميع أنواع المشاريع

إذن فهما شيئان مختلفان لهما طريقتان مختلفتان ، فهما شيئان
رسوم مختلفة

لأكون صادقًا ، لا يمكنني استخدامها جيدًا.

بالنسبة لي النهج الأفضل هو رسمان متوازيان.

2016-06-22 6:49 GMT-03: 00 تودور إيمريوروف [email protected] :

أنا لا أحب طريقة الصفر / stencyl للبرمجة المرئية. تخطيطه هو

من الصعب بصريًا المتابعة من build2 كتل وحتى عقد. أنه
حرفيًا تجميع قطعة اللغز وهي تعاني من مشكلة
معرفة أي قطعة تناسبها وأين. ليس من السهل وضعها
سويا

يوم الأحد ، 22 آذار (مارس) 2015 الساعة 5:46 صباحًا ، todheil [email protected]
كتب:

نقطة جيدة. بالنسبة لي ، الكتل هي الوسيط بين خطوط الشفرة والتدفق
الرسوم البيانية.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415
.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

ديفيد أغيار دي أكينو بايفا

ديفيد أغيار دي أكينو بايفا

مرحبا شباب! مناقشة لطيفة هنا :) أود أن أضيف شيئا.

أول شيء: أنا طالبة فنون لكن البرمجة هي هوايتي. أعرف Java و Python و (المفضل لدي) Golang. ولكن قبل أن أتعلم كيفية البرمجة (منذ حوالي 3 سنوات) ، جربت تقريبًا كل برنامج يدعي أنه يسمح "بإنشاء ألعاب بدون برمجة". كل هذه الادعاءات هراء.

حاولت (بدون ترتيب معين): Click & Play و GameMaker و The Games Factory و Multimedia Fusion و Construct 1 و RPG Maker و Stencyl و BGE وبعض الآخرين الذين لا أتذكرهم. ورأيي: يمكنك عمل لعبة بدون كود _writing_ لكن لا بدون _برمجة_. حتى إذا كنت تستخدم أوراق الأحداث أو العقد ، فلا تزال بحاجة إلى فهم منطق البرمجة. عليك أن تعرف ما هو الشرطي ، الحدث ، المتغير ، السلسلة وما إلى ذلك ، لذلك من المستحيل إنشاء لعبة بدون برمجة. كل طرق الترميز المرئية هذه هي مجرد طريقة مختلفة للتعبير عن المنطق الموجود في لغات البرمجة التقليدية. قد تبدو هذه الحجة بأكملها واضحة ولكني أؤكد لك ، لم أكن واضحًا بالنسبة لي في بداية مغامرتي بالبرمجة.

من هذا يتبعني التالي:

أفضل لغة برمجة مرئية وأكثرها سهولة وجدتها قبل أن أتعلم كيفية البرمجة هي Scrach / Stencyl Puzzle / block way. هذا هو السبب:

• هذا الحل هو الأقرب إلى البرمجة التقليدية. في الواقع ، إنه مجرد شيء مثل بناء الجملة للكود الأساسي (في الأساس هو كيفية عمل Stencyl) بالنسبة لي ، من الأنظف والأسهل متابعة أو إنشاء شيء يشبه رمزًا رائعًا ملونًا من الرسوم البيانية للعقد أو أوراق الأحداث المزدحمة التي لا يمكنك وضعها إلى هياكل لطيفة مثل الوظائف. بالنسبة لي _ هذه فوضى
  تذكر أن هذا مجرد رأيي

* أعتقد أن كتل Scrach / Stencyl هي طريقة مرئية وسهلة المتابعة. يستخدمون الألوان على نطاق واسع (والأشخاص ذوي العقلية المرئية مثل الألوان) من السهل أن نتذكر أن اللون الأصفر = الشرطية والحلقات ، والأخضر = الرياضيات ، والأزرق = المتغيرات وما إلى ذلك ، كما يبدو أيضًا وكأنه رمز حقيقي (على عكس العقد) ولكنه أكثر ودية.

أخيرًا ، لا أعتقد أن البرمجة المرئية يجب أن تكون ذات أولوية في أي وقت قريبًا. هناك الكثير من الأشياء الأكثر أهمية التي يجب القيام بها (خريطة طريق كاملة + التوثيق) وأعتقد أن تنفيذ أي من هذه الأنظمة لن يكون سريعًا وسهلاً. Godot هو IMHO من السهل حقًا العمل كما هو الآن. يحتوي على الكثير من الأدوات التي يمكن للفنان استخدامها بالتعاون مع مطوري اللعبة (محرر تظليل بصري ، محرر رسوم متحركة ، عقدة tilemap).

بالمناسبة. أود أن أغتنم هذه الفرصة وأشكر جميع المبدعين والمساهمين في Godot. لقد قمت بعمل ممتاز: +1:

راجع للشغل 2. أنا آسف لغتي الإنجليزية. أنا أبذل قصارى جهدي ولكني ما زلت أرتكب أخطاء سخيفة: ابكي:

سواء أكان ذلك build2 أو blox - فإما أن يكون أجمل بالنسبة لي من الرسوم البيانية للعقدة.

إذا كان النظام يستخدم العقد فقط كحاويات للإجراءات (كحالات) - كما هو الحال في Playmaker ، فسأكون موافقًا عليه.

الشيء الجميل في كل من blox و build2 هو أن المحرر يعرض لك جميع الشروط والإجراءات المتاحة. يفصلهم عنك ويضعهم في فئات. هذا تغيير جذري في العرض التقديمي يسمح لغير المبرمج بالقيام بالكثير مع المحرك على الفور - دون الحاجة إلى معرفة أسماء الأوامر للقيام بالأشياء.

إذا كنت تستخدم عقدًا للبرمجة المرئية - فسيكون التحدي الأكبر هو إبلاغ المستخدم بترتيب تنفيذ الأحداث. في Unity - يقوم كل من صانع الألعاب و blox بعمل ذلك بطريقة نظيفة جدًا.

في صانع الألعاب عن طريق تكديس الإجراءات داخل حاويات العقدة (الحالة - تحتوي على إجراءات). في blox - حيث لديك حالات تحتوي على وظائف.

أنها تتيح الوصول الكامل إلى معظم ميزات الوحدة. هذا حقا لطيف لغير المبرمجين.
تم تطوير blox بشكل أكبر إلى "plygame" - ملحق وحدة آخر يحتوي على blox + بعض البرامج النصية المخصصة التي يمكن لـ blox الوصول إليها من أجل إنشاء لعبة rpg hack and slash style كاملة.

Blox في الوحدة هو نفس كتل Skrach / Stencyl. يبدو أن هناك الكثير من الأشخاص الذين يحبون هذا النمط من البرمجة :)
https://www.youtube.com/watch؟v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k

أتمنى أن يجربها مطورو godot.
راجع للشغل فإن تقنية Skratch (https://scratch.mit.edu/) مفتوحة المصدر! والبعض الآخر يتبناه - ليس فقط stencyl. كان Google مهتمًا جدًا به أيضًا:
https://developers.google.com/blockly/

اقتراح - لماذا لا تحاول الحصول على أفضل ما في العالمين! العقد الخاصة بآلة الحالة - blox / skratch / stencyl للتعبيرات.
في عالم مثالي ، سيكون لديك عقد يتم استخدامها كحاويات حالة - كما هو الحال في Playmaker. لكن حاوية الحالة ستحتوي على blox / stencyl / skratch مثل نظام lego الذي يسمح للمستخدم بإعداد المنطق بسهولة - لا حاجة لتعلم كتابة التعبيرات بهذه الطريقة - فهي جاهزة فقط للسحب والإسقاط.

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

قال أحد مطوري iCanScript هذا عن أصول VS الخاصة بهم:

يؤدي التقدم التقني لـ iCS2 إلى فصله عن كونه منتجًا للوحدة فقط مما يزيد بشكل كبير من فرص السوق. تتمثل الرؤية النهائية في أن iCS2 سيكون أداة مساعدة في التنمية يمكن استخدامها لإنشاء برنامج نصي لمحركات الألعاب الأخرى بالإضافة إلى تطبيقات Windows / OSX / iOS / Android القياسية.
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

ما هي فوضى العقدة iCanScript!

على أي حال ، الأمر يستحق المحاولة قبل أن أحكم عليه. ربما يمكن لشخص ما الدخول
تواصل مع مطورها؟
إذا كان لدى Godot سوق به فرص للربح - مثل السوق
الوحدة تفعل ذلك - ربما يجذب ذلك مطوري الوحدة لإنشاء أصول لها
جودو كذلك.

في يوم السبت 23 مايو 2015 الساعة 4:24 مساءً ، كتب todheil [email protected] :

قال أحد مطوري iCanScript هذا عن أصول VS الخاصة بهم:

التقدم التقني لـ 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/okamstudio/godot/issues/1220#issuecomment -104895405.

أعتقد أن ورقة حدث build 2 من السهل حقًا فهمها وبرمجتها.

بصفتي فنانًا يقضي معظم الوقت في إنشاء رسومات لحياتي ، فإن تعلم لغة جديدة أمر صعب للغاية ويستغرق وقتًا طويلاً. يقول الناس أنه يمكنك تعلمها في غضون بضعة أشهر ، ولكن عندما يكون لديك ساعتان فقط في اليوم لنفسك ، يمكنك إما اختيار التعلم من الصفر أو الإنشاء باستخدام لغة بسيطة. أيضًا ، كونك شخصًا مرئيًا ، فإن البرمجة النصية المرئية أكثر منطقية.

لقد انتهيت من البرمجة في المدرسة ويمكنني قراءة وفهم الكود بسهولة ولكن كتابته تستغرق وقتًا. أحاول أيضًا تعلم الثعبان وهو أسهل ولكن الأمر سيستغرق شهورًا لإنشاء شيء به.

يبدو نهج Construct 2 بسيطًا. بالنسبة لي يبدو مثل:

1 حدث: عمل؛

2 الحدث: العمل؛
: عمل؛

برمجتها بشكل أساسي ولكن بطريقة يسهل فهمها. إذا كانوا قد استخدموا اللغة فقط بدلاً من الكتلة ، ما كنت لأفكر. باستخدام هذا النمط ، من السهل إنشاء منطق بالنسبة لي.

يمكن أن يخرج استخدام العقد عن نطاق السيطرة بسرعة كبيرة حيث تبدأ الأشياء في الانتشار وتقضي المزيد من الوقت للبحث عن العقد ثم لتشفير فعليًا (كما فهمت من الوحدة وصانع الألعاب).

لذا ، إذا كنت تحاول تنفيذ نص برمجي مرئي ، فيرجى التفكير بجدية في إنشاء نظام حدث.

يمكنك أيضًا إنشاء نظام البرمجة النصية المرئي كإضافة قابلة للتنزيل لأشخاص مثلنا حتى لا يضطر أولئك الذين يفضلون البرمجة إلى تنزيل هذه الحمولة الإضافية.

عمل رائع مع Godot يتطلع إلى إنشاء ألعاب رائعة عليه.

مشكلتي مع نهج Construct هو أنه يبدو وكأنه برمجة ، ذلك
لا يبدو مختلفًا كثيرًا
من منظور الفريق ، أحب نهج مخطط Unreal أكثر لأن
إنه أكثر ملاءمة للمصممين الذين ليس لديهم فكرة عن البرمجة

في الأحد 24 مايو 2015 الساعة 3:58 صباحًا ، كتب whoisda [email protected] :

أعتقد أن ورقة حدث build 2 من السهل حقًا فهمها و
برنامج في.

بصفتي فنانًا يقضي معظم الوقت في إنشاء رسومات لمعيشي ،
تعلم لغة جديدة أمر صعب للغاية ويستغرق وقتًا طويلاً. يقول الناس أنك تستطيع
تعلمها في غضون بضعة أشهر ولكن عندما يكون لديك ساعتان فقط في اليوم
بنفسك ، يمكنك إما أن تختار التعلم من البداية أو الإنشاء باستخدام ملف
لغة بسيطة. أيضًا ، كونك شخصًا مرئيًا ، فإن البرمجة النصية المرئية تجعل المزيد
حاسة.

لقد انتهيت من البرمجة في المدرسة ويمكنني قراءة وفهم الكود بسهولة
لكن الكتابة تستغرق وقتًا. أحاول أيضًا أن أتعلم الثعبان وهو أسهل
لكن الأمر سيستغرق شهورًا لإنشاء شيء باستخدامه.

يبدو نهج Construct 2 بسيطًا. بالنسبة لي يبدو مثل:

1 حدث: عمل؛

2 الحدث: العمل؛
: عمل؛

برمجتها بشكل أساسي ولكن بطريقة يسهل فهمها. اذا هم
استخدمت اللغة فقط بدلاً من الكتلة التي لم أكن لأفكر فيها. باستخدام هذا
نمط من السهل إنشاء منطق بالنسبة لي.

يمكن أن يخرج استخدام العقد عن السيطرة بسرعة كبيرة حيث تبدأ الأشياء في الانتشار و
تقضي وقتًا أطول في البحث عن العقد ، ثم في الواقع لتشفير (مثلي
يفهم من الوحدة وصانع الألعاب).

لذا ، إذا كنت تحاول تنفيذ نص برمجي مرئي ، يرجى إعطاء قيمة
التفكير الجاد لبناء نظام الحدث.

يمكنك أيضًا إنشاء نظام البرمجة النصية المرئي كبرنامج قابل للتنزيل
لأشخاص مثلنا حتى لا يضطر أولئك الذين يفضلون البرمجة إلى ذلك
تحميل تلك الحمولة الزائدة.

عمل رائع مع Godot يتطلع إلى إنشاء ألعاب رائعة عليه.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159.

لكنك هي وجهة نظر المبرمج - شخص يعرف بالفعل كيف
إلى رمز.
من الأفضل أن ننظر إلى الإحصائيات في هذه الحالة - عدد
المستخدمين غير المبرمجين الذين يمتلكون build2 على البرمجة المرئية الأخرى
يجب أن يتحدث المحررون عن أنفسهم.

من الجدير أيضًا النظر في مجموعة متنوعة من الألعاب التي تم إنشاؤها بأسلوب واحد من البرمجة المرئية على آخر.

تمتلك Unreal عددًا هائلاً من المشاريع التي تم تنفيذها في kismet بالفعل - لكنها محرك أقدم بكثير من build2 والكثير منهم مجرد رماة من منظور الشخص الأول

يوم الأحد ، 24 مايو 2015 الساعة 10:15 صباحًا ، خوان Linietsky [email protected]
كتب:

مشكلتي مع نهج Construct هو أنه يبدو وكأنه برمجة ، ذلك
لا يبدو مختلفًا كثيرًا
من منظور الفريق ، أحب نهج مخطط Unreal أكثر لأن
إنه أكثر ملاءمة للمصممين الذين ليس لديهم فكرة عن البرمجة

في الأحد 24 مايو 2015 الساعة 3:58 صباحًا ، كتب whoisda [email protected] :

أعتقد أن ورقة حدث build 2 من السهل حقًا فهمها و
برنامج في.

بصفتي فنانًا يقضي معظم الوقت في إنشاء رسومات لمعيشي ،
تعلم لغة جديدة أمر صعب للغاية ويستغرق وقتًا طويلاً. يقول لك الناس
علبة
تعلمها في غضون بضعة أشهر ولكن عندما يكون لديك ساعتان فقط في اليوم
بنفسك ، يمكنك إما أن تختار التعلم من البداية أو الإنشاء باستخدام ملف
لغة بسيطة. أيضًا ، كونك شخصًا مرئيًا ، فإن البرمجة النصية المرئية تجعل المزيد
حاسة.

لقد انتهيت من البرمجة في المدرسة ويمكنني قراءة وفهم الكود بسهولة
لكن الكتابة تستغرق وقتًا. أحاول أيضًا تعلم لغة الثعبان وهي
أسهل
لكن الأمر سيستغرق شهورًا لإنشاء شيء باستخدامه.

يبدو نهج Construct 2 بسيطًا. بالنسبة لي يبدو مثل:

1 حدث: عمل؛

2 الحدث: العمل؛
: عمل؛

برمجتها بشكل أساسي ولكن بطريقة يسهل فهمها. إذا
أنهم
استخدمت اللغة فقط بدلاً من الكتلة التي لم أكن لأفكر فيها. استخدام
هذه
نمط من السهل إنشاء منطق بالنسبة لي.

يمكن أن يخرج استخدام العقد عن السيطرة بسرعة كبيرة حيث تبدأ الأشياء في الانتشار و
تقضي وقتًا أطول في البحث عن العقد ، ثم في الواقع لتشفير (مثلي
يفهم من الوحدة وصانع الألعاب).

لذا ، إذا كنت تحاول تنفيذ نص برمجي مرئي ، يرجى إعطاء قيمة
التفكير الجاد لبناء نظام الحدث.

يمكنك أيضًا إنشاء نظام البرمجة النصية المرئي كبرنامج قابل للتنزيل
لأشخاص مثلنا حتى أولئك الذين يفضلون البرمجة لا يملكون
ل
تحميل تلك الحمولة الزائدة.

عمل رائع مع Godot يتطلع إلى إنشاء ألعاب رائعة عليه.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

يشبه نهج Construct2 في البرمجة إلى حد كبير النهج الموجود في
Clickteam الانصهار ، والذي لديه أيضًا العديد من المستخدمين. السهولة في ذلك تأتي من أ
عدد الأشياء ، رغم أنها تشبه البرمجة:

• وجود جميع الشروط الممكنة المدرجة والمتاحة للمستخدم للاختيار
  للإضافة عن طريق النقر / السحب بلغة إنجليزية عادية - هذا لا يقدر بثمن
  لأنهم ليسوا مضطرين لتعلم الكلمات السحرية. يمكنهم فقط سحب و
  ألق بهم.
• إدراج جميع الإجراءات الممكنة وإتاحتها للمستخدم للاختيار من بينها
  إضافة عن طريق النقر / السحب بلغة إنجليزية بسيطة - وهذا لا يقدر بثمن
  لأنهم ليسوا مضطرين لتعلم الكلمات السحرية. يمكنهم فقط سحب و
  ألق بهم.
• الشيء نفسه ينطبق عند القيام بأي نوع من التعبيرات في كل من الإعداد و
  فعل أو شرط. عندما تكتب التعبيرات ، فإن المحرر يساعدك
  مع قائمة منسدلة سهلة بالأشياء التي يمكن الحصول عليها من الكائنات الموجودة في
  مشهد. لا يتعين عليك تعلم كيفية الوصول إلى تلك الخصائص كما هي
  متاحة بالفعل في غضون بضع نقرات.

ولعل أفضل ما في الأمر هو أنه يعلم غير المبرمجين عنها
نظرية البرمجة بدون منحنى التعلم لتعلم برمجة جديدة
لغة.

يوم الأحد 24 مايو 2015 الساعة 10:17 صباحًا ، Todor Imreorov [email protected]
كتب:

لكنك هي وجهة نظر المبرمج - شخص يعرف بالفعل
كيفية البرمجة.
من الأفضل أن ننظر إلى الإحصائيات في هذه الحالة - عدد
المستخدمين غير المبرمجين الذين يمتلكون build2 على البرمجة المرئية الأخرى
يجب أن يتحدث المحررون عن أنفسهم.

يوم الأحد ، 24 مايو 2015 الساعة 10:15 صباحًا ، خوان لينيتسكي < [email protected]

كتب:

مشكلتي مع نهج Construct هو أنه يبدو وكأنه برمجة ، ذلك
لا يبدو مختلفًا كثيرًا
من منظور الفريق ، أحب نهج مخطط Unreal أكثر لأن
إنه أكثر ملاءمة للمصممين الذين ليس لديهم فكرة عن البرمجة

يوم الأحد 24 مايو 2015 الساعة 3:58 صباحًا ، whoisda [email protected]
كتب:

أعتقد أن ورقة حدث build 2 من السهل حقًا فهمها و
برنامج في.

بصفتي فنانًا يقضي معظم الوقت في إنشاء رسومات لمعيشي ،
تعلم لغة جديدة أمر صعب للغاية ويستغرق وقتًا طويلاً. يقول لك الناس
علبة
تعلمها في غضون بضعة أشهر ولكن عندما يكون لديك ساعتان فقط في اليوم
بنفسك ، يمكنك إما أن تختار التعلم من البداية أو الإنشاء باستخدام ملف
لغة بسيطة. أيضًا ، كونك شخصًا مرئيًا ، فإن البرمجة النصية المرئية تجعل المزيد
حاسة.

لقد انتهيت من البرمجة في المدرسة ويمكنني قراءة وفهم الكود
بسهولة
لكن الكتابة تستغرق وقتًا. أحاول أيضًا تعلم لغة الثعبان وهي
أسهل
لكن الأمر سيستغرق شهورًا لإنشاء شيء باستخدامه.

يبدو نهج Construct 2 بسيطًا. بالنسبة لي يبدو مثل:

1 حدث: عمل؛

2 الحدث: العمل؛
: عمل؛

برمجتها بشكل أساسي ولكن بطريقة يسهل فهمها. إذا
أنهم
استخدمت اللغة فقط بدلاً من الكتلة التي لم أكن لأفكر فيها. استخدام
هذه
نمط من السهل إنشاء منطق بالنسبة لي.

يمكن أن يخرج استخدام العقد عن السيطرة بسرعة كبيرة حيث تبدأ الأشياء في الانتشار
و
تقضي وقتًا أطول في البحث عن العقد ، ثم في الواقع لتشفير (مثلي
يفهم من الوحدة وصانع الألعاب).

لذا ، إذا كنت تحاول تنفيذ نص برمجي مرئي ، يرجى إعطاء قيمة
التفكير الجاد لبناء نظام الحدث.

يمكنك أيضًا إنشاء نظام البرمجة النصية المرئي كبرنامج قابل للتنزيل
لأشخاص مثلنا حتى أولئك الذين يفضلون البرمجة لا يملكون
ل
تحميل تلك الحمولة الزائدة.

عمل رائع مع Godot يتطلع إلى إنشاء ألعاب رائعة عليه.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

انظر أيضًا إلى الأمر من منظور المصمم الذي يرغب في تعلم ترميز المنطق المعقد والحصول في النهاية على الثقة الكافية لتعلم البرمجة. أرى من أين أتيت كما ترى سيستخدم النظام فريق من المصممين والمبرمجين. أنا شخصياً أرغب في استخدام Godot كمستخدم واحد وليس في فريق مع مبرمج مثل الكثير من مطوري الألعاب المستقلة. نظام الأحداث متسامح ويشعر بأنه أكثر تنظيماً باستخدام المجموعات عندما يكون لديك أكثر من 1000 حدث.

بخلاف ذلك ، ليس لدي مشكلة في نظام العقدة وإذا تمكن godot من إنشاء نظام أفضل من التيار ، فسوف أستخدم الهراء منه.

أيضًا ، إذا كان ذلك ممكنًا ، قم بإنشاء ميزة بحث للعثور على كتل / عقد التعليمات البرمجية بسهولة.

لاحظ أن أوراق الأحداث في build2 / clickteam تلغي الحاجة إلى التعلم
بناء الجملة - لذلك لا يتعين على المستخدم معرفة مكان وضع الأشياء - أي
واضح جدا. الشروط على اليسار والإجراءات على اليمين. ترتيب
تنفيذ الحدث واضح جدًا أيضًا.
قطع الليغو في نقطة الصفر / ستينسل / بلوكس الوحدة ليست واضحة ، لكنها لا تزال كذلك
بطريقة أفضل من كابوس العقد المقدم في "iCanScript". هل نظرت
في الفيديو التعليمي الخاص بهم. إنه تصميم برمجة مرئي معقد للغاية
مع منحنى تعليمي شديد الانحدار. أعتقد أنه حتى لو أعطيته لـ
المبرمج سيكون لديهم صعوبة في اكتشاف ذلك

في الأحد 24 مايو 2015 الساعة 10:33 صباحًا ، كتب whoisda [email protected] :

انظر إليها أيضًا من منظور المصمم الذي يرغب في التعلم
لترميز المنطق المعقد والحصول في النهاية على الثقة الكافية لتعلم البرمجة.
أرى من أين أتيت كما ترى سيتم استخدام النظام بواسطة ملف
فريق من المصممين والمبرمجين. أنا شخصياً أرغب في استخدام Godot كـ
مستخدم واحد وليس في فريق مع مبرمج مثل الكثير من الألعاب المستقلة
المطورين. نظام الأحداث متسامح ويشعر بأنه أكثر تنظيماً عند استخدامه
المجموعات عندما يكون لديك أكثر من 1000 حدث.

بخلاف ذلك ، ليس لدي مشكلة في نظام العقدة وإذا تمكن godot من ذلك
إنشاء نظام أفضل من الحالي سأستخدم القرف منه
هو - هي.

أيضًا ، إذا كان ذلك ممكنًا ، قم بإنشاء ميزة بحث للعثور على كتل / عقد التعليمات البرمجية
بسهولة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

إنهم لم يعودوا يبيعون حتى "icanscript" في مخزن أصول الوحدة بعد الآن.
انظر إلى أرقام المبيعات هناك - أي من البرامج المرئية المتاحة
الأكثر استخدامًا - ولديها مشاريع كاملة.

سأترككم مع هذا الفيديو:
https://www.youtube.com/watch؟v=3Zq1yo0lxOU
يحتوي على 167 لعبة مصنوعة من دمج فريق النقر - بواسطة أشخاص ليس لديهم
تجربة البرمجة.

انظر أيضًا إلى ألعاب kickstarter الناجحة المصنوعة في الاندماج.
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

أحتاج أن أذكر أيضًا Five Nights at Freddy's (صنع في اندماج فريق clickteam):
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]
كتب:

لاحظ أن أوراق الأحداث في build2 / clickteam تلغي الحاجة إلى التعلم
بناء الجملة - لذلك لا يتعين على المستخدم معرفة مكان وضع الأشياء - أي
واضح جدا. الشروط على اليسار والإجراءات على اليمين. ترتيب
تنفيذ الحدث واضح جدًا أيضًا.
قطع الليغو في نقطة الصفر / ستينسل / بلوكس الوحدة ليست واضحة ، لكنها كذلك
لا يزال أفضل بكثير من كابوس العقد المقدم في "iCanScript". فعلت
يمكنك إلقاء نظرة على الفيديو التعليمي الخاص بهم. إنها بصرية معقدة للغاية
تصميم البرمجة مع منحنى تعليمي شديد الانحدار. أعتقد أنه حتى لو
تعطيه للمبرمج سيواجهون صعوبة في اكتشافه

يوم الأحد 24 مايو 2015 الساعة 10:33 صباحًا ، whoisda [email protected]
كتب:

انظر أيضًا إليها من منظور المصمم الذي يرغب في ذلك
تعلم كيفية ترميز المنطق المعقد والحصول في النهاية على الثقة الكافية لتعلم ذلك
الشفرة. أرى من أين أتيت كما ترى سيتم استخدام النظام من قبل
فريق من المصممين والمبرمجين. أنا شخصياً أرغب في استخدام Godot
كمستخدم واحد وليس في فريق مع مبرمج مثل الكثير من المستقلين
مطوري الألعاب. نظام الحدث متسامح ويشعر بأنه أكثر تنظيماً
باستخدام المجموعات عندما يكون لديك أكثر من 1000 حدث.

بخلاف ذلك ، ليس لدي مشكلة في نظام العقدة وإذا تمكن godot من ذلك
إنشاء نظام أفضل من الحالي سأستخدم القرف منه
هو - هي.

أيضًا ، إذا كان ذلك ممكنًا ، قم بإنشاء ميزة بحث للعثور على كتل / عقد التعليمات البرمجية
بسهولة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

لا أعتقد أنه من الحكمة دفعك لاستخدام نظام يعمل بشكل ممتاز لمحرك لعبة آخر إذا لم يكن هذا هو الاتجاه الذي تريد أن تسلكه.

في نفس الملاحظة ، أود أن أرى طريقة أكثر بديهية لتنفيذ البرمجة النصية المرئية. عدم استخدام العقد الفوضوية أو الوقت الذي يستغرقه الكتل (منشئ تطبيق Android) أو نظام الأحداث الذي يبحث عن البرمجة أيضًا (والذي أفضله على أي شيء آخر). شيء يأخذ أفضل ما لديهم.

ربما استشر مصمم قابلية الاستخدام لمسح بعض المسارات وإلقاء نظرة على بعض الأرقام.

في النهاية ، سيكون من الرائع رؤية طريقة فريدة من نوعها لـ Godot تجعل من Godot محركًا رائعًا يمكّن كل من شخص مبتدئ من تصميم لعبته الأولى في أسبوع وفريق تطوير يتعاون معًا لإنشاء لعبة AAA.

يسعدني أن أرى نظامًا من شأنه أن يساعدني في إنشاء ألعاب رائعة دون تغيير المحركات وتعلم اللغات باستمرار "كثيرًا.

هتافات.

أنا لا أمانع العقد إذا تم تنفيذها مثل تلك الموجودة في صانع الألعاب - مثل
حاويات العمل (الدول).
لا تُستخدم العقد هناك فعليًا لتعيين الإجراءات أو الشروط.

إذا جعلتها مثل "iCanScript" ، فلديك فوضى كاملة.

1. من الصعب معرفة ترتيب تنفيذ الأحداث
2. من الصعب معرفة العقدة التي يمكن توصيلها بأي عقدة
3. يتطلب الأمر العديد من العقد والخطوات لإعداد إجراء واحد أكثر مما يتطلبه الأمر
   قم بسحبه وإفلاته وقم بإعداد تعبير فيه (build2 / clickteam style
4. حيث تحصل على المساعدة في بناء الجملة - فهذه طريقة رائعة لتقديمها
   شخص ما للبرمجة دون مطالبتهم بقراءة الكثير من
   الوثائق - كل شيء متاح لهم في القائمة المنسدلة لـ
   يعارض).

في الأحد 24 مايو 2015 الساعة 11:20 صباحًا ، كتب whoisda [email protected] :

لا أعتقد أنه من الحكمة دفعك لاستخدام نظام يعمل
ممتاز لمحرك لعبة آخر إذا لم يكن هذا هو الاتجاه الذي تريده
تريد أن تأخذ.

في نفس الملاحظة ، أود أن أرى طريقة أكثر بديهية من المرئية
يتم تنفيذ البرمجة النصية. عدم استخدام العقد الفوضوية أو أخذ الوقت
كتل (منشئ تطبيق Android) أو نظام حدث يبحث عن البرمجة أيضًا (وهو ما أقوم به I
تفضل على كل شيء آخر). شيء يأخذ أفضل ما لديهم.

ربما استشر مصمم قابلية الاستخدام لمسح بعض المسارات وإلقاء نظرة على بعضها
أعداد.

في النهاية ، سيكون من الرائع رؤية طريقة فريدة من نوعها يقوم بها Godot
Godot محرك رائع يمكّن شخصًا واحدًا مبتدئًا من تصميم محركه
أول لعبة في أسبوع وفريق تطوير يتعاون معًا من أجل
إنشاء لعبة AAA.

يسعدني أن أرى نظامًا يساعدني في إنشاء ألعاب رائعة
دون تغيير المحركات وتعلم اللغات باستمرار "كثيرًا.

هتافات.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104990083.

أنا أصوت لـ whoisda فيما يتعلق بشيء يتم ابتكاره من أجل / في Godot. ومع ذلك ، يبدو أن هناك ثلاث مدارس برمجة مرئية: 1) العقد ، 2) أوراق الأحداث ، 3) الكتل. من بين هذه العقد الثلاثة يبدو أنها تقود المجال في بيئات ثلاثية الأبعاد. بالحديث عن ذلك ، قرأت في مكان ما فكرة تقترح خروج البرمجة النصية / البرمجة من تنسيق خطي (نص ، كتل ، ورقة أحداث) ، أو أفقي (عقد) وبرنامج ثلاثي الأبعاد باستخدام الهياكل. لست متأكدًا من كيفية عمل ذلك ولكن يبدو رائعًا.

تم اختبار مدارس البرمجة النصية المرئية المذكورة في الممارسة العملية و
بالفعل مستخدمين. أقترح الجمع بين تصميمات Playmaker و
بلوكس في الوحدة.

عقد لإنشاء آلة الدولة.
كتل أو أوراق أحداث لإنشاء الإجراءات داخل كل عقدة (حالة).

في الأحد ، 24 مايو 2015 الساعة 1:56 مساءً ، كتب todheil [email protected] :

أصوت لـ whoisda https://github.com/whoisda فيما يتعلق بشيء ما
يجري ابتكارها لـ / في Godot. ومع ذلك ، يبدو أن هناك ثلاثة بصري
مدارس البرمجة: 1) العقد ، 2) أوراق الأحداث ، 3) الكتل. من هؤلاء الثلاثة
يبدو أن العقد تقود المجال في بيئات ثلاثية الأبعاد. بالحديث عن هذا الموضوع
لقد قرأت في مكان ما فكرة تقترح خروج البرمجة النصية / البرمجة من ملف
الخطي (النص ، الكتل ، ورقة الأحداث) ، أو الأفقي (العقد) و
برنامج في 3D باستخدام الهياكل. لست متأكدا كيف سيعمل ذلك ولكن يبدو
مبهر.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105001411.

سيكون رائعًا إذا تمكنا من استخدام العقد والأحداث معًا. يمكن للعقد الحالات التي إذا اتبعت منطقًا بسيطًا يمكن توصيلها بالعقد الأخرى أو يمكن أن تكون حاويات للبرامج النصية / الكتل / أوراق الأحداث بهذه الطريقة لن يكون لدينا عقد كبيرة جدًا ويمكننا أيضًا التعاون كفريق. ولكن قد يكون هذا كثيرًا بالنسبة للمطور. لا تزال الفكرة تبدو رائعة للغاية.

إنه نوع من هذه الطريقة في Playmaker - يبدو أن الناس يحبونه كثيرًا.
يبدو أن الكثير من الناس هنا يحبون الستينسل أيضًا - التكنولوجيا كذلك
مفتوح المصدر ومتاح على موقع جيثب الصفر. شاركتها في
المنشور السابق.

أنا شخصياً أحب أن أرى أي خطوات أولى في البرمجة المرئية
اتجاه. حتى لو قام المطور بصنع آلة حالة تعمل مع gd
البرامج النصية - ستكون بداية رائعة حتى للمبرمجين المتقدمين
سوف نقدر.

ثم ربما بعد ذلك يمكننا الحصول على شيء مرئي مثل stencyl أو
build2 - هذا يشبه الكود - ولكنه أسهل بكثير من الكود - داخل
تنص على.

إذن في الواقع هذان طلبان خاصان!

• واحد لجهاز الدولة (العقد)
• آخر لإطار البرمجة النصية المرئية التي تحل محل التعلم gdscript
  مع السحب والإفلات الترميز. ولكنها أيضًا خطوة لطيفة نحو التعلم
  gdscript.

في النهاية ، يعرف المطور الرئيسي ما هو الأفضل لتصميم godot.

في الثلاثاء ، 26 مايو 2015 الساعة 11:43 صباحًا ، كتب whoisda [email protected] :

سيكون رائعًا إذا تمكنا من استخدام العقد والأحداث معًا. يمكن للعقد
تنص على أنه إذا كان اتباع منطق بسيط يمكن توصيله بالعقد الأخرى أو
يمكن أن تكون حاويات للبرامج النصية / الكتل / أوراق الأحداث بهذه الطريقة لن يكون لدينا
العقد الكبيرة جدًا ويمكن أيضًا التعاون كفريق. لكن هذا قد يكون كذلك
الكثير للمطور. لا تزال الفكرة تبدو رائعة للغاية.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984.

سوف أتحقق من Styencyl قريبًا لأنني لست على دراية به.
في هذه المرحلة من كل ما رأيته / قرأته ، يمكنني جمع ما يلي:

1) مخطط: رائع لمصممي الألعاب / المستوى ، ولكنه ليس جيدًا لـ
البرمجة المرئية
2) Stencyl: أفضل بكثير للبرمجة المرئية ، لكنه غير قابل للاستخدام بالنسبة لـ
مصممي اللعبة / المستوى

كانت تجربتي في صنع اللعبة دائمًا بين الفرق ، لذا يمكنني رؤية 1) على أنها موجودة
مفيد جدًا ، لكن هذا أيضًا يجعلني متحيزًا. هل هناك الكثير من الناس
مهتم بالبرمجة المرئية مثل Stencyl؟

يوم الثلاثاء ، 26 مايو 2015 ، الساعة 6:10 صباحًا ، Todor Imreorov [email protected]
كتب:

إنه نوع من هذه الطريقة في Playmaker - يبدو أن الناس يحبونه كثيرًا.
يبدو أن الكثير من الناس هنا يحبون الستينسل أيضًا - التكنولوجيا كذلك
مفتوح المصدر ومتاح على موقع جيثب الصفر. شاركتها في
المنشور السابق.

أنا شخصياً أحب أن أرى أي خطوات أولى في البرمجة المرئية
اتجاه. حتى لو قام المطور بصنع آلة حالة تعمل مع gd
البرامج النصية - ستكون بداية رائعة حتى للمبرمجين المتقدمين
سوف نقدر.

ثم ربما بعد ذلك يمكننا الحصول على شيء مرئي مثل stencyl أو
build2 - هذا يشبه الكود - ولكنه أسهل بكثير من الكود - داخل
تنص على.

إذن في الواقع هذان طلبان خاصان!

• واحد لجهاز الدولة (العقد)
• آخر لإطار البرمجة النصية المرئية التي تحل محل التعلم gdscript
  مع السحب والإفلات الترميز. ولكنها أيضًا خطوة لطيفة نحو التعلم
  gdscript.

في النهاية ، يعرف المطور الرئيسي ما هو الأفضل لتصميم godot.

يوم الثلاثاء ، 26 مايو 2015 الساعة 11:43 صباحًا ، whoisda [email protected]
كتب:

سيكون رائعًا إذا تمكنا من استخدام العقد والأحداث معًا. يمكن للعقد
تنص على أنه إذا كان اتباع منطق بسيط يمكن توصيله بالعقد الأخرى
أو
يمكن أن تكون حاويات للبرامج النصية / الكتل / أوراق الأحداث بهذه الطريقة لن نفعل ذلك
يملك
العقد الكبيرة جدًا ويمكن أيضًا التعاون كفريق. لكن هذا قد يكون
جدا
الكثير للمطور. لا تزال الفكرة تبدو رائعة للغاية.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984
.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105458142.

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

هل هذا مثال أساسي لما يبدو عليه "كود" الستينسل؟ إذا كانت الإجابة بنعم ، فإنها تبدو وكأنها فكرة مروعة: فهي تبدو وكأنها ترميز قياسي في أغلفة مرئية لرياض الأطفال. هيا ، الثعبان سهل بالفعل بما يكفي لزوجتي لقراءته ، فلماذا لا أبذل جهدًا لتعلم الأساسيات؟

إذا كنت تتحدث عن البرمجة المرئية ، فإن ما يوفره Godot بالفعل أفضل بكثير - الرسوم البيانية المظللة أو الرسوم البيانية للرسوم المتحركة: رمز ملفوف في العقد المرئية.
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg - مثال آخر على البرمجة القائمة على العقدة المرئية (Sidefx Houdini أو XSI). إنها ناضجة ولا تشبه لعبة الأطفال ، كما تذكرني بعقد غودو.

أعجبتني طريقة الإنشاء 2 ، ولكن بعد النظر إلى المزيد في نقطة الصفر - يبدو أنه خيار أفضل لعدد من الأسباب:

• يبدو أن تصميم البرمجة أكثر شيوعًا من تصميم build2
• لقد تم إنشاؤه بالفعل كأداة للمساعدة في تعليم الناس لغة برمجة
• إنه مفتوح المصدر وآخرون أعادوا تصميمه لمحركهم في الماضي

اعتمد مطورو Stencyl تقنية "الصفر" مفتوحة المصدر. إنه ليس تصميمهم.
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_ (architecture_language)
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

أمثلة على استخدام سكراتش بواسطة محركات ألعاب أخرى تستهدف غير المبرمجين:

• Stencyl (الأكثر شعبية) http://www.stencyl.com/
  
• Craftstudio (http://craftstud.io/)
  
• جوجل بلوكلي (https://developers.google.com/blockly/)
• الأقرب إلى Godot هو أصل البرمجة المرئية "Blox" في Unity:
  
  https://www.youtube.com/watch؟v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k
  بدلاً من Lua ، فإنه يولد C #.
  التوثيق الكامل موجود هنا:
  http://www.plyoung.com/blox/
  ويباع هنا: https://www.assetstore.unity3d.com/en/#!/content/12859

قد تبدو فكرة مروعة للمبرمجين ذوي الخبرة ، لكنها أفضل طريقة لتعليم غير المبرمجين كيفية كتابة التعليمات البرمجية أو ببساطة لتمكينهم من البرمجة دون معرفة الكلمات السحرية أو بناء الجملة. يجعلهم Scratch جميعًا متاحين للسحب والإفلات - مما يفرض بنية صحيحة باستخدام أدلة بصرية. يرجى مشاهدة قائمة تشغيل مقاطع الفيديو "Unity Blox" التي قمت بنشرها لمشاهدتها أثناء العمل. أكثر من أي شيء آخر ، فقد ثبت في الممارسة مرارًا وتكرارًا. يبدو أنه الرهان الأكثر أمانًا.

أتفق مع reduz في نقاطه القائلة بأن أحدهما جيد في تصميم المستوى والآخر في البرمجة النصية المرئية ولم أعد أجادل في استخدام أحدهما على الآخر.

يبدو أن استخدام كلاهما هو أفضل نهج. إذا لم يكن Unity blox ، حتى إذا نظرت إلى Playmaker ، فسترى أن العقد عبارة عن حاويات بالفعل هناك - حيث يمكن تكديس الإجراءات - بشكل مشابه جدًا لـ stencyl. تقوم بسحبها وإفلاتها من القائمة!

"لكنها أفضل طريقة لتعليم غير المبرمجين كيفية كتابة التعليمات البرمجية أو ببساطة لتمكينهم من البرمجة دون معرفة الكلمات السحرية"

ثم لا أفهم ما هو الجمهور المستهدف. هل يهدف Godot إلى التنافس مع الكبار في السوق (Unreal Engine ، Unity ، إلخ) أو تعليم البرمجة للأطفال / صنع ألعاب مثل Scratch (https://scratch.mit.edu/)؟

أعرف ما هي العقد (الإدخال -> الوظيفة مع المعلمات -> الإخراج) ، لا أتفق مع العرض التقديمي.

قد يكون Stencyl و Playmaker رائعين في تعليم الأطفال كيفية البرمجة ، ولكن تم استخدامهم بنجاح من قبل غير المبرمجين (سواء الاستوديوهات أو indie) لصنع ألعاب ناجحة - تباع على منصات مختلفة.
إذا صنفت الوحدة على أنها الكبار ، فعليك أن تعلم أن الأولاد الكبار يقومون أيضًا بالبرمجة المرئية.
http://www.hutonggames.com/showcase.html

أعتقد أن جودو لديه الكثير من الميزات لاستخدامها من قبل الكبار. يمكن أن تساعد بعض الميزات التي تمكّن أصغر / إنديانا في الاعتماد الأسرع للمحرك. والطبيعة مفتوحة المصدر والتراخيص المرنة مربحة للغاية بالنسبة للمبتدئين.

تضمين التغريدة
أنا لا أجادل ضد البرمجة المرئية. أود أن أقول إن لدى Godot بالفعل ما يحتاجه (ShaderGraphs): يمكن توسيع النهج المرئي نفسه ليشمل البرمجة المنطقية لآلة الدولة ، أو البرمجة العامة. ما أجادله ضده هو ضد تبني نموذج بصري آخر (~ نقطة الصفر) لا يخيف الأطفال.

كما لوحظ من قبل ، فهو ليس للأطفال فقط. ولكن إذا كان بإمكان الأطفال فهمها واستخدامها - فأعتقد أن هذا أمر جيد. لا شيء تخجل منه.

أكبر نقطة أريد أن أوضحها هنا هي:

• يجب أن يكون ترتيب تنفيذ الإجراءات واضحًا! يمكن أن يؤدي القيام بكل منطق بالعقد إلى حدوث فوضى بسرعة كبيرة. لذلك يجب استخدام العقد مع الدول imo.
• توقع مطورو Playmaker هذه المشكلة بذكاء شديد وهذا هو السبب في أنهم جعلوا العقد عبارة عن حاويات إجراءات والتي - بشكل مشابه جدًا لـ Stencyl - تقوم بسحب وإفلات الإجراءات المتاحة من القائمة:
  
  وتكديس الأحداث بهذه الطريقة

ما ينتهي بك الأمر هو إنشاء عقدة نظيفة وفعالة للغاية!

أقترح أن يقوم مطورو Godot بتجربة صانع الألعاب أيضًا.
إن استبدال مكدس الأحداث بمنطق Stencyl سيجعل منهج godot أكثر مرونة / قوة !.

لا يجب أن يكون فقط من خلال نهج stencyl. أعتقد أنه يمكنك تمكين المبرمجين المتمرسين من إرفاق نصوص gd بالعقد. إن امتلاك خيار استخدام نهج stencyl لإنشاء نصوص gdscript سيكون أمرًا لا يقدر بثمن imo. سيدعو العديد من المستخدمين الجدد إلى مجتمع godot.

تضمين التغريدة
حسنًا ، لكن هذا شيء مختلف. سهولة الاستخدام لا تعني أنها يجب أن تبدو وكأنها مخصصة للأطفال.
يعد ترتيب التنفيذ والتصفية المساعدة للمدخلات / المخرجات المناسبة لعقدة معينة من المشكلات الشائعة لتدفقات العمل القائمة على العقدة. البرامج المختلفة تحلها بشكل مختلف.

عليك أن تسأل نفسك - هل تريد المزيد من غير المبرمجين لاستخدام Godot؟ هل تريد أن تجعل من الممكن للأشخاص الذين ليس لديهم خبرة في gdscript أن يسخروا من شيء ما؟

إذا كانت الإجابة بنعم - فإن أفضل طريقة للقيام بذلك هي من خلال منحهم نهج البرمجة النصية المرئية.
أنا لا أقترح جعل العقد تبدو وكأنها شيء مخصّص للأطفال.
ما أقترحه هو تقسيم هذا إلى مشروعين!

• تُستخدم العقد كآلة حالة تشبه في Playmaker! يمكن للمبرمجين تسمية كل عقدة وإرفاق gdscripts بها - مع المدخلات والمخرجات التي قاموا بإعدادها. لذلك هذا ليس للأطفال على الإطلاق. في الواقع ، هذا نهج أكثر مرونة للمبرمجين وهو أقل فوضى.
• سحب وإسقاط ورقة حدث أو واجهة كتل كطريقة بديلة لإنشاء GDscript. لذا بدلاً من كتابة GdScript لإرفاقها بعقدة ، يمكن لغير المبرمجين فقط تكديس الإجراءات من قائمة بجميع الأحداث المتاحة في godot - تمامًا مثل Playmaker. لاتخاذ خطوة أخرى إلى الأمام والابتكار - بدلاً من مجرد تكديس الإجراءات ، سيكون من الأفضل استخدام كتل مثل Stencyl.

بهذه الطريقة يكون لديك شيء مفيد لكل من المبرمجين وغير المبرمجين. يمكنهم استخدام آلة الحالة (العقد) ولا يحتاج غير المبرمجين إلى تعلم gdscript على الفور واستخدام gdBlocks بدلاً من ذلك لإنشاء gdscript لعقدة (مرة أخرى - كما هو الحال في Playmaker).

تضمين التغريدة
أحب أن أفضل. كما أنه يتوافق مع Shader node-graph مقابل Shader-text الموجود في Godot بالفعل.

يحتوي SideFX Houdini على شيء يسمى VEX (https://goo.gl/TMWNKk) ("تعبير متجه" لغة شبيهة بحرف c يُقصد بها الجبر المتجه). إنه مرادف إلى حد ما لـ gdScript. كما أنه يحتوي على شيء يسمى "VOPs" (http://goo.gl/Qpn2OE) (عوامل Vex) - أغلفة مرئية بشكل أساسي لمجموعة فرعية من VEX ، والتي تبدو مشابهة جدًا لصورة الرسم البياني لعقدة LeadWerks التي أشرت إليها أعلاه. في الواقع ، يمكن تحويل VOPs إلى نص نصي ، إذا لزم الأمر (ولكن ليس العكس).

التعايش بين 2 أمر طبيعي تمامًا ويسمح ، حتى غير المبرمجين ، بإنشاء كود فوضوي وغير فعال ؛)

أنا شخصياً أحب نهج Blueprint لأنه مصمم ألعاب للغاية
أعجبني ، لكني أصر على أنني قد أكون متحيزًا.

لقد قمت بتنزيل Stencyl قبل ساعتين وقمت بتشغيله معه. ربما اكون
مخطئ ، لكنني أعتقد أن Stencyl هي أداة جيدة للتعلم لأنه ليس فقط
جزء البرمجة مبسط ولكن جزء المحرك أيضًا. الجمع هو
جيد لأنه نهج برمجة بسيط لمحرك لعبة بسيط.

لكن Godot ليس محرك لعبة بسيط (على الأقل مقارنة بـ Stencyl) لذلك أنا
لا أعتقد أن البرمجة المبسطة ستكون مفيدة. يعتمد ستينسل على
الكثير من عناصر منطق اللعبة المشفرة والتي لن تكون متاحة ببساطة في
Godot ومحاولة إتاحته ستتعارض مع هدف Godot المتمثل في
كونها محرك لعبة ذو أغراض عامة.

يعتبر نهج العقد والرسم البياني أكثر إثارة للاهتمام في رأيي لأنه
مستوى أقل وطريقة أكثر مرونة للقيام بالأشياء.

يوم الثلاثاء 26 مايو 2015 الساعة 11:29 صباحًا ، فلاديمير لوباتين < [email protected]

كتب:

تضمين التغريدة
أحب أن أفضل. كما أنه يتوافق مع مخطط عقدة Shader مقابل
شادر النص الموجود في جودو بالفعل.

لدى SideFX Houdini شيء بارد VEX (https://goo.gl/TMWNKk) ("vector
التعبير "لغة شبيهة بحرف c يُقصد بها الجبر المتجه)
إلى حد ما مرادف لـ gdScript. كما أنه يحتوي على شيء يسمى "VOPs" (
http://goo.gl/Qpn2OE) (Vex Operators) - أغلفة مرئية بشكل أساسي
مجموعة فرعية من VEX ، والتي تشبه إلى حد بعيد الرسم البياني لعقدة LeadWerks
المشار إليها أعلاه. في الواقع ، يمكن تحويل VOPs إلى البرنامج النصي ، إذا لزم الأمر
(ولكن ليس العكس).

التعايش بين 2 أمر طبيعي تمامًا ويسمح بذلك
غير المبرمجين ، لإنشاء كود فوضوي للغاية وغير فعال ؛)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105543845.

ماذا عن تكديس الحركة في Playmaker و blox in Unity؟ الوحدة ليست محركًا بسيطًا للغاية.

أعتقد أن ستينسل ليس مثالًا جيدًا جدًا. من الأفضل البحث عن أمثلة في مخزن أصول الوحدة.

حاولت أن أفهم صانع الألعاب ولكني فشلت ، كيف يفترض أن يعمل؟

يوم الثلاثاء 26 مايو 2015 الساعة 12:16 ظهرًا ، Todor Imreorov [email protected]
كتب:

ماذا عن تكديس الحركة في Playmaker و blox in Unity؟ الوحدة ليست
محرك بسيط جدا.

أعتقد أن ستينسل ليس مثالًا جيدًا جدًا. من الأفضل أن تبحث عنه
أمثلة في مخزن الأصول الوحدة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760.

راجع البرنامج التعليمي الخاص بصانع الألعاب ، ولكن يبدو أنه مشابه لـ stencyl in
بمعنى أنه يأتي مع عدد من السلوكيات المحددة مسبقًا

يوم الثلاثاء ، 26 مايو 2015 الساعة 12:19 ظهرًا ، خوان Linietsky [email protected]
كتب:

حاولت أن أفهم صانع الألعاب ولكني فشلت ، كيف يفترض أن يعمل؟

يوم الثلاثاء 26 مايو 2015 الساعة 12:16 ظهرًا ، تودور إمريوروف < [email protected]

كتب:

ماذا عن تكديس الحركة في Playmaker و blox in Unity؟ الوحدة ليست
محرك بسيط جدا.

أعتقد أن ستينسل ليس مثالًا جيدًا جدًا. من الأفضل أن تبحث عنه
أمثلة في مخزن الأصول الوحدة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777.

_OkamStudio_

الأقرب في مخططات Unity إلى U4 هو uScript:
https://www.assetstore.unity3d.com/en/#!/content/1808

يبدو أن الناس يفضلون صانع الألعاب على الاستخدام - لأنه من الأسهل فهم المنطق الذي تم إعداده. كما ترون من لقطات الشاشة - يصبح الأمر فوضويًا للغاية حتى بالنسبة للمنطق البسيط.

reduzokamstudio هنا قائمة تشغيل على صانع الألعاب:
https://www.youtube.com/watch؟v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
أعتقد أنه يجب عليك استخدامه قليلاً. يمكنك القيام بسلوكيات ونصوص محددة مسبقًا ، لكن صانع الألعاب يسمح لك أيضًا بالوصول إلى الميزات الأساسية للمحرك والقيام بمثل هذه السلوكيات من الصفر بنفسك.

نعم ، صانع الألعاب هو آلة دولة والوحدة تأتي مع الكثير من السلوكيات المحددة مسبقًا.
يمتلكها Godot أيضًا - فهي مدمجة في المحرك.
ما زلت أعتقد أنه يمكنك بالفعل إنشاء نص / سلوك من الصفر باستخدام blox stencyl clone blox.

أعتقد أنك بحاجة أخيرًا إلى مبرمج ليصنع لعبة مناسبة وهذه الفكرة
من الرائع أن يصنع مصمم الألعاب اللعبة بنفسه ولكن أعتقد أنها كثيرة
من العمل الذي لا يأتي في متناول اليد في كثير من الحالات. ولكن إذا كان لدينا المزيد
ميزة للمحرر نفسه مثل مصمم المنصات الذي قام به شخص آخر
مذكور في عدد آخر أو أشياء مفيدة أخرى لتسهيل واجهة المستخدم
أكثر ودا.
في 26 مايو 2015 ، الساعة 7:52 مساءً ، كتب "Okam Studio" [email protected] :

راجع البرنامج التعليمي الخاص بصانع الألعاب ، ولكن يبدو أنه مشابه لـ stencyl in
بمعنى أنه يأتي مع عدد من السلوكيات المحددة مسبقًا

يوم الثلاثاء ، 26 مايو 2015 الساعة 12:19 ظهرًا ، خوان لينيتسكي < [email protected]

كتب:

حاولت أن أفهم صانع الألعاب ولكني فشلت ، كيف يفترض أن يعمل؟

يوم الثلاثاء ، 26 مايو 2015 الساعة 12:16 ظهرًا ، تودور إمريوروف <
[email protected]

كتب:

ماذا عن تكديس الحركة في Playmaker و blox in Unity؟ الوحدة هي
لا
محرك بسيط جدا.

أعتقد أن ستينسل ليس مثالًا جيدًا جدًا. من الأفضل أن تبحث عنه
أمثلة في مخزن الأصول الوحدة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777
.

_OkamStudio_

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105565084.

فيما يلي مراجعة في متجر أصول الوحدة لـ uScript:

أداة جيدة ، ولكن من الصعب معرفة ما إذا كان غير المبرمج ... الردود على طلبات المساعدة في المنتديات بطيئة جدًا أو غير موجودة على الإطلاق ..

أيا كان ما ينتهي به الأمر في Godot ، أعتقد - إذا كان ذلك ممكنًا - سيكون من الجيد السماح بالتحويل أحادي الاتجاه إلى GDScript. سيسمح هذا بإعداد الأشياء بشكل مرئي سريعًا ، من قبل المصممين والفنانين وغيرهم ، ثم السماح للمبرمجين في الفريق بتعديلها بشكل أكبر وإعادة صياغتها دون الحاجة إلى استخدام نقطة النقر.

adolson ستكون هذه ميزة مرغوبة كثيرًا :)

يمكن القيام بذلك ، ويمكن أيضًا إجراؤه باستخدام محرر التظليل المرئي
(وهو في الواقع يولد كود تظليل)
لكنني أعتقد أن كود التظليل الذي تم إنشاؤه لن يكون قابلاً للقراءة كما قد ترغب
توقع: ص

في الثلاثاء ، 26 مايو 2015 ، الساعة 6:33 مساءً ، كتب ناثان [email protected] :

adolson https://github.com/adolson سيكون هذا مطلوبًا كثيرًا
خاصية :)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105670945.

reduz يتوقع بعض البيانات الوصفية.
فيما يلي مثال على التحويل من VOPs -> تحويل VEX ، كما هو موضح أعلاه:
:
وإليك القائمة الكاملة للرمز ، والتي ، بخلاف ذلك ، في VEX الخالص تبدو كما يلي:
P + = متجه ({0،1،0}) ، // خذ الموضع وأضف المتجه (0،1،0)

كما ترى فإن كمية البيانات الوصفية كبيرة ، ولكن ليس من الصعب فصل 2 ، وربما يتم تحليلها بشكل شبه آلي أو آلي بالكامل.

reduz هذا صحيح. لم أكن أفكر في ذلك حقًا. ربما لن يكون نوع الكود الذي يرغب معظم المبرمجين في قضاء وقتهم فيه. يمكنني أن أرى التسميات تصبح أسماء متغيرة وما شابه ، لكن لا يمكنني رؤية الكثير للتخفيف من المشكلة.

بينما لا يمكنني التحدث نيابة عن الجميع ، إذا رأيت فوضى في التعليمات البرمجية ، فقد آخذ منها بضع أجزاء وأجزاء ، لكنني عادةً ما أشعر بالميل إلى إعادة كتابتها. لذا ، إذا كان هذا هو الحال ، فلن يكون الأمر يستحق ذلك بالنسبة لي شخصيًا.

لقد مررتم حقا يا رفاق بسلسلة من الخيارات. لقد استخدمت Construct 2 وبينما هو أنيق ، لا يمكنك أبدًا لمس أي رمز لتحسينه وكانت الخيارات محدودة نوعًا ما. لقد تخلص تحديث الخرائط المبلطة بشكل أساسي من المباني الجاهزة وبالتالي تم التثبيت أيضًا. الشيء الذي أحببته حقًا هو PlayMaker for Unity.

كان من السهل جدًا الاحتفاظ بشيء يتعلق بنطاقك وما تحتاج إلى القيام به. هذا عامل جذاب حقًا ، والسبب الكامل الذي يجعلني أحب استخدام البرامج النصية المرئية هو بسبب هذا بالضبط. لا أتمكن من رؤية ما كنت أفعله أو ما يجب أن أفعله في التعليمات البرمجية النصية ، لكن رؤية كيف أن كل شيء "يربط" يحقق أكبر فائدة بالنسبة لي. نشر NateWardog مثالاً في لقطة شاشة في وقت سابق بكثير و blurrymind مؤخرًا.

أقول reduz ، تذهب من أجله. في الوقت الحالي ، إذا كنت ستزعجك ، فسأقوم بالتقاط 1.3 أو ما بعد ذلك ، وحتى بعد ذلك سأركز في الغالب على الجانب الأمامي منه. ثم عندما يكون جاهزًا في وقت لاحق على الطريق ، ركز على جعله يخرج رمزًا قابلاً للقراءة مثل Blueprint can ، والذي أتخيل أنه سيكون صعبًا للغاية. من فضلك لا تقلل من شأن هذا!

الاشتراك. أنا مهتم جدًا بهذا أيضًا! أعرف بعض البرامج النصية ولا أمانع حقًا في استخدامها ... لكنني أفضل ربط العقد على ذلك عندما يكون ذلك ممكنًا! شيء مثل الطوب المنطقي في Blender Game Engine ، والذي يعمل كاختصارات بصرية لنص جودو يعمل كبديل لكتابتها باليد ... ستكون هذه ميزة رائعة وأنا أنتظرها بنشاط.

تجذب البرمجة النصية المرئية كثيرًا من المبدعين أو الأشخاص الذين لا يريدون تعلم لغة برمجة نصية جديدة مثل نص gd. كنت أنظر إلى صانع الألعاب الذي يتمتع بشعبية كبيرة ، والسبب الوحيد الأكثر تحديدًا هو ميكانيكي البرمجة النصية المرئية.

البرمجة النصية المرئية مملة وغبية ويصعب استخدامها.
أنا لا أرى تطبيقًا جيدًا أبدًا. يجب على الأشخاص المرئيين رسم الرسومات. أنا
أعرف أن الكثير من الناس لا يستطيعون الكتابة ،
لكن هذا لن يفيدهم. لا يعني الشخص غير البرمجة
شخص أمي.

لا أعرف أي أداة لبناء المنطق البصري ، والتي كانت النظام الأساسي لها
منطق اللعبة في أي محرك.
تمتص الطريقة المرئية في العديد من الجوانب. ينظر الناس المرئية عادة
البرمجة كـ "أشياء تقنية"
تعني شيئًا حقيقيًا من السباكة والعمل الجاد ، وتريد أن تكون أعلى
هو - هي. هذا الموقف
عادة بسبب بعض القضايا الفكرية. لا أعتقد أن هذا الشعب
يمكن أن يكون الجمهور المستهدف
في الأساس يحدون من إبداعهم.

يوم الخميس 14 أبريل 2016 الساعة 8:33 صباحًا ، Rémi Verschelde [email protected]
كتب:

تحرير: أرى أنك غيرت "RPG Maker" إلى "Game Maker" ، والآن أصبح يصنع المزيد
بمعنى: ص إزالة رسالتي.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209770726

لا أريد ذلك ، لكن يجب أن أقول ذلك ، لكن هذه نظرة ضيقة جدًا لأدوات البرمجة النصية المرئية ، سيرجي. بالنسبة للألعاب التي تم إنشاؤها باستخدامها بالكامل ، فقد اختارت بعض المحركات تمامًا مثل Construct ، لذلك لن ترى أي لعبة من هذا المحرك مصنوعة من البرمجة النصية العادية. محرك آخر (أكثر عقلانية ، imo) به مكونات إضافية مثل Unity و UE4. أنا شخصياً أحببت حقًا استخدام كل من uscript و PlayMaker في Unity جنبًا إلى جنب مع الكود العادي الخاص بي لأنه في حين أن بعض الأشياء أسهل في البرمجة ، فإن العديد منها أسهل في البرمجة النصية بصريًا ، لا سيما آلات الحالة لأنه مع وجود نص مرئي مثل PM ، فإنه يمنحك الكثير من التعليقات باستخدام breakpointsw أنه من الأسهل بكثير النظر إلى المشروع من منظور أكثر شمولاً.

الشيء الحقيقي في البرمجة النصية المرئية بشكل عام ، هو محاولة غير مجدية لذلك
جعل البرمجة في متناول غير المبرمجين ، وهذا خطأ تمامًا
يقترب.
البرمجة المرئية أصعب من البرمجة النصية العادية. لصنعه
أسهل عليك أن تكتب كتل كثيرة لكل حالة في الحياة التقليدية
طريقة و
دع هؤلاء الناس يستخدمونها. ثبت أن هذه أقل فعالية من طلب أ
مبرمج جيد لكتابة التعليمات البرمجية. الحكيمة "البرمجة ليست مهنة ،
يمكن للجميع فعل ذلك "خطأ. كل محاولات البرمجة بدون
البرمجة مضيعة.

بالنسبة لآلة الدولة - كنت أفكر في تطبيق هذا في بعض الوقت
قبل ذلك ، لكن هذا لن يساعد برنامج المرئيات العالية.
يمكن القيام بذلك بسهولة للعبتك باستخدام البرنامج النصي للأداة ومحرر العقدة ،
وهي أداة قوية ، يستخدمها العديد من الأشخاص لأدوات اللعبة ، مثل
محرري حوار اللعبة.

في الخميس ، 14 أبريل 2016 الساعة 9:09 صباحًا ، كتب Aaron M [email protected] :

لا أريد أن أقول ذلك ، لكن هذه نظرة ضيقة جدًا للبصرية
أدوات البرمجة ، سيرجي. أما بالنسبة للألعاب التي صنعت معهم بالكامل ،
اختارت بعض المحركات تمامًا مثل Construct ، لذلك أنت
لن ترى أي لعبة من هذا المحرك مصنوعة من البرمجة النصية العادية. آخر
(أكثر عقلانية ، imo) يحتوي المحرك على مكونات إضافية مثل Unity و UE4. أنا شخصيا
أحب حقًا استخدام كل من uscript و PlayMaker في Unity جنبًا إلى جنب مع نظري العادي
لأنه في حين أن بعض الأشياء أسهل في البرمجة ، فإن العديد منها أسهل في البرمجة
يخرج البرنامج النصي بصريًا ، ولا سيما آلات الحالة لأنه مرئي
scripter مثل PM يمنحك الكثير من التعليقات مع نقاط التوقف فقط
أسهل بكثير في النظر إلى المشروع من وجهة نظر خارجية أكثر تحديدًا.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

سلابين ، أنت على حق. لكنك تنسى أن البرمجة المرئية أو كتل البرمجة لها معدل فشل منخفض جدًا. إنه بسبب القيود.
إنها في الأساس هي نفسها عندما تأخذ لغة برمجة محدودة للغاية. لا يمكنك أن تفعل الكثير من الأخطاء.

أعتقد أن هذا يجب أن يكون الهدف لتحقيق ، وليس السؤال عما إذا كانت البرمجة النصية المرئية أو النصية!

إذا كنت تريد تحسين البرمجة ، فقم بتحسين الأدوات. تسليط الضوء على الشفرة ، وإكمال الترميز ، والتحقق من صحة الترميز ، والقوالب البرمجية ، aso. اجعل مصحح الأخطاء أفضل واجعل البرمجة الحية.
لقد بحثت دائمًا عن بيئة برمجة حية مستقرة ، ولكن حتى الآن لم أجدها!

إذا كنت تريد حقًا إنشاء البرمجة النصية المرئية ، فاجعلها مثل محرك Stingray. يمكنك إنشاء CodeBlocks في Visual وإنشاء TextCode يمكنك تعديله لاحقًا ، أو كتابة TextCode يمكنك استخدامه لاحقًا ككتل مرئية.

لن أقول إنه غير مجدي ، لكنني أقول إننا نتحدث عن 2
منتجات مختلفة تمامًا.

إذا كنت تدير استوديوًا ، وتقوم بإنشاء ألعاب مع 20-80 شخصًا ،
أنت تنفق 6 أرقام في تكاليف الإنتاج كل شهر ، وتحتاج إلى
محرك لصنع ألعابك ، فأنت تريد منتجًا معينًا. في هذه الحالة ، أنت
لا تهتم على الإطلاق بأدوات البرمجة النصية المرئية ، فأنت تهتم بالآخرين
أشياء ، مثل مدى إنتاجية فريقك باستخدام أدوات المحرك
(نظرًا لأنهم إذا تجاوزوا الجدول الزمني لمدة شهر واحد ، فستخرج حوالي 100 ألف دولار). أولئك
الفرق لديها مبرمجون ، وسيكونون أكثر إنتاجية في كتابة الأكواد
من استخدام بعض الأدوات المرئية (ابحث عن Vicious Engine للحصول على مثال على ذلك)

من ناحية أخرى ، إذا كانت لديك فكرة رائعة ولا تعرف حقًا كيفية القيام بذلك
اكتب رمزًا ، تريد منتجًا آخر ، شيئًا ما للقيام بنموذج أولي سريع
يمكنك إظهارها وتقديمها للمبرمجين في النهاية لتحقيق ذلك
لعبه.

إنه منتجان مختلفان ، وإذا جادلنا حول أيهما أكثر قيمة
بعد ، علينا أن نعترف بذلك. أود أن أقول أن البرمجة النصية المرئية
الأداة لا تصل إلى أكثر من شخص واحد يصنع نموذجًا أوليًا. كما
بمجرد أن تريد إنشاء لعبة كاملة ، أو بمجرد نمو فريقك إلى 2-3
الناس ، فأنت تحتاج بالفعل إلى لغة برمجة حقيقية. لذلك أنا أحب الأول
مثال أكثر كهدف عام (إلا إذا كنت تريد منتجًا ثالثًا ، وهو
"المحرك الذي يمكنك استخدامه لإنشاء لعبة مستقلة كاملة تحقق الملايين
دون كتابة أي رمز ". هذا غير موجود).

لكن يمكننا الحصول على كليهما ، ولن أحبط أي منهما. بصري
ستساعدنا أداة البرمجة النصية على المدى الطويل ، من خلال إنشاء مستخدمين مبتدئين
التي ستعمل في النهاية على الصناعة وتكون في مناصب لتقرر ذلك
استخدم godot في لعبة حقيقية ، وهذا جيد. أيضا ، CTO لشركة Square Enix
سألنا ما إذا كان المحرك يحتوي على لغة نماذج بصرية ، وهذا يعني
هناك أيضًا مكانة متخصصة في الشركات الكبيرة لهذا النوع من الأشياء ، ربما تلك
التي تقدر البحث والتطوير ولها مراحل طويلة من
ما قبل الإنتاج / النماذج الأولية / تجربة الأفكار الجديدة ، إلخ (أخبر أيضًا
لنا أن ألعابنا تشبه ألعاب وحدة التحكم وسألنا (مرتين) عن البلد
هل ذهبنا لتعلم كيفية صنعها: ع).

في 14 أبريل 2016 الساعة 03:26 ، كتب سيرجي لابين [email protected] :

الشيء الحقيقي في البرمجة النصية المرئية بشكل عام ، هو محاولة غير مجدية لذلك
جعل البرمجة في متناول غير المبرمجين ، وهذا خطأ تمامًا
يقترب.
البرمجة المرئية أصعب من البرمجة النصية العادية. لصنعه
أسهل عليك أن تكتب كتل كثيرة لكل حالة في الحياة التقليدية
طريقة و
دع هؤلاء الناس يستخدمونها. ثبت أن هذه أقل فعالية من طلب أ
مبرمج جيد لكتابة التعليمات البرمجية. الحكيمة "البرمجة ليست مهنة ،
يمكن للجميع فعل ذلك "خطأ. كل محاولات البرمجة بدون
البرمجة مضيعة.

بالنسبة لآلة الدولة - كنت أفكر في تطبيق هذا في بعض الوقت
قبل ذلك ، لكن هذا لن يساعد برنامج المرئيات العالية.
يمكن القيام بذلك بسهولة للعبتك باستخدام البرنامج النصي للأداة ومحرر العقدة ،
وهي أداة قوية ، يستخدمها العديد من الأشخاص لأدوات اللعبة ، مثل
محرري حوار اللعبة.

في الخميس ، 14 أبريل 2016 الساعة 9:09 صباحًا ، كتب Aaron M [email protected] :

لا أريد أن أقول ذلك ، لكن هذه نظرة ضيقة جدًا للبصرية
أدوات البرمجة ، سيرجي. أما بالنسبة للألعاب التي تم تصنيعها بالكامل
معهم،
اختارت بعض المحركات تمامًا مثل Construct ، لذلك أنت
لن ترى أي لعبة من هذا المحرك مصنوعة من البرمجة النصية العادية. آخر
(أكثر عقلانية ، imo) يحتوي المحرك على مكونات إضافية مثل Unity و UE4. أنا شخصيا
أحب حقًا استخدام كل من uscript و PlayMaker في Unity جنبًا إلى جنب مع نظري العادي
لأنه في حين أن بعض الأشياء أسهل في البرمجة ، فإن العديد منها أسهل في البرمجة
يخرج البرنامج النصي بصريًا ، ولا سيما آلات الحالة لأنه مرئي
scripter مثل PM يمنحك الكثير من التعليقات مع نقاط التوقف
فقط
أسهل بكثير في النظر إلى المشروع من وجهة نظر خارجية أكثر تحديدًا.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
< https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209779422

أنت فقط تتحدث معي punto slapin ، أعني ، لم أقل أبدًا أي شيء عن المصممين أو التبسيط ، ولكن سهولة الاستخدام حتى بالنسبة للمبرمجين ، والتي جربت فائدتها. ليس الأمر كما لو أنه يمكنك فقط أن تخبرني أنه مضيعة للوقت عندما تكون التجربة القصصية تظهر عكس ذلك تمامًا. أنا أفضل خيار أن يكون متاحًا - جنبًا إلى جنب - البرمجة النصية ، فأنت تتصرف وكأنني لا أستطيع سوى اختيار أحدهما أو الآخر وأنا مجبر على تسليمه إلى فناني. ليس هذا هو الحال على الإطلاق.

موضوع رائع ، الكثير من الآراء 😁

عملي بسيط. أنت بخير!

ستكون أي من هذه الأفكار إضافة رائعة إلى gdscript 😁

إنني أتطلع إلى تجربتهم عندما يظهرون.

أعتقد أن gdscript يمكن أن يفعل مع بعض الحب ليكون أكثر سهولة في الاستخدام.

لم يتم توثيق بعض العقد بشكل كامل. الكثير ليس لديه أوصاف.
يمكن أن يستفيد Godot من بعض الوظائف المساعدة لتبسيط عملية التطوير. Gamemaker gml مثال جيد:
https://twitter.com/uheartbeast/status/724326557108461568

أعتقد أن مواد التوثيق هي بيتا رئيسي هنا ، وهذا كل شيء.
التطوير في حد ذاته بسيط بما فيه الكفاية. الوثائق والبرامج التعليمية
هناك حاجة حقا. لذلك فقط اجعل حساب youtube الخاص بك مفيدًا (أو مدونة ، أو
فقط انشر في المنتدى) ،
هذا سوف يقدم الكثير من المساعدة.

يوم الاثنين 25 أبريل 2016 الساعة 9:35 صباحًا ، Todor Imreorov [email protected]
كتب:

أعتقد أن gdscript يمكن أن يفعل مع بعض الحب ليكون أكثر سهولة في الاستخدام.

لم يتم توثيق بعض العقد بشكل كامل. الكثير ليس لديه أوصاف.
يمكن أن يستفيد Godot من بعض الوظائف المساعدة لتبسيط عملية التطوير.
Gamemaker gml مثال جيد:
https://twitter.com/uheartbeast/status/724326557108461568

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -214163012

حسنًا ، لدي العديد من الأفكار حول هذا الموضوع.
يمكنك تسهيل التعامل مع محرك من خلال تضمين شيء مثل البرمجة النصية المرئية ، وسيكون ذلك مفيدًا لجميع الفنانين الذين أرادوا الدخول في صناعة الألعاب ولكن ليس لديهم خبرة في البرمجة ، ولكن هذا يدعو مجموعة أخرى كاملة من الأشخاص - وبالتحديد ، أشخاص ليس لديهم مهارات على الإطلاق. لن يكون الأشخاص الذين ينتقلون إلى البرمجة في محرر نصوص على جدول أعمالهم أبدًا ، حتى لو كان ذلك يعني أن اللعبة النهائية ستعاني. الأشخاص الذين يعتقدون أن الشيء الوحيد الصعب في صنع لعبة هو البرمجة ، وذلك مع البرمجة النصية المرئية ، فجأة ، يتم رفع هذا القيد. هذا ليس من غير المألوف أيضا. ما عليك سوى إلقاء نظرة على جميع المحركات الشائعة التي تجعل أشياء معينة أسهل لغير المبرمجين - الكثير من مجرفة. أنا لا أقول أنه لا يجب عليك تضمين البرمجة النصية المرئية لأن هذا يعني أننا نخاطر بالحصول على برامج مجرفة ، ولكن يجب تنفيذها بطريقة لا تشجع هذه الأنواع من الناس على التفكير في أنه يمكنهم فقط استخدام Godotengine لصنع مجرفة.
مشكلتي الأخرى هي أن أحد الأشياء التي يجيدها Godotengine ، والعديد من الأشخاص يحبون هذه الميزة ، هو أنها تعمل بشكل جيد جدًا مع git. تكمن مشكلة البرمجة النصية المرئية في أنها غالبًا ما يتم حفظها في بعض التنسيقات الثنائية ، وهي كابوس يجب إدارته إذا كنت تستخدم أي نوع من مراجعة الكود المصدري. إذا كان عليك تنفيذ البرمجة النصية المرئية ، فيجب حفظها بطريقة ملائمة للنص. وإذا كان هذا مستحيلاً ، فهو صعب. أفضل أن يكون لدي ملفات مشروع في Godotengine بتنسيق ملائم مع git بدلاً من أن يكون لديك نصوص مرئية لا تعمل بشكل جيد مع git.
واستناداً إلى كل العمل المطلوب لتنفيذ نظام البرمجة النصية المرئية ، وحقيقة أنه يمكنك إنشاء أنواع معينة من الألعاب في Godotengine بدون برمجة نصية مرئية دون أي فقدان للوظائف أو الكفاءة أو الأداء ، فما الخطأ في تنفيذها بمجرد مكون إضافي؟ لا أرى حقًا أي سبب يجعله جزءًا أساسيًا من المحرك.

فقط لأضيف 2 سنتًا عن البرمجة النصية المرئية ولماذا لا أحب الفكرة:

أعتقد أن القدرة على توصيل العقد في أي ملف gdscript أفضل بكثير من حيث إدارة الكود والكفاءة.

على سبيل المثال ، مع البرمجة النصية المرئية (أو استخدام ورقة أحداث مشابهة لـ C2) ، ماذا يحدث إذا كان لديك أكثر من 1000 وظيفة؟ أعتقد أن التنقل في كل شيء سيجعل الأمر أسوأ بكثير. أقوم الآن بتحويل لعبة HTML 5 Action RPG الخاصة بي إلى Godot (والتي تزيد عن 10k + سطر من التعليمات البرمجية وأكثر من 500 وظيفة). _ (يحتوي بشكل أساسي على كل ميزة واحدة يمتلكها Path of Exile ، باستثناء الرسوم المتحركة وهو متعدد اللاعبين) _

لا توجد طريقة يمكن أن يكون هذا ممكنًا بالنسبة لي مع البرمجة النصية المرئية. أعتقد أننا ومطورو godot هنا يجب أن نركز أكثر على الميزات / سحق الأخطاء أكثر من ورقة حدث الكود المرئي. لكن هذا أنا فقط :)

تحرير: كما قال البعض الآخر ، ربما بالنسبة للمشاريع الأصغر أعتقد ... لكن أي شيء كبير لا يمكنني رؤيته مفيدًا

تدعم ورقة الأحداث في الإنشاء 2 الوظائف وتعمل تمامًا مثل godots. سيحل مربع تصفية / بحث بسيط جميع الأخطاء التي ذكرتها.

لكن godot devs لا تريد القيام بأسلوب ورقة الحدث حتى لو كانت أجهزة الصراف الآلي شائعة. لدي انطباع بأنه من المرجح أن تحصل على شيء مشابه لنهج المخطط غير الواقعي. بهذه الطريقة سيستفيد المبرمجون من إضافة محرر آلة الدولة إلى ترسانتهم

لتنظيم كود البرمجة النصية المرئية في vonstruct2 ، يمكنك وضعه في مجموعات يمكن طيها. هذا شيء لا يستطيع حتى gdscript القيام به - لا يمكنك طي كتل من التعليمات البرمجية. لذلك ، من بعض النواحي ، تتمتع ورقة الأحداث بمزايا أكثر من محرر godots gdscript.

reduz كنت أبحث في Pure Data والطريقة التي يفعلون بها ذلك بسيطة للغاية. حسنا تحقق من هذا

كما ترى فإن كتابة "Bang" تحول الكائن العام إلى كائن Bang.

ماذا لو أصبحت البرمجة النصية المرئية امتدادًا لـ GD Script. ببساطة ضع عقدة عامة واكتب Vector2 لـ ex وستصبح كائن Vector2. لذا فإن كل فئة / كائن هو أيضًا عقدة.

لتشغيل وظائف أعتقد أنه يمكنك الحصول على عقدة أخرى ليست كائنًا بل هي عقدة عملية وستكتب شيئًا مثل Vector2.dot وستتحول العقدة إلى عقدة نقطية بمدخلين ومخرج واحد.

يتم تخطيط البرمجة النصية المرئية في مرحلة ما

أنت لم تخيب :) <3

نظرًا لوجود VisualScripting بالفعل ، هل يجب إغلاق هذه المشكلة؟

نعم.

"ابتسمت أيضًا بطريقة إيجابية.
لأنه سيكون أمرًا رائعًا بالنسبة لي كلاعب إذا كانت هناك شركة كبيرة مثل Steam بها العديد من كتالوج الألعاب ، والمفتوحة ، ومجانية DRM ، التي أنشأها الآلاف من مطوري الألعاب الرائعين. "
انظر فقط إلى gog ، إنه متجر يبيع ألعاب DRM المجانية.

الرد خارج الموضوع على بيان 2015 ، تعال :)