Creating a Level: From Concept to Finished Product

For a long time, I’ve wanted to write a post about how we make Levels when working on Where Shadows Slumber. The only problem was a lack of documentation. I forgot to take screenshots of the early stages of the Levels we’ve completed so far. What I really wanted to do was show our audience the growth of a Level, from it’s earliest conception and then show the various stages of the design process along the way.

When I thought of this idea, I tabled the blog and decided to wait until I started on a new batch of Levels… and here we are! We’re going to take an inside look at Level 3-1, Noria, the first Level of the Aqueduct World.

 

Maker:S,Date:2017-8-17,Ver:6,Lens:Kan03,Act:Lar02,E:Y

Step 1: Draw The Level

Every Level has a reason for being in the game. Noria is the first Level in the Aqueduct World, which makes it extra special. Whenever we design the first Level of a World, we like to communicate to the Player:

  • Why the World is going to feel different from the other Worlds in the game
  • What mechanics you’ll be dealing with in this World – especially new ideas

For the Aqueduct, we wanted to make it all about mechanical devices, switches, rotating things and whirring machines. Our game doesn’t exactly have a precise historical setting, but it’s fair to say it isn’t modern day. This gives us some leeway with technology. It has to work, but it can look really old.

MVIMG_20171025_141620.jpg

Jack’s notebook!

The Aqueduct World is all about Buttons. Buttons are Nodes that do something when you step onto them. There are all kinds of Buttons, but the most basic Button does a thing every time you step on it, no matter how many times you step on it.

To show that off, Jack designed a Level (above) where the only way to cast shadows and move the light was with a single Button. In addition to that, there are Buttons near each light in the Level to turn them on and off. The proximity of the light to the Button it’s attached to is an intuitive connection. These Buttons work like regular domestic light switches too, so it’s a cheap way of using existing Player knowledge about the real world and transmuting it into knowledge of our game.

When a Level exists in this form, the only thing we can really do is discuss it. Jack will attempt to guide a very confused Frank through the mechanics of the Level. I’ll try to poke holes in it (literally, with my pencil) and find problems with the design. We’ve never shown these sketches to testers because it’s too high-level for them to understand. If we like the idea of the Level, Jack makes a grey box prototype of it in Unity for us to test.

 

Noria-Greybox

This Level doesn’t look too special yet, huh? Just wait!

Step 2: Make A Grey-Box Prototype Level

With a design solidified, now we’re ready to make a version of the Level that can be played and tested. It doesn’t need to look pretty yet, so we use basic template cubes to represent walkable space. Affectionately called grey box prototypes, this technique is how we prototype every Level in the game. Watch a video of me beating the Level below:

As you can see, it’s playable in this stage, and everything works. You can solve the puzzle, which means testers can assess the strength of our design. (We just tell them to ignore the visuals.) We brought this Level, in this format, to AwesomeCon 2017 looking for feedback from players. When we show grey box prototypes to people, we want to make sure they can complete the puzzle. More than that, we want to make sure that they solved it on purpose instead of just by brute force. If we get good feedback, we proceed to Step 3.

 

Noria.png

Step 3: Draw Some Concept Art

This might seem backward, but this is the time when I draw a concept image of the Level. Why do I do this after the Level has been prototyped, and not before? It’s because Jack knows best which Nodes need to go where, and I don’t. I need to take cues from him about where everything must be, which often includes the actual length and width of shadow casting objects.

This is actually beneficial. It gives me good constraints to work with. I draw a paper sketch and say, “OK, if everything absolutely has to be in this location, what can I do with it? What makes sense for the setting [Aqueduct] whether it’s man-made or organic?” As you can see in the drawing, the following ideas have been spawned:

  • Obe should enter from a pipe (bottom right) to match the cutscene that plays directly before this Level.
  • The pillar now looks like it belongs – it’s a crumbling structural element of the Aqueduct, a man-made structure in disrepair.
  • The mechanism by which the lamp moves left to right is not just a magical back-and-forth switch. Now it’s a waterwheel! Why a wheel? Google “Noria”…
  • The lights need to look like actual man-made lights since they are powered by Buttons on the ground. Why not lamps?
  • There are stone pathways going horizontally that have crumbled over time. Those need to be repaired by shadows.
  • The bridges going vertically are metal grates that allow water to pass under them. This is an Aqueduct, we can’t just have standing water blocked in!
  • There’s a back wall with a door. I like to give the Player as many visual cues as possible that the finish line is an actual exit.

The concept art phase is another chance for us to critique the design. If we know the puzzle is good, but it produces an awkward-looking Level, we have the opportunity to reconfigure things. Perhaps the exit needs to be in a different place? Maybe objects should be closer or further apart? Now is the time to match the design to the intended context, the Aqueduct. Once I have good concept art to work from, I proceed to Step 4!

 

DesignBlog-Noria-FirstPass.png

Step 4: First Aesthetic Pass

