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.




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!


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

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!



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.





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.


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.



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.


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.



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.

Easter: SXSW Feedback, Release Date, and More!

Hey everyone! We have a new Easter tradition at Game Revenant, where we go over some of the feedback Jack and I received when we were at the South By Southwest music festival earlier this month.

Overall, the reception to the game was really positive – but we’ve been trying to iterate quickly on some of the ideas you guys have been giving us. So without further ado, here’s the top three pieces of feedback we received at the show, and our responses!



Feedback #1: The Stakes Are Too Low

Jack and I envisioned Where Shadows Slumber as a relaxing puzzle game made in the mold of mobile classics like Monument ValleyLara Croft: GO, and Valley of War Adventure Run. Because of that, there are no enemies in the game, or any way for Obe (the protagonist) to die. We didn’t want you to have to restart a puzzle in the middle of a Level just because you couldn’t react to something in time. In the image above, this Walker won’t damage or hurt Obe because he’s just there to serve as an obstacle in the puzzle.

However, our fans have made their voices heard loud and clear: the stakes are too low in our game! There is no tension. There is no excitement. There needs to be violence. There needs to be a way for Obe to die. With precious few months of development time remaining, we are dedicating considerable resources to this piece of feedback. Our response?

Response #1: Obe Can Die In Terrible, Confusing Ways!

Now, thanks to some quick redesigning and a few late nights programming, Obe can die randomly in the middle of gameplay if he steps on Death Spikes. (Development name, subject to change) Here’s what they look like in-game:


“How will I ever get past this important intersection?”

One of our more controversial ideas is Secret Death Spikes. The idea is that they’ll be scattered all over the map, so the player doesn’t know where they are. Then, when a Player steps on one, Obe’s flesh is ripped apart and his head is sent flying:


That’s how they gecha…

We’ll push this build out to our internal testing group and see what they think! Now, you might be wondering what happens when you die. Philosophers have been trying to sort that one out for millennia! But in Where Shadows Slumber, you’ll lose one of your precious lives and restart the Level.

How do you get more lives? Read on!



Feedback #2: This Game Won’t Make Money

Jack and I also envisioned Where Shadows Slumber as a straight-up pay-once premium title that doesn’t utilize any exploitative monetization schemes to bilk people out of their hard earned cash. Our belief was that if we were very honest with the community, they would reward us by purchasing the game at a fair market price and leaving a positive review on the App Store.

The feedback from the community has been monolithic: don’t do this! Trusting people to seek out fair trades in the marketplace is a fool’s errand. People are morons! Obviously they’ll never pay for a thing when they could not pay for a not thing. It’s so obvious!

Response #2: Loot Boxes Will Make Money!

We’ve become convinced that the premium model is no longer viable, and that modified premium models (such as a try-before-you-buy model) are not viable either. The people have spoken: they want free games with micro-transactions, in-game advertisements, and timers! 2018 is here, and we dare not defy the calendar year.

“Our goal is to make sure people can pay enough money to basically not even have to play the game.”

For this reason, shiny loot boxes are being added into the game and Where Shadows Slumber is officially going free-to-play! Loot boxes can be earned in-game by logging in once per financial quarter, but they can also be purchased via the main menu if you’re in a hurry! Inside every shiny loot box, you’ll have a chance to get an array of dizzying prizes. Just look at all of the cosmetic skins you can equip Obe with:


Left to right: Classic Obe, Spanish Inquisition Obe, Breath of the Wild Obe, ISIS Obe

But we won’t stop at just cosmetic items. Loot boxes aren’t fun unless they have a satisfying, tangible effect on the virtual world. We’re partnering with Electronic Arts to bring their popular Star Card system from Star Wars: Battlefront II into Where Shadows Slumber! People just can’t stop talking about about about about about about about these Star Cards. That’s how fun & satisfying they are!


Actual percentages included above, pursuant to Line 3 of Section 15 of the Unlawful Internet Gambling Enforcement Act of 2006

Star Cards in Where Shadows Slumber will allow you to power up Obe to make him the incredible puzzle-action hero of your dreams. If you don’t get a Star Card from a loot box, don’t feel bad! You can use the colorful Shadow Dust you’ve stockpiled to upgrade your Star Cards. Powerups include running faster, more lives-per-day, auto-skipping Levels, auto-skipping cutscenes, auto-skipping the credits, and even giving Obe a gun during cutscenes!


