تطوير ألعاب Godot بالذكاء الاصطناعي

حدّد نطاق المشروع قبل التعديلات

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

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

حدّد الملف التنفيذي والوسائط المدعومة

توفر وثائق Godot CLI المستقرة الأوامر أدناه. GODOT_BIN وPROJECT متغيرا Shell مختاران لهذا المثال وليسا إعدادات Godot؛ استبدل مساراتهما النائبة بالملف التنفيذي والمشروع الموجودين. يجب أن يحتوي مسار المشروع على project.godot.

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

GODOT_BIN="/absolute/path/to/godot"
PROJECT="/absolute/path/to/project"
"$GODOT_BIN" --version
"$GODOT_BIN" --help
"$GODOT_BIN" --headless --path "$PROJECT" --import

افصل الاستيراد والتحليل واللعب الفعلي

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

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

"$GODOT_BIN" --headless --path "$PROJECT" \
  --script res://scripts/player.gd --check-only
"$GODOT_BIN" --path "$PROJECT" --debug

اختر أدوات CLI أو MCP بوعي

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

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

امنح الإخفاقات سياق مشهد كافيًا

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

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

جهّز متطلبات التصدير صراحةً

يتطلب التصدير إعدادًا مسبقًا مطابقًا وقوالب تصدير مثبتة. راجع export_presets.cfg وتضمين الموارد قبل البناء. أبقِ بيانات اعتماد التصدير خاصة. اسم الإعداد في المثال توضيحي ويجب أن يطابق مشروعك؛ كما يجب أن يكون دليل الإخراج موجودًا مسبقًا.

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

"$GODOT_BIN" --headless --path "$PROJECT" \
  --export-release "Windows Desktop" "/absolute/existing-build-dir/game.exe"

نفّذ تدفق تسليم على الهدف

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

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

مشروع مصدر ولقطة أصلية للفحص

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

استخدم المشروع Godot 4.5.1 في تشغيل Codex لم يُتحقق فيه من نموذج التوليد الدقيق. لذلك يعرض سير عمل محرك محلي لا معيار Astra. كان تصدير المتصفح محجوبًا بسبب قوالب تصدير مفقودة، وPCK ليست ملف Windows تنفيذيًا مستقلًا. هذه الحدود مسجلة مع المصدر حتى يعرف المطور التالي ما الذي لا يزال يحتاج إلى اختبار.

أغلق الحلقة بتسليم قابل للمراجعة

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

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

الأسئلة الشائعة