L'aveu

Il y a quelques jours, j'ai joué à Lore of the Ember et j'ai dû admettre quelque chose : un énième jeu de plateforme sur Atari ST, aussi bien réalisé soit-il, a très peu de chances d'être mémorable. La scène homebrew en a produit beaucoup, et les joueurs rétro les connaissent par cœur. Avoir un moteur fluide à 50 images par seconde ne suffit pas à marquer les esprits, parce que le moteur n'est que le véhicule.

Il fallait une mécanique centrale forte, quelque chose qu'on n'a rarement vu sur la machine et surtout qui plait.

Le déclic

Un jeu à la Chaos Engine. J'adorais les jeux Bitmap Brothers et celui là en fait partie. Mais la contrainte du STe est simple : afficher beaucoup de personnages indépendants coûte cher. Même avec toutes les astuces, au-delà d'une vingtaine de sprites animés avec leur logique, la machine s'effondre. Si je voulais l'ambiance "horde qui déborde" d'un Chaos Engine, il fallait ruser.

La solution : la menace principale n'est pas faite de sprites, mais du sol lui-même qui se corrompt.

Sur Lore of the Ember, la peste noire de 1347 n'est plus un décor narratif. Elle est le gameplay. Elle se propage sur les dalles du cimetière, du rempart, du donjon, case après case, tick après tick. Le joueur, Alaric, la combat avec la flamme de sa lanterne, qui brûle les dalles contaminées et les protège un moment.

La référence est venue immédiatement : Firemen (Human Entertainment, SNES, 1994), ce jeu oublié où le feu se propage sur la carte pendant que le joueur tente de l'éteindre. Terrain dynamique, pression constante, lecture instantanée. Exactement ce qu'il faut pour un homebrew qui veut rester en mémoire.

L'idée de jeu

Une arène fixe, une grille de dalles, sans scroll. Chaque dalle a un état : saine, infectée, en train de basculer, ou récemment nettoyée. La peste part d'un foyer et grignote ses voisines. Le joueur arrose, et les dalles touchées repassent au propre.

Je voulais que tout soit léger et nerveux, donc deux principes de conception ont guidé le proto. D'abord, la peste ne s'étend que par son front : inutile de s'occuper du cœur d'une zone déjà entièrement infectée, seule la bordure peut encore mordre. Ensuite, à l'écran, je ne redessine que ce qui change, jamais toute l'arène. En vitesse de croisière, ça se résume aux quelques dalles du front et au joueur. Résultat, l'effort est proportionnel à l'action à l'écran, pas à la taille du terrain, et la machine reste tranquille.

Ce qui donne du levier au joueur

Mon tout premier proto n'avait pas d'immunité. Le joueur nettoyait une zone, et une seconde plus tard la peste revenait comme si de rien n'était. Frustrant, inutile : le sentiment "ça ne sert à rien de tirer" tuait le jeu en trente secondes.

La correction a tout changé : une dalle nettoyée reste saine quelques secondes avant de redevenir vulnérable. Pendant ce répit, elle s'affiche différemment et refuse d'être ré-infectée. Soudain, le joueur peut se créer un vrai couloir sûr, y souffler deux ou trois secondes, avancer, puis le redessiner plus loin. Le tir a du poids, et c'est là que le jeu est devenu intéressant.

Les bugs qu'on a dû traquer pour en arriver là

Aucun proto ne naît du premier jet, et celui-ci a demandé pas mal de débogage. Trois souvenirs valent le détour.

Le premier : un crash net, écran noir immédiat, avant même le premier affichage. La routine de lecture du clavier rendait la pile dans un état déséquilibré, et le programme retournait dans le vide. Erreur de débutant !!

Le deuxième, le plus instructif : mes flèches ne répondaient pas. J'ai passé un temps fou à soupçonner le décodage des touches, à bricoler la lecture du clavier, à ajouter des indicateurs visuels pour comprendre ce qui arrivait. La cause était bête : l'émulateur envoyait mes flèches comme entrées de manette, pas comme touches, et je guettais la mauvaise chose. Surtout, le projet possédait déjà une brique de gestion des entrées éprouvée depuis des semaines. J'aurais dû partir de là dès le début.

La leçon est gravée maintenant : quand un morceau fonctionne déjà dans le projet, je pars de lui avant d'inventer autre chose.

Le résultat

Le proto tient sur un seul écran, sans le moindre sprite complexe, sans une ligne de scénario, juste la mécanique nue. Et les trois questions qui comptaient à ce stade ont toutes reçu un "oui" franc en test : est-ce qu'on ressent la tension, est-ce que nettoyer une zone est satisfaisant, est-ce qu'on a envie de relancer ? Si la mécanique nue est déjà bonne, le scénario et le pixel art vont porter le jeu bien plus loin.

La suite

Le moteur de sprites et le parallax validés précédemment ne sont pas jetés : ils reviendront comme couches d'habillage. La lanterne s'animera au-dessus des dalles protégées. Les boss de chaque acte (Le Loup Cendré, La Dame en Noir) seront les quelques sprites complexes que le budget de la machine autorise, posés sur la grille qui respire en arrière-plan. Les décors gothiques de HISTOIRE.md deviendront les habillages de l'arène selon l'acte.

Prochaine étape : poser un premier boss sur la grille de corruption et commencer à relier le gameplay au lore. L'Acte I "La Forêt des Pendus" est le terrain de test naturel, et Le Loup Cendré sera le premier semeur mobile de peste.

Le proto est téléchargeable ici (archive historique). Lance-le sur Hatari, les flèches pour bouger, le bouton fire pour nettoyer, R pour recommencer et Esc pour quitter. Tu as environ trente secondes avant que la peste ne submerge tout si tu ne bouges pas. Pour la version actuelle du jeu, voir la page d'accueil.