Designing Around Limitations

Racing the Beam

I recently finished reading Racing the Beam: The Atari Video Computer System by Nick Montfort and Ian Bogost. I have a passion for classic gaming, so of course I’m always interested in reading up about the old Atari VCS, which I first came across back in 1981 I think. My first stepmother’s ex-husband had actually purchased one shortly after it came to market, and she won it, as well as an organ and his machete, in the divorce (actually, I think he just left most of his stuff in the apartment and took off for less stricter pastures, but that’s a story in and of itself).

At the time, the VCS was really gaining popularity with kids my age. My stepmother didn’t actually realize this until I started being social and going to other kids’ house in the building to play blotchy Asteroids on their consoles. Then she remembered the dusty box in the back of the closet, and my brother and I were happy campers playing endless versions of Combat.

(A note: the VCS was not our first addiction: that would be console Pong.)

The VCS was the first extremely popular console system at a time when technology for gaming was quite young and extremely limited. The MOS 6507 CPU could only use* a whopping 8 KB of memory, and games were therefore limited to 4 KB until bank switching came to games years later. The TIA was the real star of system as it was responsible for putting the graphics on our television screens. The technology was limited, however, and it wasn’t really until Activision came on the scene that designers really pushed the limits and made beautiful games for the VCS.

Racing the Beam focuses both on the technological aspects of the VCS and how game designers worked with and overcame the limitations of the hardware. Montfort and Bogost look at six games which took advantage of and pushed the envelope of the VCS:

• Combat
• Adventure
• Yars’ Revenge
• Pac-Man
• Pitfall!
• Star Wars: The Empire Strikes Back

I’m not going to go into details about how each game was handled in the text. Mostly because I’m lazy, but also because it’s much more interesting to read how the technology inspired the design of each game by people who actually know what they are talking about rather than someone simply regurgitating what they think they know. What I am going to talk about, however, is the way in which we design around limitations, using myself (one of my favorite topics!) as an example.

I’m not a programmer. I’ve tried to learn a language here or there, but I simply can never get a handle on things. It’s like mathematics: I know 1 + 1 = 2, but if you want me to do some odd trigonometry calculation you’d probably have better luck speaking to me in Swahili. This is why, in part, I took a class in Game Programming at Hunter College last semester. The language was ActionScript, and it was taught by my Concepts In Gaming professor, Angela Ferraiolo. While I did well in the class, I was a complete and utter newbie, unable to execute my rather simple ideas into finished products.

My first project, coincidentally enough, was a port of Atari’s Outlaw, one of my favorite Atari games. I created a splash screen, a rules page, and had an easter egg page on the splash screen giving a brief history of the game. That was the easy part.

I knew how to move my avatar up and down and within the limitations of the stage, but I did not really know how to randomly move the “bad guy” up and down. At the same time, I didn’t know how to successfully fire the gun and have the bullet move across the screen, but did know how to do collision detection. I also did not know how to add sound to get an audio feedback (gun fire, gun hit, win/lose, etc.). Because of my coding limitations, I had to design my game around them. There’s a win/lose state that’s only initiated when the player clicks an object on the screen. Click yourself or the cactus and you lose. Click the bad guy and you win. In either state, you can replay the game (return to the splash home page) and start again.

Whether or not my version of Outlaw is a successful game isn’t up for debate, but what is interesting to me is how I worked with my limitations to produce some sort of product. What I didn’t do, however, is push the limits of my knowledge, nor push the limits of ActionScript’s technology to produce a viable product, but that’s understandable considering that I was only two weeks into learning the language. Racing the Beam, however, gave me food for thought regarding how many designers and programmers have to work around the limitations of whatever platform they are working in. While the Atari VCS is certainly a low end platform system that was severely limited by the technology available in its day, a slew of effective games were produced that are not only some of the most beloved games of all time, but set design standards that are still in use today. Effective game design and programming looks at the lowest common denominator and then says “okay, how can I push the envelope and make a kick ass game.” Not every game is successful in this area, but it is an extremely worthy goal to reach for, and something that I, as a designer, should keep in mind as I continue to expand and learn and develop my myriad tools (none of which should really include programming :)).

Racing the Beam is part of the Platform Studies series, published by The MIT Press

* correction submitted by Simon… thanks!
Check out….

• Boston.com interview with Nick Montfort