The Good

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

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

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

 

 

Lessons Learned

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

Blogging

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

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

 

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

 

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

 

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

 

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

 

 

Personal Life

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

17159203_1817437325174646_6524966612565150056_o

BFFs Forever!

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

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

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

 

 

The Game Itself

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

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

trophy

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

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

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

 

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

 

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

 

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

 

 

A Fond Farewell

happy3

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

 

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

You can always find out more about our game and how awesome it is at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebookitch.io, or Twitch, join the Game Revenant Discord, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

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

Crunch and Burn(out)

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

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

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

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

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

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

 

Night.jpg

Crunch

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

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

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

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

 

Burnout.png

Burnout

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

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

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

 

Tunnel.jpg

The Light at the End of the Tunnel

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

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

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

 

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

You can always find out more about our game and how freaking long it’s taking us to finish it at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebookitch.io, or Twitch, join the Game Revenant Discord, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

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

Optics

Hey, it’s me, Jack! For those of you who have been following our blog, you may have noticed that I haven’t posted in a while. You’re probably wondering what happened to me. Did Frank kick me to the curb? Did I abandon Where Shadows Slumber?

In all honesty, you probably didn’t even notice. Whatever the case, I haven’t gone anywhere! The reason I haven’t posted anything in a while is that, simply put, the stuff I’m working on isn’t all that interesting. Compared to action-packed cutscenes and beautiful artistic polish, bug-fixing and number-tweaking are pretty dull.

BugFixesCommit

An enthralling contribution

That’s why, this week, I want to talk about something that isn’t specific to Where Shadows Slumber, and has nothing to do with the work I’ve been doing this past month. Instead, I’m gonna talk about something that applies to everyone – not just in indie game development, but in any business at all!

Optics is an area of business management that is very closely associated with marketing and publicity. However, as its name suggests, it refers less to the way in which you’re introducing people to your product, and more to the way that your product is actually perceived. Optics isn’t an action that you take, it’s more of a general way in which you act about your company and/or product.

Optics – the scientific study of sight and the behavior of light, or the properties of transmission and deflection of other forms of radiation.

That’s not a very useful description, so here’s a quick example:

  • Posting on Facebook, putting up billboards, and going to conventions are all examples of marketing. Note that they’re all specific actions.
  • Deciding to be very transparent about your process, or always being snarky on social media are examples of optics. They’re more like predefined ways to act.

Let’s take a look at how thinking about optics has impacted Where Shadows Slumber.

Warning – as with any conversation about a product’s “image”, this next section may be a little pretentious.

Where Shadows Slumber‘s Optics

So, what are some ways in which we consider the optics of Where Shadows Slumber? Surely, this wouldn’t be a topical blog post if I didn’t discuss our application of the concept!

The answer to this question lies in how we want our users to think about Where Shadows Slumber. Consider the difference between a game like Monument Valley and something like Candy Crush. They’re both great, successful games, but the general public thinks about them differently. Monument Valley is artsy and represents a unique experience, whereas Candy Crush is a well-oiled time-killing machine that you can always open up and play. They’re different, and both successful, in part because they know what they are and how they’re perceived. How do we want Where Shadows Slumber to be perceived?

World-7-Paradise

Where Shadows Slumber – a beautiful, mysterious, puzzle game

Where Shadows Slumber is, at its core, mysterious. When thinking about Where Shadows Slumber, people find themselves wondering: Who is Obe? What is he running from, or to? What do his journey, his light, and his darkness represent?

Where Shadows Slumber is a puzzle game. When playing it, players aren’t simply following a path, but choosing one. They’re engaged, actively trying to figure out the puzzles. They feel a sense of agency – they are in control of the game.

Where Shadows Slumber is, for lack of a better term, art. When looking at it, people appreciate the colors and the aesthetic. They notice the attention to detail and the smoothness of the gameplay. They recognize immediately the time and effort that has gone into it.

I consider each of these things, and everything else that people think about Where Shadows Slumber, to be a part of our optics. When we’re making design decisions, we ask ourselves – “does this design continue to represent our game as an engaging puzzle game?” When choosing color palettes for a level, we wonder – “will these colors result in an image that someone would hang on a wall?” By continuously working toward our desired image with every decision that we make, we do our best to ensure that the public will view the game just as we want them to.

 

