On Desynchronization
Support my writing on Patreon or Ko-fi!
The function of an arcade attract mode is simultaneously pedagogic and economic, operating as both pseudo-tutorial and pseudo-advertisement. The convention eventually made its way to home consoles, but due to the privatization of the play space was redubbed a demo(nstration). The attract mode/demo is a cousin to the PC screen-saver, both indicating that interaction with the computer has temporarily ceased, though the screen-saver obviously serves an additional practical purpose i.e. “saving” your CRT screen. But how do attract modes work? How does the apparatus animate its puppet theatre without the player–the one who ostensibly pulls the strings? Without delving into source code to say for certain for any particular example, I see five possible implementations: recording position/state, recording input, hard coding input, deterministic artificial intelligence and recording video.
Recording position/state is an unlikely candidate for many attract modes/demos, as it involves storing the precise avatar coordinates and animation sequences for a given gameplay performance. However, this method is likely used in other contexts such as games that feature doppelgangers that mimic player movement, instant replay features or temporal rewinding. Recording input is a more common solution, essentially creating a recipe for avatar movement that is then able to be replicated on demand, similar to a tool-assisted speedrun. Hard coding input is the same principle, however instead of setting up a dedicated recording feature the programmers feed input values manually via code. Deterministic AI is also an option, provided that there is no randomness in the game. Finally, on more modern consoles with video playback capabilities it is more logical to capture the game output and edit it together in some external software suite.
Of these five implementations the one that fascinates me the most is recording input, one reason being that it allows for the possibility of desynchronization. In videogames the term desynchronization is typically used in the context of fast-paced online multiplayer games such as shooters, and while this phenomenon is interesting in its own right the distributed nature of the computation involved almost invites its inevitable failure. More interesting to me are games in that technological sweet spot of the Nintendo 64, where input recording techniques were employed but unstable enough for the possibility of desynchronization (this is not to besmirch the N64, in fact one of my main examples is exclusive to an Xbox 360 port).
In the time trial mode of Mario Kart 64 both the ghost feature and the instant replay feature have the potential to desynchronize. In Super Mario 64 a glitch called spawning displacement can be used to alter the starting point of Mario’s journey through the demonstrations. As pannenkoek2012 demonstrates, hypothetically if a star were collected by Mario due to this altered trajectory it would count as if it were collected normally in File 1 of the game. Lastly is what the Banjo-Kazooie speedrun community calls the Demo Desync Adventure (DDA) for the Xbox 360 version of the game. Essentially what happens is that the demonstration wrests control of the camera for a single frame upon loading a level. If down is held on the right analog stick of the Xbox controller when the Rusty Bucket Bay demo loads, the change in camera position will cause Banjo to walk off a platform and die, since Banjo’s movement is camera-relative. This will cause Banjo and Kazooie to respawn at the start of Rusty Bucket Bay, with all the moves unlocked, saving a massive amount of time in Any% speedruns. I see a disjointed parallel between the desynchronized demo and the screen-saver’s efforts to deter ghosting of a different sort; where desynchronization is the corruption of movement through the activation of software glitches, screen-savers are movements to avoid the corruption of hardware due to inactivity.
DDA also has me reflect on a much-employed concept within game studies: ergodicity. As Espen Aarseth writes in Cybertext, ergodicity is “a term appropriated from physics that derives from the Greek words ergon and hodos, meaning ‘work’ and ‘path.’ In ergodic literature, nontrivial effort is required to allow the reader to traverse the text.” Right away I must put pressure on the concept of ergodicity on the grounds of disability, as what is trivial for one person may be nontrivial for another. Another critique of ergodicity as applied to videogames comes from James Newman, who points out that the medium is replete with moments of non-interaction, such as cutscenes, and proposes a different dichotomy of “On-line” and “Off-line” (essentially meaning whether a player is inside or outside a game’s feedback loop). In Aarseth’s defense, there is nothing in his definition of ergodic literature that says the text must be defined by nontrivial effort at all times, and others argue that ergodicity is not sheerly about registering input with a computer but about the player’s disposition to act eventually. Although Newman’s essay has a misguided anti-representational bent (which ironically often finds him saddled with Aarseth and other “ludologists”), one of its key insights is how he conceptualizes player control as a continuum rather than a binary.
What does the Demo Desync Adventure look like through the lens of ergodicity? By Newman’s account, an attract mode/demo is surely an Off-line aspect of the videogame, to the extent that input from the player is often hailed in an appeal to commence ergodic participation. But in the DDA glitch for a single frame there is the potential to intervene in the otherwise scripted affair. Does this make DDA ergodic? Perhaps. However, one could hypothetically use a “prepared” controller that holds down the right analog stick at all times to achieve the same effect, albeit slower. This would transform Banjo-Kazooie into a non-ergodic text (pre)determined by Off-line input, one that concludes with Banjo standing in place at the start of Rusty Bucket Bay.
While the speedrunner’s motivation in using DDA is always ergodic, there is another method of achieving desynchronization in Banjo-Kazooie: lag. This can be done on the N64 in one of Bottles’ puzzle challenges by using a code to unlock the red Stop ’N’ Swop egg (see fourth link above). When Banjo walks into the egg and collects it, it produces a bevy of particle effects, causing lag which desynchronizes his movements. Importantly, because this all takes place within the puzzle minigame, the desynchronized movement constitutes its own unique set of states and not merely an automatized reproduction of other possible states within the regular game. What this method of desynchronization suggests to me is that ergon/work has been over-emphasized in the concept of ergodicity, above the more relevant aspect of hodos/path. Videogames are branching possibility spaces, but sometimes the way we traverse them is simply beyond our control.
