Level Design Primer Part 3: Obstacles and Player Choice

Last chapter, I talked about obstacles in the most simple terms: Something that tests a specific player skill. However, you can also make a challenge that provides the player a choice between multiple skills. You’ve given them a problem and there are multiple (more or less equally challenging) ways to get around it. In fact, such choices are often implied by your game design.  Let’s look back at an example from the first part:

Get Adobe Flash player

There is a choice inherent in that enemy. You can either shoot it or avoid it. While neither is particularly difficult, they both require at least small amount of skill. When there are multiple ways to solve a challenge, the player is going to choose the way that better suits their own play-style. In other words, if they are better at shooting, they will likely shoot, and if they are better at avoiding, they will likely avoid.


The game Deus Ex was an excellent example of this concept, as most levels allowed for a mix of stealth, combat, and hacking to progress. You could sneak around enemies, fight them directly, or manipulate the environment to give yourself an advantage. The one thing you couldn’t do, however, was bypass the challenges completely without using at least one of your player skills. If you didn’t want to fight, you had to sneak. If you didn’t want to sneak, you were going to have to fight. There was a clear obstacle in your path, and while there were several ways through it, there was no way around it.


A strong way to build choice into your levels is through risk vs. reward. In other words, you can have one option have moderate difficulty, and have a second option with higher difficulty that will make things easier in the long run. A classic risk/reward mechanic exists in Mario. In Mario, most obstacles can be avoided by either jumping over them, or jumping on top of them. Both are challenging, however, jumping directly on enemies is both more difficult and more rewarding. You receive points, and also remove that enemy from the game so it can no longer threaten you.


So I’ve talked about how player choice can be inherent in your mechanics and enemy design. But this is a series on level design. How do you use level design to promote player choice?


Well, there are quite a few possibilities in that regard. You can provide the player with multiple paths that lead to the same goal, thus letting the player choose which obstacle they wish to face:


Get Adobe Flash player


You can embed some extra goal within the level which is challenging to get to, thus creating risk vs. reward. The player can head straight for the exit, or they can go out of the way to get the special item that will help them down the road:


Get Adobe Flash player


And, of course, you should always keep your mechanics in mind when designing levels. If you want to make a game where the player can choose between stealth and combat, make sure both are viable options in your level design. Build your level so the player could conceivably win a fire fight, and also put in enough hiding places and place the enemies in such a way that the player could sneak around them (and make sure both options are challenging to the player).


Here’s one last example which puts these together to a certain degree (and also keeps the last article in mind: this level would fall apart if you could shoot in more directions). You can run around and avoid the attacks (made more difficult by the uneven ground, since now you have to avoid attacks while also jumping around). You can also take out the enemies threatening that tunnel, but to do so you have to get past some other enemies that are guarding them (and you can either avoid or attack said enemies):


Get Adobe Flash player

 Next time I’ll talk about other sorts of obstacles that don’t necessarily involve quick reflexes.

<–Part 2: Fitting Challenges to Mechanics –>  ——– Part 4: Mental Obstacles –>

This entry was posted in Level Design. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *