The Good

In order to figure out what I was gonna write about this week, I took a quick scroll through the past few posts we’ve written, and I noticed something about the general tone of our blogs of late. Thanks to the pressure to get Where Shadows Slumber done, and the fact that we’ve entirely run out of new ideas for blog posts, everything we’ve written recently seems to have fallen into one of two camps:

  • A half-hearted explanation of a part of the game no one really wants to hear about, because we can’t afford to waste time writing blogs when we have work to do.
  • A frantic excuse for why the game hasn’t been released yet, which generally boils down to “working on this game is sucking out my soul”.

Even those descriptions fall into one of those categories! (Hint: it’s the second one). That fact aside, I’ve decided to take it in a different, more positive direction this week! Instead of talking about how much game development sucks, let’s talk about all the good that’s come from working on Where Shadows Slumber.

 

 

Lessons Learned

The first and most obvious positive result of working on Where Shadows Slumber would have to be the things that I’ve learned. Creating an entire game from the ground up in a game engine that I didn’t have much experience with has been incredibly challenging, but it has also left me with a lot of new knowledge and valuable experience.

Blogging

I’m still not the best coder on the team. That honor goes to Obe.

  • Unity itself. Unity is a very powerful, and professional, game engine. It may not have all of the depth of something like Unreal, or all of the customization of writing your own engine from the ground up, but there’s really no arguing that it’s not a “real” game engine. In fact, there is now a certification for programming in Unity.

 

  • C#. As a programmer, you get pretty used to picking up new languages, and, for the most part, it gets easier with every one you learn. The fact that I was able to learn C# isn’t the takeaway here – the fact that I was motivated to learn C# is. Without Where Shadows Slumber, I simply wouldn’t have had any reason to extend my programming repertoire.

 

  • Shaders. One of the most difficult technical challenges this project has posed has been the shaders. For the most part, the programming required for the actual game logic was similar to code I’ve written before. Shaders, however, delve into a very different type of programming. I now know far more about how Unity renders a frame than I ever thought I would, and I’m pretty happy to have that knowledge. Even if I don’t have to do any rendering work again, I’m glad to know what’s happening under the hood.

 

  • Project management. To continue a running theme throughout our blog posts, I’ll mention that this was the one that took me by surprise. When this project started, I was well aware of (most of) the technical challenges that lay ahead. What I didn’t anticipate was handling the vast array of tasks involved with actually managing a project. Where Shadows Slumber has helped me advance from a quintessential disorganized coder all the way to a slightly-less-disorganized coder!

 

There are a million other, small things that I learned throughout the production of the game, but these are the big ones. Throughout its development, Where Shadows Slumber has had a lot to teach me!

 

 

Personal Life

Another important (and perhaps more poignant) side-effect of working on Where Shadows Slumber is the personal relationships that it has helped cultivate.

17159203_1817437325174646_6524966612565150056_o

BFFs Forever!

Frank and I were friends in college, but just barely. We were in the same sketch comedy group, but outside of that, we didn’t really hang out. I guarantee that if it weren’t for Where Shadows Slumber, we wouldn’t be in contact at this point, and it probably would have been several years since we’d seen each other. Now, however, we’re definitely friends, and close friends at that. Frank and I are in nearly constant contact, which, annoying as it can be, keeps us pretty close. I don’t want to bore you by getting too gushy, so let’s just say that we do a good job of tolerating each other.

In addition to bolstering an existing friendship, this project has also created new friendships – with Alba and Noah, our sound engineers! They’re totally awesome, and I look forward to spending more time with them, hopefully even after we’re done with Where Shadows Slumber!

We may not be as close, but the other people that we’ve gotten to know are all of you! As an indie game, we have to do a lot of work to make sure people hear about the game. Throughout the past few years, we’ve been to over a dozen conventions, showcasing and pitching the game, making a name for ourselves, and, most importantly, meeting a bunch of really cool people! Seriously, all of the people we’ve met throughout this process, whether they be other game developers, fans, or just normal con-goers, are great. No matter if I’m annoyed with the game or frustrated with the drudge of development, going to a convention and seeing new people playing the game, or old fans coming back to check in, is always incredible. There are a lot of aspects of Where Shadows Slumber that I love, but that’s definitely the best part.

 

 

The Game Itself

I guess the actual most obvious result from Where Shadows Slumber would be the piles and piles of money we’re going to make from it. That, however, is not the point – as much as I would love for Where Shadows Slumber to make some money, that’s really ancillary to the whole ethos of the project.

Frank and I are avid gamers, and always have been. We set out not to make a lot of money or make the most popular game ever. We wanted to create something beautiful, something we could be proud of – and in that sense, I think we’ve done a pretty good job. When I look back on this project, I’m not going to look at my net profit – I’m going to look at Where Shadows Slumber itself, and I think I’ll always be happy with it.