“Go ahead. Make my day.”

Why lootboxes, you ask? Here’s a quote from Jackson H. Kelly, our Chief Monetization Officer: “Our goal is to make sure people can pay enough money to basically not even have to play the game. We want to take the stressful, mentally challenging experience of solving a puzzle, and turn that into a swift, painless transaction.”

When asked what could justify such a sudden change, he said “People like paying for things at a cash register more than they enjoy playing games, so we’re going to encourage that.”

EA could not be reached for a statement.



Feedback #3: Why Isn’t The Game Done Yet?

Jack and I also envisioned Where Shadows Slumber being released on the App Store and Google Play sometime during our lifetimes. However, due to the time constraints placed on this lil’ indie team (not to mention all of these exciting changes) we have not been able to get the game out the door just yet. However, fans are understandably frustrated. (see above) They want a release date to be announced! Today, I am proud to announce the date Where Shadows Slumber will be available for purchase on the App Store…

Answer #3: We’re Launching On Nov. 24th, 2067!

Just imagine. 2067. The “future” – at least, that’s what they used to call it. Now they just call it The Rinks. A beautiful array of orange cyber leaves crunch under your cyber boots as you walk down the idyllic cybewalk to the home you grew up in. Some punk kids skate by, chatting in a language that’s a mix of English, North Korean, and Blockchain. You walk through the front door (literally) to find your “family” huddled around a cyber television, tuned to the color of a dead sky. It’s Thanksgiving Day, 2067. What will you talk about with the androids that replaced your family? The ongoing war between Earth and Mars? The debate over the effectiveness of flying autonomous self-driving cars vs. self-automating driving flyers?

Never fear – there’s a brand new game available on the App Store called Where Shadows Slumber that you can download free of charge! Running on sleek, state-of-the-fifty-years-ago technology, Where Shadows Slumber is a free-to-play lootbox collecting game where one wrong move will rip the flesh from your cyber, cyber bones.* We hope you enjoy playing it as much as we enjoyed spending our entire lives creating it!

*Puzzles sold separately



Got More Feedback?

Jack and I are suckers for feedback. We just love hearing it! We just can’t get enough of your sweet, sweet, comments, haha, ha. My multiple chins and I are standing by, ready and willing to answer any and all emails, tweets, and creepy text messages you send me. Rest assured that if you contact Game Revenant with some feedback about Where Shadows Slumber, I will do my best to respond in 1-2 business years.

Thanks for reading this special edition of the blog, and Happy Easter by some strange coincidence!


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

Happy March 32nd, ya filthy animal. Our regular blog posts will resume on Tuesdays, as always. 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.

Help Us Test Where Shadows Slumber!

Hello everyone!

This week’s blog post is a quick announcement to let everyone know that the South By Southwest (SXSW) build of Where Shadows Slumber is available for testing. We brought 13 Levels to SXSW last weekend, and now you can play them on your phone!

(Do you want to join our open beta? Android users can sign up on their own by going to our Google Beta page. However, iOS users should email me at contact@GameRevenant.com to be added to our list!)



What’s New In This Build

If you tested our previous build, you played the first 13 Levels of the game. The Worlds we showed off were the Forest, the Jail, and the River – in that order! This time, we took the River out (I’ve been working on it all week) and replaced it with the City. The City is actually World 4, so if you notice a spike in difficulty, that’s why. Like last time, this build is 13 Levels, with the 5 City Levels at the end. The first 8 will be the same. Sorry about that! Testing isn’t all glitz and glamour – sometimes it’s about playing the same thing over and over again until you find every last bug.

The City World is really cool – as you can see in the images posted here, it’s an impoverished desert city under heavy guard. The shadows from Obe’s lantern cascade over crumbling walls and the silhouettes of soldiers as you make your way to a palace on top of the city. All the while, a sandstorm is raging and Obe’s clothing flaps furiously in the breeze.


There’s one more surprise – we have cutscene animations now! They don’t have sound just yet, so your phone isn’t broken. (Don’t put that in the survey, we know already!) You’ll see both cutscenes right after you beat the third Level. There’s two in a row, for story purposes. Sorry about that. This won’t happen too often, but sometimes the story requires a climax at the end of one World followed by a brief intro to another.

There won’t be too many more beta tests, so please take this opportunity to download the build and try it out before we remove it from the store. To prevent people from getting full copies of the game or getting the experience spoiled, we may not release the full game to our open beta audience. Please test it and give us your feedback!



