# Lore of the Ember - full content dump for LLMs > Lore of the Ember is an indie action game built for the Atari 1040 STe, written in C and 68000 assembly. Top-down gothic atmosphere set during the Black Plague (Auvergne, 1347), organized around a grid-corruption mechanic where the map itself becomes the threat. The website is a French-language devlog documenting the design and the journey. This file concatenates the full text of every devlog article for convenient ingestion by language models. For a short index, see https://loreoftheember.com/llms.txt. For the human-readable site, see https://loreoftheember.com/. --- ## Project facts - Working title: Lore of the Ember - Target hardware: Atari 1040 STe (1989), 1 MB RAM, also runs on the older STf - Resolution: 320x200 low-res, 16 colors from 4096 - Languages: C and 68000 assembly, built into a bootable Atari program - Genre: top-down action, gothic horror atmosphere - Signature mechanic: cellular-automaton grid corruption - Story structure: 5 acts, one boss per act, narrative of a knight named Alaric guided by a lantern holding a presence and a promise he has forgotten - Development status: in active development since February 2026 - Website language: French ## Story overview Auvergne, 1347. The Black Plague ravages the kingdom. A knight named Alaric wakes at the foot of a forest, covered in blood that is not his own. Next to him, a lantern burns with a flame that should not exist. Taking it in hand, he hears a voice from the flame: "Find me before dawn, or you will be lost forever." The flame knows him, and carries a promise he has forgotten. She guides him, protects him, and burns the creatures of darkness; but each shot weakens the flame a little. On the hill in the distance stands the castle of Morteveille. The five acts are: I - the Forest of the Hanged (boss: the Ashen Wolf); II - the Cemetery of Morteveille (boss: the Lady in Black); III - the Castle Ramparts (boss: the Twin Gargoyle); IV - the Castle Entrails (boss: the Mirror Knight); V - the Scarlet Dungeon (final boss kept secret). --- ## Avant le premier pixel : le moteur que je traîne depuis des années - **URL**: https://loreoftheember.com/blog/000-le-moteur-que-je-traine/ - **Date**: 25 janvier 2026 - **Summary**: Lore of the Ember n'est pas un projet parti de zéro. C'est l'aboutissement d'un vieux moteur STe que j'ai recommencé je ne sais combien de fois, et d'un proto de plateforme jamais fini. Voilà pourquoi je m'y remets, et cette fois pour de bon. - **Tags**: moteur Un projet qui ne date pas d'hier Lore of the Ember, ou plutôt le moteur qui le fait tourner, je le traîne depuis des années. Pas en continu, pas tous les soirs, mais c'est le genre de projet qui revient toujours. On le range dans un tiroir, on passe à autre chose, et six mois plus tard on rouvre le dossier "juste pour voir", et on repart pour quelques nuits blanches. Le vieux squelette Avant Lore of the Ember, il y a eu un proto de plateforme, très inspiré des Castlevania de l'époque, que je n'ai jamais fini. Le genre de jeu qu'on adore et qu'on se croit capable de refaire en un week-end, jusqu'à ce qu'on découvre ce que coûte vraiment, sur une machine de 1989. Simplement le fait de faire défiler un décor proprement, c'est compliqué ;) . Ce proto n'a jamais vu le jour, mais il ne s'est pas perdu pour autant. Ce qu'il m'a laissé, c'est un squelette : de quoi démarrer la machine, afficher une image, et des essais de défilement que j'ai réécrits dix fois. Et surtout des carnets entiers de notes, des pages sur tout ce qui fait qu'une machine de cette époque peut encore surprendre l'oeil aujourd'hui. La plupart de ces notes ont fini par devenir du code qui tourne. Votre navigateur ne peut pas lire la vidéo. Télécharger la vidéo (MP4) . Le moteur à ses débuts : un simple rectangle rouge qui se déplace sur fond noir, le squelette sur lequel tout le reste s'est construit. Pourquoi ça n'a jamais abouti La vérité, c'est que je n'avais jamais vraiment décidé de finir. Je recommençais. À chaque reprise, je trouvais que l'ancien code était mal fait, je repartais de plus propre, je m'arrêtais avant le moment difficile : remplir un vrai niveau, écrire une vraie histoire, faire en sorte qu'on ait envie de continuer à jouer. La technique, c'est confortable. On peut polir un défilement pendant des mois sans jamais avoir à se demander si le jeu est bon. Et puis la vie passe par-dessus. Le boulot, le reste. Un projet solo qui n'a pas de date, personne pour vous attendre, c'est le premier qu'on sacrifie. Ce qui change cette fois Cette fois, j'ai arrêté de recommencer le moteur. Je le prends tel qu'il est, avec ses cicatrices, et je construis dessus. Toutes ces années de bricolage deviennent enfin des fondations au lieu d'un éternel point de départ. La règle que je me suis fixée est simple : on ne réécrit plus le socle pour le plaisir, on s'en sert pour faire un jeu et le finir (ça rime en plus lol). Le jeu, ce sera Lore of the Ember. Un seul, choisi, terminé. Le proto plateforme a servi de tremplin, mais la direction a changé en cours de route, et c'est tant mieux. J'y reviendrai dans un article dédié, parce que ce virage est une vrai histoire en soi. Ce que vous allez lire ici Ce devlog, ce n'est donc pas un tutoriel "comment faire un jeu STe en partant de rien". C'est le journal de la dernière ligne droite, posée sur des bases qui ont mis longtemps à exister. Je vais documenter les étapes, les décisions de design, les pivots, et les erreurs. Quand je casse une règle que je m'étais fixée, je le dis. Quand un bug me coûte trois soirées, je le raconte. Le premier article du carnet démarre là où j'ai ressorti le squelette du tiroir et où je l'ai remis d'aplomb. Pour une fois, je compte bien aller jusqu'au bout. --- ## Je ressors le moteur du tiroir : un personnage qui bouge à 50 images par seconde - **URL**: https://loreoftheember.com/blog/001-le-projet-demarre/ - **Date**: 8 février 2026 - **Summary**: Premier jalon public de la reprise : je remets d'aplomb le vieux squelette moteur et j'obtiens enfin un personnage qui se déplace de façon parfaitement fluide sur Atari STe. - **Tags**: moteur Si vous arrivez ici, lisez d'abord pourquoi je ressors ce vieux moteur . Ce carnet n'est pas un projet parti de zéro : c'est la dernière ligne droite d'un moteur STe/STf que je traîne depuis des années. Le défi Reprendre mon vieux squelette moteur et le remettre d'aplomb, pour faire enfin tourner un vrai jeu sur Atari 1040 STe et STf. L'objectif n'a pas changé depuis le premier jour : pousser la machine dans ses retranchements. Avant de penser ennemis, niveaux ou histoire, il me faut une base solide. Quelque chose qui bouge, et qui bouge bien. Ce que j'ai remis en route Je repars du socle que j'avais déjà écrit et réécrit au fil des ans : reprendre le contrôle complet de la machine et reposer les fondations. La première brique, c'est d'éviter le déchirement d'image. Quand on dessine directement sur l'écran que le joueur regarde, il voit parfois la moitié d'une frame et la moitié de la suivante, ce qui donne une cassure horizontale très laide. La parade classique consiste à travailler sur une image cachée pendant que l'autre s'affiche, puis à échanger les deux au bon moment, pile entre deux balayages de l'écran. Le joueur ne voit jamais le dessin en cours, seulement des images finies. La deuxième brique, c'est le rythme. Je cale tout le jeu sur le balayage de l'écran, cinquante fois par seconde, pour que chaque image soit calculée et affichée en cadence parfaite. Pas de saccade, pas d'à-coup. Un personnage qui se déplace au pixel Le héros n'est encore qu'un rectangle rouge, un simple placeholder. Mais il se déplace au pixel près dans les quatre directions, avec une vraie sensation de glisse. Le plus délicat, c'était de le faire avancer finement sans qu'il laisse de bavure quand il chevauche deux zones de l'écran : il fallait un dessin propre à chaque position intermédiaire. La gravité et le saut fonctionnent aussi, avec une vitesse de chute plafonnée pour que les retombées restent lisibles et contrôlables plutôt que de devenir des plongeons incontrôlables. Rien de spectaculaire encore, mais c'est déjà une sensation de jeu, et c'est exactement ce que je voulais sentir avant d'aller plus loin. Prochaine étape Le décor et le scrolling horizontal. Le STe sait décaler son affichage finement, presque pour rien, et c'est cette capacité que je veux exploiter pour obtenir un défilement parfaitement lisse. Combinée avec un rechargement du décor au bord de l'écran, c'est la pièce maîtresse qui transformera ce prototype en vrai jeu de plateforme. Résultat Le personnage rouge se déplace de manière fluide sur un fond noir avec un sol gris, à cinquante images par seconde. C'est un placeholder graphique, mais le moteur est en place et le mouvement est déjà agréable. Le reste peut commencer. Télécharger morteveille-001-moteur.prg (1.5 Ko) - Archive historique de cette étape. À lancer dans Hatari en mode STe, 1 Mo de RAM. Flèches pour bouger, haut pour sauter. Pour la version actuelle du jeu, voir la page d'accueil . --- ## Le niveau prend forme : un monde plus grand que l'écran - **URL**: https://loreoftheember.com/blog/002-tilemap-et-scrolling/ - **Date**: 22 février 2026 - **Summary**: Comment j'ai construit un décor en tuiles réutilisables, puis fait défiler le monde pour qu'il suive le joueur. Le moment où le jeu cesse d'être un seul écran fixe et devient un vrai niveau à explorer. - **Tags**: tilemap, scrolling Le problème Au départ, mon jeu tenait sur un seul écran. Le personnage pouvait courir, mais il se cognait très vite aux bords le bougre, et il n'y avait nulle part où aller. Je voulais un vrai niveau, large, avec du sol, des murs, des plateformes suspendues, quelque chose qu'on a envie de parcourir. Le souci, c'est qu'un grand niveau dessiné comme une seule immense image coûterait bien plus que toute la mémoire de la machine. Impossible. Il fallait construire le décor autrement. La solution : un décor en briques réutilisables L'astuce ce sont les tuiles. Plutôt que de stocker une image géante, je découpe le décor en petits blocs réutilisables : un bout de sol, un morceau de mur, une plateforme. Le niveau devient alors une grille qui dit simplement "ici du sol, là un mur, ici du vide". C'est léger, et ça permet de composer des décors bien plus grands que l'écran sans saturer la mémoire. Pour ce premier jet, je me suis contenté de quelques tuiles témoins : du vide traversable, du sol sur lequel on marche, un mur qui bloque, une plateforme. De quoi tester la sensation avant de soigner le graphisme. Le monde défile avec le joueur Le vrai changement, c'est que le personnage ne vit plus dans un écran, mais dans un monde. Il occupe une position dans cet espace large, et c'est la caméra qui s'occupe de montrer la bonne portion au bon moment. J'ai calé le défilement sur le joueur : tant qu'il reste au centre, on suit, et quand il approche d'un bord, le décor glisse pour le garder en vue. Avec une limite aux extrémités du niveau, pour ne pas révéler le vide au-delà. Ce défilement est encore entièrement redessiné à chaque image, ce qui n'est pas la méthode la plus économe, mais à ce stade je voulais d'abord valider le ressenti avant d'optimiser. Le résultat Le personnage se promène enfin dans un niveau plus grand que l'écran, avec un sol en bas, des plateformes en l'air et un mur. Le décor défile quand on approche des bords. C'est le moment où le projet a cessé d'être une démo statique pour ressembler à un début de jeu. Télécharger morteveille-002-tilemap.prg (2.1 Ko) - Archive historique de cette étape. Flèches pour bouger, haut pour sauter, fire pour quitter. Pour la version actuelle du jeu, voir la page d'accueil . Prochaine étape Les collisions avec le décor. Pour l'instant le joueur traverse les murs et les plateformes comme un fantôme. Il faut qu'il sente le sol sous ses pieds et qu'il bute sur les obstacles. Viendra ensuite le défilement hardware du STe, pour faire glisser le décor sans avoir à tout redessiner à chaque image. Mais ça, c'est une autre histoire. --- ## Faire défiler le STe sans effort - **URL**: https://loreoftheember.com/blog/003-hardware-scroll-ste/ - **Date**: 15 mars 2026 - **Summary**: Je voulais un décor qui glisse au pixel près, sans à-coup ni clignotement. Plutôt que de tout redessiner image par image, j'ai laissé le STe faire le travail lui-même. - **Tags**: scrolling, ste Ce que je voulais à l'écran Un décor qui glisse, doux et continu, au pixel près. Pas un défilement par paliers qui sautille, pas une image qui se déchire quand le héros avance. Le genre de fluidité qu'on ressent plus qu'on ne remarque, et qui fait dire tout de suite que le jeu est bon. Le souci, c'est qu'un Atari de 1989 ne peut pas se permettre de redessiner tout l'écran cinquante fois par seconde (et je n'ai pas attaqué le STf ...). C'est trop de travail pour le processeur, surtout s'il doit aussi animer le héros, les ennemis et la logique du jeu. Si j'avais redessiné le décor à chaque image, il ne serait rien resté pour le reste. La fausse piste Mon premier réflexe a été de me dire qu'il fallait redessiner malin, recopier seulement ce qui change. Mais même optimisé, recopier le décor en continu reste trop lourd pour la machine, et ça se voyait : le défilement traînait, le reste du jeu ralentissait avec lui. Je cherchais à faire vite une chose qui, en réalité, ne devait pas être faite du tout. La solution : laisser le STe faire le travail Le STe a un atout que son grand frère le STf n'avait pas : il sait déplacer son affichage tout seul, au pixel près, sans demander quoi que ce soit au processeur. Plutôt que de faire défiler le décor en le redessinant, je prépare une bande de décor plus large que l'écran et je demande simplement à la machine de regarder un peu plus à droite à chaque image. Le décor glisse, et le processeur, lui, n'a rien fait. C'est ce qu'on appelle le scroll matériel. Il restait à régler une astuce de la machine elle-même, qui demandait à ce que les sprites s'effacent et se redessinent au bon moment pour éviter qu'ils clignotent ou laissent des traces. Une fois cette synchronisation calée, l'image est devenue parfaitement nette en mouvement. Le résultat Un défilement pixel par pixel sur STe, fluide, sans clignotement, et qui ne coûte presque rien à la machine. Tout le temps que je n'ai pas dépensé à faire bouger le décor, je peux désormais le consacrer au héros, aux ennemis et au jeu. C'est la fondation sur laquelle reposera le reste : sans ce défilement propre, rien d'autre n'aurait l'air vivant. Télécharger morteveille-003-hwscroll.prg (2.2 Ko) - Archive historique de cette étape. Flèches pour bouger, haut pour sauter, fire pour quitter. Pour la version actuelle du jeu, voir la page d'accueil . Prochaine étape Les collisions avec le décor et des niveaux plus grands . Le joueur pourra marcher sur les plateformes, être bloqué par les murs, et explorer des espaces bien plus longs que ce que l'écran montre d'un coup. --- ## Adieu parallax, bonjour bitmap : le jour où j'ai choisi le beau - **URL**: https://loreoftheember.com/blog/004-adieu-parallax-bonjour-bitmap/ - **Date**: 29 mars 2026 - **Summary**: J'abandonne mon parallax à trois plans pour un niveau entièrement dessiné à la main. Moins de prouesse technique, beaucoup plus de cachet. Retour sur un choix qui a tout changé pour le jeu. - **Tags**: level-design, graphisme, ste Le constat Après des semaines à peaufiner mon parallax à trois plans, j'ai dû me rendre à l'évidence : le résultat n'était pas à la hauteur de ce que j'avais en tête. Oui faire une Shadow Of The Beast fluide, non de Zeus c'est pas si simple. Techniquement, ça marchait. Trois couches de décor qui glissaient à des vitesses différentes, comme dans Shadow of the Beast. Mais à l'écran, c'était fade. Sur le STe, les couleurs disponibles sont comptées, et il faut les partager entre toutes les couches. Résultat : chaque plan était pauvre, terne, et l'effet de profondeur ne suffisait pas à faire oublier la pauvreté des décors. Je veux prouver que l'Atari STe peut être beau. Un parallax qui impressionne sur le papier ne suffisait pas. Pas encore. Le déclic Ce qui rend un jeu beau sur cette machine, ce n'est pas la prouesse, c'est l'art. Un décor dessiné avec soin, où chaque pixel compte, aura toujours plus d'impact qu'un empilement de couches aux couleurs étriquées. J'ai compris que je m'étais battu pour la mauvaise chose : je cherchais à multiplier les plans alors que je n'avais même pas un seul plan vraiment beau. Sur ce hardware, l'art l'emporte sur la technique. Du moins pour l'instant. Je ne baisse pas les bras sur le parallax !! La nouvelle approche : un décor peint en entier Le principe est d'une simplicité radicale : au lieu d'assembler le décor à partir de petites tuiles répétées et de couches superposées, je dessine le niveau comme un grand tableau, d'un bout à l'autre, et la machine fait simplement défiler ce tableau. Une seule couche, mais une couche libre, où je peux placer ce que je veux où je veux. Ça me rend toutes les couleurs de la machine pour un seul décor, au lieu de les éparpiller. Chaque torche, chaque ombre, chaque détail peut enfin respirer. Des flammes qui vivent toutes seules Petit bonheur de cette approche : j'anime toutes les torches du décor d'un seul geste, en faisant tourner quelques couleurs réservées au feu. Les flammes vacillent en continu, sur toute la largeur du niveau, sans que le jeu n'ait rien à calculer en plus. C'est gratuit, et ça donne immédiatement de la vie à la forêt. Ce que j'y gagne, ce que j'y perds Je gagne une liberté artistique totale : chaque pixel peut être différent, plus rien n'est contraint par des tuiles à recoller. Je gagne aussi en simplicité, le moteur respire et le décor est superbe. Je perds le parallax : le décor tient sur une seule couche, sans effet de profondeur. Je perds aussi en souplesse, un niveau peint coûte plus cher qu'un décor fait de tuiles réutilisables, et il faut le dessiner d'un bout à l'autre, sans défilement infini. Pour ce premier jeu, c'est le bon compromis. Mais ce n'est que partie remise. Le parallax reste dans un coin de ma tête. J'ai beaucoup appris en le construisant, et le jour où j'aurai des décors dessinés spécialement pour chaque couche, et pas bricolés à la va-vite, j'y reviendrai. L'objectif à terme : un vrai parallax multicouche digne du STe. Ça viendra. La suite Le Level 1, "La Forêt Maudite", est en place : un long décor sombre, des torches animées, et mon héros qui marche et saute dedans. Prochaine étape : les ennemis et le combat. Les niveaux suivants seront plus longs et plus variés. Jouez-y maintenant Voici le jeu à cette étape. Le Level 1 "La Forêt Maudite" est jouable : décor qui défile en fluidité, torches animées, saut. Télécharger morteveille-004-bitmap.prg (183 Ko) - Archive historique de cette étape. À lancer dans Hatari en mode STe, 1 Mo de RAM. Flèches pour bouger, haut pour sauter, fire pour quitter. Pour la version actuelle du jeu, voir la page d'accueil . Déplacez-vous de gauche à droite pour parcourir le niveau, et regardez les torches vivre. Parfois, la solution la plus simple est aussi la plus belle. --- ## Des sprites enfin fluides : préparer plutôt que calculer - **URL**: https://loreoftheember.com/blog/005-sprites-preshiftes-performance/ - **Date**: 5 avril 2026 - **Summary**: Mon héros clignotait et laissait des traînées dès qu'il bougeait. Voici comment je m'en suis sorti, en empruntant une vieille astuce des jeux pros : tout préparer à l'avance plutôt que de recalculer en direct. - **Tags**: sprites, ste Le problème Mon héros refusait de bouger proprement. Dès qu'il se déplaçait, il clignotait et laissait des traînées derrière lui, et les projectiles sautaient. À l'écran, ça donnait l'impression d'un jeu tout buggué. La cause tient à la façon dont l'Atari affiche son image. Pour décaler un personnage de quelques pixels, la machine doit retravailler ses données à chaque image, cinquante fois par seconde. Pour un sprite de cette taille, c'est un travail considérable, répété en boucle, et le 68000 n'a tout simplement pas le temps de le faire pour le héros, les projectiles, le décor qui défile et la logique du jeu en même temps. Quelque chose devait sauter, et c'était l'affichage du héros. Les fausses pistes J'ai d'abord voulu confier ce travail au Blitter, la puce d'accélération graphique du STe. Sur le papier, c'est exactement son rôle. En pratique, le régler correctement pour mon cas s'est révélé d'une fragilité décourageante : des bandes parasites, des traînées, des défauts presque impossibles à isoler. J'ai ensuite essayé d'alterner entre deux images à l'écran. Ça a corrigé un défaut pour en créer un autre, des sprites fantômes qui réapparaissaient une fraction de seconde plus tard. Aucune des deux pistes n'était la bonne. La solution est venue, comme souvent sur cette machine, d'une idée plus simple. La solution : tout préparer à l'avance L'astuce, c'est de ne presque rien calculer en direct. Plutôt que de retravailler le héros à chaque image, je prépare une fois pour toutes, au lancement du jeu, toutes les positions intermédiaires possibles du personnage. Ensuite, pendant la partie, la machine n'a plus qu'à choisir la bonne et l'afficher. Le gros du travail est fait avant même que le joueur appuie sur une touche. Ça coûte un peu de mémoire, mais sur le STe la mémoire est la ressource dont on dispose, et le temps de calcul celle qui manque. C'est exactement le bon échange. Tout est automatisé : je dessine le héros dans un simple fichier image, et un outil fabrique pour moi toutes les variantes nécessaires. Si je retouche le dessin, je relance l'outil et le jeu se met à jour. Le résultat Le clignotement a disparu. Le héros se déplace proprement, les projectiles suivent, et il reste largement assez de marge pour faire vivre le reste du jeu à pleine vitesse. C'est la fondation sur laquelle reposeront ensuite les animations de marche, les ennemis et les combats. La suite Maintenant que les sprites tiennent la route, place à ce qui les rend vivants : les animations, les ennemis, et les premières confrontations. --- ## Pivot : et si la carte elle-même était l'ennemi ? - **URL**: https://loreoftheember.com/blog/006-corruption-grid-pivot/ - **Date**: 11 avril 2026 - **Summary**: Lore of the Ember change de direction. Le platformer devient un jeu d'arène où la peste se propage sur le sol et où le joueur la combat case par case. Voici pourquoi j'ai pivoté, et le ressenti de jeu que ce proto a confirmé. - **Tags**: game-design, pivot 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, pour recommencer et 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 . --- ## Un vrai monde à explorer : la caméra suit enfin le héros - **URL**: https://loreoftheember.com/blog/007-scroll-fluide-c-hybride/ - **Date**: 22 avril 2026 - **Summary**: Jusqu'ici mon jeu tenait dans un seul écran fixe. Voici comment je suis passé à un monde plus grand que l'écran, avec une caméra qui colle au héros, et pourquoi j'ai accepté de me faciliter la vie côté outils. - **Tags**: scroll, ste 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, pour recommencer, 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 . --- ## Le petit à-coup d'une fois par seconde - **URL**: https://loreoftheember.com/blog/008-chasser-spike-rasterbars-budget-accumulator/ - **Date**: 2 mai 2026 - **Summary**: Un micro à-coup dans le scroll, pile toutes les secondes. Trois tentatives de correction, une vieille astuce pour voir enfin le coupable, et un piège bien caché. - **Tags**: technique, optimisation, corruption Le symptôme En testant le jeu avec le boss actif, un détail a accroché l'oeil. Toutes les secondes, le scroll hoquetait très légèrement. Pas un ralentissement, pas un flash, juste un saut. Comme si l'image restait figée une fraction de seconde avant de reprendre sa course. Immobile, on ne voit rien. Mais dès que la caméra bouge, ça se voit, parce qu'un scroll fluide rend visible le moindre bug. Sur l'Atari ST, il n'y a pas d'outil de mesure tout fait. Une machine de 1989, un émulateur, et mes yeux. Voici l'enquête d'une soirée, une sacrée soirée ;) Première piste : la peste qui calcule trop Le suspect évident, c'était la peste. Elle se propage une fois par seconde, et à ce moment-là elle inspecte beaucoup de cases d'un coup pour décider lesquelles vont contaminer leurs voisines. J'ai d'abord traqué un calcul coûteux qu'elle refaisait sans cesse, et je l'ai remplacé par une simple valeur préparée une fois pour toutes. Sur le papier, un beau gain. Résultat : le saut est toujours là. Même fréquence, même amplitude. Bravo mais non ... Deuxième piste : trop de cases redessinées d'un coup Deuxième réflexe. Quand la peste se propage, chaque case qui change d'état doit être redessinée à l'image suivante. Si beaucoup de cases basculent en même temps, ça fait soudain une grosse pile de dessins à rattraper. J'ai donc limité le nombre de basculements autorisés par seconde, le surplus attendant son tour. Résultat : le saut est toujours là. À ce stade de la soirée, je commence à douter de mes hypothèses. Il me faut voir ce qui se passe, pas deviner. Voir le temps, enfin Il existe une vieille astuce de l'Atari ST, utilisée par les demo makers, pour visualiser où part le temps de calcul. On change la couleur de fond de l'écran à chaque étape du travail d'une image. Résultat : des bandes de couleur apparaissent, et l'épaisseur de chaque bande dit en un coup d'oeil combien de temps cette étape a coûté. Pas de chiffres, pas de tableau, juste une image qui se lit instantanément. J'ai donc coloré chaque grande phase de la boucle de jeu, et relancé. La plupart des images se ressemblaient, bien équilibrées, avec une large marge de temps libre en bas, signe que tout va bien. Et puis, pile toutes les secondes, une image radicalement différente. La phase de la peste dévorait la moitié supérieure de l'écran. Tout le reste était écrasé contre le bas, et la marge avait quasiment disparu. Le diagnostic était enfin clair et sans ambiguïté : faire tout le travail de propagation de la peste en une seule fois dépassait le temps disponible pour une image, et l'émulateur sautait alors cette image. Ni le calcul coûteux ni la pile de dessins n'étaient les vrais coupables. C'était simplement le volume total fait d'un seul coup. La bonne idée : étaler le travail Puisque tout faire d'un coup pose problème, autant répartir ce travail sur les cinquante images d'une seconde. À chaque image, la peste ne traite qu'une petite tranche. Au bout d'une seconde, toutes les tranches réunies couvrent un cycle complet. Le rythme global est conservé, mais le pic disparaît. J'implémente, je teste. Scroll parfaitement fluide, plus aucun saut. Victoire. Je commence à savourer. Puis j'entre dans la salle du boss, et tout vire au rouge en trois secondes. La peste avait déferlé sur toute la carte. Le piège caché J'ai tout de suite vu l'erreur. J'avais décidé de traiter un nombre fixe de cases par image. Quand la peste est très étendue, ce nombre fixe ne couvre qu'une petite part de la population à chaque image, et tout va bien. Mais en début de partie, quand il n'y a qu'une poignée de cases actives, ce même nombre fixe les englobe toutes, à chaque image. Du coup, chaque case tentait de contaminer un voisin cinquante fois plus vite que prévu. La peste explosait. La vraie solution, c'est de raisonner en proportion plutôt qu'en quantité fixe. Au lieu de promettre un nombre de cases par image, je garantis que chaque case sera traitée une fois par seconde, quelle que soit la taille de la population. Quand il y a peu de cases, on en fait peu par image. Quand il y en a beaucoup, on en fait plus. Le rythme reste juste dans tous les cas, du tout début paisible jusqu'à la salle du boss saturée. Nouveau test, salle du boss, scroll fluide et propagation de la peste au bon rythme. Fin de l'histoire. Ce que j'en retire Deux leçons que je garde. La première : optimiser sans diagnostic, c'est perdre son temps. Mes deux premières corrections étaient des améliorations honnêtes, mais aucune ne s'attaquait au vrai coût. La visualisation par bandes de couleur aurait dû être ma première étape, pas la troisième. C'est un cadeau de l'histoire Atari ST : aucun outil moderne ne te donne ce rendu aussi immédiat, parce que sur cette machine la frontière entre calcul et image est très mince. La seconde : étaler un travail périodique avec une quantité fixe par image est un piège dès que la population varie. Raisonner en proportion garantit le bon rythme dans tous les cas. Une évidence après coup, beaucoup moins sur le moment. Le dispositif de visualisation reste dispo dans le code, désactivé. Au prochain à-coup, je le rallume et on remet ça. Le actuel est disponible au téléchargement . Flèches pour bouger, fire pour la lanterne, pour pause, pour quitter. Teste le scroll dans la salle du boss, c'est la zone où l'optimisation se voit le mieux. --- ## Assets : une musique et un décor empruntés, et soudain ça ressemble à un jeu - **URL**: https://loreoftheember.com/blog/009-placeholders-ghouls-chaos-engine/ - **Date**: 10 mai 2026 - **Summary**: Lore of the Ember a enfin du son et un vrai décor. Ce ne sont pas les miens, ce sont des placeholders. Pourquoi j'ai fait ce choix, et ce que ça change pour la suite du projet. - **Tags**: musique, graphismes Ce qui change cette semaine Lore of the Ember vient de franchir une étape que j'attendais depuis longtemps : le jeu a maintenant du son et un vrai décor. Une musique empruntée et un décor emprunté. Des placeholders, mais des placeholders qui marchent. Résultat : quand je lance le jeu, je vois un vrai niveau défiler sous mes yeux, j'entends un thème chiptune qui colle à l'ambiance, et le personnage s'y promène. Pour la première fois, ça ressemble à un jeu. Pourquoi des placeholders Simplement parce que je ne suis pas graphiste, ni musicien d'ailleurs. Et j'aimerais terminer le moteur dans un premier temps. Alors prenons des musiques et des designs existants. Pour un proto ça passe et ça me permet d'avancer. Je félicite d'autant plus tout développeur solo qui crée un jeu de A à Z. La musique J'ai récupéré la bande son de Ghouls 'n Ghosts signée Tim Follin, dans le format chiptune standard de l'Atari ST. Le jeu la joue tout seul, en fond, sans peser sur le reste : c'est la puce sonore de la machine qui fait le travail. Le fichier contient plusieurs morceaux. Je les ai tous écoutés et j'ai gardé celui qui collait le mieux à l'ambiance. Et surtout c'est le plus connu. J'avais d'abord tenté une musique à base d'échantillons numériques. Plus propre, mais justement trop propre : ça sonnait moderne, ça trahissait le côté rétro que Lore of the Ember assume. Le chiptune, lui, est minuscule (un seul petit fichier contient tous les morceaux), il ne mange quasiment pas de ressources, et il sonne juste pour ce jeu. Le décor Pour les tuiles, j'ai pris le décor du premier monde de Chaos Engine . Ce n'est pas un copier-coller brutal : je le fais passer dans ma propre palette, ces seize couleurs froides, bleu-gris avec quelques accents rouge sang, qui donnent son identité à Lore of the Ember. Puis je l'assemble sur la carte que je dessine dans mon éditeur de niveaux, et le moteur l'affiche. J'ai choisi Chaos Engine pour de bonnes raisons. Le style colle : vue de dessus, ambiance industrielle et sombre, palette limitée, lisibilité parfaite en plein mouvement. Les tuiles sont cohérentes entre elles, bords alignés, transitions propres, je n'ai pas quarante jonctions à rattraper. Et c'est exactement ma résolution cible, donc rien à redimensionner. Qu'ils étaient bons ces Bitmap Brothers ! Et pour être honnête, Chaos Engine reste l'une des plus belles directions artistiques en vue de dessus de l'époque. Si mon placeholder est de ce niveau, le cahier des charges de la version finale est limpide. Est-ce que ça tourne bien ? Oui. Vraiment bien. Le jeu se lance sur un STe d'origine, charge en moins d'une seconde, et tourne à pleine vitesse. Pour la première fois depuis le début du projet, je peux jouer à Lore of the Ember plutôt que juste tester Lore of the Ember. Et ça change tout pour le rythme du dev. La suite Avec un vrai décor et un vrai son en place, je peux attaquer les chantiers qui en dépendaient : Équilibrer la corruption sur un fond cohérent, où elle se lit différemment que sur un écran vide. Régler les déplacements du Loup Cendré, maintenant que je vois où il coince et où il se perd dans le décor. Construire le premier acte de bout en bout : le moteur tient, les assets de chantier suffisent pour passer au vrai gameplay. Et en parallèle, tranquillement, je peux commencer à dessiner les vraies tuiles de la Forêt des Pendus et à composer la musique de Lore of the Ember, sans bloquer le reste. Mais ça, ça risque de me poser des soucis ... Le moteur est fait. Maintenant, le jeu commence. Essaye-le Télécharger morteveille-009-ghouls-chaos.zip (122 Ko, contient le et le fichier musique ). Décompresse tout dans un même dossier, lance dans Hatari en mode STe 1 Mo. Flèches pour bouger, fire pour nettoyer la peste, pour pause, pour quitter. --- ## Une heure de jeu, cinq actes, zéro ennui : penser l'accroche comme une série Netflix - **URL**: https://loreoftheember.com/blog/010-accroche-serielle-design-narratif/ - **Date**: 18 mai 2026 - **Summary**: Le moteur tient, le scroll fluide passe. Il est temps de penser à ce qui va vraiment compter : pourquoi le joueur continue de jouer. Une soirée à creuser les techniques d'accroche sérielle, et les mécaniques de Lore of the Ember qui en découlent. - **Tags**: game-design, narration, design-narratif Le problème que j'ai trop longtemps repoussé Ça fait plusieurs mois que je bosse sur le moteur. Scroll fluide, corruption de grille, sprites préparés à l'avance, peste qui se propage sans saccade. C'est beau, ça tourne, mais aucun de ces billets techniques ne répond à la vraie question : pourquoi quelqu'un irait finir ce jeu ? La scène homebrew Atari ST produit pas mal de démos techniquement impressionnantes. Certaines sont magnifiques. Beaucoup sont abandonnées par le joueur après 15 minutes. Un scroll à pleine vitesse ne suffit pas. Ce qui retient, c'est l'envie de savoir la suite . Alors j'ai posé le clavier et j'ai passé une soirée à creuser une question précise : qu'est-ce qui fait qu'à 2h du matin, on clique "épisode suivant" sur Breaking Bad plutôt que d'aller dormir ? Et comment on transpose ça à un jeu qui dure 1h, en 5 actes de 15 minutes, sur une machine de 1989 ? Les trois moteurs qu'il faut connaître L'effet Zeigarnik Un peu de sérieux au fond ! En 1927, Bluma Zeigarnik montre qu'un serveur se souvient parfaitement des commandes qu'il n'a pas encore servies, et oublie instantanément celles qu'il vient de servir. Le cerveau retient les tâches interrompues beaucoup mieux que les tâches terminées. Toute la structure du cliffhanger repose là-dessus. Si tu termines un épisode de série par une action complète (la porte se ferme, le générique), le cerveau passe à autre chose. Si tu termines au milieu d'une action (la porte s'entrouvre, noir), le cerveau reste bloqué dessus. C'est mécanique, pas culturel. La mystery box JJ Abrams, puis Damon Lindelof sur Lost, ont industrialisé une idée simple : une boîte fermée a un potentiel narratif infini tant qu'on ne l'ouvre pas. Le piège classique du procédé, c'est d'accumuler des boîtes et de ne jamais les ouvrir. La version saine, c'est que chaque mystère résolu ouvre un mystère plus grand . Récursion narrative. La courbe d'intérêt fractale Jesse Schell (Art of Game Design) parle de la courbe d'intérêt : hook de départ, escalade avec des pics et des creux, climax final. Et surtout, cette courbe est fractale. Le jeu entier a sa courbe, chaque acte a la sienne, chaque salle aussi. Sans creux, les pics ne se sentent plus comme des pics. Le calme narratif n'est pas un défaut, c'est une condition de la tension. Les jeux qui ont résolu ça en format court Quelques cas d'étude que j'ai regardés de près, parce qu'ils tiennent de l'accroche sans être des RPG de 80 heures : Return of the Obra Dinn (Lucas Pope) découpe un grand mystère en 10 catastrophes autonomes. Chaque révélation recontextualise les scènes précédentes. Le cerveau rejoue spontanément. Outer Wilds (Alex Beachum) fait de la connaissance elle-même la progression. Tu ne débloques pas d'objets, tu comprends. La boucle courte force le joueur à enchaîner naturellement. Dark Souls (FromSoftware) te montre des lieux lointains dès la première heure. Anor Londo visible au loin pendant 15h de jeu, ça crée un ancrage permanent. Hades (Supergiant) a une narration qui observe ton gameplay et y réagit. Appliquer tout ça à Lore of the Ember Les principes abstraits sont une chose. Les transposer à un jeu d'une heure sur cette machine en est une autre. Voilà les directions que je retiens. Le canal textuel dialogué avec portrait du locuteur Au départ, j'imaginais que la narration serait silencieuse ou ultra-minimale. En creusant, je me suis rendu compte que j'avais un personnage sous-exploité : la lanterne elle-même . C'est un objet qui parle au héros. Pourquoi s'interdire de lui donner une vraie présence à l'écran ? Donc un encart texte style JRPG 16-bit, avec à gauche le portrait du locuteur : soit le visage du héros quand il pense ou parle, soit la flamme de la lanterne quand c'est elle qui répond. Pas de boîte de dialogue qui gèle le jeu en combat. Jamais de texte pendant que le joueur peut mourir. Uniquement dans les salles calmes, entre deux combats, ou sur les écrans inter-actes. La bonne nouvelle, c'est que la brique de base, je l'ai déjà codée il y a quelques semaines en préparant les zones 3 et 4 de l'Acte I. Une boîte basse avec le portrait à gauche et le texte à droite, pagination au bouton, flèche clignotante "page suivante". Deux portraits sont en production, le héros et la flamme. Le monde de jeu se fige proprement pendant l'affichage, sans scintillement. Plusieurs déclencheurs sont câblés sur les zones 3 et 4 : marcher sur une tuile précise lance le dialogue, et le jeu retient ceux déjà lus pour qu'ils ne se redéclenchent pas. La boîte de dialogue en bas de l'écran : le portrait à gauche, le texte à droite. Ici c'est la flamme de la lanterne qui parle, et le jeu ne s'arrête pas pour autant. Autrement dit, la brique est là et elle tourne. Ce que la recherche récente m'a apporté, c'est surtout de comprendre à quoi elle doit servir narrativement à l'échelle des 5 actes, et d'identifier les quelques couches qui manquent encore par-dessus. Le truc rusé, c'est que le portrait du héros peut évoluer sur les 5 actes. Les cernes, la pâleur, le regard. Si je fais ça bien, un joueur attentif le remarque sans qu'on le pointe jamais du doigt. Le pipeline est déjà là pour le portrait de base : il suffit de dessiner quatre variantes et de basculer l'image selon l'acte courant. Les graines plantées Le principe est simple : dans chaque acte, un détail passif que tu ne remarques pas. Un sprite qui traîne au fond du décor, un son qui revient, un élément qui suit le personnage sans intervenir. Ces détails ne sont pas interactifs. Ils ne sont pas signalés. Ils sont juste là. Plus tard dans le jeu, ce détail prend un sens. Le joueur se souvient l'avoir vu. Ça crée une sensation très particulière : l'impression que le jeu savait. Que toi tu n'avais pas vu. Techniquement, ça coûte presque rien : un sprite en plus par acte, parfois juste un élément de décor modifié. Les fins d'acte en action interrompue C'est la partie où je reviens le plus sur mon propre travail. Les 5 textes inter-actes que j'avais écrits étaient tous réflexifs : le héros se pose une question et la formule. Ça marche pour un roman, pas pour un jeu. Version corrigée : chaque fin d'acte termine sur un mouvement en cours . Une main qui se lève, un bruit dans le dos, un objet qui tombe. On ne termine jamais une phrase. On coupe en plein geste. Le cerveau du joueur termine à ma place, et c'est exactement ce qu'on veut. Zeigarnik. Le compteur visible Détail bête qui change tout : afficher en haut de l'écran inter-acte la progression ( I / V , puis II / V , etc.). Gratuit techniquement, énorme en ressenti. Le joueur sait qu'il est à 40% de la vérité. L'anticipation monte avec le compteur. Ce qui n'a pas changé (et ne changera pas) La règle 1 reste absolue : aucun texte ne s'affiche pendant que le joueur est en action . Pas de dialogue qui coupe l'action. Pas de cinématique qui s'impose au milieu d'un combat. Les textes arrivent dans les respirations, sur les écrans inter-actes, et dans les salles-pièges qui sont volontairement calmes. L'autre règle qui tient : pas de PNJ bavard, pas de marchand qui raconte sa vie, pas de quête secondaire textuelle . Juste deux voix écrites, le héros et la flamme, et le silence autour. Priorités La boîte de dialogue tourne déjà, avec freeze et portrait. L'architecture des couches qui viennent par-dessus est verrouillée, reste à coder et à dessiner les assets. Quatre briques dans l'ordre : Un mode discret, non-bloquant qui réutilise la même boîte basse, mais sans pagination et sans voler le contrôle au joueur. Une ligne de texte apparaît, tient environ trois secondes, se retire, et le jeu reprend la main. Il sert aux murmures courts qui doivent glisser pendant qu'on marche. Interdit pendant un combat, comme toujours. Le compteur de progression sur l'écran inter-acte : "I / V", "II / V", et ainsi de suite jusqu'à la fin. Le joueur voit en permanence où il en est dans les cinq actes, et sent l'approche du dernier. Réécrire la fin du premier acte pour qu'elle coupe en action plutôt qu'en question posée. Le coût mémoire de tout ça est négligeable à l'échelle du STe. Le vrai coût sera l'écriture des lignes, qui est un exercice très différent du code. Ce que j'ai appris en faisant cette recherche Deux choses surtout. La première, c'est qu'on peut passer des mois sur la technique sans que le jeu avance réélement. J'avais refusé de penser au game design narratif tant que le moteur n'était pas stable. Résultat : j'ai failli arriver à l'Acte II avec des écrans inter-actes qui ne donnent envie à personne d'enchaîner. Le fait de me forcer à une soirée de pure théorie m'a évité ça. La deuxième, c'est que les grandes idées de narration sérielle sont étonnamment compatibles avec les contraintes du STe . Une boîte de dialogue avec portrait et texte coûte moins que beaucoup d'effets graphiques que j'ai codés. L'effet Zeigarnik ne demande rien d'autre qu'une phrase coupée au bon endroit. La graine plantée, c'est un sprite en plus. La machine ne limite pas ce genre de design. Ce qui limite, c'est l'écriture. Chaque ligne doit peser, parce qu'il n'y en a pas beaucoup. La suite Spec verrouillée, il me reste à coder. Prochaine session je branche le mode discret, je dessine les variantes de portrait et j'écris les textes. Dans un prochain article je reviendrai sur les choix de rendu du texte (notamment comment faire apparaître une phrase en douceur, spoiler : pas de fondu, on fait de l'écriture dactylo). Et si ça tient ses promesses, je montrerai une petite démo qui enchaîne une séquence d'ouverture avec les deux modes d'affichage. D'ici là, si tu as des références de jeux qui ont réussi l'accroche sur format court et que j'ai ratées, je suis preneur. --- ## Un seul jeu pour deux machines : faire scroller le STf - **URL**: https://loreoftheember.com/blog/011-scroll-logiciel-stf/ - **Date**: 26 mai 2026 - **Summary**: Le STe sait scroller tout seul, le STf non. Pour livrer un seul programme qui démarre sur les deux, j'ai dû apprendre au STf à scroller à la main. Récit d'un portage où la vraie difficulté n'était jamais là où je la cherchais. - **Tags**: stf, scroll, ste Un programme, deux machines Lore of the Ember vise le STe, une machine qui sait faire glisser son image toute seule, sans effort. C'est ce confort qui porte le moteur depuis le début. Sauf que le parc réel, ce n'est pas que du STe. Beaucoup de gens, dont je fais d'ailleurs parti ont la machine d'origine, le STf, qui ne possède pas cette aide matérielle. Et un jeu Atari ST qui refuse de démarrer sur un STf, pour une partie du public, c'est un jeu qui n'existe pas. J'avais deux options : deux versions séparées, ou un seul programme qui reconnaît la machine au démarrage et choisit son mode d'affichage tout seul. J'ai pris la seconde. Sur STe, le scroll matériel d'origine, intact. Sur STf, un scroll que j'écris pour l'occasion. Le reste du jeu, la corruption qui se propage, les commandes, les ennemis, le boss, ne sait même pas sur quelle machine il tourne. Ce post raconte ce second mode. Et surtout les semaines où j'ai cru que le problème était le scroll, alors que la vérité était ailleurs ... Le STf ne sait pas scroller Sur STf, pour faire scroller l'image, il faut tout faire à la main. Décaler le décor de quelques pixels, c'est recopier toute la zone de jeu à chaque image, et c'est lent. Si on shifte naïvement les pixels à chaque image, on tombe à moins de dix images par seconde. Injouable. J'avais documenté ce plafond dès le départ, en regardant tourner de vrais jeux livrés sur STf. La conséquence pratique, c'est que le STf affiche deux fois moins souvent que le STe. Pour que le jeu ne tourne pas au ralenti sur STf, j'ai donc rendu toute la logique indépendante de la cadence d'affichage : la vitesse du monde reste la même, que l'écran rafraîchisse vite ou lentement. Sans ça, le STf jouerait au ralenti. Restait à rendre le scroll horizontal abordable. La solution : le cache. Préparer plutôt que recalculer L'idée est la même vieille astuce que pour les sprites : ne presque rien calculer en direct. Plutôt que de retravailler le décor à chaque image, je prépare à l'avance les versions décalées des colonnes visibles, et l'affichage n'a plus qu'à recopier la bonne. Une recopie coûte bien moins cher qu'un recalcul. Quand la caméra avance, seules les colonnes qui entrent à l'écran sont préparées, le reste est déjà prêt. Ça coûte un peu de mémoire, et la mémoire était déjà tendue. J'ai donc logé ce cache dans un espace qui dormait sur STf : sur STe, le décor du tableau de bord est préparé en plusieurs copies pour suivre le scroll matériel, mais sur STf ce scroll n'existe pas, alors la place reste libre. Elle tombait pile. Sur le papier, c'était fini. Sur l'écran, ça ondulait. Les vagues, premier coupable Le décor ondulait quand le héros bougeait, surtout en haut de la zone de jeu. Une vague subtile, quelques pixels, mais bien là, et insupportable une fois qu'on l'a vue. J'ai passé un temps déraisonnable à accuser mon cache. J'ai tout désactivé un par un, méthode bête et lente, un essai à chaque hypothèse. À chaque fois, les vagues restaient. Le vrai coupable était ailleurs : une astuce d'affichage que j'avais reprise du STe et qui ne passe tout simplement pas sur le STf. Elle perturbait l'image en plein milieu de son tracé, et ça ressemblait exactement à des vagues. La leçon était nette : ce qui marche en matériel sur STe casse l'image sur STf. Je l'ai donc retirée sur STf. Le scroll, lui, ne vaguait plus pour cette raison. Sauf que les vagues étaient toujours là. Les vagues, second coupable Une fois la première piste écartée, j'ai recroisé tous mes essais. Le décor de Lore of the Ember est vivant : l'eau s'anime, la corruption se propage et change le sol en permanence. Or mon cache, qui prépare les colonnes à l'avance, figeait ce décor au moment où il l'avait préparé. Pendant que le monde continuait de bouger, le cache montrait une version périmée. En scrollant, on pouvait voir ce décalage dans le temps comme une vague. La correction s'appuie sur quelque chose que le moteur sait déjà faire : repérer les cases du décor qui changent et les redessiner. Il suffisait de rafraîchir aussi le cache pour ces mêmes cases, juste après. Le cache reste en phase avec le monde. Restait un dernier piège. Quand la peste se propage, elle change d'un coup beaucoup de cases. Tout rafraîchir dans la même image, c'est un à-coup. J'étale donc ce travail sur plusieurs images et je ralentis un peu le pouls de la corruption sur STf pour que ça suive. Le cache met une seconde de plus à se mettre à jour après un gros changement, ce qui ne se voit pas en jeu, et la fluidité ne plonge jamais. Le décor de la carrière qui défile sur les deux machines : le scroll matériel du STe d'un côté, le scroll logiciel du STf de l'autre, à la même fluidité. Les freezes qui n'étaient pas où je croyais Le jeu était fluide et stable. Puis deux gels d'une seconde sont apparus : un en allant à droite pour la première fois, un en tirant sur la peste. Écran noir, plus rien. J'ai d'abord soupçonné mon cache, puis les dialogues. Faux dans les deux cas. En enquêtant proprement, j'ai vu que l'écran restait figé en plein fondu au noir. Et les fondus, ce sont les transitions entre les salles. Le vrai coupable était une mauvaise hypothèse de départ : plusieurs séquences du moteur (fondus, transitions) avaient été écrites en supposant qu'afficher une image ne coûtait rien, ce qui est vrai sur STe mais faux sur STf. Sur STf, chaque petite étape du fondu refaisait tout le travail d'affichage, et un fondu de trois secondes en résultait. Comme le niveau est conçu pour enchaîner les salles sans couture, franchir une frontière donnait l'impression de rester au même endroit, avec un long noir au milieu. La correction est simple : pendant un fondu, la scène est figée, il n'y a aucune raison de tout réafficher à chaque étape. Trois secondes sont devenues une fraction de seconde, et les deux gels ont disparu d'un coup. Le bilan Ce qui est livré : un seul programme qui démarre sur STe comme sur STf. Sur STe, le scroll matériel d'origine, intact et rapide. Sur STf, un scroll fluide écrit à la main, sans vague et sans gel, avec une logique de jeu qui tourne à la même vitesse sur les deux machines. Ce qui reste honnêtement à faire sur STf : les dialogues. Ils s'appuyaient sur l'astuce d'affichage que j'ai dû retirer, et leur position entre en conflit avec le tableau de bord du STf. Pour l'instant, sur STf, les murmures narratifs sont sautés plutôt que de geler le jeu. Un rendu de dialogue propre au STf est le prochain chantier. Sur STe, rien n'a bougé, les dialogues sont là. La leçon de ces semaines tient en une phrase : sur STf, tout ce que le STe fait gratuitement coûte du temps, et plusieurs morceaux du moteur avaient été écrits en présumant que l'écran se mettait à jour tout seul. Ce n'est jamais le scroll qui m'a coûté le plus de soirées. C'est tout ce qui croyait l'affichage gratuit. Le build de ce jalon est téléchargeable ici (un seul binaire STe + STf). Lance-le dans Hatari en mode STf pour voir le scroll logiciel, ou en mode STe pour le scroll matériel : c'est le même fichier. Flèches pour bouger, fire pour nettoyer la peste. Pour la musique, prends plutôt l'archive depuis la page d'accueil , il faut le à côté du binaire. Pour la version courante du jeu, voir la page d'accueil . --- ## Un niveau à cheval, avec de la profondeur - **URL**: https://loreoftheember.com/blog/012-parallax-cheval-preshift-par-couche/ - **Date**: 30 mai 2026 - **Summary**: Je voulais un niveau à cheval qui scrolle vite, avec un vrai sentiment de profondeur, et qui tourne aussi bien sur STe que sur STf. Voici comment je m'en suis sorti avec une vieille astuce de pros : préparer les images à l'avance, mais juste ce qu'il faut. - **Tags**: parallax, ste, stf Un niveau à cheval Je voulais un niveau qui défile vite, façon chevauchée comme sur Ivanhoe, avec de la profondeur. Un ciel en fond, puis des montagnes lointaines, une mer, et un premier plan d'herbe qui file sous les sabots. Chaque plan bouge à sa propre vitesse : le sol scrolle vite, la mer suit plus calmement, les montagnes bougent à peine. C'est l'effet de parallax, celui qui donne l'illusion qu'on traverse vraiment un paysage, et je voulais le pousser à fond sur mes deux machines cibles, le STe et le STf. Sur le papier, c'est de la profondeur empilée. En pratique, sur Atari ST, faire glisser plusieurs plans à des vitesses différentes sans casser l'image est tout le sujet. J'ai donc commencé par un proto isolé, hors du jeu, pour valider l'idée avant de l'intégrer. C'est de ce proto que parle ce post. Votre navigateur ne peut pas lire la vidéo. Télécharger la capture (MP4) . Le proto en mouvement : sur le ciel fixe, la montagne, la mer et le sol défilent à trois vitesses différentes. Capture du proto qui tourne sur STe comme sur STf, à 50 Hz, dans 1 Mo. Le réflexe matériel, et son piège Le STe sait décaler son affichage de quelques pixels tout seul, sans effort, grâce à son scroll matériel. L'idée évidente : donner à chaque plan son propre décalage et laisser la machine faire. Zéro mémoire en plus, parfaitement fluide. Je l'ai écrit. Dans l'émulateur, c'était parfait. Scroll au pixel sur tous les plans, fluide, rien à redire. Sauf que pousser ce scroll matériel à ce point, en plein affichage, c'est du terrain miné. J'avais le souvenir d'un ancien clignotement, alors avant d'aller plus loin j'ai vérifié de vraies démos et de vrais jeux pour trancher. La réponse la plus nette vient d'une démo réputée de 1990 : son auteur écrit, mot pour mot, qu'il n'a jamais vu ce type de scroll marcher correctement sur tous les ST, qu'il a croisé une bonne quinzaine de configurations de machines différentes, et que si on voit un clignotement c'est qu'on a un modèle qu'il n'a pas pu tester. Voilà le verdict, par un pro : ce scroll matériel poussé dépend des minuscules variations entre les exemplaires d'Atari ST. Ça marche sur ma machine, ça marchera mal sur d'autres. L'émulateur ne reproduit pas ces variations, donc il me mentait par omission. Pour un jeu qui doit tourner partout, ce raccourci était à jeter. Préparer les images à l'avance, mais pas toute la scène La technique fiable, celle des vrais jeux qui scrollent proprement, c'est de préparer les versions décalées du décor une fois pour toutes, au lancement, puis de ne plus faire que des copies, bien moins chères. Le scroll fin devient un simple choix d'image déjà prête. Aucune acrobatie matérielle. Mon premier jet a préparé la scène entière dans toutes ses positions décalées. Fluide, fiable, et un mégaoctet de mémoire à lui tout seul. Sur une machine d'un seul mégaoctet, c'est mort. La leçon des vrais jeux, c'est qu'on ne prépare jamais une scène plein écran : on prépare le strict minimum. D'où le vrai correctif : préparer chaque plan séparément, avec juste la finesse qu'il lui faut. Un plan lent a besoin d'une granularité fine, parce que l'oeil fige chaque petite marche. Un plan rapide non, parce que l'oeil ne fige pas une image qui file. Le ciel, lui, est un dégradé : le faire défiler ne change rien à l'écran, une seule copie suffit. En adaptant ainsi la finesse à la vitesse de chaque plan, je suis passé d'un mégaoctet à un peu plus de la moitié, et il reste de la place pour le reste du jeu. STe et STf : les mêmes images, deux façons de les poser Sur STe, je laisse la machine pointer chaque plan vers la bonne image déjà préparée, plan par plan, en cours d'affichage. Trois plans qui bougent par-dessus un ciel fixe, fluide à pleine vitesse. Un défaut est apparu en découpant la scène en bandes : une fine ligne parasite au raccord entre deux plans. C'était un débordement d'une ligne au moment où la machine change de plan. En scène unique il tombait sur le décor voisin, invisible. En bandes séparées il se voyait. J'ai prolongé chaque image de quelques lignes de marge pour que ce débordement montre une simple continuation du décor, et la ligne parasite a disparu. Le STf, lui, ne sait pas décaler son image tout seul : il faut la recomposer à la main, chaque frame. Mais les images préparées à l'avance sont déjà là, exactement les mêmes que sur STe. Le STf n'a donc qu'à recopier la bonne image au bon endroit, sans rien recalculer. Recomposer tous les plans pleine largeur à chaque frame, c'est cependant trop lourd pour le STf, qui retomberait à mi-vitesse. J'ai donc fait un choix de game design assumé : sur STf, je fige les deux plans les plus lents, le ciel et la montagne, et je ne laisse bouger que la mer et le sol. Deux plans de profondeur au lieu de trois, mais une vitesse pleine. Le STf tourne ainsi à la même cadence que le STe. Le bilan Ce qui est livré : un proto de niveau à cheval avec de la profondeur, qui tient sur STe et STf, à pleine vitesse des deux côtés, sans clignotement et sans déchirure. Le code est solide, et surtout fiable sur le vrai matériel, pas seulement dans l'émulateur. La morale rejoint celle du portage STf : sur Atari ST, le matériel offre des raccourcis magnifiques qui ne tiennent pas toujours leurs promesses sur toutes les versions. La voie sûre est souvent la plus terre à terre, ici recopier des images préparées à l'avance plutôt que de demander à la machine un tour de force en plein affichage. Le proto est téléchargeable ici en disquette .st . Monte-la comme disquette A dans Hatari, en mode STe pour voir les trois plans défiler, ou en mode STf pour la version à deux plans mobiles : c'est le même fichier, il détecte la machine tout seul. Une touche quitte. Pour la version courante du jeu, voir la page d'accueil . --- ## 50 Hz sur STe : le bug qui n'apparaissait qu'avec des ennemis - **URL**: https://loreoftheember.com/blog/013-scanwalk-ste-ennemis-aliasing/ - **Date**: 6 juin 2026 - **Summary**: Le scroll matériel du STe me donne enfin le 50 Hz. Je croyais le moteur acquis. Le jour où j'ai lâché des ennemis qui rôdent jusqu'aux bords de l'écran, un bout de décor s'est mis à apparaître au mauvais endroit. Récit d'un piège qui était resté en suspens depuis des mois - **Tags**: technique, ste, scroll Le 50 Hz, et ce qu'il coûte Pour ce jeu vu de dessus, je veux un scroll vraiment plein, à 50 images par seconde, sur STe. La bonne nouvelle, c'est que cette machine sait décaler son affichage sans recopier l'image : elle se contente de pointer ailleurs dans sa mémoire. La caméra suit le héros, le décor file, et le processeur ne s'épuise jamais à recopier un écran entier. C'est le seul moyen d'avoir à la fois la fluidité et assez de marge pour faire vivre le gameplay. Le prix à payer, c'est la mémoire. La façon la plus simple de faire glisser l'image serait de garder le monde entier en mémoire, et ça ne tient pas sur une machine d'un mégaoctet, une fois qu'on y a logé les sprites, la musique, le code et les niveaux. J'utilise donc une disposition mémoire astucieuse, empruntée à la scène demo, qui ne garde qu'une étroite bande du monde à la fois et la redessine au fur et à mesure que la caméra avance. Ça tient dans un mégaoctet, et ça donne le scroll matériel à 50 Hz. La contrepartie ... je l'apprendrai plus tard. Le héros, lui, n'a jamais eu de problème Le héros est toujours au centre de l'écran. Pour le dessiner, je sauve le décor sous lui, je l'affiche, puis à l'image suivante je remets le décor en place. Ça fonctionne depuis longtemps, fluide, sans la moindre bavure. Je pensais le moteur OK. Le jour où les ennemis bougent J'ai branché les ennemis du niveau, des Rock Men à la Chaos Engine, qui poursuivent le héros et lui jettent des rochers. Eux ne sont pas centrés : ils rôdent sur toute la largeur de l'écran, jusqu'aux bords. Et là, un rectangle de décor s'est mis à apparaître au mauvais endroit, un bout de paroi rocheuse plaqué sur le sol gris, surtout quand je revenais sur mes pas. Tant que tous les ennemis restent entièrement à l'écran, je peux balayer la caméra à gauche et à droite sans le moindre défaut. Le décalage n'apparaît qu'au moment où j'allais un peu vite et qu'au moins un ennemi disparaissait d'un bord. La disparition d'un sprite, voilà le déclencheur. Pour voir le défaut sans être embetté par le vrai décor, j'ai remplacé chaque colonne de tuiles par une couleur unie, une par colonne, en cycle. Le décor est devenu des barres verticales colorées, et la couleur d'une barre déplacée trahissait d'où elle venait. Le verdict était net : un morceau de décor s'affichait à un endroit, mais montrait le contenu d'un autre, situé bien plus loin. Le décor réduit à une couleur par colonne. Sur le bord droit, ce bloc rouge et orange n'a rien à faire là : il affiche le contenu du bord gauche. Pourquoi le bord, et pas le centre La disposition mémoire qui me fait tenir dans un mégaoctet a une particularité : elle se replie sur elle-même. Au-delà d'une certaine largeur, deux endroits du monde finissent par se partager la même case mémoire. Tant qu'on dessine au cœur de la bande visible, ce repli tombe toujours hors de l'écran, invisible et inoffensif. C'est exactement pour ça que le héros, toujours centré, n'a jamais rien révélé : il est au milieu, loin des bords où le repli mord. Un ennemi collé au bord, lui, déborde juste assez pour que son empreinte tape dans la zone repliée. Le décor qu'on redessine sous lui finit alors recopié sur le bord opposé, hors caméra, là où on ne le nettoie jamais. La corruption s'installe en coulisses, et saute aux yeux dès qu'on revient sur ses pas. Le proto d'origine, qui n'avait qu'un héros centré, ne pouvait tout simplement pas faire surgir ce piège. Le décor de carrière, parfaitement stable pendant que tout file à 50 Hz, avec un Rock Man qui rôde jusqu'au bord de l'écran. Le bandeau du haut attend toujours son second joueur. Le correctif, sans lâcher le 50 Hz L'idée du correctif tient en une phrase : ne jamais faire confiance à une copie d'écran, toujours repartir de la source propre. Plutôt que de sauver puis restaurer les pixels sous chaque ennemi, ce qui finissait par recopier en boucle la moindre bavure déjà présente, je redessine le décor sous chaque sprite directement depuis le niveau, à chaque image. La source est toujours saine, il n'y a plus rien à propager. J'y ai ajouté une sorte de garde fou aux bords : un ennemi trop près du bord est retiré de l'écran un poil plus tôt qu'avant. À l'œil ça ne se voit quasiment pas, mais ça garantit que son empreinte ne déborde plus jamais dans la zone piégée. Et quand un ennemi sort de l'écran, je nettoie soigneusement la trace qu'il laissait, en m'assurant que ce nettoyage lui-même ne déborde pas à son tour. Le serpent ne se mord plus la queue. Le bilan Le scroll matériel tient le 50 Hz sur STe, décor, foyers de peste, héros et jet de lanterne compris, et le décor reste stable, sans rectangle fantôme, même en revenant sur ses pas à pleine vitesse avec les Rock Men et leurs rochers qui rôdent jusqu'aux bords. Une réserve honnête, mesurée manette en main : quand le combat se densifie pour de bon, trois Rock Men qui chargent en lançant leurs rochers tous en même temps, le framerate descend un peu le temps que cette grosse fournée de sprites passe. Le coût, ce ne sont ni les foyers ni l'intelligence des ennemis, ce sont ces gros sprites affichés d'un coup. Hors de ces pics, c'est du 50 Hz franc. Le même binaire bascule en scroll logiciel sur STf, détecté au démarrage. La même mécanique, redessiner depuis la source et rester loin des bords, sert ensuite à tout le reste que le scroll matériel ne savait pas encore afficher : les foyers de peste, posés derrière le héros comme du décor de fond, et le jet de la lanterne, ces chevrons que le héros projette devant lui (et que je vais devoir refaire faire par un designer ;) ). Chacun repart du niveau propre, donc aucun ne ramène de salissure à l'écran. La morale rejoint celle du parallax : sur Atari ST, les astuces mémoire qui font tenir l'impossible dans un mégaoctet ont toujours une contrepartie cachée. Ici, gagner à la fois la fluidité et la place imposait une mémoire qui se replie sur elle-même. Il a suffi d'un héros toujours centré pour masquer le piège pendant des mois, et d'un seul ennemi qui sort de l'écran pour le faire apparaître. La version courante du jeu est téléchargeable ici en disquette .st . Monte-la comme disquette A dans Hatari, en mode STe pour le scroll matériel 50 Hz, ou en mode STf pour le scroll logiciel : c'est le même fichier, il détecte la machine au boot. Pour la version courante du jeu, voir aussi la page d'accueil . --- ## Un HUD qui ne bouge pas d'un pixel - **URL**: https://loreoftheember.com/blog/014-hud-bandeau-preshift-ste/ - **Date**: 7 juin 2026 - **Summary**: Le scroll matériel qui fait si bien scroller le décor sur STe a un effet de bord gênant : il décale l'écran entier, le HUD en haut compris. Mon HUD tout neuf voulait donc filer à gauche et à droite avec le décor. Récit de la technique qui le cloue en place, et du hoquet d'une seule image qui a failli tout gâcher. - **Tags**: technique, ste, scroll Le décor file, et le HUD avec lui Sur STe, le défilement se fait avec un seul réglage matériel : il décale l'image affichée de zéro à quinze pixels vers la gauche, le temps que la caméra franchisse une case. C'est ce petit décalage qui rend le scroll fluide, en complément du grand saut d'une case à l'autre. Le piège, c'est que ce réglage agit sur l'écran entier. Il ne sait pas faire la différence entre la zone de jeu et le HUD posé tout en haut, celui qui montre les cœurs de vie, le score, la jauge de lanterne et les vies restantes. Tant que ce bandeau était une simple bande noire, personne ne voyait qu'il glissait lui aussi. Le jour où j'y ai remis le vrai contenu, le HUD s'est mis à coulisser de quelques pixels à droite et à gauche au rythme du scroll. Un HUD qui bouge avec le décor, c'est exactement ce qu'on ne veut pas. Seize copies, une par décalage L'idée du correctif est de retourner le problème. Puisque le matériel va décaler tout l'écran de N pixels vers la gauche, je prépare le contenu du HUD déjà décalé de N pixels vers la droite. Les deux décalages s'annulent, et le bandeau retombe pile à sa place. Le souci, c'est que N change à chaque image, et prend toutes les valeurs de zéro à quinze, parce que la caméra avance au pixel près. Je prépare donc seize versions du bandeau, chacune décalée d'un cran de plus que la précédente. À chaque image, je regarde de combien le matériel va pousser l'écran, et je choisis la version qui compense exactement. Le bandeau paraît figé pendant que le décor file dessous. Ce qui rend l'astuce viable, c'est son coût quasi nul. Une fois les seize versions préparées, choisir la bonne à chaque image ne demande presque rien : aucun calcul, aucune recopie. Et la mémoire de ces seize copies, je la prends dans une zone déjà réservée au scroll, donc le jeu ne grossit pas et continue de tenir dans son mégaoctet, sur STe comme sur STf. Mettre à jour sans tout refaire Quand on prend un coup ou qu'on vide la lanterne, le HUD change. Refaire les seize copies en entier à ce moment-là provoquerait un clignotement très visible, le bandeau se reconstruisant version par version sur plusieurs images. La leçon, je l'avais déjà apprise en chassant un vilain défaut similaire plus tôt dans le projet. Alors je ne touche qu'à l'élément qui change. Un cœur qui se vide, un cran de jauge qui s'éteint : je redessine ce petit morceau, et lui seul, dans les seize copies d'un coup, en une seule image. Le score et les vies ne bronchent pas, et le changement passe sans le moindre scintillement. Le hoquet d'une seule image Première version en main, le bandeau affichait bien son contenu, les cœurs réagissaient proprement aux dégâts, rien ne débordait. Mais en me déplaçant, le HUD avait des hoquets, des clignotements. De temps en temps, un petit sursaut, comme s'il sautait d'un pixel avant de se rattraper. La cause tient à un détail de timing que j'avais bien pris en compte ailleurs sans y penser ici. Pour éviter un autre défaut, j'applique le nouveau scroll au moment très précis où la nouvelle image apparaît à l'écran, pas avant. Or je changeais la copie du HUD un poil plus tôt, sans attendre ce même instant. Pendant une image, le bandeau montrait déjà sa position suivante alors que le décor, lui, affichait encore la précédente. Le décalage entre les deux durait juste une image, mais il revenait par intermittence, d'où ces hoquets. Le correctif consiste à faire patienter le changement de copie jusqu'à l'instant exact où le scroll bascule. Désormais, le bandeau et le décor changent ensemble, à la même image, jamais l'un sans l'autre. Le HUD est redevenu parfaitement immobile. Le bilan Le HUD tient maintenant en haut de l'écran, cœurs, score, jauge de lanterne et vies, parfaitement fixe pendant que le décor scrolle à pleine vitesse dessous. Les dégâts et les recharges se voient sans clignotement, et il n'y a pas une ligne parasite sous le bandeau. Le tout sans rien coûter au framerate, et toujours dans un seul mégaoctet. La morale tient en une règle que je me note pour la suite : avec ce genre de scroll appliqué au dernier moment, tout ce qui est lié à l'image, le décalage du décor comme le choix de la copie du HUD, doit basculer au même instant précis. La version courante du jeu est téléchargeable ici en disquette .st . Monte-la comme disquette A dans Hatari, en mode STe pour le scroll matériel, ou en mode STf pour le scroll logiciel : c'est le même fichier, il détecte la machine au boot. Pour la version courante du jeu, voir aussi la page d'accueil . --- ## Soigner l'interface avant de montrer le jeu - **URL**: https://loreoftheember.com/blog/015-une-interface-claire-pour-deux-joueurs/ - **Date**: 30 juin 2026 - **Summary**: Avant de montrer Lore of the Ember et de réunir les premiers curieux autour du jeu, je voulais que la toute première chose qu'on voit, le HUD, soit nette et lisible. - **Tags**: game-design, interface, co-op Pourquoi maintenant Je m'apprête à montrer Lore of the Ember pour de bon, et à réunir autour de lui les premières personnes qui voudront le suivre, me donner des idées, m'aider à le mener jusqu'au bout. Or la toute première chose qu'on perçoit d'un jeu, avant même de comprendre ce qu'on y fait, c'est son interface. Un bandeau brouillon, et le jeu entier a l'air d'un brouillon. Je voulais donc poser une interface simple, mais soignée. Rien de tape-à-l'oeil, juste quelque chose de propre et de lisible, à la hauteur de ce que je veux que Lore of the Ember devienne. Ce que le HUD doit dire en une seconde En haut de l'écran, une fine bande sombre cerclée d'or. Elle ne montre que l'essentiel, mais elle doit le dire d'un seul coup d'oeil, en plein combat, sans qu'on ait à quitter l'action des yeux. Trois choses, pas une de plus : Les coeurs : la vie d'Alaric. Trois coeurs qui se vident quart par quart quand on encaisse un coup. On voit fondre sa santé sans avoir à y penser. La jauge de lanterne : la réserve de lumière. C'est à la fois l'arme et le bouclier du jeu, donc savoir combien il en reste, à tout instant, change la façon de jouer. Je l'ai dessinée comme une rangée de petites cellules qui s'éteignent une à une. Le score et le nombre de vies : posés sur le côté, bien lisibles, sans voler la vedette au reste. Simple, mais pro Le piège, quand on veut "faire joli", c'est d'en mettre trop. J'ai fait l'inverse : fond sobre, un cadre fin, des chiffres bien blancs, des coeurs chauds, et c'est tout. Un designer devra passer par là, mais pas tout de suite ;) La règle que je me suis fixée : ça doit rester net même en tout petit, et même dans une vidéo un peu compressée comme celles qui tourneront sur les réseaux. Si l'interface tient le coup à cette taille-là, elle tiendra partout. Le contraste fait le travail : du noir, de l'or, du blanc, une touche d'orange pour la vie et la lumière. De la place pour un deuxième joueur Lore of the Ember se joue à deux, en écran partagé, et l'interface le dit d'emblée. Le bandeau est coupé en son milieu : la moitié gauche, c'est vous ; la moitié droite attend un ami. Tant que personne ne l'a rejoint, ce côté droit affiche simplement "Press Fire". À la seconde où quelqu'un attrape une deuxième manette et appuie, il entre dans la partie en cours, et sa moitié de tableau de bord s'allume : sa vie, son score, ses vies à lui. Pas de menu, pas d'écran d'attente, on se pose à côté et on joue. La suite L'interface est posée, propre, prête à être filmée et montrée. Maintenant, je veux la voir entre les mains d'autres gens : est-ce qu'on lit sa vie d'un coup d'oeil, est-ce que la jauge de lanterne crée bien cette petite peur de la panne, est-ce que l'arrivée d'un deuxième joueur donne envie ? Ce sont les retours que j'attends pour la suite. Pour découvrir où en est le jeu, voir la page d'accueil . --- ## Deux machines, deux façons de scroller - **URL**: https://loreoftheember.com/blog/016-deux-facons-de-scroller-le-monde/ - **Date**: 3 juillet 2026 - **Summary**: Lore of the Ember tourne sur Atari, du STf au STe. Le décor doit y défiler avec la même fluidité partout, et pour y arriver il m'a fallu deux façons très différentes de faire scroller le jeu : le scroll matériel du STe d'un côté, tout redessiner à la main sur STf de l'autre. Voici pourquoi, et ce que ça change pour vous. - **Tags**: game-design, atari, technique Le scrolling, parlons-en Dans Lore of the Ember, la caméra suit Alaric partout, le monde scrolle autour de lui, et si ce scrolling accroche, sautille ou tremble, tout le jeu prend un air bancal, même quand tout le reste est soigné. C'est pour ça que j'ai passé beaucoup de temps sur ce détail. Un mouvement fluide, c'est ce qui permet de se plonger pleinement dans le jeu, on ne voit plus que le personnage et le monde qui l'entoure. C'est exactement l'effet que je cherche. Deux familles de machines Lore of the Ember est fait pour les Atari, et Atari a sorti plusieurs modèles au fil des années. Pour ce qui nous intéresse ici, il y en a deux grandes familles : le STf et le STe, sa version un peu plus musclée. La différence tient à deux petites choses que le STe possède et que le STf n'a pas. La première, c'est le scroll matériel : le STe sait décaler l'image affichée tout seul, en douceur, sans que le jeu ait à redessiner quoi que ce soit. La seconde, c'est le blitter, une puce dédiée qui recopie des morceaux d'image à toute vitesse, bien plus vite que le processeur ne le ferait. Sur STf, ni l'un ni l'autre : c'est le processeur, et donc mon programme, qui doit tout faire. Je tenais à ce que Lore of the Ember tourne bien sur les deux. Pas question de réserver le jeu aux STe et de laisser tomber tous ceux qui sont restés sur un STf. Sur STe, je m'appuie sur la machine Sur STe, je laisse le matériel travailler pour moi. Le scroll matériel fait défiler le décor de manière fluide, la caméra colle au héros, et le monde se déroule sans le moindre accroc. Pendant ce temps, le blitter dessine les personnages et les éléments animés. Le petit progrès dont je suis le plus content est récent : au lieu de lancer le blitter puis d'attendre qu'il ait fini, je le laisse désormais dessiner pendant que le processeur prépare déjà la suite. Les deux avancent en même temps. Ce temps grappillé, je l'utilise : plus d'ennemis à l'écran en même temps, de la marge pour le deuxième joueur, sans que le mouvement ne perde une miette de sa fluidité. C'est le rendu que je montre en premier, parce que c'est là que Lore of the Ember est le plus proche de ce que j'ai en tête : une balade fluide dans un monde qui se corrompt, où rien ne casse l'immersion. Votre navigateur ne peut pas lire la vidéo. Télécharger la capture (MP4) . Le scrolling sur STe : le décor défile au pixel près. Sur STf, je fais tout à la main Sur STf, je n'ai aucun de ces deux filets. Pas de scroll matériel : chaque petit pas du décor, c'est une image entière que mon programme doit redessiner, décalée, à la main. Pas de blitter non plus : le processeur porte seul le poids de tout ce qui bouge à l'écran. Le piège classique, c'est de finir avec un scrolling haché, qui avance par à-coups. Le vrai défi a été là : obtenir sur STf un scrolling régulier, agréable, qui ne donne jamais l'impression d'un jeu bridé ou d'une version au rabais. J'ai retourné le problème dans tous les sens pour que le mouvement reste constant, sans saccade, du début à la fin d'un déplacement. Aujourd'hui, ça roule, et j'en suis fier : c'est ce qui fait toute la différence la manette en main. Votre navigateur ne peut pas lire la vidéo. Télécharger la capture (MP4) . Le scrolling sur STf : tout est recalculé, et ça reste régulier. La suite Le mouvement est en place et fluide des deux côtés. La prochaine étape, c'est de le mettre entre les mains d'autres joueurs et de voir si ce scroll produit le bon effet : celui de s'immerger pleinement dans le jeu. Pour découvrir où en est le jeu, voir la page d'accueil . --- ## Une chevauchée à deux - **URL**: https://loreoftheember.com/blog/017-une-chevauchee-a-deux/ - **Date**: 4 juillet 2026 - **Summary**: Lore of the Ember ne se joue pas qu'à pied. J'ai ajouté dans le moteur la gestion du parallax à deux joueurs, avec des ennemis qui viennent de toutes les directions. - **Tags**: game-design, atari Sortir du village Alaric passe de niveau en niveau en marchant. Pour que le jeu soit mémorable, il faut intégrer différents gameplay, et une chevauchée type Shock Troopers (le niveau sur la moto) me paraissait intéressant à faire. Le résultat est un niveau vu de côté : on est en selle, on avance, on tire, et le paysage défile. Le ton change complètement du reste du jeu. Là où la traversée du village est lente et tendue, ici tout va vite, ça tire de partout, et on n'a pas le temps de réfléchir. Ce contraste est exactement ce que je cherchais. Deux plans, deux vitesses Pour qu'une course donne une sensation de vitesse, il ne suffit pas de faire slider une image. Il faut que les différents niveaux du décor n'aillent pas à la même allure. Le fameux parallax. J'ai donc découpé l'écran en deux zones. En haut, le ciel et un décor montagneux, qui dérivent lentement. En bas, le sol, qui file. Entre les deux, la silhouette découpée des dunes, dessinée et non calculée, pour ne pas voir une ligne droite entre les deux plans parallax. Le ciel avance d'un pixel par image, ce qui est le pas le plus fin possible, et donc le plus doux. Sur une machine de 1989, calculer ce décalage au moment de l'afficher coûte bien trop cher pour tenir la cadence. J'ai donc préparé seize versions du ciel, chacune décalée d'un pixel de plus que la précédente, et je me contente d'afficher la bonne. Le travail est fait une fois, au chargement, au lieu d'être refait cinquante fois par seconde. Ce genre d'arbitrage revient sans arrêt sur cette machine : payer une fois en mémoire pour libérer du temps processeur. À deux en selle Le passage se joue à deux. Deux cavaliers, deux lignes de tir, et le même parcours. C'est le premier endroit où j'ai vraiment senti que le jeu gagnait à être partagé : à un joueur c'est une course, à deux c'est une collaboration, on se répartit les cibles sans se parler. La chevauchée en pleine action : les deux cavaliers, le galop, les dunes qui filent, et les tirs qui traversent les deux plans du parallax. La même chose sur STf et sur STe Le piège d'un parallax, c'est qu'il tienne sur STe et s'écroule sur STf. Je me suis imposé la règle inverse : un seul programme, et la même fluidité des deux côtés. Le STe s'appuie sur sa puce graphique, le STf recalcule tout, et le joueur ne doit pas voir de différence. C'est la partie qui a pris le plus de temps, et de loin. La suite La chevauchée existe et se joue. Elle deviendra un niveau à part entière, avec ses ennemis propres et sa place dans le récit. Pour l'instant elle m'a surtout servi à prouver une chose : le jeu peut changer de rythme sans changer de moteur. Les décors sont les décors de Shock Troopers, que je referai avec mon designer. Pour découvrir où en est le jeu, voir la page d'accueil . --- ## Le second joueur entre en jeu - **URL**: https://loreoftheember.com/blog/018-le-second-joueur-entre-en-jeu/ - **Date**: 12 juillet 2026 - **Summary**: Lore of the Ember se joue désormais à deux. Le second joueur n'est pas qu'un figurant : c'est l'Ardent, un champion de braise que la lanterne appelle, avec sa propre arme, ses propres vies et son propre score. Il peut rejoindre la partie à n'importe quel moment pour aider Alaric. - **Tags**: game-design, atari Un second héros, pas un second curseur Le co-op à deux joueurs est en place. C'était prévu depuis longtemps, mais là c'est fait. Le joueur 2 incarne l'Ardent. Alaric garde la lanterne : c'est elle qui appelle ce champion de braise. L'arrivée et le départ du deuxième joueur ne se font pas dans le menu mais directement ingame. Il a son arme à lui, un bâton qui envoie une salve de trois boules, une grosse puis une moyenne puis une petite. Ça se joue autrement que la lanterne d'Alaric, et c'est volontaire : à deux, on ne veut pas deux fois la même chose à l'écran. Pour le moment ce sont des sprites de Chaos Engine, qui seront remplacés une fois le designer trouvé ;) Les deux héros à l'écran : Alaric avec sa lanterne, et l'Ardent qui envoie sa salve de trois boules. Rejoindre en cours de route Donc en résumé, le second joueur appuie sur le bouton de tir, et il est là. Pas d'écran de sélection, pas de retour au menu, pas de partie à relancer. Quelqu'un entre dans la pièce, prend la manette, et joue. Pour que ça marche, l'invitation doit être visible sans être envahissante. Le bandeau du haut, dont j'ai parlé dans un article précédent , avait justement été dessiné en prévision de ce moment. Il affiche « PRESS FIRE » à la place qu'occuperont les cœurs du joueur 2. Ce que ça coûte de rejoindre Un détail invisible qui m'a demandé pas mal de travail : à l'origine, appuyer sur le bouton pour rejoindre provoquait un à-coup. Il fallait redessiner toute la moitié droite du bandeau d'un seul coup, en pleine partie, et ça se voyait, j'avais des ralentissements. La solution que j'ai mise en place consiste à préparer cette moitié du bandeau au démarrage du jeu, pendant que l'écran est encore noir. Elle est bel et bien dessinée, mais peinte dans la couleur du fond, donc invisible en solo. Au moment où le second joueur rejoint, je ne redessine rien du tout : je change simplement les couleurs concernées. Le bandeau du joueur 2 apparaît d'un coup, sans que le jeu ne ralentisse d'une image. La palette n'est que seize couleurs, mais on peut la changer à volonté sans toucher un seul pixel, et ça ne coûte quasiment rien. Beaucoup d'effets du jeu reposent là-dessus. Et la caméra, dans tout ça Le vrai casse-tête du co-op sur un écran unique, c'est le cadrage. Deux joueurs qui partent chacun de leur côté, on doit choisir qui la caméra suit. La caméra suit donc celui qui avance, tout en gardant l'autre dans le cadre, et elle se déplace de façon progressive plutôt que de sauter quand la situation change. 📷 Capture à venir : le bandeau en co-op, les deux zones de vie et de score côte à côte, pendant que le décor défile. La suite Le co-op fonctionne sur les deux machines, STf comme STe. Reste à l'éprouver longuement à deux manettes, sur des sessions réelles, parce que c'est le genre de mécanique dont les défauts n'apparaissent qu'après une longue session de jeu. Pour découvrir où en est le jeu, voir la page d'accueil . --- ## Une intro en cinq plans - **URL**: https://loreoftheember.com/blog/019-une-intro-en-cinq-plans/ - **Date**: 28 juillet 2026 - **Summary**: Avant de jouer, le jeu doit raconter une histoire, mettre dans l'ambiance : cinq plans enchaînés, du réveil d'Alaric jusqu'à la silhouette du château sous l'orage. Une intro coûte cher sur une machine de 1 Mo, et presque tout ce qui bouge dedans ne coûte pourtant rien. - **Tags**: game-design, atari Poser le décor avant de rendre la main Lore of the Ember repose sur une situation qu'il faut comprendre en quelques secondes : un homme se réveille dans un village mort, les mains couvertes d'un sang qui n'est pas le sien, avec une lanterne à côté de lui. Si on démarre directement sur le gameplay, il ne reste qu'un personnage qui tire sur des ennemis. L'intro fait donc cinq plans, dans cet ordre : le village vu de haut, le réveil, la lanterne, la traversée de la rue, et le château sous l'orage. Chacun porte deux lignes de narration, en français ou en anglais selon la langue choisie au démarrage. Le premier plan de l'intro : le village mort, et le château qui veille au fond. La narration s'inscrit dans la bande du bas. Ce qui bouge sans rien coûter Trois de ces cinq plans sont des images fixes. Et pourtant il s'y passe quelque chose en permanence : la flamme de la lanterne respire, l'orage éclate sur le château, les paupières d'Alaric battent avant de s'ouvrir pour de bon. Presque rien de tout cela ne consomme de puissance, parce que rien n'est redessiné. Sur Atari, l'image affichée n'a que seize couleurs, et ces seize couleurs peuvent être changées à volonté, instantanément, sans toucher un seul pixel. La flamme qui vacille, c'est une couleur qu'on fait monter et descendre. L'éclair, lui, est déjà dessiné sur l'image dès le début : je le maintiens simplement à la couleur des nuages, donc invisible, et c'est son apparition brutale qui fait l'évènement. Le seul vrai mouvement, ce sont les paupières, un petit rectangle de rien du tout au milieu du visage. J'ai passé du temps sur leur rythme : à un dixième de seconde par battement, c'est en réalité une image qui clignote. À un cinquième de seconde, ça devient un réveil. Quatre écrans noirs à faire disparaître Le vrai problème de cette intro n'était pas graphique. Il y avait quatre coupures d'environ deux secondes, écran noir, en pleine narration. La cause était simple : les images de l'intro sont lues sur la disquette au moment où on en a besoin, et une disquette double densité lit lentement. Dix secondes de lecture au total, réparties entre les plans, ce n'est pas génial. J'ai d'abord essayé de faire ces lectures à certains moments de l'intro, pendant que les yeux d'Alaric sont fermés, puis pendant le plan du village. Les deux fois, la lecture débordait du temps disponible, et l'intro était en pause durant toute la durée du chargement. Bref, mauvaise idée. La solution a été de tout lire d'un bloc avant le premier plan. La cutscene se déroule ensuite sans le moindre accès au disque, exactement à la cadence prévue. Le prix à payer, c'est une attente au démarrage, mais une attente franche et annoncée vaut mieux que quatre longues pauses au milieu d'une scène. Cette attente est d'ailleurs habillée maintenant : un écran dessiné, dans la langue du joueur, remplace le minuscule témoin de chargement qu'il y avait avant. Il sert aussi au chargement des niveaux. L'écran d'attente, affiché pendant les chargements. Alaric prend son mal en patience. La suite L'intro tourne du début à la fin, dans le jeu et pas dans un programme à part. Le quatrième plan, celui où Alaric traverse la rue à pied, a demandé un travail à lui tout seul : sa démarche ne vient pas d'une courbe inventée, mais d'une marche filmée puis relevée image par image. Ce sera pour une autre fois. Pour découvrir où en est le jeu, voir la page d'accueil . --- ## Le décor arrive du disque - **URL**: https://loreoftheember.com/blog/021-le-decor-arrive-du-disque/ - **Date**: 3 août 2026 - **Summary**: Sur un Atari de 1 Mo, tout ce qui est dans le programme y reste pour toujours et de la mémoire j'en ai besoin ! Les décors des niveaux ont donc quitté la mémoire pour se loger dans la disquette, d'où ils sont lus au moment d'entrer dans une zone. Au passage, le jeu s'installe maintenant sur un disque dur. - **Tags**: game-design, atari Un mégaoctet, et pas un de plus L'Atari 1040 STf/STe a 1 Mo de mémoire. Le système en prend une part, et il reste au jeu un peu moins de 900 Ko pour absolument tout : le programme, les décors, les personnages, les sons. Il y a une règle qu'il faut bien connaitre quand on développe sur Atari : le programme est chargé d'un seul bloc, et rien n'en ressort jamais. Il n'y a pas de mémoire virtuelle, pas de pagination, pas de système qui décharge en douce ce qui ne sert plus. Tout ce que je compile dans le jeu occupe de la place du démarrage jusqu'à l'arrêt de la machine. Or les décors sont ce qu'il y a de plus lourd, et ce sont précisément des données généralement uniques par niveau. Le décor de l'acte II n'a aucune raison d'occuper de la mémoire pendant qu'on joue l'acte I par exemple. Sortir les décors du programme Les décors ont donc quitté la RAM pour rester sur la disquette. Ils sont lus quand on entre dans une zone, dans des tampons partagés : le décor qu'on quitte laisse la place à celui qu'on découvre, et le contenu cesse de coûter de la mémoire en permanence ... pour rien. Le résultat est net. La marge disponible sur une machine de 1 Mo a doublé, et le programme lui-même a perdu pas mal de kilos. Concrètement, ça veut dire des niveaux plus grands et plus détaillés, sans devoir choisir entre la taille d'une carte et le nombre d'ennemis qui y vivent. Deux précautions ont guidé le travail. D'abord, changer de pièce ne relit le disque que si le décor demandé est vraiment différent : passer une porte et revenir sur ses pas ne déclenche pas de lecture. Ensuite, l'outil que j'ai réalisé, celui qui build la disquette, annonce ce qui ne rentre pas au lieu de tronquer sans rien me dire, le bougre, parce que sinon, on a droit à des bombes. Le niveau en cours de partie. Tout ce décor est lu depuis le disque à l'entrée dans la zone, et ne pèse plus en permanence sur la mémoire. Faire du ménage ;) Le second chantier a consisté à traquer ce qui était chargé sans plus servir à rien. Un lecteur de musique qui attendait un format que je n'utilise plus. Une planche de sprites d'un adversaire qui ne peut pas apparaître dans l'état actuel du jeu. Rien de spectaculaire, mais 53 Ko qui partaient à chaque partie. Ce genre de ménage n'a rien d'excitant à raconter et c'est pourtant ce qui décide si une idée sera possible ou non trois mois plus tard. Sur cette machine, on ne gagne pas de la place en optimisant : on en gagne en jetant. Et sur disque dur Dernier point, très concret pour ceux qui jouent sur du matériel réel équipé : le jeu s'installe maintenant sur un disque dur, dans un seul dossier, sans rien éparpiller sur la partition. Le chargeur cherche les décors à côté du programme avant d'aller les chercher ailleurs. La version disquette, elle, ne voit pas la différence. Le jeu entier tient dans ce dossier. C'est un cap que je n'aurais pas cru franchir aussi tôt. Merci à la commu pour ce conseil ! La suite Avec cette marge retrouvée, la priorité redevient le contenu : finir le premier niveau de bout en bout, avec ses ennemis, ses foyers de peste et sa progression, et le mettre entre les mains d'autres joueurs. Pour découvrir où en est le jeu, voir la page d'accueil . ---