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.

Advertisements

Dream Team

As Frank mentioned a few weeks ago, we’re getting closer and closer to the release of Where Shadows Slumber in Spring 2018, and as such, we’re going to try to take on a bit more of an active role in terms of publicizing the game. To that end, I’m going to take some time today to answer a question I’ve been asked a few times, that’s very vaguely related to the topic of publicity. “If you guys were to start another indie game development project,” they ask, “how would you want to expand your team? What skills and responsibilities would you want from your new team members?”

This is an excellent question – pursuing a decently-scaled project requires a lot of forethought and planning, and none of it is more important than designing your dream team. After all, you’re going to be working with these people for a while – so what does your dream team look like? The best way to answer this question is with experience. I’ve been working on this project on a two-person team for over two years now. What’s my dream team?

a-team_1

I will never cave and get Photoshop or something else “professional”!

 

In The Beginning…

When Frank and I first embarked on Where Shadows Slumber, we felt like we already had a pretty good team. Our personal dynamic was good, and we knew that together we had the set of skills that would be required – I would do the programming and design, and Frank would do the art and sound. Boy were we in for a rude awakening!

You see, for our first project, SkyRunner, we did the same thing. We built and released it, and it never really felt like our team had a gap in skills. It didn’t do so well, but we viewed it as a learning experience either way, so we never felt that we had failed to do anything in particular. When planning Where Shadows Slumber, we tried to do the same thing – design/programming, and art/sound. What we didn’t realize was that there was a huge gap in our skillsets. One of, if not the most important skills was something that we simply didn’t possess. We’ve been managing okay without it, but everything would be going a lot smoother if we had thought about it up front.

 

Where We Are Now

Before I get into the things that we don’t have, let’s talk about what we do have. We have a very lean, very agile team, with pretty strong design, artistic, and programming skills. There hasn’t really been a point when I’ve thought “man, I don’t think I’m gonna be able to implement this” or “wow, I really wish Frank were better at art” or anything. These are our strong points, and these are the things that we’ve consistently done well throughout development. I don’t think we need to do anything to improve on these skills at the moment.

On the flip side, there are a couple of areas where we are lacking. You’ll notice that I previously listed ‘sound’ as one of the tasks, but I didn’t mention it above. That’s because neither of us has any training or experience in sound design. Frank heroically took on the sound for the demo, since it sort of feels like a more artistic endeavor, but we quickly realized that we would need someone else to do the sound design for Where Shadows Slumber if we wanted it to have a real professional sound.

However, sound isn’t the thing that we were missing at the beginning. We’ve been looking for sound people, and we’re confident that we’ll be able to incorporate great sound design into the game. No, there’s something else, a huge blind spot, something that could potentially destroy us all and leave us with nothing, something that we never realized we needed, but can’t live without. There’s one more task that encompasses everything we’ve already talked about, and is perhaps more important than all of them put together.

 

Publicity!

A successful game is one that a lot of people download. The idea is that if your game is really good, people will download it. Unfortunately, this idea doesn’t always pan out – in order to get people to download your game, you need to give them some reason to. This is where a marketing and publicity expert really helps.

press

“Our game really speaks for itself.”

This can be a tough pill to swallow – paying someone who may literally never contribute to the actual game itself can feel pretty awful. Despite this, your publicity expert will probably end up being the most important person on your team.

Think of this person as a salesman, helping you sell your product. It doesn’t matter if you have a billion units of the best product on the market – if you don’t have someone to sell it for you, you’re not going anywhere. Infrastructure like the app stores make this a little easier, since you can publish a game yourself, but you still need someone advocating for you and getting people to download the game.

We don’t have the experience or know-how to actually do this. It seems easy – just talk to people, tell them about the game, take any chance to promote it. But the reality is much more difficult. In reality, it’s a full-time job. Talking to bloggers, reaching out to potential publishers, doing interviews, even writing blog posts, all of it adds up to a lot more work than we had anticipated.

In the same way that your game’s name is the first thing people will see about your game, any efforts you make at publicity – ads, going to shows, posts on Facebook – are going to be right up there in your first impression. Why wouldn’t you do everything you can to make sure you make the best first impression possible? It doesn’t matter how great your game is if no one feels like they want to play it!

 

