State Of The Art – August 2017

Welcome to State Of The Art, August 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 August!

 

Rekt

Obe’s Feline “Friends”

This part of the update is directly tied to the cutscene discussed below, but I wanted to give it special attention just because I like how they turned out. I modeled some cats! They really only appear during a few short cutscenes during the game, but making each one took quite a long time. Here’s the Leopard:

Leopard

The spots on his coat came out way better than expected, although the top of the head is a bit off.

And the Lion:

Lion.PNG

The way his mane frames his face gets me every time!

I especially like the Lion’s mane. It was a struggle to get it to look as simple as it does. I kept making overly detailed 3D hair but it just looked wrong. At one point I considered using Cloth to simulate a glorious flowing mane, but I knew Jack would probably kill me so I backed off. I ended up going with a simple cylinder with a rotated back and it just looked right as soon as I saw it. I stepped out of my comfort zone and ended up with something super cool! Throw on Jack’s shader and voila – a glorious, friendly* Lion.

Astute observers will notice a few things about these models. For simplicity, they’re actually using the humanoid torso + limbs combo that Obe uses! But the reuse doesn’t end there. The Leopard and the Lion both have the same Head model, just with a different texture. The Lion’s mane does even more to differentiate them. A+ if you noticed this without me telling you!

* Watch the cutscene.

 

Rivah.PNG

World 2 (River)

The River World took a giant leap forward during the month of August. I’d show you a bunch of screenshots, but I made a pledge last month to show more videos of the game in action instead of just screenshots. This is part of pushing ourselves to be better – if the game doesn’t look good in video format, we need to work harder! You’ll notice of course that there’s still no sound, but we’re working on that.

 

The core pillars of the River’s design are its gross yellow water, jet black dirt, log wall structures, and rickety boardwalks. There’s a really cool interplay here between the water and the black foliage – it makes it look like more things are in shadow than there really are. I love how the trees look, stretching out into the water / sky. This is one of my favorite Worlds!

Enjoy the highlight reel of all five Levels in World 2, above. Don’t worry – there’s no spoilers for puzzle solutions, just a walking tour of what each Level looks like.

 

Cutscener.PNG

“Wardens” – The First Cutscene

You walk through the forest, alone and lost. You come to an intersection… which path to take? Suddenly, a Lion appears from behind the shadowy veil. To your left, a Wolf! As they bear down on you, you wonder if they are friend or foe. And what’s that sound behind you?

This cutscene is not quite 100% finished yet, but I’ve reached the point where it’s time to leave it and move on. I’m going to throw some facial animations in there, but I’d like those to coincide with sounds (roaring, laughing, screaming) so I’m avoiding it for now. Of course, as a final pass, we’ll need to add sound effects.

There are also minor touch-ups to his clothing that I need to do. I didn’t have to animate his robe or his chasuble, which was a godsend. But with automated animation comes other issues… notice how his clothing clips through his body and the ground sometimes. It’s possible to fix this – and it’s possible it won’t even be noticeable on an iPhone – but it’s one of those things you need to leave until the end of the project. Focusing all my energy on it now means neglecting the rest of the work on my plate, so it’s not an option.

 

Enjoy the cutscene (above) and look forward to a 100% version later, with sound!

 

CityWIP

What To Expect From September

This coming month, my first task is going to be World 3 – the Aqueduct. We’re pretty much going chronologically here, so that’s next. I’d also love to move on to World 4 – the City. The City has been started, so one Level is already basically done. Getting those two Worlds finished would be awesome! Time will tell.

I’m satisfied with how I animated the Wardens cutscene, which means I might take a break from cutscenes for now. I really just wanted to get that first proof-of-life cutscene done so our audio crew can have something to work on as a reference for how cutscenes work.

Speaking of audio, that will also be my focus this month. I won’t be working on audio per se, but I’ll be paving the way for an audio person to come in and start adding stuff. That means some light scripting and a lot of brainstorming. It’s not visual, but it counts as “aesthetic”. Maybe I should rename this monthly post State of the Aesthetic? Is greater accuracy worth wasting one of the greatest puns of all time? Surely not…

 

See you again in October!

 

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

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.

Advertisements

The 1st Play NYC Ever Was Incredible!

Back in the winter of 2016, Jack and I were delighted to hear that Where Shadows Slumber had been nominated for the ’16 Bit Awards. We had attended a bunch of Playcrafting’s shows, but had never realized the company also ran an award ceremony. Although we didn’t win the category, our ears perked up at the end of the show when we heard Dan Butchko’s plans for the summer. There was going to be “some kind of show on the Intrepid in NYC” and that everyone should “stay tuned for more information.”

Because of some odd scheduling issues with the Intrepid, the show was moved to Terminal 5 on West 56th Street, and given a name: Play NYC. We knew for the longest time that we were definitely going, no matter what. We gambled on the show, buying an 8 x 4 table slot on the third floor and marking the date in our calendars.

The concept seemed too good to be true: a PAX styled gaming event right in our own backyard, where developers could directly interface with customers, fans, and other devs? How could we miss it? But we knew the risks as well: the first year of any show is always the roughest. We had nightmares about sitting at our table in an empty rock hall, our weekend wasting away right before our eyes.

So… how did it go?

 

Disco

Jack pitches Where Shadows Slumber under the watchful eye of the disco ball of doom.

Play NYC Exceeded Our Expectations

This was a great show, and we thoroughly enjoyed everything about it! Setup was smooth, communication with Dan (the guy running the whole thing) was direct and personal, and we got to show Where Shadows Slumber to existing fans and newcomers alike! As for the various aspects of the show:

