Dirty Game Development Tricks

1: http://thedailywtf.com/Articles/Classic-WTF-The-Cool-Cam.asp...

The joke's on that guy, given what EA's stock value and bonuses have been like lately.

Ever notice that a lot of old games have very repetitive worlds? Most of them are built around what some call a "room sprite": a prefabricated room that can be placed anywhere in the world. The world, then, is not much more than a big array of of indices into an array of expensive room sprites.

That's relatively straightforward, but it gets interesting when you store some information about an instance of a room separately from the "sprite" itself. Simplest example: If you store the hardware color palette and/or tilemap information separately, you can use the same basic room in different dungeons and make it look significantly different each time.

If a game has a generic "item room" (like the ones in Metroid or Zelda), you can bet that each instance of that room only needs to specify a single byte representing the item to be found in it.

A more interesting application are the doors in Zelda: They're not a part of the "room sprite" itself. Instead, for each possible north, south, east, and west door, there's a simple bitflag that enumerates a few possibilities: "no door on this wall, there is an open door, there is a locked door, there is a door that you must trigger an event to open, etc."

I don't know if Zelda does this, but it would be pretty easy to allow rooms to be flipped horizontally or vertically as well.

Just these few techniques, a dozen rooms, and thoughtful game design would probably be enough to get a few decent dungeons that would take hours to beat, out of a modicum of kilobytes.

My favorite example of this idea: If you really explore the original Metroid, you'll find a lot of hidden bombable paths that don't always lead anywhere. For instance, all item rooms have a pipe underneath them that can be entered by bombing a nearby block, but in most of the rooms, the pipe doesn't lead anywhere. If you don't know any better, it seems like the designers are just playing with your curiosity. In hindsight, it's totally obvious that this was a trick to let the game designers choose whether or not to put a secret passageway behind a particular item room just by lining up a different room next to it!

Once you get this, you see it everywhere in the world. You start recognizing different room sprites, and memorize the where their hidden paths are located. With that and the realization that the game only ever scrolls along one axis at a time, the seemingly impossible task of mapping out the entire world ("do they really expect me to shoot every single wall?") quickly becomes a simple effort of pattern memorization. Sadly, most people who try the original Metroid today get tired of climbing up those long vertical shafts and starting with only 30 health and quit before they even get a chance to discover this metagame.

Well, that story was from 11 years ago. Even then, PS2 and XBox devkits weren't bad. Comparable to IDEs at the time, or maybe even a bit more powerful for debugging.

> The guy debugging with colored screens is a real WTF.

That's essentially the graphics equivalent of printf() debugging. It's all about quickly getting some insight into what's going on. If hacking some colors in there does it, so be it.

Note that this was a bug occurring related to handling user input while loading, so it's likely that pausing the game or stepping into a debugger would actually prevent the bug from occurring. In situations like that, you make do with what you can.