“Doesn’t Play Well With Others”

Getting back to the question at hand – what would I take into account when picking out my DREAM TEAM?

Well, clearly, more people working on any aspect of the game means that the work will be done faster, right? While this is true, it’s also subject to diminishing returns. This means that two people doing the job will get it done faster than just one, but not twice as fast. In the same way, the third person on the job adds even less.

This effect is compounded by the fact that coordinating the implementation of a complex system is a tricky business. If I’m the only one working on my game, then I completely understand the whole system, and I know what changes I need to make and how they will affect the rest of the game. As soon as someone else is involved, we each have to coordinate all of our changes and work to understand the whole system. This overhead can slow things down quite a bit, to the point where it seems like it might be more efficient if just one person were working on it. You’d have to ask Frank, but I assume the same thing goes for coordinating artistic styles and assets.

how-complex-systems-fail

“Alright, new guy, here’s our system. It’s really pretty simple…”

Now, it probably sounds like I’m a crotchety old programmer who refuses to change or take a second opinion on my work. I like to think that this is not the case – I work with a handful of other programmers every day at work, and we do awesome stuff. The difference is one of scale, timing, and goals:

  • Where Shadows Slumber is a small enough project that one programmer can conceive of and manage the entire system. If I were working on a bigger project, you bet I’d want more programmers, just so that we could wrap our collective head around the tasks at hand.
  • We are nearing the end of development for Where Shadows Slumber. There’s still a long time and a lot of work left, but we’re about 80% of the way through development. Bringing someone on now would require spending a lot of time bringing them up to speed. Since there’s so little time left anyways, adding another programmer might actually cost us time, rather than save it.
  • As the only programmer and head designer for Where Shadows Slumber, I think of it as my baby, my brainchild. When working on it, I have very specific ideations and goals – hiring another programmer would mean there’s another person with their own ideas and goals. If they don’t line up with my own, then we’re gonna butt heads a lot throughout development.

Hopefully these points do a good job of explaining why I’m still the only one doing any programming work on Where Shadows Slumber. If I were to start another project, these are the things I would think about when hiring a programmer.

 

The DREAM TEAM

DREAM Team

Dreamin’ of the Dream Team

So, if it wasn’t obvious from everything above, my first addition to the team would be a professional, dedicated marketing and publicity person. Alongside that, I would want a sound designer – which, fortunately, we are actually working toward.

Those two roles, in addition to Frank and myself, would put us in a pretty good place, in my opinion. If I were to continue expanding the team, my next move would probably be to get another artist and programmer to help with the heavy lifting. The best way to avoid diminishing returns, I think, would be to divide the work into discrete parts – for instance, the art could be divided into the art for the game itself, and the cutscenes. If I were to bring on another programmer, I would want someone with expertise in graphics and aesthetics, since those are my weakest areas.

So, if you’re looking to put together your own dream team, my recommendations are to make sure that you don’t overload any one person, and to definitely, definitely not underestimate the value of a dedicated publicity expert. Otherwise you’ll end up posting blogs full of crappy MS Paint art and thinking “Eh, it’ll be fine”.

 

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

If you want to know more about how our team is put together, or are curious about building your own dream team, 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

 

 

The Name Of The Game

As you (probably) know, Frank and I have been working for a while on a certain game-development project. And, as you also (most likely) know, the name of that project is Where Shadows Slumber. For as long as any of you have known about it, that’s what we’ve called it, so it might seem strange to think of calling it something else at this point. But the name wasn’t always Where Shadows Slumber – for quite a long time, our game didn’t even have a name. How did we get from there to here?

When I first came up with the idea for the game and we started on the proof-of-concept, we didn’t have any particular name in mind. We weren’t thinking about it at all, and we didn’t even have an idea of what kind of name we might want. That apathy followed us through the early phases of the game, up to the point where we started going to smaller events, showing it off to people, and getting feedback. We discussed different naming options, but we never considered it a huge priority, and didn’t dedicate much time to it. Before too much longer, we came to the realization – we need a name for this thing!

 

Why Do You Need a Name?

We were just getting started with a new, unknown game, and, against all odds, it was actually going well! People seemed to really enjoy playing our game. They seemed interested in our process as a small team. We had been perfecting our ‘pitch’ at every event we went to, and we know exactly what to say to people when we showed them our early prototypes. That’s when we realized the mistake we had made.

