Rendering in Unity

As you probably know, Where Shadows Slumber is starting to ramp up toward a release this summer. It’s an exciting, terrifying time. We can’t wait to share the entirety of what we’ve been working on with the world, but there’s also a daunting amount of stuff to do, and not much time to do it.

If you’ve played any of the recent beta builds, hopefully you like what you’re seeing in terms of design, functionality, polish, art, and sound. Unfortunately, if you’ve played the beta on anything other than a high-end device, you’ve probably noticed something that you don’t like: lag.

Lag is annoying. Lag is something that can take a great game and ruin it. It doesn’t matter that your level design is perfect, your models are beautiful, and your music is entrancing if it only runs at 10 frames per second. If that’s the case, nobody is going to enjoy playing it. And, regrettably, that happens to be the case for Where Shadows Slumber.

LikeButta

Like butta’!

So, one of my biggest tasks before we release is to optimize the game, making it run faster and allowing us to have higher frame rates. The area with the most opportunity for improvement is during rendering. A game consists of a lot of logic – Obe’s location, things changing in shadow, etc. – but rendering is the process of actually drawing the scene onto the pixels of your screen.

Earlier this week, I started a post about the different tools you can use to help optimize your rendering performance. It seemed like a good idea, since that’s exactly what I was doing. However, I realized that if you don’t know how rendering works in the first place, most of it is complete gibberish. So I’m gonna leave that post for next week, and this week I’ll give a quick introduction to how 3D rendering works in Unity.

Blog-Render.JPG

Rendering

Rendering is the process by which the objects in your game are drawn to the screen. Until it’s rendered, an object in your game is just a collection of information about that object. That information gets translated from information the game engine understands into information the GPU can understand. There are a few important concepts to understand here:

  • An object’s mesh describes the shape of the object. It consists of a collection of vertices and triangles.
  • An object’s material is a description of how that object should be drawn. It encapsulates things like colors and shininess.
  • Every material uses a shader. This is the program which calculates exactly what color each pixel should be, based on the information in the mesh and material.
  • World space is the 3D coordinate space in which all of your game objects live.
  • Screen space is a 2D coordinate space that represents the screen to which the game is drawn.

The basics of rendering are pretty easy to understand, at least from a high-level view. The meshes for the objects in your game are translated from world space to screen space, based on the camera that’s doing the rendering. For instance, in Where Shadows Slumber, objects that are further away in the x-axis will be higher up and more to the right when viewed on the screen. Fortunately, we don’t have to mess with this too much – Unity’s cameras do a good job of making this translation.

Once we know where each pixel should be drawn, we need to determine what color that pixel should be – this is where the material and shader come in. Unity provides a whole bunch of information to the shader (position, angle, information about lights in the scene, etc.). The shader uses that information, plus the information from the material, to determine exactly what color the given pixel should be. This happens for every pixel on the screen, resulting in a beautiful picture of exactly what you expect to see.

The GPU

Now that we understand the basics of rendering, let’s take a deeper look into how it actually happens: the GPU.

The GPU, or graphics processing unit, is the part of the computer in charge of calculating the results of our shaders to determine a pixel’s color. Since modern phones have over 2 million pixels, our shader code must be run over 2 million times per frame – all within a fraction of a second.

How does the GPU manage to do so many calculations so quickly? It’s due to the design of the GPU, and can be summed up in one very important sentence: the GPU is good at performing the same operation, a bunch of times, very quickly. The key thing to remember here is that it’s good at performing the same operation; trying to perform different operations is what slows it down.

Specifically, switching from one material to another causes a bit of a hiccup in terms of speed. The properties of the material are passed to the GPU as a set of parameters in what is known as a SetPass call. SetPass calls are one of the first and most important indicators when it comes to optimizing rendering performance, and are often indicative of how quickly or slowly your game will run.

Because SetPass calls take so long, Unity has a strategy for avoiding them called batching. If there are two objects that have the same material, that means they have the same parameters passed to the GPU. This means that those parameters don’t need to be reset in between drawing the two objects. These two objects can be batched, so the GPU will draw them at the same time. Batching is Unity’s first line of defense against rendering slowness.

The CPU

While the GPU is the star of the show when it comes to rendering, the CPU, or central processing unity, still does some important stuff that’s worth mentioning (even if it doesn’t have a huge bearing on the optimization steps we’ll be taking). Of course, the CPU is in charge of running your game, which includes all of the non-shader code you’ve written for it, as well as any under-the-hood things Unity is doing, like physics and stuff.

The CPU does a lot of the “set up” for rendering, before the GPU comes in and does the heavy number-crunching. This includes sending specific information to the GPU, including things like the positions of lights, the properties of shadows, and other details about the scene and your project’s rendering config.

One of the more important rendering-related things the CPU does is called culling. Since the CPU knows where your camera is, and where all of your objects are, it can figure out that some objects won’t ever be viewed. The GPU won’t know this, and will still perform calculations for those objects. In order to avoid doing these unnecessary calculations, the CPU will first remove any of the objects that won’t be drawn, so the GPU never even knows about them.

Image

All of these Hitlers would be culled by the CPU (image credit: smbc-comics.com)

Since we’re talking about performance, it should be noted that the GPU and the CPU are two different entities. This means that, if your game is experiencing lag, it’s likely due to either the GPU or the CPU, but not both. In this case, improving the performance of the other component won’t actually make your game run any faster, because you’ll still be bottlenecked by the slower process.

So, now that we know a little bit more about how rendering actually happens, maybe we can use that knowledge to improve performance! At least, that’s what I’m hoping. If Where Shadows Slumber never comes out, then you’ll know I’ve failed. Either way, I’ll see you next week for a look into the tools you can use to help you optimize rendering performance in Unity!

 

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

If you didn’t already have a working knowledge of rendering, I hope this post helped! If you do know about rendering stuff, I hope you don’t hate me too much for my imprecision! You can always find out more about our game 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.

Just Do It

