タスクスケジューラ は、ゲームが一時停止しているときでも、各フレームで行われたタスクをゲームが実行されているとして調整します。 これらのタスクには、プレイヤーの入力を検出し、キャラクターをアニメートし、物理シミュレーションを更新し、task.wait() 状態でスクリプトを再開することが含まれます。
実行中の複数のタスクがあっても、タスクスケジューラは、特に以下の状況で過負荷になる可能性があります：
- カスタムキャラクタリグまたは入力スキームを使用する。
- 自分でパーツをアニメートする (Animator を使用するのではない)。
- 正確な物理に大きく依存する。
- 定期的にオブジェクトをレプリケートする。
フレーム
A フレーム は、作業が行われるゲームロジックのユニットです。各フレームは効率的にタスクを実行し、 秒ごとにより多くのフレーム とより滑らかなプレイヤーエクスペリエンスをもたらすべきです。
ランサービス
フレームバイフレームゲームタスクを追加する最も直接的な方法は、次のメンバーを介して RunService です：
スケジューラ優先度
タスクスケジューラは、次の順序でタスクをカテゴリ化し、完了させます。いくつかのタスクはフレームで作業を行わないかもしれませんが、他のタスクは複数回実行する可能性があります。
最良の実践
効率を考慮して高パフォーマンスのゲームを構築するには、フォロー中のことに注意してください：
必要ない限り、レンダリングステップに機能を接続/バインドしないでください。: 入力後ですが、レンダリング前に行う必要のあるタスクは、カメラの動きのようにそのように行う必要があります。注文の厳格な制御には、BindToRenderStep() ではなく PreRender を使用します。
物理状態を注意深く管理する。: PreSimulation が起こる 前の 物理、 while PostSimulation が起こる 後の 物理。そのため、物理状態に影響を与えるゲームプレイロジックは、パーツの PreSimulation 設定などとして Velocity で行われる必要があります。一方、物理状態に依存したり反応したゲームプレイロジックは、PostSimulation で処理する必要があります。例えば、部品の Position を読んで、定義されたゾーンに入るときを検出するのです。
モーター6D 変換変更は、プレシミュレーションイベントで行う必要があります。: もしそうしない場合、Animators は次のフレームで変更を上書きします。 でさえなくても、 は、 がパートポジションに適用される前に発射された最後の Luau イベントです。