Godot: البرمجة النصية المرئية على غرار ورقة الحدث

ألا يمكن التخفيف من الكثير من هذا من خلال تمكين البرمجة النصية المرئية الحالية بوظائف أكثر وأفضل؟

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

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

فكرة جيدة للمكوِّن الإضافي. لكن الحفاظ رسميًا على نظامي البرمجة النصية المرئيين سيكون أمرًا مزعجًا ، ولن يكون له سوى القليل من المكاسب.

mhilbrunner للأسف لا ، تعد Blueprints نهجًا مختلفًا تمامًا عن البرمجة النصية المرئية. إنها تافهة بالنسبة لك ، لكنني أتحداك أن تقول ذلك في منتدى clickteam أو في منتدى الإنشاء. هؤلاء الرجال عالقون في المحركات التي يستخدمونها بسبب مدى حبهم لهذا النهج وصدقوني - لقد جرب العديد منهم المخططات في Unity والمحركات غير الواقعية والمحركات الأخرى - بما في ذلك godot. لا يزالون عالقين مع build2 أو اندماج فريق النقر لأنهم يفضلون أوراق الأحداث على المخططات. لا يزالون يطلبون نهج ورقة الحدث في منتدى الوحدة.
تم ذكر البرمجة النصية المرئية لـ Godot في منتدياتهم وما زال المستخدمون يفضلون أوراق الأحداث. لقد انتقلت شخصيًا إلى gdscript وأفضل استخدام gdscript بدلاً من المخططات - لأن gdscript أقرب في مزاياها إلى أوراق الأحداث من المخططات.

إنه مثل إخبار شخص يحب الموز أن يأكل الطماطم بدلاً من ذلك - إنها مسألة ذوق :)

groud اعتقدت الشيء نفسه لفترة من الوقت ، لكنني لست متأكدًا من أين أبدأ - وحتى كمكوِّن إضافي - سيتعين على شخص ما صيانة المكون الإضافي.

يبدو أن reduz يشعر Facebook ، لكنني أفهم أنه ممتلئ بالأشياء الأكثر أهمية

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

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

blurymind نعم ، وشكرًا بالتأكيد على الإشارة إلى هذا الأمر وأخذ الوقت الكافي للكتابة التفصيلية. ما زلت أعتقد أن هذا ربما يكون أفضل كمكوِّن إضافي.

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

لم تنظر في أي من هذا حتى الآن ، لذا نرحب بالمؤشرات. :) لا توجد مؤشرات من فضلك!

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

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

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

groud هذه نقطة جيدة في الواقع. ما المقدار الذي يمكن إعادة استخدامه من مصدر البرنامج المرئي الحالي؟ ما مدى خصوصية واجهة nodegraph؟

blurymind نعم حصلت عليك ، العمل على مثل هذه القائمة لـ VS وستفعل ، لكنها ستستغرق بعض الوقت.

بحاجة إلى التحقيق في NativeScript :)

لدينا الآن خيارات متعددة للغات البرمجة النصية (C ++ ، C # ، وحتى python). لماذا لا يكون لديك أيضًا أكثر من خيار واحد للبرمجة النصية المرئية :)

أعتقد أن هذا يمكن أن يعتمد أيضًا على مدى مرونة واجهة برمجة تطبيقات godot لبناء واجهات البرمجة النصية المرئية.
هل ينبغي إعادة استخدام قاعدة البرمجة النصية المرئية - أم ينبغي كتابة مصدر بديل تمامًا باستخدام Nativescript (c ++)؟
هل يمكن تنفيذ هذا فقط كملحق gdscript؟

لماذا لا يكون لديك أيضًا أكثر من خيار واحد للبرمجة النصية المرئية :)

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

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

ولا ، لا أعتقد أنه يمكننا إعادة استخدام كود البرمجة النصية المرئية.

groud هذه نقطة جيدة ، لكن ضع في اعتبارك نسبة المبرمجين إلى الفنانين في gamedev. صُنعت بعض من أعظم وأجمل الألعاب الرجعية ثنائية الأبعاد باستخدام الانصهار 2 بواسطة فنانين أرادوا إنشاء ألعاب بطريقة بديهية تناسب طريقة تفكيرهم. إليك بعض الألعاب التي عفا عليها الزمن من ألعاب Fusion:
https://www.youtube.com/watch؟v=3Zq1yo0lxOU

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

حسنًا ، ربما ، ولكن كم منهم قادر على فهم أوراق الأحداث ولكن ليس VisualScripting؟ أنت تقول إن "هؤلاء الرجال عالقون في المحركات التي يستخدمونها بسبب مدى حبهم لهذا النهج وصدقوني - لقد جرب العديد منهم المخططات في Unity والمحركات غير الواقعية والمحركات الأخرى - بما في ذلك godot" ، ولكنك في الواقع أول من طلب ذلك.

إذا كان هذا مطلبًا شائعًا ، فيمكننا إضافته إلى الجوهر. لكن الأمر ليس كذلك حتى الآن.

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

groud من الصعب

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

محرك صانع rpg هو حقًا محرر مستوى إذا سألتني. لا تتمتع بنفس مستوى المرونة مثل Fusion و build2

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

هل هذا

تبدو صعبة الفهم مثل هذا؟

بالتأكيد ، سيستخدم godot المزيد من كتل الأحداث لتحقيقه ، لكنه سيظل أوضح من الرسم البياني للعقدة.
حتى gdscript تبدو أوضح بالنسبة لي من ذلك. يبدو نظام النص المرئي الحالي لدينا معقدًا من النظرة الأولى

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

كم عدد الذين يستخدمون النص المرئي الحالي؟

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

سيكون groud رائعًا إذا تمكنا من اختبار النص المرئي لـ godot في بيئة مدرسية - مع تعلم الأطفال مفاهيم الترميز الأساسية.
كانت إحدى أكبر نقاط البيع في build2 هي تعليم الأطفال الترميز وهم يبيعون ترخيصًا تعليميًا خاصًا منذ سنوات.

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

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

أود أن أحاول كتابة ملحق ورقة حدث أساسي في gdscript ، فأنا لست من ذوي الخبرة الكافية لإنشاء ملحق نصي أصلي. إذا كان ذلك ممكنًا ولديك بعض المؤشرات من أين تبدأ - أود أن أسمعها
ربما إذا كان هناك اهتمام كافٍ ، فقد يجعله شخص ما مكتوبًا بالأصليّة

لأن مقاربتها تتمحور حول آلة الدولة البحتة

لما ؟ ليس لدي فكرة لماذا تعتقد ذلك. لا علاقة للسيناريو المرئي بآلات الدولة.

أيهما أسهل للاستخدام في الوقت الحالي - Blueprints أم Gdscript؟ ما هو الهدف من البرمجة النصية المرئية ومن هو المستخدم المستهدف

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

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

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

أنت لست الجمهور المستهدف المناسب - فأنت مبرمج c ++ متمرس. يرجى اختبار هذا مع أشخاص غير مبرمجين وستبدأ في رؤية ما أعنيه.

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

groud هل يمكننا حتى تجميع عقد visualscript كما هو الحال في الخلاط؟ لا أتذكر رؤية ذلك. ربما يجب على mhilbrunner إضافته إلى قائمته
https://github.com/godotengine/godot/issues/12418
هناك نقطة مهمة أخرى - القدرة على إنشاء كتل منطقية للعمل / الشرط ذات مستوى أعلى قابلة لإعادة الاستخدام عبر gdscript ستكون مفيدة جدًا لنظام ورقة الأحداث أو نظام المخطط. نظام المخطط يحتوي عليه بالفعل - لكني لا أرى أي مكونات إضافية مصممة له ..

مرة أخرى - بناء 2 هو الطريق أمامنا. أنشأ مجتمعهم العديد من المكونات الإضافية سهلة التثبيت التي تضيف شروطًا وإجراءات مخصصة - وواجهة برمجة التطبيقات الخاصة بهم لتسجيل إجراء وشرط بسيط للغاية
https://www.scirra.com/forum/completed-addons_f153
https://www.scirra.com/manual/19/actions-conditions-and-expressions

تماما بما يتفق مع blurymind
بالنسبة لي ، من الأسهل كثيرًا فهم نظام الأحداث Construct and Fusion ، والذي يوفر أيضًا تطوير أي لعبة أسرع بكثير من نظام مليء بالخطوط

لول كيف يكون هذا أسهل في القراءة من gdscript

groud هل يمكننا حتى تجميع عقد visualscript كما هو الحال في الخلاط؟ لا أتذكر رؤية ذلك

انا لا اعرف. لكن إذا لم يتم تنفيذه ، أعتقد أنه يجب أن يتم.

لول كيف يكون هذا أسهل في القراءة من gdscript

هذه ليست النقطة هنا.

groud نعم هو كذلك. لماذا قد يرغب مطور اللعبة في استخدام أوراق الأحداث عندما تكون القراءة غير منظمة / مربكة أكثر من قراءة كود gdscript البسيط؟ هذا هو جوهر اقتراح هذه الميزة بالكامل ، أليس كذلك

groud نعم هو كذلك. لماذا قد يرغب مطور اللعبة في استخدام أوراق الأحداث عندما يكون غير منظم أكثر من كود gdscript البسيط؟

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

لا معنى للمقارنة بين أوراق الأحداث و GDscript.

لا معنى للمقارنة بين أوراق الأحداث و GDscript.

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

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

مع ذلك قيل: إن gdscript الذي تم تجميعه بواسطة JIT موجود على خريطة الطريق ، وسيكون أكثر فائدة بكثير من أوراق الأحداث أو إضافات البرمجة النصية المرئية (نظرًا لأن غالبية مطوري godot يمكن أن يستفيدوا منها بالفعل بشكل كبير). وحالات الاستخدام المحتملة لـ VS / Event Sheets منخفضة جدًا حاليًا. لذلك كل ما أطلبه من فضلك كن حذرًا بشأن وقت التطوير الرئيسي ، كما أوضحت مشاركتك الأخيرة بالفعل

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

من الواضح أنك لم تلمس أبدًا الإنشاء أو اندماج فريق النقر ، إذا كنت ترغب في إجراء مناقشة حوله - على الأقل استخدم ورقة الحدث لفترة من الوقت - اصنع منهاجًا منهاجًا.
لقد قمت بربط حساب توضيحي على الإنترنت لـ build3 ، والذي لا يتطلب منك تسجيل حساب أو تسجيل الدخول.
https://www.scirra.com/
انها حرفيا ثلاث نقرات بعيدا

جرب ورقة الحدث ، اصنع شيئًا بها. ثم استخدم المخططات المرئية التي يمتلكها godot

Gdscript بسيط - نعم أوافق وأحبها أيضًا. سيكون برنامج gdscript الذي تم تجميعه بواسطة jit رائعًا! متفق عليه أكثر أهمية أيضا.
لكن هذا النقاش لا يتعلق بهذه الأشياء على الإطلاق

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

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

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

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

على أي حال ، سوف أوقف هذا النقاش هنا. تم بالفعل التعامل مع ترسيم الدراجات حول VS أو عدم VS.

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

