These past two years, I've been working off and on to create a game for Amiga, a home computer first released in 1985.
This post is a general overview of the project. In future posts, I will dive into the details of the design, code, game engine, and more.
The game is titled Magicore Anomala. It's a bullet hell game that is somewhat reminiscent of Touhou, Mega Man, and IWBTG fangames.
Thanks to the Amiga's incredible design, it's possible to draw hundreds of bullets while maintaining a full 60 frames per second—despite running on 1985 hardware.
It's been a lifelong dream of mine to make an Amiga game. My family's first computer was an Amiga, and I've been in love with retro hardware for as long as I can remember.
I want to share my passion by making a game for this system that looks, feels, and plays like a modern indie game—something that brings lasting enjoyment and is more than just a curiosity for most.
Magicore was conceptualized specifically to leverage Amiga's unique hardware capabilities, so the platform and the game's design go hand in hand. I love that sort of thing, allowing limitations to breed creativity.
Amiga is powered by a 7MHz Motorola 68000. It's the same CPU found in Macintosh, Sega Genesis, and many other systems of the time. It has 512kb onboard RAM, and usually at least 512kb of expansion RAM.
The normalcy of Amiga ends there, because everything else about the hardware is pretty ludicrous for the time period. It has full bitmap graphics (no tile or text modes at all, in fact) with a maximum color range of 4,096 colors. As for audio, you get 4-channel PCM—it has full digital audio playback.
If that wasn't enough, Amiga famously has a set of coprocessors that effectively run in parallel with the CPU. Most notable is the blitter, which can be thought of as a GPU that excels at copying, shifting, and masking blocks of memory. (Yes, we're using the blitter to draw all those bullets!)
Early Macintosh computers famously have a 1-bit display—each pixel can either be
on or off. Amiga is similar, except you can stack up to 5 of these displays on
top of each other. This means each pixel is a "stack" of 5 bits, and together,
those bits determine which color to draw. For example, a stack of bits
corresponds to color slot 22. (We get to pick what color goes into each slot.)
These 5 "screens" (bitplanes) are completely independent of each other and can each be anywhere in memory. We can update any of the screen locations any time we wish. This is very cool, and it lets you do some wild things.
Magicore is possible because the bullets layer is a single bitplane, meaning each pixel is only 1 bit. Using the blitter, we can clear and redraw this layer every frame, without having to touch the background.
At a resolution of 320x200, one bitplane is 8kb in size. For the blitter, that's child's play.
I mentioned that Magicore was inspired by the Amiga's capabilities—that may make more sense now. If I was going to make an Amiga game, I wanted it to do something special with Amiga's graphics hardware, to take advantage of its unique design in some way. Rather than try to mimic full-color "chunky" pixels, how can I take advantage of this bitplanes system? Bullet hell was the answer!
It is an absolute blessing that we can use modern tools to develop software for retro systems.
There is an Amiga Assembly extension for VS Code, which makes it very easy to build and even debug Amiga software right in the editor. I do most of my coding in Neovim with the m68k LSP, but I hop over to VS Code when I need to debug.
(Update: I've since managed to get a debugger set up in Neovim thanks to the UAE DAP, so VS Code isn't being used much anymore.)
The entire game is written in Assembly language. Amazingly, C is a first-class citizen on Amiga (even the OS was written in C), but Assembly is definitely the way to go for a game that demands high performance at almost all times.
Meanwhile, the tooling for building the game data and level files is written in Python. It's built around Simple Binary Builder, a framework that lets you easily define and assemble custom binary file formats. It was originally an internal tool, but I put some extra work into it so that I could open-source it. Find it here.
Again, thanks to these modern tools, it takes less than 1 second to go from hitting "build" to having the emulator start up. This enables some very rapid design and testing.
I expect Magicore to be in development for another 2 years or so. During this time, I hope to write some more posts that go into greater detail on specific aspects of the game engine, or problems I've had to solve.
Thanks for your interest in this passion project of mine!