حقا أحب منشورك.

تعديل:
اللعنة انها تغاضت عن هذه الفقرة

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

لذا فقد غطيت بشكل أساسي المخاوف التي كانت لدي. (آسف)
أنا فقط أتعمق أكثر في كيف أتخيل سير العمل + السلوك.

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

إذا كانت الأصول مخفية في مجلد .local/godot/assets ، فستفقد هذه الوظيفة نوعًا ما.

عرض

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

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

بمجرد أن تريد تحرير / حفظ / تحديث ملف من أحد الأصول ، ستتم مطالبتك بخيارين

حفظ في .local/godot/assets

إما تحديث الأصل في .local/godot/assets مما يضعه في إصدار مستخدم مخصص.
إذا كان مدير الحزم قائمًا على git ، فيمكن أن يكون إصدار المستخدم المخصص التزامًا إضافيًا واحدًا. الذي يحصل على commit --amend ed كلما قمت بالحفظ.
( 3.2.5/user على سبيل المثال) وهو متاح في جميع مشاريعك الأخرى أيضًا. (عند تحديث الإصدار في تلك المشاريع الأخرى إلى إصدار المستخدم الخاص بك)
لماذا هذا مفيد
يكاد يكون المظهر من متجر الأصول مثاليًا ، لكنك تكره نوع الخط ...
قم بتغيير نوع الخط واحفظه كإصدار أصول جديد. أعد زيارة جميع مشاريعك الأخرى وقم بتغيير إصدار الأصل إلى /user . الان انت سعيد.
ربما يوجد أيضًا زر واحد لنشر إصدار المستخدم من الأصل.
لذلك في متجر الأصول ، يكون لدى الأشخاص الآخرين خيار اختيار إصدار مستخدم مع تعديلات طفيفة.
فقط كوسيط لإجراء العلاقات العامة للأصل git repo. (أو مؤلف أداة إزالة الأصول لاختيار التغييرات من إصدار /user إلى إصدار جديد في الإصدار الرئيسي.)

اجعل المشروع محليًا

نسخ الملفات من المجلد .local/godot/assets إلى المشروع الحالي ... يزيل أي سلوك خاص للأصول (مثل الإصدار ...) والآن يمكنك العبث به كما تريد. (كما يفقد المجلد مظهره المخصص كأصل.)

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

افكار عشوائية

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

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

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

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

توجد مشاكل في وجود أشياء في المكونات الإضافية:

• يحتاج الناس إلى معرفة ما يبحثون عنه في المقام الأول. يستهدف Godot المبتدئين . عادةً ما تحاول البرامج الصديقة للمبتدئين الحصول على كل ما يحتاجه شخص ما (بشكل معقول) ، وإلا فسيحتاجون أولاً إلى معرفة ما ينقصهم وكيف سيحصلون عليه.
  هناك سبب لاستخدام المبتدئين لـ Ubuntu وليس Gentoo. بغض النظر عن مدى روعة إنشاء نظام التبعية هذا.
• شلل القرار موجود. إذا كانت هناك ميزة في Godot ، فهي رائعة ، تستغرق ثانية لاستخدامها. إذا كان هناك 5 مكونات إضافية لها ، فما الذي سأستخدمه؟ على سبيل المثال ، هناك أكثر من 5 مكونات إضافية لوحدة التحكم . أيهما يجب أن يختاره المبتدئ ، ولماذا ، وكم من الوقت يجب أن يقضيه بشكل معقول في هذا القرار؟
• يتم التخلي عن المكونات الإضافية ، وتتميز بجودة أقل ، وتتخلف عن الركب عند التحديث. هناك سبب أقل للثقة في أن المكون الإضافي العشوائي لن يفجر علي من الوثوق بجودو ، حيث يوجد عدد كافٍ من الأشخاص وراءه.
• انظر الوحدة . يتم دفع أصولهم في الغالب ، ولا يزال الأمر صعبًا بالنسبة للعديد من الأشياء التي تحتاجها أولاً ، والتي يتم دمجها بشكل سيء في النهاية أو تعطل التحديثات - أو توقف ، على الرغم من أنها مدفوعة الأجر وعادة ما تكون قادرة على تحمل بعض الدعم على الأقل.
• التوثيق : ليس لدينا ما يكفي من هذا على أي حال. كل ميزة ليست جوهرية ، لا يمكنني استخدامها في البرامج التعليمية / المستندات الرسمية. من المحتمل ألا يوفر الأشخاص الفرديون العشوائيون للمكونات الإضافية مستندات ، أو أمثلة قصيرة فقط ، وليس الجزء الأكثر قيمة في توفير العروض التوضيحية أو البرامج التعليمية الكاملة حول كيفية دمج هذه الميزة مع الآخرين بسلاسة في المشروع.

أمثلة:

