Ports and patches: Digital games as unstable objects

The digital game as a moving target

The preservation and archiving of videogames has become the subject of increased scholarly attention in recent years. Preserving Virtual Worlds (see McDonough et al., 2010), The Independent Game Developers’ Association Game Preservation Special Interest Group’s White Paper (Lowood, 2009), the European KEEP (‘Keeping Emulation Environments Portable’, see Pinchbeck et al., 2009) and the UK’s National Videogame Archive (see Newman and Woolley, 2009) are among the growing number of projects turning their attentions to arresting media decay and ‘bit rot’, the emulation of obsolete gaming platforms, and the documentation of the cultures of gameplay and development. Although each of these initiatives takes a different approach (see Guttenbrunner et al., 2008, 2010; Newman, 2011), one of the most significant challenges remains constant: videogames are hugely complex digital objects.

For those scholars operating in the field of game studies, this complexity is typically expressed in terms of the mutability of games and the transformative nature of play and performance. As Moulthrop (2004) has noted, play may be thought of as a ‘configurative’ practice that greatly influences what the game becomes as different players play in deliberately and unwittingly different ways. Perhaps some players exhibit a mastery inherited from previous gameplay experience while others flounder; some are simply lucky and breeze though sequences while others make carefully considered choices to follow a particular path collecting items or exploring every zone. Moreover, as a number of scholars have demonstrated (e.g. Ashton and Newman, 2010; Consalvo, 2007; Newman, 2008), gameplay often takes quite unexpected, unpredictable, emergent and even deviant directions as players probe at the boundaries of games sometimes to destruction by exploiting glitches, bugs and inconsistencies in gameplay. These distinct playing performances problematise discussions of games as static texts or even as definable sets of rules and systems. For, Morris (2003) the importance of the player’s (inter)actions and performances in shaping ‘the game’ leads to the designation of videogames as ‘co-created’ media.

For those engaged in the archiving, curation and exhibition of digital games, the contingency of play presents a clear challenge. Moreover, the various playings to which a game might be subjected are differently informed by prefigurative and regulatory materials such as walkthroughs, FAQs and reviews. As such, locating ‘the game’ as an object of curatorial attention becomes something of a task in itself, and perhaps suggests an approach to game preservation that is as much centred around gameplay as practice as it is games as objects (see Newman, 2011). However, while the configurative nature of play is a notable impediment to attempts to archive digital games as narratives or systems, it is far from the only one. Indeed, important though the notion of the game being always both in and at play is, it is one that is comparatively well-documented and, while far from being solved, can at least be incorporated into the problematic of the games preservation research agenda. In this article, I wish to highlight two further aspects of the videogame that render it an ‘unstable’ object. The points I raise here are less to do with the idea of performance or the changing nature of the game at and in play but rather focus on a more fundamental instability of the fabric of the game to-be-played-with.

As media that are routinely ported (transferred and translated to different operating systems and platforms with differing hardware and software capabilities), and patched (updated to fix bugs or modify gameplay mechanics), videogames often exist across multiple systems in multiple incarnations. As we shall see later, as a game is ported from one system to another, it gains or loses features or may have modifications made to its operation. Sometimes these missing, added or adapted features may be obviously significant, sometimes they are imperceptible to all but the cognoscenti of gamers, but missing, added or modified they remain, nonetheless. Similarly, as the game is revised, or ‘patched’, over time, its contours necessarily change perhaps leaving successful playing techniques impossible to execute and necessitating the development of new strategies and tactics.

My point here is that, before we get to considerations of the ways it is (re)configured through the performance of play, in fact regardless of whether it is ever played at all, a videogame is a potentially changing, unstable object. For Giordano (see Sterling, 2011), this ‘extreme fragmentation’ potentially undermines the entire project of game preservation. Perhaps part of the reason for this might be that many of these changes are often not formally documented or even recognised. Patches often take place ‘silently’ with a game code being updated online or via automatically installing updates while different versions of games distributed on disc or cartridge are incorporated into subsequent pressings or manufacture.

To demonstrate the impact of porting and patching games, I have chosen to focus on Sega’s Sonic the Hedgehog series. The first iteration of Sonic (hereafter Sonic 1) was released in 1991 for the 16-bit Genesis console (aka MegaDrive) and spawned many sequels and spinoffs. Such is the success and visibility of the title, even propelling Sonic to become Sega’s de facto corporate mascot, that it has been ported to a wide variety of console, PC and mobile gaming platforms.

Porting Sonic

