Andy Matuschak’s essay, Exorcising us of the Primer, highlights the limitations of Neal Stephenson’s influential The Young Lady’s Illustrated Primer, a fictional personalised interactive textbook that can teach everything. In particular, Andy explains why gamification isn’t the silver bullet for education – it’s hard enough to make something fun, let alone fun and educational; we want to encourage intrinsic motivation in learners, whereas most gamification, despite claims otherwise, does not; etc.
All of that’s true, and I want to add one more consideration: effective gamification must be highly specific to the subject in question. In my experience, this is anathema to many investors and technologists, who are more interested in general purpose and massively scalable solutions. The end result is what I call “generic gamification” – the application of generic game-like features such as points, badges, streaks, levels, and leaderboards to otherwise completely unchanged and certainly un-fun apps and teaching materials.
I encountered this misconception when designing Zombies, Run!, a smartphone game that makes running more exciting and has attracted over ten million players. You might think its game design principles could be applied to all forms of exercise, not just running (just think of the total addressable market!) but you’d be wrong, because running is completely different to other forms of exercise.
Here’s an excerpt from my book, You’ve Been Played (2022), which the NYT called “illuminating and persuasive“. It explains why Zombies, Run!’s specificity helped it succeed where other running games failed:
Zombies, Run! was far from the first running game on smartphones. It wasn’t even the first game where you ran away from zombies. But it was, and still is, the most popular and most successful running game, and I believe that’s because it was the first to fully understand and accommodate the nature of running within its design. This understanding didn’t come about because either I or Naomi Alderman, the game’s co-creators, were expert runners—far from it. It’s because we spent an inordinate amount of time thinking about and around the problem.
As soon as the iPhone was announced in January 2007, I became captivated by the new capabilities it offered for software and games. It wasn’t until July 2008, however, that the App Store launched, opening the doors to apps created by third parties. Runkeeper, a GPS-based running tracker, was among the first apps out of the gate, instantly absorbing the functionality of dedicated GPS trackers just as the iPhone absorbed MP3 players and PDAs.
One of the first running games, Seek ’n Spell, came just a year later. The game displayed the real-time positions of four players on a map, onto which letter tiles were randomly dropped. Players collected letter tiles by running over them, with the aim of spelling out high-scoring words; the game was originally called Scrambble until, I assume, Hasbro’s lawyers got in touch.
It was marvellously imaginative with simple yet clever gameplay, but I never managed to corral the few iPhone owners I knew into the same park at the same time, and that exclusivity is likely why it never caught on.
This was an important lesson for us. No matter how much fun it sounds to work out with friends, there’s a reason why most runners you see are on their own. Part of running’s appeal is how little it demands—throw on a T-shirt and shorts, slip on your shoes, walk out the door, and you’re off. Having to negotiate with three other friends on where and when to meet raises the barrier to entry considerably. Perhaps nostalgic design had a hand in Seek ’n Spell’s multiplayer requirements, with its designers assuming that everyone would be like them: iPhone-loving friends living next to one another, wanting nothing more than to try a cool new game.
Cache & Seek taught another lesson. Launched in early 2010 by a South Korean developer, it was a location-based social running game where players could drop treasure for their friends and collect others’ in turn. Unlike Seek ’n Spell, it was asynchronous—you didn’t all have to play at the same time. Yet despite drawing attention from the games media, it didn’t fare any better.
It’s hard to know the true causes for why a game succeeds or fails, but when I first tried Cache & Seek, it invited me to collect treasure from places I had no interest in running to—busy streets, back alleys, odd corners of parks—which immediately turned me off. Whether in Oxford, London, or Edinburgh, I always run one of just three or four routes depending on my mood, around a park or along a river or down a trail. I may be more of a creature of habit than others, but I suspect most runners don’t vary their routes that much either.
It’s one thing for video games to bend players to their will with interminable cutscenes and tedious gameplay; at least you can soldier on in the comfort of your home, glancing at your phone or listening to a podcast as you play. But expecting people to change their real-world behaviour is entirely different. The risk of a badly placed treasure in a location-based running game isn’t just a couple of lost minutes, but returning home with muddy shoes, venturing down a scary alleyway, or worse. The reward better be worth it, and Cache & Seek’s generic treasure icons didn’t make the grade. Another location-based smartphone spy game once asked me to walk just a hundred metres down my road to get started, and I balked even at that. It was raining!
Seek ’n Spell and Cache & Seek shared one final problem that we also encountered when designing our mopping game [an imaginary game that makes mopping the floors more fun]: they interfered with the player’s desired activity (running) by making them look at their phone’s screen every time they wanted to collect another tile or treasure. When you’re out doing cardio exercise, the last thing you want is to be stopping every thirty or sixty seconds to get your phone out; and if you don’t stop, you’re liable to have an accident.
I wasn’t sure I could design the perfect running game, but I knew I could design a better game by respecting and accommodating runners’ requirements. This meant the game would be single-player, so you wouldn’t have to persuade your few smartphone-owning friends (remember, this was 2011) to join in every time you wanted to go for a run. It wouldn’t ask you to change your existing running routes; instead, its gameplay would map onto wherever and however you chose to run. And it wouldn’t make you look at your screen at all while you were running, whether to check a map or to tap on buttons.
This was quite the set of constraints, but the narrowed options also provided clarity. If the players couldn’t look at the game on their screen, we’d have to use the next-richest output: audio. Fortunately, most runners already used headphones to listen to music or podcasts, so I wouldn’t be asking them to buy something new or change their habits. And audio was ideal for a small team like Six to Start. While it didn’t have the wow factor of amazing graphics or maps, I knew it was comparatively cheap to produce high quality sound effects and dialogue.
The input method was harder to decide on. Voice recognition was exciting, but many runners, including myself, didn’t have headphones with built-in microphones. Using the smartphone’s accelerometer sensors to detect hard taps (e.g., one tap for “yes,” two taps for “no” in response to an audio prompt) was attractive but upon testing proved to be unreliable. That meant falling back to the one sensor we could definitely rely on: GPS tracking. Players would control the game merely by speeding up or slowing down—nothing else. I wanted players to be able to use their tried-and-tested running routes rather than being forced to follow our directions. Besides, asking them to turn right or left was a nonstarter since the noisiness of GPS data would mean they’d have to run tens of metres before we could really tell whether they’d changed direction, and there were few ways to prevent players running into traffic.
All these rules and constraints may seem obvious in retrospect, but they weren’t obvious at the time. Given other designers’ repeated attempts to make ultimately doomed screen-based, route-altering games, it’s still not obvious even now. My belief is that game designers are so entranced by the possibilities of telling players where to run that they completely forget to consider what players are actually prepared to do. Alternatively, designers assume that because they’d play such a game, so would everyone else.
With these design principles in mind, I met Naomi for lunch in mid-2011 to throw around ideas for a possible collaboration. I mentioned my interest in a running game; she told me she’d just joined an online running club. Apparently, the club members were asked why they wanted to run. Some said they wanted to get fit. Others wanted to lose weight. One woman said she wanted to survive the zombie apocalypse.
When I heard this, I groaned. At the time, everyone was making a zombie game or TV show or book. In the space of just a few years, we’d had games including Left 4 Dead, Left 4 Dead 2, Plants vs. Zombies, and Dead Island, plus the movie 28 Weeks Later (the sequel to the acclaimed 28 Days Later), and most recently, the smash-hit TV show The Walking Dead. I had no interest in following the pack and I suspected (wrongly) that the entire genre of zombie media would soon become exhausted. But as we talked through the idea of a zombie theme, we realised how well it fit a running game.
The advantage of media oversaturation was that everyone already knew how zombies behaved. Zombies couldn’t be reasoned with, they were almost impossible to stop, and so the only smart way to survive was to run. A zombie apocalypse also implied a world with blocked roads and no electricity or gas, meaning your own two feet would be your most reliable mode of transport. And you’d have plenty of motivation to keep moving: not just to escape the imminent threat of zombies, but to collect supplies, relay messages, rescue survivors, and search for a cure. We would borrow a trope from spy movies and action-adventure games, though, with a radio operator guiding your actions through your headphones and delivering the story.
The story, effectively a first-person audio drama with the player as the silent Runner 5, would be players’ primary experience in the game, meaning it had to be excellent—better than any audiobook or podcast you might listen to instead. This is where Naomi’s role as cocreator and lead writer came to the fore; she provided a thrilling, emotional story with a cast of characters that remain beloved by millions to this day. Without her story and the excellent casting and direction by our audio director Matt Wieteska, Zombies, Run! would have been a failure. I know this because I’ve seen many copycats over the years, and they’ve all disappeared without trace due to their mediocre storytelling.
Alongside the story, players could rebuild and customise their own base in between runs, using supplies they collected while out on missions. In keeping with our ban on screen interaction during runs, we decided players would collect supplies automatically, rather than having to press buttons or follow waypoints on a map. Crucially, supplies were awarded according to the time players spent running, rather than the distance they covered; we didn’t want to require players to run a set distance, since that would inevitably be too short or too long for most runners. What mattered more to us was effort, which was the impulse for having a secondary currency of “materials” that were awarded more sparingly, solely on the completion of missions, to discourage players from running unhealthily long durations in order to win.
We cared about accessibility in other ways, too. We didn’t set a specific speed (e.g., ten kilometres per hour) for players to reach in order to evade our zombie chases. Instead, players had to increase their speed by 20 percent for one minute. This meant chases would pose a challenge for runners of all abilities, but an achievable one: if you were walking, you’d have to jog; if you were jogging, you’d have to run; and if you were running, you’d have to sprint (and if you were already sprinting, you were in trouble). Nothing awful would happen if you were caught, other than dropping a few supplies you’d collected; running a few more minutes would make up for the loss. Or you could simply turn off chases entirely, with no repercussions in the game whatsoever. There would be no punishment in our game, only encouragement.
This led to Zombies, Run!’s motto: “As long as you can move faster than a slow shamble, you’ll be useful.” We didn’t want to make a game just for speedy athletes or those who wanted to crush their friends—we wanted to cater for someone who could only manage a fifteen-minute walk just as much as marathon runners. True, part of this desire came from wanting to make lots of money, but it was also because we wanted to make a game that we’d enjoy ourselves. I was wary of the pitfalls of nostalgic design, but given the diversity of our team, I felt our design would expand our audience rather than contract it.
Other details emerged during development from our small design team, which also included artist Estée Chan and developer Alex Macmillan. We knew we couldn’t write and record enough audio story to fill dozens of thirty-minute missions, so we alternated between playing short story clips and the players’ own music. If players were still running after a mission was completed, we’d switch the audio over to Radio Mode, written by Matt, featuring a pair of postapocalyptic DJs reading the news and sharing survival tips.
Nothing in Zombies, Run! would be gated. You wouldn’t have to run two hundred miles or evade fifty zombies to unlock extra missions. In fact, other than a small set of achievements we half-heartedly added at the request of players after launch, there would be little of the usual generic gamification points and levels in our game (despite this, it would soon become the poster child of the gamification industry). My goal was always to make people excited to get up and run, even on a rainy Sunday morning, because they wanted to find out what would happen next, not because they would earn another badge.
We did provide some markers for progress in the game. At certain points in the story, you would receive “milestone emails” from characters you’d met. If you rescued a child in one mission, you’d get an email from her dad showing a picture of you she’d drawn. If you ran five hundred miles, your radio operator would send over a joke about the Proclaimers’ eponymous song. The emails were far more time-consuming to write and illustrate than generic achievement badges, but they’ve proven more memorable and valued than the rewards you might receive from a Fitbit or Apple Watch. In a sense, the only reward you get from completing missions in Zombies, Run! is more of the story you presumably enjoy.
The lack of traditional rewards means we’ve never had to worry about cheating. It’s easy to cheat in Zombies, Run!—we have a Simulate Running mode for players who are unable to run—but the gain is as futile as skipping to the last page of a novel. No one’s stopping you, but you’re only ruining the experience for yourself. With a hole where its heart should be, generic gamification is vulnerable to cheating in the way that good games aren’t.
Following a Kickstarter in late 2011, Zombies, Run! launched in early 2012 and went on to attract over ten million downloads by 2022, with hundreds of thousands of players running with the app every month. It’s the most popular smartphone fitness game in the world, and it achieved that feat through a more complete understanding of what it means to run.
I tell the story of Zombies, Run!’s development not to present myself as a game design genius, but to demonstrate how good gamification is precisely tailored to its activity. Over the years, we’ve been asked countless times to make a Zombies, Cycle! spinoff. On the face of it, cycling has a lot of similarities with running: they’re both cardio workouts, they’re usually conducted solo, and no doubt there are cyclists in dire need of distraction and entertainment. Technically speaking, it would be straightforward to add a special cycling mode with faster zombies, and I’m sure we could sell a few extra subscriptions that way. But it wouldn’t be a good game.
Why? Because cycling is completely different to running. It’s unsafe to cycle with headphones in traffic, so we wouldn’t be able to rely on audio. Since cyclists can coast, I’d want the game to respond to the way cyclists experience momentum, climbing uphill and coasting downhill. Unlike runners who have to deal with more varied terrain, cyclists can more easily sustain the same speed over time, and I’d like to make that a gameplay objective. Given these differences, an arcade game–experience might be more appropriate than Zombies, Run!’s story-led approach, though it would be imperative that safety came first.
That’s the beauty of gamification: every activity demands a new solution. If you’re a designer, that’s a good thing! But it’s also the challenge of gamification, because investors prefer infinitely scalable, one-size-fits-all solutions. That’s why we get points and badges instead of tailored games. Their insistence on generic solutions that serve everyone robs us of games that serve a few people well. Zombies, Run! may well be nostalgic design—Naomi and I made the game we wanted to play, and if you don’t like zombies or audio storytelling, or you’re more motivated by competition and social interaction, it’s not the game for you—but that hasn’t stopped millions of people from enjoying it. We didn’t need or expect Zombies, Run! to work for everyone; it just needed to work for enough players to pay our bills.
This story also illustrates just how contingent Zombies, Run!’s design is on the consumer technology that existed in 2011. Ten years prior, the closest thing you could get to a smartphone was the Palm m515, which lacked built-in GPS. Ten years on, smartphones are so ubiquitous and powerful that it’s possible to make multiplayer games like Pokémon GO that can essentially tell players where to walk—though I’d argue this is as much a function of Pokémon’s phenomenal popularity, plus its pre-existing game mechanic of catching monsters.
Andy’s essay remains optimistic about good gamification, but concludes with a call to arms for creating a ubiquitous computing-powered learning environment to support and structure learning in general. That’s a worthy goal, one that Neal Stephenson coincidentally touches upon in Anathem, but it reinforces the idea that general solutions are more interesting than specific ones.
Clearly there’s a good reason for that. However, the quest for the general solution can distract us from a thousand specific solutions that we could have with today’s capabilities – solutions whose funding remains limited due to their very specificity. Yes, I’d rather have billions of players for Zombies, Run! rather than millions – but I’d also rather have than millions of players than none.
I recently left Six to Start after seventeen years, but please still check out the ZRX app, which now includes both Zombies, Run! and Marvel Move.
If you enjoyed this excerpt, consider buying You’ve Been Played – or check out my NYU Game Center Lecture on it:
Photo by Eugenio Mazzone on Unsplash.
mssv 