“Which one of you is ‘Grongus’?”

What We’re Looking For

Please fill out the survey for this build! You can find it here, as a Google Form. Answer all of the required questions and as many of the optional ones as you have time for. We go through this feedback in detail as a time and it really helps us.

There are plenty of bugs we already found at SXSW, and we’re sure you’ll experience them too. Thanks for testing!

SURVEY LINK: https://goo.gl/forms/fkQHZBtnPnR8boWL2


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

Thanks for testing our game! Feel free to share your thoughts on the most recent build in the Comments section. 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.

How To Test Mobile Games

This article will be constantly kept up to date with the most relevant information you need to become a mobile BETA tester. (Last updated February 2nd, 2018)


Hello, and thank you for taking part in our beta testing program. This is the period of the development cycle where we are sharing our video game with the general public. This public test is intended to get feedback about our product in the months leading up to its final release.

Our testers come from all walks of life. We have people testing our game of many different career paths, ages, and backgrounds. We understand that not everyone is a super nerd! Some of this stuff is difficult if you’ve never done it before. Please follow this step-by-step guide to downloading our game. Thank you for your patience!

Send Frank an email at contact@GameRevenant.com if you need any help! You can also tweet @GameRevenant, or contact us on Facebook at fb.com/GameRevenant.



First, what kind of phone do you have? Scroll down to the section below that describes your device: we support Apple and Android.



Apple (iPhone or iPad)

Apple’s policies require that everyone receives a direct email invitation to test the game. That means you must have already been on our email list in order to test the Apple version. If you were not already on our list, reach out to Frank at contact@GameRevenant.com and you’ll be added.

Otherwise, proceed to these steps:

  1. An email will appear in your Inbox that says “Game Revenant has invited you to test “Where Shadows Slumber” – open it on your mobile device.
  2. Press the large blue button that says “View in TestFlight.”
  3. An invitation will appear that tells you to get TestFlight from the App Store and gives you a code to redeem. Follow those steps. Don’t worry, TestFlight is free.
  4. Now that you have the TestFlight app on your device, and the code has been redeemed, open TestFlight. Press the green Install button.
  5. The game will now take a few minutes to install.
  6. Once installed, the button will now be blue and say Open. Press it.
  7. Play the game and enjoy!

Don’t forget to fill out our survey!




Android (Google, Samsung, etc)

  1. On your Android device, click this link.
  2. (Alternatively, search Where Shadows Slumber on the Google Play Store on your Android device, and select the one that says BETA in red text)
  3. Now press the green Install button above the pictures.
  4. After the game has been downloaded to your phone, find it and tap it to open it.
  5. Play the game and enjoy!

Don’t forget to fill out our survey!



The Most Important Part: The Survey

Thank you for your patience. We hope you enjoyed playing the game! Now, the most important part: open this Google Survey in your Internet browser and answer all of the questions there. We won’t ask for anything incredibly personal, so just give us your candid feedback about the game.

Your feedback will change the outcome of the final game. Thanks for taking part in our beta test!


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

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.

Frank DiCola is the founder of Game Revenant and the artist for Where Shadows Slumber.

Join The Conversation

Everyone has an opinion on everything. If that’s true, then why is it so hard to get people to talk to us about Where Shadows Slumber?



My name is Frank DiCola, and along with my friend Jack Kelly we’ve been maintaining this blog and developing our game Where Shadows Slumber together for a while now. The game is launching soon, but we’re not announcing a specific release date to the public yet. Regardless, now is the perfect time to get feedback on our game. We’re “landing the plane,” so to speak.

It’s too late for broad sweeping changes, but now is the perfect time for you to nitpick all of the tiny details in our game. If you tell us to fix it, we’ll fix it before we launch the game on the App Store – and that might save us from getting a negative review from someone else who notices the same problem!

If you tested the game at any point during the last year, you probably heard us wave away from criticism because we’d “handle it later.” Well, now is later! We appreciate your broad feedback then, and we could really use your specific feedback now.

OK, now that I convinced you to join our fan club, let’s talk about how you can join the conversation! This blog post is dedicated to discussing the various channels we’ve setup for feedback. No matter where you make your home on social media, there’s an avenue for you to use to contact us!



The Game Revenant Discord Channel

