Where Shadows Slumber, out on iOS!

The long wait is over… Where Shadows Slumber is finally out on iOS worldwide! Grab your iPhone or iPad and download the game from our store page by clicking the link below:

STORE: https://itunes.apple.com/us/app/where-shadows-slumber/id1221749074

If you’d like an easier link to share with your friends, try this one:

SHORT LINK: bit.ly/WSS-iOS

Thank you to everyone who followed the development of this game via our blog for the past few years. Your support means the world to us. The entire team (Jack, Alba, Noah, Caroline, and myself) want to express our gratitude for your comments, Likes, Shares, and Retweets over the past few months as we prepared for this day.

We’ll have more news in the coming days as journalists post their reviews, but for now we have some exciting news to share…

 

History-GamesTab

Apple Placed Us On Top Of The Games Tab!

This is incredible – the whole team is freaking out right now on our team chat. I went to the Games tab today because I’ve been checking it frantically, and the very first image you see is Where Shadows Slumber!

This spot of the store is reserved for brand new titles, but you are never guaranteed to end up here. Nothing on this list is random. In fact, Apple put us all the way to the left, which means you don’t even need to swipe through the other titles of the day (Jurassic World Alive, Rise of Civilizations, Maze: Shadow of Light) to see our game.

NB: This is the U.S. App Store – I checked a few other countries and we are placed in different sections depending on the region. For example, in Australia we’re still in the “Coming Soon” tab. Every region manages their own curated list.

This should lead to a massive surge of impressions, sales, and reviews. But we still need your help, loyal Where Shadows Slumber fan! Read on to find out how you can help…

 

History-NoReviews

You Should Review Our Game on the App Store

When you launch a game on the App Store, it doesn’t matter if it’s something you spent 3 years working on, or a weekend project that you’re uploading on a whim. The App Store treats both the same way: your game is sort of hidden, you can only find it by searching for the title, and it says “This app hasn’t received enough ratings or reviews to display a summary” under Ratings & Reviews.

We don’t actually know how many ratings we need in order to get an App Store ranking, but we’re going to assume it’s “a lot” and try to get as many as possible. So if you have an iOS device, you should go review Where Shadows Slumber, whether you’re reading this on launch day or months from now. A good review always helps!

Let’s go over the difference between a rating and a review:

Rating: You choose a star value from 1 to 5 to “rate” our game. The higher the number, the better. If you were being objective, you’d assess if the game was outstanding (5), awful (1), or somewhere in-between. Don’t be objective. Give us a 5! After all, Where Shadows Slumber is outstanding.

Review: Along with a star value, you write down the reasons why you’ve chosen this value. Perhaps you’ve given a game a 3 because it’s good, but the game doesn’t let you tweak with the sound settings the way you like. In our case, we hope you’ll give us 5 stars and also write a short message about why you love the game. Don’t mention that you’ve “followed the game for years and loved the demo” because that will make it sound like you haven’t played the current version. When in doubt, just say you love the puzzles, the aesthetic, the music, the story, and the game’s originality.

As you can imagine, a Review is better than a Rating, and a Rating is better than nothing. Go find our app by searching Where Shadows Slumber on the App Store, and support us by reviewing or rating our game positively! Don’t feel the need to be “objective and fair” by giving us 4 stars. Anything less than 5 stars will harm our rating in the long run. Remember, we’re a tiny indie game going up against goliaths like Fortnite for mobile, which has a 4.6 out of 5 score and over 2.5 million ratings. We need your 5 star rating to fend off the occasional spoil-sport who gives us a 1. Go go go!

NB: You’ll need to purchase the game first before you can review it.

 

Blog-Launch

Spread The Word!

When we launched as a pre-order last week, it was a little difficult to “sell” people on the game. “Hey man, there’s this great game on the App Store! All you have to do is pre-purchase it and… wait longer!”

Well, now the game is out and ready for download today! No more waiting. So please, spread the word about the game, and feel free to use any of the information found in our press kit to do so: WhereShadowsSlumber.com/press

That secret page is really for journalists, which is probably why you’ve never seen it before. However, in the age of Facebook recommendations and retweets, sometimes word-of-mouth goes further when it comes from real fans instead of professional writers. So use those materials and share, share, share!

 

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

Find out more about our game at WhereShadowsSlumber.com, ask us on Twitter (@GameRevenant), 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.

Going Gold

