# Why is 3333360 the maximum score in Pac-Man?

According to the Wikipedia page for Pac-Man, the highest possible score is 3333360 points. It's called a perfect game and it was achieved by 3 different people already.

What I want to know is: WHY is it exactly 3333360 points? It must be a technical limitation, but this number makes no sense in my opinion.

I know the game has 255 levels. 255 is `11111111` in binary and level 256 (that seems to exist mystically) brings the 8-bit digit to an overflow, which ends in a crash of the game.

But, 3333360 just seems so random.

• It's not a technical limitation as much as it the score that you happen to get if you eat every pellet and piece of fruit on one life in every level. Oct 1, 2014 at 19:31
• The problem is not the fact that it tries to load level 0. The problem is that the number 256 (`100000000` in binary) is being stored in memory that has only been allocated to contain 8 bits. The first `1` is therefore written into memory that is assigned to something else, which essentially corrupts the entire game. Oct 1, 2014 at 21:26
• @LeeWhite: That's not quite the issue. The problem is that the code which is supposed to draw the fruits starts out by assuming the number of fruits should match the level number, checks if it's greater than 7, and if so sets it to 7. Then the logic to render the fruits works by repeatedly drawing a fruit, decrementing the number of fruits to draw, and looping until the decrement yields zero. If the level number was zero, the code tries to draw 256 fruits, overwriting display memory beyond the region where the fruits are supposed to go. Oct 2, 2014 at 16:31
• @LeeWhite That sounds very unlikely. As a software engineer, I don't know of any CPUs that work that way. If a number overflows, the '1' carried to the left of the number just goes away (and maybe also sets an overflow flag, depending on the architecture.) I'm not aware of any architectures that would overflow a number into the next memory address, especially since math doesn't usually happen directly on data in memory anyway. Math generally happens on data stored in registers and, after the math is complete, the data is written back to memory if needed. Oct 3, 2014 at 14:54
• @willoller No, it isn't. Integer overflow and buffer overflow are two entirely separate, unrelated concepts. Buffer overflow is the result of failing to check the bounds of allocated memory before writing something to it (or reading something from it, as the case may be.) Integer overflow is when you perform an arithmetic operation that results in a number larger (smaller) than the maximum (minimum) value supported by the data type. Integer overflow does not cause a buffer overflow. It usually just causes the integer to 'wrap around' to the other end of its range of valid values. Oct 3, 2014 at 18:20

The Pacman Museum has an article about getting 3,333,360 Points. And here's a video of some guy doing level 255 and 256, with important information regarding level 256.

## Level 1 through 255

Eating dots: There are 240 regular dots per level, worth 10 points each, Netting 2400 points per level. Additionally, eating the four energizer dots, worth 50 points each, gives you another 200 points.
⇒ 255 × 2600 = 663000

Eating "fruit": There is one edible object per level that only appears for a certain amount of time, twice per level. Depending on the type of fruit, which in turn depends on the level you are playing, you get a different amount of points. In total, you get
⇒ 2 × (100 + 300 + 2 × 500 + 2 × 700 + 2 × 1000 + 2 × 2000 + 2 × 3000 + 243 × 5000) = 2459600

Eating Ghosts: Eating a ghost in the same energizer period gives you 200 points, and double that for every additional ghost you eat (400, 800 and 1600 for the 2nd through 4th ghost, respectively). You can do this 4 times per level, but only up to level 16, and on level 18, since the ghosts don't blink in level 17 and 19+ ⇒ 4 × 3000 × 17 = 204000

Adding these numbers yields 3326600, just 6760 points short of perfect.

## Level 256

This odd number can be gotten in the glitched-out level 256.

Visible Dots: As you can see, a bit more than half of the screen is missing, which means you can only get 112 normal and 2 energizer dots.
⇒ 1220

Single Fruit: Due to the glitched screen, you can only get the key (the "fruit") once
⇒ 5000

Glitched Dots: There are 9 normal dots in the glitched out region that reappear every time you die. At 5 extra lives, you can get them 6 times
⇒ 6 × 90 = 540

## Grand Total

(663000 + 1220 + 540 (dots)) + (2459600 + 5000 (fruit)) + (204000 (ghosts)) = 3333360

• I started typing the answer, thinking the numbers would add up just fine and they didn't. Took quite some time to find out about the weirdness that is the points in level 256. Oct 1, 2014 at 20:57
• 256 is Quite an Important Number. Oct 2, 2014 at 20:23
• @Howdy_McGee Especially on an 8-bit processor... Oct 3, 2014 at 14:59
• Is the 256th level glitch on purpose - or is that something that is an actual glitch? Dec 25, 2014 at 0:22
• @RPi_Awesomeness it's an actual glitch, that has to do with numbers rolling over in binary. 256 is 100000000 in binary, but the number doesn't support more than 8 binary digits, thus cutting of the 1, making it 00000000, which is 0. For some not really related problem, this causes the glitching, rather than putting you in level 0 again. Dec 25, 2014 at 22:06

The score is limited because a glitch occurs on level 256 which overwrites half the screen with garbage. The game won't let a player advance from one board to the next without eating 244 dots and energizers, but the glitch overwrites many of the dots; this will leave the player unable to eat 244 dots and energizers, and thus unable to leave the level. In case you're wondering about why the glitch occurs, the machine code in Pac-Man to draw the fruits is similar to the C code:

``````unsigned char temp1, temp2;
unsigned char *ptr;

temp1 = level;
if (temp1 > 15) temp1 = 15;
temp2 = temp1;
if (temp2 > 7) temp2 = 7;
do
{
*ptr++ = shapes[temp1--];
} while(--temp);
``````

Note that unlike many machines, Pac Man uses a rather curious screen memory layout which places consecutive bytes horizontally on the top and bottom of the screen, and vertically in the middle. This was most likely done to make it so that when drawing the main portion of the screen, memory addresses would be incremented by a power of two every eight scan lines (note that the "top" of the monitor is at the right side of the picture). Essentially, circuitry converted row/column indices to memory addresses with a mapping similar to:

``````//Using column values in the range 30 to 1, wrapping after 63...
address = (column & 32) ?
(row << 5) | (column & 31) :
((28 | (column & 3)) << 5)  | row);
``````

but implemented in circuitry rather than code. This allowed screen addresses to be computed by using a pair of counters and a circuitry to select one of two permutations of those counters' bits. The hardware required to have memory address increase by 36 for each row rather than 32 would have been more complicated by comparison.

• @Kevin: The stated score is the maximum possible in Pac Man because the bug shown above (in C code which is functionally similar to the Z80 code in the game itself) writes useless junk over much of the screen, overwriting the dots the player is supposed to eat. The other answer states what visibly happens to limit the score, but the above indicates (for technically-minded readers) why it happens (and suggests that the 256-level limitation probably wasn't deliberate but instead occurs due to an oversight). Dec 2, 2014 at 16:00
• Both answers complement the question exceedingly well.
– Shon
Jun 20, 2015 at 19:01