Spelunky (Boss Fight Books Book 11)

by Derek Yu

Take this key. It will open the entrance to the mines. Follow me if you dare! — Yang

When I was working on Spelunky, I focused on just three attributes of roguelikes that to me held the essence of the genre: Randomized level generation. Permanent death (also known as “permadeath”), whereby the player has one life and cannot reload their game to take back mistakes. A ruleset for physical interactions that is shared by the player, non-player characters (NPCs), and items. The third attribute is my version of “monsters share rules and behaviors with players” and it extends not only to monsters but to items as well. In many games, monsters and items are coded separately and handled separately. You might be able to pick up an item and kick a monster, but you couldn’t kick an item and pick up a monster. In a roguelike, you should be able to pick up and kick items and monsters, with results that are based on consistent rules. This suggests that the player, the monsters, and the items are treated more like variations on a single type of object than three completely different objects.

Imagine a game that simulates a fantasy world many times larger than the most advanced big budget video game, but rendered completely in characters you’d find in a word processor. Dwarf Fortress has two modes: “Adventurer Mode,” in which you control a single hero, and “Fortress Mode,” which tasks you with keeping a community of dwarves alive in a mountain home of your design. This home is just a small part of a world that is procedurally-generated with remarkable detail going back hundreds of years, to the point where you can trace a minor character’s lineage back many generations. I read about one world where the history logs revealed that a particular NPC’s part-goblin blood was the result of one of his ancestors being kidnapped by goblins during a raid. And one of the cool things about the game is that both Adventurer Mode and Fortress Mode can be played in the same world, so a player could build a fortress in Fortress Mode and then visit that same fortress as an adventurer later (or the ruins of that same fortress, once things inevitably go awry). Dwarf Fortress made for interesting news because the sheer complexity of what the simulation could carry out seemed nearly matched by its inaccessibility. The game, which is still in constant development, has an air of mystery about it, like it’s being built by some advanced alien race.1 Not long after the game’s first release, the term “roguelike” began to pop up in mainstream news outlets and on social media. My personal hi...

history with the genre extended back to my childhood, so it wasn’t new to me, but I also got caught up in the excitement for this previously closed ecosystem being discovered by the outside world.

I’ve always preferred to chip away on my own part of a project in relative solitude and meet with teammates for discussion when our parts overlap, but that often made Alec, who preferred more steady communication, feel like we weren’t acting as a team at all. And although I consider myself to be a hard worker, Alec’s capacity for game-making seemed limitless. It’s a trait that I still respect, but at the time it was stressful trying to keep up. I’m proud of how Aquaria reflects the ups and downs of our partnership. But for the same reasons that I’m proud of Aquaria, I also couldn’t make another Aquaria. When the time came to start on our second game, we agreed to make something small, but each of our ideas quickly ballooned into something bigger. For me, it was too soon to start another intense, two-year project—although Alec was eager to begin working again, I realized that I needed to slow down permanently. So as difficult as it was to walk away from a successful team and a talented friend, I felt like we would both suffer if I didn’t.

It would have been difficult to make a large game like Aquaria in Game Maker 8.1, since it lacked the power and functionality of Alec’s custom-made engine.2 There was no way, for example, that Game Maker could handle the sheer number of objects that existed in a single area of Aquaria, especially at the game’s default resolution. On the other hand, Game Maker’s simplicity made it very popular amongst hobbyist developers who wanted to create something smaller, with graphics and music similar to video games of the 80s and 90s. I loved the feel of these hobbyist titles, bold and bite-sized, each one offering a few hours of pure entertainment. The personality of each game’s creator shone brilliantly through unique and decidedly uncommercial art and music choices. Even the names of the games—Clean Asia!, Punishment: the Punishing, The Jeluvian Project—and the handles of their creators—cactus, messhof, Pondwater, respectively—were refreshingly strange. The games reminded me of something the author Haruki Murakami says in the intro to the English edition of Blind Willow, Sleeping Woman: “I find writing novels a challenge, writing short stories a joy. If writing novels is like planting a forest, then writing short stories is more like planting a garden. The two processes complement each other, creating a complete landscape that I treasure.” In video games, we don’t have corresponding terms for novels and short stories—we simply have large games and small games. These Game Maker ga...

