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.

 

Advertisements

State Of The Art – June 2017

Welcome to State Of The Art, June 2017 edition! This monthly progress report is written by Frank DiCola and is focused entirely on how the game’s visuals have improved in the past month. Without further ado, let’s explore the major leaps forward we took in June!

 

The Forest Is Starting To Look Finished

Where Shadows Slumber begins with a few short tutorial levels that teach the Player how to play and start the story off with a mysterious event. This takes place in the Forest, or “World 0”, as we’ve been calling it. I’ve recently begun calling it the game’s prelude, which sounds more profound and less technical.

Take a look at this video of the second Level of the game, “Bridge”, in action:

As you can see, the Level is entirely functional and artwork has been attached to every facet of the Level. The things that are missing are either out of my hands (audio, footfall particles when the protagonist walks) or things Jack and I want to leave for the end of the development process (polish on the Draggable “grab” effect).

The toolkit of 3D models I use to build Forest Levels is really coming together. Level 2 served as a good model for how I’m going to decorate Levels 1 and 3. Those have not been started yet, but you can expect them next month!

 

World Select and Level Select Menus

Where Shadows Slumber is a journey that takes you across a desolate world with a variety of biomes. You begin in a Forest, but you’re soon kidnapped and put into a volcanic Jail. You escape, but only by traveling down a haunted, marshy River… and that’s just the game’s first act!

We found it necessary to group these biomes into Worlds. Furthermore, each puzzle in the game is its own Level. So we needed a screen that allowed Players to view each World and then select the Level they want to play. I wanted to make each World screen inviting, yet spooky. I also wanted to use as much of the existing art in the game as possible.

Below is a video of the World Select Menu in action, including transitions:

Notice how the transitions from World-to-World mirror the shadow mechanic of our game. Including that was extremely important to us!

Please know that this menu is not finished yet. The decorations for this menu are entirely downstream of the actual art in the Levels. That’s why I’ve only finished a few of them so far. Believe it or not, while these screens may seem flat, they’re actually produced with 3D models and camera trickery!

Blog-BTS

It’s a cool effect… but that means I need to finish all of the Levels in a World before I can go on to the menu. Dependencies in game development are annoying, but it’s more annoying to ignore them and then come back to find a lot of your work was erased or made worthless because too many underlying elements changed.

 

We Built This City

The toolkit for the City (World 4) is one of my favorites in the game. The inspiration for this slum town environment was a combination of the poorest regions of India mixed with the pueblo towns of South America. The result is a city that looks hewn out of a mountainside and packed to the gills – once I add the people, that is! During your travels, you’ll go from the poorest area of the City all the way to the King’s palace. Who knows what you’ll find there?

Here’s a screenshot of Level 4-1, where we introduce the concept of Doors that teleport the main character. Check it out:

 

Over time, this toolkit will grow to include fancier parts of town, including a really cool Level we have planned where you ascend one of the city’s towers. Stay tuned!

 

Wolf Attack

Last time we saw the Wolf he had just been modeled. This month, I gave his face a fresh coat of paint and worked on his animations. Now he can express a wide range of emotions, from “angry” to “really mad” and even “about to kill someone”! Check it out:

Blog-Wolf.PNG

 

Works In Progress

Worlds 3 (Aqueduct) and 5 (Hills) have progressed slowly over the past month. Whenever we’re not sure of how a World’s puzzles will look, it’s harder to focus on the art for that World. I like to pick out a really solid puzzle and work to get it to a professional place, but the level design for these two Worlds is still very much a work in progress.

Blog-Aqueduct.PNG

Having said that, I have at least started both of these Worlds using dummy scenes. This design is subject to change, however. I’m still deciding on the key colors for the Aqueduct. Blue feels a bit too obvious. The Aqueduct should be dark and cavernous, but I also want it to be a departure from the two Worlds (Jail and River) the Player just experienced, which are kind of depressing and muddy.

Blog-Hills

As for the Hills, it’s very difficult to create a scene from nature using entirely modular pieces. Sometimes you just need to make something that specifically works for a certain puzzle – especially background mountains. The Hills have a lot of moss-covered rocks and grassy cliff faces. I’m having trouble making puzzle-piece 3D models that can be assembled to look like they fit together to form the rolling hills of Ireland. Expect progress on this World to be quite slow.

 

