كيف تقيّم Roblox عملية إنشاء الألعاب

تتيح أداة Build، وهي أداة الإنشاء الجديدة التي تركز على الأجهزة المحمولة أولاً، لمستخدمي Roblox إنشاء لعبة باستخدام توجيهات نصية ونشرها للاعبين في جميع أنحاء العالم. يتطلب إنشاء لعبة متكاملة نظامًا فاعلًا شاملاً لإنشاء الألعاب: نظامًا ينسق بين الكود، والأصول المرئية، وأنظمة اللعب، وواجهة المستخدم، وعناصر التحكم في منتج مركب واحد. يجب أن يتعامل هذا النظام بقوة مع السيناريوهات المختلفة التي تنشأ مع مدخلات اللاعبين والتفاعلات متعددة اللاعبين. منذ الإطلاق التجريبي في نيوزيلندا، استخدم أكثر من 100,000 لاعب أداة Build لتجربة إنشاء لعبة، وتم نشر ما يقارب 9,000 لعبة تم إنشاؤها باستخدام Build.¹ ومن بين الآلاف الذين استخدموا Build لإنشاء لعبة، لم يسبق لـ 71% منهم استخدام Roblox Studio من قبل،¹ مما يدل على أنهم يجربون شيئًا جديدًا مع Build.

لكن المبدعين لن يستخدموا هذه الأداة الجديدة إلا إذا كانت سهلة الاستخدام وكانت جودة الألعاب التي تنتجها عالية بما يكفي للبناء عليها. لفهم جودة الألعاب التي تم إنشاؤها باستخدام Build، نقوم بتقييم رحلة الإنشاء من البداية إلى النهاية ونستخدم هذه التقييمات بالإضافة إلى ملاحظات المبدعين لتحسين المنتج. وقد ساعدنا إطار التقييم (eval) الخاص بنا على تحديد الأولويات وتحسين فهم المقصد، وقابلية اللعب ثلاثي الأبعاد، والتشذيب. منذ الإطلاق التجريبي لـ Build في نيوزيلندا، تحسنت نسبة رضا المبدعين بنسبة 10٪، وانخفضت النتائج غير المقصودة من 18٪ إلى 3٪، وتم نشر حوالي 14٪ من الجلسات الموجهة و19٪ من اختبارات اللعب.² هذه مؤشرات وصفية للتقدم، وليست تقديرات سببية لتأثير التقييم وحده.

لماذا يختلف تقييم إنشاء الألعاب

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

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

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

أربع إشارات، إطار عمل واحد

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

1. جودة مواصفات اللعبة (درجة من 0 إلى 100): Build هو وكيل الإنشاء الشامل: فهو يترجم توجيهات المبدع إلى مواصفات، ثم يستخدمها لإنشاء اللعبة. ويقوم المُقيّم بتقييم ما إذا كانت المواصفات تتخذ قرارات مهمة بشكل صريح، وتحافظ على نية المبدع، وتراعي الجدوى ضمن بيئة تشغيل Roblox، وتتجنب ابتكار متطلبات لم يتم التعبير عنها مطلقًا.

2. جودة اللعبة الثابتة (درجة من 0 إلى 100): يقوم مُقيّم الحالة الثابتة بفحص اللعبة التي تم إنشاؤها في وضع التحرير في Roblox Studio. ويشمل ذلك بنية اللعبة، والنصوص البرمجية، والأصول، والخصائص، والاتصالات، وحدود العميل/الخادم. نسعى للإجابة عن سؤالين في هذه المرحلة. الأول هو ما إذا كانت اللعبة قد بُنيت بشكل صحيح: تنفيذ الأنظمة المطلوبة، وخيارات واجهة برمجة تطبيقات المحرك والشبكات، ووجود عناصر التحكم ومكونات واجهة المستخدم المتوقعة، ومتانة وتماسك بنية اللعبة. 

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

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

3. اختبار اللعب (معدل النجاح من 0 إلى 100%): يقوم مقيم اختبار اللعب بتشغيل اللعبة وتنفيذ خطة اختبار باستخدام مدخلات تشبه تصرفات اللاعب الحقيقي، بما في ذلك النقرات، والضغطات، وضغطات المفاتيح، والتنقل، بدلاً من إطلاق الأحداث من خلال الكود. تتحقق خطة الاختبار لكل حالة من أن اللعبة تبدأ، وتستجيب، وتتقدم، وتتعافى من الأعطال، وتبقى خالية من أخطاء وقت التشغيل. يتم تقييم كل عنصر بنظام ثنائي (نجاح/فشل)، ويتم الإبلاغ عنه كمعدل نجاح مرجح حسب المستوى إلى جانب حكم بسيط بـ«قابلة للعب» أو «غير قابلة للعب». نكرر عمليات التشغيل لقياس الاتساق.

4. الجودة البصرية والتجريبية (درجة من 0 إلى 100): بعض العناصر الأكثر أهمية لمظهر اللعبة وطابعها لا يمكن استخلاصها من الكود، لذا يقوم المُقيّم البصري بتقييم العرض بصفته المستقلة باستخدام لقطات من اللعب تم التقاطها على نوافذ عرض تمثل أجهزة مختلفة. تركز معايير التقييم هذه فقط على شكل اللعبة وصوتها بناءً على جودة الأصول، وتشطيب واجهة المستخدم، والحركة، والإضاءة، والصوت. السؤال الأساسي هو: هل تبدو اللعبة كمنتج جاهز للتسويق، أم كنموذج أولي؟ إن فصل العناصر المرئية عن الآليات يعني أن عبارات «الكود يعمل» و«اللعبة تبدو مكتملة» لا يتم دمجها في درجة واحدة مضللة.

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