The Team!

Optics doesn’t just apply to the game itself – it applies to anything and everything on which a potential player might judge us. If you find out that a company has unethical business practices, you probably won’t buy their product, even if it’s the best one on the market. The optics of that company, not just the product, has affected your choice when considering it.

DREAM Team

What we want everyone to think about our team

The image that Frank and I portray as a team is just as important as the image that Where Shadows Slumber itself has. Our team optics are very carefully designed – two friends who met in a sketch comedy group in college, who love games so much that they just want to be a part of, and give back to, the indie gaming community? How can you not love that team? They sound like such cool bros! The fact that it’s actually true is just icing on the cake – now our optics include honesty and earnestness!

In fact, there are parts of our image that are purely invented for the sake of optics. Our friendship? It’s a total lie. Frank and I, after working together for nearly 5 years, simply hate each other. Why do you think we want the production of Where Shadows Slumber to be done so much? We don’t want to have to work together anymore!

Note: Sarcasm doesn’t come across very well in a pure-text format – Frank and I are actually very good friends!

17159203_1817437325174646_6524966612565150056_o

Best Friends!

Another example of optics is that note that I just made! I couldn’t let you leave, knowing the truth of our animosity! The truth is that we do hate each other – but it’s better for us if you think we’re best friends!

Note: Again, the above is sarcasm. Please disregard it!

Team

Seriously though, best friends! Frank wasn’t plotting his revenge at the moment this was taken!

As yet another example of optics, please direct your attention to that second note I just made! I have sworn a blood oath against Frank’s life! He has sworn vengeance against my family! A thousand-year feud ensues, ending only with the extinction of the human race!

Note: ……………….

This Blog!

The final thing I want to point out about the optics of Where Shadows Slumber is this blog itself! By being as transparent as possible about our process, and by connecting as much as we can with our fans and potential players, we do our best to present ourselves as a fun, interesting, and relatable team. By discussing the details of the implementation, design, and art of Where Shadows Slumber, we drive home the point that the game itself is an intricate and interesting experience. By offering tips, tricks, and advice for your own games, we give back to the community that we love so much, and establish ourselves as a part of that community.

Optics are an important part of creating any product. Without a part of your team dedicated to putting out a positive image of you and your product, it becomes the responsibility of every person on the team to actively contribute to your product’s optics. The image that you are striving to achieve should inform many of your decisions, whether they be design- or business-related.

Remember, you don’t want to just make a game – you want to look good doing it.

 

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

I hope this little foray into the world of optics helps you to better promote your own products. I don’t hope, however, that it causes you to question everything that we’ve ever said about Where Shadows Slumber! Either way, 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.

Unity’s Performance Debugging Tools

Last week I discussed some of the basics of how rendering works in Unity. As I mentioned, all of that was setup for this week’s blog post. Since I’m working on rendering optimization now, I figured it would be a great time to go over the debugging tools Unity provides in order to aid rendering performance. Online resources can be a little scarcer for rendering than they are for other aspects of coding, so hopefully anyone who’s working on their own game might glean some useful information from this post. And even if you’re not working on anything right now, I hope you follow along and maybe learn a bit!

Unity is a nice little game engine, and, as such, it does a lot of the work for you. For the most part, when making a game, you don’t have to worry about the nitty-gritty stuff like rendering. When building for mobile, however (especially when you have specific graphics/lighting customization), you might have to descend into shader-land. Fortunately, Unity provides a few tools that can help you to deal with optimizing your rendering pipeline.

 

4-24-Profiler.JPG

Profiler

The first step in fixing rendering performance issues is to know about them. The best way to do that is with the Profiler window (Window -> Profiler). While you’re running your game, the Profiler keeps track of a lot of incredibly useful information, like how long each frame takes to render, split up by category. For instance, the Profiler will tell me that a frame took 60 milliseconds to run, 40 of which were due rendering and 15 from script execution, etc. This is the first place you should check when trying to improve performance – there’s no point in optimizing your rendering if it’s actually your scripts that are running slowly!

profiler

So much information!