• عقدة ذراع الربيع. (https://github.com/godotengine/godot/pull/18822) إضافة صغيرة بشكل معقول ، مقسمة إلى فئتها الخاصة لذلك لا ينبغي كسر الأشياء ، سيتم استخدامها في العديد من الألعاب ثلاثية الأبعاد ، إن لم يكن من قبل كل لعبة فردية . الرد: يجب أن يكون مكونًا إضافيًا.
• حتى بالنسبة إلى عناصر RNG ، تمت مناقشة الحصول عليها كمكوِّن إضافي. كما لو أن 90٪ من الألعاب تحتاج إلى RNG في مكان ما.

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

karroffel هذا منشور ممتاز وأنا أتفق في الغالب مع كل ما قلته. ومع ذلك ، أود التعليق على هذه النقطة:

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

هذا مشابه لكيفية عمل نظام Python pip. أدرك الناس بعد ذلك أن أحدث إصدار من الحزمة قد أفسد المشاريع الأخرى التي لديك في نظامك. Virtualenv يحل هذه المشكلة. في النظام البيئي npm الخاص بجافا سكريبت Javascript ، يتم تثبيت الوحدات النمطية محليًا على مشروع افتراضيًا وتعتبر ميزة الاشتراك على مستوى النظام ( npm install --global ). بعد ذلك ، تحقق من package-lock.json للتحكم في المصدر للتأكد من أن كل فرد في الفريق يستخدم نفس الإصدار من كل وحدة npm وتجنب التعارضات.

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

إذا ذهبنا إلى المسار الواسع للنظام ، فإنني أقترح الاحتفاظ بتثبيت الإصدار. علي سبيل المثال:

.local/godot/assets/fsm/1.0
.local/godot/assets/fsm/1.1

يمكن أن يستخدم المشروع A fsm-1.0 بينما يستخدم المشروع B fsm-1.1. يأتي المشروع C ويمكن إعادة استخدامه أيضًا. يجب أن يكون المستخدمون قادرين على تحديد إصدارات معينة من المكونات الإضافية في ملفاتهم dependencies.json أو الحد الأدنى من التصحيح ، الإصدارات الثانوية أو الرئيسية.

بمجرد تنزيل التبعيات ، يمكن إنشاء ملف dependencies-lock.json والتحقق منه في التحكم بالمصادر.

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

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

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

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

أنا سعيد لأن هذا أثار بعض المناقشة بالفعل: أحمر الخدود:

إليكم وجهة نظري في النقاط أعلاه:

دفع الأشياء خارج المحرك

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

يجب أن تكون الفلسفة بالنسبة لي هي أن شيئًا ما يجب أن يكون جزءًا من المحرك فقط إذا تم استيفاء جميع المعايير أدناه:

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

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

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

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

يجب أن تبدو الامتدادات وكأنها جزء من المحرك

بخصوص هذه النقاط:

• تسهيل توسيع العقد المخصصة ، والسماح بوراثة البرنامج النصي عبر اللغات

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

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

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

• لا يُقترح توريث البرنامج النصي عند إرفاق برنامج نصي - التجاوز هو الإعداد الافتراضي لتلك الحالات.

يجب القيام بذلك بالتأكيد وسيكون إضافة مرحب بها للغاية.

• إضافة إدارة التبعية المناسبة مع عمليات تثبيت الأصول على مستوى النظام. انقل الإضافات من المشروع نفسه مع طريقة لإعادتها للتعديل

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

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

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

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

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

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

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

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

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

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

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

الآن بالطبع لا يمكننا فقط تضمين كل اقتراح يتم تقديمه إلينا ...

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

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

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

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

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

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

tl ؛ dr : الإرشادات مفيدة عند استخدامها كإرشادات وليست قوائم تحقق.

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

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

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

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

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

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

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

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

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

في الأحد ، 10 يونيو 2018 الساعة 13:51 كتب PLyczkowski [email protected] :

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

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

-
أنت تتلقى هذا لأنك علقت.

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

تمت تجربة برنامج نصي متعدد لكل عقدة عدة مرات وفشل دائمًا.

ما تمت تجربته هو العقدة متعددة النصوص ، لكنها كانت صعبة

في الأحد ، 10 يونيو 2018 الساعة 15:01 كتب Zireael07 [email protected] :

تمت محاولة كتابة نصوص متعددة لكل عقدة عدة مرات ودائمًا
فشل.

-
أنت تتلقى هذا لأنك علقت.

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

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

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

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

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

يبدو الميراث عبر اللغات وكأنه فكرة مروعة بالنسبة لي.

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

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

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

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

سيعطي نظام TypeDB الذي أقوم بصنعه دعمًا للمحرر لـ ...

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

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

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

رؤيتي لجودو

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

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

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

أتخيل أن المستخدمين قادرون على تنزيل المكونات الإضافية والأصول التي تشعر أنهم "يوسعون" المحرك نفسه: اعتمادًا على ما تقوم بتنزيله ، لديك Godot-fps أو Godot-platformer أو Godot-Racing.

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

مزايا

TLDR: سيسمح هذا النهج لإدارة Godot بإدارة الميزات الأساسية التقنية المتشددة بشكل منفصل والمزيد من المكونات الإضافية سهلة الاستخدام دون القلق كثيرًا بشأن تضخم المحرك

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

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

حول الميراث متعدد اللغات

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

ملاحظة حول سهولة الاستخدام

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

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

الآن هذا أيضًا نقاش ليوم آخر. الآن في الوقت الحاضر الحقائق ،

1. Godot هو محرك ألعاب مدمج وسريع ومحمول. وأنا أحب ذلك كثيرًا ولكن ....
2. يبلغ حجم ملف جودو القابل للتنفيذ حوالي 45-60 ميجابايت اعتمادًا على عوامل مختلفة. لكن يمكن أن يصل حجم قالب التصدير إلى 300 ميغا بايت. الآن هذه ضربة كبيرة للنقطة الأولى.
3. يحتوي Godot على الكثير من الميزات المذهلة التي تجعله متعة للمبتدئين مثل Camera Follow و Parallax BG و Vehicles ، وهذه ميزة كبيرة مقارنة بمحركات الألعاب المماثلة الأخرى. لأنه يجعل إنشاء الألعاب أكثر بساطة في Godot. ويجعل من Godot موطنًا للكثير من المطورين المبتدئين ، الذين لا يمتلكون المهارات اللازمة لكتابة تطبيقاتهم الخاصة لمثل هذه الأدوات.

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

ربما ، نعم ، ولكن في عالم لا يبدو أن أجهزة الكمبيوتر المكتبية تستخدم فيه أي شيء أقل من 256BG SSD + 1TB HDD وحتى الهواتف بها مساحة تبدأ من 16 جيجابايت كحد أدنى والتي من المرجح أن تزداد جميعها ، فهل سيكون ذلك سيئة؟
أعني أن أقول إننا لسنا بحاجة إلى إزالة أي شيء حتى الآن ، كل ما نحتاجه هو أن نبدأ في إدارة بعض الأشياء بشكل أفضل ويجب أن يكون الأمر كذلك.
يجب أن تحتوي الميزات على نوع من قائمة الأهمية ليتم تحديدها إذا كان من المفترض أن تكون في جوهرها أم لا ، لكن هذا لا يعني أنها تصبح قانونًا بل قاعدة عامة.

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

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

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

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

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

1. يبلغ حجم ملف جودو القابل للتنفيذ حوالي 45-60 ميجابايت اعتمادًا على عوامل مختلفة. لكن يمكن أن يصل حجم قالب التصدير إلى 300 ميغا بايت. الآن هذه ضربة كبيرة للنقطة الأولى.

300MB قوالب التصدير؟ هل تقصد مع الأصول؟

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

إذا كنت تريد "تمديد" العقدة ، فلا يمكنك ذلك! أعتقد أنه يمكنك إضافة عقدة فرعية لإضافة وظائف جديدة ، ولكن بهذه الطريقة لا يمكن تجاوز الأشياء.

تطبيق

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

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdnative/nativescript/nativescript.cpp#L696 -L712

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdscript/gdscript.cpp#L638 -L651

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/mono/csharp_script.cpp#L1175 -L1191

النمط هنا

Class *c = bottom;
while (c) {
    if (c->has_method(m)) {
        c->call(m);
        break;
    }
    c = c->base;
}

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

إذا كان كل نص برمجي يحتوي على Ref<Script> parent_script بدلاً من بنية التوريث الخاصة باللغة ، فيمكن تعميم ذلك على

if (this_class->has_method(m)) {
    this_class->call(m);
} else {
    // method not declared here, go to base class
    parent_script->call(m);
}

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

neikeq انظر هذا ،

swarnimarun هذا تصدير قوالب لجميع المنصات ، وجميع الأقواس المدعومة ، وتصحيح الأخطاء وإصدارها ، وحجمها لا علاقة له تمامًا بـ "سخام" المحرك. يمكننا أن نقرر دعم إصدار Linux X11 64 بت فقط وسيكون هذا الملف 20 ميغابايت ...

@ akien-mga لم أكن أنوي تسميته ، سخام.
لكن المستخدم الجديد سيقوم بتنزيله بالحجم الكامل ولن يكون لديه خبرة كافية ليعرف أنه بإمكانه البناء بشكل منفصل أو التنزيل لمنصة معينة.

كيف يكون غير ذي صلة عندما يكون هذا ما نقدمه للمستخدمين المبتدئين؟

@ akien-mga: حجم قوالب التصدير مهم منذ أن كانت حجتك لإزالة العقد

نشر مصفوفات الحجم (جوّال ، html5)

swarnimarun @ Zireael07 نعم حجم قوالب التصدير مهم بشكل فردي ، لكن وجهة نظري هي أن قياس حجم حزمة من القوالب لا يعطينا أي إشارة. حجم القالب الواحد (على سبيل المثال ، نموذج إصدار wasm ، أو حجم 3.4 ميغابايت مضغوط ، أو APK لإصدار Android ، 23 ميغابايت مضغوط بواسطة armv7 و x86 libs) أكثر ملاءمة من "تنزيل كل ما يلزم للتطوير يستغرق 350 ميغابايت" (+ ربما 10 GB لـ Visual Studio إذا كنت بحاجة إلى بناء شيء ما ...). ما يهم إذا كان الحجم الأدنى للعبة على المنصات حيث يكون الحجم مهمًا (الويب والجوال).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تحرير: أو "شوكة" الملحق 😜

neikeq ما تقوم بتعديله موجود داخل مشروعك. عندما تريد تعديل ملحق يتم نسخه داخل مشروعك ويتم تعديله محليًا فقط.

karroffel قد تكون هناك حاجة إلى فكرة عن مكون إضافي للمشروع ومكوِّن إضافي للمحرر لتجنب الالتباس ، مع الفصل الواضح بين الاثنين.

QbieShay ماذا لو كان هناك تحديث يقوم بتعديل الملفات التي قمت بتعديلها؟

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

إذا كان لدينا خيار لإلغاء الطرق في Script API ، فسيكون ذلك جيدًا أيضًا! (تحديد طرق جديدة خارجيًا بشكل أساسي وتجاوز الأساليب الحالية).

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

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

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

لا يوجد خط أسود / أبيض عندما يجب أن يكون هناك شيء ما داخل المشروع وعندما يكون بالخارج ، سواء كان محررًا أم لا.

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

ماذا لو كان هناك تحديث يقوم بتعديل الملفات التي قمت بتعديلها؟

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

الفكرة هي

• خارج المشروع: أسهل في التحديث ، وأسهل في أن يكون لديك مشروع مشترك
• داخل المشروع: قابل للتخصيص ، ويفقد حالة الأصول ، ولا توجد تحديثات تلقائية

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

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

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

2 سنتي على أي حال.

@ ايس التنين

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

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

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

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

Ranoller نعم ، أعتقد أنك فهمت جوهر اقتراحه.

بعض ردود الفعل على ما تناقشه يا رفاق

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

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

3) لا أحب فكرة إدارة الحزم نفسها. لقد رأيت مستخدمي Unity يخترقون ما يحصلون عليه من مخزن الأصول بلا نهاية في الغالبية العظمى من الوقت. في كثير من الأحيان يستخدمونها فقط كقاعدة ، ثم يعملون عليها وتخصيصها لاستخداماتهم الخاصة ، لأن الأصل الذي تحصل عليه هو فقط 60/70 ٪ من الطريقة التي تريدها .. أو أنهم يريدون فقط رؤيتها كيف يتم ذلك ثم يقومون بعملهم لاحقًا.

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

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

