|
|
Nick Montfort and Ian Bogost, 2009
As I have mentioned from time to time, I did my undergraduate honors thesis on generational polemic, drawing on the pop-sociology work of Neil Howe and William Strauss. These authors divided the population into generations 22 years wide (give or take), and dubbed my generation, now universally known as Generation X, the "13ers". They further subdivided us into "Atari-wave 13ers" and "Nintendo-wave 13ers", terminology that leaves a gap that I fall smack into the middle of. I spent a lot of my childhood playing console games, but I had an Intellivision. My little brother had a Nintendo in the late '80s, but I didn't use it much, and Elizabeth has more than once expressed shock at my unfamiliarity with the Nintendo canon — e.g., The Legend of Zelda was after my time and I don't know the first thing about it. At the other end of the range, our babysitter in the early '80s had an Atari, and he would occasionally bring it over. While I relished the chance to play games like Missile Command and Warlords that weren't available on the Intellivision, it was very clear to me even at age seven that the Atari was obsolescent technology. The graphics were not only primitive, but also kind of weird — why were Atari programmers so enamored of horizontal stripes?
Racing the Beam is an academic book that answers this question and many others. It lays out how the Atari VCS operates, chip by chip, and then discusses how the workings of the machine shaped the games that were produced for it, digging into six games in particular. I learned that the Atari is not just an Intellivision with less capable hardware. The Intellivision, like the IBM PC on which I did the vast majority of my arcade game programming, has a screen model that's like a big piece of graph paper. You've got a grid of squares, each with an X coordinate and a Y coordinate, which you can address directly. The Atari does not use this Cartesian system. Its screen consists of 192 horizontal stripes. If you want a different color in the middle of a stripe, you must insert a color-switching instruction into your code that triggers at precisely the right moment as the electron gun inside the television swivels from one side to the other. You can only do this a limited number of times per stripe. On the other hand, the Atari offers 128 colors rather than the Intellivision's sixteen, which encouraged programmers to go for a gradient effect, switching shades from one horizontal stripe to the next. The Atari aesthetic followed from the operation of its hardware.
This raises the question of why the designers of the Atari chose the hardware they did. Racing the Beam answers this question as well, and that answer turns out to be very interesting, at least to me. The Atari VCS was developed in the mid-1970s, before the advent of the vast majority of the games that make up the arcade canon. The exceptions were the title that launched the video game craze — 1972's Pong — and 1974's Tank. The Atari is in essence a machine designed to play variations on these two games. It supplies developers with a set of hardwired resources: a symmetrical playfield; a handful of 8×8 graphical blocks known as "sprites", two of which can appear onscreen at once; two missiles; and a ball. The first game Racing the Beam looks at in depth is the one that shipped with the console, Combat, which not coincidentally is a combination of Tank and Pong (at least in its most popular mode). Breakout was another natural fit for the system. But even as the Atari hit stores at the end of 1977, the video game world was moving beyond Pong variants.
Most of the programming I've done in the past twenty years has been interactive fiction, a computer-mediated narrative form in which you read a chunk of a story, tell the program what you'd like your character to do, read the result of your chosen action, give more instructions, and so on. You might expect that an interactive fiction platform (such as the Z-machine, historically the most popular one) would concern itself above all else with printing out paragraphs of text and accepting and parsing typed input, and you'd be right. But, at least in the case of the Z-machine, other capabilities were gradually added. Someone thought light gray text on a dark blue background would make for a more pleasant reading experience than white on black, so color was added. Someone else wanted to be able to stick apposite literary quotes in the middle of the screen, so absolute text positioning was added. Another developer wanted events to be able to unfold in real time rather than on a turn-by-turn basis, so in that went. Eventually the specifications of the Z-machine reached the point that Andrew Plotkin was able to take this storytelling platform and implement a version of Tetris on it. These stunts became known as "Z-abuses", and some were quite elaborate: I once wrote a complete game combining interactive fiction with arcade golf. The third chapter of Racing the Beam covers the opposite case. Programmer Warren Robinett had played the mid-'70s text game Adventure and decided to try adapting it for the Atari. In the process, he wound up pioneering a number of video game conventions we take for granted today, such as the notion that if you wander off the screen to the left, you wind up on the right edge of a completely different screen. But what was most fascinating to me was how Robinett repurposed the Atari resources to build an adventure game. The VCS supplies developers with a "missile" object; Robinett used it to create walls. The VCS supplies developers with a playfield consisting of a foreground and a background; to create a dark maze, Robinett made these an identical shade of gray, and implemented a light source by using the sprite utility to create an orange box around the player that would appear above the background gray but beneath the foreground gray, revealing the walls within a short radius. And as for that player: Robinett could only have one other sprite appear onscreen if one sprite were used for the player, so he simply didn't use a sprite for the player. The Atari resource used for the player… is the ball.
And Adventure is hardly alone in using these sorts of hacks. For me the big takeaway of Racing the Beam is that almost every Atari game was the equivalent of a Z-abuse. Every year Atari programmers had to take the latest wave of hit arcade games and implement them on a Pong machine. Sometimes this effort was very successful, particularly when they were given the latitude to reimagine the source material. The vector-based arcade game Star Castle was obscure enough that programmer Howard Scott Warshaw was permitted to transform it into Yars' Revenge, the third Atari game I always wished would come out on the Intellivision (and which I now realize would have disappointed me if it had, since for all its graphical advantages, the Intellivision could not do a very good rendition of the kaleidoscopic "neutral zone" that made Yars' Revenge so visually arresting). On the flip side, Pac-Man was so well-known that Atari couldn't afford to deviate from it, leaving programmer Tod Frye in a very difficult spot. The VCS allowed developers to show two moving sprites simultaneously, enough for Pac-Man himself and one ghost. But Atari could hardly go to market with a one-ghost Pac-Man; Frye had to find a way to implement all four. His solution was to alternate among them, with one screen draw showing Pac-Man and Blinky, the next Pac-Man and Pinky, the next Pac-Man and Inky, the next Pac-Man and Clyde, and back around again. The result was a horrible flickering effect. This problem had afflicted other Atari games — e.g., if two dragons and a bat showed up in the same room in Adventure, they'd flicker like mad — but it made Atari's Pac-Man virtually unplayable.
Racing the Beam is a short book, at less than 150 pages, but in addition to the above also covers such topics as the work environment at Atari, the advent of third-party development studios, the shift from original titles to arcade ports and then to licensed properties, and other facets of the Atari story. Some of the technical discussion was a little bit beyond me, and even after reading the book's descriptions I did find it hard to imagine some of the games that were unfamiliar to me — Youtube was a huge help in this regard. The style is also a little inconsistent, as you might expect from a book with multiple authors — it was a bit odd to suddenly find a lot of wordplay in the Empire Strikes Back chapter when there'd been virtually none up to that point. But all in all, Racing the Beam gets a thumbs-up from me. This is sort of comparing apples and rectangular orange vitamins, but recently I've read a few online writeups of TV shows, and I don't really get too much out of the ones that are just someone I've never heard of spouting opinions ("I liked this performance! I didn't like that plot twist!"). Better are the ones that interpret the show, that (for instance) draw attention to thematic connections among scenes that may not have been obvious on first viewing. And even better than that, to my mind, are works like Racing the Beam that not only interpret cultural artifacts but do so while supplying a lot of information that's new to me and sheds all sorts of light on the subject.