trophy

I think we’ve got a chance at this one!

Of course, Where Shadows Slumber will serve as more than just an ephemeral trophy to put on my emotional mantle. The game itself is the end goal here, and there are some tangible benefits to that:

  • Money. Even though this isn’t the goal of the project, Frank and I are both hoping to make a little something for our efforts.

 

  • “Resume bait”. At some point in the future, I expect that I’ll be looking for a job. When that time comes, I’ll be handing out my resume, hoping to catch the eye of some company. But I may be just one of hundreds of applicants, all with similar experience and qualifications. How can I stand out? By having something awesome on my resume, something that other people won’t have, something that shows that I can set a goal and reach it, that I can meet technical challenges, and that I can manage a development process.

 

  • Experience. Working on Where Shadows Slumber has given me an incredible cache of experience to draw on. Pretty much any technical problem I run into, I can find a parallel with some part of the development of Where Shadows Slumber. The end result is a game that’s more than a game; every part of that game represents a different challenge and a different piece of knowledge that I can now look back on.

 

  • A trophy. I know I said that Where Shadows Slumber was more than just a trophy, but it is also that. From conception to completion, Frank and I have worked tirelessly to bring this idea to life. This is something we’ve built ourselves, from the ground up, and it always will be. It’s something we can be proud of, and something we can always look back on.

 

 

A Fond Farewell

happy3

Thanks for listening to me ramble on for a little bit. Anyone who has ever worked on a software development project (or pretty much any long project) knows just how stressful life can start to become when you reach the dreaded “crunch time”. We all end up hating our games as they come out, and I don’t want that to be the way that Where Shadows Slumber is released. So I’m glad I got a chance to take the time and share with you all the good things Where Shadows Slumber has done for me!

 

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

You can always find out more about our game and how awesome it is at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebookitch.io, or Twitch, join the Game Revenant Discord, 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.

All About App Icons

As the completion date of Where Shadows Slumber draws near, Jack and I are coming to terms with just how much work it takes to finish a game. This means we’re revisiting old tasks that we didn’t have to deal with for a while, including the game’s app icon.

It may seem like a small detail, but your game’s icon is very important. It isn’t exactly the same as your game’s logo, but in certain contexts it plays the same role. The app icon is the rounded square button on your customer’s phone menu that they have to press to start playing your game. More importantly, this icon is on prominent display on marketplaces like the App Store and is often a potential customer’s first impression of your game.

Viewed through that lens, the app icon is immensely important and I regret not working on it sooner. It’s just a small graphic, though… how difficult could it be?

Fortunately, I’ve been researching this topic for a little while now. Below, I’ve compiled a gallery of some of my favorite app icons. We’ll also discuss in this blog post my personal “do’s and don’ts” for these graphics, inspired by both previous iterations of the Where Shadows Slumber app icon.

 


 

 

Inspiring Icons

I played a lot of mobile games during the creation of Where Shadows Slumber. That’s not because I’m lazy! I wanted to see what successful mobile games did. I spent a long time looking at their store listings, reading reviews, poring over their descriptions, and – of course – checking out app icons. It wouldn’t be a Where Shadows Slumber blog post if we didn’t gush over Monument Valley, so let’s start there.

AppIcon-Monument-Valley.JPG

The app icon for Monument Valley is really beautiful and shows off what the in-game art looks like. When you look at the icon on your device, the scale of Ida here probably matches her scale in the game. That makes this graphic one of the most honest app icons in the business! From a distance, you can clearly make out her shape because her white body contrasts starkly with the green backdrop. I also love that this picture shows the isometric angle and color shading that they use in the game. Sadly, this image does not communicate the game’s M.C. Escher inspired puzzles… but how the heck could you even show that? Maybe I shouldn’t worry too much about showing “shadow puzzles” in a tiny square image. It would just never fit!

AppIcon-Monument-Valley-2

The app icon for Monument Valley 2 was constrained somewhat by the first. The artist likely felt the need to match the style of the previous icon. Now that they’ve got a pattern established, expect to see something like this if they ever make Monument Valley 3. Still, the fact that this icon communicates the relationship between a mother and daughter tells you a lot about the game’s story and mechanics.

AppIcon-Sneaky.png

The real reason I bring up Monument Valley 2 is because of something I noticed when I was in an Apple Store the other day, getting a new iPad for my Dad. On their demo devices, the game is labeled simply as “Monument 2,” because the name is too long. Notice also that the game Alto’s Odyssey is just named “Odyssey.” I’ve wondered what Jack and I should do with our lengthy title Where Shadows Slumber… should it be listed as “Slumber,” “Shadows Slumber,” or “Shadows?”

AppIcon-AltosAdventure

