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!

 

AprilFools-LowStakes.png

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:

AprilFools-Spikes.png

“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:

AprilFoolsDEATH.gif

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!

 

AprilFools-Money.jpg

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:

AprilFools-Skins.png

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!

AprilFools-Odds.png

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!

AprilFools-Gun.png

“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.

 

AprilFools-WaitingMark.png

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

 

AprilFools-Phone

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!)

 

SXSW-Out-Header

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.

SXSW-Out-Slum.png

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!

 

SXSW-Escape.png

“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.

 

iphone-x-unboxing-09

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!

 

 

istock-495277951-58de67055f9b584683605c93

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!

 

survey-stock-photo

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!

 

maxresdefault

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)

Blog-DiscordPic.PNG

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.

 

FacebookCover-ChamberOfJudgment

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.

 

logo_primary

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!

 

Blog-RMGPic.PNG

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)

Blog-RMG.PNG

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!

 

20171212_133505

“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?

 

boolean

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;
  jumpingTimer--;
}

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;
  jumpingTimer--;
}

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) {
    movingLeftTimer++;
  }
} else if (movingLeftTimer > 0) {
  movingLeftTimer--;
}

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

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

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;
 jumpingTimer--;
}

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.

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?

IMAG0625

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!

feedback

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?

20170627_124251

“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.

What We Learned From Testing At AwesomeCon 2017

Hey everybody, it’s Frank! I just got back from a trip to Washington D.C. for AwesomeCon 2017, a comic convention that’s expanding its selection of gaming exhibits. We were invited by the wonderful team that hosts the MAGFest Indie Videogame Showcase to take part in their giant indie booth – thanks to Lexi Urell and her team for allowing us to take part in such an awesome con!

 

20170617_211819

Why Did Frank Go To AwesomeCon?

That’s kind of a weird question, right? Is there ever a reason not to go to a convention? Besides, we were invited! Do you even need to ask?

Now that the Game Revenant official coffers are looking a little emptier, it’s important to evaluate every large expense. Travel is certainly one of them. While I’d love to go to every show on planet Earth that’s even remotely related to gaming, we don’t have that kind of cash to spend. Besides that, there’s the time cost involved. If I’m standing at a table showing off Where Shadows Slumber for 3 days straight, that’s 3 days I’m not spending doing animations or environment art for the game. Was it worth it?

We decided that the best way to get a return-on-investment for our time and money was to focus on one very specific thing during AwesomeCon 2017 – testing. Conventions are a great way to show your game to a lot of people. It may seem like this is purely a marketing activity where indies promote their game, but that’s a shallow view of what conventions can do for you. When you’re given the opportunity to sit down with nearly 100 people and focus on your game, that’s a great time to ask them critical questions about your work and get their honest feedback.

So before I left, Jack created a build of our Where Shadows Slumber alpha that had all 17 of our test Levels in it, along with a basic menu for easy navigation. I resolved to show this early alpha to as many people as possible, with a specific focus on these key issues:

  1. If I don’t tell Players how to play the game, what will they do?
  2. What do Players think of the first three Levels, which are meant as a tutorial?
  3. How far will Players go before they get stuck or bored?

 

20170616_182723

My Testing Procedure This Time Around

As you test your game at a convention, you begin to find a consistent testing method that works. Halfway through the first day (Friday), I had a pitch ready to go once people sat down at the Where Shadows Slumber table.

I was really straightforward with people. I told them that I wasn’t going to teach them how to play because I wanted to see how they performed on their own. (No one seemed to mind!) Then I told them that they could ask me questions if they got really stuck. I told them that the game’s artwork was a placeholder. The only information they were allowed to know was that it was a puzzle game called Where Shadows Slumber. With that, I just watched them play through Level 0-1 and noted their progress. This pitch accomplished a few key things.

This Is Only A Test: Setting up expectations right away is key. By telling people that the game is being tested (and not them) it put them in the proper mindset. They weren’t here to be entertained – they were here to break the game if possible, and try to beat it. I think that increased people’s enjoyment actually, and definitely led to finding some serious bugs.

Ask Me Questions: Getting people to talk while they play is really hard, but it’s very important. You can only glean so much from watching people. I didn’t give anyone that much information, but allowing them to ask questions is helpful. After all, if they ask a question, it means they don’t understand something. That “something” is what Jack and I have to go back and add to our tutorial.

Don’t Tell Me The Art Sucks: It’s important that you tell people what you don’t want to hear. Setting up this expectation decreased the amount of people who would complain about the art. Seeing this alpha next to screenshots of our beautiful demo was probably  a bit jarring, but once I explained it to testers it wasn’t an issue anymore. When you’re testing, you don’t have much time with each person so you need to make it count. Make sure that people know what you already know, so they focus on different issues.

 

20170616_173920

The Results

To my surprise, people loved the alpha! I only say I am surprised because this is the first time I’ve seen people play it with my own eyes. And although the artwork is all just placeholders and the Levels are brand new, people gave it glowing reviews:

