Last week I made the very opposite of a bold assertion in claiming that the NES classic Super Mario Bros is the gold standard in good platformer mechanics. I also mentioned Tim Rogers and the “sticky friction” that so endeared him to the game; today I’d like to elaborate on that second part.
If Metacritic was around back in 1985 I’m sure you could pull up a whole swathe of reviews describing SMB’s controls as ‘intuitive’, ‘tight’ or ‘pixel perfect’, and these words could lead the uninitiated observer to conclude that Mario is some kind of Olympic athlete when in fact this is (barring certain unfortunate circumstances) patently untrue.
Pictured: Certain unfortunate circumstances
You see, while I was working on my ePortfolio last August I had cause to go back and check, and it turns out that Mario moves not like a gymnast or an action hero, but rather more like a fat guy on ice skates. It takes him a bit of time to really get moving and even longer to stop. Each jump brings not only the possibility of over or under-shooting your target, but also of landing with too much speed and plummeting forward into a Goomba or a fireball or something. Does this sound like ‘tight, intuitive, pixel perfect platforming’ to you? Well, perhaps it should.
As you may expect from a game as highly-acclaimed as SMB, its primary mechanics are all in there for good reasons. Why does Mario move like a fat guy on ice skates? Is the timer on every level there solely to provide an anachronistic, arcade-ish scorekeeping system? Why, on a controller that has two primary buttons, is one of them dedicated mostly to making your dude ‘run’? (And why, exactly, would you ever want to release that button?) The short answer: Going fast is fun. The long answer has to do with difficulty scaling, the design constraints of platform games in the early 1980s, and malevolent cacti.
The First Principles of Platform Games
Suppose you have an idea for a game about a dude who runs and jumps to the right, and your primary objective is to make it fun (insofar as we can understand what ‘fun’ means) by introducing the right amount of challenge. Well, prototyping is often a good place to start, so you go ahead and slap something together. In Version 0 of ‘Running and Jumping to the Right: Origins’, you control a dude who can move left/right at a constant velocity or else stand perfectly still; he can jump left/right in a parabolic arc or else straight up, but has no air control while doing so because, y’know, Isaac Newton. All you have environment-wise right now is an infinite flat plane.
Now, how do you make that challenging? Being a long-standing member of #teamplato, you begin by examining the current forms populating your game world and what properties they might have. You have your DUDE, and you have an ENVIRONMENT that can contain THINGS. At a fundamental level your dude can run or jump OVER, UNDER, ONTO or INTO (that is, collide with) said THINGS. However, the only THING you have right now is an infinitely-long horizontal plane; you are, therefore, gonna need more things. Version 1 includes some platforms (!) to jump onto, some pits to jump over, and some cactuses around which to navigate. Hard fail states are associated with touching the pits or the cacti: Screw up, and the game ends.
This is a game called ‘Pitfall!’ published in 1982 by Activision. It is full of pits.
You’ve seen fit to arrange these new entities into challenging scenarios. By making the holes really big, the ground really small or littering the whole place with cactuses you can force the player to time her jumps well; ledges can segment the environment into multiple routes, some of which can be dead ends or maybe deceive the player into trying a jump only to discover upon her death that it isn’t viable. Unfortunately these mechanics are not very fun. Trial-and-error is a bad choice of feedback mechanism when every error is met with abject failure, and ‘press jump within [n] milliseconds of the right time’ dynamics provide little in the way of a viable learning curve.
You speculate that the problem is a lack of mechanical nuance, so Version 2 attempts to increase the variation of challenges while reducing the rote button-press accuracy they require. No more ridiculously big holes or ridiculously small bits of ground. Some cactuses now move back and forth while some platforms move up and down, introducing a temporal dimension to the proceedings. By combining fast and slow cactuses, you create complex movement patterns that require some observation to solve. This works much better, but you’re now faced with the situation of your players sitting around for minutes at a time watching cactuses crawl across the screen as they search for a way forward. Some people are intrigued, others frustrated and bored. Later levels increase the speed, scale and complexity of the puzzle systems in an effort to increase challenge, which exacerbates the problem and tends to outpace your players’ capacity for pattern learning. Essentially what you have here is Donkey Kong: Slow and Overly-Puzzly Edition.
Donkey Kong was developed by Shigeru Miyamoto and released in 1981. It is full of donkeys.
You would prefer that your game be more broadly accessible and have a bit more flow (rising challenge + rising player skill -> endorphins!). This means that 1) the game should require a bit more doing and a bit less standing around looking for patterns, and 2) later levels should benefit more from prior learning while maintaining a more appropriate challenge level.
In abstract terms, the solution to the first problem is to break the player’s decision-making process into smaller chunks: Rather than staring at a vast, interconnected network of pits, platforms and sentient cacti (like golf), the player should be reading and responding to the situation as it unfolds before her (like hockey or basketball). One good way to accomplish this is to have the environment react to her movements and pose new (but perhaps less dire) threats dynamically, allowing her to think on her feet. Version 3 has the cacti vary their movement patterns when the player approaches them, forcing the player to react on-the-fly while opening up opportunities for new tactics that exploit these patterns. The flow problem, much like spelling Mihály Csíkszentmihályi’s name correctly, is difficult. The naïve way to make the game harder as the player gets better is to pile new game mechanics on top of the old ones. So, because your judgment is artificially poor for the purposes of my hypothetical design scenario, you end up changing the later levels of Version 3 to give the cacti laser guns in addition to dynamic movement patterns, forcing the player to dodge while she dodges.
Xzibit was released in 1974. He is full of increasingly-tiny versions of himself.
This, of course, results in your players shouting barely-intelligible curses involving “CHEAP FUCKING LASER CACTUS FUCKS”. It also leaves them bored to tears as they re-complete the first level over and over in order to get to the part where they die every time. The problems here are manifold. Now that your environment creates threats in response to the player you’re facing wicked feedback issues (“HOW COULD I HAVE KNOWN HE WAS GONNA DO THAT!?”). And because all the challenge (which must increase alongside player skill) is a function of the level layouts, early parts (which must be repeated after every ‘Game Over’ because it’s the mid-1980s and “Entertainment System” is not yet an absurd phrase) quickly become boring while later parts become doubly harrowing due to the time investment required to even get there. But then, because you are Shigeru Miyamoto and you are a little weird, you have a thought: What if my dude was a fat guy on ice skates?
Enter: A Fat Guy on Ice Skates
Version 4 allows the player to accelerate and decelerate rather than move at a constant velocity, and it takes a good little while to do either thing. This prototype also includes a ‘run’ button that lets the player go much faster (and jump much farther!) while consquently making it much harder to stop, introducing a little variety and a risk/reward dynamic. It permits air control in small doses so that the player can react to her own jumps midway through them, but it still forces her to do some amount of looking before she leaps. (Note that these mechanics all satisfy our requirement that the game be more like hockey than golf, introducing constant decision-making at a very low level.) And perhaps most interestingly, our dude’s new-found sense of (sticky) friction makes those annoying laser cactuses almost superfluous, as the presence of basic obstacles is now enough to provide challenge; indeed, even a completely static cactus still moves at variable speed relative to the player as she gets busy speeding up, skidding to a halt, and generally throwing her inertia around all over the place. It would seem that rather than forcing people to navigate complicated mazes and memorize counter-intuitive enemy movement patterns, the game might instead manage to embed the vast majority of challenge in the task of controlling your own dude.
Super Mario Bros was released in 1985. It is full of good ideas.
The first time people play level 1 they may be hesitant, moving deliberately and carefully in an effort to minimize risk; this makes level 1 very easy. Yet by the 20th or 30th time they’re more than capable of passing the first level and can now begin to take bigger risks while doing it, applying the skills they gained while failing at level 2 to move quicker, more artfully and/or more economically through level 1 (which both makes level 1 less boring and actually helps prepare them for level 3 in the process). This way, every level has a sliding difficulty scale determined by how recklessly/skilfully the player would like to approach it and further learning is possible at all times. Essentially, this prototype allows the player to learn at her own pace by decoupling the game’s minimum depth (stuff you MUST do to advance) from its maximum depth (stuff you CAN do and may have to do later). And this, in turn, permits the player’s skill to modulate the game’s difficulty automatically.
Furthermore, the shift from simple controls and environment-based difficulty to sophisticated controls and dude-based difficulty allows you to rely heavily on omnipresent forms of feedback (the player quickly internalizes how her dude accelerates, how fast he can run, and how far he can jump because she has him running and jumping literally all the time) rather than feedback specific to one kind of enemy or level. As such, the game need rarely surprise players with cheap mechanics that force her to play a rote trial-by-error style to advance. Goombas Regular cactuses can move at the same lethargic pace all the time; Venus Fly Cactuses can follow the same up-and-down rhythm (and even be polite enough to hide when players stand near them for a while); even the somewhat-deadly Hammer Brother Cactuses chuck projectiles at the same consistent rate. The player always knows why and how she died in version 4.0 of Running and Jumping to the Right: Origins, as well as how she might avoid death next time, because it’s always related more to an error in her movement than to a laser cactus. And even though the protagonist dies in one or two hits, the nuanced platformer mechanics provide generous margins for error and near-limitless different movement vectors for clearing any particular set of obstacles (ensuring things rarely come down to completely-rote button mashing).
There’s a lot going on here, but the critical ideas here are twofold: One, that a big chunk of the game’s challenge can be designed into the interface (that is, ‘the controls’) thus affording a variety of playstyles at different risk-to-reward ratios; and two, that you can make these playstyles accessible (but not required) from level one. With these principles down, you can commence work on some of the lighter touches. Maybe a countdown clock is always nudging the player forward just a little faster than she might otherwise choose to go. Maybe there are boss fights with a large, fireball-throwing cactus that vary the pacing and introduce drama. Maybe those boss fights are preceded by sparse, lonely levels with creepy music that help build up a sense of foreboding. Maybe there’s a princess cactus who likes to stretch analogies beyond their practical limits for comedic effect, but she’s always in another cactus.
The Short Answer Revisited
Here is another game about moving a little faster than you should. Where do you think they got the idea?
SMB is really about the tension between cautious and risky behavior, the joy of moving just a little faster than you should and the panic/exhilaration you feel as you frantically attempt to deal with the aftermath. It shows us that we don’t always want our platform games to handle flatly and assuredly, like a good pair of runners on a hardwood floor. We may instead want them to handle like ice skates, graceful and reckless in equal measure, on the very edge of control or perhaps slightly beyond it. This is why Mario moves the way he does, why there’s a moderate timer on every level, and why one of the two available buttons translates to ‘go faster!’ Like all the best Nintendo mechanics, it’s fun, it’s smart, and it works. Sticky Friction lies in the gulf between driving 20 miles per hour and careening off a cliff.
Pingback: This Week I Read – Now that’s Moirai like it « Normally Rascal