For the purposes of rendering, there’s an entire Profiler section! The Rendering Profiler keeps track of the number of batches, setPass calls, triangles, and vertices in each frame. Looking here for inconsistencies, spikes, and just high numbers in general is a good way to get an idea of why your game is taking so long to render. The Profiler also has a lot of other info that’s useful for diagnosing and debugging performance problems. I really recommend profiling your game and thoroughly looking through the results to get as much information about how your game is running as possible.

 

android_debug_bridge

Android Debug Bridge

While profiling in the editor is pretty useful, it doesn’t tell us much – of course our game will be fast on a great big computer, but how does it run on a crappy phone?

The is where ADB, or the Android Debug Bridge, comes in. ADB allows your computer to communicate with your Android phone about all sorts of stuff. Specifically (for our use cases), it allows you to profile your game while it’s running on a device. If you plug your phone into your computer, build the game directly to your phone, and open the profiler, you should see some results. This is the information we want, because it tells a much truer story about how your game runs on a phone.

Where Shadows Slumber, for instance, runs at ~200 fps in the Unity editor. When I plug my phone (the Google Pixel 2) into the profile, I get a framerate of ~60 fps. This is pretty good, so I know our game can run on newer devices. However, when I plug in my old phone (a broken HTC One M8), I get closer to ~12 fps. Looking at the profile during this run will give me much more useful information about what I should fix, since this is the device where performance is actually suffering. If you’re making any big decisions or changes based on profiler results, make sure those results come from your actual targeted device, and not just from the editor.

ADB usually comes with the Android SDK – if you have the Android SDK set up with Unity (which allows you to build to Android devices), then you should be able to use ADB with the profiler pretty painlessly.

I should also mention that there might be an equivalent tool for iOS debugging, but, as I do all of my development on a Windows machine, and all of my testing on an Android phone, I wouldn’t know what it is. Sorry!

 

4-24-Header

Frame Debugger

The next most important tool for rendering performance is the Frame Debugger (Window -> Frame Debugger). While the Profiler tells us a lot about what’s happening during rendering as a whole, it still treats the rendering process as a black box, not letting us see what’s actually happening. The is where the Frame Debugger comes in – it allows us to see, step by step, exactly what the GPU is doing to render our scene.

As I mentioned last week, the GPU renders the scene through a bunch of draw calls. The Frame Debugger allows us to see what each of those draw calls is drawing. This allows us to determine which materials/shaders are causing the most draw calls, which is one of the biggest contributors to rendering lag. It also provides a bunch of information about each draw call, such as the properties passed to the shader or geometry details. The important thing that it tells you is why this draw call wasn’t batched with the previous draw call.

frame debugger

All of this happens in a single frame

Batching is Unity’s first defense against rendering lag, so it makes sense to batch as much stuff into a single draw call as possible. Because rendering is such a complex process, there are a lot of reasons why draw calls can’t be batched together – certain rendering components simply can’t be batched, meshes with too many vertices or negative scaling can’t be batched, etc. The frame debugger will tell you why each draw call isn’t batched with the previous one, so you can determine if there are any changes you can make that might reduce the number of draw calls, thereby improving rendering performance.

For example, in Where Shadows Slumber, we re-use meshes in certain places. Sometimes, if we require a “mirrored” look we’ll reuse a mesh, and then set the scale to -1. This was before we really looked into rendering performance, and, unfortunately, it causes problems – a mesh with negative scaling can’t be batched with a mesh with positive scaling, so this ends up creating multiple draw calls. Rather than setting the scale of the object to -1, we simply import a new, mirrored mesh and update the object, allowing these draw calls to be batched and improving performance.

 

4-24-Stats.JPG

 

Stats

That’s it for the heavy-hitters; between the Profiler, Frame Debugger, and ADB, you should be able to get a pretty good idea of what’s going on in render-land. Unfortunately, digging through them can take a while – sometimes you just want a quick indicator of what’s going on in your scene. Enter the Stats window.

The Stats window (click “Stats” in the Game View) is a small overlay in the game view which gives you a quick rundown of various rendering indicators in real time. It’s not as in-depth, but it gives a much quicker picture of performance.

stats

That’s a lot of batches!

