The Game That Didn’t Need Fixing

At Moonstone Tavern, we’ve been Moonstone fans for so long that even its quirks and rough edges never stopped us from loving it. The intro you’ve seen 500 times you can barely skip. The floppy-disk swapping, the regular crashes, the graphics that show their age… We accepted it all, and we never thought anyone needed to fix this game.

Instead, the question was: why did we never get an AGA version?

Moonstone arrived in April 1991 while the first AGA Amigas followed in October 1992. That left an irresistible idea: what might the game have looked and sounded like if Rob Anderson crafted it for the A1200 with the same passion and care?

For years, it was just a thought. But recently, we finally had the opportunity to explore this further, making tools and investigating the original 68000 assembly code. 35 years of patience and wondering finally resolved as… Moonstone AGA.

Keep the game, bring more colours.

We started with one rule: the gameplay should feel authentic and not betray Moonstone fans.

The playfield, movement, combat pace, collisions, enemy behaviour, and animation timing make this game so special. Change them casually, and you will produce something possibly attractive, but it won’t play like Moonstone anymore. So the aim is to keep the original game logic while adding enhancements that elevate it.

That doesn’t mean keeping all the bugs, even though we remember thinking that the guru meditation after clicking, or passing over the moonstone prop in the inventory, wasn’t an unfortunate bug; it was just another way to die in Moonstone. That said, saving and resuming a game matters. Fixing a demonstrated bug matters. But those changes must be understood and tested; they shouldn’t alter the fights.

The technical starting point was unusual. Rob Anderson wrote the original game entirely in 68000 assembly and worked within the Amiga 500’s severe memory limits. So we began examining the original disk images and game files, identifying the graphics and animation formats, and tracing how the program uses them. One funny anecdote: Rob Anderson is a trained animator, and he called his graphic file format .cel, the name traditional animators use for the transparent sheet, or celluloid, on which they paint characters and other moving elements.

Making 320 × 200 pixels count

The game’s display is just 320 by 200 pixels. You cannot simply paint a detailed modern image, shrink it, and call the result pixel art. Fine details merge, edges soften, and the image loses the deliberate contrast that makes great pixel art readable.

The first Metal Slug is a personal reference for us: its silhouettes, small clusters of pixels and carefully placed highlights still look extraordinary. We don’t have an arcade studio’s art team, so the challenge was to find a practical workflow that respects those qualities.

We work on concepts at a higher resolution, then bring them into our editor. There we can choose the framing and convert them to the game’s native size using cluster sampling and Floyd–Steinberg dithering. Those methods help retain strong shapes and local contrast. Then comes the essential part: reviewing the 320 × 200 result, checking it in motion, and manually correcting anything that has turned into visual mush.

Colour is another constraint. An AGA screen may offer 256 palette entries, but the background cannot take them all. Knights, monsters, effects, text and interface elements need colours too. The editor assigns each asset a specific budget so a beautiful background doesn’t leave the characters with nowhere to go.

Some original environments were assembled from reusable chunks of trees, roots, stones, and chests to save disk space.

For AGA scenes, we can afford a much larger file size, so we use a fully painted background instead. It still has to match the original layout, because the artwork must sit behind the same game: the same actors, positions and collision rules.

The switch we wanted for ourselves

While working on the new graphics, we kept wondering whether other fans would want to see Moonstone this way at all. We certainly did, but we also understand if you prefer the original.

That doubt led to one of our favourite features: switching between the original OCS presentation and the enhanced AGA on the fly. You can compare the two views at any point, with the game continuing underneath. The graphics and audio change while the combat continues.

It is fun to use, but it also explains the whole project better than a page of promises. One button shows where Moonstone came from and the AGA path we are exploring.

There is much more to tell from rebuilding character artwork across animation poses to making the intro scroll smoothly, managing memory, and testing the result on an A1200 configuration. We’ll take those one subject at a time in the next dev diaries.

For now, that is the idea behind Moonstone AGA:

It is our beloved game, seen through maxed-out AGA capacities.