No, Where Shadows Slumber hasn’t received any funding from a mysterious shoe company. Rather, I want to discuss an aspect of working on a personal project that I’ve seen a lot of people struggle with, and that I’ve had trouble with in the past. Yes, this post touches on a few of the topics that I talked about in a previous blog post about ‘drive’, but today I want to focus more on a specific facet of the process: forcing yourself to work on something that you don’t want to.

Every project is difficult. In particular, every project begins to drag as you get closer and closer to the end. You find it more and more difficult to keep working on it. At the beginning of your project, there’s a whole bunch of stuff you’re excited to work on. As you reach the end, you find that you’ve done all of the fun things, and the only things left are boring tasks and difficult decisions. This is the point where you’re really being put to the test, and in this situation, I have one piece of advice for you – buckle down and just do it.

Let’s take a quick look at the different kinds of things you should just force yourself to do, and how to actually do so.

 

Doing Things You Don’t Want to Do

The most obvious kind of thing you don’t want to do is, well, something you just don’t want to do. These things are different for everyone, and come up for various reasons. For me, these are the cleanup/polish kinds of tasks. For other programmers, it might be the mathy, trig-related stuff. For an artist, maybe it’s animating hands or something (I hear that’s really hard…). Whatever it is, everyone has something they consider ‘dreg work’, and those tasks start to pile up.

taxes

Tax  season is coming up, and I’m already putting it off

If you’re anything like me, when you come upon one of these tasks, you briefly consider doing it, and then you move on to something easier or more interesting. After all, there’s no shortage of work in your project! This happens a lot with teams as well, especially less organized teams – “if I go work on something else instead, somebody will probably take care of this by the time I get back to it”.

Unfortunately, these two base assumptions fall apart when it comes to indie game development (or any similar venture). In most cases, your project has to come to an end eventually, which means that you can’t simply keep putting these tasks off. And with a smaller, indie-sized team, it’s unlikely that you can just put that responsibility on someone else. It’s pretty cool to be the arbiter of your own success by taking charge of your own game development project, but it also involves other responsibilities.

I know quite a  few people who check their email regularly – until they see that one email that prompts them to do something. They know they have to do it, but they simply don’t want to. Rather than just doing it, getting it out of the way, and having some peace of mind, they close their email and proceed to ignore it for the better part of a week. Inevitably, this doesn’t cause the task to go away, but just gives them less time to do it, and a boatload of stress while they’re avoiding it anyway.

The bottom line is that these tasks must be done – you’ll come across them, and you’ll simply have to do them. The most important thing is to have a positive attitude in these instances. You come upon a task that you don’t want to do – acknowledge that you have to do it, take a deep breath, and just get started. Once you’ve begun, you’ll probably find that it’s not as bad as you thought – simply starting the task is usually the hardest part. And hey, if it ends up being an awful task, at least you got it out of the way!

 

Committing to an End

Another area where it’s very important to embrace a “just do it” attitude is when it comes to actually finishing your project. As an indie game developer, it’s perfectly natural to be apprehensive of your eventual release. After all, you’re just a small group of people (or even just one!), but your game will still have to compete with games made by giant studios. It makes sense to want to make sure your game is absolutely perfect before committing to a release.

The problem with this plan is the use of the word perfect. Your game will never be perfect. In fact, your game will never even be “good enough”, especially considering your own perfectionist perspective. Waiting for perfection leads you to a phase of endless polish, which can delay your project for years, or even indefinitely. The only thing worse than releasing an imperfect game is not releasing one at all.

There’s a pretty common attitude of “I’ll release it when it’s done”, or “I’ll know when I get closer to the end”. While these make sense at first blush, and are good mentalities to have toward the very beginning of a project, they quickly turn against you, causing your project to become more and more delayed.

duedate

Red marker. That’s how you know it’s serious.

Unfortunately, as introspective as we may consider ourselves, there’s a significant amount of stuff going on under the hood that we’re not even aware of. One of the more annoying of these is that, if there’s no “due date” for your project, your brain will subconsciously de-prioritize working on it. Similarly, there’s a well-known adage that work expands to fill the space its given – if you have twice the time to do something, you’ll just subconsciously work half as hard at it. For example, at the end of November, we were on schedule to release Where Shadows Slumber by April. We recently pushed that date back by a few months, without increasing the project’s scope. You would think that this would give us some breathing room, but the new “deadline” feels like it will somehow be even harder to meet!

Managing the timeline of an entire project is an incredibly difficult task. One important piece of advice I would give would be to pick a target release date. Even if it’s not public, picking a date, committing to it, and doing everything you can to meet it will definitely help you prioritize the work you’re doing, frame it appropriately, and avoid the project stretching into infinity.

Don’t get me wrong, you shouldn’t choose a release date willy-nilly; you should realistically estimate when you can complete the project, and choose accordingly. Similarly, there’s no need to have a specific end date in mind when you start the project. Your target date is a great motivational tool, but it only works if it’s at least somewhat accurate. Even if you miss your release date (or realize you’re going to, like we did), it’s not a problem. You just have to reassess the work that’s left, and choose a new date. As long as you don’t keep extending the project, you’ll be fine.

 

Decision-Making

While there are tasks that you don’t want to do because they’re difficult or time-consuming, there are other reasons to not want to do something. In particular, making decisions is a real sticking point for a lot of people. If you implement something incorrectly, you can always redo it, but many of the decisions you have to make for your game have an irreversible effect. This is really daunting, and since decisions themselves don’t take a lot of actual physical effort, the natural response is to simply put off making the decision for a bit.

DecisionMaking

When faced with a choice between success and failure, I hope you’ll always choose Where Shadows Slumber!

This is similar to the “end date” discussion above. While many of these decisions are very important and require a great deal of thought, they still have to be made. It’s important to never forget this fact, as decision paralysis is another great way to destroy your game.