تقدم groud حجة جيدة حولهم ، لأن Marvel Heroes كانت AAA aRPG واستخدموا المخططات مع Unreal .

لا أوافق على أن لديهم حالات استخدام خاصة بهم ، أعتقد فقط أنه سيكون من الصعب تبريرها ، بناءً على المعايير التالية:

• محدودية القوى العاملة ديف
• كمية من القضايا الحالية بالفعل
• الفوضى / صعوبة القراءة (انظر هنا )
• أشعر أن معظم مطوري godot يفضلون استخدام gdscript
• علاقات gdscript بشكل جيد مع godot بالفعل
• إذا تمت إضافتها إلى العناصر
• ليس عادلاً بالنسبة لـ 90٪ من مطوري godot الذين يستخدمون gdscript بالفعل (إذا كان من الممكن استخدام وقت dev لـ gdscript المترجمة بواسطة jit ، والذي يفي بحالات الاستخدام النشط)

كمكوِّن إضافي يمكنني دعمه بالكامل ، لكن قلبي يقول إنه قد لا يكون فكرة جيدة إذا تم دعمه رسميًا

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

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

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

يأخذ النص المرئي الحالي الذي لدينا الكثير من النقرات والعقد والإسهاب للقيام بأبسط الأشياء. وهذا سبب آخر هو أن gdscript هو أكثر وضوحًا من imo - سطر من التعليمات البرمجية بدلاً من 10 عقد و 100 اتصال.

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

يمكن أن يستخدم Godot بسهولة gdscript للتعبيرات عند القيام بنفس الشيء - ولكن هذه التعبيرات موضوعة في هيكل جدول بيانات بسيط.

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

نهج Construct في إقران الكائنات أمر مروع - من بين أمور أخرى - ولكن هذا لا علاقة له بتصميم ورقة الحدث

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

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

كذلك ، فإن مناقشة JIT لـ GDscript غير موضوعية. لا يمكن قياس ميزة الميزة إلا من خلال:

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

لذا فإن ما إذا كان يجب القيام بذلك أم لا لا علاقة له بما إذا كنا نطبق JIT لـ GDScript أم لا. بخلاف ذلك ، يجب أن نغلق 99٪ من جميع طلبات الميزات حتى يتم إصلاح جميع الأخطاء الرئيسية ، أي إلى الأبد. هذه هي أكثر أهمية من JIT لـ GDScript.

mhilbrunner JIT لـ GDScript سيحدث بالفعل على الرغم من أنه موجود بالفعل على خريطة الطريق الرسمية: P. كنت أقول فقط أن هذا يمكن أن يأخذ وقت التطوير من ذلك. ومن الصعب تبرير ذلك بما أن 90٪ من مطوري godot يستخدمون بالفعل gdscript (ويعتقد الكثير من الناس أنه أفضل من أوراق الأحداث ، ولهم مشاعرهم الخاصة). آسف إذا لم أنقل نفسي بشكل صحيح. نعم ، أعلم أن هذا لا يحل محله ، لكني أقول المزيد عن وقت التطوير.

مع ذلك ، @ blurymind لا يمكنني الاختلاف مع أي شيء قلته لأنها نقاط جيدة حقًا. هل سيكون وجود أوراق الأحداث في Godot ميزة رائعة؟ أكيد ، لكن هل هذا شيء سيحدث في الواقع قريبًا؟ أنا غير متأكد. (مجرد مستخدم متعطش منذ 2014 ، وهذا رأيي فقط)

بعد أن استخدمت ورقة حدث Action Game Maker و Game Maker مسبقًا بنفسي ، أوافق على أنه أسهل في الاستخدام والفهم من VisualScript (تقرأ من أعلى إلى أسفل ، وليس الأسطر التالية) ، ولا تشغل مساحة كبيرة على الشاشة ، ويمكن أن تنفذ بشكل محدود آلة الحالة بسهولة أكبر (عن طريق تصفية الأحداث التي يمكن تشغيلها بعد انتهاء الحدث).

ستكون إضافة لطيفة للغاية. ربما لن أستخدمه بنفسي لأن GDScript كافٍ بالنسبة لي ، لكن يمكنني أن أتخيل نفسي أستخدمه على ما يرام إذا لم يكن GDScript خيارًا (ربما يواجهه المبتدئين وغير المبرمجين).

حسنًا ، أنا من مستخدمي Godot لمدة عام تقريبًا. أنا أحب GDScript وهو بناء جملة بسيط.
لكنني استخدمت Construct لأكثر من 8 سنوات ويمكنني أن أقول إنني لم أر أبدًا نصًا مرئيًا أسهل من Event Sheets. لا أحب Blueprint واستخدمت بعض أنماط VS Blueprint الأخرى ، مثل blender's و Unity ، ولا أفعل لم أفهم كيف يمكن للناس أن يقولوا إن Blue Print أسهل من Event Sheets. ربما يرجع السبب في ذلك إلى أن الفنانين اعتادوا على استخدام العقد لإعداد التظليل والرسومات ، فقد اعتادوا على هذه الجمالية. لكنني أراهن أنه إذا وضعت نظام ورقة الأحداث في محرك مثل Unreal ، فسوف يسقط الناس Blueprints.

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

فائدة أخرى أعتقد أن أوراق الأحداث ستجلبها ، ستزيد من قاعدة مستخدمي Godot ، حيث رأينا في GDC أن الاستوديوهات المتوسطة إلى الكبيرة تفضل Godot ، لكن الصغيرة تفضل Unity والحلول الأخرى. أعتقد أن المستخدمين من Construct و Fusion و Game Maker سيبدأون في الهجرة إلى Godot.

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

على أي حال ، أنا أحب ما يفعله Godot وأحب GDscript ، أردت فقط أن أتحدث عن تجربتي ، حيث أنني أستخدم كل من Event Sheet و GDscript للتدريس. حافظ على العمل الرائع!

عندما ظهر Godot 3.0 ، درسنا فكرة التخلي عن Construct 2 لاستخدام Godot VS ، لكننا تخلينا عن الفكرة لأن VS في الوقت الحالي أصعب من GDScript ، وهو أمر معقد للغاية في الفهم والاستخدام

هذه ردود فعل مثيرة للاهتمام. :)
الحقيقة هي أن أوراق الأحداث ، في نموذج Construct2 ، أقل انخفاضًا بكثير من VS أو GDscript. في الواقع يمكنهم مساعدة الأطفال للدخول في برمجة الألعاب ولكن هذا ليس هدف Godot. أعتقد أنه لا ينبغي شحن مثل هذا النظام على أنه مدمج ، ولكنه متاح عبر مكون إضافي. أعتقد أن هذا التعليق من reduz يعبر عن هذا أيضًا.

DrZanuff شكرًا لك على طرح هذه النقطة المهمة حقًا - فقد لاحظت أيضًا قناة Kidscancode على youtube و NinkuX بعض الأشياء على نفس المنوال - تعتبر أوراق الأحداث رائعة لبيئة المدرسة والانتقال الرائع إلى شيء مثل gdscript. المخططات ليست مؤسفة

ربما يمكن لـ Godot التعامل مع هذا بالطريقة التي يعمل بها صانع اللعبة - يتم ترجمة رمز السحب والإفلات المرئي مباشرة إلى كود gml الذي يمكن حتى معاينته في الوقت الفعلي. بهذه الطريقة يمكن لغير المبرمجين تعلم لغة gml أثناء استخدامهم لنظام البرمجة النصية المرئي للمحرك - إنها الاستراتيجية الدقيقة التي تستخدمها ألعاب yoyo للحصول على غير المبرمجين الذين يتم تقديمهم تدريجيًا إلى gml
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

سواء عند استخدام بعض التعبيرات gml أو أثناء معاينة ما تقوم به البرمجة المرئية

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

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

أداة التعلم الإضافية التي يستخدمها كل من دمج فريق النقر والبناء 2 هي قائمة قائمة تعتمد على النقر للطرق / الأعضاء المضمنة في العقدة

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

بهذا المعنى - يمكن أن يكون الهدف الرئيسي لتطبيق Godot لنظام ورقة الأحداث هو تقديم غير المبرمجين إلى gdscript ومفاهيم البرمجة الأساسية دون إرباكهم بأي بناء جملة - سيضع Godot بعد ذلك في المزيد من المدارس التي تدرس البرمجة لمرحلة ما قبل المراهقة. مع تقدمهم ، سيتعلمون gdscript و godot's api ، بدلاً من build2 أو صانع الألعاب

أعتقد أنني لم أشرح جيداً ... :(

عندما أقول سطورًا ، أشير إلى البرمجة النصية المرئية ، إلى الأسطر التي تربط العقد

يعد نظام أحداث الإنشاء والانصهار أكثر سهولة وسرعة وسرعة في إنشاء لعبة ، من البرمجة النصية المرئية لـ Godot

سيكون من الجيد استكشاف بديل من هذا النوع

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

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

يمكن أن يحتوي مستودع الأصول على قسم خاص لإضافات البرنامج النصي المرئي

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

ليس فقط نظام ورقة الحدث. هي أيضًا طريقة عمل المكونات الإضافية / السلوكيات / العائلات وخصائص UIDs والكائنات.

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

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

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

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

matriax لا أعتقد أنك على صواب هنا.
يتمتع Godot بهندسة معمارية أكثر مرونة ومباشرة من Construct2.
كما لوحظ أن اقتران الكائن هو ألم في البناء ، من بين أشياء أخرى كثيرة - يمكننا على سبيل المثال أن يكون لدينا ترتيب حدث أوضح من ترتيب البناء. يمكننا إرفاق أوراق الأحداث بأي عقدة - مما يتيح تنظيمًا أفضل من الإنشاء'2.
بالنسبة للأنواع / العائلات - في godot لدينا "مجموعات" - فإن تنفيذ مجموعات godot هو في الواقع أفضل من عمليات الإنشاء.
لإرفاق السلوكيات بالكائنات - يمكنك فقط إرفاق العقد الفرعية واستخدامها كسلوك للعقدة الأصل الجذرية التي تحتوي على ورقة الأحداث المرفقة. هذا في الواقع أفضل من البناء مرة أخرى.
في godot ، عليك أن تجعل عقدة شكل تصادم تابعة للعقدة التي بها تصادم. إنه ليس علم الصواريخ وهو في الواقع أفضل لتعليم الأطفال البرمجة

يجب تنفيذ بعض الأشياء التي تطلبها كوظائف إضافية وقد تم إنشاؤها بالفعل كوظائف إضافية (تخمين شكل المضلع على سبيل المثال)

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

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

blurymind أنا لا أقول عن تطبيق نفس الهندسة المعمارية كما في C2 ، هذا لا معنى له ، كما أنني لا أعرف كل الأشياء التي

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

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

matriax تحتاج إلى تعلم

الاقتراح هنا خاص بورقة الأحداث ، وليس لنسخة المحرك بأكملها من build2.

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

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

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

@ blurymind ومرة أخرى بنفس الشيء ، حسناً نسيتها.

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

إذا سألت فقط عن برنامج تعقب godot هنا - فستحصل في الغالب على خبرة متوسطة للمبرمجين - الأشخاص الذين يعرفون بالفعل ويحبون gdscript و api للمحرك وحتى c ++
سوف يتفاعلون بشكل وقائي - كما ترى في بداية الرسالة اللاحقة - التفكير في أن ما تقترحه ليس ما يحتاجونه ويحتاجه المحرك - بطبيعة الحال لأننا نعرف بالفعل كيفية كتابة التعليمات البرمجية في gdscript ونرى أهدافًا أكثر أهمية لـ محرك من هذا. صحيح أن هناك أهدافًا أكثر أهمية.
إذا كنت محظوظًا ، فقد بدأ بعضهم بدمج الإنشاء / صانع الألعاب / فريق النقر قبل الوصول إلى godot ، وسيعرفون أين تكمن قيمته بالنسبة للأشخاص الذين لا يعرفون أي لغة برمجة حتى الآن.

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

بالعودة إلى القيمة في هذا - ألن يكون رائعًا إذا أصبح جودو ، ربما يومًا ما في المستقبل ، المحرك الأول لمزيد من الأطفال؟
لماذا لا تحاول استبدال Construct في المدارس :) Scirra devs يجدونها سهلة للغاية في الوقت الحالي. انظر كيف يتفاخرون بالتعاون مع المدارس
https://www.construct.net/gb/blogs/construct-official-blog-1/construct-3-a-year-in-review-947؟utm_campaign=blog1postemailsub&utm_medium=email&utm_source=947&utm_term=txt4-read-laura_d٪ 2527s-post & utm_campaign = marketing & utm_source = sendgrid & utm_medium = بريد إلكتروني

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

