2016 Year In Review

Christmas is behind us, and the year is coming to an end. For the final blog post of 2016, we decided to recap the major events in the lifetime of Where Shadows Slumber that occurred this year.

When we began 2016, the game’s demo (currently available on iOS and Google Play) was only 2 months into development. As we created and refined our 10 level demo over the next 12 months, we also had the opportunity to attend some incredible game industry events. Here are some of our favorite development milestones!



Jack got cropped out of this picture, as punishment for being too darn tall.

April / IndieCade East

At the very end of April, we had the great fortune of attending IndieCade East. This juried “Show and Tell” event required us to submit an application and go through an approval process before being allowed to showcase the game. We’re so glad that the judges were impressed with our game, even during its infant stages. This was the earliest feedback we got from total strangers, and it was positive yet constructive.



Dan Butchko, the CEO of Playcrafting.

July / Playcrafting Summer Expo

Throughout the year, we attended two of the gaming nights hosted by Playcrafting at Microsoft’s offices in New York City. These intimate gatherings are great for indies looking for a foothold in the industry – lots of people go to them, admission is free for developers, and there’s even free pizza! Both the Spring Expo and July’s Summer Expo were excellent opportunities for us to show off the game and get some candid feedback from strangers.



September / Studio Madness

After a busy summer, we finally got a chance to sit down with Earl Madness, a photojournalist we met at IndieCade. Our long form interview is available to view on YouTube – in it, we discuss our hopes and dreams for Where Shadows Slumber, as well as some general thoughts about the game industry.



October / Website Launches

Web developer Caroline Amaba pulled off an incredible feat in October – creating a website as beautiful as our game! The site launched in October and has been a massive source of subscriptions to our newsletter, which means traffic is high as well as interest. Keep up the good work, o Mistress of Webs!



October / Gameacon

We attended Gameacon 2016 in Atlantic City, NJ for the first time in October. For a new convention, we were pleasantly surprised by the crowd that came to our table to see Where Shadows Slumber. To top it all off, we were nominated for a Crystal Award – Best Mobile Design! Unfortunately, we did not win. But the experience really helped shape the future strategy of the game, and for that we are thankful!



November / The Demo Launches

On the first day of November, we launched our game on Google Play! Shortly afterward (November 2nd, or midnight on the 3rd…) we launched our game on the App Store. We don’t like to talk about that scheduling mishap, but we should.

A word of caution: when you schedule an app to “release” on the App Store at a certain time on a certain date, the game is not available at that time on that date. Rather, it begins processing at that time and date and will be on the store a solid 24 hours later. The good news is, it happened to the demo and not the final game’s release! We won’t make that mistake again.



November / Accepted Into MIVS

After an arduous submission process, Where Shadows Slumber was accepted into MAGFest’s Indie Videogame Showcase (MIVS). We’ll have the good fortune of attending this event in just over a week (Jan 5th – 8th) at National Harbor, Maryland. This is our first time attending the Music and Gaming Festival in any capacity, so it’s going to be a wild ride! We’ll keep you posted on how that turns out just after we return.




December / Playcrafting and 16 Bit Awards

Our previous attendance at two Playcrafting events made us eligible to apply for a ’16 Bit Award. We had no idea at the time, but apparently Playcrafting holds a massive award ceremony at the end of every year! Our submission was accepted and we were officially nominated for Best Mobile Game. Although we didn’t take home the grand prize, we had a blast at the ’16 Bit Awards. They went all out for this thing! The event had free food and a live band, and we got to hang out with some really cool developers. 10/10, would go again!



That’s All For Now!

We’re going to save the “look ahead” for a future blog post, where we’ll discuss what to look forward to in 2017. Some major events are just around the corner – and there is at least one morsel of news that we are legally barred from publicly announcing. (Don’t worry, it’s good news!)

This year has been good to us. We hope it has been good to you, too. If not, well… just wait longer! 2017, here we come!


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

How was your year? We’d love to hear about any cool projects you’re working on. Maybe you’ve made progress on your game in a significant way – or perhaps 2017 is the start of something new? Whatever the case may be, feel free to use our comments section as a way to get the word out about your game! See you in the new year.

Frank DiCola is the founder and CEO of Game Revenant, a game studio in Hoboken, NJ.

Mechanic Spotlight: Shadows, Part 1

