Planificateur de tâches

*Ce contenu est traduit en utilisant l'IA (Beta) et peut contenir des erreurs. Pour consulter cette page en anglais, clique ici.

Le planificateur de tâches coordonne les tâches réalisées à chaque image pendant que le jeu s'exécute, même lorsqu'il est en pause. Ces tâches incluent la détection des entrées du joueur, l'animation des personnages, la mise à jour de la simulation physique, et la reprise des scripts dans un état task.wait().

Bien qu'il puisse y avoir plusieurs tâches en cours d'exécution, le planificateur de tâches peut potentiellement être surchargé, en particulier dans les situations suivantes :

  • Utilisation d'un rig de personnage personnalisé ou d'un schéma d'entrée.
  • Animation des parties vous-même (au lieu d'utiliser un Animator).
  • Dépendance forte à des physiciens précis.
  • Réplication régulière d'objets.

RunService

La manière la plus directe d'ajouter des tâches image par image est à travers les membres suivants de RunService :

Priorité du planificateur

Le planificateur de tâches catégorise et complète les tâches dans l'ordre suivant. Certaines tâches peuvent ne pas effectuer de travail dans une image, tandis que d'autres peuvent s'exécuter plusieurs fois.

* L'exécution des scripts pendant RunService.Heartbeat diffère selon le paramètre Workspace.SignalBehavior de votre jeu. Voir Événements différés.

Meilleures pratiques

Pour construire des jeux performants en gardant l'efficacité à l'esprit, notez les points suivants :

  • Ne connectez/liez pas de fonctions à l’étape de rendu à moins que cela ne soit absolument nécessaire. Seules les tâches qui doivent être effectuées après l'entrée mais avant le rendu devraient être effectuées de cette manière, comme le mouvement de la caméra. Pour un contrôle strict de l'ordre, utilisez BindToRenderStep() au lieu de PreRender.

  • Gérez les états physiques avec précaution. PreSimulation se produit avant la physique, tandis que PostSimulation se produit après la physique. Par conséquent, la logique de gameplay qui affecte l'état physique devrait être effectuée dans PreSimulation, comme définir la Velocity des parties. En revanche, la logique de gameplay qui dépend ou réagit à l'état physique devrait être gérée dans PostSimulation, comme lire la Position des parties pour détecter quand elles entrent dans des zones définies.

  • Les changements de transformation Motor6D doivent être effectués lors de l'événement PreSimulation. Si vous ne le faites pas, les Animators écraseront les changements lors de la prochaine image. Même sans un Animator, PreSimulation est le dernier événement Luau déclenché avant que Motor6D.Transform ne soit appliqué aux positions des parties.

©2026 Société Roblox. Roblox, le logo Roblox et Powering Imagination font partie de nos marques déposées aux États-Unis et dans d'autres pays.