reduz كيف تعمل البرامج النصية المتعددة؟ وكيف ستساهم في تمديد المحرك؟ هل شرحت فكرتك في قضية موجودة؟ (يسأل لأنه ربما يكون هناك الكثير لشرح ذلك في هذا الموضوع)

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

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

بالنسبة لمخاوف الانتفاخ ، فأنا أقدر المزيد من التحكم في _modules_ بدلاً من ذلك ، وقد تم التصويت على هذا بالفعل في استطلاع Patreon لشهر يناير 2018:

أولوية خارطة الطريق: المزيد من الخيارات لإلغاء الاشتراك في تجميع أجزاء من المحرك لإنشاء أحجام ثنائية أصغر [متوقع لـ 3.1]

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

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

أنا أتفق مع reduz على أن النواة يجب أن تكون بسيطة. في رأيي ، يجب دمج أي شيء وكل شيء لا يمكن تصنيفه على أنه "أساسي" بشكل مستقل. كمستخدم ، أتوقع أن تكون Godot لعبة متعددة المنصات _engine_. إذا كنت أرغب في godot _game framework_ (المركبات ، الكاميرات المقحمة ، التضاريس ، أجهزة التحكم في المشغل. إلخ) ، فيجب أن تكون متاحة كإضافة من الدرجة الأولى (أو وحدة؟) مستقلة عن النواة. أعتقد أن تحسين القصة الإضافية يساعد في ذلك ، ولكن يبدو أن مدير التبعية الكامل ومدير الملحق الآلي يدفعان بها لتحقيق صافي فائدة منخفضة.

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

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

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

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

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

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

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

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

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

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

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

vnen إذا قمت بالإشارة إلى جميع الأصول بالاسم ، فستكون هناك فوضى متضاربة. هذا أكثر ملاءمة للنصوص حيث يتعين على المبرمجين فقط التوصل إلى أسماء فريدة لفئاتهم لكتابتها واستخدامها (أو نادرًا ، الموارد). بالنسبة للأشياء الأخرى ، إذا تخلصنا من المسارات ، فستحتاج إلى https://github.com/godotengine/godot/issues/15673 ، إلا إذا كنت تريد أيضًا أن يضطر الفنانون والمصممين وما إلى ذلك إلى تسمية جميع أصولهم بشكل فريد (والتي لا يزال يأتي مع مسألة إعادة التسمية).

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

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

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

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

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

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

لذلك ، ربما يكون لديك "مفضلات المحرر" و "مفضلات المشروع" لـ "أريد هذا في كل مشروع ، قم بتخزينه في موقع مشترك وقم بعمل رابط رمزي" و "أريد هذا في كل مشروع ، قم بتكرار ذلك" ، على التوالي.

ربما يكون من الأنسب إذن أن يكون لديك "حزم" من المكونات الإضافية - أنشأها المستخدم وموافق عليها رسميًا + محلي أنشأه المستخدم. لذا فبدلاً من "مفضلات المحرر" و "مفضلات المشروع" لدينا "First Person Shooter" أو "Voxel Block Game" أو "أشيائي" فقط. يشبه إلى حد كبير على سبيل المثال أصول Unity Starter ، ولكن لا داعي لتضخيمها بالقوام وما إلى ذلك ، يجب أن تكون الأنواع المختلفة من وجوه Godot التميمة كافية: D

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

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

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

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

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

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

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

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

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

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

