タスクスケジューラは、ゲームが実行される各フレームで行われるタスクを調整します。ゲームが一時停止しているときでも、これらのタスクにはプレイヤー入力の検出、キャラクターのアニメーション、物理シミュレーションの更新、task.wait()状態でのスクリプトの再開が含まれます。
複数のタスクが実行されている場合でも、タスクスケジューラは、特に以下の状況で過負荷になる可能性があります。
- カスタムキャラクターリグや入力スキームを使用している場合。
- 自分でパーツをアニメーションさせている場合（Animatorを使用するのではなく）。
- 正確な物理に依存している場合。
- オブジェクトを定期的に複製している場合。
RunService
フレーム単位のタスクを追加する最も直接的な方法は、RunServiceの次のメンバーを通じてです。
スケジューラの優先順位
タスクスケジューラは、以下の順序でタスクを分類し、完了させます。一部のタスクはフレーム内で作業を行わない場合がありますが、他のタスクは複数回実行されることがあります。
* RunService.Heartbeat中のスクリプト実行は、ゲームのWorkspace.SignalBehavior設定によって異なります。詳細はDeferred eventsを参照してください。
ベストプラクティス
効率を考慮した高性能なゲームを作成するために、以下に注意してください。
絶対に必要な場合を除いて、レンダー段階に関数を接続/バインドしないでください。 入力後、描画前に行う必要があるタスクのみ、そのように行うべきです（カメラの動きなど）。順序を厳密に制御するためには、BindToRenderStep()をPreRenderの代わりに使用してください。
物理状態を慎重に管理してください。 PreSimulationは物理シミュレーションの前に発生し、PostSimulationは物理シミュレーションの後に発生します。したがって、物理状態に影響を与えるゲームプレイロジックはPreSimulationで行うべきです。例えば、パーツのVelocityを設定することです。それに対して、物理状態に依存するまたはそれに反応するゲームプレイロジックはPostSimulationで処理する必要があります。例えば、定義されたゾーンに入ったかを検出するために、パーツのPositionを読み取ることです。
Motor6Dの変換変更はPreSimulationイベントで行うべきです。 そうしないと、次のフレームでAnimatorsが変更を上書きします。Animatorがなくても、PreSimulationは、Motor6D.Transformがパーツの位置に適用される前に発火する最後のLuauイベントです。