تنسق جدولة المهام المهام المنجزة في كل إطار أثناء تشغيل اللعبة، حتى عندما تكون اللعبة متوقفة. تشمل هذه المهام اكتشاف إدخال اللاعب، وتحريك الشخصيات، وتحديث محاكاة الفيزياء، واستئناف السكريبتات في حالة task.wait().
بينما قد تكون هناك مهام متعددة تعمل، يمكن أن تكون جدولة المهام overloaded، خاصة في الحالات التالية:
- استخدام هيكل شخصيات أو نظام إدخال مخصص.
- تحريك الأجزاء بنفسك (بدلاً من استخدام Animator).
- الاعتماد بشكل كبير على الفيزياء الدقيقة.
- تكرار كائنات بانتظام.
RunService
أكثر الطرق مباشرة لإضافة مهام إطار بإطار هي من خلال الأعضاء التالية في RunService:
أولوية المجدول
تصنف جدولة المهام وتكمل المهام بالترتيب التالي. قد لا تؤدي بعض المهام عملاً في إطار واحد، بينما قد تعمل أخرى عدة مرات.
* يختلف تنفيذ السكريبت أثناء RunService.Heartbeat اعتمادًا على إعداد Workspace.SignalBehavior للعبتك. راجع الأحداث المؤجلة.
أفضل الممارسات
لإنشاء ألعاب فعالة مع التركيز على الكفاءة، لاحظ ما يلي:
لا تقم بتوصيل/ربط الوظائف بمرحلة العرض ما لم يكن ذلك ضروريًا تمامًا. يجب تنفيذ المهام التي يجب القيام بها بعد الإدخال ولكن قبل العرض بهذه الطريقة، مثل حركة الكاميرا. للحصول على تحكم صارم في الترتيب، استخدم BindToRenderStep() بدلاً من PreRender.
إدارة الحالات الفيزيائية بعناية. يحدث PreSimulation قبل الفيزياء، بينما يحدث PostSimulation بعد الفيزياء. لذلك، يجب تنفيذ منطق اللعبة الذي يؤثر على حالة الفيزياء في PreSimulation، مثل ضبط Velocity للأجزاء. في المقابل، يجب معالجة منطق اللعبة الذي يعتمد على حالة الفيزياء أو يتفاعل معها في PostSimulation، مثل قراءة Position للأجزاء لاكتشاف متى تدخل إلى مناطق محددة.
يجب تعديل تغييرات التحويل في Motor6D في حدث PreSimulation. إذا لم تقم بذلك، ستقوم Animators بإعادة كتابة التغييرات في الإطار التالي. حتى بدون Animator، فإن PreSimulation هي آخر حدث Luau يتم إطلاقه قبل تطبيق Motor6D.Transform على موضع الأجزاء.