Throughout this blog, I’m planning on doing a number of posts which outline the mechanics of Where Shadows Slumber, and how they work. Now, there are plenty of very interesting mechanics that I can (and probably will) go over. However, there are probably a lot of blog posts and tutorials out there describing path finding, object pooling, shaders, and everything else. So, the mechanic I’m going to start with is the one that is the most unique to Where Shadows Slumber – the mechanic behind the shadows.

A quick disclaimer on the nature of this post – please note that this is not an in-depth description of the exact code we used for the shadows, nor is it an attempt to tell you the correct way to think about or implement such things. I’m sure a seasoned veteran of coding and game design will be able to point out a few inconsistencies or inefficiencies in our shadow system. Rather, this is meant to be a high-level overview of my thought process while I created this system, and how those thoughts changed throughout the process. Also, since we have been working in Unity for the production of this game, I will probably be mentioning how Unity does stuff pretty often.

When playing Where Shadows Slumber, you may have noticed that sometimes, things change when they’re in shadow. In fact, you shouldn’t have been able to beat the game without figuring that out.


I think I’m just gonna use this GIF in every post…

Things change when they’re hidden by shadow and then revealed, but there are two (basic) ways to think about it – they can always change when put into shadow, or they can only change when you move around the object casting the shadow, so you’re on the other side of the casting object, relative to the changing object. One of these methods ended up making more sense to use in the game, but I implemented both of them on the way there, so I think it only makes sense to go over them both (even if it means stretching this post into two parts).

Now, these are both pretty simple problems at their cores, but there are a few interesting lessons. Let’s start with the first type of shadow, using the naive approach, which is exactly where I started a year or so ago.

So when an object is covered in shadow, the next time you see it, it should be different. The steps involved should look something like:

  • Detect if the object is in shadow now
  • Check if it was in shadow before (last frame)
  • If it wasn’t, change it!

Using these steps, the object will change every time it’s put into shadow and then revealed. So, clearly, the most important thing to be able to do is detect when an object is in shadow.

Since the light in the game comes from the player’s lantern, everything that’s in shadow is essentially ‘blocked’ from the player’s view by some obstacle. Thinking about shadows in this way leads to the first pass at detecting when an object is in shadow – basically, just draw a line from the player (or the lantern) to the object. If it hits anything along the way, that means that the light isn’t going to reach the object, which means it’s in shadow.

Image result for unity raycasting

Looks like Unity’s ray casting…


This process is pretty much the description of Unity’s ray casting: draw a ray from a point until it hits a Collider. So we just add a Collider to any object that might get in the way, and we have a simple ‘IsObjectInShadow’ function!

However, you may have noticed that there are a couple of reasons this won’t work, the most important being that it doesn’t behave correctly. Since casting a ray will only target one point, the shadow detection will only work for the exact position of the object. Anything with any amount of width or depth (so, anything) will say it’s in shadow when the center is in shadow, but the edges are not. This happens when the object is at the edge of the shadow, when it’s only partially shadowed. This is a pretty big problem if we’re going to be changing the object at that time, since the whole point is that the player won’t see the object when the change happens.

So we can detect when a point is in shadow, but just checking the exact position of an object isn’t enough. The easy solution is to simply check more points! By casting two rays, one toward the leftmost side of the object, one toward the rightmost, we can check if both of them are in shadow. If they are, then the whole object is in shadow. This version of our theoretical ‘IsObjectInShadow’ function works much better – as we move a character around a pillar, the object will more accurately determine whether or not it’s in shadow.

We can get the object’s leftmost/rightmost positions (relative to the player/light) by getting the objects dimensions, which we can either get from the Renderer component on the object (Unity will measure the visible object), or simply by placing some restriction on the size of the objects. Since Where Shadows Slumber uses a grid system, everything that changes with shadows is restricted to a 1 x 1 x 1 unit cube, in order to make shadow calculations easier.

Now comes the question – why is this version not good enough? We have to do a little math up front to get the left/right bounds, but after that, we simply have to cast a few rays, and we know whether or not our object is in shadow. Seems pretty good! And it is pretty good. It only works in two dimensions – if you move upward, above the object, the object will still think it’s in shadow – but that’s not too bad, and most level designs don’t involve a lot of vertical movement, so we can ignore it for now. The biggest problem with this version is that we have to add a Unity Collider component to every object that might cast a shadow. Then, every ray cast will test collision against every collider every frame (the reality is not quite this bad, but that’s the idea). This can become a problem in a scene with a lot of shadow objects and a lot of shadow casters, especially if you want different casters to affect different objects. We can improve upon this version with a little math and some clever thinking.