While it sounds like the stats window doesn’t add much – after all, the Profiler can give you the same information – I’ve found it to be very useful. The Profiler is probably better when you’re actively debugging rendering performance, but the stats window allows you to notice places where rendering performance might take a hit, even when you’re doing other things.

When I’m testing some other part of the game on my computer, I’m not going to notice any rendering lag, because my computer is so much more powerful than a phone. I’m also not going to be looking at the Profiler or Frame Debugger, because I’m not worrying about rendering at the moment. However, if I have the stats window open and I notice that the number of draw calls is in the hundreds, then I know something is going on. At that point I can get out the Profiler and see what’s happening – but I wouldn’t even have known there was anything amiss if it weren’t for the stats window.

 

4-24-SceneView.JPG

Scene View Draw Mode

As we get further and further down the list, we’re moving from “debugging all-star” to “it’s useful, but you probably won’t use it much”. Scene View Draw Modes fall into this category, but they’re still good to know about. You can access different Scene View Draw Modes by clicking the drop down menu at the top right of the scene view window.

The Scene View in Unity is one of the main windows that you use to make your game – it shows everything in the scene, allowing you to move around through the scene and select, move, rotate, scale, etc., any game objects. Usually the Scene View just displays the objects exactly as they would be displayed in the game. However, it has a bunch of other modes, and some of them are actually pretty useful. The two that I find the most useful when considering rendering concerns are listed below, although they’re all worth checking out:

Shaded Wireframe: This is my default draw mode, as it looks pretty similar to the normal shaded mode. The difference is that it also shows all of the triangles and vertices that you’re drawing. This is useful because certain shader operations are performed once for every vertex. Decreasing the number of vertices in your scene can give you a bit of a performance boost, and the shaded wireframe draw mode helps you see when you might have too many vertices.

3-4toomanytris

The shaded wireframe shows that there are too many polys.

Overdraw: This mode draws each object as a single transparent color. This makes it very easy to see when multiple objects are being drawn in the same spot on the screen. Since the GPU has to draw every pixel of each object (even if that pixel will be overwritten later), it ends up wasting some calculations. Areas that are very bright will waste even more calculations. Switching to this draw mode every so often lets you know if there are any places where you might want to remove some meshes.

 

161004-worst-hacks-history-feaure

The Internet!

It should pretty much go without saying, but one of your best resources for debugging performance is the internet. Unfortunately, when it comes to rendering in Unity, the information out there is pretty scarce. Unlike with normal imperative coding, where you can simply Google “how to pathfinding” and get 30 implementations, you have to work a bit harder with rendering stuff. I find it’s best to do what you can and only resort to the internet with very specific questions. That said, there is still a lot of helpful information out there. You just have to know going in that only one of every three stack overflow questions makes any sense, and only one of every four Unity forum threads are using the most recent APIs. It’s like “Googling: Nightmare Mode”!

For anyone reading this post who is actually working on rendering stuff – I’m very, very sorry. I hope that this post and the tools I discussed help to shed at least a little bit of light in the dark underworld that is shader-land, and I hope you can achieve your rendering goals and make it back to the mortal realm before your soul is forever lost.

For everyone else who hasn’t done any rendering stuff, I hope you learned a bit, and that maybe I inspired you to get involved with some rendering code! It’s really not that bad, I promise!

 

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

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.

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.

Show Prep!

For those of you who haven’t heard, Frank and I will be trekking down to Austin, Texas tomorrow to represent Where Shadows Slumber in South By Southwest’s Gamer’s Voice Awards! It’s a real honor to have been invited, and we’re super psyched to participate in one of the biggest media conferences in the world.

Of course, attending a show like this isn’t a walk in the park. There’s a lot of stuff we have to do to get ready for it, and that’s not even including the toll the show itself takes on us.

Since we’re going to SXSW tomorrow, last week was prep week. Let’s take a quick look at what that prep involves.

 

4-4-Fountain

 

Pre-Show: Game Prep