When you find yourself facing one of these decisions, make sure you don’t back off, at least not repeatedly. You have to make the decision eventually, so you might as well do it now. In fact, in the case of some difficult, important decisions, you might even lock yourself in a room until you’ve made the decision. That’s exactly what we did when picking out the name for Where Shadows Slumber – Frank and I sat down, and neither of us was allowed to leave until we had picked a name. It ended up taking a few hours, but we had managed to nail down the answer to a very difficult decision.

 

Just Do It

There are a lot of places in game development where you find it hard to do what you have to do. These moments are gateways to stagnating development and endless work. When the time comes, you often must act. Don’t make half-hearted decisions or poor implementations, but really force yourself to do what needs to be done. Just do it.

 

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

If you have any questions about any of our development struggles, or if you have any other questions about Where Shadows Slumber, feel free to contact us! You can always find out more about our game 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.

State of the Art – February 2018

Welcome to State Of The Art, February 2018 edition! This monthly* progress report is written by Frank DiCola and is focused entirely on how the game’s visuals have improved in the past month. If you are one of our beta testers, you’ve probably already seen this artwork firsthand. (Looking to sign up? Email me at contact@GameRevenant.com if you’re on iOS, or just go here to download if you’re on Android)

(*It’s been a while since I did one of these! We got so caught up in a bunch of year-end stuff with MAGFest 2018, I decided to wait until February to discuss the state of the game’s aesthetics. The good news is, this is a double helping of art updates!)

Without further excuses, let’s explore the major leaps forward we took since December!

 


 

 

Header-Forest

The Forest is Now Polished

Polish is a strange thing. You’re never really finished – you just keep making smaller and smaller increments towards perfection, never quite reaching it. Eventually you hit a point where the small changes aren’t worth it because they take too long and have very little payoff.

Check out this video of me walking through the game’s prologue:

The Forest is polished to the point where it’s worth polishing it! I only say that because there is an entire game still left to finish, so we can’t spend forever on the first few Levels. I will say though, I paid particular attention to these Levels because they are the first morsels of gameplay people will experience with Where Shadows Slumber. Leaving a bad impression here can permanently color people’s mental model of the game in a negative way, so it’s important to get it right.

 


 

 

Header-Jail

The Jail is Now Really Different

The next World in our “first time user experience” is a scary, lava filled jail where Obe has been taken prisoner. As he makes his escape, we teach the player about lights and the way they interact with shadows.

This World was quite difficult to get right. I still think some of it needs to be changed, but here’s where it’s at right now:

If you remember the blog post where I showed off the Jail World last time, you might be shocked to see that a lot has changed. I never liked the boxy, protruding walls I created for this World. It made it impossible to define complex shapes, and it cost a lot of polygons. As we polish the game, we also seek to optimize it, and that means giving your phones less information to compute each frame. Now the walls are much simpler, but still have a brutal “government building” quality to them.

Hopefully you support this drastic change! It’s the only World that’s undergoing such a dramatic shift, but I think it’s for the best.

 


 

 

Header-City

The City is Still Unfinished

To my great shame, the City World is still not polished. Some Levels (one in particular) don’t even look passable. That’s a problem I’ll try to rectify immediately, as the World is already late, even by our newly revised schedule.

What I can show you are two Levels still in polish-development, because I would like feedback from the general Game Revenant fanbase! Here’s the first City Level, called “Slum”, which got a big overhaul:

City-Slum.JPG

And below is Level four in the City, called “Fountain”, which I don’t think I ever showed because it wasn’t in great shape. It’s still missing two key components that require very specific artwork: plants and statues for the fountain. Right now it looks very sterile, but this is supposed to be a luxury fountain / garden fit for a king! Check it out:

City-Fountain.JPG

This red color is a deep callback only diehard WSS fans will recognize [ ^_^]!

Comment below this post about these changes, please! This World needed a lot removed from it in order to look good. It had way too many colors before, as well as misleading stuff on the screen. It’s not done just yet, as I said, but it’s in way better shape.

 

Header-Spoilers.JPG

Spoilers Ahead

As we near the completion of the final game, I’m going to get a bit more secretive with these updates. I realize now that although some sections of the game look awesome, players may want to experience them for the first time inside the game instead of in a blog post. That doesn’t mean I’ll stop posting, but it does mean you can expect to see spoiler tags in these art posts from now on. I’m waiving that this time around since most of the updates are in the first 10 minutes of gameplay, but be warned!

In the future, read on at your own peril…

 

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

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

 

 

Unity 2018!

For those of you who haven’t been keeping up with current events in the indie game development space, there’s something really important that’s happened recently that you should probably know about.

It’s 2018!

Which leads me to another topic that we can spend some time discussing – Unity 2018!

 

Unity

Before we talk about Unity 2018, let’s discuss Unity itself. Unity is the game engine in which we’ve been developing Where Shadows Slumber for the past two and a half years, and even longer ago, when we were working on SkyRunner. Developing in a game engine makes things a lot easier for the little guys like us, because we don’t have to worry (as much) about things like platform-specific dependencies, rendering pipelines, mipmap implementations, etc. Without having to worry about that nitty-gritty stuff, we can spend our time focusing on the more grandiose parts of the development of WSS.

So the question is – how has working with Unity been?

1200px-Unity_Technologies_Logo.svg

Unity!

Overall, Unity is awesome. It has somehow managed to find the right balance between an engine that you could use to make a AAA game, and one that you can use in a small, bureaucratically-challenged team. This alone is a great reason to use Unity – compared to using more complex engines like Unreal, it’s much easier to get up and running from scratch.

Of course, there are trade-offs, and this is a particularly big one. In order to avoid inundating newer users with game development intricacies and high-level concepts, Unity does a lot of that stuff for you, behind the scenes. While this is awesome in a lot of cases, there are some cases where it can be more of an issue. Imagine you’re an experienced game developer, with a sizable team, who wants to do something very specific in the backend. There’s a decent chance that Unity will have hidden that part of the engine from you, or at least made it difficult to interact with.

