Preserving Games

Author: walker

  • 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.

  • Making the Water Move: Techno-Historic Limits in the Game Aesthetics of Myst and Doom

    Hutchison, A. (2008). Making the Water Move: Techno-Historic Limits in the Game Aesthetics of Myst and Doom. Game Studies, 8(1). Retrieved from http://gamestudies.org/0801/articles/hutch

     

    This 2008 Games Studies article examines the effect technology (or the “techno-historic” context of a game work) has on game aesthetics. The author defines the “game aesthetics” as “the combination of the audio-visual rendering aspects and gameplay and narrative/fictional aspects of a game experience.” It is important to note that audio-visual aspects are included in this definition along with the narrative/fictional components. This is because the author later argues that advancing audio-visual technology will play an important role in advancing the narrative aspect of games.

    The article begins with a comparison of two iconic computer games of the mid 1990s: Myst and Doom. Specifically the design response in each game to the technological limitations of PCs at the time is examined. Very briefly, we see that Myst takes the “slow and high road” to rendering and first-person immersion, while Doom adopts the “fast and low road.” As the author explains, each response was prompted by the limitations of rendering that a personal computer could perform at the time. For its part, Myst’s design chooses to simply skip actual present-time 3D rendering and use only pre-rendered, impeccably crafted (at the time) images to move the player through the world. Minor exceptions exist when Quicktime video is cleverly overlaid onto these images to animate a butterfly, bug, moving wheel, etc. This overall effect very much informs the game’s aesthetic, as anyone who played the original can recall. Myst is a quiet, still, contemplative and mysterious world. Continuous and looping sound is crucial to the identity of the world and the player’s immersion. Nearly every visual element is important and serves a purpose. The designers could not afford to draw scenes extraneous to the gameplay. The player’s observation of the scenes available is key, and the player can generally be assured that all elements in the Myst world warrant some kind of attention. Hardware limitations of the time, such as the slow read time of most CD-ROM drives, serve to reinforce this slow, methodical gameplay and visual aesthetic.

    Doom by contrast uses realtime rendering at the expense of visual nuance and detail. Doom achieves immersion through visceral and immediate responsiveness, and its aesthetic is one of quick action and relentlessly urgency. The low resolution of the art and characters is compensated by the quick passing of those textures and objects, and by the near-constant survival crisis at hand. Redundancy of visual elements and spaces is not an issue: the player can face down hordes of identical opponents in similar spaces (sometimes the exact same space) and not mind at all because the dynamism of the gameplay is engaging enough to allow such repetition. Pac-Man had the same strength.

    From this comparison the author goes on to speculate how techno-historic limitations inform aesthetics in general, and whether the increasing capacity of personal computers to render audio-visual components in extreme and realtime detail will inform the narrative/fictional aspects of games as well. One only needs a passing familiarity with games to know that this aspect of games has been widely disparaged in the media and in some academic writing. Some quotes the author uses to characterize the degenerative trend of popular media and the game industry’s complicity in the coming intellectual apocalypse:

    Perhaps lending strength to this phenomenon is a current popular culture stylistic trend which emphasises “spectacle” over narrative and gameplay. Peter Lunenfeld has identified this broad movement in popular culture generally:

    Our culture has evacuated narrative from large swaths of mass media. Pornography, video games, and the dominant effects-driven, high concept Hollywood spectaculars are all essentially narrative-free: a succession of money shots, twitch reflex action, and visceral thrills strung together in time without ever being unified by classic story structure (Lunenfeld, 2000, p.141).

    And more specifically dealing with games:

    “It is a paradox that, despite the lavish and quite expensive graphics of these productions, the player’s creative options are still as primitive as they were in 1976” (Aarseth, 1997, p.103).

    Most interesting is the observation that richer media capabilities does not necessarily translate to glossier, superficial renderings. Richer media can mean a more meaningful experience for the player. Nuance and subtlety can be introduced, more information-rich media can mean more powerfully conveyed characters and a more fully realized narrative.

    On top of this, one can expand the definition of “story” and “narrative” as id developer Tom Willits argues in this Gamasutra report:

    “If you wrote about your feelings, about your excitement, the excitement you felt when new areas were uncovered [in Doom] — if you wrote it well, it would be a great story,” Willits says. “People call it a ‘bad story,’ because the paper story is only one part of the game narrative — and people focus on the paper story too much when they talk about the story of a game.”

    Information, he maintains, is learned through experiences, and the experience of playing a game is what forms a narrative, by its nature. Delivering a story through the game experience is the “cornerstone” of id Software’s game design, and the key when developing new technology.

    Whatever your opinion on what constitutes story and narrative in media, the author of this piece has made a compelling argument that advancing technical capabilities could directly inform the narrative/fictional aspect of a game’s aesthetics, and certainly has done so in the past.

  • 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…)

  • What Went Wrong? A Survey of Problems in Game Development

    Fábio Petrillo et al., “What went wrong? A survey of problems in game development,” Computers in Entertainment 7, no. 1 (2, 2009): 1-22.

    This February 2009 article from the Computer in Entertainment magazine of ACM takes a look at the game industry and compares its difficulties to the larger software industry. Specifically the authors analyze twenty postmortems from the archives of Gamasutra.com to characterize the problems that plague game development. I believe Gamasutra has discontinued this series but postmortems are still published by sister publication Game Developer.

    A postmortem “designates a document that summarizes the project development experience, with a strong emphasis on the positive and negative aspects of the development cycle.” After reviewing the literature discussing problems present in the software industry, the authors begin to analyze the problems described in the postmortems. The games covered and the problems identified and quantified are in a table that describes the number of occurrences and overall frequency (click for larger image). Note: sometime in the future (the Web 2.0 future?) I would provide a link to the actual dataset rather than a .PNG  showing you a picture of the dataset.

    =Occurrence of Problems in the Projects
    Occurrence of Problems in the Projects

    The authors’ categories provide a helpful navigation to the issues that arise in a game development project. As they note, this study sees the most cited problems as unreal or ambitious scope and features creep, both constituting 75% of all problems described. Notable for game archivists is a 40% frequency for the lack of documentation problem as well. The authors note low occurrences for crunch time and over budget (25%), both “said to be ‘universal.’” It’s difficult however to draw expansive conclusions from a small dataset. Moreover postmortems were not team projects or collaboratively written, rather a single participant is responsible for the postmortem. The authors usefully provide other limitations to put the data in context.

    The authors conclude that the electronic games industry does indeed suffer from problems in the larger software industry (overly ambitious plans and poor requirements analysis) as well as woes peculiar to itself: the first to experiment with new technologies, tool problems, and collaboration between disparate professionals, among others.

    On a final note, the postmortems are still available at Gamasutra, and they are really fascinating reads. It really becomes clear just how young an engineering and creative discipline digital game-making is, and how much fluctuation there is in how a game turns out. There are some great examples and stories there; the authors of this article cite quite a few of them.

  • Space Invaders


    Space Invaders unit decoration, and an early example of inaccurate promotional art for videogames (space werewolves not present in-game).

    Space Invaders is iconic. You need only look at UT’s own Videogame Archive logo to get a feel for the pervasiveness of its visuals and the sort of shorthand it’s become for videogames in general. Back in 1977 game developer Toshihiro Nishikado began work on Space Invaders, creating by hand the hardware necessary to programming the game. What happened after its release in 1978 is now gaming history, so I decided to take some time to find and play the most “original” version of Space Invaders I could find.

    Of course here we enter shaky grounds. The most original version might be a Japanese black-and-white cocktail table unit with woodgrain sides, largely unadorned, with a two-way joystick for control. Or you might consider an upright unit with movement buttons and two cellophane strips (for coloring sections of the screen) to be original enough for your purposes. A bibliography of Space Invaders’ complete gamut of ports, bootlegs and revisions would be a very considerable undertaking.

    For the curious person not willing to seek out original units, emulation is the natural way to go. The best general site I’ve located for getting a handle on the multiple versions of the game is CAESAR, which will often sport all kinds of image captures (logos, units, screenshots) of various versions of a game. The best general emulator for arcade games is MAME. Though presently only a 0.131 release, it’s very functional and well-polished, and is available for Windows and Linux users. I used an OS X port of the project, MAME OS X.

    The other bit of shaky ground are the disk images, or ROMs, themselves. ROMs are full data captures of read-only memory chips, in our case arcade memory chips. Theses files are what the emulators read to generate a copy of the game on a personal computer. Arcade ROMs are available at many sites like ROM World, but it should be noted that copyright restrictions are still in affect for some properties.

    To sum up: search for the ROM you want at ROM World or a similar site, run MAME and load this ROM, and if you like, go to CAESAR to try and determine exactly which version you’re playing.

    A word of caution: playing ROMs with emulators is presently in the realm of the hobbyist, and as such all the kinks are not ironed out. You may run into problems trying to play certain ROMs. Your ROM, which contains several different files, may be missing some critical ones needed by the emulator. This is because another version of the game, or another game entirely that uses some of the same instructions as the ROM you’re attempting to load, will have those files instead. In that case you’ll need to download those files as well. If you encounter this problem you may consider downloading all the versions of the game, or go to an emulation forum to try and determine which ROM package will have the files you need. Aracde@Home, an excellent resource itself, has very active forums.

    Logitecs bootleg of Space Invaders
    Logitec's bootleg of Space Invaders
    CV's version of Space Invaders

                   
    On to Space Invaders. I played two different versions: Logitec’s 1978 bootleg of the title, and the “CV” version (though I still haven’t found what that stands for), also 1978. Both versions use actually-colored pixels to emulate the cellophane-colored screens of the original units, and as you can see, the CV version emulates more strips of cellophane than the bootleg, though I prefer Logitec’s sparser color scheme. I imagine it to be closer to the real thing.

    Gameplay has been described as simplistic by today’s standard, though I don’t find this to be entirely true. While Space Invaders certainly features simple dynamics and play, these aren’t necessarily any simpler than other shoot ‘em ups today. There’s strategic use of cover, nimble placement of your fighter to hit the sides of the invaders rather than the center (opposing shots cancel each other), and careful picking off of invaders at the extreme left and right to increase across-screen travel time for the invaders.

    It’s rather the (slightly) slower pace and lower visual stimulation, as well as the less frequent positive reinforcement Space Invaders provides that elicits the simplistic descriptor. Witness the debilitating addiction afforded by PopCap’s recent release Plants vs. Zombies to see how keenly some game developers understand the elemental appeal of well-polished and finely honed reward systems.

    But along with the pleasant explosion-graphic of the somewhat aquatic-looking aliens, Space Invaders has the high score reward, the only indication you have that you were ever there, and the only way to “win” the game. Space Invaders tugs at what must be a basic need to hold out as long as possible against impossible odds. The story ends the same way every time: the space invasion is a success, and you’re dead. But for the few seconds that Space Invaders captures your attention and you’re still alive, you are wholly in its web.

    Developer Harvey Smith noted in a talk that the arcade genre distills games to the most basic and demanding mechanics. In place of compelling characters, story, writing, acting, and perhaps graphics as well, are the fundamental draws of satisfying character control and incentives. An arcade game’s world, its limitations and the role the player has within it must be intuitively grasped. Space Invaders still succeeds on all these points, and its 30+ year-old mechanics are still solid, cohesive and rewarding. I can only imagine how much more entertaining the game would be with a joystick and big red fire button.

  • Spawn Labs and Mobile Gaming

    When I think of mobile gaming, whether it’s on a laptop, iPhone or other device, I think of games sensitive to the processing constraints of those platforms: web-based items like Bejeweled or Tower Defense, a retro-graphics piece like Battle for Wesnoth, etc. The latest games on the PS3, 360 or Wii do not come to mind.

    Peter Walker of Spawn Labs and Vircion Inc., based out of Austin, gave a talk last week for the Texas Advanced Computing Center that explained the company’s plan to break this mold in the realm of console gaming. Their ambition is to allow gamers to play their console games on any computer at any location. The central idea behind this technology is that remote servers will handle the processor-intensive rendering of graphics and other game computation, sending an audio/video stream of the processed results to the user’s computer. That would allow the client’s computer to strictly handle those AV streams, rather than be responsible for the serious number-crunching. Gamers would essentially be playing the AV streams of the processed results, which would be dictated by whatever input the player sent to the server.

    Walker identified some trends in gaming: gigabyte requirements increase, as do CPU and GPU processing requirements. Moore’s Law seems to be in full effect. But Walker points out that cooling power can’t keep up. Already an increasing percent of battery power is spent just cooling the processing chips. As a result mobile platforms like laptops simply cannot pack the cooling power necessary to run resource-intensive games (at least not without burning your lap). Walker points out the success of smaller-scale games, but notes that these are a different kind of gaming experience, casual and less time-intensive than the likes of Call of Duty 4 or Mass Effect, and constitute a gaming experience of a different order. Spawn’s research is aimed at bringing the gaming experience of the most graphically intense console works to a mobile community.

    This is achieved through utilizing the increasing pervasiveness of broadband and the efficiency of audio and video codecs, specifically the H.264 standard. Key to this standard is the Scalable Video Codec. This would allow the client computer to select whichever particular bitstream it was set up to decode, among the many a gaming server would offer. That allows a gaming server to only encode and transmit once and simultaneously support a range of client machines with different codec-decoding capabilities.

    So what could all this mean for game preservation? Well, in a certain sense it will make the job much more challenging. Technology like this continues the trend of client computers handling less and less of of the actual content. In this model, gamers are essentially reacting to, and playing in, a movie (the AV stream) that their input incurs. Very little of the game’s actual binary content resides on the gamer’s computer. Compare this to a classic like Ultima 4, where a considerable preservation step is accomplished by possessing uncorrupted copies of the original 3.5” or 5.25” disks. Move ahead to World of Warcaft: the client side CD contains a lot of code and information, but a very large part of the game itself is not to be found there. In the model being developed here, gamers could possess even less of the binary makeup of the game, and might simply purchase a license to play the game. That leaves the individual’s personal game material as a minor component of preservation.

    At the same time, it’s a fascinating model for more flexible, platform-agnostic gaming, and it could point the way to interesting methods of preserving games. After all, if gamers could be happy interacting with a dynamic video stream, perhaps a preservation effort could employ a similar approach. If nothing else, the success of a model like this might open up the possibility of remote access to actively preserved games.

  • What Story? Reporting a MUD-Dev Thread from April – May 2000

    From August 22, 1996 to the early October of 2004 the MUD-Dev mailing list housed a slew of earnest and lengthy discussions — technical, philosophical, design and otherwise — concerning the development and play of multi-user dungeons (MUDs). 

    MUDs were developed before graphics-capable computers, originating and remaining entirely text-based. Players type commands, role-play or just socialize through the keyboard. Gameplay ranges from hack and slash to interactive fiction to simple chat, with all sorts of degrees of role-play in between. MUDs are often discussed as the precursors of today’s MMORPGs, and therefore an early index of the concerns and goals of those MMORPGs by at least 10 years. But MUDs are by no means a dead genre. New MUDs, and players for them, are continually coming into play.  

    The MUD-Dev archive is available at Raph Koster’s site as a bundle of distinct HTMLs, or right here at the School of Information on a single (very) large page with the messages hyperlinked and separated.

    I’ve taken a look at the threads “Procedural Storytelling” and “A footnote to Procedural Storytelling”, which had sprung off from an earlier discussion, “Self-Sufficient Worlds”. The topic, broadly, concerns the art of storytelling in MUDs and more typically, how to generate them automatically on a large scale by abstracting them. Instead of doing a play-by-play of the discussion, I thought a report of the salient ideas and contentions would be more digestible.

    (more…)

  • The Other Side of Games

    Games can be anything. Implementation is certainly restrictive, but design potential is basically limitless. Because of this potential it’s very likely that a great many game elements are cycled through before a final set is decided upon. It may be then that a game can be better understood by what it is not rather than by what it is. Seeing the other side of design decisions can add immense value to the elements that were implemented. Here are a few categories where the “other side” can be seen:  

    • Alternate or developmental versions of game elements. These could be versions of character designs, plot (dialogue, events, etc.), art, setting, or different design parameters that would change gameplay. What’s key here is that these elements have a counterpart in the actual game, whether it’s a different version of the element or a similar element designed for the same purpose. 
    • Elements developers left out. This can range from game play features to a truncated story to a smaller graphic set. They could come in two forms: elements that had been coded and pulled or elements left out of code but manifested in other creative materials. Key here is that no version or comparable elements exist in the game. 
    • Deliberately disposable elements. These are elements designed to help developers work through ideas, flesh out game dynamics, test functionality, etc. Molyneux’s development model in this interview is a good example. Here he explains the testing modules the development team used to pilot their ideas. 

    Keeping an eye out for the “other side” is naturally desirable in collecting and preserving, but it has other benefits as well. It is invaluable in bringing the story of a game’s design into a fuller light. Lost elements are a crucial component of the game-creation narrative in that they complete our view of the decisions that made the final product. You could argue that there is no story without them. 

    Lost elements also help in retaining and marking ideas that would otherwise go under the radar. Those ideas are often borne out in player modifications, and in the case of MMO’s, added ad hoc by player-designed limitations and role playing. In this way the story of an idea is more fully recorded.

    The ‘other side’ can show up in any way developers talk to each other or to publishers, distributors and fans: conversations, design documents, images, mockups, prototypes, and so on. Materials of this sort could even fall outside certain IP restrictions if an element is deemed not part of the game proper.