ما هي اللعبة
تحفر، وتبيع أو تحتفظ بما تجده، وتملأ الفهرس. العملات تشتري مجرفة أفضل، والمجرفة الأفضل تحفر أسرع وتصل إلى جواهر أندر. العملات وإنجازات الفهرس تفتح أيضًا مناطق جديدة، لكل منها كتالوج جواهر خاص بها. وبجانب الحفر هناك حيوانات أليفة من بيوض المناطق، مهام يومية وأسبوعية، قبو يمكنك المشي فيه لعرض أفضل اكتشافاتك، وفعاليات محدودة بالوقت. الولادة من جديد تعيد ضبط عملاتك وأدواتك ومناطقك مقابل حظ أكبر، مع الاحتفاظ بفهرسك وحيواناتك الأليفة ومستحضرات تجميلك. أبعد المناطق هي مجموعة جزر جحيمية، يمكن الوصول إليها عبر بوابة بعد هزيمة زعيم، مخصصة للاعبين الذين أعادوا الولادة بما يكفي ليريدوا مكانًا جديدًا للحفر.
احتمالات حقيقية، وإثباتها
الفكرة كلها هي أن "كل جوهرة تُظهر احتمالها الحقيقي. لا أسرار." وهذا لا يعني شيئًا إلا إذا كانت الاحتمالات المعروضة على الشاشة هي نفسها التي يحسبها الخادم فعليًا. RollService، الوحدة المسؤولة عن كل عملية سحب، تم اختبارها بتشغيل بذرة عشوائية ثابتة لمليون عملية حفر تتحقق من النتيجة مقابل جدول الاحتمالات: أسوأ انحراف عبر الكتالوج بأكمله كان 1.75 سيغما، وهو ضمن ما يجب أن ينتجه سحب عادل تمامًا، بمعدل 168,000 عملية سحب في الثانية داخل أداة الاختبار عبر سطر الأوامر. تعمل هذه الأداة خارج Roblox تمامًا، مقابل نفس وحدات Luau التي تستخدمها اللعبة الحية، لذلك اختبار الاحتمالات لا يختبر نسخة من المنطق، بل يختبر المنطق نفسه.
كل شيء عبارة عن جدول إعدادات
الجواهر والأسعار واحتمالات السقوط وتخطيطات المناطق وعناصر المتجر، كلها تعيش في وحدات إعدادات Luau بدلًا من أن تكون مبعثرة داخل منطق اللعبة. المنطقة الأولى وحدها، Meadow، كتالوج من 49 صفًا، واللعبة الكاملة تضم الآن مئات الجواهر عبر تسع جزر في العالم العلوي بالإضافة إلى عالم الجحيم. إبقاء كل رقم في الإعدادات يعني أن سلّم ندرة بهذا الحجم يمكن موازنته بتمريرة على غرار جدول بيانات، لا بتعديل سطر برمجي لكل جوهرة.
ويكي لا يعرض إلا ما هو منشور فعليًا
يُنشأ ويكي اللاعبين
مباشرة من إعدادات اللعبة نفسها، لذا تتطابق الجواهر والمناطق والحيوانات الأليفة والمجارف والرموز على
الويكي مع اللعبة تمامًا، دون أي شيء يحتاج إلى مزامنة يدوية. تقرأ عملية البناء أحدث وسم git من نوع live-v<version>،
لذا أي شيء لم يُنشر بعد على Roblox لا يمكنه الظهور على الويكي إطلاقًا، حتى لو كان موجودًا بالفعل في
الكود. المشكلة الخفية في هذا التصميم: الأداة التي تنشر إصدار مكان جديد لا تنشئ ذلك الوسم من
تلقائها، فخرجت سلسلة من التحديثات دون وسم، وبقي الويكي متأخرًا بصمت عدة إصدارات إلى أن أُضيف الوسم
يدويًا وأُعيد نشر الموقع. الآن يتبع كل نشر وسمٌ، ثم إعادة نشر.
الشحن على دفعات، كإصدارات للمكان
تخرج التحديثات كإصدارات مرقّمة لمكان Roblox، كل واحد منها دفعة صغيرة ومسمّاة من التغييرات بدلًا من إصدار كبير واحد. تمريرة لتحسين تجربة اللعب، نظام زعماء وآثار، سلسلة من جزر الجحيم: كل واحدة تصل كإصدار مستقل بذاته، موسوم ومُتحقق منه قبل بدء التالي. هذا يجعل كل تغيير قابلًا للتتبع إلى ما شُحن بالضبط ومتى، ويعني أنه يمكن تحديد الإصدار الذي أدخل أي خلل بدقة.
أخطاء لا تظهر إلا في اللعبة الحية
التجميع النظيف واجتياز كل اختبار غير متصل لا يقول شيئًا عن شكل اللعبة الفعلي أثناء التشغيل. بضعة أخطاء لم تظهر إلا بفتح Studio ولعب النسخة الحقيقية:
- الإضاءة القديمة. شُحن إصدار دون ضبط
Lighting.Technology، فحُمّل على محرك العرض القديم Legacy، الذي لا يعرض Atmosphere إطلاقًا. كان إعداد الضباب في كل منطقة يُتجاهل بصمت، ولم يتضح ذلك إلا حين نظر أحدهم فعليًا إلى العالم داخل Studio. - سباق ظهور اكتُشف بعد النشر. كان سكربت منفصل يبني مشاهد العالم بالتوازي مع السكربت الذي يضع نقاط ظهور الجواهر، وكانت نقاط الظهور تعمل أحيانًا أولًا. كشف فحص مباشر بعد النشر أن 18 من أصل 50 عنصرًا للالتقاط كانت داخل التلال والصخور. كان الحل بناء المشاهد مباشرة بعد بناء العالم نفسه، بترتيب ثابت، وأكّد الإصدار التالي نجاح الحل.
- نقرة ترقية بدت كتأخر. أبلغ اللاعبون عن تأخر زر المتجر عند الترقية بسرعة. كان محدّد الطلبات في المتجر يُسقِط الطلبات بصمت بمجرد أن ينقر اللاعب أسرع مما تسمح به ميزانيته، فيبقى الزر ساكنًا لبضع ثوانٍ. رفع ميزانية الطلبات أصلح ما بدا وكأنه تأخر، لكنه كان في الحقيقة محدّدًا بلا أي استجابة.
كيف بُنيت
أبني هذا بمفردي، في Claude Code مع وكلاء فرعيين ينفذون العمل بالتوازي بينما أراجع وأوجّه. هذا يُبقي كتالوجًا كبيرًا ومجموعة ميزات ضخمة قيد الحركة دون أن يمر كل تغيير عبر طابور خطي واحد.