Speaking of Alto’s Odyssey, both games in the Alto series have very beautiful app icons. However, it seems to me that the original is better because it actually communicates the mechanics of the game. Take a look at the icon above, and then look at Alto’s Odyssey below. Remember that these games have identical gameplay: both are side-scrolling snowboarding simulators. Notice anything?

AppIcon-AltosOdyssey.JPG

Alto’s Odyssey doesn’t have an image of a dude flipping over a windmill like the first game did! That’s pretty important because the whole game is about jumping over stuff, getting airtime, and doing tricks. But when I see the icon above for Alto’s Odyssey, I imagine a different game where I can actually go into some of those ruins or fly in that hot air balloon. It doesn’t set up expectations the way you might expect. Even so, the image is gorgeous and communicates the art style faithfully.

AppIcon-Prune

Of all the games I researched, my favorite app icon is probably the one for Prune. Look at this beautiful picture! Since I played the game, I happen to know that this app icon is actually a perfect rendition of what every Level looks like, too. Now that’s honesty! Prune is a game where you swipe away branches from a tree to help it grow the right way. I think you wanted to avoid the big red suns because they killed your tree. It’s a beautiful game, and the simple nature of this app icon does it justice.

We’ve looked at a lot of great artwork, but I don’t feel like comparing them to a list of “bad examples” in this blog post. I feel uncomfortable putting down other people’s work besides my own. There is no point in searching the App Store for apps that performed poorly and then ripping their icons apart. Instead, let’s just criticize the two icons I made earlier in the project cycle!

 

AppIcon-Gallery.png

Learning From My Mistakes

If you’ve ever played our free iOS Demo before, or if you are one of our beta testers, or even if you’re just a diehard follower of this blog, you’ve seen one of our app icons before. We aren’t going to use either of these for the final game’s release, so I’d like to write about them in this space.

AppIcon-WSS-2016.JPG

Our first app icon was created just for the Demo. I whipped this up in Adobe Illustrator over a year ago. The idea was to show a silhouette of Obe in a doorway, with the lantern clearly visible. Looking back on it now, this fails for a variety of reasons:

  1. This image is very detailed, so the intricacies are hard to make out at small sizes
  2. This icon requires pre-existing knowledge about what Obe looks like
  3. The lantern looked weirder back then, so it’s not immediately recognizable
  4. This looks like an icon for a horror game, almost like Amnesia for mobile phones
  5. This doesn’t really look like the art in the game at all
  6. This doesn’t really look like an app icon for a mobile puzzle game
  7. This is misleading because Obe’s body never actually casts shadows

I’m not saying I hate it or I regret making it – it seemed cool at the time! Our Demo drew in over 310,000 free installs on Android alone, so we did something right. But I wouldn’t go for this kind of style for the final game. It’s too much of a departure from the real game’s art, tone, and genre.

AppIcon-WSS-2017

Our next app icon was made much faster and was basically an unofficial app icon. I just did this for the beta, and I didn’t put much effort into it. This one fails on two levels – first of all, it’s not very unique or inspiring. It’s just text. Anybody could make this, and it tells customers nothing about our game. Second, it includes English text. That means I’d need to make a different app icon for every language we release the game in! Why bother doing that when I can just create a cool image like ustwo did?

So for the game’s final icon I need one square image that contains no text, but communicates the following to the player:

  • The game’s reflective tone, with some ominous terror looming in the periphery
  • The game’s crisp light shading model
  • The importance of the lantern to the story
  • The idea that this is a puzzle game and not some other genre
  • The idea that this is a mobile game
  • A warning that this game is not for preteen children

Yikes! Wish me luck. I’ll take a shot at this during the week, in between animating the game’s remaining cutscenes and putting out other fires. Jack and I have spoken about our app icon informally in the past, so I have a pretty good idea of what we want. This analysis helped me crystallize my plan going forward.

We’ll have some exciting news to announce in the coming weeks, so stay tuned to this blog and thanks for reading!

 

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

We hope you enjoyed this update about the game’s graphic design. 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.

 

 

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.

Crunch and Burn(out)

If you’ve been following the development of Where Shadows Slumber, then you know that we’ve been working on it for a while. It was early 2015 when the core concept first came to me. Three years ago this month was when I put together the first proof-of-concept to show to Frank. The demo version of the game has been out for over a year and a half.

Game development takes a long time, especially with a tiny team, little to no funding, a full-time job, and, the biggest time-waster of all, life itself. As Frank discussed in a previous blog post, we are holding ourselves to a pretty high standard for Where Shadows Slumber, which makes development even slower.

Fortunately, after all this time, we’re finally closing in on the end. As happy as that might make you, the fans of the game, there are two people who are definitely happier about it than you are: us. As frustrated as you might be about how long it’s taking, we’re even more frustrated. Frankly, as much as we love Where Shadows Slumber, neither of us can wait until the moment it’s over.