This one is pretty recent. If you have the app Discord on your computer or phone you can join our public channel. We’re still getting in the habit of posting screenshots, videos, and blog posts in the chat. But we’ll use it more if more people join!

Link to the Game Revenant Discord Channel: (link)


Discord’s chat system, as we discuss how best to decorate one of the game’s Levels.

I plan to use this Discord for future projects even after Where Shadows Slumber launches, but it’s safe to say that this will be dedicated to this game for at least the next two years or so. Feel free to join or leave anytime, just be sure to introduce yourself when you jump in the chat! Obviously, I retain the right to kick you out if you’re being rude to the other people in the chat. But I promise not to remove anyone for criticizing our game – that’s the whole point! It’s hard to offend me and Jack, so don’t worry about that.

Although Discord supports voice chat, we usually just use the text chat. A voice consultation in a private channel with Frank is available upon request.



Facebook: The Chamber of Judgment

We’ve had this private Facebook group up and running for a while, but it’s difficult to get in the habit of posting to it. We haven’t quite hit the critical mass of people yet needed for this to work. So, join the conversation!

Link to the Chamber of Judgment Facebook Group: (link)

Similar to Discord, this is a space dedicated purely to discussing the game and giving feedback to developers. Anyone with Facebook can join for free! If you live on Facebook, this is the best way to give us feedback.



Cartrdge, an Artistic Community

Our Cartrdge page is one of the online communities where we have the least control over the conversation, but we’d still appreciate it if you check it out! Yes, I spelled that right. Cartrdge is a super cool website for game artists to post their work. You’ll find everything there from super awesome shaders to physics demos to entire voxel cities.

Link to the Where Shadows Slumber Cartrdge Project Page: (link)

I love scrolling through the home page there just to see what everyone’s working on. It’s one of the best designed portfolio websites I’ve seen, and we’ve been selected by their Editors once or twice so far. You can also leave comments on posts, so make an account with them and be on the lookout for our stuff. Give each one a Like and then share your opinion with us!



Roast My Game

This poor website seems to be on its last legs. But the concept is so genius, I wish it would stick around. It’s a website for indie developers to post their projects, get feedback, and climb the Leaderboard to the top! You should sign up there and give them a morale boost. They explain the concept better than I could:

“One of the biggest problems that a game dev faces as they create a game is gaining a sort of “mothers love” for their game. This prevents them from being able to properly determine its flaws. Friends and family members tend to sugarcoat their feedback to avoid from being discouraging but this actually harms more than it helps. Roast My Game is a site created to help game developers gather ‘sugarfree’ feedback on games they are working on and to inspire other game developers by sharing development progress. [emphasis theirs]

Link to our Roast My Game page: (link)


A typical comment in response to our Demo, and a reasonable reply in progress.

We posted our Demo to that site last year and got some good feedback. Tragically, there just aren’t enough people using Roast My Game. My suspicion is that everyone on there is like me – they want feedback, but they don’t want to play other people’s indie games. Too bad!



“Ceiling… what are YOU doing here?”

What Did We Miss?

This is super important so I’ll close with this – what have we missed so far? Are you angry that there is no Where Shadows Slumber Subreddit? Perhaps you feel like we’re neglecting TouchArcade, Instagram, Pinterest, or some other online community you love?

I’ll be pretty frank here (ayyy) and just let you know that if there’s a guaranteed community out there, we’ll come to you. I know nothing about Pinterest. But if you know of 1,000 people out there who love indie games and would boost us on Pinterest, I will learn and become the Pinterest master. We don’t care, we just want to promote the game and get honest feedback from you before our game hits the cruel, unforgiving free market.

Leave a Reply under this post with a community you’d like to see us join. We hope to see you on the interwebs!


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

Hey! Join the conversation using the links above this. What are you doing reading this blurb? 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.

Hacks Versus Designs

I remember back in the day, when computers and programming were first becoming somewhat ‘cool’. Back then, the coolest thing you could be in the computing world was a ‘hacker’. Hackers were awesome renegades who could tear down opposing systems using nothing but their superior intellect. Being able to hack was one of the best skills you could have. Now, after studying and working in computer science for a while, the term ‘hack’ has taken on a very negative connotation.

When you’re writing code, there are several things that you’re aiming for. The two broadest and most important of these are:

  1. The code works – it does what you intend for it to do.
  2. The code is good – it’s efficient, understandable, and easy to use/improve.