People liked the game, and they wanted to know more about it. They wanted to hear about updates, they wanted to know when it came out. The problem was, the game didn’t have a name – how can someone keep up with it if there’s no name to search by? That was when we stopped messing around. Making a game is hard, and making a successful game involves making the correct decision at every point in the process. This was a place where we had screwed up, but we resolved to fix that mistake immediately, and I think that our fast action was an excellent decision that did a lot to move us toward success. The decision we made was to meet up in person the following week. We would sit down and figure out a name, and neither of us would be allowed to leave until we had decided on one.

 

What’s In A Name?

Now, choosing a name is a surprisingly difficult thing to do. The biggest hurdle for us, I think, was the dedication that it implied – once you pick a name, once people start using it, you can’t really go back. What if we chose wrong?

whatsinaname

MS Paint forever!

While this was a scary proposition, it was also one of the things you want most out of your name. You want people to remember it and recognize it – you want it to last, and you don’t want to go back. Which just means you have to be that much more careful about choosing it. So lets look at all the things you want from your chosen name.

Recognition – The most important part of your name is that people associate it with your game. For us, when people think of the words Where Shadows Slumber, we want them to think of our game, and only our game. This is associated with having ownership over the name – nothing else is named in a way that’s too similar to Where Shadows Slumber. Take my name for example – Jackson Kelly. Go ahead, give it an image search, I’ll wait.
Do you get a bunch of pictures of my beautiful face smiling back at you, or a bunch of guitars? That’s right, the name Jackson Kelly is already ‘owned’, to some extent, by a guitar company. If I were choosing a name for a company or product, I definitely wouldn’t choose Jackson Kelly, because people (and Google) already associate it with something else.

“Pre-loading” Information – When people sit down and play your game, they won’t always know what to expect. There are some people who aren’t part of your target audience, and they might not like your game. Some games require the right mood or mindset. These are all good examples of how your game’s name can “set the mood”. If your game sounds like a puzzle game, then puzzle gamers will know that it will be good for them. If your game sounds like an endless runner, people will know what to expect. This leads, perhaps even subconsciously, to people more often playing your game when they’re interested in the style of the game, and when they’re in the mood for it. This also applies to people following your progress and keeping up with your development.

Telling a Story – Every game has a narrative of some sort – not necessarily a story in the conventional sense, but something you want your players to experience, outside of the mechanics themselves, when they play your game. For a game like Where Shadows Slumber, this is a literal story – something is happening in the world of the game, and the player gets to watch it happen. Other narratives aren’t so straightforward; take Candy Crush, for example. I’ve never played it, but I assume there isn’t really a huge storyline. Rather, what you want the user to experience are the rules of the candy world, and why the player should be connecting the candies.

Whatever the narrative, everything about your game should speak to it, should play a part in making it happen. The name, as the first part of your game users will interact with, is a vital piece. It’s where the journey begins, and you want to make sure that it helps tell your story.

Representing Your Game – Every part of your game should be great, but the most important part of your game is the beginning – can you get a user “hooked”? The name of your game is the first part of your game a potential user will experience, so it should, arguably, be the best part of your game. If you clearly didn’t put a lot of thought into the name, how can people trust that you put any effort into the game itself? [Editor’s note: see “Mr. Game!” for reference] The name is part of the game, and it should be treated as such.

 

How We Came Up With the Name

As I mentioned earlier, the way we came up with the name was to have a few rough ideas in our heads, and then to sit down and get it all done in one session, cagematch-style. Perhaps this wasn’t the most efficient way to get this done, but it stopped us from dragging our feet, which had been the biggest problem. So, we met up at 10 am on a Saturday, and got into it!

naming5

A spattering of words and concepts we considered using.

The first thing we did was to brainstorm – not for names, but for emotions. People buy most of their entertainment products based on emotion, and games are no different. What emotions do we think players will feel while playing, and what do we want them to feel? What kinds of emotions will motivate them to buy it and to keep playing it? By answering these questions, we started to figure out the tone our name should have. The emotions we decided to shoot for, to various degrees, were mystery, fear, suspense, and hope.

