DeepSeek V4: تحسين إنشاء ألعاب الذكاء الاصطناعي بميزانية محدودة

هل تستطيع النماذج منخفضة التكلفة إنشاء ألعاب متصفح يرغب الناس فعلاً في لعبها؟ على مدى الأسبوع الماضي، اختبرنا هذا السؤال في OpenGame Studio. وأحدث إضافة هي DeepSeek-V4.1-Flash-1017، إصدار 17 أكتوبر من عائلة DeepSeek V4.

اختبرنا أيضاً Grok 4.6 وXiaomi MiMo V2.6 Flash وMiMo V2.6 Pro وGLM 5.3 Flash وClaude Haiku 5.5. كان هدفنا تحسين التوازن بين تكلفة التوليد ووقت الانتظار وسلوك اللعبة القابل للعب والجودة البصرية. فقد تُفتح اللعبة بنجاح لكنها قد تتحرك إلى اليمين عند ضغط اللاعب لليسار، أو تمنح العملات مبكراً، أو تواصل السقوط أثناء الإيقاف المؤقت.

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

النسخة الأصلية من عدّاء DeepSeek-V4.1-Flash-1017. يمكن تمييز الشخصية والمسارات والعملات؛ أما البيئة فبقيت نموذجاً أولياً بسيطاً.

تحسين إنشاء الألعاب بتكلفة معقولة

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

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

كان لكل خيار في قائمتنا دور مختلف:

• قدم Grok 4.6 مرجعاً عاماً. وكان أقل تركيزاً على الميزانية بالنسبة إلينا، مع جاذبية الوصول عبر الاشتراك. وتصف صفحة الإصدار الرسمية إتاحة البرمجة عبر Grok Build وأدوات أخرى.
• أتاح لنا Xiaomi MiMo V2.6 Flash وPro مقارنة خيارين من عائلة واحدة. وتقدم Xiaomi Flash للاستخدام الفعال والمتكرر، وPro للاستدلال الأكثر صعوبة والعمل على المشاريع. يُعد Pro نموذجاً رائداً ضمن عائلته، لكنه ظل خياراً في استكشافنا للميزانية.
• قدم GLM 5.3 Flash خياراً آخر يركز على الكفاءة. ويوضح التقديم الرسمي موضعه هذا. أردنا معرفة كيفية تعامله مع طلب اللعبة كاملاً.
• أضاف Claude Haiku 5.5 خياراً خارجياً يراعي التكلفة. وتصف Anthropic Haiku بأنه مناسب للأعمال السريعة وكثيفة الاستخدام. اختبرناه كمنشئ ألعاب، مع مراجعة محدودة موضحة أدناه.
• كان DeepSeek-V4.1-Flash-1017 أحدث تجربة. ويتضمن إعلان الإصدار عروضاً للمشاريع. استخدمنا طلبنا الخاص للعدّاء لمعرفة ما الذي يمكن نقله إلى OpenGame Studio.

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

عدّاء واحد وست تجارب للنماذج

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

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

أعدنا استخدام الطلب الأصلي نفسه في التجارب التالية بين 11 و17 أكتوبر 2026:

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

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

ما الذي أضافته تجارب MiMo وGLM وHaiku إلى الصورة؟

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

الناتج الأصلي من MiMo Flash قبل الإصلاحات اللاحقة المنسقة. جاء عيب توقيت الجمع من فحوص اللعب والمصدر؛ ولا تثبته هذه اللقطة وحدها.

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

مشهد المدينة الأصلي لـ MiMo Pro. تطلب عيب الإيقاف المؤقت اختباراً في منتصف القفزة لا تكشفه صورة ثابتة جذابة.

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

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

الأصل المستعاد من GLM أثناء فحص منفصل. لا تثبت هذه الصورة نجاح التسليم عبر Studio.

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

هذا التمييز مهم عند تسجيل الاختبارات: فالتسليم والمراجعة البصرية والتحقق السلوكي مراحل مختلفة.

لماذا يتحرك اللاعب يميناً عند الضغط لليسار؟

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

قبل: العدّاء في المنتصف.

بعد ArrowLeft: أصبح العدّاء ظاهراً على اليمين. تعرض اللقطتان النسخة المولدة من دون تعديل.

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

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

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

ما الذي فعله DeepSeek V4 في اختبار العدّاء؟

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

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

تجاوزت إحدى جولات العوائق 216 متراً مع جمع 51 عملة. وأرسلت أتمتة المتصفح مدخلات لعب عادية. ولم نغيّر الإحداثيات أو النقاط أو حالة التصادم للحصول على النتيجة.

يوصل السحب إلى اليسار الشخصية إلى المسار المرئي الأيسر في محاكاة متصفح عمودية. وما زال التوافق مع هاتف فعلي غير مختبر.

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

ينبغي تقييم المنطق والرسومات والوضوح كلٌّ على حدة

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

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

نموذج سباق منفصل من DeepSeek. استخدم طلباً مختلفاً وهو خارج مقارنة العدّاء المشترك.

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

هل القيود على المطالبات والمهارات صارمة أكثر من اللازم؟

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

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

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

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

يمكن لمنشئ اللعبة البدء بالمطالبة التالية:

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

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

كيف تؤثر هذه الاختبارات في تجربتنا التالية؟

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

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

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

هل لديك فكرة لعبة صغيرة؟ ابدأ موجزاً في OpenGame Studio، واتفق على حلقة اللعب الأساسية، ثم اختبر النسخة الأولى بمدخلات حقيقية.

ملاحظة المصادر

تثبت المصادر الرسمية أسماء النماذج وسياق إصدارها ومواقف الشركات من منتجاتها: إصدار DeepSeek في 17 أكتوبر وGrok 4.6 وMiMo V2.6 Flash وMiMo V2.6 Pro وGLM 5.3 Flash وClaude Haiku 5.5، وكذلك المثال الخلفي غير المختبَر للنموذج الرائد Claude Opus 5.5.

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