Pokémon's damage formula wasn't designed for the Game Boy.

My previous post on RPG math noted a pattern: early console hardware couldn’t multiply or divide natively, so early RPGs used simple formulas built around what was cheap. Addition, subtraction, bit shifts. The math reflected the machine.

Pokémon broke that pattern on purpose.

The Game Boy’s CPU was the Sharp LR35902, a custom hybrid of the Intel 8080 and the Zilog Z80, running at about 4 MHz with 8 KB of working RAM. It had no hardware multiply or divide, and arithmetic beyond addition and subtraction had to be emulated in software, which on a 4 MHz 8-bit CPU is slow and expensive. This is the machine Game Freak shipped the original Red and Green on in 1996.

The damage formula they used looks like this:

Damage = (((2 × Level / 5 + 2) × Attack × MovePower / Defense) / 50) + 2

Nothing in that expression is friendly to the hardware it’s running on. The divisions by 5 and by 50 can’t be optimized into less expensive bit shifts. Dividing by 5 requires an actual division routine, which on this CPU means a software loop. There are multiple multiplications. The operations have to be sequenced carefully to avoid integer overflow in intermediate results given the small register sizes.

This was a deliberate choice. Game Freak knew exactly what hardware they were shipping on. They’d been working on the game since 1990, six years of development, almost entirely on the original Game Boy. They were perfectly aware that divisions by arbitrary constants were expensive and chose that formula anyway.

Why? The most plausible reason is that they were designing past the Game Boy. The formula has properties that make it scale gracefully: damage output is proportional to level in a way that keeps battles competitive across a wide range, the Attack/Defense ratio produces sensible results at both extremes, and the MovePower variable slots in cleanly for any move you want to add later. It’s general-purpose and computationally expensive in a way that a bit-shift-optimized formula wouldn’t be.

As it turned out, the same formula ran in Gold and Silver on the Game Boy Color, in Ruby and Sapphire on the Game Boy Advance (which did have hardware multiply, making it finally cheap to run), in Diamond and Pearl on the DS, and on through generations of increasingly powerful hardware. The numbers grew. Base stats, move power, and HP values all inflated considerably across generations. But the algorithm stayed structurally the same until Generation V in 2010, when a revised formula updated the level scaling while preserving the overall shape of the math. Even after the revision, the logic was recognizably descended from what shipped in 1996.

That’s a 14-year run of the same core formula across roughly eight hardware generations, on machines ranging from a 4 MHz 8-bit chip with 8 KB of RAM to a 266 MHz ARM processor with 4 MB. The Game Boy paid the cost of the software division routines so that every subsequent platform got the formula essentially for free.

There’s a general principle buried in here that shows up across software engineering: optimizing hard for your current constraints can make you brittle to the next ones. The NES-era RPGs that used bit-shift-friendly formulas were fast and appropriate for their hardware, and they also didn’t survive contact with the PlayStation without being substantially redesigned. Game Freak wrote a formula that was inefficient for 1996 but scalable for the following three decades.