If we think about the way that shadows are cast, we can come up with a better way of determining if something is in shadow:


(There’s a reason Frank’s the artist, and I’m not.)


If we specify that every object is restricted to a 1 x 1 box (in the two non-height dimensions), then we can use some trigonometry to determine whether something is in shadow. I won’t get into the details of the actual math, just the overall conceptual parts. No matter the angle, the radius of the blocker will always be at least r (0.5). In the same way, no matter the angle, the radius of the shadow object will always be at most R (√2). Thus, by taking distance into account, we can always tell if the entirety of the shadow object (everything within the bigger circle) is put into shadow by the blocker (everything in the smaller circle).

By using this method, we can tell if a shadow object is in shadow without ray casts or Colliders, and we can do it for a specific object. In this way, we can specify which blockers affect which shadow objects, which gives us a lot more control over level design.

Now that we’re able to tell if an object is in shadow, the hard part is over. Every frame, we just follow the steps outlined above, for any shadow object. We check if it’s in shadow, then check if it was in shadow (meaning we have to keep track of whether or not it was in the previous frame). We change the object to the next state. The object will only change once, until the user sees it, when it’ll appear differently. Then, if it’s put in shadow again, it’ll change again. This allows us the flexibility and consistency of shadow objects.

As it turns out, this version of the shadow mechanic didn’t end up being the one that we needed for Where Shadows Slumber. The shadow mechanic that we actually did use will have to wait for Part 2. We already did a lot of the heavy lifting this time, so it shouldn’t be too hard to make some small adjustments to the work we did here.

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

I hope you enjoyed this first highlight of the shadow mechanic in Where Shadows Slumber. Hopefully it wasn’t too complex, and I was able to explain it well. Let us know if you have any feedback! As always, you can find out more about the 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 using contact@GameRevenant.com.

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

Process Spotlight: Three Phases

Last week, Jack described the creative impulse that drove him to invent the game’s unique shadow mechanic. This week, I want to go in a totally different direction. We’re going to zoom out and look at this project – all of Where Shadows Slumber – from 1,000 yards away and see what it looks like. From this distance, we don’t care about beautiful art, clever mechanics, stable builds, or challenging puzzles. All of that is assumed. We only see a calendar. Days turn into weeks, which become months, and then years.

Wait a second – this article won’t make much sense to you if you’ve never played Where Shadows Slumber before. The demo is available on both major app stores, so download it and give us a review before you read on:

The App Store  |  Google Play

Out here, we are 100% focused on project management. This blog post is for anyone who’s ever wondered “How do you make a game? Where do you start? How do you know when you’re done? When does everything that happens, happen?”

To be honest, we’re not entirely sure. This is only our third collaborative game project, and it’s the first one we’ve done with serious financial goals in mind. So take our advice with a grain of salt: it might not work for your game project, and it might not even work for us.


Doug Lombardi Shows Us The Way



Doug Lombardi schools the Stevens Game Development Club via Skype.

In my final year of graduate school at Stevens, the game development club hosted a truly awesome event: Doug Lombardi, the Vice-President of Marketing at Valve Software, Skyped into our weekly meeting to give us sage game development wisdom. I had the honor of attending!

His full talk can be found here, but I can give you a mangled, shortened version. When asked about the game development process, he said that if he had to make Portal all over again today he would start by finishing the first three levels. “Make sure it looks incredible and plays like butter – then, send it out to any journalist that will pick up the story.” The idea was simple. Your first priority ought to be creating a polished, perfect snippet of your game that you can show the public. While they get excited about that appetizer, share it with their friends, and begin engaging with you, you can develop the final game. By the time the finished product launches, everyone is excited for it because they’ve had a taste and they want more. Additionally, websites like Polygon love to be known for covering interesting indie games before anyone else.

Doug Lombardi knows what he’s talking about. This is his job! But this strategy is not something that young developers ever think of. “Why would I show someone my game before it’s done? Why would I only work on a portion of the game instead of the whole thing?”