الشيء الذي يتم تجاهله ولكن في رأيي هو أحد الأسباب التي تجعل الناس يطلبون إضافات في المحرك الأساسي هو هذا: من الذي سيجمع هذا الشيء لجميع المنصات؟

بالطبع بالنسبة لمكوِّن gdscript الإضافي ، فهذه ليست مشكلة ، ولكن بالنسبة لمكوِّن Cpp الإضافي ، فهذه مشكلة كبيرة.

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

لذا في رأيي يجب أن نحل هذه المشكلة أولاً ، وليس لدي أي فكرة عن كيفية القيام بذلك. هل من الممكن على سبيل المثال التحويل البرمجي لجميع الأنظمة الأساسية من خلال Linux؟ إذا كان الأمر كذلك ، فقد نستخدم شيئًا مثل Ubuntu Imager: https://www.maketecheasier.com/create-linux-distro/ لإنشاء بيئة Linux مُعدة بالفعل لصانعي الإضافات ومستخدمي GDNative.

هل من الممكن على سبيل المثال التحويل البرمجي لجميع الأنظمة الأساسية من خلال Linux؟ إذا كان الأمر كذلك ، فقد نستخدم شيئًا مثل Ubuntu Imager: https://www.maketecheasier.com/create-linux-distro/ لإنشاء بيئة Linux مُعدة بالفعل لصانعي الإضافات ومستخدمي GDNative.

لا (لا يمكن تجميع إصدارات macOS و iOS إلا من macOS) ، ولا أعتقد أن إجبار الأشخاص على تشغيل نظام تشغيل Linux مباشر حتى يتمكنوا من تحميل مكتبات GDNative إلى مكتبة الأصول فكرة جيدة.

ومع ذلك ، من الممكن إجراء ترجمة لجميع الأنظمة الأساسية التي تستخدم Travis CI و AppVeyor ، والتي يمكنك إعدادها مجانًا في مستودعات GitHub العامة.

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

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

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

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

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

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

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

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

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

نعم ، ويجب أن يكون من السهل أيضًا تثبيت حزم غير متصلة بالإنترنت.

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

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

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

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

بافتراض التسجيل "الملحق" العام على النظام:

• قم بتنزيل الملحق v1.3 من نظام الوظائف الإضافية عبر الإنترنت. تم تثبيت الملحق على ~/.godot أو ما لا
• يتم ربط الإصدار بمشروعي على ~/my-project في نوع من المتجر المحلي (ملف ، sqlite ، إلخ.)
• أقوم بالترقية إلى الإصدار 1.4. الآن يجب أن يعرف مدير الملحق الخاص بي أن 1.3 لا يستخدم من قبل أي مشروع وأن يقوم بتنظيفه. لذلك فإن المدير لديه وظائف إضافية لتتبع التبعيات والمشروعات التي لها ما تبعيات. بدلاً من ذلك ، لا أحد يضيف هذه الوظيفة حتى يتلوث جهازي المحلي بإصدارات متعددة من نفس الملحق
• قررت أنني أريد نقل مشروعي إلى ~/big-project/game . الآن أنا بحاجة إلى طريقة لتحديث الإشارة إلى مشروعي في التسجيل الإضافي. كيف يمكنني فعل ذلك؟ هل يجب علي تشغيل مدير الملحق بشكل منفصل؟ Manager register new_proj_location ؟
• تم اتخاذ القرار الآن لتخزين التبعيات محليًا على غرار Python requirements.txt . عظيم ، تم حل المشكلة. باستثناء أنني عدت إلى عدم معرفة المشاريع التي تعتمد على الحزم العالمية ، فلا بد لي من فحص النظام لمشاريع godot أو تسجيل كل مشروع لتجنب تراكم الإصدارات.
• حسنًا ، أنا فقط أعمل على حل المشكلة. تنظيف الحزم الميتة يدويًا من وقت لآخر. لذلك أنا أعمل على VehicleBodyAddon لمشروعي باستخدام الإصدار 1.5. آه ، إنه يستخدم F * M لحساب التسارع ولكني أريد أن أفعل F * M * 5. دعني أقوم بتعديل الكود بسرعة ... عفوًا ، هناك تذهب جميع مشاريعي الأخرى التي تعمل على هذا الملحق.
• اسمحوا لي بإنشاء ملحق جديد يعتمد على الملحق الآخر. حسنًا ، أحتاج الآن إلى التسجيل لأن الملحق المخصص الجديد الخاص بي يعتمد على الملحق الحالي. الآن أنا بحاجة إلى تمديد المدير ليس فقط لتنزيل الوظائف الإضافية من موقع بعيد ولكن أيضًا للعمل مع المسارات المحلية أو مستودعات git أو شيء من هذا القبيل.

بافتراض الإضافات "الموردة":

• تنزيل الملحق إلى الدليل الإضافي
• تحديث تجاوزات في الدليل

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

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

قررت أنني أريد نقل مشروعي إلى ~/big-project/game . الآن أنا بحاجة إلى طريقة لتحديث الإشارة إلى مشروعي في التسجيل الإضافي.

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

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

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

لذلك أنا أعمل على VehicleBodyAddon لمشروعي باستخدام الإصدار 1.5. آه ، إنه يستخدم F * M لحساب التسارع ولكني أريد أن أفعل F * M * 5. دعني أقوم بتعديل الكود بسرعة ... عفوًا ، هناك تذهب جميع مشاريعي الأخرى التي تعمل على هذا الملحق.

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

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

وحدات Git الفرعية. متطلبات أخرى. xt (مثل ما يفعله بيثون). أو أخبر المستخدم فقط أنه يتطلب إضافة X. ليس الأمر بالصعوبة التي تريدها. معظم مستخدمي Godot ليسوا أغبياء. إنهم يعرفون ما تعنيه عبارة "تتطلب هذه الوظيفة الإضافية: Add-on X Core ، Add-on Y ، Add-on Z".

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

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

يجب ألا يتعارض نظام إضافة البرنامج المساعد الجديد مع الاحترام res: // addons كما هو الحال الآن ... وهذا بسبب:

النظام الفعلي رائع ...

أكرر:

النظام الفعلي رائع ...

لا يوجد شكوى سابقة حول تلك النقطة.

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

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

التصميم الأبسط لإدارة الأصول الذي أقترحه هو

