Studio / ROBLOX
لاعبان في Roblox Studio: تنظيم اختبار مفيد
خطط لمحاكاة تعليمية بعميلين وسجل ملاحظات A وB والخادم منفصلة. الحالة الأولية والنتيجة الشخصية والمشتركة والأفعال المتقاربة والرد المتأخر والتكرار وإعادة ظهور الشخصية والجلسة الجديدة.
افتح الصورة بالحجم الكامل ↗تشغيل واحد وثلاث زوايا للملاحظة #
وجود شخصيتين بجانب بعضهما لا يثبت أن آلية اللعب الجماعي تعمل. قد يعرض العميل A نتيجة جميلة، ويبقى عند B الكائن القديم، بينما يحتفظ الخادم بحالة أخرى. ينظم هذا الدليل الملاحظات، ولا ينشئ نظام مكافآت أو حماية عامة لأحداث RemoteEvent.
استخدم نسخة تعليمية مستقلة من مشروعك. مشهد بسيط بمكان ظهور يكفي لفحص التشغيل؛ لا تختبر تفاعلاً إلا إذا كان موجوداً بالفعل. اختر كائناً مشتركاً وعنصراً شخصياً في الواجهة إذا كان نموذجك يتضمنهما. لا تخترع قاعدة جديدة أثناء الملاحظة. لم نشغل Studio ولا ألعاب مؤلف الموقع الخمس لإعداد المقال. ما يلي خطوات وخانات فارغة، وليس تقريراً عن اختبار منفذ. ابدأ بسؤال صغير يمكن وصفه بدقة بدلاً من إعلان أن اللعبة كلها سليمة.
1. اكتب بطاقة الحالة أولاً #
سجل إصدار المشروع والوضع وعميلين والكائن المختار وشرط الجاهزية. مثلاً: ظهرت الشخصيتان وتستطيعان الحركة، والكائن المشترك موجود، واللوحة المطلوبة متاحة. حدد القيمة الأولية وفق التنفيذ وموقعي A وB. إذا كانت القيمة مجهولة فتحقق منها أولاً؛ لا تعتبر أي لون ظاهر الحالة الصحيحة بلا دليل.
افصل المتوقع عن الملحوظ. عبارة «يغير A الكائن المشترك ويرى B التغيير» مطلب، لا إثبات. قد تكون لوحة المساعدة شخصية لدى A وحده؛ قرر ذلك مسبقاً أيضاً. حدد التكرار المسموح وكيفية استعادة البداية. يكفي فعل واحد للمرور الأول. تغير عدة قوائم ومهام معاً يخفي سبب الاختلاف ويمنع مطوراً آخر من إعادة الحالة نفسها بسهولة.
2. اختر الوضع وفق السؤال #
يضيف Test/F5 الفردي شخصية، بينما يشغل Run/F8 المشهد دونها. يتطلب فحص عميلين وضع Server & Clients. تضع الوثائق الحالية أدوات الاختبار يسار شريط mezzanine في Studio. اتبع هذا الوصف بدلاً من البحث عن تبويب قديم ورد في شرح مختلف.
يفيد التشغيل الفردي في مراجعة الجاهزية. التبديل Client/Server داخله يغير جهة الملاحظة في الاختبار الفردي نفسه، ولا ينشئ لاعباً ثانياً. يوفر Server & Clients الجلسات المنفصلة المطلوبة هنا. أما Team Test فمسار مختلف مع المتعاونين، وليس ضرورياً لهذا التمرين المحلي. اكتب السؤال قبل اختيار الوضع. تلخص الجدول إمكانات كل وضع وحدوده دون تسمية كل مشهد يعمل اختباراً جماعياً.
| الوضع | هدف هذا المرور | الحد |
|---|---|---|
| Test / F5 | جاهزية فردية مع شخصية | لا ينشئ لاعباً ثانياً |
| Client / Server في اختبار فردي | جهتان للتشغيل الفردي نفسه | ليستا جلستي عميل مستقلتين |
| Run / F8 | تشغيل مشهد بلا شخصية | لا يستبدل أفعال لاعبين |
| Server & Clients · 2 · Play/F7 | عميلان وخادم لسجل A وB وS | محاكاة محلية لا لعبة عامة |
3. شغل عميلين بالضبط #
اختر Server & Clients من قائمة الاختبار، وحدد عدد العملاء 2 ثم اضغط Play أو F7. يفتح Studio جلسات مستقلة: خادماً محاكياً وجلسة لكل عميل. انتظر اكتمال البدء قبل تنفيذ الفعل. نافذة التحرير الأصلية ليست لاعباً إضافياً، وعد النوافذ وحده لا يثبت تكوين الاختبار.
سم العميلين A وB في ملاحظاتك والخادم S. تحقق من الشخصية التي يتحكم بها كل عميل ومن وجود نسختين Player داخل Players على الخادم. إذا كانت الخدمة مخفية في Explorer فاستخدم Show Services… من قائمته السياقية. سجل أسماء لاعبي الاختبار كما ظهرت؛ لا تعد بأنها Player1 وPlayer2 أو حسابات حقيقية. عند بدء غير مكتمل أصلح تكوين الجلسة أولاً، ثم نفذ السيناريو.
4. جهز الملاحظة، لا سكربتاً جديداً #
افتح Explorer وOutput عبر Window؛ تذكر الوثائق أيضاً أزرارهما في أشرطة الأدوات. يستخدم Explorer للكائن المحدد وقيمه، بينما يعرض Output الأخطاء والرسائل الموجودة أصلاً. تساعد Show Context وShow Timestamp وعند الحاجة Show Source في حفظ مصدر الإدخال وترتيبه. لا يلزم إضافة سكربت جديد لهذا الدرس.
حدد جهة كل سجل: A أو B أو S. يشير LocalPlayer إلى لاعب العميل الحالي، أما الخادم فيتعامل مع لاعبي الجلسة. كلمة «اللاعب» دون دور غامضة. لا تخف خطأ بمرشح قبل توثيقه. غياب الرسائل لا يثبت غياب العملية؛ ربما لا يطبع النموذج شيئاً. سجل نقص الأدلة بوضوح، وناقش تغييرات التشخيص بعد المرور الأصلي بدلاً من اختراع نتيجة.
5. سجل ثلاث حالات أولية مستقلة #
قبل أول إدخال، أنشئ ثلاث ملاحظات. A: مكان الشخصية والكائن المرئي وحالة اللوحة الشخصية. B: المعلومات نفسها من منظوره. S: الكائن المعني وقيمة الخادم وأعضاء Players والسجل المتاح. لا تنسخ قيمة الخادم في خانة B كأنه شاهدها بنفسه.
النتيجة المشتركة لا تستلزم صورة متطابقة. قد تختلف الكاميرات واللوحات المحلية والمناطق المتاحة. في مشروع يستخدم streaming، غياب كائن بعيد عند عميل ليس خطأ تلقائياً. جهز ظروفاً قابلة للمقارنة بوضع الشخصيتين قرب الكائن المختار، وسجل ما هو متاح فعلاً. تحريك الكائن من Explorer الخادم وسط الاختبار للحصول على صورة مرغوبة تدخل مستقل ببداية أخرى، وليس ملاحظة محايدة يمكن إخفاؤها في السجل.
افتح الصورة بالحجم الكامل ↗6. اختبر بالتناوب قبل حالات التعارض #
دع A ينفذ فعلاً محدداً مسبقاً بينما يراقب B فقط. سجل استجابة واجهة A وحالة الخادم والنتيجة المرئية لدى B، ثم قارن الثلاثة بالمطلب. وثق الاختلاف قبل تعديل الكود؛ وإلا تأتي الملاحظة من إصدار والاستنتاج من إصدار آخر.
استعد البداية المتفق عليها واعكس الدورين: يعمل B ويراقب A. يمكن لقاعدة مشتركة أن تغير العميلين عمداً. بالمقابل، فتح مساعدة A الشخصية لا ينبغي أن يفتح لوحة B إذا كانت القاعدة محلية. كلا التوقعين جزء من مواصفاتك. تفيد جهة الملاحظة الثانية في فحص هذا الفرق، لا في فرض شاشة متطابقة دائماً. إذا لم يتضمن النموذج عنصراً شخصياً فضع الحالة غير منطبقة بدلاً من صنع نتيجة.
7. صف الأفعال المتقاربة بدقة #
جهز حالة ينفذ فيها A فعلاً ويتبعه B بسرعة. كرر من البداية مع عكس الترتيب، وسجل تسلسل الإدخال الحقيقي. شخص واحد ينتقل بين نافذتين لا يضمن وصول الطلبين في دورة معالجة الخادم نفسها. سمها أفعالاً متقاربة، لا تزامناً مثبتاً.
سياسة التعارض تخص الآلية الموجودة: ربما يسمح بتغيير واحد، أو توضع الأفعال في طابور، أو يرفض الثاني. اكتب السياسة المختارة دون اختراعها لهذا المقال. رؤية B لكائن متغير بعد A ليست وحدها فشلاً. قارن التسلسل بالقاعدة. التزامن الدقيق يحتاج حالة منفصلة مضبوطة؛ ضغطتان سريعتان لا تثبتان فحص كل حالات التنافس. ترتيب واضح وقيم معروفة أفضل من عبارة عامة تقول إن الضغط المتزامن نجح.
8. افصل الرد المتأخر عن تكرار الفعل #
إذا ربط التنفيذ الحالي الطلب بنتيجته فسجل هذا الارتباط. افحص هل يستبدل رد متأخر عرض فعل أحدث ومختلف. غياب النتيجة يعني أنها مجهولة، وليس رفضاً تلقائياً. أمان التكرار يعتمد على عقد الآلية الفعلي، لا على وجود زر مناسب.
استخدم Network Simulator في مرور مضبوط منفصل، وسجل إعدادات الاتجاهين. الأداة beta في Studio؛ راجع تعليمات توفرها الحالية. اختيار إعداد مسبق يجهز القيم، وApply يطبقها. الانتقال البطيء بين النوافذ ليس تأخير شبكة محاكياً. بعدها استعد قيم البداية المسجلة وطبقها: Reset يجهز Ideal Fiber لا تأخيراً صفرياً. الأداة لا تغير اتصالات اللعبة المنشورة. إذا تعذر ربط الطلب والنتيجة فوثق حدود الملاحظة بدلاً من وعد بمحاولة آمنة.
9. إعادة الظهور داخل الجلسة نفسها #
بعد مرور أولي واضح، أعد ظهور شخصية A باستخدام طريقة المشروع التعليمي الموجودة. سجل التغير لدى A وما يراه B وما يبقى على S. Character جديد ليس Player انضم حديثاً. يرتبط CharacterAdded بظهور الشخصية أو عودتها، ولا يضمن بقاء اللوحات أو المهام أو حالة اللعبة.
انتظر شرط الجاهزية مجدداً قبل العمل. قد تحتاج مراجع الشخصية القديمة أو العناصر المحلية إلى تحديث بحسب التنفيذ. لا نصلح شيئاً ولا نضيف كوداً هنا؛ نوثق حالة قابلة للتكرار للمطور. لا تسم إعادة الظهور زيارة جديدة، ولا تستبدلها بإيقاف الجلسة كلها. إذا عطل المشروع تحميل الشخصيات المعتاد فاستخدم آليته الموجودة، دون افتراض إعادة ظهور تلقائية في كل مشروع. احتفظ بحالة العودة والجلسة الجديدة كسطرين مختلفين.
10. إنهاء الاختبار ليس حفظ الملف #
بعد تسجيل الملاحظات، استخدم End Session من أي جلسة محاكاة لإنهاء جميع عملاء Server & Clients والخادم المحاكي. ينهي Stop الاختبار الفردي ويعيد الكائنات إلى حالتها السابقة. إغلاق نافذة واحدة أو الإيقاف المؤقت ليس بديلاً عاماً لإنهاء الفحص كله.
عد إلى مشروع التحرير الأصلي. لحفظ نسخة محلية استخدم File → Save to File إذا غيرت مواد التأليف. هذا ليس تخزين تقدم اللاعبين. تغييرات العالم أثناء التنفيذ لا تصبح تلقائياً تعديلات ملف. يحتاج التشغيل الجديد إلى سجل بداية جديد. إذا استخدم النموذج تخزيناً خارجياً فلا يضمن إعادة التشغيل بيانات نظيفة؛ افحص ذلك منفصلاً. احتفظ بالملاحظات خارج المشروع حتى لا تفقد ترتيب الأفعال وسياقها بعد الإنهاء.
11. سلم نتيجة يمكن تكرارها بحدود واضحة #
يتضمن التقرير المفيد الإصدار وتكوين العملاء والبداية والإدخالات الدقيقة وأدوار A وB وS والمتوقع والملاحظات الفعلية. عند الاختلاف أرفق الخطأ المتاح مع سياقه، وحدد هل تكرر من البداية نفسها. عبارة «يعمل» دون هذه الشروط لا تمنح مطوراً آخر طريقة موثوقة لإعادة الفحص.
راجعت مصادر المقال الرسمية وبنيته؛ رسومنا خطط أصلية وليست صور Studio. لم ينفذ اختبار فعلي وفق الدليل. المحاكاة المحلية لا تثبت أداء هاتف حقيقي أو خادم عام أو كل ظروف الشبكة. بعد الإصلاح أعد الحالة المحددة التي أخفقت ومرورها الأولي المرتبط. تأتي الأجهزة الحقيقية وبيئة التشغيل المطلوبة في مرحلة مستقلة. سجل صغير ودقيق يجعل العميلين زاويتي ملاحظة مفيدتين، لا مجرد نافذتين إضافيتين على الشاشة.
| الحالة / الإدخال | المعيار المحدد مسبقاً | A: الملاحظ | B: الملاحظ | S: الملاحظ |
|---|---|---|---|---|
| بداية: الطرفان جاهزان | سجل التوفر والقيمة الحقيقيين وقارنهما ببطاقة الحالة | — | — | — |
| يعمل A ويراقب B | تغيرات وفق القاعدة المشتركة وملاحظات مستقلة | — | — | — |
| يعمل B ويراقب A بعد الاستعادة | كرر مع عكس المبادر | — | — | — |
| يفتح A اللوحة الشخصية إن وجدت | مع قاعدة محلية تبقى لوحة B مغلقة | — | — | — |
| A ثم B بسرعة وبعدها العكس منفصلاً | سجل الترتيب وقارنه بسياسة التعارض | — | — | — |
| تكرار ورد متأخر: مرور منفصل | اربط الطلب بالنتيجة ولا تستبدل عملية أحدث مختلفة | — | — | — |
| عودة شخصية A داخل الجلسة | راجع الجاهزية وCharacter والحالة المطلوبة | — | — | — |
| End Session ثم بدء جديد | سجل التكوين والبداية مجدداً؛ لا تفترض بيانات خارجية نظيفة | — | — | — |
المصادر الأصلية
Roblox Creator Hub — Studio testing modesRoblox Creator Hub — Client-server runtime
Roblox Creator Hub — Players
Roblox Creator Hub — Player
Roblox Creator Hub — Explorer
Roblox Creator Hub — Output
Roblox Creator Hub — Network Simulator
Roblox Creator Hub — Place files