Shortly after its release on the 16-bit Genesis console, Sega released versions of Sonic 1 for their 8-bit Master System and handheld Game Gear. Both of these versions bear marked similarities to the original title and capture much of the essence of the gameplay but, by virtue of the technical dissimilarities of the target systems, there are many immediately noticeable differences. Variations in graphics capabilities mean that the Master System and Game Gear versions lose much of the visual detail present in the Genesis version and, indeed, differ substantially from one another. Moreover, level design and structure deviate from the Genesis with only three of the original stages included in the conversion and the function of the Bonus Levels being altered to become points-scoring opportunities rather than being oriented around the collection of Chaos Emeralds as per the original. Crucially, while the 8-bit conversions retain Sonic’s roster of moves, the speed of the gameplay – one of its defining features – is significantly reduced. The differences between the 8- and 16-bit conversions are, in fact, legion and are researched and documented in the many Sonic fansites and in walkthroughs and FAQs (see Sonic Retro, 2004 –2011 or the Sonic News Network, 2005 –2012 for instance). However, these ports are of less interest to our project here as, while they share the Sonic the Hedgehog name, they are implicitly at least, conversions rather than literal re-presentations of the original title. As such, one could infer that the expectations of players might be managed and that, for the archivist, the 8-bit game would be considered sufficiently different to warrant consideration as a separate, though related, entity.

Things become more complex, however, when we begin to consider the bewildering array of platforms which have hosted ports of Sonic 1 in the 20 years since these first 16- (and 8-) bit titles. Sonic Retro lists 24 ports of Sonic 1 though this does not include the numerous unofficially published fan-made games or the unofficial, pirated or unlicensed versions of the title such as Somari which ported Sonic to the Nintendo Famicom and replaced the Hedgehog with Mario as protagonist. The 24 phone, mobile, console, and embedded TV player ports can be distinguished from Sega’s 1991 8-bit console conversions by the use of emulation. Each of these iterations purports not merely to capture the essence of the experience of Sonic 1 but to faithfully reproduce it by running the original code.

We might flag some immediately obvious issues at this stage. It will be clear to even the most casual of gamer that many of the aforementioned platforms and systems employ markedly different hardware interfaces. Some devices connect to televisions while others, such as phones and handheld consoles, have embedded displays (we should be mindful here of Montfort and Bogost’s (2009) comments on the importance of display characteristics such as CRT scanlines/colour bleeding and so forth and Bogost’s (n.d.) call for a ‘television simulator’). Control systems in these ports range from joypads with different configurations of digital/analogue sticks and buttons through to ‘classic’ iPod clickwheels and iPhone touchscreens. The marked change in the experience of controlling and playing Sonic given these variations must immediately call into question the singularity of a Sonic 1 game regardless of the code being run. However, if we delve deeper, we find yet more changes.

While its use of the clickwheel and comparatively small display might represent the most obvious ways in which the 2007 ‘fifth-generation’ iPod, iPod classic and ‘third-generation’ iPod nano port of Sonic 1 differs from the Genesis version, there are, in fact, many more changes to its gameplay, structure and design. The musical soundtrack differs from all but the 2010 Nintendo DS version as it is not emulated but instead streamed. As such, rather than the music dynamically accelerating when Sonic activates a speed boost and decelerating on exhaustion of the power-up, a new audio track is triggered from the iPod (or DS) memory thereby altering the aesthetic of the game. Perhaps of more impact than this are changes to the game’s saving system. Where the Genesis title offered only a minimal number of save points within levels and included no battery-backed memory to retain players’ progress between system power-offs, the iPod version implements an auto-save feature that saves progress at the beginning of any level reached. Moreover, where 3 lives and a sparse availability of ‘1-Ups’ marked the 1991 experience, the iPod player is offered an unlimited number of continues with which to progress though the gameworld. As Crawford (1984) noted, the nature of the ‘save-die-retry’ mechanism employed in a game goes a long way to contributing the sense of jeopardy and asks players to manage risk-taking and caution. To alter the savestate mechanic in this way might make the game more suitable for the kind of opportunistic gaming that mobile play engenders but it fundamentally changes its operation and necessarily affects how players approach its challenges.

This is by no means an isolated example and we need only look at comments on the iTunes App Store to note similar concerns in relation to the more recent iPhone/iPod touch ports of Sonic 1 as well as its sequel. Interestingly, for many players, the first iPod port has become the point of reference and the absence of a save function from the iPhone versions renders it a game in need of update:

Takes me back to the Megadrive I bought with my first bonus! Exactly the same game, but PLEASE PLEASE PLEASE add a save button! (22Kelbel, 2011)

The presence and absence of specific elements in the port is important in defining the scope of what the game may subsequently become through play. For instance, the debug or ‘Config’ mode of the Japanese Genesis version, which, as Surman (2010) has noted, reframes the relationship between player and game designer, is not universally available in Sonic ports. As such, the ludic possibilities afforded the player are limited and restricted in different ways in different ports depending on the specificities of their implementation, which are themselves subject to change over time.

