Everyone has childhood dreams. Mine was to make a game for my first console: the Nintendo Game Boy. Today, I fulfilled this dream, by releasing my first Game Boy game on a actual cartridge: Sheep It Up!

In this article, I'll present the tools I used, and some pitfalls a newcomer like me had to overcome to make this project a reality! Due to it's length, this article will be split in two parts:

The game

"Sheep It Up!" is an arcade game where a sheep has to climb up by hanging himself to flying velcro straps. The concept is simple, but the game rapidly gets quite challenging: how high can you climb without falling down?

As a game collector myself, I wanted this game to be produced without sacrificing any vintage Game Boy titles. So everything is manufactured specifically for this game: the pcb, the rom, the shell, the protective case and even the sticker! We also tried to keep the price reasonable, so everyone can enjoy the game: $15 (+shipping). It will run on any Game Boy model, from the first one to the GBA SP, including the Super Game Boy.

If you still own a Game Boy, you can buy a cartridge on the publisher website:

https://catskullgames.com/sheep-it-up

The tools : thanks 2017!

In the 90's, creating game for a 8-bit game console was a real challenge, and required a team of highly trained professionals. Designers, artists and developers from this era are real heroes to me: to be able to produce such wonderful games with the limited tools they had compared the ones we have today.

In 2017, it's still a lot of work to make a game for a 8-bit console. But, thanks to the wonderful homebrew communities, we now have a lot of tools to make our life easier! Without them, an hobbyist like me could never be able create a Game Boy game on his own. So, what are those tools?

For starter, the programming language. Back in the day, all dedicated gaming hardware was programmed in Assembly. It's still possible (and even recommended) to use Assembly today. But it's no longer the only option, as many devkits for 8-bits and 16-bits consoles are based on the C programming language. For the Game Boy, this awesome tool is called Game Boy Developers Kit (GBDK).

Then, to make art and level design, you no longer need to use graph paper and a hand scanner. Hopefully, you can now use two complementary piece of software:

Last but not least, we also need a way to test our game. This is where modernity is key. While in the 90's developers had to use expensive ICE boxes, today we have powerful software emulators that can run on any computer. To test your own game, the best choice is BGB. It's a very accurate Game Boy emulator that comes with a powerful debugger, the one tool you'll need to create a working game!

The game is in top-right corner, all the other scary windows are the various debugger tools!

But to be really sure your game is working, you will also need to test it on real hardware. In the 90's, people were burning their program on a EPROM chip, and used some special cartridges to plug this chip into an actual Game Boy. While efficient, it was quite a lengthy and expensive process. Today, we have what are called "Flashcarts": cartridges where you can plug a SD card with your game ROM to play it on an actual Game Boy. The idea is the same, but the tools are more easily accessible and faster to use. Several Game Boy Flashcarts exists, but the best one is arguably the one built by Krikzz: The Everdrive Game Boy. A newer and improved model was released this summer, but I used the old version that I bought some time ago.

   
A flashcart from the 90's vs one from the 2010's

Despite these great tools available in 2017, making a game today for a 1989 game console is still a challenge. Especially for people who have been trained to use "modern tools", such as Unity, Unreal Engine or Godot. Here are the main challenges I faced during the development of Sheep It Up!, including the things that surprised me about how a Game Boy is actually working.

Technical challenges

Size limitation

Let's start with the obvious one: Sheep It Up! is a rather simple game. One factor that explains this fact is that the whole game weights only 32KB. Yup, the code, the images, and even the sounds are all fitting in a tiny 32KB space. To give you a point of comparison, 32KB is the size of the Wikipedia logo in a very tiny resolution:

                    
           Full Game: 32KB                            160x146px (PNG-24): 32KB 

Of course, not every Game Boy game fits in 32KB. For me, it was a technical limitation to be able to release the game on an actual cartridge (more details in part 2). The best and most famous Game Boy titles are actually way larger than that :

In reality, few Game Boy titles are only 32KB. Most of them are from the early life of the console. For example, both Alleyway (one of the Game Boy launch title in Japan) and Tetris (launch title in US and Europe) are 32KB games. These are both excellent titles, but due to their tiny cartridge space, they are also somewhat "limited" in scope: single screen, few different graphical and audio assets, etc.

      
Alleyway and Tetris are 32KB games, like Sheep It Up!

