The Quest for Good Platformer Mechanics: Fat Men on Ice Skates

On my personal blog I once 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 the game to him; 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’. 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.

What do Mario and Sonic have in common?

Pictured: Certain unfortunate circumstances

During the development of my post-undergrad ePortfolio a while back I had cause to go check, and, as I imagine you all could have told me, it turns out that Mario moves not like a gymnast or an action hero, but rather more like a fat man 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’? 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 ‘go faster’? (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 aesthetic goal 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.0.1 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 available right now is an infinitely-long horizontal plane; you are, therefore, gonna need more things. Version 1.0 includes some platforms (!) to jump onto, some pits to jump over, and some cactuses around which to navigate. Touching the pits or the cacti triggers a fail state: Screw up once and the game ends.

Sadly, Pitfall does not allow you to prestige.

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 possible. 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.0 attempts to increase the variation of challenges while reducing the rote button-press accuracy they require. Thus there are no more ridiculously big holes or ridiculously small bits of ground. Furthermore, 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 now new problems emerge: You must watch in horror as your players sit frozen for minutes at a time, searching in frustration for a way forward as your cacti march blithely past one another. Some people are intrigued; most are 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.

This screenshot represents agony

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 an 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 procedurally with new (but perhaps less dire) threats. Version 3.0 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 limited for the purposes of my hypothetical design scenario, you end up changing the later levels of Version 3.0 to give the cacti laser guns in addition to dynamic movement patterns: In essence, the player must now dodge while she dodges.

Xzibit

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 ****ING LASER CACTUS ****S”. 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 is a function of the level layouts, early sequences (which must be repeated after every ‘Game Over’ screen 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 bit weird, you have a thought: What if my dude was a fat person on ice skates?

Enter: A Fat Person on Ice Skates

Version 4.0 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 version also includes a ‘run’ button that lets the player go much faster (and jump much farther!) while consequently making it much harder to stop; this introduces a little variety to each playthrough as well as a fairly compelling risk/reward dynamic. The prototype now 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 one's own dude.

Mario swings his arms from side to side.

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 20^th or 30^th 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, making further learning possible at all times. Here we have discovered a design pattern that allows the player to learn at her own pace by decoupling the game’s minimum depth at any given stage (stuff she MUST do to advance) from its maximum depth (stuff she CAN do and may have to do later). The designer produces a difficulty space rather than a more conventional difficulty curve, permitting the player’s skill to modulate the difficulty of any given playthrough 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 rather than feedback specific to one kind of enemy or level; the player quickly internalizes how her dude accelerates, how fast it can run, and how far it can jump because she feels its run and its jump at all times. 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 paths 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 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

You can't catch what you can't see

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.