Godot: C # كلغة برمجة

إن إضافة المزيد من الميزات إلى GDscript سيكون أفضل طريقة للتعامل مع البرمجة النصية في رأيي

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

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

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

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

إذن ما هي فلسفة جودو؟ لنلقِ نظرة على بعض الحقائق:

• بالمقارنة مع Godot ، فإن كل محرك رئيسي آخر منتفخ.
  حجم تنزيل Godot أصغر من 20 ميجابايت ، "التثبيت" بالكامل هو ملف تنفيذي واحد يقل حجمه عن 50 ميجابايت. من ناحية أخرى ، يحتوي Lumberyard على حجم تنزيل أولي يبلغ حوالي 5.5 جيجابايت ، ويبلغ حجم مجلد التثبيت حاليًا 15.3 جيجابايت. السبب الرئيسي لذلك هو فلسفة أمازون فيما يتعلق بالتبعية. يحتوي هذا التنزيل الأولي على 10.5 جيجابايت من الصور المبنية لـ 42 تبعيات ، وإذا كنت قد عملت مع خدمات الويب من أمازون قبل أن تعرف أن AWS SDK لا تختلف كثيرًا في هذا الجانب ، لذا فهي ليست مسألة ضرورة أو قدرة ، إنها مسألة الاختيار. على سبيل المثال ، بينما يشتمل Lumberyard على boost و Lua ، يحتوي Godot على إصداراته الخاصة من حاويات STL الأكثر أهمية ويستخدم GDScript بدلاً من lua ، مما يحافظ على الحجم صغيرًا ويزيل التبعيات ويجعل الكود أكثر قابلية للقراءة ويمكن الوصول إليه.
• شفرة مصدر Godot سهلة الوصول للغاية.
  يبدأ ذلك باختيار نظام البناء (SCons) الذي يستخدم Python كلغة بناء. تستخدم معظم المشاريع الأخرى أنظمة البناء الحالية مع لغات بناء خاصة أو تكتب نظام بناء خاص بها ، وكلاهما له تأثير سلبي على قابلية قراءة كود البناء.
  شفرة المصدر نفسها أيضًا أعلى من المتوسط ​​في هذا الجانب. استغرق الأمر نفس الوقت تقريبًا لمعرفة كيفية كتابة عقدة Unreal Blueprint واحدة في C ++ حيث استغرق الأمر مني كتابة الكود الخاص بطلب السحب الأول إلى Godot. هذا لا يعني أن كود C ++ الخاص بـ Unreal كان غير قابل للقراءة ، فهو ببساطة ليس نظيفًا مثل Godot لأنه يستخدم المزيد من وحدات الماكرو ويتطلب من المستخدم فهم المزيد من كود مشروع Unreal الافتراضي أكثر من Godot.
• يروج Godot لمبادئ KISS و OO.
  لتوضيح ذلك دعونا نلقي نظرة على بعض الأشياء البسيطة في الوحدة. المفهوم الأول الذي تواجهه في Unity هو مفهوم GameObjects مع المكونات المرفقة. "التركيبة على الميراث" كما يطلق عليها غالبًا (أفضل صياغة مايكل جي ديكهايزر "الاحتواء مقابل الميراث" من "C ++ لمطوري الألعاب" والتي لا تبدو وكأنها صرخة حرب وتعزز التفكير في الموضوع) هي نمط ناجح بسبب المرونة التي يوفرها. لكن هذه المرونة تأتي بتكلفة. إذا كان كل شيء في لعبتك عبارة عن كائن GameObject ، فلا يمكنك حقًا الحصول على إشارة إلى "اللاعب" ، لأنه لا يوجد لاعب ، فهناك فقط كائن GameObject قد يكون مرفقًا أو لا يحتوي على مكون لاعب (أو بالأحرى تلك المكونات العديدة التي تجعل يصل اللاعب).
  رأى مطورو Unity نفس المشكلة ، في بعض الأحيان تريد فقط إنشاء زر ، وليس كائن GameObject مع مكون Button. إذن ما فعلوه هو هذا: لقد سمحوا لك بإنشاء "زر" من خلال واجهة المحرر التي تقوم بالفعل بإنشاء كائن GameObject مع ملحق Button. بالإضافة إلى أنهم قاموا بتوجيه أهم أعضاء GameObject من خلال كل مكون ، بحيث يمكنك الآن استخدام مرجع إلى زر مثلما تستخدم مرجعًا إلى كائن GameObject. يمكنك أن تطلب من الزر موقعه ، ويمكنك أن تطلب منه قائمة بمكوناته - على الرغم من أن الزر هو في الواقع مكون ، وليس الكائن المرتبط به.
  إذن لدينا الآن مزيج من الطريقتين الأكثر شيوعًا لوصف عالم اللعبة - على أساس التركيب وفي الكائنات العادية. ولكن عندما تنظر إلى مشاريع المبتدئين (وحتى بعض المشاريع المتقدمة) ستجد أن Unity يسهل أيضًا الطريقة الثالثة لتفسير عالم اللعبة: البرمجة الإجرائية.
  في الوحدة ، كل كائن هو دائمًا جزء من "مشهد". بخلاف ما ورد في Godot ، يصف هذا المصطلح جزءًا من المستوى الأعلى من اللعبة (إخلاء المسؤولية: الآن لدى Unity مدير SceneManager يجلس فوق المشاهد ، لكن وجهة نظري لا تزال صالحة) ، مما يعني أنه إذا أراد العدو إطلاق النار على اللاعب ، فيمكنه فقط ابحث عن المشهد الحالي للاعب وتفاعل معه. هذه هي الفكرة الأساسية للبرمجة الإجرائية - لديك سلسلة من الأوامر التي تغير حالة البيئة دون اعتبار للملكية. بالطبع ، من الناحية الفنية ، لا تزال البرمجة الموجهة للكائنات ، ولكن نظرًا لأن كل كائن يمكن أن يتوقع أن يكون جزءًا من نفس المشهد ، فقد تم تمكينك لكتابة رمز يتصرف مثل الكود العالمي. على سبيل المثال ، إذا كنت ترغب في إنشاء مثيل لكائن ما ، فكل ما عليك فعله هو استدعاء "Instantiate (templateObject)" وسيتم إنشاء نسخة من templateObject وإضافتها إلى المشهد. ليست هناك حاجة للسؤال عن المشهد الذي يجب إضافة الكائن إليه لأن هناك دائمًا مشهد واحد يمثل كل شيء جزءًا منه حاليًا.
  لذا فإن الوحدة تعزز مزيجًا من التركيب والتفكير الكينوني والبرمجة الإجرائية.

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

إذن كيف يحدث هذا فرقًا فيما يتعلق باختيار لغات البرمجة النصية؟
C # بالنسبة للغات ما تمثله الوحدة بالنسبة للمحركات. لطالما كانت فلسفة C # هي أنه إذا كان من الجيد إضافة بعض الميزات إلى اللغة. ما عليك سوى إلقاء نظرة على قائمة الميزات التي تمت إضافتها مع كل إصدار: https://en.wikipedia.org/wiki/C_Sharp_ (developer_language) #Features_added_in_versions
الآن قد تجادل بأن امتلاك ميزة ليس شيئًا سيئًا ، أليس كذلك؟ ليس عليك استخدامه ، فقط اتركه إذا لم يعجبك. لسوء الحظ ، هذا ليس صحيحًا بالنسبة للغة. مع أهمية الإنترنت اليوم ، لم تعد اللغات أدوات بعد الآن ، إنها ثقافات. عاجلاً أم آجلاً ، سيتعين عليك طلب المساعدة من Google ، وستستخدم وحدات أو كائنات أنشأها الآخرون ، وستستخدم ميزات جديدة أنشأها المجتمع في المحرك ، وستتطلب منك عاجلاً أم آجلاً استخدام ميزات لغة لم تقصدها أبدًا ليستخدم.
أيضًا إذا كنت تعمل في فريق ، فسوف تتعلم تقدير استخدام لغة تروج لأسلوب تشفير مشترك ولا تقدم لك عشرات الطرق لكتابة نفس الكود.

الآن قد تتساءل عما إذا كنت أقصد أن أقول إن اللغة ذات الميزات الأقل تكون دائمًا أفضل من لغة بها ميزات أكثر. بالطبع هذا ليس هو الحال. لنقارن كيف حلّت Java المشكلة.
يتيح لك C # كتابة رمز غير مُدار. ما عليك سوى استخدام الكلمة الأساسية المناسبة ويمكنك استخدامها مباشرة في نفس الملف. كما يسمح لك بكتابة كود وظيفي باستخدام LINQ ، والذي يقرأ مثل كود SQL ويتصرف مثل كود وظيفي. لكي تفهم تمامًا ما هو الملف الواحد ، قد تحتاج إلى معرفة الكثير عن نماذج البرمجة.
إذا كنت تكتب Java ، فيمكنك استخدام البرمجة الوظيفية أيضًا ، ما عليك سوى كتابتها في ملف منفصل ، واستخدام مترجم مختلف وتسميته "برمجة Clojure". إذا كنت تفضل الجمع بين البرمجة الشيئية والوظيفية ، فيمكنك تسميتها "برمجة Scala". الجزء المهم هو أنك لا تزال تكتب رمزًا لـ JVM يمكنه التفاعل بسهولة مع الكود من لغات JVM الأخرى.
تتمتع لغات .NET بنفس الإمكانية ، فهي غير مستخدمة في C # -philosophy. كان من الممكن أيضًا أن يقرروا التمسك بنموذج أو اثنين من نماذج البرمجة في C # وإنشاء لغة جديدة لإضافة نماذج جديدة ، ولكن بدلاً من ذلك ذهبوا مع "لغة واحدة لغزوهم جميعًا" - وهو أمر جيد تمامًا ، من الرائع أن يكون لديك لغة من هذا القبيل. يجب أن تكون على دراية بهذه الفلسفة والخيارات التي لديك كمبرمج.

قصة قصيرة طويلة: من بين جميع اللغات التي لدينا ، أعتقد أن لغة C # هي الأسوأ لـ Godot. إنها مناسبة بشكل طبيعي للوحدة ، ولكن إذا كانت لديك كل هذه الخيارات ، فلماذا تختار لغة تعزز خلط النماذج ومطابقتها في محرك يعزز مبادئ OO النظيفة وبرمجة KISS في كل جزء آخر من أجزائه؟

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

تضمين التغريدة

إن إضافة المزيد من الميزات إلى GDscript سيكون أفضل طريقة للتعامل مع البرمجة النصية في رأيي

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

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

ولكن يمكن استخدام Godot بالفعل من C ++ ، لذلك لن يتغير شيء حقًا (بشرط الاحتفاظ بـ GDScript) باستثناء الترميز في C ++ سيكون أسهل بالنسبة لأولئك الذين يرغبون في القيام بذلك (تتطلب وحدات الكتابة حاليًا تجميع كل Godot ، وهي ليست متكاملة في سير العمل).

Warlaan تحليل لطيف. إذا قرأت رسالتي ، فأنا أختلف أيضًا مع C # كونها اختيارًا جيدًا لـ Godot ، ولهذا السبب اقترحت توسيع إمكانيات C ++ الموجودة بالفعل لتمكين استخدامها كلغة برمجة نصية ، مع بقاء GDScript هي اللغة الافتراضية لمعظم المستخدمين.

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

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

@ paper-pauper فهمت أننا في نفس الجانب. عندما كتبت "إذا كنت تعتقد أن C # سيكون إضافة لطيفة" كنت أعني "أنت ، القارئ المجهول" ، وليس أنت شخصيًا. ؛-)
ونعم ، فإن أي لغة برمجة نصية جديدة سوف تستنزف الانتباه عن GDScript. أشك في أن المجتمع سيهتم بأكثر من لغة ، عاجلاً أم آجلاً ، ستكون بعض الميزات غير متوفرة أو معطلة من أي منهما وربما حتى إلى النقطة التي يتم فيها إسقاط إحدى اللغات.

أوافق أيضًا على أن المشكلات الحقيقية الوحيدة هنا هي أوقات ترجمة C ++ وأداء GDScript.
إن الحجة القائلة بأن الناس يعرفون بالفعل C # هي مجرد فكرة خاطئة بشكل واضح. لقد عملت بشكل احترافي مع C # منذ حوالي 4 سنوات (أعمل بشكل أساسي مع C ++ و SQL) والشيء الوحيد الذي تعلمته في ذلك الوقت هو أنني على الأرجح لن أكون قادرًا على القول إنني أعرف حقًا هذه اللغة. بعد كل شيء مع C # 6 والاقتراحات الخاصة بـ 7 ، لا يزال عدد الميزات في تزايد.
لذلك عندما نتحدث عن "معرفة C #" كل ما يمكن أن نشير إليه في الواقع هو معرفة التركيب الأساسي الذي يجب أن يتمكن حتى أسوأ المبتدئين من إعادة التعلم في غضون أيام قليلة. لقد ألقيت مؤخرًا محاضرة حول محركات الألعاب المختلفة لفئة من مصممي الألعاب الذين كانوا يستخدمون Unity حصريًا من قبل ولم يعلق أي منهم بشكل سيء على بناء جملة GDScript بينما في الواقع العديد من الذين تخلوا عن البرمجة أصبحوا الآن متحمسين مرة أخرى.

لذا ، نعم ، الحل الذي يسرع GDScript ويجعل C ++ أقل تعقيدًا في التجميع والاستخدام سيكون هو المفضل لدي أيضًا.

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

لهذا السبب وحده ، أنا متشكك للغاية بشأن المزايا العملية التي يمكن أن تقدمها C #. هم لطيفون في العديد من السياقات ، ليس فقط تطوير اللعبة. إلى جانب ذلك ، تقدم C ++ 1x بالفعل العديد من هذه الأشياء (بما في ذلك الاستدلال على الكتابة ، والمكررات وبعض الأدوات الوظيفية الأساسية) دون أي تكاليف إضافية.