Once we had some emotions, we started to focus on the actual content of the name. Our name should be indicative of the things in the game, and, in particular, of the story players will find within. What are our main mechanics and story points? What words can we find for those things that fit within the emotions we chose? Again, we’re not thinking about actual names yet (for the most part), but just building up a collection of words. We ended up with quite a few, but some of the major ones were umbra, nimbus, slumber, wraith, and plenty of others.

After that, we finally got started on actually choosing a name. We tried to combine the words we had come up with into sensible, interesting names. We came up with quite a few, decided on our top four favorites, and made a little bracket. We discussed each of the names at length – what will people think, will it help us connect with players, are there other games with similar names – and eventually narrowed the search down to Where Shadows Slumber!

naming4

The final four!

This whole process took upwards of eight hours. It was an exhausting day, but I think we ended up with a pretty good name at the end of it all.

 

Aftermath

When we first decided on the name Where Shadows Slumber, I was pretty apprehensive, and I think Frank was too. We didn’t want to commit to a name that might not have been 100% perfect. That said, we knew we had to make a decision, so we did.

In the end, I’m really glad we settled on Where Shadows Slumber. I think the name does a lot to describe what our game will be like, we have good ownership over the name, and it really just seems to fit. It was a heck of a process, but I think we made the right choice at the end of the day!

 

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

If you want to know more about our naming process, 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.

Fake It Til You Make It

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

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

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

 

2

The video game Hydrophobia was criticized for focusing too much on its water physics and not enough on other forms of gameplay.

Faker!

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

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

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

lava

How did you even get there? …How are you not dying?!

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

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

 

 

NoShadow

Wait, what’s making that shadow?

Where FAKE Shadows Slumber

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

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

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

 

8rgt8bamhlnvicvzsd3pfjof

Otherwise known as “what happens when two hacks collide.”

Potential Pitfalls of Constantly Lying

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

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

StairShadow

Something looks just a little off…

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

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

 

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

I hope this gave you a bit of an insight into what’s actually happening in Where Shadows Slumber! If your confidence in us is shaken and you have any questions about what else we’re lying about, feel free to contact us! You can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), 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.

What Happens When You Forget to Write A Blog Post?

“Yo Frank, what upppp?!” I ask once he answers the phone call and his face shows up, larger than life, on my screen.

“Ey boii!” he replies, his voice booming through my headphones. The line falls silent for a few seconds, before we both speak up in unison:

“So, you’ve got a blog post planned for tomorrow, right?”

We stare at each other (well, as much as you can over the internet), our faces slowly transforming into masks of horror as we realize the ultimate fate we have incidentally worked together to bring upon ourselves.

“What will our millions of fans think?!” Frank cries, as the room around him is engulfed in flame.

“How will we ever persist without the precise instrumentation and scheduling that our weekly blog posts bring into our lives?!” I ask of the world in general, falling to the floor, unable to go on.

Then I meet Frank’s eye. I climb back into my chair as he slowly lifts his  hand, making both a fist and intense eye contact. I raise mine as well, shaking it in the air as we chant:

“Rock, paper, scissors, shoot!”

And that’s the story of how I got stuck spending last night writing this blog post.

ConceptArt-Murder_Arson

We all know how it feels to forget about a responsibility…

Not Really Though…

I really spent the whole week writing this post, not just last night (wink), but that story does a good job of showing how it feels to be behind, especially when it comes to our blog. We’ve made the conscious choice to involve ourselves in indie game development, without any real outside motives other than a love for games and development. Because of that, we do a lot of interesting and difficult things, and we talk about them a lot on this blog. But you know what interesting, difficult thing we do every week that doesn’t really get talked about that often?

That’s right – every week, one of us writes a blog post. Some of them are pretty good – a lot of them show interesting choices we made, or maybe they provide insight to other developers out there. But the point of writing this blog isn’t to write the best blog out there, or to prove ourselves as ultimate authorities on game development (hint: we’re not).

The point of writing this blog is to connect with people. We want to let people know about the struggles we’ve gone through to make our game as great as possible. We want to help other developers make their games as great as possible. We want to get feedback from anyone reading these posts, so that our game can be as great as possible.

 

How Hard Can It Be?