games were Murakami’s gardens: vibrant, intimate, and full of charm. Having just planted a large forest with Alec, I was eager to find my own little patch of fertile soil.

Until recently, programming was the crucial gatekeeper to making games. Early in the history of video games, the lead programmer was typically also the lead writer, artist, and designer. If you could program software, you could be a game creator. You may not have necessarily been able to craft a good game, but at least you could try. If you weren’t a programmer, you needed to find one. The advent of game-making tools like Klik & Play and Game Maker changed the landscape of game development drastically, putting less of a premium on programming and allowing all kinds of new people to make games. I think the people these programs benefited most are people like me, generalists for whom programming is not a primary passion but a means to an end. What I lack, perhaps, is an enjoyment of programming for the sake of programming, or “programming in the abstract sense,” as John Carmack, the programmer of Doom and Quake, once described it. While the problem-solving and optimization involved in programming is sometimes a welcome change from making artwork, most of the time I would prefer code to just work and get out of my way. Were it not for video games, I would probably have very little interest in learning how to program at all. This was evidenced by the mediocre grades I got in college, save for a single “A” in a computer graphics course where I submitted a video game as the final project. I’ve tried programming a game engine from scratch before, surrounding myself with books lik...

like Tricks of the Game-Programming Gurus in an effort to “make games the right way,” but when days of work yield as much as I could make in Game Maker in a few minutes, it’s hard to stay motivated. At the beginning of each semester at Berkeley I had the same sort of naive gumption, buying pristine notebooks and attentively jotting down everything the professors said, only to succumb to ennui a week later, my notes devolving into irreverent doodles. Post-school, however, I accepted that I wasn’t cut out for academia and programming theory. I no more wanted to program my own game engine than I wanted to fashion my own paintbrushes. This important realization meant I could stop wasting my time trying to be something I wasn’t. Instead of being embarrassed about not being a “real programmer” using “real programming languages,” I vowed to make games whichever way felt good to me.

In one of my early Game Maker platformers, you controlled a cloud and your primary action was soaking up water that you could unleash as rain, hail, or thunder. In another, you were a questing king. In another, you were a robot that could build a variety of guns out of spare parts. But ultimately, none of these ideas felt like they broke enough new ground. When working on games, I’ve found that the projects I have the highest chance of finishing fall at the intersection of three categories: games I want to make, games I’m good at making, and games I wish I had made. “Games I want to make” and “games I wish I had made” sound similar, but in reality, not every game that is fun to work on is necessarily a game that I’d be proud of releasing, and vice versa. My platformer prototypes were enjoyable enough to work on, but they only added small twists on conventional gameplay, a fact that was hurting my motivation to keep working on them. If I wasn’t going to make another big game, I wanted my small game to be something special.

NetHack is the successor to Hack and adds new content, as well as a charming graphical tileset. Once, while playing NetHack, I came across a troll in a spike pit. Trolls are not friendly creatures, and although they’re easy to kill, they have a nasty habit of reviving after death. In this situation, it would make sense to leave the troll where he was—stuck—but for whatever reason, I felt compelled to pull him out of the trap with the #untrap command (one of the “extended commands” that is not mapped to its own key on the keyboard). After doing so, a little heart icon appeared next to the troll’s sprite to let me know that he had been tamed, grateful for the rescue. Stories like these abound in NetHack. There is, for example, an entire spoiler page that details all of the ways that a cockatrice can turn you to stone. Just touching the corpse of this deadly creature petrifies you, so if you want to pick one up safely you need to be wearing gloves. Why would you want to hold one, though? To use it as a weapon, of course! But even with gloves on, a dead cockatrice is worrisome, since you could easily fall on top of it while descending the stairs or because you stumbled while wearing cursed boots. The vastness of the game’s possibility space and the fact that each possibility is handled elegantly, without bugs or inappropriate messages, has led NetHack players to create a mantra that’s now applied to other games, as well: “The DevTeam Thinks of Everything.”

