We raised the issue of emulation in our presentation at The National Archives a few weeks back and the question has arisen again with the news of the KEEP project so it’s probably time to share some of our thoughts on the subject and outline our position. This is very much a discussion piece that outlines a position towards emulation is not a definitive statement of the NVA’s position. As such, you should feel free to chime in on the discussion, tell us why I’ve got it all wrong or, heaven forbid, that you agree – community participation is a cornerstone of The NVA and we’ve been very clear from the outset that all of our work should engage with the perspectives of as wide an array of constituencies as possible – and that includes, academics, developers, journalists, and gamers of all types.
[Note: I should be clear at the outset of this position document that any discussion of 'emulation' refers to the currently available array of videogame emulation software such as MAME or the myriad freely-downloadable console emus and not to any bespoke, tailor-made emulation system such as that proposed by projects such as KEEP. It is important to make this distinction at the very outset of the project a few of the issues raised below could, perhaps, be deal with, or are perhaps a consequence of, different approaches and techniques.]
We have a somewhat ambivalent attitude towards emulation.
In one sense, our position on emulation is a very simple one. It’s truly fascinating. I’ve written a little on the subject in my most recent book on videogame fan cultures and, like any observer of the phenomenon, have been constantly overwhelmed by the sheer amount of individual and collective effort that goes into the creation and maintenance of videogame emulators. As (reverse) engineering projects, these are constant reminders of the rich, diverse and ultimately supportive nature of videogame culture. And, in one sense, this is how we see emulation – as part of the vibrant, complexly-contoured space in which videogames are celebrated and kept alive – as part of videogame culture. Without doubt, there is much to be learned from emulator programmers, alpha and beta testers and this productive work sheds much light on the richness of fandom while their use signals the voracity with which the ‘old’ games are consumed long after they have gone from retailers’ shelves and marketers’ mailouts. It goes without saying, then, that like other areas of fan production, the emulation scene is one that we consider to be important in shaping gaming culture and, therefore, is one that must come under the purview of The NVA.
So far so good. Where emulation is more problematic for us, however, is where it becomes a tool for archiving and exhibiting videogames. Why is this? Emulation seems like an ideal, almost purpose-built, mechanism for dealing with disparate formats. By turning a generic PC or Mac into a whole host of different platforms, we immediately sidestep the very real issues of original hardware breaking down (assuming we can even locate and acquire it in the first place). The reliability and longevity of these machines is a very significant issue for us. Hardly surprising – if this stuff was ubiquitous and lasted forever what would be the point of an archive? But, while the ease and convenience of emulation is appealing, there are a number of issues that make its use problematic. For the purposes of this discussion, I am going to set aside questions of legality in relation to the ownership and generation of ROMs and concentrate instead on investigating how emulators might be useful and, perhaps, challenging some of the presuppositions about what emulators really are.
Let’s start by asking the simplest question. What does an emulator emulate? The most facetious answer is that it depends. Not least, it depends on the ambition and coverage of the specific emulation project. Some emulators target a particular piece of hardware (the MegaDrive/Genesis, the Atari VCS etc.) while others aim to be more all-encompassing with projects such as MAME covering multiple chipsets and hardware configurations. PC/Mac videogame emulators such as Generator and Genesis Plus do a wonderful job of bringing 1990s classics like the Sonic the Hedgehog to desktop PCs. Indeed, from a European PAL-MegaDrive owner’s perspective, we might even say that the emulator offers some significant advantages over the original as the readily- (if not wholly legally-) available NTSC ROM of Sonic the Hedgehog allows European gamers to enjoy full-speed gameplay, music at the correct pitch and tempo, and no ugly black letterboxed borders (unless, of course, you download Sonic the Hedgehog from Nintendo’s Virtual Console where the unoptimised 50Hz conversion remains the version on offer). We might argue that the NTSC version is that which was intended by the game’s designers and as such should be considered the canonical version although given that countless millions of European gamers’ experience was of the demonstrably hobbled conversion, surely this, imperfect as it may be, is the version that has cultural and historical resonance and meaning in this context. This variation in the localised versions of a single title and the comparative ease with which contemporary gamers can gain access to and knowledge of them, highlights another, related issue of course. When I talk about ‘Sonic the Hedgehog’ or ‘the ROM’, I am in fact referring to a range of artefacts. 60Hz Sonic is not the same as 50Hz Sonic just as the first release is different from the ’2.0′ revision that addressed an inconsistency in the bevahviour of the spikes in the Green Hill Zone that put paid to Sonic even if he was temporarily invincible following an earlier hit (in the original release, when struck in mid-air, invincibility was not gained immediately but only after Sonic’s feet hit the ground).
But, even though the game itself might change throughout it’s life in different pressing or releases or may even be quite clearly changed for release in different markets as it is tailored for different preferences or cultural norms, the game system remains constant, surely? Unfortunately, things are not quite so simple. Hardware revisions that occur throughout the life of the given platform often have noticeable, usually wholly unintended and sometimes wholly undesirable, impact upon performance. The variations in the tonal quality of the SID-chip filters across various revisions of the Commodore 64 home computer are well-documented and make a particularly good example given the legion of fans of C64 game music for whom the work of Rob Hubbard, Martin Galway, Ben Daglish et al. is their classical music (see the High Voltage SID Collection for some extremely tuneful examples). As you can hear, the Sega MegaDrive/Genesis sound mixing systems went through similar revisions that subjectively degraded the audio quality on later models. Where there are variations in the target hardware that have qualitative and experiential impacts on the output of the system, which version does the emulator address? Is the version declared or even offered as a choice to the user? Let me be clear, these are not criticisms of any particular emulator. Rather, my questions here demonstrate my sensitivity to the difficulty of the broad project of emulation when that which is to be emulated is not stable and static in itself.
From our point of view as videogames archivists and curators, the issue over what is emulated is almost of secondary importance when we begin to consider what isn’t. Let us be clear. Regardless of one’s opinions on the merits of any given project, a MegaDrive emulator is not a MegaDrive. I make this point as a simple matter of fact and I am well aware that few, if any, would wish to claim otherwise – emulator creators included. However, let me explain precisely what I mean and why the distinction is important in our work. The most immediately obvious distinction between the MegaDrive and the MegaDrive emulator is the controller. The physical hardware interface and, in particular, the joypad. Emulators are great at turning the 64-Bit Dual Core chips in a current Mac or PC into something that behaves like a Motorola 68000, but they can’t turn the keyboard into a MegaDrive pad. Clearly, players can buy additional or alternative pads to replicate the functionality of the original controller. The availability of such peripherals and adaptors may offer one way to sidestep one issue, but the questions remains as important when we consider the huge variety of other, non-generic joypad interfaces that grace consoles and coin-ops. What about the integrated buttons and D-pads of handheld gaming devices like the GameBoy or the bespoke hardware of coin-op cabinets with wheels, pedals, light guns, skis…? These pieces of hardware are integral parts of the gaming experience. PropCycle demands its preposterous, audacious bicycle as Wii Fit requires it Balance Board and Rock Band it’s guitars, drums and mics. Sega’s R360 fairly ably demonstrates the centrality of the interface and the impossibility of recreating its viscerality through emulating code or audiovisuals alone.
If we’re going to ‘emulate’, we need to emulate the whole game and recognise that the meaning of the experience flows through these interfaces. Anybody familiar with Nintendo’s Virtual Console will be aware of the generic ‘Classic Controller‘ peripheral and its attempt to provide the functionality of a range of different controllers from NES, through MegaDrive to N64 and Neo Geo. As a single piece of equipment, it is a neat, convenient solution but it is not a substitute for the original controllers an games feel substantially different as the buttons on the Classic Controller are a different shape, have different resistance and travel, and fall slightly differently under the hand.
While we firmly believe in the importance of the integrity of the ‘original’ controller, we are aware that there is (at least one) serious flaw in this argument. Just as the ‘authentic’ Sonic is difficult to pin down, few consoles have ever specified a particular joypad. Certainly, they usually ship with one (or more), but there is little to prohibit and often much to encourage one to purchase a different, perhaps more specialised (fighting stick, steering wheel), more feature-packed (remember ‘autofire’ and ‘slo-mo’ pads?) or just plain bigger and more impressive (X-Arcade anybody?). So, we have a problem. Which Sonic? Which pad? Clearly, the sheer number of third-party peripherals makes it impossible to talk about the definitive hardware interface for any console so we have to make compromises and arrive at best-fit solutions. It is worth reiterating here that the NVA is not a completeist collection and so it is not our intention to acquire examples of every peripheral for their own sake and so our choices of hardware interface will be governed by judgements about the integrity of the experience and the representativeness of the setup in the context of the story we are seeking to tell.
We should remember also that videogame emulators often make use of tricks and hacks to improve performance and/or compatibility that necessarily impact upon the integrity of the playable experience. Perhaps the most obvious example is the skipping of frames to improve the performance of playback of complex games (or even of particularly processor-intensive sequences of games where the emulation struggles and demands more horsepower from the host system than it can readily provide). As such, games that may have played at a smooth 50/60 Hz in their original incarnations may have their refresh reduced thus impacting on the visual and visceral complexion. In some cases, depending on the emulator or the configuration, the frame rate may be dynamically adjusted bringing the game to a judder in certain places. Now of course, ‘slowdown’ is not a feature unique to emulation and the original hardware may well have experienced similar problems. Indeed, throughout the 8- and 16-bit eras, slowdown was rife as CPUs strained to near-breaking point to fill the screen with sprites. However, even though slowdown may (still) be an endemic part of gaming and indicative of the compromises and tradeoffs between creative ambition and technological capability that are inherent in any design work, the issue for us is about the replicating the original slowdown (along with all the other imperfections, quirks and vagaries of the original game running on its (evidently sometimes inadequate) platform.
[Image credit: http://www.gameandwatch.com]
It is important to remain constantly mindful of the huge impact minute variations can have on the experience of a videogame and how attentive and unforgiving we as players can (and perhaps should) be to such inconsistencies. Some years ago, I purchased a Game & Watch Gallery cartridge for the GameBoy. Now, technically, these games aren’t emulations per se and are perhaps better described as remakes or even simulations of the original LCD games that I grew up with in the 1980s but, nonetheless, they illustrate the point quite well. Among the titles on this collection was Donkey Kong. I had, in fact still have, an original DK-52 Donkey Kong Game & Watch handheld, so I know the game pretty well. Indeed, and perhaps indicative of my destiny as a games archivist, my DK-52 remains in its box complete with polystyrene insert and instruction manual. I was excited to relive Donkey Kong in a more convenient form on my shiny new GameBoy but was almost immediately disappointed. This was Donkey Kong alright. It looked like Donkey Kong (as far as the GameBoy display could given the fundamental differences in display technologies between the two systems), and it sounded like the game (though it looked more like it than it sounded like it to my eyes and ears). But still this wasn’t the game.
The cause of the problem was as small as it was massive: the rhythm was wrong. Let me explain. Every time Mario and the barrels move in Donkey Kong, they each make an audible blip. The barrels move on their own (or rather, they move in accordance with the rudimentary physics model which dictates that everything moves down the slopes). Mario, under the player’s control, moves with the D-Pad. Holding down one direction of the D-Pad makes Mario run. That is, he moves position in accordance with the rhythm of the game (which gradually increases in tempo as progress is made). Seasoned players of Donkey Kong will know the distinctive, Steve Reich-like phasing polyrhythm of the barrels and Mario blipping their collision-course paths across the screen. Indeed, true connoisseurs of the game will soon learn judge their jumps according to the audio cues of this minimalist composition more than they will rely on reading the visual especially once the pace picks up. The poorly-quantized, dissonant truth of the GameBoy version of the game was that the rhythmic beating of Mario against the barrels is not offset in the same way as the original. The result is not only a qualitatively and aesthetically different one, but one that robs the player of part of the fundamental tools of interaction and feedback. The result is a different game. Minutely different. Utterly different. Wholly enjoyable as a game of Donkey Kong. Wholly unacceptable as a version of DK-52.
I was reminded of this story recently when I came across a fascinating comparison of the 360 and PS3 versions of Street Fighter IV (see also Eurogamer’s comparison screenshots gallery).
Such debates about consoles and the ‘best’ platform are as old as games themselves and platform loyalty is one of the bedrocks of videogame fandom and culture. This was no partisan, ‘fanboy’ ranting, however. This was a carefully and skilfully constructed video showing – in split-screen – identical sequences from the two (con)versions of the game allowing detailed analysis of the impact of the PS3′s lack of full-frame anti-aliasing and its dynamically-shifting 720p-630p resolution. The sheer level of commitment and effort that is entailed in producing a video analysis of this kind will be immediately evident to anybody who has attempted to lift, let alone read, the manuals for Final Cut Studio. This hugely compelling and insightful piece of work is invaluable in its own right but, perhaps more importantly for our purposes here, it speaks volumes about the meticulousness, passion, care, affection and knowledge of gamers. Ultimately, what is essential to remember is that, analysis such as this are not motivated by a desire to reveal only the technical but rather to understand and explain the impact of the technical on the experiential. The point of the Street Fighter IV video comparison, as I read it, is to evaluate the consequences of anti-aliasing on gameplay experience. It’s all about the game and the game is all about the gameplay.
Given the enormity of the impact of even minor inconsistencies in conversion and emulation on the playable experience of the game and the more general issues surrounding the scope, literal, theoretical and practical potentialities of emulation, our position at The NVA remains one that, where possible, offers primacy to the integrity and purity of experiencing ‘the original’. Let us not forget also that, beyond our discussion of the uses and limitations of emulation, the original object, the original work of art has its own aura and that there is something special, distinctive, moving and powerful about being in its presence. Even in an age of digital reproduction.