CPU: playing with Portable Power!

The Game Boy is powered by a 4MHz CPU, custom built for the console (it's a mix between Zilog's Z80 and Intel's 8080 processors). All in all, Gameboy processing power is comparable to a NES, and even a bit more powerful due the reduced screen size and colors to display (more on that latter). Despite a mere 4Mhz speed, all the Game Boy games are displayed in constant 60fps. Take that PS4 Pro and Xbox One X!

But, for a programmer fresh out of college, the biggest constraints will be that it's a 8-bits processor. As you may know, internally all the computers are using 0 and 1 to process data. A single digit, which can have either 0 or 1 as value, is called a "bit" (short for "binary digit", as it can only have two different values). A processor is defined as "8-bits" if it can process 8 bits of data in a single operation.

How does it affect the making of video games?

Well, the less "bits" the CPU can process, the more limited will your gameplay variables be. For example, in games we use a lot of integers numbers to represent values: life, speed, score, etc.

With 8 bits of data, an integer can store smaller numbers than a 16 bits variable :

If that's still obscure for you, let's take a concrete example from Sheet It Up!

As you can see in this picture, the score variable has 5 digits, and can range from 0 to 99999. Sadly, it's way larger than what a 8 bits integer variable can store. I mean, even a 16 bits integer variable isn't enough to hold such a "large" score!

So, in order to be able to track score in Sheep It Up!, I had to use not one, but five different 8 bits integer variables to store the player score. I let you guess how "fun" it was to handle all these variables, especially when I added the ability to keep a high score, thus I had to compare two values stored across 5 different variables. Programming on a 8 bits system will force you to come up with complex solutions like that all the time, while modern systems will simply use 32 bits or 64 bits variables and never pose such a problem to their programmers.

(N.B. for experienced game developers: I know that I could have been more efficient than using a whole int8 to store a single digit ranging from 0 to 9. But I actually needed each variable to be able to go from 0 to 255, as in reality I don't store the score digit directly, but the tile id used to display this number on the screen)

Art challenges

One world, two planes

Any image displayed on the Game Boy is composed of two elements: a background layer (BKG) and several moving objects, also called sprites (OBJ). You are limited to a maximum on 40 sprites onscreen, with the additional limitation that the Game Boy can't display more than 10 sprites on the same line.

              Background (BKG)                                      Sprites (OBJ)

In reality, it's a bit more complex than that, as there is an additional "window" layer than can scroll differently from the background. It's usually used to make the user interface (score, etc.).  But this layer is "non-transparent": it will hide any graphical data on the background layer behind it. So, for the sake of simplicity, you can consider that you have a single "background" layer on a Game Boy, but that you can make part of it scrolling independently if you need to.

Game Boy sees 4 colors!

Let's introduce the elephant in the room: the original Game Boy model can only display 4 different colors.

One can argue that it's not really Light Grey and Dark Grey, but rather Light Green and Dark Green, but that's not the point: you can only use 4 colors to draw our art. At least, as long as you are drawing the background, because the case is different with sprites!

Indeed, as you can see in this picture, the Sheep is drawn with 3 colors only. Why is that? Actually, I drew the sprite with 4 colors. But the 4th color, here "Black", is simply not displayed because it's used as "transparent color" by the Game Boy. That way, the sprites are not all "square images", but they can be a wide variety of shapes allowing to see the background image behind them.

Does it mean that I cannot use black to draw sprites?

Of course not, as you can see below with the "velcro" strap sprite. For this sprite, I actually used a different palette of 3+1 colors: "White" is used as transparent color, and "Black" is displayed on the sprite.

Fun with palettes

Despite being limited to 4 colors only, the Game Boy actually uses 3 different palettes to display images, and that's very cool!

As you can see, there is a single "4 colors" palette for the background layer, and two "3 colors + 1 transparent color" palettes that the sprites can use (each sprite can use one palette or the other). The cool thing about these palettes is that you can freely assign any color you want to any palette slot. This allow you to make some nice effects, such as the fade-in / fade-out seen in many games.

To make a fade-in on a Game Boy, you simply need modify the colors on the 3 palettes. In the first step, all the palette slots are filled with white color. Then, in Step 2, the darkest color slot (black) is filled with light gray, to progressively reveal the image. In Step 3, Light Gray becomes Dark Gray, and so on, until the 4 colors are displayed on each palette.

Using a similar method, we can also make a character "blink", by switching the colors on its palette every frame. For example, this method is used when Mario catch a star and become invincible in Super Mario Land.

Tiling the world!

There is one last oddity in the way a Game Boy display images, at least for a game developer trained on current-gen engines. As the console doesn't have a "frame buffer", you can't specify the color of each pixel on screen individually. Indeed, all the on-screen images are built by assembling loads of "tiles", i.e. 8x8 pixels squares. This is applicable for both background and sprites :

This technique, designed to reduce the amount of video RAM needed to display images, implies that you can't draw freehand lines on the Game Boy screen. But it's also one of the secret that makes the Game Boy able to display such beautiful games with a mere 4Mhz CPU and only 8KB of video RAM (yes, I wrote kilobytes and not megabytes or gigabytes).

However, one of the drawback of this tile-based display is that our "sheep" and "velcro" sprites are actually made of more than one sprite. The Sheep is 16x16 pixels, so in theory it would need four 8x8 sprites to be displayed. Hopefully the Game Boy also have a 8x16 display mode for the sprites, meaning that in reality each object in Sheep It Up! is only made of two sprites, and not four.

Do you remember that we are limited to 40 sprites onscreen, with the additional limitation that the Game Boy can't display more than 10 sprites on the same line?

In this case, it means that we can't have more 5 sheep side by side on the same line, instead of 10 as you might have thought at first (because the sheep is made of 2 sprites from an hardware point of view).

Full-screen tiles

I didn't mention it yet, but the Game Boy screen resolution is 160x144 pixels. It means that you need 20x18 = 360 tiles to cover the whole screen.

Sadly, the Game Boy VRAM is limited (8KB), and it can store only 256 different tiles. It means that, without any coding trick, you can't display a fullscreen image :

The secret is to reuse tiles, as you can see, the tile image have a lot of "empty space", meaning that a single "white tile" in RAM is placed several times on the image. In reality, the title screen image only uses 178 different tiles, meaning I still had room for some extra details if I needed to.

I don't know what method they followed to re-use tiles in the 90's, but today we have a very nice tool for that, called Game Boy Tile Data Generator. You feed it with a PNG image (in 4 colors) and it will automatically generate you the tiles and the tilemap needed to display it on an actual Game Boy. Obviously, it will also automatically detect and reuse identical tiles to save as much video RAM as possible on the console!

For information, most of the 80s and 90's consoles work in a similar way, with 8x8 tiles-based display: Nes, Master System, PC-Engine, Super Nintendo, Genesis, Game Boy, Game Gear... The first mainstream home consoles to have a frame buffer were the PlayStation and Saturn, and the first Nintendo handled to do it was the Game Boy Advance (The Atari Lynx being the first handheld with individually addressable pixels). So learning to "work with tiles" on the Game Boy is actually a transferable skill if you later work on another retro game console!

Tips from the pros: making 4 colors sprites!

Let's end with a little tip coming from the talented developers at Nintendo. Please look at this screenshot from Wario Land :

Do you see how the coin, a sprite, is actually drawn with 4 colors? How did they perform such a feat, when I just told you that the Game Boy can only display 3 colors per sprite ?

The answer is simple : each coin is made of 2 sprites, and each sprite uses a different object palette. As you can see, when we split the coin in two halves, it's indeed made of two 8x16 sprites. As always with Nintendo, there is a great attention to detail: they didn't simply merged two "sprites halves", but they draw them slightly tilted and they overlapped them by 1 pixels, so the coin feel more like a single element!

Conclusion

This is the end of the first part of postmortem. Thanks for reading it this far! In part 2, we'll discuss the audio challenges (lot of oddities here too!), and how the cartridges were built without destroying any previously existing Game Boy game. I'll also go over the feedback I received from players on Sheep It Up!

I hope you enjoyed this article! And, if you still have a Game Boy laying around, don't forget that you can buy a beautiful Sheep It Up cartridge for a mere $15 from Catskull games. Each cartridge will be assembled by hand before being sent to you!

And if you want to discover more of my creations you can: