When you’re creating a game, you obviously are going to test it, to look for bugs, see if mechanics work out and how the game feels.

If you’re using GB Studio, you’ll most likely use the built-in emulator the most for that purpose. That’s a good start, but only scratches the surface.

Depending on the game you’re creating, it is very important to test it on as many devices, systems and emulators as possible, because there are more obstacles to tackle than “it just doesn’t run.” 

Even if you build and design your game with emulation on computer displays specifically in mind, players may download your rom file to play and experience it on their hardware, be it the original Game Boy with the help of flash cartridges, modern retro handhelds, or other consoles.

No matter what you do, you can’t please every player and making the game perfect for every device and edge case would be a never ending money and time sink, but it’s a good start toward making your game work for as many devices possible, or at least being aware of the situations where your game doesn’t live up to its full potential due to its limitations.

In this article I’ll cover why it makes sense to test your game on multiple devices or emulators, and point out the problems you might consider addressing or keeping in mind.

Screen Sizes

You’ll most likely use some sort of computer/laptop to develop your game (if not, let us know, because that sounds wild and we’re interested to hear about it). The screen you’re using and the emulator window popping up to test your game will in most situations already be larger than the original hardware screen. 

You have to keep that fact in mind when creating the pixel art for your game. The limitations of the Game Boy are already pretty steep, but if you’re designing sprites that are barely identifiable on the bigger screen, then players will have a harder time on their original hardware. 

Colors

This topic should be taken care of outside of the spectrum of testing on multiple devices, as strong contrasts in general are better to see, especially for people with color blindness or other disabilities that makes it hard to differentiate certain colors. 

But the same principle applies when having different devices in mind. For example, if you’re building a game with fast paced movements and you designed the levels with very detailed pixel art and less contrast in it, movements will start to blur, which makes it hard to see oncoming obstacles or enemies on an original Game Boy. This blurriness is less noticeable or completely invisible on newer devices with modern IPS screens.

Input Lag

Game Boy games are known to be a bit slower paced. Mario games, the prime example of a typical Nintendo platformer, have slow-walking acceleration, and often feel like running on ice. Even if you’re at full speed, it’s not that fast compared to modern platformer titles on other consoles or PC. Still, precise input is required to let Mario land where you want him to land. 

Input lag in games where precise input is needed to succeed can be very frustrating when played on the wrong setup. On original hardware, input lag isn’t a problem to worry about. Most of the time input lag is introduced through less-than-ideal emulation or the machine running the emulator isn’t powerful enough for it to run smoothly. 

I’m currently creating an action platformer with very high movement speeds for the Game Boy, which requires precise and quick input. On original hardware the input is flawless. On my laptop through the GB Studio emulator, the input is okayish, depending on what is running simultaneously in the background. But in my playtests with other people I found out that input lag can also be introduced through things like wireless keyboards or controllers! 

All playtesters who had wireless keyboards for their computers (where they were testing the game through emulation, just like on itch.io) got back to me and said that the input felt a bit off and they had a hard (and maybe frustrating) time playing my game because of that.

Only when I asked them to use a wired keyboard or another method like playing on original hardware was the problem fixed, and playtesters felt significant differences in input lag.

These are things to have in mind when you plan to bring such a game to platforms like Steam, where users will experience the game through an emulation wrapper, and many players own wireless keyboards and controllers that will introduce input lag.

Imprecise Input

Another thing to consider is how well can your game be played on devices that are controlled via touchscreen? 

The standard web export on GB Studio offers the game wrapped in an emulator, served to be played via web, either with a keyboard or via touch controls on devices like smartphones.

If you’re uploading your game on platforms like itch.io to be played there, then this is one of the first ways players will be introduced to your game.

Playing a game like Super Mario Land would already be a challenge with touch controls, where your fingers can’t feel if they’re touching the right button, or any buttons at all. Now imagine having to play a fast-paced action platformer with very precise inputs and one-hit-kill mechanics. This is where frustration will be born! 

Multi Input

An emulator on the computer offers another thing, that, if not kept in mind, could cause game-breaking bugs or mechanics: that you can press multiple keys at the same time. 

If you’re building a mechanic that is being performed by pressing Up and Down simultaneously, then it could work on your computer, maybe even on touch screen devices, but it will not be possible on original hardware, because of the way the input is built on the Game Boy. 

I know that this information is a bit of a “duh?” moment, since everyone who grew up with or owned a Game Boy knows this. But there are also plenty of younger developers who were never lucky enough to get their hands on an actual Game Boy DMG-01, and that’s why I think this is a good thing to know, as you could in fact make a mechanic like “Pressing Up and Down at the same time”.

Computing Power & Emulation

While modern devices like smartphones or the Analogue Pocket surely have enough computing power to handle a heavy Game Boy game, there can be certain mechanics, scripts, and other aspects in the game that can bring even those powerful devices to their knees. 

A poorly made emulator can have a slowdown while walking through a busy part of your game handling multiple actors and effects. Or a kernel panic error could occur on the Analogue Pocket where it would be running safely on your original Game Boy.

So testing on multiple devices and emulators is a good idea to check if your game could have issues in certain situations.

What can you test on easily?

I know not everyone can just buy a handful of different retro handhelds, original Game Boy (Colors), and other devices & systems that possibly can run Game Boy games.

But you probably can test on:

• the built-in GB Studio emulator
• the web export version of GB Studio on your computer (keyboard, controller)
• the web export version on your smartphone (touchscreen testing)

You can also always ask the community discord for people to test your game on different devices that you don’t have. It should at least be tested on:

• Original Game Boy
• Original Game Boy Color
• Analogue Pocket
• Super Game Boy (SNES)
• Some retro handheld devices (Anbernic, Powkiddy, Retroid, you name it)