سيكون من الرائع أن تستخدم عقدة richtextlabel في godot أيقونات محرر godot الداخلية

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

بمجرد إنشاء واجهة ، فإن الباقي هو مجرد الحصول عليها لحفظ / تخزين البيانات داخل المشهد وللتمكن من إنشاء gdscript نظيف - ولكن قد أفتقد شيئًا ما

@ blurymind نيس ، أحببت المفهوم.
ربما يجب أن تكون الأزرار لإضافة إجراءات وشروط بدون زر الخلفية ، كما هو الحال في الإنشاء 2

وأعتقد أنه سيكون من الجيد فصل الشرط عن الإجراء

أنا أحب الطريقة التي يتحول بها هذا.

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

DrZanuff شكرا لك على ردود الفعل
@ Zireael07 شكرا لك :)
نعم بالضبط - أداة من شأنها أن تساعدنا على استبدال Construct2 تمامًا بـ Godot في المدارس التي تستخدم كلا المحركين لتعليم البرمجة.
يوجد تحتها مجرد واجهة مرئية لإنشاء ملفات gdscript - على غرار طريقة استخدام DnD في Game Maker 2. لا أطلب أي تغييرات على بنية godot الممتازة.
يمكن أن تكون أوراق الأحداث أحد خيارات البرمجة النصية المرئية في Godot بحيث تكون سهلة الاستخدام لغير المبرمجين (المخططات ليست كذلك) والأطفال الصغار يتعلمون مفاهيم البرمجة - ويسهل عليهم تحويلها إلى gdscript

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

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

أحب عملك على هذا. هل ستكون على استعداد لإتاحته في الريبو أثناء عملك عليه (إذا قمت بذلك)؟ أود إلقاء نظرة وكزة عليه واللعب.

mhilbrunner بالطبع يمكنك ذلك -

أنا بصدد دمج واجهة المستخدم الرسومية في محرر godot كمكوِّن إضافي لـ gdscript - إنه ليس تفاعليًا بدرجة كافية حتى الآن :)

سأقوم بنشره على github عندما أحصل على واجهة المستخدم الرسومية الأساسية تعمل بشكل تفاعلي لتوصيل أفكار التصميم :) اليوم حصلت على واجهة المستخدم الرسومية الخاصة بورقة الحدث ليتم تحميلها كعلامة تبويب - مع أخذ بعض الإلهام من البرنامج المساعد sketchfab:

ربما ينبغي الوصول إلى ورقة الحدث من مكان آخر؟

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

• هل تعرفون يا رفاق طريقة سهلة لعرض أيقونات عقدة Godot داخل عقدة تسمية النص الغني عبر BBcode؟
  في نموذجي السابق ، استخدمت علامات [img] - ولكن هذا أسلوب ضعيف جدًا حيث سيتطلب مني تنزيل جميع رموز العقدة التي يستخدمها محرر godot وتخزينها مع الملحق

• أنا أيضًا أكافح لمعرفة كيفية تسجيل مورد نوع برنامج نصي جديد لورقة الأحداث عبر الملحق API

@ blurymind جيد جدا! الآن أصبح أكثر قابلية للقراءة. نحتاج إلى التفكير في كيفية عرض قائمة الإجراءات للمستخدم.

كان أحد الأشياء التي أحببتها من Construct Classic القديم هو خيار تحرير القيم من ورقة الحدث دون فتح الإجراء أو الشرط ، ولكن انقر نقرًا مزدوجًا فوق القيمة لتحريره:

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

تعتمد spyres على ما إذا كان فريق reduz و
أنا شخصياً أعتقد أنه يمكننا استبدال البناء في المدارس بـ godot تمامًا.
لن يعمل نظام المخطط الحالي من أجل ذلك. يعد استخدامه أكثر تعقيدًا من gdscript وكما ذكرنا سابقًا - ليست أفضل طريقة لتقديم شخص ما إلى نماذج البرمجة - لأنه يحتوي على مجموعة القواعد الخاصة به.
الهدف من هذا ليس استبدال gdscript أو نظام المخطط الحالي - بل على العكس - إعطاء الأطفال طريقة لتعلم gdscript من خلال مساعدتهم. هذه هي الطريقة التي تستخدم بها ألعاب yoyo نظام البرمجة النصية المرئي DnD لتقديم غير المبرمجين تدريجيًا إلى Gml راجع للشغل.
لا أعتقد أن هناك أي ضرر في وجود نظام برمجة نصية مرئي يمكن الوصول إليه بشكل أكبر لغير المبرمجين وهو مصمم بشكل أفضل لنقلهم إلى gdscript. لما انت؟

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

لدىDrZanuff Godot طريقة لإدراج جميع الطرق الموجودة في العقدة ، لكني لست متأكدًا بعد من كيفية

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

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

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

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

@ spyres هل أنت مطور بنفسك؟ أم مدرس؟ هل استخدمت بالفعل نص جودو المرئي في أي من مشاريعك الخاصة؟ إذا كان الأمر كذلك ، فكيف يمكن تحسينها لتكون أداة أفضل لتعليم الناس البرمجة؟

@ blurymind أعتقد أن فكرتك جيدة. بالإضافة إلى ذلك ، يبدو أن لديك بالفعل رؤية قوية جدًا لذلك.

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

أتفق أيضًا مع spyres على أن

ومع ذلك ، أعتقد أن ورقة الحدث هذه فكرة مثيرة للاهتمام.

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

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

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

باعتباري شخصًا استخدم كل من build2 و Fusion ، فأنا أحب أسلوب ورقة الأحداث وأرى في Godot's api مرشحًا رائعًا لنظام ورقة الأحداث - بدون عيوب المحركات التي تلهمه.
سيعمل تصميم تداخل العقدة في Godot جيدًا مع ذلك ، بالإضافة إلى وضوح gdscript للتعبيرات.
لا أتوقع أن يتم تنفيذه في godot ، لكنني سأستمر في مشاركة تقدم المكون الإضافي هنا ، على أمل الحصول على تعليقات مفيدة ومساعدة في واجهة برمجة التطبيقات. استخدم بعض المطورين هنا Construct2 ويعرفون Godot جيدًا ، لذلك قد تنشأ أفكار جيدة من المناقشة.

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

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

spyres من فضلك حافظ على النغمة مدنية. لا تحتاج إلى إخبار الآخرين بأن افتراضاتهم " غبية " أو أن المكون الإضافي المحتمل الذي يستثمرون فيه (مجانًا!) في العمل سيكون مجرد شيء " متمحور حول الأطفال ".

بالتأكيد ، يتمتع الأشخاص بالحرية في قضاء وقتهم (أشعر أن ذلك قد يكون عديم الفائدة في النهاية) كما يحلو لهم ، على الرغم من أنه قد يكون غير مواتٍ للتصميم الأساسي لـ Godot على هذا النحو.

في مصلحة التحضر (على الرغم من أن "التمركز حول الأطفال" هو _ بالضبط _ ما محرجة ، ولا تركز على الخصائص الديمغرافية الأساسية لـ Godot ، وهو أمر نأمل ألا يضيع وقت المطور الأساسي ، إلخ.

لماذا تهتم بإعادة إنشاء البنية داخل

هل الطفل الديموغرافي البالغ من العمر 7 سنوات يصرخ حقًا من أجل هذا النوع من الازدواجية؟

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

هل لدى github طريقة لمنع الأشخاص من النشر إذا كانوا مسيئين؟

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

ما من شأنه أن يكرر وظيفة الإنشاء داخل Godot والذي لم يتم توفيره جيدًا بالفعل بواسطة er ... Construct.

هل هناك جانب إيجابي في استنساخ مجموعة ميزات Construct (ربما بطريقة أقل) في godot لمجرد جذب الأطفال الذين يبلغون من العمر 7 سنوات؟

لماذا لا تستخدم البناء فقط؟ هل إعدادهم (الذي يبدو أن البعض حريصًا على تكراره) يفتقر حقًا إلى هذا الحد؟

هل هناك سبب منطقي لافتراض أن الأطفال لا يستطيعون الانتقال إلى لغة gdscript أو البرمجة النصية المرئية بمجرد تجاوزهم للبناء؟

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

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

جعل اندماج Clickteam عدد الألعاب يفوق عدد الألعاب التي صنعها Godot على Steam و kickstarter وحتى متاجر التطبيقات من حيث العدد والإيرادات التي تحققها. هذا محرك قائم على ورقة الأحداث بالكامل ، يستخدمه الأشخاص الذين تتراوح أعمارهم بين 10 و 80 عامًا. إنه مزيج من جميع الأعمار. بعض المستخدمين هم صانعو أفلام ، والبعض الآخر فنانون - أشخاص لديهم وظائف ينفقون أموالهم على التراخيص والمصدرين وما إلى ذلك. هيك ، لقد ربحت أموالًا من بيع الأشياء في متجر الأصول أكثر من أي شيء آخر يتعلق بـ godot حتى الآن.
إليك بعض الأمثلة - قرر صانع الأفلام ألونسو مارتن أن يصنع لعبة:
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia
مجموعة من 7 سنوات يصنعون لعبة
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game

الق نظرة هنا
http://indiegames.clickteam.com/
هؤلاء الأطفال في سن السابعة يعرفون بالتأكيد كيف يصنعون الألعاب ويكسبون المال إيه
https://thinkgaming.com/app-sales-data/publisher/3107/scott-cawthon/

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

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

الآن ، كيف ستحفزني قراءة مشاركاتك حول كون النظام "غير مرغوب فيه" على إنشاء ملحق مجاني لـ godot؟ فكر في هذا قليلا

قف! تغيير قواعد المرمى على الرغم من ...

اسمحوا لي أن أوضح.

البناء ناجح جدًا في ما يفعله. لذا فإن الحاجة (؟!) إلى الكسب غير المشروع / تكرار مجموعة ميزاتها (كليًا أو جزئيًا) في محرك مختلف تمامًا (بدون فائدة ملحوظة) تهرب مني.

تظل الأسئلة المتعلقة بالمزايا الفعلية كما هي ، على الرغم من أن البعض قد يعتبرها (لسبب غير مفهوم) "مسيئة".

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

لكن مهلا ، لماذا تتوقف عند هذا الحد؟ توجد أدوات ممتازة (بعد الإنشاء) لتعليم البرمجة للأطفال (مثل Scratch و Styncl و code.org وما إلى ذلك) لماذا لا تدمجهم في Godot أيضًا!

أو ربما لا ... ؛-)