أيضًا ، من الممكن أن تؤدي النفقات العامة التي يجلبها CLR (أو حتى JVM) إلى جعل Godot يؤدي _الأسوأ _ ، على الرغم من أنني أرى بعض المزايا في استخدام جامع القمامة في JVM (هل يعرف أي شخص المزيد عن إدارة ذاكرة Godot)؟

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

بدون الحاجة إلى تنفيذ C ++ JIT عبر LLVM ، هناك حل يعمل على كود أصلي ولا يتطلب أي عبث بمصادر Godot: الارتباط الديناميكي.

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

يجب أن يكون هذا سهلاً للغاية (عبر libdl؟) ولكن بقدر ما فهمت لم يتم ذلك بسبب مخاوف عبر الأنظمة الأساسية.

أيضًا ، هناك فكرة تجميع GDScript إلى C ++ ، تمامًا مثلما تفعل ENIGMA مع لغتها. هذا ليس بالأمر السهل ، لكن من الواضح أنه يقدم أفضل أداء.

هل يعرف أي شخص المزيد عن إدارة ذاكرة جودو؟

من المستندات :

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

فقط أن نلاحظ ...

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

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

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

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

تضمين التغريدة

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

لا أعتقد أنه توجد لغات جادة تعمل مثل BASIC بعد الآن! :)

مرحبا!
هنا تاريخ GDScript:
////////////////////////////
تاريخ
في البداية ، تم تصميم Godot لدعم لغات البرمجة النصية المتعددة (هذه القدرة لا تزال موجودة حتى اليوم). ومع ذلك ، فقط GDScript قيد الاستخدام الآن. هناك القليل من التاريخ وراء هذا.

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

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

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

أخيرًا ، تمت كتابة GDScript كحل مخصص. انتهى الأمر بأن تكون اللغة والمترجم الفوري أصغر من رمز الربط نفسه لـ Lua و Squirrel ، وكذلك وظيفتهما. مع مرور الوقت ، أثبت وجود لغة مدمجة أنه ميزة كبيرة
//////////////////////////

في رأيي ، يمكن أن يكون c ++ هو الأفضل. هناك بعض الحلول مثل:
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
يمكن حتى أن يكون البرنامج النصي الملائكي عادةً مثل وقت تشغيل مُجمَّع.
في البرمجة النصية ، أحب بايثون لأنني دائمًا أحب الحلول التي تجمع بين الألعاب والمحاكاة العلمية (يوجد في Python العديد من المكتبات العلمية). لذلك أشتكي! في قضية أخرى لماذا يمتلك godot مكتبة فيزيائية خاصة به: https://github.com/godotengine/godot/issues/4217
توجد بعض المشكلات حول لغات مثل C #: https://github.com/godotengine/godot/issues/2790

اكتشاف رائع ، @ alabd14313 - من شأنه أن يحل معظم المشكلات تقريبًا ، مع ترك GDScript بمفرده.

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

يبدو أن المؤلفين يعرفون أشياءهم ، لأنهم أدرجوا في هذه الصفحة معظم البدائل لنهجهم (بما في ذلك النهج الذي ذكرته ، LLVM JIT).

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

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

Warlaan ماذا سيحدث إذا أرسل عنوان URL هذا إلى مجموعة Facebook؟ :)

الرجاء تغيير العنوان إلى شيء مثل "C ++ كلغة برمجة".
يحتوي C ++ 17 على المزيد من الميزات:
http://blog.mattnewport.com/why-c17-is-the-new-programming-language-for-games-i-want/
أنا معجب بمطوري godot وأشكرهم على أعمالهم. لكني أقاوم مكتبات Box2D / LiquidFun / Bullet. بهذه الطريقة يمكن للمطورين التركيز على خطوط الأنابيب ، وليس على مكونات مثل الفيزياء. باستخدام C ++ ، يمكنهم التركيز على الأداء ، وليس الحفاظ على gdscript وتحديثه. من الناحية النظرية ، يمكن لـ RCCPP تنفيذ بعض الميزات الجديدة مثل وضع الأداة بطريقة أفضل. ربما...

ذكر reduz منذ بضعة أشهر أنه يريد تنفيذ البرمجة النصية المرئية ، شيء مثل المخططات غير الواقعية. باستخدام RCCPP ، يمكن تنفيذ سير العمل بين C ++ (للمبرمجين) و Visualscripting (لمصممي المستوى والفنانين) مثل:
مقدمة في برمجة C ++ في UE4
C ++ والمخططات
لذلك في المجموعة ، يمكن للمبرمجين تطوير فصول تخطيط جديدة للفنانين والفنانين يستخدمونها بدلاً من الترميز المباشر.

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

@ alabd14313 أود تغيير العنوان ولكن ربما يكون من الأفضل إنشاء قضية منفصلة والاحتفاظ بها من أجل الأجيال القادمة بحيث يمكن ربطها عندما يقترح شخص ما C # (كما هو الحال غالبًا).

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

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

تعد الرسوم البيانية للتدفق مفيدة إلى حد ما عندما يتعلق الأمر بالتظليل / المواد ، حيث يمكن عرض النتائج الوسيطة ، ولكن حتى هناك يعاني النظام بشكل كبير من حقيقة أن المعادلة القصيرة مثل
تعويم س = (أب) * (أ + ب) / (1- (أ + ب))
يملأ الشاشة بأكملها بسهولة عندما يتم ذلك كرسم بياني ، لأن كل عملية ضرب أو مجموع أو فرق هي عقدة ذات مدخلين ومخرج. هذا ما لا يقل عن 10 عقد للصيغة أعلاه ، وإذا كنت لا تريد التسبب في فوضى في الاتصالات ، فسيتعين عليك تكرار العقدتين a و b.

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

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

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

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

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

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

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

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

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

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

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

ميزة أخرى مفيدة لـ C ++ هي الكتابة بشكل ثابت. يمكن لمنشآت "auto" و "رفض النوع" اكتشاف نوع الكائن. يمكن أن يكون إكمال المحرر والكود أسهل. بدلاً من التركيز على محرر الكود الداخلي ، يمكننا استخدام IDE خارجي آخر. في الوقت الحالي ، أعتقد أن كل من codelite و qtcreator يتمتعان بوضع أفضل في إكمال الكود. تواجه الكودات البرمجية بعض المشاكل مع c ++ 11 kewords. يحتوي eclipse-cdt أيضًا على إكمال كود جيد. يعد البرنامج المساعد لـ qtcreator فكرة جيدة (مثل الاستوديو غير الواقعي المرئي و Unity-Monodevelop). يمكن التعرف على IDE الخارجي من خلال مسار النظام في إعدادات godot (مثل / use / bin / qtcreator) ، لا حاجة إلى تجميعها وتعبئتها باستخدام godot (على عكس حزمة Unity التي بنيت في monodevelop).
هناك أدوات أخرى مثل cppcheck و valgrind تحتوي على مكونات إضافية في qtcreator.
إذا كنت ترغب في الحصول على معاينة لما هو RCCPP:
تجريبي

أرغب في رؤية لغة برمجة نصية تستند إلى C ++ لـ Godot ، لكن تنفيذ جميع ميزات C ++ سيكون مرهقًا مثل برمجة القوالب. يجب أن يكون هناك بعض القيود على هذا النوع من لغة البرنامج النصي (STL) ويجب عدم استخدام القوالب. كما يمكن أن يتسبب RTTI في حدوث مشكلات في الأداء.

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

3 سنتات بلدي. (اه ... انتهى الأمر 20 ، لكن فليكن ...)

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

لديها كل القطع المطلوبة.

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

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

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

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

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

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

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

البرمجة النصية المرئية؟
أوه. يمكن أن يجبرنا المبرمجين على تغيير طريقة التفكير "قليلاً" بطريقة غير عادية ، بالإضافة إلى أنني لا أعتقد أنه يمكن أن يكون مرنًا وقابل للقراءة مثل الكود العادي.
تخيل أنك تقوم بالترميز ولديك سطر واحد بسيط مثل هذا (abc / def) * ghi
ثم الطريقة السريعة ، كالعادة (؟) لحفظ الكتابة ، يمكنك تحديد جزء من شيء ما ، ولصقه هنا ، ثم قصه ، ولصقه مرة أخرى وفي غضون 5 ثوانٍ وضغطات المفاتيح ، ينتهي الأمر بـ "بسيط" (لأنك تعرف ما يفعله) خط واحد مثل ((((abc / def + ((abc / def) _ghi ^ 4)) _ ghi) + (abc / def_ (100)) _ ghi) + abc)
من الشائع ، ربما يفعل الكثير منا ذلك بهذه الطريقة بطريقة فائقة السرعة.
الآن تخيل القيام بذلك بطريقة مرئية ...
قد يستغرق الأمر شاشة كاملة ، والكثير من أعمال الماوس ، ولن تبدو سهلة القراءة كما ينبغي.
(بالطبع ، مثل هذه البطانات أيضًا لا تبدو سهلة بعد عام ولكن هذا ما هي التعليقات من أجله)

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

إذن لمن ستكون البرمجة النصية المرئية حقًا؟
لجعل حياة المبرمجين أكثر صعوبة أو للحد من مستوى godot - محرك "للألعاب البسيطة" للمبتدئين؟

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

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

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

RebelliousX حتى مع RTTI ، سيظل أداء C ++ أفضل بكثير من GDScript. على الرغم من صحة أن القوالب قد تكون مشكلة.

الحل الذي اقترحه reduz في # 3936 سيجعل الترميز في C ++ تافهًا إلى حد ما - ما عليك سوى القيام بذلك باستخدام المحرر والمجمع المختار والرابط مقابل واجهة برمجة تطبيقات Godot. إذا تم تنفيذ ذلك ، حتى لو كانت البرمجة النصية في C ++ لطيفة ، فلن تختلف كثيرًا عن كتابة التعليمات البرمجية في C ++ ثم استدعائها من GDScript ، من حيث الأداء. باختصار ، أعتقد أن التركيز على # 3936 (وهو حل بسيط) سيحسن بشكل كبير:

• الأداء (نظرًا لأن كتابة الأجزاء في C ++ ستكون سهلة للغاية)
• توافر مكتبات الطرف الثالث (حيث يمكن توزيع الأغلفة بسهولة أكبر ، ولكن ليس بنفس السهولة # 3943)
• قاعدة المستخدمين والمساهمين (العديد من مبرمجي C ++ سيتبنون Godot)

ثم يمكن التركيز على الكتابة الثابتة في GDScript وتحسين المترجم الفوري (عبر JIT أو عن طريق تجميع GDScript إلى C ++) ، ولكن هذا يمكن أن يأتي لاحقًا إذا أصبحت وحدات الكتابة أسهل.

أريد فقط أن أذكر بضع نقاط تسللت إلى هذه المناقشة ولكن لم تتم معالجتها بعد:

• يتحدث البعض منا عن تحسين النظام الحالي (GDScript كلغة برمجة نصية ، C ++ كلغة خلفية) من خلال تسهيل تطوير C ++ وزيادة أداء GDScript. يتحدث آخرون عن استخدام C ++ (أو Java / C # / ...) كلغة برمجة نصية. قد يبدو أنه لا يوجد فرق حقيقي بين تمكين التطوير السريع لـ C ++ وجعلها لغة برمجة نصية ، لكنني سأشرح بكل سرور كيف اختبرت ولاحظت التأثير السلبي للغات البرمجة النصية القوية على جودة تصميم اللعبة. وما لم يصبح هذا هو موضوع المناقشة ، سأفعل ذلك بكل سرور في المنتديات أو في مكان آخر حيث لا يتم اختطاف هذا الموضوع.
• RebelliousX : عندما تتحدث عن "مساحة الأسماء المتغيرة" و "البرامج النصية الكبيرة" و "مشاركة المتغيرات بين الوظائف" يبدو كثيرًا أنك لم تفهم تمامًا طبيعة GDScript الموجهة للكائنات (بلا إهانة). كل ملف GDScript عبارة عن فئة ، لذلك يجب أن يحدث تضارب الأسماء بين المتغيرات (الأعضاء) تمامًا كما هو الحال في أي لغة أخرى موجهة للكائنات. أنت لا تشارك المتغيرات بين البرامج النصية ، فأنت تكتب العديد من الوظائف التي يمكنها الوصول إلى حالة الكائن الشامل.

Warlaan حول النقطة الأولى ، أعتقد أنه يمكنك النشر هنا ، لأنها مرتبطة بالموضوع.

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

أنا أحب C # ، لكني أرى إيجابيات وسلبيات.

الايجابيات:

• دعم جيد للأدوات (دعنا نواجه الأمر ، هل يمكنك كتابة التعليمات البرمجية في C # بدون Visual Studio أو MonoDevelop؟)
• مناسبة للمشاريع الكبيرة
• تستخدم على نطاق واسع وناضجة ، وهناك الكثير من خيوط الدعم على الإنترنت.
• أداء جيد ، والمفاضلة بين C ++ ولغات البرمجة النصية أثناء العمل عبر الأنظمة الأساسية
• من السهل نسبيًا الارتباط بـ C ++

سلبيات:

• جمع القمامة: تحتاج مشاريع الألعاب واسعة النطاق أيضًا إلى تنفيذ استراتيجيات التخصيص لمنع حدوث ركلات GC في كثير من الأحيان ، وقد يكون هذا أمرًا سيئًا
• ليست متكاملة مثل GDScript (إكمال مسار العقدة؟ متغيرات أعضاء البرنامج النصي على العقد؟ نموذج تخصيص الذاكرة؟)
• وقت التشغيل ثقيل ، وإطار عمل .NET أكثر. كما هو الحال في الوحدة ، يجب إعادة تعيين المكتبات القياسية إلى مكتبات Godot.
• ليس أفضل ما يناسب البرمجة النصية الفعلية ، بمعنى إنجاز الأشياء بسرعة وقذرة. C # مطول وتقييد أكثر من GDScript.
• لا توجد إرشادات بعد بشأن تطوير Godot. اللغة عامة ويمكنها القيام بالعديد من الأشياء ، وكما قال Warlaan ، فإن للمطورين ثقافات مختلفة (يمكنك الحصول على مبرمج WPF يجرب Godot ويتساءل عن سبب عدم وجود طريقة MVVM لإنشاء واجهات المستخدم الرسومية: p)

ينطبق معظم هذا أيضًا على Java.
ربما نسيت أشياء أخرى لأن الوقت متأخر هنا.

حسنًا ، هذه هي تجربتي فيما يتعلق بلغات البرمجة النصية الغنية بالميزات. النقص الكامل في لغة البرمجة النصية اعتمادًا على تعريفك لـ "لغة البرمجة النصية". سأحاول أن أجعلها قصيرة. ؛-)

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

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

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

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

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

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

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

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

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

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

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

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

لدى Godot بشكل عام قيود أكثر مما نعتقد. لا يمكنك عمل أحاديات منفردة من النوع "c-static-style" أو متغيرات عامة لسبب: تسرب الذاكرة وملاءمة مؤشر الترابط. GDScript ليس مميزًا مثل Python لسبب: التركيز على مهام تطوير اللعبة والأداء. نظام المشهد أيضًا موجه للكائنات لسبب ما: يمكنك إنشاء "مربعات" مستقلة يمكن اختبارها وإعادة استخدامها :)

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

using GodotEngine;

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

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

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

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

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

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

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

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

}

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

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

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

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

