شاشة التحميل في Roblox: اختر الموارد الضرورية واشرح الجاهزية بوضوح

حدد أول فعل يقوم به اللاعب #

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

تستخدم قائمتنا الخيالية رسما وأيقونة زر وصوتا قصيرا. الأسماء illustration وstart-icon وfirst-sound معرفات تعليمية وليست asset ID منشورة في Roblox. لا نربط صورا مستعارة ولا نقدم التمرين باعتباره اختبارا لألعابنا الخمس. الهدف هو بناء تسجيل صادق لنتائج موارد مختارة قبل توصيله بتنزيلات حقيقية وواجهة مستخدم. يوفر الموقف الخيالي نطاقا محدودا يمكن مقارنة حالاته بوضوح.

افصل تحميل المحتوى عن جاهزية التجربة #

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

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

لا تحول طابور الطلبات إلى نسبة #

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

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

أنشئ قائمة صغيرة لما تحتاجه فعلا #

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

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

افتح الصورة بالحجم الكامل ↗

احتفظ بعدادات نتائج مختلفة #

يحفظ المثال الأصلي بلغة Luau الخالصة القيم total وresolved وsucceeded وfailed. الأولى حجم القائمة، والثانية عدد النتائج المستلمة، والأخريان تفصلان النجاح والفشل. تقبل record معرفا تعليميا وقيمة منطقية. لا تستدعي Roblox API ولا تنزل ملفا ولا تقبل Enum.AssetFetchStatus مباشرة. يجب على محول حقيقي ترجمة نتيجة تحميل متحقق منها بصورة منفصلة إلى الحالة التي يحتاجها النموذج.

المثال نموذج تسجيل قابل للفحص. بعد فشل واحد ونجاحين تصبح القيم resolved=3 وsucceeded=2 وfailed=1. تعني settled وجود نتيجة لكل مدخل، بينما تبقى allSucceeded مساوية false هنا. لا تختصر الفحصين بكلمة واحدة مثل جاهز. استلام نتائج ثلاثة محاولات والحصول بنجاح على ثلاثة موارد إنجازان مختلفان، حتى لو كان عدد المدخلات المعالجة متساويا تماما في الحالتين.

-- Pure Luau bookkeeping, not a ContentProvider adapter.
-- Each manifest entry represents exactly one distinct content identifier.
local function newTracker(ids)
    assert(type(ids) == "table", "Manifest must be a table")
    local expected = {}
    local total = 0
    for _, id in ipairs(ids) do
        assert(type(id) == "string" and id ~= "", "Invalid content identifier")
        assert(not expected[id], "Duplicate content identifier")
        expected[id] = true
        total += 1
    end
    local entries = 0
    for index in pairs(ids) do
        assert(type(index) == "number" and index >= 1 and index % 1 == 0,
            "Manifest must use consecutive array indices")
        entries += 1
    end
    assert(entries == total, "Manifest cannot contain array gaps")
    local outcomes = {}
    local resolved = 0
    local succeeded = 0
    local failed = 0
    local tracker = {}

    function tracker.record(id, success)
        assert(type(success) == "boolean", "Outcome must be boolean")
        if not expected[id] or outcomes[id] ~= nil then
            return false
        end
        outcomes[id] = success
        resolved += 1
        if success then
            succeeded += 1
        else
            failed += 1
        end
        return true
    end

    function tracker.snapshot()
        return {
            total = total,
            resolved = resolved,
            succeeded = succeeded,
            failed = failed,
            settled = resolved == total,
            allSucceeded = resolved == total and failed == 0,
        }
    end

    return tracker
end

return newTracker

امنع النتائج المكررة من تغيير التسجيل #

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

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

افتح الصورة بالحجم الكامل ↗

اشرح الفشل برسالة مفهومة #

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

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

المتابعة لا تعني إلغاء التنزيل #

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

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

اختبر التسجيل والتكامل بصورة منفصلة #

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

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

احتفظ بخلاصة قابلة لإعادة الفحص #

تشمل الخلاصة المفيدة القائمة الصغيرة وأسباب الاختيار والفرق بين resolved وsucceeded والسلوك عندما لا تساوي failed صفرا وحدود جاهزية الشاشة. يجب أن يحفظ سجل النجاحين والفشل الواحد الفشل صراحة. بالنسبة للقائمة الفارغة، لا يقسم النموذج على صفر، بل يعرض حالة منتهية دون موارد. اشرح هذه الحالة بالكلمات بدلا من رسم نسبة غير معرفة قد توحي بعمل لم يحدث.

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