To beat NetHack, also known as “ascending,” you have to travel 45 to 53 floors deep to acquire the Amulet of Yendor, then climb back up and past the first level, through the first four Elemental Planes and finally to the Astral Plane, where you must sacrifice the amulet to the deity of your alignment. In the “Maniac’s Ascension Guide,” a popular strategy guide that was first posted to the game’s USENET newsgroup in 2002, the author claims that a “fast ascension” takes around 40,000 turns. “There is no time limit,” he explains. “Take as long as you need to do the job properly.” Ascending not only requires extensive knowledge about the game, but also a great deal of tedium. High-level play involves tactics like training a pet to steal items for you or “pudding farming,” an act where the player splits a monster called a black pudding in half over and over again to collect its corpses. The NetHack wiki describes the act as its own punishment because of how dull it is. Another high-level technique is called “polypiling” and involves creating large piles of items to zap with a wand of polymorph, transforming the items into something different (but of the same general category). Usually the transformed items are just useless junk, but there is a small chance that you will get something that is good enough to keep for your “ascension kit,” a collection of equipment that is more or less required to ascend—a problem in and of itself, since the existence of such a kit reduces the num...

number of interesting choices the player can make if they want to win the game. https://alt.org/nethack/mirror/homepage.mac.com/mhjohnson/mag-r342.html

Unimpressed with my platformer prototypes, I turned to roguelikes. But after Aquaria’s complex development I was still attracted to simplicity and minimalism, so I decided my roguelike would be very contained. The player would only be allowed to carry nine items, regardless of their weight, and the actions they could perform on the items would be limited to “use” and “throw.” Another constraint I placed on the game was that each floor of the game’s dungeon had to take place on a single grid of 15x15 tiles. Compare that to NetHack’s 24x80 tile levels, for example. To generate a dungeon in such a small space, I had to forgo the twisting passages that lead you from one room to the other. Instead, the nine rooms would be crammed together like tiny cubicles in an office space. This seemed reasonable—even though the larger dungeons of NetHack allow for more variety, not much of the time spent traversing the long hallways between rooms is interesting. There’s a reason why NetHack includes a special key that lets you “fast move” from one end of a hallway to another, stopping in the middle only if something crosses your path. Whereas the hallways are generally just hallways, a room in NetHack can be many things. At the most basic, they’re small chess-like boards that contain monsters, treasures, and traps, but they can also be shops, monster zoos, or throne rooms. Sometimes they’re pitch black and you have to bump your way through. It wasn’t long before I stopped working on my rogu...

roguelike. By the time I had made a couple of generic dungeons populated with enemies, traps, and shops, I was running into the same problem I ran into with my previous prototypes—distilling roguelikes into something simpler was a fun exercise, but it didn’t add anything new to the genre. So once again, my mind began to drift away, from this little puzzle I had in front of me to the rest of my puzzle pieces. When I started, there was only a large, disorganized pile strewn in front of me, but now there were some smaller puzzles partially completed. Platformers and roguelikes, platformers and roguelikes. I asked myself, what is it that I like about platformers? I’m a more action-oriented game player and I like how easy they are to pick up and play. I like the tension behind each jump. What didn’t I like about platformers? I didn’t like the repetitiveness of playing the same levels over and over again, and the reliance on memorizing level layouts to succeed. What did I like about roguelikes? I liked the variety that the randomly-generated levels offer and how meaningful death is in them. What didn’t I like about roguelikes? I didn’t like the repetitiveness of certain tasks that were required to succeed, like polypiling, and the reliance on memorizing commands. Platformers and roguelikes, platformers and rogue- likes… Then it clicked!

