Classic Games, Classic Bugs

They just don’t make video games like they used to. The same can be said for gaming bugs.

Not long ago, I watched The King of Kong: A Fistful of Quarters, a quasi-documentary about the rivalry between two gaming “legends” competing for the high score in Nintendo’s 1981 version of Donkey Kong. Aside from a hilarious portrayal of the competitive gaming culture, the film introduced me to the infamous kill screens of Donkey Kong and Pac-Man – easily two of the most unique bugs ever discovered by the end-user.

The Donkey Kong Kill Screen

A showstopper bug on level 22 – a level only a handful of gamers ever reach – causes poor old Jumpman (now known as Mario) to die for no apparent reason. And you thought the barrels were tough! According to the Wikipedia entry:

This is an example of a kill screen that is not due to an integer overflow in a level counter (since programmers prevented this), but a different oversight on the part of the designers. The amount of time allowed for any given screen is determined algorithmically during play by the level the player is on. The timer is calculated 100*(10* (level + 4)), and has a maximum value of 8000. When the level reaches 22, the game reads 100*(10*(22+4)) or 100*260. However, the 8-bit counter rolls over at 256, meaning the game calculates 100*4. This causes the timer to be set so low that there is simply not enough time for the screen to possibly be completed.

Seems like an honest mistake. Besides, how many gaming testers were there back in 1981?

The Pac-Man Kill Screen

The Pac-Man kill screen, on the other hand, takes an impossible game (there’s technically no end to the levels) and makes it even impossible-er. Here’s another quick description of the bug from Wikipedia:

…because of a bug in the routine that draws the fruit, the right side of the 256th level becomes a garbled mess of text and symbols, rendering the level impossible to pass by legitimate means. Normally, no more than seven fruits are displayed at any one time, but when the internal level counter (stored in a single byte) reaches 255, the subroutine erroneously causes this value to “roll over” to zero before drawing the fruit. This causes the routine to attempt to draw 256 fruits, which corrupts the bottom of the screen and the whole right half of the maze with seemingly random symbols.

Pretty neat, eh?

The lesson that we must draw from the popularity of these bugs, of course, is that users love your bugs as well. They are especially fond of ones that prevent them from completing the next level, or even the game in its entirety. They enjoy these showstoppers so much, in fact, that they’ll even make t-shirts out of them, write about them on  their blogs and even reference them in popular TV shows.

Or maybe, as is more likely the case, the Pac-Man and Donkey Kong kill screens are just classic exceptions to the rule (albeit very cool exceptions) and that bugs like this should be avoided at all costs.

Have a great weekend everyone. Happy gaming!

Essential Guide to Mobile App Testing

Comments

  1. says

    upload it at mediafire.com to get a direct link of that mp3. then use this code: . . . Look for aduioUrl, then after that equal sign.. delete the entire line that says MP3_FILE_URL.. and type in the url of your mp3 file you had uploaded in mediafire.

  2. says

    I recently came across your blog and have been reading along. I thought I would leave my first comment. I don’t know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

    Susan

    http://onlinemariogames.net

Trackbacks

  1. [...] From Wikipedia: “Donkey Kong also featured a kill screen in the 22nd stage, and the 117th screen. This is an example of a kill screen that is not due to an integer overflow in a level counter (since programmers prevented this), but a different oversight on the part of the designers. The amount of time allowed for any given screen is determined algorithmically during play by the level the player is on. The timer is calculated 100×(10×(level + 4)), and has a maximum value of 8000. When the level reaches 22, the game reads 100×(10×(22+4)) or 100×260. However, the 8-bit counter rolls over at 256, meaning the game calculates 100*4. This causes the timer to be set so low that there is simply not enough time for the screen to possibly be completed.” (Note: we’ve blogged about this before) [...]

Leave a Reply

Your email address will not be published. Required fields are marked *