It seems like these two things would go hand-in-hand, and for well-designed code, that is often the case. However, the road to that ‘well-designed’ code is often fraught with terrible, terrible code. So, what’s the intrinsic difference between these two goals, and how does it lead to bad code?



Hack First, Ask Questions Later

When you’re working on a large, intricate system, and you need to add something or make a change, these two goals lead to two different types of results – a hack, or a design:

  • A hack is a piece of code with only the first goal in mind – you’re just trying to ‘make it work’. You don’t want to put a lot of thought or time into the implementation, you just want it to work.
  • A design has both goals in mind – you’re spending time to come up with a good solution. You’re willing to work a little harder to end up with a more robust, long-loving solution.

Designing a solution to a task leaves you with good code. It’s easy to understand, easy to use, and easy to update. The algorithm makes sense, not just in terms of “does it do what I want”, but also in terms of “does it make sense with the theory behind it”.

Looking at these two descriptions, it’s pretty easy to see – designs are better than hacks. So why would anyone ever want to use a hack to get something done? There are a few reasons.

Designs take more time. You have to come up with a solution, consider its long-term viability, consider how it will interact with every part of your system, present and future, tweak it accordingly, and make sure that it still matches the theory of your application. A hack, on the other hand, involves simply coming up with a quick and dirty solution, and implementing it.

Designs require deeper understanding. In order to fully understand the impact of your newly-designed code, you have to completely understand the current state of your application, remember all of the assumptions you made when coding it, and ensure that your new stuff won’t interfere with any existing stuff (Note that this is much harder to do on a larger team, as there are areas of the code you may not be as familiar with).

Designs are often much larger in scope. When designing a solution, it will often involve creating a ‘system’ or ‘engine’ of sorts. Not only does this take longer to think through and implement, but it also opens the door to a lot of subtle interactions between systems. Hacks are (usually) much more localized – “I’m gonna make this hack here, but I won’t use it in other places”.

You don’t want to spend a lot of effort on code that will be replaced eventually. This is really just a combination of the above points, but it’s an important reason why hacks exist. If you have to update a small piece of code, but you know that you’re going to come in and change the whole thing next month anyways, why would you put a lot of time and effort into designing a solution when a quick, hacky fix will do the trick?

Looks about right Cropped

This is what happens when you leave hacks in your code!


Here’s An Example

Let’s say you’re you’re working on a pretty simple game in a pretty simple game engine, using a pretty simple programming language (hint: this means I’ll be using pseudo-code rather than real code). You’ve got your character on the screen, and you want to make him move back and forth along some flat ground whenever you hit an arrow key. You might start out with something like this:

