Self-Imposed Restrictions: Examining the GBA and SNES

Since I finished the last blog post, two weeks have passed, mostly because there was no clear direction to go next, and there were other matters taking up my free time. Also procrastination.

Anyway, in my post on save game serialization I said that the game I want to build would be to 16 bit RPGs as Shovel Knight was to 8 bit platformers. The Shovel Knight devs went to great lengths adhering to technical limitations imposed by the NES, breaking the rules only where both justifiable and necessary. Programmer David D'Angelo outlined this in a fascinating Gamasutra post. A style guide for Steel Assault imposes similar restrictions.

So, since all the topics I wanted to tackle, but couldn't decide on, should adhere to similar restrictions, the goal of this post is to find a suitable rule set based on the SNES, home to classical RPGs, and the technically similar GBA, home to most games of my childhood.

Input

One thing I wanted to write about from the very beginning is an input system; reconfigurable controls, game pad/keyboard support, the whole shebang. Funnily, input isn't mentioned in either of the rule sets I linked, but the Shovel Knight one touches on the implications for level design some of the graphical limitations had. I think something similar should apply here:
the SNES had six face buttons (A, B, X, Y, Start, Select), an 8-way D-pad, and two shoulder buttons (L and R). Compare that to an XInput controller, which adds six analogue input axes (two thumb sticks and two shoulder triggers) or a modern keyboard's ~100 digital keys. Obviously not all of these are used, but think of games like League of Legends, Starcraft or even Dragon Age. These require a mouse in one hand and the keyboard with dozens of short cuts in the other. There is basically no way to figure the controls out as you go in these games.

Granted, these are complex games, and you don't need all those short cuts, but it's more intimidating and complex than it needs to be, for this game at least.
We will ban mouse input, and limit the keyboard to 12 freely remappable keys, with sensible defaults.
Controllers will also not be utilized fully: Analogue inputs are forbidden, except for the left thumb stick, which will be truncated to function as a D-pad.

Graphics

This is the main factor in simulating the look-and-feel of a SNES or GBA game. Both systems have comparable graphical capabilities, which is why so many games for the former were remade for the latter. For starters, we will cherry pick the best of both, and see if we need to add more loop holes during development.

For one, the two share the same color space. Both use 5-bit-per-channel RGB colors in palettes of 16 colors. I've read claims that the sixteenth bit in a color determines its transparency, but I've never actually seen it used. The first color in a palette is transparent for backgrounds and sprites alike (except for the back-most layer), giving us 15 colors per sprite or background tile.
The SNES had a total of sixteen palettes available, the GBA had 32. Both assigned one half to backgrounds and the other half to sprites. We will enforce no hard limit on the total number of palettes. Certainly not for sprites. But considering that UI and other overlays also require some palettes, there won't be a limit for backgrounds either. There will be a limit for the actual tile sets, however. Instead of limiting ourselves to exactly one set of fifteen colors per 8x8 cell, we will limit the total number of colors in a tile set to 128, including transparency.

Speaking of background layers, the SNES has two while the GBA has four. We will ramp that up to eight layers. These are larger than the screen and can be scrolled freely, allowing smooth-scrolling maps and parallax effects.
The available blending options differed a lot more wildly: The GBA had alpha blending with arbitrary five bit coefficients, with one bit unused, giving us lots of options, most importantly semi-transparent and additive blending with 16 different opacities. The SNES did not have modifiable coefficients, offering four blend modes instead: adding, adding and halving (i.e. averaging, effectively 50% transparency), subtracting, and subtracting and halving, which went mostly unused because the results are extremely dark.
If we pretend the fifth bit of the coefficient was a sign, we can have subtractive blending with 16 different opacities as well.

Then there's sprites. Both consoles only have one continuous section of Object Attribute Memory, where the order determines how sprites should overlap, and blending generally considers all sprites as one layer. However, on the GBA at least, each object can set between which layers it appears.
This behaviour can lead to some visual glitches and is actually pretty hard to simulate with modern rendering techniques, so we will have eight separate sprite layers, one in front of each background layer. There will be no hard limit on the total number of sprites.
Sprites could be scaled and rotated freely, with nearest neighbour sampling.

As for the screen size itself, we will use a virtual 320x180 display, for various reasons: Shovel Knight carried over the height of the NES's resolution and expanded horizontally to accommodate modern displays. They decided on that because of the way gravity works. In a top down RPG, there is no gravity as such, so the screen height in tiles becomes less important to gameplay.
Instead, the total number of visible tiles becomes more important to replicate the same sense of scale as RPGs on the SNES. I arrived at 320x180 by calculating the 16:9 resolution that comes closest to the total number of pixels of the SNES resolution.
It has some other nice properties, such as scaling perfectly to 360p, 720p, 1080p and 4K displays.

Finally, perhaps the most iconic SNES feature is graphics mode 7. Contemporary RPGs commonly used it for the world map, showing off features in the distance, impressing you with the vastness of the world. Chrono Trigger used it in the racing minigame, to much of the same effect: you get an idea how much distance you cover. It also looked pretty cool. Personally, I'd use it to juice up combat a bit.
The GBA had it as well, although it was used more rarely and perceived as less exciting. The point is to transform the background in 3D space. I'm not sure where to use it, if at all, but if I do, it'll be as follows: The ground will be a single 256 color texture, and sprites can be used freely.

There's some other visual effects that had native support, such as mosaic filtering on background layers, as well as fade to black or white. Since there's central palette memory, you could feasibly manipulate the coloring of the scenery, as some talented ROM hackers did to add a day/night cycle to the Pokémon games on the GBA.
I will definitely discuss color manipulation in a later post, but every other effect will be decided on on a case by case basis.

Sound

I won't say too much at this moment, because I know little about audio programming and less about music theory. I know these consoles have similar audio capabilities, with a certain limit on how many sound effects may be playing at the same time, how many sounds a song may simultaneously use, and a maximum sample rate on all sounds.

We will not enforce any limit on the number of sounds playing at the same time, and probably allow any and all music that can be rendered with a MIDI file and a sound font. Sample rate limitations will be considered at a later time.

Where to go from here

Okay, with these rules in mind, how should we proceed from here? I already mentioned that I wanted to write about the Input system for a while, and with what I wrote here, I think I can wrap that up in a single post, so that's next.
The other topics I wanted to tackle are the tile map rendering system, which obviously depended somewhat on the graphical limitations I put in place here, and prototyping a combat system.
We will do tile maps first, because the combat system should be seen in context of a narrative-driven RPG, so we should at least have a map to explore and enter multiple fights from there.

If you are interested in the technical specification of the Gameboy Advance, you might want to take a look at GBATEK, which also discusses the Nintendo DS. I haven't found an equivalent document describing the SNES, but I admittedly never looked particularly hard.