How Spelunky Creates Amazing Unexpected Situations

This is The Mechanic, where Alex Wiltshire invites a developer to help him put their game up on blocks and take a wrench to hack out its best feature, just to see how it works.

The arrow trap that shoots the croc man that causes him to telefrag you. Being caught mid-jump by a boomerang that juggles you towards a spike trap, leaving you stunned in front of it until it springs. Shopstorm.

These are not necessarily the noblest events in Spelunky, but they’re surprising, funny, fascinating, and entirely consistent and logical and correct. They might not be exactly your fault, but neither are they, really, the game’s fault. They’re the result of a big reason – the big reason? – why Spelunky is amazing:

THE MECHANIC: How every object in Spelunky has shared fundamental traits

That’s a pretty snappy name. It’s the root of all the interactions between the different items, traps, monsters and other objects that populate its world, and all the fortuitous, hapless, funny, enraging, and wondrous things that can happen as a result.

And it exists primarily for simplicity. “I think at one point I was asked how I could possibly handle all of the cases that come up in Spelunky, like when this item hits that,” programmer of Spelunky’s 2013 remake, Andy Hull, tells me. The answer is that every object in the world has default behaviours and properties. For instance, Olmec is actually a glorified push-block. When the spiked balls in Hell are sent flying, they become boulders. The way hawk men, croc men and shopkeepers bounce around when enraged – they share the exact same movement abilities.

“When you’re coding a game you think about what traits things share naturally, right?” says Derek Yu, creator of the original Spelunky. “You want your code to be efficient; you don’t want to be reinventing the wheel for every new thing.”

All Spelunky’s richness, therefore, is down to a programmer’s shortcut, and a way of structuring code. And all its objects are either an item or a monster. The main difference is that monsters automatically inherit extra variables for getting around. “They’re pretty similar,” says Hull. “It kept our code organised and we didn’t get weird things like push-blocks running around shooting shotguns.”

So Olmec, the core (kind of) boss of the game, is an item, not a monster. He’s a push-block, but has special-case properties that make him distinct, such as being able to move independently, not be pushable by the player, to have other push-blocks stacked on his head, and to be able to crush these blocks if he jumps and the ceiling is too close, so he doesn’t get stuck. If you want to see what the code looks like, Yu and Hull gave us access to some of Spelunky remake’s source code, which gives some insight into what makes Olmec and the shopkeeper tick.

As far as the game’s concerned, it just goes down the list of properties to figure out how to resolve any particular situation. Is this a heavy object? A light object? A breakable object? Can it take damage? If something breakable hits a wall, then the thing breaks. If the player whips the ghost, then – well.

“It might be good to mention the ghost, because it’s a case where the default led to a pretty interesting situation,” says Yu. The ghost was meant to be invincible, and as far as Yu knows, in his 2008 original, it is. But people figured out how to kill the ghost in the remake, and the way they did this is down to these shared traits.

The ghost appears when you’ve been on a level for over two and a half minutes, if you take the Crystal Skull, or if you destroy too many of Kali’s altars, and it’s a monster with a few special-case properties. Objects don’t collide with it, they don’t deal damage to it, and it has 9999 hit points. “I think we put that in probably just as a failsafe, right, Andy?” says Yu.

“Right, yeah, when I was implementing it, the hitpoints had to be filled in,” Hull replies. But he was also aware that there might just be *something* that could damage it, so he didn’t give it one hitpoint. 9999 seemed right.

“It’s definitely not something we thought about very hard,” says Yu. “But of course you can never play it safe enough, I guess.”

It turned out that the ghost could be damaged by lava. Lava causes any monster to lose 99 hit points when it touches it, an instant kill. One day a player noticed the ghost hit lava and display a hit effect, something it had inherited from being a monster, and the player realised it was taking damage. And so, soon enough came the discovery that by moving the ghost in and out of lava 101 times, it could be killed.

Yu and Hull were happy. “It’s a cool property of the game!” says Yu. “It doesn’t really bother us because it becomes part of the lore, like this supposedly unkillable thing is killable. That someone worked out how to kill it was pretty nifty.”

Another example is the Moai, a statue found in the Ice Caves that’s part of the City of Gold route through the game. Players are meant to have the Ankh item and then kill themselves to find themselves resurrected at the Moai with a new item, the Hedjet, and a door having opened in the Moai’s mouth. The Moai itself was meant to be indestructible, and it would be if it wasn’t for the ball and chain.

“It’s crazy, right, because it’s meant to be a punishment!” says Yu. The ball and chain is attached to you if you destroy too many Kali altars, and it makes it hard to move – you either have to drag the ball behind you, or pick it up, meaning you can’t carry something else. But what the ball also does is to tear through blocks if it’s placed on a ledge and you hang below it, a feature that was meant to stop players from getting stuck.

