State of the Art – November 2017

Welcome to State Of The Art, November 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.

<Don’t forget to add in some lame excuse about Thanksgiving before you post this>

Without further excuses, let’s explore the major leaps forward we took in November!

 

0-1-Header

The Game’s First Level, “Fallen”

It took me a while to get around to doing this Level, because there’s a bunch of triggers I had to animate and I didn’t feel like doing those. For the longest time, Level 0-2 has been our de facto “first level.”

Dec-5-Blog-Forest

But the game really begins here, along this spooky Forest path, where Obe first encounters the Lantern. You can watch the entire Level in the video below, since it’s so short. (Just ignore the missing sound effects and animation polish, all of that comes later.) Jack and I have a rigid philosophical stance when it comes to game design: we don’t like using text to tell players what to do. That’s annoying! So this Level is designed so that people can learn how to walk. It’s impossible to avoid picking up Obe’s lantern because he automatically does that when you walk on the first open space in the clearing.

This Level didn’t take too long once I actually sat down and did it. Since Obe can only walk around the center of the Level, and his light radius is quite small, there’s a lot of art I can intentionally ignore. This may seem lazy, but there have been times in the past where the opposite has occurred! I’ve done beautiful artwork around the edges of the Level only to be dismayed to find the light never reaches there, and players will never see it. But I still see it. In my dreams.

 

Dec-5-Blog-City-Header

Level 4-3, “Ramparts”

One of the most ambitious Levels we planned for the game has you scaling the ramparts of a city wall as you climb to the palace on top. It’s a transition Level, which makes it super important for the story. The first two Levels in this World take place in the slums, and the final two Levels in this World take place in beautiful palace gardens. We need a bridge in between those two, otherwise the jump from one to the other will be too abrupt for the audience.

Enter Level 4-3, “Ramparts,” a vertical bridge between two different worlds separated by economic class and power. It’s easier to show you than tell you! We begin on the street, with the dogs.*

Dec-5-Blog-City-A.png

*Dogs not included

Then there’s the middle section:

Dec-5-Blog-City-B.png

On top, we can see the palace architecture more clearly:

Dec-5-Blog-City-C

This Level took forever for Jack to make and for me to decorate. Even now, it still needs an extra coat of paint! The puzzle isn’t difficult, but the vertical nature of it means we need to cover up a lot of the screen. I want to put more plants closer to the top, which I didn’t really have time to do yet. Plant life would indicate that even in this barren desert, the wealthy King who lives in the castle gets to be surrounded by beautiful foliage.

 

Dec-5-Blog-Paradise-Header.PNG

Paradise Begun

The game’s final World is a beautiful island paradise floating in the sky. This is somewhat of a story spoiler, but we’ve blogged about it before so I’m not too concerned. Read on at your own peril, I guess?

It’s taken me a while to return to this beautiful setting. Anything that comes last in a video game usually gets the least attention. It’s regrettable, but understandable. After all, if you see a movie in theatres, you often see 100% of it.  Unless you leave in the middle for some reason, you’ll experience the beginning, middle, and ending. But video games are different. Only a fraction of players make it to the end of the game, but by definition anyone who plays a game experiences the first 5 minutes. That’s why those first 5 minutes are so crucial and get so much special treatment.

I’d like to break the chain, if I can. I want people to feel rewarded for getting to the end of this difficult puzzle experience. Here’s the current progress on World 7, which I just started last week. They’re in rough shape at this stage, but you can get a sense of where I’m going with these.

Dec-5-Blog-Paradise-A.png

Level 7-1, “Ladder” is all about compiling a ladder from a bunch of broken pieces. The ladder comes together using the shadows from that conveniently specific rotating object. It’s harder than it looks! I designed this one and I forgot how to solve it. Good luck!

On the first landing, we get a chance to show off that majestic Bermudian inspired architecture I love so much. If I have time, I’ll even include a cool dude relaxing on a chair just to show how far removed this World is from everything below.

Dec-5-Blog-Paradise-B.png

Level 7-2, “Pond” is due for somewhat of a re-do. The major thing I forgot to include here was a pond in the center where that button is. We want some kind of a sacred grove with a sacred button because that’s how you solve this Level – you need to use the center piece in order to drag boxes around and cast the shadows you need to fix the ending staircase.

This is where design and aesthetics conflict. The pathways we need are very specific and jagged, but the “look and feel” we want is uniform and symmetrical. It’s a tough compromise. I’ll return to this one and remove that weird green rock path (a placeholder) and try to do something closer to my original “Toolkit” Level I posted so long ago:

World-7-Paradise

(This isn’t a Level in the game, but rather spec work I did a few months ago when I was beginning each World’s “Toolkit.” But that center pond is making a comeback, just wait for it!)