لا أعتقد أنه من العدل أن نتوقع أن يكون جودو تلاعبًا بالوحدة - فمن الواضح أن جودو لديه تصميم أفضل وبقدر ما أعرف ، أداء أفضل. لكن بعض الناس يعتقدون أن GDScript ليس مناسبًا للتطوير "الجاد" ولن يكون أبدًا لأنه وقت تشغيل مخصص ، على الرغم من حقيقة أن الإصدار القديم من Mono الذي تستخدمه Unity هو أيضًا بطريقة "مخصصة" وقت التشغيل. وإلى جانب ذلك ، عندما تكتب C # في Unity ، فأنت تكتب رمزًا يعمل فقط في Unity في معظم الأحيان وتتبع أنماط تصميمها ، لذلك يمكنك أيضًا استخدام لغة أخرى.

أعتقد أن هؤلاء الأشخاص الذين يريدون C # مخطئون ، ولكن الحل الوسط الجيد في رأيي هو تقديم:

1) أداء أفضل (كتابة ثابتة ، ربما JIT)
2) دعم أفضل لمكتبات الطرف الثالث (عبر FFI وتكامل C ++ أسهل)

لـ GDScript. يمكن القيام بالباقي في C ++ ، بما في ذلك وحدات الكتابة التي تنفذ لغات البرمجة النصية الأخرى (والتي لا تحتاج إلى أن تكون الطرف الأول - يمكن للجميع كتابة وحدة C # ، إذا أرادوا).

Zylann لا أرى أي فائدة في كتابة هذا الكود بدلاً من C ++ المكافئ ، بصراحة ، سيكون للكود C ++ أداء أفضل.

@ paper-pauper ميزة كتابة هذا الرمز هي نفسها GDScript: لا تحتاج إلى إعادة ترجمة المحرك لكل منصة تريد التصدير إليها ، و ... حسنًا ، يمكنك اختيار اللغة (والأداء هو ليست النقطة الوحيدة ، كما أشرت سابقًا). أوافق على أن تجربة GDScript حاليًا متفوقة ، وأن C ++ هي الخيار الأفضل للحصول على أداء خالص. ولكن ، هناك أشخاص لا يريدون فعل ++ C ، مهما كانت نفعها.
لست مهتمًا شخصيًا بـ Godot + C # ، فقط أقوم بتقييم ما يحدث إذا أضفته إلى Godot. وهو ليس بهذه الخطورة: ص

بعد قراءة الكتاب الرائع Game Scripting Mastery (لا يمكنك العثور على العديد من الكتب حول هذا الموضوع ، باستثناء كتاب غير الألعاب حول المترجمين Red Dragon). استنتاجي هو أن GDscript مناسب ، ومن السهل جدًا الاستمرار في إضافة ميزات إلى لغة برمجة تجعلها تفقد قوتها. أهم شيء هو تطبيق لغة نصية غير متضخمة وعمومية قدر الإمكان لجعلها مناسبة لمشاريع مختلفة. من نفس الكتاب يقول أن Unreal يستخدم C ++ مع LLVM.

فكرة أخرى قد تكون خفيفة الوزن أكثر من تنفيذ وقت تشغيل منفصل: ماذا عن تكييف مترجم مثل TypeScript (وهو مشابه جدًا لـ C # ، بدون وقت التشغيل) لإصدار GDScript بدلاً من JavaScript؟ لا يجب تضمين هذا في Godot ، في الواقع قد يكون وحدة تابعة لجهة خارجية. سيقدم على الأقل كتابة ثابتة (في وقت الترجمة) وعددًا من المكتبات ، بنفس أداء GDScript (لأنه سيكون GDScript).

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

ما زلت أعتقد أن الفكرة الأفضل هي الحصول على إصدار ثابت من GDScript يمكن أن يلجأ بسهولة أكبر على JIT ولا يزال وثيق الصلة بالمحرك ومع GDScript الحالي نفسه.

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

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

تضمين التغريدة

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

أوه ، أوافق 100٪ - في الحقيقة لقد عبرت عن وجهة نظر مماثلة في # 3936. كنت أرميها هناك فقط لأننا ذكرنا وقت تشغيل C # كعيب :)

بالنسبة لي ، نموذج C # النموذجي من Zylann جميل ، سأنتقل من Unity الآن إذا كان ذلك متاحًا - لا يتعلق الأمر بالأداء العالي لـ C ++ أو `` سهولة '' GDScript ، إنه يتعلق بالراحة.

ما زلت جديدًا جدًا على Godot ولم تتح لي فرصة عمل لعبة اختبار حتى الآن ، لذا قد لا تجدون رأيي صحيحًا يا رفاق ، ولكن بالنسبة لي ، فإن GDScript هي أكبر عقبة ، وليس في كيفية عملها مع Nodes والمشاهد - أفهم ذلك (وهو أنيق جدًا!).

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

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

هذا بالطبع ، فقط سنتان من عدة ساعات مع Godot - لا تتردد في عدم الموافقة (وأنا متأكد من أن معظمكم سيفعل ذلك).

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

@ بيكل :

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

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

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

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

Pikl بادئ ذي بدء ، شكرًا على تقديم الحجة الأولى لصالح C #. الآن اسمحوا لي أن أشرح لماذا أعتقد أن رأيك غير صالح. ؛-P

دعنا نلقي نظرة فاحصة على بداية مثال الكود بواسطة Zylann:

    using GodotEngine;

    public class Spikeball : RigidBody2D {

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

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

بعد ذلك لدينا
public class Spikeball : RigidBody2D {
كل شيء في GDScript متاح للجميع فلماذا نذكره؟
class Spikeball : RigidBody2D {
يحتوي كل ملف GDScript على فئة تحمل نفس اسم البرنامج النصي. هذا ليس مجرد اصطلاح ترميز كما هو الحال في اللغات الأخرى ، يتم تعريفه على هذا النحو ، فأين الهدف من تكرار اسم الفصل؟
: RigidBody2D {
الآن بما أن: هي "الكلمة الأساسية" الوحيدة ذات المعنى في هذا السطر ، فلنستبدلها بشيء أكثر قابلية للقراءة.
extends RigidBody2D {
سيستخدم أي مبرمج لديه القليل من الخبرة المسافة البادئة لتمييز المناطق المختلفة من الكود. هذا يعني أنه يمكن التعرف على الكود الموجود داخل الفصل من خلال الأقواس المحيطة والمسافة البادئة ، ولهذا السبب قرر مطورو Python جعل المسافة البادئة إلزامية والتخلص من الأقواس الزائدة عن الحاجة الآن.
في حالتنا هذه ليست المسافة البادئة ضرورية حتى على مستوى الفصل لأن كل ملف نصي يتم تعريفه على أنه فئة واحدة (إلا إذا كنت تستخدم الفئات الفرعية التي تم تمييزها بمسافة بادئة).
extends RigidBody2D

بعد ذلك لدينا خطوط التصدير.

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

تشير الأحرف [] إلى السمات المحددة في فئات تحمل نفس الاسم ، وهي آلية غير موجودة في Godot ، لذا فهي تستخدم الكلمات الرئيسية بدلاً من ذلك.

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

مرة أخرى ، كل شيء علني:

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

ولست بحاجة إلى تحديد نوع البيانات.

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

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

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

إذن ، الفرق بين كود C # هذا

    using GodotEngine;

    public class Spikeball : RigidBody2D {

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

وهذا كود GDScript

extends RigidBody2D

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

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

قادمًا من خلفية C ++ / C # / TorqueScript ، يجب أن أقول إن نموذج Godot يستغرق بضعة أيام لتعتاد عليه ولكن بمجرد "نقرات" بساطته ، يمكنك الانتقال من الفكرة إلى التنفيذ بأسرع ما يمكنك الكتابة.

vnen :

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

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

نحاول الآن إنشاء دليل Godot لمستخدمي Unity

ربما يمكنني المساعدة في ذلك؟ لقد كنت أستخدم Unity لعدة سنوات وأعرف الشيء جيدًا مقارنة بأي محرك آخر - سأكون فأر مختبر جيد لهذا الدليل.

Warlaan :

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

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

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

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

فكرة لاحقة:
هل يمكن استخدام لغة ++ C فقط في Godot؟ أعتقد بصدق أنني أفضل تعلم C ++ واستخدامه عبر GDScript.

ربما يمكنني المساعدة في ذلك؟ لقد كنت أستخدم Unity لعدة سنوات وأعرف الشيء جيدًا مقارنة بأي محرك آخر - سأكون فأر مختبر جيد لهذا الدليل.

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

neikeq شكرا ، انتهى!

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

أنت بحاجة إلى using نظرًا لوجود مساحات أسماء لتجنب تضارب الأسماء مع الكثير من الفئات (وهو ما يحدث لي بالفعل في مشروع اللعبة الخاص بي).
أنت بحاجة إلى public لأن هناك فكرة عن التغليف لمنع أخطاء المبرمج بمرور الوقت.
لديك [SomeClass] لأنه يمكننا توسيع التعليقات التوضيحية المضمنة لتناسب احتياجات المشروع المختلفة وتحسين الأدوات.
أما بالنسبة للأقواس ... لا أرى أي ميزة إلا في تحديد النطاقات.

هذه الميزات هنا لسبب ما. من بينها ، أود أن أقول قابلية التوسع. هل يمكنك تطوير لعبة ثلاثية الأبعاد ضخمة متعددة المنصات مع جميع قواعد التعليمات البرمجية في GDScript؟ كذلك يمكنك. لكن الكثير من المستخدمين سيفضلون C ++ أو C # أو Java ، بسبب المحترفين الذين أدرجتهم (وأنا أتحدث فقط عن اللغة ، وليس الإطار).

لكن في الوقت نفسه ، لا يوجد مشروع لعبة "ضخم" أعرف أنه تم تطويره باستخدام Godot ، لذا لا توجد أمثلة كثيرة: p
أيضًا ، أرى بعض الميزات السيئة في C # (تحذير: رأي شخصي في المستقبل):

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

أوه. لم أذكر preload() . هذا لا يمكن أن يصل إلى C # / Java ، إلا إذا كنت تعتمد على حيل المترجم: p

هل بدأ أي شخص بالفعل في تجربة وحدة أحادية؟

لإضافة رأيي المتواضع ، كشخص يعمل كمطور لـ C # ، إلى هذا ...

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

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

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

كتعليق ختامي ، وأنا أعلم أن بعض الناس سوف يسلكون الطريق الخطأ ، يجب أن أقول هذا:

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

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

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

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

يمكن أن تسد تلميحات الكتابة الفجوة التي تمنع إكمال التعليمات البرمجية بشكل كامل. لقد عملت ذات مرة في مشروع باستخدام Lua ، وكانوا يريدون الحصول على هذا أيضًا. قادني البحث هنا: https://github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48
هذا ما يمكن أن تصبح عليه معلمة الوظيفة ، إذا تعمقت كثيرًا في كتابة تلميح xD
لكن أعتقد أنه يجب أن تكون هناك مقايضة. انظر فقط إلى كيفية عمل TypeScript أو Haxe (كلاهما يسمح بمزج المتغيرات والمكتوبة). أيضًا ، كتابة التلميح موجودة بالفعل في Godot. يتم استخدامه فقط في التصدير () :)

هل بدأ أي شخص بالفعل في تجربة وحدة أحادية؟
تضمين التغريدة

تحقق من GodotSharp . الحالة الحالية في المستودع ليست قابلة للاستخدام بعد. في الريبو المحلي الخاص بي ، تمكنت من تنفيذ أشياء كافية (يتوفر فقط Vector2 و Matrix32 كأنواع أساسية) لترجمة العرض التوضيحي 2d / platformer إلى C # ، باستثناء تثبيت الأعداء والرصاص الذي يتم من GDScript نظرًا لأن المراجع لا تعمل بعد.
هذا مثال على فئة اللاعب: https://github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs

تضمين التغريدة

فكرة لاحقة:
هل يمكن استخدام لغة ++ C فقط في Godot؟ أعتقد بصدق أنني أفضل تعلم C ++ واستخدامه عبر GDScript.

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

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

Pikl لا يتعلق الأمر بمقدار ضغطات المفاتيح ، إنه يتعلق بمقدار الاختيارات والمعنى الضمني للأحرف الإضافية. لا يحتوي GDScript ببساطة على بعض الميزات التي من شأنها إضفاء الشرعية على الكلمات الرئيسية الإضافية. على سبيل المثال ، يجب أن يسبق كل متغير وفئة ووظيفة بالكلمة الأساسية "عام" ، نظرًا لأن معدل الرؤية الافتراضي لـ C # ليس عامًا (باستثناء مساحات الأسماء - يتغير بناءً على حالة الاستخدام ... موقف آخر حيث قررت Microsoft ذلك KISS هي مجرد فرقة من الثمانينيات) ومنذ ذلك الحين في GDScript أصبح كل شيء عامًا.

فلماذا لا تضيف C # بكل ميزاتها؟
كما ذكر Zylann بالفعل ، فإن تأثير إضافة C # إلى Godot ليس بهذه السهولة للتنبؤ. إذا لم تكن قد انتهيت من ذلك بعد ، فسأكون ممتنًا إذا قرأت رسالتي الطويلة في هذا الموضوع (https://github.com/godotengine/godot/issues/5081#issuecomment-225226235). بصفتي مطورًا ، كنت سأطلب دائمًا لغات أكثر قوة. في وقت فراغي ، أبحث حاليًا عن Kotlin لمجرد أن الفقير الورقي ذكرها في المنشور الأول.
لكن منذ أن أتيحت لي الفرصة للنظر في تأثير لغات البرمجة على النتيجة وسلوك مطوري اللعبة ، أدركت مدى أهمية اختيار لغة مناسبة بدلاً من لغة قوية.
كما أوضحت في المنشور المرتبط ، أنا متأكد من أن C # لها تأثير ملحوظ على الثقافة في مجتمع الوحدة الذي يرى المبرمجين كأشخاص

• كتابة الأشياء لمتجر الأصول
• كتابة دروس
• إصلاح الخلل.

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

وهذه فقط حجةي المضادة المفضلة ، كان هناك العديد من الحجج الجيدة الأخرى في المشاركات الأولى. ؛-)

مشكلة JVM أنها ثقيلة جدًا. هل ألقى أي شخص نظرة على Avian ؟ ما مدى توافقه مع عالم جافا؟

neikeq هذا لا يعني أن أداءه سيئ - AFAIK و JVM لديه أداء أفضل من CLR ، وكذلك جامع القمامة أكثر ملاءمة لتطوير اللعبة. يتم تثبيته أيضًا على معظم أجهزة الكمبيوتر ، بغض النظر عما إذا كانت تعمل بنظام Windows أو Mac أو GNU / Linux.

كما أن لديها ثروة أكبر من مكتبات FLOSS عالية الجودة ، وبغض النظر عما يقوله بعض الناس ، فهي توفر دعمًا أفضل عبر الأنظمة الأساسية.

أود أن أقول أنه بين الاثنين ، من الواضح أن JVM أفضل لتطوير اللعبة (لكنني سأتجنبها وكذلك CLR على حد سواء).

يبدو الطيور مثيرة للاهتمام. ليس لدي خبرة في ذلك ، لذلك لا يمكنني الإجابة على سؤالك ، وأخشى أن يكون توافقه مشكلة مثل إصدار Unity's Mono ، مما يجعل استخدام مكتبات الجهات الخارجية أمرًا محرجًا حقًا ما لم تفعل يحدث للعثور على واحد لأحد إصدارات .NET المقدمة.

لكن الحصول على تطبيق Java خفيف الوزن كخيار إضافي إلى جانب GDScript & C ++ للحالات التي تحتاج فيها إلى أوقات استجابة سريعة ويمكن أن تضحي بجودة الكود (مثل اختناقات اللعبة أو النماذج الأولية السريعة لأفكار الواجهة الخلفية الجديدة) سيكون أمرًا رائعًا.

تم وضعneikeq Avian في الاعتبار لتوفير برمجة جافا لمشاريع c ++ ، لذا فهي حقًا مرشح جيد. يمكن أن يكون صغيرًا جدًا (شيء مثل 100 كيلوبايت إذا كنت أتذكر بشكل صحيح). سمعت عن بعض ألعاب libGDX التي كانت تستخدم Avian لتحرير منافذ iOS ... محرك jMonkey يستخدم Avian على iOS أيضًا). بشكل عام ، يأتي Avian بدون عبوة كاملة تأتي عادةً مع JVM مثل فصول sun / oracle. ومع ذلك ، لا أعتقد أنها مشكلة نظرًا لأن فصول جافا "الأصلية" ليست مناسبة تمامًا للألعاب على الإطلاق ، ولهذا السبب توفر مكتبات مثل libGDX التنفيذ الخاص بها على المتجهات أو هياكل البيانات .. وفي النهاية أعتقد أننا سنفعل ذلك. بحاجة إلى إعادة تطبيق تلك الفئات أيضًا. (على الرغم من أنه من السهل تضمين أجزاء مختلفة من فئات جافا الأصلية ، ولكن كلما قمنا بتضمين المزيد ، سيصبح Avian أكبر)

@ paper-pauper قصدته ثقيل الحجم ، بافتراض أنه سيتم دمجه مع اللعبة. ولكن كما قلت ، يتم تثبيته على معظم أجهزة الكمبيوتر ، وبالنظر إلى شعبية أطر مثل libGDX ، فقد يكون الخيار الأفضل.
مشكلتي مع C ++ كبديل لـ GDScript هي أن تركيبها فظيع. هذا قاتل للإنتاجية. لا بأس في تطوير المحرك والوحدات ، لكنني لن أكتب لعبة كاملة معها. بعد قولي هذا ، أنا أؤيد # 3936 ولدي شيء مثل ما يفعله Unreal ، لكنني لن أعتبره لغة "برمجة" بديلة.

@ kubecz3k هل يدعم لغات JVM الأخرى؟ على سبيل المثال: Kotlin

neikeq نعم بقدر ما أعرف أنه متوافق تمامًا مع java bytecode لذا فهو يدعم أي لغة جاهزة لـ jvm (kotlin و scala و jpython وما إلى ذلك)
أعتقد أننا قد نطرح بعض الأسئلة على مجموعة جوجل الطيور: https://groups.google.com/forum/#!forum/avian
يبدو أنه نشط للغاية

+1 لعدم مشاهدة C ++ كلغة برمجة نصية بديلة. كما قلت من قبل ، من الجيد أن لدى Godot لغة واحدة محسّنة للبرمجة ولغة لتطوير الخلفية بدلاً من وجود لغة واحدة "meh" في كلا المجالين.

هذا لا يعني أن دعم lib الديناميكي وتطوير C ++ الأسرع لم يكن شيئًا أحب أن أراه.

ولكن لكي لا تكون متحمسًا أكثر من اللازم بشأن Avian ، فإليك منشور مدونة من المطور الرئيسي لـ libGDX والذي يوضح فيه سبب عدم استخدام libGDX لـ Avian لمنافذ iOS. http://www.badlogicgames.com/wordpress/؟p=3925 (انتقل لأسفل إلى جزء الطيور)
أنا لست مبرمجًا / مخترقًا بتنسيق jvm (ولكن المؤلف - نظرًا لأنه كان يعمل أيضًا على RoboVm (وهو ملف JVM آخر تم شراؤه وإغلاقه بواسطة Microsoft)) لذلك لا أعرف مقدار ما سيتحول بالفعل إلى الموقف الذي يتم فيه استخدام Avian كلغة برمجة نصية فقط (وليس لتشغيل المحرك الأساسي)

من المحتمل أن يكون معظمكم مبرمجين يتمتعون بخبرة أكثر مني ، ولكن هناك سنتان. قبل عام ، كنت سأقوم بالتجذير لـ C #. لكنني تعلمت تركيب GDScript بسرعة كبيرة. في نهاية اليوم ، ما زلت بحاجة إلى تعلم API وربما يكون هذا هو الشيء الأكثر استهلاكا للوقت للتعلم. لذا نعم ، لست بحاجة إلى C #. انسحبت Warlaan من الكثير من الأسباب الوجيهة ضد C #. قد يستغرق تنفيذ C # أيضًا الكثير من الوقت. قد يعني أيضًا المزيد من الأخطاء. نعم ، لدينا مجتمع رائع يساهم في قاعدة التعليمات البرمجية ولكن لا يزال لدينا واحد فقط reduz أعتقد أن الوقت المطلوب لتطبيق C # يجب استثماره في الميزات التي نحتاجها حقًا. كم عدد مطوري Godot الراضين عن GDScript؟ نعم ، يمكن أن يكون أسرع ، لكن ليس لدي أي مشاكل أخرى معه. أفضل استخدام لغة برمجة واحدة رائعة على لغتين ليستا جيدين. حتى الوحدة تتخلف مع مونو العجوز.

ما أرغب في الحصول عليه هو الكتابة الثابتة في GDScript. ليست C ++ كلغة برمجة نصية ، وليس C #. دعونا نركز على GDScript ونجعله أفضل مما هو عليه الآن.

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

كتبنا مترجمنا الخاص (مكتوبًا أيضًا بلغتنا الخاصة بعد تمهيده في C ++) والذي تم تجميعه إلى كود C ++ (شبه خالص تقريبًا) والذي تم إدخاله بعد ذلك في المجمعين لجميع الأنظمة الأساسية التي دعمناها (XBox / PS / PC / Wii / إلخ). كتبنا جامع القمامة الخاص بنا لنتمكن من ضبط أدائه حسب الحاجة - كان القيام بذلك بهذه الطريقة يعني أنه تم استخدامه في جميع أنحاء المحرك مما يعني أنه تم اختباره وتحديد سماته بشكل جيد. ونظرًا لأننا كنا نتخطى التحويل البرمجي إلى C ++ ، يمكننا بسهولة كتابة كود C ++ في وظائف "أصلية" يمكنها استدعاء واجهات برمجة التطبيقات للنظام حسب الحاجة أو تتضمن عمليات خاصة بالنظام الأساسي (SIMD).

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

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

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

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

فيما يتعلق بمقدمة GDScript ، فقد حدث شيء مثل هذا:

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

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

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

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

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

كنا نضحك بشدة ونطلق النكات ، وكان منتج اللعبة (الذي كان وراءنا ولم نلاحظه) يرتجف من الخوف وقال: "انتظر ماذا؟ كل ما تبقى الآن هو ترجمة اللعبة إلى البرتغالية ، هذه مزحة اليس كذلك؟"

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

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

لقد وصلت شخصيًا إلى عنق زجاجة CPU / Gdscript في هذا المشروع: http://godotdevelopers.org/index.php؟topic=15519.0

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

أيضًا ، أعتقد أنني واجهت نفس عنق الزجاجة CPU / Gdscript العام الماضي مع هذا المشروع الآخر الذي كان يستخدم GDscript للذكاء الاصطناعي الأساسي لكل حشرة (حيوانات): http://ludumdare.com/compo/ludum-dare-32/؟ الإجراء = معاينة & uid = 50893
كلما أضفت المزيد من الحشرات (الحيوانات) ، كان الأداء أقل.

يمكنني مشاركة تجربتي في ذلك إذا أراد شخص ما.

SuperUserNameMan يرجى المضي قدمًا ، لكنني أعتقد أن هذه التذكرة الأخرى التي فتحتها # 5049 (والتي تتحدث تحديدًا عن أداء GDScript) هي أكثر ملاءمة لذلك.

@ paper-pauper: لست متأكدًا من أنه يمكنني المساهمة # 5049 (والذي يتعلق أكثر بإضافة JIT ، حول ما يمكنني فقط إضافة إبهام لأعلى). تتعلق التجربة التي يمكنني مشاركتها أكثر حول نوع عنق الزجاجة الذي وصلت إليه ، وما هي الأعراض المحددة ، وكيف كان علي العمل ، وكيف قمت بالتحسين ، وما هي "فوائد تصميم godot" التي كان علي التضحية بها.

SuperUserNameMan لم أفكر كثيرًا بعد في تنفيذ JIT عبر الاستدلال بالنوع ، ولكن لذلك يجب أن يدعم VM الكتابة الثابتة أولاً

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

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

@ paper-pauper سأنظر إلى الموضوع الآخر الذي ذكرته. لم أقصد حقًا أن يبدأ الأشخاص في نشر مشكلات الأداء في هذا الموضوع.

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

سيؤدي القيام بذلك أيضًا إلى الحفاظ على IDEs الحالي (VC ++ ، وما إلى ذلك ومحرر Godot) الذي اعتاد الناس على استخدامه. لقد استخدمنا في الواقع VC ++ لتصحيح أخطاء لغتنا ، وقام المحول البرمجي الخاص بنا بإنشاء توجيهات #LINE في ملفات .cpp بحيث يمكنك بسهولة التنقل خلال الكود الأصلي وتعيين نقاط التوقف. لذلك من الناحية النظرية ، ستكون قادرًا على وضع نموذج أولي وتصحيح الأخطاء باستخدام GDScript العادي في المحرر ، ولكن أثناء الإنشاءات الممكّنة لـ "GDScript-> C ++" ، لا يزال بإمكانك استخدام C ++ IDE / Debugger وتعيين نقاط التوقف / التصحيح في ملفات gdscript. بالنسبة لنا ، كانت ملفات C ++ التي تم إنشاؤها مؤقتًا ولم ننظر إليها إلا إذا كانت هناك مشكلة في إنشاء الكود.

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

في الواقع لم أفهم أنه كان من المفترض أن أنشر مشكلات الأداء الخاصة بي في هذا الموضوع أيضًا. هنا كان أكثر ملاءمة: https://github.com/SuperUserNameMan/kart-zero/issues/1

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

ومن الأمثلة على ذلك الرجال الذين يرغبون في ربط Steam API و ODBC و SQLite و Kinect وما إلى ذلك ، وكلها تتطلب وحدات كتابة في C ++. يؤدي القيام بذلك باستخدام واجهة برمجة تطبيقات C إلى حل مشكلة الارتباط الديناميكي مقابل C ++ (وهو أمر محدود للغاية نظرًا لأن كل مترجم أو إصدار مترجم له ABI الخاص به ، ومشكلات عدم تطابق حجم الرمز التي قد تحدث بين إصدارات Godot). C ليس لديه أي من هذه المشاكل.

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

reduz آه رائع. إذن ، فأنت تتحدث بشكل أساسي عن القدرة على كتابة ملف DLL "مكون إضافي" يمكنه كشف ما يريده لـ GDScript؟ (أم أنني أسأت الفهم؟)

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

هل يعمل هذا مع شخص يريد كتابة ملف dll يحتوي على عدة أنواع جديدة مشتقة من عقدة C ++؟

من المحزن بعض الشيء أن دعم وحدات C ++ الجديدة يبدو كافيًا لإصلاح بعض مشكلات مكتبات DLL.

لماذا لا تستخدم لغة برمجة نصية قابلة للتضمين مثل lua أو Ruby؟

jersten لأن قراءة المستندات - http://docs.godotengine.org/en/latest/reference/gdscript.html

Ziflin نعم ، ولكن سيتعين عليك استخدام واجهة برمجة تطبيقات C عبر الانعكاس (على الرغم من أنه يمكنك طلب مؤشرات الوظيفة عبر الانعكاس ، لذا يجب أن تكون سريعة بما يكفي ..). سيكون الهدف في الغالب هو الحصول على طريقة سهلة لتحميل ملفات DLL التي تتجنب مشكلة ABI ، وأيضًا طريقة بسيطة لترجمة GDScript إلى C وتحميلها كملف.

سأضع 2 سنتي هنا مقابل ما يستحق. لم أقم مطلقًا بالتشفير في C # ولكن فقط في Java. على الرغم من أنني شخصياً أفضل استخدام Java نظرًا لاستخدامه وأحببته ، إلا أنني أؤيد بالفعل C # عبر Java. C # هو ما يستخدمه مطورو لعبة Unity ، لذا فإن وجودها سيجعل من Godot جزءًا من هذا النظام البيئي المستقل الذي تم إنشاؤه بواسطة Unity. كما أن Java ليست خيارًا جيدًا إذا كنت تريد لغة JVM. هناك لغات أخرى أفضل يتم تجميعها إلى JVM.

أعتقد أن الناس فاتتهم النقطة على أي حال. C # / Java! = لغة البرمجة النصية. GDScript كافية ؛ سهل بما يكفي للتعلم ، إلخ.

إن إضافة لغة مثل Java (بناء JVM لأي غرض ؟! بناء الجملة؟! طلب JVM بإصدار معين ليعمل؟!؟) أو C # (تنفيذ mono و kludge المحرك ؛ أو إنشاء الخاصة بك؟) من شأنه أن يسمم المحرك .

إذا كانت هناك مشكلة في GDScript فيجب الإشارة إليها ؛ ثم حاول إصلاحه.

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

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

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

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

أعتقد أن هناك سوء فهم:

• يرون GDScript ويعتقدون أن GDScript على قدم المساواة مع C # ؛ تفتقد النقطة الأساسية التي مفادها أن C # ليست لغة برمجة نصية.
• بسبب الحقيقة المذكورة أعلاه ، عندما يقول أحدهم "Java or C #" ؛ ما يطلبونه حقًا هو إعادة كتابة المحرك إلى C # / Java أو إضافة بعض الارتباطات لدعم تلك اللغات (lol no).

منذ أن أفترض الأخير ؛ تصحيح الأخطاء في C # / Java هو كابوس على منصات متعددة ؛ نظرًا لأن هاتين اللغتين ليستا مستقلتين عن النظام الأساسي (يوجد في inb4 أوقات تشغيل على جميع أنظمة التشغيل تقريبًا) ؛ يتحول إلى "اكتب مرة واحدة ، وصحح الأخطاء في كل مكان" (وهذا هو سبب ظهور الألعاب المكتوبة على Monogame على Windows أولاً ؛ ثم في النهاية على Linux / Mac لأنه يتعين على المطورين تصحيح الأخطاء لهذه الأنظمة الأساسية). هذا هو السبب في أن تحديثات JVM تعطل التطبيقات.

إضافة دعم لتلك اللغات لا يضيف أي قيمة للمحرك.

إذا كانت الحجة "moar Unity devs" ؛ ثم يجب عمل التوثيق للمساعدة في انتقال مطوري الوحدة ؛ تلك الاختلافات في التخطيط ، وما إلى ذلك.

هذا هو السبب في أنني قلت في النهاية أنه لا يهم اللغة التي تستخدمها ، فستظل بحاجة إلى تعلم فصول Godot API وكلها. ليس مثل Unity devs سيكونون خبراء insta لأنهم يعرفون C #. أعتقد أنه أكثر من "هالة من الخير" لجودو إذا كان يدعم C #. يشعر الناس أنهم يعرفون المزيد وأن جودو المفاجئ أصبح متاحًا بشكل أكبر ولم يعد مخيفًا بعد الآن. الشيء السلبي الوحيد في Godot من غير مستخدمي Godot هو أنه يحتوي على لغة برمجة خاصة به. كمستخدم في Godot ، يعرف أن BS لأن GDScript هي لغة ممتعة وبسيطة ولكن للغرباء قد تبدو غير جذابة.
لا يمكنني التحدث من وجهة نظر dev ، لكن ربما يكون جهدًا أكثر مما يستحق ما لم يحصل المطورون على شيء ما من تنفيذ C # فإن الأمر يستحق ذلك. في النهاية هو قرار مطوري الرصاص وأيًا كان ما يقررونه فسوف أتعامل معه. أنا متأكد من أنه سيكون قرارًا جيدًا.

أنا أتفق معك في أن GDScript هو أمر مستبعد بعض الشيء لأنها لغة غير معروفة تقريبًا. ولكن ، بعد أن قرأت سبب إزالة Lua و Python وفوائد إضافة GDScript ، كنت أقل قلقًا.

شيء آخر قد يكون ذا صلة: هناك محرك آخر مرخص من معهد ماساتشوستس للتكنولوجيا يدعم بالفعل C # وهو أكثر شبهاً بـ Unity ، Atomic Game Engine . أقترح أن يجربه جميع الأشخاص الذين هم في أمس الحاجة إلى شيء قريب من الوحدة قدر الإمكان.

سأضيف فقط 2 سنتي هنا. بالنسبة لي ، فإن الميزة الكبيرة لـ C # هي الأداء ، بينما لا يزال العمل معها أسهل من C ++. GDScript ، التي تتم كتابتها ديناميكيًا وكلها ، سريعة جدًا في الكتابة ، ولكنها لن تكون أبدًا سريعة التشغيل (على الرغم من إمكانية تحسينها كثيرًا ، وهو ما تم التخطيط له). وحدات C ++ سريعة جدًا ، ولكن من الصعب التعامل معها ؛ C ++ ليست لغة ودية تمامًا ، ولا يعد الاضطرار إلى إعادة ترجمة المحرك لاستخدامها هو الأمثل حقًا. بالنسبة لي ، يعد C # نوعًا من التسوية: أسرع بكثير من GDScript ، ومع الدعم المناسب ، يكون العمل أسهل كثيرًا من وحدات C ++.

كل ما يقال ، لا يجب أن يكون C #. أي شيء آخر له تأثير مماثل سيكون جيدًا ، بقدر ما أشعر بالقلق ، سواء كان مكتوبًا بشكل ثابت / JIT GDScript ، أو أي شيء آخر مثل Swift أو شيء من هذا القبيل. قد يكون C # هو الأفضل "لأغراض التسويق" ؛ حتى بدون واجهة برمجة تطبيقات مماثلة ، فإن المطورين من محركات / أطر عمل أخرى سيكونون أكثر راحة في التعامل معها. قد يكون تطبيق GDScript المعدل أسهل في التنفيذ ، ومن المحتمل أن يتم دمجه بشكل أفضل.

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

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

اسمحوا لي أن أضيف تعليقًا على الحجة القائلة بأن C # ستجلب أشخاصًا جددًا.
لماذا نريد المزيد من الناس لاستخدام Godot؟ أنا أفهم تمامًا أن المشاريع مفتوحة المصدر تحتاج إلى مجتمع

• يضيف الميزات
• يصلح الخلل
• يخلق أصولًا قابلة لإعادة الاستخدام
• يقدم اقتراحات لميزات جديدة
• يجد أخطاء أو مشاكل في سير العمل
• يكتب الدروس

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

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

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

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

تحرير: إزالة بعض اللغة القاسية غير الضرورية ؛-)

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

1. نعم ، لا يريد الناس إضاعة الوقت. المواصفات الكاملة لـ GDScript: بضع شاشات. كتب تشرح C #: عادة ما لا يقل عن 500 صفحة. لقد قضيت بضعة أيام في تعلم GDScript وأنا متأكد تمامًا من أنه لا يحتوي على ميزة واحدة لا أعرفها. لقد عملت بشكل احترافي وفي أوقات فراغي مع C # لسنوات حتى الآن (باستخدام Window Forms و WPF و XNA و Unity) وما زلت أجد مقتطفات التعليمات البرمجية التي تستخدم ميزات لم أفهمها تمامًا. طلب C # لأنه كان أقل إهدارًا للوقت لا معنى له حقًا.
2. "سينتهي الأمر بالمبتدئين إلى تعلم أي لغة تمت كتابة مقتطفات الشفرة التي يستخدمونها" - انظر النقطة 1. إن الفكرة القائلة بأنه يمكنك تعلم لغة C # من مقتطفات الشفرة بعيدة كل البعد عن الحقيقة. الأشياء التي يمكنك تعلمها بهذه الطريقة أساسية جدًا لدرجة أنها لن تستغرق أكثر من بضعة أيام "لتعلم" لغة مختلفة. قلت لنفسك أنك تعلمت GDScript بهذه الطريقة.
3. "ستجعل C # Godot جزءًا من نظام التطوير المستقل هذا". وماذا من المفترض أن يعني ذلك؟
   هل يمكنك استخدام مقتطفات كود الوحدة في C # -Godot؟ رقم.
   هل يمكنك إعادة استخدام أصول الوحدة في C # -Godot؟ رقم.
   هل يمكنك قراءة دروس Unity وتطبيقها حرفًا بكلمة على C # -Godot؟ رقم.
   إذن ما هو "النظام البيئي المستقل للمطورين" الذي تشير إليه؟

كما قال الفقير الورقي ، هناك الكثير من المحركات والمكتبات للاختيار من بينها.
هل تريد نظام مكون مثل نظام Unity؟ انظر إلى محرك اللعبة الذرية.
هل تريد الاستمرار في استخدام C # في المحرك ولكنك تريد التخلص من نظام المكونات؟ انظر إلى CryEngine / Luberyard.
هل تريد الاستمرار في استخدام C # ولكنك تريد التخلص من المحرك؟ انظر إلى لعبة MonoGame.

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

سأضيف فقط 2 سنتي هنا. بالنسبة لي ، فإن الميزة الكبيرة لـ C # هي الأداء ، بينما لا يزال العمل معها أسهل من C ++. GDScript ، التي تتم كتابتها ديناميكيًا وكلها ، سريعة جدًا في الكتابة ، ولكنها لن تكون أبدًا سريعة التشغيل (على الرغم من إمكانية تحسينها كثيرًا ، وهو ما تم التخطيط له). وحدات C ++ سريعة جدًا ، ولكن من الصعب التعامل معها ؛ C ++ ليست لغة ودية تمامًا ، ولا يعد الاضطرار إلى إعادة ترجمة المحرك لاستخدامها هو الأمثل حقًا. بالنسبة لي ، يعد C # نوعًا من التسوية: أسرع بكثير من GDScript ، ومع الدعم المناسب ، يكون العمل أسهل كثيرًا من وحدات C ++.

جميع المشكلات التي ذكرتها مع C ++ التي ذكرتها صالحة ويمكن إصلاحها عبر # 3936. لقد ناقشنا هذا عدة مرات بالفعل ، ولكن فقط من أجل الوضوح ، توجد هنا المشكلات المتعلقة بـ GDScript التي يمكننا التعرف عليها بشكل موضوعي:

1. دعم ضعيف لمكتبات الطرف الثالث
2. أداء سيء

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

قرأت هذا الموضوع بسرعة ، ورأيت أنه تم تصور GDScript to C.

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

يتم توزيع TCC بموجب رخصة جنو العمومية الصغرى.

(مصدر)

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

Warlaan لست مضطرًا للتفكير كثيرًا. في هذه المرحلة ، قلنا نفس الشيء حوالي 10 مرات بالفعل أعتقد أننا نعرف إلى حد كبير ما إذا كنا جميعًا نقف. بخلاف 2 سنتي وبعض الأفكار ، ليس لدي الكثير للمساهمة به لأنني لست مطورًا ولا أعرف المحرك جيدًا. سأترك أولئك الذين يعرفون أفضل الكلام. أردت فقط التعبير عن دعمي وهذا كل شيء.
خارج الموضوع:
لكن نعم فيما يتعلق بالنقطة 2. التي أثارت ضجة كبيرة حول ذلك ، كان عليك تعديل تعليقك. إذن أنت تقول أنك لا تستطيع تعلم لغة بناءً على الأمثلة؟ أعتقد أنك تفترض أن الأشخاص غير قادرين على تعلمها إلا إذا قرأوا 500 صفحة كتيبات والتي تعرف C # لأنك تقول السبب الأول لرفضها. حسنًا ، أنا دليل حي على أنك مخطئ. كيف تعتقد أنني تعلمت GDScript؟ مع واجهة برمجة التطبيقات وأمثلة العروض التوضيحية وطرح الأسئلة. ضع في اعتبارك أنه لم يكن لدي أي معرفة ببايثون قبل أن أبدأ ، لذا فكل شيء عنها غريب جدًا. كملاحظة جانبية ، أتساءل عن عدد الأشخاص الذين يشترون أدلة libGDX مقابل عدد الأشخاص الذين يستخدمون Google في الواقع "كيفية القيام بـ X في libGDX" على الأرجح سبب كون متجر الأصول أمرًا سيئًا للغاية في Unity. وبهذا انتهيت في الوقت الحالي لأنني لم أجد ما أقوله.

( Calinou : سمح Bellard لشوكة TCC بأن تصبح BSD أو MIT. لكن في المرة الأخيرة التي تحققت فيها ، لم يصدر مطور الشوكة رمز المصدر. لذا ، ربما يقبل Bellard السماح لمجتمع Godot بإعادة ترخيص TCC أيضًا؟)

لست متأكدًا من أن TCC جيدة مثل GCC أو Clang كمترجم - حجمها يدعم الكثير من البنى ولإنشاء كود محسن جدًا (أداء أفضل).

ماذا عن Godot اعتمادًا اختياريًا على GCC أو Clang لتجميع لغة C؟ يتم تثبيتها على أجهزة معظم الأشخاص الذين يبنون الألعاب على أي حال (لذا فإن الحجم ليس مصدر قلق حقًا) ، وهي الطريقة التي تقوم بها اللغات الأخرى التي يتم تجميعها إلى لغة C (مثل الدجاج ). كما أنها تدعم C ++ ، في حالة الحاجة إليها في أي وقت.

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

اقترحت استخدام TCC كـ JIT لـ GDScripts. لذلك كانت أهم ميزة هي سرعة الترجمة. وأعتقد أن النتائج يمكن أن تكون بالفعل أسرع بكثير من الحل الحالي.

يريد معظم الناس C / C ++ للأداء و Lua / Javascript لكونها أسهل وأسرع في الكتابة ، فلماذا لا يكون لديك أفضل ما في العالمين؟

نيم - http://nim-lang.org/

فعالة مثل لغة C ، معبرة مثل Python ومرنة مثل Lisp

الايجابيات:

• يجمع إلى C أو C ++ أو Obj-C أو JS (http://nim-lang.org/docs/backends.html)
• (بايثون / باسكال) مثل (https://learnxinyminutes.com/docs/nim/)
• GC أو يدوي (http://nim-lang.org/docs/gc.html)
• يمكن استخدامها في مكان آخر غير جودو
• متعدد المنصات (windows ، linux ، osx ، mobile)
• يساعد في تحويل كود C إلى Nim
• يدعم C libs
• مترجم قابل للتعديل
• مرخصة من معهد ماساتشوستس للتكنولوجيا
• المصدر المفتوح
• النوع الآمن

سلبيات:

• يتطلب مترجم C / C ++ في كمبيوتر المطورين -> gcc ، vcc ، llvm_gcc ، icc ، clang أو ucc _ (ليس خدعة حقًا ، في رأيي) _
• مجتمع صغير
• ليس 1.0 بعد

قائمة Nim's TODO صغيرة ، فهي قريبة من 1.0:
https://github.com/nim-lang/Nim/blob/devel/todo.txt

كما قال الفقير الورقي (حول وجود مترجم في كمبيوتر المطور):

يتم تثبيتها على أجهزة معظم الأشخاص الذين يبنون الألعاب على أي حال
https://github.com/godotengine/godot/issues/5081#issuecomment -227706106

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

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

إنه ليس الحل المفضل لدي ، ولكن إذا كان يجب عليك السير في هذا الطريق ، أقترح بشدة استخدام Haxe (

لا يمكنني التعليق على ترخيص Haxe (المترجم نفسه يستخدم "GPLv2 +" ، والمكتبة القياسية تستخدم MIT) ، ولكن جميع العوامل الأخرى تجعلها خيارًا ممتازًا imho.
إنها منصة تم اختبارها (حاليًا في الإصدار 3.2.1) على عكس Nim الذي لم يكن الإصدار 1.0 حتى الآن ، ولكن ما هو أكثر أهمية بالنسبة لي هو أن بناء الجملة أقرب كثيرًا إلى اللغات الأخرى المعروفة. عند قراءة أمثلة Nim ، يبدو لي أن المطورين وراء تلك اللغة حاولوا إيجاد حلول غير عادية و / أو قبيحة.

لكن كما ذكرت ، ليس هذا هو الحل المفضل لدي وإليك السبب:
اللغات الوسيطة مثل Nim أو Haxe لها العديد من "التبعيات الدلالية". لا أعني التبعيات على المكتبات أو الملفات التنفيذية التي يجب أن تكون موجودة ، أعني أنها تتعلق بلغات أخرى. الآن كما قلت من قبل اللغات لم تعد أدوات بعد الآن ، إنها ثقافات. وحتى إذا كنت تراهم فقط كأدوات ، فإن لديهم مجالات أساسية مختلفة تم إنشاؤها من أجلها. على سبيل المثال ، من المنطقي تمامًا أن يقوم الأمر "echo" بطباعة النص إلى الإخراج القياسي عند إدخاله في الإدخال القياسي. من التبعي فقط استخدام نفس الأمر في البرنامج النصي الدفعي. باتباع هذا المنطق ، من المفهوم أن PHP تستخدم نفس الأمر. إن استخدامها بلغة ذات أغراض عامة مثل Nim لا معنى له ، لأن جميع اللغات الأخرى ذات الأغراض العامة لها طرق تسمى شيئًا ما مع "كتابة" أو "طباعة" في الاسم.
ليس لدي أي فكرة عن سبب استمرار استخدام Nim لـ "echo" كاسم لهذا الأمر ، ولكن هذا هو نوع الشيء الذي يمكنك ملاحظته كثيرًا مع Haxe والذي أتوقعه من Nim في المستقبل إن لم يكن بالفعل في الإصدار الأول . على سبيل المثال ، تحتوي مكتبة Haxe القياسية على طريقة فرعية (int ، int) وسلسلة فرعية (int ، int) -method. يقوم أحدهما بإرجاع السلسلة الفرعية من الفهرس الأول إلى الثاني ، بينما يقوم الآخر بإرجاع السلسلة الفرعية من الفهرس الأول بطول الوسيطة الثانية. السبب في وجود كليهما هو أنه نظرًا لأنه يمكن استخدام اللغة لاستبدال اللغات من أنواع مختلفة ، فإن لديها مستخدمين يأتون من منصات مختلفة ، وما لم يكن هناك شخص لديه يد قوية للغاية يقرر ما يدخل في مكتبة مفتوحة المصدر وما لا ستنتهي بسهولة بمثل هذا المزيج من أنماط الترميز.

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

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

من السهل جدًا تعلم GDScript ، مما يجعل Godot أقرب قليلاً إلى Gamemaker من Unity في هذا الصدد.
ولكن بعد كتابة 3 ألعاب صغيرة واللعب مع مجموعة من العروض التوضيحية ، يجب أن أقول إن GDScript يفتقر إلى أي شيء يتجاوز الألعاب الأساسية للغاية.

تصبح ملفات التعليمات البرمجية طويلة جدًا ويفتقر محرر الكود إلى الكثير من الميزات المفيدة الموجودة في IDEs الأخرى مثل: طي النطاقات ، والمناطق ، والقفز إلى بداية / نهاية النطاق الحالي.

يفتقر GDScript أيضًا إلى الكثير من الميزات الأساسية للغات الإجرائية مثل: المناسبة _ for _ الحلقات ، المناسبة _ do ... بينما _ الحلقات (تدعم _ while _ الحلقات) ، _ switch ... case _ ، _ مشغل ثلاثي _ ، _ التعداد _.
_ لا يوجد وعي بالعلاقة بين مشهد الفصل _ لذا إذا لم يكن قد تم إنشاؤه مسبقًا ، فستكون فئة "خارجية" ويجب تحميلها مسبقًا.

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

عين 776 ؛ لا يمكن استخدام GDscript إلا لأكثر من مجرد ألعاب بسيطة إذا قررت تجاهل الميزات الأخرى (مثل استخدام العقد وعمليات الاسترجاعات حيثما أمكن) بدلاً من الالتزام حصريًا بوظائف مثل _get_overlapping_bodies () _

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

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

تصبح ملفات التعليمات البرمجية طويلة جدًا

هل تقصد نصوص مثل هذا؟ https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd
هل تعتقد أن C # يمكن أن يمنع حدوث ذلك؟ أنا شخصياً لا أفعل. في الواقع ، يسهل إعادة تشكيل الأخطاء واكتشافها في وقت سابق في هذه البرامج النصية الطويلة بسبب الأدوات (نعم ، عندما يقصد الأشخاص C # ، فهم غالبًا ما يقصدون VS ضمنيًا) والكتابة الثابتة ، على الرغم من أن أخطاء مسار العقدة ستكون غير قابلة للكشف حتى يتم تشغيل اللعبة. ولكن بصرف النظر عن ذلك ، فإن التصميم الجيد واستخدام العقد يمكن أن يبسط البرامج النصية كثيرًا.

يفتقر محرر الكود إلى الكثير من الميزات المفيدة الموجودة في IDEs الأخرى مثل: طي النطاقات ، والمناطق ، والقفز إلى بداية / نهاية النطاق الحالي.

يمكن إضافة هذه في المستقبل إذا طلبت ذلك ، على الرغم من أنه يمكنك استخدام محرر خارجي دون مشكلة (https://atom.io/packages/lang-gdscript) ، إلا أن Godot لديها خدمات الإكمال التلقائي.

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

لا يوجد وعي بالعلاقة بين الفصل والمشهد

ماذا تعني؟ أنت تعلم أنه يمكنك وضع نص على جذر المشهد ، أليس كذلك؟ كما لا يستطيع محررو C # تخمين ما يوجد في المشهد حيث يتم استخدامها ، بينما يمكن لـ GDScript القيام بذلك.

أيضًا ، نظرًا لطبيعة GDScript ، لا توجد مراجع وظيفية ولا قوالب.

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

يفتقر GDScript أيضًا إلى الكثير من الميزات الأساسية للغات الإجرائية

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

هل تقصد نصوص مثل هذا؟ https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

يجب أن أقول أنه حتى لو كان الملف طويلاً ، فقد رأيت أسوأ بكثير ولا يزال قابلاً للقراءة على الرغم من كون الكود إجرائيًا إلى حد ما. الآن فهمت أخيرًا سبب كون بناء الجملة البسيط أفضل بالنسبة لـ GDScript: إنه الأفضل لمنطق اللعبة المتوسط ​​، والذي يكون في الغالب if s والمكالمات الوظيفية.

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

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

هل يمكنك التعمق أكثر قليلاً في الجزء for وبعض الأمثلة لما تشير إليه في GDScript الزائفة؟

@ paper-pauper ، فإن الأشياء التي تفتقر إلى GDScript لا تتعلق بـ C # ، ولكن على سبيل المثال for i in range(-PI, PI) لا يعمل في GDScript ، وكذلك for i=0, i < size and stuff, ++i . أود أيضًا أن أكتب ثلاثية بدلاً من الاضطرار إلى كتابة ثلاثة أسطر- if. ولكن كما قلت ، هناك مشكلات في أداة التعقب بالفعل ولن تمنعني من استخدام GDScript: p

ولكن حتى لو كانت كل نصوصك تتكون من 200 سطر كحد أقصى ومصممة جيدًا نسبيًا ، إذا كان لديك الآلاف منها في لعبتك ، فستواجه مشكلة في الحفاظ على قاعدة الكود هذه وإعادة بنائها: وهذا ليس كثيرًا بسبب اللغة ، ولكن بسبب الأدوات : يرجع جزء كبير من شعبية C # إلى أن Visual Studio يعد بمثابة جحيم من IDE الجيد له. أنا متأكد تمامًا مما إذا كان Godot يدمج الأدوات المناسبة (تعريف الانتقال ، إعادة تسمية فئة / وظيفة / عضو موثوق بها ، العثور على جميع المراجع وما إلى ذلك) ، فإن العمل على قواعد أكواد GDScript الضخمة سيكون أسهل كثيرًا. بشكل عام ، هذا ما أود رؤيته في Godot ، كيف يمكن أن يتسع نطاقه بشكل جيد لألعاب BIG ، لأنني حتى الآن لم أر أيًا (بما في ذلك مشاريعي الخاصة).

for i in range(-PI, PI)

هذا يجعل رأسي يدور حول محوره حتى يصل إلى الانقسام بمقدار صفر ويبدأ في تدمير الإنتروبيا. آمل ألا توجد لغة تنفذ مثل هذا البيان غير المتوقع. ماذا تعمل، أو ماذا تفعل؟ كرر على الأعداد الصحيحة بين -PI و PI (أي -3 ، -2 ، ... ، 2 ، 3) ، أو بين مضاعفات PI (أي -PI و 0) ، أو هل تتكرر على عدد عشري مثل بعض خطوات الشعوذة الافتراضية مثل 0.176 أو ln(2) الذي وجده بعض مبرمجي اللغة الأنسب؟

@ akien-mga عفواً. كان يجب علي إضافة وسيطة خطوة بالفعل xD لكنها ما زالت لا تعمل. إليكم المشكلة التي أعددتها لها https://github.com/godotengine/godot/issues/4164

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

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

vnen سيكون وضع EMACS لـ GDScript في (M) ELPA خطوة في الاتجاه الصحيح ، في كتابي :)

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

• الحجج ليست جزءًا من توقيع الوظيفة. هذا يعني أنه لا يمكنك تجاوز الوظائف.
  من الناحية العملية ، فإن وجود function doFoo(a,b,c,d) و function doFoo(a,b) في نفس الفصل سيؤدي إلى الفشل في التحويل البرمجي. انتهى بي الأمر بإعادة تسميتها إلى doFoo4(a,b,c,d) و doFoo2(a,b) وإعادة بناء مجموعة من ملفات البرامج النصية.
• نظرًا لعدم وجود دعم للتعداد ، فإن جميع الأعلام وأكواد الإرجاع ، بالضرورة ، هي ints ، لذا عليك تخمينها ولا يزال الكثير منها غير موثق في الوقت الحالي.

ملاحظة: من الواضح أنه لم يتم تسمية الوظائف حرفيًا doFoo . ؛)

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

Zylann : ~ 1200 LOC؟ ... pffft لا ، أنا أتحدث عن الصفقة الحقيقية ... 20k + LOC لكل ملف. مطور RPG الذي يستخدم Unity ، والذي يجب أن يظل غير مسمى (لا أنا لا أعمل معهم) ، لديه بشكل روتيني فئات مع 25k + loc. ثم مرة أخرى يجعلون جميع وظائفهم ثابتة ويستخدمون C # كما لو كان C.: خائف:

آسف على الموضوع خارج.

@ eye776 لا أستطيع التفكير في أي لغة ديناميكية تسمح بالتجاوز (يمكن تزويرها بالحجج الافتراضية في بعض الحالات) ، ولكن سيكون من الجيد الحصول عليها في GDScript.

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

@ eye776 لم أر أيضًا لغات ديناميكية مع تجاوز الوظيفة. يحتوي GDScript على معلمات افتراضية ، بحيث يمكن استخدامها بدلاً من ذلك.

أيضًا ، من هو المجنون الذي يعمل 20K + LOC في ملف واحد؟ لا تكمن المشكلة هنا في الأداة ... في مصدر Godot بأكمله ، لا يوجد ملف واحد يمكنني العثور عليه مع 10K LOC.

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

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

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

vnen للمتعة فقط: godot/drivers/gles2/rasterizer_gles2.cpp هو 11K LOC: p (إنه أكبر ما وجدته ، لكنه استثناء نادر).

تضمين التغريدة

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

لقد أحرقني جودو مرة أخرى في مارس (الإصدار 2.0.1). كنت العبث بكاميرا وشخصية شخص ثالث وحاولت استخدام فيزياء Godot للحركة (السحب والقوى) وجعلتها تعمل.
الإصدار الثانوي التالي (v 2.0.2) كسر بشكل أساسي سرعة الشخصية (2-3x أسرع) لنفس القيم بالضبط.
اكتشفت أنه من الأفضل أن أبقيها ذات طبيعة حركية وأقوم بـ "الفيزياء" الخاصة بي.

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

على أي حال ، أنا آسف حقًا لإخراج الخيط عن مساره.

@ eye776 هل قمت بفحص

أحادي أم CoreCLR؟ و لماذا؟

كثرة الوحيدات:

• مرخص من معهد ماساتشوستس للتكنولوجيا
• مستقر
• إمكانية التخلي عنها
• وثائق جيدة

CoreCLR:

• مرخص من معهد ماساتشوستس للتكنولوجيا
• لا يزال ليس 1.0 (حاليًا هو RC2)
• صغير
• وثائق رديئة

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

يوم الخميس ، 4 أغسطس 2016 الساعة 1:45 مساءً ، إشعارات Hubert Jaroszgithub.com
كتب:

أحادي أم CoreCLR؟ و لماذا؟

كثرة الوحيدات:

• مرخص من معهد ماساتشوستس للتكنولوجيا
• مستقر
• إمكانية التخلي عنها
• وثائق جيدة

CoreCLR:

• مرخص من معهد ماساتشوستس للتكنولوجيا
• لا يزال ليس 1.0 (حاليًا هو RC2)
• صغير
• وثائق رديئة

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

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

CoreCLR: لا يزال ليس 1.0 (حاليًا هو RC2)

وصلت إلى 1.0 مستقر في 14 يونيو.

أحادية: إمكانية التخلي عنها

بناء على ما؟

أحادي: وثائق جيدة

اه اه اه

بناء على ما؟

لماذا تقوم Microsoft بتطوير ثلاث مجموعات من .NET؟ انها ليست جيدة من حيث الموارد. (.NET Framework ، Mono ، .NET Core)

اه اه اه

لقد راجعت كلا المستندين حول C ++ / C # interop (ما نحتاجه لـ godot) وهو موثق تمامًا في Mono. في coreCLR اضطررت إلى البحث في بعض التعليمات البرمجية الخاصة بهم وطلب المساعدة من المطورين لتشغيل تطبيقي.

يحتوي الدليل المرجعي على العديد من الوظائف غير الموثقة والروابط المعطلة ...

من الناحية النظرية ، أنا متحيز هنا ... لكنني آمل أن تكون حججي موضوعية ...

• لا أرى أي تراجع في تطوير Mono: https://github.com/mono/mono/graphs/contributors
• لم يكن تطوير Mono على Windows بنفس القوة التي هي عليه اليوم (دليل نوعي (بدون ربط الكثير من الالتزامات) https://github.com/mono/mono/pull/3231 يقول ميغيل "بما أن لدينا الآن مشرفين حقيقيين") النقطة السابقة أكثر وضوحا
• تم اختبار تضمين واجهة برمجة التطبيقات في Mono (ليس فقط Unity ، فهناك العديد من المستخدمين الخاصين الآخرين)
• يعمل Mono TODAY على PS4 و Android و Windows و iOS BITCODE (استمرت سنوات العمل في هذا) و AppleTV والعديد من الأنظمة الأساسية ...

لذا ، إذا كنت ترغب في تقديم هذا في المستقبل القريب (أقل من 3 سنوات) وعلى معظم منصات الألعاب ... اذهب مع Mono.

مرحبا،

بعض التعليقات:

• بالإضافة إلى الأنظمة الأساسية المدرجة بواسطة David Karlas ، فإننا نضيف أيضًا دعم WebAssembly و XboxOne و UWP و Win64.
• يمكن أيضًا إجراء العينة التي تتم مشاركتها باستخدام طرق افتراضية (إرسال أسرع) أو يمكن إجراؤها باستخدام أحداث C #.
• كانت C # تاريخياً في مقدمة العديد من الابتكارات اللغوية ، حيث استمدت الأفكار الجيدة من أي مكان. لقد شاع وقدم العديد من الأفكار إلى السوق الشامل من أبحاث اللغة والتي نأخذها الآن كأمر مسلم به ، أشياء مثل التكرارات ، والأدوية غير الممحاة ، و lambdas ، والبرمجة غير المتزامنة ، والخصائص ، واستدعاء النظام الأساسي ، ولكنها واحدة من اللغات التي هي الأكثر نشاطًا في الأماكن العامة . على سبيل المثال ، يضيف الإصدار القادم عددًا كبيرًا من الميزات الجديدة ، بما في ذلك مطابقة الأنماط المفضلة لدي.
• بشكل عام ، لا تعرض Unity C # الحديثة لأنها تستخدم وقت تشغيل أقدم. نأمل أن يتغير هذا قريبًا. ومع ذلك ، يدعم Mono الحالي جميع ميزات C # الجديدة ، من بين تلك البرمجة "غير المتزامنة" التي تعتبر مثالية لرمز اللعبة ، حيث يمكنك كتابتها خطيًا ، ويقوم المترجم تلقائيًا بإعادة كتابة الكود الخاص بك كجهاز حالة - مثل coroutines أو المتقدمة نسخة من "العائد" كما هو مستخدم في الوحدة.
• تعني سياقات المزامنة أنه يمكنك كتابة تعليمات برمجية غير متزامنة يتم تنفيذها ضمن سياق معين. على سبيل المثال ، قد يكون لديك تنفيذ مرتبط باللعبة ، أو تنفيذ مرتبط بـ IO ، أو تنفيذ مرتبط بخلفية رئيسية مقابل خلفية ، كل ذلك جزء من النظام.
• أثناء النشر ، لديك خيار تجميع JIT ، أو التجميع الثابت (AOT) مع LLVM أو بدونه ، لذلك تحصل على أسرع ما يمكن لـ C ++ ، وتعديل حقيقة أن C # يقوم بفحص حدود المصفوفات (ومع ذلك ، إذا كنت تستخدم لغة أصلية المخازن المؤقتة ، تستعيد أدائك على حساب السلامة)
• على مدار السنوات القليلة الماضية ، نظرًا لتركيز Mono القوي على الهاتف المحمول ، تم ضبط Mono GC ليس للخوادم ، ولكن لأحمال العمل التفاعلية. لدينا GC الجديد من الأجيال مع دور الحضانة الصغيرة التي يمكن جمعها بسرعة كبيرة ولا تتطلب مسح الكومة بأكملها.

بالنسبة إلى سبب قيام Microsoft بتطوير CLRs متعددة (لدينا ثلاثة: CoreCLR لأحمال عمل JIT ؛ عائلة CoreRT ، للتجميع الثابت في UWP ؛ Mono لأحمال العمل المتنقلة) فذلك لأنهم جميعًا يخدمون أغراضًا مختلفة قليلاً. تتقارب العناصر الداخلية حيثما أمكن ذلك ، على سبيل المثال ، استبدلت Mono الآن حوالي 60٪ من الكود الأساسي برمز يتم مشاركته مباشرةً مع بقية .NET. إنها مجرد مسألة معرفة عبء العمل الأنسب لك.

يمكنك البدء بجهاز افتراضي واحد اليوم ، والتبديل إلى جهاز آخر في المستقبل. يحتوي Mono حاليًا على سطح API أكبر ، ويعمل على الهاتف المحمول ، وقد تم تحسينه لأحمال العمل التفاعلية ويدعم المزيد من البنى (مثل ARM64).

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

migueldeicaza أهلا وسهلا! من الرائع أنك قررت المشاركة في مناقشتنا وأنك مهتم بـ Godot: +1: آمل أن تبقى معنا لبعض الوقت :)

شكرا على الانهيار الجميلmigueldeicaza! لدي سؤالان سريعان لك أو لمطوري Mono الآخرين.

1) ما هو الإعداد الحالي لتصحيح أخطاء Mono المضمنة في Windows باستخدام Visual Studio؟ لدى Unity المكون الإضافي الخاص بهم ، لكنني لم أتمكن من العثور على أي شيء سوى المكونات الإضافية التي تتصل بأجهزة Linux / OSX.

2) ما هي الطريقة الموصى بها للتعامل مع إعادة التحويل البرمجي لوقت التشغيل (التجميع والتفريغ وإعادة التحميل ، على سبيل المثال ، التجميع للعب أو المكونات الإضافية للأداة في المحرر)؟ C # (جدًا) للأسف لا يعرض طريقة Assembly.Unload () والتعامل مع AppDomains ومشكلات AppDomain المتقاطعة يبدو أنه مزعج للغاية لهذا الموقف.

كمرجع ، ليس Unity فقط يستخدم Mono - https://github.com/xamarin/urho (C # / Mono bindings لمحرك Urho3D) - هذا واحد على ترخيص MIT ، لذلك يمكننا البحث بسهولة عن حلهم.

سنتى:

يعتبر C # أفضل بكثير في برمجة الألعاب مقارنة باللغات الأخرى ذات المستوى المماثل من حيث أنه يدعم أنواع القيم المخصصة. هذه ميزة مهمة للغاية للأداء ، والتي لا يوجد بديل لها في Java (و JVM بشكل عام).

لقد حصلت:

• أنواع الرياضيات المخصصة للمكدس ، والتي تدعم العمليات الحسابية والكائنات المؤقتة بدون أي تخصيصات كومة.
• مجموعات مستمرة محسّنة ومناسبة لذاكرة التخزين المؤقت.
• علم الوراثة باستخدام أنواع القيم (بما في ذلك الأنواع الأولية)

علاوة على ذلك ، يحتوي C # على ميزات أخرى تجعل حياتك أسهل. لا أرى أي ميزة في استخدام Java بدلاً من C # عندما تتفوق C # على Java في كل ما يهم في برمجة _game_.

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

الحالة الحالية هي:
o) تقوم الوحدة النمطية بتوسيع فئة العقدة لعرض أحداث العقدة إلى netCode
(init، tree_entered، ready، process، fixprocess ....))،
س) تم "net host / wrapper module" (باستخدام آلية مضيف dotNet من Microsoft)
يتم تغليفها في مكتبة ديناميكية ، لذلك يجب أن يكون التبديل إلى Mono أمرًا سهلاً في وقت لاحق
س) ترتبط طرق dotNet وتسمى (init، tree_entered، ready، process، fixprocess ....)
س) يتم لف فئة العقدة وربطها بـ netAssembly (رمز مكتوب يدويًا للنماذج الأولية)
o) المكالمات إلى godot (من netCode) تعمل من خلال آلية ربط مكتوبة ذاتيًا
(من dll إلى godot-exe) لذا فإن exe لا يحتاج إلى وظائف التصدير.
س) بسبب استخدام msDotNet المرتبط بالنوافذ في المستقبل القريب ..