In today’s culture, the hype surrounding new games is just an assumed part of your marketing plan. Games that have been released are fun to play – but people enjoy speculating about games that aren’t out yet even more. Gamers love to theorycraft about what a game is going to be like before they know all the details. It’s a coping mechanism to deal with the anticipation of waiting for launch day.

The idea of making a “press release” version of the game was not something we ever considered before, but the idea informed our thinking so much that we planned our entire development effort around this idea. Because of Mr. Lombardi’s excellent advice, we decided at the outset to structure the project into the following 3 Phases:

  • The Throwaway Phase
  • The Press Release Phase
  • The Production Phase

Using this strategy, our complicated game is actually broken down into three small projects, each one larger then the next. This lets us take on selective parts of the game as we are ready for them. Unfortunately, I failed to put timeboxes on these Phases, which sets out expectations about how long each Phase should take to complete. This was a big mistake, and it meant that we (ok, mostly just myself) were allowed to procrastinate, stretching the Phases for a bit too long. Since there are no estimates on these Phases, I’ll just show you how the project is shaping up based on the data we’ve collected on ourselves during the course of the project:

  • The Throwaway Phase (May 11th, 2015 – November 9th, 2015) 6 months
  • The Press Release Phase (November 9th, 2015 – January 10th, 2017) 14 months
  • The Production Phase (January 10th, 2017 – December 31st, 2017) 12 months?

Let’s talk about each Phase in some more detail, and then we’ll analyze where the project is at right now.


The Throwaway Phase



The Throwaway Project used the basic Unity shadow system, where lights dim at a distance. Notice that the player model is the same one that is currently in our demo.

This was the first Phase of our project, and as the name implies it was “thrown away” once we finished it. The purpose of the Throwaway Phase is to work on the game in a safe environment where you can try stuff out without worrying about the public ever seeing it. Our Throwaway Phase ended last November, and we have not released it to the public. It was never designed that way. Save for a few screenshots, you’ll never see the Throwaway project.

That’s because we made it for ourselves (and a select group of testers) and not the general populace. It was a Unity project where Jack could write and rewrite code, create test scenes, and nail down tricky mechanics. I used it as a way to refine my artistic pipeline and answer some of the more fundamental questions about the game’s art, like “what is the visual style of the game?” and “how does artwork get from my modeling program into Unity?”

Answering these basic questions saved us from dealing with some big headaches later. No one wants their engineer to build an entire game in a game engine only to find out that the artist can’t import their work into that same game engine. A mistake like that could cost you months – better to do a quick test during the Throwaway Phase and get that risk out of the way.

The dirty secret of the Throwaway Phase is that the game could have died there. In fact, the Throwaway Phase is meant to be a “proving ground” for the game. Is it a fun game even when it doesn’t look pretty? Is there something unique about it that makes it worth creating? In my life, I’ve thrown out many game designs at this stage because they were unworthy of more of my time. Don’t be afraid to do this! Time flies – remember death. Life is too short to work on bad games.

Obviously, we knew right away that we wanted to keep working on Where Shadows Slumber (which was called Light / Shadow Game at the time), so we migrated from the Throwaway Phase to the Press Release Phase. We kept some of the code and one 3D model, but from here on out we recreated everything from scratch. That might sound like a real waste of time, but it’s not. People learn skills quickly. I’m a better artist than I was a few months ago just because of my time working on the game. I prefer to start over rather than use shoddy files crafted by the inferior Frank of the past.


The Press Release Phase



Level 7 of the ‘Press Release’ Demo of Where Shadows Slumber.

Don’t be fooled like I was – this Phase is not meant for you to advertise your game or begin talking to customers. That was a mistake I made early on. This Phase is when we created the demo that is available now on the store through the App Store and Google Play. It’s a development Phase designed to prepare you for the Production Phase, where development and marketing combine until they crescendo into a record-breaking app launch.

We focused on creating something worth releasing. We decided on a 10 level demonstration of the game’s mind-bending mechanics, haunting ambiance, and beautiful worlds. Doug Lombardi suggested 3 for Portal, but levels in Where Shadows Slumber go a lot faster than the puzzles in Portal, so 10 made more sense. The production quality of this “Press Release” project is meant to reflect that of the final game, so it’s a huge step up from the Throwaway.

Currently, it’s taking a bit longer than we’d like. This is on me – the art for a game like this tends to take much longer than the coding, and I’m the only artist on the team. We’re not moving at a good pace, so I’m planning on restructuring my life a little bit to spend more time each week working on the game.