Thanks For Reading!

That’s all for now. In the future I’d like to make this update strictly contain videos of the game in action. Screenshots are great, but this is a game, and I want to push myself to film more sections of it and analyze it from every angle (animation, color, sound, feedback). Look out for that in July’s update!

 

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

We hope you enjoyed this update about the game’s artwork. Have a question about aesthetics that wasn’t mentioned here? You can find out more about our game at WhereShadowsSlumber.com, ask us on Twitter (@GameRevenant), Facebookitch.io, or Twitch, and feel free to email us directly at contact@GameRevenant.com.

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

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.

Monument Valley 2 and Its Implications

On Monday, Apple and ustwo games nonchalantly made an announcement that could forever change the development of Where Shadows Slumber. If you haven’t heard (or figured it out from the title), then I’m glad I get to be the one to tell you – Monument Valley 2 has just been released for iOS devices, with Android coming “soon”!

If you’ve ever played the original Monument Valley, then you’ve probably noticed that it was a big inspiration for Where Shadows Slumber (in fact, you might remember that I mentioned something to that effect in my first blog post). Monument Valley is one of my favorite games of all time, and I’m super excited to be able to return to that world for another round!

As awesome as this announcement is, it’s also a little bit scary. Monument Valley 2 is gonna make a big splash, and people are going to be paying attention to it. The development, production, and eventual release of Where Shadows Slumber will all be happening in its wake, and so this announcement is very important to the future of Where Shadows Slumber.

How does this announcement affect our development, you ask? Well, let’s take a look!

 

There Can Only Be One

Monument Valley was awesome. I mean, it changed the face of mobile gaming as we know it. It was genre-defining and laid a lot of ground for future games like Where Shadows Slumber.

The problem with using a game as inspiration is that your game becomes pretty similar to that game. Since Monument Valley was such a hit, that’s not really a bad thing. Until you consider the fact that two very similar games are inherently competitors. We feel pretty confident in Where Shadows Slumber, and we felt that four years would definitely be enough to set us apart. A new Monument Valley game really changes the equation, for a number of reasons.

screen_263x350_2017-06-06_08-24-37

Ro vs. Grongus: Deathmatch

The first reason is pretty obvious – there are only so many people buying puzzle games. A giant like Monument Valley 2 takes up a lot of that demand. If Joe Puzzlegamer pulls up to the App Store and wants to get an artsy puzzle game, he’ll have a lot of choices. Even if he only had two choices, which would he choose – Where Shadows Slumber or Monument Valley 2?

Monument Valley 2 has a pedigree. It has a wildly successful predecessor. It was made by a studio with a real budget, decently-sized teams, and the know-how to bring a successful game to market. Where Shadows Slumber is awesome, but we’re just two random guys with little money and even less experience. Even if that’s not how we see it, that’s how everyone else will. Monument Valley 2 is the clear choice for the random outside observer.

In addition to losing out on potential sales, there are other things we could lose to Monument Valley 2. For a team without a large advertising budget, one of the best ways for us to get publicity is through conventions and awards. With Monument Valley 2 crowding the beautiful Unity-based puzzle genre, we could also lose chances to attend conventions and win awards. Again, people will have to choose between us and them. Will Unity invite us to represent them at an event? Will Apple shower us with promotions? Will we be anyone’s pick for best puzzle game? Probably not, if they can get Monument Valley 2.

 

Puzzle Mania

While there are some negative takeaways to Monument Valley 2, there are definitely quite a few positives (in addition to the fact that we have another awesome game to play). As they say, a rising tide lifts all boats.

When Monument Valley first hit the mobile gaming scene three years ago, it made quite a big splash. People absolutely loved it, and they clamored for more – I know when I finished Monument Valley, I wished for nothing but more levels. Imagine if we had been able to release Where Shadows Slumber 8 months or so after that – just when people are done with Monument Valley, but still want a similar experience, we provide them with exactly that!

Monument-Valley-2-Main-by-Ustwo-games

Bringing people back to puzzle games