Dec-5-Blog-Paradise-C.png

Level 7-3, “Tower” isn’t very far along, but it’s such a cool design I thought I would tease it here. You need to see a video of it in action to really grasp what’s going on, so no more for you just yet! Be patient [ ^_^]!

 

UI-Header.PNG

User Interface Sketches

Generally I prefer not to show off drawings that are not part of the game. But Jack and I just started on the user interface design, so it can’t hurt to show you a tiny bit of what I’m working on…

 

It may seem late in the game to handle this, but we decided long ago that we don’t want a complicated user interface. Above, you can see that our Levels contain all the features that a Main Menu would normally have. We don’t really like having a separate menu detached from the game, so you can access all the key stuff just by “pausing” the game.

Note: this is just a Photoshop design. We haven’t coded this in yet, and not all of the buckets you see above are necessarily being included in the final game. For example, being able to take a picture of the Level is an important social feature, but it’s not essential for the game’s launch and may fall by the wayside.

Interacting with phone features is a big pain and it’s one of the toughest things about game development. Making your game work on every single tablet, flip-phone, e-reader and seashell Kindle out there is a nightmare. Maybe we’ll write a blog about that topic once we get more into the weeds of cross-platform development…

 

christmas2012_alternative_santa_onlycoke_flexible

See You Next Year!

The next time you read this particular blog series, it will be 2018 and I’ll be recapping December. Man, where does the time go? This year has gone blazing by!

This month, I hope to finish World 7 and move on to polishing up each Level. That work is highly specific, which is why it was left until the end.

Polishing the Levels will intersect with working on the game’s cutscenes. That’s because some of these Levels have animated characters in them. I’d like to be sure that the animated characters I create work well in both settings, to save myself time later. So don’t be surprised if next month’s update is a bit of a mixed bag. That’s the way it’s going to be from now until the game launches!

 

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

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

Problem Solving: Design and Complexity

Game design and development is a complicated process. Creating an intricate tapestry of player interaction, incentive, and reward can be quite difficult, and you will no doubt run into trouble along the way. This is a simple fact of game development – in fact, this phenomenon represents most of the time you’ll spend working on your game. Therefore, you shouldn’t worry about it when that trouble finds you! However, an important part of how polished your game ends up, how long it takes to make, and whether or not you even get a chance to finish it is how you handle the issues you run into.

At its core, a game can be described by a set of rules which govern gameplay, and a starting game state. A match-three game, for example, can be described by the following rules:

Simple match-three rules

  1. The game starts with a grid of colors.
  2. Any three or more adjacent cells of the same color disappear, granting points to the player.
  3. If there is an empty cell, the cells above it slide down to fill in the space, generating a new cell at the top.
  4. The player may switch the colors in two adjacent cells.
  5. The game may end when the player reaches a certain number of points, or when they make a certain number of moves, or if there are no available moves, etc.

Obviously, these rules don’t encompass everything that happens in a game, and the rules get much more complicated very quickly for more complex games. These simple base rules define your gameplay, but they very quickly become more intricate as you add features and functionality. Let’s look at a few updates to our match-three example:

  • If we want to add a type of cell which can’t be moved, we would have to change rule #4 to “The player may switch the colors in two adjacent cells unless either of those cells is unmovable”.
  • If we want to add an “exploding” cell which eliminates nearby cells, we would have to change rule #2 to “Any three or more adjacent cells of the same color disappear, granting points to the player, and if one of them is an exploding cell, adjacent cells also disappear”.

The base rules handle 90% of the gameplay situations, but we have to add special provisions for exceptions of those rules. In game development (and computer science in general), these exceptions are called edge cases, and, as necessary as they are, they’re super annoying. Your code will include edge cases, and it should, but you have to be careful with them (edge cases may be considered a type of hack, which I discuss in one of my previous blog posts), and you should avoid them when possible. One of the primary ways to do that, depending on your game, is through design – rather than complicating your codebase, you can try to design your game and/or levels in such a way that you don’t need to change your code.

 

An Example from Where Shadows Slumber

Let’s take a look at the inspiration behind this post – a case I ran into in Where Shadows Slumber where I faced such a decision.

1-1 goal

Ominous!

At the end of each level, there’s a ‘goal’ space. When Obe steps on it, it triggers the end-of-level sequence to begin – the lights fade, Obe walks out of the scene, and then the next level loads. The question is, given the game rules, how can I make this happen? I could have added a specific code path for this case, but I realized that I could use some already-existing mechanics to create this effect:

  • The machinery behind buttons can already handle “trigger something when Obe steps on a space”, including a delay for ending the level.
  • The machinery behind Obe walking in at the start of the level allows us to redirect his movement.