This tradeoff is, at its core, the reason that you would or wouldn’t want to use Unity. The next most important feature is the ease with which Unity allows you to develop on multiple platforms. All of your development is platform-agnostic, and you only choose the platform as you’re compiling. Is your Android game a success, and you want to build it for PC? Simply hit a different button, and Unity takes care of the rest. I don’t have too much experience with other engines, but this seems to be a place where other developers give Unity a lot of credit, and I think it’s deserved. I can’t imagine having to go through all of the development we’ve done multiple times for different platforms.

Beyond these bigger points, there are a few other things that might sway you, though they’re probably a little less important:

  • Unity is very UI-based, which means that it might be a little annoying for a hardcore programmer, like myself, whereas this probably makes it easier for someone with less coding experience, like Frank.
  • Unity is a sort of one-size-fits-all solution, whereas some other engines are ready-made to create certain types of games. For example, Unreal has good support for creating FPS games. If I were to make an FPS game, using Unreal would probably give me a bit of a head start on Unity.
  • The only language Unity supports is C#. C# is a pretty awesome language, but for those of you who hate C#, or strongly-typed languages in general, it may take some adjusting.

Again, I want to say that Unity has been great for us, and I would probably use it again if I were to start another game. Frank and I wouldn’t have gotten to where we are with Where Shadows Slumber if it weren’t for Unity.

 

Unity 2018

I mentioned earlier that Unity does a lot of stuff for us, and I specifically brought up rendering pipelines. The danger of using a game engine (that you didn’t make yourself) is that other people are making decisions for you, and those decisions are set in stone to a certain degree. On one hand, we didn’t want to mess with the collision system, so we were glad to have it. On the other hand, we ended up in a position where we did want to mess around with the rendering pipeline, and we weren’t able to.

Enter Unity 2018.

image5_rs

The Unity UI, blatantly stolen from one of their blog posts.

I normally don’t pay too much attention to the ins and outs of the various updates that Unity makes. They’ve been marching out updates, both major and minor, for a while now, and we’ve just been going with the flow. Unity 2018, however, has managed to catch my eye. Unity recently released a blog post describing the updates they’ve been making to graphics and rendering in Unity 2018, and I have to admit that I’m pretty excited about it.

As I mentioned before, Unity does a good job of riding the line between too-complicated-for-new-users and not-powerful-enough-for-power-users, and the updates described for Unity 2018 somehow manage to play to both sides. If you’ve ever held a conversation with me about Unity and Where Shadows Slumber, then you know that I’ve been struggling with getting shadows to render the way I want, while also maximizing the efficiency of the rendering pipeline. Fortunately, Unity 2018’s focus on graphics and rendering has provided two huge features in this area, one for each of the two camps.

Scriptable Render Pipelines is the feature that I’m excited about, as it’s the feature aimed toward the entrenched coder. Rather than using the hard-coded rendering pipeline that we’ve been wrestling with for the past two years, we can create our own rendering pipeline that does exactly what we need it to.

“Programmers can now write custom renderers tailored specifically to their project.”

This is a huge boon to us, and to game developers everywhere. Rather than hacking together a shader that uses Unity’s shadow-mapping inefficiently, we can (hopefully) create a rendering pipeline that performs shadow-mapping exactly how and when we need it. This should result in more efficient rendering, along with less headache while writing shaders.

Shader Graph is the other great feature Unity 2018 will have, and is targeted toward less code-inclined users. Unity provides a standard shader with a bunch of options, so you can create the materials you want. However, if you need more customization than the standard shader provides (like we do), you’re suddenly thrust into the depths of shader-writing. With a masters degree in computer science, I’ve been just barely keeping up with writing our shaders, and there’s no way that Frank would have been able to do it. This is really a bummer, as the artist tends to know a bit more about the “look” they’re trying to get.

“[I]t’s simple enough that new users can become involved in shader creation.”

Unity 2018’s Shader Graph changes this – rather than writing complex shader code, Unity exposes a simple interface for creating shaders graphically. This would allow an artist with no coding experience whatsoever to build a custom shader to display things exactly as they want – giving the artist the control they need over the “look” of the game, and allowing the programmer to focus on the game itself.

shadergraph

A sneak preview of Unity 2018’s Shader Graph UI

I’m sure that Unity 2018 comes with quite a few quality-of-life updates, as well as some other new and interesting features. For me, however, it’s all about those rendering updates!

 

Beyond Where Shadows Slumber

A friend of mine recently asked if I would use Unity for my theoretical next project, and if I would recommend it to someone just starting on a game. The answer I gave him is one that applies to every question – it depends. In fact, it mostly depends on the factors described in the first section.

Overall, I’m inclined to say that I would use Unity again. After over four years, I’ve come to know it pretty well. It’s powerful, and allows you to create and iterate pretty quickly. That said, there are some exceptions; I would probably pass on Unity for my next project, or at least do some more research, if:

  • I had very specific backend/optimization requirements
  • I were working with people who had a lot of experience with a different engine
  • The scale of the game were much bigger
  • The game involved a lot of networking/server concerns

There are probably other factors that come into play – basically, it pays to do some research before you dive in. I would recommend Unity, but more than that, I would recommend knowing what you’re getting yourself into. There’s nothing worse for your game than getting halfway through it in an engine that won’t work for you in the end.

If you’re anything like me, at this point the word “Unity” no longer sounds like a word. I’m gonna take that as a sign and wrap this post up; I hope I was able to answer any questions you might have had about working with Unity, and that I got you pumped for Unity 2018!

 

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

If you have any questions about working with Unity, or if you have any other questions about Where Shadows Slumber, feel free to contact us! You can always find out more about our game 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.

State of the Art – November 2017

Welcome to State Of The Art, November 2017 edition! This monthly progress report is written by Frank DiCola and is focused entirely on how the game’s visuals have improved in the past month.

<Don’t forget to add in some lame excuse about Thanksgiving before you post this>

Without further excuses, let’s explore the major leaps forward we took in November!

 

0-1-Header

The Game’s First Level, “Fallen”

It took me a while to get around to doing this Level, because there’s a bunch of triggers I had to animate and I didn’t feel like doing those. For the longest time, Level 0-2 has been our de facto “first level.”