هل هناك أي شخص استخدم البرمجة النصية المرئية من Godot ويبدو أنه من الجيد أنه يستخدم فقط البرمجة النصية المرئية من Godot؟

Zonacas لا أعتقد أن البرمجة النصية المرئية

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

مرحبًا بالجميع ، لدي تحديث بشأن التقدم المحرز في ملحق إثبات المفهوم الخاص بي.

إليك صورة gif جديدة لك:

بعض المعلومات الأساسية حول ما تفعله - تتكون ورقة الأحداث بشكل أساسي من الخلايا. يمكن أن تكون الخلية إما لشروط (محاضر / تعبيرات) أو إجراءات (محددات يمكن تغذيتها بأحرف / تعبيرات).
على جانب واجهة المستخدم الرسومية ، يتم إنشاء خلية الحدث عبر عقدة richtextlabel وكود BB الذي يتم إنشاؤه من gdscript. عند النقر فوقه مرتين ، يتحول richtextlabel إلى عقدة مربع تحرير تحتوي على تعبير gdscript الفعلي.

إذن ، تحتوي خلية ورقة الحدث على وضعين:

• وضع التحرير - عقدة textEdit التي يمكن كتابتها باستخدام gdscript.
  الاختلاف الوحيد هو أن المستخدم لا يحتاج إلى كتابة If / else / while - فهذا حساس للسياق للحاوية الرئيسية كما هو موضح في لقطة الشاشة. كل سطر هو شرط جديد ، لذلك إذا لم يبدأ المستخدم السطر بـ "أو" أو أي شيء آخر ، يعرف المحلل اللغوي تلقائيًا أن السطر الجديد به "ذريعة" و "

عند النقر عليه بعيدًا ، ينتقل إلى وضع العرض.

• وضع العرض - تسمية النص المنسق - عند التبديل إلى وضع العرض ، يتم تحليل bbCode من gdscript الموجود في وضع التحرير ويتم تقديمه عبر تسمية نص منسق تفاعلي. بصرف النظر عن كونها تفاعلية وسهلة التغيير ، فإن الهدف هو تقديم كود gdscript بطريقة أوضح. هذا يعني إظهار اسم ورمز العقدة فقط (وليس المسار بالكامل) والتخلص من بعض الكلمات ، عندما تكون واضحة (مثل get_ و set_). نظرًا لأن كل جزء قابل للنقر هو في الواقع علامة url ، عند التمرير فوق اسم عقدة على سبيل المثال - يمكن للمستخدم الحصول على بعض المعلومات ، مثل المسار الكامل للعقدة.

حول قائمة إضافة شرط / إجراء جديد:
هذا هو ما يُنشئ سطرًا جديدًا من التعليمات البرمجية gdscript لشرط أو إجراء. ما يميزه أنه يتيح لك تصفح جميع العقد داخل المشهد وطرقها بسهولة - إنه يعمل بطريقة مقلوبة إلى حد ما لكيفية عمل الإكمال التلقائي في محرر gdscript. يُظهر جميع العقد وكل ما لديهم من أدوات ضبط أو حاصل أو كلتا الطريقتين. يمكنك بعد ذلك تضييق نطاق ما تريد عبر مرشح.
إذا كان الاستدعاء من خلية شرطية ، فإن هذه القائمة تعرض الحاصل فقط ، إذا تم استدعاؤها من خلية إجراءات ، فإنها تعرض كلاً من أساليب setter و getter.

ما هي الخطوة التالية للحصول على هذا العمل:

• أحتاج إلى اكتشاف طريقة للقيام بسحب الخلايا - لأكون قادرًا على تغيير ترتيب الأحداث بسهولة.
• أيضا نسخ ولصق في وضع المعاينة.
• بعد ذلك ، لا بد لي من إنشاء محرر تعبيرات ينبثق عند النقر فوق نوع معين من عنوان url لخلية وضع المعاينة
• معرفة كيفية التعامل مع العناصر النائبة. فكرت في وضع التعليقات ، لكن godot المؤسف لا يدعم التعليقات المضمنة: https://github.com/godotengine/godot/pull/18258 لذلك قد أضطر للعودة إلى لوحة الرسم على ذلك

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

شكرا للجميع على هذا الدعم

فكرة جيدة للمكوِّن الإضافي. لكن الحفاظ رسميًا على نظامي البرمجة النصية المرئيين سيكون أمرًا مزعجًا ، ولن يكون له سوى القليل من المكاسب.

XKCD: المعايير

لا أفهم لماذا لا يمكن أن يكون هذا ملحقًا / مكونًا إضافيًا فعليًا وليس مجرد دليل على المفهوم. لا يجب أن يتم تجميع كل شيء مع المحرك بشكل افتراضي. أعني أليس هذا هو سبب تطوير GDNative؟

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

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

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

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

لمثل هذه الأشياء ، أفضل احترام رغبات المطورين:

https://godot.readthedocs.io/en/3.0/about/faq.html

لدي فكرة رائعة ستجعل Godot أفضل.

سيتم تجاهل فكرتك بالتأكيد.

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

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

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

@ blurymind "مساهمة" رجل ما هي إلهاء رجل آخر (أو محرك). نأسف لأن مفهوم الآراء المختلفة (حتى آراء المطورين الذين شعروا بأهمية كافية لنشرها كجزء من المستندات الرسمية) يبدو مرفوضًا للغاية بالنسبة لك.

حظا سعيدا مع إضافتك. :ابتسامة:

spyres لكن هل صنعت أي شيء بالفعل؟ هل سبق لك أن خلقت ملحقًا لـ godot؟ هل تستخدم جودو؟

لماذا أنت هنا؟ أنت لا تحاول المساهمة في المناقشة

@ blurymind واو ، الآراء المختلفة تزعجك كثيرًا حقًا؟ كم هو حزين بالنسبة لك.

spyres يمكن للجميع هنا رؤية رأيك - فأنت تقوم بإرسال بريد عشوائي إلى الموضوع. كل إبهام هنا هو ملكك. إنه ليس رأي - إنه بريد مزعج. على الأقل nitpick في التصميم وأشياء محددة؟ لقد طرحت عليك بعض الأسئلة في وقت سابق - لم تجب أبدًا على أي شيء

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

كطريقة عمل بديلة مدمجة بالفعل في جودو كور؟ آه ، من فضلك ، لا. أنا مع رأي devs في هذا النوع من الأشياء.

spyres نعم ، لقد قلت ذلك بالفعل. قم بالتمرير لأعلى واقرأه 5 مرات أخرى. هناك واحد منكم .. ولكن مرات كثيرة

@ blurymind ويبدو أنه يزعجك بطريقة ما؟ واو ، آراء بديلة وما شابه.

أفترض أنك لم تكرر أي شيء على الإطلاق صحيح؟ (من أنت ، لماذا أنت هنا ، تبرر نفسك dagnabbit!). : ابتسامة عريضة:

أعتقد أن القليل من تعليقات التوثيق الرسمية التي كتبها المطورون تسببت في القليل من عسر الهضم؟

نعم ، إنه رائع للغاية

blurymind شكرا ، العناق في كل مكان بعد ذلك!

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

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

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

mhilbrunner إذا كانت آرائي المختلفة

spyres لقد أشرت في

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

على حد تعبير رجل حكيم: "لا تقلق ، كن سعيدًا". : ابتسامة عريضة:

أو "كل شيء ممتع وألعاب حتى يصطاد أحدهم عينيه!" (انتظر ، لا أعتقد أن هذا كان الاقتباس الذي كنت أبحث عنه ...)

رائع. سأكون صادقا ، هذا مذهل!

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

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

بمجرد الانتهاء من ذلك ، سيساعد عددًا كبيرًا من الأشخاص

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

فكرة ممتازة!

هذا سيكون مفيد جدا لا استطيع الانتظار حتى يتم الافراج عنه!

فكرة رائعة ، تعاون مع SnailOn.

1. إنه عبقري.
2. لقد استخدم Godot حوالي 3 سنوات.
3. لقد استخدم محركات Clickteam منذ TGF
4. المرشح المثالي.

boruok لقد كنت من محبي قناة yt snailon منذ الأيام الأولى. ساعدتني دروسه التعليمية على تعلم الاندماج منذ فترة طويلة. هل لديه حساب جيثب؟ أحب أن أفكر في بعض الأشياء.

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

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

بدون التعليقات المضمنة ، من الصعب الحفاظ على التبديل السهل بين gdscript و visualscript ، ولكن لدي بعض الأفكار حول كيفية تجاوز ذلك وإجراء التجارب - لذلك أنا أعمل على ذلك الصراف الآلي.
أحتاج إلى طريقة ما لتحديد عنصر نائب فارغ حيث يُتوقع وجود تعبير في gdscript.
نظرًا لأن التعبيرات ستعيد نوعًا من القيمة ، فقد فكرت فقط في استخدام طريقة تحويل القيمة في godot لتمييز العنصر النائب:
float() ## this will turn into a bbcode item that expects an expression resulting in a float
ولكن قد يكون هذا قبيحًا إلى حد ما لأنه سيؤدي إلى إنشاء العديد من طرق التحويل غير الضرورية من النوع المتغير داخل gdscript الذي تم إنشاؤه نهائيًا

إذا كان بإمكان godot عمل تعليقات مضمنة ، فسأكون قادرًا على تحليلها بالطريقة التي تنشئ كود BBcode من gdscript بدلاً من ذلك. سيسمح لي هذا بإطعامه ببعض المعلومات الإضافية

أفضل طريقة حقًا هي جعل طريقة gdscript لعينة محلل bbcode أكثر ذكاءً - وهو ما أحاول القيام به الآن

blurymind أنا لا

@ blurymind أنا أؤيد هذا 100٪!
(آسف مقدما للغة الإنجليزية)

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

يهتم المطورون (على سبيل المثال) بما يلي:

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

مع وضع ذلك في الاعتبار:

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

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

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

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

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

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