This is one way of handling an edge case – try to reduce it into an example of something you already have, thus changing it from an edge case into a normal case. Now we’ve changed the ‘goal’ space into a different-looking button with a redirect space.

Now, there’s another situation involving the goal space where I was given a similar choice. In some levels, there’s a space both to the left and to the right of the goal space. This enables a situation in which the player moves onto the goal space, and then away from the goal space. This creates a problem: the end-of-level ‘button’ will trigger, the lights will dim and the next level will load, but Obe hasn’t left the scene – he’s still just standing there!

ezgif.com-video-to-gif

Well that’s not quite right…

This is a problem I can solve by changing the rules, or by changing the design. The rules for redirecting Obe’s movement only apply when he doesn’t already have a destination. In order to handle this situation, I could add a case that says “if the current node is the goal node, do the redirection”. This requires that I add code to mark a node as the goal node, and to check if the current node is the goal node. While this code would be pretty small and easy to write, it still adds to the overall complexity of the codebase. Is there a way to avoid doing so?

There is, in fact, and it’s quite easy. If we simply remove all of the places where this could happen, then we don’t have to worry it! We’re not “solving” the problem in a conventional sense – if the configuration of spaces were to come up again, the problem would still occur. However, by changing the level design, we remove any chance of that happening.

1-1 goal with boxes

I’ll have Frank make something more on-theme to fill that space

This is another way of handling an edge case – by making a small change to the level design, we’re able to avoid making changes to the codebase. This prevents our code from becoming needlessly more complex, making it easier to understand and maintain. While not every problem can be solved in such a simple way, there are many that can, and keeping an eye out for them is a great way to avoid unnecessary code complexity.

 

Living on the Edge

I keep talking about edge cases and code complexity like they’re bad things. But an entire game is a very complex thing – doesn’t it make sense for the codebase behind it to be complex as well?

There’s nothing inherently wrong with complexity in your code; a well-implemented cache invalidation algorithm is a beautiful thing, complex as it is. What isn’t beautiful is needlessly complex code. The logic in this code is usually hard to follow, makes assumptions, and leaves a lot of small bugs that you’re unlikely to notice right away. This is a recipe for disaster, because every time you try to make a small change, you have to wade through a swamp of half-thought-out code paths, and you end up adding more complexity just so that you don’t have to deal with the complexity that’s already there!

The biggest problem is that it’s very hard to tell the difference between code that’s complex because it has to be (good) and code that’s complex when it doesn’t have to be (bad). The way I deal with this is to try and realize when the code I’m writing is starting to become very complex. Even though I might only be fixing one bug or working on a specific part of the implementation, I try to take a step back and look at the problem that I’m trying to solve, and how I’m solving it. If the problem is a complex one (cache invalidation), then I accept that it’s gonna be a complex algorithm, and keep writing it. If it’s not a complex problem (sorting), I take another look at my code and see if there’s a better way to do what I’m trying to do. In this way, I continuously re-evaluate the complexity of my code, and whether or not I need it.

Hack

Six while loops isn’t too many, right?

I know that “I just know when it’s too complex” might not be the most satisfying answer for those of you who often run into issues of complexity. That feeling is something that you pick up as you do more and more coding, and especially as you revisit your own code – “wow, I can’t believe I wrote such stupid code”. For those who want a more concrete answer, here are some of the ‘red flags’ that I try to keep an eye out for when assessing the complexity of my code:

  • A lot of ‘if’ statements – If your code has a lot (and I mean a lot) of random ‘if’ statements (especially nested ones), then you might want to take another look at the design.
  • “I don’t know…” – If you can’t quickly and easily determine what each piece of your code is meant to be doing, your design might be too complex.
  • Guessing – If you ever find yourself just “trying things” and “seeing if they work”, it’s a clear sign that you don’t understand your code well enough. Take some time and get to know it!
  • Duplicated code – If you have the same block of code copied into a few places, you should revisit your design. Either that block belongs in a helper that you can reference, or the control flow of your code needs to be reconsidered.
  • Asynchronicity – If you’re doing anything asynchronous, you should give your code another look. I know you probably did it right the first time, but asynchronicity is one of the most difficult parts of computer science, and it’s always worth double-checking.

There are a lot of other things that you might notice about your own code and its complexity – these are just a few quick guidelines off the top of my head. Hopefully they help!

 

But Game Development is Fun!

Anyways, I hope I didn’t scare you away from computer science. If anything, I wanted to instill a healthy fear of needless complexity, and I hope that you’ll do what you can to reduce that complexity – whether by redesigning your code or redesigning your levels!

 

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

If you have any questions about code complexity and how to design around it, or if you have any other questions about Where Shadows Slumber, feel free to contact us! You can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebookitch.io, or Twitch, 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