ตัว จัดตารางงาน จะประสานงานการทำงานในแต่ละเฟรมขณะที่เกมกำลังทำงาน แม้ว่าเกมจะถูกหยุดชั่วคราว งานเหล่านี้รวมถึงการตรวจจับการป้อนข้อมูลจากผู้เล่น การสร้างอนิเมชันให้กับตัวละคร การอัปเดตการจำลองฟิสิกส์ และการดำเนินการสคริปต์ในสถานะ task.wait()
แม้ว่าจะมีงานหลายอย่างที่กำลังดำเนินการอยู่ ตัวจัดตารางงานอาจถูกโหลดเกิน โดยเฉพาะในสถานการณ์ต่อไปนี้:
- การใช้ตัวละครหรือแผนการป้อนข้อมูลที่กำหนดเอง
- การสร้างอนิเมชันด้วยตนเอง (แทนที่จะใช้ Animator)
- ขึ้นอยู่กับฟิสิกส์ที่แม่นยำมาก
- การทำซ้ำวัตถุเป็นประจำ
RunService
วิธีที่ตรงไปตรงมาที่สุดในการเพิ่มงานที่เป็นเฟรมต่อเฟรมคือผ่านสมาชิกต่อไปนี้ของ RunService:
ลำดับความสำคัญของตัวจัดตาราง
ตัวจัดตารางงานจะจัดหมวดหมู่และทำงานในลำดับต่อไปนี้ บางงานอาจไม่ดำเนินการในเฟรมเดียว ในขณะที่บางงานอาจทำงานหลายครั้ง
* การดำเนินการสคริปต์ในระหว่าง RunService.Heartbeat จะแตกต่างกันขึ้นอยู่กับการตั้งค่า Workspace.SignalBehavior ของเกมของคุณ ดู Deferred events
แนวทางปฏิบัติที่ดีที่สุด
เพื่อสร้างเกมที่มีประสิทธิภาพโดยคำนึงถึงประสิทธิภาพ โปรดสังเกตดังต่อไปนี้:
ไม่ควรเชื่อมต่อ/ผูกฟังก์ชันกับขั้นตอนการแสดงผล เว้นแต่จะจำเป็นจริงๆ งานที่ต้องทำหลังจากการป้อนข้อมูลแต่ก่อนการแสดงผล เช่น การเคลื่อนไหวของกล้อง ควรทำในลักษณะนี้ สำหรับการควบคุมลำดับที่เข้มงวด ให้ใช้ BindToRenderStep() แทน PreRender
จัดการสถานะของฟิสิกส์อย่างระมัดระวัง PreSimulation จะเกิดขึ้น ก่อน ฟิสิกส์ ขณะที่ PostSimulation จะเกิดขึ้น หลัง ฟิสิกส์ ดังนั้นตรรกะการเล่นเกมที่มีผลต่อสถานะฟิสิกส์ควรทำใน PreSimulation เช่น การตั้งค่า Velocity ของชิ้นส่วน ในทางกลับกัน ตรรกะการเล่นเกมที่เกี่ยวข้องกับสถานะฟิสิกส์หรือตอบสนองต่อสถานะฟิสิกส์ควรทำใน PostSimulation เช่น การอ่าน Position ของชิ้นส่วนเพื่อตรวจจับเมื่อพวกเขาเข้าสู่โซนที่กำหนด
การเปลี่ยนแปลงการแปลงของ Motor6D ควรทำในเหตุการณ์ PreSimulation หากคุณไม่ทำเช่นนั้น Animators จะเขียนทับการเปลี่ยนแปลงในเฟรมถัดไป แม้จะไม่มี Animator ก็ตาม PreSimulation จะเป็นเหตุการณ์ Luau สุดท้ายที่ถูกเรียกก่อนที่การแปลง Motor6D.Transform จะถูกใช้กับตำแหน่งของชิ้นส่วน