Task Scheduler

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 Class.Animator)|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 a 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:

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 RenderStepped.

  • 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 events like Stepped or 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. Stepped happens before physics, while Heartbeat happens after physics. Therefore, gameplay logic that affects the physics state should be done in Stepped, such as setting the Velocity of parts. In contrast, gameplay logic that relies on or reacts to the physics state should be handled in Heartbeat, such as reading the Position of parts to detect when they enter defined zones.

  • Motor6D transform changes should be done on the Stepped event. If you don't, Animators will overwrite changes on the next frame. Even without an Animators, Stepped is the last Lua event fired before Motor6D.Transform is applied to part positions.