TheGoklayeh شكرا على كلمات التشجيع الرقيقة. أنا أعرف بالضبط ما تعنيه. كما لوحظ سابقًا هنا - أدى اندماج Indie Clickteam الناجح إلى جعل الألعاب تفوق بشكل كبير عدد الألعاب الناجحة التي صنعها Godot.
الألعاب التي يتم نشرها ، وعدد المبيعات على Steam والجوال وعناوين kickstarter التي تحقق هدفها.
يجب أن يكون هذا دليلًا كافيًا على أن الفنانين والمصممين المحترفين يستخدمونه - وليس فقط "الأطفال"

فيما يتعلق بموضوع IDE الجديد الخاص بـ Gdevelop ، أعتقد أنه رائع ، ولكنه ليس ميزة كاملة. كانت إحدى الخطوات الذكية التي قام بها المطور الرئيسي هي نقل بيئة تطوير متكاملة إلى جافا سكريبت - مما يجعلها سهلة الوصول لمطوري C ++ للمساهمة فيها. لقد ساهمت بالفعل في ذلك بإصلاحات صغيرة حتى الآن - فقط للعب والتعلم. سأحاول في نهاية هذا الأسبوع إجراء بعض الخطوات لدمج piskel فيه 😃 - إذا كان كل شيء على ما يرام ، فقد يكون الحصول على محرر بكسل مدمج.
قام المطور الرئيسي مؤخرًا بدمج مساهمة من قبل مطور آخر ، مضيفًا دعمًا لعظام التنين خارج الصندوق. إذا كنت ترغب في ذلك ، فجرّب الإصدار الأحدث من github - وليس الإصدار التجريبي عبر الإنترنت. لديها البضاعة
https://github.com/4ian/GD/releases

ما زلت أحقق تقدمًا بطيئًا في هذا الملحق. تحتاج بعض الأشياء إلى إعادة هيكلة قبل أن أتمكن من المضي قدمًا بها.

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

هذا يبدو مذهلا! شكرا لتطوير / دفع هذا ، blurymind.
لقد أنجزت لعبة gamedev لمدة 23 عامًا أو نحو ذلك ، وجربت كل شيء بشكل أساسي - كل أدوات / محركات الألعاب الشهيرة ، ولغات البرامج ، وما إلى ذلك .. وأنا أفضل أوراق الأحداث في نهاية اليوم لأنها تتيح لي إنهاء الألعاب. :)
إن وجوده في نهج مدرج من أعلى إلى أسفل مقسم بين الشروط والإجراءات يجعله أكثر تنظيماً وإيجازاً من أي نظام آخر. نظرًا لأنني أكثر توجهاً بصريًا ، فإن وجود هيكل صلب عمودي / أفقي يسمح لي بالتدفق عبر البرنامج / الأحداث بسهولة.
البرمجة النصية المرئية الأخرى التي تتطلب وصلات السباغيتي فوضوية للغاية ومشتتة للانتباه - التفاصيل المرئية مبعثرة في جمالية صاخبة تكسر تركيز الأشخاص ذوي العقلية البصرية (يُفترض أن يستهدف نفس الأشخاص البرمجة النصية المرئية).
أوراق الأحداث هي الأفضل بالنسبة لي. لقد أمضيت 23 عامًا ، باستخدام كل شيء - blitzbasic ، و gamesfactory ، و union ، و c ++ ، و javascript ، وما إلى ذلك ، وأنا متأكد من هذا - أنا أحب أوراق الأحداث !!

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

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

bigelodprominentdetail أشكركم على توفير مزيد من ردود الفعل على ما يجعل ورقة الحدث حتى جيدة - وليس فقط بالنسبة لأولئك الذين يتعلمون لcode- ولكن أيضا للمبرمجين أكثر خبرة.

أعتقد أنك على حق تماما. تمامًا مثل prominentdetail ، بدأت في دمج أوراق الأحداث ثم

ألاحظ أيضًا الاتجاهات في أجهزة الصراف الآلي لمجتمع لعبة ورقة الحدث ، والتي يمكن أن يستفيد منها godot حقًا لتوسيع قاعدة المستخدمين الخاصة به:

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

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

في ملاحظة جانبية ، تمكنت من تجميع Piskel ودمجها مع Gdevelop. كان هذا يجعلني مشغولاً في الأسابيع القليلة الماضية. يمكنك تجربته إذا كنت تريد :)
لقد كنت أبحث في كيفية عمل أوراق الأحداث في gdevelop أيضًا

blurymind حسنًا ، دعنا نقول فقط أنني حاولت تجاهل هذا النصين المرئيين .

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

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

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

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

لكن Blueprints أداة على مستوى الصناعة ، لذا فهي تستخدم وقد تجلب سمكة أكبر لـ Godot وهو أمر مهم بالنسبة لـ Godot أيضًا. وقلت ربما لا أعرف الكثير عنها أيضًا.

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

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

إذن ماذا لو لم يتم التوصل إلى حل وسط. شيء ما سيموت. بغض النظر عن ما هو عليه.

أنا شخصياً قد أصوت لصالح Blueprints لأن لدي خبرة سابقة في ذلك ، وأود مقارنة السمكة الأكبر Unreal مع.
ولكن للمقارنة فقط ، حصلت على GDevelop في أقل من 15 دقيقة. GDScript أقل من ساعات قليلة في أيام منفصلة و Blueprint ضعف ذلك من GDScript بالتأكيد.
على الرغم من أنه يظهر أيضًا مستوى خبرتي كمبرمج.

أنا فقط لا أستطيع أن أقرر. انظر هنا.

1. الوحدة: 4011
2. غير واقعي: 316
3. صانع الألعاب: 274
4. البناء: 223
5. جودو: 75
   _List من سقسقة Reduz لعدد الألعاب لكل محرك في Global Jam._

أريد جودو في القمة. لذلك آمل أن يساعد بعض الحب VS في تحقيق ذلك.
لكن Unreal + Godot + GameMaker + Construct لم يفلح بعد. لكنه يجعلها رقم 2 على الأقل.

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

"إن EventSystem يشبه البرمجة باستخدام Scratch إلى مستوى ما. حيث يكون Blueprint فريدًا تمامًا ولكنه أقوى من EventSystem لأن EventSystems تصبح أكثر إرباكًا مع العمق وقابلية أقل للقراءة."

ماذا؟؟ إنه عكس ذلك تمامًا إذا جربت نظام أحداث Construct ، لا سيما تضمين أوراق الأحداث الأخرى واستخدام المجموعات.

سيكون أفضل نظام عقدة دائمًا عبارة عن معكرونة برمجية مقارنةً بنظام حدث متوسط.

bigelod صحيح لا ينبغي أن يقال من هذا القبيل. اعتقدت انه مشابه لقد كتبت هذا التعليق على مدار ساعتين أثناء تعلمي EventSystems. آسف لذلك سوف يصلحها.

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

swarnimarun منذ سنوات عديدة ،

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

الجحيم حتى عند النظر إلى منتديات محرك البرمجة المرئية الأخرى ، يمكنك رؤية ردود الفعل السلبية لأي محرك نظام مخططات جديد:
https://rpgmaker.net/forums/topics/23922/؟post=857285#post857285

الآن في نهاية اليوم لا أرى سببًا لعدم وجود كلا النظامين. يمكنهم العمل معًا - بالطريقة التي يمكن أن تعمل بها المخططات مع عقد gdscript.

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

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

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

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

يمكن أن تستخدم ورقة الحدث gdscript لتعبيراتها وبهذه الطريقة تساعد في الواقع أولئك الذين يأتون من محرك نوع ورقة الأحداث على تعلمها بسرعة كبيرة

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

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

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

يثير prominentdetail نقطة جيدة للغاية.
للإضافة إليها سأقول هذا فقط:
لدى Godot الفرصة ليكون أول محرك ألعاب ثلاثي الأبعاد مناسب لدعم أوراق الأحداث. هذا بحكم التعريف سيرفعه فوق كل محركات ورقة الأحداث الأخرى في الوقت الحالي.
كما ذكرت من قبل ، تمت محاولة ذلك من قبل في كل من دمج Clickteam وفي Construct - كمكونات إضافية ، حتى في صانع الألعاب. وهي فوضى عارمة هناك لأن محرري تلك المحركات لا يمتلكون أي قدرات ثلاثية الأبعاد.

Clickteam Fusion - محرك Firefly:
http://clickstore.clickteam.com/firefly
https://store.steampowered.com/app/267655/Firefly/
يتم انتقاده على Steam - لأنه ملحق عربات التي تجرها الدواب فظيعة

بناء 2 - q3d
https://www.scirra.com/tutorials/9456/building-your-first-3d-game-with-the-q3d-plugin

ما عليك سوى إلقاء نظرة على مشكلة إعداد مشهد ثلاثي الأبعاد بسيط دون الحاجة إلى محرر مشهد ثلاثي الأبعاد
https://youtu.be/VUGsTdBpRCQ؟t=6m17s

يبدو IMHO الهجين طريقة رائعة للحصول على سلبيات كليهما.

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

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

أعتقد أن الأشخاص الذين يخافون من تجربة البرمجة هم على الأرجح الوحيدون الذين قد يحتاجون إليها في وجود GDScript.

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

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

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

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

كيف تختلف أوراق الأحداث عن لغات gdscript / البرمجة النصية؟

للمبتدئين (الأشياء التي تجعلها أكثر جاذبية من البرمجة):

• هناك بعض التمثيل المرئي للمنطق - باستخدام الرموز والألوان وأقل قدر ممكن من النص
• تم توضيح الشروط في العمود الأيسر ، والإجراءات في اليمين - في ترميز كل من الشروط والإجراءات في عمود واحد - مما يجعل من الصعب على البعض التمييز بين الاثنين عند قراءة منطق شخص آخر.
• بدلاً من سلسلة نصية طويلة ، يتم عرض الأساليب على أنها كلمات بسيطة - يتم تجريد علامات بناء الجملة عند الإمكان - إزالة ضجيج بناء الجملة يجعل القراءة أكثر وضوحًا
• يقدم Intelisense / autocompletion للمستخدم واجهة برمجة التطبيقات بالكامل - حتى يتمكنوا من رؤية جميع المحددات أو الحاصلون المتاحون وتصفية ما يريدون - مقلوبًا إلى كيفية عمله في ترميز IDE - حيث يظهر الإكمال التلقائي بعد بدء الكتابة وواجهة برمجة التطبيقات بالكامل لا يزال مخفيًا في وثائق المحرك. كما أن لديها أدلة مرئية للعثور على الأشياء (الرموز). يظهر مباشرة نوع المتغيرات التي تم إرجاعها أو توقعها
• يتيح لك منطق التجميع إنشاء مجلد خاص بك منه بحيث يمكنك تصغيره / إلغاء تصغيره والتنقل فيه. إن القدرة على طي الكتل المنطقية التي قررت أنه يجب أن تكون قابلة للطي أمر رائع جدًا عندما تقوم بتنظيم الكود الخاص بك وترغب في إخفاء أجزاء منه لا تعمل عليها.

