We’ve put a lot of work into designing, building, and testing our levels. In particular, now that we’ve got a lot of the other pieces in place and a good amount of user-testing done, we’ve been focusing quite a bit on level design. After all, as a puzzle game, the most important part of our gameplay is the puzzles themselves. An incredible game can end up flopping due to bad puzzle design, and a mediocre one can actually do really well, if the level design is good.

But how does level design actually happen? We have a bunch of levels, but how did we come up with them? What’s the process?

 

Design Process

The problem with level design is that it’s an inherently creative endeavor. I’ve always had trouble with this type of task – if I sit down and work on something for an hour, I want to see some measurable progress. But if I try to work on level design for an hour, I could literally just be sitting there thinking the whole time, with nothing to show for it. This (at least for me) is one of the reasons that level design often gets pushed to the proverbial back burner. I always want to work on game features, because I know I can make some progress on them, so I opt to do that rather than level design. However, this can be a dangerous prospect, as this is a great way to end up scrambling for levels, putting too little thought into their design, and releasing a great game with bad puzzles.

You can’t just say “I’m gonna go design a level!” I mean, you can (and sometimes I do), but that’s not the best way to go about it. Unfortunately, you’re really at the whim of your own brain – you have to be struck with inspiration. The best levels I’ve designed didn’t happen during a ‘level-designing brainstorm’. They happened when I was walking down the street, or sitting down at dinner, or pretty much anywhere, when I noticed something that made me think of a cool level. Inspiration isn’t something you can schedule, work hard at, and then just do. It has to come to you, which, for me at least, is terribly annoying.

 

Designing for Where Shadows Slumber

All of this gets even more difficult when it comes to designing puzzles specifically for Where Shadows Slumber. Any innovative puzzle game has a sort of quirky concept, a hook to get users to take notice and to make the puzzles more unique and interesting. For us, of course, it’s the shadows and the ever-changing nature of the world, and those aspects of the game are what make it the hardest to design for.

So you sit down and design a level. It looks pretty cool, it’s got a nice flow, it seems challenging and fun. You show it to your team, or you start to implement it, and suddenly you realize – it just doesn’t work. There’s one small thing that prevents the level from working, whether it be a light in the wrong place, an object that should cast shadows but can’t, or maybe it’s just too difficult for a user to get. These aren’t great examples, but this type of situation comes up all the time. We designed around 30 levels for Where Shadows Slumber at the beginning of the year, and now we only have around 15. What happened to the other half? There was something small that prevented them from being good levels – and it’s hard to notice any of these issues until you implement the level and test it out.

The other difficult part of designing these intricate levels is actually communicating them to each other. Every level design, no matter how great, needs to withstand the feedback of its peers. The problem is – how can we show these crazy levels to each other?

We’ve tried drawing them and sending them to each other, but they’re often too intricate to really ‘get’ from a drawing. In the end, the only process we’ve found for sharing levels is to sit down in the same room together and talk through what the level consists of, along with the drawings. Even this isn’t good enough for a lot of the more complex levels – sometimes the only way to show your team the level is to build it! This is very frustrating, especially when you build a level that’s no good, and you have to throw it out, but sometimes it’s a necessary part of the process.

 

Taking the User into Account

Of course, the real judge of level design is the user. It doesn’t matter if every one of your levels is a masterful blend of elegant design and game mechanics if your users don’t enjoy playing it. This is a pitfall that I continually see people falling into, and, as I recently realized, one in which I lived for a good portion of the development of Where Shadows Slumber. But no longer! Throughout our testing, the users have spoken, and we are listening!

What does it meant to design for the user? How do we know what they will and won’t like? That’s a difficult question without an easy answer, but I will share some of the tips that I try to stick to.

Listen to your users. This should be obvious, but sometimes it’s not. You have to get your game in the users’ hands, get them playing the game, hear their feedback, and actually listen to it! You’ll never know that users don’t like one of your levels unless you let them test it out, and your level design won’t be good if you disregard their feedback.

Difficulty/learning curve. If your game has a crazy mechanic or concept, the user isn’t going to know how it works – it might seem intuitive to you, but that’s because you’ve been working on the game for so long! You have to make sure that you gently introduce them to the mechanic, in a way that shows how it works while also keeping them hooked. And you have to make sure the difficulty ramps up before too long, or they’ll just get bored of your everlasting tutorial.

Remember that the user doesn’t know what you know. Some people phrase this rule as “treat the user like they’re stupid”, but I think that’s an overstatement. Your users aren’t stupid, they just don’t understand the subtleties of your game the same way you do. They will never do exactly what you expect, and they will never understand the level as well as you do. You need to keep that in mind, examine your level design with an objective eye, and make sure that the experience is enjoyable for the user no matter how they go about solving your puzzles.

Users want to feel smart. The people who pick up and play a puzzle game are usually pretty smart people, and they want to feel smart. This leads to an important design philosophy – make your levels hard, but not too hard. The user doesn’t want to just play an endless parade of easy levels – they won’t feel any satisfaction from beating them. On the other hand, the user doesn’t want to hit a near-impossible level – that’s just frustrating! Beating a level should be easy enough that your users will beat it without getting frustrated, but hard enough that they feel accomplished when they do.

Iterate and Re-use. Sometimes, your users won’t like a level – it happens. In this case, you shouldn’t simply throw the level out. An important part of design is iteration – if your users don’t like a level, figure out why. Figure out what you can do to improve the level. There are parts they don’t like, that you’ll probably end up taking out, but there are most likely some good things about the level, and you don’t want to waste them. Try to fix what the users disliked, and then head back to them and get another opinion.

 

If I Had to Skimp on Level Design…

Creating a game takes a long time, and there’s a lot to do. Sometimes, you just don’t have the time to pour your heart and soul into every level you design. Sometimes, you just have to put in a few ‘filler’ levels. When is it okay to do that, and what’s the best way to go about doing it?

 

As much as I’d like to say “all levels are created equal”, I can’t, because it’s not true. Frankly, there are some levels that are a lot more important than others. Which levels are most important? The early ones.

One of the biggest hurdles for a game is what I call the barrier to entry. If I pick up a new game, and the second level is really annoying, there’s a chance I’ll just put it down and never play it again, even if the rest of the game is phenomenal – I have no way of knowing that, and I assume the rest will be just as annoying. However, if I play the exact same game, but it’s the seventh level that’s really annoying, I’ve already played through six awesome levels. The game has earned some credit with me, so I’m willing to let one annoying level slide.

This is doubly true for puzzle games where the user has to learn the mechanics. If you don’t teach the user your mechanics very well in the first few levels, they’re not going to enjoy the rest of the game, because they won’t have learned how to solve the puzzles.

The third argument for this is simply a mathematical one. Every user who plays your game will play the first level. No matter how good your game is, there’s some rate of falloff – some people just stop playing. That means that almost every user plays level two, and most users play level three, and so on. So, the levels that will see the most playtime overall are the first levels, hands down (for any statistics nerds out there, this is basically the same premise as Benford’s Law).

So, if you’re running out of time for level design and you need to skimp on some levels, you should make it levels later in the game. Anyone who has gotten that far already likes the game (presumably), so you don’t need to sell it to them, and they’ll give you a little more leeway.

Now that we’ve tested some of our levels, we’re ramping up into more level design, and I though it would be a good opportunity to show you a little bit of our process. Hopefully you learned something about our level design process, and maybe you can even use it in your own projects!

 

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

If you have questions about our game design process, feel free to contact us! You can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebook, itch.io, or Twitch, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

Jack Kelly is the head developer and designer for Where Shadows Slumber.