We’re hoping for a similar situation to unfurl here. People will play Monument Valley 2, and it’ll get their brains working. They’ll (presumably) love the puzzles, the art, the brooding atmosphere. They’ll be all warmed up to the genre, and they’ll be on the lookout for anything similar. We’ll be ready to pounce on that crowd, and hopefully it’ll help us release into a bit more hype than we might otherwise.

Basically, we’re hoping that Monument Valley 2 will revitalize the moody puzzle game market. Not to sound too utilitarian, but we plan to use Monument Valley 2 as a sort of springboard to success!

 

Timing

There are a few things about this announcement that could be bad for Where Shadows Slumber, as I mentioned, but I think that there is an important factor worth mentioning, and that is the timing. We’re planning on releasing Where Shadows Slumber in early 2018. So, all things considered, I think this timing is just about perfect for us. If Monument Valley 2 had to be released sometime soon, now is probably the best time.

timing

Perfect timing.

If Monument Valley 2 were to be released a month or so after Where Shadows Slumber, we wouldn’t even stand a chance. As soon as people were starting to get excited about our game, a much more acclaimed game would come along and steal all our thunder! A similar story plays out if we release shortly after them – our release simply goes unnoticed.

So why is this the best time? Wouldn’t it be better if they had released a long time ago, to keep our release as far away from theirs as possible? While that makes a lot of sense, I think that Monument Valley 2 will inspire more interest in puzzle games overall, and eight months seems like a pretty good timeframe for the MV2 hype to die down, but for the puzzle fever to still be strong.

Additionally, the fact that Monument Valley 2 has been released in a different calendar year from Where Shadows Slumber works in our favor as well. A lot of awards are of the form ‘game of the year‘, and Monument Valley 2 is a shoo-in for many of those awards. With our biggest competitor releasing in a different year, we won’t have to compete directly with them for ‘of the year’ awards. Not that we expect to win these awards, but it’s always nice to feel like you have a chance.

 

Changes To Development

So how does this actually change our development plans for Where Shadows Slumber?

Since the timing of Monument Valley 2 is working in our favor, we’ve decided that we’re going to stay the course. We’re still aiming for an early 2018 release, which we feel puts us far enough away from this release. If Monument Valley 2 announced their release in early 2018, we would have no choice but to push our release back a few months. As of now, we aren’t making any changes to our schedule, but we’re definitely keeping our eyes open – if they release an expansion of some sort in early 2018, we might have to reconsider our own release date.

Since Where Shadows Slumber was so inspired by the original Monument Valley, we’re also looking at this as an opportunity to be inspired again. People have, and will continue to make comparisons between our game and Monument Valley, but now they’ll have a newer, sleeker version to compare us to – we have to try and keep up! We get to see another take on the Monument Valley style of puzzler, and we get to see a bunch of new mind-bending puzzles. Perhaps some of them will strike inspiration in our hearts, and help us make Where Shadows Slumber that much better!

inspiration

Can you feel the inspiration?

On the other side of that coin, we’ll also be playing Monument Valley 2 and looking for anything that’s a little too similar to Where Shadows Slumber. If we find that one of our levels is very similar to one of theirs, we may have to change it – even though we didn’t steal it from them originally, that’s what it will look like to the outside observer. We want to be similar to Monument Valley, but not too similar.

 

Takeaways

Most of the above musings on the implications of Monument Valley 2 are pretty specific, and overall, they’re pretty far beside the point. This is one of the most exciting announcements I’ve heard in a long time, and I can’t wait to get my hands on the new game! That’s the biggest takeaway you should have from this post – no matter what the implications, I’m super excited, and you should be too!

 

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

If you finish Monument Valley 2 and are looking for more puzzle-y goodness, 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.

3 Ways Our Art Changed In May 2017

Last week, Jack wrote a general progress update about the game. We hadn’t done one in a while, and we’re trying to get our audience more informed about the process of game development. Inspired by his post, I’ve decided to dedicate the last post of every month to an update about the visual aesthetics in our game. We’ll review everything that got done in the previous month, with a small glimpse of the road ahead and how it relates to the larger goal of completing the game.

 

 

Getting The Ball Rolling On Five Worlds

Our game will feature 8 different Worlds by the time we’re done. Completing the artwork for all of those will take a while, so it’s never too early to get started. I had hoped to get more done this month, but I am glad to report that five of these Worlds have been started. They may never really be “finished” because I’m a perfectionist. Even when the game launches, I’ll still want to change things. But I might as well get them to a place where Jack can say “Frank, stop working! Step away from the computer!”. I’ve included some Work In Progress shots of each World below.