Dec-5-Blog-Forest

But the game really begins here, along this spooky Forest path, where Obe first encounters the Lantern. You can watch the entire Level in the video below, since it’s so short. (Just ignore the missing sound effects and animation polish, all of that comes later.) Jack and I have a rigid philosophical stance when it comes to game design: we don’t like using text to tell players what to do. That’s annoying! So this Level is designed so that people can learn how to walk. It’s impossible to avoid picking up Obe’s lantern because he automatically does that when you walk on the first open space in the clearing.

This Level didn’t take too long once I actually sat down and did it. Since Obe can only walk around the center of the Level, and his light radius is quite small, there’s a lot of art I can intentionally ignore. This may seem lazy, but there have been times in the past where the opposite has occurred! I’ve done beautiful artwork around the edges of the Level only to be dismayed to find the light never reaches there, and players will never see it. But I still see it. In my dreams.

 

Dec-5-Blog-City-Header

Level 4-3, “Ramparts”

One of the most ambitious Levels we planned for the game has you scaling the ramparts of a city wall as you climb to the palace on top. It’s a transition Level, which makes it super important for the story. The first two Levels in this World take place in the slums, and the final two Levels in this World take place in beautiful palace gardens. We need a bridge in between those two, otherwise the jump from one to the other will be too abrupt for the audience.

Enter Level 4-3, “Ramparts,” a vertical bridge between two different worlds separated by economic class and power. It’s easier to show you than tell you! We begin on the street, with the dogs.*

Dec-5-Blog-City-A.png

*Dogs not included

Then there’s the middle section:

Dec-5-Blog-City-B.png

On top, we can see the palace architecture more clearly:

Dec-5-Blog-City-C

This Level took forever for Jack to make and for me to decorate. Even now, it still needs an extra coat of paint! The puzzle isn’t difficult, but the vertical nature of it means we need to cover up a lot of the screen. I want to put more plants closer to the top, which I didn’t really have time to do yet. Plant life would indicate that even in this barren desert, the wealthy King who lives in the castle gets to be surrounded by beautiful foliage.

 

Dec-5-Blog-Paradise-Header.PNG

Paradise Begun

The game’s final World is a beautiful island paradise floating in the sky. This is somewhat of a story spoiler, but we’ve blogged about it before so I’m not too concerned. Read on at your own peril, I guess?

It’s taken me a while to return to this beautiful setting. Anything that comes last in a video game usually gets the least attention. It’s regrettable, but understandable. After all, if you see a movie in theatres, you often see 100% of it.  Unless you leave in the middle for some reason, you’ll experience the beginning, middle, and ending. But video games are different. Only a fraction of players make it to the end of the game, but by definition anyone who plays a game experiences the first 5 minutes. That’s why those first 5 minutes are so crucial and get so much special treatment.

I’d like to break the chain, if I can. I want people to feel rewarded for getting to the end of this difficult puzzle experience. Here’s the current progress on World 7, which I just started last week. They’re in rough shape at this stage, but you can get a sense of where I’m going with these.

Dec-5-Blog-Paradise-A.png

Level 7-1, “Ladder” is all about compiling a ladder from a bunch of broken pieces. The ladder comes together using the shadows from that conveniently specific rotating object. It’s harder than it looks! I designed this one and I forgot how to solve it. Good luck!

On the first landing, we get a chance to show off that majestic Bermudian inspired architecture I love so much. If I have time, I’ll even include a cool dude relaxing on a chair just to show how far removed this World is from everything below.

Dec-5-Blog-Paradise-B.png

Level 7-2, “Pond” is due for somewhat of a re-do. The major thing I forgot to include here was a pond in the center where that button is. We want some kind of a sacred grove with a sacred button because that’s how you solve this Level – you need to use the center piece in order to drag boxes around and cast the shadows you need to fix the ending staircase.

This is where design and aesthetics conflict. The pathways we need are very specific and jagged, but the “look and feel” we want is uniform and symmetrical. It’s a tough compromise. I’ll return to this one and remove that weird green rock path (a placeholder) and try to do something closer to my original “Toolkit” Level I posted so long ago:

World-7-Paradise

(This isn’t a Level in the game, but rather spec work I did a few months ago when I was beginning each World’s “Toolkit.” But that center pond is making a comeback, just wait for it!)

Dec-5-Blog-Paradise-C.png

Level 7-3, “Tower” isn’t very far along, but it’s such a cool design I thought I would tease it here. You need to see a video of it in action to really grasp what’s going on, so no more for you just yet! Be patient [ ^_^]!

 

UI-Header.PNG

User Interface Sketches

Generally I prefer not to show off drawings that are not part of the game. But Jack and I just started on the user interface design, so it can’t hurt to show you a tiny bit of what I’m working on…

 

It may seem late in the game to handle this, but we decided long ago that we don’t want a complicated user interface. Above, you can see that our Levels contain all the features that a Main Menu would normally have. We don’t really like having a separate menu detached from the game, so you can access all the key stuff just by “pausing” the game.

Note: this is just a Photoshop design. We haven’t coded this in yet, and not all of the buckets you see above are necessarily being included in the final game. For example, being able to take a picture of the Level is an important social feature, but it’s not essential for the game’s launch and may fall by the wayside.

Interacting with phone features is a big pain and it’s one of the toughest things about game development. Making your game work on every single tablet, flip-phone, e-reader and seashell Kindle out there is a nightmare. Maybe we’ll write a blog about that topic once we get more into the weeds of cross-platform development…

 

christmas2012_alternative_santa_onlycoke_flexible

See You Next Year!

The next time you read this particular blog series, it will be 2018 and I’ll be recapping December. Man, where does the time go? This year has gone blazing by!

This month, I hope to finish World 7 and move on to polishing up each Level. That work is highly specific, which is why it was left until the end.

