Walkthrough vs. Speedrun
On the spectrum of play between contemplation and corruption.
While watching the E3 2014 coverage on Twitch this week, I restrained myself to a brief, six-tweet burst. As an Ubisoft employee demonstrated the latest Assassin’s Creed sequel—now a yearly tradition—I mused about the ‘genre’ of the developer walkthrough. The gist is this: the developer walkthrough, I’d wager, is unlike most players’ experience of a game. The walkthrough is precisely that, a walk through the game’s spectacular elements, lingering over the minutiae of game design that many players miss. The developer pauses, uses the camera to pan across the landscape, listens in on mundane dialog, points out textural work, comments on lighting or weather effects, marvels at animation, and so on.
This contemplative experience is understandable. In a game like Assassin’s Creed, hundreds of animators, UI designers, sound designers, programmers, and concept artists have poured thousands of hours into a singularly expensive and labor-intensive digital object. An artist might devote three years working solely on particle effects—why not revel in their beauty for a moment? Your average game player might appreciate the gestalt of a scene, but it’s unlikely most are giving serious consideration to the expert modeling of a polygonal bench.
The walkthrough is also carefully paced because the games are typically unfinished. Publishers must spend significant resources to prepare an exhibition-worthy build, and these are often teetering on the brink of stability. A wrong turn can surface a glitch. The demoer must stick to scripted paths lest the demo fall apart. In sum, the walkthrough is meant to show the game in its best light in an effort to build excitement for the game’s eventual release.
Consider the April 2013 developer demonstration of Dark Souls II originally featured on IGN:
From Software director Yui Tanimura narrates a canned 12-minute demo that begins with, prior to any character movement, a 360-degree pan of an early environment. The player then walks forward slowly, pushes open a door, and lights a nearby bonfire. Once lit, another short pan and a dramatic camera position show off the impressive lighting effects. While the Dark Souls series generally demands a slower pace than most games, the IGN demo has numerous unnecessary pauses meant to show off architecture, level design, and graphical effects.
(And this kind of demonstration isn’t new. Super Mario 64’s debut at E3 1996 shared the same features, including an extended stay in the opening ‘playground’ area. Note the presenter’s comments as he directs Mario to climb trees, jump, and swim: ‘This game world is a very interactive world. You can almost do anything you want to do within this world. It’s a lot of fun just to run around and play within the game before you even start searching for the stars.’)
The developer walkthrough is especially fascinating in comparison to its antipode, the speedrun. Speedruns are a competitive genre of play dedicated to completing a game as quickly as possible, often utilizing exploits or glitches to save precious seconds. Any (in-game) technique is valid in the pursuit of speed.
Compare the IGN demo to one of Bananasaurus Rex’s recent Dark Souls II ‘Any%’ speedruns, which completes the entire game only a few minutes slower than Tanimura’s walkthrough:
Brex (also a prominent Spelunky speedrunner) is using several community-discovered techniques to effectively break the game. The ‘bino-boost’ exploits an unintended behavior triggered when the player holds the binoculars item, aims, and taps a two-button combination to generate a significant speed boost while expending minimal stamina. The more difficult ‘pairywalking’ glitch triggers when players roll/attack across the body of a parried foe, allowing them to ‘airwalk’ over level geometry. In combination, these techniques allow speedrunners to dash past enemies and sequence break massive portions of the game.
Speedrunning Dark Souls II shows the game in its worst light. When scripted pathways are circumvented, the game loads its level geometry improperly, surfacing its bare architecture. Solid objects become permeable. Enemy attacks are trivially avoided. A game lauded for its difficulty is digestible at sitcom pace. (Though I say this not to trivialize speedrunners’ efforts—mastering these glitches takes hundreds of hours of practice as well as a frustrating measure of luck.) To the speedrunner, these glitches are the lifeblood of competitive play; in a developer walkthrough, the same glitches would cause embarrassment (and relentless online mockery).
Though their ultimate aims are widely divergent, both developers and speedrunners share a common trait: they have an intimate knowledge of a game’s underlying systems. The developers’ insights are earned through authorship—they design the game, so they understand its flaws at a procedural level. The speedrunners earn their insights through luck, brute force, and experience.
However, neither developer nor runner represent the common player. Each of us plots our own pace through a game—there are those that rush and those that linger, and most of us do some combination of the two. But the walkthrough and the speedrun show us the full extent of the playing spectrum, with those that revel in a simulated world’s fragile beauty at one end and those that aim to dismantle that world’s cohesion at the other.