World-0-Forest

World 0 – Forest. This kit needs a lot of work. The bushes are too high-fidelity, and the trees are too low-fidelity. This is a screenshot of the game’s first Level.

World-1-Jail

World 1 – Jail. This kit exceeded my expectations. I wanted to convey the feeling of a claustrophobic, harsh volcanic prison. The brutalist-inspired walls really pull the aesthetic together.

World-2-River

World 2 – River. Inspired by the river styx, this is designed as a swampy, foreboding, gross river. Rickety wooden plank bridges contrast with log-cabin style barricades.

World-6-Summit

World 6 – Summit. One of the toughest to apply modular asset creation to so far. Blurring the grid lines was key to pulling this wintry, icy art kit together.

World-7-Paradise

World 7 – Paradise. This kit is complete, and looks gorgeous. I won’t actively work on it anymore unless something is missing in a Level we’re designing.

Please note that the screenshots included here don’t always reflect actual Levels in the game. Sometimes, to show off how pieces of artwork interact, I design fake Levels in the spirit of the game. Hopefully it gives you a good idea of my progress, and what needs to be done. I also decided to pawn off water effects onto Jack, so that’s why the fluids in these Levels just look like flat planes. (I built them with flat planes) Water will come later. Also coming later – the Worlds I haven’t started yet!

Expect to see screenshots of Worlds 3, 4, and 5 during next month’s update.

 

TwoHeads

Character Faces

One of the barriers I’ve been trying to break through is my Character Design issue. Every humanoid model I’ve created for Where Shadows Slumber so far has been hastily created for an upcoming deadline. The result is a slipshod model that looks nice from 1,000 feet away, but performs poorly when I need it to do something. In a previous blog post about cutscenes, I lamented at how terribly the Demo protagonist handled when I needed to animate him. His clothing had to be key-framed by hand, and his arms were bent out of whack.

But one of the biggest problems was his face. I modeled it the quick and easy way, and as the saying goes, you get what you pay for. I found it impossible to give him good facial expressions when the situation called for it.

HeadAnimations

The protagonist’s new head uses Morphs to smoothly transition between preset facial poses.

Flash forward to this month: I’m taking a new approach where I model character heads separately from their bodies so I can focus on facial animations using Morphs in 3DS Max. As long as no one notices that these heads are disconnected from their torsos, the effect works. Morphs allow me to model facial animations (frowns, smiles, surprise, anger) and move a slider from 0 – 100 to set the Intensity of the animation. How sad are you? Are you 35 sad, or 100 sad?

So far I modeled the main character’s head, along with a mysterious Wolf that no one knows about. The main character’s facial animations are done. In the future I’ll model two other mysterious figures that need facial animations… but I won’t give them away now!

Expect to see more character head animations during next month’s update. I’ll also do a more in-depth blog post about Facial Animation Using Morphs.

 

EveryUI.png

Main Menu User Interface

This piece of artwork is still in the planning stages. Unfortunately, I ran out of time this week and had to resort to paper-planning. I would have preferred to mock this up in Photoshop, but my computer died on me before I got around to it (more on that below).

HammerUI.png

Left: The main menu splash screen you see when loading up the game on your device. Right: The Settings and Junk page you see when you press the hammer button on the splash screen.

The plan for the UI is to make it as minimalist as possible, and refrain from using unnecessary text. To that end, I’m currently envisioning a bare bones splash page that just has the protagonist relaxing by a campfire and two buttons on it – a hammer and an arrow. The hammer is meant to indicate “Settings and Junk”. When pressed, it takes you to a side page where you can toggle various togglers™, such as the game language, in-game sound, and auto-skipping cutscenes. Team credits will be displayed there as well. An “X” at the bottom represents “go back” and I’ll try to keep that consistent throughout the whole game.

20170530_143221.jpg

Left: A screen of World 0. Center: A screen of World 1. Right: Half of a screen of World 2, which is locked and cannot be accessed.

The World menu is more involved. Pressing the arrow moves the camera to the right, where we see a 2D view of the first World, Forest. From there, players can swipe left and right to see the other Worlds. Worlds that they aren’t ready to play yet will be locked behind a padlock icon. (No need to reinvent the wheel there) When you’re looking at a World, I want the sounds of that World to play quietly in the background.

20170530_143238.jpg

Tiny overworld map of World 0, which begins with a cutscene “Level” and then has three real Levels. Some are blocked by the shadow.

Pressing the big juicy button with a number on it will take you to the Level Select menu for that World. This will look like a top-down map, with little circles representing the levels each connected by solid black pathways. As you beat more Levels, this map floods with more light. Pressing on a circle will take you to that Level.

That’s the flow I have in mind for the game’s menu. This doesn’t even cover menus that appear INSIDE the game’s Levels, such as when you press the pause button. But in any event, I believe I’ve covered everything the outer menu needs. I just hope this isn’t too much fiddling for a casual audience that isn’t used to games. Getting casual players over these hurdles is always a struggle!

Expect to see a digital version of this UI during next month’s update.

 

DAxOPKeVoAAK6FY

And now his watch is ended.

Tempus Fugit: Memento Mori

Normally in these blog posts, I showcase my cheery optimistic attitude. But not this time.

Late last week, my laptop suffered a blue screen crash and would not reboot to Windows when I tried turning it back on. I’ve been having rolling blue screen crashes for a while, but it usually restarted afterward. Now my computer is in the repair shop, and I’m getting the impression that it doesn’t look good. Probably because the technician told me “this doesn’t look good.” That’s what I get for ignoring the crashes all this time and refusing to pay for cutting-edge anti-virus software.

As I write this blog post on my old college ASUS laptop, I have mountains of artwork to do and very little time to do it. This laptop crash is going to set me back. The worst part is, it’s a waste of time that didn’t need to happen. Fortunately, no artwork was lost because everything is always on GitHub. I’m mostly worried about losing time.

My next update may be a little scarce, but hopefully it will include good news about my computer’s physical (and mental) health. Always back up your work online, kids! You never know when your next blue screen of death will be your last.

 

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

We hope you enjoyed this update about the game’s artwork. Have a question about aesthetics that wasn’t mentioned here? You can find out more about our game at WhereShadowsSlumber.com, ask us on Twitter (@GameRevenant), Facebook, itch.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.

Object Pooling

Alright, it’s finally getting a little bit warmer around here as spring comes and goes, so let’s celebrate by jumping into the pool! That’s right, today we’re going to be talking about an ever-important pattern in game development, the concept of Object Pooling. Object Pooling is a design pattern which involves creating a set of objects – a ‘pool’ – and reusing those objects, rather than creating/destroying objects throughout a game.

pool

Object Pooling involves recycling objects

This is a very important concept in game development, and it’s the first topic we’ve reached that is almost entirely associated with the optimization of a game. For mobile game developers, resources are limited, so it’s important that we don’t waste anything. Object pooling helps us save resources, and is less of a mechanic, and more of a general design pattern. We used it in Where Shadows Slumber, but it isn’t even one of the more defining features of the game. However, it’s still an incredibly important concept.

So, without further ado, let’s dive in!

 

Why do we need Object Pooling?

Unity is a pretty cool system, and it gives you some pretty cool toys to play with. Two powerful toys it gives you are Instantiate() and Destroy(), which allow you to create a new instance of a GameObject, and to get rid of an instance of a GameObject, respectively. I assume that other game engines provide similar functions. If you’ve played around with some simple stuff in Unity, you might have seen how useful these functions can be.

The problem with Instantiate() and Destroy() comes when we try to use them a lot. You see, every time you call Instantiate(), Unity goes into your memory, finds a chunk of memory big enough to store the new object, and allocates it. Conversely, every time you call Destroy(), Unity finds that object in memory, clears it out, and marks that memory as ‘available’. This whole process is aided by the use of a garbage collector, which runs occasionally, making sure that deleted things were actually deleted.

Those of you familiar with computer science may see where I’m going with this. Basically, this isn’t great. Calling Instantiate() or Destroy() every once in a while is fine. But when you call them all the time, Unity starts to slow down. Memory allocations and deallocations are somewhat expensive, meaning the garbage collector will be running a lot, sucking valuable power away from your game! Every time the garbage collector runs, your game might lag a tiny bit. This is doubly true for environments where resources are limited (say, on a mobile device).

