The confession

A few days ago I played Lore of the Ember and had to admit something: yet another platform game on the Atari ST, however well made, stands very little chance of being memorable. The homebrew scene has produced plenty of them, and retro players know them by heart. Having a smooth engine at 50 frames per second isn't enough to leave a mark, because the engine is only the vehicle.

It needed a strong central mechanic, something rarely seen on the machine and, above all, something people enjoy.

The realisation

A game in the vein of Chaos Engine. I loved the Bitmap Brothers games and that one is among them. But the STe constraint is simple: displaying lots of independent characters is expensive. Even with every trick in the book, beyond twenty or so animated sprites with their own logic, the machine collapses. If I wanted the "overwhelming horde" feel of a Chaos Engine, I had to be cunning.

The answer: the main threat isn't made of sprites, but of the ground itself becoming corrupted.

In Lore of the Ember, the Black Plague of 1347 is no longer narrative set dressing. It's the gameplay. It spreads across the flagstones of the cemetery, the rampart, the dungeon, tile after tile, tick after tick. The player, Alaric, fights it with the flame of his lantern, which burns the contaminated tiles and protects them for a while.

The reference came immediately: Firemen (Human Entertainment, SNES, 1994), that forgotten game where fire spreads across the map while the player tries to put it out. Dynamic terrain, constant pressure, instant readability. Exactly what a homebrew that wants to be remembered needs.

The game idea

A fixed arena, a grid of tiles, no scrolling. Every tile has a state: healthy, infected, in the middle of turning, or recently cleaned. The plague starts from an outbreak and eats away at its neighbours. The player hoses it down, and the tiles hit go back to clean.

I wanted the whole thing light and quick on its feet, so two design principles guided the prototype. First, the plague only spreads along its front: there is no point dealing with the heart of an area that is already fully infected, only the border can still bite. Second, on screen, I only redraw what changes, never the whole arena. At cruising speed that comes down to the handful of tiles on the front and the player. As a result the effort is proportional to the action on screen, not to the size of the terrain, and the machine stays calm.

What gives the player leverage

My very first prototype had no immunity. The player would clean an area, and a second later the plague came back as if nothing had happened. Frustrating, pointless: the feeling that "shooting achieves nothing" killed the game in thirty seconds.

The fix changed everything: a cleaned tile stays healthy for a few seconds before becoming vulnerable again. During that reprieve it's displayed differently and refuses to be re-infected. Suddenly the player can carve out a genuinely safe corridor, catch their breath in it for two or three seconds, move forward, then draw it again further on. Shooting has weight, and that is where the game became interesting.

The bugs I had to hunt down to get here

No prototype comes out right on the first pass, and this one took a fair bit of debugging. Three memories are worth the detour.

The first: a clean crash, black screen immediately, before anything was even displayed. The keyboard reading routine left the stack unbalanced, and the program returned into the void. A rookie mistake!

The second, the most instructive: my arrow keys weren't responding. I spent an age suspecting key decoding, fiddling with the keyboard reading, adding visual indicators to work out what was happening. The cause was daft: the emulator was sending my arrows as joystick input, not as keys, and I was watching the wrong thing. Above all, the project already had an input handling block that had been proven for weeks. I should have started from there.

The lesson is engraved now: when a piece already works in the project, I start from it before inventing something else.

The result

The prototype fits on a single screen, without a single complex sprite, without a line of story, just the bare mechanic. And the three questions that mattered at this stage all got a clear "yes" in testing: do you feel the tension, is clearing an area satisfying, do you want to play again? If the bare mechanic is already good, the story and the pixel art will carry the game much further.

What comes next

The sprite engine and the parallax validated earlier are not thrown away: they will come back as presentation layers. The lantern will animate above the protected tiles. Each act's bosses (the Ashen Wolf, the Lady in Black) will be the handful of complex sprites the machine's budget allows, placed on the grid breathing in the background. The gothic scenery of the story will become the arena dressing depending on the act.

Next step: place a first boss on the corruption grid and start tying the gameplay to the lore. Act I, "The Forest of the Hanged", is the natural test ground, and the Ashen Wolf will be the first mobile sower of plague.

The prototype is downloadable here (historical archive). Run it in Hatari, arrows to move, fire button to clean, 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.