← Selected Work
Arduwars, Game Design & C++ Engineering

Game Design & C++ Engineering

Arduwars

A hobby port of Advance Wars to the Arduboy, fitting a full turn-based strategy game with AI and fog of war into 2.5KB of RAM.

Role
Solo project. Designed every game system and wrote the whole engine in C++, squeezing it into the Arduboy's tiny memory.
Team
Solo, hobby project
Duration
On and off, 2018–2019
Outcome
A playable alpha running real strategy gameplay on an 8-bit handheld. Unfinished by choice, kept as a portfolio piece for the game design and low-level engineering it took.

Context

Arduwars is a hobby project with no client and no brief: a port of the classic strategy game Advance Wars to the Arduboy, a credit-card-sized open-source handheld. I built it to stretch two muscles at once, game design and low-level C++, on hardware that makes both genuinely hard.

The Arduboy runs on an 8-bit microcontroller with roughly 2.5KB of RAM, 32KB of storage, and a 1-bit black-and-white screen. Advance Wars is a deep strategy game with dozens of unit types, terrain rules, an economy, fog of war and an AI opponent. Getting one onto the other was the whole point.

The challenge

Strategy games are hungry. They track a grid full of units, each with its own stats, movement range, health and state, on top of terrain, buildings, income and an AI that has to reason about all of it at once. On a normal machine you lean on the standard library and never think about memory. The Arduboy gives you none of that. No STL, almost no RAM, and every byte spent on game state is a byte you can’t spend on the map.

What I built

I designed the systems first: a roster of 15+ units across infantry, vehicles, aircraft and ships, terrain bonuses, a capture-and-build economy, fog of war, and the rules for direct versus indirect attacks. Then I built the engine to run them in C++.

The whole game is an exercise in spending memory carefully. Everything that never changes at runtime, the maps, the sprites, the unit stats, every line of text, lives in the chip’s flash storage through PROGMEM and gets read back only when needed, so the scarce RAM stays free for live game state. The data is modeled down to the byte: units and tiles are single-byte typed enums, prices pack into one byte each. Nothing is bigger than it has to be.

And it had to look good, not just run. The screen is one bit deep, pure black and white, which makes a readable unit sprite or a legible map genuinely hard to pull off. I drew the whole tileset, the units and the UI by hand at the pixel, and kept pushing until the game looked the way I wanted on that tiny monochrome display. Getting the look right was as much of a fight as getting it to fit, and it paid off.

What runs today: single-player against an AI, pass-and-play multiplayer, and three maps spanning land, air and sea, with custom maps on top.

The trade-off

Every feature was a negotiation with the hardware. The easy move would have been a more forgiving platform, but the constraint was the point. So I kept the depth and paid for it in engineering: trimming data structures to the byte, pushing everything I could into flash, and cutting whatever didn’t earn its RAM. The game I could fit was always smaller than the game I could imagine, and deciding what survived that cut was most of the work.

The result

I never finished Arduwars, and I have always been straight about that. It is a playable alpha, not a shipped game. What it proves is the part worth showing: I can design a real game system and then engineer it down onto hardware that fights you the whole way. Both the design and the C++ had to be tight, and getting a strategy game to breathe inside 2.5KB of RAM taught me more than a comfortable project ever could.