So, our clever brain gets to work. ‘Hmm’, it says, ‘if calling these functions is bad, let’s just not call them!’ Brilliant, brain, as usual! Surprisingly, in this case, the first idea that pops into our head is actually pretty good – we just won’t use Instantiate() or Destroy(). Problem solved!

The only remaining question is how to maintain the functionality we had before. We were, for example, using a gun, and every time we fired, we would instantiate a bullet. Every time the bullet hit something, we would destroy it. How can we get that same functionality without using Instantiate() or Destroy()?

 

Object Pooling

The answer to the above questions is, obviously, to use object pooling. The concept is pretty simple – rather than creating a new bullet every time we fire our gun, and then destroying every bullet individually, why don’t we just reuse the bullets? They all look the same, so no one will know the difference!

NonVsPooling

Object pooling in a space shooter (image credit: raywenderlich.com)

This is the idea behind object pooling. Rather than creating and destroying a bunch of bullets every frame, which can get expensive, we simply create a bunch of bullets at the beginning of the game, and reuse them. We store all of the bullets in a ‘pool’ – they’re all deactivated and unmoving, so they have no effect on the game. Then, every time we fire the gun, we grab a bullet from the pool, change its position and velocity so it looks like it’s coming from the gun, and enable it. The bullet flies through the air, and then strikes a wall, or moves off of the screen. At this point, we simply disable the bullet and return it to the pool to be used again!

If this seems a little weird, think of it like extras in a TV show or movie. In the first scene, we need a crowd, so we hire a bunch of actors to be people in the crowd. The next scene is in a different city, but still needs a crowd. Do we fire all of the extras we already hired, and then spend more time hiring different extras? Well, nobody was really paying too much attention to the extras in the first scene – let’s just use them again for the second scene! This is pretty common in TV and movies, and there’s no reason we can’t do the same thing here.

“I gave a very memorable performance as the nurse, and now, suddenly, I’m the waitress? That’s gonna confuse my fans!”
– Phoebe Buffay, Friends

Using object pooling, we can avoid the need for our expensive allocation/deallocation functions (other than at the beginning/end of a level, where slowness is more acceptable) by reusing all sorts of objects. There is a tradeoff here – using an object pool means that, whenever we need a bullet (or any object), we have to be sure that there will be one in the pool. This means that we actually need to store more copies of the object than we ever expect to use. While object pooling makes it easier for the CPU to keep up with what we’re doing, it uses up more memory.

This is called the space-time tradeoff, and it’s pretty common in computer science. The idea is that, in order to optimize for time (make your code run as fast as possible), it generally uses up more space (in the form of RAM). In this case, time refers to time spent in the CPU – saving time means less lag, which makes for a better game. In general, on mobile platforms at least, saving time it more important, so this is a tradeoff we’re happy to make by using object pooling.

 

Where Shadows Slumber

So, how did we use object pooling in Where Shadows Slumber? We don’t have any bullets, so what else can object pooling be used for?

Honestly, object pooling wasn’t incredibly important to the core game – all of our levels are pre-made and we don’t have any projectiles or anything else flying around. Where we did use object pooling was in ‘special effect land’. Every time the main character takes a step, a small sound plays, and in some levels you can see a puff of sand behind him. These are what we have taken to calling footfalls, and they’re one of the main things we used object pooling for.

Footfall

This group of particles is a footfall, and was pulled from a pool rather than instantiated!

In fact, sometimes you may have used object pooling without even realizing it! You see, one of the primary uses for object pooling is within particle systems. A particle system may emit a burst of hundreds of particles at once. Imagine trying to instantiate that many object in the same frame – your game would lag for sure! However, if the particle system uses object pooling, it will simply enable all of those objects, and your game will keep running without a hitch. This allows you to get high-quality particle effects without having to worry too much about the impact on performance.

Hopefully this quick conceptual intro to object pooling helps you out, and saves you many CPU cycles! I should mention that I got an image from this blog post on object pooling, which coincidentally is a very good resource if you want to get a good look at an implementation of object pooling.

 

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

If you have any questions or comments about object pooling (or anything else), 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.