The Moai is actually an image covered by invisible, invincible floor blocks. And what players discovered, namely BaerTaffy and bisnap, is that the ball could destroy them just like any other. “The floors are set to invincible but the ball and chain doesn’t check that at all,” says Yu. “We never considered anyone would try to use it on the Moai.”

“So the reason it doesn’t check the invincibility flag is that the only other blocks in the game that are invincible are the frame blocks around the level,” says Hull. “I knew when I was coding the ball that there was no way to get it on top of the frame with the player below it. So there was no sense to check it. That was the oversight. There was somewhere else with invincible blocks! It just wasn’t something we foresaw – there are so many interactions to consider that it’s pretty much guaranteed that something would fall through the cracks.” Still, again, it became part of the game’s lore, and a critical component of the utterly amazing solo eggplant run, and so the only thing Yu and Hull did was to change the graphic for the Moai to indicate the damage the ball does.

Mostly, though, this system of reuse is about the opposite of glitches and bugs – it’s about enabling interesting interactions, and it also made development and testing easier. “We only had to find the things that we didn’t think of that weren’t working in an acceptable way already,” says Yu.

“Some people say that it would be better if we handcoded exclusive systems for handling interactions, but the problem is that you’re segregating them from the rest of the mechanics of the game,” says Hull. “If it interacts with the rules already, even though it’s slightly not as good, it’s going to have so much more play with the rest of the game. It’s more interesting immediately, which is way more valuable than that extra bit of polish you can get with a separate implementation.”

So there are the revolving spiked balls in Hell, which fly off when detached and smash through the level like a boulder – because that’s what they functionally become. Each item is simply defined by an identifying number, so Hull could tell the spike ball that it’s now a boulder; it’d keep its visual properties but suddenly start to interact with the rest of the game as a boulder. The freeze ray is similar – the same projectile (which to the game is an item) comes out of both the gun and the mammoth’s trunk. It even comes into play in the cutscenes, which run entirely in the game engine. In the intro, the character is placed on invisible blocks with a sand graphic in front, while the game simulates a controller input to the right.

“It actually gives us an interesting interaction at the end of the game where you’re shot out of the volcano, you fall on to the ground and you drop the item you were holding because you fell too far. But if you have a parachute it’ll actually deploy and float to the ground.” Yu laughs – it’s the best laugh, a crazy infectious giggle.

“And you can keep your item through the rest of the cutscene that way, which is pretty amazing, right?” continues Hull. “It wasn’t something we planned out, but it’s a nice little touch. The game’s still functioning, even in the end when you can’t even control it any more. It reinforces how the whole game works.”

“I’m pretty sure we had bugs were you could land in that ending cutscene and you could actually die, because you take fall damage,” says Yu.

“The fix was pretty lame,” says Hull. “It just gives you an extra life at the beginning of the scene and you’ll lose it when you hit the ground.” Yu laughs again.

“And then the blood!” says Hull. “When I did the mummy vomit, the vomit itself is just actually just green blood. We were putting it in, late in development, and I was like, what do we have that already does the thing I need? Well the blood, vomit, same difference. It’s a liquid that can squish around and bounce or whatever, so I just made a new graphic of the blood turned green and made vomit. Of course, later in development, we put in the Kapala that collects blood. We didn’t even realise the interaction existed until the game was out; people were collecting mummy vomit and it counted as blood. I’m like, of course it does. It *is* blood. It just became part of the lore.”

“People basically farmed the mummies, getting them stuck on a ledge above them with a hole the vomit could fall through, so they’re just endlessly throwing up on to the player until they had 99 health!” says Yu.

This is why Spelunky is great, but to be clear, Spelunky is far from being the only game to be coded in this way. Dwarf Fortress takes it to a whole extra level, and it also underlies games from Skyrim to GTA V. But there’s something extra special about the way Spelunky works. Perhaps because it’s an action game and also very legible, with clear cause and effect. And partly because its objects are so defined in their properties. When something unexpected happens, everyone really notices it, even Yu. “I think things that surprise even the designers themselves make the world feel that much more real, versus something that was designed.”