ترتبط الإشارات بالفشل الذي تكتشفه:

تجول عبر مسار لعبة Obby ثلاثية الأبعاد موجهة

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

الخطة والمواصفات

أعدت شركة Build وثيقة مواصفات لعبة جديدة، تسمى Skyforge Ascent، توضح بالتفصيل مسارًا مكونًا من خمسة أقسام مع نقاط تفتيش وثلاثة أنواع من المخاطر. وقد حددت الوثيقة الحلقة الأساسية، ومنحنى الصعوبة، والتوجيه الفني، والشاشات، والتراكبات، وعناصر التحكم. وحصلت المواصفات على تقييم 91/100، وحصلت على الدرجة الكاملة في مجالات الاكتمال، والالتزام الفوري، والجدوى، والاتساق الداخلي. وجاءت النقاط المخصومة من بعدين محددين: تفاصيل التنفيذ وتغطية معايير القبول. 

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

الفحوصات الثابتة: جودة الكود وجودة المحتوى

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

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

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

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

اختبار التشغيل

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

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

الجودة البصرية

أخيرًا، قام نظام التقييم بتقييم الجلسة المسجلة على نافذة عرض بحجم الهاتف من حيث العرض المرئي. حصلت Skyforge Ascent على 86/100: تصميم نظيف ومتماسك ومتوافق بشكل مريح مع العناصر المرئية لألعاب «أوبي» النموذجية؛ وهندسة منصات واضحة؛ ومخاطر يمكن تمييزها بسهولة؛ وشاشة عرض معلومات (HUD) حديثة وغير مزعجة. تمنع بعض القيود البصرية الطفيفة اللعبة من بلوغ الكمال، لكن لا يوجد أي خلل، ولا يوجد ما قد يجعل اللاعب يتوقف عن التمرير أيضًا.

مقاييس التتبع

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

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

كيف ساهم التقييم المبكر في تحسين Build 

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

1. الحل السريع لمشاكل مطوري الإصدار التجريبي: في إطلاقنا التجريبي في نيوزيلندا، أبلغنا المستخدمون أن Build كان ينشئ أحيانًا لعبة ثنائية الأبعاد (2D) بينما كانوا يريدون لعبة ثلاثية الأبعاد (3D). ساعد إطار التقييم فريقنا على تحسين قدرات Build في مجال ثلاثي الأبعاد بسرعة. في غضون أسبوعين، قمنا بتحسين قدرة Build على فهم نية المستخدم في إنشاء لعبة ثلاثية الأبعاد — حتى لو لم يذكر ذلك صراحةً. كما قمنا بتحسين قابلية اللعب ثلاثية الأبعاد وصقلها من خلال إصلاح المشكلات الشائعة المتعلقة بوضع الكائنات والإضاءة وما إلى ذلك. ومنذ ذلك الحين، انخفضت الشكاوى من نوع «ليس ما أريده» من 18% إلى 3% من بين جميع الشكاوى؛ وانخفضت نسبة ردود الفعل غير الراضية بشكل عام بعد اختبار اللعب بمقدار 10 نقاط مئوية. كما اكتسبنا خبرات عند إجراء عمليات التكرار على إطار العمل نفسه. 
2. المقارنة المعيارية بين النماذج والبنى: نستخدم إطار عمل التقييم الخاص بنا لإجراء مقارنة معيارية دقيقة لتكوينات نظام البناء مقابل مجموعات المطالبات القياسية. قبل نشر التغييرات في بيئة الإنتاج، تقارن تقارير التقييم A/B غير المتصلة بالإنترنت الإصدارات المرشحة بخطوط الأساس الخاصة بنا في بيئة الإنتاج عبر الأبعاد الأربعة التالية: 

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

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

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

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

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

ماذا بعد ذلك

نركز حاليًا على توسيع نظام تقييم إنشاء Build في خمسة اتجاهات:

1. تغطية أوسع عبر الأنواع المختلفة، وتجارب ثنائية الأبعاد/2.5D/ثلاثية الأبعاد، وسيناريوهات اللعب الجماعي، ومستويات التعقيد
2. دعم أقوى للتعديلات متعددة الأدوار
3. أدلة أكثر موثوقية من اختبارات اللعب، ولقطات الشاشة، ومقاطع الفيديو، والتسجيلات الصوتية
4. معايرة على نطاق واسع مع التقييمات البشرية وحالات المقارنة المعيارية التي يقودها المبدعون
5. تكامل أفضل بين التقييم غير المتصل بالإنترنت، وإشارات المنتج عبر الإنترنت، واختبارات الانحدار

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

للاطلاع على نظرة ذات صلة بتقييم الأنظمة الوكيلة لـ Roblox Assistant، انظر استخدام OpenGameEval لقياس أداء المساعدين الذكائيين الوكيلين لـ Roblox Studio.