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

ابدأ بحلقة لعبة صغيرة مكتملة

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

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

اختر سير العمل ثم المحرك

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

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

أبقِ الوصول إلى النموذج منفصلًا عن أدوات المحرك

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

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

اجعل الموجز الأول قابلًا للاختبار

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

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

Deliver one original 2D room with start, play, win/loss, and restart states.
Use project-owned placeholder art. Preserve the chosen engine version.
Record each edit, tool result, failed check, and human intervention.
Stop before downloads, purchases, uploads, or publishing.
Report unfinished requirements with their reproduction steps.

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

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

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

عامل الأصول والتوطين كمدخلات إنتاج

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

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

أثبت كل حالة تسليم بصورة مستقلة

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

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

ما الذي يوضحه مثال Playco عن سير العمل؟

تصف قصة العميل التي نشرتها OpenAI في 3 سبتمبر 2026 استخدام Playco لـ Astra في Playbot، وهي بيئة تطوير متصلة بمحركات الألعاب. كرر الفريق العمل على أساس grey-box قبل إنتاج نماذج أولية ذات طابع. هذه رواية عميل منشورة من المزود وليست معيارًا من APIsRouter.

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

افحص نموذج Godot محليًا

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

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

اختر الدليل التالي وفق عنق الزجاجة

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

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

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