if (keys.leftArrow) {
  dudeGuy.position.x -= 10;

if (keys.rightArrow) {
  dudeGuy.position.x += 10;

Pretty simple and straightforward – if you’re pressing the left arrow key, move your dudeGuy to the left, and if you’re pressing the right arrow key, move him to the right.

So, you use this code for your movement, and it works, and you continue working on your game. Then, suddenly, you have an epiphany – what if your dudeGuy could jump? You add a variable and hook it up:

int jumpingTimer = 0;


if (keys.spaceBar && jumpingTimer == 0) {
  dudeGuy.position.y += 30;
  jumpingTimer = 3;

if (jumpingTimer > 0) {
  dudeGuy.position.y -= 10;

As you continue making your game, you design some levels where you realize that you want the gravity to be less strong, so you have to account for that:

float gravity = 10;


if (keys.spaceBar && jumpingTImer == 0) {
  dudeGuy.position.y += 30;
  jumpingTimer = 30 / gravity;

if (jumpingTimer > 0) {
  dudeGuy.position.y -= gravity;

Then you realize that your back-and-forth movement looks pretty choppy, so you decide to add some ‘smoothing’, so your dudeGuy speeds up and slows down:

int movingLeftTimer = 0;
int movingRightTimer = 0;
int jumpingUpTimer = 0;
int jumpingTimer = 0;
float gravity = 10;


if (keys.leftArrow) {
  if (movingLeftTimer < 3) {
} else if (movingLeftTimer > 0) {

if (movingLeftTimer > 0) {
  dudeGuy.position.x -= 10 / (4 - movingLeftTimer);

if (keys.rightArrow) {
  if (movingRightTimer < 3) {
} else if (movingRightTimer > 0) {

if (movingRightTimer > 0) {
  dudeGuy.position.x += 10 / (4 - movingRightTimer);

if (keys.spaceBar && jumpingTimer == 0) {
 dudeGuy.position.y += 30;
 jumpingTimer = 30 / gravity;

if (jumpingTimer > 0) {
 dudeGuy.position.y -= gravity;

And,  before you know it, with only a few changes to what we were trying to do, we end up with a piece of code that’s incredibly messy, almost impossible to understand, and prone to bugs and off-by-one errors. Honestly, I just wrote this thing, and I have no idea what it’s supposed to be doing.

Now, this example is a bit of an esoteric one, just to prove a point. However, it is definitely not the worst code I’ve ever seen (or written), and that’s saying something. What should we have written instead? Well, if you couldn’t guess, the above code is an example of a hack (or a number of hacks put together). Rather than examining what it was we needed in the long run, we repeatedly implemented something that did the job in the short term. So, let’s make a design for this use-case, and think about what we need overall.

We want to be able to move left/right, jump, have different values for gravity, and have smoothing on our movement. This sounds a bit like actual physics, so lets steal some important concepts from them – acceleration and deceleration. We’ll determine some rules that match our design, modify the dudeGuy’s acceleration in each direction based on those rules, and then move his position all at once:

float maxSpeed = 10;
float acceleration = 3;
float jumpAcceleration = 10;
float gravity = 3;
float friction = 5;
float minY = 0;

float vx = 0;
float vy = 0;


// If the left arrow key is down, accelerate to the left
if (keys.leftArrow) {
  vx -= acceleration;

// If the right arrow key is down, accelerate to the right
if (keys.rightArrow) {
  vx += acceleration;

// If the spacebar is down and the dudeGuy is on the ground, accelerate upwards
if (keys.spaceBar && dudeGuy.position.y == minY) {
  vy += jumpAcceleration;

// Accelerate downwards for gravity
vy -= gravity;

// Decelerate for friction
if (vx > 0) {
  vx -= friction;
} else if (vx < 0) {
  vx += friction;

// If we're going to fast to the right, slow us down to the max speed
if (vx > maxSpeed) {
  vx = maxSpeed;

// If we're going to fast to the left, slow us down to the max speed
if (vx < -maxSpeed) {
  vx = -maxSpeed;

// Update the dudeGuy's position based on our current velocity in each direction
dudeGuy.position.x += vx;
dudeGuy.position.y += vy;

// If the dudeGuy is below the ground, move him up to ground level
if (dudeGuy.position.y < minY) {
  dudeGuy.position.y = minY;
  vy = 0;

While we have a similar number of lines of code here, it’s much clearer what’s happening on each line. Every block serves an easy-to-understand purpose, and making changes to the ‘rules’ of movement is very easy. There are a lot of different ways to improve this code, depending on your game’s overall design, but this is a decent, and most importantly simple, place to start.

Another important feature of this piece of code is that it is well documented. Every block is pretty small, but it still has a comment describing the purpose of the block. This is an extremely important part of programming in the context of larger systems – you want to make sure that you (or anyone else) can quickly understand what your code is doing, especially in complex cases. Even though some complex logic might seem simple to you, it’ll definitely seem more difficult when you come back to it in 6 months!


A Necessary Evil

Unfortunately, hacks are a necessary evil. While I would love to only ever have to deal with and implement beautifully-designed code, that world doesn’t exist. There’s always a timeline, there are always changing assumptions and new features, and there’s always someone who wants it to be finished yesterday. Inevitably, you’re going to have to write some code quickly, implement a feature that’s likely to change, or come up with a simple ‘solution’ to a difficult problem. In cases like this, you’re forced to use a hack.


I mean, it works… technically…

It’s not all bad, though. While hacks in general are pretty bad, they can be manageable if you make sure to use them correctly. In fact, I would be willing to bet that any system currently in production (of a certain size) contains quite a few hacks. There are certain qualities that hacks can have which make them a little bit more manageable, and you should try to aim for them whenever you find yourself implementing a hack:

  • Understandable – It’s important that, whatever your hack is, anyone else looking at the code can understand what you were trying to do, and how your hack works. This means leaving a lot of comments around your hack, as well as simplifying the logic as much as possible.
  • Localized – If you have to hack something in, you want it to only be in one place. Every time that code path is used, there’s a chance that something will go wrong. If your hack only touches a small part of your system, then its negative effects will be much less noticeable. This means that frequently-used code paths should never really have hacks in them, while hacks in rarely-used code paths are more acceptable.
  • Known – This is, to me, the most important part of making a hack. If you hack something in and then forget about it, when your system starts failing, you won’t know where to look. If you make sure you remember it (by writing it down somewhere and then telling every person you know), then you’ll know where to look if something goes wrong. On top of that, you’ll always have that hack in the back of your mind, so you’ll be more likely to think of a good design to replace it.

If you follow these guidelines and make sure to try to go back and fix them, then putting hacks into your code won’t end up destroying you.

I hope this was helpful to those of you just starting out in game development – or anything which involves designing complex systems! For those of you who already know a little something about computer science, I hope this at least reinforced your burning hatred of hacks!


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

If you want to know more about how to deal with hacky code, or what kind of hacks are in Where Shadows Slumber so that you can exploit them, 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.

Level Design

We’ve put a lot of work into designing, building, and testing our levels. In particular, now that we’ve got a lot of the other pieces in place and a good amount of user-testing done, we’ve been focusing quite a bit on level design. After all, as a puzzle game, the most important part of our gameplay is the puzzles themselves. An incredible game can end up flopping due to bad puzzle design, and a mediocre one can actually do really well, if the level design is good.

But how does level design actually happen? We have a bunch of levels, but how did we come up with them? What’s the process?


Design Process

4-3 design

Design of an upcoming level, Fountain!

The problem with level design is that it’s an inherently creative endeavor. I’ve always had trouble with this type of task – if I sit down and work on something for an hour, I want to see some measurable progress. But if I try to work on level design for an hour, I could literally just be sitting there thinking the whole time, with nothing to show for it. This (at least for me) is one of the reasons that level design often gets pushed to the proverbial back burner. I always want to work on game features, because I know I can make some progress on them, so I opt to do that rather than level design. However, this can be a dangerous prospect, as this is a great way to end up scrambling for levels, putting too little thought into their design, and releasing a great game with bad puzzles.

You can’t just say “I’m gonna go design a level!” I mean, you can (and sometimes I do), but that’s not the best way to go about it. Unfortunately, you’re really at the whim of your own brain – you have to be struck with inspiration. The best levels I’ve designed didn’t happen during a ‘level-designing brainstorm’. They happened when I was walking down the street, or sitting down at dinner, or pretty much anywhere, when I noticed something that made me think of a cool level. Inspiration isn’t something you can schedule, work hard at, and then just do. It has to come to you, which, for me at least, is terribly annoying.


Designing for Where Shadows Slumber

All of this gets even more difficult when it comes to designing puzzles specifically for Where Shadows Slumber. Any innovative puzzle game has a sort of quirky concept, a hook to get users to take notice and to make the puzzles more unique and interesting. For us, of course, it’s the shadows and the ever-changing nature of the world, and those aspects of the game are what make it the hardest to design for.

So you sit down and design a level. It looks pretty cool, it’s got a nice flow, it seems challenging and fun. You show it to your team, or you start to implement it, and suddenly you realize – it just doesn’t work. There’s one small thing that prevents the level from working, whether it be a light in the wrong place, an object that should cast shadows but can’t, or maybe it’s just too difficult for a user to get. These aren’t great examples, but this type of situation comes up all the time. We designed around 30 levels for Where Shadows Slumber at the beginning of the year, and now we only have around 15. What happened to the other half? There was something small that prevented them from being good levels – and it’s hard to notice any of these issues until you implement the level and test it out.

The other difficult part of designing these intricate levels is actually communicating them to each other. Every level design, no matter how great, needs to withstand the feedback of its peers. The problem is – how can we show these crazy levels to each other?


Notice how my drawing style is a more clinical, overhead view than Frank’s (above)

We’ve tried drawing them and sending them to each other, but they’re often too intricate to really ‘get’ from a drawing. In the end, the only process we’ve found for sharing levels is to sit down in the same room together and talk through what the level consists of, along with the drawings. Even this isn’t good enough for a lot of the more complex levels – sometimes the only way to show your team the level is to build it! This is very frustrating, especially when you build a level that’s no good, and you have to throw it out, but sometimes it’s a necessary part of the process.


Taking the User into Account

Of course, the real judge of level design is the user. It doesn’t matter if every one of your levels is a masterful blend of elegant design and game mechanics if your users don’t enjoy playing it. This is a pitfall that I continually see people falling into, and, as I recently realized, one in which I lived for a good portion of the development of Where Shadows Slumber. But no longer! Throughout our testing, the users have spoken, and we are listening!


Getting some feedback on level design!

What does it meant to design for the user? How do we know what they will and won’t like? That’s a difficult question without an easy answer, but I will share some of the tips that I try to stick to.

Listen to your users. This should be obvious, but sometimes it’s not. You have to get your game in the users’ hands, get them playing the game, hear their feedback, and actually listen to it! You’ll never know that users don’t like one of your levels unless you let them test it out, and your level design won’t be good if you disregard their feedback.

Difficulty/learning curve. If your game has a crazy mechanic or concept, the user isn’t going to know how it works – it might seem intuitive to you, but that’s because you’ve been working on the game for so long! You have to make sure that you gently introduce them to the mechanic, in a way that shows how it works while also keeping them hooked. And you have to make sure the difficulty ramps up before too long, or they’ll just get bored of your everlasting tutorial.

Remember that the user doesn’t know what you know. Some people phrase this rule as “treat the user like they’re stupid”, but I think that’s an overstatement. Your users aren’t stupid, they just don’t understand the subtleties of your game the same way you do. They will never do exactly what you expect, and they will never understand the level as well as you do. You need to keep that in mind, examine your level design with an objective eye, and make sure that the experience is enjoyable for the user no matter how they go about solving your puzzles.

Users want to feel smart. The people who pick up and play a puzzle game are usually pretty smart people, and they want to feel smart. This leads to an important design philosophy – make your levels hard, but not too hard. The user doesn’t want to just play an endless parade of easy levels – they won’t feel any satisfaction from beating them. On the other hand, the user doesn’t want to hit a near-impossible level – that’s just frustrating! Beating a level should be easy enough that your users will beat it without getting frustrated, but hard enough that they feel accomplished when they do.

Iterate and Re-use. Sometimes, your users won’t like a level – it happens. In this case, you shouldn’t simply throw the level out. An important part of design is iteration – if your users don’t like a level, figure out why. Figure out what you can do to improve the level. There are parts they don’t like, that you’ll probably end up taking out, but there are most likely some good things about the level, and you don’t want to waste them. Try to fix what the users disliked, and then head back to them and get another opinion.


If I Had to Skimp on Level Design…

Creating a game takes a long time, and there’s a lot to do. Sometimes, you just don’t have the time to pour your heart and soul into every level you design. Sometimes, you just have to put in a few ‘filler’ levels. When is it okay to do that, and what’s the best way to go about doing it?


“Okay, hear me out: we open on a completely blank screen…”


As much as I’d like to say “all levels are created equal”, I can’t, because it’s not true. Frankly, there are some levels that are a lot more important than others. Which levels are most important? The early ones.

One of the biggest hurdles for a game is what I call the barrier to entry. If I pick up a new game, and the second level is really annoying, there’s a chance I’ll just put it down and never play it again, even if the rest of the game is phenomenal – I have no way of knowing that, and I assume the rest will be just as annoying. However, if I play the exact same game, but it’s the seventh level that’s really annoying, I’ve already played through six awesome levels. The game has earned some credit with me, so I’m willing to let one annoying level slide.

This is doubly true for puzzle games where the user has to learn the mechanics. If you don’t teach the user your mechanics very well in the first few levels, they’re not going to enjoy the rest of the game, because they won’t have learned how to solve the puzzles.

The third argument for this is simply a mathematical one. Every user who plays your game will play the first level. No matter how good your game is, there’s some rate of falloff – some people just stop playing. That means that almost every user plays level two, and most users play level three, and so on. So, the levels that will see the most playtime overall are the first levels, hands down (for any statistics nerds out there, this is basically the same premise as Benford’s Law).

So, if you’re running out of time for level design and you need to skimp on some levels, you should make it levels later in the game. Anyone who has gotten that far already likes the game (presumably), so you don’t need to sell it to them, and they’ll give you a little more leeway.

Now that we’ve tested some of our levels, we’re ramping up into more level design, and I though it would be a good opportunity to show you a little bit of our process. Hopefully you learned something about our level design process, and maybe you can even use it in your own projects!


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

If you have questions about our game design process, feel free to contact us! You can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebook, itch.io, or Twitch, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

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