الاختيار ما بين التحميل التلقائي والعقد العادية في جودو

من موسوعة حسوب
< Godot
مراجعة 07:14، 28 أكتوبر 2023 بواسطة جميل-بيلوني (نقاش | مساهمات)
(فرق) → مراجعة أقدم | المراجعة الحالية (فرق) | مراجعة أحدث ← (فرق)
اذهب إلى التنقل اذهب إلى البحث


يقدم جودوت ميزة تحميل العقد تلقائيًا في جذر المشروع، ويسمح لك بالوصول إليهم بشكل عام global، وتحمل هذه العقد مسؤولية واحدة singleton، ولا تحرر هذه العقد المحملة تلقائيًا عندما تغير المشهد من الشيفرة البرمجية باستخدام SceneTree.change_scene_to_file

سنتعلم هنا عن ميزة التحميل التلقائي Autoload والتقنيات التي يمكنك استخدامها لتفاديها.

مشكلة قطع الصوت

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

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

واحدة من الحلول هي كتاية شيفرة صنف إدارة صوت عام ومحمل تلقائيًا. تُنشئ مجمّع عقد AudioStreamPlayer يتم دورته كل مرة يُطلب فيه التأثير الصوتي. نسمي هذا الصنف Sound، ويمكنك استخدامه في أي مكان في المشروع الخاص بك باستدعاء Sound.play("coin_pickup.ogg"). يحل ذلك المشكلة على المدى القصير ولكنه يسبب مشاكل أخرى:

  1. الحالة العامة: الآن يوجد كائن واحد مسؤول عن كل بيانات الكائن. إذا كان لدى الصنف Sound أخطاء أو ليس لديه AudioStreamPlayer متوفر، يمكن أن تتعطّل كل العقد التي تستدعيه.
  2. الوصول العام: الآن يستطيع أي كائن استدعاء Sound.play(sound_path) من أي مكان ولا يوجد طريقة سهلة لمعرفة أصل الخطأ
  3. تخصيص الموارد العام: بوجود مجمع عقد AudioStreamPlayer مخزنة من الأول يمكن إما أن يكون لديك عدد قليل وتواجه أخطاء أو عدد كبير و تستهلك ذاكرة أكثر من اللازم.

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

قارن السابق مع كل مشهد يحتفظ بعدد عقد AudioStreamPlayer يحتاجها في داخله وكل هذه المشاكل ستُحلّ:

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

إدارة الوظائف المشتركة أو البيانات

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

يمكن استخدام نوع جديد من Node التي تؤمن ميزة لمشهد ما باستخدام الكلمة المفتاحية class_name في GDScript في حالة الدوال.

أما بالنسبة للبيانات فيمكنك:

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

متى يجب استخدام التحميل التلقائي

تدعم GDScripts إنشاء دوال static باستخدام static funcيسمح ذلك بإنشاء مكتبة دوال مساعدة بدون الحاجة لإنشاء نسخة لاستدعائهم عندما تُجمع مع class_name، إلا أنه من محدوديات الدوال الساكنة هو أنها لا تستطيع أن تُرجع متغيرات العناصر أو الدوال غير الساكنة أو self.

من إصدار جودوت 4.1 وما بعد، تدعم GDScripts أيضًا المتغيرات static باستخدام static var، أي يمكنك الآن مشاركة المتغير عبر نسخ الصنف بدون الحاجة لإنشاء محمل تلقائي آخر.

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

ملاحظة: ليس بالضرورة أن يكون التحميل التلقائي متفرّد singleton. لا يوجد شيء يمنعك من نسخ عقد تحميل تلقائي. التحميل التلقائي هو أداة تجعل العقد تُحمل تلقائيًا كابن من جذر شجرة المشهد، بغض النظر عن هيكلية عقدة اللعبة أو أي مشهد تنفذه، مثال عن ذلك ضغط المفتاح F6. كنتيجة يمكنك الحصول على العقدة المحملة تلقائيًا، كالعقدة المحملة تلقائيًا Sound مثلًا، وذلك باستدعاء get_node("/root/Sound").

مصادر