خارطة الطريق الخاصة بي لتضمين. الصافي ستكون:

1. وحدة نمطية لـ Godot باستخدام آلية استضافة Microsoft .Net (تم)
2. لفائف جودو
   (حالتي الحالية: كتابة منشئ غلاف ، يوزع كود godot c ++ ،
   الاعراب يتم ، والتوليد مستمر)
3. أخرج المشروع من حالة النموذج الأولي (أكمل الحواف ، اختبره ...)
4. كتابة آلية الاستضافة الأحادية للتخلص من روابط الويندوز
5. تمكين Visual Studio بطريقة ما لتصحيح أخطاء mono ، للتخلص من xamarin / monodev (مثل الوحدة مقابل البرنامج المساعد)
6. استمتع بالمئات من مطوري godot .net الجدد :)

بعض الأسئلة:

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

2.
أقوم حاليًا بإنشاء غلاف يلف جميع طرق godot في وظائف بحيث يمكن استدعاؤها عبر حدود dll وحدود c ++ / netCode بسهولة. (آلية ربط مكتوبة ذاتيًا لـ netCode)
لا أريد تغيير كود godot (باستثناء رمز الوحدة الخاصة بي) للبقاء متوافقًا.
أيضًا ، جعلتني افتراضية ثابتة وغير ثابتة أبكي ، ولهذا اخترت هذه الطريقة.
أي حل أفضل لهذا؟