للمستخدمين الأكثر خبرة:

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

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

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

لقد انحرفت نوعًا ما عن بعض عناصر جافا سكريبت وأحب أن يجربها الآخرون :) ولكن سأعود إليها

أتفق مع mhilbrunner على أنه يجب أن يكون نظامًا خاصًا به ، ولكن سيكون رائعًا إذا كان من الممكن دمجه مع نظام المخططات - الطريقة التي يمكنك بها دمج gdscript مع المخططات في المشروع

تضمين التغريدة
إذن ، قلت أنك كنت تعمل على مكون إضافي من هذا القبيل؟
ما هو اسم الريبو؟ انها بالفعل على جيثب الخاص بك؟

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

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

الجانب السلبي الوحيد الذي أراه هو أنك تصبح كسولًا عندما يتعين عليك تعلم الكود التقليدي.

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

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

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

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

prominentdetail لجميع المقاصد والأغراض ، يمكن

لقد استخدمت Blueprints بعد ترك الترميز لدمعة كاملة وشعرت أنها طبيعية ومناسبة في غضون دقيقتين. لذلك أعتقد أن معظم الناس سيكونون على ما يرام معها.

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

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

تظل حجتي أن ورقة الأحداث أسهل في التعلم منها
المخططات وأسرع لاقامة.

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

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

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

في يوم الأربعاء ، 30 مايو 2018 ، الساعة 22:59 مساءً ، كتب دافين بيجلو ، [email protected] :

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

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-393333602 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AGMbVT30aPs63RYwxtFqDTHWVqclenRBks5t3xZTgaJpZM4S8wyr
.

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

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

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

swarnimarun هل هناك وحدة نمطية hello world تنشئ واجهة مستخدم جديدة أو تغير القائمة الحالية؟
هل يمكنك أن تنصح بأي دروس تعليمية جيدة حول البدء ساعدتك؟

على أي حال ، أفكر الآن في تغيير بنية gdscript التي ستنشئها قائمة المساعد إلى gdscript المكتوب:
https://github.com/godotengine/godot/pull/19264
ثم يتم تحويل ذلك إلى BBcode الذي يعرض واجهة خلية ورقة الأحداث التفاعلية

لقد صنعت هذا المخطط الانسيابي لشرح كيفية عمله في الوقت الحالي
https://www.draw.io/#Hblurymind٪ 2FGodot-eventSheetPrototype٪ 2Fmaster٪ 2FEventSheetDiagramPlan.xml

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

وأعتقد أنك تستخدم GDScript للقيام بكل البرمجة ، أو أنك تستخدم C ++.
لأنه لا توجد وحدات تسمح لك بعمل أي شيء بشكل افتراضي أو عند البدء. عليك أن تتعلم مما هو موجود بالفعل. واصنع بنفسك.

يجب أن يكون التحويل إلى GDScript مكتوبًا بسيطًا إذا كنت تستخدم GDScript وإذا كنت تستخدم C ++ ، فستكون هناك حاجة إلى القليل من النقل. وبقدر ما أعرف ، يجب دمج العلاقات العامة في أي وقت الآن. تمت مراجعته ويبدو أنه جيد. لم أجربها بعد لكنني متحمس حقًا.

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

وأخيرًا ، إذا كنت تريد المساعدة ، فما عليك سوى مراسلتي على Twitter أو Discord. سأكون حرا لبضعة أيام الآن.

swarnimarun أنا أستخدم gdscript لكتابة الملحق ، هناك بعض الاستخدامات للإشارات الموجودة فيه بالفعل لأشياء مثل تشغيل الأحداث.
نعم ، أستخدم get_method_list () و get_property_list () لعرض قائمة المساعد أيضًا

هل لديك نفس المقبض على تويتر والخلاف؟

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

gdscript المكتوب هو ما ستنشئه القوائم المساعدة لوضع التعبير - إنه أفضل للتحويل إلى كود BB لعرض واجهة المستخدم بتسمية نص منسق

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

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

@ blurymind - عمل ممتاز. لقد بدأت للتو في تعلم C ++ بسبب تحسن الأداء في Godot بالمقارنة مع GDScript (3 إلى 4 مرات أسرع ، اعتمادًا على المقياس الخاص بك - انظر bunnymark ). إذا كان ذلك ممكنًا على الإطلاق ، فإنني أوصي بالذهاب مباشرة إلى الذهب واستخدام C ++ لهذا الغرض ، حتى لو كان ذلك يعني التعلم أثناء العمل - فسيكون الأمر يستحق ذلك. أعطني بضعة أسابيع لأتعرف على C ++ وسأكون مستعدًا للمساعدة أيضًا إذا كنت ترغب في ذلك.

colludium لا تستحق السرعة الأسرع من 3 إلى 4 مرات جهد تعلم C ++. إذا كنت ترغب في تعلم كيفية جعل المزيد من الألعاب المحسّنة ، فتعلم C # بدلاً من ذلك (ستزداد سرعة مع نضوجها في Godot). والآن أيضًا ، بعد ظهور GDScript المكتوب ، ستجعل GDScript تنتظر أسرع من ذي قبل. بالقرب من C # يعتقد.

C ++ هو ألم. ثق بي. المؤشر والمراجع وتجميع الكود ليس سوى ألم. ما لم تكن ترغب في صنع مستقبل كمطور ألعاب لشركة كبيرة أو كنت تدرسها في الكلية أو كنت ذكيًا جدًا لدرجة أنك تعرف GDScript تمامًا أو كنت على مستوى احترافي كمبرمج.

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

blurymind أريد أن أسأل عن إصدار EventSystem الذي تستخدمه كقاعدة أساسية ، لأنني أردت إنشاء نموذج أولي للنظام كوحدة C ++ ، لذا أود أن يكون متزامنًا مع نظامك على الأقل في المستوى الأساسي.

swarnimarun - شكرًا على النصيحة بخصوص: C ++. أنا مجرد مبرمج هواية قادم من JavaScript ، لذا فإن الانتقال إلى الحد الأدنى من الألم / الحد الأقصى من الأداء هو ما أبحث عنه. لم أكن على علم بالتحسينات المخطط لها لجعل GDScript's أسرع بكثير - من الجيد معرفة ذلك. الآن لدي مأزق - C # أو أسهل بكثير لتعلم GDScript ...

colludium دعنا نقول أنه مهما كان ما تجده أسهل ، فإن رؤية خلفيتك لتكون جافا سكريبت ، أوصي باستخدام GDScript لأنه يحتوي أيضًا على كتابة ديناميكية ، ومع الكتابة الثابتة الواردة ، يجب أن يكون الرفيق المثالي.
واسمحوا لي أن أخبرك إذا كنت تعتقد أن C ++ هي لغة يجب أن تتعلمها فقط اذهب وتصفح صفحة Rust vs C ++ في بعض المنتديات.

تضمين التغريدة
هذا هو اختبار الريبو الذي أضفت إليه المشروع
https://github.com/blurymind/Godot-eventSheetPrototype
الجميع أحرار في القيام بطلبات سحب أو تفرع 👍

لا تتردد في البدء في كتابة وحدة c ++. ما لدي وظيفي حتى الآن هو مجرد لبنة البناء الأساسية للواجهة - حاوية الخلية المنطقية.

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

الباقي هو مجرد واجهة ثابتة تم وضعها لأغراض لقطة الشاشة

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

على أي حال ، يرجى مشاركته إذا كان لديك شيء - حتى لو كان أساسيًا. سأحاول تعلم المزيد من لغة C ++ وأنضم إليك في كتابتها كوحدة نمطية :)

تضمين التغريدة شخص يفهم بوضوح أن البرمجة النصية المرئية Godot Engine 3.x غير مجدية (معقدة للغاية بالنسبة للمبتدئين وعديمة الفائدة للخبراء).

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

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

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

تحياتي ، وشكرا لك على عملك الرائع!

XenonCoder لقد

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

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

إنها مثل نصف الهدية ، لأنه بدون المتابعة ، فهي بلا فائدة حقًا.

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

bigelod أتفق معك تمامًا. أنا سعيد لأنك لم تسيء فهم نواياي ، وفهمت تمامًا ما قصدته.

Godot Game Engine رائع بكل بساطة! لديها إمكانات لا تصدق. لصنع ألعاب ثنائية الأبعاد ، إنه رقم 1! لقد جربت لسنوات كل محرك اللعبة وأطر العمل الحالية ، ويمكنني أن أقول بكل تأكيد أن Godot هو مشروع يعد بأشياء عظيمة.

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

نحتاج إلى برامج تعليمية ووثائق عامة وقبل كل شيء نظام مبسط بأسلوب Build 3 و GDevelop و Game Maker Studio 2. في البداية كإضافة لتحقيق ألعاب ثنائية الأبعاد بشكل أساسي ، يتم تحسينه في المستقبل ويتم تنفيذه رسميًا. أدرك أنها ليست مهمة سهلة ، إنها مجرد فكرة لجعل Godot Game Engine الحل الأمثل للمتحمسين والطلاب ومحترفي ألعاب الفيديو.

شكرا لكم جميعا.

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

لقد نشأت مع Klik 'n Play و The Games Factory و Multimedia Fusion ، واستخدم Construct 2 هذه الأيام. تختلف البرمجة النصية المرئية مع أوراق الأحداث تمامًا عن استخدام عقد آلة الدولة على غرار المخططات المتصلة ببعضها البعض ، وبالنسبة للأشخاص الذين اعتادوا على أوراق الأحداث ، فهي الطريقة الأسهل والأكثر فاعلية للبرمجة. يسعدني أن أرحب بطريقة البرمجة النصية في GoDot باستخدام أوراق الأحداث.

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

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

الفكرة هي أنه سيتم كتابة gdscript الذي تم إنشاؤه لورقة الحدث. ستعطي البيانات المكتوبة بيانات سياقية إضافية لورقة الحدث فيما يتعلق بنوع المعلمات المتوقعة.

إذا كان هناك اهتمام بهذا كوحدة c ++ مناسبة أو ملحق gdnative - فكل شخص حر في محاولة تنفيذ ذلك.

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