Running the ‘original code’ under emulation might sound like a recipe for precise duplication, except that performance of the game is contingent on the ability of the host system to run the emulation software layer, the performance of that emulator (and the specific iteration running on the host) and the ability of this general purpose system emulator to accurately reproduce the particularities of this specific game. Factor in these variables and the scope for differing implementations across platforms becomes abundantly apparent. What we witness in many of the variations between ports might be explained as being the result of differences in execution which, from an archival perspective, might be noteworthy but ultimately not unduly troubling as the ‘original’ Sonic 1 cartridge/code retains its primacy (though see McDonough et al., 2010 esp. pp. 24–27 on the problems of deploying library and information services’ bibliographical frameworks in relation to videogames). However, even cracking this does not solve the problem entirely. Regardless of whether we consider the 16-bit version ‘the original’ and all other iterations ‘derivatives’, ‘facsimiles’ or ‘reproductions’ that achieve their goal with varying degrees of success (irrespective of the fact that these might be the only versions of Sonic 1 currently commercially available and that no rider accompanies their official distribution to this effect), one further question remains: which original 16-bit version do we mean?

Patching Sonic

Returning to the code of the ‘original’ release raises its own issues as in fact there exist multiple versions of Genesis Sonic 1. Although they are not formally differentiated, different cartridges contain differently patched versions of the code. Perhaps the most tangible consequence of the patching is found in the variable behaviour of the spikes encountered in levels such as the opening ‘Green Hill Zone’.

*BUG: In Sonic the Hedgehog 1, there is a bug with the hit system. Usually if you get hit, you flash for a few seconds and are temporarily invincible. But if you get hit and get knocked back, and land on spikes, you get hit again. This usually means you die since you don't have time to recover any rings after the first hit. The first hit may or may not have come from touching spikes – just getting knocked back onto spikes will kill you. This is a very annoying bug and it is one reason you must take special care to avoid spikes when you see them. Luckily this does not happen with anything else (lava, etc.). (Walker, 2003)

To complicate matters, where the use of emulation software that reproduces a 60 Hz NTSC audiovisual signal has become commonplace in delivering these ports, consistency in the emulated ROM is not so standardised. The iPhone version, for instance, uses the third (Japanese) ROM, while the Sonic Mega Collection released in 2002 for the GameCube offers as a hidden extra a choice between three different ROMs.

Different versions of Sonic 1

In Sonic Mega Collection, the version of Sonic 1 you play is the Japanese version. You can play the US version by pressing, on the info screen for Sonic 1, Up, Z, Down, Z, Left, Z, Right, Z. The American version differs in that the clouds don't move in Green Hill, there's no wavy water in Labyrinth, and the level select is in the wrong order. To play another Japanese version, which fixes the bug which makes you continue to take hits when you hit spikes even if you're flashing and supposed to be temporarily invincible, hit, on the same screen, Z, Z, Z, Z, Z, Z, Z, Z, Z, Up, Down, Left, Right. (SonicAD, n.d.)

It is important to note that it is not only the original game that is patched but also the various ports that have become the contemporary points of access for many players. The iPhone iterations of Sonic 1 (and 2) are cases in point and it was only with later revisions that Sega reinstated the level skip functionality that was integral to the (various) Genesis iterations. The level skip is by no means a trivial addition to the Sonic gameworld as it fundamentally alters the player’s ability to access levels non-linearly and perhaps even becomes the only means by which some levels are accessed at all. In the absence of the level skip feature, the progression and reward model is recast as wholly contingent on performance and prowess as Zone 2 becomes available only upon successful completion of Zone 1 and so on.

That the underlying codebase of a game might change over time whether in response to an identified bug or in order to (re)implement gameplay mechanics or features, clearly problematises the location of the object of study/curatorial activity. Ultimately, what is perhaps most significant about many of the patches that alter and adapt digital games is that they happen ‘silently’. Just as the different spike behaviours in Sonic 1’s different ROMs were quietly incorporated into new releases of the Genesis cartridge throughout the 1990s, so online updating and patching brings new aspects of gameplay to Sonic on contemporary console, PC and mobile platforms, while removing others. In many cases, players will be unaware of the implemented changes. Indeed, even where changelogs document modifications, players may be left with no choice but to update in order to maintain compatibility with changes in the underlying operating system, for instance.

Summary

Regardless of the details, the fact that the game changes over time leads to a situation where, depending on the time of purchase, the platform, the territory, the number of updates and patches applied, different players playing ostensibly the same game might necessarily enjoy different experiences in markedly, or subtly, different worlds. It might be overly provocative to declare that this fluidity of form, this mutability of code, and these variations in implementation, mean that there is no such thing as ‘a videogame’ but we must surely recognise that it is a real challenge to define exactly what we mean when we talk of Sonic 1, even if we seek to home in on the ‘original’ Genesis version. The problem for curators and archivists of digital games is that, like most other titles, Sonic 1 is inherently unstable. Mojang's Minecraft, for instance, was recently updated in such a way as to effectively redefine the genre in which the game resides, adding features and mechanics through the new ‘Survival Mode’ whose absence had been central to the game's initial design. As such, whether we consider Sonic 1, Minecraft or practically any other digital game, we must conclude that these are not clearly definable objects per se. Rather, each is part of an extensive, growing and mutating collection of many related objects that evolve over time often in undocumented and difficult to discover ways.