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.

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.

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.

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 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.

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 ;)

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.

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.

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.

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.

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.

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 ;)

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.

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 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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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 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 .SND next to the binary. For the current version of the game, see the homepage.

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.

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:

1. 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.
2. 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.
3. 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.

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 .prg and the music file LEVEL1.SND). Unzip everything into the same folder and run morteveille.prg in Hatari in STe mode with 1 MB. Arrows to move, fire to clean the plague, P to pause, Esc to quit.

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 .prg is available for download. Arrows to move, fire for the lantern, P to pause, Esc to quit. Test the scroll in the boss room, that is the area where the optimisation shows best.

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, R to restart, Esc 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.

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, R to restart and Esc 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.

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.

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.

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.

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.

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.

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.

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.