The whole point of these conventions is to show off Where Shadows Slumber, so one of the most important parts of preparing for the show is making sure we have a version of the game ready. One of the biggest surprises I’ve found is how much time and effort this takes. Since we’re actively working on making a game, you would think that we would be able to build and deploy it in a matter of minutes. However, this model of game development isn’t quite correct – having a game that’s 90% complete doesn’t mean we have a complete game with 90% as much content. Rather, it means that we have a game where most of its parts are 100% complete, and some of them haven’t even been started; we might even have a bunch of complete pieces that aren’t hooked up together.

Unfortunately, this means that show prep is quite time-consuming. It mostly comes down to the minutiae – we update the game’s build settings from “easy to develop” mode to “ready for production” mode. We have to change some configuration in order to bring only the levels we want. Small bugs or visual glitches are things we often ignore for the time being and revisit after level design and implementation is complete, but they have to be fixed for a show (even if they’re going to be changed again later). If we weren’t planning on implementing something (like menus), we may have to throw together a crude version just for the current show.

These annoying little time-wasters are one of the reasons we made the demo version of the game – no matter where we are in development, we can always simply bring the demo to a show, and know that it will work. However, as development has stretched out, we find that we don’t reap very much reward from showing the demo; people have already seen it, we’ve already heard all of the same feedback on it, and it doesn’t do a great job of showing how far Where Shadows Slumber has come. Especially for a big show like SXSW, we like to have a build of the game that has some recent work and shows off how awesome it can be, even if it does require jumping through a few more hoops.

After all of that, the only thing left is to actually build the game. This process is pretty easy for Android, and a little more complex for iOS, but it’s not too bad in either case. Then we actually test out the build on our devices, to ensure that users will get the best experience they can out of Where Shadows Slumber. If there are any bugs, then we have to go in, fix them, and build again. This is a much more time-consuming debugging process than usual, but, again, it’s usually worth it to get a chance to show off the most recent developments of the game.

 

20180313_130606

Buttons from Herb Ferman, dropcards from Moo, and Alba & Noah’s Phoz cards!

 

Pre-Show: Physical Prep

The most important part of showing off the game is the game itself, but that doesn’t mean there aren’t other things that need to be done. First and foremost, we need travel and lodging – a show isn’t much good if we’re not there for it! This is one of the reasons we go to a lot of shows in the northeast, but not too many elsewhere; we can often drive to Boston or Washington D.C., and sometimes we even know someone who lives nearby (and is willing to put up with us).

Another important factor in going to shows is actually being allowed to show Where Shadows Slumber at the show. This involves a lot of emailing back and forth with the convention runners, whether it’s them inviting us and us accepting, or us begging them to let us come.

Once we know where we’re staying and how we’re getting there, we have to figure out what else we’re going to bring. Most of this comes from a pretty stock list – we need devices to showcase on, computers to play videos, our banner, a tablecloth, foam floor padding, etc. On top of that, we like to bring business cards (above), and sometimes Where Shadows Slumber buttons. These can take some time to design, because we like to use very recent content from the game. After that, the only thing left is to coordinate between us when and where we’re going to meet, and it’s off to the show!

I should mention that most of the non-game prep that goes into these shows is done by Frank. He’s the one in charge of Game Revenant’s bankroll, so he ends doing anything that requires actually purchasing something. Which is pretty awesome, because I’m far too scatterbrained to handle organizing any of that stuff.

 

gaming_ma

The Show Itself!

I know this post is about the show prep, but I would be remiss if I failed to mention the show itself! The preparation is a lot of tedious stuff that makes us feel like we’re wasting time, but actually going to the show is the part that really exhausts us. We’ve spent a lot of time and effort making a great game to show people (both in terms of specific show prep and in general), so we end up spending 2-4 days showing it to literally every person we meet. And at a large convention, that usually ends up being several hundred people. We’re on our feet, talking, conversing, explaining, and schmoozing for pretty much the entire convention – it really takes it out of you!

All in all, show prep is a necessary evil. When you’re already spending most of your free time working on something, it’s really galling to have to spend even more time on more tedious parts of that project. But, once we get to the show, it quickly becomes clear that it’s all worth it. Frank and I are pretty used to Where Shadows Slumber at this point, but seeing the look on someone’s face when they realize what’s going on for the first time is a really great feeling. And knowing that we put in the work to bring the best possible version of the game to a show really helps us understand how people are going to react to the final game itself.