Another key element that’s present in this early build is Spelunky’s “theme,” which, in game design terms, refers to the setting, story, and imagery that we wrap around the abstract rules and systems. The name Spelunky is a reference to caving, also known as “spelunking.” Originally, it wasn’t intended to be the game’s final name—I just needed a more interesting filename than “explorer” for a preview screenshot I posted online. It was another indie developer, Phil Fish, who made me consider it again when he replied, “Spelunky, huh? I like it.” Looking back, it’s uncertain whether he meant that he liked the name or the screenshot, but I took it as the former.

With Spelunky, the caving theme seemed appropriate for a number of reasons. For one thing, I had already decided that the player would be heading downwards toward the exits, since it’s easier to let the player fall than to generate a path they can climb up. Caves, dungeons, and other natural or ruined environments also lend themselves well to video games because they’re easy to mold into levels of almost any shape without looking out of place. This is even more valuable when you’re generating levels algorithmically and can’t anticipate what they’ll look like. While it’s certainly possible to set a game in, say, a pristine office building, the rigidity and repetitiveness of the layout gets boring quickly and places restrictions on how a character can move. Finally, I wanted to give the player special equipment so they could create their own paths, and spelunking tools like rope, bombs, and pickaxes were a natural fit for that. So long as your theme is consistent with your rules, it doesn’t matter whether it makes perfect sense in real life. On the surface, a story about an Italian-American plumber saving a Mushroom Kingdom from turtles seems surreal and disconnected from reality. But after just a few minutes of playing Super Mario Bros., we start accepting that eating mushrooms makes us grow larger, flowers let us throw fireballs, and stomping on koopas will let us kick their empty shells across the floor. Given how quickly human beings adapt to new situations, I could have...

easily set Spelunky in a world where you were blowing up cheesecake floors with exploding penguins, but since there was already so much for the player to figure out and so much for me to design, it made sense to start from a setting that both the audience and I recognized. That was the same reasoning I used when I started making platformers with Game Maker: Use the familiar as solid footing to learn something new. Spelunky was both my easiest development and also most popular project to date, and I believe it’s because the key elements—the theme, the random level generation, and the destructible terrain—work together without friction. Nothing was compromised to make something else fit and each part only boosted the signal of the other parts.

Each level in Spelunky is composed of a 4x4 grid of rooms that are each made up of 10x8 tiles.

The game’s first priority is to make sure that there is a path from the entrance to the exit that is traversable without the use of bombs, rope, or other special equipment. This makes winning less luck-dependent, reduces the chances of getting stuck, and lets players save bombs and rope for reasons other than getting past badly-generated levels. A script called “scrLevelGen” begins by picking one of the four rooms in the top row of the grid and marks it as an “entrance.” From there, the algorithm generates a path from the entrance to the exit by randomly moving left and right on the grid and dropping down either randomly or when it hits the edge. Rooms that the algorithm never walks over are assigned a number “0,” and rooms it walks over are assigned a number greater than “0.” This lets the game know whether a room is on the path and whether it’s a room with openings on the left and right sides (“1”), a room that has an additional opening on the bottom (“2”), or a room that has openings to the left, right, and top (“3”). In my head, I think of these as normal rooms, drops, and landing rooms, respectively. In the case where a “2” is on top of another “2,” the bottom room will also have an opening on the top. On the bottom row the algorithm stops and marks the room it stops on as the “exit.”

Rooms that are not on the path (the zeroes) are designated as “side rooms.” Their defining characteristic is that the player may not necessarily be able to reach them without destroying the walls—they can be completely sealed off. Again, one of the nice things about destructible terrain is that it makes the random level generation easier, since we only need to worry about whether there is a clear path from the entrance to the exit. If the opening on the edge of the path happens to connect with an opening on the edge of a side room, that’s great, but if not, that’s okay. To the player, openings that end up meeting with walls will simply look like they were walls to begin with. After the path is set, each room will run a script called “scrRoomGen” that builds the room out of tiles. First, it randomly selects a room template out of a set of six to twelve templates, depending on the type of room. Templates are based on themes such as “basic room,” “low ceiling,” “ladders,” “upper platforms,” or “treasure below” (these names are taken from comments in the source code), and are defined in the script by a long string of characters. Here’s a template from the Mines, for example: 00000000110060000L040000000P110000000L11 0000000L11000000001100000000111112222111