Polishing the Levels will intersect with working on the game’s cutscenes. That’s because some of these Levels have animated characters in them. I’d like to be sure that the animated characters I create work well in both settings, to save myself time later. So don’t be surprised if next month’s update is a bit of a mixed bag. That’s the way it’s going to be from now until the game launches!

 

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

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

Problem Solving: Design and Complexity

Game design and development is a complicated process. Creating an intricate tapestry of player interaction, incentive, and reward can be quite difficult, and you will no doubt run into trouble along the way. This is a simple fact of game development – in fact, this phenomenon represents most of the time you’ll spend working on your game. Therefore, you shouldn’t worry about it when that trouble finds you! However, an important part of how polished your game ends up, how long it takes to make, and whether or not you even get a chance to finish it is how you handle the issues you run into.

At its core, a game can be described by a set of rules which govern gameplay, and a starting game state. A match-three game, for example, can be described by the following rules:

Simple match-three rules

  1. The game starts with a grid of colors.
  2. Any three or more adjacent cells of the same color disappear, granting points to the player.
  3. If there is an empty cell, the cells above it slide down to fill in the space, generating a new cell at the top.
  4. The player may switch the colors in two adjacent cells.
  5. The game may end when the player reaches a certain number of points, or when they make a certain number of moves, or if there are no available moves, etc.

Obviously, these rules don’t encompass everything that happens in a game, and the rules get much more complicated very quickly for more complex games. These simple base rules define your gameplay, but they very quickly become more intricate as you add features and functionality. Let’s look at a few updates to our match-three example:

  • If we want to add a type of cell which can’t be moved, we would have to change rule #4 to “The player may switch the colors in two adjacent cells unless either of those cells is unmovable”.
  • If we want to add an “exploding” cell which eliminates nearby cells, we would have to change rule #2 to “Any three or more adjacent cells of the same color disappear, granting points to the player, and if one of them is an exploding cell, adjacent cells also disappear”.

The base rules handle 90% of the gameplay situations, but we have to add special provisions for exceptions of those rules. In game development (and computer science in general), these exceptions are called edge cases, and, as necessary as they are, they’re super annoying. Your code will include edge cases, and it should, but you have to be careful with them (edge cases may be considered a type of hack, which I discuss in one of my previous blog posts), and you should avoid them when possible. One of the primary ways to do that, depending on your game, is through design – rather than complicating your codebase, you can try to design your game and/or levels in such a way that you don’t need to change your code.

 

An Example from Where Shadows Slumber

Let’s take a look at the inspiration behind this post – a case I ran into in Where Shadows Slumber where I faced such a decision.

1-1 goal

Ominous!

At the end of each level, there’s a ‘goal’ space. When Obe steps on it, it triggers the end-of-level sequence to begin – the lights fade, Obe walks out of the scene, and then the next level loads. The question is, given the game rules, how can I make this happen? I could have added a specific code path for this case, but I realized that I could use some already-existing mechanics to create this effect:

  • The machinery behind buttons can already handle “trigger something when Obe steps on a space”, including a delay for ending the level.
  • The machinery behind Obe walking in at the start of the level allows us to redirect his movement.

This is one way of handling an edge case – try to reduce it into an example of something you already have, thus changing it from an edge case into a normal case. Now we’ve changed the ‘goal’ space into a different-looking button with a redirect space.

Now, there’s another situation involving the goal space where I was given a similar choice. In some levels, there’s a space both to the left and to the right of the goal space. This enables a situation in which the player moves onto the goal space, and then away from the goal space. This creates a problem: the end-of-level ‘button’ will trigger, the lights will dim and the next level will load, but Obe hasn’t left the scene – he’s still just standing there!

ezgif.com-video-to-gif

Well that’s not quite right…

This is a problem I can solve by changing the rules, or by changing the design. The rules for redirecting Obe’s movement only apply when he doesn’t already have a destination. In order to handle this situation, I could add a case that says “if the current node is the goal node, do the redirection”. This requires that I add code to mark a node as the goal node, and to check if the current node is the goal node. While this code would be pretty small and easy to write, it still adds to the overall complexity of the codebase. Is there a way to avoid doing so?

There is, in fact, and it’s quite easy. If we simply remove all of the places where this could happen, then we don’t have to worry it! We’re not “solving” the problem in a conventional sense – if the configuration of spaces were to come up again, the problem would still occur. However, by changing the level design, we remove any chance of that happening.

1-1 goal with boxes

I’ll have Frank make something more on-theme to fill that space

This is another way of handling an edge case – by making a small change to the level design, we’re able to avoid making changes to the codebase. This prevents our code from becoming needlessly more complex, making it easier to understand and maintain. While not every problem can be solved in such a simple way, there are many that can, and keeping an eye out for them is a great way to avoid unnecessary code complexity.

 

Living on the Edge

I keep talking about edge cases and code complexity like they’re bad things. But an entire game is a very complex thing – doesn’t it make sense for the codebase behind it to be complex as well?

There’s nothing inherently wrong with complexity in your code; a well-implemented cache invalidation algorithm is a beautiful thing, complex as it is. What isn’t beautiful is needlessly complex code. The logic in this code is usually hard to follow, makes assumptions, and leaves a lot of small bugs that you’re unlikely to notice right away. This is a recipe for disaster, because every time you try to make a small change, you have to wade through a swamp of half-thought-out code paths, and you end up adding more complexity just so that you don’t have to deal with the complexity that’s already there!

The biggest problem is that it’s very hard to tell the difference between code that’s complex because it has to be (good) and code that’s complex when it doesn’t have to be (bad). The way I deal with this is to try and realize when the code I’m writing is starting to become very complex. Even though I might only be fixing one bug or working on a specific part of the implementation, I try to take a step back and look at the problem that I’m trying to solve, and how I’m solving it. If the problem is a complex one (cache invalidation), then I accept that it’s gonna be a complex algorithm, and keep writing it. If it’s not a complex problem (sorting), I take another look at my code and see if there’s a better way to do what I’m trying to do. In this way, I continuously re-evaluate the complexity of my code, and whether or not I need it.

Hack

Six while loops isn’t too many, right?

