3 Brutal 2025 Lessons: Making a D&D Game Boy Game in C

We think of C as a low-level language. On the Game Boy’s 8-bit Z80-esque processor, C is a high-level luxury, and its abstractions can be incredibly expensive. Writing clean, readable, modern C code can—and will—kill your performance.

The Slowdown of Convenience

In the early days, my game loop was full of simple, elegant function calls. I had draw_player(), update_npcs(), and render_ui(). It looked great. It ran at about 5 frames per second.

Every function call on the Z80 has overhead: pushing arguments onto the stack, jumping to a new memory address, executing the code, and then popping everything back off the stack to return. When you do this hundreds of times per frame, that overhead adds up. A simple multiplication or division operation, which we take for granted, can translate into a surprisingly long series of assembly instructions, grinding your game to a halt.

My worst offender was using printf() to debug values on screen. It’s a convenient function, but it’s also a monster. It pulls in a huge library of code for string formatting, bloating your ROM size and taking an eternity (in CPU cycles) to execute. It was like summoning a dragon to light a candle.

The Solution: Think Like the CPU

I had to stop writing C like a modern programmer and start writing it like a 1989 hardware engineer.

• Inlining and Macros: Small, frequently-called functions were either rewritten as macros or declared with inline to encourage the compiler to paste the code directly into the call site, avoiding the function call overhead. It makes the code uglier but faster.
• Bitwise Operations are Your Best Friend: Need to multiply or divide by two? Use bitwise shifts (x << 1 or x >> 1). They are orders of magnitude faster than using * or /. Checking if a number is even? Use if (x & 1 == 0).
• Data Types Matter: The CPU is 8-bit. Using int (which is 16-bit in GBDK) when all you need is a value from 0-255 is wasteful. I switched almost everything to unsigned char or GBDK’s UINT8. This halved the memory usage for many variables and made operations faster.

You don't necessarily have to write pure assembly, but you absolutely have to understand the cost of the C code you’re writing.

Lesson 3: Your Game State is the Real Final Boss

This was the most brutal lesson of all. A D&D game is nothing but state: character stats (Strength, Dexterity, etc.), HP, MP, status effects, inventory, equipped items, spell lists, quest flags, NPC locations, and which chests you’ve opened in which dungeons. All of this data that makes the world feel alive must be stored somewhere.

On the Game Boy, your primary active storage is 8KB of Work RAM (WRAM). Good luck fitting a party of four adventurers and a sprawling world in there.

The Data Explosion

Initially, I defined my player character with a simple C struct. It was clean and easy to read.

  struct Player {
    unsigned char strength;
    unsigned char dexterity;
    unsigned char constitution;
    unsigned char intelligence;
    // ... and so on
  };
  

This seems fine, but each unsigned char takes a full byte. My six core D&D stats took 6 bytes. HP and Max HP took another 2. Add in inventory (an array of item IDs), spell slots, and location data, and a single character could easily eat up 100+ bytes. For a party of four, that’s almost half a kilobyte, just for the party! Add in flags for 100 quests and 200 treasure chests, and my 8KB of WRAM was gone before the game even loaded.

The Solution: Bit-Packing and SRAM Agony

The only way forward was to treat every single bit as precious. This is called bit-packing.

A character stat like Strength only needs to go up to 20. You don’t need a full 8-bit byte (0-255) to store that. You only need 5 bits (0-31). So, you can pack a character’s Strength (5 bits) and Dexterity (5 bits) into a single byte with 6 bits to spare! It’s tedious to code, requiring a lot of bitwise AND, OR, and shift operations to get and set the values, but it’s the only way.

My new character data looked less like a struct and more like a cryptic puzzle:

  // Byte 0: [STR | CON | 2 unused bits]
  // Byte 1: [DEX | INT | 2 unused bits]
  // ... etc
  

This extended to the save file. Most Game Boy cartridges with save functionality have 8KB of SRAM. You have to decide what is absolutely critical to save. Can you regenerate the state of every NPC in the world, or do you need to store it? My solution was to only save core player data, major quest flags, and the player's current location. Everything else—like the fact that you killed three goblins in the Whispering Woods—is forgotten the moment you turn the power off. It’s a compromise that hurts, but it’s the only way to make saving possible.

---

Was It Worth It?

Absolutely. The process was brutal, and my respect for the developers of the 90s has grown tenfold. They weren't just making games; they were fighting the hardware every step of the way.

Making a game on the Game Boy is a fantastic exercise in resource management and computational thinking. It forces you to understand the machine at a deep level. So if you’re thinking of starting a retro project, I say go for it. But be prepared. The hardware is a harsh teacher, and its lessons are, well, brutal.