The 0’s are empty space, the 1’s are basic walls, the L’s are ladders, the P is a ladder with a wooden platform cutting across it, and the 4 is a stone block that can be pushed horizontally. The 2’s have a 50% chance to be a wall and a 50% chance to be empty space. Once you know what each character represents, it’s easy to see that this is a room where a ladder on the right side leads to a small passageway plugged up by a stone block. Because of the 2’s, there’s a good chance that there will be an opening downward, but it could also be flat ground. Later on in the script these characters get converted into graphical tiles. The “6” floating in mid-air doesn’t represent a single tile, but a 5x3 group of tiles that I call a “chunk,” randomly selected out of a possible ten.

The chunks come in two main varieties: chunks that are meant to hang in the air and chunks that are meant to sit on the floor. There are some special varieties, too, like in the Jungle, where there are chunks for groups of hanging vines. The purpose of these smaller groupings of tiles is to provide further randomization within a room, allowing me to create what feels like a lot of variety with a fairly small number of room templates. Once scrRoomGen has done its thing, it’s time to generate monsters, traps, items, and treasures, in a new script called “scrEntityGen.” This script checks each floor tile and decides whether to generate an entity on or around the tile. It will, for example, check that there’s an empty space above the tile and then roll the proverbial dice to possibly generate a monster there. Item crates, treasure chests, gems, and gold like to spawn in alcoves where there is an empty space surrounded by walls in three out of the four directions. In this fashion, the level is populated with all of the deadly obstacles and tempting rewards that make the game fun. I’ve been asked how I come up with the percentages for how frequently monsters, traps, and items are generated in Spelunky. The truth, which may be a relief or maddening depending on how you look at it, is that it’s not an exact science—a lot of trial and error is required. Usually, I find it best to just start with some ballpark figure, like 1/10, 1/20, 1/50, or 1/100. From there, values are just twea...

tweaked up and down until they feel right.

The randomized level algorithm in Spelunky is the perfect example of the kind of programming exercise I enjoy. In this case, it was my distinct lack of passion for programming that led me to the idea, since I didn’t want to do anything more complicated. This system doesn’t create the most natural-looking caves ever, and players will quickly begin to recognize certain repeating landmarks and perhaps even sense that the levels are generated on a grid. But with enough templates and random mutations, there’s still plenty of variability. More importantly, it creates fun and engaging levels that the player can’t easily get stuck in, something much more valuable than realism when it comes to making an immersive experience.

My relationship with TIGSource began before Aquaria and long before Spelunky, in 2005. I was at a bit of a low point—Berkeley had spat me out a year earlier with a computer science degree, but not much desire nor energy to code. I had been unfocused my senior year, distracted by a break-up with my long-term girlfriend, and ended up failing a self-directed programming course that I had planned to spend making a game. Before that, my long-time game development partner Jon Perry had lost interest in working on video games, choosing to focus on his film degree and other hobbies instead. I was tired and lonely.

I think I got a bit jaded about the games industry. I feel like it’s a hard place for creative people. Most people want to be Sid Meier, or Warren Spector, or Shigeru Miyamoto, or something. But I started wondering: If I tried to get in the games industry, how many Spongebob Squarepants games would I have to make before I could get to do what I wanted? And making a living off of indie games is hard. I guess it’s like any industry: you have to find the right people to work with. To be honest, college also burned me out. Between trying to do art, make games, study for classes, keep up a serious relationship, go out and have fun and meet new friends… If you want to be a game programmer, you have to really love programming. After college, I wasn’t sure that I really did, I guess. And you can’t just jump into the games industry as a designer.