We’ve come to the part of the development cycle that no artist ever enjoys: the gold-stamping process. What is this mysterious “gold-stamping?” Why do artists despise it so? You thought it was just fixing bugs and making small tweaks, didn’t you? Well, read on to find out…

 

You’re reading the development blog for Where Shadows Slumber, a puzzle game coming to iOS and Android later this year. Check out our free Demo here.


 

 

LevelProgress.JPG

Gold Stamping: The Point of No Return

Every project must come to an end eventually. In order to make sure your game is ready for the whole world to see, every piece of it must be tested individually. Then, the entire game has to be tested as one unit. Before we can move on to that final testing phase, every Level, Cutscene, and Menu in the game needs to be approved by three teams: Art, Sound, and Development.

The Art team is just me – and the Development team is just Jack. Alba and Noah work on Sound together. That means we need three approvals for each Level, Cutscene and Menu. Approval means “I’m done working on this Level forever – there is absolutely nothing left to do. Put it in the game.” (See the screenshot above for a look at our spreadsheet that has each Level listed as well as the “Gold” stamps)

There’s a specific order we have to do this in, as well. I need to put my “Gold Stamp of Approval” on Levels before Sound does, because I’m in charge of the game’s visuals. If I add a blazing torch to a Level after Sound has “gold-stamped” that Level, they’ll need to come back and give that torch some kind of looping audio. Art and Sound need to gold-stamp the Level before Jack takes over, because he’s duplicating each Level in the game into a separate file and running an optimization process on that Level.

This optimization process takes time, and destroys the editability of the scene. (By way of analogy, consider what happens to a Photoshop file when you Flatten it into a JPG file. The JPG takes up less space on your computer, but you lose the editable Layers from Photoshop) Jack is able to lower the time it takes your phone to render a frame of the game by “crunching” these Levels. If your phone can render a frame faster, the game will feel smoother. Players hate lag more than they hate bad graphics or design, because it interrupts the flow of play. Everything we’re doing now is to make the game run smoothly even on older devices.

But you can see the problem: if Art or Sound has to tell Jack that they made changes to a Level, one of two things happen:

(a) We need to make that change in both the original Scene and the crunched Scene

(b) OR… Jack needs to start the optimization process for that Scene over again

Option A introduces the possibility of human error. Have you ever made a mistake copying something down by hand over to another sheet of paper? Imagine that with a bunch of tiny numbers and sliders in Unity! Unfortunately, Option B wastes time we don’t have. And since “crunching” makes these Levels unable to easily edit, there is no Option C.

In the late stages of the project, we’re in a mad dash to finish each Level and hand them off to Jack. We’re a bit on top of each other at the moment, and tensions are high. Some of our beloved changes won’t make it into the first release of the game and may have to be stealthily added as a patch later on. (Shhhh don’t tell anyone I said that, blog reader)

Those are all the downsides of gold-stamping. Enough complaining: let’s talk about why this process makes the game so much better!

 

HowEmbarrassing.png

iPhone X Stretching

We began working on this game long before the iPhone X was announced. Since we designed the game in portrait mode, we planned for it to work in 9:16 resolutions as well as 3:4 resolutions. The plan was simple: we would assume you had the tiniest screen there was (9:16) and make sure you could solve the puzzle using everything you saw. And then, if you had a large screen, your screen would show more of the artwork surrounding the puzzle… but not any more key information. (Our demo works this way. Download it for free on a few devices to see what I mean.)

The iPhone X dashed our hopes when it launched, since it has a very thin and tall screen. When we booted it up on an iPhone X earlier this year for the first time, we noticed that key puzzle information was being cut off! Furthermore, there were sections above and below the Scene that I never planned for human eyes to see. We had to fill those sections in with art, or iPhone X users would know the game wasn’t made for them.

Here’s another analogy: imagine if you were designing the set for a Broadway musical. You do all your work, and then a week before opening night your director comes to you and says: “Listen, we’re lowering the stage by 2 feet and extending the ceiling by 2 feet above the stage. Do you think your set will still look good?”

The correct answer is: “yes, but I need to extend the artwork so it doesn’t cut off!” It’s ok if your art bleeds over into a section that human eyes will never see. But you can’t have your screen bleed over into artwork that isn’t finished or cuts off arbitrarily!

Fortunately, Jack solved our width problem by writing a Camera Resizing script that adjusts the Orthographic camera size to the proper width depending on your hardware. (Thank God for Jack, lol. Just that script alone would take me the full 3 years we spent working on this game to complete) I am solving our height problem by extending the shadowy silhouettes on each Level where appropriate, and adding more art where it’s necessary.

 