This is a fair question, and the quick answer to it is actually one of the reasons we ended up starting the blog in the first place – it should be easy, right?

And for a while, it was! We had spent a year and a half creating a game and only sharing the details of it with each other. We had a whole boatload of topics to talk about! We were itching to discuss artistic direction, algorithm implementations, and design decisions. I think there was a point when we had a full two months worth of posts already written.

However, that was the easy part, the colloquial ‘honeymoon’ period. Of course it’s easy at the beginning! But as the months have worn on (and we’re still less than a year into it), the obvious topics have started to dry up. “What’s our game about? Shadows? Well I already wrote that one…” You end up having to weave thinner and thinner topics into a real story – I mean, I’m writing a blog post about writing a blog. That’s when you know you’re at the bottom of the barrel.

Running out of ideas

Running out of ideas!

That said, game development and Where Shadows Slumber are both pretty interesting, so we’ve been able to manage coming up with enough topics. The real hard part of this blog is the opportunity cost. We spend a few hours throughout the week writing, revising, and proofreading, and then another few hours finding and creating the perfect images to include. The problem with this is pretty clear – every day we have less and less time left for the game, and every minute spent on something else is a minute we’re not spending on the game. Spending a few hours a week, especially when you have other responsibilities, is a large portion of time to commit. Is it really worth it?

 

Then Why Bother?

When I pictured myself as a game developer, I never pictured myself writing a blog. Even when Frank and I were pretty far into the development of Where Shadows Slumber, I never even considered it. I mean, we’re making a game, right? Shouldn’t we just, you know, make the game?

Blogging

Obe does not engage in blogging. He engages in Gronging.

It turns out that, despite the fact that we could make a game without writing a blog, there are still some places where it’s pretty important. When the idea of the blog first came up, we weighed the positive against the negative, and decided to do it – we must have some reasons, right? And we do!

1.) Getting Noticed. One of the hardest parts of indie game development is publicity. How do you get people to notice your game? If you somehow manage to build a fanbase during development, how do you keep a hold of them until your production release? Thanks to Frank’s orchestration of our process (which you can read about in his blog post about it), we found ourselves with a pretty good demo of our game, and we were still pretty far from a production release. Between a few conventions, a timely release, and an insane amount of luck, we have managed to garner over 200,000 downloads! The problem is, we’re still around 8 months away from a real release. What happens to all of the people antsy for more Where Shadows Slumber?

This is where the blog comes in – anyone who has played the demo and is interested in the game can find out more about it here. They can keep track of our progress and get updates about the game. They can get an idea of when the game will be ready, and they can keep it in mind. They can even hack into WordPress, figure out our home addresses, and then force us to finish the game, if they really want to!

2.) Marketing. Being open about our development process helps us to ‘build a brand’, and writing a blog is one of the best ways for us to do so. Our brand is something that’s very important for us to cultivate – when people think of Frank and Jack, we want them to think of two awesome guys, who are sharing their process and trying to be a part of the indie game development community. We don’t want the general perception of us to be that we’re secretive or shady. Would you rather buy a game from Sir Awesome Coolguy or Creepy McCreeperson?

3.) Helping Ourselves and Others. The biggest aspect of the blog, and the reason that we’re still doing it, is that it’s rewarding for us, selfish as we are. We were part of a panel on indie game development at PAX (which you can read about here), and that’s still one of the most rewarding parts of working on Where Shadows Slumber for me. It really means a lot to me to be able to answer questions or give advice that helps someone else with their game. I truly love game development, and if this blog helps a single person or team bring their ideas to life and complete a game, then it’s all worth it.

 

So, Why The Where Shadows Slumber Blog?

There are a lot of blogs out there. I mean, there are a lot of blogs out there. That’s one of the beautiful things about the internet (*cough* plug for net neutrality *cough*) – pretty much anyone can put something together and get their message out. So why are you, dear reader, reading this blog, of all of the blogs out there?

We aren’t trying to be the best blog on the internet. We aren’t trying to be the most insightful game designers. We aren’t trying to be the best at teaching programming or art. There are other blogs out there, and there are great ones for learning about anything you want to learn about.

ConceptArt-Inhabitants_Citizens

We want to share Where Shadows Slumber with all of the citizens of the world!

What the Game Revenant blog, at least as it pertains to Where Shadows Slumber, is all about is our progress. We’re a small indie development team, going through this process for the first(ish) time, and we want to let you all know about it. Whether you use it to keep tabs on our game, get tips on your own, or just learn more about us and our process, is up to you. Either way, we really appreciate you reading!

 

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

Thanks for reading! If you want to know even more about our process, or have any questions about blogging in general, feel free to contact us, and 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.

Keeping it All in Your Head

When you study computer science, or first get into toying around with it in your spare time, you find yourself working on a lot of small projects, just to get your feet wet. ‘Hello World’, a program which simply prints the text ‘Hello World!’ is perhaps the most-written program of all time. As your projects get bigger, the code behind them gets more complex, and you, as the software architect, have to keep track of everything that’s going on. This seems like a pretty easy task when working on a guess-the-secret-number game. But what happens when your codebase becomes BIGGER THAN YOUR ENTIRE BRAIN?!

 

Untangling The Web

In case you couldn’t tell from all the words about code, computer science, and programming, this post is gonna be one for the more technical folks out there. However, that doesn’t mean that there aren’t lessons to be learned by anyone else – keeping track of complex systems is a skill that applies to any project management task!

Real-world systems are incredibly complex – even more so than they appear, even after working with them for a while. As you add features, fix bugs, and increase the overall complexity of your code, you suddenly find yourself stuck in a tangled web of your own design. Now, the best way to combat this is simply to write good, clean code and follow good design patterns. However, if you want some advice other than “just do everything exactly right”, then read on!

Where Shadows Slumber isn’t the most complex game, but the implementation behind it is very intricate, and I definitely didn’t do everything exactly right. As the only developer on the project, I have to keep track of everything, which is a lot of stuff. Here are some tips I’ve developed for not going crazy trying to understand a system that you yourself created!

 

Tip 1: Divide and Conquer

The first application of divide and conquer is exactly what it sounds like – take the whole system, divide it up, and give a different part of it to each team member. While this doesn’t really apply to the development of Where Shadows Slumber, it’s still worth mentioning. If you’re in charge of one part of your project, and someone else is in charge of another part, there’s less minutiae for you each to keep track of. You only have to know how the pathfinding (for example) works on a higher level – the intricate details of the exact implementation are left for the ‘pathfinding team’. And if you do need to understand how pathfinding works, there’s someone who knows all about it – and that’s what teammates are for!

The other application of dividing and conquering is what I’ve heard referred to as ‘the Google Maps approach’. When you’re looking at a map of the world, you don’t need to be able to see every single city. But if you’re looking at a map of a state, you probably do want to see them all. So, the amount of detail you get depends on the context in which you’re examining it.

How can we apply this to project management? It’s really just a state of mind. When you’re thinking about your whole project, try to think of it from a more abstract point of view, rather than considering all of the details of the implementation. This kind of thinking happens naturally, but we want to actively embrace it. You want to think of the smaller parts of your project as a ‘black boxes’ – you give them some input, and they give you some output. You don’t know (or care) how it gets figured out, until you need to look at that code – at which point, you shouldn’t be thinking about the rest of the project. By only caring about the part of the project you’re currently working on, you free up a lot of space in your head.

 

Tip 2: Keep It Simple

The best way to prevent your project from becoming too complex is, obviously, to keep it simple!

Honor Societies

This comic is a comic [Image credit: xkcd.com]

“But how do you keep your project simple?” I can hear you asking. The key is in how you think about your code. For the most part – and there are notable exceptions – you should be able to think about or describe the function of different parts of your code with ease. Doing so might require the context within which that piece is working, but given that, it should be relatively simple.

Now, don’t get me wrong – your code itself will probably be very complex. However, it’s important that any code has a specific purpose. If some piece of code doesn’t have an easy-to-determine purpose, consider why it’s there and what it’s doing. If possible, see if you can move parts of it into the appropriate parts of your project.

Additionally, when describing the purpose of a section of your code, make sure it’s a relatively simple purpose – the best way to do this is to avoid the word “and”. If the purpose of a file is “to perform pathfinding and determine nearby enemies”, it would probably be best to split that into two different files.

By keeping your code as simple as possible, at least from an organizational perspective, you won’t have to strain yourself every time you try to remember what your code is trying to do.

 

Tip 3: Organization

Speaking of organization, keeping your project organized is one of the best ways to keep it under control. This can be tricky and surprisingly time-consuming, which is why people so often shy away from it, but it can also be crucial to your success. The key here is to create sensible patterns, and then follow them.

ORGANIZED

Everything is right where it should be!

The easiest way to apply this is in directory structure. Make a decision toward the start of your project how you’re going to organize everything, and then stick to it. For Where Shadows Slumber, as you can see, we sort most things by world. All of the levels, materials, and textures for World 1 are in the same folder, since they all apply to the same levels.

However, notice that there are some folders which are not organized by world. Scripts and prefabs are examples of things which span across worlds. While a model or texture might be specific to a certain world, the shadowCharacter.cs script, or the pathfinding node prefab are not, so why should they be sorted by world?

Thinking through your project and deciding on a directory structure that makes sense can make it a lot easier to understand what’s happening in your project. And, every so often, you should re-examine your organization, make sure it still makes sense, and make sure you’re actually following it. In this way, you can be organized, stay organized, and know that your organization is actually effective.

There are also organizational paradigms that you can apply to your code to keep it clean. One of my favorites is the idea of data ownership. The idea is that every piece of data in your project (the location of the character, a bullet’s speed, the number of points a player has, etc.) should have an owner. It’s usually pretty easy to figure out who the owner should be, but sometimes it can be tricky – and it’s in those cases where it’s important to know. If my shadowCharacter.cs script is the owner of the character’s position and velocity, then no other code should be allowed to mess with those values. That way, if there’s a problem with the character’s position, you know exactly where to look.

This is just one example of an organizational coding pattern, but the concept behind them all is pretty similar – at every point, you want to make it easier to understand what your code is doing. It’s a whole lot easier to make changes, fix bugs, and implement new features when the things that your code is doing actually make sense to you.

 

Tip 4: Not Too Complex… Yet

Every project starts out small and simple, and yet we constantly find that our projects have gotten out of hand, growing into sentient monsters, taking over our lives and ruining any chance we had of success – who knew that project management was so much like parenthood?

Incredibly clever comments aside, if our project starts out simple and ends up complex, there has to be some point when it started to go awry, right? And if so, there’s probably a point when we could have noticed it going wrong and steered it back on track. Thus, it’s important, as you’re working, to be constantly considering the state that your codebase is in. Every so often, ask yourself; is this code still clean? The more often you ask yourself this question, the sooner you’ll know when you start heading in the wrong direction – it’s much easier to fix this problem if it’s only just started to go wrong!

This is the concept of technical debt – every so often, you add in some bad code, just so that you can meet a deadline, or get some functionality off the ground. Every time you do that, you’re increasing your technical debt – and if you don’t pay that debt, it adds up until your code is unmanageable. It’s always good to keep your technical debt in the back of your mind, and address it as often as possible.

In my experience, there’s one really good way to determine if your technical debt is getting to the point where it’s impairing your development. If you ever find yourself writing overly complex code, it probably means that you have an overly complex system.

The longer the conditional the better

Genius!

Again, I’m not advocating against complex code in general, as it has its place. But if you find yourself writing complex code to do something simple, or repeatedly thinking “it should be easier to do this”, that’s a big red flag. If you ever fix a bug by ‘trying something’, but you don’t know exactly why it fixed the problem, that’s a sign that you don’t fully understand your code, and code that has exceeded your grasp is exactly what leads to very subtle (read: hard to fix) bugs.

When you get to this point, you should take a step back (and maybe a break), get a fresh look at your code, and spend some time cleaning it up. No one likes spending time on housekeeping tasks, but trust me, it’s a lot more fun spending an hour here and there cleaning up your code than it is mucking through an overgrown garden of technical debt.

 

…And Beyond

This is by no means a definitive list, nor will every part of it apply to you or your project. Rather, these are just some of the philosophies I try to keep in mind as I’m coding and software architect-ing. There are plenty of others, but hopefully adding these to your repertoire will help you reign in your projects and keep them from becoming too complex!

 

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

If you have questions about managing complex systems, or want to share your own tips, 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.