Un casse-tête d'entrepôt en quelques kilo-octets
Sokoban (« gardien d'entrepôt » en japonais, 1981) tient en une règle : pousser des caisses sur leurs emplacements, dans une grille de murs et de sol. On ne peut que pousser, jamais tirer, et jamais deux caisses à la fois. Cette contrainte minuscule suffit à produire des situations irréversibles — je m'en sers ici pour montrer, à ciel ouvert, comment on modélise une règle de jeu, comment on décrit un niveau en données, et comment on rend une action annulable.
La logique de poussée, au cœur du jeu
Toute la mécanique tient dans une seule fonction. Quand le joueur avance d'un pas, je regarde la case visée : si c'est un mur, rien ne bouge ; si elle est libre, le joueur s'y déplace ; si elle contient une caisse, je regarde la case juste derrière — le déplacement n'est autorisé que si cette case-là est elle-même libre (ni mur, ni autre caisse). C'est cette double vérification qui interdit de pousser deux caisses d'un coup et qui rend certaines erreurs définitives. Une règle claire, exprimée en quelques lignes, plutôt qu'un empilement de cas particuliers.
Des niveaux décrits en données, pas en code
Chaque niveau n'est pas dessiné dans le code : c'est un simple tableau de chaînes
de caractères, où # est un mur, . une cible,
$ une caisse et @ le joueur. Un court analyseur
transforme cette grille lisible en structures de jeu (murs, cibles, caisses,
position de départ). Résultat : ajouter, corriger ou réordonner un niveau se fait
en éditant du texte, sans toucher à la logique. Séparer les données du
moteur, c'est exactement ce qui rend un logiciel facile à faire évoluer.
Annuler, grâce à un historique d'états
Comme un mauvais coup peut bloquer une caisse, l'annulation n'est pas un confort mais une nécessité. Avant chaque déplacement, j'empile un instantané de l'état (position du joueur, position de chaque caisse, nombre de pas) dans une pile. La touche U dépile le dernier instantané et le restaure : on remonte le temps, pas à pas. C'est le même principe qui, à plus grande échelle, sous-tend le « annuler » d'un éditeur ou l'historique d'une application métier — un état immuable qu'on archive avant chaque changement.
Ce que ça dit de ma façon de travailler
Un jeu jouable en quelques kilo-octets, sans dépendance, illustre une conviction que j'applique à vos projets : la valeur naît d'un modèle juste et d'un code lisible, pas d'un empilement d'outils. Une règle bien posée, des données séparées du moteur et des actions réversibles donnent un logiciel qu'on comprend, qu'on teste et qu'on fait durer — dont vous gardez la pleine maîtrise.