The shopkeeper has become the most notorious character in Spelunky, equally feared and beloved by his patrons. His shop, which appears 100% of the time in level 2 and has a decreasing chance of appearing in later levels (2/3 chance in level 3, 2/4 in level 4, 2/5 in level 5, and so on), is the most consistent source of life-saving items as you spelunk your way downward.

But as difficult as he can be, the shopkeeper has a fairly simple set of behaviors. While he’s alive, there are four main “states” that he can be in: IDLE is a resting state when he’s standing still and watching over his shop. FOLLOW is a state he enters when the player picks up an item in his shop, causing him to walk up to the player and stay close by. Whether he’s following to offer assistance or out of suspicion is left to the player’s imagination. I added this state because in initial tests it was too easy to steal items when he stayed at his counter. ATTACK is the shopkeeper’s angry state, when he’s actively hunting down the player. And in the world of Spelunky he is the judge, jury, and executioner. If he’s not already carrying a shotgun when he enters this state, he will pull one out. He can only pull out one shotgun, though, so if you manage to wrest it from his grasp, he’ll become unarmed (but still dangerous). PATROL is a state that replaces IDLE when the player is wanted as a criminal. In this state, the shopkeeper will walk back and forth holding the shotgun until the player draws near, in which case he will enter his ATTACK state.

In the ATTACK state, the shopkeeper is fairly adept at finding the player, although the underlying AI is nothing special. Pathfinding is an area with a lot of research behind it and there are a variety of algorithms that people use to get a non-player character (NPC) from one place to another. For the shopkeeper, however, my simple solutions worked just fine. His ATTACK AI can be summed up like this: Every now and then, turn toward the player. Every now and then, fire my shotgun at the player if they are close enough and I have the shotgun. If the player is below me, and not too far away from me horizontally, do nothing. Otherwise, if there’s an obstacle directly in front of me, jump. Otherwise, if the player is above me, jump. Basically, when the player is at the same height or above the shopkeeper, or far enough away from him to the left or right, he likes to jump… a lot. The strength of his jump is random, too. I wasn’t sure how this would work when I first coded it, but it turns out that jumping around a lot at random heights is an effective method of getting around obstacles and finding little gaps in the wall to get through. The repeated jumping also makes his movements seem manic and unpredictable, increasing his danger factor and going hand-in-hand with his angry and violent persona. It’s a great example of how thematic imagery can mask simple mechanics.

Interestingly enough, I noticed from the angry player’s posts that while he was getting more and more angry, he was also making progress, getting to the later levels and eventually beating the game. This convinced me that the difficulty was not itself the problem, and that I was right to not include an easy mode in the game, since it would have become an unnecessary crutch for players like him. The real culprits were all of the aggregate smaller annoyances that made interacting with the game more difficult. Spelunky did get easier with each update, but in a way that improved the core experience rather than watering it down. So in some sense, that angry player was right: The game was too hard. But not for the reasons that he or I assumed. If we were talking about the game of tennis instead of Spelunky, it’s as though this player asked me to remove the net because he was having trouble hitting the ball over it, neither of us realizing that the real problem was that I gave him a racket with broken strings. Another way to think about interpreting a player’s feedback is as a doctor diagnosing a patient. A patient brings his or her symptoms to the doctor (“My stomach hurts!”) and may even offer a possible solution (“I think it could be the flu!”). In that scenario, it’d be a bad idea for the doctor to either dismiss the validity of the patient’s symptoms or to blindly accept that they have what they say they have. Like patients, players are often most in tune with how they feel ...

about the problem rather than what is causing it. Doctors and game developers, with their experience and knowledge of their field, need to ask questions, perform tests, and eliminate possibilities in order to zero in on the correct solution.

Another game developer might be able to articulate problems that your average player can’t, but their understanding of the development process may cause them to miss the forest for the trees, obsessing about minutiae that most players won’t notice. This becomes even worse if the developer is a friend or someone from your social circle, since it adds a layer of sympathy that the honesty must cut through. I’ve often felt the temptation to suggest to another indie developer that they fix this or that small problem when something more fundamental was the real problem. It can be hard to tell someone to start over when you know how hard they’ve worked.