I should probably wrap this post up. Honestly, it’s shorter than most of my other posts, and probably not quite as good, but I don’t really have any time to make it better – I have to fix a bunch of bugs before we leave for South by Southwest tomorrow!

 

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

I hope you enjoyed a look at our pre-show process – if you have any questions about our con-going habits or anything else, we would love to hear from you (although we probably won’t get back to you until after SXSW). 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. And if you’re in Austin this weekend, make sure you come by our booth!

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

Menus

I’ve been talking a lot about less technical stuff recently. Let’s mix it up – today, I’m gonna talk all about the design and implementation of an important part of our game. If you couldn’t guess from the title, today we’re gonna talk about menus!

Design

Menus are a pretty important part of your game. Most people make a game and then just “slap” a menu down on top of it. Since the menu is the first thing users will see, it can be pretty make-or-break, so it seems like poor form to spend the least amount of time on it! That’s why it’s so important to actually put some thought into your menu design.

Early on, Frank and I decided that we wanted to have as little text in Where Shadows Slumber as possible. There were a number of reasons for this, the most obvious being:

  • We have to do less work to translate the game into other languages
  • It adds to the “mysterious” vibe we’ve been going for
  • The user isn’t burdened with a bunch of text they have to read
  • The text-based menus were possibly the worst part of SkyRunner (our previous game)

To go along with this choice, we also aimed to make the menus as transient as possible – rather than opening to a menu, where the player must choose to start playing, the game itself would just start playing immediately. That’s what the user is here for, after all! This “game-focused” menu model is an attempt to reduce the user’s barrier to entry, making it as easy as possible to actually start playing the game.

So what does that look like? Our menu design breaks down into four small parts:

  1. The first thing the user will see is the splash screen. This is just a quick little screen that shows the Where Shadows Slumber logo. It’s not really a menu, since it doesn’t do anything, but it’s worth mentioning (and it’s important for implementation purposes).
  2. Before starting a level, the user is met with a level title card. This tells the user what level they’re on, which provides important context, as it’s the only menu interaction they’ll have before they get to the game itself. After tapping through this menu, the user is dropped right into the game.
  3. During the game, the user can press the pause button, which will bring them to the pause menu. This is where most of the interaction is – you can restart the level, mess with the settings, etc. In order to move from “menu-focused” to “game-focused”, we’ve moved everything you would see in a “main menu” into the pause menu.
  4. The only exception to the “game-focused” menu design is our level select menu. Coming here will actually take you out of the game – but for good reason. This menu is by far the most complex, as the user can choose from any of our levels or cutscenes.

After textlessness and transience, a big driving force behind our menu design was incorporating game elements. For example, a quick description of our game’s mechanics might read like “things change when they’re in shadow”. So, wherever possible, we wanted to have a menu where things changed in shadow. The only place where we had the freedom to do something like this was in the level select menu. We thought about it a bit, and ended up with this beauty:

LevelSelect

This idea came up after about a million attempts at a menu design that showed off our mechanics a bit, but I think it was worth it. It’s pretty subtle, and uses a relatively standard swiping interaction.

Implementation

For those of you looking to make your own games, or just curious what our process was, lets take a look at how we actually brought these menus to life.

This is an area of development that really benefited from our three-phase process, in which we made a demo version of the game, and then started over when we began on the full game. This allowed us to iterate on our first approach to implementing the menus, without having to go through and update the existing menus. There are three interesting things that we did to create these menus.

Splash Screen and Pause Menu

In the demo version of the game, we created a pause menu prefab, and made an instance of it in each level. That way, we could update the prefab, and it would apply to every level. Seems pretty cool, right?

pausemenu

Because Where Shadows Slumber isn’t reflex-based, it can continue to play in the background!

While this is a pretty good pattern, and we’ve used it for a lot of other things, it didn’t really work for menus. The biggest reason for this was that we found ourselves going through every single level to update the individual menu objects with small, level-specific changes. While this might work for the demo, which only had ten levels, it’s a lot more work for the final game, which will have 38 levels.