بعض الأفكار الإضافية:

Microsoft .Net مقابل Mono:

أعتقد أنه لا يهم إذا كنت تستخدم mono أو msDotNet ، لأنه في معظم الحالات ، يعمل كود dotNet دون تغيير على كليهما. الجهد الوحيد لدعم كليهما هو كتابة "مضيف" لكل منهما (وهو أصغر جزء من "GodotDotNet"). لقد اخترت msDotNet للنماذج الأولية.
حسنًا ، يدعم mono العديد من plattforms msDotNet فقط windows ، فلماذا دعم / استخدام msDotNet؟
الجواب: الإنتاجية ، التصحيح

msDotNet:
خاصة عند كتابة / وضع النماذج الأولية لوحدة DotNetModule ، أحتاج / أريد تجميع وتصحيح الأخطاء بسرعة ، يعني أن مصحح الأخطاء الخاص بك يجب أن يقفز إلى netCode من c ++ والعكس صحيح.
اخترت VisualStudio ، لأنه يمكن تصحيح كليهما. ولكن فقط إذا كنت تستخدم msDotNet.
عند القيام بذلك ، قم بتغيير جزء من netCode ، واضغط على Run وفي 1sek! تجميعها وتشغيلها !!! بما في ذلك إمكانية التصحيح في godot. (إذا لم تغير شيئًا ما في godot ، فعليك أن تنتظر عادةً 30sek إلى 1min ... اللعنة عليك scons بطيئة! :))

