The Super Mario World Method: Using Evolutions and Expansions

This is a follow-up to my first tutorial on using the Nintendo method of level design. During the creation of Super Mario World, the design team at Nintendo (perhaps serendipitously) created a method for building and organizing level content. I call this method the “challenge, cadence, skill theme” system, or CCST for short.

In the previous tutorial, I defined the terms challenge and cadence; if you haven’t read that article, this one isn’t going to make much sense. In this article, I’m going to talk about how to use the primary types of challenges, evolutions, and expansions.

Although the CCST structure is a means of organizing level design content, it does not restrict the creativity of the designer by any means. Indeed, I'll show you how the CCST structure helps designers to make the most of a limited set of tools for creating level designs.

My Example

I have created a level here which shows how to produce a number of different (and increasingly difficult) challenges with only six different enemies/obstacles. I'll refer to this level throughout this tutorial, so take a look at the playthrough below:

Level code: 1288 0000 00EC F5A2

The Use of Evolutions

For the first seven challenges in the level, I’m going to focus on using evolutions. If you recall from the first article, a challenge evolves when it becomes qualitatively more difficult than the previous challenge, while keeping the same essential idea.

Let’s see how this works in this level. Here’s the first challenge the player comes across:

It’s a simple instance of a Thwomp which will drop from the ceiling when Mario comes close enough to it. It’s a very simple design idea, and the evolution of this is also fairly simple.

All I did here was to add the rotating fire trap. Instead of running straight through, the player now has to make a small jump to get over it.

Adding a new element to an old element is probably the most basic form of evolution. When there are more obstacles to think about, the challenge is more difficult—it’s a pretty simple dynamic, but it’s also a building block for more difficult challenges.

For the third challenge, I add a new element: a pitfall just to the left side of the Thwomp.

This pit forces the player to jump, meaning that the player has to make a jump into the Thwomp’s line of fire (so to speak). You’ll notice that this isn’t much more difficult than the previous evolution, and it’s not supposed to be. Both of these evolutions are simply branching off from the first challenge, but in different directions.

Next, I introduce an evolution of the pitfall: a fireball shoots up at a regular interval, meaning that the player has to wait for the right moment to jump over the platform and underneath the Thwomp. This is clearly building on the previous challenge, and it is a little harder—but it’s still not that hard yet.

For the next challenge, I add together everything that the level has done up to this point:

This is the most difficult challenge so far, because it has three obstacles working in it at once. Most of the time, three obstacles is the greatest number you’ll see in a Nintendo challenge. This challenge is pretty difficult, and about as hard as most Nintendo challenges get. You might aim for something harder in your own games (or your own Mario Maker levels), but the technique I use here is still a means to getting there.

For the next two evolutions, I actually drop the difficulty a little bit, and instead focus on qualitative variety. One game design principle that I cannot stress enough is that levels should not always get harder in a linear fashion. The difficulty of most levels goes both up and down. Sometimes, it’s enough for challenges to simply be different, rather than more and more difficult.

With that in mind, for this evolution, I remove the pit and replace it with a Chain Chomp.

And then, for the final challenge, I bring back the pits and fireball, but I drop the rotating flame trap.

These are still fairly difficult challenges, but they don’t keep piling design elements up. There’s a limit on how much stuff you can stack in your challenges before the challenge stops being fun and starts being annoying, although that limit depends a lot on context.

The Use of Expansions

Before I get to the overarching lesson that we can learn from evolutions, I want to look at the proper development of expansion challenges. In the previous article, I defined expansions as being like evolutions, except that they change quantitative elements of some challenge before them. Let’s take a look at a very simple expansion, now.

This is the first expansion. We're going all the way back to the first challenge in the level, and simply doubling the number of Thwomps.

The key question to ask is “what is the relationship between numerical increases and perceived difficulty?” This challenge is numerically more dangerous than its ancestor, but despite doubling the number of Thwomps, there's not a huge change in player's effort level.

This is an important principle to understand about using expansions: the difficulty of a challenge does not scale linearly with expansions. Expansions are just as dependent on context as evolutions are, despite being different in construction.

Let's take a look at another expansion.

Doubling the number of flame traps creates a challenge that is significantly more difficult than the doubling of the Thwomps (especially since their rotations do not sync up). In fact, this is probably the most difficult challenge in the whole level. The same kind of expansion as before is going on, but the player's experience of it is significantly different.