Rather than have a menu object in each level, we decided to have a single menu object that persists throughout the entire game. After all, the menus themselves don’t change much from level to level. This is where the splash screen comes in – when the game loads up, the first scene is always the splash screen. This scene has the single menu object, and we simply tell Unity to allow it to persist from scene to scene (using DontDestroyOnLoad()). Any changes that need to be made to the overall menu text are made per level, as the level is loaded.

Level Title Cards and Translation

One part of the menu system that often gets overlooked during design is translation. For example, we decided to provide different languages for the demo, but we didn’t consider it or add it in until close to the release. This left us with a half-hearted translation system that was hard to update.

titlecard

I don’t think we need outside translators – my skills should suffice

The second time around, we decided to think about translation from the beginning of menu implementation, and we were determined to come up with something easy to work with. What we realized was that, for a foreign language, all text should be loaded from somewhere else – why should English be any different? Instead of creating an English menu and then applying translations, we started with an “empty” menu, and used our translation system to populate it with whatever language we wanted, English included! This forced us to take translation into account much earlier – so we can be much more sure that our translation system will work nicely with our menus.

But what does that translation system look like? Pretty much all of our other scripts are given values through the Unity editor. We did this for translation as well in the demo, and it was a complete disaster – even with our low-text menus, there was still a lot to add! We realized pretty quickly that we didn’t want to include the translations as part of the Unity scenes – we decided to have them loaded in separately, using JSON.

JSON, or JavaScript Object Notation, is a pretty cool file format used to organize values into a set structure. By storing all of our menu text (and translations of that text) in a JSON file, we can pretty easily read it into the game as it’s loading, thus allowing us to populate menu text objects with the correct language. It’s easy to read, easy to backup, and easy to update (unlike the Unity editor script fields), which makes it perfectly suited to this type of use-case.

json

A small sample of our JSON

The end process is pretty simple – when the game loads, parse the JSON file (which has all of the game’s text in “every” language). During the splash screen, where the menus are created, populate their text fields with the correct text from the JSON file. If we need to update the text, it’s as simple as changing the text in the JSON file, and everything just works!

The Level Select Menu

While the other subsections here describe ways that we learned from a bad implementation to make a good one, the level select menu is just a cool menu design.

Whille toying with menu ideas, Frank created a few of these “world tableaus”, and we knew that we wanted to have them in the level select menu. The coolest thing about them is that they aren’t just textures – they’re 3D scenes, which allows us to give them subtle movement (this kind of effect really helps make a game look “polished”). The question becomes – how can we display these scenes in such a way that they can interact with each other in two dimensions, while acting as completely separate scenes?

Unity has a pretty awesome feature called a RenderTexture, which allows a texture to display the live view of a Camera object (for the curious among you, that’s how you could make a CCTV screen or a mirror in a Unity game). Using a RenderTexture basically allows us to “flatten” the moving tableau scene into a moving texture, which we can then manipulate as we please. And, as it turns out, it pleases us to use math and angles to create the “sweeping shadow” effect.

You see, I’m a pretty big fan of math on the whole, and this was a perfect place to apply some trigonometry. Using complicated concepts (like “sinusoidal”, and “minus”), I came up with an algorithm that  would put two RenderTextures and a shadow triangle together in such a way that it created the desired effect:

Level Select Transition

theta = (3 * atan(h / 2x) – atan(h / (2 * (x + w)))) / 2

What you’re seeing here is that each RenderTexture is angled (and stretched appropriately), and then positioned in such a way that the line where they cross is exactly covered by the moving shadow. This gives the illusion of the menu behind the shadow magically changing from one image to the other.

This menu is my favorite part of the menu system, because it’s the most interesting, both from a technical, implementation perspective, and from an outside, aesthetic perspective. That said, I think we ended up with a pretty sweet menu system all around, thanks in no small part to our past failures in this area.

Looking Ahead

Unfortunately, no part of the game is ever really done. The menus are in pretty good shape, but there’s still some polish we need to do, and I’m sure there will be small changes we want to make as we move forward. In fact, this was one of the more important concepts behind a lot of our decisions – any changes we want to make should be pretty easy!

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

Hopefully you enjoyed this peek at the menus for Where Shadows Slumber! If you have any questions about our menus, 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.