Miyamoto once said that his childhood exploration of the Kyoto countryside was the inspiration for creating The Legend of Zelda, a top-down action-adventure game set in the fictional land of Hyrule. Recalling the time he discovered a lake while hiking, he explained, “It was quite a surprise for me to stumble upon it. When I traveled around the country without a map, trying to find my way, stumbling on amazing things as I went, I realized how it felt to go on an adventure like this.” It’s the perfect way to describe my experience with The Legend of Zelda as a child, when my dad and I spent many hours meticulously exploring and mapping Hyrule. As I moved from screen to screen, slaying monsters and prodding the environment for hidden secrets, he would mark them down on our map with colored pencils.

In my suburban hometown of Pasadena, California, there was the famous Pak Mann Arcade, which had the best selection of games but never shook its reputation for being a seedy hangout for “Asian gangsters.” And then there was Tilt, tucked away neatly in a corner of the mall, where I would weave my way to the back to beat up thugs in The Punisher. I also spent more than a few quarters on the Mortal Kombat cabinet in a nearby ice skating rink, trying to rip out people’s spines as Sub-Zero. Arcade games were even more violent, zany, and sexualized than the games I played at home, and arcades themselves were dimly lit and smelled like sweat and smoke. The brevity of my experiences with these games only added to their mystique—more often than not, a visit to the arcade was just a side trip, somewhere to spend a few quarters before moving on. When my elementary school friends and I became obsessed with Street Fighter II, we spent more time theorizing about the game than actually playing it. The home and arcade gaming experiences have always been defined, and separated, by how they’re played. In PC and console gaming, single-player campaigns are sometimes expected to last hundreds of hours long, but the optimal length of an average arcade game is around 30 minutes to an hour—short enough to play through in a single session, standing on your feet. And while someone who has spent $60 on a big budget home game might be willing to sit through long tutorials or cutscenes, those features...

would be suicidal in the arcade environment, where the player’s time is limited and they’re buying games a quarter at a time. A dull game might tease the first quarter out of a new player, but it will quickly lose the rest to any number of great-looking games a few feet away. Looking back at the arcades of the 80s and 90s, it’s easy to see the games that stood the test of time were lean, sinuous animals that offered a lot of challenge and excitement in a short amount of time.

Beating Spelunky from beginning to end takes, on average, about 30 minutes to an hour, that perfect arcade length, and there’s pressure to move quickly. Lingering too long in a level will induce a scary message (“A chill runs up your spine!”), followed by a steep drop in the music’s pitch. The source of this nightmarish transformation is revealed soon enough as the ghost floats onscreen from somewhere outside the level, its mouth gaping open, and begins to slowly give chase. The warning that precedes its entrance is clear enough: instant death if it touches you! Timers are a popular carry-over from arcade games that depended on the patronage of easily distracted crowds and were designed to prevent any one player from hogging the machine. Anyone who’s spent time in arcades during the 80s and 90s is probably familiar with the sight of a frantic arrow or cartoon finger pointing to one side of the screen, emblazoned with the word “GO!”—the games say it so that the people waiting to play don’t have to. When timers in video games run down, they typically kill the player immediately like in Super Mario Bros. (i.e. a “hard timer”) or make life more difficult for them (i.e. a “soft timer”). In Taito’s Bubble Bobble, the command “Hurry Up!” is displayed on the screen in suitably bubbly letters before the frightening “Baron von Blubba” appears onscreen and begins pursuing the players. Does a timer make sense for someone playing Spelunky in the comfort of their own home, though? Why n...