I know that “I just know when it’s too complex” might not be the most satisfying answer for those of you who often run into issues of complexity. That feeling is something that you pick up as you do more and more coding, and especially as you revisit your own code – “wow, I can’t believe I wrote such stupid code”. For those who want a more concrete answer, here are some of the ‘red flags’ that I try to keep an eye out for when assessing the complexity of my code:

  • A lot of ‘if’ statements – If your code has a lot (and I mean a lot) of random ‘if’ statements (especially nested ones), then you might want to take another look at the design.
  • “I don’t know…” – If you can’t quickly and easily determine what each piece of your code is meant to be doing, your design might be too complex.
  • Guessing – If you ever find yourself just “trying things” and “seeing if they work”, it’s a clear sign that you don’t understand your code well enough. Take some time and get to know it!
  • Duplicated code – If you have the same block of code copied into a few places, you should revisit your design. Either that block belongs in a helper that you can reference, or the control flow of your code needs to be reconsidered.
  • Asynchronicity – If you’re doing anything asynchronous, you should give your code another look. I know you probably did it right the first time, but asynchronicity is one of the most difficult parts of computer science, and it’s always worth double-checking.

There are a lot of other things that you might notice about your own code and its complexity – these are just a few quick guidelines off the top of my head. Hopefully they help!

 

But Game Development is Fun!

Anyways, I hope I didn’t scare you away from computer science. If anything, I wanted to instill a healthy fear of needless complexity, and I hope that you’ll do what you can to reduce that complexity – whether by redesigning your code or redesigning your levels!

 

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

If you have any questions about code complexity and how to design around it, or if you have any other questions about Where Shadows Slumber, feel free to contact us! You can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebookitch.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

Our Demo: 1 Year Anniversary

One year ago, on November 1st 2016, we released a free Demo build of Where Shadows Slumber to the world. This marketing build has just 10 Levels and a cutscene at the end, yet it’s been downloaded hundreds of thousands of times by gamers all over the globe. We don’t get a chance to talk data often, but this post is dedicated entirely to discussing the performance metrics of our Demo. Towards the end, we’ll answer the burning question on your mind: was it worth it?

 


 

 

google-play-logo-2016

Google Play Lifetime Stats

The Demo performed the best on the Google Play store. I have a feeling that’s because the Demo is free, and people on the Google Play store tend to be younger / less willing to pay for games. When they see a free game that looks beautiful, of course they’re going to download it! Let’s dive into the Google Play Console and check out some of our stats…

GP-Installs.PNG

Left: the chart of app installs. Right: the chart of app uninstalls.

Installs and Uninstalls

First, the obvious: we’re two no-name developers living in Hoboken, New Jersey and 250,000 PEOPLE DOWNLOADED OUR GAME ON ANDROID!!!

\[ 0_0]/

*Ahem*

The lifetime chart of the Demo on Android shows that it went live in November and hit its peak in December, probably due to the Christmas holiday. I think it’s interesting to note that the first two months an app is live appears to be “prime-time.” Look at all those downloads!

Yet, even though we hit our lowest point (since the November we launched) in May 2017, we’ve consistently gotten more downloads every month after that. Rather than plateau, the app continues to outdo itself month after month. That’s crazy. I’m proud of that, and I hope this month’s downloads eclipse October’s, which is 26, 467. That’s pretty tough to beat!

Of course, the downside is that nearly everyone who installed the app promptly uninstalled it, most likely after completing it. I’m not shocked by that. This is just a demo. People want to play it and then get rid of it – it doesn’t really deserve to stay on their phone. I expect this behavior will continue with the final game, save for a few thousand people who feel sentimental and can’t bring themselves to delete it. I’m pretty ruthless when it comes to clearing space on my phone’s hard drive, so I don’t blame people for not sticking around. You might say our “retention” is terribly low. But I also don’t think it matters for Premium games the same way it does for Free games.

 

GP-RatingsAmalgamation

Top: Our rating. Left: A chart of our rating over time. Right: A sample review.

Ratings and Reviews

As you can see in the charts above, our lifetime rating is quite high and we’ve received thousands of ratings. People have responded very positively to the Demo! The majority of our ratings are 5 Stars (4,149) with only a sliver of negative 1 and 2 Star reviews.

The graph of our rating is interesting. Starting with a perfect 5 Star rating at launch, we slowly drip down to a 4.6 (the bottom of the graph is 4.6, not zero!) by May 2017. Then, as indicated, the build adding a finale cutscene goes live. From there, our ratings steadily increase to the point we’re at now.

This is a really important moment in time, because Jack and I were nervous about how the story would be received. It’s a bit off – not quite what you’d expect from a puzzle game made in the image of Monument Valley. We expected more negative reviews. Instead, they’ve been largely positive. We kind of left people on a cliffhanger and they’re eager to find out just what the heck is going on.

At right, you’ll see a common review. Most of them are like this: people love the game, say they’ll buy it, but are disappointed that this is just a Demo. Truly, I have no idea how people missed this! The title of the app is Where Shadows Slumber Demo (Beta). There’s two keywords in that title that would tell you this is not a finished thing! But you can file that under “nothing is too simple for people.”

If you want to read more reviews, go to our Demo’s Google Play app page and flip through them. I could read them all day, but it would make my head get too big.

 

GP-World.PNG

The top 5 countries that downloaded our Demo.

Who Is Playing?

The top five countries that downloaded our game are South Korea, India, the U.S., France, and Mexico in that order. France and Mexico are nearly tied, and the U.S. isn’t too far ahead of them. But India has double our installs, and South Korea blows everyone out of the water. What the heck is going on?

It’s important to note that Jack and I went through the arduous process of paying for 14 languages of translated text and put them into the Demo. That means Indian players see the game’s app page in Hindi, as well as the in-game text. That’s a big deal. It means we’re meeting people where they are across a global market. We didn’t translate the game into any African languages, so it’s no wonder that entire continent is grey except Egypt. (We did translate the game into Arabic…)