TooManyVerts.JPG

Low Poly Means Low Poly

When you set out to make a low-poly game, you aren’t just deciding on an art style. You’re also setting boundaries for how much the game will need to handle. This is why you’ll see a lot of cartoony artwork on mobile games and MMOs. Both of those are situations where you want the game to run on low end devices like old phones (mobile games) or old computers (MMOs). Cartoony graphics let you show what you want without having high-resolution textures or incredibly detailed model topology. It isn’t just an artistic decision – it’s also a marketing, business, and programming decision.

However, just because I said that I would do low-poly art doesn’t mean I kept my promise. There are a lot of Levels that go wildly above our Triangle / Vertex budget. (See the screenshot above, with emphasis on the Tris and Verts) Unity counts the number of Tris and Verts that are displaying on the screen at one time. Jack wants us to be well under 100k of each. That may sound like a high number, but you’d be surprised by how even simple scenes can skyrocket to 150k. When he finds Levels that are egregiously “over-budget,” he sends them over to me so I can make reductions.

Fortunately, Tri / Vert budgets are not like monetary budgets. If Jack told me not to spend $100,000 dollars, and then I bought a yacht, we’d be $100K in the hole. (But, we’d have a boat. Jack, I urge you to reconsider this proposal.) With polygons, as long as I cut down on fatty models before the game launches, no one will ever know. Except for the readers of this blog, of course. But you’re sworn to secrecy! Don’t share this post.

There is one more thing about this I discovered: Unity’s lighting system counts polygons in a very strange way. You can’t always trust their readout. I discovered that multiple lights require Unity to count the same object multiple times. If a cube has 8 Verts and one light is lighting it up, Unity will show 8 Verts. If there are six lights on it, Unity will show 48 Verts. So there’s some Levels that Jack will reduce once he does his big crunch, since he rewrote how our Lights will work to make them all act as one super-Light. (More wizardry, I’m sure.)

We’re doing all we can to make the game run fast on your phone. If it’s still lagging, get a new phone!

 

TextureAtlas.png

File Formats and Compression

This is the kind of boring stuff that puts artists to sleep, but it’s important. Unity imports textures, models, and audio files according to a standard. You can set the standard somewhere, but we never did. Instead, I am going through every file in the game and asking the had question: does this really need to be as large as it is?

The answer is usually “no!” which is good. I’m crunching a lot of textures down from 1024 x 1024 to 32 x 32 pixels, Unity’s smallest maximum size for images. Noah and Alba also did a bunch of audio crunching that I can’t really explain properly. You’ll have to wait for their revealing tell-all novella (Where Shadows Is Grongus: Nightmare Stories From Development Hell) for all the juicy secrets!

One more thing about textures: it might not be super necessary for me to make these textures smaller after all. Jack is actually doing this crazy optimization thing where we have every texture on one big image called a Texture Atlas. This image is as small as I can make it and has every texture in it laid out like a grid. We have one of these for every Scene in the game (Levels and Cutscenes) and when the game wants to render an object that uses a texture, it’s going to go to this image and pick from the proper coordinates.

This is insane and Jack explained it to me once and it’s insane and I’m sure it will make the game run super fast. If I’m remembering correctly, Jack told me that the rendering system needs to pause and switch gears every time it has to render a new Material. (So if the grass is GreenMaterial and the tree is TreeMaterial, the renderer needs to pause and switch) If it never has to switch like that, the rendering process should go way faster. The way to do that is to make one Material with the Level specific Texture Atlas called “Scene-0-2-Atlas” or something and put that on each object with the right coordinates. We’ll have fewer batches to render, and you’ll never even know what’s going on under the hood!

I’m going to stop giving the layman’s explanation here before I embarrass myself by showing my limited knowledge. But look forward to Jack’s upcoming tell-all blogella (Life With Frank: The Man Who Knew Nothing) for all the juicy secrets!

 

rubber stamp APPROVED

See You In Hell

This is going to be a rough week. This lengthy process is taking longer than I would have liked, and I’ve been pulled away from animating the final cutscenes. I desperately want to get back on track so Alba and Noah have enough time to work on the audio score for the final cutscenes.

Thanks for reading this blog post – I have to get back to gold-stamping!

 

 

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

We hope you enjoyed this update about the game’s development. Have a question about aesthetics that wasn’t mentioned here? You can find out more about our game at WhereShadowsSlumber.com, ask us on Twitter (@GameRevenant), 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.

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.