التطوير / ROBLOX
شارة إنجاز في Roblox: تحديد الشرط ومراجعة الخادم
خطط لشارة واحدة لمسار تدريب: شرط دقيق، ولعبة صحيحة، ومنح من الخادم، وفحص ملكية. افصل رسالة الواجهة وتنفيذ API عن النتيجة المؤكدة.
صف الإنجاز أولاً #
اختر هدفاً صغيراً تشرحه جملة: إكمال مسار التدريب والوصول إلى نهايته. سجل المراحل المطلوبة وحالة الخادم التي تؤكد الاكتمال. ينبغي أن تمثل الشارة هذا الإنجاز، لا مجرد لمس أي جزء يشبه النهاية في شكله.
يخطط مثالنا لمشروع تدريب منفصل. لم ننشئ شارة حقيقية أو نحصل على معرف أو نمنح جائزة، ولم نغير شيفرة ألعابك. يجهز المقال مهمة التنفيذ ولا يمثل سكربت BadgeService جرى اختباره بالفعل في Studio.
طابق الاسم والوصف والشرط #
يقول الاسم ما حدث، ويشرح الوصف طريقة الاكتساب. قارنهما بقاعدة المسار: إن كان المسار كله مطلوباً، فلا تقل إن الدخول يكفي. وضح الميكانيكية غير المحددة أولاً، ثم اكتب بطاقة الإنجاز حتى لا يخمن اللاعب الشرط.
سجل الآثار الإضافية منفصلة. العملات أو العناصر أو منطقة جديدة لا تظهر بسبب اسم الشارة؛ يحتاج كل أثر إلى تنفيذ خاص. يتناول خطتنا شارة الاكتمال فقط، لا Robux أو عنصر صورة رمزية أو امتيازاً إضافياً للاعب.
جهز الكائن دون تكاليف عرضية #
تتبع أدوات الشارات في Creator Dashboard اللعبة المختارة. تصف الوثائق الإنشاء من قائمة اللعبة ثم الإدارة في Engagement → Badges. قبل الإنشاء، تحقق من اللعبة والحصة الحالية: قد تكلف الشارات الإضافية Robux، فلا تفترض مجانية كل عملية.
لا يحتاج إعداد المقال إلى كائن حقيقي. املأ الوصف والهدف واترك badgeId فارغاً. لا تستخدم معرف مؤلف آخر أو رقماً مختلقاً على أنه يعمل. عندما يُنشأ كائن لاحقاً في مهمة مستقلة، طابق الصفحة والمعرف واللعبة مع البطاقة.
راجع الأيقونة والإتاحة #
توصي الوثائق بصورة أصلية 512×512 وتراعي الاقتصاص الدائري. في خطتنا يبقى الرمز المهم داخل الدائرة والاسم الطويل خارج الرسم. راجع وضوح المعنى عند التصغير، لا في الصورة الكاملة وحدها، كي يبقى الإنجاز قابلاً للتمييز.
للشارة حالة تفعيل. الشارة المعطلة لا تظهر في قسم شارات صفحة اللعبة ولا يمكن اكتسابها. صنع الرسم وإنشاء الشارة مهمتان مختلفتان؛ الأيقونة الجميلة لا تؤكد الإتاحة أو صحة شرط الخادم أو جاهزية المنح.
اربط الهدف بمنطق الخادم #
تصف الوثائق المنح عبر AwardBadgeAsync من Script على الخادم. قبل الاستدعاء، يجب أن يحدد المنطق المستقبلي إن كان هذا اللاعب قد أكمل هذا المسار. رسالة العميل «أنهيت» أو حركة مرئية لا تحل محل فحص حالة اللعبة.
سجل مكان حفظ التقدم وطريقة تحديد النهاية الصالحة. أدرج الحالات المرفوضة: مراحل البداية ناقصة، أو نهاية تخص مساراً آخر، أو إنجاز مؤكد بالفعل. هذه متطلبات تنفيذ مقترحة، وليست نتائج اختبارات أجريناها أو قاعدة منح بلا شروط.
افتح الصورة بالحجم الكامل ↗افصل المعلومات والمنح والملكية #
يحصل GetBadgeInfoAsync على معلومات الشارة ومنها IsEnabled. يمنح AwardBadgeAsync الشارة، ويفحص UserHasBadgeAsync ملكية شارة محددة. تجيب هذه الاستدعاءات عن أسئلة مختلفة، ولا ينبغي دمجها في ملاحظة واحدة بأن كل شيء يعمل.
سجل منفصلاً اختيار الشارة الصحيحة والإتاحة والشرط وانتهاء استدعاء المنح وفحص الملكية. احتفظ بحساب الاختبار وbadgeId في سجل خاص. لا يحتاج المقال العام إلى بيانات حقيقية للاعبين أو كلمة مرور القارئ لتوضيح الخطة.
راجع أكثر من نجاح الاستدعاء المحمي #
يسرد API نتيجة boolean لكل من AwardBadgeAsync وUserHasBadgeAsync. يبين الاستدعاء المحمي بصورة منفصلة وجود الاستثناء والقيمة التي أعادتها الدالة الداخلية. لذلك لا تسم غياب الخطأ تلقائياً منحاً ناجحاً؛ راجع طبقتي النتيجة.
وبالمثل، يترك خطأ فحص الملكية النتيجة مجهولة ولا يثبت غياب الشارة. يحتفظ سجلنا المقترح بالطبقتين والقرار التالي. لا تعرض «تم الاكتساب» بثقة عندما لم تلاحظ إلا تشغيل دالة أو ضغط زر، دون دليل النتيجة المطلوبة.
أدرج التكرار والحالات غير المتاحة #
تتضمن الخطة لمس النهاية ثانية، وشارة مملوكة مسبقاً، وكائناً معطلاً، ومعرفاً خاطئاً، وفشل جلب المعلومات. حدد لكل حالة ما هو معلوم وما الذي يمكن أن تقوله الواجهة بصدق. لا تحول كل خطأ إلى منح جديد أو تعتبر غياب الدليل نجاحاً.
افحص الدخول اللاحق بصورة منفصلة. ملكية الشارة وتقدم المسار حالتان مختلفتان؛ تأكيد إحداهما لا يثبت الملف كله. إن احتجت إلى ميزة لعب أخرى، فراجع تطبيقها وحفظها بسيناريو مستقل، لا باستنتاج تلقائي من وجود الشارة.
خطط لاختبار محدود وسجل الملاحظات #
استخدم مشروع تدريب منفصلاً وهدفاً محدداً. راجع السلوك قبل النهاية، ثم الاكتمال الصحيح والتكرار. يطرح الجدول التالي أسئلة متوقعة، وليس تقرير منح حقيقي. لا تختبر ألعاب الآخرين أو حساباتهم أو تعدل مشروعاً منشوراً لعرض المقال.
احفظ الخطوة والحالة الأولية ونتيجة API ونتيجة الملكية. بعد تغيير شرط، كرر السيناريو الذي كشف المشكلة. استدعاء محاكى ومخطط ذهني وفحص فعلي في Studio تقدم أدلة مختلفة؛ وضح المستوى حتى لا تتحول المحاكاة إلى ادعاء اختبار المنصة.
| السيناريو | ما يُفحص |
|---|---|
| قبل النهاية | هل الشرط غير مؤكد بعد؟ |
| نهاية صالحة | ما الذي يؤكد الاكتمال؟ |
| التكرار | هل الملكية والإشارة المكررة منفصلتان؟ |
| خطأ API | هل المجهول لا يسمى نجاحاً؟ |
انقل البطاقة إلى المطور التالي #
تتضمن البطاقة الهدف والوصف واللعبة وbadgeId المستقبلي والإتاحة وشرط الخادم ومصفوفة المراجعة. أدرج منفصلاً ما لم ينفذ والملاحظات المطلوبة قبل الإطلاق. بذلك يفهم Chat آخر المهمة دون تخمين الأفكار السابقة.
جاهزية إنجاز تدريب واحد لا تثبت صحة كل مكافآت اللعبة. لم ننفذ إنشاء أو دفعاً أو منحاً هنا. النتيجة المفيدة قاعدة قابلة للمراجعة وخطة أدلة لينفذها مطور ويتحقق منها لاحقاً في بيئة متفق عليها.
افتح الصورة بالحجم الكامل ↗| الحقل | ما يُسجل |
|---|---|
| الهدف | الفعل الدقيق في الوصف |
| الكائن | اللعبة الصحيحة والمعرف والإتاحة |
| المنطق | شرط الخادم والتكرار |
| الدليل | نوع الاختبار والنتيجة الملاحظة |
المصادر الأصلية
Roblox Creator Hub — BadgesRoblox Creator Hub — BadgeService API