Google Play aggregated ratings as of December 12th. (Source)

There is good news, though – the glowing response to our released demo has motivated me to work harder! Believe it or not, this is actually part of the project management plan. Keeping developers motivated is difficult. If you release your game too early, you’ll get critical feedback that will make you want to quit. If you wait too long to release your game, the developers might get anxious that they’re working on something horrible that no one has had the chance to openly criticize. Engaging the community at the right time isn’t just a good marketing strategy. It’s also part of keeping morale up!


The Production Phase



The final designs we’re considering for the official logo. Credit: Zak Moy

We have not yet begun this Phase in earnest, although Jack has been working on some preliminary narrative designs. He’s also got a notebook chock full of level designs, just waiting to be put into Unity. Above, you can see the logo designs our talented friend Zak Moy has been working on for us.

This is the most straightforward Phase to explain because it’s what everyone assumes – you build the game that you’ve already started and engage your audience along the way. Using Facebook, Twitter, blogs (spoiler: you’re reading part of our marketing plan right now), Reddit, and anything else you can get your hands on, you drip information out to the community as development progresses. The desire to have new content to show them acts as a motivator, causing you to actually produce new content.

Marketing and development coincide on launch day. A terrible crisis happens (one always does!) and then the launch goes well from there. I’ll have to write about this Phase again once we’re finished. The picture I’m painting right now is a bit too rosy and it’s actually getting me worried.

We’ll have the most work to do in this Phase, but also the most clarity. There’s no more room for wiggle-room. We know our game won’t have jumping, multiplayer, shotguns, real-time strategy base building, or MOBA mechanics. With a clear idea of what we’re building (and what we’re not building), development can go smoothly without taking us down the rabbit holes of scope creep.




Let’s look at our estimated Phase times again:

  • The Throwaway Phase (May 11th, 2015 – November 9th, 2015) 6 months
  • The Press Release Phase (November 9th, 2015 – January 10th, 2017) 14 months
  • The Production Phase (January 10th, 2017 – December 31st, 2017) 12 months?

There’s a big problem with this. Can you see it? The Production Phase is estimated to take less time than the Press Release Phase, even though the Press Release Phase is just 1/10th of the effort it will take to make the final game. How do we account for this?

Part of the reason we’re confident of our delivery date is that, as the project rolls onward, we make concrete decisions about the game every day. Each decision we make means there is less uncertainty in the work we do, which in turn allows us to move on confidently in our plan. Ideally, by the time we begin the Production Phase in January, we are moving full steam ahead at a rapid pace. We’ll know the story, the characters, the setting, the levels, and the mechanics. The code will be finalized for the most part, and the artwork will follow from our concrete plan.

It’s an ambitious goal, and I wouldn’t be surprised if we get delayed by a month or two. That’s why I want to stress that this is an estimate and not a promised release date.

Would We Follow This Plan Again?



Patcha approves. If he approves, then so do I!

I think this is a great way to make games. It gives you room to experiment and even trash the project if you don’t think it’s a winning idea (during the The Throwaway Phase). It allows you to get a build out to the community early and build excitement for your game (during the Press Release Phase). Finally, when it comes time to develop, you can do so with a clear mind (the Production Phase).

Big budget game studios have their own way of doing things, but if you’re a small team like us I can’t recommend this process highly enough. For projects with a larger scope (blockbuster FPS games, RPGs) you may want to consider having numerous Press Release Phases so you can take miniature steps toward Production while keeping your growing player base happy.


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

Thanks for taking the time to read about our process. Are you a game developer or software management expert? How have you structured your projects in the past? Let us know in the comments below! Next week, Jack will post a detailed overview of how he implemented the game’s shadow mechanic in Unity, so get your software engineering hat ready!

Frank DiCola is the founder and CEO of Game Revenant, a game studio in Hoboken, NJ.

Where Shadows Slumber: Inception

Welcome to the Where Shadows Slumber blog! I know Frank posted something last week, but this is my first post, so I’m going to pretend like I’m important or something. In case I’m not important and you don’t know who I am, I’m Jack – the head designer and lead engineer for Where Shadows Slumber. We’ve decided to do a blog to keep in touch with the people that really matter in the production of our game – the users!