• يعد الحصول على تبعيات. أعتقد أن هذه المعلومات مطلوبة.
• لا ، لا تدع الأصول قادرة على تحديد التبعيات. لا أعتقد أن أصول Godot ستتمتع بقدر كبير من الاعتماد على بعضها البعض مثل وحدات npm. اسمح لمطور الأصول بالحالة في الوثائق إذا كان يعتمد حقًا على أصل آخر والسماح للمستخدم بالتثبيت يدويًا. سيؤدي هذا إلى تبسيط الأمور ولن نضطر إلى إنشاء شيء آخر للتحقق من التبعية وهو رمز bloat / المزيد من التعليمات للحفاظ عليه.
• لا ، لا تحفظ الأصول في موقع "عالمي". الاحتفاظ بها في مجلد إضافات المشروع أمر جيد بالفعل. يسمح لهم بالالتزام بالتحكم في المصدر بالمشروع ويسهل إدارتهم. حتى npm node_modules يحفظ وحدات المشروع داخل المشروع.
• الآن ، قم بتحسين مستعرض الأصول حتى يتمكن من سرد الأصول المثبتة التي تم تحديثها وتتيح لك تحديثها إذا كنت ترغب في ذلك.
• الآن ، من المنطقي أن تكون قادرًا على امتلاك إضافات "عالمية" لتلك الإضافات التي هي مجرد تحسينات للمحرر. لذلك لا تزال الوظائف الإضافية العادية تنتقل إلى مجلد الوظائف الإضافية للمشروع ، ولكن بالنسبة للوظائف الإضافية ذات الصلة بالمحرر ، لديك خيار تثبيتها عالميًا. يؤدي هذا أيضًا إلى نقل هذا الرمز خارج مجلد الوظائف الإضافية للمشروع حتى لا يدخل في حزمة الإصدار. (هذا مشابه لـ npm install -g لأدوات التطوير)

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

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

• إما أن يقوم كل مطور يجرؤ على امتلاك تبعية واحدة على الأقل بإعداد كود معياري لإظهار للمستخدم أنه يحتاج إلى تثبيت تبعية (حتى لو كانت الحزمة مجرد عرض توضيحي لهذا البرنامج المساعد!)
• أو هل الأصول على الأقل تشير إلى ذلك؟

أيضًا +1 لتحديث الأصول بسهولة ، لا داعي لتصفحها مرة أخرى في المكتبة.

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

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

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

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

@ eon-s إذن ، شيء من هذا القبيل اقتراح @ bojidar-bg؟

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

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

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

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

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

الرد على chanon هنا.

لا ، لا تدع الأصول قادرة على تحديد التبعيات. لا أعتقد أن أصول Godot ستتمتع بقدر كبير من الاعتماد على بعضها البعض مثل وحدات npm.

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

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

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

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

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

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

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

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

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

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

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

مناقشة مثيرة للاهتمام. العديد من المقترحات الجيدة كذلك.

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

أردت فقط تمرير إيماءة لبعض هذه الأفكار الشيقة.

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

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

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

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

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

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

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

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

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

مجرد فكرة أخرى مجنونة:

ربما سيكون من الممكن بطريقة ما التحويل التلقائي لـ GDNative C ++ إلى وحدة نمطية (بشكل مثالي إزالة طبقات المراوغة التي أنشأتها GDNative)؟ بعد ذلك ، قد يُرضي كل من مؤيدي نهج "كل شيء في ملف ثابت واحد قابل للتنفيذ" وأسلوب "ميزات الشريط بدون تثبيت برنامج التحويل البرمجي"

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

أخشى أن يؤدي ذلك إلى الإضرار بالأداء لأن GDScript ليس سريعًا جدًا.

يوم الجمعة 22 يونيو 2018 الساعة 11:10 مساءً ، Alan North [email protected]
كتب:

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

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

AlansCodeLog إذا كان يجب إزالتها تمامًا وتحويلها إلى ملحقات خارجية ، فسيكون من الجيد أن يكون لديك إصدار GDScript على الأقل ، حتى لا يحتاج المستخدمون إلى إعادة ترجمة المحرك (إذا كان هو ملفات C ++ الأصلية) أو تثبيت Mono ( إذا تم تحويله إلى GDNative). ومع ذلك ، فإن جزءًا من إجابتي الأصلية (انظر القسم الخاص بمستودع الامتدادات الرسمي) تضمن قلقي من أن إدخالها في الامتدادات سيؤدي فقط إلى إنشاء هذا النوع الغريب من السوق (لعدم وجود كلمة أفضل) إذا توقف المستخدمون عن تذكر أن هناك إعادة شراء إضافية يحتوي على ما يحتاجون إليه ، بغض النظر عن مدى الرسمية أو مدى حداثة النسخة الرسمية. ستأتي الوظائف الإضافية الجديدة إلى مكتبة الأصول التي سيكون بها "Node X with Feature X" و "Node X with Feature Y" وما إلى ذلك ("Node X" التي تمثل العقدة التي تم إنشاؤها في ملحق) - مما يؤدي إلى حدوث فوضى من الوظائف الإضافية التي تدعي جميعًا أنها تساعد في المركبات ولكن ليس لديها هذا المستوى أو التدقيق الذي قد تحصل عليه المزيد من العقد الرسمية.

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

لكن لماذا رغم ذلك؟ في هذه المرحلة ، لماذا لا ندع الأصول تحتوي على هذه التبعيات على أي حال لأنها لن تضر بأي شيء؟

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

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

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

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

كنت أفكر في هذا السيناريو المثالي لـ

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

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

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

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

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

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

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

فيما يلي بعض اقتراحاتي حول كيفية التعامل معها ،

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

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

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

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

1. اجعل الخادم يحتفظ بكل إصدار تم تحميله

2. السماح للمكونات الإضافية بتحديد إصدار معين من مكون إضافي معين

3. حاول استخدام نظام إصدارات عاقل للإضافات (يبدو أن Godot يستخدم امتداد
   Major.Feature.BugFix ترقيم الإصدار الذي يعجبني)

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

@ نغمتين فلماذا حتى جعل كل شيء مجانا سخام. ؟؟

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

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

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

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

ربما ، نعم ، ولكن في عالم لا يبدو أن أجهزة الكمبيوتر المكتبية تستخدم فيه أي شيء أقل من 256BG SSD + 1TB HDD وحتى الهواتف بها مساحة تبدأ من 16 جيجابايت كحد أدنى والتي من المرجح أن تزداد جميعها ، فهل سيكون ذلك سيئة؟

في قطاع أجهزة الكمبيوتر المحمول المحمولة وبأسعار معقولة ، فإن eMMC ما زالت حية وبصحة جيدة ، كما أن حجم 32 جيجابايت (مع أقل من 10 جيجابايت مجانًا) ليس نادرًا جدًا.

