Why and how I am making a game for two very different platforms.

I've now started on my third e-reader development adventure. But I'm more jaded and experienced this time, so I'm doing things a bit differently. I am making my next gba/e-reader game for the PC as well. Here is why and a bit of the how.

E-Reader releases marred by manufacturing

I was very lucky with my first set of e-reader games, but at the time I didn't realize it. I managed to find a printer who could manufacture cards that were of good quality and more importantly, scanned very well in the e-reader.

The GBA e-reader reads dot strips that are printed on trading cards. The dot strip contains data in a similar fashion to QR codes. They are notoriously difficult to print such that the picky e-reader will properly ingest them. For more info on the e-reader, check out my post about making Solitaire for the e-reader.

Since these cards scanned so well, I thought I had solved the biggest challenge and eagerly moved onto creating my next e-reader game, Pixel Pup. We had completely finished the e-reader version and even had the cards manufactured just to cancel the release. The printer I was working with changed their equipment (both hardware and software), and no longer printed scannable cards. There's a lot more to this story, but that's the gist.

Pixel Pup e-reader cards that don't scan very well :(

Printing e-reader cards is very difficult. Printing them well enough to sell as a product is even harder. Printing companies aren't in the business to print such precise things. Why spend all this extra time and effort on a (very) small client, when their larger customers printing business cards, books, restaurant menus, whatever, don't have any of this fuss? I was lucky in that the printer I found before was willing to do some test runs and help with my unique needs ... up to a point. When they switched to a different printing press, they understandably didn't want to spend a lot of effort helping me get my cards printing properly on it. At this point I've reached out to about a dozen printers across the country and none of them wanted to take on my specific printing needs. I don't blame them at all, it's a perfectly reasonable stance to take.

We instead released Pixel Pup as a standard GBA game and I'm unsure what to do going forward with new e-reader games.

But, I really like the e-reader. I still want to make a game for it that takes advantage of this unique device in ways Nintendo never did.

Hedging my bets

I decided to finally embark on creating that ambitious game for the e-reader despite these problems. In parallel I will keep exploring ways to manufacture the cards. Hopefully as the game is wrapping up, I will have found a good way to manufacture the cards. But I might not. And to be totally honest, I probably won't.

The game is called Eridin. It's a fantasy turned based strategy game with a few twists. Here's some very early mock ups and screenshots. These will change a lot as development progresses...

Early screenshots/mock ups of Eridin. (The last screenshot is not accurate, the e-reader integration will be quite different. I made that one when I was first brainstorming the game)

I decided to make this game both as a GBA/e-reader game, and a PC game. Worst case scenario, I just release the PC version. I needed to find a good balancing point for a game that can be both an e-reader game and PC game at the same time. In other words, if the PC version "scanned cards" for no other reason than that's what the e-reader version does, that'd come off as gimmicky and tedious (and rightly so). I think I have found a good way to balance the two, which I'll talk about more as the game progresses.

It's also possible to release the e-reader cards digitally. There are a few ways to do this that I'm also considering. The most interesting way is using the upcoming GB-Link. At this point, I'm unsure if I will actually do any of this, but it's interesting to think about.

Writing one game for two very different platforms

To pull this off, I am writing the game in C using DevKitPro and libtonc for the GBA side (just like I did with Pixel Pup), and SDL2 on the PC side.

I started by extracting the engine I had developed for Pixel Pup and building an API layer out of it. This layer is actually inspired by the e-reader itself, which has an API built into it for games. For example, to load sprites I have the API defined in a sprites.h header file, here's a simple example usage.

#include "sprites.h"
static const struct SpriteDef mySpriteDef = { ... };
...
int spriteHandle = sprites_load(&mySpriteDef);
sprites_pos(spriteHandle, 10, 20);
...

Then for implementation I have both sprites.gba.c and sprites.sdl.c.

// sprites.gba.c
int sprites_load(const struct SpriteDef *def) {
    struct LogicalSprite *ls = getfreeLogicalSprite();
    loadTilesIntoVram(def, ls);
    loadPalette(def, ls);
    setupOAMEntries(def, ls);
    return ls->handle;
}
// sprites.sdl.c
int sprites_load(const struct SpriteDef *def) {
    struct SDLSprite *sp = sprites[spriteCount++];
    sp->texture = IMG_LoadTexture(renderer, def->file);
    return sp->handle;
}

The above code snippets are not actual code and simplified, but you get the idea.

Each platform's Makefile pulls in all common files, and the platform specific files. I worked to minimize how often I need specific platform implementations. Once I had the basics like sprites, backgrounds, fonts and audio in place, I found the vast majority of the engine is platform agnostic. So far the game itself has some platform specific files, but overall they are quite rare. Granted it's early in development, this may change :)

Keeping the overall GBA aesthetic

The PC version will still be 240x160, the GBA's resolution. It does scale that resolution up quite a bit so it's not a tiny postage stamp on modern displays. The PC version will mostly "feel" like a GBA game, similar to the recently released Pipistrello and the Cursed Yoyo, which is also a modern game with a GBA aesthetic.

But the PC version will have more quality of life improvements, graphical flourishes and will be the more pleasant version overall. It reminds me of modern first person shooters that take their inspiration from classic Doom/Heretic/etc, like REKKR. REKKR is much more modern than classic Doom, it's more like it's using modern advancements to recreate our rose tinted memories of classic Doom instead of exactly how it was 30+ years ago.

To give a simple example, the PC version uses subpixels to smooth out scrolling graphics.

The GBA version scrolls the map in a very clunky fashion, while the PC is much more smooth.

This is possible because the PC version renders at a much higher resolution (1200x800 in this video, but the scaling factor can be changed), and so uses "subpixels" to position things. It is also not capped at 60 frames per second like the GBA version is. The PC version can render at any frame rate the machine is capable of, which also leads to smoother animations and just makes the game "feel" better. I might blog about this frame rate difference in the future, as it's the biggest difference between the platforms and I'm really happy how well I was able to hide this difference away from day to day dev work.

Conclusion

If you read this far, thanks! I'm going to keep plugging away at Eridin. I post updates about it over at Bluesky if you're interested.