# Lore of the Ember - full content dump for LLMs > Lore of the Ember is an indie action game built for three machines of the golden age: the Atari ST, the Sega Megadrive (Genesis) and the Commodore Amiga. 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 Atari ST is the original and reference version; the Megadrive and Amiga versions carry the same game with whatever their machine does better. The website is a bilingual devlog (French and English) documenting the design and the journey. This file concatenates the full text of every devlog article for convenient ingestion by language models. The English articles come first, then the French originals; each article appears once per language. For a short index, see https://loreoftheember.com/llms.txt. For the human-readable site, see https://loreoftheember.com/ (French) or https://loreoftheember.com/en/ (English). --- ## Project facts - Working title: Lore of the Ember - Machines: Atari ST (STe, STf, Mega STe), Sega Megadrive / Genesis, Commodore Amiga (stock A500) - Reference version: the Atari ST, where the game started; the other two follow it and add what their hardware allows - 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 languages: French (canonical) and English ## 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). --- # Devlog articles in English ## Before the first pixel: the engine I've been dragging around for years - **URL**: https://loreoftheember.com/en/blog/000-the-engine-i-have-been-dragging-around/ - **Date**: 25 January 2026 - **Language**: English - **Summary**: Lore of the Ember isn't a project that started from zero. It's the culmination of an old STe engine I have restarted more times than I can count, and of a platformer prototype I never finished. Here is why I'm picking it up again, and this time for good. - **Tags**: engine A project that didn't start yesterday Lore of the Ember, or rather the engine that runs it, is something I've been dragging around for years. Not continuously, not every evening, but it's the kind of project that always comes back. You put it in a drawer, you move on to something else, and six months later you open the folder again "just to have a look", and off you go for a few sleepless nights. The old skeleton Before Lore of the Ember there was a platformer prototype, heavily inspired by the Castlevania games of the era, which I never finished. The kind of game you love and think you can rebuild in a weekend, until you find out what it really costs on a machine from 1989. Just scrolling scenery cleanly is hard ;) . That prototype never saw the light of day, but it wasn't lost either. What it left me was a skeleton: enough to boot the machine, put an image on screen, and scrolling experiments I rewrote ten times. And above all, entire notebooks of notes, pages on everything that lets a machine from that era still surprise the eye today. Most of those notes eventually turned into code that runs. Your browser cannot play this video. Download the video (MP4) . The engine in its early days: a plain red rectangle moving on a black background, the skeleton everything else was built on. Why it never got finished The truth is that I had never really decided to finish. I kept starting over. Every time I came back, I decided the old code was badly done, I restarted from something cleaner, and I stopped just before the hard part: filling a real level, writing a real story, making people want to keep playing. Technique is comfortable. You can polish a scroll for months without ever having to ask yourself whether the game is any good. And then life takes over. Work, everything else. A solo project with no deadline and nobody waiting for it is the first one you sacrifice. What is different this time This time I have stopped rewriting the engine. I'm taking it as it is, scars and all, and building on top. All those years of tinkering finally become foundations instead of an eternal starting point. The rule I have set myself is simple: no more rewriting the base for the fun of it, use it to make a game and finish it. The game will be Lore of the Ember. One game, chosen, finished. The platformer prototype was a springboard, but the direction changed along the way, and that is for the better. I will come back to that in a dedicated article, because that turn is a real story in itself. What you're going to read here So this devlog isn't a tutorial on "how to make an STe game from nothing". It's the journal of the final stretch, resting on foundations that took a long time to exist. I'm going to document the steps, the design decisions, the pivots and the mistakes. When I break a rule I set myself, I will say so. When a bug costs me three evenings, I will tell you about it. The first entry in the journal starts where I pulled the skeleton out of the drawer and got it standing straight again. For once, I fully intend to see this through. --- ## Pulling the engine back out of the drawer: a character moving at 50 frames per second - **URL**: https://loreoftheember.com/en/blog/001-the-project-starts/ - **Date**: 8 February 2026 - **Language**: English - **Summary**: First public milestone of the revival: I get the old engine skeleton standing straight again and finally have a character moving perfectly smoothly on the Atari STe. - **Tags**: engine If you're arriving here, read why I'm pulling this old engine back out first. This journal isn't a project started from zero: it's the final stretch of an STe/STf engine I've been dragging around for years. The challenge Pick up my old engine skeleton and get it standing straight again, so I can finally run a real game on the Atari 1040 STe and STf. The goal hasn't changed since day one: push the machine as far as it will go. Before thinking about enemies, levels or story, I need a solid base. Something that moves, and moves well. What I got running again I'm starting from the base I had already written and rewritten over the years: take full control of the machine and lay the foundations back down. The first building block is avoiding screen tearing. When you draw straight onto the screen the player is looking at, they sometimes see half of one frame and half of the next, which gives an ugly horizontal split. The classic answer is to work on a hidden image while the other one is displayed, then swap the two at exactly the right moment, right between two sweeps of the screen. The player never sees the drawing in progress, only finished images. The second building block is rhythm. I lock the whole game to the screen sweep, fifty times a second, so that every image is computed and displayed in perfect cadence. No stutter, no jerk. A character that moves pixel by pixel The hero is still just a red rectangle, a simple placeholder. But it moves pixel by pixel in all four directions, with a real sense of glide. The tricky part was making it advance finely without leaving a smear when it straddles two areas of the screen: it needed a clean drawing at every intermediate position. Gravity and jumping work too, with a capped falling speed so that landings stay readable and controllable rather than turning into uncontrolled dives. Nothing spectacular yet, but it already feels like a game, and that is exactly what I wanted to feel before going any further. Next step Scenery and horizontal scrolling. The STe can shift its display finely, almost for free, and that is the capability I want to exploit to get perfectly smooth scrolling. Combined with reloading the scenery at the edge of the screen, it's the centrepiece that will turn this prototype into a real platform game. Result The red character moves smoothly on a black background with a grey floor, at fifty frames per second. It's a graphical placeholder, but the engine is in place and the movement already feels good. The rest can begin. Download morteveille-001-moteur.prg (1.5 KB) - Historical archive of this step. Run it in Hatari in STe mode, 1 MB of RAM. Arrows to move, up to jump. For the current version of the game, see the homepage . --- ## The level takes shape: a world bigger than the screen - **URL**: https://loreoftheember.com/en/blog/002-tilemap-and-scrolling/ - **Date**: 22 February 2026 - **Language**: English - **Summary**: How I built scenery out of reusable tiles, then made the world scroll so it follows the player. The moment the game stops being a single fixed screen and becomes a real level to explore. - **Tags**: tilemap, scroll The problem At the start, my game fitted on a single screen. The character could run, but he bumped into the edges very quickly, and there was nowhere to go. I wanted a real level, wide, with ground, walls, hanging platforms, something you want to travel through. The trouble is that a large level drawn as one enormous image would cost far more than all the memory in the machine. Impossible. The scenery had to be built another way. The answer: scenery made of reusable bricks The trick is tiles. Rather than storing a giant image, I cut the scenery into small reusable blocks: a piece of ground, a chunk of wall, a platform. The level then becomes a grid that simply says "ground here, wall there, empty space here". It's light, and it lets me compose scenery far bigger than the screen without saturating memory. For this first pass I made do with a few test tiles: empty space you can walk through, ground you walk on, a wall that blocks you, a platform. Enough to test the feel before worrying about the artwork. The world scrolls with the player The real change is that the character no longer lives in a screen, but in a world. He holds a position in that wide space, and it's the camera's job to show the right part of it at the right moment. I locked the scrolling to the player: as long as he stays in the centre we follow along, and when he approaches an edge the scenery slides to keep him in view. With a limit at the ends of the level, so as not to reveal the void beyond. This scrolling is still entirely redrawn on every frame, which isn't the most economical method, but at this stage I wanted to validate the feel before optimising. The result The character finally wanders through a level bigger than the screen, with ground below, platforms in the air and a wall. The scenery scrolls when you approach the edges. This is the moment the project stopped being a static demo and started to look like the beginning of a game. Download morteveille-002-tilemap.prg (2.1 KB) - Historical archive of this step. Arrows to move, up to jump, fire to quit. For the current version of the game, see the homepage . Next step Collisions with the scenery. For now the player walks through walls and platforms like a ghost. He needs to feel the ground under his feet and to bump into obstacles. After that comes the STe hardware scroll, to make the scenery slide without having to redraw everything on every frame. But that is another story. --- ## Scrolling the STe without breaking a sweat - **URL**: https://loreoftheember.com/en/blog/003-hardware-scroll-ste/ - **Date**: 15 March 2026 - **Language**: English - **Summary**: I wanted scenery that slides pixel by pixel, without stutter or flicker. Rather than redrawing everything frame by frame, I let the STe do the work itself. - **Tags**: scroll What I wanted on screen Scenery that slides, soft and continuous, pixel by pixel. Not a stepped scroll that hops along, not an image that tears when the hero moves forward. The kind of smoothness you feel more than you notice, and that makes you say straight away that the game is good. The trouble is that a 1989 Atari cannot afford to redraw the whole screen fifty times a second (and I hadn't even started on the STf yet). It's too much work for the processor, especially if it also has to animate the hero, the enemies and the game logic. If I had redrawn the scenery on every frame, there would have been nothing left for the rest. The wrong track My first instinct was to tell myself I should redraw cleverly, copying only what changes. But even optimised, copying the scenery continuously is still too heavy for the machine, and it showed: the scrolling dragged, and the rest of the game slowed down with it. I was trying to do quickly something that, in reality, shouldn't have been done at all. The answer: let the STe do the work The STe has an advantage its big brother the STf didn't have: it can move its own display, pixel by pixel, without asking anything of the processor. Rather than scrolling the scenery by redrawing it, I prepare a strip of scenery wider than the screen and simply ask the machine to look a little further right on each frame. The scenery slides, and the processor has done nothing. This is what is called hardware scroll. There was still a quirk of the machine itself to sort out, which required the sprites to be erased and redrawn at the right moment so they wouldn't flicker or leave trails. Once that synchronisation was dialled in, the image became perfectly crisp in motion. The result Pixel-by-pixel scrolling on STe, smooth, flicker-free, and costing the machine almost nothing. All the time I'm not spending moving the scenery, I can now spend on the hero, the enemies and the game. This is the foundation everything else rests on: without clean scrolling, nothing else would look alive. Download morteveille-003-hwscroll.prg (2.2 KB) - Historical archive of this step. Arrows to move, up to jump, fire to quit. For the current version of the game, see the homepage . Next step Collisions with the scenery and bigger levels . The player will be able to walk on platforms, be blocked by walls, and explore spaces much longer than what the screen shows at once. --- ## Goodbye parallax, hello bitmap: the day I chose beauty - **URL**: https://loreoftheember.com/en/blog/004-goodbye-parallax-hello-bitmap/ - **Date**: 29 March 2026 - **Language**: English - **Summary**: I'm dropping my three-layer parallax for a level drawn entirely by hand. Less technical showmanship, far more character. A look back at a choice that changed everything for the game. - **Tags**: level-design, graphics The verdict After weeks of polishing my three-layer parallax, I had to face facts: the result wasn't up to what I had in mind. Yes, making a smooth Shadow of the Beast is, good grief, nowhere near that simple. Technically it worked. Three layers of scenery sliding at different speeds, just like in Shadow of the Beast. But on screen it was bland. On the STe the available colours are few, and they have to be shared between all the layers. The result: every layer was poor and drab, and the depth effect wasn't enough to make you forget how thin the scenery looked. I want to prove the Atari STe can be beautiful. A parallax that impresses on paper wasn't enough. Not yet. The realisation What makes a game beautiful on this machine isn't showmanship, it's art. Scenery drawn with care, where every pixel counts, will always have more impact than a stack of layers with cramped colours. I realised I had been fighting for the wrong thing: I was trying to multiply the layers when I didn't even have a single genuinely beautiful one. On this hardware, art beats technique. For now, at least. I'm not giving up on parallax! The new approach: scenery painted whole The principle is radically simple: instead of assembling the scenery from small repeated tiles and stacked layers, I draw the level as one big painting, end to end, and the machine simply scrolls that painting. A single layer, but a free one, where I can put whatever I want wherever I want. That gives me all the machine's colours for one piece of scenery, instead of scattering them. Every torch, every shadow, every detail can finally breathe. Flames that live on their own A small joy of this approach: I animate every torch in the scenery in one gesture, by cycling a few colours reserved for fire. The flames flicker continuously, across the whole width of the level, without the game having to compute anything extra. It's free, and it immediately brings the forest to life. What I gain, what I lose I gain total artistic freedom: every pixel can be different, nothing is constrained by tiles that have to be stitched together. I also gain simplicity, the engine breathes and the scenery looks superb. I lose the parallax: the scenery lives on a single layer, with no depth effect. I also lose flexibility, since a painted level costs more than scenery made of reusable tiles, and it has to be drawn end to end, with no infinite scrolling. For this first game it's the right trade. But it's only postponed. Parallax stays in a corner of my mind. I learned a lot building it, and the day I have scenery drawn specifically for each layer, rather than bodged together in a hurry, I will come back to it. The long-term goal: a proper multi-layer parallax worthy of the STe. It will come. What comes next Level 1, "The Cursed Forest", is in place: a long dark stretch of scenery, animated torches, and my hero walking and jumping through it. Next step: enemies and combat. The following levels will be longer and more varied. Play it now Here is the game at this step. Level 1, "The Cursed Forest", is playable: smoothly scrolling scenery, animated torches, jumping. Download morteveille-004-bitmap.prg (183 KB) - Historical archive of this step. Run it in Hatari in STe mode, 1 MB of RAM. Arrows to move, up to jump, fire to quit. For the current version of the game, see the homepage . Move from left to right to travel through the level, and watch the torches live. Sometimes the simplest solution is also the most beautiful. --- ## Sprites that finally flow: prepare rather than compute - **URL**: https://loreoftheember.com/en/blog/005-preshifted-sprites-performance/ - **Date**: 5 April 2026 - **Language**: English - **Summary**: My hero flickered and left trails as soon as he moved. Here is how I got out of it, by borrowing an old trick from professional games: prepare everything ahead of time rather than recomputing it live. - **Tags**: sprites The problem My hero refused to move cleanly. As soon as he shifted, he flickered and left trails behind him, and the projectiles jumped. On screen it looked like a thoroughly buggy game. The cause lies in the way the Atari displays its image. To shift a character by a few pixels, the machine has to rework its data on every frame, fifty times a second. For a sprite that size that is a considerable amount of work, repeated in a loop, and the 68000 simply doesn't have time to do it for the hero, the projectiles, the scrolling scenery and the game logic all at once. Something had to give, and it was the hero's display. The dead ends I first tried to hand the job to the Blitter, the STe's graphics acceleration chip. On paper that is exactly its role. In practice, tuning it correctly for my case proved discouragingly fragile: stray bands, trails, defects that were almost impossible to isolate. I then tried alternating between two images on screen. That fixed one defect and created another, ghost sprites reappearing a fraction of a second later. Neither path was the right one. The solution came, as it often does on this machine, from a simpler idea. The answer: prepare everything ahead of time The trick is to compute almost nothing live. Rather than reworking the hero on every frame, I prepare once and for all, at game startup, every possible intermediate position of the character. Then, during play, the machine only has to pick the right one and display it. The bulk of the work is done before the player even presses a key. It costs a little memory, but on the STe memory is the resource you have and processing time is the one you lack. That is exactly the right trade. The whole thing is automated: I draw the hero in a plain image file, and a tool builds all the variants I need. If I touch up the drawing, I rerun the tool and the game updates. The result The flicker is gone. The hero moves cleanly, the projectiles follow, and there is still plenty of headroom to run the rest of the game at full speed. This is the foundation the walk animations, the enemies and the fighting will rest on. What comes next Now that the sprites hold up, on to what brings them to life: animations, enemies, and the first confrontations. --- ## Pivot: what if the map itself were the enemy? - **URL**: https://loreoftheember.com/en/blog/006-corruption-grid-pivot/ - **Date**: 11 April 2026 - **Language**: English - **Summary**: Lore of the Ember changes direction. The platformer becomes an arena game where the plague spreads across the ground and the player fights it tile by tile. Here is why I pivoted, and the feel this prototype confirmed. - **Tags**: game-design, pivot The confession A few days ago I played Lore of the Ember and had to admit something: yet another platform game on the Atari ST, however well made, stands very little chance of being memorable . The homebrew scene has produced plenty of them, and retro players know them by heart. Having a smooth engine at 50 frames per second isn't enough to leave a mark, because the engine is only the vehicle. It needed a strong central mechanic , something rarely seen on the machine and, above all, something people enjoy. The realisation A game in the vein of Chaos Engine. I loved the Bitmap Brothers games and that one is among them. But the STe constraint is simple: displaying lots of independent characters is expensive. Even with every trick in the book, beyond twenty or so animated sprites with their own logic, the machine collapses. If I wanted the "overwhelming horde" feel of a Chaos Engine, I had to be cunning. The answer: the main threat isn't made of sprites , but of the ground itself becoming corrupted. In Lore of the Ember, the Black Plague of 1347 is no longer narrative set dressing. It's the gameplay. It spreads across the flagstones of the cemetery, the rampart, the dungeon, tile after tile, tick after tick. The player, Alaric, fights it with the flame of his lantern, which burns the contaminated tiles and protects them for a while. The reference came immediately: Firemen (Human Entertainment, SNES, 1994), that forgotten game where fire spreads across the map while the player tries to put it out. Dynamic terrain, constant pressure, instant readability. Exactly what a homebrew that wants to be remembered needs. The game idea A fixed arena, a grid of tiles, no scrolling. Every tile has a state: healthy, infected, in the middle of turning, or recently cleaned. The plague starts from an outbreak and eats away at its neighbours. The player hoses it down, and the tiles hit go back to clean. I wanted the whole thing light and quick on its feet, so two design principles guided the prototype. First, the plague only spreads along its front: there is no point dealing with the heart of an area that is already fully infected, only the border can still bite. Second, on screen, I only redraw what changes, never the whole arena. At cruising speed that comes down to the handful of tiles on the front and the player. As a result the effort is proportional to the action on screen, not to the size of the terrain, and the machine stays calm. What gives the player leverage My very first prototype had no immunity. The player would clean an area, and a second later the plague came back as if nothing had happened. Frustrating, pointless: the feeling that "shooting achieves nothing" killed the game in thirty seconds. The fix changed everything: a cleaned tile stays healthy for a few seconds before becoming vulnerable again. During that reprieve it's displayed differently and refuses to be re-infected. Suddenly the player can carve out a genuinely safe corridor, catch their breath in it for two or three seconds, move forward, then draw it again further on. Shooting has weight, and that is where the game became interesting. The bugs I had to hunt down to get here No prototype comes out right on the first pass, and this one took a fair bit of debugging. Three memories are worth the detour. The first: a clean crash, black screen immediately, before anything was even displayed. The keyboard reading routine left the stack unbalanced, and the program returned into the void. A rookie mistake! The second, the most instructive: my arrow keys weren't responding. I spent an age suspecting key decoding, fiddling with the keyboard reading, adding visual indicators to work out what was happening. The cause was daft: the emulator was sending my arrows as joystick input, not as keys, and I was watching the wrong thing. Above all, the project already had an input handling block that had been proven for weeks. I should have started from there. The lesson is engraved now: when a piece already works in the project, I start from it before inventing something else. The result The prototype fits on a single screen, without a single complex sprite, without a line of story, just the bare mechanic. And the three questions that mattered at this stage all got a clear "yes" in testing: do you feel the tension, is clearing an area satisfying, do you want to play again? If the bare mechanic is already good, the story and the pixel art will carry the game much further. What comes next The sprite engine and the parallax validated earlier are not thrown away : they will come back as presentation layers. The lantern will animate above the protected tiles. Each act's bosses (the Ashen Wolf, the Lady in Black) will be the handful of complex sprites the machine's budget allows, placed on the grid breathing in the background. The gothic scenery of the story will become the arena dressing depending on the act. Next step: place a first boss on the corruption grid and start tying the gameplay to the lore. Act I, "The Forest of the Hanged", is the natural test ground, and the Ashen Wolf will be the first mobile sower of plague. The prototype is downloadable here (historical archive). Run it in Hatari, arrows to move, fire button to clean, to restart and to quit. You have about thirty seconds before the plague overruns everything if you stand still. For the current version of the game, see the homepage . --- ## A real world to explore: the camera finally follows the hero - **URL**: https://loreoftheember.com/en/blog/007-smooth-scroll-hybrid-c/ - **Date**: 22 April 2026 - **Language**: English - **Summary**: Until now my game fitted in a single fixed screen. Here is how I moved to a world bigger than the screen, with a camera glued to the hero, and why I agreed to make my life easier on the tooling side. - **Tags**: scroll The problem Until now my whole game fitted in a single screen. A fixed arena, the hero moving inside it, and when he reaches the edge, he stops. That is fine for a prototype, but it's not a world. And I wanted a real space to explore: rooms, corners, a boss that gives chase, the plague settling in out of sight. None of that fits in a box the size of the screen. So the goal of this step was easy to state: terrain bigger than the screen, and a camera that follows the player and keeps him centred, pixel by pixel, without stutter. And I still have The Chaos Engine in the back of my mind at all times, which is to say the bar for perfection is set fairly high. A decision I kept putting off Before getting there, I had to settle an old promise I had made to myself. Since the beginning of the project I kept saying that Lore of the Ember would be written entirely in assembly, with no shortcuts. It was a constraint I imposed to learn the machine inside out. Two years on, I know it. The trouble is that with every new feature (camera, bigger world, organising the code into reusable blocks), I was spending an age hand-unrolling mechanics that add nothing to the game. So I let go of my aesthetic rule to focus on what matters. I keep assembly for the sensitive parts, the ones that have to be lightning fast on screen, and I hand the rest, the orchestration and the game state, to more comfortable tools. What I want to say clearly: I have rewritten nothing that already worked. Sprite drawing, keyboard reading, the whole graphics core stays exactly as it was. What changes is only the glue around it, the code that decides what to do and when. And that code isn't in the critical path, it doesn't slow the game down. The answer: one world, a window wandering over it The idea fits in a single image. Instead of drawing exactly what you see, I prepare a world wider than the screen, and the screen only shows a window onto it. The STe can slide that window on its own, without the processor having to redraw the scenery on every frame. That is what is called hardware scroll, and it's precisely what makes scrolling so soft on this machine. The camera then becomes a small, quiet piece of arithmetic: I aim to keep the hero centred, and I clamp the window when it touches the edges of the world so it never shows empty space. The hero wanders, the window follows, the scenery scrolls pixel by pixel. While reorganising all this, I took the opportunity to sort the code into two families: a generic engine on one side, reusable for a future STe game, and everything that belongs specifically to Lore of the Ember on the other. A week of meticulous tidying, but now every new piece finds its place without hesitation. A plague that sleeps when your back is turned A bigger world raises a new question. If the player lets the plague settle in one corner, then wanders off to the other end, should that invisible plague keep being simulated? Constantly recomputing corruption nobody can see is wasted work. So I put the plague to "sleep" off-screen. As long as an area isn't on screen, its corruption freezes: its state is preserved, but it stops spreading. As soon as the player comes back, it picks up exactly where it left off. And the best part is that it fits the fiction perfectly. The plague has no awareness, it doesn't crawl towards the player. It spreads where it is, locally, without intent. That it pauses when you move away reinforces that idea. An optimisation that serves the story is rare and precious. How it turned out The hero wanders without flicker, the camera sticks to the player pixel for pixel, the Ashen Wolf boss gives chase across the whole terrain, and the plague waits patiently for the player to come within range before it starts nibbling again. For the first time it really feels like a place to explore rather than a demo in a box. What comes next The engine is ready to take content. The next job is building the real first room of Act I, the Edge of the Forest of the Hanged, drawn by hand rather than generated at random. That means a small scenery editor, a system of transitions between rooms, and the first narrative ambushes. The build for this step is downloadable here (94 KB, historical archive). Run it in Hatari in STe mode, arrows to move, fire to clean the plague, to restart, to quit. Wander around the world and you will see the scroll follow the player and the plague freeze as soon as you move away. For the current version of the game, see the homepage . --- ## The little hitch that came once a second - **URL**: https://loreoftheember.com/en/blog/008-hunting-the-once-a-second-hitch/ - **Date**: 2 May 2026 - **Language**: English - **Summary**: A micro-hitch in the scroll, exactly once a second. Three attempted fixes, an old trick to finally see the culprit, and a well-hidden trap. - **Tags**: technique, optimisation, corruption The symptom Testing the game with the boss active, one detail caught my eye. Once a second, the scroll hiccuped very slightly. Not a slowdown, not a flash, just a jump. As if the image froze for a fraction of a second before resuming its run. Standing still, you see nothing. But as soon as the camera moves, it shows, because a smooth scroll makes the tiniest bug visible. On the Atari ST there is no ready-made measuring tool. A machine from 1989, an emulator, and my eyes. Here is one evening's investigation, and quite the evening it was ;) First lead: the plague computing too much The obvious suspect was the plague. It spreads once a second, and at that moment it inspects a great many cells at once to decide which ones will contaminate their neighbours. I first hunted down an expensive calculation it kept redoing, and replaced it with a simple value prepared once and for all. On paper, a decent gain. Result: the jump is still there. Same frequency, same amplitude. Well done, but no. Second lead: too many cells redrawn at once Second reflex. When the plague spreads, every cell that changes state has to be redrawn on the next frame. If a lot of cells flip at the same time, that suddenly makes a big pile of drawing to catch up on. So I limited the number of flips allowed per second, with the surplus waiting its turn. Result: the jump is still there. At that point in the evening I started to doubt my hypotheses. I needed to see what was happening, not guess. Seeing time, at last There is an old Atari ST trick, used by demo makers, for visualising where the processing time goes. You change the screen's background colour at every stage of a frame's work. The result: coloured bands appear, and the thickness of each band tells you at a glance how much time that stage cost. No figures, no table, just an image you read instantly. So I coloured each major phase of the game loop and ran it again. Most frames looked alike, nicely balanced, with a wide margin of free time at the bottom, a sign that all is well. And then, exactly once a second, a radically different frame. The plague phase was devouring the top half of the screen. Everything else was crushed against the bottom, and the margin had all but vanished. The diagnosis was finally clear and unambiguous: doing all the plague's propagation work in one go exceeded the time available for a frame, and the emulator then skipped that frame. Neither the expensive calculation nor the pile of drawing was the real culprit. It was simply the total volume, done all at once. The good idea: spread the work out Since doing everything at once is a problem, I may as well spread that work across the fifty frames of a second. On each frame, the plague only handles a small slice. After a second, all the slices together cover a complete cycle. The overall rhythm is preserved, but the spike disappears. I implement it, I test. Perfectly smooth scroll, no more jumps. Victory. I start to savour it. Then I walk into the boss room, and everything turns red in three seconds. The plague had swept across the whole map. The hidden trap I saw the mistake immediately. I had decided to handle a fixed number of cells per frame. When the plague is very widespread, that fixed number only covers a small share of the population on each frame, and all is well. But at the start of a game, when there is only a handful of active cells, that same fixed number takes in all of them, on every frame. So each cell was trying to contaminate a neighbour fifty times faster than intended. The plague exploded. The real solution is to think in proportions rather than in fixed quantities. Instead of promising a number of cells per frame, I guarantee that every cell will be handled once a second, whatever the size of the population. When there are few cells, we do few per frame. When there are many, we do more. The rhythm stays right in every case, from the peaceful opening right through to a saturated boss room. New test, boss room, smooth scroll and plague spreading at the right rate. End of story. What I take away Two lessons I'm keeping. The first: optimising without a diagnosis is a waste of time. My first two fixes were honest improvements, but neither attacked the real cost. Visualising with coloured bands should have been my first step, not my third. It's a gift from Atari ST history: no modern tool gives you a reading that immediate, because on this machine the boundary between computation and image is very thin. The second: spreading periodic work with a fixed quantity per frame is a trap as soon as the population varies. Thinking in proportions guarantees the right rhythm in every case. Obvious afterwards, much less so at the time. The visualisation rig stays in the code, switched off. At the next hitch, I turn it back on and we do this again. The current is available for download . Arrows to move, fire for the lantern, to pause, to quit. Test the scroll in the boss room, that is the area where the optimisation shows best. --- ## Assets: borrowed music and borrowed scenery, and suddenly it looks like a game - **URL**: https://loreoftheember.com/en/blog/009-placeholders-ghouls-chaos-engine/ - **Date**: 10 May 2026 - **Language**: English - **Summary**: Lore of the Ember finally has sound and real scenery. They aren't mine, they are placeholders. Why I made that choice, and what it changes for the rest of the project. - **Tags**: music, graphics What changes this week Lore of the Ember has just passed a milestone I had been waiting for: the game now has sound and real scenery. Borrowed music and borrowed scenery. Placeholders, but placeholders that work. The result: when I launch the game, I see a real level scrolling in front of me, I hear a chiptune theme that fits the mood, and the character walks through it. For the first time, it looks like a game. Why placeholders Simply because I'm not an artist, nor a musician for that matter. And I would like to finish the engine first. So let us take existing music and existing designs. For a prototype it does the job and it lets me move forward. It makes me admire all the more any solo developer who creates a game from A to Z. The music I took the soundtrack of Ghouls 'n Ghosts by Tim Follin, in the Atari ST's standard chiptune format. The game plays it on its own, in the background, without weighing on the rest: it's the machine's sound chip doing the work. The file contains several tracks. I listened to them all and kept the one that fitted the mood best. And it's the best known, too. I had first tried music based on digital samples. Cleaner, but precisely too clean: it sounded modern, and it betrayed the retro side Lore of the Ember owns. Chiptune, on the other hand, is tiny (one small file holds every track), it eats almost no resources, and it sounds right for this game. The scenery For the tiles I took the scenery from the first world of Chaos Engine . It's not a brutal copy and paste: I run it through my own palette, those sixteen cold colours, blue-grey with a few blood-red accents, that give Lore of the Ember its identity. Then I assemble it on the map I draw in my level editor, and the engine displays it. I picked Chaos Engine for good reasons. The style fits: top-down view, dark industrial atmosphere, limited palette, perfect readability in full motion. The tiles are consistent with each other, edges aligned, clean transitions, so I don't have forty junctions to patch up. And it's exactly my target resolution, so nothing needs resizing. Those Bitmap Brothers were good! And to be honest, Chaos Engine remains one of the finest top-down art directions of the era. If my placeholder is at that level, the specification for the final version is crystal clear. Does it run well? Yes. Really well. The game launches on a stock STe, loads in under a second, and runs at full speed. For the first time since the project started, I can play Lore of the Ember rather than just test Lore of the Ember. And that changes everything for the rhythm of development. What comes next With real scenery and real sound in place, I can start the jobs that depended on them: Balance the corruption against coherent scenery, where it reads differently than on an empty screen. Tune the Ashen Wolf's movement, now that I can see where it gets stuck and where it gets lost in the scenery. Build the first act end to end: the engine holds up, and workbench assets are enough to move on to real gameplay. And in parallel, quietly, I can start drawing the real tiles of the Forest of the Hanged and composing the music for Lore of the Ember, without blocking the rest. But that is likely to give me trouble. The engine is done. Now the game begins. Try it Download morteveille-009-ghouls-chaos.zip (122 KB, contains the and the music file ). Unzip everything into the same folder and run in Hatari in STe mode with 1 MB. Arrows to move, fire to clean the plague, to pause, to quit. --- ## One hour of play, five acts, zero boredom: thinking about the hook like a Netflix series - **URL**: https://loreoftheember.com/en/blog/010-serial-hook-narrative-design/ - **Date**: 18 May 2026 - **Language**: English - **Summary**: The engine holds up, the smooth scroll passes muster. It's time to think about what will really matter: why the player keeps playing. An evening digging into serial hook techniques, and the Lore of the Ember mechanics that come out of it. - **Tags**: game-design, narrative, narrative-design The problem I put off for too long I've been working on the engine for several months. Smooth scroll, grid corruption, sprites prepared ahead of time, a plague that spreads without stutter. It looks good, it runs, but none of those technical posts answers the real question: why would anyone see this game through? The Atari ST homebrew scene turns out plenty of technically impressive demos. Some are gorgeous. Many are abandoned by the player after 15 minutes. A scroll at full speed isn't enough. What holds people is wanting to know what happens next . So I put the keyboard down and spent an evening digging into a precise question: what makes you click "next episode" on Breaking Bad at 2 in the morning instead of going to bed? And how do you transpose that to a game that lasts an hour, in 5 acts of 15 minutes, on a machine from 1989? The three engines worth knowing The Zeigarnik effect A bit of seriousness at the back there! In 1927, Bluma Zeigarnik showed that a waiter remembers perfectly the orders he hasn't yet served, and instantly forgets the ones he has just served. The brain retains interrupted tasks far better than completed ones. The whole structure of the cliffhanger rests on that. If you end an episode of a series on a complete action (the door closes, the credits roll), the brain moves on. If you end in the middle of an action (the door opens a crack, cut to black), the brain stays stuck on it. It's mechanical, not cultural. The mystery box JJ Abrams, then Damon Lindelof on Lost, industrialised a simple idea: a closed box has infinite narrative potential as long as you don't open it. The classic trap of the technique is to pile up boxes and never open any of them. The healthy version is that every mystery solved opens a bigger mystery . Narrative recursion. The fractal interest curve Jesse Schell (The Art of Game Design) talks about the interest curve: an opening hook, escalation with peaks and troughs, a final climax. And crucially, that curve is fractal. The whole game has its curve, each act has its own, each room too. Without troughs, the peaks no longer feel like peaks. Narrative calm isn't a flaw, it's a condition of tension. Games that solved this in a short format A few case studies I looked at closely, because they manage a hook without being 80-hour RPGs: Return of the Obra Dinn (Lucas Pope) cuts a big mystery into 10 self-contained disasters. Every revelation recontextualises the earlier scenes. The brain replays them spontaneously. Outer Wilds (Alex Beachum) makes knowledge itself the progression. You don't unlock items, you understand. The short loop naturally pushes the player into another run. Dark Souls (FromSoftware) shows you distant places from the very first hour. Anor Londo visible in the distance for 15 hours of play creates a permanent anchor. Hades (Supergiant) has a narrative that watches your gameplay and reacts to it. Applying all this to Lore of the Ember Abstract principles are one thing. Transposing them to a one-hour game on this machine is another. Here are the directions I'm keeping. The spoken text channel with a portrait of the speaker At first I imagined the narration would be silent or ultra-minimal. Digging in, I realised I had an underused character: the lantern itself . It's an object that speaks to the hero. Why forbid myself from giving it a real presence on screen? So: a 16-bit JRPG style text panel, with the speaker's portrait on the left, either the hero's face when he thinks or speaks, or the lantern's flame when it's the one answering. No dialogue box that freezes the game in combat. Never any text while the player can die. Only in quiet rooms, between fights, or on the inter-act screens. The good news is that I already coded the basic block a few weeks ago while preparing zones 3 and 4 of Act I. A low box with the portrait on the left and the text on the right, pagination on the button, a blinking "next page" arrow. Two portraits are in production, the hero and the flame. The game world freezes cleanly during the display, without flicker. Several triggers are wired into zones 3 and 4: stepping on a specific tile launches the dialogue, and the game remembers the ones already read so they don't fire again. The dialogue box at the bottom of the screen: portrait on the left, text on the right. Here it's the lantern's flame speaking, and the game doesn't stop for it. In other words, the block is there and it runs. What the recent research gave me was mostly an understanding of what it should be for narratively across the 5 acts, and identifying the few layers still missing on top. The cunning part is that the hero's portrait can evolve across the 5 acts. The dark circles, the pallor, the look in his eyes. If I do it well, an attentive player notices without it ever being pointed out. The pipeline is already there for the base portrait: I just have to draw four variants and swap the image according to the current act. Seeds planted The principle is simple: in every act, one passive detail you don't notice. A sprite lurking at the back of the scenery, a sound that comes back, an element that follows the character without intervening. These details aren't interactive. They aren't flagged. They are just there. Later in the game, that detail takes on meaning. The player remembers seeing it. It creates a very particular sensation: the impression that the game knew. That you hadn't seen. Technically it costs almost nothing: one extra sprite per act, sometimes just a modified piece of scenery. Act endings on an interrupted action This is the part where I most revise my own work. The 5 inter-act texts I had written were all reflective : the hero asks himself a question and puts it into words. That works for a novel, not for a game. Corrected version: every act ending finishes on a movement in progress . A hand rising, a noise behind you, an object falling. We never finish a sentence. We cut mid-gesture. The player's brain finishes it for me, and that is exactly what we want. Zeigarnik. The visible counter A daft detail that changes everything: showing progress at the top of the inter-act screen ( I / V , then II / V , and so on). Free technically, enormous in feel. The player knows they are 40% of the way to the truth. Anticipation climbs with the counter. What hasn't changed (and will not) Rule 1 remains absolute: no text is displayed while the player is in action . No dialogue that cuts the action. No cutscene that forces itself in mid-fight. Text arrives in the breathing spaces, on the inter-act screens, and in the trap rooms that are deliberately quiet. The other rule that holds: no chatty NPCs, no merchant telling you his life story, no textual side quests . Just two written voices, the hero and the flame, and silence around them. Priorities The dialogue box already runs, with freeze and portrait. The architecture of the layers that go on top is locked down, all that remains is to code them and draw the assets. Four building blocks, in order: A discreet, non-blocking mode that reuses the same low box, but without pagination and without stealing control from the player. A line of text appears, holds for about three seconds, withdraws, and the game takes over again. It serves the short murmurs that have to slip by while you walk. Forbidden during combat, as always. The progress counter on the inter-act screen: "I / V", "II / V", and so on to the end. The player permanently sees where they are in the five acts, and feels the last one approaching. Rewriting the end of the first act so that it cuts on an action rather than on a question asked. The memory cost of all this is negligible on the STe's scale. The real cost will be writing the lines, which is a very different exercise from code. What I learned doing this research Two things above all. The first is that you can spend months on technique without the game really moving forward. I had refused to think about narrative game design until the engine was stable. The result: I nearly arrived at Act II with inter-act screens that would make nobody want to carry on. Forcing myself into an evening of pure theory spared me that. The second is that the big ideas of serial narrative are surprisingly compatible with the STe's constraints . A dialogue box with a portrait and text costs less than many of the graphical effects I have coded. The Zeigarnik effect asks for nothing more than a sentence cut in the right place. A planted seed is one extra sprite. The machine doesn't limit this kind of design. What limits it is the writing. Every line has to carry weight, because there aren't many of them. What comes next Spec locked, all that is left is to code it. Next session I wire up the discreet mode, draw the portrait variants and write the text. In a future article I will come back to the choices around text rendering (in particular how to bring a sentence in gently, spoiler: no fade, we go typewriter). And if it lives up to its promise, I will show a small demo that runs an opening sequence through both display modes. Until then, if you know of games that nailed the hook in a short format and I have missed them, I'm all ears. --- ## One game for two machines: making the STf scroll - **URL**: https://loreoftheember.com/en/blog/011-software-scroll-stf/ - **Date**: 26 May 2026 - **Language**: English - **Summary**: The STe can scroll on its own, the STf cannot. To ship a single program that boots on both, I had to teach the STf to scroll by hand. The story of a port where the real difficulty was never where I was looking for it. - **Tags**: scroll One program, two machines Lore of the Ember targets the STe, a machine that can slide its own image around effortlessly. That comfort has carried the engine from the start. Except that the real installed base isn't all STe. Plenty of people, myself included, have the original machine, the STf, which doesn't have that hardware help. And an Atari ST game that refuses to boot on an STf is, for part of the audience, a game that doesn't exist. I had two options: two separate versions, or a single program that recognises the machine at startup and picks its display mode by itself. I took the second. On STe, the original hardware scroll, untouched. On STf, a scroll I write for the occasion. The rest of the game, the spreading corruption, the controls, the enemies, the boss, doesn't even know which machine it's running on. This post is about that second mode. And above all about the weeks when I thought the problem was the scroll, when the truth lay elsewhere. The STf cannot scroll On the STf, scrolling the image means doing everything by hand. Shifting the scenery by a few pixels means copying the entire play area on every frame, and that is slow. If you naively shift the pixels on every frame, you drop below ten frames per second. Unplayable. I had documented that ceiling from the start, by watching real games shipped on the STf run. The practical consequence is that the STf displays half as often as the STe. So that the game doesn't run in slow motion on the STf, I made all the logic independent of the display rate: the speed of the world stays the same whether the screen refreshes fast or slowly. Without that, the STf would play in slow motion. That left making horizontal scrolling affordable. The answer: a cache. Prepare rather than recompute The idea is the same old trick as for the sprites: compute almost nothing live. Rather than reworking the scenery on every frame, I prepare the shifted versions of the visible columns ahead of time, and the display only has to copy the right one. A copy costs far less than a recalculation. When the camera moves forward, only the columns coming into view are prepared, the rest are already ready. It costs a little memory, and memory was already tight. So I housed that cache in a space that lies dormant on the STf: on the STe, the HUD scenery is prepared in several copies to follow the hardware scroll, but on the STf that scroll doesn't exist, so the space stays free. It fitted exactly. On paper it was done. On screen it rippled. The waves, first culprit The scenery rippled when the hero moved, especially at the top of the play area. A subtle wave, a few pixels, but definitely there, and unbearable once you have seen it. I spent an unreasonable amount of time blaming my cache. I disabled everything one piece at a time, a daft and slow method, one test per hypothesis. Every time, the waves stayed. The real culprit was elsewhere: a display trick I had carried over from the STe that simply doesn't work on the STf. It disturbed the image right in the middle of it being drawn, and that looked exactly like waves. The lesson was clear: what works in hardware on the STe breaks the image on the STf. So I removed it on the STf. And the scroll no longer waved for that reason. Except the waves were still there. The waves, second culprit Once the first lead was ruled out, I went back over all my tests. The scenery in Lore of the Ember is alive: water animates, corruption spreads and changes the ground constantly. But my cache, which prepares columns ahead of time, froze that scenery at the moment it prepared it. While the world kept moving, the cache was showing an out-of-date version. When scrolling, you could see that lag in time as a wave. The fix leans on something the engine already knows how to do: spot the scenery cells that change and redraw them. All it took was to also refresh the cache for those same cells, right afterwards. The cache stays in step with the world. One last trap remained. When the plague spreads, it changes a lot of cells at once. Refreshing all of it in the same frame is a hitch. So I spread that work over several frames and slow the pulse of the corruption slightly on the STf so it keeps up. The cache takes an extra second to update after a big change, which is invisible in play, and the smoothness never dips. The quarry scenery scrolling on both machines: the STe hardware scroll on one side, the STf software scroll on the other, at the same smoothness. The freezes that weren't where I thought The game was smooth and stable. Then two one-second freezes appeared: one when going right for the first time, one when shooting at the plague. Black screen, nothing. I first suspected my cache, then the dialogue. Wrong on both counts. Investigating properly, I saw that the screen stayed frozen in the middle of a fade to black. And fades are the transitions between rooms. The real culprit was a bad initial assumption: several sequences of the engine (fades, transitions) had been written assuming that displaying an image cost nothing, which is true on the STe but false on the STf. On the STf, every small step of the fade redid the entire display work, and a three-second fade was the result. Since the level is designed to run rooms together seamlessly, crossing a border gave the impression of staying in the same place, with a long stretch of black in the middle. The fix is simple: during a fade the scene is frozen, so there is no reason to redisplay everything at each step. Three seconds became a fraction of a second, and both freezes vanished at once. Taking stock What is delivered: a single program that boots on the STe as well as the STf. On the STe, the original hardware scroll, untouched and fast. On the STf, a smooth hand-written scroll, without waves and without freezes, with game logic that runs at the same speed on both machines. What honestly remains to be done on the STf: the dialogue. It relied on the display trick I had to remove, and its position conflicts with the STf HUD. For now, on the STf, the narrative murmurs are skipped rather than freezing the game. A dialogue rendering path specific to the STf is the next job. On the STe nothing has moved, the dialogue is there. The lesson of these weeks fits in one sentence: on the STf, everything the STe does for free costs time, and several parts of the engine had been written assuming the screen updated itself. It was never the scroll that cost me the most evenings. It was everything that assumed display was free. The build for this milestone is downloadable here (a single STe + STf binary). Run it in Hatari in STf mode to see the software scroll, or in STe mode for the hardware scroll: it's the same file. Arrows to move, fire to clean the plague. For the music, take the archive from the homepage instead, you need the next to the binary. For the current version of the game, see the homepage . --- ## A level on horseback, with depth - **URL**: https://loreoftheember.com/en/blog/012-horseback-parallax-preshift-per-layer/ - **Date**: 30 May 2026 - **Language**: English - **Summary**: I wanted a horseback level that scrolls fast, with a real sense of depth, and that runs just as well on STe as on STf. Here is how I got there with an old professional trick: prepare the images ahead of time, but only as much as you need. - **Tags**: parallax A level on horseback I wanted a level that scrolls fast, a ride in the style of Ivanhoe, with depth. Sky in the background, then distant mountains, a sea, and a foreground of grass streaming under the hooves. Each layer moves at its own speed: the ground scrolls fast, the sea follows more calmly, the mountains barely move. That is the parallax effect, the one that gives the illusion you're really crossing a landscape, and I wanted to push it as far as it would go on both my target machines, the STe and the STf. On paper it's stacked depth. In practice, on the Atari ST, sliding several layers at different speeds without breaking the image is the whole subject. So I started with an isolated prototype, outside the game, to validate the idea before integrating it. This post is about that prototype. Your browser cannot play this video. Download the capture (MP4) . The prototype in motion: over the fixed sky, the mountain, the sea and the ground scroll at three different speeds. A capture of the prototype running on STe as well as STf, at 50 Hz, in 1 MB. The hardware reflex, and its trap The STe can shift its display by a few pixels on its own, effortlessly, thanks to its hardware scroll. The obvious idea: give every layer its own offset and let the machine do the work. Zero extra memory, perfectly smooth. I wrote it. In the emulator it was perfect. Pixel-accurate scroll on every layer, smooth, nothing to complain about. Except that pushing that hardware scroll this far, mid-display, is a minefield. I remembered an old flicker, so before going any further I checked real demos and real games to settle it. The clearest answer comes from a well-known demo from 1990: its author writes, word for word, that he has never seen this type of scroll work correctly on all STs, that he came across a good fifteen different machine configurations, and that if you see flicker it means you have a model he couldn't test. There is the verdict, from a professional: this pushed hardware scroll depends on tiny variations between individual Atari STs. It works on my machine, it will work badly on others. The emulator doesn't reproduce those variations, so it was lying to me by omission. For a game that has to run everywhere, that shortcut had to go. Prepare the images ahead of time, but not the whole scene The reliable technique, the one used by real games that scroll cleanly, is to prepare the shifted versions of the scenery once and for all, at startup, then do nothing but copies, which are far cheaper. Fine scrolling becomes a simple choice among ready-made images. No hardware acrobatics. My first pass prepared the entire scene in all its shifted positions. Smooth, reliable, and a megabyte of memory all by itself. On a machine with a single megabyte, that is dead on arrival. The lesson from real games is that you never prepare a full-screen scene: you prepare the bare minimum. Hence the real fix: prepare each layer separately, with just the fineness it needs. A slow layer needs fine granularity, because the eye freezes every small step. A fast layer does not, because the eye doesn't freeze an image that is streaming past. The sky is a gradient: scrolling it changes nothing on screen, so a single copy is enough. By matching fineness to the speed of each layer like this, I went from a megabyte to a little over half of that, and there is room left for the rest of the game. STe and STf: the same images, two ways of placing them On the STe, I let the machine point each layer at the right ready-made image, layer by layer, mid-display. Three moving layers over a fixed sky, smooth at full speed. One defect appeared when I cut the scene into bands: a thin stray line at the join between two layers. It was a one-line overflow at the moment the machine changes layer. In a single scene it landed on the neighbouring scenery and was invisible. In separate bands it showed. I extended each image by a few lines of margin so that the overflow shows a simple continuation of the scenery, and the stray line disappeared. The STf, for its part, cannot shift its image on its own: it has to be recomposed by hand, every frame. But the images prepared ahead of time are already there, exactly the same ones as on the STe. So the STf only has to copy the right image into the right place, without recomputing anything. Recomposing every full-width layer on every frame is nevertheless too heavy for the STf, which would drop to half speed. So I made a deliberate game design choice: on the STf, I freeze the two slowest layers, the sky and the mountain, and only let the sea and the ground move. Two layers of depth instead of three, but full speed. The STf therefore runs at the same cadence as the STe. Taking stock What is delivered: a prototype of a horseback level with depth, holding up on STe and STf, at full speed on both sides, without flicker and without tearing. The code is solid, and above all reliable on real hardware, not just in the emulator. The moral joins the one from the STf port: on the Atari ST, the hardware offers gorgeous shortcuts that don't always keep their promises across every version. The safe route is often the most down to earth, here copying images prepared ahead of time rather than asking the machine for a tour de force mid-display. The prototype is downloadable here as an .st floppy image . Mount it as floppy A in Hatari, in STe mode to see the three layers scroll, or in STf mode for the two-moving-layer version: it's the same file, it detects the machine by itself. Any key quits. For the current version of the game, see the homepage . --- ## 50 Hz on STe: the bug that only showed up with enemies - **URL**: https://loreoftheember.com/en/blog/013-scanwalk-ste-enemies-aliasing/ - **Date**: 6 June 2026 - **Language**: English - **Summary**: The STe hardware scroll finally gives me 50 Hz. I thought the engine was settled. The day I let loose enemies that prowl out to the edges of the screen, a piece of scenery started appearing in the wrong place. The story of a trap that had been lying in wait for months. - **Tags**: technique, scroll 50 Hz, and what it costs For this top-down game I want a truly full scroll, at 50 frames per second, on the STe. The good news is that this machine can shift its display without copying the image: it simply points somewhere else in its memory. The camera follows the hero, the scenery streams past, and the processor never exhausts itself copying a whole screen. It's the only way to get both smoothness and enough headroom to bring the gameplay to life. The price is memory. The simplest way to slide the image would be to keep the whole world in memory, and that doesn't fit on a one-megabyte machine once you have housed the sprites, the music, the code and the levels in it. So I use a clever memory layout, borrowed from the demo scene, that only keeps a narrow strip of the world at a time and redraws it as the camera advances. It fits in a megabyte, and it delivers hardware scroll at 50 Hz. The catch, I would learn later. The hero never had a problem The hero is always in the centre of the screen. To draw him, I save the scenery under him, display him, then on the next frame I put the scenery back. That has worked for a long time, smoothly, without the slightest smear. I thought the engine was fine. The day the enemies moved I wired up the level's enemies, Chaos Engine style Rock Men who chase the hero and throw rocks at him. They aren't centred: they prowl across the whole width of the screen, out to the edges. And then a rectangle of scenery started appearing in the wrong place, a chunk of rock face pasted onto the grey ground, especially when I doubled back on myself. As long as all the enemies stay entirely on screen, I can sweep the camera left and right without the slightest defect. The offset only appears the moment I move a little fast and at least one enemy vanishes off an edge. A sprite disappearing, that is the trigger. To see the defect without being bothered by the real scenery, I replaced each column of tiles with a flat colour, one per column, cycling. The scenery became coloured vertical bars, and the colour of a displaced bar gave away where it had come from. The verdict was clear: a piece of scenery was being displayed in one place, but showing the contents of another, much further away. The scenery reduced to one colour per column. On the right edge, that red and orange block has no business being there: it's displaying the contents of the left edge. Why the edge, and not the centre The memory layout that lets me fit inside a megabyte has a peculiarity: it folds back on itself. Beyond a certain width, two places in the world end up sharing the same memory cell. As long as you draw in the heart of the visible strip, that fold always lands off screen, invisible and harmless. That is exactly why the hero, always centred, never revealed anything: he is in the middle, far from the edges where the fold bites. An enemy hugging the edge, on the other hand, overflows just enough for its footprint to land in the folded area. The scenery redrawn underneath it then ends up copied onto the opposite edge, off camera, where we never clean it up. The corruption settles in behind the scenes, and jumps out at you as soon as you double back. The original prototype, which only had a centred hero, simply couldn't bring this trap out. The quarry scenery, perfectly stable while everything streams past at 50 Hz, with a Rock Man prowling out to the edge of the screen. The top banner is still waiting for its second player. The fix, without giving up 50 Hz The idea behind the fix fits in one sentence: never trust a screen copy, always go back to the clean source. Rather than saving and then restoring the pixels under each enemy, which ended up copying any smear already present round and round, I redraw the scenery under each sprite directly from the level, on every frame. The source is always clean, so there is nothing left to propagate. To that I added a sort of guard rail at the edges: an enemy too close to the edge is removed from the screen a touch earlier than before. To the eye it's barely noticeable, but it guarantees that its footprint never again overflows into the trapped area. And when an enemy leaves the screen, I carefully clean the trace it was leaving, making sure that this cleanup doesn't itself overflow in turn. The snake no longer bites its own tail. Taking stock The hardware scroll holds 50 Hz on the STe, including scenery, plague outbreaks, hero and lantern jet, and the scenery stays stable, with no ghost rectangle, even doubling back at full speed with the Rock Men and their rocks prowling out to the edges. An honest reservation, measured with a joystick in hand: when the fighting really thickens, three Rock Men charging and throwing their rocks all at once, the frame rate dips a little while that big batch of sprites goes through. The cost is neither the outbreaks nor the enemy intelligence, it's those big sprites displayed all at once. Outside those spikes, it's solid 50 Hz. The same binary switches to software scroll on the STf, detected at startup. The same mechanic, redraw from the source and stay away from the edges, then serves everything else the hardware scroll didn't yet know how to display: the plague outbreaks, laid behind the hero like background scenery, and the lantern jet, those chevrons the hero projects in front of him (and which I'm going to have to get a designer to redo ;) ). Each one starts again from the clean level, so none of them brings any dirt to the screen. The moral joins the one from the parallax: on the Atari ST, the memory tricks that fit the impossible into a megabyte always have a hidden catch. Here, winning both smoothness and space required a memory that folds back on itself. It took nothing more than an always-centred hero to hide the trap for months, and a single enemy leaving the screen to bring it out. The current version of the game is downloadable here as an .st floppy image . Mount it as floppy A in Hatari, in STe mode for the 50 Hz hardware scroll, or in STf mode for the software scroll: it's the same file, it detects the machine at boot. For the current version of the game, see also the homepage . --- ## A HUD that doesn't move a single pixel - **URL**: https://loreoftheember.com/en/blog/014-hud-banner-preshift-ste/ - **Date**: 7 June 2026 - **Language**: English - **Summary**: The hardware scroll that moves the scenery so nicely on STe has an awkward side effect: it shifts the entire screen, including the HUD at the top. So my brand new HUD wanted to slide left and right with the scenery. The story of the technique that nails it in place, and the one-frame hiccup that nearly ruined everything. - **Tags**: technique, scroll The scenery streams past, and the HUD goes with it On the STe, scrolling is done with a single hardware setting: it shifts the displayed image from zero to fifteen pixels to the left, for as long as it takes the camera to cross one tile. That small offset is what makes the scroll smooth, on top of the big jump from one tile to the next. The trap is that this setting acts on the entire screen. It cannot tell the difference between the play area and the HUD sitting right at the top, the one showing the hearts, the score, the lantern gauge and the remaining lives. As long as that banner was a plain black strip, nobody could see that it was sliding too. The day I put the real content back into it, the HUD started sliding a few pixels left and right in time with the scroll. A HUD that moves with the scenery is exactly what you don't want. Sixteen copies, one per offset The idea behind the fix is to turn the problem around. Since the hardware is going to shift the whole screen N pixels to the left, I prepare the HUD content already shifted N pixels to the right. The two offsets cancel out, and the banner lands exactly where it belongs. The trouble is that N changes every frame, and takes every value from zero to fifteen, because the camera advances pixel by pixel. So I prepare sixteen versions of the banner, each shifted one notch further than the last. On every frame I look at how far the hardware is about to push the screen, and I pick the version that compensates exactly. The banner looks frozen while the scenery streams past beneath it. What makes the trick viable is that it costs next to nothing. Once the sixteen versions are prepared, picking the right one on each frame asks almost nothing: no computation, no copying. And the memory for those sixteen copies comes from an area already reserved for the scroll, so the game doesn't grow and still fits in its megabyte, on STe as well as STf. Updating without redoing everything When you take a hit or empty the lantern, the HUD changes. Rebuilding all sixteen copies in full at that moment would cause very visible flicker, with the banner reconstructing itself version by version across several frames. I had already learned that lesson hunting a similarly nasty defect earlier in the project. So I only touch the element that changes. A heart emptying, a notch of the gauge going out: I redraw that small piece, and only that, across all sixteen copies at once, in a single frame. The score and the lives don't flinch, and the change goes through without the slightest shimmer. The one-frame hiccup With the first version in hand, the banner displayed its content properly, the hearts reacted cleanly to damage, nothing overflowed. But while moving, the HUD hiccuped and flickered. Every so often, a small jolt, as if it jumped by a pixel before catching itself. The cause lies in a timing detail I had properly accounted for elsewhere without thinking of it here. To avoid another defect, I apply the new scroll at the very precise moment the new image appears on screen, not before. But I was changing the HUD copy a touch earlier, without waiting for that same instant. For one frame, the banner was already showing its next position while the scenery was still showing the previous one. The mismatch between the two lasted just one frame, but it came back intermittently, hence the hiccups. The fix is to make the copy change wait until the exact instant the scroll switches. Now the banner and the scenery change together, on the same frame, never one without the other. The HUD is perfectly still again. Taking stock The HUD now holds at the top of the screen, hearts, score, lantern gauge and lives, perfectly fixed while the scenery scrolls at full speed beneath it. Damage and refills are visible without flicker, and there isn't a stray line under the banner. All of it without costing anything in frame rate, and still within a single megabyte. The moral fits into a rule I'm noting down for later: with this kind of scroll applied at the last moment, everything tied to the frame, the scenery offset as much as the choice of HUD copy, has to switch at the same precise instant. The current version of the game is downloadable here as an .st floppy image . Mount it as floppy A in Hatari, in STe mode for the hardware scroll, or in STf mode for the software scroll: it's the same file, it detects the machine at boot. For the current version of the game, see also the homepage . --- ## Polishing the interface before showing the game - **URL**: https://loreoftheember.com/en/blog/015-a-clear-interface-for-two-players/ - **Date**: 30 June 2026 - **Language**: English - **Summary**: Before showing Lore of the Ember and gathering the first curious people around the game, I wanted the very first thing you see, the HUD, to be crisp and readable. - **Tags**: game-design, interface, co-op Why now I'm about to show Lore of the Ember properly, and to gather around it the first people who will want to follow it, give me ideas, help me see it through. And the very first thing you perceive of a game, before you even understand what you do in it, is its interface. A scruffy banner, and the whole game looks like a rough draft. So I wanted to lay down a simple interface, but a polished one. Nothing flashy, just something clean and readable, worthy of what I want Lore of the Ember to become. What the HUD has to say in one second At the top of the screen, a thin dark strip ringed with gold. It shows only the essentials, but it has to say them at a single glance, mid-fight, without you having to take your eyes off the action. Three things, not one more: The hearts: Alaric's life. Three hearts that empty a quarter at a time when you take a hit. You watch your health drain without having to think about it. The lantern gauge: the reserve of light. It's both the weapon and the shield of the game, so knowing how much is left, at any moment, changes how you play. I drew it as a row of small cells that go out one by one. The score and the number of lives: placed to the side, clearly readable, without stealing the show from the rest. Simple, but professional The trap, when you want to "make it pretty", is to put in too much. I did the opposite: a restrained background, a thin frame, nice white digits, warm hearts, and that is all. A designer will have to come through here, but not right away ;) The rule I set myself: it has to stay crisp even when very small, and even in slightly compressed video like the ones that will do the rounds on social media. If the interface holds up at that size, it will hold up anywhere. Contrast does the work: black, gold, white, a touch of orange for life and light. Room for a second player Lore of the Ember is played by two, in split screen, and the interface says so from the outset. The banner is cut down the middle: the left half is you, the right half is waiting for a friend. As long as nobody has joined, that right side simply displays "Press Fire". The second someone grabs a second joystick and presses, they enter the game in progress, and their half of the HUD lights up: their life, their score, their own lives. No menu, no waiting screen, you sit down next to each other and play. What comes next The interface is in place, clean, ready to be filmed and shown. Now I want to see it in other people's hands: can you read your health at a glance, does the lantern gauge really create that little fear of running dry, does the arrival of a second player make you want to join? Those are the responses I'm waiting for. To see where the game is at, see the homepage . --- ## Two machines, two ways of scrolling - **URL**: https://loreoftheember.com/en/blog/016-two-ways-to-scroll-the-world/ - **Date**: 3 July 2026 - **Language**: English - **Summary**: Lore of the Ember runs on Atari, from the STf to the STe. The scenery has to scroll with the same smoothness everywhere, and to get there I needed two very different ways of scrolling the game: the STe hardware scroll on one side, redrawing everything by hand on the STf on the other. Here is why, and what it means for you. - **Tags**: game-design, technique Let's talk about scrolling In Lore of the Ember, the camera follows Alaric everywhere, the world scrolls around him, and if that scrolling catches, hops or shakes, the whole game takes on a wonky air, even when everything else is polished. That is why I have spent a lot of time on this detail. Smooth movement is what lets you sink fully into the game, until all you see is the character and the world around him. That is exactly the effect I'm after. Two families of machines Lore of the Ember is made for Atari, and Atari released several models over the years. For our purposes here there are two big families: the STf and the STe, its slightly beefier version. The difference comes down to two small things the STe has and the STf does not. The first is hardware scroll: the STe can shift the displayed image on its own, smoothly, without the game having to redraw anything. The second is the blitter, a dedicated chip that copies pieces of image at high speed, far faster than the processor would. On the STf, neither: it's the processor, and therefore my program, that has to do everything. I was determined that Lore of the Ember should run well on both. There is no way I'm reserving the game for the STe and leaving out everyone who stayed on an STf. On the STe, I lean on the machine On the STe, I let the hardware work for me. The hardware scroll moves the scenery smoothly, the camera sticks to the hero, and the world unrolls without a single snag. Meanwhile, the blitter draws the characters and the animated elements. The small improvement I'm happiest with is recent: instead of starting the blitter and then waiting for it to finish, I now let it draw while the processor is already preparing what comes next. The two advance at the same time. I put that scavenged time to use: more enemies on screen at once, headroom for the second player, without the movement losing a scrap of its smoothness. That is the version I show first, because it's where Lore of the Ember is closest to what I have in mind: a smooth walk through a world going bad, where nothing breaks the immersion. Your browser cannot play this video. Download the capture (MP4) . Scrolling on the STe: the scenery moves pixel by pixel. On the STf, I do everything by hand On the STf I have neither of those safety nets. No hardware scroll: every small step of the scenery is an entire image my program has to redraw, shifted, by hand. No blitter either: the processor alone carries the weight of everything moving on screen. The classic trap is to end up with choppy scrolling that lurches forward. That is where the real challenge was: getting scrolling on the STf that is steady and pleasant, that never feels like a limited game or a cut-price version. I turned the problem over every which way so that the movement stays constant, without stutter, from the beginning to the end of a move. Today it rolls, and I'm proud of it: that is what makes all the difference with a joystick in hand. Your browser cannot play this video. Download the capture (MP4) . Scrolling on the STf: everything is recomputed, and it stays steady. What comes next The movement is in place and smooth on both sides. The next step is to put it in other players' hands and see whether this scroll produces the right effect: sinking fully into the game. To see where the game is at, see the homepage . --- ## A ride for two - **URL**: https://loreoftheember.com/en/blog/017-a-ride-for-two/ - **Date**: 4 July 2026 - **Language**: English - **Summary**: Lore of the Ember isn't only played on foot. I have added two-player parallax handling to the engine, with enemies coming from every direction. - **Tags**: game-design Leaving the village Alaric goes from level to level on foot. For the game to be memorable it needs different kinds of gameplay, and a ride in the style of Shock Troopers (the motorbike level) struck me as an interesting thing to build. The result is a side-on level: you're in the saddle, you move forward, you shoot, and the landscape streams past. The tone changes completely from the rest of the game. Where crossing the village is slow and tense, here everything is fast, shots come from everywhere, and there is no time to think. That contrast is exactly what I was after. Two layers, two speeds For a chase to give a sense of speed, sliding one image isn't enough. The different layers of the scenery have to move at different rates. The famous parallax. So I cut the screen into two zones. At the top, the sky and mountainous scenery, drifting slowly. At the bottom, the ground, streaming past. Between the two, the cut-out silhouette of the dunes, drawn rather than computed, so you don't see a straight line between the two parallax layers. The sky advances one pixel per frame, which is the finest possible step and therefore the softest. On a machine from 1989, computing that offset at display time costs far too much to hold the cadence. So I prepared sixteen versions of the sky, each shifted one pixel further than the last, and I simply display the right one. The work is done once, at load time, instead of being redone fifty times a second. This kind of trade-off comes up constantly on this machine: pay once in memory to free up processor time. Two in the saddle The sequence is played by two. Two riders, two lines of fire, and the same route. It's the first place where I really felt the game gained from being shared: with one player it's a race, with two it's a collaboration, and you divide up the targets without saying a word. The ride in full flow: the two riders, the gallop, the dunes streaming past, and the shots crossing both parallax layers. The same thing on STf and on STe The trap with parallax is that it holds up on the STe and collapses on the STf. I imposed the opposite rule on myself: one program, and the same smoothness on both sides. The STe leans on its graphics chip, the STf recomputes everything, and the player must not see a difference. That is the part that took the longest, by far. What comes next The ride exists and is playable. It will become a level in its own right, with its own enemies and its own place in the story. For now it has mostly served to prove one thing: the game can change rhythm without changing engine. The scenery is the Shock Troopers scenery, which I will redo with my designer. To see where the game is at, see the homepage . --- ## The second player joins in - **URL**: https://loreoftheember.com/en/blog/018-the-second-player-joins-in/ - **Date**: 12 July 2026 - **Language**: English - **Summary**: Lore of the Ember is now played by two. The second player isn't just an extra: he is the Ardent, a champion of embers summoned by the lantern, with his own weapon, his own lives and his own score. He can join the game at any moment to help Alaric. - **Tags**: game-design A second hero, not a second cursor Two-player co-op is in place. It had been planned for a long time, but now it's done. Player 2 plays the Ardent. Alaric keeps the lantern: it's the lantern that summons this champion of embers. The second player arriving and leaving doesn't happen in a menu but directly in game. He has his own weapon, a staff that fires a volley of three orbs, one large then one medium then one small. It plays differently from Alaric's lantern, and that is deliberate: with two players you don't want the same thing twice on screen. For now these are Chaos Engine sprites, which will be replaced once I find a designer ;) The two heroes on screen: Alaric with his lantern, and the Ardent firing his volley of three orbs. Joining mid-game So in short, the second player presses the fire button, and there he is. No selection screen, no going back to the menu, no game to restart. Someone walks into the room, picks up the joystick, and plays. For that to work, the invitation has to be visible without being intrusive. The top banner, which I talked about in an earlier article , had been designed with this very moment in mind. It displays "PRESS FIRE" in the place player 2's hearts will occupy. What joining costs An invisible detail that took a fair bit of work: originally, pressing the button to join caused a hitch. The whole right half of the banner had to be redrawn all at once, mid-game, and it showed, I was getting slowdowns. The solution I put in place is to prepare that half of the banner at game startup, while the screen is still black. It's genuinely drawn, but painted in the background colour, so it's invisible in single player. When the second player joins, I redraw nothing at all: I simply change the colours concerned. Player 2's banner appears at once, without the game slowing by a single frame. The palette is only sixteen colours, but you can change it at will without touching a single pixel, and it costs almost nothing. Many of the game's effects rest on that. And the camera, in all this The real headache of co-op on a single screen is framing. Two players each heading their own way, and you have to choose who the camera follows. So the camera follows whoever is moving forward, while keeping the other in frame, and it moves gradually rather than jumping when the situation changes. 📷 Capture to come: the banner in co-op, the two health and score areas side by side, while the scenery scrolls. What comes next Co-op works on both machines, STf as well as STe. What remains is to put it through long testing with two joysticks, over real sessions, because it's the kind of mechanic whose flaws only show up after a long play session. To see where the game is at, see the homepage . --- ## An intro in five shots - **URL**: https://loreoftheember.com/en/blog/019-an-intro-in-five-shots/ - **Date**: 28 July 2026 - **Language**: English - **Summary**: Before you play, the game has to tell a story and set the mood: five shots in sequence, from Alaric waking up to the silhouette of the castle under the storm. An intro is expensive on a 1 MB machine, and yet almost everything that moves in it costs nothing. - **Tags**: game-design Setting the scene before handing over control Lore of the Ember rests on a situation you have to grasp in a few seconds: a man wakes up in a dead village, his hands covered in blood that isn't his own, with a lantern beside him. If you start straight on the gameplay, all that is left is a character shooting at enemies. So the intro runs five shots, in this order: the village from above, the awakening, the lantern, the walk across the street, and the castle under the storm. Each carries two lines of narration, in French or in English depending on the language chosen at startup. The first shot of the intro: the dead village, and the castle keeping watch in the background. The narration appears in the strip at the bottom. What moves without costing anything Three of those five shots are still images. And yet something is happening in them constantly: the lantern's flame breathes, the storm bursts over the castle, Alaric's eyelids flutter before opening for good. Almost none of that consumes any power, because nothing is redrawn. On the Atari, the displayed image has only sixteen colours, and those sixteen colours can be changed at will, instantly, without touching a single pixel. The flickering flame is a colour being raised and lowered. The lightning is already drawn on the image from the start: I simply hold it at the colour of the clouds, so it's invisible, and it's its sudden appearance that makes the event. The only real movement is the eyelids, a tiny rectangle in the middle of the face. I spent time on their rhythm: at a tenth of a second per blink, it's really an image flickering. At a fifth of a second, it becomes an awakening. Four black screens to get rid of The real problem with this intro wasn't graphical. There were four cuts of about two seconds, black screen, in the middle of the narration. The cause was simple: the intro images are read from the floppy at the moment they are needed, and a double density floppy reads slowly. Ten seconds of reading in total, spread across the shots, isn't great. I first tried doing those reads at specific moments of the intro, while Alaric's eyes are closed, then during the village shot. Both times the reading overran the time available, and the intro sat paused for the whole duration of the load. In short, a bad idea. The solution was to read everything in one block before the first shot. The cutscene then plays out without a single disk access, at exactly the intended cadence. The price is a wait at startup, but an honest, announced wait is better than four long pauses in the middle of a scene. That wait is now dressed up, too: a drawn screen, in the player's language, replaces the tiny loading indicator that was there before. It also serves for level loading. The loading screen, displayed during loads. Alaric waits it out. What comes next The intro runs from beginning to end, inside the game and not in a separate program. The fourth shot, the one where Alaric walks across the street, took a job of its own: his gait doesn't come from an invented curve, but from a filmed walk traced frame by frame. That will be for another time. To see where the game is at, see the homepage . --- ## The scenery arrives from disk - **URL**: https://loreoftheember.com/en/blog/021-the-scenery-arrives-from-disk/ - **Date**: 3 August 2026 - **Language**: English - **Summary**: On a 1 MB Atari, everything that is in the program stays there forever, and I need that memory! So the level scenery has left memory to live on the floppy, from where it's read when you enter an area. Along the way, the game now installs on a hard disk. - **Tags**: game-design One megabyte, and not one more The Atari 1040 STf/STe has 1 MB of memory. The system takes a share, and the game is left with a little under 900 KB for absolutely everything: the program, the scenery, the characters, the sounds. There is a rule you have to know well when developing on the Atari: the program is loaded in a single block, and nothing ever leaves it. There is no virtual memory, no paging, no system quietly unloading what is no longer needed. Everything I compile into the game takes up space from startup until the machine is switched off. And scenery is the heaviest thing there is, and it's precisely the sort of data that is generally unique to each level. There is no reason for the Act II scenery to occupy memory while you're playing Act I. Getting the scenery out of the program So the scenery has left RAM to stay on the floppy. It's read when you enter an area, into shared buffers: the scenery you're leaving makes room for the one you're discovering, and the content stops costing memory permanently for nothing. The result is clear. The available headroom on a 1 MB machine has doubled, and the program itself has lost a fair bit of weight. In concrete terms, that means bigger and more detailed levels, without having to choose between the size of a map and the number of enemies living on it. Two precautions guided the work. First, changing room only re-reads the disk if the scenery requested is genuinely different: going through a door and coming straight back doesn't trigger a read. Second, the tool I built, the one that builds the floppy, announces what doesn't fit instead of truncating without telling me, because otherwise you get bombs. The level in play. All this scenery is read from disk on entering the area, and no longer weighs on memory permanently. Doing some housekeeping ;) The second job was hunting down what was being loaded without serving any purpose. A music player waiting for a format I no longer use. A sprite sheet for an opponent that cannot appear in the current state of the game. Nothing spectacular, but 53 KB that went out with every session. This kind of housekeeping isn't exciting to write about, and yet it's what decides whether an idea will be possible or not three months later. On this machine, you don't gain space by optimising: you gain it by throwing things away. And on hard disk One last point, very concrete for those playing on real hardware that has one: the game now installs on a hard disk, in a single folder, without scattering anything across the partition. The loader looks for the scenery next to the program before going to look elsewhere. The floppy version sees no difference. The whole game fits in that folder. That is a milestone I didn't think I would reach this early. Thanks to the community for the tip! What comes next With that headroom recovered, the priority goes back to content: finishing the first level end to end, with its enemies, its plague outbreaks and its progression, and putting it in other players' hands. To see where the game is at, see the homepage . --- ## The screen takes the hit - **URL**: https://loreoftheember.com/en/blog/022-the-screen-takes-the-hit/ - **Date**: 5 August 2026 - **Language**: English - **Summary**: Until now an enemy died cleanly: it disappeared, and nothing else moved. There was the explosion, of course, but I wanted to go further. I spent a few days preparing this. The screen now shakes under explosions, monsters blow apart, and a white flash appears before the screen tilts ;) - **Tags**: game-design The explosion that shakes the screen In Chaos Engine there are items that let you set off a huge explosion, killing every enemy on screen. I absolutely had to have that in my engine. So it's done, and it's very smooth, on both STf and STe. The music doesn't glitch during the explosion, which is exactly what I had in mind. The first thing I added is the simplest to describe: when something explodes, the whole screen is shaken. A sharp jolt, then a bounce that damps out in a fraction of a second. There are two intensities. A monster's death gives a firm shake. A hit taken by the hero gives a more discreet shake, but enough for you to understand you have just lost health. That is actually the effect I cared about most: when you take a hit in the back while aiming elsewhere, the screen tells you before your eyes have time to check. Handling particles I wanted to build particle handling into the engine. You never know, particles are bound to come in useful. I spent more time than expected on those few scraps of pixels, for a reason I hadn't anticipated. My first version sent the debris out in eight perfectly regular directions, at the same speed, over the same distance. The result looked like a geometric pattern, a sort of rosette, anything but an explosion. An explosion is disorder. As long as every fragment left in exactly the same way, no amount of tuning speed or weight changed anything. The solution was to randomise, for each piece, its exact direction, its speed and its lifetime. And to give them different silhouettes, because a square stays a square: a stone has no right angles. Second lesson, more amusing. I had given the debris a weight strong enough that you would see them fall back down, except that this weight crushed everything: after a few moments every fragment dived downwards whatever its starting direction. They never had time to go anywhere. I had to balance the fall against the momentum, which sounds obvious written down like this, and isn't obvious at all when you're looking at the result without understanding why it falls flat. All of this is now configured from a single line of settings per family of effect: how many pieces, which hues, what speed, what weight, how long. The fragments in action: every piece leaves in its own direction, at its own speed, and the screen takes the shock. The flash, then the blast My first attempt triggered everything at once: the white flash, the explosions, the shake. The result wasn't right. The current version goes step by step. A white flash briefly covers the screen. Then, as the light falls away, everything blows at once. That is something I learned by getting it wrong: how you stage an effect often matters more than the effect itself. The explosion at work: flash and tremor. Without losing anything along the way There was one constraint above all this work, and it wasn't negotiable. These effects must not cost the game an ounce of smoothness, not on the STe, and not on the STf which is by far the tighter of the two. And my first version of the fragments did exactly that, it cost the game its smoothness. The obvious reflex would have been to remove half of them, since nobody notices eight pieces of debris rather than four whereas everybody notices a game that stutters. Except that the real problem wasn't their number, it was the way I was drawing them. My first method noted what lay under each fragment before placing it, so it could put the scenery back on the next frame. It works, it's what the game does for the hero and the enemies, but it's expensive: you set aside and then restore an area far larger than the pebble itself, and you pay for that on every frame and for every piece. So I took the problem from another angle. Rather than memorising the scenery under a fragment, I simply redraw it where it was, from the level map. It's a technique my engine already uses elsewhere, and it's far better suited to objects this small: nothing to hold in reserve, and four cells of scenery to repaint instead of saving and then restoring a whole area. The result is that in the end I had nothing to sacrifice. The eight particles are there, and the game runs exactly as if there were none. I did keep eight as a ceiling, because twice that was starting to show, but it's a limit of caution and not a surrender. It's a lesson this machine teaches me again regularly: when an effect costs too much, the right question is almost never "how many can I remove", but "am I going about this the right way". What comes next The next step will be light: a lantern that genuinely lights up its surroundings, in dark scenery. And that won't be a walk in the park ;) --- ## On the ice, our reflection has to appear - **URL**: https://loreoftheember.com/en/blog/023-on-the-ice-everything-reflects/ - **Date**: 12 August 2026 - **Language**: English - **Summary**: The world of Lore of the Ember is matt, dusty, eaten away. I wanted one place doing the exact opposite: a surface that gives back the image of whatever walks on it. A sheet of ice on the ground, big enough for two players, with the monsters reflected in it too. - **Tags**: game-design, technique Ground that gives back the image Everything in Lore of the Ember is matt. Earth, stone, trunks, ash: nothing shines, nothing gives anything back, and that is on purpose, this is a world going out. Hence the urge to drop, right in the middle of it, a surface doing the exact opposite. A sheet of ice, flat on the ground, on which you watch your own reflection walk. What it looks like on screen The hero steps onto the sheet and his reflection appears under his feet, upside down, translucent, offset by just the right amount. It follows him step for step. When the hero shoots, the reflection shoots too. When he leaves the ice, the reflection is cut clean at the edge, it never bleeds onto the soil around. The monsters do not escape it either. A golem crossing the sheet drags its reflection along, and that is where the effect earns its place: you stop watching only the character and start watching a surface that answers everything moving across it. Your browser cannot play the video. Download the capture (MP4) . The ice sheet in two player mode: every character drags its reflection. With two players, it counts double In cooperative play the sheet turns into a little stage. Two heroes, two reflections gliding side by side, and the monsters walking into frame with theirs. I made the sheet bigger for exactly that reason: the first version sat in a corner of the screen, you crossed it in three steps and never had time to see the effect. This one fills almost the whole screen, you walk in, you fight on it, you walk out. How it holds on an Atari This is the kind of effect you expect to be expensive, and that is precisely what made it worth doing. The reflection is not a second drawing. It is not one more image handed over by the artist, nor a copy stored somewhere: it is the character himself, read from bottom to top. Eight walking directions stay eight walking directions, there is nothing extra to draw. The transparency costs no extra colour either. The reflection is laid down through a pattern that lets only one pixel in two through, so the ice shows underneath and the eye reads a ghost rather than a second character. One detail I care about: that pattern is pinned to the surface, not to the character. Pinned to the ice, it behaves like what it stands for, a state of the ground. What comes next The most satisfying part is that none of this talks about ice. What reflects is described separately, and ice is only the first case. A puddle after the rain, a polished slab in a place of worship, black water at the bottom of a cellar: all of them will now give your image back the same way, and I fully intend to use that. --- ## The game no longer fits on a single machine - **URL**: https://loreoftheember.com/en/blog/024-the-game-no-longer-fits-on-one-machine/ - **Date**: 22 August 2026 - **Language**: English - **Summary**: Lore of the Ember was born on the Atari ST and never intended to leave it. Today it also runs on the Megadrive and on the Amiga. Here is why I finally went there, what it changes for you depending on which machine you kept, and what it does not change at all. - **Tags**: game-design Three machines, and only one that decides Some announcements take weeks to prepare. This one made itself, and the hard part, the day I sat down to write it, was finding the right way to say it to the people who have followed this devlog from the start. Lore of the Ember was born on the Atari ST. It was born there because that is the machine where my passion took root, and letting go of it was never on the table. It remains the original version, the one I run first, the one that settles arguments. But for a few weeks now, the same game has also been running on the Megadrive and on the Amiga . I say it in that order on purpose, because the order is half the story: the Atari has not become one version out of three. It stayed the yardstick. Whatever fits there fits everywhere else, and not the other way round. Why I did not go there sooner Because it is the kind of idea that kills solo projects. Adding machines before the game is finished is the surest way to finish none of them. You spend your time doing the same thing three times, each one slightly worse, and the game stops moving. I have watched enough projects die that way not to jump in out of enthusiasm. What changed is that the game reached a state where the question no longer worked like that. Years ago, tidying this old engine away for the tenth time, I had separated two things: the game on one side, its monsters, its plague, its rules; and on the other the part that talks to the machine. At the time it was just housekeeping, and honestly I did it for my own peace of mind, not as part of some grand plan. That housekeeping is what made the rest possible. The day I wanted to see what the game would look like elsewhere, I did not have to rewrite it. I had to learn to talk to another machine, which is an enormous amount of work, but which never touches the game itself. What it changes for you Entirely depending on what you kept in a box. If you have an Atari ST , nothing changes, except that you now have company. It is still the most advanced of the three versions, and still the one that gets new things first. It runs on the STe and on the STf, on a stock Atari, and it installs to a hard disk too. If you have a Megadrive , you will not get a watered-down conversion. I set one rule for that version and I hold to it: the game is not ported to the console, it is improved there. Every step is judged twice, is it faithful to the game, and is it the best this console can do. Copying the Atari stroke for stroke would mean paying its constraints without collecting what the Megadrive gives. The first gain is visible immediately: the scenery is no longer held to the Atari's sixteen colours. Same artwork, far richer. If you have an Amiga , that is the youngest of the three builds and the one moving fastest right now. The target is the stock A500, the one nearly everybody had, not an upgraded box. A game that only runs on a rare configuration is no use to anyone. What it does not change The world, the story, the monsters and the rules are the same everywhere. The plague spreads the same way, the lantern does the same work, the second player joins the same way. Nobody gets an amputated version, and nobody gets an exclusive. And above all: no version is held back to look like the others. That was the obvious temptation, the one that makes life easier, and it is exactly the one to refuse. A machine that can do better must do better, even if its neighbour cannot follow. A player does not compare three versions side by side, they play on theirs. Where each version stands I have added three pages to the site, one per machine, with the real state of each: Atari ST , Megadrive , Amiga . The progress bars on the homepage are now split into three sets, for the same reason. I would rather the gap between the three be visible than let anyone assume a parity that does not exist yet. The devlog itself now filters by machine. The earlier posts are all about the Atari, which is normal, that is what happened. The next ones will always say which machine they are about. And what comes next That does not change either. I did not add two machines in order to slow the first one down: the remaining acts are still the main build, on all three at once. One last thing, for those who have followed this project since the first post. There is an irony I rather enjoy: spending thirty years defending the Atari against the Amiga in the playground, and ending up writing a game that runs on both. I have not switched sides. I have simply come round to admitting that the other side had a fine machine. --- # Devlog articles in French (originals) ## 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 - **Language**: French - **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 - **Language**: French - **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 - **Language**: French - **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, scroll 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 - **Language**: French - **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**: scroll 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 - **Language**: French - **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, graphismes 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 - **Language**: French - **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 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 - **Language**: French - **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 - **Language**: French - **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 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 - **Language**: French - **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 - **Language**: French - **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 - **Language**: French - **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 - **Language**: French - **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**: scroll 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 - **Language**: French - **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 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 - **Language**: French - **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, 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 - **Language**: French - **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, 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 - **Language**: French - **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 - **Language**: French - **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, 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 - **Language**: French - **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 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 - **Language**: French - **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 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 - **Language**: French - **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 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 - **Language**: French - **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 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 . --- ## L'écran encaisse les coups - **URL**: https://loreoftheember.com/blog/022-l-ecran-encaisse-les-coups/ - **Date**: 5 août 2026 - **Language**: French - **Summary**: Jusqu'ici, un ennemi mourait proprement : il disparaissait, et rien d'autre ne bougeait. Il y avait bien l'explosion, mais je souhaitais faire encore plus. J'ai passé quelques jours à préparer ça. L'écran tremble maintenant sous les explosions, les monstres partent en éclats, et un éclair blanc apparait avant que l'écran tilt ;) - **Tags**: game-design L'explosion qui fait trembler l'écran Sur Chaos Engine, il existe des items, qui te permettent de générer une grosse explosion, permettant de tuer tous les ennemis présents à l'écran. Il fallait absolument cela dans mon moteur. Du coup c'est chose faite, et c'est très fluide, à la fois sur STf et STe. La musique ne bug pas durant l'explosion, c'est exactement ce que j'imaginais. La première chose que j'ai ajoutée est la plus simple à décrire : quand quelque chose explose, tout l'écran est secoué. Un choc sec, puis un rebond qui s'amortit en une fraction de seconde. Il y a deux intensités. La mort d'un monstre donne une secousse franche. Un coup encaissé par le héros donne une secousse plus discrète, mais suffisante pour qu'on comprenne qu'on vient de perdre de la vie. C'est même l'effet auquel je tenais le plus : quand on se prend un coup dans le dos pendant qu'on vise ailleurs, l'écran le dit avant que le regard n'ait le temps de vérifier. La gestion des particules J'ai voulu intégrer la gestion des particules dans le moteur. On ne sait jamais les particules ça va forcément me servir. J'ai passé plus de temps que prévu sur ces quelques morceaux de pixels, pour une raison que je n'avais pas anticipée. Ma première version envoyait les débris dans huit directions parfaitement régulières, à la même vitesse, sur la même distance. Le résultat ressemblait à un motif géométrique, une sorte de rosace, tout sauf à une explosion. Une explosion, c'est du désordre. Tant que chaque éclat partait exactement de la même manière, aucun réglage de vitesse ou de poids n'y changeait quoi que ce soit. La solution a été de random, pour chaque morceau, sa direction exacte, sa vitesse et sa durée de vie. Et de leur donner des silhouettes différentes, parce qu'un carré reste un carré : une pierre n'a pas d'angles droits. Deuxième leçon, plus amusante. J'avais donné aux débris un poids assez fort pour qu'on les voie retomber, sauf que ce poids écrasait tout : au bout de quelques instants, tous les éclats plongeaient vers le bas quelle que soit leur direction de départ. Ils n'avaient jamais le temps d'aller nulle part. Il a fallu doser la chute contre l'élan, ce qui parait évident écrit comme ça, et ne l'est pas du tout quand on regarde le résultat sans comprendre pourquoi il tombe à plat. Tout cela se paramètre maintenant depuis une seule ligne de réglages par famille d'effet : combien de morceaux, quelles teintes, quelle vitesse, quel poids, combien de temps. Les éclats en action : chaque morceau part dans sa propre direction, à sa propre vitesse, et l'écran encaisse le choc. L'éclair, puis la déflagration Ma première tentative déclenchait tout en même temps : le flash blanc, les explosions, la secousse. Le rendu n'était pas le bon. La version actuelle utilise le step by step. Un éclair blanc couvre l'écran, brièvement. Puis, quand la lumière retombe, tout saute d'un coup. C'est une chose que j'ai apprise en la ratant : la mise en scène d'un effet compte souvent plus que l'effet lui-même. L'explosion en oeuvre : Eclair et tremblement Sans rien perdre en route Il y avait une contrainte au-dessus de tout ce travail, et elle n'était pas négociable. Ces effets ne devaient pas coûter une once de fluidité au jeu, ni sur le STe, ni sur le STf qui est de loin le plus serré des deux. Et ma première version des éclats faisait justement perdre au jeu sa fluidité. Le réflexe évident aurait été d'en enlever la moitié, puisque personne ne remarque huit débris plutôt que quatre alors que tout le monde remarque un jeu qui saccade. Sauf que le vrai problème n'était pas leur nombre, c'était ma façon de les dessiner. Ma première méthode notait ce qui se trouvait sous chaque éclat avant de le poser, pour pouvoir remettre le décor en place à l'image suivante. Ça marche, c'est ce que fait le jeu pour le héros et les ennemis, mais c'est cher : on met de côté puis on restaure une zone bien plus grande que le caillou lui-même, et ça se paie à chaque image et pour chaque morceau. J'ai donc pris le problème autrement. Plutôt que de mémoriser le décor sous un éclat, je le redessine simplement là où il était, à partir de la carte du niveau. C'est une technique que mon moteur utilise déjà ailleurs, et elle est bien mieux adaptée à des objets aussi petits : rien à mettre en réserve, et quatre cases de décor à repeindre au lieu de sauvegarder puis restaurer toute une zone. Le résultat, c'est que je n'ai finalement rien eu à sacrifier. Les huit particules sont là, et le jeu tourne exactement comme s'il n'y en avait aucun. J'ai quand même gardé huit comme plafond, parce que le double commençait à se faire sentir, mais c'est une limite de prudence et pas un renoncement. C'est une leçon que cette machine me réapprend régulièrement : quand un effet coûte trop cher, la bonne question n'est presque jamais "combien puis-je en enlever", mais "est-ce que je m'y prends de la bonne manière". La suite La prochaine étape sera la lumière : une lanterne qui éclaire vraiment autour d'elle, dans un décor sombre. Et ça ce sera pas du gâteau ;) --- ## Sur la glace, il faut faire apparaitre notre reflet - **URL**: https://loreoftheember.com/blog/023-sur-la-glace-tout-se-reflete/ - **Date**: 12 août 2026 - **Language**: French - **Summary**: Le monde de Lore of the Ember est mat, poussiéreux, rongé. Je voulais un endroit qui fasse exactement l'inverse : une surface qui renvoie l'image de ce qui passe dessus. Une plaque de glace au sol, assez grande pour qu'on y marche à deux, avec les monstres qui s'y reflètent aussi. - **Tags**: game-design, technique Un sol qui renvoie l'image Tout dans Lore of the Ember est mat. La terre, la pierre, les troncs, la cendre : rien ne brille, rien ne renvoie quoi que ce soit, et c'est voulu, c'est un monde qui s'éteint. D'où l'envie de poser, au milieu de ça, une surface qui fasse exactement l'inverse. Une plaque de glace, à même le sol, sur laquelle on voit son propre reflet marcher. Ce que ça donne à l'écran Le héros arrive sur la plaque, et son reflet apparaît sous ses pieds, à l'envers, translucide, décalé juste ce qu'il faut. Il le suit pas à pas. Quand le héros tire, le reflet tire aussi. Quand il sort de la glace, le reflet se coupe net au bord, il ne bave pas sur la terre autour. Les monstres n'y échappent pas. Un golem qui traverse la plaque traîne son reflet avec lui, et c'est là que l'effet prend son sens : on ne regarde plus seulement le personnage, on regarde une surface qui réagit à tout ce qui passe dessus. Votre navigateur ne peut pas lire la vidéo. Télécharger la capture (MP4) . La plaque de glace, à deux joueurs : chaque personnage traîne son reflet. À deux, ça compte double En coopération, la plaque devient une petite scène. Deux héros, deux reflets qui glissent côte à côte, et les monstres qui entrent dans le cadre avec le leur. J'ai agrandi la plaque exprès pour ça : la première version tenait dans un coin de l'écran, on la traversait en trois pas et on n'avait pas le temps de voir l'effet. Celle-ci occupe presque tout l'écran, on y entre, on s'y bat, on en ressort. Comment ça tient sur un Atari C'est le genre d'effet dont on se dit qu'il va coûter cher, et c'est justement ce qui le rendait intéressant à faire. Le reflet n'est pas un deuxième dessin. Ce n'est pas une image de plus fournie par le graphiste, ni une copie stockée quelque part : c'est le personnage lui-même, relu de bas en haut. Huit directions de marche restent huit directions de marche, il n'y a rien à dessiner en plus. La transparence, elle, ne coûte aucune couleur supplémentaire. Le reflet est posé au travers d'un motif qui ne laisse passer qu'un pixel sur deux, si bien que la glace transparaît dessous et que l'oeil lit un fantôme plutôt qu'un second personnage. Détail auquel je tiens : ce motif est accroché à la surface, pas au personnage. Accroché à la glace, il se comporte comme ce qu'il représente, un état du sol. La suite Le plus satisfaisant, c'est que rien là-dedans ne parle de glace. Ce qui reflète est décrit à part, et la glace n'en est que le premier cas. Une flaque après la pluie, une dalle polie dans un lieu de culte, l'eau noire au fond d'une cave : tout ça renverra désormais votre image de la même façon, et j'ai bien l'intention de m'en servir. --- ## Le jeu ne tient plus sur une seule machine - **URL**: https://loreoftheember.com/blog/024-le-jeu-ne-tient-plus-sur-une-seule-machine/ - **Date**: 22 août 2026 - **Language**: French - **Summary**: Lore of the Ember est né sur Atari ST et n'a jamais eu l'intention d'en bouger. Il tourne pourtant aujourd'hui aussi sur Megadrive et sur Amiga. Voici pourquoi j'ai fini par y aller, ce que ça change pour vous selon la machine que vous avez gardée, et ce que ça ne change pas du tout. - **Tags**: game-design Trois machines, et une seule qui décide Il y a des annonces qu'on prépare pendant des semaines. Celle-là s'est imposée toute seule, et le jour où j'ai voulu l'écrire, le plus dur a été de trouver la bonne façon de le dire à ceux qui suivent ce devlog depuis le début. Lore of the Ember est né sur Atari ST. Il y est né parce que c'est la machine sur laquelle ma passion s'est enracinée, et il n'a jamais été question de la lâcher. Elle reste la version d'origine, celle que je fais tourner en premier, celle qui tranche. Mais depuis quelques semaines, le même jeu tourne aussi sur Megadrive et sur Amiga . Je le dis dans cet ordre à dessein, parce que l'ordre est la moitié de l'histoire : l'Atari n'est pas devenu une version parmi trois. Il est resté l'étalon. Ce qui tient chez lui tient partout ailleurs, et pas l'inverse. Pourquoi je n'y suis pas allé plus tôt Parce que c'est une idée qui rend les projets solo malades. Ajouter des machines quand le jeu n'est pas fini, c'est le meilleur moyen de ne finir aucune version. On passe son temps à refaire la même chose trois fois, chacune un peu moins bien, et le jeu n'avance plus. J'ai vu assez de projets mourir comme ça pour ne pas m'y jeter par enthousiasme. Ce qui a changé, c'est que le jeu a atteint un état où la question ne se posait plus dans ce sens. Il y a des années, quand je rangeais ce vieux moteur pour la dixième fois, j'avais séparé deux choses : d'un côté le jeu, ses monstres, sa peste, ses règles ; de l'autre la partie qui parle à la machine. À l'époque, c'était juste du rangement, et honnêtement je l'avais fait pour ma tranquillité, pas pour un plan grandiose. C'est ce rangement qui a rendu la suite possible. Le jour où j'ai voulu voir ce que le jeu donnerait ailleurs, je n'ai pas eu à le réécrire. J'ai eu à réapprendre à parler à une autre machine, ce qui est un travail énorme, mais qui ne touche pas au jeu. Ce que ça change pour vous Ça dépend entièrement de ce que vous avez gardé dans un carton. Si vous avez un Atari ST , rien ne change, sinon que vous avez maintenant de la compagnie. C'est toujours la version la plus avancée des trois, et c'est toujours celle qui reçoit les nouveautés en premier. Elle tourne sur STe comme sur STf, sur un Atari d'origine, et elle s'installe aussi sur disque dur. Si vous avez une Megadrive , vous n'aurez pas une conversion au rabais. J'ai posé une règle sur cette version-là et je m'y tiens : on ne porte pas le jeu, on l'améliore. Chaque étape se juge deux fois, est-ce fidèle au jeu, et est-ce le mieux que cette console sache faire. Refaire l'Atari trait pour trait reviendrait à payer ses contraintes sans encaisser ce que la Megadrive donne. Le premier gain se voit tout de suite : le décor n'est plus tenu aux seize couleurs de l'Atari. Même dessin, beaucoup plus riche. Si vous avez un Amiga , c'est le plus jeune des trois chantiers, et celui qui avance le plus vite en ce moment. La cible est l'A500 d'origine, celle que presque tout le monde avait, pas une machine gonflée. Un jeu qui ne tourne que sur une configuration rare ne sert à personne. Ce que ça ne change pas Le monde, l'histoire, les monstres et les règles sont les mêmes partout. La peste se propage de la même façon, la lanterne fait le même travail, le second joueur arrive de la même manière. Personne n'a une version amputée, et personne n'a une exclusivité. Et surtout : aucune version n'est bridée pour ressembler aux autres. C'était la tentation évidente, celle qui simplifie la vie, et c'est exactement celle qu'il fallait refuser. Une machine qui sait faire mieux doit faire mieux, même si sa voisine ne suit pas. Un joueur ne compare pas trois versions côte à côte, il joue sur la sienne. Où en est chaque version J'ai ajouté trois pages au site, une par machine, avec l'état réel de chacune : Atari ST , Megadrive , Amiga . Les barres d'avancement de la page d'accueil sont désormais séparées en trois séries, pour la même raison. Je préfère que l'écart entre les trois se voie plutôt que de laisser croire à une parité qui n'existe pas encore. Le devlog, lui, se filtre maintenant par machine. Les articles précédents parlent tous de l'Atari, c'est normal, c'est ce qui s'est passé. Les prochains diront à chaque fois de quelle machine ils parlent. Et la suite Elle ne change pas non plus. Je n'ai pas ajouté deux machines pour ralentir la première : les actes suivants restent le chantier principal, sur les trois à la fois. Une dernière chose, pour ceux qui suivent ce projet depuis le premier article. Il y a une ironie que je savoure : passer trente ans à défendre l'Atari contre l'Amiga dans les cours de récréation, et finir par écrire un jeu qui tourne sur les deux. Je n'ai pas changé de camp. J'ai juste fini par admettre que le camp d'en face avait une belle machine. ---