بالمناسبة ، في تلك الفئة من أجهزة الكمبيوتر المحمولة ، أعتقد أن نظام تصدير android الحالي قابل للاستخدام ، بينما النظام المخطط له (https://github.com/godotengine/godot/issues/18865) ليس كذلك. أنا أفهم مزايا النظام الجديد ، وبشكل عام ، ربما كنت سأصوت له بنفسي (عندما رأيت المشكلة لم تكن هناك مسابقة بالفعل) ، لكن يجب أن ندرك أننا نفقد حالة استخدام مهمة بسبب التغيير.

swarnimarun قد يكون هناك سوء تفاهم. عندما أقول "النظام" في ذلك التعليق ، فأنا أعني الخادم الذي يخدم المكونات الإضافية ، وليس المحرك. آسف إذا كان هذا هو ما تعثرت لك.

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

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

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

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

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

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

تجربتي في الواقع الافتراضي بعيدة كل البعد عن بعض هؤلاء. هناك سبب في أن الأمر يستغرق وقتًا أطول ، فأنا أرغب في الحصول عليه وتشغيله على الهاتف المحمول. نظرًا للطلبات ، خاصة على الهاتف المحمول ، لإعداد شاشات العرض بطرق مختلفة ، يجب عليك تغيير طريقة عمل النواة وإثبات صعوبة التقاطها في مكون إضافي.
OpenVR و OpenHMD حتى الآن كانا أسهل. Oculus لقد مررت بحل بديل ينظر إليه بازدراء ولكني سعيد به.
يجب أن يكون ARKit في جوهره ، فهو غير قابل للحل كوحدة نمطية ، على الأقل ليس في هيكلنا الحالي (لا تسمح Apple حتى بالمكتبات الديناميكية على نظام iOS لذلك هناك أيضًا).
يحتاج كل من GearVR و Daydream حقًا إلى أن يكونا في الصميم ، وهو استحالة لـ GearVR نظرًا لاستخدامها مكتبات الملكية.
Hololens / Microsoft MR أنا أسير في طريق معرفة ما إذا كان بإمكاني جعل هذا اختيارًا للنظام الأساسي ، ترى Microsoft ذلك بهذه الطريقة لأنه من المفترض أن تعمل التطبيقات بين الاثنين ويتم تثبيتها على Hololens كتطبيق هولوغرافي فقط.

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

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

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

لجعل قصة طويلة قصيرة ، حيث تكون المكونات الإضافية منطقية ، ادعم المكونات الإضافية ، لكن لا تفرط في ذلك.

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

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

IMO ، لا ينبغي إزالة أي من هذه من المحرك. عقد التحكم وعقد الفيزياء (مثل السيارة) وحتى دعم Terrain غير الموجود حاليًا:

أستخدم Godot لأنه تطبيق متكامل قائم بذاته إلى حد ما.
إذا كنت بحاجة إلى تنزيل Godot في المستقبل ، ثم ابحث عن السيارة ، وعقد التحكم ، ودعم Terrain ، ومحرر Shader ، ومكوِّن Navmesh الإضافي اللائق وتشغيله - باستخدام المكون الإضافي الحالي ونظام AssetLib - فلا شكرًا.

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

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

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

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

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

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

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

الآن بعد أن تم حل المشكلة ، العوامل الرئيسية التي تشجعنا على التفكير في إبقاء بعض الأشياء ("بعضها" يتعين تحديدها) خارج المحرك هي:

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

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

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

حسنًا ... إذا احتاج شخص ما إلى أفكار لبدء الميزات الخارجية بالإضافة إلى VehicleBody المسمى بذلك ، فأنا أريد أن أتذكر بعض العقد والفئات المفقودة من godot 2 إلى 3: ParticlesAttractor2D (عقدة) و EventStreamChibi (هذه الفئة مثالية لأصل خارجي ) ، أعلم أن الجرار الجسيم غير متوافق مع نظام الجسيمات الفعلي ، ولكن ... ماذا عن استعادة وظائف godot المفقودة في شكل أصول خارجية (Ej ، نظام الجسيمات القديم يتعايش مع الجديد ....). ربما يريد شخص ما الاحتفاظ بهذا الرمز في مستودعات منفصلة ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إذا كنت بحاجة إلى تنزيل Godot في المستقبل ، ثم ابحث عن السيارة ، وعقد التحكم ، ودعم Terrain ، ومحرر Shader ، ومكوِّن Navmesh الإضافي اللائق وتشغيله - باستخدام المكون الإضافي الحالي ونظام AssetLib - فلا شكرًا.

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

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

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

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

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

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

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

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

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

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

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

addons/
    addon_name/
        plugin.cfg
        ...other files

ما أقترحه هو توسيع مخطط plugin.cfg وإضافة القدرة على الحصول على قائمة إصدارات التبعية مع خيار تجزئة الالتزام (أو اسم الفرع / العلامة) لاستخدامه. قد ينجح شيء مثل ما يلي:

[plugin]
name="foo"
description="foobar"
author="blah"
version="1.0.0"
script="plugin.gd"

[dependency]
name="dep1"
path="github.com/foo/dep1"
hash="7fc2367508c41cfab86eaf7d84e04cd122978fdb"

[dependency]
name="dep2"
path="github.com/foo/dep2"
tag="v3.1.2"

[dependency]
name="dep3"
path="github.com/foo/dep3"
branch="big-refactor"

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

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

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

الحاجة إلى عقد متعدد النصوص

هذا موضوع ساخن آخر في هذه القضية بالفعل ، وبصراحة ، ليس لدي طريقة جيدة جدًا للتعامل مع هذا دون تغيير الأيديولوجية الأساسية لكيفية استخدام Godot. قد يكون هذا أو لا يكون جيدًا ، ولكن نعم ... على أي حال ، هذه ليست مشكلة كبيرة بالنسبة للمكوِّن الإضافي _المؤلفون _ كما هو الحال بالنسبة للمكوِّن الإضافي _ المستخدمين_ (غالبًا ما يكون نفس الشخص ؛).

في النهاية ، إذا تمكنا من حل هذين الأمرين ، أعتقد أننا سنكون هناك بنسبة 90٪. نسبة الـ 10٪ الباقية ليست صفقة كبيرة في رأيي ، وربما ينبغي التعامل معها من منظور إصلاح البنية الأساسية للأصول ، والتي في رأيي يمكن أن تنتظر بعد قلي سمكة أكبر بكثير.

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

تبدو إدارة التبعية رائعة بالنسبة لي. : مبتسم:

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

ما لم يتمكن شخص ما من التوصل إلى طريقة بسيطة للتعامل مع صراعات التبعية من أعلى رأسه

أعتقد أن حل ذلك سيعتمد على كيفية استدعاء المكون الإضافي للكود
مكون إضافي مختلف. إذا قمنا بإعداده بحيث تعمل البرامج النصية للإضافة
extends "dep2/folder/script.gd" ، عند التثبيت يمكننا تغيير dep2
إلى dep2-v3.1.2 . بالنسبة إلى التجزئات ، يمكننا فقط استخدام أول 5 أرقام (ما لم يكن
نريد مجلدات بأسماء لا يقل طولها عن 42 حرفًا). في 5
أرقام فرصة الاصطدام صغيرة بشكل لا يصدق.

أنا متعب بعض الشيء الآن ، لذلك ربما أفتقد شيئًا ما ، لكني لا أرى
أي قضايا.

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

نعم ، أعتقد أن معرّف الأصل والنسخة فقط يجب أن يكونا كافيين.

قد يكون تحديد مستودع Git / الفرع / العلامة / التجزئة طريقة اختيارية لتحديد التبعية ، لكن الطريقة الرئيسية يجب أن تكون عن طريق معرف الأصل.

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

قد تبدو مواصفات التبعية بعد ذلك

[dependency]
asset_id="some_asset"
version="1.0.0"

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

Zylann ربما سأستخدم نفس الأسلوب المستخدم حاليًا في الأصول - تنزيل واستخراج الملف المضغوط من جيثب.

chanon the الأصول lib wirks مع github مباشرة لذا فإن التعريف الوحيد الذي لدينا للإصدارات هو الالتزام بالتجزئة والفرع والعلامة.

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

في الثلاثاء ، 3 يوليو 2018 ، الساعة 11:23 صباحًا ، كتب Jon Bonazza [email protected] :

@ Two-Tone https://github.com/Two-Tone كنت أحاول ألا أصاب بالجنون
مع هذا. أردت فقط شيئًا بسيطًا يبقينا على ما هو أفضل
تم تحديد النهج عليه.

Zylann https://github.com/Zylann ربما سأستخدم نفس الأسلوب
المستخدمة حاليًا في ملف الأصول - تنزيل واستخراج ملف zip
ملف من جيثب.

chanon https://github.com/chanon يتعامل موقع lib الخاص بالأصول مع جيثب
بشكل مباشر ، لذا فإن التعريف الوحيد الذي لدينا للإصدارات هو تجزئة الالتزام ،
الفرع والعلامة.

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

@ Two-Tone آسف ، ولكن "مجنون للغاية" كنت أعني "معقدة للغاية" لأن هذا من المفترض أن يكون حلًا سريعًا لإيقافنا. أوافق على أن الحل المناسب للنزاع ضروري على المدى الطويل ، لكنني كنت آمل أن نتمكن من الإفلات بدونه في غضون ذلك.

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

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

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

يمكنك استخدام وحدات git الفرعية للاعتماديات.

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

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

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

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

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

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

في الثلاثاء ، 3 يوليو ، 2018 ، 12:11 مساءً ، كتب Jon Bonazza [email protected] :

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

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

@ Two-Tone لا يمكنك إعادة تسمية المجلدات فقط لأن البرامج النصية في كود البرنامج المساعد غالبًا ما تستخدم مسار الوظيفة الإضافية مباشرة. على سبيل المثال

extends "res://addons/foo/bar.gd"

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

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

"يمتد" الدقة: // addonname / "

واستبدله بـ

"يمتد" res: // addonname-versionnumber / "

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

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

في يوم الأربعاء ، 4 يوليو 2018 ، الساعة 12:48 مساءً ، كتب Marc [email protected] :

jonbonazza https://github.com/jonbonazza أود أن أضيف ، الأمر ليس فقط
البرامج النصية التي تقوم بذلك ، ولكن أي أصل يشير إلى أصل آخر.

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

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

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

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

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

الحل الوحيد الذي يمكنني التفكير فيه هو توسيع gdscript بحيث يمكن للمستخدم أن يحدد في البرنامج النصي ما هو إصدار المكون الإضافي الذي يستخدمه ، ثم من تلك النقطة فصاعدًا يقومون فقط باستخدام extends "res://addonname/etc ويكون المحرك نفسه يتعامل مع الطريق الصحيح. هذا ، مع ذلك ، يقع بالتأكيد في قضية "معقدة للغاية" التي ذكرها jonbonazza . ولكن على المدى القصير يمكن تخطيه.

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

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

بصراحة ، أعتقد أن أفضل مسار للعمل لحل قصير المدى هو تغيير lib للأصول لدعم (على الرغم من عدم _طلب _ للتوافق مع الإصدارات السابقة) القدرة على خدمة المشاريع التي هي طبقة واحدة تحت addons dir. على سبيل المثال

godot-tools.level-streamer/
    project.cfg

بدلا من

addons/
    godot-tools.level-streamer/
        project.cfg

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

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

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

$UserSetLocation/
    godot-tools.level-streamer/
        project.cfg

deps/
    thing-level-streamer-uses/
        project.cfg

@ Two-Tone ولكن ماذا لو كان اعتمادك على التبعية؟ ألا يجب أن يكون مجلد deps بدلاً من ذلك مجلدًا فرعيًا للمكوِّن الإضافي نفسه ، وبهذه الطريقة يمكنك التعمق بشكل تعسفي حسب الضرورة؟

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

ما قيل...

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

نعم ، إدارة التبعية ليست بالأمر السهل. وإلا فلن يلزم أن يكون npm معقدًا كما هو ولن يلزم إنشاء yarn .

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

في node.js web dev ، على سبيل المثال ، من الجيد إلى حد ما تجاهل ما بداخل وحدات node_modules طالما أنها تعمل حيث سيتم نشرها على الخادم فقط. بالنسبة للعبة ، ستقوم بتجميع كل هذا الرمز / الأصول في حزمة تطبيق نهائية وسيكون تكرار نفس التبعية n مرة أمرًا سيئًا للغاية.

هذه المشاكل هي السبب في أن اقتراحاتي الأولية قالت بعدم السماح للأصول بتحديد التبعيات حتى الآن ، ولكن لديك طريقة لسرد تبعيات المشروع ، والسماح للمستخدم بتثبيت أي تبعيات للأصول يدويًا:
https://github.com/godotengine/godot/issues/19486#issuecomment -399559419

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

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

لا أعتقد أن وضع التبعيات كمجلد فرعي للأصول فكرة جيدة لأنها تؤدي إلى مسار سيكون معقدًا للغاية.
إذا كانت لدينا أصول تحدد التبعيات ، فأعتقد أنه يجب تثبيتها جميعًا على نفس المستوى (في res: // addons folder

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

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

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

أشعر أن قضية التبعية بأكملها يتم التفكير فيها بشكل مبالغ فيه

@ LikeLakers2 تعتبر إدارة التبعية السليمة وتجنب الصراع مسألة مهمة وصعبة. تتم مناقشتها كثيرًا بسبب ذلك

لا أتوقع أن تنتهي هذه المحادثة بالطريقة التي تتجه بها حاليًا.

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

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

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

مثل الانتقال دائمًا إلى الإصدار الأحدث

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

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

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

أتفق مع willnationsdev و @ LikeLakers2

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

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

@ Two-Tone إذا كان المكون الإضافي A يحتاج إلى الإصدار 1 من X والمكون الإضافي B يحتاج إلى الإصدار 2 من X ، أود أن أقول إن Godot يجب ألا يحاول إصلاحه بطريقة سحرية. فيما يلي حلول بسيطة لذلك:

• عادةً ، يجب أن يكون الإصدار 2 من X متوافقًا مع الإصدارات السابقة مع الإصدار 1 ، وهذه هي الطريقة التي يجب أن تكون عليها الأمور لتبسيط الأمر (تذكر عندما أشرت إلى طريقة التفكير عند تطوير المكونات الإضافية).
• إذا لم تتمكن من استخدام أحدث إصدار من X ، فانتظر البرنامج المساعد A لدعمه وتنزيل الإصدار السابق (نحتاج إلى واجهة برمجة تطبيقات الأصول للتعامل مع الحصول على إصدارات مختلفة ، وليس الإصدار الأحدث فقط ، ولا ينبغي أن يكون ذلك صعبًا). إنه مثل التعديلات ، لا يجب أن يكون مثاليًا.
• يقوم صانع المكون الإضافي لـ X بتحميله كمكوِّن إضافي مختلف (لأن واجهة برمجة التطبيقات تعطل التوافق) ، تمامًا كما كان علينا عندما خرج Godot 3. إذن سيكون لديك ضعف نفس المكون الإضافي ، لكن لا بأس بذلك لأنهما مختلفان جدًا بحيث لا يكونان حقًا نفس المكون الإضافي على أي حال ، وستعمل الأشياء التي تعتمد عليها أيضًا. يمكن أن يكون مجرد إعادة تسمية للمجلد من قبل مطور البرنامج المساعد ، ولا حتى الحاجة إلى وجود إدخالين lib للأصول.

في أسوأ السيناريوهات ، سيتعين عليك إجراء هذا العمل يدويًا (وتوافق العلاقات العامة مع صانع المكونات الإضافية في النهاية).

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

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

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

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

يفرض الخيار 2 على المستخدمين عدم استخدام المكون الإضافي الذي يريدونه لأنه يتعين عليهم إما انتظار تحديث المكون الإضافي ، أو إذا كان لا يزال قيد التطوير ، أو عدم استخدامه على الإطلاق.

يجعل الخيار 3 الأمور أكثر صعوبة مرة أخرى لمطوري المكونات الإضافية.

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

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

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

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

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

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

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

نسختان بمسارات مختلفة ليست مشكلة صعبة

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

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

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

إجراء 1+ لكل شيء في هذا الموضوع - توسيع وحدة البرنامج المساعد وزيادة استخدام lib للأصل هو السبيل للذهاب

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

الأول هو أن Unity لديها الآن "مدير الحزم" الذي يستخدمونه للسماح للمستخدمين بتحديد مكونات المحرك التي يرغبون في تثبيتها / إلغاء تثبيتها. يبدو أنهم قد يستخدمون هذا أيضًا لمتجر الأصول في المستقبل.

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

أيضًا ، ربما يجب إنشاء "الوحدات النمطية" العادية كمكتبات مشتركة (ملفات dll / .so) بحيث يمكن تحديدها للتثبيت / إلغاء التثبيت في مدير الحزم.

يجب أن تحتوي المشاريع والحزم على ملفات بيان تسرد الحزم التي تعتمد عليها وسيضمن Godot / مدير الحزم تثبيت الحزم المطلوبة.

ستكون هناك حاجة إلى سجل عام للحزم.

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

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

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

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

هذا الكثير من التعقيد الإضافي الذي يجب إدارته بشكل جيد ، حتى لا ينتهي بنا المطاف في جحيم التبعية :)

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

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

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

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

أنا متأكد من أن هذا حل ساذج للغاية لمشكلة بهذا التعقيد ، لكنني كنت أفكر في نظام المكون الإضافي مؤخرًا بسبب تصحيح الخط المخصص. أعتقد أن أفضل تجربة للمستخدم هي تلك التي لا داعي للقلق بشأن التبعيات ، والمطورين هم من يجب أن يهتموا بإدارة تبعياتهم. هذا يسهل على المستخدم الإدارة: يمكن أن يتم تمثيل المشروع كملف واحد في قفص الاتهام لنظام الملفات ، ويمكنك النقر بزر الماوس الأيمن والحصول على خيارات إضافية ( extract files (للتطوير) ، update plugin (للتحديثات السهلة) ، انتقل إلى موقع الويب ( for easy community organization )) وقم أيضًا بالإشارة إلى الفئات داخل "حاوية" معينة ( extends "[path-to-addon-tar]://ClassName" )

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

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

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

أعتقد أن أرشيفات .tar ستكون غير مألوفة إلى حد ما بالنسبة لمعظم المستخدمين (ahem ، مستخدمو windows) لذا قد يكون من الأفضل استخدام أرشيفات zip. لأنها تتمتع بدعم أوسع إلى حد ما.

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

بالتأكيد ، قصدت في الغالب .tar كمثال لنوع أرشيف معبأ بشكل عام. يمكن وربما يجب أن يستخدم تنسيق godot .pck.

لماذا لا تستخدم ZIP لأنه يوفر ضغطًا وهو تنسيق قياسي؟

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

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

في عالمي المثالي ، أود أن يكون لدي زري تنزيل على https://godotengine.org/download :

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

أكثر مثالية:
حدد وامزج. عند تنزيل الحد الأدنى ، يمكنني تحديد الإصدار الأدنى + "سمات" المكون الإضافي. وهي مجموعات من المكونات الإضافية الشائعة اللازمة لحالات الاستخدام الشائعة. (على سبيل المثال: 2DPixelart ، 3D FirstPersonShooter ، 3D ThirdPerson ، RTS ، RPG ، 2.5D game ، 2DCutout ، Rougelike ، ManagementSim ، Sidescroller ، Eventpackage ، Shaderpackage ، Scriptpackage ، Assetpackace ، إلخ). لذلك عندما أبدأ تشغيل المحركات ، تكون المكونات الإضافية الأساسية مثبتة بالفعل وجاهزة للعمل وأنا أعلم أنها تعمل لأنها تمت الموافقة عليها.
يمكن للمستخدمين الأكثر تقدمًا إلغاء تحديد المكونات الإضافية الفردية ضمن مجموعات السمات هذه إذا كانوا يعرفون أنهم لا يحتاجون إليها ، أو دمج اثنين أو أكثر من سمات المكونات الإضافية ، أو إضافة مكونات إضافية فردية إلى السمات من مجموعة المكونات الإضافية المعتمدة لإنشاء حزمة مخصصة.

من الناحية المثالية ، ستكون النتيجة أن https://godotengine.org/download ينشئ من هذه الاختيارات _ رابط تنزيل واحد سريعًا _.

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

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

الحل الأبسط هو أن تطلب تثبيت مكونات إضافية [رسمية فقط؟] عند تشغيل المحرر لأول مرة. حاليًا لدينا خيار لفتح AssetLib إذا كانت قائمة المشروع فارغة ؛ لماذا لا يكون لديك نافذة حوار منبثقة لتثبيت المكونات الإضافية الرسمية في حالة تشغيل Godot لأول مرة؟

الإغلاق لصالح https://github.com/godotengine/godot-proposals/issues/142 و https://github.com/godotengine/godot-proposals/issues/577 و https://github.com/godotengine/ godot-articles / issue / 607 ، حيث يتم الآن تتبع مقترحات الميزات في مستودع مقترحات Godot.

تحرير من aaronfranke: راجع أيضًا https://github.com/godotengine/godot-proposals/issues/554