Coyote time et jump buffer : les douze lignes d'un bon saut
Quand les joueurs disent « le saut ne se sent pas bien », ils parlent en général de deux fonctionnalités manquantes. Les deux s'écrivent en une demi-heure.
À quoi ressemble le problème
Tous ceux qui testent votre prototype de plateforme disent la même chose : « le saut est bizarre ». Personne ne sait dire précisément ce qui cloche. Le code est correct : si tu touches le sol, saute ; sinon, ne saute pas.
Le problème n'est pas dans le code, il est dans l'humain. Le joueur appuie au moment où il remarque qu'il est sorti de la plateforme — mais il est déjà trop tard. Et quand il appuie en l'air, il s'attend à sauter à l'instant où il atterrit.
Deux petites fenêtres de tolérance
Le coyote time garde le droit de sauter ouvert un court instant après que le personnage a quitté le sol. Le nom vient du coyote de dessin animé qui court au-delà de la falaise et reste un instant suspendu.
Le jump buffer fonctionne dans l'autre sens : si le joueur a appuyé juste avant d'atterrir, cette pression est mémorisée et appliquée dès le contact avec le sol.
Quelles valeurs choisir
Dans les projets que j'ai mesurés, les deux fenêtres fonctionnent bien entre 100 et 150 ms — soit six à neuf frames à 60 FPS. Plus court, l'effet est imperceptible ; plus long, le personnage semble sauter dans le vide.
N'écrivez pas ces valeurs en dur. Mettez-les dans un ScriptableObject ou une table de données ; un designer doit pouvoir les changer sans lancer le jeu.
Jusqu'où ça va
La même logique paie partout ailleurs : mise en tampon des entrées d'attaque, tolérance du double saut, fenêtre d'accroche au rebord, jusqu'à la file de touches dans les transitions de menu.
La règle générale : quand l'intention du joueur entre en conflit avec les règles du jeu, tranchez en faveur du joueur. Les jeux qui font ça sont ceux qu'on qualifie de « réactifs ».