What Happens When You Forget to Write A Blog Post?

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

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

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

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

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

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

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

“Rock, paper, scissors, shoot!”

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

ConceptArt-Murder_Arson

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

Not Really Though…

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

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

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

 

How Hard Can It Be?

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

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

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

Running out of ideas

Running out of ideas!

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

 

Then Why Bother?

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

Blogging

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

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

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

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

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

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

 

So, Why The Where Shadows Slumber Blog?

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

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

ConceptArt-Inhabitants_Citizens

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

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

 

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

Thanks for reading! If you want to know even more about our process, or have any questions about blogging in general, feel free to contact us, and you can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebookitch.io, or Twitch, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

Jack Kelly is the head developer and designer for Where Shadows Slumber.

Advertisements

Designing Obe, The Mysterious Protagonist of Where Shadows Slumber

For years, Jack and I have been referring to the main character of Where Shadows Slumber by euphemisms such as “the main character”, “the protagonist”, and “little lantern dude”. Now that the game’s story is coming together, we have finally given him a name! In this blog post, we’re going to do a deep dive into how we gradually got to this point in the character design process.

 

Obe

Meet Obe (oh-bee)

In Where Shadows Slumber, you guide Obe on his journey using magical shadows that emanate from a mysterious lantern. But the lantern is not the only thing that’s full of mystery. Who is Obe? Why has he come to this strange land? And is that a yarmulke?

We can’t give too much of the story away at this time. You’ll have to play the game when it comes out next year to find out the full story. Suffice it to say, Obe is an elderly man at the end of his life on a quest to set things right. (We would have called the game Old Man’s Journey, but someone beat us to the punch.) Obe didn’t ask for his lantern, but he would be lost without it.

The artwork above is the final rendering of how the character will appear in-game. Once I rig his cloth chasuble to work properly, I’ll post some videos of him in action. Before I do that, let’s take a journey through time to see how we got to this point.

 

thresh_by_predator95-d6zmsh6

You Inspire Me!

From the beginning, Jack and I knew that we would need a character that the Player could guide through the world. Something about our game’s shadow mechanics made us feel that it had to take place in a dark, mysterious landscape. We couldn’t go “full abstract” and make the main character a capsule or something. (Though, that would have made my job as an artist much easier!) We needed to show the shadows interacting with real objects in a real place, which meant the protagonist needed to be an actual humanoid. Moreover, the protagonist either needed to emit light or carry some kind of light source with them. We decided a lantern would look cool, and started exploring characters in popular culture that would inspire our character’s design.

maxresdefault

Jack suggested Thresh from the online game League of Legends. A sinister character, Thresh uses a lantern and a hooked chain to grab his enemies and pull them to their doom. He traps people’s souls in his lantern and tortures them for all eternity.

This was a bit too evil for an indie puzzle game. Thresh looks like a take on the grim reaper, and his lantern isn’t even in the forefront of his design. But still, it was an inspiration! If you ever get creeped out by Obe, that’s because of the Thresh-y part of his design.

tonberry___color

Then I suggested to Jack the design of Tonberry, a strange little green character from the Final Fantasy series. This enemy is apparently quite rare and super dangerous, despite its innocent appearance. Though it has many abilities across multiple Final Fantasy games, the recurring theme is that he slowly advances toward a party member until he is close enough. Then, he stabs them with his knife, delivering an instant kill.

I’m not sure why every character with a lantern in video games is a psycho murderer. That’s a little weird, don’t you think? Surely Where Shadows Slumber will change that perception!

What we enjoyed about Tonberry’s design was the simple, monk-like burlap robes and a nondescript lantern. His disarming appearance was also a huge inspiration for Obe. Now, Obe doesn’t carry a weapon around and he also isn’t a lizard, but his design was heavily influenced by this character.

 

ConceptArt-Inhabitants_Body

The Drawing Board

With a few key characters in mind, I set about drawing lots of pictures of what the game’s protagonist could look like. I began by deconstructing Thresh and Tonberry and distilling them into “mobile” versions. Remember, our game takes place on a small screen, so the character’s key elements must be clearly visible from far away.

ConceptArt-Protagonist-Sketches

What would chibi-Thresh look like? What elements can be stripped away and still retain the design? What elements are not necessary for a peaceful puzzle game?

ConceptArt-GhostCharacter.png

Simple designs for the character. Bottom Left: an unused design for a horrifying shadow creature that only appears in darkness and eats the souls of its victims.

ConceptArt-Protagonist-Body.jpg

The character’s robe became a central part of the design here, acting like Thresh’s gathering shadows and unearthly aura.

As you can see from the drawings, I tried to straddle the line between “cute and disarming” and “somehow a little sinister”. It was important to us that the Player trust the character in the beginning of the game, and then question their motives a little later on. Also pictured above, you can see the beginnings of some other character designs that would use our humanoid model. From an early stage we knew that if there were other humanoids in this universe, they would look like the main character – just slightly altered.

 

boat

First Character: Rayman-like

While this was happening, Jack and I were working on the very first iteration of Where Shadows Slumber. It was still just called “Light / Shadow Game” and we needed a character. Based on my drawings – but too scared to actually try using Unity Cloth – I created a simple character in 3DS Max.

Check out the character in action in the video above. He has a little cone shaped lantern, nubby little arms and legs, a fake robe and hood, one rhombus-shaped eye (!), and fingers. While this design is still near and dear to me, it had a lot of flaws.

One Eye Messes With Depth Perception: So apparently when a character only has one eye, it’s super difficult to tell where they are looking or when their head is turning. As humans, we’re much more used to the human face. We subconsciously compare both eyes to each other and make a judgment call about the way the head is turned based on that. A single eye made it difficult to animate the character properly.

Rayman Limbs Mess With Shadows: I love Rayman limbs. By this, I mean “floating hands and feet that aren’t attached to the torso in a visible way”. I think it’s an underused design. However, as much as I love it, it doesn’t work in a game where characters need to cast shadows and have silhouettes that make sense. We had to cut it.

 

screen_2432x1368_2017-01-24_13-34-45

If At First You Don’t Succeed…

For the next draft of our character model, I took the chibi style to heart and tried to think of a purpose for the character’s robes. It’s not enough to say “he’s wearing robes because he’s traveling and it’s a cloak”. I wanted to give them some kind of a purpose or possible religious significance. Now the character looks more like a cardinal or some kind of priest. This fits with his nondescript age of “old” and allows the Player to begin projecting their beliefs onto the character.

CharacterDesign

This model ended up being really close to the final design, but it just wasn’t there yet. Troubles with rigging the arms, face, and clothing meant that I needed to take one more shot at it. Still, we’re getting there! This character model appears in our Demo. Check out how the character looks in the Demo’s finale cutscene:

What were we saying about all lantern characters being really violent? Oh well… I guess some stereotypes really are true!

 

Happy.PNG

Welcome Home, Obe

Designing a character for this long almost feels like searching for a missing person. There are a lot of promising leads, but none of them pan out until finally you happen to stumble across what you’re looking for.

I feel that our main character has finally come home. He has a personality and feels like someone I can’t control anymore. It’s a strange feeling, but I take it as a sign that he will bring joy and intrigue to players around the world that want to unravel his mysterious story.

 

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

We hope you enjoyed this update about the game’s character artwork. Have a question about Obe 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.