But what about an expansion with a totally different element? Here's an expansion of the jump-distance.

This is a slightly less-obvious ways of implementing expansions. I've increased the size of the pit by two block-lengths (doubling its size, just like I doubled everything else), meaning that the player will definitely feel the change in the size of the jump, even if the change isn't obvious at a glance.

The interesting thing about this challenge is that the expanded jump-distance actually doesn't make the challenge that much harder. Part of the challenge of the fireball jumps is that the player has to angle Mario's descent so as not to collide with the Thwomp.

The jump over the larger pit actually changes Mario's jump path so that he'll be farther away from the falling Thwomp, and safer! The initial jump is still more difficult than its ancestor, but the overall challenge might not be much harder at all. These are the things to be on the lookout for during play-testing, if you're using the CCST framework.

Next, I return to the more obvious form of doubled elements, by inserting two fireballs.

This challenge is harder than the two Thwomps, but easier than the two flame traps. Doubling the number of fireballs creates a slightly smaller window of time in which the player can jump through the challenge, but it’s just not as hard as the challenge immediately prior.

The takeaway message here is that, although expansions are very easy to implement at first, they can be very difficult to balance. Doubling one element is not the same as doubling another element, no matter how similar those two elements are.

Expansion by Contraction

There are other ways of using expansions to make challenges more difficult. One method I like a lot is what I call the expansion by contraction. It's an oxymoronic term, but it captures the idea well. Let's take a look at one:

What I've done here is to contract the amount of safe space between Mario and the Thwomp. It's clearly a numerical increase in difficulty based on the first challenge in the level, so we still call it an expansion, even though it's reducing something. Almost always, expansions by contraction are executed by reducing the space between Mario and some danger. Sometimes it's done by moving closer to the danger, and sometimes it's done by reducing the size of a platform; it all depends on context.

The biggest danger in the expansion by contraction is contracting too much, so that the player simply cannot get through the challenge without taking damage. My last challenge does this: the final Thwomp is so close to the ground that Mario must end up being hit by it if he tries to run past them all.

This brings up two very important points about the use of expansions.

The first point is that there is a limit on how much a design element can expand numerically. Eventually, the pits will be too wide, the enemies too many, or the safe spaces too narrow. If you want to design your level up to the maximum threshold of expandability, it’s probably a good idea to design backwards, starting from the maximum and working back towards a smaller beginning.

That said, the other important thing to know about expansions is that sometimes they’re just psychological. In the last challenge I showed you, the first three Thwomps will not actually reach Mario if he remains at full speed, so the danger isn’t that great. If the player feels like they’ve just done something flashy and complicated, then the level has done its job well enough.

Conclusion and Tips

This was a long and somewhat winding article, so I’d like to reiterate some of the main points here. The overall point is that although there are clear, repeatable strategies for developing level content, those strategies do not produce perfectly predictable content. Really, this is a good thing, because it means that the CCST framework still offers plenty of room for creativity. The framework isn’t about making paint-by-numbers levels; it’s about organizing your content so levels can be both coherent and challenging.

• A handful of mechanics are enough to fill an entire level if you mix and match your design elements. My level had only six different types of obstacles in it, but I actually ran out of room before I was even close to exhausting the possibilities.
• Introduce and use several different evolutions of your main design idea.
• You can stack the different evolutionary branches of your level up, but be careful about stacking too many at once. Usually, any two evolutions can be made to work together, but once you hit three, you should make sure it’s not too difficult or time-consuming to play through.
• Expansions are numerical in nature, but the player’s experience of an expansion will not usually match the expansion perfectly. That is, if you double something, it’s not going to make the challenge twice as hard. It could be 10% harder or 400% harder; it depends on what you’re expanding.
• There is an absolute limit on how much any design element can be expanded. If you want to push this limit in your level, consider designing backwards.
• Remember that a player’s subjective experience of your game doesn’t have to match the nuts-and-bolts numbers of it. If something feels more challenging than it really was, you may have achieved your design goals.

Nintendo created several games using this method, or a slightly modified version of it. What’s more, the CCST framework (evolutions and expansions) appears in lots of other kinds of games, not just Nintendo titles or platformers. At the end of the day, this method is just a means of organizing your content, not of changing the voice of your game.