للأسف لدي وظيفة بدوام كامل تستغرق معظم وقتي في الوقت الحالي :(
آسف للتحديثات البطيئة

للإضافة إلى هذه المناقشة ، أود أن أقدم للجميع هنا مثالًا رائعًا لمحرك البرمجة النصية المرئية باستخدام نهج البرمجة المرئية القائم على اتصالات العقدة والذي يفشل حاليًا في استهدافه الديموغرافي
https://youtu.be/b8GZ21YCh50؟t=4m12s
يشبه إلى حد ما https://www.reddit.com/r/unrealengine/comments/4nt0up/need_help_debugging_this_blueprint/

لاحظ البدائل التي تقدمها Gamesfromscratch

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

ربما مع النص المرئي يمكن الوصول إليها حتى لو شاشات اللمس؟

في الواقع ، تعتبر البرمجة النصية المرئية بنمط ورقة الحدث مناسبة تمامًا للمس
شاشات

في يوم الأربعاء ، 1 أغسطس 2018 06:46 ، كتب Elmapul ، [email protected] :

ربما مع النص المرئي يمكن الوصول إليها حتى لو شاشات اللمس؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-409456475 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AGMbVdqoa3AdMNfiM986iwIpNeqzqjVLks5uMUCvgaJpZM4S8wyr
.

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

انها فكرة عظيمة! لم أفهم هذه المخططات حقًا ، لكن النهج القائم على الحدث معروف جيدًا ، لا سيما في المجتمعات الحديثة ، مثل Warcraft III World Editor.

أمثلة على الشاشات:


تبدو الفئات والقائمة النظيفة بالمشغلات رائعة ، على الأقل بالنسبة لي. من الأسهل إدراكها من الشاشات الموجودة في المنشور الأول.

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

تضمين التغريدة
هذه الصورة أصغر من أن ترى / تقرأ أي شيء

تضمين التغريدة
عذرا ، كان هناك خطأ ما في ذلك. محدث.

Elmapul في حين أن الملحق المفاهيمي الخاص بي لا يمكنه إجراء التعشيش بعد ، فإن ورقة الحدث التي

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

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

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

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

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

من وجهة نظري ، فإن الإشارات في godot هي تمامًا مثل الأحداث الوظيفية المضمنة. ربط الإشارات مرئي بالفعل في godot :)

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

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

أعتقد بشدة أننا يجب أن نبقي الأمر بسيطًا وأن نكون مجمِّعًا لـ gdscript المكتوب ، ولكن إذا لم يكن ذلك ممكنًا أو عمليًا - فقد تكون واجهة برمجة تطبيقات مختلفة. سيكون من المفيد التحقق من كيفية عمل النص المرئي الحالي في godot كتجريد.

إذا كنت تتساءل عن كيفية إنشاء الوظائف المخصصة في الإنشاء ، فإليك رابطًا إلى مستندهم
https://www.scirra.com/tutorials/823/creating-function
:)

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

swarnimarun أشكرك على الوقت الذي

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

Jummit إلا أنك تستطيع تمامًا ، جرب Construct 2. لم يعد منتفخًا أكثر من الكود القياسي.

ويمكن أن تحتوي على جميع وظائف GDscript؟ ثم ماذا ننتظر؟ هيا نحصل على أوراق الأحداث في Godot!

يحتويJummit godot على جميع الوظائف التي تريدها في شكل "عقد"

تشبه "العقد" في godot "السلوكيات" في الإنشاء 2
يشبه سلوك المنصة في الإنشاء 2 عقدة kintematicbody2d أقل قوة :)
ليس عليك كتابة كل شيء من البداية.

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

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

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

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

هذا قبيح مثل f ** k بالنسبة لي. أعني ، نصوص في الفيديو.

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

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

هل هذا المشروع ميت الآن؟

@ Amr512 لا أعتقد أنه مات. هناك بالتأكيد رغبة كبيرة في جلب هذه الوظيفة إلى godot.
حتى أن reduz أبدى بعض الاهتمام في gdevelop مؤخرًا على تويتر
https://twitter.com/reduzio/status/1085206844275081218

على الرغم من أنني لم أعمل على الملحق لفترة من الوقت ، فقد قررت أن أذهب بالفعل وأبدأ في المساهمة في تطوير نفسها - من أجل معرفة المزيد حول كيفية برمجة ورقة الأحداث الخاصة بها - بالإضافة إلى المساعدة في جعلها بديلاً أفضل عن المدفوع والخيارات.
https://github.com/4ian/GDevelop/

بدأت بعض الجامعات في الحصول على gdevelop لتدريس دورات البرمجة
https://github.com/4ian/GDevelop/issues/882

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

blurymind لقد تركت تذكرة على مشروعك (أخطاء في Godot 3.1beta3).
انا احب الفكرة تماما

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

القاعدة = الحدث
ورقة الحدث = مخطط

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

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

ونعم ، السماح للاعبين بإنشاء أوضاع / مهام / تحديات خاصة بهم عبر التعديل هو سبب آخر لاستخدام مثل هذا النظام.

@ Xrayez هل يمكنك مشاركة git repo؟ أعتقد أنك محق في أن تطبيقي دقيق للغاية ، ولكن هذا صحيح بالنسبة لكيفية عمل gdscript و godot's api.
أيضًا بمجرد النظر إلى لقطة الشاشة ، أعتقد أنك تفتقد النقطة - يجب أن تكون عمودين فقط ، وليس ثلاثة. اليسار = الشروط ، اليمين = الإجراءات. كما يجب أن تكون قادرًا على سحب الأحداث وإفلاتها بين الخلايا ، وكذلك سحب وإسقاط الصفوف وتداخلها. لبناء هذا نحتاج إلى استخدام شجرة قابلة للفرز. استمتع باللعب مع gdevelop and build ، سوف تحصل على فكرة أفضل عما يجعل أوراق الأحداث هذه لطيفة للغاية

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

class_name SchemeCondition extends Node

func is_met(object): # override
    return true

class_name SchemeAction extends Node

func perform(object): # override
    pass

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

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

قم ببناء و Gdevelop و Stencyl و Game Maker و Playmaker و Bolt و Fungus for Unity و Blueprints in Unreal و Flow Graph و Schematyc في CryEngine ، إلخ ...

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

لديك حتى أشياء مثل الأحلام تصدر بعض الضوضاء.

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

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

إنه نوع مما أعتقد أنه يمكن أن يعمل بشكل جيد مع godot.

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

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

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

على أي حال ، إذا كانت معرفتي بلغة c ++ أفضل ، كنت سأجربها :) لكنني أعرف جافا سكريبت ، لذا فإن مساهماتي تذهب إلى gdevelop بدلاً من ذلك

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

أنا مبرمج الآن ، وقد بدأت حتى في تطوير المحرك. لكن لا يزال بإمكاني أن أضمن بثقة أوراق الأحداث.

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

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

في الواقع ، السبب الرئيسي الذي جعلني أصلاً ابتعد عن Construct 2 هو ببساطة لأنني أردت الدخول إلى 3D بالفعل. انتهى بي الأمر بتجربة Unity ، و Unreal ، و Godot ، و Amazon Lumberyard ، وانتهى بي الأمر بالذهاب مع Godot إلى حد كبير لمجرد أنه كان من الأسهل فتحه واستخدامه وشعرت عملية الاستيراد بتحسن. ولكن إذا كان لدى Godot نظام نمط ورقة الأحداث ، فمن المحتمل أن أكون قد تعثرت على الفور في Godot. من المؤكد أنه لا يحدث فرقًا بالنسبة لي الآن شخصيًا ، ولكن مرة أخرى ، يتعلق الأمر بجعل Godot ودودًا لغير المبرمجين (أي جزء كبير من مطوري الألعاب الجدد / الطموحين) قدر الإمكان.

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

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

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

لدينا بالفعل عدد قليل جدًا من المشرفين على نظام البرمجة النصية المرئي الحالي. لا أعتقد أن التبديل الكامل سيكتمل أبدًا في حياتنا 🙂

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

لقد بدأت أيضًا بـ Construct 2 ووجدت أن أوراق الأحداث رائعة لحلها 2
مشاكل:

• مثل أي نصوص مرئية ، فإنك تعرض كل الاحتمالات لأي منها
  module / plugin / add-on / function ، هذا مفيد جدًا لتعلم كود جديد.
  تتحول العقد المرئية إلى رمز سباغيتي سريعًا جدًا رغم ذلك (أنا رجل الخلاط ،
  أعرف عن السباغيتي في التركيب والتظليل).
• ورقة الأحداث مثل اختيال ل Rest API ، عليك أن تبدأ مع توثيق جيد
  رمز يملأ القائمة المنسدلة لورقة الأحداث وتحصل على واجهة مستخدم رسومية نظيفة
  طريقة لاستهلاك التعليمات البرمجية الخاصة بك ، يمكنك توسيعها مع الحصول على الفوضى ، و ، ربما
  إنشاء رمز منه (JS from Construct2) ، ومن هنا سؤالي: هل يمكننا
  توليد رمز منه؟

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

أعلم أن ورقة الحدث لا تحل جميع المشكلات ولكن على الأقل يمكنك ترميز 500
أحداث مثل ما تفعله في جدول بيانات دون أن تضيع في المرئيات
الروابط في كل مكان.

يوم الأربعاء 8 أبريل 2020 الساعة 7:44 مساءً كتب Jay [email protected] :

لدينا بالفعل عدد قليل جدًا من المشرفين على البرمجة النصية المرئية الحالية
النظام. لا أعتقد أن التبديل الكامل سيكتمل على الإطلاق في منطقتنا
العمر 🙂

حسنًا ، بافتراض أننا حصلنا على نموذج أولي عملي لورقة الحدث ، ثم الكود
سيتم بالفعل في الغالب ، سيكون الأمر مجرد مسألة ما إذا كنا
تريد التبديل إلى ذلك بدلاً من ذلك ، أليس كذلك؟

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611096608 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAAP6LM4PU6RYLO5NK5IL23RLSZWHANCNFSM4EXTBSVQ
.

لقد بدأت في استخدام Construct 2 وانتقلت في النهاية إلى تطوير المكونات الإضافية باستخدام JavaScript ، لذا فإن أوراق الأحداث لها مكان في قلبي. كانت سهلة وبديهية بالنسبة للمبتدئين ، مع معظم السحر من التصور السهل للطرق المتاحة (الإجراءات والظروف) لكل فئة (البرنامج المساعد). بصراحة ، أصبح GDScript في VSCode جيدًا الآن ، مع التحسس الكامل والإكمال التلقائي مما يجعل الحياة نسيمًا. على الرغم من أنني كنت من أشد المعجبين بهذه الفكرة منذ عامين ، إلا أنني غيرت رأيي الآن. أفضل أن يركز أبطال Godot dev وقتهم وجهدهم على إضافة تحسينات أخرى للمحرك.

هل يمكننا إنشاء رمز منه؟

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

أفضل أن يركز أبطال Godot dev وقتهم وجهدهم على إضافة تحسينات أخرى للمحرك.

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

أنا لست في Gdscript أو Godot بما يكفي أيضًا.
لكن ما طورته كملحق VS Code يسير أيضًا بهذه الطريقة الواسعة
(https://github.com/j2l/blocklight).
فهم الكود بصريًا من خلال اللعب بجزء منه وبصريًا
ربط المتغيرات والنتائج (العقد في معظم النصوص المرئية أو الألوان
في التمديد الخاص بي) هو حجر الزاوية المفقود بالنسبة للكثيرين.
في الواقع ، نحن نفهم الكود عندما ننتهي من تعلمه ، بينما ينبغي لنا ذلك
رؤية المتغيرات وروابط الأجزاء قبل الحصول على كل
الشفرة.
التصميم قبل البرمجة :)

يوم الأربعاء 8 أبريل 2020 الساعة 8:08 مساءً كتب Jay [email protected] :