Thor

Having said that, not everything is sunshine and rainbows. We found a few bugs over the weekend, and there are some Levels that may need to be redesigned or cut from the game entirely. Here are all my notes from AwesomeCon 2017:

 

  • People don’t realize they can’t drag something if the Player is in the way. Draggable objects should smack into the protagonist to give them feedback on this matter.
  • Someone suggested a mechanic where torches (lights) are only on for a fixed amount of time before they shut off.
  • Someone requested a Reset button (which our demo has, but the alpha does not – even though you can just re-select the current Level from the menu).
  • MAJOR ISSUE: People didn’t realize they could drag red objects. Many suggested that they “shimmer” when they are dormant to encourage dragging. Perhaps there should be a handle on the Draggable object to indicate that it is interactive, and show the direction it moves. They should glow when they are being dragged as well.
  • Someone suggested a UI indicator that shows how a Draggable moves, since some objects rotate but others slide across the floor.
  • When the Player is following closely behind a Walker, he stutters and stops, producing an awkward floating animation.
  • The protagonist’s light should grow out from him and stop at the predetermined radius needed to solve this Level.
  • MAJOR ISSUE: Every single Player (with few exceptions) dragged-to-move if I didn’t tell them the controls. Our game is tap-to-move, so dragging is not an optimal way to play. People assume the controls are bad, but they’re just doing it wrong. Without a way to correct them, they make it harder on themselves.
  • Someone suggested charting a path (like in StarCraft) when you drag-to-move, a possible solution to those who find that way more comfortable. This would basically be like connecting the dots between every space you dragged over.
  • IDEA FOR A LEVEL: Level 1-3’s “Lock”, but the Light Switches are connected to some of the Rotating Draggable blocks.
  • MAJOR ISSUE: People tried to drag the purple blocks, but couldn’t. This stopped them from trying things in the future.
  • Glyphs are really just buttons that can be pressed infinite times, right?
  • Draggable Light Switches need to be turned off when they’re off. They still appear on, which is impairing people’s understanding of the light mechanic.
  • The age when players seem able to understand the game is 12 – younger children could trudge through it by trial and error, but with limited understanding.
  • MAJOR ISSUE: “Why is there a shadow?” People do not realize the main character has a lantern with a massive radius and it’s the only light in the scene. This is understandable because our game is super weird. We need to find a way to show this constantly, or they’ll think the shadows have a mind of their own.
  • Someone suggested a mechanic where the main character’s lantern is a spotlight, instead of a point light, for a few Levels.
  • Someone suggested a mechanic where the main character can lower their lantern’s light radius and then reset it, for a few Levels.
  • A businesswoman with knowledge of the Indian market suggested that we lower the price from $5 for that particular market. She felt strongly that Indian mobile gamers wanted free games or something much cheaper.

Here are my notes that are specific to each Level in the alpha.

 

0-1.PNG

Level 0-1, Fallen

There’s a bug in this level where there bridge (which should fall after you press a trigger) stays exactly where it is. Players who drag-to-move skip right over the trigger, and they never trigger the bridge sequence, so basically they miss the puzzle.

The Draggable box on this level doesn’t have much weight to it. People fling it around like crazy. They also really want to drag it down (onto the dirt path), up (onto the dirt path), or onto the bridge to drop it into the water as a makeshift bridge. None of that is possible but there’s no feedback for that and they don’t know how shadows work yet so it doesn’t register.

Half of the people who play this Level don’t quite understand that the shadow makes the bridge appear.

It’s possible to walk past the Goal Space, and go to a spot on the Level that is beyond the door.

This level is not idiot-proof, like the first Level in our demo.

I think this is our weakest Level. I suggest cutting it and replacing it with a walking tutorial similar to the first Level in the demo. This Level is just throwing way too much at Players all at once.

 

0-2

Level 0-2, Bridge

An excellent Level. This serves as a perfect introduction to 3 key mechanics: walking, shadow revelation, and dragging.

The Rotatable bridges here should probably wobble after a while to indicate they can be dragged. I can also make a circular pivot point in the center, cut into the stone. That would be a good indication that these are on a swivel.

Draggables can also have parts on them that suck in when Players hold them down. Having parts of the stone depress inward is a good sign that you’re controlling the object with your finger.

 

0-3.PNG

Level 0-3, Monolith

This Level is perfect teaching. It’s a great gateway – you will never beat this if you do not understand how shadows work in our game.

“The purple box moved!” We need to make sure people don’t think the shadows merely move things. They make things appear and disappear… the visual style of the purple box makes it seem like it’s jumping around.

Why can’t Players make the farthest purple block appear if they are standing all the way at the entrance of the Level?

The Draggable Block here should be on some kind of a flagpole so that the vertical movement appears to be a natural fit to Players. (Many tried to move it horizontally.)

 

1-1

Level 1-1, Recovery

The name of this Level ought to be “Protection” or even just “Light”.

