The difficulty is legendary, yet I can’t say I ever truly “understood” the troubles in programming an Atari Video Computer System, or Atari 2600 as it is better known. MIT Press’ new series “Platform Studies” aims to choose a target system and examine how the construction of that platform dictates the growth and maturation of its software. Great artists struggle within the confines of their chosen medium, and this is just as true in software as in physical media.
Their first examination is the Atari 2600 and its “television adapter interface” (TIA) in the book Racing the Beam by Nick Montfort and Ian Bogost. To say I was enthralled is a complete understatement. I found the book a quick, enjoyable read that didn’t get bogged down too much into the arcane, while not shying away from digging deeply into the machinations of the TIA to show the challenges faced by developers on that system.
One would be hard pressed to find a developer today who really understands what is happening behind the code she writes. We’re so accustomed to writing to software APIs which themselves are written upon a software API which is itself built upon a software API which is built upon an OS which is built upon a kernel. The 2600 and its TIA were basically a direct link between program and television electron beam. The system had no operating system and so each game essentially became a custom-tuned, handcrafted series of assembly language calls that did one thing and one thing only: play one particular game.
Reuse of concepts was important, but reuse of code seemed to be almost an impossibility. Some code relied upon happenstances of other code to feed registers appropriate information at appropriate times. When you have a system with 128 bytes of RAM (!) the programmer must essentially try to outrun the television scan-line, feeding it the color and position of pixels in a kind of JIT manner.
As the system could not hold an entire line of data in memory, let alone an entire screen, we must surely appreciate the efforts that looked at these limitations as challenges to overcome, not barriers to creativity. Consider the game Pitfall! (one of six games covered in the book) and its 256-screen wide map of exploration. Now consider that the entire map (which is location consistent, not random), its graphics, its gameplay, its sound effects… all of it fit into 4K.
Also consider that another of the profiled games, Adventure, fit in 4K as well and only had a map of about 30 screens (warning, linked map graphic at 30K is 8.5x larger than the entire original game). Comparing the world size and graphics fidelity, we can clearly see that programmers gained more and more mastery (and by mastery here I do truly mean a deep understanding and ability) of the machine. Racing the Beam seeks to illuminate this process for us and does so very well. Perhaps the highest compliment I can pay the book is to say that it sparked in me a desire to tinker with some Atari 2600 code. Not so much because I wish to make a game for it, but more to appreciate that as a programmer I am always programming a machine, no matter how abstracted that level has become for me. To appreciate that, I feel I must actually do such a thing at least once.
For understanding the machine behind the code, I must also recommend the No Starch Press series Write Great Code. I found the books to be well-written and also found myself challenged to reconsider some of my daily programming challenges in terms of the machine. Not from an implementation point-of-view, but more in the sense of, “Do I actually know what the code I’m writing does?” As an intellectual pursuit, considering how I would cram the state of a chessboard into as few bits (I do mean bits, not bytes) as possible proved almost liberating in its tightly focused scope.
I also felt that Racing the Beam helped me put into words what I find so boring about video games and media these days. It really boils down to there not being any limits nor boundaries to consider during the creation process. There is no longer any real reason to create art that looks abstract when it is so EASY to make it look real. Just take some digital photos, scan in some 3D geometry, map the textures and you’re done. We can see this lazy approach by just looking at the plethora of look-alike games and look-alike graphics. The “gritty, urban” environments that dominate the game worlds, the “gritty, urban, stubble-headed” characters that populate them, the orchestral soundtracks, the lifelike sound effects… all of this stuck onto a Blu-Ray disc that holds 30GB. There’s not really any constraint in storage, and while the Cell processor of the PS3 is difficult to program, it isn’t really presenting “limitations” unless absolute reality is your goal (and it often is, and so it is seen as being challenging).
Basically, we’re at a point in game design where if you can think of it, it can be done. Why put much deep thought into a project concept when your first concept is instantly possible? There is nothing to struggle against. Nothing to harden yourself against. No boundary to constrain your vision. No limit. This seems like such a great idea, and yet Barry Schwartz’ The Paradox of Choice builds a compelling argument that it may not be all its cracked up to be from the consumer level. Perhaps this also holds true at the creator level?
And yet, on a machine like the Atari 2600 with its many limitations, entire genres were born and an entire language for gameplay was created. I can’t help but wonder what a generation raised on games that are literal interpretations of reality must build in the future. When I can’t tell the difference between Madden 2010 and a televised game, I have to wonder if this is actually progress. Isn’t going back to reality the regressive state? I am all too aware of the games that try to do something different. We all know this short list by heart (Rez, Space Channel 5, Portal, World of Goo, Ico, Shadow of the Colossus, et al) precisely because it is so short.
I would love to see an iPad enhanced version of this book, taking cues from the The Elements for the iPad and AppStar Games‘ Technical Wizardry series for the iPhone. Seeing living representations of the machine and its code, giving the reader an opportunity to tinker and tweak register settings, then seeing live changes in a running game would really get some of the more technical points across. All said, it is a great book and a must-read for anyone who programs and has an interest in video gaming. If you’re older, you’ll recall the system fondly and learn a lot about a machine you thought you knew. If you’re younger, seeing the roots of gaming’s visual vocabulary may kick your thinking off in new directions and build an appreciation for the deep, rich history this young hobby already enjoys.