So, since this is the very start of our blog, I figured that a good topic would have something to do with the very start of Where Shadows Slumber – the inception of the idea itself. If you haven’t played yet, you definitely should (and how did you end up here?). If you have, then you probably know that the core mechanic of the game is rather interesting, and isn’t something you see, or think of, every day. So how did I come up with it? I get this question a lot, and I never have a satisfying answer for it.


Watch the bridge – it appears and disappears!

I’ve always been a gamer, and thus a game designer, even if it’s usually just in the back of my mind. I’m always thinking about what might be a good game design. A kid walking down the street, avoiding cracks in the sidewalk? Maybe that could make a good game. The picture on that billboard? Looks like a cool puzzle to me – can I expand on it? These thoughts are always floating around my head, and, to be honest, 99% of them are completely worthless. Almost everything I think of has an inherent flaw, or has already been done, or just wouldn’t be fun.

However, it’s the other 1% (it’s probably far less, honestly) that matters. I find that these few half-decent ideas often come up when I’m thinking about the design of existing games, since they’re often far more in tune with what users might be looking for. And I think that’s an important point – no one wants to play Generic Shooter 257342, but a lot of people are willing to give a new, quirky platformer a shot.

Enter Monument Valley. Yeah, I said it, and I’m gonna pander commit a whole paragraph to it. Monument Valley is one of the greatest mobile games I have ever played. Monument Valley took a simple idea and a simple aesthetic, polished them both into a well-oiled game engine, and gave us an incredible experience based around an interesting, understandable mechanic. It wasn’t difficult, but it made you think. I love Monument Valley, and if you haven’t played it, you should go do that. If you have played it, you can probably tell that it was a pretty big inspiration for Where Shadows Slumber, and despite the many reasons for that, there’s one word (which I just learned) that I would use to describe why that is: frisson.

  1. a sudden strong feeling of excitement or fear; a thrill.
    “a frisson of excitement”

The way I think of it, frisson is that feeling you get when something really cool happens. When you figure something out, and it makes you realize that the universe fits together in a really awesome way (the math nerds out there know what I’m talking about). In short, it’s the feeling you get when you solve, understand, and appreciate a really cool puzzle. That feeling stood out so drastically when playing Monument Valley that it made me realize – this is why I play puzzle games, and this is the feeling that puzzle games should strive to inspire.

So Monument Valley came out, and I played it, and I loved it. This was right around the time of the lackluster culmination of our previous project, SkyRunner (go check it out!), and it made me want to try to create something just as unique, interesting, and beautiful. So I continued thinking about potential game ideas, but I started aiming for something new, something interesting, something that hadn’t really been done before. I never sat down and tried to think of a great idea, I just tried to let them come to me.


Left: Monument Valley, by ustwo games. Right: Where Shadows Slumber, by Game Revenant.

And then (and this is the unsatisfying answer that I have to give everyone), the idea came to me. I don’t remember how or when or where, but it just came to me – gradually. It didn’t start out as shadows – basically, it was the idea that anything that you can’t see might be different from the way you remember. You don’t know – you can’t see it! This eventually developed into the idea of shadows, because we decided on creating a third-person game, and shadows are a good way to show that something ‘can’t be seen’.

Now this idea is by no means new. Erwin Schrödinger stuck a cat in a box with the same general concept. If you look, you can find other instances (in fact, you don’t even have to look – just click here or here.) In fact, I remember watching a proof-of-concept demo for a video game based on this exact idea – anything you couldn’t see could change. So it wasn’t a brand new idea, but it was definitely something novel, something interesting, something that we hadn’t seen in the mobile gaming space, and something we thought we could design a lot of fun puzzles around. After a few conversations with Frank, we decided to put together a small initial demo for the first version of Where Shadows Slumber.

We ended up falling in love with both the concept and the aesthetic we had managed to cultivate. For probably the first time in my life, I can actually say that, 18 months or so after I had the idea, we have managed to create a game that actually looks every bit as good as what had first popped into my head. I’m really proud of the work we’ve done to get here (which you’ll hear about if you’re willing to continue reading my hackneyed posts), and I’m very excited for the upcoming phase of production.


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

Thanks for tuning in, I hope you enjoyed reading about the inception of the idea for our game, Where Shadows Slumber. As always, you can find out more about the game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebook, or Frank’s game development Twitch stream – and feel free to email us directly with any questions or feedback at contact@GameRevenant.comNext week, Frank will talk about our development process and how we manage our time.

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