The Venue: Terminal 5 was an odd choice, but I really liked how it turned out. These conventions are often held in single floor, boring, flat convention spaces where everyone gets a 10 x 10 section. But to be frank (ahhh!) I hate those labyrinthine atrocities of pipe and drape. What I loved about using a concert hall was the vertical element of it: from the top floor, we could see everything. And I’m sure it helped out show-goers to know that they could take everything one floor at a time. The building is not modern at all and has some weird layout issues, but we dealt with the quirks just fine. The best part by far was that some gaming kiosks had couches. Every gaming convention in the world should have couches!

Players

The Crowd: Saturday was way busier than I expected, which was great. At these shows you never want to have the table empty. If someone can be playing your game, you want them there. At the same time, you hate to turn people away, which happens at shows like PAX East where there are just too many people at once. This was a good balance. Considering I was expecting a ghost town, I was blown away! Sunday was more in like with what I expected, definitely slow in the morning. But the afternoon really picked up and we had a strong ending. I have no idea how Dan got so many attendees! Keep up the good work, sir.

Playerz.jpg

The People Attending: Crowd quality is different than crowd volume. Just because a show has a lot of people, that doesn’t mean they are interested in your product or interested in even taking a look. (That’s a dig at you, NY Toy Fair…) As for the people who attended Play NYC, it was a solid mix of young teens and parents, along with fans and developers that were our age. We were really able to relate to everybody and we never felt like people were “brushing us off” for being a mobile game. What surprised me the most was how many cool developers I met! If you’re an audio designer, programmer, or artist, don’t worry – I have your card and you’re in my Rolodex. We’re not hiring anyone else for Where Shadows Slumber, but I’ll consider everyone I spoke to for future projects at Game Revenant. You have time to work on those portfolios!

 

Green

See You Next Year!

If Playcrafting can deliver a stellar experience next year, we’d love to return to Play NYC for their second show. Hopefully the price doesn’t go up by too much – we’ll see what happens. A lot can change in a year. Perhaps Playcrafting will seek out a larger, more traditional venue (although I liked Terminal 5) and try to bring in more people. I heard rumblings about the convention perhaps going a bit longer each day, or extending to Friday. No confirmation of that yet.

We’ll be there regardless. It’s one of the easiest shows for us to do, and many people in the NYC gaming scene are now eagerly looking for news about Where Shadows Slumber. Returning for Play NYC 2018 is a great way to capitalize on all the hype we’ve built over the past year and a half.

We hope to see you at Play NYC 2018!

 

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

Didn’t get a chance to come by our Play NYC table? 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.

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.

State Of The Art – July 2017

Welcome to State Of The Art, July 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 July!

 

MountDoom

Pictured above is our classic scene where Obe throws the ring into Mt. Doom

World 1 (The Jail) Is Ready

It looks like the entire first real World, our volcanic prison that you must escape from, is ready! I say “ready” and not “finished” because nothing in the art world is ever truly finished. But these five Levels are “ready” because I’m ready to move on to something else without worrying about these all the time. They look good. They look pretty done. Will I need to tune them up later? Absolutely. But I’m not going to spend more time getting these Levels from 90% to 100% when there are some Levels at 0%.

Having said that, bask in the molten glory that is World 1!

1-1.png

Level 1-1, “Light” is the first Level of the Jail World.

1-2.png

Level 1-2, “Detour” shows off some of the cell blocks in this prison.

1-3.png

Level 1-3, “Lock” contains a rarely used side-exit door.

1-4.png

Level 1-4, “Pressure” needs a different back wall than the one currently shown.

1-5

Level 1-5, “Ascent” has a lot of annoying overlapping lights and we’ll fix those later.

What do you think of these Levels? Please leave a comment with your feedback, as I have a few concerns of my own and I want to see if casual observers would notice them. Maybe I’m just paranoid!

 

Obe

Obe’s Clothing Is Ready

Our main character has quite the wardrobe. He’s wearing a lot of complicated clothing! Some of it is made from animated mesh, but other parts are physically based cloth that Unity simulates in real-time.

Getting this right has taken me a long time. But now I’m done messing with it and I’m ready to give it the ultimate stress test – cutscenes, weather (wind and rain!), and lots of animation. I believe his accessories can withstand the stress and remain looking cool.

Obe-Pants.PNG

Dude what happened to your pants?!

Undoubtedly, his clothing is going to get messed up sometimes. We’ll just need to identify those situations and preempt them with special scripts that manage his robes and keep them from going haywire.

Obe-Detail.PNG

Currently, the robe can clip through his white alb and skirt. This should be fixed by launch.

What do you think of his clothing? Is it worth it to have such a detailed robe on such a small character? I promise, for these close up cutscenes, it will look great!

 

River

What To Expect In August

This month, I’m going to aggressively go after the Levels in the River World. I’ve been so excited to work on that one for a long time! It’s wide open (as opposed to the claustrophobic Forest and Jail) which is a nice change of pace. The color scheme is totally unique, and the assets are really interesting. There’s some creepy story stuff happening there as well.

I also want to get cutscenes rolling, probably the first two (Intro to Forest, Finale to Forest) since they are the first things players will see. I don’t like the idea of waiting until the very end of the development cycle to start cranking out cutscenes. These things are going to be trailer-fodder and they need to look awesome. A rushed cutscene is probably going to end up being a cut cutscene 😛

See you again on September 1st!

 

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

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.

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.

 

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.