Un classique de plus, un problème de plus
Popularisé par les téléphones Nokia à la fin des années 1990, Snake est un formidable exercice de logique sur grille. Là où Pong tenait dans la physique continue d'une balle, Snake se joue en cases discrètes : chaque déplacement est un pas d'un état vers le suivant. Un terrain idéal pour illustrer la gestion d'un état de jeu propre et de collisions fiables.
Une cadence de jeu découplée du rendu
Le serpent n'avance pas à chaque image, mais à intervalle fixe. Je sépare donc
deux horloges : le rendu, cadencé à 60 fps par
requestAnimationFrame pour rester fluide, et la logique,
déclenchée tous les N millisecondes via un accumulateur de temps.
Ce découplage garantit une vitesse de jeu identique quel que soit l'écran, et
permet d'accélérer la partie — en réduisant l'intervalle à chaque fruit — sans
toucher au rendu.
Le serpent, une simple file
Le corps est modélisé comme une file de cases. À chaque pas, j'ajoute une case en tête dans la direction courante et je retire la dernière — sauf lorsqu'un fruit est mangé, où la queue est conservée : le serpent grandit d'exactement une case. Cette structure rend la mise à jour triviale et sans allocation superflue, même quand le serpent occupe la moitié du plateau.
Des collisions sans surprise
Deux fins de partie possibles : sortir du plateau, ou se mordre la queue. La première est une comparaison de bornes ; la seconde, une recherche de la future tête dans le corps. Un détail compte : un demi-tour instantané est interdit, sinon le serpent se rentrerait dedans dès le premier pas. La direction n'est donc validée qu'au moment du pas suivant, ce qui évite aussi qu'une rafale de touches sur une même image ne provoque un retournement illégal.
Un fruit toujours atteignable
À chaque fruit mangé, le suivant est tiré au sort parmi les cases libres uniquement. Jamais sous le serpent, jamais hors d'atteinte — et, en fin de partie théorique, le plateau se remplit proprement jusqu'à la dernière case. Ce sont ces petits invariants, posés dès la conception, qui distinguent un code qui « marche » d'un code qui ne casse jamais. La même rigueur, appliquée à vos projets, évite bien des bugs en production.
