Boucle du joueur Unity : séparer les mises à jour de l'entrée, de la physique et de la caméra

La frontière qui compte

Un bouton de saut, un rigidbody et une caméra de suivi fonctionnent selon des cadences différentes. Il faut considérer leur interaction comme un transfert d'intention vers la simulation, puis vers la présentation. La bonne question de conception est de savoir quel système est responsable de chaque transition d'état, et non quel callback peut accéder à tous les objets. Cet article s'appuie sur la documentation d'Unity 6.0 et sur Input System 1.14.

Connaître les trois phases

Update s'exécute avec les images rendues ; FixedUpdate peut s'exécuter zéro, une ou plusieurs fois au cours d'une même image. Utilisez cette dernière pour les forces appliquées à un Rigidbody. LateUpdate suit Update, ce qui en fait une phase adaptée à la caméra. Ces callbacks ne sont que des éléments d'une boucle du joueur (player loop) plus vaste, et non le déroulement complet. [1][2]

Transférer l'entrée de manière délibérée

Input System peut traiter les événements pendant les mises à jour dynamiques, les mises à jour fixes ou les mises à jour manuelles. Choisissez ce réglage explicitement. [3] Dans une conception qui utilise l'entrée dynamique, enregistrez l'intention de déplacement et mettez une demande de saut en file d'attente lorsque son action se déclenche. Le composant qui gère la physique lit cette intention stockée ; il ne doit pas supposer que chaque pas de physique reçoit un nouveau front de bouton. Donnez aux commandes en file d'attente une règle de consommation et, si nécessaire, un délai d'expiration.

Exemple : un robot de livraison

Prenons un robot qui déplace des caisses et saute par-dessus des câbles. On mémorise le dernier vecteur de direction et un seul saut en attente. Au pas de physique suivant, on vérifie si le saut est autorisé, on applique l'impulsion choisie une seule fois et on consomme la demande. La direction reste disponible pour les pas suivants jusqu'à ce que l'entrée change. Dans LateUpdate, on positionne la caméra à partir de la pose de présentation qui résulte du mouvement du robot. Si une image lente entraîne trois pas de physique, cette conception applique trois mises à jour de déplacement, mais un seul saut. Si aucun pas de physique n'a lieu, la demande en attente reste disponible. Il s'agit d'une conception illustrative, et non d'une implémentation mesurée.

Limites et vérification

Précisez ce qu'il advient de l'entrée en attente lors d'une pause, d'un respawn et d'une perte de focus ; sinon, un saut périmé peut se déclencher à la reprise du jeu. Une file booléenne fusionne volontairement les appuis répétés ; utilisez donc une file de commandes bornée si chaque appui compte. Ne déduisez pas l'ordre d'exécution entre des instances quelconques à partir de leur hiérarchie. [1] Testez les appuis courts et les déplacements maintenus à plusieurs fréquences d'images, puis examinez la chronologie du profileur pour détecter une consommation en double des commandes. Le lissage de la caméra et l'interpolation du rigidbody demandent chacun leur propre réglage ; déplacer du code dans LateUpdate ne suffit pas, à lui seul, à garantir un mouvement fluide.

Sources

1. Event function execution order — Unity Technologies.
2. MonoBehaviour.FixedUpdate — Unity Technologies.
3. Input System 1.14: Input settings — Unity Technologies.