Un coureur, un bouton, une difficulté qui monte
Le principe tient en une phrase : le coureur avance tout seul, le décor défile de droite à gauche, et je n'ai qu'une action à ma disposition — sauter. Toute la richesse du jeu vient de ce que je place autour de ce geste unique : un défilement qui accélère, des obstacles générés à la volée et une détection de collision qui doit être parfaitement juste. C'est un banc d'essai idéal pour travailler proprement une boucle temps réel, sans moteur de jeu ni dépendance.
Un défilement à vitesse croissante
Le sol est fixe : ce n'est pas le coureur qui se déplace, ce sont les obstacles qui viennent vers lui. À chaque image, je décale tout le décor d'une distance proportionnelle au temps écoulé (delta time) et à une vitesse de défilement qui augmente lentement, seconde après seconde, jusqu'à un plafond. Cette accélération est le vrai moteur de la difficulté : plus la partie dure, moins j'ai de temps pour réagir à chaque obstacle. La montée est progressive et bornée, pour rester exigeante sans jamais devenir injouable.
Des obstacles générés avec un espacement contrôlé
Les obstacles n'existent pas à l'avance : je les crée un par un, avec une largeur et une hauteur tirées au hasard dans des bornes maîtrisées. Le point délicat, c'est l'espacement. Je raisonne en temps, pas en pixels : je laisse s'écouler un intervalle avant de faire apparaître le suivant. Comme la distance parcourue vaut la vitesse multipliée par ce temps, l'écart réel s'élargit automatiquement quand le décor accélère. Résultat : deux obstacles ne sont jamais assez proches pour être infranchissables, ni assez espacés pour rendre la partie ennuyeuse — l'écart s'adapte de lui-même au rythme.
Un saut : une impulsion, puis la gravité
Le saut est de la physique élémentaire, mais faite correctement. Un appui donne au coureur une impulsion vers le haut — une vitesse verticale négative instantanée — puis la gravité reprend la main : à chaque image, elle ajoute à cette vitesse, plafonnée en chute, et j'intègre le tout par le delta time. La courbe est donc une vraie parabole, identique sur un écran 60 ou 144 Hz. Un détail qui compte : je n'autorise l'impulsion que lorsque le coureur touche le sol, ce qui interdit le double saut et garde le jeu honnête.
Une collision AABB qui ne pardonne pas
Toucher un obstacle met fin à la partie, il faut donc que le contact soit détecté ni trop tôt ni trop tard. J'utilise une collision AABB (axis-aligned bounding box) : le coureur et chaque obstacle sont ramenés à un rectangle aligné sur les axes, et il y a impact dès que les deux rectangles se chevauchent sur l'horizontale et sur la verticale. C'est peu de calcul, exécuté à chaque image sur les seuls obstacles présents à l'écran, et le comportement reste parfaitement prévisible — exactement ce qu'on attend d'une règle qui décide de la fin de partie.
Ce que je cherche à démontrer
Derrière ce petit jeu, il y a la même exigence que sur un projet sérieux : découpler la logique du rendu, borner le temps pour un comportement identique partout, et régler la difficulté par des paramètres clairs plutôt que par des valeurs magiques. Livrer une expérience fluide et équitable à partir de règles simples et lisibles, c'est ce que j'apporte à vos interfaces critiques — un code que vous pouvez reprendre, comprendre et faire évoluer en toute autonomie.