هل يمكننا إنشاء رمز منه؟

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611108712 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAAP6LN7GFGSBDZ537XXA6DRLS4Q5ANCNFSM4EXTBSVQ
.

أحب فكرة أنه سينشئ ملف Gdscript عادي. سيكون رائعًا حقًا للتعلم

عندما بدأت في صنع الألعاب ، كان نظام الأحداث في Klik & Play طريقة رائعة حقًا بالنسبة لي للحصول على منطق البرمجة ، وما زلت أحب العودة إليه.

أحب فكرة أنه سينشئ ملف Gdscript عادي. سيكون رائعًا حقًا للتعلم

عندما بدأت في صنع الألعاب ، كان نظام الأحداث في Klik & Play طريقة رائعة حقًا بالنسبة لي للحصول على منطق البرمجة ، وما زلت أحب العودة إليه.

أعتقد أن هذه من المحتمل أن تكون واحدة من أعظم مزاياها على نظام السباغيتي الحالي - نظرًا لتصميمه ، فإنه سيسهل على الناس تعلم البرمجة وواجهة برمجة تطبيقات gdscript / godot.

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

سوف يعلمك أمر التنفيذ وكيفية قراءة الكود.

تعرف على ما يفعله التحويل إلى GML في صانع الألعاب
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

blurymind مثيرة للاهتمام حقا! خطرت لي نفس الفكرة وأنا أؤيدها بالكامل.
ما زلت أقوم بعمل ملحقات لـ Clickteam Fusion 2.5 ولكن كل ما أريد إضافته في Fusion موجود في Godot.
كل ما أحتاجه هو وضع طبقة تجريد أخرى (ورقة أحداث) في Godot لتسهيل عملية التطوير.
لم أقرأ الموضوع بالكامل ولكن الاختلاف الرئيسي من وجهة نظري بين البرمجة النصية المرئية في Godot وأوراق الأحداث في محركات الألعاب الأخرى هو أن البرمجة النصية المرئية هي "مجرد" عرض مرئي للكود وأوراق الأحداث هي تجريد الكود مع عرض مبسط. إنه أكثر قابلية للقراءة من قبل الإنسان ، وهو تحليل الأشياء التي تحتاج إلى عدة أسطر من التعليمات البرمجية في سطر واحد ويتم ربط الإشارات / الفتحات تلقائيًا.
في الواقع ، فإن إضافة بعض القوالب (مشاهد محددة مسبقًا) إلى كائن مدمج CF2.5 مجردة مع الاستمرار في استخدام GDScript من شأنه أن يؤدي معظم المهمة بالنسبة لي ، لكن ورقة الأحداث ستجعلني بالتأكيد أكثر كفاءة في Godot مما أفعله في CF2.5 الآن.

blurymind مثيرة للاهتمام حقا! خطرت لي نفس الفكرة وأنا أؤيدها بالكامل.
ما زلت أقوم بعمل ملحقات لـ Clickteam Fusion 2.5 ولكن كل ما أريد إضافته في Fusion موجود في Godot.
كل ما أحتاجه هو وضع طبقة تجريد أخرى (ورقة أحداث) في Godot لتسهيل عملية التطوير.
لم أقرأ الموضوع بالكامل ولكن الاختلاف الرئيسي من وجهة نظري بين البرمجة النصية المرئية في Godot وأوراق الأحداث في محركات الألعاب الأخرى هو أن البرمجة النصية المرئية هي "مجرد" عرض مرئي للكود وأوراق الأحداث هي تجريد الكود مع عرض مبسط. إنه أكثر قابلية للقراءة من قبل الإنسان ، وهو تحليل الأشياء التي تحتاج إلى عدة أسطر من التعليمات البرمجية في سطر واحد ويتم ربط الإشارات / الفتحات تلقائيًا.
في الواقع ، فإن إضافة بعض القوالب (مشاهد محددة مسبقًا) إلى كائن مدمج CF2.5 مجردة مع الاستمرار في استخدام GDScript من شأنه أن يؤدي معظم المهمة بالنسبة لي ، لكن ورقة الأحداث ستجعلني بالتأكيد أكثر كفاءة في Godot مما أفعله في CF2.5 الآن.

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

شكرا لك
أنا أؤيد هذه الفكرة الرائعة
يقولون البناء 2 سيتقاعد!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

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

شكرا لك
أنا أؤيد هذه الفكرة الرائعة
يقولون البناء 2 سيتقاعد!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

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

أشك في أنه يمكننا استخدام أي كود من build2 على godot - فهما قاعدة كود مختلفة تمامًا.

أفضل رهان لبديل مفتوح المصدر هو الانتقال إلى gdevelop
https://github.com/4ian/GDevelop

من المحتمل أن يتم إغلاق بطاقة الإصدار هذه قريبًا ، لذلك إذا كان هناك أي اهتمام بورقة الحدث هذه في godot - فقد يتعين علينا قريبًا نقلها إلى مكان آخر :) (أو gdevelop)

من المحتمل أن يتم إغلاق بطاقة الإصدار هذه قريبًا ، لذلك إذا كان هناك أي اهتمام بورقة الحدث هذه في godot - فقد يتعين علينا قريبًا نقلها إلى مكان آخر :)

لما؟ لماذا ا؟

TheGoklayeh قد يتم إغلاقه لأننا نقوم بترحيل مقترحات الميزات إلى مقترحات godot .

ومع ذلك ، يمكن لـ blurymind تحرير قالب الاقتراح . يمكننا بعد ذلك نقل هذه المسألة إلى مستودع الاقتراحات.

نحتاج حقًا إلى محرك ثلاثي الأبعاد يستخدم أوراق الأحداث.

شكرا لك
أنا أؤيد هذه الفكرة الرائعة
يقولون البناء 2 سيتقاعد!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

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

قد يفسد ذلك أعمالهم. وفريق النقر بالإضافة إلى ذلك.

شكرا لك
أنا أؤيد هذه الفكرة الرائعة
يقولون البناء 2 سيتقاعد!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
أتساءل عما إذا كان من الممكن التفاوض مع مطور الإنشاء 2 من أجل فتح المصدر لنظام الحدث ، واستخدامه في godot ، والوحدة ، إلخ.
إنها خسارة يتم إهمال بناء نظام حدثين على الرفوف غير المستخدمة

قد يفسد ذلك أعمالهم. وفريق النقر بالإضافة إلى ذلك.

إذا قتلهم أي شيء - فإن clickteam سيكون بسبب عدم وجود تحديثات لبرامجهم (آخرها في عام 2019) ، فإن Scirra ستجبر مستخدميها على التبديل إلى ترخيص إيجار البرنامج الذي يجبرهم على الدفع كل عام أو الحصول عليه اقفل. كلتا الشركتين بهما عيوب ولا يتحكم مجتمعهما في ما يحدث للبرنامج. هذا هو المكان الذي يضيء فيه المصدر المفتوح

TheGoklayeh قد يتم إغلاقه لأننا نقوم بترحيل مقترحات الميزات إلى مقترحات godot .

ومع ذلك ، يمكن لـ blurymind تحرير قالب الاقتراح . يمكننا بعد ذلك نقل هذه المسألة إلى مستودع الاقتراحات.

هل يمكن لشخص أن يفعل ذلك بدلا مني؟ :)
لقد فقدت الأمل نوعًا ما في أن تصل هذه الميزة إلى godot محليًا (وليس امتدادًا). استحوذ نهج السباغيتي على مستخدمي ومطوّري godot

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

مع ذلك ، يحتوي هذا الموضوع على الكثير من المناقشات القيمة ، لذا شكرًا على أي حال:

أعتقد أن هذا الاقتراح سخيف للغاية :)
ولكن هل يمكننا إنشاء نظام الحدث ببناء 3 محرك ؟!
أعتقد أن اللعبة يمكنها إنشاء رموز وإرسالها في ملف نصي إلى محرك godot عبر node.js

هذا سخيف .. لكنني أعتقد أن البناء 3 قوي بما يكفي لإنشاء نظام حدث
هذا أفضل من لا شيء في الوقت الحالي

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

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

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

أخطط لأخذ البرمجة النصية المرئية تدريجياً نحو اتجاه يمكن أن يكون فيه واجهات متخصصة لجميع أجزاء المحرك.
تخيل طريقة مختلفة للتحرير لكل نوع من العقدة المعقدة البدائية ، كما هو الحال في Blueprints ، التي تحتوي على عقدة تعبير.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

ولكن فقط لأكون واضحًا ، أنا لست ضد برمجة الأحداث ، أود أن أرى أحدهم يتوصل إلى اقتراح يمكن أن يغطي بعض أنظمة معينة من Godot ، ولماذا وكيف يمكن أن يكون مفيدًا. أنا شخصياً أجد أنه من الجيد جدًا برمجة السلوكيات ، كيف يفعلها GDevelop.
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors

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

على الرغم من أنه يمكن قول الشيء نفسه عن VisualScript والوحدات النمطية فمن المحتمل أن يكون من الأسهل تحقيقه معها. ستكون المشكلة هي التوحيد والاتساق (يستخدم Visual Shader و VisualScript قواعد أكواد مختلفة تمامًا ، فقط التشابه هو عقد واجهة المستخدم المستخدمة).
ومع ذلك ، يمكننا بالتأكيد أن نحاول أن يكون لدينا نظام سيناريو الأحداث كمكوِّن إضافي (C ++ Plugin ، نأمل أن يصبح من السهل القيام به بعد 4.0) يمكن للمجتمع الحفاظ عليه وإضافته إلى Godot عند الحاجة. (أنا متحيز نوعًا ما تجاه محرك ألعاب معياري)

على أي حال هذا فقط سنتان.

لماذا تم تمييز تعليقي على أنه غير موضوع؟ هل هناك من يقوم بمراقبة المجتمع ومن؟ هذا لا يبشر بالخير. هناك تعليقات أخرى بخلاف التعليقات الخاصة بي والتي تخرج عن الموضوع.

prominentdetail هذه هي رسالتي الخاصة بإشعار مكافحة

يُرجى عدم طرح المشكلات دون المساهمة بمعلومات جديدة مهمة. استخدم: +1: زر رد الفعل في المشاركة الأولى بدلاً من ذلك.

(أتمنى أن يكون لدى GitHub طريقة لإرسال رسائل خاصة ، أو على الأقل تحديد سبب مخصص للاختباء ، لذلك لن أضطر إلى إلقاء سلسلة التعليقات بهذا.)

ملاحظة: هذا هو آداب السلوك النموذجي على GitHub ؛ انها ليست خاصة بهذا المستودع.

أنا أؤيد هذا الاقتراح ، لكن لا أعتقد أن أي شخص سيخصص الوقت اللازم لتنفيذه.
لا يتمتع بدعم قوي كافٍ من المطورين الذين يمكنهم فعلاً تحقيق ذلك.

كان يستحق المحاولة وكانت المناقشة ممتعة بالتأكيد :)

blurymind إذا كنت لا تزال تدعم الاقتراح وترغب في قضاء الوقت في كتابته بالتنسيق المطلوب لـ GIPs. الأمر يستحق القيام به IMO.

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

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