Derek Yu has written a book about how he made Spelunky that comes out on March 29. You should definitely pre-order it now.


  1. April March says:

    Very interesting. It makes me think of NetHack, which of course did go the route of having the developers actually plan a lot of weird item interactions. “The dev team thinks of everything.” The flaw of this approach is that, of course, they don’t – there are many things that they just couldn’t think of, and many things they think should work one way when the public thought should work another (just look at the interactions between wands and inanimate objects in NetHack vs. SlashEM). But the worst part in my opinion is how these coded interactions would allow people to identify items by using them in controlled ways, and while many fans of the rogues would think this item identification dance is central to what makes NetHack and its kin fun, I think it’s a boring and counter-intuitive way to bypass what should be a fun activity of trying to figure out what you have and getting it wrong.

    Of course, if there’s no way to identify items them the optimum strategy is to hold them until you’re fucked and then hope that the potion you randomly decide to drink isn’t a Potion of Randomly Bursting into Fire. But see Dungeon Crawls simple, elegant, and, most of all, nice solution to this conondrum: health potions spawn more than any other, so drinking the potion you have the most of is your best bet. Even when some vagrary of the RNG causes you to find more Potions of Turning your Small Intestines into Buzzsaws more than potions of healing, you don’t feel cheated when that happens, because you know you were playing the odds.

    Of course, Spelunky doesn’t even have item identification, so I’m prattling on. But, given that NetHack is the poster child of oldskool roguelikes, (perhaps even THE Game that is Like Rogue), whereas Spelunky is the poster child for the newskool ones, it’s interesting to see how big is the difference between their most basic and intrinsic approach to the elements in their worlds: simple, consistent, unified and physical versus complex, unique, esoterical and mystical.

    • Baines says:

      Nethack and other classic Roguelikes have such identification methods in place in order to make item identification more than just desperately using an item and hoping that you live. Many of those systems do attempt to have some measure of logic to them. It might be worth noting that the original Rogue gave you the ability to recognize both the potion of paralysis and scroll of scare monster through alternate methods, as those two items had specially coded alternative uses. Other Roguelikes took those ideas and expanded them across more items, both for more variety and to counter the unfairness of so many items now existing.

      Various Roguelikes also have degrees of generic item definition and interaction. Angband’s monster dat file looks rather similar to the Spelunky code included in the article above, for example. And some games have pushed elements further.

      It is also worth noting that the classic Roguelikes were originally written before Object Oriented Programming became the new Really Big Thing in coding. And those early years of the rush to teach and spread C++ and the tenets of OOP also lead to creating some rather ugly coding methods, as people tried to turn everything into a single massive tree of inherited classes.

      And while some would dream of game worlds that functioned from generic rules applied to objects defined by their generic component properties, the dreams were often far too ambitious to be practical. You could be more productive, actually getting out something playable, by using the old methods.

      • Geebs says:

        I dunno, OOP and class inheritance seem like a great way to get accidental emergence which is still mostly logically consistent. In fact, giving your game entities a set of properties and setting them loose is far more interesting to me than hard coding a bunch of stuff and then relying on RNGsus to sort out what happens.

        Not really arguing, I mostly posted to say that this series of articles is awesome.

  2. theholypenguin says:

    Great article, perfect game. Good timing too, as there was a new Spelunky world record set today:
    link to
    100 seconds. eeep.

  3. kikito says:

    Great article series. Just one note on this one: when something unexpected happens because there is a set of simpler rules going on, like in this case, that’s called “emergence”. And you get “emergent behaviours” etc. The poster child of emergence is The Game of Life, in which 4 simple rules can produce complex patterns which were not “hard-coded” by the programmers.

  4. Syrion says:

    Interesting article, really cool series!

    The case of cutscenes still adhering to the game rules reminds me of GoldenEye on the N64. In it, getting to a specific area, mostly the exit, just starts the (ending) cutscene in that level and often other characters appear. But as it really is the level you were in before, you can have a lot of fun messing it. The most obvious one is throwing grenades and other explosives, watching the cutscene start, and then they explode and lots of the characters die, with Bond still talking to them.
    You can even still use your weapons in those cutscenes by switching the control layout to one rarely used by players, using two controllers at once. Normally the control is taken away, but aparently the programmers only disabled the controls for one of the controllers. Seen here: link to

  5. MondSemmel says:

    “You should definitely pre-order it now.”
    Isn’t this against RPS’ editorial policy? In general, it’s bad news when journalists act as ads. Don’t do that, Mr. Wiltshire.

    • JFS says:

      Yep. The last time I pre-ordered because of RPS, I got an XCOM game that is fun but to this day – four weeks after release – hasn’t had any more fixing done than changing the preset maximum graohics setting and two bugs.

      • basilisk says:

        Yes, and I’m pretty sure the book won’t receive any bugfixes either!

  6. MakeSkyrimGreen says:

    No mention of games like Deus Ex, or Dishonored that frequently exhibit emergent situations due to the simulation of various interacting propertie?

  7. MadTinkerer says:

    I checked the source code for the Game Maker version of Spelunky and found that the Ghost enemy doesn’t even inherit from oEnemy, it inherits from oDrawnSprite! So there’s really no way to kill it in the original.

  8. Catchcart says:

    Excellent piece, thank you for that. I’m delighted by still finding new and strange attributes of stuff in Spelunky after two years of playing. Only the other day I realised that throwing spider critters causes damage. I’ve been looking out for Yu’s book – definitely a must for any Spelunky-obsessive like myself.

  9. says:

    Maybe I’m just terrible at the game, but I’d really enjoy a ghost-free mode.

  10. FriendFive says:

    This was very interesting to read, but it just made me sad because I am so terrible at the game. After over 50 hours of playing it, there is so much content I have never seen. I don’t think I’ll ever beat the game, but it is really quite a fantastic design. I’m just no good at roguelikes.