not let them take their time if they want to? I think it depends on what type of experience you want to give your audience. While the arcade business model may have shaped the design of the games, in many ways it shaped them well—maximizing a player’s time was a trait of successful arcade titles. Ultimately, I never intended Spelunky players to collect every piece of treasure, get every item, or explore every room each time they play. Instead, I wanted to force them to make difficult decisions and experience both the satisfaction of choosing correctly and the regret of choosing poorly. Collecting treasure and acquiring items without limitation is joyless, but add some time pressure and it becomes an exciting dilemma that makes skillful play more meaningful. Good players can make better decisions within the time constraints and are rewarded with better results. In Spelunky, they can even use the ghost to their advantage: Leading the apparition over large emeralds, sapphires, and rubies will cause them to change into more valuable diamonds.

The question is, once you’ve introduced shortcuts, how do you get players to stop using them of their own accord? I wanted players to realize that Spelunky was designed to be played from beginning to end in one sitting, like an arcade game, but I didn’t want to say it explicitly in a text message, since that would rob them of the satisfaction of realizing it themselves. My solution was in two parts. The first was already built into the basic design. How do you convince a kid to take training wheels off her bike? Simple: You don’t need to, because bikes can be ridden faster and with more control once the training wheels are off. Once you understand Spelunky well enough, you come to realize that it is a huge boon to start each run from the beginning, because there are more opportunities to prepare yourself for the difficult later sections. Bombs and rope, for example, are easily obtained in crates or from the shop in the second level of the Mines, and these items are crucial to overcoming obstacles later on. Likewise, each level you skip is a missed chance of getting kissed by a damsel or currying favor with Kali by sacrificing monsters on her altars. It might also mean missing a chance to grab a shotgun from the hands of a stunned shopkeeper, along with all of his wares. A new player may barely make it to the Jungle with anything, and that’s when shortcuts are the most useful. But with more experience, they’ll find it a setback to start there with only the basic equipment. ...

The second part of my solution was added deliberately. Recalling Miyamoto’s saying that “a good idea solves many problems,” I developed something that not only obliterates the long-term usefulness of shortcuts, but also serves as Spelunky’s biggest secret. I call it “The Chain.”

I call it the Chain because it’s not just a single secret, but a chain of secrets that culminates with the player entering a special level called the City of Gold. There are four major items in the Chain, corresponding to the four areas of the game, and each item is used to obtain the one in the next area. The first item is the Udjat Eye, locked inside a unique treasure chest with a golden lock—this chest and the gold key that unlocks it are generated in one of the last three levels of the Mines. The chest is always generated somewhere on the path from the entrance to the exit, but the key can be hidden in any alcove on the map.

The Black Market was created to expand upon Spelunky’s shopping experience, which added so much wonderful complexity to the game. I loved the various interactions the player could have with the shopkeeper, and how being a wanted criminal created a narrative thread that ran across levels, heightening the experience of being a treasure hunter. Unlike a normal level, the Black Market is mostly static in its layout and contains seven shops and seven shopkeepers. Two shops always appear in the same place—the Dice House, where you can roll dice for a chance to win money and prizes, and a small stall that only sells one item, the Ankh. The other five shops are randomly generated from the remaining shop types.

There is another problem with difficulty settings, which was made apparent during my discussion with the angry Spelunky player: Offer players an easier difficulty setting up front, and some of them will take it even though they could handle more challenge. My solution to this was to weave difficulty seamlessly into the game itself. If you’re a new player, your goal is to deliver supplies to the Tunnel Man so he can build shortcuts to the Jungle, Caves, and Temples. After that, your goal is to defeat Olmec and beat the game. From there, you’re ready to tackle the Chain. But whether you’re mining out the City of Gold or simply trying escape the Mines, you’re playing the same Spelunky. This way, everyone can focus on playing instead of wringing their hands over an uninformed decision. Once you’re ready, your knowledge and understanding of the game will make the harder challenges apparent, and you can go after them without switching into a different mode. The Chain’s final purpose is to provide permanent features to a randomized landscape. Although randomization gives Spelunky and roguelikes their longevity and makes each playthrough feel unique, it’s what stays the same from run to run that makes the world feel real. But without the randomization, playing the game enough times to figure out the Chain would be much more repetitive. The permanence of the Chain and the randomization of the world work in tandem to give you a greater appreciation of the other.