كثرة الوحيدات:
يجب أن يكون Mono هو الهدف النهائي ولا يوجد نقاش حول ذلك (استقلالية المنصة) ، ولكن:
إذا كان أحد يستخدم mono ، فستواجه مشكلة كبيرة عندما يتعلق الأمر بتصحيح الأخطاء: mono لديه آلية تصحيح الأخطاء الخاصة به!
بالنسبة لي ، يعد هذا نجاحًا كبيرًا للإنتاجية ، لأنه ما لم تكتب مكونًا إضافيًا monodebug لـ visualstudio (الوحدة فعلت ذلك) لا يمكنك تصحيح شفرة netcode المستضافة الأحادية في الاستوديو المرئي وتصحيح الأخطاء في كود c ++ (هناك حلول اختراق ولكن ...).
حاولت إعداد حل قائم على Mono ، لكنني انتهيت من استخدام VisualStudio (لـ c ++) و xamarin / monodev (netcode) بالتوازي.

استنتاج:
حالة النموذج الأولي: msDotNet
lateron: أحادي ، للمستخدمين غير المهتمين بتصحيح الأخطاء في godot / c ++ واستقلالية النظام الأساسي
بعد ذلك: قم بإنشاء vs-plugin لتصحيح أخطاء mono

c # مقابل جافا:
الجواب واضح ج #! جافا سكريتبكيدز! (ما رأي مبرمج c ++ في c # devs :))
لا كانت هذه مزحة :)
أنا لا أفهم المناقشة ... عندما يتم تنفيذ نظام الشبكة ، يمكنك استخدام كل لغة تدعم dotNet بما في ذلك كلتا اللغتين بالإضافة إلى المزيد.
هذا ليس هو الحال إذا كان نظام جافا مدعومًا ...