Free games are really popular in Asia. To the extent that this Demo is a “free game,” that explains its success in South Korea and India. After all, it is a game that costs no money. So it is technically a free game! I do not expect this same success once the game costs $0.01 or more. We’re going to have to target the Asian market with a lower price than normal, or perhaps even a try-before-you-buy method where the first half of the game is free. Don’t get me wrong, I’m happy that these people downloaded our game and clearly loved it. But when the business model flips and we ask for their cash up front, I don’t expect to see South Korea or India to even make it into the top 10 list.

 


 

 

applestore20copy

App Store Performance

The App Store’s analytics aren’t quite as easy to decipher as Google Play’s… also, our performance on Google Play dwarfed the App Store in every possible way!

Apple-AppUnits.PNG

From iTunes Connect – a chart of our App Units.

App Units vs. Impressions

Our performance on Apple makes more sense to me. We only “sold” 32,285 app units. We got over 200,000 lifetime impressions, but I don’t know what that means! That may just be when someone sees the game but doesn’t necessarily act upon that.

The chart of our downloads follows a pretty standard “flash-in-the-pan” trajectory. This may be partly because we were never able to upload our language translations to the App Store. I’ll discuss that a bit more when we get to my conclusions, but that’s my guess as to why we plateaued in May and never really rebounded.

It should be stated that App Store customers are the polar opposite of Android people – App Store customers probably want paid games and see “Free” as a mark of low quality. I expect these numbers to swap when the final game is released.

 

Apple-Review

Our dashboard for monitoring reviews. Note the total in grey on the right.

Ratings and Reviews

We didn’t get nearly as many reviews on the App Store – just 26 in one year. That’s probably all an indie developer can expect, but it doesn’t explain the disparity between this and Android. The reviewers were quite kind, and we have a 4.9 out of 5.0. However, with such a small sample size, that’s not as impressive.

 

Apple-World.PNG

Who Is Playing?

Surprisingly, China is our top country on the App Store. I didn’t even know we had access to the Chinese App Store! I don’t know if we can trust those numbers. In second place we have the United States, and then Russia, Japan, and South Korea. These numbers are too small to really tell us anything meaningful, except that we should focus our efforts on China for the iOS release of this game!

 


 

 

amazon_appstore_logos

Amazon App Store Performance

The Amazon version of our Demo went up earlier this year, but there’s no way to really see how much traffic it has gotten. My guess is that no one besides Jack and I have seen it, since the only review is one that I left on the company account.

AmazonLOL.PNG

My very serious review

If you have a Kindle or a Fire, please check out the Demo there! We’re doing a lot by trying to be on as many platforms as possible, and we could use the testing feedback.

I hope things will be better in the future with Amazon, but this isn’t promising. The company has gifted us four mobile devices to use for testing, as well as a guaranteed spot on the Amazon App Store feature banner at a time of our choosing. Let’s hope they have the install base to make it worth our time! We will not be coming to Windows Phone since those devices have been discontinued – I hope the same fate does not befall Amazon.

 


 

 

WorthIt

Retrospective: Was It Worth It?

After having our Demo available for free all this time, people often ask us “was it worth it?” What’s the point of releasing a demo so far in advance of the actual game? Don’t you want those people to pay for the real version? Won’t they forget about your game by the time it launches? Does anyone even make demos anymore?

That’s true – mobile gamers who stumbled upon our Demo a few months ago probably already forgot about us. They’re not eagerly anticipating the release of the final game. It probably isn’t even on their phone anymore! Just because this game is the center of our world, that doesn’t mean we can expect the same loyalty from some people who played a 15 minute trial. (Shout out to everyone reading this blog, because the previous paragraph clearly does not apply to you!)

It’s fine though, because none of that was ever the intended purpose of the Demo. All we needed were the following things:

  • A proof of concept that shows we can actually make something great
  • Something that claims the name Where Shadows Slumber before anyone else
  • quickly deployable version of the game to showcase at events
  • An easily submittable build that we can send to judges for contest submissions
  • Something that gives us experience dealing with the App Store and Xcode.

By these metrics, the Demo was a whopping success!

We proved to ourselves and our fans (and shadowy unnamed figures who can’t be named) that we can put together an awesome small indie game. Making something a little larger would take more time, but we already had the talent and the drive.

Judging by a Google search of “Where Shadows Slumber”, no one else has been able to claim that digital territory except for an old song from 2007. We’ve been in Google’s search algorithm for over a year, which can only help us in the long run when people try to find us online.

“The Demo has given us an air of legitimacy that many indie developers never consider when releasing their game into the wild.”

Any time we go to an event and the current build of the game isn’t ready to show real people, we just default to the Demo and it’s no problem! In fact, those events go even smoother than when we try to show off the development build. As for contests, having a no-strings-attached build out in the wild makes online applications a breeze. I’ve already got a folder filled with screenshots, videos, and a recent .APK that I can throw in there. I don’t know how many festivals want to feature our Demo, but at least they’ll remember us when we return next year with a finished game.

The App Store is an odd one. Technically, our Demo shouldn’t even be on there because Apple forbids you from submitting them. We slipped through the cracks five times! I don’t think that’s an endorsement of our talent, but rather an indictment of Apple’s system of judging builds. Perhaps we’re on borrowed time, and they’ll delete it any day now. Who knows? It doesn’t matter – between our Demo and the previously released SkyRunner, we’ll be Xcode pros by the time we jump in there a third time for the final release of Where Shadows Slumber.

In the end, it was definitely worth it to produce our Demo. Yes, it’s maddening to watch our game grow better every day knowing that people’s only conception of it is a year-old marketing build. But it will all be worth it in the end when we get to show the world what we’re working on! The Demo has given us an air of legitimacy that many indie developers never consider when releasing their game into the wild.

In the meantime… (I’ll have to train myself to not say this automatically, because I’m so used to it by now) …download our Demo. It’s free!

 

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

Thanks for reading this long-form business analytics update. If you came here from Reddit, please be kind! 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.