The Task Scheduler coordinates tasks done each frame as the game runs, even when the game is paused. These tasks include detecting player input, animating characters, updating the physics simulation, and resuming scripts in a wait() state.
While there may be multiple tasks running, the task scheduler can potentially be overloaded, especially in the following situations:
- Using a custom character rig or input scheme.
- Animating parts yourself (instead of using an Animator).
- Depending heavily on precise physics.
- Replicating objects regularly.
Frames
A frame is a unit of game logic where work is done. Each frame should perform tasks efficiently, leading to more frames per second and a smoother player experience.
RunService
The most direct way to add frame-by-frame game tasks is through the following members of RunService:
- Class.RunServer.PreAnimation
Scheduler Priority
The task scheduler categorizes and completes tasks in the following order. Some tasks may not perform work in a frame, while others may run multiple times.
Best Practices
To build performant games with efficiency in mind, note the following:
Don't connect/bind functions to the render step unless absolutely necessary. Only tasks that must be done after input but before rendering should be done in such a way, like camera movement. For strict control over order, use BindToRenderStep() instead of PreRender.
Minimize the amount of waiting scripts. Avoid using while wait() do end or while true do wait() end constructs, since these aren't guaranteed to run exactly every frame or gameplay step. Instead, use an event like Heartbeat. Similarly, avoid using spawn() or delay() as they use the same internal mechanics as wait(). Uses of spawn() are generally better served with coroutine.wrap() and coroutine.resume() of the coroutine library.
Manage physical states carefully. PreSimulation happens before physics, while PostSimulation happens after physics. Therefore, gameplay logic that affects the physics state should be done in PreSimulation, such as setting the Velocity of parts. In contrast, gameplay logic that relies on or reacts to the physics state should be handled in PostSimulation, such as reading the Position of parts to detect when they enter defined zones.
Motor6D transform changes should be done on the PreSimulation event. If you don't, Animators will overwrite changes on the next frame. Even without an Animator, PreSimulation is the last Lua event fired before Motor6D.Transform is applied to part positions.