Le problème

Jusqu'ici, tout mon jeu tenait dans un seul écran. Une arène fixe, le héros se déplace dedans, et quand il atteint le bord, il s'arrête. C'est très bien pour un proto, mais ce n'est pas un monde. Or je voulais un vrai espace à explorer : des salles, des recoins, un boss qui poursuit, la peste qui s'installe loin du regard. Tout ça ne rentre pas dans une boîte de la taille de l'écran.

L'objectif de cette étape était donc simple à énoncer : un terrain plus grand que l'écran, et une caméra qui suit le joueur en le gardant au centre, au pixel près, sans à-coups. De plus j'ai encore et toujours en tête The Chaos Engine, autant dire que le niveau de perfection est assez élevé !

Une décision que je repoussais

Avant d'arriver là, j'ai dû régler une vieille promesse que je me faisais à moi-même. Depuis le début du projet, je répétais que Lore of the Ember serait écrit entièrement en assembleur, sans aucune facilité. C'était une contrainte que je m'imposais pour apprendre la machine à fond. Au bout de deux ans, je la connais.

Le souci, c'est qu'à chaque nouvelle fonctionnalité (caméra, monde plus grand, organisation du code en briques réutilisables), je passais un temps fou à dérouler à la main des mécaniques qui n'apportent rien au jeu. J'ai donc lâché ma règle esthétique pour me concentrer sur ce qui compte. Je garde l'assembleur pour les parties sensibles, celles qui doivent être ultra rapides à l'affichage, et je confie le reste, l'orchestration et l'état du jeu, à des outils plus confortables.

Ce que je tiens à dire clairement : je n'ai rien réécrit de ce qui marchait déjà. Le dessin des sprites, la lecture du clavier, tout le cœur graphique reste tel quel. Ce qui change, c'est seulement la colle autour, le code qui décide quoi faire et quand. Et ce code-là n'est pas dans le chemin critique, il ne ralentit pas le jeu.

La solution : un monde, une fenêtre qui se promène dessus

L'idée tient en une image. Au lieu de dessiner exactement ce que l'on voit, je prépare un monde plus large que l'écran, et l'écran n'en montre qu'une fenêtre. Le STe sait faire glisser cette fenêtre tout seul, sans que le processeur ait à redessiner le décor à chaque image. C'est ce qu'on appelle le scroll matériel, et c'est précisément ce qui rend le défilement si doux sur cette machine.

La caméra, du coup, devient un petit calcul ... tranquille : je vise à garder le héros au centre, et je bloque la fenêtre quand elle touche les bords du monde pour ne jamais montrer du vide. Le héros se promène, la fenêtre le suit, le décor défile au pixel.

En réorganisant tout ça, j'en ai profité pour ranger le code en deux familles : d'un côté un moteur générique, réutilisable pour un prochain jeu STe, de l'autre ce qui appartient en propre à Lore of the Ember. Une semaine de rangement minutieux, mais désormais chaque nouvelle pièce trouve sa place sans hésitation.

Une peste qui dort quand on a le dos tourné

Un monde plus grand pose une question nouvelle. Si le joueur laisse la peste s'installer dans un coin, puis part se promener à l'autre bout, faut-il continuer à simuler cette peste invisible ? Recalculer en permanence une corruption que personne ne voit, c'est du travail gaspillé.

J'ai donc fait "dormir" la peste hors champ. Tant qu'une zone n'est pas à l'écran, sa corruption se fige : son état est conservé, mais elle ne s'étend plus. Dès que le joueur revient, elle repart exactement d'où elle en était.

Et le plus beau, c'est que ça colle parfaitement à la fiction. La peste n'a pas de conscience, elle ne rampe pas vers le joueur. Elle se répand là où elle est, localement, sans intention. Qu'elle se mette en pause quand on s'éloigne renforce cette idée. Une optimisation qui sert le récit, c'est rare et c'est précieux.

Ce que ça donne

Le héros se promène sans clignotement, la caméra colle au joueur au pixel, le boss Loup Cendré poursuit sur tout le terrain, et la peste attend sagement que le joueur passe à portée avant de recommencer à grignoter. Pour la première fois, ça ressemble vraiment à un lieu à explorer plutôt qu'à une démo dans une boîte.

La suite

Le moteur est prêt à accueillir du contenu. Le prochain chantier, c'est de construire la vraie première salle de l'Acte I, la Lisière de la Forêt des Pendus, dessinée à la main plutôt que générée au hasard. Cela veut dire un petit éditeur de décor, un système de transitions entre salles, et les premières embuscades narratives.

Le build de cette étape est téléchargeable ici (94 Ko, archive historique). Lance dans Hatari en mode STe, flèches pour bouger, fire pour nettoyer la peste, R pour recommencer, Esc pour quitter. Promène-toi dans le monde, tu verras le scroll suivre le joueur et la peste se figer dès que tu t'éloignes. Pour la version actuelle du jeu, voir la page d'accueil.