“But Jack”, you ask incredulously, “if you love it, why do you want it to be over? You’ve managed to work on it for three years – what’s another few months?”

There are two phenomena that often creep up at around the same time in the development cycle of a game (or any project, really). Here they both are, followed by something I’ve said in the past week that represents each of them:

  • Crunch – “There’s only a little bit of work left, but there’s even less time left!”
  • Burnout – “I’ve spent so long on this game, I’m just sick of it!”

 

Night.jpg

Crunch

I’ve discussed before the “ninety-ninety” rule, so I’ll just summarize it quickly here, since it’s relevant: not only does software development take a long time, it takes significantly longer than you think it will. This is an issue when you first start your project (“it’ll probably only take 18 months or so”), but there’s no scheduled release date or external pressure at that point. Nobody really cares yet! However, it becomes a bigger issue when dealing with shorter time periods. For some reason, people have a hard time realizing that their estimates are wrong and adjusting (at least, we do). Because of that, we’re still making poor estimates for how long something will take!

This is the reason that developers inevitably end up in the dreaded state known as crunch time. We thought there were about 6 weeks of work left, but it turns out there were 12 weeks of work left. Too bad we already gave a bunch of outside parties a solid release date! Since they’re now depending on us to meet those deadlines, we have to do 12 weeks worth of work in 6 weeks!

This is the phenomenon that leads to crazy overtime, too many all-nighters, and an incredible amount of stress. If you follow game design, you’ve probably heard about it, because it somehow ends up happening to pretty much every game. If you’re involved in game design, then you’ve probably gone through it, and you know how awful it can be.

It’s a little better for us than for bigger, more established studios – we don’t have employees to pay, stockholders to appease, or a public release date to hit. That said, we don’t want Where Shadows Slumber to turn into an indie game for which development takes forever that people are perennially waiting for. It’s now or never!

 

Burnout.png

Burnout

Cascading into crunch time at full speed is pretty bad, but it’s not the worst thing in the world – we’re been working on Where Shadows Slumber for a long time, and we are both willing to put in a little extra time as we reach the end. However, one of the biggest problems is that crunch time is also usually accompanied by burnout.

When you’re just starting out on a project, everything is pretty exciting. You enjoy working on interesting problems like pathfinding and game mechanics, and you don’t even mind fixing any bugs that come up. On the other hand, once you’ve been working on a game for a long time, you’re pretty much sick of it. All of the interesting stuff is already implemented, so the only things left to work on are tiny quality improvements (“does this look better when the position is 0.4 or 0.41? How about 0.42?”), annoying, subtle, or hard-to-reproduce bugs (“this was working last week, but a change to a different piece of code is somehow causing it to break, but only ~10% of the time”), and tasks that you intentionally avoided because they aren’t interesting or fun (“how many setPass calls will this scene render when running on a 6-year old Android phone? Is that too many?”).

None of these tasks are really very enjoyable – so not only has your excitement about the work decreased, but so has the objective fun-ness of the work that’s left to do. This leaves you in a state of never actually wanting to work on the project. Combine that decreased drive with the increased amount of work you have to do, and it starts to become pretty obvious why the end of development for a game tends to get pretty hairy, and why we’re looking forward to being done with it.

 

Tunnel.jpg

The Light at the End of the Tunnel

Don’t worry, though – it’s not all bad! We’re both still really excited about Where Shadows Slumber, because of the amount of work we’ve put into it. We’re both dedicated to the cause, and we’re not gonna let a little extra work put a stop to it (even if it ends up slowing us down).

The purpose of this blog post is two-fold. On one, more selfish hand, I want to offer up to our adoring fans an explanation for why we haven’t finished the game yet. We know a lot of you love the game, and are really looking forward to it, and many of you have shown us that by popping up and saying hi at various conventions. The past 8 months or so have been a real whirlwind, both personally and professionally, and our timeline has been shifting around quite a bit as a result. So I wanted to offer a bit of an explanation, as well as reassure you that we’re still working on Where Shadows Slumber, and we’re not gonna let it fall by the wayside!

The other reason for this post is to serve as a sort of warning, albeit a likely redundant one. For anyone working on their own game (or any project, really), it’s very important to take time management seriously. Ending up in the crunch time/burnout trap is an awful place to be. Despite this, most developers (indie and AAA alike) end up here, because it’s hard for people to grasp how time-consuming the last 10% of a project can be. So, if you take away anything from this post, I hope you do your best to allow enough time at the end of development to get your game out without ending up there. You’ll end up there anyway, but maybe by knowing about it ahead of time, you won’t be there for long.

 

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

You can always find out more about our game and how freaking long it’s taking us to finish it at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebookitch.io, or Twitch, join the Game Revenant Discord, 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.