Preserving Games

Tag: history

  • Book Review: Racing the Beam

    Montfort, N., & Bogost, I. (2009). Racing the Beam: The Atari Video Computer System. Platform Studies. Cambridge, Massachusetts: MIT Press.

    Racing the Beam: The Atari Video Computer System
    Racing the Beam: The Atari Video Computer System

    Just want to give a brief rundown on a really great read I’ve come across. MIT has started a “Platform Studies” series of books where the idea is to examine a platform and its technologies to understand how this informs creative work done on the platform. Platforms could range from gaming consoles, to a programming language, to an operating system, or even the Web itself if this is the platform upon which creative work is being made. The platform in this case is the Atari Video Computer System, the first Atari home system, later referred to as the Atari 2600 in the wake of the newer Atari 5200.

    The authors examine the Atari VCS as a computing system, and take care to elaborate the unique (really exceptionally odd) constraints found there. Six games are investigated in chronological order, giving the reader a sense of the programming community’s advancing skill and knowledge of the system: Combat (1977), Adventure (1980), Yar’s Revenge (1981), Pac-Man (1982), Pitfall! (1982), and Star Wars: The Empire Strikes Back (1982).

    The most prominent technical details are explained in first few chapters, and they illuminate each game’s construction as an exceptional act of engineering and ingenuity. Just to give an idea of the unique affordances of the Atari VCS, here are a few of the most characteristic details:

    • The custom sound and graphics chip, the Television Interface Adapter (TIA), is specifically designed to work with a TV’s CRT ray. The ray itself sprays the electrons onto the inside of a TV screen, left to right, one horizontal scan line at a time, taking a brief break at the end of each line (a “horizontal blank”) and a longer break at the bottom line, before resetting to the top and starting over again (a “vertical blank”). A programmer only has those tiny breaks to send any instructions to the TIA, and really only the vertical break provided enough time to send any game logic to the system.
    • It was imperative that game logic be sent at these breaks because the Atari VCS had no room for a video buffer. This meant there was no way to store an image of the next frame of the game, all graphic instructions are written in real time (sound instructions had to be dropped in on one of the breaks). A designer or programmer could choose to restrict the visual field of the game in exchange for more time to send game logic instructions. Pitfall! is an example of this.
    • This means there are no pixels on the Atari VCS. Pixels require horizontal and vertical planes, but for the Atari VCS, there is only horizontal scan lines. There is no logical vertical division at all for the computational system. As the beam goes across the screen, a programmer can send a signal to one of the TIA’s register to change the color. Thus, the “pixels” are really a measure of time (the clock counts of the processor) and not space.
    • Sprites, such as they existed for the Atari VCS, were hard-coded into the ROM of the system. Programmers had five: two player sprites, two missiles, and one ball. Reworking that setup (clearly designed for Pong and the like) into something like Adventure, Pitfall!, or even the Pac-Man port is an amazing feet.

    The book doesn’t refrain from the technical. I could have used even more elaboration than what is presented in the book, but after a certain point the book would turn into an academic or technical tome, so I appreciate the fine line walked here. The authors succeed at illuminating technical constraints enough for the general reader to understand the quality of the engineering solutions being described. Moreover, the authors leave room to discuss the cultural significance of the platform, and to reflect on how the mechanics and aesthetics of these Atari titles have informed genres and gameplay presently.

  • Hardware gimmick or cultural innovation?

    Y. Aoyama and H. Izushi, “Hardware gimmick or cultural innovation? Technological, cultural, and social foundations of the Japanese video game industry,” Research Policy 32, no. 3 (2003): 423–444.

    This 2002 article (written 2001) looks at the success of the Japanese video game industry and attempts to illuminate the unique factors behind its success. Japan’s video game industry is especially remarkable given the dominance of “English language-based exportable cultural products” and the origin of the video game industry, which began in the US with Steve Russell’s programming of Space War for the PDP-10 and Nolan Bushnell’s subsequent creation of Atari to market and sell such arcade games.

    Mega Man, hero of the early NES platformers. The design has characteristics of the <i>manga</i> style.
    Mega Man, hero of the early NES platformers. His design has characteristics of the manga style.

    The authors give a history of the industry and observe Nintendo’s very early interest and involvement with electronic toy games. This began as early as the 1960s with the emerging popularity of shooting games with optical sensors. Nintendo was able to recruit technical expertise from consumer electronics and provided them with early successes like Game and Watch and Color TV Game (totally cool old ad at gamepressure). But Nintendo’s historic rise in the console market with both the Famicon and NES was due in no small part to its attention to quality software; the company made sure to foster in-studio works (Donkey Kong, Super Mario Brothers) and hold alliances with outside game developers.

    After the mid 90s Nintendo falters by retaining cartridges for their games rather than the CD-ROM; this among other factors allows Sony to rise in the market. The authors continue the brief history up to the approximate time of the article, but one main point can be drawn from the narrative: hardware and software are intricately linked and related; success frequently hinges on a deep synchronicity between the two engineering pursuits. The authors go on to elaborate this point, emphasizing Nintendo’s early collaboration with domestic electronic consumer goods firms.

    The article describes three types of software publishers:

    • in-house publishers of platform developers (e.g. Nintendo)
    • comprehensive software publishers with in-house capability for most development (e.g. Square)
    • publishers that act as producer/coordinator and outsource most functions (e.g. Enix)

    (more…)

  • Interviewing Within the Industry

    For a while now I’ve been concerned about my ability to conduct interviews within the industry. I have been told by someone who would know that very few studios are going to allow me to look at their development process because in many cases, that process is itself a trade secret. I’m early enough in the process to not know if this is true or not, but in an attempt to be prepared, I’ve come up with a few workarounds for this issue:

    1. Collect oral history interviews with pioneers regarding their early experiences building video games, the processes and tools they employed, their needs then and now, and their attitudes regarding preservation of their creations. I figure that many of these people still hold IP on their first games (although I might be wrong on this); and even if they don’t still hold copyright, talking about their experiences during this formative period of development is beyond the reach of industry lawyers. Who would some of these pioneers be? And does anyone have contact information for them? I’m envisioning this as something like the Stanford and the Silicon Valley project at Stanford. I know that there are lots of interviews with pioneers out there, but I’d like to conduct some oral histories as well.
    2. Interview out-of-work designers and developers. I’ve been told that this group is large in Austin specifically. They may or may not be under gag orders, but again, talking in generalities about the development process seems like it should be fair game, particularly if I never mention the name of the interviewee, the companies they worked for, or the games they worked on.
    3. Interview open-source game developers. (both text-based and image-centric) They, by definition, are not beholden to “the man,” and should be able to freely talk about their development process,  their needs, attitudes, and tools. I’m also making the assumption that they work under the same conditions, with the same tools and and work processes as those within industry (but again, this assumption might be wrong – but anything I find will be interesting).
    4. Finally, talk to those players who have the ability to modify their games (this can be related to Second Life, or events like machinima). I don’t know if players have systematic methods or tools for modifying their games, or common attitudes towards creation and modification, but it certainly would be interesting to explore it more deeply. Additionally, interviewing players/modifiers  would be interesting from the “what is a creator when everyone can be a creator” point of view, as well as from a preservation perspective: “what is important to preserve: the original system or the ability to modify the original system in the same way that it was possible to modify it when it was originally available?”

    Any thoughts would be appreciated.