@ Ziflin :
السؤال رقم 1:
فعلت هذا البحث أيضًا ... فقط monoRemotedebugger هو (ليس) الحل atm :(
توصيتي ، كما هو مذكور أعلاه: استخدام microsofts dotNet hosting للنماذج الأولية
ثم في وقت لاحق التحول إلى أحادية.
لبديل:
ابدأ xamarin في وضع الاختراق الخاص به ، ودعه يستمع إلى المضيف المحلي ، وحدد نقاط التوقف ، ثم ابدأ مشروعك في مقابل اختباره ، إنه يعمل ، ولكن ...
بالنسبة لي لا يوجد حل! أريد "ضربة تشغيل وتصحيح في ثانية واحدة" - آلية وهذا بنقرة واحدة!
ليس لدي الكثير من الوقت في أوقات فراغي ، لذا فإن الإنتاجية هي هدفي الرئيسي.

السؤال 2:
لا أعرف ذلك جيدًا حتى الآن ، لكنني أعتقد أنه يجب عليك القيام بذلك في c ++ ، وتنفيذ الاستضافة الأحادية ، وإدارتها من "الخارج" في c ++.

روابطCharlesWoodhill الرسمية C # هي بالفعل قيد العمل ويمكن رؤيتها هنا https://github.com/neikeq/GodotSharp/

رائع tnx ، ثم أعرف كيف أقضي بعض أيام هوليلي القادمة ؛)

