The Retro card

Make a game for an old console! Not a game that looks old, but one that actually runs on a Game Boy, an NES, a Sega Genesis…

What counts

A game that runs on a real old console, or on an emulator of one. You ship a ROM, and anyone with that console (or an emulator) can play it. The Game Boy, Game Boy Advance, NES, SNES, Genesis, Atari 2600, N64 and PlayStation are all great picks.

A modern game with pixel art and a CRT filter doesn’t count, and neither does PICO-8, since fantasy consoles were never real hardware. If you’re not sure whether your console counts, ask in #crescent-help before you start!

This card is the Emulator card flipped around: instead of making a computer pretend to be a console, you’re writing software for the console itself.

The easiest thing that counts

GB Studio! It’s a free game maker for the Game Boy where you put together scenes, sprites and scripts in a visual editor, and it spits out a real Game Boy ROM. It can export a version that plays in the browser too, which makes your demo super easy.

It’s also a great way to learn what the Game Boy can and can’t do before you go any lower. When you want more control, GBDK-2020 lets you write Game Boy games in C.

Want to try a few consoles before you pick one? 8bitworkshop is a browser IDE for the Atari 2600, the NES and a bunch of other old machines, with an emulator right next to your code.

Working with limits

This is what makes retro games so fun to make. Every byte counts!

• The Game Boy has a 160×144 screen with four shades of green-ish grey, and just 8 KB of RAM to work with.
• The NES has only 2 KB of RAM, and it can show 64 sprites at once, but only 8 on the same line before they start flickering.
• The Atari 2600 has 128 bytes of RAM, and no framebuffer at all. Your code draws the screen line by line, as the TV’s beam sweeps across it. People call it “racing the beam”.

A lot of classic game design comes from working around limits like these. Little screens and short loops of music are features, not bugs!

Going further

• Assembly. Write a Game Boy game in assembly with RGBDS. The GB ASM Tutorial walks you through making a whole Breakout clone, and the Pan Docs cover everything about the hardware.
• The NES. The NESdev wiki is the place to learn. You can write in 6502 assembly with ca65, or in C with cc65 if you’re brave.
• The Genesis. SGDK lets you write Genesis games in C, and the Genesis has a lot more power to play with than the 8-bit consoles.
• The Game Boy Advance. Way more room, and you can write it in C or C++. Butano is a lovely C++ engine for it.
• Real hardware. Flash carts let you put your own ROM on a real cartridge. Seeing your game running on an actual Game Boy is something else!

Testing it

Use an accurate emulator with a good debugger. Emulicious and mGBA are great for Game Boy games, and Mesen is amazing for the NES and SNES. Test on more than one if you can: something that only works in one emulator might not work on the real thing.

Before you ship

There’s a few things every project needs before we can approve it:

• It works. It doesn’t have to be finished, but the main thing it does should actually work.
• All of your code is public, on GitHub or somewhere like it.
• Anyone can try it, even someone who doesn’t code, in under two minutes of setup.
• Someone else could rebuild it from your repo and README.

For a retro game, that means:

• Ship a ROM, not just the source code. Put it in a release on GitHub.
• Make it easy to play. If there’s an emulator that runs in the browser, your demo link should open your game already loaded in it. If you can’t make a link like that, link your release page instead, with the ROM, a link to an emulator, and steps for loading the game into it.
• No emulator at all? If it only runs on real hardware (an unusual console, or something you built), you’ll need a video of it clearly running on the real thing, on YouTube, Vimeo or as an .mp4 (not Google Drive).
• Write down any extra steps. Flash carts, patching, special emulator settings… if we need to do it, it goes in your README.

A gameplay video is lovely to have, but if your game can be played in an emulator, the video can’t replace the playable link.

Shipping one

• Demo: a page where we can play it in the browser is ideal. GB Studio can export one, and EmulatorJS can put any ROM on a web page. Otherwise, link your release page with the ROM, an emulator and how to load it. It’s your own game, so sharing the ROM is totally fine!
• Screenshot: your game running, in an emulator or on a real screen.
• README: which console it’s for, the controls, what tools you used and how to build it. A photo or video of it on real hardware is a huge bonus.