Why is the Light Switch casting a shadow? Does that shadow do anything? That may be a visual error.

 

1-2.PNG

Level 1-2, Detour

This Level can be broken to make both Goal Spaces appear at the same time. Players usually move the Draggable Block back and forth so rapidly that it causes both to be visible. However, the fake Goal Space does not work. If we can’t fix this bug… we should make it work! Why not reward Players for their trickery?

If there was a Light Switch near the space where the Goal Space is revealed, this Level would be a bit harder. You’d have to make sure the Light Switch was off. That may make it more interesting for the Players who figure it out in two seconds – and it keeps the World’s atmosphere consistent, since we use a lot of lights here.

The shadow needs to change more of the Level when it swipes across the screen, to give Players a clue that something weird is going on.

There ought to be two Shadow Eyes on the Draggable Block.

 

1-3.PNG

Level 1-3, Lock

Let’s make the sides of the Rotating Blocks sloped here, or at least spiked. People consistently try to walk on the sides of them when they are down, but that would break the Lights. It must appear unwalkable.

 

1-4.PNG

Level 1-4, Pressure

Extremely hard Level. That’s a good thing to have at this point in the game.

“I didn’t know I could stand on the box and rotate it.” Are we being consistent with when Players can do this and when they cannot?

How will Shadow Eyes work here? How can we align them with the object they are changing?

Someone found a bug where both buttons were pressed and they beat the Level, but they could not walk on the green path. (This is a soft crash I guess, since the Level is broken but the game still works fine.)

 

1-5.PNG

Level 1-5, Wolf

This Level should be renamed to something that indicates how to solve the puzzle, like “Doors” or “Black” or “Pitch”.

People don’t know they can drag these pillars.

The effect of pressing a Button here was not always obvious. I need to make an animation and we ought to have a clear sound attached to it.

On the iPhone, there was a bug where the sliding pillars could not be dragged. We had to reset the Level. I suspect Glyphs have something to do with this.

 

2-1.PNG

Level 2-1, Docks

Literally every tester thought the Walkers would hurt them and everyone called them “zombies”. My use of the color green was foolish!

We should start this Level with a Walker coming toward you that you can’t avoid, so people see that they aren’t bad.

People LOVE the reveal with the pillar sweeping across the Level. We should do more.

People tried to reverse the reveal and they couldn’t do that, which upset them. I think they wanted to see it more than once. When we get it set up properly, let’s consider this. It’s about consistency and Players enjoying the game for its toys rather than its puzzles.

 

2-2.PNG

Level 2-2, Test

We can call this Level “Elevator” or something. Maybe “Switch”, because you press a switch, but you also need to change places with the Walker.

Walkers flip around when you rotate Draggable Bridges, and this really annoys Players who are trying to guide his path. Also sometimes the Walkers float, breaking immersion.

 

2-3.PNG

Level 2-3, Guide

Pressed Buttons really ought to look pressed. I need to redo the art and then I’ll need help setting the states properly. We can also drain them of color once pressed.

For some reason I think buttons should be octagons. Why did I write this?

 

2-4.PNG

Level 2-4, Ebb

These Walkers cast a light, but they don’t have an obvious light source. I can make them holding torches, but what happened to their little light bulbs? Did I delete them?

 

3-2

Level 3-2, Tradeoff

The main light in this Level looks like it’s off because it’s so dark. The Player’s lantern doesn’t always need to be the brightest light in the scene! This sliding light is way more important to the mechanics of the Level. We can dim the Player’s light in favor of the other one.

 

3-3

Level 3-3, Anchor

Rectangles can pass through each other.

The right side Button node was briefly unwalkable, due to a multiple reality error.

After leaving a node, the state of a Button was still pressed. This made the Level unbeatable.

 

3-4.PNG

Level 3-4, Torus

“Is that it?” Torus looks more intimidating than it is. Can we bring up the difficulty on this one somehow? I think people are disappointed that you don’t need to find a way to navigate back and forth using the rotating segments. It is solved quite easily.

 

3-5.PNG

Level 3-5, Island

This Level can be broken by drag-dashing back and forth until the pillars remain upright. Then, walk into the island, the pillars lower, and you beat the puzzle without really solving anything.

 

It’s incredible how much insight you can get from just a few days of testing! These kind of testing moments are hard to come by, so it’s important to make the most of them. I hope you appreciated seeing how your feedback will impact the game, and this gave you an insight into what indie developers are looking for from testers.

We’ve got a lot of work cut out for us this month, so expect to see these changes reflected in my post at the end of June where I update you on the state of the game’s artwork.

 

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

We hope you enjoyed this insight into our testing methods. Do you have any feedback for us about the game’s alpha? You can reach out to us at WhereShadowsSlumber.com, tweet at us on Twitter (@GameRevenant), message us on Facebook, leave a comment on itch.io, jump into chat on Twitch, and email us directly at contact@GameRevenant.com.

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