Now it’s time to take that ugly grey box prototype (sorry Jack) and make it look and sound beautiful! I’m ready to apply my toolkit of Aqueduct paths, walls and bridges to the design. Once the art is laid down, Alba and Noah have their first chance to put some audio effects into the Level and set the mood. It makes a huge difference: now the Level doesn’t sound like it takes place in a silent death vacuum! Creepy chimes and rushing water converge to give the Level a sense of place. Here’s a video of it all in action:

The Level doesn’t look grey anymore! That’s awesome. But… it also doesn’t look finished, does it? This kind of art would pass for a student game or something in a game jam, but we want to be an App Store Editor’s Pick and win a ton of awards. That means the art needs to be worth the price people paid to download the game. It needs to be extraordinary! It needs to be… polished.

 

DesignBlog-Noria-Polished

Step 5: Aesthetic Polish

Polish is a game design term for taking your finished product and finishing it again so it’s even better – much like shining a shoe with shoe polish. You want to make your Level shine! If you’re making an island paradise, it needs to be the most relaxing paradise the player has ever experienced. If it’s a scummy slum in a city, you need to make that slum as dirty as possible. Everything needs to be pushed to the extreme.

My personal philosophy is that I want to turn every Level in the game into my favorite one. Obviously, I know that can’t happen. But at least while I’m working on it, I can take something boring and give it life. Speaking of which, this is usually where animation enters the picture.

animate (verb)

1530s, “to fill with boldness or courage,” from Latin animatus past participle of animare “give breath to,” also “to endow with a particular spirit, to give courage to, enliven,” from anima “life, breath”

Animation is the most time-consuming part of aesthetic design, and it requires a lot of setup as well. It makes sense for this to come last. But it’s definitely the most important artistic layer. Bad video games tend to feel frozen and stale: great games are always in motion, even when everything appears still. I think our modern brains are conditioned to assume that a screen containing no motion is frozen, as if the app crashed. If you look at games with a high level of polish (Blizzard’s Hearthstone comes to mind), there’s always something moving around to give the player the illusion of life. The goal of polish is to make your game appear to crackle with the spark of life. See for yourself:

Pretty different, huh? Our water shader adds some much needed liveliness to the water, and makes it feel like a rushing stream. Buttons now move and bounce under Obe’s weight. An animated glyph on the ground lets you know where you’ve just clicked. The lamp posts are now chains dangling from the ceiling, which lets them sway gently on a loop.

The other perk of animation is that it allows you to add a third sense to the game: touch (or, feel). In a very real sense, players can only experience your game using their eyes and ears. But if you do your job right as a game designer, certain elements in your game will make the player feel things. Have you ever gotten hit in a video game and exclaimed out loud “ow!” after seeing what happened to your avatar? You didn’t actually feel pain, but something about the experience was immersive enough that it made you connect with your character. That’s what polish is for. That’s how games rise to the top!

 

yellow-happy-smile-526968

forever and ever and ever and ever and ever and ever and ever

Step 6: You Never Finish, This Goes On Forever

Here’s the dirty little secret about my strategy for artistic polish: I’ll never be finished. I will never finish this game. I will work on this game every day until I am dead. It doesn’t even matter if I’m improving the artwork, even if I’m actively making everything worse I will never finish anything in this game.

Whoops! That’s not what I meant to say. Where was I?

Eventually, you need to stop working on a Level so you can move on. This is always a heartbreaking moment in game development. If I could choose any superpower, I would choose a very specific one – the ability to do things on my computer without time slipping through my fingers like grains of sand into an endless void.

[  . _ . ]

You have to move on so you can finish the rest of your game, so when do you do that? It’s at the point where your hours of input are only reaping very marginal gains. People won’t spend an eternity looking at your Levels, so you shouldn’t spend an eternity working on them either. If anything looks truly awful at launch, you can always sneakily patch in fixes that you missed. Just say you’re fixing bugs. and blame the programmer!

Besides, I can always improve the artwork again when we remaster Where Shadows Slumber for BlackBerry…

 


 

I’ve been working on this blog post for too long, and now my hours of writing input are reaping only marginal gains. Time to end this post. Thanks for looking at this inside scoop into our process! If you’re wondering why game development takes so long, imagine doing this for all 38 Levels in the game. That’s not even including the cutscenes…

Say, that gives me an idea for another blog post!

 

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

We hope you enjoyed this deep dive into our development process. You can find out more about our game at WhereShadowsSlumber.com, ask us on Twitter directly using the handle @GameRevenant, find us on Facebookitch.io, or Twitch, and feel free to email us directly at contact@GameRevenant.com.

Frank DiCola is the founder of Game Revenant and the artist for Where Shadows Slumber.

 

Level Design

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

4-3 design

Design of an upcoming level, Fountain!

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?

IMAG0625

Notice how my drawing style is a more clinical, overhead view than Frank’s (above)

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!

feedback

Getting some feedback on level design!

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?

20170627_124251

“Okay, hear me out: we open on a completely blank screen…”

 

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.