Alright people. There’s something that’s been bothering me for a while, and I think it’s time we come clean. For the last two years, ever since the first prototype of Where Shadows Slumber, Frank and I have been lying to you.

“What?!” you ask incredulously, affronted dignity ablaze. “How can this be? What have you lied to us about? I must know!”

Well, never fear – we’ve never lied about the game. All of our screenshots are from the actual game, we’ve represented our progress pretty accurately, and we love you as much as we always have. Rather, inside the game, within Obe’s world, basically everything is a lie.

 

Faker!

This phenomenon is not unique to Where Shadows Slumber – in fact, it’s one of the defining features of video games. If you have experience with video game development, you know exactly what I mean. Think about the real world and the way things actually work. Molecules, fluid dynamics, physics – it’s just way too much stuff to simulate. Even if we get rid of all the stupid sciencey stuff and just consider things like gravity, friction, momentum, and basically anything else from classical physics, the real world is far too complicated to quickly and reliably reproduce on a phone (or a supercomputer, for that matter).

And the best part about this is that it’s not a problem. In fact, even if phones could handle all of physics, we would probably continue faking it. After all, if we do a good enough job of faking it, why would we bother actually implementing it?

This brings me to the actual point – when developing a game, we’re not trying to create a world for you to look at and interact with. Instead, we’re trying to create something that looks enough like a world that you can interact with that you think we actually did create a whole world. This is a very fine line to ride – too far toward realism, and your game will lag, but too far toward fake-ism, and people will be able to tell and won’t like it.

Think about a character walking on relatively flat ground. You could spend all of your time designing a system which allows you to near-perfectly imitate physics. Every time the character takes a step, you calculate exactly how their foot hits the ground, and how it changes their path. This process has eaten up most of your development time, and is so intensive that your game can’t run at more than 15 frames per second. But hey, those perfect physics are worth it, right?

Well, no. I mean, in this case, the ground is relatively flat, so you could have the character just walk along a straight line. Sure, his feet might hover above the ground or clip through it at times, but it’s close enough. Even if the ground isn’t flat, the point is that a simplification of what actually happens is always ‘good enough’ for your game, and it helps you save where you really need to – both development time and processor time.

 

 

Where FAKE Shadows Slumber

Now, when it comes to Where Shadows Slumber, there are two big areas in which we consistently lie.

Physics. This is the case that applies to most, if not all, games, and Where Shadows Slumber is no exception. Everything you see when you’re playing is a carefully constructed illusion. Obe is never standing on the ground – the ground is conveniently and strategically placed so that it looks like he’s standing on the ground. “Physics” covers any physical interactions or representations of objects. This leads to a huge disconnect between what things look like, and how they work. In fact, nothing in the game serves the dual purpose of actually doing something and actually looking like something. In every case, we simply have two game objects – one which interacts with other objects according to the rules of our game (our simplified “physics”, if you will), and the other which is just there to look pretty.

Shadows. Where Shadows Slumber is, obviously, based on shadows. Someone who has played the game would tell you that “shadows change things”. However, this isn’t exactly true – in fact, the shadows in Where Shadows Slumber have literally no effect on the gameplay whatsoever! This is another instance of the decoupling of an object and its visual representation. We show the dark black shadow as it moves across the world, but using that shadow’s location is far too computationally intense to be doing every frame. We could do it, but this is another case where we don’t need to be 100% realistic, as discussed in my blog posts on how our shadows work (part 1 and part 2), we use a much simpler algorithm to determine if something is in shadow. This saves computation time while not sacrificing quality. It’s all about that trade-off!

 

Potential Pitfalls of Constantly Lying

While I strongly advocate for this type of simplification, there are cases where it can cause some trouble. A great example of this came up when we were doing the finishing touches on the original demo for the game.

We had added ramps that Obe could walk on to some levels, to give them a little more depth. It  was working very smoothly, and made the world feel less game-y. Separately, we also came to a decision to have a drop shadow for Obe. It felt weird that Obe himself didn’t cast any shadows, but it didn’t make sense for him to, or everything behind him would be in shadow. We ended up with a circular shadow underneath him. Even though it didn’t make sense from a literal standpoint (since the light wasn’t directly above him), we found that players simply knew what it was, and it added realism, since they were so familiar with the concept of shadows being ‘underneath’ something.

This was all fine and good – both of these ideas were strong ideas (in fact, the latter is a great example of a place where simulating a very fake shadow was much better than attempting to use a realistic one). However, it was when we combined these ideas that we ran into trouble. You see, the drop shadow we made assumed a flat floor – we just plopped it down with a little transparency, and it looked great! Until Obe got to the stairs, that is. Once he started up a ramp, half of the drop shadow ended up being invisible (because it was underneath the ramp), and the other half was at the wrong angle. We had come up with a great simplification, but it ended up totally ruining the illusion!

These situations do come up, and pretty often – two great ideas can combine to form one horrible edge case. However, this situation in particular came about due to a bad design process. At some point near the end of the demo’s development period, we realized “Oh shoot, Obe needs a shadow!” We hacked together the drop shadow solution without considering the long-term design implications. The important thing about making this type of simplification is to understand that it is inherently “wrong” on some level, since it doesn’t perfectly respect the way the world works. This is fine, until it comes up against other things, which are themselves “wrong”. In these cases, you must be extra careful to think through your design decisions with respect to everything they’re going to interact with. This is yet another reason why it’s important not to make design decisions or changes toward the end of your project.

 

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

I hope this gave you a bit of an insight into what’s actually happening in Where Shadows Slumber! If your confidence in us is shaken and you have any questions about what else we’re lying about, 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.