مرحبًا ، لقد جئت للتو إلى godotSharp ولكن هذا تم إسقاطه.

هذا هو قطرة.

النسخة الرسمية التي سمعتها على IRC كانت شيئًا مثل:

لا يحب neikeq دفع رمز غير مكتمل ، لذا فهو يعمل في فرعه المحلي

حسنًا ، من الجيد معرفة ذلك ، كنت على وشك القيام بوحدتي الخاصة ولكن أعتقد أنني قد أفعل ذلك أيضًا بالنسبة لـ Godot 2.2 أو 3.0

لن يكون هناك إصدار 2.2 ، فقد نقل مطورو Godot جميع ميزات 2.2 إلى 3.0.

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

قلقي الرئيسي هو أنه مع دعم C # المضاف ، سيتم ترك GDscript وراءها أو رؤية تطوير أقل بعد تدفق مطوري Unity. C # هي لغة جيدة ولكنها ليست المفضلة الشخصية

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

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

zaywolfe تم التعبير عن قلقك عدة مرات من قبل مستخدمين آخرين. لديك ما يدعو للقلق. ستظل GDScript هي اللغة الرئيسية في Godot.

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

أيضًا ، أود أن أذكر أنني أحيانًا أستخدم Godot لبعض النماذج الأولية للبرامج. وبالتالي ، من المحتمل أن تفتح لغة البرمجة شديدة التكامل الأبواب أمام تطوير البرامج داخل المحرك. سيكون هذا حقا قاتل الوحدة. (إذا تم اختيار Java أو C ++ بالطبع)

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

VenHayz لا أعرف ما إذا كنت تقرأ وثائق Godot ، ولكن يمكنك بالفعل كتابة ألعابك بلغة C ++ ، منذ الإصدار الأول من Godot - http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

ماذا عن استخدام Microsoft. net core؟ إنه نظام أساسي يركز على الأداء ، بالإضافة إلى أنه مفتوح المصدر ويتم تطويره بنشاط

مرحبا مجرد رجل عشوائي يمر

أردت إخبارك بأنني لا أستخدم Godot لأنني لا أحب لغة النص التي تستخدمها

إذا قمت بإضافة Java أو C # ، فسأقوم بتثبيت واستخدام godot بعد الإعلان مباشرة :)

RUSshy وداعًا إذن ، إنها خسارتك ، Godot رائع ، GDScript رائع ، إذا كنت مبرمجًا حقيقيًا ، فسوف يستغرق الأمر ساعتين حرفيًا لمعرفة ما يكفي لبدء أي مشروع. يجب على المبرمجين الحقيقيين إتقان العديد من اللغات ، يمكنك التمسك بـ java / C # الخاص بك وأن تكون شابًا "عشوائيًا" يمر بهواة إلى الأبد. أنا لا أحاول أن أكون وقحًا ، فقط أذكر الحقائق. إذا كنت لا تحب شيئًا عن هذا المحرك ، فقم بالمساهمة ببعض التعليمات البرمجية ، فهو مجاني على عكس معظم المحركات الأخرى.

يفضل إله التسويق C #. : يضحك:

RebelliousX اختيار Java أو C # يعني أنه سيكون لديك تحميل مكتبة لاستخدامها

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

الاختيار مجنون في الوقت الحاضر لا تغلق ذهنك

RUSshy هل تمزح معي؟ لقد كتبت (والعديد من الآخرين) حرفياً صفحات من التفسيرات حول فوائد GDscript على C # وتعتقد أنه يمكنك حل المناقشة بفقرة قصيرة واحدة دون قراءة أي شيء قيل من قبل؟

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

جدياً ، جرأة بعض الناس ...

لقد قيل عدة مرات في أماكن مختلفة أن وحدة تكامل C # قيد العمل. إنها تسير بسرعة مقدار الوقت الذي يتعين على الناس القيام به. الطريقة الوحيدة لجعله أسرع هي المساهمة في هذا التكامل :)

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

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

إن مستقبل Godot من حيث البرمجة النصية واضح جدًا بالفعل:

• ستبقى GDScript كلغة رئيسية وهناك خطط أو أفكار لتحسينها (ولكن هذا ليس المكان المناسب لمناقشة ذلك).
• بدءًا من 3.0 ، سيتم دعم C # كبديل للبرمجة. سنوفر ثنائيات منفصلة لتجنب فرض الحجم الإضافي الناجم عن وقت التشغيل الأحادي على الأشخاص الذين لن يستخدموه.
• DLScript قيد العمل أيضًا. سيسمح للأشخاص باستخدام المكتبات المشتركة للبرمجة النصية. يمكن كتابة هذه المكتبات بأي لغة تدعم ارتباط c والمكتبات المشتركة (توقع لغات مثل Rust و D). ليس من الواضح بعد ما إذا كان سيكون جاهزًا لـ 3.0 رغم ذلك (إلا إذا كنت قديمًا).
• لا تنس أنه سيكون هناك برمجة نصية مرئية في 3.0 أيضًا!

إذا خطط شخص ما للمساهمة بشيء آخر ، فلن يكون هذا هو المكان المناسب لمناقشة ذلك أيضًا.

أعتقد أن هذه القضية يمكن وينبغي إغلاقها.

متفق.

هل يمكن من فضلك توفير رابط لأكواد مصدر التكامل C #؟

https://github.com/neikeq/GodotSharp

كيف وظيفية تكامل GodotSharp؟ جاهز للاستخدام للاختبار؟
يمكن استخدامها مع مصدر البناء من godot master؟

nictaylr لا يتم البناء مع السيد حاليًا. إذا كنت ترغب في اختباره ، فأنت بحاجة إلى استخدام 2.2-legacy. إنه يعمل مع هذا الإصدار جيدًا

أنا أعمل على أن يكون جاهزًا لـ 3.0 ألفا في أبريل.

فكرة عشوائية ، ولكن بعد التفكير بعمق في ++ C مع Godot ، فكرت في شيء ربما يكون أفضل. لغة د. إنه يقع ضمن حصة لغة "منخفضة المستوى" يمكن القول إنها تتفاعل مع دعم C و (بعض) C ++. بها فصول ، وهي حديثة جدًا. على الرغم من أنه يبدو مخيفًا ، إلا أنه يشبه إلى حد كبير GDScript ، ويمكنني أن أرى أنه يتم استخدامه لتشغيل مشاريع كبيرة جدًا. إنها قوية بما يكفي للتنافس مع C و C ++ (gcc / g ++) مع مترجم يسمى GDC. (يمكن أيضًا استخدام DMC للترجمة ، لكن GDC يجمع مباشرة إلى دول مجلس التعاون الخليجي) شاهد المزيد عن GDC هنا

على أي حال ، مجرد اقتراح سريع أو ربما لأفكار.

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

@ karroffel هذا رائع حقًا. ليس لدي أي خبرة في كتابة المكتبات وواجهات برمجة التطبيقات (إشارة إلى ذكر "الارتباطات") على الرغم من أنه يمكنني على الأرجح البحث عنها لمدة يوم والقيام بذلك ؛ أنا بفخر سريع التعلم. أود الاتصال بك على Discord ، إذا كنت لا تمانع؟ خلافي: _hasCat # 3941

VenHayz لا يمكنني إضافتك ، فأنت لا تسمح للآخرين بإضافتك. Karroffel # 8409 أو انضم إلى خادم Godot

neikeq هل ريبو GodotSharp هو قاعدة الكود التي يتم استخدامها لدعم C # في Godot 3.0؟ أسأل فقط لأنني أحاول الحصول على فكرة تقريبية عن الميزات التي ستكون متاحة وسألتفت حول قاعدة التعليمات البرمجية هذه إذا كان الأمر كذلك. شكرا!

أنا أنظر godotsharp ، عفا عليها الزمن؟ ميزة جديدة ؟ أو جاهز للاستخدام في تطوير البناء؟

كيف يمكنني تجميع godosarp من soruce لي؟

nictaylr ستحتاج إلى استخدام الفرع 2.2-legacy

أعتقد أنني قرأت ما يكفي لمعرفة ما إذا كان شخص آخر قد ذكر ذلك.

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

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

تخيل إحضار البيرة إلى حفلة للأطفال. هل تقول أنه "لا داعي للكراهية على شخص يساهم بمشروب جديد"؟ هناك فرصة جيدة أن تؤدي إضافة C # إلى الإضرار بتطوير GDscript. أعلم أن الجميع مصمم على إبقاء GDscript هو اللغة الأساسية لـ Godot ، لكنه لا يزال يزعجني عندما تم شرحه عدة مرات لماذا إضافة ميزات جديدة لها جوانب سلبية وما زال الناس يسألون "ما الضرر؟".

كما أن طلب C # بدلاً من GDscript لأن "لا تريد أن تتعلم" هو حجة غبية حقًا. من بين جميع اللغات التي أعرفها في تطوير الألعاب ، يحتوي GDscript على أقل الميزات و C # لديه أكثر من ذلك بكثير. إذا كنت لا تريد أن تتعلم ، فيجب أن تكون ممتنًا لـ GDscript.

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

كما أن طلب C # بدلاً من GDscript لأن "لا تريد أن تتعلم" هو حجة غبية حقًا.

لا أمانع في تعلم C # لأنني قد أتمكن من استخدامها في مكان آخر.

فقط قم بإغلاق الخيط ، يصبح الأمر لئيمًا.

صحيح أن هذا الخيط قد خدم غرضه ، فلنقفله.